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 ; 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: 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

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-- ------=_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 ; 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" To: "Fred Baker" Cc: 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 ; 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 To: "Templin, Fred L" 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 ; 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: Cc: v6ops@ops.ietf.org, Matt Mathis Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance Date: Wed, 5 Oct 2005 13:33:55 -0700 To: "Templin, Fred L" 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| 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 ; 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" To: "Fred Baker" Cc: , "Matt Mathis" 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 ; 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: , "Matt Mathis" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance Date: Wed, 5 Oct 2005 17:36:39 -0700 To: "Templin, Fred L" 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| 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 ; 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" To: "Fred Baker" Cc: , "Matt Mathis" 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 ; 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: Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance thread-index: AcXJ7CwbnBxWHUiHR8G9L2DOYzHOWgAAeJmQAA5unaA= From: "Christian Huitema" To: "Templin, Fred L" , "Fred Baker" Cc: , "Matt Mathis" 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 ; 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: 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 ; 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" To: "Christian Huitema" , "Fred Baker" Cc: , "Matt Mathis" 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 ; 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 ; 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 ; 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: Content-Transfer-Encoding: 7bit From: Fred Baker 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| 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 > Date: October 6, 2005 8:33:21 AM PDT > To: Fred Baker , Kurt Erik Lindqvist > > 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 ; 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: , "Matt Mathis" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance Date: Thu, 6 Oct 2005 14:29:19 -0700 To: "Templin, Fred L" 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| 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 ; 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 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> In-Reply-To: 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 >> Date: October 6, 2005 8:33:21 AM PDT >> To: Fred Baker , Kurt Erik Lindqvist >> >> 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 ; 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" To: "Fred Baker" Cc: , "Matt Mathis" 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 ; 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: , "Matt Mathis" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance Date: Fri, 7 Oct 2005 08:51:51 -0700 To: "Templin, Fred L" 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| 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 ; 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" To: "Fred Baker" Cc: , "Matt Mathis" 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 ; 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: Thread-Topic: Requirements for IP-in-IP Tunnel MTU Assurance thread-index: AcXKwLlb/iWZVC44Qp+7B3C3J1/E6AAu9Flg From: "Christian Huitema" To: "Matt Mathis" Cc: "Templin, Fred L" , "Fred Baker" , 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 ; 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 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 CC: Matt Mathis , "Templin, Fred L" , Fred Baker , v6ops@ops.ietf.org Subject: Re: Requirements for IP-in-IP Tunnel MTU Assurance References: In-Reply-To: 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 ; 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: Cc: Lindqvist Erik Kurt , David Kessens Content-Transfer-Encoding: 7bit From: Fred Baker 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 ; 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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker CC: v6ops@ops.ietf.org, Lindqvist Erik Kurt , David Kessens Subject: Re: Time to put together an agenda References: In-Reply-To: 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 ; 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" To: "Fred Baker" , Cc: "Lindqvist Erik Kurt" , "David Kessens" 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 ; 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 ; 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 To: Fred Baker , "v6ops@ops.ietf.org" CC: Kurt Erik Lindqvist , David Kessens Message-ID: Thread-Topic: Time to put together an agenda Thread-Index: AcXSnHdotb8Pfj6PEdqQXQAKldLC/g== In-Reply-To: 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 > Responder a: > Fecha: Wed, 12 Oct 2005 03:45:17 -0400 > Para: "v6ops@ops.ietf.org" > CC: Lindqvist Erik Kurt , David Kessens > > 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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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 > Responder a: > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > Para: > CC: "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 ; 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" To: , 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 > Responder a: > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > Para: > CC: "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 ; 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 To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: Message-ID: 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 ; 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 To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: Message-ID: 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 > > Responder a: > > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > > Para: > > CC: "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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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" > Responder a: > Fecha: Sun, 16 Oct 2005 19:10:47 -0400 > Para: , > 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 >> Responder a: >> Fecha: Mon, 15 Aug 2005 14:47:02 -0700 >> Para: >> CC: "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 ; 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 ; 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 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 ; 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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'v6ops@ops.ietf.org '" CC: "Wijnen, Bert (Bert)" , Cedric Aoun 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 ; 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: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: JORDI PALET MARTINEZ , "v6ops@ops.ietf.org" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Mon, 17 Oct 2005 05:34:07 -0700 To: shogunx 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 ; 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 Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Mon, 17 Oct 2005 07:08:22 -0700 To: Tim Chown 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| 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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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 > Responder a: > Fecha: Mon, 17 Oct 2005 07:08:22 -0700 > Para: Tim Chown > CC: "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 ; 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 To: Fred Baker cc: JORDI PALET MARTINEZ , "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: Message-ID: 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 ; 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 To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: Message-ID: 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 ; 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: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: JORDI PALET MARTINEZ , "v6ops@ops.ietf.org" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Mon, 17 Oct 2005 05:34:07 -0700 To: shogunx 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 ; 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 ; 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 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 ; 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 ; 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 To: Fred Baker , "v6ops@ops.ietf.org" CC: Kurt Erik Lindqvist , David Kessens Message-ID: Thread-Topic: Time to put together an agenda Thread-Index: AcXSnHdotb8Pfj6PEdqQXQAKldLC/g== In-Reply-To: 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 > Responder a: > Fecha: Wed, 12 Oct 2005 03:45:17 -0400 > Para: "v6ops@ops.ietf.org" > CC: Lindqvist Erik Kurt , David Kessens > > 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 ; 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: References: Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "v6ops@ops.ietf.org" , Kurt Erik Lindqvist , David Kessens Content-Transfer-Encoding: 7bit From: Fred Baker 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| 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 >> Responder a: >> Fecha: Wed, 12 Oct 2005 03:45:17 -0400 >> Para: "v6ops@ops.ietf.org" >> CC: Lindqvist Erik Kurt , David Kessens >> >> 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 ; 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 To: jordi.palet@consulintel.es Cc: v6ops@ops.ietf.org In-Reply-To: References: 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 ; 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 User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'v6ops@ops.ietf.org '" CC: "Wijnen, Bert (Bert)" , Cedric Aoun 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 ; 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: 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 ; 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: 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 ; 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 ; 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 From: Salman Asadullah Subject: Re: Time to put together an agenda Cc: v6ops@ops.ietf.org In-Reply-To: <434D4633.601@dial.pipex.com> References:

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" 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-- 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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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 > Organizaci=F3n: Unfix > Responder a: > Fecha: Mon, 17 Oct 2005 21:37:56 +0200 > Para: > CC: "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 ; 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 To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: Message-ID: 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 > > Responder a: > > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > > Para: > > CC: "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 ; 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" To: , 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 > Responder a: > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > Para: > CC: "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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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" > Responder a: > Fecha: Sun, 16 Oct 2005 19:10:47 -0400 > Para: , > 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 >> Responder a: >> Fecha: Mon, 15 Aug 2005 14:47:02 -0700 >> Para: >> CC: "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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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 > Responder a: > Fecha: Mon, 15 Aug 2005 14:47:02 -0700 > Para: > CC: "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 ; 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:

<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 Subject: Re: Time to put together an agenda Date: Mon, 17 Oct 2005 16:16:38 -0700 To: Salman Asadullah 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| 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 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-- 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 ; 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 To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" In-Reply-To: References: 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 ; 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 ; 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 To: "v6ops@ops.ietf.org" Message-ID: 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 > Organizaci=F3n: Unfix > Responder a: > Fecha: Tue, 18 Oct 2005 09:46:53 +0200 > Para: > CC: "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 ; 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 To: jordi.palet@consulintel.es Cc: "v6ops@ops.ietf.org" In-Reply-To: References: 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 ; 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 From: "Gunter Van de Velde (gvandeve)" Subject: Re: Time to put together an agenda Cc: v6ops@ops.ietf.org, Lindqvist Erik Kurt , David Kessens In-Reply-To: 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 ; 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 To: JORDI PALET MARTINEZ cc: "v6ops@ops.ietf.org" Subject: mailing list loop at flarion.com [Re: Time to put together an agenda] In-Reply-To: Message-ID: References: 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 ; 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 ; 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 From: Salman Asadullah 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>

<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" 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-- 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 ; 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>

<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 Subject: Re: Time to put together an agenda Date: Tue, 18 Oct 2005 09:50:09 -0700 To: Salman Asadullah 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| 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 then=A0that 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-- 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 ; 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 ; 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 From: Salman Asadullah 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>

<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" 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-- 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 ; 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: Thread-Topic: mailing list loop at flarion.com [Re: Time to put together an agenda] Thread-Index: AcXUBP09lk+CruxWTv2R0Dk1e4s2KQAAd7wQ From: "Soliman, Hesham" To: "Pekka Savola" , "JORDI PALET MARTINEZ" CC: 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 ; 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 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: In-Reply-To: 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 ; 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

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-- ------=_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 ; 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: 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 ; 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 From: "Gunter Van de Velde (gvandeve)" 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 At 09:33 2/09/2005 +0100, Tim Chown wrote:

Issue 24 - so what text will you use? :)

In the background Elwyn worked with us on this aspect. The
text to replace Ch4.4 is below. We feel that text looks more balanced now.
This replacement text will be in the NAP-02 draft.

<snip>
4.4. Privacy and Topology Hiding using IPv6

   Partial host privacy is achieved in IPv6 using pseudo-random privacy
   addresses [RFC 3041] which are generated as required, so that a
   session can use an address that is valid only for a limited time.
   Exactly as with IPv4 NAT, this only allows such a session to be
   traced back to the subnet that originates it, but not immediately to
   the actual host.

   Due to the large IPv6 address space available there is plenty of
   freedom to randomize subnet allocations. By doing this, it is
   possible to reduce the correlation between a subnet and its location.
   When doing both subnet and IID randomization [RFC 3041] a casual
   snooper won't be able to deduce much about the networks topology.
   The obtaining of a single address will tell the snooper very little
   about other addresses. This is different from IPv4 where address
   space limitations cause this to be not true. In most usage cases
   this concept should be sufficient for address privacy and topology
   hiding.

   In the case where a network administrator wishes to fully conceal the
   internal IPv6 topology, and the majority of its host computer
   addresses, a possible option is to run all internal traffic using
   Unique Local Addresses (ULA) since such packets can by definition
   never exit the site. For hosts that do in fact need to generate
   external traffic, by using multiple IPv6 addresses (ULAs and one or
   more global addresses), it will be possible to hide and mask some or
   all of the internal network. As discussed in Section 3.1, there are
   multiple parts to the IPv6 address, and different techniques to
   manage privacy for each.

   There are two possible scenarios for the extreme situation when a
   network manager also wishes to fully conceal the internal IPv6
   topology.

   o One could use explicit host routes and remove the correlation
      between location and IPv6 address. This solution does however
      show severe scalability issues.
   o The other technology to fully hide the internal topology would be
      to use a tunneling mechanism. Mobile IPv6 without route
      optimization is one example. In this example the public facing
      addresses are indirected via an edge Home Agent (HA). This
      indirection method truly masks the internal topology as all nodes
      with global access appear to share a common subnet. The downside
      of using this method is that it makes usage of middleware like a
      Home Agent (HA).

<end snip>

Brgds,
G/ 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 ; 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: 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