From 9liam@acadia.net Sat Oct 01 12:11:09 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ELjx7-0003lZ-Ae
	for v6ops-archive@megatron.ietf.org; Sat, 01 Oct 2005 12:11:09 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08199
	for <v6ops-archive@ietf.org>; Sat, 1 Oct 2005 12:11:06 -0400 (EDT)
Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1ELk5C-0001QB-7G
	for v6ops-archive@ietf.org; Sat, 01 Oct 2005 12:19:31 -0400
Received: from cpe-72-224-81-57.nycap.res.rr.com ([72.224.81.57])
	by mx2.foretec.com with smtp (Exim 4.24)
	id 1ELjwv-0007Ke-Fa
	for v6ops-archive@ietf.org; Sat, 01 Oct 2005 12:10:59 -0400
Message-ID: <b05201c5c6a0$4bcb1cc5$1b849aff@acadia.net>
From: "Jennifer A. Clark" <9liam@acadia.net>
To: v6ops-archive@ietf.org
Subject: =?iso-8859-1?B?UG9wdWxhciBzb2Z0IC0gZHV0eS1mcmVlIHByaWNlcw==?=
Date: Sat, 01 Oct 2005 15:51:38 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
    type="multipart/alternative";
    boundary="----=_NextPart_000_0000_6F46DC2D.D0D6E03E"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express V6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1

This is a multi-part message in MIME format.

------=_NextPart_000_0000_6F46DC2D.D0D6E03E
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0001_710C8574.799517F4"


------=_NextPart_001_0001_710C8574.799517F4
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

      Access all the software you ever imagined for extremely low prices!
We sell software 2-6 times cheaper than retail price.

A few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many other... To visit us go:

http://www.all-cds.net

Regards,
Jennifer A. Clark


________________________________ 
To change your mail preferences, go here
________________________________ 

 
------=_NextPart_001_0001_710C8574.799517F4
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<!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.2900.2604" name=GENERATOR></HEAD>
<BODY>
<CENTER>
<TABLE cellSpacing=0 cellPadding=0 width=800 align=center border=0>
<table id="76366F70732D6172636869766540696574662E6F7267">  <TBODY>
  <TR>
    <TD>Access all the software you ever imagined for 
      extremely low 
      prices!<BR>We sell software 2-6 times cheaper than retail 
      price.<BR><BR>A few examples:<BR>$79.95 Windows XP Professional (Including: Service Pack 
      2)<BR>$89.95 Microsoft Office 2003 Professional / $79.95 Office 
      XP Professional<BR>$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady 
      CS)<BR>$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX<BR>$149.95 Adobe Creative Suite Premium (5 CD)<br>$79.95 Adobe Acrobat 6.0 
      Professional<BR>$59.95 Corel Draw Graphics Suite 11<BR><BR>
Special offers:<br>
$89.95 Windows XP Pro + Office XP Pro<br>
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10<br>
$109.95 Dreamweaver MX 2004 + Flash MX 2004<br><br>


All main products from Microsoft, 
      Adobe, Macromedia, Corel, etc.<BR>And many 
      other... To visit 
      us go:<BR><BR><A 
      href="http://www.all-cds.net">http://www.all-cds.net</A><BR><BR>Regards,<BR>Jennifer A. Clark<BR><BR><BR>________________________________     <BR>To change your mail preferences, go <a href="http://www.all-cds.net/uns.htm">here</A><BR>________________________________

      <P></P></TD></TR></TBODY></TABLE></CENTER></BODY></HTML>

------=_NextPart_001_0001_710C8574.799517F4--



------=_NextPart_000_0000_6F46DC2D.D0D6E03E--




From owner-v6ops@ops.ietf.org Wed Oct 05 12:20:15 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENC06-000567-VW
	for v6ops-archive@megatron.ietf.org; Wed, 05 Oct 2005 12:20:15 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02637
	for <v6ops-archive@lists.ietf.org>; Wed, 5 Oct 2005 12:20:11 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENBwP-0003pY-JM
	for v6ops-data@psg.com; Wed, 05 Oct 2005 16:16:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENBwO-0003pI-5b
	for v6ops@ops.ietf.org; Wed, 05 Oct 2005 16:16:24 +0000
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA17431;
	Wed, 5 Oct 2005 11:16:22 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j95GGMN00550;
	Wed, 5 Oct 2005 11:16:22 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Oct 2005 09:16:22 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Wed, 5 Oct 2005 09:16:21 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D507B@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXAW1x+TtPa9HKuRSa+/F0sREjUuQFs2JTAAO4UHWA=
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 05 Oct 2005 16:16:22.0684 (UTC) FILETIME=[208F6DC0:01C5C9C8]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,

Please see the following draft which documents operational issues
relevant to v6ops and calls for a solution:

http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt

Please note that this obsoletes a previos draft called:
"Requirements for Link Adaptation over IP-in-IPv4 Tunnels".

Fred
fred.l.templin@boeing.com  =20

> -----Original Message-----
> From: Templin, Fred L=20
> Sent: Friday, September 30, 2005 3:40 PM
> To: Fred Baker
> Cc: v6ops@ops.ietf.org
> Subject: Requirements for Link Adaptation over IP-in-IPv4=20
> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)=20
>=20
> Fred - please see:
>=20
> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> qts-00.txt
>=20
> Fred
> fred.l.templin@boeing.com
>=20
> > -----Original Message-----
> > From: Fred Baker [mailto:fred@cisco.com]=20
> > Sent: Friday, September 23, 2005 9:24 AM
> > To: Templin, Fred L
> > Cc: v6ops@ops.ietf.org
> > Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels=20
> >=20
> > Does it still propose a protocol or protocol change?
> >=20
> > I don't know offhand whether the charter of v6ops then precluded =20
> > protocol work, and won't go into whether it was proper for=20
> [MECH] to =20
> > be done in v6ops. Given the present charter, I can treat it as a =20
> > requirements document that may be asking for something like=20
> the work =20
> > you are proposing. But my read of the document you pointed to=20
> > is that =20
> > it is still proposing an incompatible change (as in "unchanged =20
> > equipment will not perform the function and once the message is =20
> > segmented in this fashion it must be reassembled in this fashion.
> >=20
> > I think that has to be done in a WG chartered to do non-backward-=20
> > compatible changes to IPv4.
> >=20
> > On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> >=20
> > > Can this work be contributed as an extension to [MECH]?
> > >
> >=20
>=20
>=20




From owner-v6ops@ops.ietf.org Wed Oct 05 12:32:34 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENCC2-0000nI-H5
	for v6ops-archive@megatron.ietf.org; Wed, 05 Oct 2005 12:32:34 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03043
	for <v6ops-archive@lists.ietf.org>; Wed, 5 Oct 2005 12:32:31 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENCBM-0004rs-P9
	for v6ops-data@psg.com; Wed, 05 Oct 2005 16:31:52 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [213.136.24.43] (helo=purgatory.unfix.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ENCBL-0004ra-R2
	for v6ops@ops.ietf.org; Wed, 05 Oct 2005 16:31:52 +0000
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 01D928F1B;
	Wed,  5 Oct 2005 18:31:47 +0200 (CEST)
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
From: Jeroen Massar <jeroen@unfix.org>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: v6ops@ops.ietf.org
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D507B@XCH-NW-7V2.nw.nos.boeing.com>
References: 
	 <39C363776A4E8C4A94691D2BD9D1C9A10D507B@XCH-NW-7V2.nw.nos.boeing.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-+p4lswSwmITC7088iS4y"
Organization: Unfix
Date: Wed, 05 Oct 2005 18:31:43 +0200
Message-Id: <1128529903.1985.8.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-+p4lswSwmITC7088iS4y
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2005-10-05 at 09:16 -0700, Templin, Fred L wrote:
> Fred,
>=20
> Please see the following draft which documents operational issues
> relevant to v6ops and calls for a solution:
>=20
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>=20
> Please note that this obsoletes a previos draft called:
> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".

Are there implementations/prototypes of this protocol (publically)
available? eg Linux/BSD? It sounds really good and would replace quite a
number of manual knobs, especially as MTU's of endusers (eg dsl) have
been going up and using 1280m,unless manually changed, is thus not very
efficient.

Greets,
 Jeroen


--=-+p4lswSwmITC7088iS4y
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBDQ//vKaooUjM+fCMRAvixAJ9lTJ2fhGn+SBg2TFWzTUQyzSuLrACgpVfN
3TOdEPvr6rfhZl9oQAbiL9E=
=7dty
-----END PGP SIGNATURE-----

--=-+p4lswSwmITC7088iS4y--





From owner-v6ops@ops.ietf.org Wed Oct 05 16:37:02 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENG0b-00025g-GU
	for v6ops-archive@megatron.ietf.org; Wed, 05 Oct 2005 16:37:02 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16230
	for <v6ops-archive@lists.ietf.org>; Wed, 5 Oct 2005 16:36:58 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENFxh-000PVT-F0
	for v6ops-data@psg.com; Wed, 05 Oct 2005 20:34:01 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENFxg-000PVG-Ca
	for v6ops@ops.ietf.org; Wed, 05 Oct 2005 20:34:00 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-3.cisco.com with ESMTP; 05 Oct 2005 13:34:00 -0700
X-IronPort-AV: i="3.97,178,1125903600"; 
   d="scan'208"; a="348615710:sNHT29006688"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j95KXv4u023343;
	Wed, 5 Oct 2005 13:33:58 -0700 (PDT)
Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j95KirIY026925;
	Wed, 5 Oct 2005 13:45:14 -0700
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D507B@XCH-NW-7V2.nw.nos.boeing.com>
References: <39C363776A4E8C4A94691D2BD9D1C9A10D507B@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <CA4102E2-2BC2-4F2B-B30B-D6F1091FA823@cisco.com>
Cc: v6ops@ops.ietf.org, Matt Mathis <mathis@psc.edu>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Wed, 5 Oct 2005 13:33:55 -0700
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=3447; t=1128545114; x=1128977314;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Requirements=20for=20IP-in-IP=20Tunnel=20MTU=20Assurance|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Wed,=205=20Oct=202005=2013=3A33=3A55=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=GePzQq//mwTe0qzOz9VRy6S+TGRDQHpFK3w92BZYfK0f8ODTe7Pah+8Jom8E8HqoGSmED8tW
	EQFk5er4vlTeKdGajzZHiDVlrmPtEK+u7Ypy+N/2qzQVS0LO3hBABMd2hSZKdPulCNU47nHpL08
	VfcdkKfBZoDfkjcd3Nnn6CaE=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft- 
mathis-pmtud-method-00.txt. The fundamental algorithm is that the  
sending TCP starts from the negotiated MSS (or should transmission  
suddenly stop being successful, potentially due to a route change  
that reduces the real path MTU from the current message size it is  
sending) and reduces its segment size until succeeds in getting a  
packet through, and then periodically attempts to increase the  
message size in order to take advantage of capacity that might become  
available as routes shift. It seems that this fundamental approach  
would address your issues. Does it?

As to the efficiency of file transfer, yes, if the header overhead is  
of fixed size, carrying more payload will increase efficiency. ie, if  
the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6  
MTU is 1500 bytes, the maximum payload we can carry is 1440 bytes, or  
96%, and being able to switch that to a 9180 byte IPv6 MTU would  
change the efficiency to 99.3% and reduce the interrupt load an the  
two hosts by a factor of about 9180/1500. Changing from 1280 to 1500  
bytes, however, is a change from 95.3% to 96% efficiency, which seems  
relatively minor, and switching from 1280 to 1380 bytes of payload  
seems even more trivial.

The principal value of getting the pmtu right, it seems to me, is to  
first get an estimated pmtu that in fact works at all (downsize it  
from the negotiated MSS to a packet size that works regardless of  
what hiccups lie en route), and second to that, it would be really  
nice to minimize the interrupt load on the sending and receiving  
hosts in order to balance the goals of maximizing throughput and  
minimizing the impact on the hosts themselves. ie, if the sender and  
receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the  
path, carrying a 1280 byte payload is better than carrying a 1440  
byte payload because the former works and the latter doesn't, and it  
would be nice to be able to figure out that a 1380 byte payload would  
also work and be a .35% improvement in efficiency.

So, question (and yes, this is a question): are you chasing a problem  
I don't see? What is the objective here?

On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:

> Fred,
>
> Please see the following draft which documents operational issues
> relevant to v6ops and calls for a solution:
>
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>
> Please note that this obsoletes a previos draft called:
> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
>
> Fred
> fred.l.templin@boeing.com
>
>
>> -----Original Message-----
>> From: Templin, Fred L
>> Sent: Friday, September 30, 2005 3:40 PM
>> To: Fred Baker
>> Cc: v6ops@ops.ietf.org
>> Subject: Requirements for Link Adaptation over IP-in-IPv4
>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
>>
>> Fred - please see:
>>
>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
>> qts-00.txt
>>
>> Fred
>> fred.l.templin@boeing.com
>>
>>
>>> -----Original Message-----
>>> From: Fred Baker [mailto:fred@cisco.com]
>>> Sent: Friday, September 23, 2005 9:24 AM
>>> To: Templin, Fred L
>>> Cc: v6ops@ops.ietf.org
>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
>>>
>>> Does it still propose a protocol or protocol change?
>>>
>>> I don't know offhand whether the charter of v6ops then precluded
>>> protocol work, and won't go into whether it was proper for
>>>
>> [MECH] to
>>
>>> be done in v6ops. Given the present charter, I can treat it as a
>>> requirements document that may be asking for something like
>>>
>> the work
>>
>>> you are proposing. But my read of the document you pointed to
>>> is that
>>> it is still proposing an incompatible change (as in "unchanged
>>> equipment will not perform the function and once the message is
>>> segmented in this fashion it must be reassembled in this fashion.
>>>
>>> I think that has to be done in a WG chartered to do non-backward-
>>> compatible changes to IPv4.
>>>
>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
>>>
>>>
>>>> Can this work be contributed as an extension to [MECH]?
>>>>
>>>>
>>>
>>>
>>
>>
>




From owner-v6ops@ops.ietf.org Wed Oct 05 17:07:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENGUM-0000ef-JP
	for v6ops-archive@megatron.ietf.org; Wed, 05 Oct 2005 17:07:47 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25725
	for <v6ops-archive@lists.ietf.org>; Wed, 5 Oct 2005 17:07:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENGTZ-0003MV-5s
	for v6ops-data@psg.com; Wed, 05 Oct 2005 21:06:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENGTV-0003Lg-S2
	for v6ops@ops.ietf.org; Wed, 05 Oct 2005 21:06:53 +0000
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA16099;
	Wed, 5 Oct 2005 14:06:44 -0700 (PDT)
Received: from XCH-NWBH-10.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j95L6hi11412;
	Wed, 5 Oct 2005 14:06:43 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Wed, 5 Oct 2005 14:05:32 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Wed, 5 Oct 2005 14:05:31 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D5080@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXJ7CwbnBxWHUiHR8G9L2DOYzHOWgAAeJmQ
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 05 Oct 2005 21:05:32.0552 (UTC) FILETIME=[85E33080:01C5C9F0]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,

Yes, I know about Matt Mathis' work on Packetization Layer Path
MTU Discovery (PLPMTUD) but that work covers packetization layers
above layer 3 and is independent of the requirement to provide an
assured MTU below layer 3 for IP/IP tunnels.

To your question, the requirement is for an assured MTU for IP/IP
tunnels, i.e., when the tunnel MTU is X bytes then upper layer
protocols can be assured that packets no larger than X will
traverse the tunnel under normal circumstances or a layer 3
"packet too big" message will be returned that informs upper
layers of a smaller MTU. For tunnels over IPv4, if no other
mechanism were provided then the only assured MTU that could
be offered would be 68 bytes since RFC 791 specifies that as
the minimum link MTU for IPv4. But, IPv6 needs to see an assured
MTU of 1280 bytes so some form of MTU assurance for tunnels
is needed.

Fred
fred.l.templin@boeing.com  =20

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Wednesday, October 05, 2005 1:34 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-=20
> mathis-pmtud-method-00.txt. The fundamental algorithm is that the =20
> sending TCP starts from the negotiated MSS (or should transmission =20
> suddenly stop being successful, potentially due to a route change =20
> that reduces the real path MTU from the current message size it is =20
> sending) and reduces its segment size until succeeds in getting a =20
> packet through, and then periodically attempts to increase the =20
> message size in order to take advantage of capacity that=20
> might become =20
> available as routes shift. It seems that this fundamental approach =20
> would address your issues. Does it?
>=20
> As to the efficiency of file transfer, yes, if the header=20
> overhead is =20
> of fixed size, carrying more payload will increase=20
> efficiency. ie, if =20
> the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6 =20
> MTU is 1500 bytes, the maximum payload we can carry is 1440=20
> bytes, or =20
> 96%, and being able to switch that to a 9180 byte IPv6 MTU would =20
> change the efficiency to 99.3% and reduce the interrupt load an the =20
> two hosts by a factor of about 9180/1500. Changing from 1280 to 1500 =20
> bytes, however, is a change from 95.3% to 96% efficiency,=20
> which seems =20
> relatively minor, and switching from 1280 to 1380 bytes of payload =20
> seems even more trivial.
>=20
> The principal value of getting the pmtu right, it seems to me, is to =20
> first get an estimated pmtu that in fact works at all (downsize it =20
> from the negotiated MSS to a packet size that works regardless of =20
> what hiccups lie en route), and second to that, it would be really =20
> nice to minimize the interrupt load on the sending and receiving =20
> hosts in order to balance the goals of maximizing throughput and =20
> minimizing the impact on the hosts themselves. ie, if the sender and =20
> receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the =20
> path, carrying a 1280 byte payload is better than carrying a 1440 =20
> byte payload because the former works and the latter doesn't, and it =20
> would be nice to be able to figure out that a 1380 byte=20
> payload would =20
> also work and be a .35% improvement in efficiency.
>=20
> So, question (and yes, this is a question): are you chasing a=20
> problem =20
> I don't see? What is the objective here?
>=20
> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>=20
> > Fred,
> >
> > Please see the following draft which documents operational issues
> > relevant to v6ops and calls for a solution:
> >
> >=20
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> >
> > Please note that this obsoletes a previos draft called:
> > "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >
> >> -----Original Message-----
> >> From: Templin, Fred L
> >> Sent: Friday, September 30, 2005 3:40 PM
> >> To: Fred Baker
> >> Cc: v6ops@ops.ietf.org
> >> Subject: Requirements for Link Adaptation over IP-in-IPv4
> >> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> >>
> >> Fred - please see:
> >>
> >> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> >> qts-00.txt
> >>
> >> Fred
> >> fred.l.templin@boeing.com
> >>
> >>
> >>> -----Original Message-----
> >>> From: Fred Baker [mailto:fred@cisco.com]
> >>> Sent: Friday, September 23, 2005 9:24 AM
> >>> To: Templin, Fred L
> >>> Cc: v6ops@ops.ietf.org
> >>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> >>>
> >>> Does it still propose a protocol or protocol change?
> >>>
> >>> I don't know offhand whether the charter of v6ops then precluded
> >>> protocol work, and won't go into whether it was proper for
> >>>
> >> [MECH] to
> >>
> >>> be done in v6ops. Given the present charter, I can treat it as a
> >>> requirements document that may be asking for something like
> >>>
> >> the work
> >>
> >>> you are proposing. But my read of the document you pointed to
> >>> is that
> >>> it is still proposing an incompatible change (as in "unchanged
> >>> equipment will not perform the function and once the message is
> >>> segmented in this fashion it must be reassembled in this fashion.
> >>>
> >>> I think that has to be done in a WG chartered to do non-backward-
> >>> compatible changes to IPv4.
> >>>
> >>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> >>>
> >>>
> >>>> Can this work be contributed as an extension to [MECH]?
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>=20




From owner-v6ops@ops.ietf.org Wed Oct 05 20:39:24 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENJnA-0004pw-9B
	for v6ops-archive@megatron.ietf.org; Wed, 05 Oct 2005 20:39:24 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11659
	for <v6ops-archive@lists.ietf.org>; Wed, 5 Oct 2005 20:39:22 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENJkc-000JYq-G3
	for v6ops-data@psg.com; Thu, 06 Oct 2005 00:36:46 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENJkb-000JYc-0e
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 00:36:45 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-1.cisco.com with ESMTP; 05 Oct 2005 17:36:44 -0700
X-IronPort-AV: i="3.97,179,1125903600"; 
   d="scan'208"; a="663787063:sNHT29151372"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j960af4u024173;
	Wed, 5 Oct 2005 17:36:42 -0700 (PDT)
Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j960lWpl028988;
	Wed, 5 Oct 2005 17:47:57 -0700
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D5080@XCH-NW-7V2.nw.nos.boeing.com>
References: <39C363776A4E8C4A94691D2BD9D1C9A10D5080@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <96913C60-C56D-4F6E-8FE6-A889B45DE72E@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Wed, 5 Oct 2005 17:36:39 -0700
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=5049; t=1128559677; x=1128991877;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Requirements=20for=20IP-in-IP=20Tunnel=20MTU=20Assurance|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Wed,=205=20Oct=202005=2017=3A36=3A39=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=qY9hT7zahDpJUCmBDqixv36bo/C8/RxnvYnYVZytHku9L3olS6vtSyMLrwI6YHeo5tjvVmMq
	svjQrWM6JBbdg4lMLVE+Xz0p+3Y770F8NViTWilGXypYi5v9a9le9j0KH6f2WGbwynjCqvQsO3Y
	H/yp0mbEFAwOf/fmZ3D6fNCc=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

ah. ok.

so, dumb question of the month. are you looking for a simple protocol  
that can be run over such a tunnel (including not only ip/ip, but  
GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would  
something along the lines of pmtu accomplish it? As in, it seems to  
me that the algrorithm is funcdamentally useful for things other than  
TCP.


On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:

> Fred,
>
> Yes, I know about Matt Mathis' work on Packetization Layer Path
> MTU Discovery (PLPMTUD) but that work covers packetization layers
> above layer 3 and is independent of the requirement to provide an
> assured MTU below layer 3 for IP/IP tunnels.
>
> To your question, the requirement is for an assured MTU for IP/IP
> tunnels, i.e., when the tunnel MTU is X bytes then upper layer
> protocols can be assured that packets no larger than X will
> traverse the tunnel under normal circumstances or a layer 3
> "packet too big" message will be returned that informs upper
> layers of a smaller MTU. For tunnels over IPv4, if no other
> mechanism were provided then the only assured MTU that could
> be offered would be 68 bytes since RFC 791 specifies that as
> the minimum link MTU for IPv4. But, IPv6 needs to see an assured
> MTU of 1280 bytes so some form of MTU assurance for tunnels
> is needed.
>
> Fred
> fred.l.templin@boeing.com
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]
>> Sent: Wednesday, October 05, 2005 1:34 PM
>> To: Templin, Fred L
>> Cc: v6ops@ops.ietf.org; Matt Mathis
>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>
>> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-
>> mathis-pmtud-method-00.txt. The fundamental algorithm is that the
>> sending TCP starts from the negotiated MSS (or should transmission
>> suddenly stop being successful, potentially due to a route change
>> that reduces the real path MTU from the current message size it is
>> sending) and reduces its segment size until succeeds in getting a
>> packet through, and then periodically attempts to increase the
>> message size in order to take advantage of capacity that
>> might become
>> available as routes shift. It seems that this fundamental approach
>> would address your issues. Does it?
>>
>> As to the efficiency of file transfer, yes, if the header
>> overhead is
>> of fixed size, carrying more payload will increase
>> efficiency. ie, if
>> the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6
>> MTU is 1500 bytes, the maximum payload we can carry is 1440
>> bytes, or
>> 96%, and being able to switch that to a 9180 byte IPv6 MTU would
>> change the efficiency to 99.3% and reduce the interrupt load an the
>> two hosts by a factor of about 9180/1500. Changing from 1280 to 1500
>> bytes, however, is a change from 95.3% to 96% efficiency,
>> which seems
>> relatively minor, and switching from 1280 to 1380 bytes of payload
>> seems even more trivial.
>>
>> The principal value of getting the pmtu right, it seems to me, is to
>> first get an estimated pmtu that in fact works at all (downsize it
>> from the negotiated MSS to a packet size that works regardless of
>> what hiccups lie en route), and second to that, it would be really
>> nice to minimize the interrupt load on the sending and receiving
>> hosts in order to balance the goals of maximizing throughput and
>> minimizing the impact on the hosts themselves. ie, if the sender and
>> receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the
>> path, carrying a 1280 byte payload is better than carrying a 1440
>> byte payload because the former works and the latter doesn't, and it
>> would be nice to be able to figure out that a 1380 byte
>> payload would
>> also work and be a .35% improvement in efficiency.
>>
>> So, question (and yes, this is a question): are you chasing a
>> problem
>> I don't see? What is the objective here?
>>
>> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>>
>>
>>> Fred,
>>>
>>> Please see the following draft which documents operational issues
>>> relevant to v6ops and calls for a solution:
>>>
>>>
>>>
>> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>>
>>>
>>> Please note that this obsoletes a previos draft called:
>>> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
>>>
>>> Fred
>>> fred.l.templin@boeing.com
>>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: Templin, Fred L
>>>> Sent: Friday, September 30, 2005 3:40 PM
>>>> To: Fred Baker
>>>> Cc: v6ops@ops.ietf.org
>>>> Subject: Requirements for Link Adaptation over IP-in-IPv4
>>>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
>>>>
>>>> Fred - please see:
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
>>>> qts-00.txt
>>>>
>>>> Fred
>>>> fred.l.templin@boeing.com
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>>> Sent: Friday, September 23, 2005 9:24 AM
>>>>> To: Templin, Fred L
>>>>> Cc: v6ops@ops.ietf.org
>>>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
>>>>>
>>>>> Does it still propose a protocol or protocol change?
>>>>>
>>>>> I don't know offhand whether the charter of v6ops then precluded
>>>>> protocol work, and won't go into whether it was proper for
>>>>>
>>>>>
>>>> [MECH] to
>>>>
>>>>
>>>>> be done in v6ops. Given the present charter, I can treat it as a
>>>>> requirements document that may be asking for something like
>>>>>
>>>>>
>>>> the work
>>>>
>>>>
>>>>> you are proposing. But my read of the document you pointed to
>>>>> is that
>>>>> it is still proposing an incompatible change (as in "unchanged
>>>>> equipment will not perform the function and once the message is
>>>>> segmented in this fashion it must be reassembled in this fashion.
>>>>>
>>>>> I think that has to be done in a WG chartered to do non-backward-
>>>>> compatible changes to IPv4.
>>>>>
>>>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Can this work be contributed as an extension to [MECH]?
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>




From owner-v6ops@ops.ietf.org Thu Oct 06 11:49:46 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENY0A-0001f9-5e
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 11:49:46 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11352
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 11:49:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENXxt-000N56-9X
	for v6ops-data@psg.com; Thu, 06 Oct 2005 15:47:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENXxp-000N4q-SD
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 15:47:21 +0000
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA22542;
	Thu, 6 Oct 2005 08:47:11 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j96FlAo06633;
	Thu, 6 Oct 2005 10:47:10 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Oct 2005 08:47:00 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Thu, 6 Oct 2005 08:46:59 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D5082@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXKD5AmB7k/eL7sTfW1s64cZneyTQAewbzg
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 06 Oct 2005 15:47:00.0207 (UTC) FILETIME=[307487F0:01C5CA8D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,

I'm not sure I exactly understand your question, but the requirement
is for a path MTU assurance mechanism that is employed *within* the
tunnel to ensure that packets no larger than the tunnel MTU make it
through to the other side of the tunnel, i.e., the mechanism would act
only on one hop of what may be multiple hop path. The path MTU method
outlined in Matt Mathis' draft is employed at packetization layers
*above* the tunnel to determine the MTU of the path that may extend
many hops beyond the other side of the tunnel, and I agree that the
algorithm could be used for protocols other than TCP.

The algorithm used by the tunnel MTU assurance mechanism might be
quite similar to that described in Matt's draft, but the use case
and implementation are different. In fact, it could happen that
implementations of Matt's packetization layer path MTU scheme and
a tunnel MTU assurance mechanism would occur in the same physical
box and would act at independently of each other.

Fred
fred.l.templin@boeing.com
    =20

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Wednesday, October 05, 2005 5:37 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> ah. ok.
>=20
> so, dumb question of the month. are you looking for a simple=20
> protocol =20
> that can be run over such a tunnel (including not only ip/ip, but =20
>=20
> GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would =20
> something along the lines of pmtu accomplish it? As in, it seems to =20
> me that the algrorithm is funcdamentally useful for things=20
> other than =20
> TCP.
>=20
>=20
> On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:
>=20
> > Fred,
> >
> > Yes, I know about Matt Mathis' work on Packetization Layer Path
> > MTU Discovery (PLPMTUD) but that work covers packetization layers
> > above layer 3 and is independent of the requirement to provide an
> > assured MTU below layer 3 for IP/IP tunnels.
> >
> > To your question, the requirement is for an assured MTU for IP/IP
> > tunnels, i.e., when the tunnel MTU is X bytes then upper layer
> > protocols can be assured that packets no larger than X will
> > traverse the tunnel under normal circumstances or a layer 3
> > "packet too big" message will be returned that informs upper
> > layers of a smaller MTU. For tunnels over IPv4, if no other
> > mechanism were provided then the only assured MTU that could
> > be offered would be 68 bytes since RFC 791 specifies that as
> > the minimum link MTU for IPv4. But, IPv6 needs to see an assured
> > MTU of 1280 bytes so some form of MTU assurance for tunnels
> > is needed.
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >
> >> -----Original Message-----
> >> From: Fred Baker [mailto:fred@cisco.com]
> >> Sent: Wednesday, October 05, 2005 1:34 PM
> >> To: Templin, Fred L
> >> Cc: v6ops@ops.ietf.org; Matt Mathis
> >> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
> >>
> >> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-
> >> mathis-pmtud-method-00.txt. The fundamental algorithm is that the
> >> sending TCP starts from the negotiated MSS (or should transmission
> >> suddenly stop being successful, potentially due to a route change
> >> that reduces the real path MTU from the current message size it is
> >> sending) and reduces its segment size until succeeds in getting a
> >> packet through, and then periodically attempts to increase the
> >> message size in order to take advantage of capacity that
> >> might become
> >> available as routes shift. It seems that this fundamental approach
> >> would address your issues. Does it?
> >>
> >> As to the efficiency of file transfer, yes, if the header
> >> overhead is
> >> of fixed size, carrying more payload will increase
> >> efficiency. ie, if
> >> the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6
> >> MTU is 1500 bytes, the maximum payload we can carry is 1440
> >> bytes, or
> >> 96%, and being able to switch that to a 9180 byte IPv6 MTU would
> >> change the efficiency to 99.3% and reduce the interrupt load an the
> >> two hosts by a factor of about 9180/1500. Changing from=20
> 1280 to 1500
> >> bytes, however, is a change from 95.3% to 96% efficiency,
> >> which seems
> >> relatively minor, and switching from 1280 to 1380 bytes of payload
> >> seems even more trivial.
> >>
> >> The principal value of getting the pmtu right, it seems to=20
> me, is to
> >> first get an estimated pmtu that in fact works at all (downsize it
> >> from the negotiated MSS to a packet size that works regardless of
> >> what hiccups lie en route), and second to that, it would be really
> >> nice to minimize the interrupt load on the sending and receiving
> >> hosts in order to balance the goals of maximizing throughput and
> >> minimizing the impact on the hosts themselves. ie, if the=20
> sender and
> >> receiver are on 10/100 Ethernets and there is an IP/IP=20
> tunnel on the
> >> path, carrying a 1280 byte payload is better than carrying a 1440
> >> byte payload because the former works and the latter=20
> doesn't, and it
> >> would be nice to be able to figure out that a 1380 byte
> >> payload would
> >> also work and be a .35% improvement in efficiency.
> >>
> >> So, question (and yes, this is a question): are you chasing a
> >> problem
> >> I don't see? What is the objective here?
> >>
> >> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
> >>
> >>
> >>> Fred,
> >>>
> >>> Please see the following draft which documents operational issues
> >>> relevant to v6ops and calls for a solution:
> >>>
> >>>
> >>>
> >>=20
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> >>
> >>>
> >>> Please note that this obsoletes a previos draft called:
> >>> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> >>>
> >>> Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Templin, Fred L
> >>>> Sent: Friday, September 30, 2005 3:40 PM
> >>>> To: Fred Baker
> >>>> Cc: v6ops@ops.ietf.org
> >>>> Subject: Requirements for Link Adaptation over IP-in-IPv4
> >>>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> >>>>
> >>>> Fred - please see:
> >>>>
> >>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> >>>> qts-00.txt
> >>>>
> >>>> Fred
> >>>> fred.l.templin@boeing.com
> >>>>
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Fred Baker [mailto:fred@cisco.com]
> >>>>> Sent: Friday, September 23, 2005 9:24 AM
> >>>>> To: Templin, Fred L
> >>>>> Cc: v6ops@ops.ietf.org
> >>>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> >>>>>
> >>>>> Does it still propose a protocol or protocol change?
> >>>>>
> >>>>> I don't know offhand whether the charter of v6ops then precluded
> >>>>> protocol work, and won't go into whether it was proper for
> >>>>>
> >>>>>
> >>>> [MECH] to
> >>>>
> >>>>
> >>>>> be done in v6ops. Given the present charter, I can treat it as a
> >>>>> requirements document that may be asking for something like
> >>>>>
> >>>>>
> >>>> the work
> >>>>
> >>>>
> >>>>> you are proposing. But my read of the document you pointed to
> >>>>> is that
> >>>>> it is still proposing an incompatible change (as in "unchanged
> >>>>> equipment will not perform the function and once the message is
> >>>>> segmented in this fashion it must be reassembled in=20
> this fashion.
> >>>>>
> >>>>> I think that has to be done in a WG chartered to do=20
> non-backward-
> >>>>> compatible changes to IPv4.
> >>>>>
> >>>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> >>>>>
> >>>>>
> >>>>>
> >>>>>> Can this work be contributed as an extension to [MECH]?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >
>=20
>=20




From owner-v6ops@ops.ietf.org Thu Oct 06 15:20:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENbIV-00071d-0k
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:20:55 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24964
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 15:20:52 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENbFj-000EEk-BL
	for v6ops-data@psg.com; Thu, 06 Oct 2005 19:18:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [131.107.3.123] (helo=mail3.microsoft.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENbFf-000EEQ-Rh
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 19:17:59 +0000
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);
	 Thu, 6 Oct 2005 12:17:59 -0700
Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Oct 2005 12:17:59 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Oct 2005 12:17:58 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Oct 2005 12:17:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Thu, 6 Oct 2005 12:17:57 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA113A2E87@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
thread-index: AcXJ7CwbnBxWHUiHR8G9L2DOYzHOWgAAeJmQAA5unaA=
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>,
        "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 06 Oct 2005 19:17:57.0995 (UTC) FILETIME=[A915B3B0:01C5CAAA]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

There is an obvious strategy: tunnel servers should set the "don't
fragment" bit when forwarding a packet larger than the "guaranteed MTU",
and allow fragmentation for smaller packets, e.g. smaller than 1280 for
IPv6. Then, they should just ignore any ICMP message. That should make
the tunnel behavior equivalent to sending through a firewall, something
that transport protocols are expected to handle.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
Behalf Of Templin, Fred L
Sent: Wednesday, October 05, 2005 2:06 PM
To: Fred Baker
Cc: v6ops@ops.ietf.org; Matt Mathis
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance

Fred,

Yes, I know about Matt Mathis' work on Packetization Layer Path
MTU Discovery (PLPMTUD) but that work covers packetization layers
above layer 3 and is independent of the requirement to provide an
assured MTU below layer 3 for IP/IP tunnels.

To your question, the requirement is for an assured MTU for IP/IP
tunnels, i.e., when the tunnel MTU is X bytes then upper layer
protocols can be assured that packets no larger than X will
traverse the tunnel under normal circumstances or a layer 3
"packet too big" message will be returned that informs upper
layers of a smaller MTU. For tunnels over IPv4, if no other
mechanism were provided then the only assured MTU that could
be offered would be 68 bytes since RFC 791 specifies that as
the minimum link MTU for IPv4. But, IPv6 needs to see an assured
MTU of 1280 bytes so some form of MTU assurance for tunnels
is needed.

Fred
fred.l.templin@boeing.com  =20

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Wednesday, October 05, 2005 1:34 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-=20
> mathis-pmtud-method-00.txt. The fundamental algorithm is that the =20
> sending TCP starts from the negotiated MSS (or should transmission =20
> suddenly stop being successful, potentially due to a route change =20
> that reduces the real path MTU from the current message size it is =20
> sending) and reduces its segment size until succeeds in getting a =20
> packet through, and then periodically attempts to increase the =20
> message size in order to take advantage of capacity that=20
> might become =20
> available as routes shift. It seems that this fundamental approach =20
> would address your issues. Does it?
>=20
> As to the efficiency of file transfer, yes, if the header=20
> overhead is =20
> of fixed size, carrying more payload will increase=20
> efficiency. ie, if =20
> the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6 =20
> MTU is 1500 bytes, the maximum payload we can carry is 1440=20
> bytes, or =20
> 96%, and being able to switch that to a 9180 byte IPv6 MTU would =20
> change the efficiency to 99.3% and reduce the interrupt load an the =20
> two hosts by a factor of about 9180/1500. Changing from 1280 to 1500 =20
> bytes, however, is a change from 95.3% to 96% efficiency,=20
> which seems =20
> relatively minor, and switching from 1280 to 1380 bytes of payload =20
> seems even more trivial.
>=20
> The principal value of getting the pmtu right, it seems to me, is to =20
> first get an estimated pmtu that in fact works at all (downsize it =20
> from the negotiated MSS to a packet size that works regardless of =20
> what hiccups lie en route), and second to that, it would be really =20
> nice to minimize the interrupt load on the sending and receiving =20
> hosts in order to balance the goals of maximizing throughput and =20
> minimizing the impact on the hosts themselves. ie, if the sender and =20
> receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the =20
> path, carrying a 1280 byte payload is better than carrying a 1440 =20
> byte payload because the former works and the latter doesn't, and it =20
> would be nice to be able to figure out that a 1380 byte=20
> payload would =20
> also work and be a .35% improvement in efficiency.
>=20
> So, question (and yes, this is a question): are you chasing a=20
> problem =20
> I don't see? What is the objective here?
>=20
> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>=20
> > Fred,
> >
> > Please see the following draft which documents operational issues
> > relevant to v6ops and calls for a solution:
> >
> >=20
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> >
> > Please note that this obsoletes a previos draft called:
> > "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >
> >> -----Original Message-----
> >> From: Templin, Fred L
> >> Sent: Friday, September 30, 2005 3:40 PM
> >> To: Fred Baker
> >> Cc: v6ops@ops.ietf.org
> >> Subject: Requirements for Link Adaptation over IP-in-IPv4
> >> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> >>
> >> Fred - please see:
> >>
> >> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> >> qts-00.txt
> >>
> >> Fred
> >> fred.l.templin@boeing.com
> >>
> >>
> >>> -----Original Message-----
> >>> From: Fred Baker [mailto:fred@cisco.com]
> >>> Sent: Friday, September 23, 2005 9:24 AM
> >>> To: Templin, Fred L
> >>> Cc: v6ops@ops.ietf.org
> >>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> >>>
> >>> Does it still propose a protocol or protocol change?
> >>>
> >>> I don't know offhand whether the charter of v6ops then precluded
> >>> protocol work, and won't go into whether it was proper for
> >>>
> >> [MECH] to
> >>
> >>> be done in v6ops. Given the present charter, I can treat it as a
> >>> requirements document that may be asking for something like
> >>>
> >> the work
> >>
> >>> you are proposing. But my read of the document you pointed to
> >>> is that
> >>> it is still proposing an incompatible change (as in "unchanged
> >>> equipment will not perform the function and once the message is
> >>> segmented in this fashion it must be reassembled in this fashion.
> >>>
> >>> I think that has to be done in a WG chartered to do non-backward-
> >>> compatible changes to IPv4.
> >>>
> >>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> >>>
> >>>
> >>>> Can this work be contributed as an extension to [MECH]?
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >
>=20





From owner-v6ops@ops.ietf.org Thu Oct 06 15:51:04 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENblg-00070j-C0
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:51:04 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26832
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 15:51:01 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENbkq-000GME-7B
	for v6ops-data@psg.com; Thu, 06 Oct 2005 19:50:12 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ENbkp-000GLz-In
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 19:50:11 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ENbkf-0002pc-VA; Thu, 06 Oct 2005 15:50:01 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-security-overview-03.txt 
Message-Id: <E1ENbkf-0002pc-VA@newodin.ietf.org>
Date: Thu, 06 Oct 2005 15:50:01 -0400
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		: IPv6 Transition/Co-existence Security Considerations
	Author(s)	: E. Davies, et al.
	Filename	: draft-ietf-v6ops-security-overview-03.txt
	Pages		: 36
	Date		: 2005-10-6
	
The transition from a pure IPv4 network to a network where IPv4 and
   IPv6 co-exist brings a number of extra security considerations that
   need to be taken into account when deploying IPv6 and operating the
   dual-protocol network and the associated transition mechanisms.  This
   document attempts to give an overview of the various issues grouped
   into three categories:
   o  issues due to the IPv6 protocol itself,
   o  issues due to transition mechanisms, and
   o  issues due to IPv6 deployment.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-03.txt

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-security-overview-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-security-overview-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-v6ops@ops.ietf.org Thu Oct 06 15:57:12 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENbrb-00008k-76
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 15:57:12 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28045
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 15:57:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENbq2-000H6I-67
	for v6ops-data@psg.com; Thu, 06 Oct 2005 19:55:34 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENbq0-000H5t-8u
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 19:55:32 +0000
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA28465;
	Thu, 6 Oct 2005 14:55:22 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j96JtLA12593;
	Thu, 6 Oct 2005 12:55:21 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 6 Oct 2005 12:55:21 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Thu, 6 Oct 2005 12:55:20 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D5086@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXJ7CwbnBxWHUiHR8G9L2DOYzHOWgAAeJmQAA5unaAAIZpUIA==
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Christian Huitema" <huitema@windows.microsoft.com>,
        "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 06 Oct 2005 19:55:21.0197 (UTC) FILETIME=[E22329D0:01C5CAAF]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

When both tunnel endpoints are on the Internet (or, on the same
Intranet) then allowing fragmentation might be sub-optimal but it
should still work. But, when the tunnel endpoints are on opposite
sides of one or more network middlebox (NATs, firewalls, etc) the
concern is for those middle boxes that only forward the first
fragments of fragmented IP datagrams and discard the remaining
fragments. Have there been recent studies that document the
behavior of fragmented traffic across network middleboxes?

Fred
fred.l.templin@boeing.com
 =20

> -----Original Message-----
> From: Christian Huitema [mailto:huitema@windows.microsoft.com]=20
> Sent: Thursday, October 06, 2005 12:18 PM
> To: Templin, Fred L; Fred Baker
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> There is an obvious strategy: tunnel servers should set the "don't
> fragment" bit when forwarding a packet larger than the=20
> "guaranteed MTU",
> and allow fragmentation for smaller packets, e.g. smaller=20
> than 1280 for
> IPv6. Then, they should just ignore any ICMP message. That should make
> the tunnel behavior equivalent to sending through a firewall,=20
> something
> that transport protocols are expected to handle.
>=20
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Templin, Fred L
> Sent: Wednesday, October 05, 2005 2:06 PM
> To: Fred Baker
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> Fred,
>=20
> Yes, I know about Matt Mathis' work on Packetization Layer Path
> MTU Discovery (PLPMTUD) but that work covers packetization layers
> above layer 3 and is independent of the requirement to provide an
> assured MTU below layer 3 for IP/IP tunnels.
>=20
> To your question, the requirement is for an assured MTU for IP/IP
> tunnels, i.e., when the tunnel MTU is X bytes then upper layer
> protocols can be assured that packets no larger than X will
> traverse the tunnel under normal circumstances or a layer 3
> "packet too big" message will be returned that informs upper
> layers of a smaller MTU. For tunnels over IPv4, if no other
> mechanism were provided then the only assured MTU that could
> be offered would be 68 bytes since RFC 791 specifies that as
> the minimum link MTU for IPv4. But, IPv6 needs to see an assured
> MTU of 1280 bytes so some form of MTU assurance for tunnels
> is needed.
>=20
> Fred
> fred.l.templin@boeing.com  =20
>=20
> > -----Original Message-----
> > From: Fred Baker [mailto:fred@cisco.com]=20
> > Sent: Wednesday, October 05, 2005 1:34 PM
> > To: Templin, Fred L
> > Cc: v6ops@ops.ietf.org; Matt Mathis
> > Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
> >=20
> > I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-=20
> > mathis-pmtud-method-00.txt. The fundamental algorithm is that the =20
> > sending TCP starts from the negotiated MSS (or should transmission =20
> > suddenly stop being successful, potentially due to a route change =20
> > that reduces the real path MTU from the current message size it is =20
> > sending) and reduces its segment size until succeeds in getting a =20
> > packet through, and then periodically attempts to increase the =20
> > message size in order to take advantage of capacity that=20
> > might become =20
> > available as routes shift. It seems that this fundamental approach =20
> > would address your issues. Does it?
> >=20
> > As to the efficiency of file transfer, yes, if the header=20
> > overhead is =20
> > of fixed size, carrying more payload will increase=20
> > efficiency. ie, if =20
> > the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6 =20
> > MTU is 1500 bytes, the maximum payload we can carry is 1440=20
> > bytes, or =20
> > 96%, and being able to switch that to a 9180 byte IPv6 MTU would =20
> > change the efficiency to 99.3% and reduce the interrupt=20
> load an the =20
> > two hosts by a factor of about 9180/1500. Changing from=20
> 1280 to 1500 =20
> > bytes, however, is a change from 95.3% to 96% efficiency,=20
> > which seems =20
> > relatively minor, and switching from 1280 to 1380 bytes of payload =20
> > seems even more trivial.
> >=20
> > The principal value of getting the pmtu right, it seems to=20
> me, is to =20
> > first get an estimated pmtu that in fact works at all (downsize it =20
> > from the negotiated MSS to a packet size that works regardless of =20
> > what hiccups lie en route), and second to that, it would be really =20
> > nice to minimize the interrupt load on the sending and receiving =20
> > hosts in order to balance the goals of maximizing throughput and =20
> > minimizing the impact on the hosts themselves. ie, if the=20
> sender and =20
> > receiver are on 10/100 Ethernets and there is an IP/IP=20
> tunnel on the =20
> > path, carrying a 1280 byte payload is better than carrying a 1440 =20
> > byte payload because the former works and the latter=20
> doesn't, and it =20
> > would be nice to be able to figure out that a 1380 byte=20
> > payload would =20
> > also work and be a .35% improvement in efficiency.
> >=20
> > So, question (and yes, this is a question): are you chasing a=20
> > problem =20
> > I don't see? What is the objective here?
> >=20
> > On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
> >=20
> > > Fred,
> > >
> > > Please see the following draft which documents operational issues
> > > relevant to v6ops and calls for a solution:
> > >
> > >=20
> >=20
> http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> > >
> > > Please note that this obsoletes a previos draft called:
> > > "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> > >
> > > Fred
> > > fred.l.templin@boeing.com
> > >
> > >
> > >> -----Original Message-----
> > >> From: Templin, Fred L
> > >> Sent: Friday, September 30, 2005 3:40 PM
> > >> To: Fred Baker
> > >> Cc: v6ops@ops.ietf.org
> > >> Subject: Requirements for Link Adaptation over IP-in-IPv4
> > >> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> > >>
> > >> Fred - please see:
> > >>
> > >> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> > >> qts-00.txt
> > >>
> > >> Fred
> > >> fred.l.templin@boeing.com
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Fred Baker [mailto:fred@cisco.com]
> > >>> Sent: Friday, September 23, 2005 9:24 AM
> > >>> To: Templin, Fred L
> > >>> Cc: v6ops@ops.ietf.org
> > >>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> > >>>
> > >>> Does it still propose a protocol or protocol change?
> > >>>
> > >>> I don't know offhand whether the charter of v6ops then precluded
> > >>> protocol work, and won't go into whether it was proper for
> > >>>
> > >> [MECH] to
> > >>
> > >>> be done in v6ops. Given the present charter, I can treat it as a
> > >>> requirements document that may be asking for something like
> > >>>
> > >> the work
> > >>
> > >>> you are proposing. But my read of the document you pointed to
> > >>> is that
> > >>> it is still proposing an incompatible change (as in "unchanged
> > >>> equipment will not perform the function and once the message is
> > >>> segmented in this fashion it must be reassembled in=20
> this fashion.
> > >>>
> > >>> I think that has to be done in a WG chartered to do=20
> non-backward-
> > >>> compatible changes to IPv4.
> > >>>
> > >>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> > >>>
> > >>>
> > >>>> Can this work be contributed as an extension to [MECH]?
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >=20
>=20
>=20




From owner-v6ops@ops.ietf.org Thu Oct 06 16:54:43 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENclH-0006RV-7O
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 16:54:43 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15575
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 16:54:40 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENcio-000M1U-10
	for v6ops-data@psg.com; Thu, 06 Oct 2005 20:52:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENcil-000M15-DH
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 20:52:07 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-4.cisco.com with ESMTP; 06 Oct 2005 13:52:07 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j96Kq54V009364
	for <v6ops@ops.ietf.org>; Thu, 6 Oct 2005 13:52:05 -0700 (PDT)
Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j96L3HlI004951
	for <v6ops@ops.ietf.org>; Thu, 6 Oct 2005 14:03:17 -0700
Mime-Version: 1.0 (Apple Message framework v734)
References: <434543C1.2050005@dial.pipex.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <D165EA23-F420-4AF8-9BE3-8BF09B6DE687@cisco.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Fwd: New version of security overview submitted
Date: Thu, 6 Oct 2005 13:52:03 -0700
To: v6ops@ops.ietf.org
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=2160; t=1128632598; x=1129064798;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Fwd=3A=20New=20version=20of=20security=20overview=20submitted|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Thu,=206=20Oct=202005=2013=3A52=3A03=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=EB8HSG3eqHpOa6d4Q6ksTgfcH6c2EdskD+u2bUAi6cJ7rnCb6B0x3I8RJ/f/n1pM4vTkLV5e
	X4txeLCVRQ90CGWJOuPLlVYhuyCRB/v17Mygbb/W15mSjCIwDpyjO0xtgeQ3FcqiANtuqVUxjUI
	YUZB82nWi23ql1lmaBxzLD+k=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Folks:

I don't think we need another WGLC on this, but I would like to hear  
from those that commented that their concerns have or have not been  
met, and in the latter case suggested text.

Begin forwarded message:

> From: Elwyn Davies <elwynd@dial.pipex.com>
> Date: October 6, 2005 8:33:21 AM PDT
> To: Fred Baker <fred@cisco.com>, Kurt Erik Lindqvist  
> <kurtis@kurtis.pp.se>
> Subject: New version of security overview submitted
>
>
> Hi.
>
> I just submitted the new version of the security overview  
> addressing the second last call comments (mostly from Tim Chown).
> I'll send a message to the list when it appears.
>
> I don't know if you feel this needs yet another last call... one  
> section (4.1) got rewritten as a result of Tim's comments and there  
> are a number of other changes.
>
> Regards,
> Elwyn
>
> The list of changes is:
> 02 -> 03
> Couple of pieces of spelling converted from UK to US fulfil/tunnelling
> Several instances of 'unrecognized' appear to have vanished  
> (probably while changing them from
> unrecognised in the previous edit.
> s2.1.4: s/an  /an unrecognized / (2 instances in next to last para)
> s2.1.8.3: s/items  /items unrecognized /
> s2.1.6: 2nd para: s/to for any future/for any future/
> s2.1.11: s/IPv4 addresses/IPv4 link-local addresses/
> s2.1.11.1: promoted to s2.1.12, renumber rest of s2.1 accordingly
> s2.1.11.1: added note on possible DoS attacks due to malicious  
> deprecation of prefixes with and
> without IPv6 Router Selection option. (Tim Chown)
> Added new s2.1.13: Documenting security issues with Host-Router  
> Load Sharing (Tim Chown)
> Old s2.1.12 (Mobile IP) is now 2.1.14.
> s2.2: last sentence s/and/ and/
> s3.3: Added extra paragraph and figure 1 at end suggesting routing  
> of traffic through IPv6 and
> IPv4 firewalls with tunnel endpoint between them (Tim Chown)
> s4.1: completely rewritten
> s4.3: added additional example of DHCP servers for guessable addresses
> s4.4: Added comment emphasising that multiaddressing is the norm  
> not the exception (Tim Chown)
> s4.4: Added note that privacy addresses can only be disabled by  
> using full stateful DHCPv6 Tim Chown)
> s4.5:s/in might/it might/
> s4.7: Added reference to IPv6 Node Requirements draft (Tim Chown)
> s4.6: s/stable/mature/ in first para (Tim Chown)
> App A: Added comment that 3041 addresses can only be used behind  
> 6to4 router if host is not to be reachable from elsewhere. (Tim Chown)
> App B: Added reference to Network Architecture Protection draft  
> (Tim Chown)
> App B.3: Added note that many users woudl like a static /48 so they  
> can host services. (Tim Chown)
>




From owner-v6ops@ops.ietf.org Thu Oct 06 17:31:31 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENdKt-0004HC-0Y
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 17:31:31 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17941
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 17:31:27 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENdIs-000PBT-Hz
	for v6ops-data@psg.com; Thu, 06 Oct 2005 21:29:26 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENdIp-000PBC-N6
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 21:29:23 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-1.cisco.com with ESMTP; 06 Oct 2005 14:29:23 -0700
X-IronPort-AV: i="3.97,184,1125903600"; 
   d="scan'208"; a="664054311:sNHT32364340"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j96LTLKC009157;
	Thu, 6 Oct 2005 14:29:21 -0700 (PDT)
Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j96LeX4w005347;
	Thu, 6 Oct 2005 14:40:33 -0700
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D5082@XCH-NW-7V2.nw.nos.boeing.com>
References: <39C363776A4E8C4A94691D2BD9D1C9A10D5082@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <3A0A3CE8-F414-4C54-8AFD-080D6A202395@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Thu, 6 Oct 2005 14:29:19 -0700
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=7397; t=1128634834; x=1129067034;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Requirements=20for=20IP-in-IP=20Tunnel=20MTU=20Assurance|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Thu,=206=20Oct=202005=2014=3A29=3A19=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=HZW8t9sHoPSSO7VzEptbwzq3sAvUok+J7hMxo5+9RNEdtagwDs2p4tKB1NJK5bx3z6KB2hfv
	Hf3NHXTkCDwZMz/j8eK8DDe3gpstXxEPoLppKnuCKUbcTjc6Zj5pXrvhWdJSHRJfRk3TV7HhBbl
	pGaKN3vUSkid9vS2XL3tf/Bo=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

hmm.

dumb question, wearing "participant" hat...

fragmentation is done end to end in IPv6; the network doesn't  
fragment. Ultimately, the question for the application is what packet  
size will work to get its data end to end, of which the tunnel is  
just a part of the path. The big difference in doing this end to end  
and on the tunnel is that on the tunnel a packet-too-large ICMP goes  
to the tunnel endpoint and not the originator of the message, so that  
a per-potential-destination route MTU could be maintained, but that  
only goes to the actual originator when the originator fires off a  
message.

It seems to me more practical to advise applications to (a) respond  
to ICMP packet-too-huge by reducing their MSS, and to provide some  
tool that would measure goodput rates such that if goodput is zero  
but ICMP is not getting back to follow a heuristic to Matt's pmtud.  
that has several effects. First, it is consistent with the end2end  
principal, which suggests that one should not implement at a lower  
layer something that already has to be supplied end to end; doing  
this in the tunnel is a duplicative mechanism. Second, it  
generalizes; on any path, there is a least MTU en route and tyerefore  
a packet size that will work. It is IMHO up to the application, if it  
wants its transmissions to work, to find that packet size among other  
things.

On Oct 6, 2005, at 8:46 AM, Templin, Fred L wrote:
> Fred,
>
> I'm not sure I exactly understand your question, but the  
> requirement is for a path MTU assurance mechanism that is employed  
> *within* the tunnel to ensure that packets no larger than the  
> tunnel MTU make it through to the other side of the tunnel, i.e.,  
> the mechanism would act only on one hop of what may be multiple hop  
> path. The path MTU method outlined in Matt Mathis' draft is  
> employed at packetization layers *above* the tunnel to determine  
> the MTU of the path that may extend many hops beyond the other side  
> of the tunnel, and I agree that the algorithm could be used for  
> protocols other than TCP.
>
> The algorithm used by the tunnel MTU assurance mechanism might be  
> quite similar to that described in Matt's draft, but the use case  
> and implementation are different. In fact, it could happen that  
> implementations of Matt's packetization layer path MTU scheme and a  
> tunnel MTU assurance mechanism would occur in the same physical box  
> and would act at independently of each other.
>
> Fred
> fred.l.templin@boeing.com
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]
>> Sent: Wednesday, October 05, 2005 5:37 PM
>> To: Templin, Fred L
>> Cc: v6ops@ops.ietf.org; Matt Mathis
>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>
>> ah. ok.
>>
>> so, dumb question of the month. are you looking for a simple  
>> protocol that can be run over such a tunnel (including not only ip/ 
>> ip, but
>>
>> GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would  
>> something along the lines of pmtu accomplish it? As in, it seems  
>> to me that the algrorithm is funcdamentally useful for things  
>> other than TCP.
>>
>> On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:
>>> Fred,
>>>
>>> Yes, I know about Matt Mathis' work on Packetization Layer Path  
>>> MTU Discovery (PLPMTUD) but that work covers packetization layers  
>>> above layer 3 and is independent of the requirement to provide an  
>>> assured MTU below layer 3 for IP/IP tunnels.
>>>
>>> To your question, the requirement is for an assured MTU for IP/IP  
>>> tunnels, i.e., when the tunnel MTU is X bytes then upper layer  
>>> protocols can be assured that packets no larger than X will  
>>> traverse the tunnel under normal circumstances or a layer 3  
>>> "packet too big" message will be returned that informs upper  
>>> layers of a smaller MTU. For tunnels over IPv4, if no other  
>>> mechanism were provided then the only assured MTU that could be  
>>> offered would be 68 bytes since RFC 791 specifies that as the  
>>> minimum link MTU for IPv4. But, IPv6 needs to see an assured MTU  
>>> of 1280 bytes so some form of MTU assurance for tunnels is needed.
>>>
>>> Fred
>>> fred.l.templin@boeing.com
>>>
>>>> -----Original Message-----
>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>> Sent: Wednesday, October 05, 2005 1:34 PM
>>>> To: Templin, Fred L
>>>> Cc: v6ops@ops.ietf.org; Matt Mathis
>>>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>>>
>>>> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/ 
>>>> draft- mathis-pmtud-method-00.txt. The fundamental algorithm is  
>>>> that the sending TCP starts from the negotiated MSS (or should  
>>>> transmission suddenly stop being successful, potentially due to  
>>>> a route change that reduces the real path MTU from the current  
>>>> message size it is sending) and reduces its segment size until  
>>>> succeeds in getting a packet through, and then periodically  
>>>> attempts to increase the message size in order to take advantage  
>>>> of capacity that might become available as routes shift. It  
>>>> seems that this fundamental approach would address your issues.  
>>>> Does it?
>>>>
>>>> As to the efficiency of file transfer, yes, if the header  
>>>> overhead is of fixed size, carrying more payload will increase  
>>>> efficiency. ie, if the IPv6 header is 40 bytes and the TCP  
>>>> header is 20, and the IPv6 MTU is 1500 bytes, the maximum  
>>>> payload we can carry is 1440 bytes, or 96%, and being able to  
>>>> switch that to a 9180 byte IPv6 MTU would change the efficiency  
>>>> to 99.3% and reduce the interrupt load an the two hosts by a  
>>>> factor of about 9180/1500. Changing from 1280 to 1500 bytes,  
>>>> however, is a change from 95.3% to 96% efficiency, which seems  
>>>> relatively minor, and switching from 1280 to 1380 bytes of  
>>>> payload seems even more trivial.
>>>>
>>>> The principal value of getting the pmtu right, it seems to me,  
>>>> is to first get an estimated pmtu that in fact works at all  
>>>> (downsize it from the negotiated MSS to a packet size that works  
>>>> regardless of what hiccups lie en route), and second to that, it  
>>>> would be really nice to minimize the interrupt load on the  
>>>> sending and receiving hosts in order to balance the goals of  
>>>> maximizing throughput and minimizing the impact on the hosts  
>>>> themselves. ie, if the sender and receiver are on 10/100  
>>>> Ethernets and there is an IP/IP tunnel on the path, carrying a  
>>>> 1280 byte payload is better than carrying a 1440 byte payload  
>>>> because the former works and the latter doesn't, and it would be  
>>>> nice to be able to figure out that a 1380 byte payload would  
>>>> also work and be a .35% improvement in efficiency.
>>>>
>>>> So, question (and yes, this is a question): are you chasing a  
>>>> problem I don't see? What is the objective here?
>>>>
>>>> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>>>>> Fred,
>>>>>
>>>>> Please see the following draft which documents operational  
>>>>> issues relevant to v6ops and calls for a solution: http:// 
>>>>> www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>>>>>
>>>>> Please note that this obsoletes a previos draft called:  
>>>>> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
>>>>>
>>>>> Fred
>>>>> fred.l.templin@boeing.com
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Templin, Fred L
>>>>>> Sent: Friday, September 30, 2005 3:40 PM
>>>>>> To: Fred Baker
>>>>>> Cc: v6ops@ops.ietf.org
>>>>>> Subject: Requirements for Link Adaptation over IP-in-IPv4
>>>>>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
>>>>>>
>>>>>> Fred - please see:
>>>>>>
>>>>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt- 
>>>>>> reqts-00.txt
>>>>>>
>>>>>> Fred
>>>>>> fred.l.templin@boeing.com
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>>>>> Sent: Friday, September 23, 2005 9:24 AM
>>>>>>> To: Templin, Fred L
>>>>>>> Cc: v6ops@ops.ietf.org
>>>>>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
>>>>>>>
>>>>>>> Does it still propose a protocol or protocol change?
>>>>>>>
>>>>>>> I don't know offhand whether the charter of v6ops then  
>>>>>>> precluded protocol work, and won't go into whether it was  
>>>>>>> proper for [MECH] to be done in v6ops. Given the present  
>>>>>>> charter, I can treat it as a requirements document that may  
>>>>>>> be asking for something like the work you are proposing. But  
>>>>>>> my read of the document you pointed to is that it is still  
>>>>>>> proposing an incompatible change (as in "unchanged equipment  
>>>>>>> will not perform the function and once the message is  
>>>>>>> segmented in this fashion it must be reassembled in this  
>>>>>>> fashion.
>>>>>>>
>>>>>>> I think that has to be done in a WG chartered to do non- 
>>>>>>> backward-compatible changes to IPv4.
>>>>>>>
>>>>>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
>>>>>>>> Can this work be contributed as an extension to [MECH]?




From owner-v6ops@ops.ietf.org Thu Oct 06 17:33:07 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENdMO-0004pm-Jb
	for v6ops-archive@megatron.ietf.org; Thu, 06 Oct 2005 17:33:06 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18023
	for <v6ops-archive@lists.ietf.org>; Thu, 6 Oct 2005 17:33:01 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENdMD-000PYd-8s
	for v6ops-data@psg.com; Thu, 06 Oct 2005 21:32:53 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ENdMB-000PYI-Th
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 21:32:52 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ENdM8-00082a-5T
	for v6ops@ops.ietf.org; Thu, 06 Oct 2005 22:32:48 +0100
Message-ID: <43459857.8020709@dial.pipex.com>
Date: Thu, 06 Oct 2005 22:34:15 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: v6ops@ops.ietf.org
Subject: Re: Fwd: New version of security overview submitted
References: <434543C1.2050005@dial.pipex.com> <D165EA23-F420-4AF8-9BE3-8BF09B6DE687@cisco.com>
In-Reply-To: <D165EA23-F420-4AF8-9BE3-8BF09B6DE687@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

The new version of the draft is on the server now.

Regards,
Elwyn

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		: IPv6 Transition/Co-existence Security Considerations
	Author(s)	: E. Davies, et al.
	Filename	: draft-ietf-v6ops-security-overview-03.txt
	Pages		: 36
	Date		: 2005-10-6

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-03.txt




Fred Baker wrote:

> Folks:
>
> I don't think we need another WGLC on this, but I would like to hear  
> from those that commented that their concerns have or have not been  
> met, and in the latter case suggested text.
>
> Begin forwarded message:
>
>> From: Elwyn Davies <elwynd@dial.pipex.com>
>> Date: October 6, 2005 8:33:21 AM PDT
>> To: Fred Baker <fred@cisco.com>, Kurt Erik Lindqvist  
>> <kurtis@kurtis.pp.se>
>> Subject: New version of security overview submitted
>>
>>
>> Hi.
>>
>> I just submitted the new version of the security overview  addressing 
>> the second last call comments (mostly from Tim Chown).
>> I'll send a message to the list when it appears.
>>
>> I don't know if you feel this needs yet another last call... one  
>> section (4.1) got rewritten as a result of Tim's comments and there  
>> are a number of other changes.
>>
>> Regards,
>> Elwyn
>>
>> The list of changes is:
>> 02 -> 03
>> Couple of pieces of spelling converted from UK to US fulfil/tunnelling
>> Several instances of 'unrecognized' appear to have vanished  
>> (probably while changing them from
>> unrecognised in the previous edit.
>> s2.1.4: s/an  /an unrecognized / (2 instances in next to last para)
>> s2.1.8.3: s/items  /items unrecognized /
>> s2.1.6: 2nd para: s/to for any future/for any future/
>> s2.1.11: s/IPv4 addresses/IPv4 link-local addresses/
>> s2.1.11.1: promoted to s2.1.12, renumber rest of s2.1 accordingly
>> s2.1.11.1: added note on possible DoS attacks due to malicious  
>> deprecation of prefixes with and
>> without IPv6 Router Selection option. (Tim Chown)
>> Added new s2.1.13: Documenting security issues with Host-Router  Load 
>> Sharing (Tim Chown)
>> Old s2.1.12 (Mobile IP) is now 2.1.14.
>> s2.2: last sentence s/and/ and/
>> s3.3: Added extra paragraph and figure 1 at end suggesting routing  
>> of traffic through IPv6 and
>> IPv4 firewalls with tunnel endpoint between them (Tim Chown)
>> s4.1: completely rewritten
>> s4.3: added additional example of DHCP servers for guessable addresses
>> s4.4: Added comment emphasising that multiaddressing is the norm  not 
>> the exception (Tim Chown)
>> s4.4: Added note that privacy addresses can only be disabled by  
>> using full stateful DHCPv6 Tim Chown)
>> s4.5:s/in might/it might/
>> s4.7: Added reference to IPv6 Node Requirements draft (Tim Chown)
>> s4.6: s/stable/mature/ in first para (Tim Chown)
>> App A: Added comment that 3041 addresses can only be used behind  
>> 6to4 router if host is not to be reachable from elsewhere. (Tim Chown)
>> App B: Added reference to Network Architecture Protection draft  (Tim 
>> Chown)
>> App B.3: Added note that many users woudl like a static /48 so they  
>> can host services. (Tim Chown)
>>
>




From owner-v6ops@ops.ietf.org Fri Oct 07 11:26:24 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENu75-0004AY-7Q
	for v6ops-archive@megatron.ietf.org; Fri, 07 Oct 2005 11:26:24 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25126
	for <v6ops-archive@lists.ietf.org>; Fri, 7 Oct 2005 11:26:20 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENu2u-000BNS-N3
	for v6ops-data@psg.com; Fri, 07 Oct 2005 15:22:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENu2t-000BND-D9
	for v6ops@ops.ietf.org; Fri, 07 Oct 2005 15:22:03 +0000
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA25679;
	Fri, 7 Oct 2005 08:21:51 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j97FLoo08332;
	Fri, 7 Oct 2005 10:21:50 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Oct 2005 08:21:46 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Fri, 7 Oct 2005 08:21:45 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D5089@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXKxwmSJjE9FnTNR32n+4MQaey9EQAilJcw
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 07 Oct 2005 15:21:46.0350 (UTC) FILETIME=[D48A08E0:01C5CB52]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,

I couldn't tell whether you were asking a question here or
not, but I don't see the tunnel MTU assurance requirement
as being at-odds with the end-to-end principles. The tunnel
is simply a link that occurs somewhere on the path and, like
any other link, needs to present an assured MTU to layer 3.
Link adaptation within the tunnel (i.e., below layer 3) is
really no different than for ordinary links that need to do
link-layer segmentation/reassembly to present an assured MTU
to layer 3 (e.g., 802.11, 802.15).

Fred
fred.l.templin@boeing.com

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Thursday, October 06, 2005 2:29 PM
> To: Templin, Fred L
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>=20
> hmm.
>=20
> dumb question, wearing "participant" hat...
>=20
> fragmentation is done end to end in IPv6; the network doesn't =20
> fragment. Ultimately, the question for the application is=20
> what packet =20
> size will work to get its data end to end, of which the tunnel is =20
> just a part of the path. The big difference in doing this end to end =20
> and on the tunnel is that on the tunnel a packet-too-large ICMP goes =20
> to the tunnel endpoint and not the originator of the message,=20
> so that =20
> a per-potential-destination route MTU could be maintained, but that =20
> only goes to the actual originator when the originator fires off a =20
> message.
>=20
> It seems to me more practical to advise applications to (a) respond =20
> to ICMP packet-too-huge by reducing their MSS, and to provide some =20
> tool that would measure goodput rates such that if goodput is zero =20
> but ICMP is not getting back to follow a heuristic to Matt's pmtud. =20
> that has several effects. First, it is consistent with the end2end =20
> principal, which suggests that one should not implement at a lower =20
> layer something that already has to be supplied end to end; doing =20
> this in the tunnel is a duplicative mechanism. Second, it =20
> generalizes; on any path, there is a least MTU en route and=20
> tyerefore =20
> a packet size that will work. It is IMHO up to the=20
> application, if it =20
> wants its transmissions to work, to find that packet size=20
> among other =20
> things.
>=20
> On Oct 6, 2005, at 8:46 AM, Templin, Fred L wrote:
> > Fred,
> >
> > I'm not sure I exactly understand your question, but the =20
> > requirement is for a path MTU assurance mechanism that is employed =20
> > *within* the tunnel to ensure that packets no larger than the =20
> > tunnel MTU make it through to the other side of the tunnel, i.e., =20
> > the mechanism would act only on one hop of what may be=20
> multiple hop =20
> > path. The path MTU method outlined in Matt Mathis' draft is =20
> > employed at packetization layers *above* the tunnel to determine =20
> > the MTU of the path that may extend many hops beyond the=20
> other side =20
> > of the tunnel, and I agree that the algorithm could be used for =20
> > protocols other than TCP.
> >
> > The algorithm used by the tunnel MTU assurance mechanism might be =20
> > quite similar to that described in Matt's draft, but the use case =20
> > and implementation are different. In fact, it could happen that =20
> > implementations of Matt's packetization layer path MTU=20
> scheme and a =20
> > tunnel MTU assurance mechanism would occur in the same=20
> physical box =20
> > and would act at independently of each other.
> >
> > Fred
> > fred.l.templin@boeing.com
> >
> >> -----Original Message-----
> >> From: Fred Baker [mailto:fred@cisco.com]
> >> Sent: Wednesday, October 05, 2005 5:37 PM
> >> To: Templin, Fred L
> >> Cc: v6ops@ops.ietf.org; Matt Mathis
> >> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
> >>
> >> ah. ok.
> >>
> >> so, dumb question of the month. are you looking for a simple =20
> >> protocol that can be run over such a tunnel (including not=20
> only ip/=20
> >> ip, but
> >>
> >> GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would =20
> >> something along the lines of pmtu accomplish it? As in, it seems =20
> >> to me that the algrorithm is funcdamentally useful for things =20
> >> other than TCP.
> >>
> >> On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:
> >>> Fred,
> >>>
> >>> Yes, I know about Matt Mathis' work on Packetization Layer Path =20
> >>> MTU Discovery (PLPMTUD) but that work covers=20
> packetization layers =20
> >>> above layer 3 and is independent of the requirement to=20
> provide an =20
> >>> assured MTU below layer 3 for IP/IP tunnels.
> >>>
> >>> To your question, the requirement is for an assured MTU=20
> for IP/IP =20
> >>> tunnels, i.e., when the tunnel MTU is X bytes then upper layer =20
> >>> protocols can be assured that packets no larger than X will =20
> >>> traverse the tunnel under normal circumstances or a layer 3 =20
> >>> "packet too big" message will be returned that informs upper =20
> >>> layers of a smaller MTU. For tunnels over IPv4, if no other =20
> >>> mechanism were provided then the only assured MTU that could be =20
> >>> offered would be 68 bytes since RFC 791 specifies that as the =20
> >>> minimum link MTU for IPv4. But, IPv6 needs to see an assured MTU =20
> >>> of 1280 bytes so some form of MTU assurance for tunnels is needed.
> >>>
> >>> Fred
> >>> fred.l.templin@boeing.com
> >>>
> >>>> -----Original Message-----
> >>>> From: Fred Baker [mailto:fred@cisco.com]
> >>>> Sent: Wednesday, October 05, 2005 1:34 PM
> >>>> To: Templin, Fred L
> >>>> Cc: v6ops@ops.ietf.org; Matt Mathis
> >>>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
> >>>>
> >>>> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/=20
> >>>> draft- mathis-pmtud-method-00.txt. The fundamental algorithm is =20
> >>>> that the sending TCP starts from the negotiated MSS (or should =20
> >>>> transmission suddenly stop being successful, potentially due to =20
> >>>> a route change that reduces the real path MTU from the current =20
> >>>> message size it is sending) and reduces its segment size until =20
> >>>> succeeds in getting a packet through, and then periodically =20
> >>>> attempts to increase the message size in order to take=20
> advantage =20
> >>>> of capacity that might become available as routes shift. It =20
> >>>> seems that this fundamental approach would address your issues. =20
> >>>> Does it?
> >>>>
> >>>> As to the efficiency of file transfer, yes, if the header =20
> >>>> overhead is of fixed size, carrying more payload will increase =20
> >>>> efficiency. ie, if the IPv6 header is 40 bytes and the TCP =20
> >>>> header is 20, and the IPv6 MTU is 1500 bytes, the maximum =20
> >>>> payload we can carry is 1440 bytes, or 96%, and being able to =20
> >>>> switch that to a 9180 byte IPv6 MTU would change the efficiency =20
> >>>> to 99.3% and reduce the interrupt load an the two hosts by a =20
> >>>> factor of about 9180/1500. Changing from 1280 to 1500 bytes, =20
> >>>> however, is a change from 95.3% to 96% efficiency, which seems =20
> >>>> relatively minor, and switching from 1280 to 1380 bytes of =20
> >>>> payload seems even more trivial.
> >>>>
> >>>> The principal value of getting the pmtu right, it seems to me, =20
> >>>> is to first get an estimated pmtu that in fact works at all =20
> >>>> (downsize it from the negotiated MSS to a packet size=20
> that works =20
> >>>> regardless of what hiccups lie en route), and second to=20
> that, it =20
> >>>> would be really nice to minimize the interrupt load on the =20
> >>>> sending and receiving hosts in order to balance the goals of =20
> >>>> maximizing throughput and minimizing the impact on the hosts =20
> >>>> themselves. ie, if the sender and receiver are on 10/100 =20
> >>>> Ethernets and there is an IP/IP tunnel on the path, carrying a =20
> >>>> 1280 byte payload is better than carrying a 1440 byte payload =20
> >>>> because the former works and the latter doesn't, and it=20
> would be =20
> >>>> nice to be able to figure out that a 1380 byte payload would =20
> >>>> also work and be a .35% improvement in efficiency.
> >>>>
> >>>> So, question (and yes, this is a question): are you chasing a =20
> >>>> problem I don't see? What is the objective here?
> >>>>
> >>>> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
> >>>>> Fred,
> >>>>>
> >>>>> Please see the following draft which documents operational =20
> >>>>> issues relevant to v6ops and calls for a solution: http://=20
> >>>>> www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> >>>>>
> >>>>> Please note that this obsoletes a previos draft called: =20
> >>>>> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> >>>>>
> >>>>> Fred
> >>>>> fred.l.templin@boeing.com
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Templin, Fred L
> >>>>>> Sent: Friday, September 30, 2005 3:40 PM
> >>>>>> To: Fred Baker
> >>>>>> Cc: v6ops@ops.ietf.org
> >>>>>> Subject: Requirements for Link Adaptation over IP-in-IPv4
> >>>>>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> >>>>>>
> >>>>>> Fred - please see:
> >>>>>>
> >>>>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-=20
> >>>>>> reqts-00.txt
> >>>>>>
> >>>>>> Fred
> >>>>>> fred.l.templin@boeing.com
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Fred Baker [mailto:fred@cisco.com]
> >>>>>>> Sent: Friday, September 23, 2005 9:24 AM
> >>>>>>> To: Templin, Fred L
> >>>>>>> Cc: v6ops@ops.ietf.org
> >>>>>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> >>>>>>>
> >>>>>>> Does it still propose a protocol or protocol change?
> >>>>>>>
> >>>>>>> I don't know offhand whether the charter of v6ops then =20
> >>>>>>> precluded protocol work, and won't go into whether it was =20
> >>>>>>> proper for [MECH] to be done in v6ops. Given the present =20
> >>>>>>> charter, I can treat it as a requirements document that may =20
> >>>>>>> be asking for something like the work you are proposing. But =20
> >>>>>>> my read of the document you pointed to is that it is still =20
> >>>>>>> proposing an incompatible change (as in "unchanged equipment =20
> >>>>>>> will not perform the function and once the message is =20
> >>>>>>> segmented in this fashion it must be reassembled in this =20
> >>>>>>> fashion.
> >>>>>>>
> >>>>>>> I think that has to be done in a WG chartered to do non-=20
> >>>>>>> backward-compatible changes to IPv4.
> >>>>>>>
> >>>>>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> >>>>>>>> Can this work be contributed as an extension to [MECH]?
>=20




From owner-v6ops@ops.ietf.org Fri Oct 07 11:53:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENuX3-0003tV-Oa
	for v6ops-archive@megatron.ietf.org; Fri, 07 Oct 2005 11:53:13 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26964
	for <v6ops-archive@lists.ietf.org>; Fri, 7 Oct 2005 11:53:10 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENuVr-000EQo-LN
	for v6ops-data@psg.com; Fri, 07 Oct 2005 15:51:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENuVn-000EQB-R3
	for v6ops@ops.ietf.org; Fri, 07 Oct 2005 15:51:55 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-3.cisco.com with ESMTP; 07 Oct 2005 08:51:56 -0700
X-IronPort-AV: i="3.97,186,1125903600"; 
   d="scan'208"; a="349402466:sNHT29285556"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j97Fpr4u010970;
	Fri, 7 Oct 2005 08:51:53 -0700 (PDT)
Received: from [10.32.244.220] (stealth-10-32-244-220.cisco.com [10.32.244.220])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j97G32Jx012063;
	Fri, 7 Oct 2005 09:03:02 -0700
In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D5089@XCH-NW-7V2.nw.nos.boeing.com>
References: <39C363776A4E8C4A94691D2BD9D1C9A10D5089@XCH-NW-7V2.nw.nos.boeing.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <277497F7-8C01-416E-891D-449030D256C2@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Fri, 7 Oct 2005 08:51:51 -0700
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=10189; t=1128700983; x=1129133183;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Requirements=20for=20IP-in-IP=20Tunnel=20MTU=20Assurance|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Fri,=207=20Oct=202005=2008=3A51=3A51=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=YR/t1y6lu3eTn3Avd4FBnN5d395op/oxex3OP2C5mZINjIHjY1lSDC/yRRANL7UgDfLuuS9B
	Cte36XaGV7olYOk8OTlIsz4zRJrm0YG9MOdcelBQEAdk26fBv16GYROfsdwl+iNIMCK6n+iEdRv
	kreFZyDlSvf8ldiR+5+y0mQU=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

that's true. That said, fragmentation and reassembly are rather a big  
deal, big enough that RFC 1812 (which I edited but I didn't write -  
this text was agreed on by a large number of folks) comments in the  
discussion of section 5.2.6 Fragmentation and Reassembly: RFC-791  
Section 3.2

       A few people have suggested that there might be some topologies
       where reassembly of transit datagrams by routers might improve
       performance.  The fact that fragments may take different paths to
       the destination precludes safe use of such a feature.

The use of tunnels in the network is a case in which the router acts  
(from a certain perspective) as a host: it takes a payload, embeds it  
into an IP datagram (and might fragment it), transmits that across an  
IP network (where the receiving system might reassemble it), and then  
operates on that payload (in this case, sending it as an IP datagram  
somewhere else). However, this host also forwards traffic, obviously.

The reason that fragmentation in the network, as done in IPv4, was  
removed from IPv6 and made a host function was that fragmentation in  
the network is truly a last resort, and something many  
administrations disable entirely. So I find myself wondering  
(participant hat) why that applies in the general case and not in the  
specific case we are discussing.

BTW, I also wonder why it is specific to IP/IP encapsulation, as  
opposed to being considered also for tunnel-mode VPNs, GRE tunnels  
(used in Mobile IP), and so on. But I digress.

If we want to remove fragmentation from the network, then it seems to  
me that the approach of choice would be to figure out not the MTU for  
the tunnel, but the path MTU end to end. That is the direction of my  
question. Why is it proper to fragment at a tunnel endpoint and not  
in the general case? Why would this be preferable to finding the path  
MTU?

On Oct 7, 2005, at 8:21 AM, Templin, Fred L wrote:

> Fred,
>
> I couldn't tell whether you were asking a question here or
> not, but I don't see the tunnel MTU assurance requirement
> as being at-odds with the end-to-end principles. The tunnel
> is simply a link that occurs somewhere on the path and, like
> any other link, needs to present an assured MTU to layer 3.
> Link adaptation within the tunnel (i.e., below layer 3) is
> really no different than for ordinary links that need to do
> link-layer segmentation/reassembly to present an assured MTU
> to layer 3 (e.g., 802.11, 802.15).
>
> Fred
> fred.l.templin@boeing.com
>
>
>> -----Original Message-----
>> From: Fred Baker [mailto:fred@cisco.com]
>> Sent: Thursday, October 06, 2005 2:29 PM
>> To: Templin, Fred L
>> Cc: v6ops@ops.ietf.org; Matt Mathis
>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>
>> hmm.
>>
>> dumb question, wearing "participant" hat...
>>
>> fragmentation is done end to end in IPv6; the network doesn't
>> fragment. Ultimately, the question for the application is
>> what packet
>> size will work to get its data end to end, of which the tunnel is
>> just a part of the path. The big difference in doing this end to end
>> and on the tunnel is that on the tunnel a packet-too-large ICMP goes
>> to the tunnel endpoint and not the originator of the message,
>> so that
>> a per-potential-destination route MTU could be maintained, but that
>> only goes to the actual originator when the originator fires off a
>> message.
>>
>> It seems to me more practical to advise applications to (a) respond
>> to ICMP packet-too-huge by reducing their MSS, and to provide some
>> tool that would measure goodput rates such that if goodput is zero
>> but ICMP is not getting back to follow a heuristic to Matt's pmtud.
>> that has several effects. First, it is consistent with the end2end
>> principal, which suggests that one should not implement at a lower
>> layer something that already has to be supplied end to end; doing
>> this in the tunnel is a duplicative mechanism. Second, it
>> generalizes; on any path, there is a least MTU en route and
>> tyerefore
>> a packet size that will work. It is IMHO up to the
>> application, if it
>> wants its transmissions to work, to find that packet size
>> among other
>> things.
>>
>> On Oct 6, 2005, at 8:46 AM, Templin, Fred L wrote:
>>
>>> Fred,
>>>
>>> I'm not sure I exactly understand your question, but the
>>> requirement is for a path MTU assurance mechanism that is employed
>>> *within* the tunnel to ensure that packets no larger than the
>>> tunnel MTU make it through to the other side of the tunnel, i.e.,
>>> the mechanism would act only on one hop of what may be
>>>
>> multiple hop
>>
>>> path. The path MTU method outlined in Matt Mathis' draft is
>>> employed at packetization layers *above* the tunnel to determine
>>> the MTU of the path that may extend many hops beyond the
>>>
>> other side
>>
>>> of the tunnel, and I agree that the algorithm could be used for
>>> protocols other than TCP.
>>>
>>> The algorithm used by the tunnel MTU assurance mechanism might be
>>> quite similar to that described in Matt's draft, but the use case
>>> and implementation are different. In fact, it could happen that
>>> implementations of Matt's packetization layer path MTU
>>>
>> scheme and a
>>
>>> tunnel MTU assurance mechanism would occur in the same
>>>
>> physical box
>>
>>> and would act at independently of each other.
>>>
>>> Fred
>>> fred.l.templin@boeing.com
>>>
>>>
>>>> -----Original Message-----
>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>> Sent: Wednesday, October 05, 2005 5:37 PM
>>>> To: Templin, Fred L
>>>> Cc: v6ops@ops.ietf.org; Matt Mathis
>>>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>>>
>>>> ah. ok.
>>>>
>>>> so, dumb question of the month. are you looking for a simple
>>>> protocol that can be run over such a tunnel (including not
>>>>
>> only ip/
>>
>>>> ip, but
>>>>
>>>> GRE, IPSEC, etc) to determine the pmt of the tunnel? If so, would
>>>> something along the lines of pmtu accomplish it? As in, it seems
>>>> to me that the algrorithm is funcdamentally useful for things
>>>> other than TCP.
>>>>
>>>> On Oct 5, 2005, at 2:05 PM, Templin, Fred L wrote:
>>>>
>>>>> Fred,
>>>>>
>>>>> Yes, I know about Matt Mathis' work on Packetization Layer Path
>>>>> MTU Discovery (PLPMTUD) but that work covers
>>>>>
>> packetization layers
>>
>>>>> above layer 3 and is independent of the requirement to
>>>>>
>> provide an
>>
>>>>> assured MTU below layer 3 for IP/IP tunnels.
>>>>>
>>>>> To your question, the requirement is for an assured MTU
>>>>>
>> for IP/IP
>>
>>>>> tunnels, i.e., when the tunnel MTU is X bytes then upper layer
>>>>> protocols can be assured that packets no larger than X will
>>>>> traverse the tunnel under normal circumstances or a layer 3
>>>>> "packet too big" message will be returned that informs upper
>>>>> layers of a smaller MTU. For tunnels over IPv4, if no other
>>>>> mechanism were provided then the only assured MTU that could be
>>>>> offered would be 68 bytes since RFC 791 specifies that as the
>>>>> minimum link MTU for IPv4. But, IPv6 needs to see an assured MTU
>>>>> of 1280 bytes so some form of MTU assurance for tunnels is needed.
>>>>>
>>>>> Fred
>>>>> fred.l.templin@boeing.com
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>>>> Sent: Wednesday, October 05, 2005 1:34 PM
>>>>>> To: Templin, Fred L
>>>>>> Cc: v6ops@ops.ietf.org; Matt Mathis
>>>>>> Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>>>>>
>>>>>> I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/
>>>>>> draft- mathis-pmtud-method-00.txt. The fundamental algorithm is
>>>>>> that the sending TCP starts from the negotiated MSS (or should
>>>>>> transmission suddenly stop being successful, potentially due to
>>>>>> a route change that reduces the real path MTU from the current
>>>>>> message size it is sending) and reduces its segment size until
>>>>>> succeeds in getting a packet through, and then periodically
>>>>>> attempts to increase the message size in order to take
>>>>>>
>> advantage
>>
>>>>>> of capacity that might become available as routes shift. It
>>>>>> seems that this fundamental approach would address your issues.
>>>>>> Does it?
>>>>>>
>>>>>> As to the efficiency of file transfer, yes, if the header
>>>>>> overhead is of fixed size, carrying more payload will increase
>>>>>> efficiency. ie, if the IPv6 header is 40 bytes and the TCP
>>>>>> header is 20, and the IPv6 MTU is 1500 bytes, the maximum
>>>>>> payload we can carry is 1440 bytes, or 96%, and being able to
>>>>>> switch that to a 9180 byte IPv6 MTU would change the efficiency
>>>>>> to 99.3% and reduce the interrupt load an the two hosts by a
>>>>>> factor of about 9180/1500. Changing from 1280 to 1500 bytes,
>>>>>> however, is a change from 95.3% to 96% efficiency, which seems
>>>>>> relatively minor, and switching from 1280 to 1380 bytes of
>>>>>> payload seems even more trivial.
>>>>>>
>>>>>> The principal value of getting the pmtu right, it seems to me,
>>>>>> is to first get an estimated pmtu that in fact works at all
>>>>>> (downsize it from the negotiated MSS to a packet size
>>>>>>
>> that works
>>
>>>>>> regardless of what hiccups lie en route), and second to
>>>>>>
>> that, it
>>
>>>>>> would be really nice to minimize the interrupt load on the
>>>>>> sending and receiving hosts in order to balance the goals of
>>>>>> maximizing throughput and minimizing the impact on the hosts
>>>>>> themselves. ie, if the sender and receiver are on 10/100
>>>>>> Ethernets and there is an IP/IP tunnel on the path, carrying a
>>>>>> 1280 byte payload is better than carrying a 1440 byte payload
>>>>>> because the former works and the latter doesn't, and it
>>>>>>
>> would be
>>
>>>>>> nice to be able to figure out that a 1380 byte payload would
>>>>>> also work and be a .35% improvement in efficiency.
>>>>>>
>>>>>> So, question (and yes, this is a question): are you chasing a
>>>>>> problem I don't see? What is the objective here?
>>>>>>
>>>>>> On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>>>>>>
>>>>>>> Fred,
>>>>>>>
>>>>>>> Please see the following draft which documents operational
>>>>>>> issues relevant to v6ops and calls for a solution: http://
>>>>>>> www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>>>>>>>
>>>>>>> Please note that this obsoletes a previos draft called:
>>>>>>> "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
>>>>>>>
>>>>>>> Fred
>>>>>>> fred.l.templin@boeing.com
>>>>>>>
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Templin, Fred L
>>>>>>>> Sent: Friday, September 30, 2005 3:40 PM
>>>>>>>> To: Fred Baker
>>>>>>>> Cc: v6ops@ops.ietf.org
>>>>>>>> Subject: Requirements for Link Adaptation over IP-in-IPv4
>>>>>>>> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
>>>>>>>>
>>>>>>>> Fred - please see:
>>>>>>>>
>>>>>>>> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-
>>>>>>>> reqts-00.txt
>>>>>>>>
>>>>>>>> Fred
>>>>>>>> fred.l.templin@boeing.com
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Fred Baker [mailto:fred@cisco.com]
>>>>>>>>> Sent: Friday, September 23, 2005 9:24 AM
>>>>>>>>> To: Templin, Fred L
>>>>>>>>> Cc: v6ops@ops.ietf.org
>>>>>>>>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
>>>>>>>>>
>>>>>>>>> Does it still propose a protocol or protocol change?
>>>>>>>>>
>>>>>>>>> I don't know offhand whether the charter of v6ops then
>>>>>>>>> precluded protocol work, and won't go into whether it was
>>>>>>>>> proper for [MECH] to be done in v6ops. Given the present
>>>>>>>>> charter, I can treat it as a requirements document that may
>>>>>>>>> be asking for something like the work you are proposing. But
>>>>>>>>> my read of the document you pointed to is that it is still
>>>>>>>>> proposing an incompatible change (as in "unchanged equipment
>>>>>>>>> will not perform the function and once the message is
>>>>>>>>> segmented in this fashion it must be reassembled in this
>>>>>>>>> fashion.
>>>>>>>>>
>>>>>>>>> I think that has to be done in a WG chartered to do non-
>>>>>>>>> backward-compatible changes to IPv4.
>>>>>>>>>
>>>>>>>>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
>>>>>>>>>
>>>>>>>>>> Can this work be contributed as an extension to [MECH]?
>>>>>>>>>>
>>
>




From owner-v6ops@ops.ietf.org Fri Oct 07 12:58:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENvYV-0004z1-08
	for v6ops-archive@megatron.ietf.org; Fri, 07 Oct 2005 12:58:47 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00170
	for <v6ops-archive@lists.ietf.org>; Fri, 7 Oct 2005 12:58:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENvX4-000KL0-U9
	for v6ops-data@psg.com; Fri, 07 Oct 2005 16:57:18 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENvX4-000KKa-4b
	for v6ops@ops.ietf.org; Fri, 07 Oct 2005 16:57:18 +0000
Received: from stl-av-01.boeing.com ([192.76.190.6])
	by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id LAA23618;
	Fri, 7 Oct 2005 11:57:09 -0500 (CDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j97Gv9o12825;
	Fri, 7 Oct 2005 11:57:09 -0500 (CDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Oct 2005 09:57:03 -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: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Fri, 7 Oct 2005 09:57:02 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D508B@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
Thread-Index: AcXLVw0GncmeWxd2S6O1cE2Dnf3E4AAAcY7A
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>
Cc: <v6ops@ops.ietf.org>, "Matt Mathis" <mathis@psc.edu>
X-OriginalArrivalTime: 07 Oct 2005 16:57:03.0804 (UTC) FILETIME=[246847C0:01C5CB60]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,=20

Cutting down some on text from the earlier discussions:

> Why is it proper to fragment at a tunnel endpoint and not =20
> in the general case?

Because the tunnel endpoint is the head-end of a link over
which an assured MTU has to be presented to layer 3. This
falls within the realm of layer 2 link adaptation; not
network-based fragmentation.

> Why would this be preferable to finding the path MTU?

Tunnel MTU assurance is not a replacement for finding the
path MTU; the tunnel is just an ordinary link on the path
and the tunnel endpoint would participate in classic path
MTU discovery the same as for any other link.

Fred
fred.l.templin@boeing.com
=20





From owner-v6ops@ops.ietf.org Fri Oct 07 16:26:36 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENynb-0004AQ-7f
	for v6ops-archive@megatron.ietf.org; Fri, 07 Oct 2005 16:26:36 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21381
	for <v6ops-archive@lists.ietf.org>; Fri, 7 Oct 2005 16:26:32 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENykd-000DtX-KD
	for v6ops-data@psg.com; Fri, 07 Oct 2005 20:23:31 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [131.107.3.123] (helo=mail3.microsoft.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENykc-000DtF-6D
	for v6ops@ops.ietf.org; Fri, 07 Oct 2005 20:23:30 +0000
Received: from mailout2.microsoft.com ([157.54.1.120]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.2499);
	 Fri, 7 Oct 2005 13:23:29 -0700
Received: from red-hub-04.redmond.corp.microsoft.com ([157.54.3.6]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Oct 2005 13:23:28 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Oct 2005 13:23:28 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Fri, 7 Oct 2005 13:23:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
Date: Fri, 7 Oct 2005 13:23:28 -0700
Message-ID: <DAC3FCB50E31C54987CD10797DA511BA1141256E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance
thread-index: AcXKwLlb/iWZVC44Qp+7B3C3J1/E6AAu9Flg
From: "Christian Huitema" <huitema@windows.microsoft.com>
To: "Matt Mathis" <mathis@psc.edu>
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>,
        "Fred Baker" <fred@cisco.com>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 07 Oct 2005 20:23:28.0005 (UTC) FILETIME=[F9F76350:01C5CB7C]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I am just saying that ICMP black holes are frequent enough, because of
firewalls. The level of support in various stacks may vary. I would not
be surprised if it was be pretty simplistic in some cases. But stacks do
indeed have to be able to deal with the issue.=20

-----Original Message-----
From: Matt Mathis [mailto:mathis@psc.edu]=20
Sent: Thursday, October 06, 2005 2:55 PM
To: Christian Huitema
Cc: Templin, Fred L; Fred Baker; v6ops@ops.ietf.org
Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance

This strategy is only obvious if all important stacks already have
robust mechanisms to deal with ICMP black holes.

Christian, are you asserting that this is true?   Would you care to
define "all
important stacks"?

Thanks,
--MM--

On Thu, 6 Oct 2005, Christian Huitema wrote:

> There is an obvious strategy: tunnel servers should set the "don't
> fragment" bit when forwarding a packet larger than the "guaranteed
MTU",
> and allow fragmentation for smaller packets, e.g. smaller than 1280
for
> IPv6. Then, they should just ignore any ICMP message. That should make
> the tunnel behavior equivalent to sending through a firewall,
something
> that transport protocols are expected to handle.
>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
> Behalf Of Templin, Fred L
> Sent: Wednesday, October 05, 2005 2:06 PM
> To: Fred Baker
> Cc: v6ops@ops.ietf.org; Matt Mathis
> Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
>
> Fred,
>
> Yes, I know about Matt Mathis' work on Packetization Layer Path
> MTU Discovery (PLPMTUD) but that work covers packetization layers
> above layer 3 and is independent of the requirement to provide an
> assured MTU below layer 3 for IP/IP tunnels.
>
> To your question, the requirement is for an assured MTU for IP/IP
> tunnels, i.e., when the tunnel MTU is X bytes then upper layer
> protocols can be assured that packets no larger than X will
> traverse the tunnel under normal circumstances or a layer 3
> "packet too big" message will be returned that informs upper
> layers of a smaller MTU. For tunnels over IPv4, if no other
> mechanism were provided then the only assured MTU that could
> be offered would be 68 bytes since RFC 791 specifies that as
> the minimum link MTU for IPv4. But, IPv6 needs to see an assured
> MTU of 1280 bytes so some form of MTU assurance for tunnels
> is needed.
>
> Fred
> fred.l.templin@boeing.com
>
> > -----Original Message-----
> > From: Fred Baker [mailto:fred@cisco.com]
> > Sent: Wednesday, October 05, 2005 1:34 PM
> > To: Templin, Fred L
> > Cc: v6ops@ops.ietf.org; Matt Mathis
> > Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
> >
> > I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-
> > mathis-pmtud-method-00.txt. The fundamental algorithm is that the
> > sending TCP starts from the negotiated MSS (or should transmission
> > suddenly stop being successful, potentially due to a route change
> > that reduces the real path MTU from the current message size it is
> > sending) and reduces its segment size until succeeds in getting a
> > packet through, and then periodically attempts to increase the
> > message size in order to take advantage of capacity that
> > might become
> > available as routes shift. It seems that this fundamental approach
> > would address your issues. Does it?
> >
> > As to the efficiency of file transfer, yes, if the header
> > overhead is
> > of fixed size, carrying more payload will increase
> > efficiency. ie, if
> > the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6
> > MTU is 1500 bytes, the maximum payload we can carry is 1440
> > bytes, or
> > 96%, and being able to switch that to a 9180 byte IPv6 MTU would
> > change the efficiency to 99.3% and reduce the interrupt load an the
> > two hosts by a factor of about 9180/1500. Changing from 1280 to 1500
> > bytes, however, is a change from 95.3% to 96% efficiency,
> > which seems
> > relatively minor, and switching from 1280 to 1380 bytes of payload
> > seems even more trivial.
> >
> > The principal value of getting the pmtu right, it seems to me, is to
> > first get an estimated pmtu that in fact works at all (downsize it
> > from the negotiated MSS to a packet size that works regardless of
> > what hiccups lie en route), and second to that, it would be really
> > nice to minimize the interrupt load on the sending and receiving
> > hosts in order to balance the goals of maximizing throughput and
> > minimizing the impact on the hosts themselves. ie, if the sender and
> > receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the
> > path, carrying a 1280 byte payload is better than carrying a 1440
> > byte payload because the former works and the latter doesn't, and it
> > would be nice to be able to figure out that a 1380 byte
> > payload would
> > also work and be a .35% improvement in efficiency.
> >
> > So, question (and yes, this is a question): are you chasing a
> > problem
> > I don't see? What is the objective here?
> >
> > On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
> >
> > > Fred,
> > >
> > > Please see the following draft which documents operational issues
> > > relevant to v6ops and calls for a solution:
> > >
> > >
> >
http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
> > >
> > > Please note that this obsoletes a previos draft called:
> > > "Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
> > >
> > > Fred
> > > fred.l.templin@boeing.com
> > >
> > >
> > >> -----Original Message-----
> > >> From: Templin, Fred L
> > >> Sent: Friday, September 30, 2005 3:40 PM
> > >> To: Fred Baker
> > >> Cc: v6ops@ops.ietf.org
> > >> Subject: Requirements for Link Adaptation over IP-in-IPv4
> > >> Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
> > >>
> > >> Fred - please see:
> > >>
> > >> http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
> > >> qts-00.txt
> > >>
> > >> Fred
> > >> fred.l.templin@boeing.com
> > >>
> > >>
> > >>> -----Original Message-----
> > >>> From: Fred Baker [mailto:fred@cisco.com]
> > >>> Sent: Friday, September 23, 2005 9:24 AM
> > >>> To: Templin, Fred L
> > >>> Cc: v6ops@ops.ietf.org
> > >>> Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
> > >>>
> > >>> Does it still propose a protocol or protocol change?
> > >>>
> > >>> I don't know offhand whether the charter of v6ops then precluded
> > >>> protocol work, and won't go into whether it was proper for
> > >>>
> > >> [MECH] to
> > >>
> > >>> be done in v6ops. Given the present charter, I can treat it as a
> > >>> requirements document that may be asking for something like
> > >>>
> > >> the work
> > >>
> > >>> you are proposing. But my read of the document you pointed to
> > >>> is that
> > >>> it is still proposing an incompatible change (as in "unchanged
> > >>> equipment will not perform the function and once the message is
> > >>> segmented in this fashion it must be reassembled in this
fashion.
> > >>>
> > >>> I think that has to be done in a WG chartered to do
non-backward-
> > >>> compatible changes to IPv4.
> > >>>
> > >>> On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
> > >>>
> > >>>
> > >>>> Can this work be contributed as an extension to [MECH]?
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> >
>
>




From owner-v6ops@ops.ietf.org Fri Oct 07 17:34:41 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ENzrU-0006wp-HB
	for v6ops-archive@megatron.ietf.org; Fri, 07 Oct 2005 17:34:41 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25867
	for <v6ops-archive@lists.ietf.org>; Fri, 7 Oct 2005 17:34:37 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ENzpp-000NXT-At
	for v6ops-data@psg.com; Fri, 07 Oct 2005 21:32:57 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [212.27.42.28] (helo=smtp2-g19.free.fr)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ENzpl-000NVy-JC
	for v6ops@ops.ietf.org; Fri, 07 Oct 2005 21:32:54 +0000
Received: from [192.168.0.126] (ver78-2-82-241-89-240.fbx.proxad.net [82.241.89.240])
	by smtp2-g19.free.fr (Postfix) with ESMTP id 21B8733950;
	Fri,  7 Oct 2005 23:32:51 +0200 (CEST)
Message-ID: <4346E981.7000000@6wind.com>
Date: Fri, 07 Oct 2005 23:32:49 +0200
From: Vincent Jardin <vincent.jardin@6wind.com>
Organization: http://www.ipv6.6WIND.com/
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Christian Huitema <huitema@windows.microsoft.com>
CC: Matt Mathis <mathis@psc.edu>,
        "Templin, Fred L" <Fred.L.Templin@boeing.com>,
        Fred Baker <fred@cisco.com>, v6ops@ops.ietf.org
Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
References: <DAC3FCB50E31C54987CD10797DA511BA1141256E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
In-Reply-To: <DAC3FCB50E31C54987CD10797DA511BA1141256E@WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I agree. The main issues we saw are not related to "bad IP stacks", but 
to something inside the networks (mainly firewalls) that cannot be 
controlled. Many times, we needed to change the MSS to get Teredo, 
ISATAP, 6in4 or 6to4 working. It is just a fact (or maybe a dream) that 
we have to accept that any stacks should support the broken PMTUs.

My 2 cents,
   Vincent

Christian Huitema wrote:

>I am just saying that ICMP black holes are frequent enough, because of
>firewalls. The level of support in various stacks may vary. I would not
>be surprised if it was be pretty simplistic in some cases. But stacks do
>indeed have to be able to deal with the issue. 
>
>-----Original Message-----
>From: Matt Mathis [mailto:mathis@psc.edu] 
>Sent: Thursday, October 06, 2005 2:55 PM
>To: Christian Huitema
>Cc: Templin, Fred L; Fred Baker; v6ops@ops.ietf.org
>Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
>
>This strategy is only obvious if all important stacks already have
>robust mechanisms to deal with ICMP black holes.
>
>Christian, are you asserting that this is true?   Would you care to
>define "all
>important stacks"?
>
>Thanks,
>--MM--
>
>On Thu, 6 Oct 2005, Christian Huitema wrote:
>
>  
>
>>There is an obvious strategy: tunnel servers should set the "don't
>>fragment" bit when forwarding a packet larger than the "guaranteed
>>    
>>
>MTU",
>  
>
>>and allow fragmentation for smaller packets, e.g. smaller than 1280
>>    
>>
>for
>  
>
>>IPv6. Then, they should just ignore any ICMP message. That should make
>>the tunnel behavior equivalent to sending through a firewall,
>>    
>>
>something
>  
>
>>that transport protocols are expected to handle.
>>
>>-----Original Message-----
>>From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On
>>Behalf Of Templin, Fred L
>>Sent: Wednesday, October 05, 2005 2:06 PM
>>To: Fred Baker
>>Cc: v6ops@ops.ietf.org; Matt Mathis
>>Subject: RE: Requirements for IP-in-IP Tunnel MTU Assurance
>>
>>Fred,
>>
>>Yes, I know about Matt Mathis' work on Packetization Layer Path
>>MTU Discovery (PLPMTUD) but that work covers packetization layers
>>above layer 3 and is independent of the requirement to provide an
>>assured MTU below layer 3 for IP/IP tunnels.
>>
>>To your question, the requirement is for an assured MTU for IP/IP
>>tunnels, i.e., when the tunnel MTU is X bytes then upper layer
>>protocols can be assured that packets no larger than X will
>>traverse the tunnel under normal circumstances or a layer 3
>>"packet too big" message will be returned that informs upper
>>layers of a smaller MTU. For tunnels over IPv4, if no other
>>mechanism were provided then the only assured MTU that could
>>be offered would be 68 bytes since RFC 791 specifies that as
>>the minimum link MTU for IPv4. But, IPv6 needs to see an assured
>>MTU of 1280 bytes so some form of MTU assurance for tunnels
>>is needed.
>>
>>Fred
>>fred.l.templin@boeing.com
>>
>>    
>>
>>>-----Original Message-----
>>>From: Fred Baker [mailto:fred@cisco.com]
>>>Sent: Wednesday, October 05, 2005 1:34 PM
>>>To: Templin, Fred L
>>>Cc: v6ops@ops.ietf.org; Matt Mathis
>>>Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance
>>>
>>>I imagine you have read http://www.psc.edu/~mathis/MTU/pmtud/draft-
>>>mathis-pmtud-method-00.txt. The fundamental algorithm is that the
>>>sending TCP starts from the negotiated MSS (or should transmission
>>>suddenly stop being successful, potentially due to a route change
>>>that reduces the real path MTU from the current message size it is
>>>sending) and reduces its segment size until succeeds in getting a
>>>packet through, and then periodically attempts to increase the
>>>message size in order to take advantage of capacity that
>>>might become
>>>available as routes shift. It seems that this fundamental approach
>>>would address your issues. Does it?
>>>
>>>As to the efficiency of file transfer, yes, if the header
>>>overhead is
>>>of fixed size, carrying more payload will increase
>>>efficiency. ie, if
>>>the IPv6 header is 40 bytes and the TCP header is 20, and the IPv6
>>>MTU is 1500 bytes, the maximum payload we can carry is 1440
>>>bytes, or
>>>96%, and being able to switch that to a 9180 byte IPv6 MTU would
>>>change the efficiency to 99.3% and reduce the interrupt load an the
>>>two hosts by a factor of about 9180/1500. Changing from 1280 to 1500
>>>bytes, however, is a change from 95.3% to 96% efficiency,
>>>which seems
>>>relatively minor, and switching from 1280 to 1380 bytes of payload
>>>seems even more trivial.
>>>
>>>The principal value of getting the pmtu right, it seems to me, is to
>>>first get an estimated pmtu that in fact works at all (downsize it
>>>from the negotiated MSS to a packet size that works regardless of
>>>what hiccups lie en route), and second to that, it would be really
>>>nice to minimize the interrupt load on the sending and receiving
>>>hosts in order to balance the goals of maximizing throughput and
>>>minimizing the impact on the hosts themselves. ie, if the sender and
>>>receiver are on 10/100 Ethernets and there is an IP/IP tunnel on the
>>>path, carrying a 1280 byte payload is better than carrying a 1440
>>>byte payload because the former works and the latter doesn't, and it
>>>would be nice to be able to figure out that a 1380 byte
>>>payload would
>>>also work and be a .35% improvement in efficiency.
>>>
>>>So, question (and yes, this is a question): are you chasing a
>>>problem
>>>I don't see? What is the objective here?
>>>
>>>On Oct 5, 2005, at 9:16 AM, Templin, Fred L wrote:
>>>
>>>      
>>>
>>>>Fred,
>>>>
>>>>Please see the following draft which documents operational issues
>>>>relevant to v6ops and calls for a solution:
>>>>
>>>>
>>>>        
>>>>
>http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt
>  
>
>>>>Please note that this obsoletes a previos draft called:
>>>>"Requirements for Link Adaptation over IP-in-IPv4 Tunnels".
>>>>
>>>>Fred
>>>>fred.l.templin@boeing.com
>>>>
>>>>
>>>>        
>>>>
>>>>>-----Original Message-----
>>>>>From: Templin, Fred L
>>>>>Sent: Friday, September 30, 2005 3:40 PM
>>>>>To: Fred Baker
>>>>>Cc: v6ops@ops.ietf.org
>>>>>Subject: Requirements for Link Adaptation over IP-in-IPv4
>>>>>Tunnels (was RE: Link Adaptation for IPv6-in-IPv4 Tunnels)
>>>>>
>>>>>Fred - please see:
>>>>>
>>>>>http://www.ietf.org/internet-drafts/draft-templin-linkadapt-re
>>>>>qts-00.txt
>>>>>
>>>>>Fred
>>>>>fred.l.templin@boeing.com
>>>>>
>>>>>
>>>>>          
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Fred Baker [mailto:fred@cisco.com]
>>>>>>Sent: Friday, September 23, 2005 9:24 AM
>>>>>>To: Templin, Fred L
>>>>>>Cc: v6ops@ops.ietf.org
>>>>>>Subject: Re: Link Adaptation for IPv6-in-IPv4 Tunnels
>>>>>>
>>>>>>Does it still propose a protocol or protocol change?
>>>>>>
>>>>>>I don't know offhand whether the charter of v6ops then precluded
>>>>>>protocol work, and won't go into whether it was proper for
>>>>>>
>>>>>>            
>>>>>>
>>>>>[MECH] to
>>>>>
>>>>>          
>>>>>
>>>>>>be done in v6ops. Given the present charter, I can treat it as a
>>>>>>requirements document that may be asking for something like
>>>>>>
>>>>>>            
>>>>>>
>>>>>the work
>>>>>
>>>>>          
>>>>>
>>>>>>you are proposing. But my read of the document you pointed to
>>>>>>is that
>>>>>>it is still proposing an incompatible change (as in "unchanged
>>>>>>equipment will not perform the function and once the message is
>>>>>>segmented in this fashion it must be reassembled in this
>>>>>>            
>>>>>>
>fashion.
>  
>
>>>>>>I think that has to be done in a WG chartered to do
>>>>>>            
>>>>>>
>non-backward-
>  
>
>>>>>>compatible changes to IPv4.
>>>>>>
>>>>>>On Sep 23, 2005, at 9:04 AM, Templin, Fred L wrote:
>>>>>>
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>Can this work be contributed as an extension to [MECH]?
>>>>>>>
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>            
>>>>>>
>>>>>          
>>>>>
>>    
>>
>
>
>  
>





From owner-v6ops@ops.ietf.org Wed Oct 12 03:59:23 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPbWF-00086r-NY
	for v6ops-archive@megatron.ietf.org; Wed, 12 Oct 2005 03:59:23 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04059
	for <v6ops-archive@lists.ietf.org>; Wed, 12 Oct 2005 03:59:20 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EPbSc-000PDw-IQ
	for v6ops-data@psg.com; Wed, 12 Oct 2005 07:55:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EPbSb-000PDO-JH
	for v6ops@ops.ietf.org; Wed, 12 Oct 2005 07:55:37 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-1.cisco.com with ESMTP; 12 Oct 2005 00:55:37 -0700
X-IronPort-AV: i="3.97,205,1125903600"; 
   d="scan'208"; a="665361535:sNHT25231340"
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9C7t7Jx013980;
	Wed, 12 Oct 2005 00:55:35 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 12 Oct 2005 00:55:34 -0700
Received: from [198.18.159.207] ([10.21.145.83]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Wed, 12 Oct 2005 00:55:33 -0700
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Cc: Lindqvist Erik Kurt <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Time to put together an agenda
Date: Wed, 12 Oct 2005 03:45:17 -0400
To: v6ops@ops.ietf.org
X-Mailer: Apple Mail (2.734)
X-OriginalArrivalTime: 12 Oct 2005 07:55:33.0898 (UTC) FILETIME=[52FACEA0:01C5CF02]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Who has a document that is new since we met in Paris and needs to  
discuss?




From owner-v6ops@ops.ietf.org Wed Oct 12 13:22:57 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EPkJd-0001xI-M1
	for v6ops-archive@megatron.ietf.org; Wed, 12 Oct 2005 13:22:57 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06368
	for <v6ops-archive@lists.ietf.org>; Wed, 12 Oct 2005 13:22:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EPkHE-000LbQ-Rm
	for v6ops-data@psg.com; Wed, 12 Oct 2005 17:20:28 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1EPkHD-000LbD-Td
	for v6ops@ops.ietf.org; Wed, 12 Oct 2005 17:20:28 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1EPkHB-0007u6-B9; Wed, 12 Oct 2005 18:20:25 +0100
Message-ID: <434D4633.601@dial.pipex.com>
Date: Wed, 12 Oct 2005 18:21:55 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fred Baker <fred@cisco.com>
CC: v6ops@ops.ietf.org, Lindqvist Erik Kurt <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
Subject: Re: Time to put together an agenda
References: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
In-Reply-To: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have the updated ICMPv6 filtering draft.

I guess it would be good to give a status report ... the updated draft 
is filing tomorrow.

The security overview presumably just needs a report in your doc 
status.  BTW I haven't had any input from Tim Chown.. he has been tied 
up with other issues.

Regards,
Elwyn

Fred Baker wrote:

> Who has a document that is new since we met in Paris and needs to  
> discuss?
>




From owner-v6ops@ops.ietf.org Thu Oct 13 12:42:43 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EQ6AE-0005pA-SN
	for v6ops-archive@megatron.ietf.org; Thu, 13 Oct 2005 12:42:43 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27935
	for <v6ops-archive@lists.ietf.org>; Thu, 13 Oct 2005 12:42:38 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EQ671-000DLb-Cd
	for v6ops-data@psg.com; Thu, 13 Oct 2005 16:39:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EQ66y-000DKu-0D
	for v6ops@ops.ietf.org; Thu, 13 Oct 2005 16:39:20 +0000
Received: from blv-av-01.boeing.com ([192.42.227.216])
	by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA12838;
	Thu, 13 Oct 2005 09:39:15 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1])
	by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id j9DGdBJ19887;
	Thu, 13 Oct 2005 09:39:11 -0700 (PDT)
Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Thu, 13 Oct 2005 09:39:11 -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: Time to put together an agenda
Date: Thu, 13 Oct 2005 09:39:11 -0700
Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A181891B@XCH-NW-7V2.nw.nos.boeing.com>
Thread-Topic: Time to put together an agenda
Thread-Index: AcXPBRz9qwJmjs8wSGa2KoFQOkexPwBDy21A
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: "Fred Baker" <fred@cisco.com>, <v6ops@ops.ietf.org>
Cc: "Lindqvist Erik Kurt" <kurtis@kurtis.pp.se>,
        "David Kessens" <david.kessens@nokia.com>
X-OriginalArrivalTime: 13 Oct 2005 16:39:11.0558 (UTC) FILETIME=[A3C70660:01C5D014]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Fred,

Can we have a timeslot to discuss "Requirements for IP-in-IP
Tunnel MTU Assurance":

  http://www.ietf.org/internet-drafts/draft-templin-mtuassurance-00.txt

Fred
fred.l.templin@boeing.com=20

> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]=20
> Sent: Wednesday, October 12, 2005 12:45 AM
> To: v6ops@ops.ietf.org
> Cc: Lindqvist Erik Kurt; David Kessens
> Subject: Time to put together an agenda
>=20
> Who has a document that is new since we met in Paris and needs to =20
> discuss?
>=20
>=20




From owner-v6ops@ops.ietf.org Sun Oct 16 17:58:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERGWe-0004bU-BR
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 17:58:40 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27008
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 17:58:32 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERGVJ-000IVJ-SB
	for v6ops-data@psg.com; Sun, 16 Oct 2005 21:57:17 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERGVG-000IV2-Dz
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 21:57:14 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343322.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 00:01:59 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Sun, 16 Oct 2005 23:56:31 +0200
Subject: Re: Time to put together an agenda
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fred Baker <fred@cisco.com>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
CC: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
Message-ID: <BF78992F.1348F8%jordi.palet@consulintel.es>
Thread-Topic: Time to put together an agenda
Thread-Index: AcXSnHdotb8Pfj6PEdqQXQAKldLC/g==
In-Reply-To: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Mon, 17 Oct 2005 00:01:59 +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
Reply-To: jordi.palet@consulintel.es
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I will like to have a few minutes to talk about
draft-palet-v6ops-6in4-vs-6over4-00.txt.

The goal is to move it forward as an Informational WG item.

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Wed, 12 Oct 2005 03:45:17 -0400
> Para: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> CC: Lindqvist Erik Kurt <kurtis@kurtis.pp.se>, David Kessens
> <david.kessens@nokia.com>
> Asunto: Time to put together an agenda
> 
> Who has a document that is new since we met in Paris and needs to
> discuss?
> 







From owner-v6ops@ops.ietf.org Sun Oct 16 17:58:49 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERGWm-0004bg-Eq
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 17:58:49 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27013
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 17:58:40 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERGTX-000IQi-05
	for v6ops-data@psg.com; Sun, 16 Oct 2005 21:55:27 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERGTT-000IQN-4n
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 21:55:23 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343321.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 00:00:09 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Sun, 16 Oct 2005 23:54:57 +0200
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/g==
In-Reply-To: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3212351708_6739812"
X-Authenticated-Sender: jordi.palet@consulintel.es
X-Spam-Processed: consulintel.es, Mon, 17 Oct 2005 00:00:09 +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
Reply-To: jordi.palet@consulintel.es
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>Este mensaje tiene formato MIME. Al no reconocer su lector de
correo este formato, puede que todo o parte del mensaje resulte ilegible.

--B_3212351708_6739812
Content-type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Clue accepted ;-)

A new document has been submitted (attached for those that want to start
commenting already).

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> 
> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>> Overall, agree with your conclusions about 3.3, but I think there
>> is one more scenario, which is the one that we are facing, and
>> seems to me the right way to go, actually the natural one, being
>> deployed with some of our customers.
>> 
>>       ,---.                                                  ,---.
>>      /     \                                                /     \
>>     /       \                                              /       \
>>    ; IPv4+6  :                                            ; IPv4+6  :
>>    | Network |                                            | Network |
>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>      \    +----+     +----+       \   /      +----+     +----+    /
>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>             | Network+----+   +    | |    +  +----+Network |
>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>    | Network |                                            | Network |
>>    :         ;                                            :         ;
>>     \       /                                              \       /
>>      \     /                                                \     /
>>       `---'                                                  `---'
>> 
>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>> the v4-in-v6 tunneling, automatically.
> 
> There are certainly cases in which a consistent transition strategy
> is being followed and is working. I think I said something in the
> document about granting that the use of a single consistent strategy
> that works will probably work :^).
> 
> What I am concerned about is the proliferation of inconsistent
> strategies, and the set of cases I can come up with in which they do
> not work. That is the issue I am trying to raise.
> 
>> One more comment. I've discovered a lot of confusion in several
>> documents regarding 6over4 and 6in4, which is being followed by
>> confusing documents from vendors. I think is very important to make
>> a general recommendation, may be not just to this WG, but in
>> general to all the IETF documents which mention tunneling, to
>> clearly make a distinction between both mechanisms, probably
>> avoiding using "over" when actually is referring 6in4
>> encapsulation. Not sure if this should be raised at IESG level or
>> whatever. What do you think ?
> 
> What you expect clue? :^)
> 
> Yes, it would be good if people would say clueful things in a clueful
> way. There is probably room for an internet draft on the subject.
> 


--B_3212351708_6739812
Content-type: text/plain; name="draft-palet-v6ops-6in4-vs-6over4-00.txt";
 x-mac-creator="74657874";
 x-mac-type="54455854"
Content-disposition: attachment;
	filename="draft-palet-v6ops-6in4-vs-6over4-00.txt"
Content-Transfer-Encoding: base64

CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBKLiBQYWxldApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsaW50ZWwKRXhwaXJlczogQXBy
aWwgMTksIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDE2
LCAyMDA1CgoKICAgICAgICAgICAgICAgICAgICAgNmluNCB2ZXJzdXMgNm92ZXI0IHRlcm1p
bm9sb2d5CiAgICAgICAgICAgICAgICBkcmFmdC1wYWxldC12Nm9wcy02aW40LXZzLTZvdmVy
NC0wMC50eHQKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJ
bnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQogICBhcHBs
aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp
cyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Yg
d2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGlu
IGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcK
ICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw
cy4gIE5vdGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr
aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u
dGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv
dGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv
IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNp
dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0
IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRw
Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBv
ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0
CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0
LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDE5LCAyMDA2LgoKQ29weXJpZ2h0IE5vdGlj
ZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuCgpBYnN0
cmFjdAoKICAgVGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgdGhlIGV4aXN0aW5nIHRlcm1pbm9s
b2d5IGNvbmZ1c2lvbiBhbW9uZwogICByZWZlcmVuY2VzIHRvIElQdjYvSVB2NCBlbmNhcHN1
bGF0aW9ucyBhbmQgSVB2NC9JUHY2IHRyYW5zaXRpb24KICAgbWVjaGFuaXNtcy4KCgoKCgoK
CgoKUGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAg
ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJz
dXMgNm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKVGFibGUgb2Yg
Q29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAyLiAgRGVmaW5pdGlvbiBvZiAnaW4n
IGFuZCAnb3ZlcicgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgMy4g
IENvbmNsdXNpb25zIGFuZCBGdXR1cmUgQ29uc2lzdGVuY3kgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiA0CiAgIDQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA1LiAgSUFOQSBDb25zaWRlcmF0
aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAg
Ni4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiA1CiAgIDcuICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICAgIDcuMS4gIE5vcm1hdGl2
ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUK
ICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiA2CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICBJbnRlbGxlY3R1YWwg
UHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IDgKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQYWxldCAgICAgICAg
ICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNiAgICAgICAgICAgICAgICAgW1Bh
Z2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2aW40IHZlcnN1cyA2b3ZlcjQgdGVybWlu
b2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgoxLiAgSW50cm9kdWN0aW9uCgogICBBIG51
bWJlciBvZiBJRVRGIGRvY3VtZW50cyBoYXZlIHVzZWQgaW4gYW4gImludGVyY2hhbmdlYWJs
ZSIgd2F5CiAgIHNldmVyYWwgZXhwcmVzc2lvbnMgc3VjaCBhczoKCiAgIG8gIDZpbjQKCiAg
IG8gIDYtaW4tNAoKICAgbyAgSVB2Ni1pbi1JUHY0CgogICBvICBJUHY2IGluIElQdjQKCiAg
IG8gIDZvdmVyNAoKICAgbyAgNi1vdmVyLTQKCiAgIG8gIElQdjYtb3Zlci1JUHY0CgogICBv
ICBJUHY2IG92ZXIgSVB2NAoKICAgbyAgNGluNgoKICAgbyAgNC1pbi02CgogICBvICBJUHY0
LWluLUlQdjYKCiAgIG8gIElQdjQgaW4gSVB2NgoKICAgbyAgNG92ZXI2CgogICBvICA0LW92
ZXItNgoKICAgbyAgSVB2NC1vdmVyLUlQdjYKCiAgIG8gIElQdjQgb3ZlciBJUHY2CgogICBO
b3RlIHRoYXQgdGhpcyBsaXN0IGlzIG5vdCBleGhhdXN0aXZlIGFuZCBtYW55IG90aGVyIHNp
bWlsYXIKICAgZXhwcmVzc2lvbnMgbWF5IGJlIGFsc28gaW4gdXNlLiAgRm9yIGV4YW1wbGUs
IGluIHNvbWUgc2l0dWF0aW9ucwogICBvdGhlciBlbmNhcHN1bGF0aW5nIGxheWVycyBhcmUg
dXNlZCAoaS5lLiwgNi9VRFAvNCksIGFuZCBzaW1pbGFyCiAgIGV4cHJlc3Npb25zIGFyZSBi
ZWluZyB1c2VkLgoKICAgQXMgYSBjb25zZXF1ZW5jZSwgZG9jdW1lbnRzIGZyb20gdmVuZG9y
cywgcHJvZHVjdCBtYW51YWxzLAogICBwdWJsaWNhdGlvbnMsIHBhcGVycywgYm9va3MsIHR1
dG9yaWFscywgdHJhaW5pbmcgbWF0ZXJpYWwgYW5kIG1hbnkKICAgb3RoZXJzLCB1c2UgYWxz
byB0aG9zZSBleHByZXNzaW9ucy4KCiAgIEhvd2V2ZXIgbm90IGFsbCB0aG9zZSBkb2N1bWVu
dHMsIGluY2x1ZGluZyB0aGUgSUVURiBvbmVzLCBhcmUKICAgYWN0dWFsbHkgcmVmZXJyaW5n
IHRvIHRoZSBzYW1lIElQdjYvSVB2NCBlbmNhcHN1bGF0aW9ucyBvciBJUHY0L0lQdjYKCgoK
UGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAg
ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJzdXMg
Nm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKICAgdHJhbnNpdGlv
biBtZWNoYW5pc21zLgoKICAgVGhlIHJlc3VsdCBvZiB0aGlzIHRlcm1pbm9sb2d5IGNvbmZ1
c2lvbiBpcyBhIG51bWJlciBvZiBlcnJvcnMgYW1vbmcKICAgdmVuZG9ycywgb3BlcmF0b3Jz
LCBlbmdpbmVlcnMgYW5kIHVzZXJzIHdoZW4gZGVzaWduaW5nIGFuZAogICBkb2N1bWVudGlu
ZyBwcm9kdWN0cywgb3Igd2hlbiBzZXR0aW5nIHVwIHRyYW5zaXRpb24gbWVjaGFuaXNtcywK
ICAgY3JlYXRpbmcgYXQgdGhlIGVuZCB1bm5lY2Vzc2FyeSBvcGVyYXRpb25hbCBjb3N0cywg
c3BlY2lhbGx5IGZvcgogICBiZWdpbm5lcnMgd2hpY2ggdHJ5IHRvIHNldHVwIElQdjYgZm9y
IHRoZWlyIGZpcnN0IG9jY2FzaW9ucy4KCgoyLiAgRGVmaW5pdGlvbiBvZiAnaW4nIGFuZCAn
b3ZlcicKCiAgIElQIGluIElQIFR1bm5lbGluZyB3YXMgZGVmaW5lZCBieSBbMV0uICBBZnRl
cndhcmRzIFsyXSwgb2Jzb2xldGVkIGJ5CiAgIFszXSwgZGVmaW5lcyB0aGUgYmFzaWMgSVB2
NC9JUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcywgaW5jbHVkaW5nIHRoZQogICBlbmNhcHN1
bGF0aW9uIG9mIElQdjYgcGFja2V0cyBpbiBJUHY0IG9uZXMgKGJ5IG1lYW5zIG9mIHByb3Rv
Y29sIDQxKTsKICAgdGhpcyBkb2N1bWVudCBpcyBiZWluZyB1cGRhdGVkIGFzICJpZXRmLXY2
b3BzLW1lY2gtdjIiLgoKICAgU2ltaWxhcmx5LCBbNF0sIGRlZmluZXMgdGhlIGVuY2Fwc3Vs
YXRpb24gb2YgSVB2NCBwYWNrZXRzIGluIElQdjYKICAgb25lcy4KCiAgIEEgZmlyc3QgY29u
Y2x1c2lvbiBjYW4gYmUgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudHMgKGV2ZW4gaWYg
c29tZQogICBvZiB0aGVtIGFjdHVhbGx5IHVzZSwgc29tZSB0aW1lcywgIm92ZXIiKTogVGhv
c2UgZW5jYXBzdWxhdGlvbgogICBtZWNoYW5pc21zIGFyZSB0aGUgb25lcyB0aGF0IHNob3Vs
ZCB1c2UgdGhlICJpbiIgdGVybWlub2xvZ3kuICBOb3RlCiAgIHRoYXQgdGhleSBhcmUganVz
dCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMsIHdoaWNoIG9mdGVuIGFyZSB1c2VkIGJ5CiAg
IHNldmVyYWwgdHJhbnNpdGlvbiBtZWNoYW5pc21zLgoKICAgRnVydGhlcm1vcmUsIFs1XSBz
cGVjaWZ5IGEgdHJhbnNpdGlvbiBtZWNoYW5pc20sIHdoaWNoIHVzZXMgNmluNAogICAoZW5j
YXBzdWxhdGlvbiBvZiBJUHY2IHBhY2tldHMgaW4gSVB2NCBvbmVzKSwgY3JlYXRpbmcgYSB2
aXJ0dWFsIElQdjYKICAgbGluayBvdmVyIGFuIElQdjQgbXVsdGljYXN0IGluZnJhc3RydWN0
dXJlLiAgVGhpcyB0cmFuc2l0aW9uCiAgIG1lY2hhbmlzbSBpcyBuYW1lZCBhcyAiNm92ZXI0
Ii4KCiAgIENsZWFybHksICI2aW40IiBhbmQgIjZvdmVyNCIgYXJlIHF1aXRlIGRpZmZlcmVu
dCB0aGluZ3MsIGFjdHVhbGx5CiAgIDZvdmVyNCBpcyBhIHRyYW5zaXRpb24gbWVjaGFuaXNt
IHdoaWNoIHVzZXMgNmluNCBhcyB0aGUgcHJvY2VkdXJlIGZvcgogICBlbmNhcHN1bGF0aW5n
IElQdjYgcGFja2V0cyBpbiBJUHY0IG11bHRpY2FzdCBpbmZyYXN0cnVjdHVyZXMuCgogICBU
aGUgZmFjdCB0aGF0IHRoZXkgYXJlIGRpZmZlcmVudCB0aGluZ3MgYW5kIHNwZWNpYWxseSB0
aGUgcmVxdWlyZW1lbnQKICAgZm9yIGEgKElQdjQpIG11bHRpY2FzdCBpbmZyYXN0cnVjdHVy
ZSBmb3IgNm92ZXI0LCBtYWtlcyBuZWNlc3NhcnkgdG8KICAgY2xhcmlmeSB0aGUgZGlmZmVy
ZW5jZSBhbmQgYXZvaWQgY29uZnVzaW9ucyBhbW9uZyBib3RoLgoKICAgRW5naW5lZXJzIG9w
ZXJhdGluZyBuZXR3b3JrcyBhbmQgdGhlaXIgY3VzdG9tZXJzIChmb3IgZXhhbXBsZSB3aGVu
CiAgIHNldHRpbmcgdXAgdHVubmVscyksIG9mdGVuIGRvIG5vdCByZWFkIGFsbCB0aGUgSUVU
RiBkb2N1bWVudHMsIHNvCiAgIHRoZXkgY291bGQgZWFzaWx5IG1pc3VuZGVyc3RhbmQgaWYg
YSB0dW5uZWwgaXMgIjZvdmVyNCIgb3IgIjZpbjQiCiAgIChzcGVjaWFsbHkgd2hlbiB2ZW5k
b3IgZG9jdW1lbnRzIHVzZSBib3RoIHRlcm1zIHRvIGFjdHVhbGx5IG5hbWUKICAgIjZpbjQi
LCBwb3NzaWJseSBiZWNhdXNlIHRoZSBtaXN1c2FnZSBvZiB0aG9zZSB0ZXJtcyBpbiBbMl0s
IFszXSksCiAgIGFuZCB0aGlzIGNyZWF0ZXMgc29tZSBleHRyYSB0cm91Ymxlc2hvb3Rpbmcg
dGltZSBhbmQgY29uZnVzaW9uLgoKCjMuICBDb25jbHVzaW9ucyBhbmQgRnV0dXJlIENvbnNp
c3RlbmN5CgoKCgpQYWxldCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwg
MjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2
aW40IHZlcnN1cyA2b3ZlcjQgdGVybWlub2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgog
ICBJbiBvcmRlciB0byBhdm9pZCB0aGlzIGtpbmQgb2YgY29uZnVzaW9uLCBpdCBzaG91bGQg
YmUgdW5kZXJzdG9vZCB0aGUKICAgZGlmZmVyZW5jZSBiZXR3ZWVuIDZvdmVyNCBhbmQgNmlu
NCAoYW5kIGFueSBvdGhlciBlcXVpdmFsZW50CiAgIHRlcm1pbm9sb2dpZXMpLCBhbmQgZnV0
dXJlIGRvY3VtZW50cyAoaW5jbHVkaW5nIElFVEYgb25lcykgbXVzdCB0YWtlCiAgIHRoaXMg
aW4gY29uc2lkZXJhdGlvbiB3aGVuIHJlcHVibGlzaGVkLgoKICAgTW9yZW92ZXIsIG5ldyBk
b2N1bWVudHMgd2hpY2ggZGVzY3JpYmUgb3RoZXIgZW5jYXBzdWxhdGlvbnMgYW5kCiAgIHBy
b3RvY29scywgc3VjaCBhcyBJUHY0IGluIElQdjYsIElQdjYgaW4gVURQL0lQdjQsIElQdjYg
aW4gSVB2NiwgbXVzdAogICBhbHNvIHVzZSwgZm9yIGNvbnNpc3RlbmN5IHJlYXNvbnMsICJp
biIgaW5zdGVhZCBvZiAib3ZlciIuCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFueSBl
eGlzdGluZyBkb2N1bWVudHMgYXJlIGFtZW5kZWQgQVNBUCB0bwogICBhdm9pZCB0aGUgZXhp
c3RpbmcgY29uZnVzaW9uLgoKCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhp
cyBkb2N1bWVudCBkb2VzIG5vdCBoYXZlIGFueSBwcm90b2NvbC1yZWxhdGVkIHNlY3VyaXR5
CiAgIGNvbnNpZGVyYXRpb25zLgoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlz
IGRvY3VtZW50IGRvZXMgbm90IGhhdmUgYW55IHNwZWNpZmljIElBTkEgY29uc2lkZXJhdGlv
bnMuCgoKNi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBhdXRob3Igd291bGQgbGlrZSB0
byBhY2tub3dsZWRnZSB0aGUgaW5wdXRzIG9mIC4uLgoKCjcuICBSZWZlcmVuY2VzCgo3LjEu
ICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgWzFdICBTaW1wc29uLCBXLiwgIklQIGluIElQ
IFR1bm5lbGluZyIsIFJGQyAxODUzLCBPY3RvYmVyIDE5OTUuCgogICBbMl0gIEdpbGxpZ2Fu
LCBSLiBhbmQgRS4gTm9yZG1hcmssICJUcmFuc2l0aW9uIE1lY2hhbmlzbXMgZm9yIElQdjYK
ICAgICAgICBIb3N0cyBhbmQgUm91dGVycyIsIFJGQyAxOTMzLCBBcHJpbCAxOTk2LgoKICAg
WzNdICBHaWxsaWdhbiwgUi4gYW5kIEUuIE5vcmRtYXJrLCAiVHJhbnNpdGlvbiBNZWNoYW5p
c21zIGZvciBJUHY2CiAgICAgICAgSG9zdHMgYW5kIFJvdXRlcnMiLCBSRkMgMjg5MywgQXVn
dXN0IDIwMDAuCgogICBbNF0gIENvbnRhLCBBLiBhbmQgUy4gRGVlcmluZywgIkdlbmVyaWMg
UGFja2V0IFR1bm5lbGluZyBpbiBJUHY2CiAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyAy
NDczLCBEZWNlbWJlciAxOTk4LgoKICAgWzVdICBDYXJwZW50ZXIsIEIuIGFuZCBDLiBKdW5n
LCAiVHJhbnNtaXNzaW9uIG9mIElQdjYgb3ZlciBJUHY0CiAgICAgICAgRG9tYWlucyB3aXRo
b3V0IEV4cGxpY2l0IFR1bm5lbHMiLCBSRkMgMjUyOSwgTWFyY2ggMTk5OS4KCgoKCgpQYWxl
dCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNiAgICAgICAgICAg
ICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2aW40IHZlcnN1cyA2b3Zl
cjQgdGVybWlub2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgo3LjIuICBJbmZvcm1hdGl2
ZSBSZWZlcmVuY2VzCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKUGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIw
MDYgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmlu
NCB2ZXJzdXMgNm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKQXV0
aG9yJ3MgQWRkcmVzcwoKICAgSm9yZGkgUGFsZXQgTWFydGluZXoKICAgQ29uc3VsaW50ZWwK
ICAgU2FuIEpvc2UgQXJ0ZXNhbm8sIDEKICAgQWxjb2JlbmRhcyAtIE1hZHJpZAogICBFLTI4
MTA4IC0gU3BhaW4KCiAgIFBob25lOiArMzQgOTEgMTUxIDgxIDk5CiAgIEZheDogICArMzQg
OTEgMTUxIDgxIDk4CiAgIEVtYWlsOiBqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcwoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGFsZXQgICAgICAgICAgICAg
ICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDdd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJzdXMgNm92ZXI0IHRlcm1pbm9sb2d5
ICAgICAgICAgT2N0b2JlciAyMDA1CgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu
dAoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0
eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBv
dGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhl
IGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4K
ICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVu
ZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5v
ciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVu
dCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAg
b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1l
bnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBv
ZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55
CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRo
ZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGlj
ZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkg
cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRp
b24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y
eSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMg
YW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAg
Y29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw
cm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1h
eSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBh
ZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRm
Lm9yZy4KCgpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5CgogICBUaGlzIGRvY3VtZW50IGFuZCB0
aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4KICAg
IkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhF
L1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElO
VEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVAogICBFTkdJTkVFUklORyBUQVNLIEZP
UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsCiAgIElO
Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBP
RiBUSEUKICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdI
VFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKQ29weXJpZ2h0IFN0YXRlbWVu
dAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlz
IGRvY3VtZW50IGlzIHN1YmplY3QKICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJl
c3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQKICAgZXhjZXB0IGFzIHNldCBm
b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4KCgpB
Y2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24g
aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoK
UGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAg
ICAgICAgICAgIFtQYWdlIDhdCgwKCg==

--B_3212351708_6739812--







From owner-v6ops@ops.ietf.org Sun Oct 16 19:13:14 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERHgo-00009D-I5
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 19:13:14 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01739
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 19:13:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERHew-000MkT-31
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:11:18 +0000
Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERHes-000MkF-Kk
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:11:14 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Date: Sun, 16 Oct 2005 19:10:47 -0400
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/gACQSf/
From: "Durand, Alain" <Alain_Durand@cable.comcast.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 16 Oct 2005 23:10:48.0418 (UTC) FILETIME=[D83C9420:01C5D2A6]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Few comments:
=20
a) I have seen much more confusion with 6to4 that with anything else. =
Most people think of it
    as NAT IPv6 -> IPv4.
=20
b) Many other encapsulation exists, not just v6/v4 & friends. The jargon =
"over" is used very widely,
    like ATM over Sonnet, and, for instance, many of the documents in =
the Int area can be described
    as "IP over foo". So creating a new jargon for just IPvx over IPvy =
may introduce even more
    confusion.
=20
c)  More, asking all the standard bodies that used "foo over bar" =
terminology to
    change to "foo in bar" just because there is a little use IETF =
protocol named "6over4"
    does not sound very realistic.
=20
d) 6over4 as a transition mechanism isn't used much, it might be simpler =
to just suggest to
    either deprecate it or rename it, then restoring the original "foo =
over bar" terminology
    as semantically equivalent to "foo in far".
=20
   - Alain.

________________________________

From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
Sent: Sun 10/16/2005 5:54 PM
To: v6ops@ops.ietf.org
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt



Clue accepted ;-)

A new document has been submitted (attached for those that want to start
commenting already).

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>
> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>> Overall, agree with your conclusions about 3.3, but I think there
>> is one more scenario, which is the one that we are facing, and
>> seems to me the right way to go, actually the natural one, being
>> deployed with some of our customers.
>>
>>       ,---.                                                  ,---.
>>      /     \                                                /     \
>>     /       \                                              /       \
>>    ; IPv4+6  :                                            ; IPv4+6  :
>>    | Network |                                            | Network |
>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>      \    +----+     +----+       \   /      +----+     +----+    /
>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>             | Network+----+   +    | |    +  +----+Network |
>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>    | Network |                                            | Network |
>>    :         ;                                            :         ;
>>     \       /                                              \       /
>>      \     /                                                \     /
>>       `---'                                                  `---'
>>
>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>> the v4-in-v6 tunneling, automatically.
>
> There are certainly cases in which a consistent transition strategy
> is being followed and is working. I think I said something in the
> document about granting that the use of a single consistent strategy
> that works will probably work :^).
>
> What I am concerned about is the proliferation of inconsistent
> strategies, and the set of cases I can come up with in which they do
> not work. That is the issue I am trying to raise.
>
>> One more comment. I've discovered a lot of confusion in several
>> documents regarding 6over4 and 6in4, which is being followed by
>> confusing documents from vendors. I think is very important to make
>> a general recommendation, may be not just to this WG, but in
>> general to all the IETF documents which mention tunneling, to
>> clearly make a distinction between both mechanisms, probably
>> avoiding using "over" when actually is referring 6in4
>> encapsulation. Not sure if this should be raised at IESG level or
>> whatever. What do you think ?
>
> What you expect clue? :^)
>
> Yes, it would be good if people would say clueful things in a clueful
> way. There is probably room for an internet draft on the subject.
>







From owner-v6ops@ops.ietf.org Sun Oct 16 19:43:58 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERIAX-00004w-VN
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 19:43:58 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03037
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 19:43:51 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERI9I-000OPU-AM
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:42:40 +0000
Received: from [24.227.114.150] (helo=sleekfreak.ath.cx)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERI9F-000OPB-1C
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:42:37 +0000
Received: from localhost ([127.0.0.1])
	by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian))
	id 1ERI9J-00011P-00; Sun, 16 Oct 2005 19:42:41 -0400
Date: Sun, 16 Oct 2005 19:42:41 -0400 (EDT)
From: shogunx <shogunx@sleekfreak.ath.cx>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
In-Reply-To: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.44.0510161942310.3866-100000@sleekfreak.ath.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

that should read "v4 over v6"

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/





From owner-v6ops@ops.ietf.org Sun Oct 16 19:44:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERIAf-0000Iy-Qy
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 19:44:05 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03041
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 19:43:59 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERI9T-000OPy-B2
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:42:51 +0000
Received: from [24.227.114.150] (helo=sleekfreak.ath.cx)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERI9H-000OPN-UC
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:42:40 +0000
Received: from localhost ([127.0.0.1])
	by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian))
	id 1ERI8U-00011N-00; Sun, 16 Oct 2005 19:41:50 -0400
Date: Sun, 16 Oct 2005 19:41:45 -0400 (EDT)
From: shogunx <shogunx@sleekfreak.ath.cx>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
In-Reply-To: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Fred,

Why tunnel v over v6?

Scott


On Sun, 16 Oct 2005, JORDI PALET MARTINEZ wrote:

> Clue accepted ;-)
>
> A new document has been submitted (attached for those that want to start
> commenting already).
>
> Regards,
> Jordi
>
>
>
>
> > De: Fred Baker <fred@cisco.com>
> > Responder a: <owner-v6ops@ops.ietf.org>
> > Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> > Para: <jordi.palet@consulintel.es>
> > CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> > Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> >
> > On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
> >> Overall, agree with your conclusions about 3.3, but I think there
> >> is one more scenario, which is the one that we are facing, and
> >> seems to me the right way to go, actually the natural one, being
> >> deployed with some of our customers.
> >>
> >>       ,---.                                                  ,---.
> >>      /     \                                                /     \
> >>     /       \                                              /       \
> >>    ; IPv4+6  :                                            ; IPv4+6  :
> >>    | Network |                                            | Network |
> >>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
> >>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
> >>      \    +----+     +----+       \   /      +----+     +----+    /
> >>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
> >>             | Network+----+   +    | |    +  +----+Network |
> >>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
> >>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
> >>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
> >>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
> >>    | Network |                                            | Network |
> >>    :         ;                                            :         ;
> >>     \       /                                              \       /
> >>      \     /                                                \     /
> >>       `---'                                                  `---'
> >>
> >> Network A and D are IPv6-only, with GW-A and GW-B taking care of
> >> the v4-in-v6 tunneling, automatically.
> >
> > There are certainly cases in which a consistent transition strategy
> > is being followed and is working. I think I said something in the
> > document about granting that the use of a single consistent strategy
> > that works will probably work :^).
> >
> > What I am concerned about is the proliferation of inconsistent
> > strategies, and the set of cases I can come up with in which they do
> > not work. That is the issue I am trying to raise.
> >
> >> One more comment. I've discovered a lot of confusion in several
> >> documents regarding 6over4 and 6in4, which is being followed by
> >> confusing documents from vendors. I think is very important to make
> >> a general recommendation, may be not just to this WG, but in
> >> general to all the IETF documents which mention tunneling, to
> >> clearly make a distinction between both mechanisms, probably
> >> avoiding using "over" when actually is referring 6in4
> >> encapsulation. Not sure if this should be raised at IESG level or
> >> whatever. What do you think ?
> >
> > What you expect clue? :^)
> >
> > Yes, it would be good if people would say clueful things in a clueful
> > way. There is probably room for an internet draft on the subject.
> >
>
>

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/





From owner-v6ops@ops.ietf.org Sun Oct 16 19:45:40 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERICB-0000S5-Tq
	for v6ops-archive@megatron.ietf.org; Sun, 16 Oct 2005 19:45:40 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03084
	for <v6ops-archive@lists.ietf.org>; Sun, 16 Oct 2005 19:45:33 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERIBP-000OYN-Ar
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:44:51 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERIBL-000OXp-SC
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:44:48 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343398.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 01:49:36 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Mon, 17 Oct 2005 01:40:09 +0200
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF78B179.134994%jordi.palet@consulintel.es>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/gACQSf/AAFraKQ=
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Alain,

The point is not only the IETF docs ... Is more all the vendor documents an=
d
operational guidelines.

So, if we decide to rename 6over4 (6overm4, for example), we still need to
have a document that says 6in4=3D6over4 from now on.

I was referring only to 6in4, 4in6, not foo over bar, but in any case, I'm
not absolutely sure if we really need to modify the IETF documents as I
indicate in this document, or if just the document itself is enough
clarification and must reinforce the change for any new publications
(specially for vendor documents, etc.).

Regards,
Jordi




> De: "Durand, Alain" <Alain_Durand@cable.comcast.com>
> Responder a: <alain_durand@cable.comcast.com>
> Fecha: Sun, 16 Oct 2005 19:10:47 -0400
> Para: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
> Conversaci=F3n: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> Asunto: RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>=20
> Few comments:
> =20
> a) I have seen much more confusion with 6to4 that with anything else. Mos=
t
> people think of it
>     as NAT IPv6 -> IPv4.
> =20
> b) Many other encapsulation exists, not just v6/v4 & friends. The jargon
> "over" is used very widely,
>     like ATM over Sonnet, and, for instance, many of the documents in the=
 Int
> area can be described
>     as "IP over foo". So creating a new jargon for just IPvx over IPvy ma=
y
> introduce even more
>     confusion.
> =20
> c)  More, asking all the standard bodies that used "foo over bar" termino=
logy
> to
>     change to "foo in bar" just because there is a little use IETF protoc=
ol
> named "6over4"
>     does not sound very realistic.
> =20
> d) 6over4 as a transition mechanism isn't used much, it might be simpler =
to
> just suggest to
>     either deprecate it or rename it, then restoring the original "foo ov=
er
> bar" terminology
>     as semantically equivalent to "foo in far".
> =20
>    - Alain.
>=20
> ________________________________
>=20
> From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
> Sent: Sun 10/16/2005 5:54 PM
> To: v6ops@ops.ietf.org
> Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>=20
>=20
>=20
> Clue accepted ;-)
>=20
> A new document has been submitted (attached for those that want to start
> commenting already).
>=20
> Regards,
> Jordi
>=20
>=20
>=20
>=20
>> De: Fred Baker <fred@cisco.com>
>> Responder a: <owner-v6ops@ops.ietf.org>
>> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
>> Para: <jordi.palet@consulintel.es>
>> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
>> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>>=20
>> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>>> Overall, agree with your conclusions about 3.3, but I think there
>>> is one more scenario, which is the one that we are facing, and
>>> seems to me the right way to go, actually the natural one, being
>>> deployed with some of our customers.
>>>=20
>>>       ,---.                                                  ,---.
>>>      /     \                                                /     \
>>>     /       \                                              /       \
>>>    ; IPv4+6  :                                            ; IPv4+6  :
>>>    | Network |                                            | Network |
>>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>>      \    +----+     +----+       \   /      +----+     +----+    /
>>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>>             | Network+----+   +    | |    +  +----+Network |
>>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>>    | Network |                                            | Network |
>>>    :         ;                                            :         ;
>>>     \       /                                              \       /
>>>      \     /                                                \     /
>>>       `---'                                                  `---'
>>>=20
>>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>>> the v4-in-v6 tunneling, automatically.
>>=20
>> There are certainly cases in which a consistent transition strategy
>> is being followed and is working. I think I said something in the
>> document about granting that the use of a single consistent strategy
>> that works will probably work :^).
>>=20
>> What I am concerned about is the proliferation of inconsistent
>> strategies, and the set of cases I can come up with in which they do
>> not work. That is the issue I am trying to raise.
>>=20
>>> One more comment. I've discovered a lot of confusion in several
>>> documents regarding 6over4 and 6in4, which is being followed by
>>> confusing documents from vendors. I think is very important to make
>>> a general recommendation, may be not just to this WG, but in
>>> general to all the IETF documents which mention tunneling, to
>>> clearly make a distinction between both mechanisms, probably
>>> avoiding using "over" when actually is referring 6in4
>>> encapsulation. Not sure if this should be raised at IESG level or
>>> whatever. What do you think ?
>>=20
>> What you expect clue? :^)
>>=20
>> Yes, it would be good if people would say clueful things in a clueful
>> way. There is probably room for an internet draft on the subject.
>>=20
>=20
>=20
>=20







From owner-v6ops@ops.ietf.org Mon Oct 17 03:53:01 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERPno-0000u8-JH
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 03:53:01 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23049
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 03:52:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERPkn-000OyK-Q9
	for v6ops-data@psg.com; Mon, 17 Oct 2005 07:49:53 +0000
Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERPkk-000Oxq-8c
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 07:49:50 +0000
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id j9H7nh9v006171
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 08:49:44 +0100
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j9H7nhU13807
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 08:49:43 +0100
Date: Mon, 17 Oct 2005 08:49:43 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Message-ID: <20051017074939.GA13256@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Sun, Oct 16, 2005 at 07:10:47PM -0400, Durand, Alain wrote:
>  
> d) 6over4 as a transition mechanism isn't used much, it might be simpler to just suggest to
>     either deprecate it or rename it, then restoring the original "foo over bar" terminology
>     as semantically equivalent to "foo in far".

I have not seen any active use of 6over4.   Given the huge (and potentially
confusing) pool of transition/integration solutions already on the table, 
we should consider deprecating it.

Tim




From owner-v6ops@ops.ietf.org Mon Oct 17 05:24:03 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERRDv-0002az-JV
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 05:24:03 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28610
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 05:23:55 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERRBv-0007HO-AS
	for v6ops-data@psg.com; Mon, 17 Oct 2005 09:21:59 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERRBu-0007H7-9P
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 09:21:58 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ERRBs-0000QB-9v; Mon, 17 Oct 2005 10:21:56 +0100
Message-ID: <43536D8B.2070802@dial.pipex.com>
Date: Mon, 17 Oct 2005 10:23:23 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, Cedric Aoun <cedaoun@yahoo.fr>
Subject: New version of draft-ietf-v6ops-natpt-to-expermentl(-02)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

This draft is taking part in a new experiment designed to speed up 
publication after approval.

The draft is being copy edited by the RFC Editor in advance of IETF Last 
Call and submission to the IESG so that
- delays after approval are minimised by parellelising the copy 
editing/community review process
- the text which is reviewed and approved is essentially the text that 
is published rather than a copy edited version, so minimising the chance 
that the copy editing inadvertently changes the technical meaning

In the process of getting the document into this process we discovered 
that four of the references were in fact not referenced in the text 
(thanks to a more recent version of xml2rfc!).
It turns out that three of them are left over references from an early 
version of the document that shouldn't be in the
document at all: RFC3095, RFC 3574, I-D.durand-v6ops-dualstack-vs-natpt.
There ought to be a reference to the fourth one, RFC3484 (default 
address selection),  in the second  paragraph of s4.1.

This mistake has been corrected and  we have taken the chance to update 
Cedric Aoun's contact details: the updated version (-02) will be 
available in the I-D database shortly.

The copy edited document will be published probably in about a week's 
time and will be the one that is submitted for IETF last call (althoug 
it is itself informational, it affects a standards track document).

Regards,
Elwyn




From owner-v6ops@ops.ietf.org Mon Oct 17 08:37:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERUEr-0003tf-Im
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 08:37:13 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09470
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 08:37:06 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERUC6-000IQP-UV
	for v6ops-data@psg.com; Mon, 17 Oct 2005 12:34:22 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERUC6-000IQC-Bl
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 12:34:22 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-2.cisco.com with ESMTP; 17 Oct 2005 05:34:22 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HCYFud005100;
	Mon, 17 Oct 2005 05:34:20 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 17 Oct 2005 05:34:08 -0700
Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 17 Oct 2005 05:34:08 -0700
In-Reply-To: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
References: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AC1FD12F-AD0B-4969-978A-347A4526034F@cisco.com>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>,
        "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Date: Mon, 17 Oct 2005 05:34:07 -0700
To: shogunx <shogunx@sleekfreak.ath.cx>
X-Mailer: Apple Mail (2.734)
X-OriginalArrivalTime: 17 Oct 2005 12:34:08.0316 (UTC) FILETIME=[119D57C0:01C5D317]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

if you have a v6-only domain - and these already exist - and you want  
v4 to run over it, that's you're only option.

On Oct 16, 2005, at 4:41 PM, shogunx wrote:

> Why tunnel v over v6?
>




From owner-v6ops@ops.ietf.org Mon Oct 17 10:10:30 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERVh8-0000Ki-4N
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:10:30 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14457
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 10:10:22 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERVf9-000NsX-Qm
	for v6ops-data@psg.com; Mon, 17 Oct 2005 14:08:27 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERVf9-000NsI-3a
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 14:08:27 +0000
Received: from sj-core-4.cisco.com ([171.68.223.138])
  by sj-iport-5.cisco.com with ESMTP; 17 Oct 2005 07:08:26 -0700
X-IronPort-AV: i="3.97,222,1125903600"; 
   d="scan'208"; a="220833991:sNHT782602248"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9HE8NUw012634;
	Mon, 17 Oct 2005 07:08:24 -0700 (PDT)
Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9HEIu6v028031;
	Mon, 17 Oct 2005 07:18:56 -0700
In-Reply-To: <20051017074939.GA13256@login.ecs.soton.ac.uk>
References: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com> <20051017074939.GA13256@login.ecs.soton.ac.uk>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <65B4EA83-C522-43EE-967B-06D6DE428FA4@cisco.com>
Cc: v6ops@ops.ietf.org
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Date: Mon, 17 Oct 2005 07:08:22 -0700
To: Tim Chown <tjc@ecs.soton.ac.uk>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=550; t=1129558736; x=1129990936;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20RV=3A=20I-D=20ACTION=3Adraft-baker-v6ops-end2end-00.txt|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Mon,=2017=20Oct=202005=2007=3A08=3A22=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=oQYLdxQFO/IZZjkyymMp0mNgUqrOmGVuJi2pbFwuivB6WtAEHzOYDAGvBfOd8IvkJAQlKlwm
	/K/N7YXAsumsvgRY1GVKrYumohzh3HffXrCHsNdH1g7zjuKFEmVTRmDtzn25jqcC8u1bi7fnB7O
	Stej8sJik1et21bgfupJhVO4=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

you might check the nanog list. There is an active discussion of the  
use of 6to4 operationally on it right now.

On Oct 17, 2005, at 12:49 AM, Tim Chown wrote:

> On Sun, Oct 16, 2005 at 07:10:47PM -0400, Durand, Alain wrote:
>
>>
>> d) 6over4 as a transition mechanism isn't used much, it might be  
>> simpler to just suggest to
>>     either deprecate it or rename it, then restoring the original  
>> "foo over bar" terminology
>>     as semantically equivalent to "foo in far".
>>
>
> I have not seen any active use of 6over4.   Given the huge (and  
> potentially
> confusing) pool of transition/integration solutions already on the  
> table,
> we should consider deprecating it.
>
> Tim
>




From owner-v6ops@ops.ietf.org Mon Oct 17 10:27:54 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERVxy-00054s-0S
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 10:27:54 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15373
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 10:27:46 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERVxR-000OxX-Qk
	for v6ops-data@psg.com; Mon, 17 Oct 2005 14:27:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERVxQ-000Owx-Sv
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 14:27:21 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001345469.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 16:32:02 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Mon, 17 Oct 2005 16:26:53 +0200
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF79814D.134E29%jordi.palet@consulintel.es>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXTJtGuECfaSj8aEdqiqQAKldLC/g==
In-Reply-To: <65B4EA83-C522-43EE-967B-06D6DE428FA4@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 17 Oct 2005 16:32:06 +0200
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yes but is about 6to4, not 6over4 (the one that is often confused with
6in4).

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 17 Oct 2005 07:08:22 -0700
> Para: Tim Chown <tjc@ecs.soton.ac.uk>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> 
> you might check the nanog list. There is an active discussion of the
> use of 6to4 operationally on it right now.
> 
> On Oct 17, 2005, at 12:49 AM, Tim Chown wrote:
> 
>> On Sun, Oct 16, 2005 at 07:10:47PM -0400, Durand, Alain wrote:
>> 
>>> 
>>> d) 6over4 as a transition mechanism isn't used much, it might be
>>> simpler to just suggest to
>>>     either deprecate it or rename it, then restoring the original
>>> "foo over bar" terminology
>>>     as semantically equivalent to "foo in far".
>>> 
>> 
>> I have not seen any active use of 6over4.   Given the huge (and
>> potentially
>> confusing) pool of transition/integration solutions already on the
>> table,
>> we should consider deprecating it.
>> 
>> Tim
>> 
> 




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

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







From owner-v6ops@ops.ietf.org Mon Oct 17 11:28:08 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERWuG-0003rw-Lt
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:28:08 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19329
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 11:28:00 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERWsb-0002Or-MH
	for v6ops-data@psg.com; Mon, 17 Oct 2005 15:26:25 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [24.227.114.150] (helo=sleekfreak.ath.cx)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERWsa-0002O7-T0
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 15:26:25 +0000
Received: from localhost ([127.0.0.1])
	by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian))
	id 1ERWu1-0002nV-00; Mon, 17 Oct 2005 11:27:53 -0400
Date: Mon, 17 Oct 2005 11:27:47 -0400 (EDT)
From: shogunx <shogunx@sleekfreak.ath.cx>
To: Fred Baker <fred@cisco.com>
cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>,
        "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
In-Reply-To: <AC1FD12F-AD0B-4969-978A-347A4526034F@cisco.com>
Message-ID: <Pine.LNX.4.44.0510171118210.10671-100000@sleekfreak.ath.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Mon, 17 Oct 2005, Fred Baker wrote:

> if you have a v6-only domain - and these already exist - and you want
> v4 to run over it, that's you're only option.

so if i want to provide ipv4 service to my wireless network, currently
v6 only, unless you call "v4 NAT" v4 cnnectivity, which i don't because
the end to end is broken with NAT, i place a v4inv6 tunnel in my v6inv4
tunnel (nasty for latency, since both of my v6 tunnels travel some 2000+
miles before terminating at the tunnel brokers) and i'm still left with
the same problem that led me to NAT and number (and multihome) with v6 in
the first place:  i was too young to get a v4 allocation when they were
free, don't have barrels of cash laying around to get a proper v4
allocation, and those v4 addresses retail for around $10/each per month
these days.

>
> On Oct 16, 2005, at 4:41 PM, shogunx wrote:
>
> > Why tunnel v over v6?
> >
>
>

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/





From owner-v6ops@ops.ietf.org Mon Oct 17 11:35:58 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERX1p-0005LT-VK
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 11:35:58 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19680
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 11:35:50 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERX1E-0002tS-22
	for v6ops-data@psg.com; Mon, 17 Oct 2005 15:35:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERX1D-0002tG-F6
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 15:35:19 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 11:33:08 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 19:46:43 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERI9I-000OPU-AM
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:42:40 +0000
Received: from [24.227.114.150] (helo=sleekfreak.ath.cx)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERI9F-000OPB-1C
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:42:37 +0000
Received: from localhost ([127.0.0.1])
	by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian))
	id 1ERI9J-00011P-00; Sun, 16 Oct 2005 19:42:41 -0400
Date: Sun, 16 Oct 2005 19:42:41 -0400 (EDT)
From: shogunx <shogunx@sleekfreak.ath.cx>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
In-Reply-To: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.44.0510161942310.3866-100000@sleekfreak.ath.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 16 Oct 2005 23:46:43.0626 (UTC) FILETIME=[DCD738A0:01C5D2AB]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

that should read "v4 over v6"

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/






From owner-v6ops@ops.ietf.org Mon Oct 17 15:24:28 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERaay-0001lh-JO
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:24:28 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02308
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:24:21 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERaZY-000DYo-Qb
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:23:00 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERaZY-000DYZ-3M
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:23:00 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 15:22:01 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Oct 2005 08:45:14 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERUC6-000IQP-UV
	for v6ops-data@psg.com; Mon, 17 Oct 2005 12:34:22 +0000
Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERUC6-000IQC-Bl
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 12:34:22 +0000
Received: from sj-core-1.cisco.com ([171.71.177.237])
  by sj-iport-2.cisco.com with ESMTP; 17 Oct 2005 05:34:22 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144])
	by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9HCYFud005100;
	Mon, 17 Oct 2005 05:34:20 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 17 Oct 2005 05:34:08 -0700
Received: from [10.32.244.221] ([10.32.244.221]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	 Mon, 17 Oct 2005 05:34:08 -0700
In-Reply-To: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
References: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AC1FD12F-AD0B-4969-978A-347A4526034F@cisco.com>
Cc: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>,
        "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Date: Mon, 17 Oct 2005 05:34:07 -0700
To: shogunx <shogunx@sleekfreak.ath.cx>
X-Mailer: Apple Mail (2.734)
X-OriginalArrivalTime: 17 Oct 2005 12:34:08.0316 (UTC) FILETIME=[119D57C0:01C5D317]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

if you have a v6-only domain - and these already exist - and you want  
v4 to run over it, that's you're only option.

On Oct 16, 2005, at 4:41 PM, shogunx wrote:

> Why tunnel v over v6?
>





From owner-v6ops@ops.ietf.org Mon Oct 17 15:24:36 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERab6-0001mf-3F
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:24:36 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02314
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:24:28 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERaYf-000DUS-NN
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:22:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERaYe-000DUE-MS
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:22:04 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 15:21:52 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Oct 2005 04:01:46 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERPkn-000OyK-Q9
	for v6ops-data@psg.com; Mon, 17 Oct 2005 07:49:53 +0000
Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERPkk-000Oxq-8c
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 07:49:50 +0000
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id j9H7nh9v006171
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 08:49:44 +0100
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j9H7nhU13807
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 08:49:43 +0100
Date: Mon, 17 Oct 2005 08:49:43 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Message-ID: <20051017074939.GA13256@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
X-OriginalArrivalTime: 17 Oct 2005 08:01:46.0869 (UTC) FILETIME=[055A6A50:01C5D2F1]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Sun, Oct 16, 2005 at 07:10:47PM -0400, Durand, Alain wrote:
>  
> d) 6over4 as a transition mechanism isn't used much, it might be simpler to just suggest to
>     either deprecate it or rename it, then restoring the original "foo over bar" terminology
>     as semantically equivalent to "foo in far".

I have not seen any active use of 6over4.   Given the huge (and potentially
confusing) pool of transition/integration solutions already on the table, 
we should consider deprecating it.

Tim





From owner-v6ops@ops.ietf.org Mon Oct 17 15:26:20 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERacl-00024n-TW
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:26:20 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02365
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:26:12 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERacc-000DrN-R3
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:26:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERacc-000Dr5-4B
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:26:10 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 15:23:12 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 18:06:28 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERGVJ-000IVJ-SB
	for v6ops-data@psg.com; Sun, 16 Oct 2005 21:57:17 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERGVG-000IV2-Dz
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 21:57:14 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343322.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 00:01:59 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Sun, 16 Oct 2005 23:56:31 +0200
Subject: Re: Time to put together an agenda
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: Fred Baker <fred@cisco.com>, "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
CC: Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
Message-ID: <BF78992F.1348F8%jordi.palet@consulintel.es>
Thread-Topic: Time to put together an agenda
Thread-Index: AcXSnHdotb8Pfj6PEdqQXQAKldLC/g==
In-Reply-To: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-OriginalArrivalTime: 16 Oct 2005 22:06:28.0349 (UTC) FILETIME=[DB74CAD0:01C5D29D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

I will like to have a few minutes to talk about
draft-palet-v6ops-6in4-vs-6over4-00.txt.

The goal is to move it forward as an Informational WG item.

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Wed, 12 Oct 2005 03:45:17 -0400
> Para: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> CC: Lindqvist Erik Kurt <kurtis@kurtis.pp.se>, David Kessens
> <david.kessens@nokia.com>
> Asunto: Time to put together an agenda
> 
> Who has a document that is new since we met in Paris and needs to
> discuss?
> 








From owner-v6ops@ops.ietf.org Mon Oct 17 15:35:13 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERalL-0003Zb-O8
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:35:13 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02790
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:35:04 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERaku-000EeC-P2
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:34:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERaku-000Edz-3A
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:34:44 +0000
Received: from sj-core-2.cisco.com ([171.71.177.254])
  by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 12:34:44 -0700
X-IronPort-AV: i="3.97,222,1125903600"; 
   d="scan'208"; a="353228576:sNHT190109428"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9HJYfJh015049;
	Mon, 17 Oct 2005 12:34:41 -0700 (PDT)
Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9HJjCfS031101;
	Mon, 17 Oct 2005 12:45:12 -0700
In-Reply-To: <BF78992F.1348F8%jordi.palet@consulintel.es>
References: <BF78992F.1348F8%jordi.palet@consulintel.es>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <B7F4897F-68F5-4187-9659-60F963B11A53@cisco.com>
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>,
        Kurt Erik Lindqvist <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
Content-Transfer-Encoding: 7bit
From: Fred Baker <fred@cisco.com>
Subject: Re: Time to put together an agenda
Date: Mon, 17 Oct 2005 12:34:39 -0700
To: jordi.palet@consulintel.es
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=537; t=1129578313; x=1130010513;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Time=20to=20put=20together=20an=20agenda|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Mon,=2017=20Oct=202005=2012=3A34=3A39=20-0700|
	Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20format=3Dflowed|
	Content-Transfer-Encoding:7bit;
	b=DusZXsOMoHDoed3EONQ2dYtZjKIzYhlofD7+nAdZPH63+vqvwrkRMlcvyJ/oxnJvnNhkqaNG
	egmKKhC59XbYQLXWJVfD7mBl7hQs1VkADoaWXQjRtThSJUM9m7ZSj8rJE58No/4L7KHKRkhNYCB
	Qm2tgTf2h6eK6EEinyPUnUJ8=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

ok

On Oct 16, 2005, at 2:56 PM, JORDI PALET MARTINEZ wrote:

> I will like to have a few minutes to talk about
> draft-palet-v6ops-6in4-vs-6over4-00.txt.
>
> The goal is to move it forward as an Informational WG item.
>
> Regards,
> Jordi
>
>
>
>
>
>> De: Fred Baker <fred@cisco.com>
>> Responder a: <owner-v6ops@ops.ietf.org>
>> Fecha: Wed, 12 Oct 2005 03:45:17 -0400
>> Para: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
>> CC: Lindqvist Erik Kurt <kurtis@kurtis.pp.se>, David Kessens
>> <david.kessens@nokia.com>
>> Asunto: Time to put together an agenda
>>
>> Who has a document that is new since we met in Paris and needs to
>> discuss?
>>
>>
>
>
>




From owner-v6ops@ops.ietf.org Mon Oct 17 15:38:21 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERaoP-0004Rj-8f
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:38:21 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02907
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:38:13 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERaoA-000F0J-QD
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:38:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [213.136.24.43] (helo=purgatory.unfix.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERao9-000Ezq-TV
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:38:06 +0000
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 6B0EC7F54;
	Mon, 17 Oct 2005 21:38:00 +0200 (CEST)
Subject: Re: Time to put together an agenda
From: Jeroen Massar <jeroen@unfix.org>
To: jordi.palet@consulintel.es
Cc: v6ops@ops.ietf.org
In-Reply-To: <BF78992F.1348F8%jordi.palet@consulintel.es>
References: <BF78992F.1348F8%jordi.palet@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-6fdwwWXtfQVIfr3UBZ9y"
Organization: Unfix
Date: Mon, 17 Oct 2005 21:37:56 +0200
Message-Id: <1129577877.24798.55.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-6fdwwWXtfQVIfr3UBZ9y
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

[snipped cc list]

On Sun, 2005-10-16 at 23:56 +0200, JORDI PALET MARTINEZ wrote:
> I will like to have a few minutes to talk about
> draft-palet-v6ops-6in4-vs-6over4-00.txt.

Is there a URL for this? It's not at:
http://www.ietf.org/internet-drafts/draft-palet-v6ops-6in4-vs-6over4-00.txt

and even Google doesn't know of the existence!?

Greets,
 Jeroen


--=-6fdwwWXtfQVIfr3UBZ9y
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBDU/2UKaooUjM+fCMRAoJJAJ4ra2WNNLG1riLmiTWJOP//BtJX7ACgsZ5+
iJq+i4Yl8t+xiQU99EX0QAY=
=lpfs
-----END PGP SIGNATURE-----

--=-6fdwwWXtfQVIfr3UBZ9y--





From owner-v6ops@ops.ietf.org Mon Oct 17 15:42:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERash-0005UV-CQ
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:42:47 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03092
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:42:39 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERasH-000FUL-U2
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:42:21 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 
	autolearn=unavailable version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERasH-000FU4-8g
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:42:21 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 15:31:15 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Mon, 17 Oct 2005 05:27:43 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERRBv-0007HO-AS
	for v6ops-data@psg.com; Mon, 17 Oct 2005 09:21:59 +0000
Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERRBu-0007H7-9P
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 09:21:58 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ERRBs-0000QB-9v; Mon, 17 Oct 2005 10:21:56 +0100
Message-ID: <43536D8B.2070802@dial.pipex.com>
Date: Mon, 17 Oct 2005 10:23:23 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, Cedric Aoun <cedaoun@yahoo.fr>
Subject: New version of draft-ietf-v6ops-natpt-to-expermentl(-02)
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 17 Oct 2005 09:27:43.0988 (UTC) FILETIME=[073C5340:01C5D2FD]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

This draft is taking part in a new experiment designed to speed up 
publication after approval.

The draft is being copy edited by the RFC Editor in advance of IETF Last 
Call and submission to the IESG so that
- delays after approval are minimised by parellelising the copy 
editing/community review process
- the text which is reviewed and approved is essentially the text that 
is published rather than a copy edited version, so minimising the chance 
that the copy editing inadvertently changes the technical meaning

In the process of getting the document into this process we discovered 
that four of the references were in fact not referenced in the text 
(thanks to a more recent version of xml2rfc!).
It turns out that three of them are left over references from an early 
version of the document that shouldn't be in the
document at all: RFC3095, RFC 3574, I-D.durand-v6ops-dualstack-vs-natpt.
There ought to be a reference to the fourth one, RFC3484 (default 
address selection),  in the second  paragraph of s4.1.

This mistake has been corrected and  we have taken the chance to update 
Cedric Aoun's contact details: the updated version (-02) will be 
available in the I-D database shortly.

The copy edited document will be published probably in about a week's 
time and will be the one that is submitted for IETF last call (althoug 
it is itself informational, it affects a standards track document).

Regards,
Elwyn





From owner-v6ops@ops.ietf.org Mon Oct 17 15:50:34 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERb0D-0006yw-Vw
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:50:34 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03568
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:50:25 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERazm-000GH2-Mf
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:50:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERazl-000GGh-Qk
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:50:06 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ERazi-0005KN-HK; Mon, 17 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-natpt-to-exprmntl-02.txt 
Message-Id: <E1ERazi-0005KN-HK@newodin.ietf.org>
Date: Mon, 17 Oct 2005 15:50:02 -0400
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		: Reasons to Move NAT-PT to Experimental
	Author(s)	: C. Aoun, E. Davies
	Filename	: draft-ietf-v6ops-natpt-to-exprmntl-02.txt
	Pages		: 25
	Date		: 2005-10-17
	
This document discusses issues with the specific form of IPv6-IPv4
   protocol translation mechanism implemented by the Network Address
   Translator - Protocol Translator (NAT-PT) defined in RFC 2766.  These
   issues are sufficiently serious that recommending RFC 2766 as a
   general purpose transition mechanism is no longer desirable, and this
   document recommends that the IETF should reclassify RFC 2766 from
   Standards Track to Experimental status.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-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-natpt-to-exprmntl-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-natpt-to-exprmntl-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-natpt-to-exprmntl-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org Mon Oct 17 15:50:39 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERb0J-00070E-RK
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 15:50:39 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03575
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 15:50:32 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERazq-000GHQ-ES
	for v6ops-data@psg.com; Mon, 17 Oct 2005 19:50:10 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERazo-000GH9-Sb
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 19:50:09 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ERazi-0005Jy-Cc; Mon, 17 Oct 2005 15:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt 
Message-Id: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
Date: Mon, 17 Oct 2005 15:50:02 -0400
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		: Best Current Practice for Filtering ICMPv6 Messages in Firewalls
	Author(s)	: E. Davies, J. Mohacsi
	Filename	: draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
	Pages		: 27
	Date		: 2005-10-17
	
   In networks supporting IPv6 the Internet Control Message Protocol
   version 6 (ICMPv6) plays a fundamental role with a large number of
   functions, and a correspondingly large number of message types and
   options.  A number of security risks are associated with uncontrolled
   forwarding of ICMPv6 messages.  On the other hand, compared with IPv4
   and the corresponding protocol ICMP, ICMPv6 is essential to the
   functioning of IPv6 rather than a useful auxiliary.

   This document provides some recommendations for ICMPv6 firewall
   filter configuration that will allow propagation of ICMPv6 messages
   that are needed to maintain the functioning of the network but drop
   messages which are potential security risks.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.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-icmpv6-filtering-bcp-00.txt".

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org Mon Oct 17 16:03:51 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERbD5-0002BQ-0i
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:03:51 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05723
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 16:03:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERbCP-000HnZ-3B
	for v6ops-data@psg.com; Mon, 17 Oct 2005 20:03:09 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40,
	HTML_MESSAGE autolearn=ham version=3.1.0
Received: from [171.68.227.75] (helo=av-tac-sj.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERbCM-000Hn9-LV
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 20:03:06 +0000
X-TACSUNS: Virus Scanned
Received: from fire.cisco.com (localhost [127.0.0.1])
	by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9HK36621368
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 13:03:06 -0700 (PDT)
Received: from sasad-w2k01.cisco.com (sasad-w2k01.cisco.com [64.101.144.244])
	by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9HK35103034;
	Mon, 17 Oct 2005 13:03:05 -0700 (PDT)
Message-Id: <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
X-Sender: sasad@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 17 Oct 2005 13:03:04 -0700
To: Fred Baker <fred@cisco.com>
From: Salman Asadullah <sasad@cisco.com>
Subject: Re: Time to put together an agenda
Cc: v6ops@ops.ietf.org
In-Reply-To: <434D4633.601@dial.pipex.com>
References: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
 <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_17958052==_.ALT"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--=====================_17958052==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hello Fred,

We are going to be publishing the -04 version of the 
"draft-ietf-v6ops-bb-deployment-scenarios" shortly.

This new version is based on some feedback from Alain and Kurt.

The draft and its progress were presented in IETF 61, 62 and 63.

Do you see a need to provide an update to the wg for this work in next 
meeting ?

Regards,
Salman



>Fred Baker wrote:
>
>>Who has a document that is new since we met in Paris and needs to
>>discuss?

--=====================_17958052==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Hello Fred,<br>
<br>
We are going to be publishing the -04 version of the
&quot;draft-ietf-v6ops-bb-deployment-scenarios&quot; shortly.<br>
<br>
This new version is based on some feedback from Alain and Kurt.<br>
<br>
The draft and its progress were presented in IETF 61, 62 and 63.<br>
<br>
Do you see a need to provide an update to the wg for this work in next
meeting ?<br>
<br>
Regards,<br>
Salman<br>
<br>
<br>
<br>
<blockquote type=cite cite>Fred Baker wrote:<br>
<br>
<blockquote type=cite cite>Who has a document that is new since we met in
Paris and needs to  <br>
discuss?<br>
</font></blockquote></blockquote></html>

--=====================_17958052==_.ALT--





From owner-v6ops@ops.ietf.org Mon Oct 17 16:07:50 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERbGw-0004c4-Hl
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:07:50 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07462
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 16:07:42 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERbGl-000IPG-Ou
	for v6ops-data@psg.com; Mon, 17 Oct 2005 20:07:39 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERbGk-000IOn-NP
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 20:07:38 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001346425.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 22:10:10 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Mon, 17 Oct 2005 22:04:29 +0200
Subject: Re: Time to put together an agenda
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF79D06D.1350DB%jordi.palet@consulintel.es>
Thread-Topic: Time to put together an agenda
Thread-Index: AcXTVfsyOZfMJj9JEdqiqQAKldLC/g==
In-Reply-To: <1129577877.24798.55.camel@firenze.zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Mon, 17 Oct 2005 22:11:27 +0200
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Jeroen,

I've attached it in a previous email yesterday to v6ops, until the deadline
queue is emptied ... Anyway is also available at:

http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-6in4-vs-6over4-00.
txt

Regards,
Jordi




> De: Jeroen Massar <jeroen@unfix.org>
> Organizaci=F3n: Unfix
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 17 Oct 2005 21:37:56 +0200
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: Time to put together an agenda
>=20
> [snipped cc list]
>=20
> On Sun, 2005-10-16 at 23:56 +0200, JORDI PALET MARTINEZ wrote:
>> I will like to have a few minutes to talk about
>> draft-palet-v6ops-6in4-vs-6over4-00.txt.
>=20
> Is there a URL for this? It's not at:
> http://www.ietf.org/internet-drafts/draft-palet-v6ops-6in4-vs-6over4-00.txt
>=20
> and even Google doesn't know of the existence!?
>=20
> Greets,
>  Jeroen
>=20




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

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







From owner-v6ops@ops.ietf.org Mon Oct 17 16:13:27 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERbMN-00089X-Nc
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:13:27 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09716
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 16:13:20 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERbLy-000J54-A0
	for v6ops-data@psg.com; Mon, 17 Oct 2005 20:13:02 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERbLx-000J4g-Dh
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 20:13:01 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 16:10:54 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 19:46:51 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERI9T-000OPy-B2
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:42:51 +0000
Received: from [24.227.114.150] (helo=sleekfreak.ath.cx)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERI9H-000OPN-UC
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:42:40 +0000
Received: from localhost ([127.0.0.1])
	by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian))
	id 1ERI8U-00011N-00; Sun, 16 Oct 2005 19:41:50 -0400
Date: Sun, 16 Oct 2005 19:41:45 -0400 (EDT)
From: shogunx <shogunx@sleekfreak.ath.cx>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
In-Reply-To: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.44.0510161941290.3866-100000@sleekfreak.ath.cx>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-OriginalArrivalTime: 16 Oct 2005 23:46:51.0658 (UTC) FILETIME=[E1A0CEA0:01C5D2AB]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Fred,

Why tunnel v over v6?

Scott


On Sun, 16 Oct 2005, JORDI PALET MARTINEZ wrote:

> Clue accepted ;-)
>
> A new document has been submitted (attached for those that want to start
> commenting already).
>
> Regards,
> Jordi
>
>
>
>
> > De: Fred Baker <fred@cisco.com>
> > Responder a: <owner-v6ops@ops.ietf.org>
> > Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> > Para: <jordi.palet@consulintel.es>
> > CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> > Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> >
> > On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
> >> Overall, agree with your conclusions about 3.3, but I think there
> >> is one more scenario, which is the one that we are facing, and
> >> seems to me the right way to go, actually the natural one, being
> >> deployed with some of our customers.
> >>
> >>       ,---.                                                  ,---.
> >>      /     \                                                /     \
> >>     /       \                                              /       \
> >>    ; IPv4+6  :                                            ; IPv4+6  :
> >>    | Network |                                            | Network |
> >>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
> >>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
> >>      \    +----+     +----+       \   /      +----+     +----+    /
> >>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
> >>             | Network+----+   +    | |    +  +----+Network |
> >>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
> >>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
> >>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
> >>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
> >>    | Network |                                            | Network |
> >>    :         ;                                            :         ;
> >>     \       /                                              \       /
> >>      \     /                                                \     /
> >>       `---'                                                  `---'
> >>
> >> Network A and D are IPv6-only, with GW-A and GW-B taking care of
> >> the v4-in-v6 tunneling, automatically.
> >
> > There are certainly cases in which a consistent transition strategy
> > is being followed and is working. I think I said something in the
> > document about granting that the use of a single consistent strategy
> > that works will probably work :^).
> >
> > What I am concerned about is the proliferation of inconsistent
> > strategies, and the set of cases I can come up with in which they do
> > not work. That is the issue I am trying to raise.
> >
> >> One more comment. I've discovered a lot of confusion in several
> >> documents regarding 6over4 and 6in4, which is being followed by
> >> confusing documents from vendors. I think is very important to make
> >> a general recommendation, may be not just to this WG, but in
> >> general to all the IETF documents which mention tunneling, to
> >> clearly make a distinction between both mechanisms, probably
> >> avoiding using "over" when actually is referring 6in4
> >> encapsulation. Not sure if this should be raised at IESG level or
> >> whatever. What do you think ?
> >
> > What you expect clue? :^)
> >
> > Yes, it would be good if people would say clueful things in a clueful
> > way. There is probably room for an internet draft on the subject.
> >
>
>

sleekfreak pirate broadcast
http://sleekfreak.ath.cx:81/






From owner-v6ops@ops.ietf.org Mon Oct 17 16:24:26 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERbX0-0007SP-Jo
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:24:26 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15034
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 16:24:18 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERbVg-000K8z-8o
	for v6ops-data@psg.com; Mon, 17 Oct 2005 20:23:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERbVf-000K8S-Cj
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 20:23:03 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 16:22:09 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 19:16:58 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERHew-000MkT-31
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:11:18 +0000
Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERHes-000MkF-Kk
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:11:14 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Date: Sun, 16 Oct 2005 19:10:47 -0400
Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/gACQSf/
From: "Durand, Alain" <Alain_Durand@cable.comcast.com>
To: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 16 Oct 2005 23:10:48.0418 (UTC) FILETIME=[D83C9420:01C5D2A6]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Few comments:
=20
a) I have seen much more confusion with 6to4 that with anything else. =
Most people think of it
    as NAT IPv6 -> IPv4.
=20
b) Many other encapsulation exists, not just v6/v4 & friends. The jargon =
"over" is used very widely,
    like ATM over Sonnet, and, for instance, many of the documents in =
the Int area can be described
    as "IP over foo". So creating a new jargon for just IPvx over IPvy =
may introduce even more
    confusion.
=20
c)  More, asking all the standard bodies that used "foo over bar" =
terminology to
    change to "foo in bar" just because there is a little use IETF =
protocol named "6over4"
    does not sound very realistic.
=20
d) 6over4 as a transition mechanism isn't used much, it might be simpler =
to just suggest to
    either deprecate it or rename it, then restoring the original "foo =
over bar" terminology
    as semantically equivalent to "foo in far".
=20
   - Alain.

________________________________

From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
Sent: Sun 10/16/2005 5:54 PM
To: v6ops@ops.ietf.org
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt



Clue accepted ;-)

A new document has been submitted (attached for those that want to start
commenting already).

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>
> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>> Overall, agree with your conclusions about 3.3, but I think there
>> is one more scenario, which is the one that we are facing, and
>> seems to me the right way to go, actually the natural one, being
>> deployed with some of our customers.
>>
>>       ,---.                                                  ,---.
>>      /     \                                                /     \
>>     /       \                                              /       \
>>    ; IPv4+6  :                                            ; IPv4+6  :
>>    | Network |                                            | Network |
>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>      \    +----+     +----+       \   /      +----+     +----+    /
>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>             | Network+----+   +    | |    +  +----+Network |
>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>    | Network |                                            | Network |
>>    :         ;                                            :         ;
>>     \       /                                              \       /
>>      \     /                                                \     /
>>       `---'                                                  `---'
>>
>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>> the v4-in-v6 tunneling, automatically.
>
> There are certainly cases in which a consistent transition strategy
> is being followed and is working. I think I said something in the
> document about granting that the use of a single consistent strategy
> that works will probably work :^).
>
> What I am concerned about is the proliferation of inconsistent
> strategies, and the set of cases I can come up with in which they do
> not work. That is the issue I am trying to raise.
>
>> One more comment. I've discovered a lot of confusion in several
>> documents regarding 6over4 and 6in4, which is being followed by
>> confusing documents from vendors. I think is very important to make
>> a general recommendation, may be not just to this WG, but in
>> general to all the IETF documents which mention tunneling, to
>> clearly make a distinction between both mechanisms, probably
>> avoiding using "over" when actually is referring 6in4
>> encapsulation. Not sure if this should be raised at IESG level or
>> whatever. What do you think ?
>
> What you expect clue? :^)
>
> Yes, it would be good if people would say clueful things in a clueful
> way. There is probably room for an internet draft on the subject.
>








From owner-v6ops@ops.ietf.org Mon Oct 17 16:32:16 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERbea-00055L-GV
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 16:32:16 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19166
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 16:32:08 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERbe9-000L2i-DJ
	for v6ops-data@psg.com; Mon, 17 Oct 2005 20:31:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERbe8-000L2K-II
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 20:31:48 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 16:24:01 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 19:48:44 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERIBP-000OYN-Ar
	for v6ops-data@psg.com; Sun, 16 Oct 2005 23:44:51 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERIBL-000OXp-SC
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 23:44:48 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343398.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 01:49:36 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Mon, 17 Oct 2005 01:40:09 +0200
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF78B179.134994%jordi.palet@consulintel.es>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/gACQSf/AAFraKQ=
In-Reply-To: <6EEEACD9D7F52940BEE26F5467C02C7302217955@PACDCEXCMB01.cable.comcast.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-OriginalArrivalTime: 16 Oct 2005 23:48:44.0319 (UTC) FILETIME=[24C782F0:01C5D2AC]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Alain,

The point is not only the IETF docs ... Is more all the vendor documents an=
d
operational guidelines.

So, if we decide to rename 6over4 (6overm4, for example), we still need to
have a document that says 6in4=3D6over4 from now on.

I was referring only to 6in4, 4in6, not foo over bar, but in any case, I'm
not absolutely sure if we really need to modify the IETF documents as I
indicate in this document, or if just the document itself is enough
clarification and must reinforce the change for any new publications
(specially for vendor documents, etc.).

Regards,
Jordi




> De: "Durand, Alain" <Alain_Durand@cable.comcast.com>
> Responder a: <alain_durand@cable.comcast.com>
> Fecha: Sun, 16 Oct 2005 19:10:47 -0400
> Para: <jordi.palet@consulintel.es>, <v6ops@ops.ietf.org>
> Conversaci=F3n: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> Asunto: RE: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>=20
> Few comments:
> =20
> a) I have seen much more confusion with 6to4 that with anything else. Mos=
t
> people think of it
>     as NAT IPv6 -> IPv4.
> =20
> b) Many other encapsulation exists, not just v6/v4 & friends. The jargon
> "over" is used very widely,
>     like ATM over Sonnet, and, for instance, many of the documents in the=
 Int
> area can be described
>     as "IP over foo". So creating a new jargon for just IPvx over IPvy ma=
y
> introduce even more
>     confusion.
> =20
> c)  More, asking all the standard bodies that used "foo over bar" termino=
logy
> to
>     change to "foo in bar" just because there is a little use IETF protoc=
ol
> named "6over4"
>     does not sound very realistic.
> =20
> d) 6over4 as a transition mechanism isn't used much, it might be simpler =
to
> just suggest to
>     either deprecate it or rename it, then restoring the original "foo ov=
er
> bar" terminology
>     as semantically equivalent to "foo in far".
> =20
>    - Alain.
>=20
> ________________________________
>=20
> From: owner-v6ops@ops.ietf.org on behalf of JORDI PALET MARTINEZ
> Sent: Sun 10/16/2005 5:54 PM
> To: v6ops@ops.ietf.org
> Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>=20
>=20
>=20
> Clue accepted ;-)
>=20
> A new document has been submitted (attached for those that want to start
> commenting already).
>=20
> Regards,
> Jordi
>=20
>=20
>=20
>=20
>> De: Fred Baker <fred@cisco.com>
>> Responder a: <owner-v6ops@ops.ietf.org>
>> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
>> Para: <jordi.palet@consulintel.es>
>> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
>> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
>>=20
>> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>>> Overall, agree with your conclusions about 3.3, but I think there
>>> is one more scenario, which is the one that we are facing, and
>>> seems to me the right way to go, actually the natural one, being
>>> deployed with some of our customers.
>>>=20
>>>       ,---.                                                  ,---.
>>>      /     \                                                /     \
>>>     /       \                                              /       \
>>>    ; IPv4+6  :                                            ; IPv4+6  :
>>>    | Network |                                            | Network |
>>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>>      \    +----+     +----+       \   /      +----+     +----+    /
>>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>>             | Network+----+   +    | |    +  +----+Network |
>>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>>    | Network |                                            | Network |
>>>    :         ;                                            :         ;
>>>     \       /                                              \       /
>>>      \     /                                                \     /
>>>       `---'                                                  `---'
>>>=20
>>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>>> the v4-in-v6 tunneling, automatically.
>>=20
>> There are certainly cases in which a consistent transition strategy
>> is being followed and is working. I think I said something in the
>> document about granting that the use of a single consistent strategy
>> that works will probably work :^).
>>=20
>> What I am concerned about is the proliferation of inconsistent
>> strategies, and the set of cases I can come up with in which they do
>> not work. That is the issue I am trying to raise.
>>=20
>>> One more comment. I've discovered a lot of confusion in several
>>> documents regarding 6over4 and 6in4, which is being followed by
>>> confusing documents from vendors. I think is very important to make
>>> a general recommendation, may be not just to this WG, but in
>>> general to all the IETF documents which mention tunneling, to
>>> clearly make a distinction between both mechanisms, probably
>>> avoiding using "over" when actually is referring 6in4
>>> encapsulation. Not sure if this should be raised at IESG level or
>>> whatever. What do you think ?
>>=20
>> What you expect clue? :^)
>>=20
>> Yes, it would be good if people would say clueful things in a clueful
>> way. There is probably room for an internet draft on the subject.
>>=20
>=20
>=20
>=20








From owner-v6ops@ops.ietf.org Mon Oct 17 17:21:31 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERcQF-0000zH-Kh
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 17:21:31 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06565
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 17:21:23 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERcPX-000Nzk-8w
	for v6ops-data@psg.com; Mon, 17 Oct 2005 21:20:47 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERcPV-000NzK-Nb
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 21:20:45 +0000
Received: from mail pickup service by mail.flarion.com with Microsoft SMTPSVC;
	 Mon, 17 Oct 2005 17:18:26 -0400
Received: from psg.com ([147.28.0.62]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713);
	 Sun, 16 Oct 2005 18:06:35 -0400
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERGTX-000IQi-05
	for v6ops-data@psg.com; Sun, 16 Oct 2005 21:55:27 +0000
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERGTT-000IQN-4n
	for v6ops@ops.ietf.org; Sun, 16 Oct 2005 21:55:23 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001343321.msg
	for <v6ops@ops.ietf.org>; Mon, 17 Oct 2005 00:00:09 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Sun, 16 Oct 2005 23:54:57 +0200
Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF7898D2.1348F6%jordi.palet@consulintel.es>
Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
Thread-Index: AcXSnD9hfdqoZj6PEdqQXQAKldLC/g==
In-Reply-To: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com>
Mime-version: 1.0
Content-type: multipart/mixed;
	boundary="B_3212351708_6739812"
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-OriginalArrivalTime: 16 Oct 2005 22:06:35.0380 (UTC) FILETIME=[DFA5A340:01C5D29D]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

>Este mensaje tiene formato MIME. Al no reconocer su lector de
correo este formato, puede que todo o parte del mensaje resulte ilegible.

--B_3212351708_6739812
Content-type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Clue accepted ;-)

A new document has been submitted (attached for those that want to start
commenting already).

Regards,
Jordi




> De: Fred Baker <fred@cisco.com>
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Mon, 15 Aug 2005 14:47:02 -0700
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt
> 
> On Aug 15, 2005, at 2:25 PM, JORDI PALET MARTINEZ wrote:
>> Overall, agree with your conclusions about 3.3, but I think there
>> is one more scenario, which is the one that we are facing, and
>> seems to me the right way to go, actually the natural one, being
>> deployed with some of our customers.
>> 
>>       ,---.                                                  ,---.
>>      /     \                                                /     \
>>     /       \                                              /       \
>>    ; IPv4+6  :                                            ; IPv4+6  :
>>    | Network |                                            | Network |
>>    :      +----+---.        ,---.       ,---.       ,---+----+      ;
>>     \     |GW-A|    \      /     \     /     \     /    |GW-D|     /
>>      \    +----+     +----+       \   /      +----+     +----+    /
>>       `---' ;  IPv6  |GW-B| IPv4   : ;  IPv4 |GW-C| IPv6   : `---'
>>             | Network+----+   +    | |    +  +----+Network |
>>       ,---. :Transition  :  IPv6   : :  IPv6  ,---.
>>      /     +----+A   /    \   B   /   \   C   /   \   D+----+     \
>>     /      |GW-A|   /      \     /     \     /     \   |GW-D|      \
>>    ; IPv4+6+----+--'        `---'       `---'       `--+----+IPv4+6 :
>>    | Network |                                            | Network |
>>    :         ;                                            :         ;
>>     \       /                                              \       /
>>      \     /                                                \     /
>>       `---'                                                  `---'
>> 
>> Network A and D are IPv6-only, with GW-A and GW-B taking care of
>> the v4-in-v6 tunneling, automatically.
> 
> There are certainly cases in which a consistent transition strategy
> is being followed and is working. I think I said something in the
> document about granting that the use of a single consistent strategy
> that works will probably work :^).
> 
> What I am concerned about is the proliferation of inconsistent
> strategies, and the set of cases I can come up with in which they do
> not work. That is the issue I am trying to raise.
> 
>> One more comment. I've discovered a lot of confusion in several
>> documents regarding 6over4 and 6in4, which is being followed by
>> confusing documents from vendors. I think is very important to make
>> a general recommendation, may be not just to this WG, but in
>> general to all the IETF documents which mention tunneling, to
>> clearly make a distinction between both mechanisms, probably
>> avoiding using "over" when actually is referring 6in4
>> encapsulation. Not sure if this should be raised at IESG level or
>> whatever. What do you think ?
> 
> What you expect clue? :^)
> 
> Yes, it would be good if people would say clueful things in a clueful
> way. There is probably room for an internet draft on the subject.
> 


--B_3212351708_6739812
Content-type: text/plain; name="draft-palet-v6ops-6in4-vs-6over4-00.txt";
 x-mac-creator="74657874";
 x-mac-type="54455854"
Content-disposition: attachment;
	filename="draft-palet-v6ops-6in4-vs-6over4-00.txt"
Content-Transfer-Encoding: base64

CgoKCkludGVybmV0IEVuZ2luZWVyaW5nIFRhc2sgRm9yY2UgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICBKLiBQYWxldApJbnRlcm5ldC1EcmFmdCAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgQ29uc3VsaW50ZWwKRXhwaXJlczogQXBy
aWwgMTksIDIwMDYgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBPY3RvYmVyIDE2
LCAyMDA1CgoKICAgICAgICAgICAgICAgICAgICAgNmluNCB2ZXJzdXMgNm92ZXI0IHRlcm1p
bm9sb2d5CiAgICAgICAgICAgICAgICBkcmFmdC1wYWxldC12Nm9wcy02aW40LXZzLTZvdmVy
NC0wMC50eHQKClN0YXR1cyBvZiB0aGlzIE1lbW8KCiAgIEJ5IHN1Ym1pdHRpbmcgdGhpcyBJ
bnRlcm5ldC1EcmFmdCwgZWFjaCBhdXRob3IgcmVwcmVzZW50cyB0aGF0IGFueQogICBhcHBs
aWNhYmxlIHBhdGVudCBvciBvdGhlciBJUFIgY2xhaW1zIG9mIHdoaWNoIGhlIG9yIHNoZSBp
cyBhd2FyZQogICBoYXZlIGJlZW4gb3Igd2lsbCBiZSBkaXNjbG9zZWQsIGFuZCBhbnkgb2Yg
d2hpY2ggaGUgb3Igc2hlIGJlY29tZXMKICAgYXdhcmUgd2lsbCBiZSBkaXNjbG9zZWQsIGlu
IGFjY29yZGFuY2Ugd2l0aCBTZWN0aW9uIDYgb2YgQkNQIDc5LgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSB3b3JraW5nIGRvY3VtZW50cyBvZiB0aGUgSW50ZXJuZXQgRW5naW5lZXJpbmcK
ICAgVGFzayBGb3JjZSAoSUVURiksIGl0cyBhcmVhcywgYW5kIGl0cyB3b3JraW5nIGdyb3Vw
cy4gIE5vdGUgdGhhdAogICBvdGhlciBncm91cHMgbWF5IGFsc28gZGlzdHJpYnV0ZSB3b3Jr
aW5nIGRvY3VtZW50cyBhcyBJbnRlcm5ldC0KICAgRHJhZnRzLgoKICAgSW50ZXJuZXQtRHJh
ZnRzIGFyZSBkcmFmdCBkb2N1bWVudHMgdmFsaWQgZm9yIGEgbWF4aW11bSBvZiBzaXggbW9u
dGhzCiAgIGFuZCBtYXkgYmUgdXBkYXRlZCwgcmVwbGFjZWQsIG9yIG9ic29sZXRlZCBieSBv
dGhlciBkb2N1bWVudHMgYXQgYW55CiAgIHRpbWUuICBJdCBpcyBpbmFwcHJvcHJpYXRlIHRv
IHVzZSBJbnRlcm5ldC1EcmFmdHMgYXMgcmVmZXJlbmNlCiAgIG1hdGVyaWFsIG9yIHRvIGNp
dGUgdGhlbSBvdGhlciB0aGFuIGFzICJ3b3JrIGluIHByb2dyZXNzLiIKCiAgIFRoZSBsaXN0
IG9mIGN1cnJlbnQgSW50ZXJuZXQtRHJhZnRzIGNhbiBiZSBhY2Nlc3NlZCBhdAogICBodHRw
Oi8vd3d3LmlldGYub3JnL2lldGYvMWlkLWFic3RyYWN0cy50eHQuCgogICBUaGUgbGlzdCBv
ZiBJbnRlcm5ldC1EcmFmdCBTaGFkb3cgRGlyZWN0b3JpZXMgY2FuIGJlIGFjY2Vzc2VkIGF0
CiAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwuCgogICBUaGlzIEludGVybmV0
LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEFwcmlsIDE5LCAyMDA2LgoKQ29weXJpZ2h0IE5vdGlj
ZQoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuCgpBYnN0
cmFjdAoKICAgVGhpcyBkb2N1bWVudCBjbGFyaWZpZXMgdGhlIGV4aXN0aW5nIHRlcm1pbm9s
b2d5IGNvbmZ1c2lvbiBhbW9uZwogICByZWZlcmVuY2VzIHRvIElQdjYvSVB2NCBlbmNhcHN1
bGF0aW9ucyBhbmQgSVB2NC9JUHY2IHRyYW5zaXRpb24KICAgbWVjaGFuaXNtcy4KCgoKCgoK
CgoKUGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAg
ICAgICAgICAgICAgIFtQYWdlIDFdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJz
dXMgNm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKVGFibGUgb2Yg
Q29udGVudHMKCiAgIDEuICBJbnRyb2R1Y3Rpb24gIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gMwogICAyLiAgRGVmaW5pdGlvbiBvZiAnaW4n
IGFuZCAnb3ZlcicgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDQKICAgMy4g
IENvbmNsdXNpb25zIGFuZCBGdXR1cmUgQ29uc2lzdGVuY3kgIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiA0CiAgIDQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucyAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICA1LiAgSUFOQSBDb25zaWRlcmF0
aW9ucyAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUKICAg
Ni4gIEFja25vd2xlZGdlbWVudHMgIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiA1CiAgIDcuICBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNQogICAgIDcuMS4gIE5vcm1hdGl2
ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIDUK
ICAgICA3LjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IC4gLiAuIC4gLiAuIC4gLiA2CiAgIEF1dGhvcidzIEFkZHJlc3MgIC4gLiAuIC4gLiAuIC4g
LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gNwogICBJbnRlbGxlY3R1YWwg
UHJvcGVydHkgYW5kIENvcHlyaWdodCBTdGF0ZW1lbnRzICAuIC4gLiAuIC4gLiAuIC4gLiAu
IDgKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgpQYWxldCAgICAgICAg
ICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNiAgICAgICAgICAgICAgICAgW1Bh
Z2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2aW40IHZlcnN1cyA2b3ZlcjQgdGVybWlu
b2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgoxLiAgSW50cm9kdWN0aW9uCgogICBBIG51
bWJlciBvZiBJRVRGIGRvY3VtZW50cyBoYXZlIHVzZWQgaW4gYW4gImludGVyY2hhbmdlYWJs
ZSIgd2F5CiAgIHNldmVyYWwgZXhwcmVzc2lvbnMgc3VjaCBhczoKCiAgIG8gIDZpbjQKCiAg
IG8gIDYtaW4tNAoKICAgbyAgSVB2Ni1pbi1JUHY0CgogICBvICBJUHY2IGluIElQdjQKCiAg
IG8gIDZvdmVyNAoKICAgbyAgNi1vdmVyLTQKCiAgIG8gIElQdjYtb3Zlci1JUHY0CgogICBv
ICBJUHY2IG92ZXIgSVB2NAoKICAgbyAgNGluNgoKICAgbyAgNC1pbi02CgogICBvICBJUHY0
LWluLUlQdjYKCiAgIG8gIElQdjQgaW4gSVB2NgoKICAgbyAgNG92ZXI2CgogICBvICA0LW92
ZXItNgoKICAgbyAgSVB2NC1vdmVyLUlQdjYKCiAgIG8gIElQdjQgb3ZlciBJUHY2CgogICBO
b3RlIHRoYXQgdGhpcyBsaXN0IGlzIG5vdCBleGhhdXN0aXZlIGFuZCBtYW55IG90aGVyIHNp
bWlsYXIKICAgZXhwcmVzc2lvbnMgbWF5IGJlIGFsc28gaW4gdXNlLiAgRm9yIGV4YW1wbGUs
IGluIHNvbWUgc2l0dWF0aW9ucwogICBvdGhlciBlbmNhcHN1bGF0aW5nIGxheWVycyBhcmUg
dXNlZCAoaS5lLiwgNi9VRFAvNCksIGFuZCBzaW1pbGFyCiAgIGV4cHJlc3Npb25zIGFyZSBi
ZWluZyB1c2VkLgoKICAgQXMgYSBjb25zZXF1ZW5jZSwgZG9jdW1lbnRzIGZyb20gdmVuZG9y
cywgcHJvZHVjdCBtYW51YWxzLAogICBwdWJsaWNhdGlvbnMsIHBhcGVycywgYm9va3MsIHR1
dG9yaWFscywgdHJhaW5pbmcgbWF0ZXJpYWwgYW5kIG1hbnkKICAgb3RoZXJzLCB1c2UgYWxz
byB0aG9zZSBleHByZXNzaW9ucy4KCiAgIEhvd2V2ZXIgbm90IGFsbCB0aG9zZSBkb2N1bWVu
dHMsIGluY2x1ZGluZyB0aGUgSUVURiBvbmVzLCBhcmUKICAgYWN0dWFsbHkgcmVmZXJyaW5n
IHRvIHRoZSBzYW1lIElQdjYvSVB2NCBlbmNhcHN1bGF0aW9ucyBvciBJUHY0L0lQdjYKCgoK
UGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAg
ICAgICAgICAgIFtQYWdlIDNdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJzdXMg
Nm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKICAgdHJhbnNpdGlv
biBtZWNoYW5pc21zLgoKICAgVGhlIHJlc3VsdCBvZiB0aGlzIHRlcm1pbm9sb2d5IGNvbmZ1
c2lvbiBpcyBhIG51bWJlciBvZiBlcnJvcnMgYW1vbmcKICAgdmVuZG9ycywgb3BlcmF0b3Jz
LCBlbmdpbmVlcnMgYW5kIHVzZXJzIHdoZW4gZGVzaWduaW5nIGFuZAogICBkb2N1bWVudGlu
ZyBwcm9kdWN0cywgb3Igd2hlbiBzZXR0aW5nIHVwIHRyYW5zaXRpb24gbWVjaGFuaXNtcywK
ICAgY3JlYXRpbmcgYXQgdGhlIGVuZCB1bm5lY2Vzc2FyeSBvcGVyYXRpb25hbCBjb3N0cywg
c3BlY2lhbGx5IGZvcgogICBiZWdpbm5lcnMgd2hpY2ggdHJ5IHRvIHNldHVwIElQdjYgZm9y
IHRoZWlyIGZpcnN0IG9jY2FzaW9ucy4KCgoyLiAgRGVmaW5pdGlvbiBvZiAnaW4nIGFuZCAn
b3ZlcicKCiAgIElQIGluIElQIFR1bm5lbGluZyB3YXMgZGVmaW5lZCBieSBbMV0uICBBZnRl
cndhcmRzIFsyXSwgb2Jzb2xldGVkIGJ5CiAgIFszXSwgZGVmaW5lcyB0aGUgYmFzaWMgSVB2
NC9JUHY2IHRyYW5zaXRpb24gbWVjaGFuaXNtcywgaW5jbHVkaW5nIHRoZQogICBlbmNhcHN1
bGF0aW9uIG9mIElQdjYgcGFja2V0cyBpbiBJUHY0IG9uZXMgKGJ5IG1lYW5zIG9mIHByb3Rv
Y29sIDQxKTsKICAgdGhpcyBkb2N1bWVudCBpcyBiZWluZyB1cGRhdGVkIGFzICJpZXRmLXY2
b3BzLW1lY2gtdjIiLgoKICAgU2ltaWxhcmx5LCBbNF0sIGRlZmluZXMgdGhlIGVuY2Fwc3Vs
YXRpb24gb2YgSVB2NCBwYWNrZXRzIGluIElQdjYKICAgb25lcy4KCiAgIEEgZmlyc3QgY29u
Y2x1c2lvbiBjYW4gYmUgZXh0cmFjdGVkIGZyb20gdGhpcyBkb2N1bWVudHMgKGV2ZW4gaWYg
c29tZQogICBvZiB0aGVtIGFjdHVhbGx5IHVzZSwgc29tZSB0aW1lcywgIm92ZXIiKTogVGhv
c2UgZW5jYXBzdWxhdGlvbgogICBtZWNoYW5pc21zIGFyZSB0aGUgb25lcyB0aGF0IHNob3Vs
ZCB1c2UgdGhlICJpbiIgdGVybWlub2xvZ3kuICBOb3RlCiAgIHRoYXQgdGhleSBhcmUganVz
dCBlbmNhcHN1bGF0aW9uIG1lY2hhbmlzbXMsIHdoaWNoIG9mdGVuIGFyZSB1c2VkIGJ5CiAg
IHNldmVyYWwgdHJhbnNpdGlvbiBtZWNoYW5pc21zLgoKICAgRnVydGhlcm1vcmUsIFs1XSBz
cGVjaWZ5IGEgdHJhbnNpdGlvbiBtZWNoYW5pc20sIHdoaWNoIHVzZXMgNmluNAogICAoZW5j
YXBzdWxhdGlvbiBvZiBJUHY2IHBhY2tldHMgaW4gSVB2NCBvbmVzKSwgY3JlYXRpbmcgYSB2
aXJ0dWFsIElQdjYKICAgbGluayBvdmVyIGFuIElQdjQgbXVsdGljYXN0IGluZnJhc3RydWN0
dXJlLiAgVGhpcyB0cmFuc2l0aW9uCiAgIG1lY2hhbmlzbSBpcyBuYW1lZCBhcyAiNm92ZXI0
Ii4KCiAgIENsZWFybHksICI2aW40IiBhbmQgIjZvdmVyNCIgYXJlIHF1aXRlIGRpZmZlcmVu
dCB0aGluZ3MsIGFjdHVhbGx5CiAgIDZvdmVyNCBpcyBhIHRyYW5zaXRpb24gbWVjaGFuaXNt
IHdoaWNoIHVzZXMgNmluNCBhcyB0aGUgcHJvY2VkdXJlIGZvcgogICBlbmNhcHN1bGF0aW5n
IElQdjYgcGFja2V0cyBpbiBJUHY0IG11bHRpY2FzdCBpbmZyYXN0cnVjdHVyZXMuCgogICBU
aGUgZmFjdCB0aGF0IHRoZXkgYXJlIGRpZmZlcmVudCB0aGluZ3MgYW5kIHNwZWNpYWxseSB0
aGUgcmVxdWlyZW1lbnQKICAgZm9yIGEgKElQdjQpIG11bHRpY2FzdCBpbmZyYXN0cnVjdHVy
ZSBmb3IgNm92ZXI0LCBtYWtlcyBuZWNlc3NhcnkgdG8KICAgY2xhcmlmeSB0aGUgZGlmZmVy
ZW5jZSBhbmQgYXZvaWQgY29uZnVzaW9ucyBhbW9uZyBib3RoLgoKICAgRW5naW5lZXJzIG9w
ZXJhdGluZyBuZXR3b3JrcyBhbmQgdGhlaXIgY3VzdG9tZXJzIChmb3IgZXhhbXBsZSB3aGVu
CiAgIHNldHRpbmcgdXAgdHVubmVscyksIG9mdGVuIGRvIG5vdCByZWFkIGFsbCB0aGUgSUVU
RiBkb2N1bWVudHMsIHNvCiAgIHRoZXkgY291bGQgZWFzaWx5IG1pc3VuZGVyc3RhbmQgaWYg
YSB0dW5uZWwgaXMgIjZvdmVyNCIgb3IgIjZpbjQiCiAgIChzcGVjaWFsbHkgd2hlbiB2ZW5k
b3IgZG9jdW1lbnRzIHVzZSBib3RoIHRlcm1zIHRvIGFjdHVhbGx5IG5hbWUKICAgIjZpbjQi
LCBwb3NzaWJseSBiZWNhdXNlIHRoZSBtaXN1c2FnZSBvZiB0aG9zZSB0ZXJtcyBpbiBbMl0s
IFszXSksCiAgIGFuZCB0aGlzIGNyZWF0ZXMgc29tZSBleHRyYSB0cm91Ymxlc2hvb3Rpbmcg
dGltZSBhbmQgY29uZnVzaW9uLgoKCjMuICBDb25jbHVzaW9ucyBhbmQgRnV0dXJlIENvbnNp
c3RlbmN5CgoKCgpQYWxldCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwg
MjAwNiAgICAgICAgICAgICAgICAgW1BhZ2UgNF0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2
aW40IHZlcnN1cyA2b3ZlcjQgdGVybWlub2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgog
ICBJbiBvcmRlciB0byBhdm9pZCB0aGlzIGtpbmQgb2YgY29uZnVzaW9uLCBpdCBzaG91bGQg
YmUgdW5kZXJzdG9vZCB0aGUKICAgZGlmZmVyZW5jZSBiZXR3ZWVuIDZvdmVyNCBhbmQgNmlu
NCAoYW5kIGFueSBvdGhlciBlcXVpdmFsZW50CiAgIHRlcm1pbm9sb2dpZXMpLCBhbmQgZnV0
dXJlIGRvY3VtZW50cyAoaW5jbHVkaW5nIElFVEYgb25lcykgbXVzdCB0YWtlCiAgIHRoaXMg
aW4gY29uc2lkZXJhdGlvbiB3aGVuIHJlcHVibGlzaGVkLgoKICAgTW9yZW92ZXIsIG5ldyBk
b2N1bWVudHMgd2hpY2ggZGVzY3JpYmUgb3RoZXIgZW5jYXBzdWxhdGlvbnMgYW5kCiAgIHBy
b3RvY29scywgc3VjaCBhcyBJUHY0IGluIElQdjYsIElQdjYgaW4gVURQL0lQdjQsIElQdjYg
aW4gSVB2NiwgbXVzdAogICBhbHNvIHVzZSwgZm9yIGNvbnNpc3RlbmN5IHJlYXNvbnMsICJp
biIgaW5zdGVhZCBvZiAib3ZlciIuCgogICBJdCBpcyByZWNvbW1lbmRlZCB0aGF0IGFueSBl
eGlzdGluZyBkb2N1bWVudHMgYXJlIGFtZW5kZWQgQVNBUCB0bwogICBhdm9pZCB0aGUgZXhp
c3RpbmcgY29uZnVzaW9uLgoKCjQuICBTZWN1cml0eSBDb25zaWRlcmF0aW9ucwoKICAgVGhp
cyBkb2N1bWVudCBkb2VzIG5vdCBoYXZlIGFueSBwcm90b2NvbC1yZWxhdGVkIHNlY3VyaXR5
CiAgIGNvbnNpZGVyYXRpb25zLgoKCjUuICBJQU5BIENvbnNpZGVyYXRpb25zCgogICBUaGlz
IGRvY3VtZW50IGRvZXMgbm90IGhhdmUgYW55IHNwZWNpZmljIElBTkEgY29uc2lkZXJhdGlv
bnMuCgoKNi4gIEFja25vd2xlZGdlbWVudHMKCiAgIFRoZSBhdXRob3Igd291bGQgbGlrZSB0
byBhY2tub3dsZWRnZSB0aGUgaW5wdXRzIG9mIC4uLgoKCjcuICBSZWZlcmVuY2VzCgo3LjEu
ICBOb3JtYXRpdmUgUmVmZXJlbmNlcwoKICAgWzFdICBTaW1wc29uLCBXLiwgIklQIGluIElQ
IFR1bm5lbGluZyIsIFJGQyAxODUzLCBPY3RvYmVyIDE5OTUuCgogICBbMl0gIEdpbGxpZ2Fu
LCBSLiBhbmQgRS4gTm9yZG1hcmssICJUcmFuc2l0aW9uIE1lY2hhbmlzbXMgZm9yIElQdjYK
ICAgICAgICBIb3N0cyBhbmQgUm91dGVycyIsIFJGQyAxOTMzLCBBcHJpbCAxOTk2LgoKICAg
WzNdICBHaWxsaWdhbiwgUi4gYW5kIEUuIE5vcmRtYXJrLCAiVHJhbnNpdGlvbiBNZWNoYW5p
c21zIGZvciBJUHY2CiAgICAgICAgSG9zdHMgYW5kIFJvdXRlcnMiLCBSRkMgMjg5MywgQXVn
dXN0IDIwMDAuCgogICBbNF0gIENvbnRhLCBBLiBhbmQgUy4gRGVlcmluZywgIkdlbmVyaWMg
UGFja2V0IFR1bm5lbGluZyBpbiBJUHY2CiAgICAgICAgU3BlY2lmaWNhdGlvbiIsIFJGQyAy
NDczLCBEZWNlbWJlciAxOTk4LgoKICAgWzVdICBDYXJwZW50ZXIsIEIuIGFuZCBDLiBKdW5n
LCAiVHJhbnNtaXNzaW9uIG9mIElQdjYgb3ZlciBJUHY0CiAgICAgICAgRG9tYWlucyB3aXRo
b3V0IEV4cGxpY2l0IFR1bm5lbHMiLCBSRkMgMjUyOSwgTWFyY2ggMTk5OS4KCgoKCgpQYWxl
dCAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBcHJpbCAxOSwgMjAwNiAgICAgICAgICAg
ICAgICAgW1BhZ2UgNV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICA2aW40IHZlcnN1cyA2b3Zl
cjQgdGVybWlub2xvZ3kgICAgICAgICBPY3RvYmVyIDIwMDUKCgo3LjIuICBJbmZvcm1hdGl2
ZSBSZWZlcmVuY2VzCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK
CgoKCgoKCgoKUGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIw
MDYgICAgICAgICAgICAgICAgIFtQYWdlIDZdCgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmlu
NCB2ZXJzdXMgNm92ZXI0IHRlcm1pbm9sb2d5ICAgICAgICAgT2N0b2JlciAyMDA1CgoKQXV0
aG9yJ3MgQWRkcmVzcwoKICAgSm9yZGkgUGFsZXQgTWFydGluZXoKICAgQ29uc3VsaW50ZWwK
ICAgU2FuIEpvc2UgQXJ0ZXNhbm8sIDEKICAgQWxjb2JlbmRhcyAtIE1hZHJpZAogICBFLTI4
MTA4IC0gU3BhaW4KCiAgIFBob25lOiArMzQgOTEgMTUxIDgxIDk5CiAgIEZheDogICArMzQg
OTEgMTUxIDgxIDk4CiAgIEVtYWlsOiBqb3JkaS5wYWxldEBjb25zdWxpbnRlbC5lcwoKCgoK
CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKUGFsZXQgICAgICAgICAgICAg
ICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAgICAgICAgICAgIFtQYWdlIDdd
CgwKSW50ZXJuZXQtRHJhZnQgICAgICAgNmluNCB2ZXJzdXMgNm92ZXI0IHRlcm1pbm9sb2d5
ICAgICAgICAgT2N0b2JlciAyMDA1CgoKSW50ZWxsZWN0dWFsIFByb3BlcnR5IFN0YXRlbWVu
dAoKICAgVGhlIElFVEYgdGFrZXMgbm8gcG9zaXRpb24gcmVnYXJkaW5nIHRoZSB2YWxpZGl0
eSBvciBzY29wZSBvZiBhbnkKICAgSW50ZWxsZWN0dWFsIFByb3BlcnR5IFJpZ2h0cyBvciBv
dGhlciByaWdodHMgdGhhdCBtaWdodCBiZSBjbGFpbWVkIHRvCiAgIHBlcnRhaW4gdG8gdGhl
IGltcGxlbWVudGF0aW9uIG9yIHVzZSBvZiB0aGUgdGVjaG5vbG9neSBkZXNjcmliZWQgaW4K
ICAgdGhpcyBkb2N1bWVudCBvciB0aGUgZXh0ZW50IHRvIHdoaWNoIGFueSBsaWNlbnNlIHVu
ZGVyIHN1Y2ggcmlnaHRzCiAgIG1pZ2h0IG9yIG1pZ2h0IG5vdCBiZSBhdmFpbGFibGU7IG5v
ciBkb2VzIGl0IHJlcHJlc2VudCB0aGF0IGl0IGhhcwogICBtYWRlIGFueSBpbmRlcGVuZGVu
dCBlZmZvcnQgdG8gaWRlbnRpZnkgYW55IHN1Y2ggcmlnaHRzLiAgSW5mb3JtYXRpb24KICAg
b24gdGhlIHByb2NlZHVyZXMgd2l0aCByZXNwZWN0IHRvIHJpZ2h0cyBpbiBSRkMgZG9jdW1l
bnRzIGNhbiBiZQogICBmb3VuZCBpbiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIENvcGllcyBv
ZiBJUFIgZGlzY2xvc3VyZXMgbWFkZSB0byB0aGUgSUVURiBTZWNyZXRhcmlhdCBhbmQgYW55
CiAgIGFzc3VyYW5jZXMgb2YgbGljZW5zZXMgdG8gYmUgbWFkZSBhdmFpbGFibGUsIG9yIHRo
ZSByZXN1bHQgb2YgYW4KICAgYXR0ZW1wdCBtYWRlIHRvIG9idGFpbiBhIGdlbmVyYWwgbGlj
ZW5zZSBvciBwZXJtaXNzaW9uIGZvciB0aGUgdXNlIG9mCiAgIHN1Y2ggcHJvcHJpZXRhcnkg
cmlnaHRzIGJ5IGltcGxlbWVudGVycyBvciB1c2VycyBvZiB0aGlzCiAgIHNwZWNpZmljYXRp
b24gY2FuIGJlIG9idGFpbmVkIGZyb20gdGhlIElFVEYgb24tbGluZSBJUFIgcmVwb3NpdG9y
eSBhdAogICBodHRwOi8vd3d3LmlldGYub3JnL2lwci4KCiAgIFRoZSBJRVRGIGludml0ZXMg
YW55IGludGVyZXN0ZWQgcGFydHkgdG8gYnJpbmcgdG8gaXRzIGF0dGVudGlvbiBhbnkKICAg
Y29weXJpZ2h0cywgcGF0ZW50cyBvciBwYXRlbnQgYXBwbGljYXRpb25zLCBvciBvdGhlciBw
cm9wcmlldGFyeQogICByaWdodHMgdGhhdCBtYXkgY292ZXIgdGVjaG5vbG9neSB0aGF0IG1h
eSBiZSByZXF1aXJlZCB0byBpbXBsZW1lbnQKICAgdGhpcyBzdGFuZGFyZC4gIFBsZWFzZSBh
ZGRyZXNzIHRoZSBpbmZvcm1hdGlvbiB0byB0aGUgSUVURiBhdAogICBpZXRmLWlwckBpZXRm
Lm9yZy4KCgpEaXNjbGFpbWVyIG9mIFZhbGlkaXR5CgogICBUaGlzIGRvY3VtZW50IGFuZCB0
aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBhcmUgcHJvdmlkZWQgb24gYW4KICAg
IkFTIElTIiBiYXNpcyBhbmQgVEhFIENPTlRSSUJVVE9SLCBUSEUgT1JHQU5JWkFUSU9OIEhF
L1NIRSBSRVBSRVNFTlRTCiAgIE9SIElTIFNQT05TT1JFRCBCWSAoSUYgQU5ZKSwgVEhFIElO
VEVSTkVUIFNPQ0lFVFkgQU5EIFRIRSBJTlRFUk5FVAogICBFTkdJTkVFUklORyBUQVNLIEZP
UkNFIERJU0NMQUlNIEFMTCBXQVJSQU5USUVTLCBFWFBSRVNTIE9SIElNUExJRUQsCiAgIElO
Q0xVRElORyBCVVQgTk9UIExJTUlURUQgVE8gQU5ZIFdBUlJBTlRZIFRIQVQgVEhFIFVTRSBP
RiBUSEUKICAgSU5GT1JNQVRJT04gSEVSRUlOIFdJTEwgTk9UIElORlJJTkdFIEFOWSBSSUdI
VFMgT1IgQU5ZIElNUExJRUQKICAgV0FSUkFOVElFUyBPRiBNRVJDSEFOVEFCSUxJVFkgT1Ig
RklUTkVTUyBGT1IgQSBQQVJUSUNVTEFSIFBVUlBPU0UuCgoKQ29weXJpZ2h0IFN0YXRlbWVu
dAoKICAgQ29weXJpZ2h0IChDKSBUaGUgSW50ZXJuZXQgU29jaWV0eSAoMjAwNSkuICBUaGlz
IGRvY3VtZW50IGlzIHN1YmplY3QKICAgdG8gdGhlIHJpZ2h0cywgbGljZW5zZXMgYW5kIHJl
c3RyaWN0aW9ucyBjb250YWluZWQgaW4gQkNQIDc4LCBhbmQKICAgZXhjZXB0IGFzIHNldCBm
b3J0aCB0aGVyZWluLCB0aGUgYXV0aG9ycyByZXRhaW4gYWxsIHRoZWlyIHJpZ2h0cy4KCgpB
Y2tub3dsZWRnbWVudAoKICAgRnVuZGluZyBmb3IgdGhlIFJGQyBFZGl0b3IgZnVuY3Rpb24g
aXMgY3VycmVudGx5IHByb3ZpZGVkIGJ5IHRoZQogICBJbnRlcm5ldCBTb2NpZXR5LgoKCgoK
UGFsZXQgICAgICAgICAgICAgICAgICAgIEV4cGlyZXMgQXByaWwgMTksIDIwMDYgICAgICAg
ICAgICAgICAgIFtQYWdlIDhdCgwKCg==

--B_3212351708_6739812--








From owner-v6ops@ops.ietf.org Mon Oct 17 19:19:39 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EReGZ-0005h9-Ne
	for v6ops-archive@megatron.ietf.org; Mon, 17 Oct 2005 19:19:39 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14228
	for <v6ops-archive@lists.ietf.org>; Mon, 17 Oct 2005 19:19:31 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EReDy-0004sm-GD
	for v6ops-data@psg.com; Mon, 17 Oct 2005 23:16:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE 
	autolearn=ham version=3.1.0
Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EReDv-0004sQ-RV
	for v6ops@ops.ietf.org; Mon, 17 Oct 2005 23:16:55 +0000
Received: from sj-core-5.cisco.com ([171.71.177.238])
  by sj-iport-3.cisco.com with ESMTP; 17 Oct 2005 16:16:42 -0700
X-IronPort-AV: i="3.97,225,1125903600"; 
   d="scan'208,217"; a="353312978:sNHT3842207356"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j9HNGd94017735;
	Mon, 17 Oct 2005 16:16:40 -0700 (PDT)
Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9HNQPdM000977;
	Mon, 17 Oct 2005 16:27:11 -0700
In-Reply-To: <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
References: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com> <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com> <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: multipart/alternative; boundary=Apple-Mail-2-959943084
Message-Id: <6C7BAC09-4C09-40DD-B6BD-9795E01619DF@cisco.com>
Cc: v6ops@ops.ietf.org
From: Fred Baker <fred@cisco.com>
Subject: Re: Time to put together an agenda
Date: Mon, 17 Oct 2005 16:16:38 -0700
To: Salman Asadullah <sasad@cisco.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=1201; t=1129591631; x=1130023831;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Time=20to=20put=20together=20an=20agenda|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Mon,=2017=20Oct=202005=2016=3A16=3A38=20-0700|
	Content-Type:multipart/alternative=3B=20boundary=3DApple-Mail-2-959943084;
	b=kaN4JqIjFOFQsX9YXw6LXmF0fNswZB4daN7FOeNgaryBnUUV1S7dLO9nlwwdneKi4PhpkPz8
	aeOkoiR9yLRfFFA0FLvBjxpXOZpck2FDw3LvIgIdxhfjqJdci6kK/u0lcRA+bGu/O7aZ2ug6CWr
	mtp17WgLtrpJcQ35DHFjOOLg=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	28 extraneous bytes; message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


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

depends on the changes. Are they big ones, or merely editorial?

On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:

> Do you see a need to provide an update to the wg for this work in  
> next meeting ?


--Apple-Mail-2-959943084
Content-Type: text/html;
	charset=US-ASCII
Content-Transfer-Encoding: 7bit

<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; ">depends on the changes. Are they big ones, or merely editorial?<DIV><BR><DIV><DIV>On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><SPAN class="Apple-style-span" style="border-collapse: separate; border-spacing: 0px 0px; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; text-align: auto; -khtml-text-decorations-in-effect: none; text-indent: 0px; -apple-text-size-adjust: auto; text-transform: none; orphans: 2; white-space: normal; widows: 2; word-spacing: 0px; "><FONT size="3">Do you see a need to provide an update to the wg for this work in next meeting ?<BR></FONT></SPAN></BLOCKQUOTE></DIV><BR></DIV></BODY></HTML>
--Apple-Mail-2-959943084--




From owner-v6ops@ops.ietf.org Tue Oct 18 03:49:46 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERmEE-0004VY-5A
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 03:49:46 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10803
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 03:49:38 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERmBd-0004DD-1p
	for v6ops-data@psg.com; Tue, 18 Oct 2005 07:47:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [213.136.24.43] (helo=purgatory.unfix.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERmBb-0004Ci-Qz
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 07:47:04 +0000
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 5575B7F54;
	Tue, 18 Oct 2005 09:46:57 +0200 (CEST)
Subject: Re: Time to put together an agenda
From: Jeroen Massar <jeroen@unfix.org>
To: jordi.palet@consulintel.es
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
In-Reply-To: <BF79D06D.1350DB%jordi.palet@consulintel.es>
References: <BF79D06D.1350DB%jordi.palet@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-S73xMoCiHyNW/CO0F4G8"
Organization: Unfix
Date: Tue, 18 Oct 2005 09:46:53 +0200
Message-Id: <1129621614.24798.73.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-S73xMoCiHyNW/CO0F4G8
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Mon, 2005-10-17 at 22:04 +0200, JORDI PALET MARTINEZ wrote:
> Hi Jeroen,
>=20
> I've attached it in a previous email yesterday to v6ops, until the deadli=
ne
> queue is emptied ... Anyway is also available at:
>=20
> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-6in4-vs-6over4-=
00.
> txt

I missed out on the attachment I guess :)

My 'solution' to the 6in4 vs 6over4 debate is simple: call 6in4
'proto-41', as that is what it is. Not clear directly clear to end
users, but they can Google for it and then it becomes clear.
End users don't know what MPLS and a lot of other acronyms are either.

Greets,
 Jeroen


--=-S73xMoCiHyNW/CO0F4G8
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBDVKhtKaooUjM+fCMRAvgOAJ956+ToM5e7sTLgrPIiPjs8pGKKiQCdE0Zq
2RapkoIzZKNqfOK1pDhlYA0=
=q1Wx
-----END PGP SIGNATURE-----

--=-S73xMoCiHyNW/CO0F4G8--





From owner-v6ops@ops.ietf.org Tue Oct 18 04:16:05 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERmdg-0005rW-Ft
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 04:16:05 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12122
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 04:15:56 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERmcp-0005qt-S9
	for v6ops-data@psg.com; Tue, 18 Oct 2005 08:15:11 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,
	RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.0
Received: from [213.172.48.142] (helo=consulintel.es)
	by psg.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.52 (FreeBSD))
	id 1ERmco-0005qa-Mw
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 08:15:10 +0000
Received: from [10.10.10.101] by consulintel.es
	(MDaemon.PRO.v7.2.5.R)
	with ESMTP id md50001347384.msg
	for <v6ops@ops.ietf.org>; Tue, 18 Oct 2005 10:19:26 +0200
User-Agent: Microsoft-Entourage/11.2.0.050811
Date: Tue, 18 Oct 2005 10:14:17 +0200
Subject: Re: Time to put together an agenda
From: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
To: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Message-ID: <BF7A7B79.135450%jordi.palet@consulintel.es>
Thread-Topic: Time to put together an agenda
Thread-Index: AcXTu+7hLViJ+D+vEdqiqQAKldLC/g==
In-Reply-To: <1129621614.24798.73.camel@firenze.zurich.ibm.com>
Mime-version: 1.0
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
X-Authenticated-Sender: jordi.palet@consulintel.es
X-MDRemoteIP: 217.126.187.160
X-Return-Path: jordi.palet@consulintel.es
X-MDaemon-Deliver-To: v6ops@ops.ietf.org
Reply-To: jordi.palet@consulintel.es
X-MDAV-Processed: consulintel.es, Tue, 18 Oct 2005 10:19:58 +0200
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

I think something strange happened yesterday with the ietf mail exploders
... Seen duplicate emails and some which where delivered with a lot of extra
delay.

Do you mean keep 6over4 only for the transition mechanism and rename every
expression which means 6in4 to proto-41 ?

If that's the case I would disagree because we also have 4in6, 6in6, etc.
and seems to me much easy to remember that (you don't need to remember the
protocol number, but what the encapsulation does), than the cost of using
6over4 properly ;-)

Regards,
Jordi




> De: Jeroen Massar <jeroen@unfix.org>
> Organizaci=F3n: Unfix
> Responder a: <owner-v6ops@ops.ietf.org>
> Fecha: Tue, 18 Oct 2005 09:46:53 +0200
> Para: <jordi.palet@consulintel.es>
> CC: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
> Asunto: Re: Time to put together an agenda
>=20
> On Mon, 2005-10-17 at 22:04 +0200, JORDI PALET MARTINEZ wrote:
>> Hi Jeroen,
>>=20
>> I've attached it in a previous email yesterday to v6ops, until the deadline
>> queue is emptied ... Anyway is also available at:
>>=20
>> http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-6in4-vs-6over4-00.
>> txt
>=20
> I missed out on the attachment I guess :)
>=20
> My 'solution' to the 6in4 vs 6over4 debate is simple: call 6in4
> 'proto-41', as that is what it is. Not clear directly clear to end
> users, but they can Google for it and then it becomes clear.
> End users don't know what MPLS and a lot of other acronyms are either.
>=20
> Greets,
>  Jeroen
>=20




************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Information available at:
http://www.ipv6-es.com

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







From owner-v6ops@ops.ietf.org Tue Oct 18 04:39:06 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERmzy-0004w3-OS
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 04:39:06 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13447
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 04:38:58 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERmzQ-0007K8-Rb
	for v6ops-data@psg.com; Tue, 18 Oct 2005 08:38:32 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [213.136.24.43] (helo=purgatory.unfix.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ERmzQ-0007Jt-7I
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 08:38:32 +0000
Received: from firenze.zurich.ibm.com (pat.zurich.ibm.com [195.176.20.45])
	(using SSLv3 with cipher RC4-MD5 (128/128 bits))
	(No client certificate requested)
	by purgatory.unfix.org (Postfix) with ESMTP id 219BF7F54;
	Tue, 18 Oct 2005 10:38:28 +0200 (CEST)
Subject: Re: Time to put together an agenda
From: Jeroen Massar <jeroen@unfix.org>
To: jordi.palet@consulintel.es
Cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
In-Reply-To: <BF7A7B79.135450%jordi.palet@consulintel.es>
References: <BF7A7B79.135450%jordi.palet@consulintel.es>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-4OSxDDaHxR4lOtafzKdi"
Organization: Unfix
Date: Tue, 18 Oct 2005 10:38:24 +0200
Message-Id: <1129624705.30404.6.camel@firenze.zurich.ibm.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.2.3 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


--=-4OSxDDaHxR4lOtafzKdi
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Tue, 2005-10-18 at 10:14 +0200, JORDI PALET MARTINEZ wrote:
> I think something strange happened yesterday with the ietf mail exploders
> ... Seen duplicate emails and some which where delivered with a lot of ex=
tra
> delay.
>=20
> Do you mean keep 6over4 only for the transition mechanism and rename ever=
y
> expression which means 6in4 to proto-41 ?

No, my case only covers 6in4 unfortunately. I don't use much else at the
moment. Clarification of these words is imho quite useful because of the
confusion that surrounds it.

Greets,
 Jeroen


--=-4OSxDDaHxR4lOtafzKdi
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iD8DBQBDVLSAKaooUjM+fCMRAmlKAJsE2KpdSwPAgeTAd9lF7EVUgauKigCfafld
KsMl0JLEHmmnxvKJ7Qqau2o=
=eRwX
-----END PGP SIGNATURE-----

--=-4OSxDDaHxR4lOtafzKdi--





From owner-v6ops@ops.ietf.org Tue Oct 18 04:41:58 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERn2k-0005vg-HY
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 04:41:58 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13539
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 04:41:50 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERn2Q-0007Zl-Ni
	for v6ops-data@psg.com; Tue, 18 Oct 2005 08:41:38 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERn2P-0007ZT-QR
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 08:41:38 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9I8fVt06543;
	Tue, 18 Oct 2005 10:41:31 +0200 (CEST)
Received: from gvandeve-w2k01.cisco.com (dhcp-peg3-vl30-144-254-7-103.cisco.com [144.254.7.103])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9I8fTC17653;
	Tue, 18 Oct 2005 10:41:29 +0200 (CEST)
Message-Id: <4.3.2.7.2.20051018090106.055de760@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 18 Oct 2005 10:41:28 +0200
To: Fred Baker <fred@cisco.com>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: Time to put together an agenda
Cc: v6ops@ops.ietf.org, Lindqvist Erik Kurt <kurtis@kurtis.pp.se>,
        David Kessens <david.kessens@nokia.com>
In-Reply-To: <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Fred,

NAP -02 will be submitted during this week. Various editorial
changes have happened. No other large significant changes for
the rest. Not sure if we should ask for a slot.

G/



At 03:45 12/10/2005 -0400, Fred Baker wrote:
>Who has a document that is new since we met in Paris and needs to
>discuss?





From owner-v6ops@ops.ietf.org Tue Oct 18 12:46:55 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERuc0-0002N6-6p
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 12:46:55 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13821
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 12:46:43 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERuYL-000Gie-BH
	for v6ops-data@psg.com; Tue, 18 Oct 2005 16:43:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERuYK-000GiG-1E
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 16:43:04 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j9IGgxl06535;
	Tue, 18 Oct 2005 19:42:59 +0300
Date: Tue, 18 Oct 2005 19:42:59 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: JORDI PALET MARTINEZ <jordi.palet@consulintel.es>
cc: "v6ops@ops.ietf.org" <v6ops@ops.ietf.org>
Subject: mailing list loop at flarion.com [Re: Time to put together an agenda]
In-Reply-To: <BF7A7B79.135450%jordi.palet@consulintel.es>
Message-ID: <Pine.LNX.4.61.0510181941310.6456@netcore.fi>
References: <BF7A7B79.135450%jordi.palet@consulintel.es>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Tue, 18 Oct 2005, JORDI PALET MARTINEZ wrote:
> I think something strange happened yesterday with the ietf mail exploders
> ... Seen duplicate emails and some which where delivered with a lot of extra
> delay.

Actually, by inspecting the headers, it seems that flarion.com's mail 
system had looped about 7-8 messages at least on this list.  As these 
haven't appeared (again), the problem may have been fixed already.

-- 
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 Tue Oct 18 12:49:44 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERuem-0002mL-8d
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 12:49:44 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13917
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 12:49:35 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERuds-000H45-0V
	for v6ops-data@psg.com; Tue, 18 Oct 2005 16:48:48 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40,
	HTML_MESSAGE autolearn=ham version=3.1.0
Received: from [171.68.227.75] (helo=av-tac-sj.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERudr-000H3r-CZ
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 16:48:47 +0000
X-TACSUNS: Virus Scanned
Received: from fire.cisco.com (localhost [127.0.0.1])
	by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9IGmkZ04247
	for <v6ops@ops.ietf.org>; Tue, 18 Oct 2005 09:48:46 -0700 (PDT)
Received: from sasad-w2k01.cisco.com ([64.101.172.226])
	by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9IGmj100190;
	Tue, 18 Oct 2005 09:48:45 -0700 (PDT)
Message-Id: <4.3.2.7.2.20051018094744.01e62d28@ce-nfs-1.cisco.com>
X-Sender: sasad@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 18 Oct 2005 09:48:45 -0700
To: Fred Baker <fred@cisco.com>
From: Salman Asadullah <sasad@cisco.com>
Subject: Re: Time to put together an agenda
Cc: v6ops@ops.ietf.org
In-Reply-To: <6C7BAC09-4C09-40DD-B6BD-9795E01619DF@cisco.com>
References: <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
 <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
 <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
 <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_92699194==_.ALT"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--=====================_92699194==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Mainly editorial changes.

Regards,
Salman

At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:
>depends on the changes. Are they big ones, or merely editorial?
>
>On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:
>
>>Do you see a need to provide an update to the wg for this work in next 
>>meeting ?

--=====================_92699194==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Mainly editorial changes.<br>
<br>
Regards,<br>
Salman<br>
<br>
At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:<br>
<blockquote type=cite cite>depends on the changes. Are they big ones, or
merely editorial?<br>
<br>
On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:<br>
<br>
<blockquote type=cite cite>Do you see a need to provide an update to the
wg for this work in next meeting
?</blockquote></font></blockquote></html>

--=====================_92699194==_.ALT--





From owner-v6ops@ops.ietf.org Tue Oct 18 12:51:00 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERug0-0003da-7z
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 12:51:00 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14036
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 12:50:51 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERufI-000HAT-4A
	for v6ops-data@psg.com; Tue, 18 Oct 2005 16:50:16 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_50_60,
	HTML_MESSAGE autolearn=ham version=3.1.0
Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERufF-000HAF-Fp
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 16:50:13 +0000
Received: from sj-core-4.cisco.com ([171.68.223.138])
  by sj-iport-4.cisco.com with ESMTP; 18 Oct 2005 09:50:13 -0700
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91])
	by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j9IGoBUw010337;
	Tue, 18 Oct 2005 09:50:11 -0700 (PDT)
Received: from [10.32.244.221] (stealth-10-32-244-221.cisco.com [10.32.244.221])
	by imail.cisco.com (8.12.11/8.12.10) with SMTP id j9IH0dBQ007520;
	Tue, 18 Oct 2005 10:00:39 -0700
In-Reply-To: <4.3.2.7.2.20051018094744.01e62d28@ce-nfs-1.cisco.com>
References: <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com> <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com> <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com> <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com> <4.3.2.7.2.20051018094744.01e62d28@ce-nfs-1.cisco.com>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: multipart/alternative; boundary=Apple-Mail-11-1023154619
Message-Id: <5C7E099F-1C66-4ACD-9918-9017ED539751@cisco.com>
Cc: v6ops@ops.ietf.org
From: Fred Baker <fred@cisco.com>
Subject: Re: Time to put together an agenda
Date: Tue, 18 Oct 2005 09:50:09 -0700
To: Salman Asadullah <sasad@cisco.com>
X-Mailer: Apple Mail (2.734)
DKIM-Signature: a=rsa-sha1;  q=dns; l=1308; t=1129654840; x=1130087040;
	c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding;
	d=cisco.com; i=fred@cisco.com; 
	z=Subject:Re=3A=20Time=20to=20put=20together=20an=20agenda|
	From:Fred=20Baker=20<fred@cisco.com>|
	Date:Tue,=2018=20Oct=202005=2009=3A50=3A09=20-0700|
	Content-Type:multipart/alternative=3B=20boundary=3DApple-Mail-11-1023154619;
	b=HjgZ3BHZYx7jWQ8uZvpSm+yp83atRvKEQytT7ev3AmE/kHNwCEgae56WEAFtZsZ+QrTTa+jT
	uYxwqqZ52Vyh7ILt0ppnQsobJZr7kfx8FXsgoz/aAKnCDfcx5OYRvkrPIq68HO/3hE4IYgbV4gO
	C1l62RU2DlFKSe2iRq+GXev0=
Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass (
	30 extraneous bytes; message from cisco.com verified; ); 
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk


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

then that sounds like a mailing list topic.

On Oct 18, 2005, at 9:48 AM, Salman Asadullah wrote:

> Mainly editorial changes.
>
> Regards,
> Salman
>
> At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:
>> depends on the changes. Are they big ones, or merely editorial?
>>
>> On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:
>>
>>> Do you see a need to provide an update to the wg for this work in  
>>> next meeting ?


--Apple-Mail-11-1023154619
Content-Type: text/html;
	charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<HTML><BODY style=3D"word-wrap: break-word; -khtml-nbsp-mode: space; =
-khtml-line-break: after-white-space; ">then=A0that sounds like a =
mailing list topic.<DIV><BR><DIV><DIV>On Oct 18, 2005, at 9:48 AM, =
Salman Asadullah wrote:</DIV><BR =
class=3D"Apple-interchange-newline"><BLOCKQUOTE type=3D"cite"><FONT =
size=3D"3">Mainly editorial changes.<BR> <BR> Regards,<BR> Salman<BR> =
<BR> At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:<BR> =
</FONT><BLOCKQUOTE type=3D"cite" cite=3D""><FONT size=3D"3">depends on =
the changes. Are they big ones, or merely editorial?<BR> <BR> On Oct 17, =
2005, at 1:03 PM, Salman Asadullah wrote:<BR> <BR> <BLOCKQUOTE =
type=3D"cite" cite=3D"">Do you see a need to provide an update to the wg =
for this work in next meeting =
?</BLOCKQUOTE></FONT></BLOCKQUOTE></BLOCKQUOTE></DIV><BR></DIV></BODY></HT=
ML>=

--Apple-Mail-11-1023154619--




From owner-v6ops@ops.ietf.org Tue Oct 18 13:06:18 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERuul-0007RB-6Y
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 13:06:18 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15915
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 13:06:06 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERut4-000I5s-9V
	for v6ops-data@psg.com; Tue, 18 Oct 2005 17:04:30 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,HTML_30_40,
	HTML_MESSAGE autolearn=ham version=3.1.0
Received: from [171.68.227.75] (helo=av-tac-sj.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERut3-000I5f-Hn
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 17:04:29 +0000
X-TACSUNS: Virus Scanned
Received: from fire.cisco.com (localhost [127.0.0.1])
	by av-tac-sj.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9IH4TY05403
	for <v6ops@ops.ietf.org>; Tue, 18 Oct 2005 10:04:29 -0700 (PDT)
Received: from sasad-w2k01.cisco.com ([64.101.172.226])
	by fire.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9IH4S121391;
	Tue, 18 Oct 2005 10:04:28 -0700 (PDT)
Message-Id: <4.3.2.7.2.20051018100333.01f4fcf8@ce-nfs-1.cisco.com>
X-Sender: sasad@ce-nfs-1.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 18 Oct 2005 10:04:27 -0700
To: Fred Baker <fred@cisco.com>
From: Salman Asadullah <sasad@cisco.com>
Subject: Re: Time to put together an agenda
Cc: v6ops@ops.ietf.org
In-Reply-To: <5C7E099F-1C66-4ACD-9918-9017ED539751@cisco.com>
References: <4.3.2.7.2.20051018094744.01e62d28@ce-nfs-1.cisco.com>
 <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
 <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
 <FEF2D488-51BE-4DCC-BE53-AF35083E292F@cisco.com>
 <4.3.2.7.2.20051017125736.02f4f370@ce-nfs-1.cisco.com>
 <4.3.2.7.2.20051018094744.01e62d28@ce-nfs-1.cisco.com>
Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="=====================_93641409==_.ALT"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

--=====================_93641409==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

Sounds good.

We'll publish the -04 based on these changes during this week.

Regards,
Salman

At 09:50 AM 10/18/2005 -0700, Fred Baker wrote:
>then that sounds like a mailing list topic.
>
>On Oct 18, 2005, at 9:48 AM, Salman Asadullah wrote:
>
>>Mainly editorial changes.
>>
>>Regards,
>>Salman
>>
>>At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:
>>>depends on the changes. Are they big ones, or merely editorial?
>>>
>>>On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:
>>>
>>>>Do you see a need to provide an update to the wg for this work in next 
>>>>meeting ?

--=====================_93641409==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
<font size=3>Sounds good.<br>
<br>
We'll publish the -04 based on these changes during this week.<br>
<br>
Regards,<br>
Salman<br>
<br>
At 09:50 AM 10/18/2005 -0700, Fred Baker wrote:<br>
<blockquote type=cite cite>then that sounds like a mailing list
topic.<br>
<br>
On Oct 18, 2005, at 9:48 AM, Salman Asadullah wrote:<br>
<br>
<blockquote type=cite cite>Mainly editorial changes.<br>
<br>
Regards,<br>
Salman<br>
<br>
At 04:16 PM 10/17/2005 -0700, Fred Baker wrote:<br>
<blockquote type=cite cite>depends on the changes. Are they big ones, or
merely editorial?<br>
<br>
On Oct 17, 2005, at 1:03 PM, Salman Asadullah wrote:<br>
<br>
<blockquote type=cite cite>Do you see a need to provide an update to the
wg for this work in next meeting
?</blockquote></blockquote></blockquote></font></blockquote></html>

--=====================_93641409==_.ALT--





From owner-v6ops@ops.ietf.org Tue Oct 18 13:11:42 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ERv02-0002d9-5x
	for v6ops-archive@megatron.ietf.org; Tue, 18 Oct 2005 13:11:42 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16651
	for <v6ops-archive@lists.ietf.org>; Tue, 18 Oct 2005 13:11:33 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ERuzg-000Ig1-Ad
	for v6ops-data@psg.com; Tue, 18 Oct 2005 17:11:20 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [63.103.94.23] (helo=mail.flarion.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ERuzf-000Ifp-Ix
	for v6ops@ops.ietf.org; Tue, 18 Oct 2005 17:11:19 +0000
Received: from ftmailserver.flariontech.com ([10.10.1.140]) by mail.flarion.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 18 Oct 2005 13:11:17 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
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: mailing list loop at flarion.com [Re: Time to put together an agenda]
Date: Tue, 18 Oct 2005 13:11:17 -0400
Message-ID: <A11736FE943F1A408F8BBB1B9F5FE8AD01CBCD3D@ftmailserver.flariontech.com>
Thread-Topic: mailing list loop at flarion.com [Re: Time to put together an agenda]
Thread-Index: AcXUBP09lk+CruxWTv2R0Dk1e4s2KQAAd7wQ
From: "Soliman, Hesham" <H.Soliman@flarion.com>
To: "Pekka Savola" <pekkas@netcore.fi>,
        "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
CC: <v6ops@ops.ietf.org>
X-OriginalArrivalTime: 18 Oct 2005 17:11:17.0668 (UTC) FILETIME=[F3E4D640:01C5D406]
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Pekka,

Thanks, I've alerted our IT admin. We had a problem on the weekend.=20

Hesham

 > -----Original Message-----
 > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On
 > Behalf Of Pekka Savola
 > Sent: Tuesday, October 18, 2005 12:43 PM
 > To: JORDI PALET MARTINEZ
 > Cc: v6ops@ops.ietf.org
 > Subject: mailing list loop at flarion.com [Re: Time to put=20
 > together an
 > agenda]
 >=20
 >=20
 > On Tue, 18 Oct 2005, JORDI PALET MARTINEZ wrote:
 > > I think something strange happened yesterday with the ietf=20
 > mail exploders
 > > ... Seen duplicate emails and some which where delivered=20
 > with a lot of extra
 > > delay.
 >=20
 > Actually, by inspecting the headers, it seems that=20
 > flarion.com's mail=20
 > system had looped about 7-8 messages at least on this list. =20
 > As these=20
 > haven't appeared (again), the problem may have been fixed already.
 >=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

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





From owner-v6ops@ops.ietf.org Wed Oct 19 08:34:27 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESD9H-0004lU-0W
	for v6ops-archive@megatron.ietf.org; Wed, 19 Oct 2005 08:34:27 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13110
	for <v6ops-archive@lists.ietf.org>; Wed, 19 Oct 2005 08:34:17 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ESD61-0003b4-Ep
	for v6ops-data@psg.com; Wed, 19 Oct 2005 12:31:05 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ESD60-0003ao-4c
	for v6ops@ops.ietf.org; Wed, 19 Oct 2005 12:31:04 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ESD5x-0008FS-Ar
	for v6ops@ops.ietf.org; Wed, 19 Oct 2005 13:31:01 +0100
Message-ID: <43563CE0.4020009@dial.pipex.com>
Date: Wed, 19 Oct 2005 13:32:32 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
In-Reply-To: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

This new wg draft was published this week.  It is a substantial rewrite 
of the individual draft which Janos and I published in July.

It now covers all the messages that are currently defined for ICMPv6 and 
is written in a format which should make it easier for administrators to 
crate firewall rules from it.

Comments would be appreciated.

One suggestion we had was to include a set of 'pseudo-code' rules as a 
an example of how the recommendations might be implemented.

Regards,
Elwyn

Internet-Drafts@ietf.org wrote:

>A New Internet-Draft is available from the on-line Internet-Drafts directories.
>This draft is a work item of the IPv6 Operations Working Group of the IETF.
>
>	Title		: Best Current Practice for Filtering ICMPv6 Messages in Firewalls
>	Author(s)	: E. Davies, J. Mohacsi
>	Filename	: draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
>	Pages		: 27
>	Date		: 2005-10-17
>	
>   In networks supporting IPv6 the Internet Control Message Protocol
>   version 6 (ICMPv6) plays a fundamental role with a large number of
>   functions, and a correspondingly large number of message types and
>   options.  A number of security risks are associated with uncontrolled
>   forwarding of ICMPv6 messages.  On the other hand, compared with IPv4
>   and the corresponding protocol ICMP, ICMPv6 is essential to the
>   functioning of IPv6 rather than a useful auxiliary.
>
>   This document provides some recommendations for ICMPv6 firewall
>   filter configuration that will allow propagation of ICMPv6 messages
>   that are needed to maintain the functioning of the network but drop
>   messages which are potential security risks.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.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-icmpv6-filtering-bcp-00.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html 
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	mailserv@ietf.org.
>In the body type:
>	"FILE /internet-drafts/draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt".
>	
>NOTE:	The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>		
>		
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>  
>




From 539albert@absolutemotion.com Wed Oct 19 20:32:12 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ESOLs-0007t8-EB
	for v6ops-archive@megatron.ietf.org; Wed, 19 Oct 2005 20:32:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28690
	for <v6ops-archive@ietf.org>; Wed, 19 Oct 2005 20:32:02 -0400 (EDT)
Received: from [219.253.250.84] (helo=219.253.250.84)
	by ietf-mx.ietf.org with smtp (Exim 4.43)
	id 1ESOXg-0001JZ-2B
	for v6ops-archive@ietf.org; Wed, 19 Oct 2005 20:44:26 -0400
Message-ID: <91cd01c5d50b$16c3f540$c98e9e18@absolutemotion.com>
From: "Jennifer A. Clark" <539albert@absolutemotion.com>
To: v6ops-archive@ietf.org
Subject: =?iso-8859-1?B?QWxsIHNvZnR3YXJlIC0gNzUlIE9GRg==?=
Date: Thu, 20 Oct 2005 00:14:44 +0000
MIME-Version: 1.0
Content-Type: multipart/related;
    type="multipart/alternative";
    boundary="----=_NextPart_000_0000_A9989711.4408078D"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express V6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Spam-Score: 4.7 (++++)
X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1

This is a multi-part message in MIME format.

------=_NextPart_000_0000_A9989711.4408078D
Content-Type: multipart/alternative;
    boundary="----=_NextPart_001_0001_8803B478.CD3530DC"


------=_NextPart_001_0001_8803B478.CD3530DC
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

      Access all the popular software you ever imagined for unbelievably
low prices!
We sell software 2-6 times cheaper than retail price.

Just a few examples:
$79.95 Windows XP Professional (Including: Service Pack 2)
$89.95 Microsoft Office 2003 Professional / $79.95 Office XP Professional
$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady CS)
$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX
$149.95 Adobe Creative Suite Premium (5 CD)
$79.95 Adobe Acrobat 6.0 Professional
$69.95 MS Project 2003 Professional

Special offers:
$89.95 Windows XP Pro + Office XP Pro
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10
$109.95 Dreamweaver MX 2004 + Flash MX 2004

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Enter here:

http://www.softdisks.org

Regards,
Jennifer A. Clark


________________________________ 
To stop further mailings, go here
________________________________ 

 
------=_NextPart_001_0001_8803B478.CD3530DC
Content-Type: text/html;
    charset="iso-8859-1"
Content-Transfer-Encoding: 7bit

<!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.2900.2604" name=GENERATOR></HEAD>
<BODY>
<CENTER>
<TABLE cellSpacing=0 cellPadding=0 width=800 align=center border=0>
<table id="76366F70732D6172636869766540696574662E6F7267">  <TBODY>
  <TR>
    <TD>Access all the popular 
      software you ever imagined for 
      unbelievably low prices!<BR>We sell software 2-6 times cheaper than retail 
      price.<BR><BR>Just a few 
      examples:<BR>$79.95 Windows XP Professional (Including: Service Pack 
      2)<BR>$89.95 Microsoft Office 2003 Professional / $79.95 Office 
      XP Professional<BR>$99.95 Adobe Photoshop 8.0/CS (Including: ImageReady 
      CS)<BR>$69.95 Dreamweaver MX 2004 / Flash MX 2004 / Fireworks MX<BR>$149.95 Adobe Creative Suite Premium (5 CD)<br>$79.95 Adobe Acrobat 6.0 
      Professional<BR>$69.95 MS Project 2003 Professional<BR><BR>
Special offers:<br>
$89.95 Windows XP Pro + Office XP Pro<br>
$129.95 Photoshop 7 + Premiere 7 + Illustrator 10<br>
$109.95 Dreamweaver MX 2004 + Flash MX 2004<br><br>


All main products from Microsoft, 
      Adobe, Macromedia, Corel, etc.<BR>And many more... Enter here:<BR><BR><A 
      href="http://www.softdisks.org">http://www.softdisks.org</A><BR><BR>Regards,<BR>Jennifer A. Clark<BR><BR><BR>________________________________     <BR>To stop further mailings, go <a href="http://www.softdisks.org/uns.htm">here</A><BR>________________________________

      <P></P></TD></TR></TBODY></TABLE></CENTER></BODY></HTML>

------=_NextPart_001_0001_8803B478.CD3530DC--



------=_NextPart_000_0000_A9989711.4408078D--




From owner-v6ops@ops.ietf.org Fri Oct 21 15:51:18 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2v8-0004Jp-6L
	for v6ops-archive@megatron.ietf.org; Fri, 21 Oct 2005 15:51:18 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00280
	for <v6ops-archive@lists.ietf.org>; Fri, 21 Oct 2005 15:51:06 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ET2uf-000Kyx-Ou
	for v6ops-data@psg.com; Fri, 21 Oct 2005 19:50:49 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ET2ue-000Kyl-V3
	for v6ops@ops.ietf.org; Fri, 21 Oct 2005 19:50:49 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ET2tv-0001HU-4h; Fri, 21 Oct 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-natpt-to-exprmntl-03.txt 
Message-Id: <E1ET2tv-0001HU-4h@newodin.ietf.org>
Date: Fri, 21 Oct 2005 15:50:03 -0400
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		: Reasons to Move NAT-PT to Experimental
	Author(s)	: C. Aoun, E. Davies
	Filename	: draft-ietf-v6ops-natpt-to-exprmntl-03.txt
	Pages		: 25
	Date		: 2005-10-21
	
This document discusses issues with the specific form of IPv6-IPv4
   protocol translation mechanism implemented by the Network Address
   Translator - Protocol Translator (NAT-PT) defined in RFC 2766.  These
   issues are sufficiently serious that recommending RFC 2766 as a
   general purpose transition mechanism is no longer desirable, and this
   document recommends that the IETF should reclassify RFC 2766 from
   Standards Track to Experimental status.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-03.txt

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-natpt-to-exprmntl-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-natpt-to-exprmntl-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--





From owner-v6ops@ops.ietf.org Fri Oct 21 15:51:28 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2vG-0004SU-86
	for v6ops-archive@megatron.ietf.org; Fri, 21 Oct 2005 15:51:28 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00291
	for <v6ops-archive@lists.ietf.org>; Fri, 21 Oct 2005 15:51:14 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ET2s2-000KpZ-Nb
	for v6ops-data@psg.com; Fri, 21 Oct 2005 19:48:06 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,
	MIME_HTML_ONLY autolearn=ham version=3.1.0
Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ET2s1-000KpM-PC
	for v6ops@ops.ietf.org; Fri, 21 Oct 2005 19:48:06 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9LJm4612972;
	Fri, 21 Oct 2005 21:48:04 +0200 (CEST)
Received: from gvandeve-w2k01.cisco.com (rtp-vpn4-543.cisco.com [10.82.210.31])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9LJm2C10373;
	Fri, 21 Oct 2005 21:48:02 +0200 (CEST)
Message-Id: <4.3.2.7.2.20051021214428.054eca38@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 21 Oct 2005 21:47:57 +0200
To: Tim Chown <tjc@ecs.soton.ac.uk>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: Proposed Resolution of Issues [1-37]
Cc: v6ops@ops.ietf.org
In-Reply-To: <20050902083300.GL17558@login.ecs.soton.ac.uk>
References: <4.3.2.7.2.20050901124115.04916658@strange-brew>
 <4.3.2.7.2.20050901124115.04916658@strange-brew>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

<html>
At 09:33 2/09/2005 +0100, Tim Chown wrote:<br>
<blockquote type=cite cite>Issue 24 - so what text will you use?
:)</blockquote><br>
In the background Elwyn worked with us on this aspect. The <br>
text to replace Ch4.4 is below. We feel that text looks more balanced
now. <br>
This replacement text will be in the NAP-02 draft.<br>
<br>
&lt;snip&gt;<br>
<font face="Courier New, Courier">4.4.&nbsp; Privacy and Topology Hiding
using IPv6<br>
<br>
&nbsp;&nbsp; Partial host privacy is achieved in IPv6 using pseudo-random
privacy<br>
&nbsp;&nbsp; addresses [RFC 3041] which are generated as required, so
that a<br>
&nbsp;&nbsp; session can use an address that is valid only for a limited
time.<br>
&nbsp;&nbsp; Exactly as with IPv4 NAT, this only allows such a session to
be<br>
&nbsp;&nbsp; traced back to the subnet that originates it, but not
immediately to<br>
&nbsp;&nbsp; the actual host.<br>
<br>
&nbsp;&nbsp; Due to the large IPv6 address space available there is
plenty of<br>
&nbsp;&nbsp; freedom to randomize subnet allocations.&nbsp; By doing
this, it is<br>
&nbsp;&nbsp; possible to reduce the correlation between a subnet and its
location.<br>
&nbsp;&nbsp; When doing both subnet and IID randomization [RFC 3041] a
casual<br>
&nbsp;&nbsp; snooper won't be able to deduce much about the networks
topology.<br>
&nbsp;&nbsp; The obtaining of a single address will tell the snooper very
little<br>
&nbsp;&nbsp; about other addresses.&nbsp; This is different from IPv4
where address<br>
&nbsp;&nbsp; space limitations cause this to be not true.&nbsp; In most
usage cases<br>
&nbsp;&nbsp; this concept should be sufficient for address privacy and
topology<br>
&nbsp;&nbsp; hiding.<br>
<br>
&nbsp;&nbsp; In the case where a network administrator wishes to fully
conceal the<br>
&nbsp;&nbsp; internal IPv6 topology, and the majority of its host
computer<br>
&nbsp;&nbsp; addresses, a possible option is to run all internal traffic
using<br>
&nbsp;&nbsp; Unique Local Addresses (ULA) since such packets can by
definition<br>
&nbsp;&nbsp; never exit the site.&nbsp; For hosts that do in fact need to
generate<br>
&nbsp;&nbsp; external traffic, by using multiple IPv6 addresses (ULAs and
one or<br>
&nbsp;&nbsp; more global addresses), it will be possible to hide and mask
some or<br>
&nbsp;&nbsp; all of the internal network.&nbsp; As discussed in Section
3.1, there are<br>
&nbsp;&nbsp; multiple parts to the IPv6 address, and different techniques
to<br>
&nbsp;&nbsp; manage privacy for each.<br>
<br>
&nbsp;&nbsp; There are two possible scenarios for the extreme situation
when a<br>
&nbsp;&nbsp; network manager also wishes to fully conceal the internal
IPv6<br>
&nbsp;&nbsp; topology.<br>
<br>
&nbsp;&nbsp; o&nbsp; One could use explicit host routes and remove the
correlation<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; between location and IPv6 address.&nbsp;
This solution does however<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; show severe scalability issues.<br>
&nbsp;&nbsp; o&nbsp; The other technology to fully hide the internal
topology would be<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; to use a tunneling mechanism.&nbsp; Mobile
IPv6 without route<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; optimization is one example.&nbsp; In this
example the public facing<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; addresses are indirected via an edge Home
Agent (HA).&nbsp; This<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; indirection method truly masks the
internal topology as all nodes<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with global access appear to share a
common subnet.&nbsp; The downside<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; of using this method is that it makes
usage of middleware like a<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Home Agent (HA).<br>
<br>
<br>
&lt;end snip&gt;<br>
<br>
Brgds,<br>
G/</font></html>





From owner-v6ops@ops.ietf.org Fri Oct 21 15:51:44 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2vY-0004YP-A0
	for v6ops-archive@megatron.ietf.org; Fri, 21 Oct 2005 15:51:44 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00372
	for <v6ops-archive@lists.ietf.org>; Fri, 21 Oct 2005 15:51:32 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ET2vR-000L2e-Jn
	for v6ops-data@psg.com; Fri, 21 Oct 2005 19:51:37 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ET2vQ-000L2R-Ug
	for v6ops@ops.ietf.org; Fri, 21 Oct 2005 19:51:37 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1ET2tv-0001I1-6e; Fri, 21 Oct 2005 15:50:03 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-bb-deployment-scenarios-04.txt 
Message-Id: <E1ET2tv-0001I1-6e@newodin.ietf.org>
Date: Fri, 21 Oct 2005 15:50:03 -0400
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		: ISP IPv6 Deployment Scenarios in Broadband Access Networks
	Author(s)	: S. Asadullah, et al. 
	Filename	: draft-ietf-v6ops-bb-deployment-scenarios-04.txt
	Pages		: 82
	Date		: 2005-10-21
	
This document provides detailed description of IPv6 deployment and
   integration methods and scenarios in today's Service Provider (SP)
   Broadband (BB) networks in coexistence with deployed IPv4 services.
   Cable/HFC, BB Ethernet, xDSL and WLAN are the main BB technologies
   that are currently deployed, and discussed in this document.  The
   emerging Broadband Power Line Communications (PLC/BPL) access
   technology is also discussed for completeness.  In this document we
   will discuss main components of IPv6 BB networks and their
   differences from IPv4 BB networks and how IPv6 is deployed and
   integrated in each of these BB technologies using tunneling
   mechanisms and native IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-04.txt

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


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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-bb-deployment-scenarios-04.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-v6ops-bb-deployment-scenarios-04.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




From owner-v6ops@ops.ietf.org Fri Oct 21 15:55:17 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ET2yz-0006aK-Kq
	for v6ops-archive@megatron.ietf.org; Fri, 21 Oct 2005 15:55:17 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01465
	for <v6ops-archive@lists.ietf.org>; Fri, 21 Oct 2005 15:55:06 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ET2yl-000LMl-6d
	for v6ops-data@psg.com; Fri, 21 Oct 2005 19:55:03 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ET2yj-000LLW-QL
	for v6ops@ops.ietf.org; Fri, 21 Oct 2005 19:55:02 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ET2yf-0001FU-Lp; Fri, 21 Oct 2005 20:54:57 +0100
Message-ID: <435947ED.4050207@dial.pipex.com>
Date: Fri, 21 Oct 2005 20:56:29 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "'v6ops@ops.ietf.org '" <v6ops@ops.ietf.org>
CC: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        David Kessens <david.kessens@nokia.com>
Subject: Updated draft  draft-ietf-v6ops-natpt-to-exprmntl-03 published
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi.

This draft has been taking part in a new experiment - the early copy 
editing experiment.

The experiment is being organzed by Bert Wijnen and information about 
what is going on can be found here:

  http://ops.ietf.org/ece/ and
  http://ops.ietf.org/ece/draft-bwijnen-early-copy-editing-experiment-00.txt

This document has actually been through WG Last Call already and should be headed for IETF Last Call and the IESG (Although the document is targeted for Informational it recommends reclassifying a standards track document to experimental and so is expected to go to IETF Last Call).

The object of the exercise is to get the document as close to its final form *before* it goes to the IESG so that there is minimal work for the RFC Editor (copy editing, etc) after approval. Then the AUTH48 exercise should just be a quick check rather than having to verify the RFC Editor copy edits and doing significant changes either as a consequence of the copy edits or because minor issues have been found after IETF Last Call.

In principal this should make the document more readable by the time it reaches last call (wg and IETF) and generally speed up the whole process by reducing the back end serialization of the publishing process.

As regards this document:
- the authors found three references that were unreferenced (left over from an earlier version and not noticed on subsequent edits) - xml2rfc now flags up the unreferenced items which will avoid this problem in future
- one reference (RFC3484) was unreferenced - the reference was added back in to s4.1.
- both of thse were fixed up in the intermediate version -02 which was given to the RFC editor as an xml2rfc source.
- the copy editor (Alice) did a very quick job: the majority of changes that were made were related to the author's addiction to 'which' whereas our style guide prefers 'that' for the sentence form used, plus the insertion of a fair number of commas.
- Alice picked up two things which she asked the authors to fix:
  - the phrase 'may be tempted to assume that the complex and 
    (development) time-consuming expedients' is confusing. The 
    authors decided that '(development) time consuming' was 
    gilding the lily and deleted the phrase leaving 'may be 
    tempted to assume that the complex expedients'.
  - the use of the combined acronym NA(P)T-PT:  Alice suggested 
    that this ought to be replaced with 'NAT-PT and NAPT-PT' 
    throughout.  On inspection the authors decided that there was 
    some overloading of the NAT-PT term: In most places it meant 
    'any sort of NAT-PT' (i.e., either NAT-PT or NAPT-PT) but in 
    a couple of places it meant basic NAT-PT (i.e., NOT NAPT-PT). 
    Hence we added the following note to para 2 of the intro:

       In the following discussion, where the term "NAT-PT" is used 
       unqualified, the discussion applies to both basic NAT-PT and NAPT-PT.
       "Basic NAT-PT" will be used if points apply to the basic address-only 
       translator.

    In the remainder of the document we have generally replaced 'NA(P)T-PT' 
    with 'basic NAT-PT and NAPT-PT'.  We inspected all the instances and 
    the surrounding text and some knock-on wording changes were required.

- Essentially we did one major and two minor edit cycles and the whole process was finished in three days.


Hopefully the document is now in really good shape and can progress through its remaining stages very quickly.

Please take a look at the result (version -03) which is now available on the I-D database.
If you have any general points I am sure Bert will be pleased to answer them.
If you have any comments on the process for this document or the current version of the document please contact me via the list.

Regards,
Elwyn







From owner-v6ops@ops.ietf.org Sat Oct 22 12:35:19 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETMKz-0000GU-7F
	for v6ops-archive@megatron.ietf.org; Sat, 22 Oct 2005 12:35:19 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19545
	for <v6ops-archive@lists.ietf.org>; Sat, 22 Oct 2005 12:35:04 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ETMIO-000G37-Em
	for v6ops-data@psg.com; Sat, 22 Oct 2005 16:32:36 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ETMIL-000G2q-HI
	for v6ops@ops.ietf.org; Sat, 22 Oct 2005 16:32:33 +0000
Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194])
	by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j9MGWPB28870;
	Sat, 22 Oct 2005 18:32:25 +0200
Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1])
	by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j9MGWPXd065835;
	Sat, 22 Oct 2005 18:32:26 +0200 (CEST)
	(envelope-from dupont@givry.rennes.enst-bretagne.fr)
Message-Id: <200510221632.j9MGWPXd065835@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Elwyn Davies <elwynd@dial.pipex.com>
cc: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt 
In-reply-to: Your message of Wed, 19 Oct 2005 13:32:32 BST.
             <43563CE0.4020009@dial.pipex.com> 
Date: Sat, 22 Oct 2005 18:32:25 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

 In your previous mail you wrote:

   It now covers all the messages that are currently defined for ICMPv6 and 
   is written in a format which should make it easier for administrators to 
   crate firewall rules from it.
   
   Comments would be appreciated.
   
=> if you believe I should add a reference to this I-D in the
draft-dupont-mip6-dhaadharmful-01.txt I-D where I've just added
a section about ICMPv6 filtering impact on DHAAD (written by James
Kempf), please send a note to me.

Regards

Francis.Dupont@enst-bretagne.fr

PS: my I-D will never be published as it but the ideas/arguments in it
will be in a standard track document (if they are adopted of course),
so the reference too.




From owner-v6ops@ops.ietf.org Sun Oct 23 06:26:26 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETd3a-0004vY-Pk
	for v6ops-archive@megatron.ietf.org; Sun, 23 Oct 2005 06:26:26 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26600
	for <v6ops-archive@lists.ietf.org>; Sun, 23 Oct 2005 06:26:14 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ETd00-00033k-J2
	for v6ops-data@psg.com; Sun, 23 Oct 2005 10:22:44 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ETczw-00033X-IG
	for v6ops@ops.ietf.org; Sun, 23 Oct 2005 10:22:41 +0000
Received: (qmail 7508 invoked from network); 23 Oct 2005 10:22:10 -0000
Received: from 200-70-179-82.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.179.82)
  by server.frh.utn.edu.ar with SMTP; 23 Oct 2005 10:22:10 -0000
Message-Id: <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Sun, 23 Oct 2005 05:51:02 -0300
To: Elwyn Davies <elwynd@dial.pipex.com>, v6ops@ops.ietf.org
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
In-Reply-To: <43563CE0.4020009@dial.pipex.com>
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
 <43563CE0.4020009@dial.pipex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 09:32 a.m. 19/10/2005, Elwyn Davies wrote:

>This new wg draft was published this week.  It is a substantial rewrite of 
>the individual draft which Janos and I published in July.
>
>It now covers all the messages that are currently defined for ICMPv6 and 
>is written in a format which should make it easier for administrators to 
>crate firewall rules from it.
>
>Comments would be appreciated.


A couple of issues that seem to be missing:

* There's no mention of ICMP attacks against TCP. I have authored a draft 
on this issue, along with counter-measures. You can find my internet-draft 
at http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-04.txt 
. You should probably mention the attacks, and provide a reference to my 
draft for further discussion.

* There's no mention of ingress and egress ICMP-filtering based on the 
payload of ICMP messages. You can find a description of such an "advanced" 
filtering in Section 4.3 ("Filtering ICMP error messages based on the ICMP 
payload") of my internet-draft "ICMP attacks against TCP", too.

Kindest regards,

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









From owner-v6ops@ops.ietf.org Sun Oct 23 08:09:31 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETefL-0005RY-3t
	for v6ops-archive@megatron.ietf.org; Sun, 23 Oct 2005 08:09:31 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01004
	for <v6ops-archive@lists.ietf.org>; Sun, 23 Oct 2005 08:09:17 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ETedY-000AGJ-BA
	for v6ops-data@psg.com; Sun, 23 Oct 2005 12:07:40 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ETedX-000AFx-1G
	for v6ops@ops.ietf.org; Sun, 23 Oct 2005 12:07:39 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ETedS-0005Tx-SE; Sun, 23 Oct 2005 13:07:35 +0100
Message-ID: <435B7D62.2010700@dial.pipex.com>
Date: Sun, 23 Oct 2005 13:09:06 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
CC: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org> <43563CE0.4020009@dial.pipex.com> <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar>
In-Reply-To: <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi, Fernando.

Fernando Gont wrote:

> At 09:32 a.m. 19/10/2005, Elwyn Davies wrote:
>
>> This new wg draft was published this week.  It is a substantial 
>> rewrite of the individual draft which Janos and I published in July.
>>
>> It now covers all the messages that are currently defined for ICMPv6 
>> and is written in a format which should make it easier for 
>> administrators to crate firewall rules from it.
>>
>> Comments would be appreciated.
>
>
>
> A couple of issues that seem to be missing:
>
> * There's no mention of ICMP attacks against TCP. I have authored a 
> draft on this issue, along with counter-measures. You can find my 
> internet-draft at 
> http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-04.txt 
> . You should probably mention the attacks, and provide a reference to 
> my draft for further discussion.
>
> * There's no mention of ingress and egress ICMP-filtering based on the 
> payload of ICMP messages. You can find a description of such an 
> "advanced" filtering in Section 4.3 ("Filtering ICMP error messages 
> based on the ICMP payload") of my internet-draft "ICMP attacks against 
> TCP", too.
>
Denial of service attacks via error messages are covered in s3.1 (I 
believe the attacks covered in your draft fall into this category). 

After your previous message on this subject, I did mention the 
possibility of deep packet inspection looking at the embedded packet 
(s4.1, next to last paragraph) and that this was relevant to the TCP 
attacks you describe.  However, this draft is specifically about 
firewall rules and the firewall would have to do quite heavy work on the 
packet to implement this sort of rule - not all firewalls are 
ncecessarily capable of this.  If the firewall can carry out the checks 
then they shuld apply to error messages for any sort of transport and 
not just TCP.  Also if the embedded packet is encrypted, it would not be 
possible to tell that it was specifically a TCP packet.   On the other 
hand end hosts should certainly do the verification as mentioned in your 
draft as is implied by the words in s4.1.

As regards referencing the draft, I did consider this: it would be 
possible but it would preferable if it was clear that it was going to 
become an RFC.  I notice that the current version of the draft has 
expired... are you making any moves to either have this adopted as a wg 
draft or get it published as an individual submission RFC.  I would 
suggest you talk to either Margaret Wasserman (covering the ipv6 group) 
or David Kessens (v6ops) to see if you can have it published as an 
individual submission via AD since it is pretty much complete and the 
IPv6 wg is currently winding down and maybe reluctant to take on new work.

Regards,
Elwyn

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




From owner-v6ops@ops.ietf.org Sun Oct 23 13:23:35 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETjZG-0004PC-Kv
	for v6ops-archive@megatron.ietf.org; Sun, 23 Oct 2005 13:23:35 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16246
	for <v6ops-archive@lists.ietf.org>; Sun, 23 Oct 2005 13:23:21 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ETjWk-00044G-3e
	for v6ops-data@psg.com; Sun, 23 Oct 2005 17:20:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1ETjWh-00043x-Ff
	for v6ops@ops.ietf.org; Sun, 23 Oct 2005 17:20:56 +0000
Received: (qmail 9274 invoked from network); 23 Oct 2005 17:20:18 -0000
Received: from 200-70-177-15.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.177.15)
  by server.frh.utn.edu.ar with SMTP; 23 Oct 2005 17:20:18 -0000
Message-Id: <6.2.0.14.0.20051023125926.05b5c6b0@pop.frh.utn.edu.ar>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Sun, 23 Oct 2005 13:56:12 -0300
To: Elwyn Davies <elwynd@dial.pipex.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
Cc: v6ops@ops.ietf.org
In-Reply-To: <435B7D62.2010700@dial.pipex.com>
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
 <43563CE0.4020009@dial.pipex.com>
 <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar>
 <435B7D62.2010700@dial.pipex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 09:09 a.m. 23/10/2005, Elwyn Davies wrote:

>Denial of service attacks via error messages are covered in s3.1 (I 
>believe the attacks covered in your draft fall into this category).

Yes, but that section basically mentions only blind connection-reset 
attacks. The attacks discussed in my draft can be performed not only 
against TCP, but against similar protocols such as SCTP, too.



>After your previous message on this subject, I did mention the possibility 
>of deep packet inspection looking at the embedded packet (s4.1, next to 
>last paragraph) and that this was relevant to the TCP attacks you describe.

While the draft mentions deep packet inspection, it still does not mention 
ingress and egress filtering based on the IP address contained in the ICMP 
payload. If you receive a packet from your local network, and the IP 
address contained in the ICMP payload claims to be from a network that you 
know you are not connecting to the Internet, you should drop it. Also, if 
you receive a packet from the Internet which contains in the ICMP payload a 
source IP address which belongs to the network you are providing 
connectivity, you should drop it.

This simple policy helps *a* *lot* to prevent ICMP attacks against 
transport protocols such as TCP.



>However, this draft is specifically about firewall rules and the firewall 
>would have to do quite heavy work on the packet to implement this sort of 
>rule - not all firewalls are ncecessarily capable of this.

Note that the firewall needs not keep per-conenction state to perform the 
checks I mentioned.



>If the firewall can carry out the checks then they shuld apply to error 
>messages for any sort of transport and not just TCP.

Correct. But this ingress and egress filtering policy is not TCP-specific, 
but general. Not that it does not require per-connection state, and thus it 
does not require firewalls to be able to parse the transport protocol headers.


>Also if the embedded packet is encrypted, it would not be possible to tell 
>that it was specifically a TCP packet.

Well, you need not know it to filter it.



>As regards referencing the draft, I did consider this: it would be 
>possible but it would preferable if it was clear that it was going to 
>become an RFC.

As to whether it is clear it will become an RFC, I hope and think so. 
However, I'm not sure this is relevant. If I submitted the draft directly 
to the RFC Editor to publish it as Informational, the processing backlog 
might be long enough to be certain.



>I notice that the current version of the draft has expired...

No, current version is -05, and has been available since September 5th.



>are you making any moves to either have this adopted as a wg draft or get 
>it published as an individual submission RFC.

Yes, I will be presenting the draft at the next IETF, in the TCPM WG 
meeting. Pekka Savola presented this draft at IETF 62, too.
And this draft has probably been the most discussed draft at the TCPM WG 
mailing list since August 2004.

The draft has even received support from the IAB in their document 
"Architectural Implications of Link Indications" 
(draft-iab-link-indications-03). And is referenced in the current ICMPv6 draft.



>I would suggest you talk to either Margaret Wasserman (covering the ipv6 
>group) or David Kessens (v6ops) to see if you can have it published as an 
>individual submission via AD since it is pretty much complete and the IPv6 
>wg is currently winding down and maybe reluctant to take on new work.

Thanks for your comments. We are still discussing the draft at the TCPM WG, 
and I hope it becomes a WG item in the next IETF.

Not to mention that if your schedule allows you, I'd appreciate if you 
could be present at that meeting. It would certainly help to move things 
forward. We will also be discussing draft-gont-tcpm-tcp-soft-errors-02.txt, 
which originated in this WG (v6ops), and is still being argued against at 
the TCPM WG.

Kindest regards,

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









From owner-v6ops@ops.ietf.org Sun Oct 23 14:13:46 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1ETkLp-0003Ov-BZ
	for v6ops-archive@megatron.ietf.org; Sun, 23 Oct 2005 14:13:46 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18342
	for <v6ops-archive@lists.ietf.org>; Sun, 23 Oct 2005 14:13:31 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1ETkL4-0007Q7-LB
	for v6ops-data@psg.com; Sun, 23 Oct 2005 18:12:58 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1ETkL3-0007Pt-8l
	for v6ops@ops.ietf.org; Sun, 23 Oct 2005 18:12:57 +0000
Received: from [81.187.254.247] (helo=[127.0.0.1])
	by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.43)
	id 1ETkKy-0003JK-3p; Sun, 23 Oct 2005 19:12:52 +0100
Message-ID: <435BD300.1050607@dial.pipex.com>
Date: Sun, 23 Oct 2005 19:14:24 +0100
From: Elwyn Davies <elwynd@dial.pipex.com>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Fernando Gont <fernando@gont.com.ar>
CC: v6ops@ops.ietf.org
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org> <43563CE0.4020009@dial.pipex.com> <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar> <435B7D62.2010700@dial.pipex.com> <6.2.0.14.0.20051023125926.05b5c6b0@pop.frh.utn.edu.ar>
In-Reply-To: <6.2.0.14.0.20051023125926.05b5c6b0@pop.frh.utn.edu.ar>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
Content-Transfer-Encoding: 7bit



Fernando Gont wrote:

> At 09:09 a.m. 23/10/2005, Elwyn Davies wrote:
>
>> Denial of service attacks via error messages are covered in s3.1 (I 
>> believe the attacks covered in your draft fall into this category).
>
>
> Yes, but that section basically mentions only blind connection-reset 
> attacks. The attacks discussed in my draft can be performed not only 
> against TCP, but against similar protocols such as SCTP, too.

I am not currently very specific about what DoS attacks can be made.  
The wording is not exclusive and covers any sort of DoS attack that can 
be made with ICMPv6.

It is possible that we should be more comprehensive about the attacks 
that could be made via ICMPv6 but maybe this should be in the security 
overview document rather than here.  That document has been through last 
call but is still just about open for comments.. take a look.

>
>
>
>> After your previous message on this subject, I did mention the 
>> possibility of deep packet inspection looking at the embedded packet 
>> (s4.1, next to last paragraph) and that this was relevant to the TCP 
>> attacks you describe.
>
>
> While the draft mentions deep packet inspection, it still does not 
> mention ingress and egress filtering based on the IP address contained 
> in the ICMP payload. If you receive a packet from your local network, 
> and the IP address contained in the ICMP payload claims to be from a 
> network that you know you are not connecting to the Internet, you 
> should drop it. Also, if you receive a packet from the Internet which 
> contains in the ICMP payload a source IP address which belongs to the 
> network you are providing connectivity, you should drop it.
>
> This simple policy helps *a* *lot* to prevent ICMP attacks against 
> transport protocols such as TCP

I appreciate that it will help and I believe we are pointing up the problem.
.
We don't use the words ingress and egress filtering (after all the whole 
of s4.2 is about ingress and egress filtering) but we are saying that if 
your firewall is up to it, it should look at the embedded packet and 
check it has sensible addresses.  Are you saying we should try to do 
more?  If so just what are we to do?  I think the firewall can only do 
more if it is retaining state about packets in the opposite direction 
and not every firewall can do that.

One thing that would perhaps help is to put a pointer in s4.2.1 to the 
additional discussion in s4.1 to remind admins  that *if* your firewall 
can handle it you can go the extra distance..

Regards,
Elwyn

>
>
>
>> However, this draft is specifically about firewall rules and the 
>> firewall would have to do quite heavy work on the packet to implement 
>> this sort of rule - not all firewalls are ncecessarily capable of this.
>
>
> Note that the firewall needs not keep per-conenction state to perform 
> the checks I mentioned.
>
>
>
>> If the firewall can carry out the checks then they shuld apply to 
>> error messages for any sort of transport and not just TCP.
>
>
> Correct. But this ingress and egress filtering policy is not 
> TCP-specific, but general. Not that it does not require per-connection 
> state, and thus it does not require firewalls to be able to parse the 
> transport protocol headers.
>
>
>> Also if the embedded packet is encrypted, it would not be possible to 
>> tell that it was specifically a TCP packet.
>
>
> Well, you need not know it to filter it.
>
>
>
>> As regards referencing the draft, I did consider this: it would be 
>> possible but it would preferable if it was clear that it was going to 
>> become an RFC.
>
>
> As to whether it is clear it will become an RFC, I hope and think so. 
> However, I'm not sure this is relevant. If I submitted the draft 
> directly to the RFC Editor to publish it as Informational, the 
> processing backlog might be long enough to be certain.
>
>
>
>> I notice that the current version of the draft has expired...
>
>
> No, current version is -05, and has been available since September 5th.
>
>
>
>> are you making any moves to either have this adopted as a wg draft or 
>> get it published as an individual submission RFC.
>
>
> Yes, I will be presenting the draft at the next IETF, in the TCPM WG 
> meeting. Pekka Savola presented this draft at IETF 62, too.
> And this draft has probably been the most discussed draft at the TCPM 
> WG mailing list since August 2004.
>
> The draft has even received support from the IAB in their document 
> "Architectural Implications of Link Indications" 
> (draft-iab-link-indications-03). And is referenced in the current 
> ICMPv6 draft.
>
>
>
>> I would suggest you talk to either Margaret Wasserman (covering the 
>> ipv6 group) or David Kessens (v6ops) to see if you can have it 
>> published as an individual submission via AD since it is pretty much 
>> complete and the IPv6 wg is currently winding down and maybe 
>> reluctant to take on new work.
>
>
> Thanks for your comments. We are still discussing the draft at the 
> TCPM WG, and I hope it becomes a WG item in the next IETF.
>
> Not to mention that if your schedule allows you, I'd appreciate if you 
> could be present at that meeting. It would certainly help to move 
> things forward. We will also be discussing 
> draft-gont-tcpm-tcp-soft-errors-02.txt, which originated in this WG 
> (v6ops), and is still being argued against at the TCPM WG.
>
> Kindest regards,
>
> -- 
> Fernando Gont
> e-mail: fernando@gont.com.ar || fgont@acm.org
>
>
>
>
>




From owner-v6ops@ops.ietf.org Mon Oct 24 11:37:25 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EU4O5-0006t9-Jv
	for v6ops-archive@megatron.ietf.org; Mon, 24 Oct 2005 11:37:25 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15884
	for <v6ops-archive@lists.ietf.org>; Mon, 24 Oct 2005 11:37:12 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EU4K7-0008TF-33
	for v6ops-data@psg.com; Mon, 24 Oct 2005 15:33:19 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO 
	autolearn=ham version=3.1.0
Received: from [170.210.17.146] (helo=server.frh.utn.edu.ar)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EU4K3-0008S5-Fx
	for v6ops@ops.ietf.org; Mon, 24 Oct 2005 15:33:18 +0000
Received: (qmail 27401 invoked from network); 24 Oct 2005 15:32:28 -0000
Received: from 200-70-145-28.mrse.com.ar (HELO fgont.gont.com.ar) (gont-fernando@200.70.145.28)
  by server.frh.utn.edu.ar with SMTP; 24 Oct 2005 15:32:28 -0000
Message-Id: <6.2.0.14.0.20051023170909.01d63748@pop.frh.utn.edu.ar>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Mon, 24 Oct 2005 12:29:55 -0300
To: Elwyn Davies <elwynd@dial.pipex.com>
From: Fernando Gont <fernando@gont.com.ar>
Subject: Re: I-D ACTION:draft-ietf-v6ops-icmpv6-filtering-bcp-00.txt
Cc: v6ops@ops.ietf.org
In-Reply-To: <435BD300.1050607@dial.pipex.com>
References: <E1ERazi-0005Jy-Cc@newodin.ietf.org>
 <43563CE0.4020009@dial.pipex.com>
 <6.2.0.14.0.20051023055004.05db6f50@pop.frh.utn.edu.ar>
 <435B7D62.2010700@dial.pipex.com>
 <6.2.0.14.0.20051023125926.05b5c6b0@pop.frh.utn.edu.ar>
 <435BD300.1050607@dial.pipex.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

At 03:14 p.m. 23/10/2005, Elwyn Davies wrote:

>>>Denial of service attacks via error messages are covered in s3.1 (I 
>>>believe the attacks covered in your draft fall into this category).
>>
>>
>>Yes, but that section basically mentions only blind connection-reset 
>>attacks. The attacks discussed in my draft can be performed not only 
>>against TCP, but against similar protocols such as SCTP, too.
>
>I am not currently very specific about what DoS attacks can be made.
>The wording is not exclusive and covers any sort of DoS attack that can be 
>made with ICMPv6.
>
>It is possible that we should be more comprehensive about the attacks that 
>could be made via ICMPv6 but maybe this should be in the security overview 
>document rather than here.

My feedback was based on the perception that there was a more 
extensive/explicit discussion of redirect attacks, for example.



>That document has been through last call but is still just about open for 
>comments.. take a look.

I will have a look at the security overview document.



>>While the draft mentions deep packet inspection, it still does not 
>>mention ingress and egress filtering based on the IP address contained in 
>>the ICMP payload. If you receive a packet from your local network, and 
>>the IP address contained in the ICMP payload claims to be from a network 
>>that you know you are not connecting to the Internet, you should drop it. 
>>Also, if you receive a packet from the Internet which contains in the 
>>ICMP payload a source IP address which belongs to the network you are 
>>providing connectivity, you should drop it.
>>
>>This simple policy helps *a* *lot* to prevent ICMP attacks against 
>>transport protocols such as TCP
>
>I appreciate that it will help and I believe we are pointing up the problem.
>.
>We don't use the words ingress and egress filtering (after all the whole 
>of s4.2 is about ingress and egress filtering) but we are saying that if 
>your firewall is up to it, it should look at the embedded packet and check 
>it has sensible addresses.  Are you saying we should try to do more?  If 
>so just what are we to do?  I think the firewall can only do more if it is 
>retaining state about packets in the opposite direction and not every 
>firewall can do that.

My impression was that you only recommend deep packet inspection as part of 
stateful inspection.

Also, it's not clear to me that the draft proposes to filter those ICMP 
packets whose payloads contain an IP packet with a source address that does 
not correspond to any of the networks to which the router/firewall is 
providing connectivity.

e.g., my faculty's network is 170.210.17.0/24. If the source IP address of 
the payload of an ICMP error message does not correspond to that network, 
the faculty's firewall won't let the ICMP error message go out to the Internet.

That's what I think is missing in your document, or, at least, not very 
explicit.


>One thing that would perhaps help is to put a pointer in s4.2.1 to the 
>additional discussion in s4.1 to remind admins  that *if* your firewall 
>can handle it you can go the extra distance..

Note that the check I'm describing does not need the firewall to keep state.

Kindest regards,

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









From owner-v6ops@ops.ietf.org Tue Oct 25 10:52:47 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EUQAR-0004Iy-L3
	for v6ops-archive@megatron.ietf.org; Tue, 25 Oct 2005 10:52:47 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21804
	for <v6ops-archive@lists.ietf.org>; Tue, 25 Oct 2005 10:52:32 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EUQ7o-000OJO-Rv
	for v6ops-data@psg.com; Tue, 25 Oct 2005 14:50:04 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,
	MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.0
Received: from [132.151.6.50] (helo=newodin.ietf.org)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1EUQ7n-000OIW-7e
	for v6ops@ops.ietf.org; Tue, 25 Oct 2005 14:50:04 +0000
Received: from mlee by newodin.ietf.org with local (Exim 4.43)
	id 1EUQ7m-0004pw-2K; Tue, 25 Oct 2005 10:50:02 -0400
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: i-d-announce@ietf.org
Cc: v6ops@ops.ietf.org
From: Internet-Drafts@ietf.org
Subject: I-D ACTION:draft-ietf-v6ops-nap-02.txt 
Message-Id: <E1EUQ7m-0004pw-2K@newodin.ietf.org>
Date: Tue, 25 Oct 2005 10:50:02 -0400
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		: IPv6 Network Architecture Protection
	Author(s)	: G. Van de Velde, et al.
	Filename	: draft-ietf-v6ops-nap-02.txt
	Pages		: 36
	Date		: 2005-10-25
	
Although there are many perceived benefits to Network Address
   Translation (NAT), its primary benefit of "amplifying" available
   address space is not needed in IPv6.  In addition to NAT's many
   serious disadvantages, there is a perception that other benefits
   exist, such as a variety of management and security attributes that
   could be useful for an Internet Protocol site.  IPv6 does not support
   NAT by design and this document shows how Network Architecture
   Protection (NAP) using IPv6 can provide the same or more benefits
   without the need for NAT.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-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-nap-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-nap-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-v6ops-nap-02.txt

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

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

--OtherAccess--

--NextPart--




From owner-v6ops@ops.ietf.org Fri Oct 28 05:08:10 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVQDa-00005K-1j
	for v6ops-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:08:10 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02938
	for <v6ops-archive@lists.ietf.org>; Fri, 28 Oct 2005 05:07:53 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EVQB5-000EUs-H4
	for v6ops-data@psg.com; Fri, 28 Oct 2005 09:05:35 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [152.78.68.161] (helo=peewit.ecs.soton.ac.uk)
	by psg.com with esmtps (TLSv1:AES256-SHA:256)
	(Exim 4.52 (FreeBSD))
	id 1EVQB4-000EUX-Ij
	for v6ops@ops.ietf.org; Fri, 28 Oct 2005 09:05:34 +0000
Received: from login.ecs.soton.ac.uk (login.ecs.soton.ac.uk [IPv6:2001:630:d0:f102:230:48ff:fe23:58df])
	by peewit.ecs.soton.ac.uk (8.13.1/8.13.1) with ESMTP id j9S95Rvu008146
	for <v6ops@ops.ietf.org>; Fri, 28 Oct 2005 10:05:27 +0100
Received: (from tjc@localhost)
	by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j9S95Qu19978
	for v6ops@ops.ietf.org; Fri, 28 Oct 2005 10:05:26 +0100
Date: Fri, 28 Oct 2005 10:05:26 +0100
From: Tim Chown <tjc@ecs.soton.ac.uk>
To: v6ops@ops.ietf.org
Subject: draft-chown-v6ops-port-scanning-implications-02
Message-ID: <20051028090526.GT17444@login.ecs.soton.ac.uk>
Mail-Followup-To: v6ops@ops.ietf.org
References: <200510280850.j9S8oeH2004731@peewit.ecs.soton.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200510280850.j9S8oeH2004731@peewit.ecs.soton.ac.uk>
User-Agent: Mutt/1.4i
X-ECS-MailScanner-Information: Please contact the ISP for more information
X-ECS-MailScanner: Found to be clean
X-ECS-MailScanner-From: tjc@smtp.ecs.soton.ac.uk
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi,

This draft has been resurrected since it is cited by Elwyn in two other (WG)
drafts.   It would be useful to have a slot in Vancouver to discuss whether
it should be progressed or the key point absorbed into both of the drafts
currently citing it.

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 	Title		: IPv6 Implications for TCP/UDP Port Scanning
> 	Author(s)	: T. Chown
> 	Filename	: draft-chown-v6ops-port-scanning-implications-02.txt
> 	Pages		: 9
> 	Date		: 2005-10-27
> 	
> The 128 bits of IPv6 address space is considerably bigger than the 32
>    bits of address space in IPv4.  In particular, the IPv6 subnets to
>    which hosts attach will by default have 64 bits of host address
>    space.  As a result, traditional methods of remote TCP or UDP port
>    scanning to discover open or running services on a host will
>    potentially become far less computationally feasible, due to the
>    larger search space in the subnet.  This document discusses that
>    property of IPv6 subnets, and describes related issues for site
>    administrators of IPv6 networks to consider, which may be of
>    importance when planning site address allocation and management
>    strategies.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-chown-v6ops-port-scanning-implications-02.txt


-- 
Tim/::1






From owner-v6ops@ops.ietf.org Fri Oct 28 05:22:21 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVQRJ-0006f0-Ee
	for v6ops-archive@megatron.ietf.org; Fri, 28 Oct 2005 05:22:21 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03543
	for <v6ops-archive@lists.ietf.org>; Fri, 28 Oct 2005 05:22:04 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EVQQh-000FwC-BQ
	for v6ops-data@psg.com; Fri, 28 Oct 2005 09:21:43 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EVQQg-000Fvp-9p
	for v6ops@ops.ietf.org; Fri, 28 Oct 2005 09:21:42 +0000
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9S9Lfa18242;
	Fri, 28 Oct 2005 11:21:41 +0200 (CEST)
Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp4232.cisco.com [10.61.80.135])
	by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j9S9LeC15309;
	Fri, 28 Oct 2005 11:21:40 +0200 (CEST)
Message-Id: <4.3.2.7.2.20051028111126.039084f0@strange-brew>
X-Sender: gvandeve@strange-brew
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 28 Oct 2005 11:21:27 +0200
To: Tim Chown <tjc@ecs.soton.ac.uk>
From: "Gunter Van de Velde (gvandeve)" <gvandeve@cisco.com>
Subject: Re: draft-chown-v6ops-port-scanning-implications-02
Cc: v6ops@ops.ietf.org
In-Reply-To: <20051028090526.GT17444@login.ecs.soton.ac.uk>
References: <200510280850.j9S8oeH2004731@peewit.ecs.soton.ac.uk>
 <200510280850.j9S8oeH2004731@peewit.ecs.soton.ac.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

Hi Tim,

I would prefer to see independent work on the port scanning implications 
document, as
there might be more future documents that may refer to this work.

The scope/vision of NAP is quite different from what the port-scanning 
draft wants to achieve
and i see it as being a great piece of reference work outside of NAP. The 
reference
is included in the *-nap-02.txt document already. Hence i would like to see 
port-scanning
become a separate piece of work for the WG.

<snip>
[18] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning (chown- v6ops- 
port-scanning-implications-01.txt)", July 2004.
<end snip>

Groetjes,
G/

At 10:05 28/10/2005 +0100, Tim Chown wrote:
>Hi,
>
>This draft has been resurrected since it is cited by Elwyn in two other (WG)
>drafts.   It would be useful to have a slot in Vancouver to discuss whether
>it should be progressed or the key point absorbed into both of the drafts
>currently citing it.
>
> > A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> >       Title           : IPv6 Implications for TCP/UDP Port Scanning
> >       Author(s)       : T. Chown
> >       Filename        : draft-chown-v6ops-port-scanning-implications-02.txt
> >       Pages           : 9
> >       Date            : 2005-10-27
> >
> > The 128 bits of IPv6 address space is considerably bigger than the 32
> >    bits of address space in IPv4.  In particular, the IPv6 subnets to
> >    which hosts attach will by default have 64 bits of host address
> >    space.  As a result, traditional methods of remote TCP or UDP port
> >    scanning to discover open or running services on a host will
> >    potentially become far less computationally feasible, due to the
> >    larger search space in the subnet.  This document discusses that
> >    property of IPv6 subnets, and describes related issues for site
> >    administrators of IPv6 networks to consider, which may be of
> >    importance when planning site address allocation and management
> >    strategies.
> >
> > A URL for this Internet-Draft is:
> > 
> http://www.ietf.org/internet-drafts/draft-chown-v6ops-port-scanning-implications-02.txt
>
>
>--
>Tim/::1





From owner-v6ops@ops.ietf.org Fri Oct 28 12:22:53 2005
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.32)
	id 1EVX0H-0000ws-4G
	for v6ops-archive@megatron.ietf.org; Fri, 28 Oct 2005 12:22:53 -0400
Received: from psg.com (mailnull@psg.com [147.28.0.62])
	by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27325
	for <v6ops-archive@lists.ietf.org>; Fri, 28 Oct 2005 12:22:36 -0400 (EDT)
Received: from majordom by psg.com with local (Exim 4.52 (FreeBSD))
	id 1EVWy9-000DzK-AG
	for v6ops-data@psg.com; Fri, 28 Oct 2005 16:20:41 +0000
X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on psg.com
X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham 
	version=3.1.0
Received: from [193.94.160.1] (helo=netcore.fi)
	by psg.com with esmtp (Exim 4.52 (FreeBSD))
	id 1EVWy8-000Dyv-5o
	for v6ops@ops.ietf.org; Fri, 28 Oct 2005 16:20:40 +0000
Received: from localhost (pekkas@localhost)
	by netcore.fi (8.11.6/8.11.6) with ESMTP id j9SGKcX29405
	for <v6ops@ops.ietf.org>; Fri, 28 Oct 2005 19:20:38 +0300
Date: Fri, 28 Oct 2005 19:20:38 +0300 (EEST)
From: Pekka Savola <pekkas@netcore.fi>
To: v6ops@ops.ietf.org
Subject: Re: draft-chown-v6ops-port-scanning-implications-02
In-Reply-To: <20051028090526.GT17444@login.ecs.soton.ac.uk>
Message-ID: <Pine.LNX.4.64.0510281919450.29191@netcore.fi>
References: <200510280850.j9S8oeH2004731@peewit.ecs.soton.ac.uk>
 <20051028090526.GT17444@login.ecs.soton.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk

On Fri, 28 Oct 2005, Tim Chown wrote:
> This draft has been resurrected since it is cited by Elwyn in two other (WG)
> drafts.   It would be useful to have a slot in Vancouver to discuss whether
> it should be progressed or the key point absorbed into both of the drafts
> currently citing it.

I also believe this is a very useful work item.

However, as it has been around for a long time, I believe that if we 
take it up, we'll need to make quick progress.

>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> 	Title		: IPv6 Implications for TCP/UDP Port Scanning
>> 	Author(s)	: T. Chown
>> 	Filename	: draft-chown-v6ops-port-scanning-implications-02.txt
>> 	Pages		: 9
>> 	Date		: 2005-10-27
>>
>> The 128 bits of IPv6 address space is considerably bigger than the 32
>>    bits of address space in IPv4.  In particular, the IPv6 subnets to
>>    which hosts attach will by default have 64 bits of host address
>>    space.  As a result, traditional methods of remote TCP or UDP port
>>    scanning to discover open or running services on a host will
>>    potentially become far less computationally feasible, due to the
>>    larger search space in the subnet.  This document discusses that
>>    property of IPv6 subnets, and describes related issues for site
>>    administrators of IPv6 networks to consider, which may be of
>>    importance when planning site address allocation and management
>>    strategies.
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-chown-v6ops-port-scanning-implications-02.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