From owner-v6ops@ops.ietf.org Mon Aug 01 01:19:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzSiE-0007BZ-9s for v6ops-archive@megatron.ietf.org; Mon, 01 Aug 2005 01:19: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 BAA10933 for ; Mon, 1 Aug 2005 01:19:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzSe7-0007XN-9P for v6ops-data@psg.com; Mon, 01 Aug 2005 05:15:27 +0000 Received: from [144.254.224.140] (helo=ams-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzSe6-0007Wu-Kz for v6ops@ops.ietf.org; Mon, 01 Aug 2005 05:15:26 +0000 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 01 Aug 2005 07:15:26 +0200 Received: from xbh-ams-331.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j715FLDg021185; Mon, 1 Aug 2005 07:15:22 +0200 (MEST) Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 07:15:21 +0200 Received: from [10.11.0.143] ([10.61.80.60]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 07:15:20 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D184193-6710-46F0-9EA8-27527EF3F094@cisco.com> Cc: Lindqvist Erik Kurt , David Kessens , agenda@ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: v6ops agenda Date: Mon, 1 Aug 2005 07:15:20 +0200 To: "v6ops@ops.ietf.org" X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 01 Aug 2005 05:15:20.0931 (UTC) FILETIME=[03767330:01C59658] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit At long last, the proposed agenda for today's meeting. We will bash this in the course of the meeting as well. First, current document status: RFC Editor's queue: - draft-ietf-v6ops-3gpp-analysis-11.txt - draft-ietf-v6ops-renumbering-procedure-05.txt - draft-ietf-v6ops-mech-v2-07.txt - draft-huitema-v6ops-teredo-05.txt WG Last Call complete: - draft-ietf-v6ops-onlinkassumption-03.txt - draft-ietf-v6ops-natpt-to-exprmntl-01.txt - draft-ietf-v6ops-vlan-usage-00.txt - draft-ietf-v6ops-bb-deployment-scenarios-03.txt - draft-ietf-v6ops-security-overview-02.txt In discussion today with respect to WG last call comments: - draft-ietf-v6ops-nap-01.txt - draft-ietf-v6ops-ipsec-tunnels-00.txt - draft-ietf-v6ops-ent-analysis-03.txt New proposals: - draft-vives-v6ops-distributed-security-framework-00.txt - draft-davies-v6ops-icmpv6-filtering-bcp-00.txt I'm not sure where these are going: - draft-chown-v6ops-renumber-thinkabout-02.txt - draft-palet-v6ops-ipv6security-02.txt - draft-vandevelde-v6ops-nap-01.txt - draft-vives-v6ops-ipv6-security-ps-03.txt - draft-lee-v6ops-mipv6-deployment-00.txt - draft-larsson-v6ops-mip-scenarios-01.txt Transition-related, currently planned for individual submission to RFC Editor: - draft-despres-v6ops-transition-v5roadmap-00.txt - draft-liumin-v6ops-silkroad-03.txt - draft-blanchet-v6ops-tunnelbroker-tsp-02.txt - draft-massar-v6ops-tunneldiscovery-00.txt - draft-massar-v6ops-heartbeat-01.txt - draft-ooms-v6ops-bgp-tunnel-05.txt - draft-palet-v6ops-tun-auto-disc-03.txt --------------------------------------------------------------------- The agenda: In today's working group meeting, we will spend ten minutes on each of the following: - draft-ietf-v6ops-ent-analysis-03.txt - draft-ietf-v6ops-nap-01.txt - draft-ietf-v6ops-ipsec-tunnels-00.txt - draft-vives-v6ops-distributed-security-framework-00.txt - draft-davies-v6ops-icmpv6-filtering-bcp-00.txt The first three with a view to finishing working group last call in August, and the last two with a view to accepting them as new work. We will spend the second hour on a discussion of renumbering work in done in 6net, led by Ralph Droms: Introduction Ralph Droms ( 5 mins) Prior art and tools, backbone renumbering JOIN/Univ. Muenster ( 5 mins) and BGP issues, SOHO renumbering Enterprise experiments and recommendations Univ. Southampton ( 5 mins) Router renumbering protocol Renater ( 5 mins) Impact of renumbering on management tools PSNC ( 5 mins) Maintaining management plane during Loria-Inria ( 5 mins) renumbering, monitoring renumbering Conclusions Ralph Droms ( 5 mins) Discussion (25 mins) From owner-v6ops@ops.ietf.org Mon Aug 01 03:15:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUWa-0005Dr-29 for v6ops-archive@megatron.ietf.org; Mon, 01 Aug 2005 03:15:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00898 for ; Mon, 1 Aug 2005 03:15:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzUUu-000I78-Ex for v6ops-data@psg.com; Mon, 01 Aug 2005 07:14:04 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzUUs-000I6n-FM for v6ops@ops.ietf.org; Mon, 01 Aug 2005 07:14:02 +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 j717Dqm21397; Mon, 1 Aug 2005 09:13:52 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp4443.cisco.com [10.61.81.90]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j717Dnp16204; Mon, 1 Aug 2005 09:13:49 +0200 (CEST) Message-Id: <4.3.2.7.2.20050801091219.05324d90@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 01 Aug 2005 09:13:47 +0200 To: Fred Baker From: "Gunter Van de Velde (gvandeve)" Subject: Re: v6ops agenda Cc: "v6ops@ops.ietf.org" , Lindqvist Erik Kurt , David Kessens In-Reply-To: <7D184193-6710-46F0-9EA8-27527EF3F094@cisco.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk draft-vandevelde-v6ops-nap-01.txt Replaced with draft-ietf-v6ops-nap-* drafts. G/ At 07:15 1/08/2005 +0200, Fred Baker wrote: >At long last, the proposed agenda for today's meeting. We will bash >this in the course of the meeting as well. > >First, current document status: > > RFC Editor's queue: > - draft-ietf-v6ops-3gpp-analysis-11.txt > - draft-ietf-v6ops-renumbering-procedure-05.txt > - draft-ietf-v6ops-mech-v2-07.txt > - draft-huitema-v6ops-teredo-05.txt > > WG Last Call complete: > - draft-ietf-v6ops-onlinkassumption-03.txt > - draft-ietf-v6ops-natpt-to-exprmntl-01.txt > - draft-ietf-v6ops-vlan-usage-00.txt > - draft-ietf-v6ops-bb-deployment-scenarios-03.txt > - draft-ietf-v6ops-security-overview-02.txt > > In discussion today with respect to WG last call comments: > - draft-ietf-v6ops-nap-01.txt > - draft-ietf-v6ops-ipsec-tunnels-00.txt > - draft-ietf-v6ops-ent-analysis-03.txt > > New proposals: > - draft-vives-v6ops-distributed-security-framework-00.txt > - draft-davies-v6ops-icmpv6-filtering-bcp-00.txt > > I'm not sure where these are going: > - draft-chown-v6ops-renumber-thinkabout-02.txt > - draft-palet-v6ops-ipv6security-02.txt > - draft-vandevelde-v6ops-nap-01.txt > - draft-vives-v6ops-ipv6-security-ps-03.txt > - draft-lee-v6ops-mipv6-deployment-00.txt > - draft-larsson-v6ops-mip-scenarios-01.txt > > Transition-related, currently planned for individual >submission to RFC Editor: > - draft-despres-v6ops-transition-v5roadmap-00.txt > - draft-liumin-v6ops-silkroad-03.txt > - draft-blanchet-v6ops-tunnelbroker-tsp-02.txt > - draft-massar-v6ops-tunneldiscovery-00.txt > - draft-massar-v6ops-heartbeat-01.txt > - draft-ooms-v6ops-bgp-tunnel-05.txt > - draft-palet-v6ops-tun-auto-disc-03.txt > >--------------------------------------------------------------------- > >The agenda: > >In today's working group meeting, we will spend ten minutes on each >of the following: > - draft-ietf-v6ops-ent-analysis-03.txt > - draft-ietf-v6ops-nap-01.txt > - draft-ietf-v6ops-ipsec-tunnels-00.txt > - draft-vives-v6ops-distributed-security-framework-00.txt > - draft-davies-v6ops-icmpv6-filtering-bcp-00.txt > >The first three with a view to finishing working group last call in >August, and the last two with a view to accepting them as new work. > >We will spend the second hour on a discussion of renumbering work in >done in 6net, led by Ralph Droms: > >Introduction Ralph Droms ( 5 mins) > >Prior art and tools, backbone renumbering JOIN/Univ. Muenster ( 5 mins) >and BGP issues, SOHO renumbering > >Enterprise experiments and recommendations Univ. Southampton ( 5 mins) > >Router renumbering protocol Renater ( 5 mins) > >Impact of renumbering on management tools PSNC ( 5 mins) > >Maintaining management plane during Loria-Inria ( 5 mins) >renumbering, monitoring renumbering > >Conclusions Ralph Droms ( 5 mins) > >Discussion (25 mins) From owner-v6ops@ops.ietf.org Mon Aug 01 03:18:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzUZC-0005hc-Gx for v6ops-archive@megatron.ietf.org; Mon, 01 Aug 2005 03:18: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 DAA00905 for ; Mon, 1 Aug 2005 03:18:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1DzUYo-000IXe-1s for v6ops-data@psg.com; Mon, 01 Aug 2005 07:18:06 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DzUYe-000IWU-4i for v6ops@ops.ietf.org; Mon, 01 Aug 2005 07:17:56 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j717HbqA016756; Mon, 1 Aug 2005 08:17:37 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA01185; Mon, 1 Aug 2005 08:17:10 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j717H9c05391; Mon, 1 Aug 2005 08:17:09 +0100 Date: Mon, 1 Aug 2005 08:17:09 +0100 From: Tim Chown To: Fred Baker Cc: "v6ops@ops.ietf.org" , Lindqvist Erik Kurt , David Kessens Subject: Re: v6ops agenda Message-ID: <20050801071709.GB4913@login.ecs.soton.ac.uk> Mail-Followup-To: Fred Baker , "v6ops@ops.ietf.org" , Lindqvist Erik Kurt , David Kessens References: <7D184193-6710-46F0-9EA8-27527EF3F094@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D184193-6710-46F0-9EA8-27527EF3F094@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 01, 2005 at 07:15:20AM +0200, Fred Baker wrote: > > I'm not sure where these are going: > - draft-chown-v6ops-renumber-thinkabout-02.txt This is now -03, and aims to be complementary to your renumbering procedure text. It will be updated again based on feedback from the renumbering discussion today. > - draft-vandevelde-v6ops-nap-01.txt That's now draft-ietf-v6ops-nap-01 and very much on track :) Tim From 22javed@access-one.com Mon Aug 01 10:36:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzbPW-0007xF-V9 for v6ops-archive@megatron.ietf.org; Mon, 01 Aug 2005 10:36:59 -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 KAA13130 for ; Mon, 1 Aug 2005 10:36:57 -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 1Dzbvp-0003WD-Eg for v6ops-archive@ietf.org; Mon, 01 Aug 2005 11:10:21 -0400 Received: from pool-71-97-140-71.aubnin.dsl-w.verizon.net ([71.97.140.71]) by mx2.foretec.com with smtp (Exim 4.24) id 1DzbPU-0008CQ-M9 for v6ops-archive@ietf.org; Mon, 01 Aug 2005 10:36:57 -0400 Message-ID: <664f01c596a4$fbbc9f45$af7ec499@access-one.com> From: "Richard K. Lee" <22javed@access-one.com> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?Q2lhbGlzIC0gJDIuOTkvZG9zZQ==?= Date: Mon, 01 Aug 2005 14:23:43 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_1CAF97F6.46CD83D6" 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: 3.6 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_0000_1CAF97F6.46CD83D6 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_28358B8E.1EACE9DD" ------=_NextPart_001_0001_28358B8E.1EACE9DD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Easy erection Long lasting effects No prescription needed Only $2.99/$1.99 per dose (2 doses in each pill): CIALIS - http://www.c-pills.com/sv/ VIAGRA - http://www.c-pills.com/vt/ Directly from the manufacturer! _________________________________________________________________________ To be taken off future campaigns, go here _________________________________________________________________________ ------=_NextPart_001_0001_28358B8E.1EACE9DD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit

Easy erection
Long lasting effects
No prescription needed

Only $2.99/$1.99 per dose (2 doses in each pill):
CIALIS - http://www.c-pills.com/sv/
VIAGRA - http://www.c-pills.com/vt/

Directly from the manufacturer!


_________________________________________________________________________
To be taken off future campaigns, go here
_________________________________________________________________________

------=_NextPart_001_0001_28358B8E.1EACE9DD-- ------=_NextPart_000_0000_1CAF97F6.46CD83D6-- From owner-v6ops@ops.ietf.org Mon Aug 01 11:58:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dzcg3-00032D-GP for v6ops-archive@megatron.ietf.org; Mon, 01 Aug 2005 11:58:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20095 for ; Mon, 1 Aug 2005 11:58:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1Dzccl-000Cyf-5X for v6ops-data@psg.com; Mon, 01 Aug 2005 15:54:43 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dzccj-000CyG-Gg for v6ops@ops.ietf.org; Mon, 01 Aug 2005 15:54:41 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 01 Aug 2005 08:54:41 -0700 X-IronPort-AV: i="3.95,157,1120460400"; d="scan'208"; a="652181080:sNHT30481700" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j71FscJP009570; Mon, 1 Aug 2005 08:54:40 -0700 (PDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 11:54:39 -0400 Received: from [86.255.31.47] ([10.82.224.96]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 1 Aug 2005 11:54:39 -0400 In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15507B5BC49@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B15507B5BC49@nl0006exch001u.nl.lucent.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1716F1C9-3C90-480C-8D90-1BBF1176D3C4@cisco.com> Cc: "Ops-Chairs (E-mail)" , "v6ops@ops.ietf.org '" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: IETF63 Summary v6ops Date: Mon, 1 Aug 2005 17:54:37 +0200 To: David Kessens , Bert Wijnen X-Mailer: Apple Mail (2.733) X-OriginalArrivalTime: 01 Aug 2005 15:54:39.0569 (UTC) FILETIME=[52FE1C10:01C596B1] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit v6ops is about to send you the following documents for AD review and eventual IESG movement. These have been through working group last call; I am completing the indicated paperlesswork. draft-ietf-v6ops-onlinkassumption informational, corollary to draft-ietf-ipv6-2461bis-04.txt draft-ietf-v6ops-natpt-to-exprmntl draft-ietf-v6ops-vlan-usage These documents will be last-called after the meeting and will likely be sent to you in September draft-ietf-v6ops-ipsec-tunnels draft-ietf-v6ops-ent-analysis draft-ietf-v6ops-nap draft-ietf-v6ops-security-overview Waiting for Cable Labs input draft-ietf-v6ops-bb-deployment-scenarios These are new work that v6ops will pick up draft-davies-v6ops-icmpv6-filtering-bcp - as a potential BCP draft-vives-v6ops-distributed-security-framework - potential BOF next meeting, in security area We also had a presentation by Ralph Droms and a list of folks from 6NET on the renumbering project that they did. There is some follow- on work, including a document publication sometime next year. The upshot of that is a variety of documents from Cisco and 6Net, and some specific recommendations to be posted to the mailing list. draft- chown-v6ops-renumber-thinkabout will be updated, and there may be specific recommendations concerning renumbering. From owner-v6ops@ops.ietf.org Fri Aug 05 02:59:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wB0-000294-1x for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:59: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 CAA19336 for ; Fri, 5 Aug 2005 02:59:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0w74-0003aJ-Rt for v6ops-data@psg.com; Fri, 05 Aug 2005 06:55:26 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0w74-0003ZO-B7 for v6ops@ops.ietf.org; Fri, 05 Aug 2005 06:55:26 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2005 23:55:25 -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 j756tOoo001460 for ; Thu, 4 Aug 2005 23:55:24 -0700 (PDT) Received: from [1.0.99.34] (ams-clip-vpn-dhcp186.cisco.com [10.61.64.186]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j756qLaF025842 for ; Thu, 4 Aug 2005 23:52:40 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: Last call on draft-ietf-v6ops-nap-01.txt Date: Fri, 5 Aug 2005 07:08:20 +0200 X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=238; t=1123224760; x=1123656960; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Last=20call=20on=20draft-ietf-v6ops-nap-01.txt| From:Fred=20Baker=20| Date:Fri,=205=20Aug=202005=2007=3A08=3A20=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=l4zTwWyaDXnu2tiGj4HbsiJwAVyP5sVd0v8KNt+GA0qkecg0tpINKlrK4NpwpTXTyXAP/4xI E9QZ5OJPsctKHTpfEfi5BRWw4l5s3jamq4GvEEVLK2IYk+4Iv2q2DGGGmP9EY+0Gny3aQF9D99x j3A8MEUFl6+dfhbUwnNoGA9o= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With this note, I am opening a working group last call on draft-ietf- v6ops-nap-01.txt. This WGLC will close in two weeks, at close of business 19 July. Please read the document and comment to the list - either say that the document is ready, or say what issues you may have with it. Thanks. From owner-v6ops@ops.ietf.org Fri Aug 05 02:59:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wB7-00029T-Ag for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:59:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19347 for ; Fri, 5 Aug 2005 02:59:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0w7F-0003cC-W4 for v6ops-data@psg.com; Fri, 05 Aug 2005 06:55:37 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0w77-0003aQ-FS for v6ops@ops.ietf.org; Fri, 05 Aug 2005 06:55:29 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2005 23:55:29 -0700 X-IronPort-AV: i="3.95,169,1120460400"; d="scan'208"; a="653100267:sNHT26584904" 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 j756tP0J029600 for ; Thu, 4 Aug 2005 23:55:25 -0700 (PDT) Received: from [1.0.99.34] (ams-clip-vpn-dhcp186.cisco.com [10.61.64.186]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j756qLaH025842 for ; Thu, 4 Aug 2005 23:52:43 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: last call on draft-ietf-v6ops-ipsec-tunnels-00.txt Date: Fri, 5 Aug 2005 07:08:22 +0200 X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=248; t=1123224763; x=1123656963; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:last=20call=20on=20draft-ietf-v6ops-ipsec-tunnels-00.txt| From:Fred=20Baker=20| Date:Fri,=205=20Aug=202005=2007=3A08=3A22=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=q3e8MPkVUivXU6jeEmko/DlCOXg+4gFqpfOfA2W6vUgChm+VO+F6LW8ES+hh0SH2uoHWHM7R dcyETFZiUNL9dJ5rX9kW/hg6EnWoeymyGdlEj9etIcYt52lofXWLECYzIuoAQxy3tEYInq9qWM0 +uaPbWlVqfY1LV1yDJFd/IaU= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With this note, I am opening a working group last call on draft-ietf- v6ops-ipsec-tunnels-00.txt. This WGLC will close in two weeks, at close of business 19 July. Please read the document and comment to the list - either say that the document is ready, or say what issues you may have with it. Thanks. From owner-v6ops@ops.ietf.org Fri Aug 05 02:59:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wBG-0002A3-AQ for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:59: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 CAA19350 for ; Fri, 5 Aug 2005 02:59:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0w78-0003b2-KR for v6ops-data@psg.com; Fri, 05 Aug 2005 06:55:30 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0w76-0003aQ-1B for v6ops@ops.ietf.org; Fri, 05 Aug 2005 06:55:28 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 04 Aug 2005 23:55:28 -0700 X-IronPort-AV: i="3.95,169,1120460400"; d="scan'208"; a="653100258:sNHT27033552" 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 j756tN0J029596 for ; Thu, 4 Aug 2005 23:55:23 -0700 (PDT) Received: from [1.0.99.34] (ams-clip-vpn-dhcp186.cisco.com [10.61.64.186]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j756qLaG025842 for ; Thu, 4 Aug 2005 23:52:41 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: Last Call on draft-ietf-v6ops-ent-analysis-03.txt Date: Fri, 5 Aug 2005 07:08:21 +0200 X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=247; t=1123224762; x=1123656962; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Last=20Call=20on=20draft-ietf-v6ops-ent-analysis-03.txt| From:Fred=20Baker=20| Date:Fri,=205=20Aug=202005=2007=3A08=3A21=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=i3xpnr7SwPbr8jVM2U/l4tdcqFm9Bx82JSln/cCv3uYEEPYyeWI69WwT7ivjrfsKuP/aXtoy UcUY3coE/1nu7RQ4Srl1Fgp/k6ONBxxJPxb221/4l0/dKpfwuQ6yCxWHP3Fy+IXfgeBg0HQdSLz Ex1iR46KXClV0QiAFBt87r9o= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With this note, I am opening a working group last call on draft-ietf- v6ops-ent-analysis-03.txt. This WGLC will close in two weeks, at close of business 19 July. Please read the document and comment to the list - either say that the document is ready, or say what issues you may have with it. Thanks. From owner-v6ops@ops.ietf.org Fri Aug 05 02:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E0wBM-0002G6-50 for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 02:59:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19356 for ; Fri, 5 Aug 2005 02:59:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E0w74-0003a1-2P for v6ops-data@psg.com; Fri, 05 Aug 2005 06:55:26 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E0w72-0003ZO-Gf for v6ops@ops.ietf.org; Fri, 05 Aug 2005 06:55:24 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Aug 2005 23:55:23 -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 j756tMoo001444 for ; Thu, 4 Aug 2005 23:55:22 -0700 (PDT) Received: from [1.0.99.34] (ams-clip-vpn-dhcp186.cisco.com [10.61.64.186]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j756qLaE025842 for ; Thu, 4 Aug 2005 23:52:38 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Transfer-Encoding: 7bit Message-Id: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: v6ops@ops.ietf.org From: Fred Baker Subject: Last Call on draft-ietf-v6ops-security-overview-02.txt Date: Fri, 5 Aug 2005 07:08:19 +0200 X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=252; t=1123224758; x=1123656958; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Last=20Call=20on=20draft-ietf-v6ops-security-overview-02.txt| From:Fred=20Baker=20| Date:Fri,=205=20Aug=202005=2007=3A08=3A19=20+0200| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=FfBSjM+/HcrVSnuNtisv/Gih8nJvy4EQQ0TzGc5Jp++UCwOGHvAIAQLmCbyWLWqljbq/TwC3 lohn4rlCJuBl9D5Xh/30KERQiIiz3YQbWJ5/kSTyifPUIUroq2gBr9azva9bNdREhDPX7rFKJon LjsqdnOnLiZayJLDdVg9uf64= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit With this note, I am opening a working group last call on draft-ietf- v6ops-security-overview-02.txt. This WGLC will close in two weeks, at close of business 19 July. Please read the document and comment to the list - either say that the document is ready, or say what issues you may have with it. Thanks. From owner-v6ops@ops.ietf.org Fri Aug 05 15:48:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18BK-0001jl-6p for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 15:48:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28740 for ; Fri, 5 Aug 2005 15:48:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E18A4-000D1N-RH for v6ops-data@psg.com; Fri, 05 Aug 2005 19:47:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E18A3-000D18-Ty for v6ops@ops.ietf.org; Fri, 05 Aug 2005 19:47:20 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j75JlIb05064 for ; Fri, 5 Aug 2005 22:47:18 +0300 Date: Fri, 5 Aug 2005 22:47:18 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WGLC ent-analysis-03: DSTM Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (I'll put two most separable & possibly most discussable items in separate mails.) In 8.1: Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or in the case of early deployment of IPv6-dominant networks DSTM can be used too. and in 8.4: DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the enterprise transition or deployment of IPv6-dominant network links is desired. DSTM is to being submitted as an IETF Experimental RFC. ==> as it is, DSTM is a way too overloaded a mechanism to be referred to without more disclaimers or description. As it is, different people use "DSTM" to mean at least the following things: a) v4-in-v6 tunnels b) automatically set-up v4-in-v6 tunnels c) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket d) automatic monitoring and tear-down of said v4-over-v6 tunnel when the host detects it no longer needs the address/connectivity e) plus a number of extensions for even more colorful setups. a) doesn't require DSTM; b) can be achieved using a tunnel broker; c) does not require IETF interoperability (a local implementation choice when/how to launch the v4-in-v6 activation). d) could also be considered in the same category (there are no bits in the wire or anything requiring interoperability AFAICS on when the host removes the tunnel), though I'm skeptical whether even providing that would be a good engineering choice. My point is that I'm having hard time figuring out: 1) what the document means when it's recommending DSTM, and 2) based on my analysis above, I do not believe that DSTM (in the way that I think it's being referred to) is even needed. Therefore my suggestion is to remove references to DSTM (preferable) or greatly clarify the assumptions and the requirements on why it should be necessary. (On the other hand, if the DSTM spec only described the algorithms for doing c) and d) above in my list, I would have a lot fewer concerns -- but as it is, I believe a reference would confuse more than help.) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 05 15:48:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18BS-0001k5-Bd for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 15:48: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 PAA28755 for ; Fri, 5 Aug 2005 15:48:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E187J-000Coq-Kd for v6ops-data@psg.com; Fri, 05 Aug 2005 19:44:29 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E187H-000CoZ-Vr for v6ops@ops.ietf.org; Fri, 05 Aug 2005 19:44:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j75JiQM05005 for ; Fri, 5 Aug 2005 22:44:26 +0300 Date: Fri, 5 Aug 2005 22:44:26 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: comments on draft-davies-v6ops-icmpv6-filtering-bcp-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I think the document is good and necessary one, but (IMHO) still (well, it's a -00 version :) requires substantive work. Note: I didn't look more than about 5 pages or so, because the flight ended, but I think you get the picture ;-) 1) I think the most important issue is representation of the requirements and summing them up. That is, the recommendations should be categorized in roughly following categories: * must not drop these messages (e.g., pkt too big) * should not drop these messages, think twice before you even consider it! (most other ICMP errors) * these messages may be dropped but there's really no need to drop them (redirects, ns/na, rs/ra, etc. -- things that the specifications say MUST be discarded if they come from with hop count != 255 or link-local address checks) * may or may not want to drop these * should consider dropping these messages (e.g., ICMP name lookups) secondly, the messages/rules needed at the firewall to ensure its own link-local messaging works OK should be separated from "transiting" messages (split in categories like above). further, the guidance needs to be summarized in some form: e.g., a table at the end and/or very short pseudo-rules. 2) it may also already have come across above, but IMHO most of the recommendations right now seem too strict and/or unnecessary. I don't think it's necessary to encourage the firewall admins to keep track of all the ICMP types one by one (even with more precision than that in some cases), and try to figure out how to deal with them. We'll need to deal with the messages by fixing sensible defaults, also to minimize the need for continuous maintenance of the rules. (Personally, I'm in favor accepting everything except maybe some some stupid [if used in inter-domain] messages like ICMP name lookups. For example, I don't think ICMP echo does any harm, due to the reasons described in Tim Chown's "port scanning considerations draft", but YMMV.) semi-editorial -------------- Abstract ==> the abstract is (comparatively) long for an I-D. I'd try to cut it to about a half. (5-10 lines is probably a good ballpark figure.) Less is more :) o Simple monitoring of connectivity through echo requests and responses used by the ping and traceroute utilities. The Echo Request and Echo Response messages are specified in [RFC2463]. ==> traceroute utils which use echo req/resp are, hopefully, relatively rare, or are you referring to some more aggressive programs which e.g. first do traceroute and then send a dozens of pings to each hop? o Finding neighbors (both routers and hosts) connected to the same link and determining their IP and link layer addresses. These messages are also used to check the uniqueness of any addresses that an interface proposes to use (Duplicate Address Detection - DAD)) - DAD can be turned off if the network administrator believes that the configuration method used is bound to generate unique addresses. Four messages - Neighbor Solicitation (NS), Neighbor Advertisement (NA), Router Solicitation (RS) and Router Advertisement (RA) - are specified in [RFC2461]. ==> in the interest of brevity, I'd remove the "DAD can be turned off" debate from this (shorter) list of considerations/functions. It can always be described with the full considerations of DAD later in the doc. o Redirecting packets to a more appropriate router on the local link for the destination address or pointing out that a destination is actually on the local link even if it is not obvious from the IP address (where a link supports multiple subnets). This facility could be used by a malicious sender to divert packets and nodes should provide configuration options to prevent the messages being sent by routers and acted on by hosts. The redirect message is specified in [RFC2461]. ==> the same applies to redirects here; just say that it can only be used on-link. 2.2 Addressing of ICMPv6 ICMPv6 messages are sent using various kinds of source and destination address types. The source address is usually a unicast address, but during address autoconfiguration message exchanges, the unspecified address :: is also used as a source address [RFC2462]. ==> well, MLDv1 can also use it as src in some scenarios (see the RFC on MLDv1 source address selection).. 2.3 Network Topology and Address Scopes ==> I think this section would use a lot of boosting w/ hop count=255 checks. Personally, I find those pretty trustworthy, especially in addition to (typically) having to use link-local addresses... (see my point above in message types which don't really need to be blocked unless you want to make pretty useless rules..) 3.3 Redirection Attacks These attacks would normally have to be carried out locally on a link, but it is important to ensure that Redirect messages are not allowed through the firewall. Redirection could be used simply for DoS as well as endeavouring to redirect traffic to a compromised node. ==> redirects are very well protected by default, see above. addresses. In some cases, where deeper packet inspection is possible, it may be desirable to filter on, for example, the Code field of ICMPv6 error messages. ==> I'd use a different example: ICMP type and code are, from the firewall perspective, "equally deep"... Echo Requests travel end-to-end but never have a role in establishing communications. Similarly Echo Responses (Type 129) travel end-to-end and would have a unicast address as destination and either a unicast or anycast address as source. ==> as the verifying node can't know whether it's uni- or anycast, I think the point is moot, and you could just talk about unicast addresses.. editorial --------- that an interface proposes to use (Duplicate Address Detection - DAD)) - DAD can be turned off if the network administrator ==> add a '(' or remove a ')' around DAD ? specified in Multicast Listener Discovery MLDv1 [RFC2710] and MLDv2[RFC3810]. ==> s/MLDv2/MLDv2 / o Providing support for some aspects of Mobile IPv6 especially dealing with the IPv6 Mobile Home Agent functionality provided in routers and needed to support a Mobile node homed on the link. The Home Agent Address Discovery Request and reply; and Mobile Prefix Solicitation and Advertisement messages are specified in [RFC3775] ==> something weird around "HA disc", the sentence doesn't parse? missing a bullet point or something? Compared with the corresponding IPv4 protocol, ICMP, ICMPv6 cannot be treated as an auxiliary function with packets that can be dropped in most cases without damaging the functionality of the network. This means that firewall filters for ICMPv6 have to be more carefully configured than was the case for ICMP, where typically a small set of blanket rules could be applied. ==> maybe it would be simpler to just refer to ICMP as ICMPv4.. to be sent to or pass through firewalls, and may be essential to the establishment of communications (see Section 2.4 whereas ==> missing ')' messages are any-to-end in nature. Generally end-to-end and any-to- end messages might be expected to pass through firewalls depending on policies but local communications must not ==> something missing at the end ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 05 15:49:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18C7-0001v3-Vh for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 15:49: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 PAA28797 for ; Fri, 5 Aug 2005 15:49:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E18BJ-000D5V-7z for v6ops-data@psg.com; Fri, 05 Aug 2005 19:48:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E18BI-000D4x-Ab for v6ops@ops.ietf.org; Fri, 05 Aug 2005 19:48:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j75JmZD05080 for ; Fri, 5 Aug 2005 22:48:35 +0300 Date: Fri, 5 Aug 2005 22:48:35 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WGLC ent-analysis-03: application vs network driven Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (I'll put two most separable & possibly most discussable items in separate mails.) ==> the document seems to have been written based on the assumption that first the enterprise decides which kind of network it will run (dual-IP, v6-only) and whether its applications will be v6-only, dual-IP or v4, and then takes a look at the surrounding environment -- and the result is often "oops.. we need translation, tunneling, and a number of other complexities for our decision to be fulfilled". In some cases, this approach may be appropriate (though I hope this is not commonplace). In most cases, the better way is to look at what kind of applications you have or want to have (also the ones which you need to communicate with outside the enterprise) and after that make the decisions (weighing the different tradeoffs of course) which kind of network topologies would be best suited for the job. After this deliberation, the result might be that an enterprise might have to take a "hard road" in any case, resulting the matrix we're describing, but the thought process is different. Maybe or maybe not this has also been implicit when writing this document, but this thought process just hasn't been spelled out. It should be, in a number of places. I think a key message that needs to be delivered is, "if a particular scenario is difficult, maybe it is worth considering alternative assumptions?" [for example, having the application be dual-IP or network dual-stack] or in other words, "don't push if there's resistance". This issue should probably be discussed in section 3, maybe reminded briefly in section 6, and again mentioned in appropriate places in section 8. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 05 15:52:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E18Ed-0002Fw-VM for v6ops-archive@megatron.ietf.org; Fri, 05 Aug 2005 15:52: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 PAA28924 for ; Fri, 5 Aug 2005 15:52:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E18Di-000DQB-JC for v6ops-data@psg.com; Fri, 05 Aug 2005 19:51:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E18Dg-000DPa-AM for v6ops@ops.ietf.org; Fri, 05 Aug 2005 19:51:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j75Jp3a05149 for ; Fri, 5 Aug 2005 22:51:03 +0300 Date: Fri, 5 Aug 2005 22:51:03 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WGLC ent-analysis-03 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Thank you for additional "textual" discussion of the matrix. IMHO it is very useful. While I am skeptic about the matrix approach, modifying that goes beyond the point of diminishing returns. In general, I think the document is in a very good shape, though Section 8 (which is a recent addition) still requires wider review. Flights are good at catching up on your reading list :) substantial ----------- 1) I still think appendix is a bit inappropriate for this document, and it be removed from this doc. (I did not review it at length.) 2) [see separate mail on app vs network-driven] 3) [see separate mail on DSTM] 4) 8.2 Recognizing Application incompatibilities [...] This leads us to the third theme represented by Scenario E and G, i.e. incompatible applications communicating across a homogenous network. Translation is an obvious solution, but not recommended except for legacy devices at the network edge which cannot or never will be upgraded to IPv6. A more scaleable solution would be to use an Application Layer Gateways (ALG) between the incompatible hosts. ==> I don't understand this theme. In all scenarios from E to J, it seems that the application version between the two endpoints is different. Is this what you meant in the matrix? I fail to see how that kind of situation can be addressed by tunneling. (I don't think that's what you're implying, but rather that there are typos in the matrix or I don't understand its basic assumptions.) 5) Having IPv6 applications on a Dual-IP host on a v4-only network lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end service. ISATAP [ISTP] can be used to provide end node IPv6 connectivity from nodes on an isolated IPv4 network, through the use of automatic tunneling of IPv6 in IPv4. Enterprise architects should consider providing a Tunnel Broker [TBRK, TSPB] as a cost effective service to local users or applications. Tunnel Brokers can be used to provide tunnel setup for an enterprise using manual configured tunnels, 6to4, or DSTM. Tunnel Brokers can automate the use of tunnels across an enterprise deploying IPv6. ==> I think these paragraphs provide a bit too little context. The first paragraph also seems to introduce ISATAP and Teredo with different manner compared to the tunnel broker. Here's my attempt at rewording: Having IPv6 applications on a Dual-IP host on a v4-only network requires some form of tunneling. Where configured tunnels [BCNF] are not sufficient, a more automatic solution may be appropriate. Typical solutions include a tunnel broker [TBRK, TSPB], ISATAP [ISTP], or even Teredo [TRDO]. (there is more analysis on the tradeoffs of the solutions later, so I don't think it's necessary to do that here.) 6) 11.1 Normative References There are no normative references in this document to depict correct protocol operation. This document is an analysis technical effort not a operative or protocol specification. ==> while the "Normative References" section is not meant to be normative in that sense, in documents like this, it is typically intended to include those documents which are: 1) required to be understood for understanding this specification, 2) are work-in-progress and significantly discussed, and the details mentioned in this document could change before the other drafts are complete, so we require that those docs must be published as RFCs before this is published as an RFC, or 3) other documents which are appropriate for understanding this one which should be published as RFCs before this draft is done. In that light, I'd suggest moving some documents over to the Normative references: BSCN, 6TO4, TRDO, BCNF (note, I'd also refer to draft-ietf-v6ops-mech-v2 instead/in addition because it's replacing BCNF) Moving these would not hurt: CONF, DHCPF, DHCPL, 6TUN, TBRK, ALLOC These might also be candidates for moving: DNSV6, APPS, NAP, V6SEC, NATDE These could probably be removed completely: SEC1 (not referred), OSPF, BGP4, ISIS, RIPng almost substantial ------------------ - The second column represents the IP-capability of the host network wherein the node originated the packet. (Host 1 Network) ==> I'm sorry, but I'm still not 100% sure on what you mean here. Do you mean: a) "the network where the host plugs into" (i.e., the subnet), where the enterprise might have different network elements, or b) "the least common denominator in the whole enterprise network". Let me try to take an example from scenario A: | IPv6 | |Dual IP | | IPv6 | A | ---- | IPv4 | or |Dual IP| ---- | | Dual IP | | IPv4 | | Dual IP | Could network 1 address this problem (if the service provider is dual-IP) by configuring a manual tunnel from the host 1 to the enterprises border router (assumption a) above) or some other component? (With interpretation b) above, this wouldn't be possible because there wouldn't be any IPv6 connectivity, v6-capable routers, etc. from the enterprise to the ISP.) This is important point to get clarified, though it's not as critical as before because the recommendations for solutions are no longer strongly tied to the scenarios. ........ If the number of nodes to be using IPv6 is reduced, another option is to use statically configured tunnels. However automatically configured tunnels are generally preferred. ==> I'm not sure if I agree completely with this phrasing; I'd recommend (unless other considerations are on the table, such as the dynamicity/nomadicity of nodes/tunnels) using static tunnels when the number of tunnels is low. I would suggest below (though I would not object to spelling out the different tradeoffs further): If the number of nodes to be using IPv6 is low, the first option is to use statically configured tunnels. However, automatically configured tunnels may be preferable especially if the number is higher. ....... A stateless configured node wishing to gain other configuration information (e.g. DNS, NTP servers) will likely need a Stateful DHCPv6 [DHCPv6] service available. ==> I'm not sure if this is a typo or is I disagree: "other configuration" can very well obtained from a _stateless_ DHCPv6 service. I think it's also important to point out, somewhere, that you don't need to config v6 infortmation (at least at start) if you don't want to. Suggest: A stateless configured node wishing to gain other IPv6 configuration information (e.g. DNS, NTP servers) will likely need at least stateless DHCPv6 [DHCPL] service. In dual-IP networks, some enterprises may also choose to only distribute configuration information using DHCPv4. .... 7.4.5 Security ==> I think an important pointer to add at the end of this section would be something like: Specifically, the firewall policies must be configured appropriately especially with regard to ICMPv6 [ICMPFIL]. Blocking all ICMP messages, as has often been done with IPv4 with disastrous effects on, e.g., PMTUD, must be avoided. (where ICMPFIL could be an informative ref to elwyn and janos' draft.) .... Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to develop a test network in the enterprise, but will not scale well for a complete implementation of an IPv6 network. Manual Configured Tunnels for IPv6 is an IETF Proposed Standard. ==> I think this deserves more text on which scenarios or cases it doesn't scale to be fair. For example, Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism for tunneling between network segments, but has scalability limitations if applied to a large number of host-based tunnels, for example in scenarios A or C. Manual Configured Tunnels for IPv6 is an IETF Proposed Standard. .... 6to4 [6t4] is a useful tunneling mechanism for deployment if the enterprise has not obtained a native IPv6 prefix from their provider. 6to4 is an IETF Proposed Standard. ==> while I don't have strong qualms with this text, I think it may mislead the network admin to think 6to4 is a good replacement for a real IPv6 prefix. It isn't, due to its unpredictability especially with "return routing" scenarios. Therefore, I'd suggest adding a bit more warning here, for example add "Due to the unpredicatability of "return path", it may not be suitable for production use" as a second last paragraph. .... NAT-PT [NATPT] can be useful when there is no other means to access an IPv4 node behind a NAT network that only has a private address. But, it is recommended that the enterprise also look at the ability to provide access to that IPv4 node using a Proxy or Application Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF Proposed Standard. ==> please also refer to the applicability statement and state that it is being reclassified to experimental. ISATAP [ISTP] is a useful tunneling mechanism when the enterprise has deployed IPv6, and there are particpating nodes for the IPv6 deployment that exist on IPv4 networks. ISATAP is being submitted as an IETF Experimental RFC. ==> the last sentence is not pedantically correct, I believe; RFCs that are submitted through the RFC-editor are not "IETF" RFCs per se. I suggest: "ISATAP has been submitted as an individual submission to the RFC editor for Experimenal RFC" or something like that. (similar applies to the other mechanisms.) (also s/partic/partici/) .... Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the Enterprise wants to automate the setup of tunnels in the enterprise, and a tunnel broker can be used to support 6to4, ISATAP, and DSTM mechanisms. Tunnel Broker set-up protocol is being submitted as an IETF Experimental RFC. ==> I believe at least TSP has considered "Informational" instead (at least that's what Florent said). The base spec, AFAICS, does not include the 6to4, ISATAP, and DSTM extensions, so I'd suggest removing that part of the sentence. semi-editorial -------------- -- maybe still not clear enough what the 'host X network' means? [In section 4.4.2.1] In the widespread dual-IP scenario, a more structured, manageable method is required, where the administrator has control of the deployment per-link and (ideally) long-term, aggregatable global IPv6 addressing is obtained, planned and used from the outset. ==> I don't understand the relevance of v6 addressing to the tunnel discussion. Maybe some of this text should be removed or elaborated? (If obtaining global addresses is/should be mentioned, it should probably be done higher in the document hierarchy?; this is mentioned in 7.3 at least) When the enterprise's users are off-site, and using an ISP that does not support any native IPv6 service or IPv6 transition aids, the enterprise may consider deploying it's own remote IPv6 access support, as described in Section 7.5.2 below. ==> there is no section 7.5.2 ..? 5.1 Internal versus External Tunnel End Point Let's assume the upstream provider has deployed some IPv6 services, either native IPv6 in its backbone or in the access network, or some combination of both (Scenario B of Table 1). [...] ==> this has some very good text, but is this (enterprise has no v6 infra) on the borderline of being out-of-scope, wrt. the paragraph in Intro: We are also assuming that the enterprise deployment is one being undertaken by the network administration team, i.e. this document is not discussing the case of an individual user gaining IPv6 connectivity (to some external IPv6 provider) from within an enterprise network. [...] (these two cases are, at least from the ISP's perspectively, apparently pretty close to equivalent..) So, I'm not sure whether changes or further applicability text would be useful. I think the external tunnel point discussion may also apply to Scenario F and some others (e.g., if your business partner would want to use v6 application to reach your v6 app, but you'd have to provide a tunnel to him. ..... For internal routing, an appropriate interior routing protocol may be deployed. IPv6 routing protocols that can be used are as follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng [RIPng]. ==> maybe a more informative way for the reader would be to point to the ISP analysis on the routing protocol selection (the only difference here is that RIPng may be a bit more applicable in enterprise networks, but I'm not sure whether that is worth mentioning), for example: For internal routing, an appropriate interior routing protocol may be deployed. The routing protocol selection and the tradeoffs have been discussed in Section X of [ISPA], also applicable here. .... ... Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; there is support for DHCPv6 to assign privacy addresses to nodes in managed environments. ==> I'd say more briefly and less controversially: Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; there is also support for DHCPv6 to assign privacy addresses. editorial --------- The audience for this document is the enterprise network team considering deployment of IPv6. The document will be useful for enterprise teams that will have to determine the IPv6 transition strategy for their enterprise. ==> isn't this saying almost the same thing twice? maybe slight reword. - Requirements or Transtion at the Providers network ==> s/Trans/Transi/ (this seems a bit obvious as well, because this is an enterprise doc, not provider doc..) We are also assuming that the enterprise deployment is one being undertaken by the network administration team, i.e. this document ==> remove "one" ? enterprise. In sectioin 7 we discuss general issues and ==> s/sectioin/section/ The notional enterprise network is comprised of hosts attached to ==> do you mean "notational" with notional or something else? (many instances of this) Obviously Table 1 does not describe every possible scenario. Trivial notional networks (such as pure IPv4, pure IPv6, and ubiquitous Dual-IP) are not addressed. However, the authors feel these ten represent the vast majority of transitional situations likely to be encountered in today's enterprise. Therefore, we will use these ten to address the analysis for enterprise deployment. ==> this seems to overlap with an earlier (and more fleshed out) paragraph starting with "Addressing every possible combination of network IP-capability in this notional enterprise network is impractical, [...]". I'd suggest some combining to remove the overlap. use IPv6 applications, but has yet to transition its internal networks and it's Service Provider also lags, offering only a v4 IP-service. ==> s/it's/its/ (the same in a couple of other places) Consider the situation where there exists IPv6 edge routers which are IPv6-capable, while others,and perhaps the enterprise backbone ==> s/,and/, and/ There is a need for end-to-end communication with IPv6, but the infrastructure only supports IPv4 routing. Thus, the only viable method for end-to-end communication with IPv6 is to tunnel the traffic over the existing IPv4 infrastructure, within this analysis documents boundaries defined. ==> I'm not sure if I understand the last part of the last sentence, starting from "within ...". Maybe slight reword? IPv6-dominant network, except if required at to support edge IPv4 networks. ==> remove "at" ? In each case, communicating with an IPv4 end host or over an IPv4 network requires a transition point exist within the network to support that operation. ==> s/a transition point exist/that a transition point exists/ or s/exist/to exist/ ? network must aquire an IPv4 address (to interoperate with the IPv4 ==> s/aquire/acquire/ IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use ==> s/IPSEC/IPsec/ this mechanism provides no automated tunnnel configuration. ==> s/tunnnel/tunnel/ driven by the position of the incompatible touchpoint. If a local network is incompatible than host tunneling is appropriate. If the ==> s/than/then/ service both IPv4 and IPv6 data streams that are simulataneously ==> s/simulataneously/simultaneously/ The following transition mechanism have at least two independent ==> s/mechanism/mechanisms/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 08 08:05:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26OB-0007UG-Kd for v6ops-archive@megatron.ietf.org; Mon, 08 Aug 2005 08:05: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 IAA16601 for ; Mon, 8 Aug 2005 08:05:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E26KN-0006OK-Ml for v6ops-data@psg.com; Mon, 08 Aug 2005 12:01:59 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E26KK-0006Nj-Nj for v6ops@ops.ietf.org; Mon, 08 Aug 2005 12:01:56 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id C6124148; Mon, 8 Aug 2005 08:01:45 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 08:01:45 -0400 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: WGLC ent-analysis-03: DSTM Date: Mon, 8 Aug 2005 08:01:46 -0400 Message-ID: <936A4045C332714F975800409DE09240BC3584@tayexc14.americas.cpqcorp.net> Thread-Topic: WGLC ent-analysis-03: DSTM Thread-Index: AcWZ9r6tMtwEotYUTbKlrq0bkaYQ6wCGg0Aw From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 08 Aug 2005 12:01:45.0715 (UTC) FILETIME=[F2D17430:01C59C10] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable We are not removing DSTM from this spec all the authors know for a fact it is important to operators. If you want further applicability statements we can do that and there is other work in progress. Thanks for you input, /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, August 05, 2005 3:47 PM > To: v6ops@ops.ietf.org > Subject: WGLC ent-analysis-03: DSTM >=20 > Hi, >=20 > (I'll put two most separable & possibly most discussable items in=20 > separate mails.) >=20 > In 8.1: >=20 > Later in the transition process, after the enterprise has > transitioned to a predominately IPv6 infrastructure, the architect > should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or > in the case of early deployment of IPv6-dominant networks DSTM can > be used too. >=20 > and in 8.4: >=20 > DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the > enterprise transition or deployment of IPv6-dominant network links > is desired. DSTM is to being submitted as an IETF Experimental RFC. >=20 > =3D=3D> as it is, DSTM is a way too overloaded a mechanism to be=20 > referred to > without more disclaimers or description. As it is, different=20 > people use > "DSTM" to mean at least the following things: > a) v4-in-v6 tunnels > b) automatically set-up v4-in-v6 tunnels > c) automatic set up of v4-in-v6 tunnels when the host > doesn't have v4 address and an app wants to create a v4 socket > d) automatic monitoring and tear-down of said v4-over-v6 tunnel > when the host detects it no longer needs the address/connectivity > e) plus a number of extensions for even more colorful setups. >=20 > a) doesn't require DSTM; b) can be achieved using a tunnel broker; c) > does not require IETF interoperability (a local implementation choice > when/how to launch the v4-in-v6 activation). d) could also=20 > be considered in > the same category (there are no bits in the wire or anything requiring > interoperability AFAICS on when the host removes the tunnel),=20 > though I'm > skeptical whether even providing that would be a good=20 > engineering choice. >=20 > My point is that I'm having hard time figuring out: > 1) what the document means when it's recommending DSTM, and > 2) based on my analysis above, I do not believe that DSTM=20 > (in the way that > I think it's being referred to) is even needed. >=20 > Therefore my suggestion is to remove references to DSTM=20 > (preferable) or > greatly clarify the assumptions and the requirements on why it should > be necessary. (On the other hand, if the DSTM spec only described the > algorithms for doing c) and d) above in my list, I would have=20 > a lot fewer > concerns -- but as it is, I believe a reference would confuse=20 > more than > help.) >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 08 08:06:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26OJ-0007YN-G3 for v6ops-archive@megatron.ietf.org; Mon, 08 Aug 2005 08:06: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 IAA16620 for ; Mon, 8 Aug 2005 08:06:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E26Lz-0006Z5-1z for v6ops-data@psg.com; Mon, 08 Aug 2005 12:03:39 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E26Lw-0006XT-6q for v6ops@ops.ietf.org; Mon, 08 Aug 2005 12:03:36 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 85725157; Mon, 8 Aug 2005 08:03:35 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 08:03:35 -0400 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: WGLC ent-analysis-03: application vs network driven Date: Mon, 8 Aug 2005 08:03:33 -0400 Message-ID: <936A4045C332714F975800409DE09240BC3585@tayexc14.americas.cpqcorp.net> Thread-Topic: WGLC ent-analysis-03: application vs network driven Thread-Index: AcWZ9tItfM7kCZ3GQTenjIfWTNUVLQCGjahQ From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 08 Aug 2005 12:03:35.0043 (UTC) FILETIME=[33FB9530:01C59C11] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Let us discuss this ok it is valid input. But yes from our view the enterprise will select how the network will be deployed but from two vantage points. One because they want to begin the infrastructure deployment and IPv6 readiness, and two to support key applications they want to operate over IPv6. =20 thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, August 05, 2005 3:49 PM > To: v6ops@ops.ietf.org > Subject: WGLC ent-analysis-03: application vs network driven >=20 > (I'll put two most separable & possibly most discussable=20 > items in separate=20 > mails.) >=20 > =3D=3D> the document seems to have been written based on the = assumption=20 > that first the enterprise decides which kind of network it will run=20 > (dual-IP, v6-only) and whether its applications will be v6-only,=20 > dual-IP or v4, and then takes a look at the surrounding=20 > environment --=20 > and the result is often "oops.. we need translation, tunneling, and a=20 > number of other complexities for our decision to be fulfilled". >=20 > In some cases, this approach may be appropriate (though I=20 > hope this is=20 > not commonplace). In most cases, the better way is to look at what=20 > kind of applications you have or want to have (also the ones=20 > which you=20 > need to communicate with outside the enterprise) and after that make=20 > the decisions (weighing the different tradeoffs of course) which kind=20 > of network topologies would be best suited for the job. >=20 > After this deliberation, the result might be that an enterprise might=20 > have to take a "hard road" in any case, resulting the matrix we're=20 > describing, but the thought process is different. >=20 > Maybe or maybe not this has also been implicit when writing this=20 > document, but this thought process just hasn't been spelled out. It=20 > should be, in a number of places. I think a key message that=20 > needs to=20 > be delivered is, "if a particular scenario is difficult, maybe it is=20 > worth considering alternative assumptions?" [for example, having the=20 > application be dual-IP or network dual-stack] or in other words,=20 > "don't push if there's resistance". >=20 > This issue should probably be discussed in section 3, maybe reminded=20 > briefly in section 6, and again mentioned in appropriate places in=20 > section 8. >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 08 08:07:28 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E26Pg-0000HB-EY for v6ops-archive@megatron.ietf.org; Mon, 08 Aug 2005 08:07: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 IAA16741 for ; Mon, 8 Aug 2005 08:07:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E26PQ-0006yw-D7 for v6ops-data@psg.com; Mon, 08 Aug 2005 12:07:12 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E26PM-0006yO-DY for v6ops@ops.ietf.org; Mon, 08 Aug 2005 12:07:08 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 7B1E1157; Mon, 8 Aug 2005 08:07:07 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 8 Aug 2005 08:05:31 -0400 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: WGLC ent-analysis-03 Date: Mon, 8 Aug 2005 08:05:22 -0400 Message-ID: <936A4045C332714F975800409DE09240BC3586@tayexc14.americas.cpqcorp.net> Thread-Topic: WGLC ent-analysis-03 Thread-Index: AcWZ9y5I71AlBrtXRGKgzypA5/G+YQCGhGJw From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 08 Aug 2005 12:05:31.0184 (UTC) FILETIME=[79354B00:01C59C11] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable thanks for in depth review and comments. Will respond to each point and we highly appreciate your consistent review of this spec and support we are going to make it very clear in the final spec of your significant contributions and logic check to us technically. Sorry I am still behind from all the IETF work. Will catch up as I can. THANK YOU BIG TIME. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Friday, August 05, 2005 3:51 PM > To: v6ops@ops.ietf.org > Subject: WGLC ent-analysis-03 >=20 > Hi, >=20 > Thank you for additional "textual" discussion of the matrix. =20 > IMHO it is > very useful. While I am skeptic about the matrix approach,=20 > modifying that > goes beyond the point of diminishing returns. In general, I think the > document is in a very good shape, though Section 8 (which is a recent > addition) still requires wider review. >=20 > Flights are good at catching up on your reading list :) >=20 > substantial > ----------- >=20 > 1) I still think appendix is a bit inappropriate for this document, > and it be removed from this doc. (I did not review it at length.) >=20 > 2) [see separate mail on app vs network-driven] >=20 > 3) [see separate mail on DSTM] >=20 > 4) >=20 > 8.2 Recognizing Application incompatibilities > [...] >=20 > This leads us to the third theme represented by Scenario E and G, > i.e. incompatible applications communicating across a homogenous > network. Translation is an obvious solution, but not recommended > except for legacy devices at the network edge which cannot or never > will be upgraded to IPv6. A more scaleable solution would be to > use an Application Layer Gateways (ALG) between the incompatible > hosts. >=20 > =3D=3D> I don't understand this theme. In all scenarios from E=20 > to J, it seems > that the application version between the two endpoints is > different. Is this what you meant in the matrix? I fail to=20 > see how that > kind of situation can be addressed by tunneling. (I don't=20 > think that's what > you're implying, but rather that there are typos in the=20 > matrix or I don't > understand its basic assumptions.) >=20 > 5) >=20 > Having IPv6 applications on a Dual-IP host on a v4-only network > lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end > service. ISATAP [ISTP] can be used to provide end node IPv6 > connectivity from nodes on an isolated IPv4 network, through the > use of automatic tunneling of IPv6 in IPv4. >=20 > Enterprise architects should consider providing a Tunnel Broker > [TBRK, TSPB] as a cost effective service to local users or > applications. Tunnel Brokers can be used to provide tunnel setup > for an enterprise using manual configured tunnels, 6to4, or DSTM. > Tunnel Brokers can automate the use of tunnels across an enterprise > deploying IPv6. >=20 > =3D=3D> I think these paragraphs provide a bit too little=20 > context. The first > paragraph also seems to introduce ISATAP and Teredo with=20 > different manner > compared to the tunnel broker. Here's my attempt at rewording: >=20 > Having IPv6 applications on a Dual-IP host on a v4-only network > requires some form of tunneling. Where configured tunnels [BCNF] > are not sufficient, a more automatic solution may be appropriate. > Typical solutions include a tunnel broker [TBRK, TSPB],=20 > ISATAP [ISTP], > or even Teredo [TRDO]. >=20 > (there is more analysis on the tradeoffs of the solutions=20 > later, so I don't > think it's necessary to do that here.) >=20 > 6) >=20 > 11.1 Normative References >=20 >=20 > There are no normative references in this document to depict > correct protocol operation. This document is an analysis technical > effort not a operative or protocol specification. >=20 > =3D=3D> while the "Normative References" section is not meant to=20 > be normative in > that sense, in documents like this, it is typically intended=20 > to include > those documents which are: > 1) required to be understood for understanding this specification, > 2) are work-in-progress and significantly discussed, and the details > mentioned in this document could change before the other drafts > are complete, so we require that those docs must be published > as RFCs before this is published as an RFC, or > 3) other documents which are appropriate for understanding this one > which should be published as RFCs before this draft is done. >=20 > In that light, I'd suggest moving some documents over to the Normative > references: >=20 > BSCN, 6TO4, TRDO, BCNF (note, I'd also refer to=20 > draft-ietf-v6ops-mech-v2 > instead/in addition because it's replacing BCNF) >=20 > Moving these would not hurt: >=20 > CONF, DHCPF, DHCPL, 6TUN, TBRK, ALLOC >=20 > These might also be candidates for moving: >=20 > DNSV6, APPS, NAP, V6SEC, NATDE >=20 > These could probably be removed completely: >=20 > SEC1 (not referred), OSPF, BGP4, ISIS, RIPng >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > almost substantial > ------------------ >=20 > - The second column represents the IP-capability of the > host network wherein the node originated the packet. > (Host 1 Network) >=20 > =3D=3D> I'm sorry, but I'm still not 100% sure on what you mean here. > Do you mean: >=20 > a) "the network where the host plugs into" (i.e., the=20 > subnet), where the > enterprise might have different network elements, or >=20 > b) "the least common denominator in the whole enterprise network". >=20 > Let me try to take an example from scenario A: >=20 > | IPv6 | |Dual IP | | IPv6 | > A | ---- | IPv4 | or |Dual IP| ---- | > | Dual IP | | IPv4 | | Dual IP | >=20 >=20 > Could network 1 address this problem (if the service=20 > provider is dual-IP) > by configuring a manual tunnel from the host 1 to the=20 > enterprises border > router (assumption a) above) or some other component? (With=20 > interpretation > b) above, this wouldn't be possible because there wouldn't be any IPv6 > connectivity, v6-capable routers, etc. from the enterprise to=20 > the ISP.) >=20 > This is important point to get clarified, though it's not as=20 > critical as > before because the recommendations for solutions are no longer=20 > strongly tied to the scenarios. >=20 > ........ >=20 > If the number of nodes to be using IPv6 is reduced, another option > is to use statically configured tunnels. However automatically > configured tunnels are generally preferred. >=20 > =3D=3D> I'm not sure if I agree completely with this phrasing;=20 > I'd recommend > (unless other considerations are on the table, such as the > dynamicity/nomadicity of nodes/tunnels) using static tunnels=20 > when the number > of tunnels is low. I would suggest below (though I would not=20 > object to > spelling out the different tradeoffs further): >=20 > If the number of nodes to be using IPv6 is low, the first option > is to use statically configured tunnels. However, automatically > configured tunnels may be preferable especially if the number is > higher. >=20 > ....... >=20 > A stateless configured node wishing to gain other configuration > information (e.g. DNS, NTP servers) will likely need a Stateful > DHCPv6 [DHCPv6] service available. >=20 > =3D=3D> I'm not sure if this is a typo or is I disagree: "other=20 > configuration" > can very well obtained from a _stateless_ DHCPv6 service. I=20 > think it's also > important to point out, somewhere, that you don't need to config v6 > infortmation (at least at start) if you don't want to. Suggest: >=20 > A stateless configured node wishing to gain other IPv6 configuration > information (e.g. DNS, NTP servers) will likely need at least > stateless DHCPv6 [DHCPL] service. In dual-IP networks,=20 > some enterprises > may also choose to only distribute configuration information using > DHCPv4. >=20 > .... >=20 > 7.4.5 Security >=20 > =3D=3D> I think an important pointer to add at the end of this=20 > section would be > something like: >=20 > Specifically, the firewall policies must be configured=20 > appropriately > especially with regard to ICMPv6 [ICMPFIL]. Blocking all=20 > ICMP messages, > as has often been done with IPv4 with disastrous effects=20 > on, e.g., PMTUD, > must be avoided. >=20 > (where ICMPFIL could be an informative ref to elwyn and janos' draft.) >=20 > .... >=20 > Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to > develop a test network in the enterprise, but will not scale well > for a complete implementation of an IPv6 network. Manual Configured > Tunnels for IPv6 is an IETF Proposed Standard. >=20 > =3D=3D> I think this deserves more text on which scenarios or=20 > cases it doesn't > scale to be fair. For example, >=20 > Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism for > tunneling between network segments, but has scalability limitations if > applied to a large number of host-based tunnels, for example=20 > in scenarios A > or C. Manual Configured Tunnels for IPv6 is an IETF Proposed=20 > Standard. >=20 > .... >=20 > 6to4 [6t4] is a useful tunneling mechanism for deployment if the > enterprise has not obtained a native IPv6 prefix from their > provider. 6to4 is an IETF Proposed Standard. >=20 > =3D=3D> while I don't have strong qualms with this text, I think=20 > it may mislead > the network admin to think 6to4 is a good replacement for a real IPv6 > prefix. It isn't, due to its unpredictability especially with "return > routing" scenarios. Therefore, I'd suggest adding a bit more=20 > warning here, > for example add "Due to the unpredicatability of "return=20 > path", it may not > be suitable for production use" as a second last paragraph. >=20 > .... >=20 > NAT-PT [NATPT] can be useful when there is no other means to access > an IPv4 node behind a NAT network that only has a private address. > But, it is recommended that the enterprise also look at the ability > to provide access to that IPv4 node using a Proxy or Application > Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF > Proposed Standard. >=20 > =3D=3D> please also refer to the applicability statement and=20 > state that it is > being reclassified to experimental. >=20 > ISATAP [ISTP] is a useful tunneling mechanism when the enterprise > has deployed IPv6, and there are particpating nodes for the IPv6 > deployment that exist on IPv4 networks. ISATAP is being submitted as > an IETF Experimental RFC. >=20 > =3D=3D> the last sentence is not pedantically correct, I believe; > RFCs that are submitted through the RFC-editor are not "IETF" > RFCs per se. I suggest: "ISATAP has been submitted as an individual > submission to the RFC editor for Experimenal RFC" or=20 > something like that. > (similar applies to the other mechanisms.) (also s/partic/partici/) >=20 > .... >=20 > Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the > Enterprise wants to automate the setup of tunnels in the enterprise, > and a tunnel broker can be used to support 6to4, ISATAP, and DSTM > mechanisms. Tunnel Broker set-up protocol is being submitted as an > IETF Experimental RFC. >=20 > =3D=3D> I believe at least TSP has considered "Informational"=20 > instead (at least > that's what Florent said). The base spec, AFAICS, does not=20 > include the > 6to4, ISATAP, and DSTM extensions, so I'd suggest removing=20 > that part of the > sentence. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > semi-editorial > -------------- >=20 > -- maybe still not clear enough what the 'host X network' means? >=20 >=20 > [In section 4.4.2.1] > In the widespread dual-IP scenario, a more structured, manageable > method is required, where the administrator has control of the > deployment per-link and (ideally) long-term, aggregatable global > IPv6 addressing is obtained, planned and used from the outset. >=20 > =3D=3D> I don't understand the relevance of v6 addressing to the = tunnel > discussion. Maybe some of this text should be removed or elaborated? > (If obtaining global addresses is/should be mentioned, it=20 > should probably be > done higher in the document hierarchy?; this is mentioned in=20 > 7.3 at least) >=20 > When the enterprise's users are off-site, and using an ISP that > does not support any native IPv6 service or IPv6 transition aids, > the enterprise may consider deploying it's own remote IPv6 access > support, as described in Section 7.5.2 below. >=20 > =3D=3D> there is no section 7.5.2 ..? >=20 > 5.1 Internal versus External Tunnel End Point >=20 > Let's assume the upstream provider has deployed some IPv6 services, > either native IPv6 in its backbone or in the access network, or > some combination of both (Scenario B of Table 1). [...] >=20 > =3D=3D> this has some very good text, but is this (enterprise has=20 > no v6 infra) > on the borderline of being out-of-scope, wrt. the paragraph in Intro: >=20 > We are also assuming that the enterprise deployment is one being > undertaken by the network administration team, i.e. this document > is not discussing the case of an individual user gaining IPv6 > connectivity (to some external IPv6 provider) from within an > enterprise network. [...] >=20 > (these two cases are, at least from the ISP's perspectively,=20 > apparently > pretty close to equivalent..) So, I'm not sure whether=20 > changes or further > applicability text would be useful. I think the external tunnel point > discussion may also apply to Scenario F and some others (e.g., if your > business partner would want to use v6 application to reach=20 > your v6 app, but > you'd have to provide a tunnel to him. >=20 > ..... >=20 > For internal routing, an appropriate interior routing protocol may > be deployed. IPv6 routing protocols that can be used are as > follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng > [RIPng]. >=20 > =3D=3D> maybe a more informative way for the reader would be to=20 > point to the ISP > analysis on the routing protocol selection (the only=20 > difference here is that > RIPng may be a bit more applicable in enterprise networks,=20 > but I'm not sure > whether that is worth mentioning), for example: >=20 > For internal routing, an appropriate interior routing protocol may > be deployed. The routing protocol selection and the tradeoffs > have been discussed in Section X of [ISPA], also applicable here. >=20 > .... >=20 >=20 > ... >=20 > Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; > there is support for DHCPv6 to assign privacy addresses to nodes in > managed environments. >=20 > =3D=3D> I'd say more briefly and less controversially: >=20 > Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; > there is also support for DHCPv6 to assign privacy addresses. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > The audience for this document is the enterprise network team > considering deployment of IPv6. The document will be useful for > enterprise teams that will have to determine the IPv6 transition > strategy for their enterprise. >=20 > =3D=3D> isn't this saying almost the same thing twice? maybe=20 > slight reword. >=20 > - Requirements or Transtion at the Providers network >=20 > =3D=3D> s/Trans/Transi/ (this seems a bit obvious as well,=20 > because this is an > enterprise doc, not provider doc..) >=20 > We are also assuming that the enterprise deployment is one being > undertaken by the network administration team, i.e. this document >=20 > =3D=3D> remove "one" ? >=20 > enterprise. In sectioin 7 we discuss general issues and >=20 > =3D=3D> s/sectioin/section/ >=20 > The notional enterprise network is comprised of hosts attached to >=20 > =3D=3D> do you mean "notational" with notional or something else? > (many instances of this) >=20 > Obviously Table 1 does not describe every possible scenario. > Trivial notional networks (such as pure IPv4, pure IPv6, and > ubiquitous Dual-IP) are not addressed. However, the authors feel > these ten represent the vast majority of transitional situations > likely to be encountered in today's enterprise. Therefore, we will > use these ten to address the analysis for enterprise deployment. >=20 > =3D=3D> this seems to overlap with an earlier (and more fleshed=20 > out) paragraph > starting with "Addressing every possible combination of network > IP-capability in this notional enterprise network is=20 > impractical, [...]". > I'd suggest some combining to remove the overlap. >=20 > use IPv6 applications, but has yet to transition its internal > networks and it's Service Provider also lags, offering only a v4 > IP-service. >=20 > =3D=3D> s/it's/its/ (the same in a couple of other places) >=20 > Consider the situation where there exists IPv6 edge routers which > are IPv6-capable, while others,and perhaps the enterprise backbone >=20 > =3D=3D> s/,and/, and/ >=20 > There is a need for end-to-end communication with IPv6, but the > infrastructure only supports IPv4 routing. Thus, the only viable > method for end-to-end communication with IPv6 is to tunnel the > traffic over the existing IPv4 infrastructure, within this analysis > documents boundaries defined. >=20 > =3D=3D> I'm not sure if I understand the last part of the last = sentence, > starting from "within ...". Maybe slight reword? >=20 > IPv6-dominant network, except if required at to support edge IPv4 > networks. >=20 > =3D=3D> remove "at" ? >=20 > In each case, communicating with an IPv4 end host or over an IPv4 > network requires a transition point exist within the network to > support that operation. >=20 > =3D=3D> s/a transition point exist/that a transition point exists/ > or s/exist/to exist/ ? >=20 > network must aquire an IPv4 address (to interoperate with the IPv4 >=20 > =3D=3D> s/aquire/acquire/ >=20 > IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use >=20 > =3D=3D> s/IPSEC/IPsec/ >=20 > this mechanism provides no automated tunnnel configuration. >=20 > =3D=3D> s/tunnnel/tunnel/ >=20 > driven by the position of the incompatible touchpoint. If a local > network is incompatible than host tunneling is appropriate. If the >=20 > =3D=3D> s/than/then/ >=20 > service both IPv4 and IPv6 data streams that are simulataneously >=20 > =3D=3D> s/simulataneously/simultaneously/ >=20 > The following transition mechanism have at least two independent >=20 > =3D=3D> s/mechanism/mechanisms/ >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Tue Aug 09 14:17:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Yfc-0005OF-LT for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 14:17: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 OAA27352 for ; Tue, 9 Aug 2005 14:17:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2Ybe-0001BZ-QA for v6ops-data@psg.com; Tue, 09 Aug 2005 18:13:42 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2Ybc-0001BH-7H for v6ops@ops.ietf.org; Tue, 09 Aug 2005 18:13:40 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 09 Aug 2005 11:13:40 -0700 X-IronPort-AV: i="3.96,92,1122879600"; d="scan'208"; a="203786085:sNHT302548446" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j79IDXZ1025974 for ; Tue, 9 Aug 2005 11:13:34 -0700 (PDT) From: fred@cisco.com Received: (fred@localhost) by irp-view7.cisco.com (8.11.2/CISCO.WS.1.2) id j79IDXE00886 for v6ops@ops.ietf.org; Tue, 9 Aug 2005 11:13:33 -0700 (PDT) Date: Tue, 9 Aug 2005 11:13:33 -0700 (PDT) Message-Id: <200508091813.j79IDXE00886@irp-view7.cisco.com> To: v6ops@ops.ietf.org Subject: v6ops Proceedings Reivew X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Before I actually post minutes for the meeting at the IETF site, I would appreciate review. Cedric Aoun (thanks!) took notes during the recent meeting, which are posted at ftp://ftpeng.cisco.com/fred/v6ops/v6ops-01-08-2005.txt. Supporting documents include: ftp://ftpeng.cisco.com/fred/v6ops/v6ops-agenda.pdf ftp://ftpeng.cisco.com/fred/v6ops/IETF63-draft-ietf-v6ops-nap-01.pdf ftp://ftpeng.cisco.com/fred/v6ops/IETF63_v6Ops_bb-scenarios_update_v2.pdf ftp://ftpeng.cisco.com/fred/v6ops/IPv6_Ent_Analysis_IET63_Update_Aug_2005.pdf ftp://ftpeng.cisco.com/fred/v6ops/distributed_security_framework_ietf63.pdf ftp://ftpeng.cisco.com/fred/v6ops/icmpv6-filtering-v6ops-ietf63-02.pdf ftp://ftpeng.cisco.com/fred/v6ops/renumbering-join-paris-20050801.pdf ftp://ftpeng.cisco.com/fred/v6ops/sec-draft-02-v6ops-ietf63-01.pdf ftp://ftpeng.cisco.com/fred/v6ops/v6ops-intro.pdf ftp://ftpeng.cisco.com/fred/v6ops/v6ops-tunnels.pdf ftp://ftpeng.cisco.com/fred/v6ops/Net-renumbering.pdf 1,$p From owner-v6ops@ops.ietf.org Tue Aug 09 14:59:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ZKK-0004cq-0i for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 14:59:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29614 for ; Tue, 9 Aug 2005 14:59:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2ZJ1-0004Ro-Nn for v6ops-data@psg.com; Tue, 09 Aug 2005 18:58:31 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2ZIy-0004RR-R6 for v6ops@ops.ietf.org; Tue, 09 Aug 2005 18:58:28 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2005 11:58:29 -0700 X-IronPort-AV: i="3.96,93,1122879600"; d="scan'208"; a="653798063:sNHT33274240" 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 j79IwPoo021974; Tue, 9 Aug 2005 11:58:26 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79ItOIT025377; Tue, 9 Aug 2005 11:55:25 -0700 In-Reply-To: <936A4045C332714F975800409DE09240BC3584@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE09240BC3584@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: "Pekka Savola" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: WGLC ent-analysis-03: DSTM Date: Tue, 9 Aug 2005 11:58:22 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=3170; t=1123613725; x=1124045925; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20WGLC=20ent-analysis-03=3A=20DSTM| From:Fred=20Baker=20| Date:Tue,=209=20Aug=202005=2011=3A58=3A22=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=kiwnZT9jGnE+Qe071H3fHUBIfK0IURFAkZDwduy4Kk312VEU0w7Zdl1ook03g1gmbn6hWOeq hHmfdmesRJJiKspZ0tyVgQqGHLPkuJojCl2HKkQy9GmgQqs95QiTgzWZBLvxqmkP5BbpBnUtpJ4 AVjb+gYXnhzGkNPmAm3yWGAw= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim: I don't think Pekka was saying that Dual-Stack as described in RFCs 1933 and 2765 is not important to operators. I think that he was saying that extending that to include an Experimental protocol that has specific algorithms attached to it that haven't been agreed to seems an odd recommendation from a working group document. I think you need to take a little less strident attitude. Your commentary re DSTM sounds a little like "this is my protocol and you don't get to comment on it". If you can't find a way to accept Pekka's commentary, we may need to make this no longer be a working group draft, and advise the IESG to ensure that any RFC Editor path submission of it be published with a note stating that it was not agreed to by the relevant working group. Lets find common ground here, guys. Fred On Aug 8, 2005, at 5:01 AM, Bound, Jim wrote: > We are not removing DSTM from this spec all the authors know for a > fact > it is important to operators. If you want further applicability > statements we can do that and there is other work in progress. > > Thanks for you input, > /jim > > >> -----Original Message----- >> From: owner-v6ops@ops.ietf.org >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola >> Sent: Friday, August 05, 2005 3:47 PM >> To: v6ops@ops.ietf.org >> Subject: WGLC ent-analysis-03: DSTM >> >> Hi, >> >> (I'll put two most separable & possibly most discussable items in >> separate mails.) >> >> In 8.1: >> >> Later in the transition process, after the enterprise has >> transitioned to a predominately IPv6 infrastructure, the architect >> should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or >> in the case of early deployment of IPv6-dominant networks DSTM can >> be used too. >> >> and in 8.4: >> >> DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the >> enterprise transition or deployment of IPv6-dominant network links >> is desired. DSTM is to being submitted as an IETF Experimental RFC. >> >> ==> as it is, DSTM is a way too overloaded a mechanism to be >> referred to >> without more disclaimers or description. As it is, different >> people use >> "DSTM" to mean at least the following things: >> a) v4-in-v6 tunnels >> b) automatically set-up v4-in-v6 tunnels >> c) automatic set up of v4-in-v6 tunnels when the host >> doesn't have v4 address and an app wants to create a v4 socket >> d) automatic monitoring and tear-down of said v4-over-v6 tunnel >> when the host detects it no longer needs the address/ >> connectivity >> e) plus a number of extensions for even more colorful setups. >> >> a) doesn't require DSTM; b) can be achieved using a tunnel broker; c) >> does not require IETF interoperability (a local implementation choice >> when/how to launch the v4-in-v6 activation). d) could also >> be considered in >> the same category (there are no bits in the wire or anything >> requiring >> interoperability AFAICS on when the host removes the tunnel), >> though I'm >> skeptical whether even providing that would be a good >> engineering choice. >> >> My point is that I'm having hard time figuring out: >> 1) what the document means when it's recommending DSTM, and >> 2) based on my analysis above, I do not believe that DSTM >> (in the way that >> I think it's being referred to) is even needed. >> >> Therefore my suggestion is to remove references to DSTM >> (preferable) or >> greatly clarify the assumptions and the requirements on why it should >> be necessary. (On the other hand, if the DSTM spec only described the >> algorithms for doing c) and d) above in my list, I would have >> a lot fewer >> concerns -- but as it is, I believe a reference would confuse >> more than >> help.) >> >> -- >> 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 Aug 09 15:28:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2Zlv-0000sB-FL for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 15:28: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 PAA02524 for ; Tue, 9 Aug 2005 15:28:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2Zjy-0006sQ-Rt for v6ops-data@psg.com; Tue, 09 Aug 2005 19:26:22 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2Zju-0006s8-Py for v6ops@ops.ietf.org; Tue, 09 Aug 2005 19:26:18 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id B35611C9; Tue, 9 Aug 2005 15:26:17 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 15:26:17 -0400 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: WGLC ent-analysis-03: DSTM Date: Tue, 9 Aug 2005 15:26:15 -0400 Message-ID: <936A4045C332714F975800409DE09240C47AF9@tayexc14.americas.cpqcorp.net> Thread-Topic: WGLC ent-analysis-03: DSTM Thread-Index: AcWdFFb0uay+eoUVR5qifiFpTkm2hAAA2XhA From: "Bound, Jim" To: "Fred Baker" Cc: "Pekka Savola" , X-OriginalArrivalTime: 09 Aug 2005 19:26:17.0528 (UTC) FILETIME=[36DEE380:01C59D18] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred, It is not a strident attitude. DSTM was work in the IETF for minimum two years, has been deployed in test networks, and the response was the authors response not Jim's response. I think we need applicability around it for sure. Please don't threaten me or the authors work because of a quick email that I stated would have more serious follow up. That is inappropriate and I would like an apology for your assumption that was my intention? I think you jumped the gun on the response. We are not going to remove DSTM at this time, first we would like to attempt applicability statements. Thanks for your input, /jim=20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, August 09, 2005 2:58 PM > To: Bound, Jim > Cc: Pekka Savola; v6ops@ops.ietf.org > Subject: Re: WGLC ent-analysis-03: DSTM >=20 > Jim: >=20 > I don't think Pekka was saying that Dual-Stack as described in RFCs =20 > 1933 and 2765 is not important to operators. I think that he was =20 > saying that extending that to include an Experimental protocol that =20 > has specific algorithms attached to it that haven't been agreed to =20 > seems an odd recommendation from a working group document. >=20 > I think you need to take a little less strident attitude. Your =20 > commentary re DSTM sounds a little like "this is my protocol and you =20 > don't get to comment on it". If you can't find a way to accept =20 > Pekka's commentary, we may need to make this no longer be a working =20 > group draft, and advise the IESG to ensure that any RFC Editor path =20 > submission of it be published with a note stating that it was not =20 > agreed to by the relevant working group. >=20 > Lets find common ground here, guys. >=20 > Fred >=20 >=20 > On Aug 8, 2005, at 5:01 AM, Bound, Jim wrote: >=20 > > We are not removing DSTM from this spec all the authors know for a =20 > > fact > > it is important to operators. If you want further applicability > > statements we can do that and there is other work in progress. > > > > Thanks for you input, > > /jim > > > > > >> -----Original Message----- > >> From: owner-v6ops@ops.ietf.org > >> [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > >> Sent: Friday, August 05, 2005 3:47 PM > >> To: v6ops@ops.ietf.org > >> Subject: WGLC ent-analysis-03: DSTM > >> > >> Hi, > >> > >> (I'll put two most separable & possibly most discussable items in > >> separate mails.) > >> > >> In 8.1: > >> > >> Later in the transition process, after the enterprise has > >> transitioned to a predominately IPv6 infrastructure, the=20 > architect > >> should implement the Dual-IP Transition Mechanism [DSTM,=20 > DSTM+]. Or > >> in the case of early deployment of IPv6-dominant=20 > networks DSTM can > >> be used too. > >> > >> and in 8.4: > >> > >> DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the > >> enterprise transition or deployment of IPv6-dominant network links > >> is desired. DSTM is to being submitted as an IETF Experimental RFC. > >> > >> =3D=3D> as it is, DSTM is a way too overloaded a mechanism to be > >> referred to > >> without more disclaimers or description. As it is, different > >> people use > >> "DSTM" to mean at least the following things: > >> a) v4-in-v6 tunnels > >> b) automatically set-up v4-in-v6 tunnels > >> c) automatic set up of v4-in-v6 tunnels when the host > >> doesn't have v4 address and an app wants to create a v4 socket > >> d) automatic monitoring and tear-down of said v4-over-v6 tunnel > >> when the host detects it no longer needs the address/=20 > >> connectivity > >> e) plus a number of extensions for even more colorful setups. > >> > >> a) doesn't require DSTM; b) can be achieved using a tunnel=20 > broker; c) > >> does not require IETF interoperability (a local=20 > implementation choice > >> when/how to launch the v4-in-v6 activation). d) could also > >> be considered in > >> the same category (there are no bits in the wire or anything =20 > >> requiring > >> interoperability AFAICS on when the host removes the tunnel), > >> though I'm > >> skeptical whether even providing that would be a good > >> engineering choice. > >> > >> My point is that I'm having hard time figuring out: > >> 1) what the document means when it's recommending DSTM, and > >> 2) based on my analysis above, I do not believe that DSTM > >> (in the way that > >> I think it's being referred to) is even needed. > >> > >> Therefore my suggestion is to remove references to DSTM > >> (preferable) or > >> greatly clarify the assumptions and the requirements on=20 > why it should > >> be necessary. (On the other hand, if the DSTM spec only=20 > described the > >> algorithms for doing c) and d) above in my list, I would have > >> a lot fewer > >> concerns -- but as it is, I believe a reference would confuse > >> more than > >> help.) > >> > >> --=20 > >> Pekka Savola "You each name yourselves=20 > king, yet the > >> Netcore Oy kingdom bleeds." > >> Systems. Networks. Security. -- George R.R. Martin: A=20 > Clash of Kings > >> > >> > > >=20 From owner-v6ops@ops.ietf.org Tue Aug 09 16:03:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2aKB-0004RV-27 for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:03: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 QAA06087 for ; Tue, 9 Aug 2005 16:03:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2aIt-0009kS-Tl for v6ops-data@psg.com; Tue, 09 Aug 2005 20:02:27 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2aIr-0009jl-3w for v6ops@ops.ietf.org; Tue, 09 Aug 2005 20:02:25 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 3F043B3 for ; Tue, 9 Aug 2005 16:02:22 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 16:02:21 -0400 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: Enterprise Analysis DSTM Issue Date: Tue, 9 Aug 2005 16:02:20 -0400 Message-ID: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> Thread-Topic: Enterprise Analysis DSTM Issue Thread-Index: AcWdHUApq+2wYd74ReiFdo10dMiOaA== From: "Bound, Jim" To: X-OriginalArrivalTime: 09 Aug 2005 20:02:21.0916 (UTC) FILETIME=[40F249C0:01C59D1D] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable WG Members, For DSTM we are going to discuss as authors what we want to do here per Fred's mail telling us we could go away if we leave it in the spec, at least my read of his mail. This will take us a few weeks as some are on summer vacation. For your information if your new. DSTM had a minimum of two years IETF NGTRANS working group discussion, and had discussion before that as the AIIH proposal. In fact the authors reduced and altered the DSTM protocol several times per the NGTRANS Chairs input over the years and the WG. =20 There will be a series of DSTM specifications sent for Experimental RFC in the next 6 months. At the same time there will be a new industry focus on DSTM, that will be quite rigorous, and produce a set of deployment guidelines including DSTM for the IPv6 Transition. =20 I realize DSTM is not an Experimental RFC now, but that was because we were not sure best path to move the work until about 3 weeks ago. But ISATAP is still awaiting Experimental RFC, was only discussed in NGTRANS too, not v6ops, and we still need a Tunnel Set Up Protocol. Yet both of these are fine to reference in the spec? If true, is that "fair". DSTM is a mechanism that is part of the plan for several enterprises, it is a valid reference. No need to respond or support this mail that is not its purpose. But I want you the WG members to understand our decision or my "individual" decision when it is made in the next few weeks. Also it would have been nice if this could have been brought up when I asked are there other issues in person at the Paris IETF last week. We could have all met that care in person then at that IETF event. /jim From owner-v6ops@ops.ietf.org Tue Aug 09 16:33:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2amz-0003gg-P9 for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:33:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12722 for ; Tue, 9 Aug 2005 16:33:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2akx-000CBs-I3 for v6ops-data@psg.com; Tue, 09 Aug 2005 20:31:27 +0000 Received: from [161.114.80.246] (helo=tayrelbas03.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2aks-000CBO-RX for v6ops@ops.ietf.org; Tue, 09 Aug 2005 20:31:22 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id CF985BA for ; Tue, 9 Aug 2005 16:31:21 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 16:31:21 -0400 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: Enterprise Analysis Disclaimer on DSTM Date: Tue, 9 Aug 2005 16:31:20 -0400 Message-ID: <936A4045C332714F975800409DE09240C47B66@tayexc14.americas.cpqcorp.net> Thread-Topic: Enterprise Analysis Disclaimer on DSTM Thread-Index: AcWdIUz6EZqbWOd3QV6SQsTdDbDVMA== From: "Bound, Jim" To: X-OriginalArrivalTime: 09 Aug 2005 20:31:21.0603 (UTC) FILETIME=[4DE17530:01C59D21] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable WG Members, I also want to relay as individual that DSTM references are not a "Jim" attitude, but referenced because it is being used in the market and as I stated in previous mail has had IETF discussion, in our archives. DSTM, back to AIIH, is a method to support a specific IPv6 deployment model. In fact two entities took two ideas from AIIH and tried to patent them for other purposes, and I stopped those claiming public disclosure back at the Munich IETF (IETF 39 Munich August 1997). DSTM is far bigger than I now and not "my" spec or agenda at all. There are now about 25 top engineers and implementers working on the next release of DSTM specs, within industry. In addition enterprises that have already put out out RFIs for IPv6 Transition scenarios that have requested input on use of DSTM as a "method". DSTM and its architecture model for IPv6 Transition and operational aspects will be deployed in the market and widely. /jim=20 From owner-v6ops@ops.ietf.org Tue Aug 09 16:51:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2b4Q-0003pW-TO for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 16:51:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13704 for ; Tue, 9 Aug 2005 16:51:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2b3J-000E4T-94 for v6ops-data@psg.com; Tue, 09 Aug 2005 20:50:25 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2b3I-000E3u-5T for v6ops@ops.ietf.org; Tue, 09 Aug 2005 20:50:24 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 09 Aug 2005 13:50:22 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j79KoJ0J022553; Tue, 9 Aug 2005 13:50:19 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79KlKIl026304; Tue, 9 Aug 2005 13:47:20 -0700 In-Reply-To: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Enterprise Analysis DSTM Issue Date: Tue, 9 Aug 2005 13:50:18 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=4977; t=1123620441; x=1124052641; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Enterprise=20Analysis=20DSTM=20Issue| From:Fred=20Baker=20| Date:Tue,=209=20Aug=202005=2013=3A50=3A18=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=e44Xqrbl+1sQzoRhZRTGY3mCTDGo2AI74UiyTeTSsroOl+oIabqmSwGnwD+W0qmexfuKGtrF fZXu6Nk+z337QM2tr030gW/mt1pUmjgJNOt2RH4BOvh8/uvrFfjSJMYVsCgoLmDWOMRn3E2aGjx BV+BFz6dVLVJSwCzg5sUkf/M= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit let's clarify on the conversation. a) Pekka said that the term "Dual-Stck" was heavily overloaded, and it didn't seem wise for the working group to recommend something that was so unclear. b) You said that you had no intention of removing DSTM (your experimental work) from the draft regardless of working group (Pekka's) input, because you had customers interested in running DSTM. c) I said that a working group draft needs to reflect working group input, and that if this could not be accomplished then maybe the document should not be a working group document. That is not a position I plan to apologize for; it is also related to the reason that v6ops doesn't work on transition strategies - the various transition discussions in v6ops did not lead to convergence on a single or small number of recommended strategies. d) You now have your back up. Pekka's comments originate from the dual use of the term "dual stack". The IETF has a long-standing recommendation that a network should run both IPv4 and IPv6 (network layer forwarding, routing, and so on) natively, allowing end systems to use either protocol with the expectations one would have of any native deployment. This is described as "dual stack" in RFC 1933 and its successor 2893, in several RFCs describing potential transition mechanisms (2765, 2766, and 2767 come quickly to mind). The term "dual stack" is also used by DSTM. But DSTM doesn't actually run two stacks in the network. It runs an IPv6-only network (at least as far as its customers are concerned) and provides a way for IPv4 systems to rendezvous over it and tunnel through it, allowing end systems to run dual stacks. In your words: DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the enterprise transition or deployment of IPv6-dominant network links is desired. DSTM is to being submitted as an IETF Experimental RFC. Pekka's observation is that while this is mostly transparent to the end system, it is hardly transparent in the network and (being experimental) is not something the IETF is at this time recommending. This reflects my comment to you of perhaps two months ago. I'm all for your draft discussing dual stack mechanisms - mechanisms that use two stacks, consistent with RFC 2893. But recommending DSTM in a working group recommendation is not consistent with its experimental status. RFC 2026 says, in section 4.2.1: The "Experimental" designation typically denotes a specification that is part of some research or development effort. Such a specification is published for the general information of the Internet technical community and as an archival record of the work, subject only to editorial considerations and to verification that there has been adequate coordination with the standards process (see below). An Experimental specification may be the output of an organized Internet research effort (e.g., a Research Group of the IRTF), an IETF Working Group, or it may be an individual contribution. and in section 3.3: (d) Limited Use: The TS is considered to be appropriate for use only in limited or unique circumstances. For example, the usage of a protocol with the "Experimental" designation should generally be limited to those actively involved with the experiment. In other words, an experimental protocol or procedure may be a perfectly good protocol or procedure and may be a candidate for future standardization. It may have customers using it. However, its general utility has not been shown at the point in time that it has been given that status, and the protocol or procedure is not recommended for general deployment until the experiment has been run. So, I have two expectations of a working group document: that it reflect the opinions of the working group, and that it reflect the recommendations of the IETF. As you and I discussed in July, the statement Later in the transition process, after the enterprise has transitioned to a predominately IPv6 infrastructure, the architect should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. fails the latter point, and from the sound of Pekka's comment, fails the former point as well. I appreciate that you are accepting a number of Pekka's other comments. I'd like you to consider carefully his comment regarding DSTM. On Aug 9, 2005, at 1:02 PM, Bound, Jim wrote: > WG Members, > > For DSTM we are going to discuss as authors what we want to do here > per > Fred's mail telling us we could go away if we leave it in the spec, at > least my read of his mail. This will take us a few weeks as some > are on > summer vacation. > > For your information if your new. DSTM had a minimum of two years > IETF > NGTRANS working group discussion, and had discussion before that as > the > AIIH proposal. In fact the authors reduced and altered the DSTM > protocol several times per the NGTRANS Chairs input over the years and > the WG. > > There will be a series of DSTM specifications sent for Experimental > RFC > in the next 6 months. At the same time there will be a new industry > focus on DSTM, that will be quite rigorous, and produce a set of > deployment guidelines including DSTM for the IPv6 Transition. > > I realize DSTM is not an Experimental RFC now, but that was because we > were not sure best path to move the work until about 3 weeks ago. But > ISATAP is still awaiting Experimental RFC, was only discussed in > NGTRANS > too, not v6ops, and we still need a Tunnel Set Up Protocol. Yet > both of > these are fine to reference in the spec? If true, is that "fair". > > DSTM is a mechanism that is part of the plan for several > enterprises, it > is a valid reference. > > No need to respond or support this mail that is not its purpose. > But I > want you the WG members to understand our decision or my "individual" > decision when it is made in the next few weeks. > > Also it would have been nice if this could have been brought up when I > asked are there other issues in person at the Paris IETF last > week. We > could have all met that care in person then at that IETF event. > > /jim > From owner-v6ops@ops.ietf.org Tue Aug 09 17:15:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2bRr-0007RB-1m for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 17:15: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 RAA15182 for ; Tue, 9 Aug 2005 17:15:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2bQc-000HNR-Cy for v6ops-data@psg.com; Tue, 09 Aug 2005 21:14:30 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2bQb-000HNC-8T for v6ops@ops.ietf.org; Tue, 09 Aug 2005 21:14:29 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j79LESqA011960 for ; Tue, 9 Aug 2005 22:14:28 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id WAA29844 for ; Tue, 9 Aug 2005 22:13:55 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j79LDtw29684 for v6ops@ops.ietf.org; Tue, 9 Aug 2005 22:13:55 +0100 Date: Tue, 9 Aug 2005 22:13:55 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050809211354.GD27778@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 09, 2005 at 01:50:18PM -0700, Fred Baker wrote: > > c) I said that a working group draft needs to reflect working group > input, and that if this could not be accomplished then maybe the > document should not be a working group document. That is not a > position I plan to apologize for; it is also related to the reason > that v6ops doesn't work on transition strategies - the various > transition discussions in v6ops did not lead to convergence on a > single or small number of recommended strategies. And here's the funny thing, or it is if I understood Paris correctly. At IETF 62, the v6tc BoF showed one way forward for nailing down tunnelling solutions (which could include DSTM). Sadly due to blockage somewhere in the IETF upper reaches the WG never formed. At Paris, a non-advertised BoF on tunneling, called 'lrw' (!?) was held with near-identical goals to v6tc. And now we hear that lrw (hopefully with a better name) will be formed, and as an Internet area WG will be able to do protocol work. Provided the work is based on existing drafts. This is good. So after all the stalling since ngtrans closed up, we now have a WG that *could* publish DSTM, or something very like it, potentially, since it covers 4 in 6 and 6 in 4 in its charter (and oddly inter-network tunnelling). Anyway, one could see tunneling protocols emerging soon from lrw. > Pekka's observation is that while this is mostly transparent to the > end system, it is hardly transparent in the network and (being > experimental) is not something the IETF is at this time recommending. But lrw has something not too different as its goal? What does the IETF recommend for dual-stack nodes in an IPv6 infrastructure? > So, I have two expectations of a working group document: that it > reflect the opinions of the working group, and that it reflect the > recommendations of the IETF. As you and I discussed in July, the > statement > > Later in the transition process, after the enterprise has > transitioned to a predominately IPv6 infrastructure, the architect > should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. > > fails the latter point, and from the sound of Pekka's comment, fails > the former point as well. Something 'like it' is likely to be needed though? e.g. transitioned to a predominately IPv6 infrastructure, the architect is likely to need to deploy IPv4-in-IPv6 tunnelling solutions, such as the Dual-IP Transition Mechanism [DSTM, DSTM+]. ? But again, what would the IETF's recommended tool be here? Tim From owner-v6ops@ops.ietf.org Tue Aug 09 17:58:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2c6t-0008QO-Gh for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 17:58:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17115 for ; Tue, 9 Aug 2005 17:58:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2c4p-000MHK-8i for v6ops-data@psg.com; Tue, 09 Aug 2005 21:56:03 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2c4n-000MH1-D0 for v6ops@ops.ietf.org; Tue, 09 Aug 2005 21:56:01 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 09 Aug 2005 14:56:01 -0700 X-IronPort-AV: i="3.96,94,1122879600"; d="scan'208"; a="653833383:sNHT33879220" 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 j79Ltr0J022718; Tue, 9 Aug 2005 14:55:54 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j79Lqvrh026906; Tue, 9 Aug 2005 14:52:57 -0700 In-Reply-To: <20050809211354.GD27778@login.ecs.soton.ac.uk> References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Enterprise Analysis DSTM Issue Date: Tue, 9 Aug 2005 14:55:55 -0700 To: Tim Chown X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=2907; t=1123624377; x=1124056577; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Enterprise=20Analysis=20DSTM=20Issue| From:Fred=20Baker=20| Date:Tue,=209=20Aug=202005=2014=3A55=3A55=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=KsfQpqiosnaqPx240F8sNVgHVP4thzRw/GoWaqTphPdG15meIMKLp6gGU7/lb/di35l10ZhQ No3IkPI2ycMAB5koRL8LQGPLtFp14J61lQXLmHd7p4U3ngbb6fy9t7O60muC4rRkFepjukRYi0M IBFNGLpEvRV4QH8GKePHsH9A= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 9, 2005, at 2:13 PM, Tim Chown wrote: > > What does the IETF recommend for dual-stack nodes in an IPv6 > infrastructure? > The IETF's current recommendations are encapsulated in http:// www.ietf.org/rfc/rfc2893.txt. The abstract is: This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6. This document obsoletes RFC 1933. As Jim is wont to point out, this doesn't address the case of an IPv6- only infrastructure. The deployment of IPv6-only infrastructures greatly complicates the transition, as we have no guarantee that there is a way to bridge IPv6 deployed over any given IPv4 infrastructure, and the presence of IPv6-only infrastructures means that we can no longer make that guarantee for IPv4/IPv6 either. In addition, given that there are a variety of different transition models, many of which similarly pick off a piece of the puzzle without analyzing its effectiveness end to end: draft-blanchet-v6ops-tunnelbroker-tsp-02.txt draft-despres-v6ops-transition-v5roadmap-00.txt draft-huitema-v6ops-teredo-05.txt draft-kim-v6ops-ipv6overwibro-issues-00.txt draft-liumin-v6ops-silkroad-03.txt draft-massar-v6ops-heartbeat-01.txt draft-massar-v6ops-tunneldiscovery-00.txt draft-ooms-v6ops-bgp-tunnel-05.txt Even if every IPv4-only or IPv6-only network provides a way to bridge the other over it, I'm not aware of a proof that end-to-end connectivity is eventually assured, as I don't have a guarantee that they will not touch each other and (as would be required) provide all relevant transition mechanisms over all relevant paths. There is a good article on this concept at http://www.isen.com/papers/ Dawnstupid.html. Yes, you heard this from someone whose day job is with a company that likes to talk about the "Intelligent Information Network". Let's just say that I don't work in marketing... Oh, by the way, as IPv4 address space allocation in fact approaches impossibility, the deployment of IPv6-only infrastructure is not only predictable, it is unavoidable. At this point, it is very avoidable, and I have a hard time arguing that the complications resulting from it are preferable to the complications of running a dual stack network. I'm all for lrw, v6tc, or whatever it winds up being called. I was last time around as well. AFAIK, v6tc is *also* not chartered to solve the entire complexity of the end to end problem - it is chartered to come up with a rendezvous protocol for a tunneling solution, and presumably not a dozen mutually incompatible ones. From what Mark Townsley and Dave Ward told me, something like DSTM might be part of that, but it has to manage an arbitrary underlying tunnel architecture - MPLS, ATM, L2TP, IP/IP6, GRE6, etc, and perhaps a couple of such strung together end to end - and is therefore probably not exactly DSTM. But DSTM would be a useful input. I don't think we should be deploying IPv6-only networks in any form until we have figured out the end to end problem. From 1fu-hua@acadia.net Tue Aug 09 21:16:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2fCU-00017h-Kv for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 21:16:10 -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 VAA27823 for ; Tue, 9 Aug 2005 21:16:06 -0400 (EDT) Received: from 200216097005.user.veloxzone.com.br ([200.216.97.5]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E2fkQ-0004mq-Fa for v6ops-archive@ietf.org; Tue, 09 Aug 2005 21:51:18 -0400 Message-ID: <62d901c59d46$4204cfd7$01faee43@acadia.net> From: "Vanessa J. Smith" <1fu-hua@acadia.net> To: v6ops-archive@ietf.org Subject: =?iso-8859-1?B?QWRvYmUgQWNyb2JhdCA2LjAgLSB2ZXJ5IGxvdyBwcmljZQ==?= Date: Wed, 10 Aug 2005 00:57:14 +0000 MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----=_NextPart_000_0000_6E828F1F.0433AB31" 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.1 (++++) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 This is a multi-part message in MIME format. ------=_NextPart_000_0000_6E828F1F.0433AB31 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0001_6F5FC17E.63063581" ------=_NextPart_001_0001_6F5FC17E.63063581 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Get access to all the software possible for prices substantially lower than in stores! Our software is 2-10 times cheaper than sold by our competitors. 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) $179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX) $79.95 Adobe Acrobat 6.0 Professional $59.95 Corel Draw Graphics Suite 11 Special Offers: $89.95 Windows XP Professional + Office XP Professional $149.95 Adobe Creative Suite Premium (5 CD) $129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10 All main products from Microsoft, Adobe, Macromedia, Corel, etc. And many more... Please visit us at: http://www.soft-on-disks.com Regards, Vanessa Smith _____________________________________________________ To be taken off future campaigns, go here _____________________________________________________ ------=_NextPart_001_0001_6F5FC17E.63063581 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 7bit
Get access to all the software possible for prices substantially lower than in stores!
Our software is 2-10 times cheaper than sold by our competitors.

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)
$179.95 Macromedia Studio MX 2004 (Including: Dreamweaver MX + Flash MX + Fireworks MX)
$79.95 Adobe Acrobat 6.0 Professional
$59.95 Corel Draw Graphics Suite 11

Special Offers:
$89.95 Windows XP Professional + Office XP Professional
$149.95 Adobe Creative Suite Premium (5 CD)
$129.95 Adobe Photoshop 7 + Adobe Premiere 7 + Adobe Illustrator 10

All main products from Microsoft, Adobe, Macromedia, Corel, etc.
And many more... Please visit us at:

http://www.soft-on-disks.com

Regards,
Vanessa Smith


_____________________________________________________
To be taken off future campaigns, go here
_____________________________________________________

------=_NextPart_001_0001_6F5FC17E.63063581-- ------=_NextPart_000_0000_6E828F1F.0433AB31-- From owner-v6ops@ops.ietf.org Tue Aug 09 22:53:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2giK-00045f-Lg for v6ops-archive@megatron.ietf.org; Tue, 09 Aug 2005 22:53:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01072 for ; Tue, 9 Aug 2005 22:53:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2gdv-000Mz8-Du for v6ops-data@psg.com; Wed, 10 Aug 2005 02:48:35 +0000 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E2gdq-000Myi-SC for v6ops@ops.ietf.org; Wed, 10 Aug 2005 02:48:31 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id E33EF20000AD; Tue, 9 Aug 2005 22:48:24 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 9 Aug 2005 22:48:24 -0400 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: Enterprise Analysis DSTM Issue Date: Tue, 9 Aug 2005 22:48:22 -0400 Message-ID: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> Thread-Topic: Enterprise Analysis DSTM Issue Thread-Index: AcWdJABddMGwwTYuRtiTjPaxp9FEJwAMGN1Q From: "Bound, Jim" To: "Fred Baker" Cc: X-OriginalArrivalTime: 10 Aug 2005 02:48:24.0777 (UTC) FILETIME=[FA57DB90:01C59D55] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable The DSTM authors will get back to the WG and you on our decision regarding DSTM in a few weeks. We have and will continue to take WG input and incorporate consensus and clearly abide by requirements in the IETF to assure our IETF rules of engagement are followed strictly. In addition I will respond to Pekka's excellent technical discussion points as always for some time now.=20 Regarding your lack of apology that is fine below, I will take that as a no and note it to my self. No reason to further discuss. Regarding your individual input, opinion, and analysis it is read. Regarding your view on IPv6 dominant deployment we can just agree to disagree as two people. I see no point of rehashing again. Ipv6 dominant networks are a requirement and the WG consenus is that it will in fact be a reality, as I hear consensus. Regarding DSTM it does assume a dual stack on all nodes and states that clearly in the spec and supports IPv6 - in - IPv6 tunneling RFC should be used. It is only the IPv4 routing within the DSTM domain that will not be used and this was an idea supported by the market and that is input at least to those of us that will drive and assist the market to use DSTM as an IPv6 Transiton mechanism. To state DSTM does not support a dual-stack method is not valid based on the DSTM spec. /jim > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, August 09, 2005 4:50 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: Enterprise Analysis DSTM Issue >=20 > let's clarify on the conversation. >=20 > a) Pekka said that the term "Dual-Stck" was heavily overloaded, and =20 > it didn't seem wise for the working group to recommend=20 > something that =20 > was so unclear. >=20 > b) You said that you had no intention of removing DSTM (your =20 > experimental work) from the draft regardless of working group =20 > (Pekka's) input, because you had customers interested in running DSTM. >=20 > c) I said that a working group draft needs to reflect working group =20 > input, and that if this could not be accomplished then maybe the =20 > document should not be a working group document. That is not a =20 > position I plan to apologize for; it is also related to the reason =20 > that v6ops doesn't work on transition strategies - the various =20 > transition discussions in v6ops did not lead to convergence on a =20 > single or small number of recommended strategies. >=20 > d) You now have your back up. >=20 > Pekka's comments originate from the dual use of the term "dual =20 > stack". The IETF has a long-standing recommendation that a network =20 > should run both IPv4 and IPv6 (network layer forwarding,=20 > routing, and =20 > so on) natively, allowing end systems to use either protocol=20 > with the =20 > expectations one would have of any native deployment. This is =20 > described as "dual stack" in RFC 1933 and its successor 2893, in =20 > several RFCs describing potential transition mechanisms (2765, 2766, =20 > and 2767 come quickly to mind). The term "dual stack" is also=20 > used by =20 > DSTM. But DSTM doesn't actually run two stacks in the network. It =20 > runs an IPv6-only network (at least as far as its customers are =20 > concerned) and provides a way for IPv4 systems to rendezvous over it =20 > and tunnel through it, allowing end systems to run dual stacks. In =20 > your words: >=20 > DSTM [DSTM, DSTM+] is a useful tunneling mechanism for=20 > later in =20 > the > enterprise transition or deployment of IPv6-dominant=20 > network links > is desired. DSTM is to being submitted as an IETF Experimental =20 > RFC. >=20 > Pekka's observation is that while this is mostly transparent to the =20 > end system, it is hardly transparent in the network and (being =20 > experimental) is not something the IETF is at this time=20 > recommending. =20 > This reflects my comment to you of perhaps two months ago. I'm all =20 > for your draft discussing dual stack mechanisms - mechanisms=20 > that use =20 > two stacks, consistent with RFC 2893. But recommending DSTM in a =20 > working group recommendation is not consistent with its experimental =20 > status. RFC 2026 says, in section 4.2.1: >=20 > The "Experimental" designation typically denotes a specification =20 > that > is part of some research or development effort. Such a =20 > specification > is published for the general information of the Internet technical > community and as an archival record of the work, subject only to > editorial considerations and to verification that there has been > adequate coordination with the standards process (see below). An > Experimental specification may be the output of an organized =20 > Internet > research effort (e.g., a Research Group of the IRTF), an IETF =20 > Working > Group, or it may be an individual contribution. >=20 > and in section 3.3: >=20 > (d) Limited Use: The TS is considered to be appropriate for use > only in limited or unique circumstances. For example, the =20 > usage > of a protocol with the "Experimental" designation should =20 > generally > be limited to those actively involved with the experiment. >=20 > In other words, an experimental protocol or procedure may be a =20 > perfectly good protocol or procedure and may be a candidate for =20 > future standardization. It may have customers using it. However, its =20 > general utility has not been shown at the point in time that it has =20 > been given that status, and the protocol or procedure is not =20 > recommended for general deployment until the experiment has been run. >=20 > So, I have two expectations of a working group document: that it =20 > reflect the opinions of the working group, and that it reflect the =20 > recommendations of the IETF. As you and I discussed in July, the =20 > statement >=20 > Later in the transition process, after the enterprise has > transitioned to a predominately IPv6 infrastructure,=20 > the architect > should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. >=20 > fails the latter point, and from the sound of Pekka's comment, fails =20 > the former point as well. >=20 > I appreciate that you are accepting a number of Pekka's other =20 > comments. I'd like you to consider carefully his comment=20 > regarding DSTM. >=20 > On Aug 9, 2005, at 1:02 PM, Bound, Jim wrote: >=20 > > WG Members, > > > > For DSTM we are going to discuss as authors what we want to=20 > do here =20 > > per > > Fred's mail telling us we could go away if we leave it in=20 > the spec, at > > least my read of his mail. This will take us a few weeks as some =20 > > are on > > summer vacation. > > > > For your information if your new. DSTM had a minimum of two years =20 > > IETF > > NGTRANS working group discussion, and had discussion before=20 > that as =20 > > the > > AIIH proposal. In fact the authors reduced and altered the DSTM > > protocol several times per the NGTRANS Chairs input over=20 > the years and > > the WG. > > > > There will be a series of DSTM specifications sent for=20 > Experimental =20 > > RFC > > in the next 6 months. At the same time there will be a new industry > > focus on DSTM, that will be quite rigorous, and produce a set of > > deployment guidelines including DSTM for the IPv6 Transition. > > > > I realize DSTM is not an Experimental RFC now, but that was=20 > because we > > were not sure best path to move the work until about 3=20 > weeks ago. But > > ISATAP is still awaiting Experimental RFC, was only discussed in =20 > > NGTRANS > > too, not v6ops, and we still need a Tunnel Set Up Protocol. Yet =20 > > both of > > these are fine to reference in the spec? If true, is that "fair". > > > > DSTM is a mechanism that is part of the plan for several =20 > > enterprises, it > > is a valid reference. > > > > No need to respond or support this mail that is not its purpose. =20 > > But I > > want you the WG members to understand our decision or my=20 > "individual" > > decision when it is made in the next few weeks. > > > > Also it would have been nice if this could have been=20 > brought up when I > > asked are there other issues in person at the Paris IETF last =20 > > week. We > > could have all met that care in person then at that IETF event. > > > > /jim > > >=20 From owner-v6ops@ops.ietf.org Wed Aug 10 03:16:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2kos-0006JM-AO for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 03:16:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08924 for ; Wed, 10 Aug 2005 03:16:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2km2-000Mau-3I for v6ops-data@psg.com; Wed, 10 Aug 2005 07:13:14 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2km0-000MZy-Dy for v6ops@ops.ietf.org; Wed, 10 Aug 2005 07:13:12 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2005 00:13:12 -0700 X-IronPort-AV: i="3.96,94,1122879600"; d="scan'208"; a="330707150:sNHT34557268" 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 j7A7D4QM019638; Wed, 10 Aug 2005 00:13:04 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7A7A6Xs029569; Wed, 10 Aug 2005 00:10:07 -0700 In-Reply-To: <6.2.3.4.2.20050809231210.077743c8@mail.amaranth.net> References: <6.2.3.4.2.20050809231210.077743c8@mail.amaranth.net> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1A366AA8-2123-4869-AE0A-5F701B40D194@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: draft-ietf-v6ops-nap-01.txt Date: Wed, 10 Aug 2005 00:13:06 -0700 To: Daniel Senie X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=770; t=1123657807; x=1124090007; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20draft-ietf-v6ops-nap-01.txt| From:Fred=20Baker=20| Date:Wed,=2010=20Aug=202005=2000=3A13=3A06=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=qyWgTFGE+EZZzUP4HJUZ4o+nba28lc+61po4EG6jAoKS5ixHzr0ovPx+MWVfw7YGzMpfLTZZ ToNcg1+kgX/pgB7hDk/QDwn6uinYXAyILtXupsSOSx7oBahjkakQdKiqikAD4SLfDR8lyIl+N7z togrGJ9eSXADlzWvLhFiM2Dw= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 9, 2005, at 9:36 PM, Daniel Senie wrote: > Section 2.6: Please provide citations and statistics for the use of > NAT and RFC1918 in the delivery of ISP services. Though this is > talked about throughout this document, the practice is rare in at > least some regions. Hard data would lend credence to this claim. > Since this claim is used to justify many things in this document, > the lack of citations gives the appearance of a strawman construct. While I don't have specific statistics, as this would require access ot a lot of networks and the NDAs that accompany such, I do know that the practice is common in Africa and parts of Asia. At one time, China Unicom (which last year delivered over a billion voice minutes using VoIP over an IP/ATM fiber backbone) used three layers of NATs, citing inability to obtain IPv4 addresses as the primary reason. They have since directly joined APNIC, I'm told, and may no longer do that. From owner-v6ops@ops.ietf.org Wed Aug 10 04:36:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2m4v-0001Jd-Rz for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 04:36: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 EAA12462 for ; Wed, 10 Aug 2005 04:36:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2m2s-0004sf-L3 for v6ops-data@psg.com; Wed, 10 Aug 2005 08:34:42 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E2m2q-0004sP-HB for v6ops@ops.ietf.org; Wed, 10 Aug 2005 08:34:40 +0000 Received: (qmail 10477 invoked by uid 417); 10 Aug 2005 08:34:39 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 10 Aug 2005 08:34:39 -0000 Received: from mehr ([132.70.221.139]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Wed, 10 Aug 2005 02:34:38 -0600 Message-ID: <006201c59d86$57350c40$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <6.2.3.4.2.20050809231210.077743c8@mail.amaranth.net> <1A366AA8-2123-4869-AE0A-5F701B40D194@cisco.com> Subject: Re: draft-ietf-v6ops-nap-01.txt Date: Wed, 10 Aug 2005 11:34:16 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred Baker Wrote: > > On Aug 9, 2005, at 9:36 PM, Daniel Senie wrote: > > > Section 2.6: Please provide citations and statistics for the use of > > NAT and RFC1918 in the delivery of ISP services. Though this is > > talked about throughout this document, the practice is rare in at > > least some regions. Hard data would lend credence to this claim. > > Since this claim is used to justify many things in this document, > > the lack of citations gives the appearance of a strawman construct. > > While I don't have specific statistics, as this would require access > ot a lot of networks and the NDAs that accompany such, I do know that > the practice is common in Africa and parts of Asia. At one time, > China Unicom (which last year delivered over a billion voice minutes > using VoIP over an IP/ATM fiber backbone) used three layers of NATs, > citing inability to obtain IPv4 addresses as the primary reason. They > have since directly joined APNIC, I'm told, and may no longer do that. > I am not sure about all regions / nations, but I do know that in the following countries (names withheld due to NDA) there are several companies that are using NAT to separate internal private networks infrastructure and management from the Publicly aces: In the United States there are at least 4 fixed line phone companies, 2 long distance, and 1 Utility company In the UK there are at least 2 cellular and 2 fixed companies In Israel there are at least 3 long distance, 2 cellular and the national carrier In the Netherlands there is one carrier Eric From owner-v6ops@ops.ietf.org Wed Aug 10 06:24:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2nlZ-0006qE-KM for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:24: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 GAA18405 for ; Wed, 10 Aug 2005 06:24:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2nj0-000Gi3-AD for v6ops-data@psg.com; Wed, 10 Aug 2005 10:22:18 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2niy-000Ghl-BS for v6ops@ops.ietf.org; Wed, 10 Aug 2005 10:22:16 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7AAL8qC025453; Wed, 10 Aug 2005 11:21:08 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA05928; Wed, 10 Aug 2005 11:20:24 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7AAKNA14828; Wed, 10 Aug 2005 11:20:23 +0100 Date: Wed, 10 Aug 2005 11:20:23 +0100 From: Tim Chown To: v6ops@ops.ietf.org Cc: townsley@cisco.com Subject: lrw (tunnelling) BoF at Paris Message-ID: <20050810102023.GB14462@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org, townsley@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, It's quite possible that many on this list did not find out about the lrw BoF in Paris: Lightweight Reachability softWires BOF (lrw) CHAIRS: David Ward Alain Durand DESCRIPTION: The LRW (Lightweight Reachability softWires) BOF is to discuss the problem space of: discovery, control and encapsulation methods for connecting IPv4 networks across IPv6 networks and IPv6 networks across IPv4 networks. Due to the fact that some networks are mandated that certain network functions must be IPv4 or IPv6 (e.g. due to financial or political reasons); dynamic tunnels or 'softwires' are suited for the inter-networking job. The goal of the BOF is to form the LRW WG that will work on these issues I don't think it was advertised in v6ops or ipv6 WG lists, so it may be useful to have some discussion about it here. It isn't dissimilar from v6tc, but I understand this time that the WG will be formed, under the Internet Area, and thus able to do protocol work. Maybe Alain or David can tell us more? Is there a link to a Charter page? With recent DSTM discussion, it should be noted that IPv4-in-IPv6 tunnelling solutions are very much in scope for this proposed WG. -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Aug 10 06:47:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2o6s-0004mN-TX for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 06:47: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 GAA19325 for ; Wed, 10 Aug 2005 06:46:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2o5f-000JDi-4x for v6ops-data@psg.com; Wed, 10 Aug 2005 10:45:43 +0000 Received: from [131.228.20.96] (helo=mgw-ext04.nokia.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.50 (FreeBSD)) id 1E2o5c-000JDH-49 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 10:45:40 +0000 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j7AAhSgn022521; Wed, 10 Aug 2005 13:44:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 13:43:52 +0300 Received: from esebe100.NOE.Nokia.com ([172.21.138.118]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 Aug 2005 13:43:51 +0300 Received: from 172.21.23.64 ([172.21.23.64]) by esebe100.NOE.Nokia.com ([172.21.138.118]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Aug 2005 10:43:49 +0000 Received: from hi30-dhcp-02364.ntc.nokia.com by ESEBE100.noe.nokia.com; 10 Aug 2005 13:43:50 +0300 Subject: Re: lrw (tunnelling) BoF at Paris From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Tim Chown Cc: v6ops@ops.ietf.org, townsley@cisco.com In-Reply-To: <20050810102023.GB14462@login.ecs.soton.ac.uk> References: <20050810102023.GB14462@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1123670630.4092.18.camel@hi30-dhcp-02364.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 10 Aug 2005 13:43:50 +0300 X-OriginalArrivalTime: 10 Aug 2005 10:43:51.0557 (UTC) FILETIME=[65A10B50:01C59D98] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, could somebody still do the favor of forwarding the mailing list info if there is one. Cheers, Jonne. On Wed, 2005-08-10 at 13:20, ext Tim Chown wrote: > Hi, > > It's quite possible that many on this list did not find out about the > lrw BoF in Paris: > > Lightweight Reachability softWires BOF (lrw) > > CHAIRS: David Ward > Alain Durand > > DESCRIPTION: > > The LRW (Lightweight Reachability softWires) BOF is to discuss the problem > space of: discovery, control and encapsulation methods for connecting IPv4 > networks across IPv6 networks and IPv6 networks across IPv4 networks. Due > to the fact that some networks are mandated that certain network functions > must be IPv4 or IPv6 (e.g. due to financial or political reasons); dynamic > tunnels or 'softwires' are suited for the inter-networking job. The goal > of the BOF is to form the LRW WG that will work on these issues > > > I don't think it was advertised in v6ops or ipv6 WG lists, so it may be > useful to have some discussion about it here. > > It isn't dissimilar from v6tc, but I understand this time that the WG will > be formed, under the Internet Area, and thus able to do protocol work. > > Maybe Alain or David can tell us more? Is there a link to a Charter page? > > With recent DSTM discussion, it should be noted that IPv4-in-IPv6 tunnelling > solutions are very much in scope for this proposed WG. -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Aug 10 07:32:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ooo-00005Q-Qp for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 07:32:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20990 for ; Wed, 10 Aug 2005 07:32:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2onE-000OYy-Nx for v6ops-data@psg.com; Wed, 10 Aug 2005 11:30:44 +0000 Received: from [64.233.184.207] (helo=wproxy.gmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2onB-000OYg-Aw for v6ops@ops.ietf.org; Wed, 10 Aug 2005 11:30:41 +0000 Received: by wproxy.gmail.com with SMTP id i20so115263wra for ; Wed, 10 Aug 2005 04:30:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LCS2N+bo15R05WcUqjAx4Z7dexHv6nstdVn6+9b39fGeOhepzW0W6wWz1TfgSB6KFHf0rMHJAAceSnRD1ZnaDPSHC6Uq424vH0KnYZvHLgi+Tkp6f8w1LvfKUgl3JdL3/WxN9MrmJyvQv2woJzFvq/j9o/B2tG3BY6LsQKDQyXU= Received: by 10.54.30.40 with SMTP id d40mr402573wrd; Wed, 10 Aug 2005 04:30:39 -0700 (PDT) Received: by 10.54.92.13 with HTTP; Wed, 10 Aug 2005 04:30:39 -0700 (PDT) Message-ID: <9a8fa98b05081004306a0ea824@mail.gmail.com> Date: Wed, 10 Aug 2005 12:30:39 +0100 From: Rob Evans To: v6ops@ops.ietf.org Subject: Re: lrw (tunnelling) BoF at Paris In-Reply-To: <20050810102023.GB14462@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050810102023.GB14462@login.ecs.soton.ac.uk> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_BY_IP autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > Maybe Alain or David can tell us more? Is there a link to a Charter pag= e? I noted this down during the meeting. I don't know if it is still current following the discussion that was had: http://bgp.nu/~dward/softwires/Softwires_charter.htm The mailing list was going to be @ietf.org, but I don't see it listed (either as softwires or lrw) on: https://www1.ietf.org/mailman/listinfo/ Cheers, Rob From owner-v6ops@ops.ietf.org Wed Aug 10 08:28:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2pgd-0006lW-Oq for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 08:28: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 IAA23796 for ; Wed, 10 Aug 2005 08:27:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2pfc-0005Bi-QC for v6ops-data@psg.com; Wed, 10 Aug 2005 12:26:56 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2pfX-0005B3-Px for v6ops@ops.ietf.org; Wed, 10 Aug 2005 12:26:51 +0000 Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IL000MM8AKQNP@mailout2.samsung.com> for v6ops@ops.ietf.org; Wed, 10 Aug 2005 21:26:50 +0900 (KST) Received: from srkrishnan ([107.108.71.58]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0IL000ID3AKOSE@mmp1.samsung.com> for v6ops@ops.ietf.org; Wed, 10 Aug 2005 21:26:50 +0900 (KST) Date: Wed, 10 Aug 2005 17:52:29 +0530 From: "Radhakrishnan.S" Subject: Re: lrw (tunnelling) BoF at Paris To: Rob Evans Cc: V6OPS WG Reply-to: "Radhakrishnan.S" Message-id: <096701c59da6$2e9006d0$3a476c6b@sisodomain.com> Organization: Samsung India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20050810102023.GB14462@login.ecs.soton.ac.uk> <9a8fa98b05081004306a0ea824@mail.gmail.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT @ietf.org is still not active!!!! ----- Original Message ----- From: "Rob Evans" To: Sent: Wednesday, August 10, 2005 5:00 PM Subject: Re: lrw (tunnelling) BoF at Paris > Maybe Alain or David can tell us more? Is there a link to a Charter > page? I noted this down during the meeting. I don't know if it is still current following the discussion that was had: http://bgp.nu/~dward/softwires/Softwires_charter.htm The mailing list was going to be @ietf.org, but I don't see it listed (either as softwires or lrw) on: https://www1.ietf.org/mailman/listinfo/ Cheers, Rob From owner-v6ops@ops.ietf.org Wed Aug 10 09:03:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qF6-0007xd-Pa for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 09:03: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 JAA25728 for ; Wed, 10 Aug 2005 09:03:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2qDg-0009M2-QE for v6ops-data@psg.com; Wed, 10 Aug 2005 13:02:08 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2qDe-0009Lb-W4 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 13:02:07 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7AD25qA001657 for ; Wed, 10 Aug 2005 14:02:05 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA25571 for ; Wed, 10 Aug 2005 14:01:30 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7AD1UN21241 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 14:01:30 +0100 Date: Wed, 10 Aug 2005 14:01:30 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050810130130.GL14462@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 09, 2005 at 10:48:22PM -0400, Bound, Jim wrote: > Regarding DSTM it does assume a dual stack on all nodes and states that > clearly in the spec and supports IPv6 - in - IPv6 tunneling RFC should > be used. It is only the IPv4 routing within the DSTM domain that will > not be used and this was an idea supported by the market and that is > input at least to those of us that will drive and assist the market to > use DSTM as an IPv6 Transiton mechanism. To state DSTM does not support > a dual-stack method is not valid based on the DSTM spec. One option may be to title it 'Dual Stack (Host) Transition Mechanism' to distinguish it from 'conventional' dual stack where dual stack on the wire is used (and nodes may be v4 only, v6 only or both). I think enough people know what DSTM is as to not change the acronym. Tim From owner-v6ops@ops.ietf.org Wed Aug 10 09:13:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qOr-0001tt-4n for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 09:13: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 JAA26393 for ; Wed, 10 Aug 2005 09:13:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2qOS-000Ayz-6y for v6ops-data@psg.com; Wed, 10 Aug 2005 13:13:16 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2qOR-000Ayb-8U for v6ops@ops.ietf.org; Wed, 10 Aug 2005 13:13:15 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7ADDEqA002178 for ; Wed, 10 Aug 2005 14:13:14 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA26594 for ; Wed, 10 Aug 2005 14:12:43 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7ADCh021895 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 14:12:43 +0100 Date: Wed, 10 Aug 2005 14:12:43 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050810131243.GN14462@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 09, 2005 at 02:55:55PM -0700, Fred Baker wrote: > > Oh, by the way, as IPv4 address space allocation in fact approaches > impossibility, the deployment of IPv6-only infrastructure is not only > predictable, it is unavoidable. At this point, it is very avoidable, > and I have a hard time arguing that the complications resulting from > it are preferable to the complications of running a dual stack network. I think for the majority of cases/networks that's true. But I have spoken to people recently who believe (conventional) dual-stack adds to security complexity, and they'd like to run one protocol only. RFC4057 (section 3.1) defines the IPv6-only infrastructure scenario as one of the three base secenarios: Scenario 3: IPv6-only network infrastructure with some IPv4-capable nodes/applications needing to communicate over the IPv6 infrastructure. Enterprise deploying a new network or restructuring an existing network, decides IPv6 is the basis for most network communication. Some IPv4 capable nodes/applications will need to communicate over that infrastructure. so it seems to be appropriate to cover the potential solutions in the analysis document. I know Pekka was reluctant to include that scenario while he was co-chair, but consensus was there and it was included. My view is that something 'DSTM-like' will be needed for Scenario 3, but (for whatever reason) we have nothing on standards track that solves that case yet. The analysis wording should describe the nature of the solution, and could cite DSTM as one example. > I'm all for lrw, v6tc, or whatever it winds up being called. I was > last time around as well. AFAIK, v6tc is *also* not chartered to > solve the entire complexity of the end to end problem - it is > chartered to come up with a rendezvous protocol for a tunneling > solution, and presumably not a dozen mutually incompatible ones. Agreed, it was supposed to find one solution. > From what Mark Townsley and Dave Ward told me, something like DSTM might > be part of that, but it has to manage an arbitrary underlying tunnel > architecture - MPLS, ATM, L2TP, IP/IP6, GRE6, etc, and perhaps a > couple of such strung together end to end - and is therefore probably > not exactly DSTM. But DSTM would be a useful input. I agree. > I don't think we should be deploying IPv6-only networks in any form until > we have figured out the end to end problem. If there are overall connectivity concerns with the model, these should be discussed of course. Maybe a short text/draft describing the problem would be useful input? :) Brief text and a couple of example concerns? -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Aug 10 09:24:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qZ2-0004bA-Bw for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 09:24: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 JAA26960 for ; Wed, 10 Aug 2005 09:24:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2qYM-000CGl-1m for v6ops-data@psg.com; Wed, 10 Aug 2005 13:23:30 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2qYJ-000CFM-RX for v6ops@ops.ietf.org; Wed, 10 Aug 2005 13:23:28 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7ADNQTb005716 for ; Wed, 10 Aug 2005 15:23:26 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7ADNQPv002297 for ; Wed, 10 Aug 2005 15:23:26 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7ADNQEm002296 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 15:23:26 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 10 Aug 2005 15:23:26 +0200 From: Stig Venaas To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050810132326.GA2265@storhaugen.uninett.no> References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050810130130.GL14462@login.ecs.soton.ac.uk> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 10, 2005 at 02:01:30PM +0100, Tim Chown wrote: > On Tue, Aug 09, 2005 at 10:48:22PM -0400, Bound, Jim wrote: > > > Regarding DSTM it does assume a dual stack on all nodes and states that > > clearly in the spec and supports IPv6 - in - IPv6 tunneling RFC should > > be used. It is only the IPv4 routing within the DSTM domain that will > > not be used and this was an idea supported by the market and that is > > input at least to those of us that will drive and assist the market to > > use DSTM as an IPv6 Transiton mechanism. To state DSTM does not support > > a dual-stack method is not valid based on the DSTM spec. > > One option may be to title it 'Dual Stack (Host) Transition Mechanism' to > distinguish it from 'conventional' dual stack where dual stack on the > wire is used (and nodes may be v4 only, v6 only or both). Yes that might be an idea. Not to be difficult, but a router and, thus a network of routers, can easily forward IPv6 without having a TCP/IP stack, so strictly speaking we're misusing the term dual-stack a little bit when we talk of dual-stack networks too (: Anyway, it's how people use it that is important, and it's become common to talk of dual-stack networks. > I think enough people know what DSTM is as to not change the acronym. Right, might be confusing to change the name again (or go back to the AIIH name...). I don't care that much about the name though. There are some people deploying IPv6-only networks today, and I'm sure there will be more in the future. So I do see the need for IPv4 over IPv6 tunneling. Stig > > Tim From owner-v6ops@ops.ietf.org Wed Aug 10 09:35:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2qkB-00077y-Hc for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 09:35: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 JAA27717 for ; Wed, 10 Aug 2005 09:35:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2qjV-000DaD-Nt for v6ops-data@psg.com; Wed, 10 Aug 2005 13:35:01 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2qjS-000DZW-Oy for v6ops@ops.ietf.org; Wed, 10 Aug 2005 13:34:59 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7ADYs206913; Wed, 10 Aug 2005 16:34:54 +0300 Date: Wed, 10 Aug 2005 16:34:54 +0300 (EEST) From: Pekka Savola To: Stig Venaas cc: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue In-Reply-To: <20050810132326.GA2265@storhaugen.uninett.no> Message-ID: References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 10 Aug 2005, Stig Venaas wrote: > Right, might be confusing to change the name again (or go back to the > AIIH name...). I don't care that much about the name though. There are > some people deploying IPv6-only networks today, and I'm sure there will > be more in the future. So I do see the need for IPv4 over IPv6 tunneling. Yeah, but your last sentence was exactly my point. You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6 tunneling". If that's what we wanted, we could just say we need v4-over-v6 and be done. As I said in my earliest mail, I think we now should get the people actually doing DSTM deployments or otherwise interested in it to state 1) what they believe it does, and 2) what are their requirements for a solution in more generic terms? Below is cut'n'pasted from my earlier mail: As it is, different people use "DSTM" to mean at least the following things: a) v4-in-v6 tunnels b) automatically set-up v4-in-v6 tunnels c) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket d) automatic monitoring and tear-down of said v4-over-v6 tunnel when the host detects it no longer needs the address/connectivity e) plus a number of extensions for even more colorful setups. We need to separate "use of v4-in-v6 tunnels as a concept" from "DSTM the protocol". Fleshing it out or removing it seem the only choices. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 10 10:07:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2rES-0000u2-Hz for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 10:07: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 KAA29947 for ; Wed, 10 Aug 2005 10:06:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2rD5-000HhZ-1l for v6ops-data@psg.com; Wed, 10 Aug 2005 14:05:35 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2rD3-000Hh9-TC for v6ops@ops.ietf.org; Wed, 10 Aug 2005 14:05:34 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7AE5VqG004808 for ; Wed, 10 Aug 2005 15:05:32 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id OAA04948 for ; Wed, 10 Aug 2005 14:59:58 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7ADxvD24397 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 14:59:57 +0100 Date: Wed, 10 Aug 2005 14:59:57 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050810135957.GR14462@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 10, 2005 at 04:34:54PM +0300, Pekka Savola wrote: > On Wed, 10 Aug 2005, Stig Venaas wrote: > >Right, might be confusing to change the name again (or go back to the > >AIIH name...). I don't care that much about the name though. There are > >some people deploying IPv6-only networks today, and I'm sure there will > >be more in the future. So I do see the need for IPv4 over IPv6 tunneling. > > Yeah, but your last sentence was exactly my point. > > You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6 > tunneling". > > If that's what we wanted, we could just say we need v4-over-v6 and be > done. But you could say the same for other protocols mentioned. My view is that the style of DSTM commentary in 8.4 is good, but 8.1 is too strong. We should keep DSTM cited as a 'useful tool for IPv6 dominant infrastructures'. We can state in the analysis that we need a protocol for that scenario (#3 of RFC4057) that supports: a) v4-in-v6 tunnels b) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket c) authentication for tunnel setup And maybe: > d) automatic monitoring and tear-down of said v4-over-v6 tunnel > when the host detects it no longer needs the address/connectivity > e) plus a number of extensions for even more colorful setups. but these are too specific for the analysis text. Look at RFC3904. That cited Teredo as 'work in progress'. I see no reason why we can't state what generic problem DSTM is solving (assuming we can agree that!) and cite DSTM as an example, and 'work in progress'. We could even add a recommendation, as per section 7 of RFC3904, saying we should develop DSTM or something 'DSTM-like'. Scenario 3 of Section 3.1 of RFC4057 means we need text for this case. I could also point out Section 6.2 of RFC3094: 6.2. IPv4 Connectivity Requirements Local IPv4 capable hosts may still want to access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and the IETF has devoted very little effort to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers. I think this still applies. If anything, it adds to the case for the IETF to get active in this issue, via lrw WG or whereever. So we have unman and ent cases anting some solution in this space. -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Aug 10 11:34:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2sah-0003gb-B2 for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 11:34: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 LAA06415 for ; Wed, 10 Aug 2005 11:33:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2sYc-00027F-6D for v6ops-data@psg.com; Wed, 10 Aug 2005 15:31:54 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2sYb-00026t-3B for v6ops@ops.ietf.org; Wed, 10 Aug 2005 15:31:53 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7AFVjj09577; Wed, 10 Aug 2005 18:31:48 +0300 Date: Wed, 10 Aug 2005 18:31:45 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue In-Reply-To: <20050810135957.GR14462@login.ecs.soton.ac.uk> Message-ID: References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <20050810135957.GR14462@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk First note: you may have an assumption that I have something against v4-in-v6 tunnels in general. Even though I don't see the management simplicity considerations myself, I don't object to having a simple solution. So, a v4-in-v6 solution is "just OK". But this is already provided under "tunnel broker" section. I don't see the _other_ requirements for the additional DSTM features at least yet. On Wed, 10 Aug 2005, Tim Chown wrote: > We can state in the analysis that we need > a protocol for that scenario (#3 of RFC4057) that supports: > > a) v4-in-v6 tunnels > b) automatic set up of v4-in-v6 tunnels when the host > doesn't have v4 address and an app wants to create a v4 socket > c) authentication for tunnel setup OK, this is good. Let's try to separate b) into three: b1) automatic set up of v4-in-v6 tunnels b2) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address b3) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket What are the requirements, exactly? > And maybe: > >> d) automatic monitoring and tear-down of said v4-over-v6 tunnel >> when the host detects it no longer needs the address/connectivity >> e) plus a number of extensions for even more colorful setups. > > but these are too specific for the analysis text. Maybe, maybe not -- but we need to figure out what's the thing that people are looking for. > Look at RFC3904. That cited Teredo as 'work in progress'. I see no reason > why we can't state what generic problem DSTM is solving (assuming we can agree > that!) and cite DSTM as an example, and 'work in progress'. We could > even add a recommendation, as per section 7 of RFC3904, saying we should > develop DSTM or something 'DSTM-like'. Yes, but Teredo has a very clear applicability and scenarios. [More or less automatic] IPv4-in-IPv6 tunneling also can also be argued for. That can be solved with a tunnel broker; DSTM specifies much more. So, the point here is, do we just need [automatic] v4-in-v6 tunnel set-up mechanism (provided by tunnel brokers), or something more (it isn't clear _what_, exactly). > I think this still applies. If anything, it adds to the case for the > IETF to get active in this issue, via lrw WG or whereever. So we have > unman and ent cases anting some solution in this space. Yes, there is no doubt v4-in-v6 tunneling is needed. A standards track solution already exists (RFC 2473). But if you need more, tunnel server/broker concept is widely used, and I believe that's what lrw is aiming to solve. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 10 12:01:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2t19-0003IS-Cz for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 12:01: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 MAA07847 for ; Wed, 10 Aug 2005 12:01:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2t0U-00068X-L2 for v6ops-data@psg.com; Wed, 10 Aug 2005 16:00:42 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2t0S-00067w-1E for v6ops@ops.ietf.org; Wed, 10 Aug 2005 16:00:40 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 10 Aug 2005 09:00:40 -0700 X-IronPort-AV: i="3.96,97,1122879600"; d="scan'208"; a="653994093:sNHT68640222" 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 j7AG0aoo001216; Wed, 10 Aug 2005 09:00:37 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7AFvXud000492; Wed, 10 Aug 2005 08:57:33 -0700 In-Reply-To: References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8737DE0B-A494-437F-8C66-F37FAB654D30@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Enterprise Analysis DSTM Issue Date: Wed, 10 Aug 2005 09:00:33 -0700 To: Pekka Savola X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=613; t=1123689453; x=1124121653; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Enterprise=20Analysis=20DSTM=20Issue| From:Fred=20Baker=20| Date:Wed,=2010=20Aug=202005=2009=3A00=3A33=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=arpQGxChkQvQX7OpYPqSpzzpcEzil0ldDW5V3T7XzyjcmAZMc/ZuIYxGm9vHBRfk8HwBY2Lr ffviOf9lSEow07nWdc6dnRO8MEvsSQpnmU6BdkJ9ab9Be58dky1ig+6dPyC2FStk+9YpJsOzxOF qLqTzR/kVImFtTO/9dBKex2o= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 10, 2005, at 6:34 AM, Pekka Savola wrote: > We need to separate "use of v4-in-v6 tunnels as a concept" from > "DSTM the protocol". Fleshing it out or removing it seem the only > choices. So what I hear you arguing for, which I think is consistent with Tim's comments, is that this section should say that we require a tunneling solution which might use a variety of tunnel approaches including virtual circuit networks including MPLS, IP/IP, IP/GRE, IPSEC Tunnel Mode, and so on, and that in addition a common rendezvous mechanism is required. DSTM is an example of a rendezvous mechanism, as are the DNS-ALG in NATPT, the mechanism in Silkroad, and so on, and v6tc-or-whatever is chartered to come up with that mechanism. Am I correct? From owner-v6ops@ops.ietf.org Wed Aug 10 12:05:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2t4f-0003a7-9B for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 12:05: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 MAA08191 for ; Wed, 10 Aug 2005 12:04:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2t4O-0006jp-NA for v6ops-data@psg.com; Wed, 10 Aug 2005 16:04:44 +0000 Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2t4N-0006jQ-I5 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 16:04:43 +0000 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j7AG4go24569 for ; Wed, 10 Aug 2005 12:04:42 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 7573EBF00 for ; Wed, 10 Aug 2005 12:04:42 -0400 (EDT) Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j7AG4eT24439; Wed, 10 Aug 2005 12:04:40 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 12:04:39 -0400 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: Enterprise Analysis DSTM Issue Date: Wed, 10 Aug 2005 12:04:36 -0400 Message-ID: <4E678B2D81B783489141F6B9E7ECBA273540B5@IMCSRV2.MITRE.ORG> Thread-Topic: Enterprise Analysis DSTM Issue Thread-Index: AcWdtjTd0dOfLHCvQy2ODt99IKlbagACRIsw From: "Klynsma,Steven L." To: "Tim Chown" , X-OriginalArrivalTime: 10 Aug 2005 16:04:39.0676 (UTC) FILETIME=[3666EBC0:01C59DC5] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I'd have to concur with Tim's analysis. Here, in the Army at least, we are convinced that it makes sense economically to transition to v6-dominant networks as soon as possible. Under DoD guidance (and frankly, OMB has just issued similar guidance to other US Govt agencies), we are to migrate to IPv6 (probably dual-stacked) by Sep 2008. However, there are several large wireless systems I'm aware of that are planning to implement Ipv6 only in their core with transition mechanisms at edges to ensure interop with v4 legacy. Combine that with DoD and OMB's strong push to go to dual-stacked backbone infrastructure by 2008, and I see the department being in a position to require DSTM (or DSTM-like) mechanisms (probably combined with scaleable tunnel brokers) to support v4 islands as soon as three years from now. =20 Having said that, I agree with Pekka that the term "dual-stack" is overused and increasingly ambiguous, but don't really have any position one-way or other on whether DSTM is properly named or not. Got no problem softening section 8.1 per Tim's suggestion. =20 vr, =20 Steve 703-983-6469 =20 "Lead your life so you won't be ashamed to sell the family parrot to the town gossip." Will Rogers, Jr. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown Sent: Wednesday, August 10, 2005 10:00 AM To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue On Wed, Aug 10, 2005 at 04:34:54PM +0300, Pekka Savola wrote: > On Wed, 10 Aug 2005, Stig Venaas wrote: > >Right, might be confusing to change the name again (or go back to the > >AIIH name...). I don't care that much about the name though. There are > >some people deploying IPv6-only networks today, and I'm sure there will > >be more in the future. So I do see the need for IPv4 over IPv6 tunneling. >=20 > Yeah, but your last sentence was exactly my point. >=20 > You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6=20 > tunneling". >=20 > If that's what we wanted, we could just say we need v4-over-v6 and be=20 > done. But you could say the same for other protocols mentioned. =20 My view is that the style of DSTM commentary in 8.4 is good, but 8.1 is too strong. We should keep DSTM cited as a 'useful tool for IPv6 dominant infrastructures'. We can state in the analysis that we need a protocol for that scenario (#3 of RFC4057) that supports: a) v4-in-v6 tunnels b) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket c) authentication for tunnel setup And maybe: > d) automatic monitoring and tear-down of said v4-over-v6 tunnel > when the host detects it no longer needs the address/connectivity > e) plus a number of extensions for even more colorful setups. but these are too specific for the analysis text. Look at RFC3904. That cited Teredo as 'work in progress'. I see no reason why we can't state what generic problem DSTM is solving (assuming we can agree that!) and cite DSTM as an example, and 'work in progress'. We could even add a recommendation, as per section 7 of RFC3904, saying we should develop DSTM or something 'DSTM-like'. =20 Scenario 3 of Section 3.1 of RFC4057 means we need text for this case. I could also point out Section 6.2 of RFC3094: 6.2. IPv4 Connectivity Requirements=20 Local IPv4 capable hosts may still want to access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and the IETF has devoted very little effort to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers. I think this still applies. If anything, it adds to the case for the IETF to get active in this issue, via lrw WG or whereever. So we have unman and ent cases anting some solution in this space. --=20 Tim/::1 From owner-v6ops@ops.ietf.org Wed Aug 10 13:20:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uFb-0001yF-53 for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:20: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 NAA12103 for ; Wed, 10 Aug 2005 13:20:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2uDk-000GKW-V0 for v6ops-data@psg.com; Wed, 10 Aug 2005 17:18:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2uDj-000GK8-Vv for v6ops@ops.ietf.org; Wed, 10 Aug 2005 17:18:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7AHIOb12050; Wed, 10 Aug 2005 20:18:24 +0300 Date: Wed, 10 Aug 2005 20:18:24 +0300 (EEST) From: Pekka Savola To: Fred Baker cc: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue In-Reply-To: <8737DE0B-A494-437F-8C66-F37FAB654D30@cisco.com> Message-ID: References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <8737DE0B-A494-437F-8C66-F37FAB654D30@cisco.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 10 Aug 2005, Fred Baker wrote: > On Aug 10, 2005, at 6:34 AM, Pekka Savola wrote: >> We need to separate "use of v4-in-v6 tunnels as a concept" from "DSTM the >> protocol". Fleshing it out or removing it seem the only choices. > > So what I hear you arguing for, which I think is consistent with Tim's > comments, is that this section should say that we require a tunneling > solution which might use a variety of tunnel approaches including virtual > circuit networks including MPLS, IP/IP, IP/GRE, IPSEC Tunnel Mode, and so on, > and that in addition a common rendezvous mechanism is required. DSTM is an > example of a rendezvous mechanism, as are the DNS-ALG in NATPT, the mechanism > in Silkroad, and so on, and v6tc-or-whatever is chartered to come up with > that mechanism. > > Am I correct? Yes, but I think this still misses the point. I don't have strong objections to v4-in-v6 tunneling (whatever the encapsulation), BUT the main point is that referring to DSTM as an example of either v4-in-v6 or v4-in-v6 rendezvous function is misleading. If we want to refer to a protocol or a rendezvous function for v4-in-v6 tunnels, we can just refer to RFC2473 and TSP (they're already referred to in the document)? The first describes the encapsulation ("configured v4-in-v6 tunneling"), the second also more of the rendezvous (+address assignment) function. Both are pretty straightforward protocol specifications, easy to implement interoperably if you need to, and the scope of the specs is well understood. Referring to DSTM is misleading because its specification seems like a mix between a paper describing a relatively straightforward v4-in-v6 concept (though this might or might not have been obvious 5 years ago) and a protocol specification. And: a) I have not seen a justification for a concept document (we should consider including the appropriate discussion in this doc, if the concept needs more discussion) b) The spec is not useful as a protocol specification; while it can probably be used to create an implementation, it doesn't seem sufficient to create interoperable implementations, and it's not clear what's actually required for the implementations and what's not. As rewriting an external spec (the area of which would be under discussion for softwires BOF/WG) is out of scope for this WG (though I might be willing to help off-list in the interest of clearing up the confusion).. My question is now: is there something missing in ent-analysis with regards to the description of the v4-in-v6 tunnel concept? If we could find appropriate description, maybe we wouldn't need the references to DSTM and all would be clearer to the reader. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 10 13:20:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2uFk-00020y-1l for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:20:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12111 for ; Wed, 10 Aug 2005 13:20:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2uF5-000GV9-M0 for v6ops-data@psg.com; Wed, 10 Aug 2005 17:19:51 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2uF0-000GUW-Je for v6ops@ops.ietf.org; Wed, 10 Aug 2005 17:19:47 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7AHJfTb026540; Wed, 10 Aug 2005 19:19:41 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7AHJfr7003357; Wed, 10 Aug 2005 19:19:41 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7AHJfn3003356; Wed, 10 Aug 2005 19:19:41 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 10 Aug 2005 19:19:41 +0200 From: Stig Venaas To: Pekka Savola Cc: Tim Chown , v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050810171941.GA3296@storhaugen.uninett.no> References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <20050810135957.GR14462@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, Aug 10, 2005 at 06:31:45PM +0300, Pekka Savola wrote: [...] > On Wed, 10 Aug 2005, Tim Chown wrote: > >We can state in the analysis that we need > >a protocol for that scenario (#3 of RFC4057) that supports: > > > > a) v4-in-v6 tunnels > > b) automatic set up of v4-in-v6 tunnels when the host > > doesn't have v4 address and an app wants to create a v4 socket > > c) authentication for tunnel setup > > OK, this is good. Let's try to separate b) into three: > > b1) automatic set up of v4-in-v6 tunnels > > b2) automatic set up of v4-in-v6 tunnels when the host > doesn't have v4 address > > b3) automatic set up of v4-in-v6 tunnels when the host > doesn't have v4 address and an app wants to create a v4 socket > > What are the requirements, exactly? If you have sufficient amount of IPv4 addresses you could probably use several mechanisms where you set up tunnels and assign addresses to every client in the network. As I understand it, DSTM is in particularly useful when you have hosts that rarely need IPv4 communications, you have enough IPv4 addresses to serve the hosts using IPv4 at any given time, but not for all the IPv4-capable hosts simultaneously. Hence the idea of being triggered by apps trying to use IPv4 (e.g. creation of v4 socket). I'm not sure b2 makes sense above. You could automatic setup v4-in-v6 tunnel when hosts boots provided you have enough IPv4 addresses. However, I think IPv6-only core only makes sense if IPv4 is rarely used. In that case it makes sense to have tunneling state only when needed. And as I said above, this may also make sense if you have lack of addresses. So the tunnel setup and the assignment of IPv4 address should only be done when needed. One way of detecting need, is request an IPv4 socket. I think several networks could manage with little IPv4 traffic already today. In particular if you have dual-stack mailservers, dual-stack web proxies etc. You would only need IPv4 to the internet when using more rare applications. There are also some networks today that struggle getting enough IPv4 addresses for the network infrastructure... Stig From owner-v6ops@ops.ietf.org Wed Aug 10 13:48:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2ugv-0000JE-Jh for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 13:48:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13479 for ; Wed, 10 Aug 2005 13:48:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2ugG-000LWK-Ko for v6ops-data@psg.com; Wed, 10 Aug 2005 17:47:56 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2ugE-000LVy-V3 for v6ops@ops.ietf.org; Wed, 10 Aug 2005 17:47:55 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 10 Aug 2005 10:47:55 -0700 X-IronPort-AV: i="3.96,97,1122879600"; d="scan'208"; a="330879922:sNHT28112670" 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 j7AHlqoo000063 for ; Wed, 10 Aug 2005 10:47:52 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7AHimWT001802 for ; Wed, 10 Aug 2005 10:44:48 -0700 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <20050810171941.GA3296@storhaugen.uninett.no> References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <20050810135957.GR14462@login.ecs.soton.ac.uk> <20050810171941.GA3296@storhaugen.uninett.no> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3BFC3E46-ECFF-4774-B124-FCA96ADEEAC1@cisco.com> Content-Transfer-Encoding: 7bit From: Fred Baker Subject: A side note Date: Wed, 10 Aug 2005 10:47:49 -0700 To: v6ops@ops.ietf.org X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=101; t=1123695888; x=1124128088; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:A=20side=20note| From:Fred=20Baker=20| Date:Wed,=2010=20Aug=202005=2010=3A47=3A49=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=fnZmO4+42EcaE1sdH6UnJcaIDOErj1Fih+mLTPwuTYskOU8yc2aRMDiVGxYY5t72QSZZJ/lm LkGZaexl4eJbS9RPVk2eWhXvoZ8rZVx3TLW6EbGHGFyH/hOIwQrg3maFf11kzLgApKR3DagjyCZ +dES12dWFNgLVQ15e+SF3/oU= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit It is very refreshing to find technical discussion regarding a document in progress on this list. We need to do more of it. From owner-v6ops@ops.ietf.org Wed Aug 10 14:51:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vfd-0001ke-NR for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 14:51:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18308 for ; Wed, 10 Aug 2005 14:51:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2veT-0004Oi-NN for v6ops-data@psg.com; Wed, 10 Aug 2005 18:50:09 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2veS-0004OA-Kz for v6ops@ops.ietf.org; Wed, 10 Aug 2005 18:50:09 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7AIo5m14118; Wed, 10 Aug 2005 21:50:05 +0300 Date: Wed, 10 Aug 2005 21:50:05 +0300 (EEST) From: Pekka Savola To: Stig Venaas cc: Tim Chown , v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue: dynamic setup In-Reply-To: <20050810171941.GA3296@storhaugen.uninett.no> Message-ID: References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <20050810135957.GR14462@login.ecs.soton.ac.uk> <20050810171941.GA3296@storhaugen.uninett.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Wed, 10 Aug 2005, Stig Venaas wrote: > On Wed, Aug 10, 2005 at 06:31:45PM +0300, Pekka Savola wrote: >> b1) automatic set up of v4-in-v6 tunnels >> >> b2) automatic set up of v4-in-v6 tunnels when the host >> doesn't have v4 address >> >> b3) automatic set up of v4-in-v6 tunnels when the host >> doesn't have v4 address and an app wants to create a v4 socket >> >> What are the requirements, exactly? > > If you have sufficient amount of IPv4 addresses you could probably > use several mechanisms where you set up tunnels and assign addresses > to every client in the network. As I understand it, DSTM is in > particularly useful when you have hosts that rarely need IPv4 > communications, you have enough IPv4 addresses to serve the hosts > using IPv4 at any given time, but not for all the IPv4-capable > hosts simultaneously. Hence the idea of being triggered by apps > trying to use IPv4 (e.g. creation of v4 socket). First off, the mechanism which triggers the activation of the tunnel is purely a local decision (no bits on the wire), right? So, it's not clear that this even requires a protocol specification. (Especially if the protocol specification doesn't really help the implementor in implementing the algorithm.) But I'm not sure that v4 access is triggered by apps can even work (the number of possible failure modes is one reason why I've been very troubled by the approach). For example, almost all server apps try to create a socket both for v6 and v4 when they start up. Many client programs also do similar things. Are you saying that the hosts would not have any of these applications or couldn't use them without lots of manual configuration (i.e., forcing to use only v6 socket) ? In fact, this dynamic setup when a v4 socket creation is attempted could even be undesirable. There have certainly been folks which don't want to enable v6 when apps try to create v6 sockets (some systems have done this automatically). It seems clear that the same also holds for v4. I.e., a quick failure in the socket loop might be better (and intended) than trying to obtain the address. > I'm not sure b2 makes sense above. You could automatic setup > v4-in-v6 tunnel when hosts boots provided you have enough IPv4 > addresses. However, I think IPv6-only core only makes sense if > IPv4 is rarely used. In that case it makes sense to have tunneling > state only when needed. And as I said above, this may also make > sense if you have lack of addresses. So the tunnel setup and the > assignment of IPv4 address should only be done when needed. One > way of detecting need, is request an IPv4 socket. [...] > There are also some networks today that struggle getting enough > IPv4 addresses for the network infrastructure... Yes, but one could say that those networks are also the ones who are most likely to use private addresses and NAT. Given that the assumption is that v6 is already deployed basically everywhere (at least in the enterprise): 1) public v4 addresses are typically needed by public server apps or some p2p softwares and similar 2) p2p softwares and similar are also the ones which have most profits of being ported to v6 3) public server apps are those (e.g., the enterprise web servers) which require very high amount of reliability. Would you as a system/network admin trust a transition mechanism to automatically get [often dynamic] address (and update DNS etc.) using mechanisms like this? That is, frankly, I don't think there is really big justification for dynamic "enablement" due to address space scarcity. Private addresses would be just fine in those deployments AFAICS. So whether to enable the tunnels dynamically or not seems to be just a matter of whether you want all the hosts which you know should run v4 apps to get connectivity reliably w/o complexity at the startup (or some locally defined) time. In other words, IMHO "dynamic setup" seems like an interesting problem (e.g., to be fussed about by geeks like you and me :), but not something we need to solve.. Less is More. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 10 14:56:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E2vkW-00047l-DL for v6ops-archive@megatron.ietf.org; Wed, 10 Aug 2005 14:56: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 OAA19019 for ; Wed, 10 Aug 2005 14:56:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E2vkF-0005Vv-Qo for v6ops-data@psg.com; Wed, 10 Aug 2005 18:56:07 +0000 Received: from [192.160.51.76] (helo=smtp-bedford.mitre.org) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E2vk4-0005Tj-It for v6ops@ops.ietf.org; Wed, 10 Aug 2005 18:55:56 +0000 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j7AItt503742 for ; Wed, 10 Aug 2005 14:55:55 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id BB6CDBEFB for ; Wed, 10 Aug 2005 14:55:55 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j7AItsF03620; Wed, 10 Aug 2005 14:55:54 -0400 Received: from IMCSRV3.MITRE.ORG ([129.83.20.198]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.211); Wed, 10 Aug 2005 14:55:53 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: Enterprise Analysis DSTM Issue Date: Wed, 10 Aug 2005 14:55:52 -0400 Message-ID: Thread-Topic: Enterprise Analysis DSTM Issue Thread-index: AcWdtjTd0dOfLHCvQy2ODt99IKlbagACRIswAAdEMiA= From: "Chakravorty,Sham" To: "Klynsma,Steven L." , "Tim Chown" , X-OriginalArrivalTime: 10 Aug 2005 18:55:53.0038 (UTC) FILETIME=[21CD8EE0:01C59DDD] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I will second Steve by saying that when I was working on the transition issues last year, the issue of IPv6 core with IPv4 islands around was the scenario we had to deal with most (contrary to the commercial scenario), and DSTM was one of the very few mechanisms that scored high as a solution.=20 I would like to request its continuance in the WG with necessary changes in the text. Sham=20 -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Klynsma,Steven L. Sent: Wednesday, August 10, 2005 12:05 PM To: Tim Chown; v6ops@ops.ietf.org Subject: RE: Enterprise Analysis DSTM Issue I'd have to concur with Tim's analysis. Here, in the Army at least, we are convinced that it makes sense economically to transition to v6-dominant networks as soon as possible. Under DoD guidance (and frankly, OMB has just issued similar guidance to other US Govt agencies), we are to migrate to IPv6 (probably dual-stacked) by Sep 2008. However, there are several large wireless systems I'm aware of that are planning to implement Ipv6 only in their core with transition mechanisms at edges to ensure interop with v4 legacy. Combine that with DoD and OMB's strong push to go to dual-stacked backbone infrastructure by 2008, and I see the department being in a position to require DSTM (or DSTM-like) mechanisms (probably combined with scaleable tunnel brokers) to support v4 islands as soon as three years from now. =20 Having said that, I agree with Pekka that the term "dual-stack" is overused and increasingly ambiguous, but don't really have any position one-way or other on whether DSTM is properly named or not. Got no problem softening section 8.1 per Tim's suggestion. =20 vr, =20 Steve 703-983-6469 =20 "Lead your life so you won't be ashamed to sell the family parrot to the town gossip." Will Rogers, Jr. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown Sent: Wednesday, August 10, 2005 10:00 AM To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue On Wed, Aug 10, 2005 at 04:34:54PM +0300, Pekka Savola wrote: > On Wed, 10 Aug 2005, Stig Venaas wrote: > >Right, might be confusing to change the name again (or go back to the > >AIIH name...). I don't care that much about the name though. There are > >some people deploying IPv6-only networks today, and I'm sure there will > >be more in the future. So I do see the need for IPv4 over IPv6 tunneling. >=20 > Yeah, but your last sentence was exactly my point. >=20 > You don't need the mechanism labeled as DSTM to do "IPv4 over IPv6=20 > tunneling". >=20 > If that's what we wanted, we could just say we need v4-over-v6 and be=20 > done. But you could say the same for other protocols mentioned. =20 My view is that the style of DSTM commentary in 8.4 is good, but 8.1 is too strong. We should keep DSTM cited as a 'useful tool for IPv6 dominant infrastructures'. We can state in the analysis that we need a protocol for that scenario (#3 of RFC4057) that supports: a) v4-in-v6 tunnels b) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket c) authentication for tunnel setup And maybe: > d) automatic monitoring and tear-down of said v4-over-v6 tunnel > when the host detects it no longer needs the address/connectivity > e) plus a number of extensions for even more colorful setups. but these are too specific for the analysis text. Look at RFC3904. That cited Teredo as 'work in progress'. I see no reason why we can't state what generic problem DSTM is solving (assuming we can agree that!) and cite DSTM as an example, and 'work in progress'. We could even add a recommendation, as per section 7 of RFC3904, saying we should develop DSTM or something 'DSTM-like'. =20 Scenario 3 of Section 3.1 of RFC4057 means we need text for this case. I could also point out Section 6.2 of RFC3094: 6.2. IPv4 Connectivity Requirements=20 Local IPv4 capable hosts may still want to access IPv4-only services. The proper way to do this for dual-stack nodes in the unmanaged network is to develop a form of "IPv4 over IPv6" tunneling. There are no standardized solutions and the IETF has devoted very little effort to this issue, although there is ongoing work with [DSTM] and [TSP]. A solution needs to be standardized. The standardization will have to cover configuration issues, i.e., how to provision the IPv4 capable hosts with the address of the local IPv4 tunnel servers. I think this still applies. If anything, it adds to the case for the IETF to get active in this issue, via lrw WG or whereever. So we have unman and ent cases anting some solution in this space. --=20 Tim/::1 From owner-v6ops@ops.ietf.org Thu Aug 11 02:58:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E371m-0000UY-GE for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 02:58: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 CAA12268 for ; Thu, 11 Aug 2005 02:58:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E36yu-000OfC-RI for v6ops-data@psg.com; Thu, 11 Aug 2005 06:56:00 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E36yt-000Oek-VW for v6ops@ops.ietf.org; Thu, 11 Aug 2005 06:56:00 +0000 Received: (qmail 22064 invoked by uid 417); 11 Aug 2005 06:55:56 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 11 Aug 2005 06:55:56 -0000 Received: from mehr ([132.70.221.139]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 11 Aug 2005 00:55:55 -0600 Message-ID: <036a01c59e41$b46afb20$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org Subject: Re: draft-ietf-v6ops-nap-01.txt Date: Thu, 11 Aug 2005 09:55:46 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > Fred Baker Wrote: > > > > On Aug 9, 2005, at 9:36 PM, Daniel Senie wrote: > > > > > Section 2.6: Please provide citations and statistics for the use of > > > NAT and RFC1918 in the delivery of ISP services. Though this is > > > talked about throughout this document, the practice is rare in at > > > least some regions. Hard data would lend credence to this claim. > > > Since this claim is used to justify many things in this document, > > > the lack of citations gives the appearance of a strawman construct. > > > > While I don't have specific statistics, as this would require access > > ot a lot of networks and the NDAs that accompany such, I do know that > > the practice is common in Africa and parts of Asia. At one time, > > China Unicom (which last year delivered over a billion voice minutes > > using VoIP over an IP/ATM fiber backbone) used three layers of NATs, > > citing inability to obtain IPv4 addresses as the primary reason. They > > have since directly joined APNIC, I'm told, and may no longer do that. > > I am not sure about all regions / nations, but I do know that in the following countries (names withheld due to NDA) there are several companies that are using NAT to separate internal private networks infrastructure and management from the Publicly aces: In the United States there are at least 4 fixed line phone companies, 2 long distance, and 1 Utility company In the UK there are at least 2 cellular and 2 fixed companies In Israel there are at least 3 long distance, 2 cellular and the national carrier In the Netherlands there is one carrier Eric From owner-v6ops@ops.ietf.org Thu Aug 11 05:08:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E393K-0001oS-0t for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 05:08: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 FAA17938 for ; Thu, 11 Aug 2005 05:08:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E391R-0009cb-Su for v6ops-data@psg.com; Thu, 11 Aug 2005 09:06:45 +0000 Received: from [213.204.46.35] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E391Q-0009cB-PK for v6ops@ops.ietf.org; Thu, 11 Aug 2005 09:06:45 +0000 Received: from [192.71.80.74] (laptop2.kurtis.autonomica.se [192.71.80.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id BB4B9329F14; Thu, 11 Aug 2005 12:06:28 +0300 (EEST) In-Reply-To: <1A366AA8-2123-4869-AE0A-5F701B40D194@cisco.com> References: <6.2.3.4.2.20050809231210.077743c8@mail.amaranth.net> <1A366AA8-2123-4869-AE0A-5F701B40D194@cisco.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Daniel Senie , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: draft-ietf-v6ops-nap-01.txt Date: Thu, 11 Aug 2005 11:06:01 +0200 To: Fred Baker X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On 10 aug 2005, at 09.13, Fred Baker wrote: > > On Aug 9, 2005, at 9:36 PM, Daniel Senie wrote: > > >> Section 2.6: Please provide citations and statistics for the use >> of NAT and RFC1918 in the delivery of ISP services. Though this is >> talked about throughout this document, the practice is rare in at >> least some regions. Hard data would lend credence to this claim. >> Since this claim is used to justify many things in this document, >> the lack of citations gives the appearance of a strawman construct. >> > > While I don't have specific statistics, as this would require > access ot a lot of networks and the NDAs that accompany such, I do > know that the practice is common in Africa and parts of Asia. At > one time, China Unicom (which last year delivered over a billion > voice minutes using VoIP over an IP/ATM fiber backbone) used three > layers of NATs, citing inability to obtain IPv4 addresses as the > primary reason. They have since directly joined APNIC, I'm told, > and may no longer do that. I know of several European providers doing the same BTW. - kurtis - From owner-v6ops@ops.ietf.org Thu Aug 11 05:09:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E393l-0001s6-GC for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 05:09:11 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17947 for ; Thu, 11 Aug 2005 05:09:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E393b-0009oZ-5F for v6ops-data@psg.com; Thu, 11 Aug 2005 09:08:59 +0000 Received: from [213.204.46.35] (helo=mariehamn.kurtis.pp.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E393Z-0009o1-EG for v6ops@ops.ietf.org; Thu, 11 Aug 2005 09:08:57 +0000 Received: from [192.71.80.74] (laptop2.kurtis.autonomica.se [192.71.80.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by mariehamn.kurtis.pp.se (Postfix) with ESMTP id 76033329F12; Thu, 11 Aug 2005 12:08:47 +0300 (EEST) In-Reply-To: <20050810131243.GN14462@login.ecs.soton.ac.uk> References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> <20050810131243.GN14462@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3C78953C-C6AF-41A8-A878-80C2B77B8964@kurtis.pp.se> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Kurt Erik Lindqvist Subject: Re: Enterprise Analysis DSTM Issue Date: Thu, 11 Aug 2005 11:07:16 +0200 To: Tim Chown X-Mailer: Apple Mail (2.733) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit (this is somewhat off-topic I guess) On 10 aug 2005, at 15.12, Tim Chown wrote: > I think for the majority of cases/networks that's true. But I have > spoken > to people recently who believe (conventional) dual-stack adds to > security > complexity, and they'd like to run one protocol only. I must miss something here. In what way would these people think the security model differed from any other tunnelling model for security? I.e the payload is the payload is the payload, and from my experience that is what is hard to secure...the only way to protect them then is to either leave out the v4 Internet (which might not be a bad idea from security POV :-) or do translation? - kurtis - From owner-v6ops@ops.ietf.org Thu Aug 11 06:54:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3AhY-0000VI-Pk for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 06:54: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 GAA22954 for ; Thu, 11 Aug 2005 06:54:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3Aff-000H8g-VE for v6ops-data@psg.com; Thu, 11 Aug 2005 10:52:23 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3Afd-000H8I-Si for v6ops@ops.ietf.org; Thu, 11 Aug 2005 10:52:22 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7BAqKqA001475 for ; Thu, 11 Aug 2005 11:52:20 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA16648 for ; Thu, 11 Aug 2005 11:51:45 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7BApiq22672 for v6ops@ops.ietf.org; Thu, 11 Aug 2005 11:51:44 +0100 Date: Thu, 11 Aug 2005 11:51:44 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050811105144.GC21632@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> <20050810131243.GN14462@login.ecs.soton.ac.uk> <3C78953C-C6AF-41A8-A878-80C2B77B8964@kurtis.pp.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C78953C-C6AF-41A8-A878-80C2B77B8964@kurtis.pp.se> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Aug 11, 2005 at 11:07:16AM +0200, Kurt Erik Lindqvist wrote: > > (this is somewhat off-topic I guess) > > On 10 aug 2005, at 15.12, Tim Chown wrote: > > >I think for the majority of cases/networks that's true. But I have > >spoken > >to people recently who believe (conventional) dual-stack adds to > >security > >complexity, and they'd like to run one protocol only. > > > I must miss something here. In what way would these people think the > security model differed from any other tunnelling model for security? > I.e the payload is the payload is the payload, and from my experience > that is what is hard to secure...the only way to protect them then is > to either leave out the v4 Internet (which might not be a bad idea > from security POV :-) or do translation? Sorry if I was not being as clear as I could be. There's some overlap betweeen DSTM and conventional dual stack in this discussion. I'm saying that some (UK) people have mentioned to me that they do not want to run dual-stack because they believe it adds complexity to security, and thus would want to run IPv6 only, or at least IPv6-only network infrastructure. Given the latter, if they have some dual-stack hosts, something DSTM-like in functionality may be required. They are also evaluating NAT-PT, etc in light of this. The concern expressed was the fact that two protocols are in use, and both need to be secured, mainly with consistent policies and with some IPv6 specific policies. I'm not saying I agree with that assessment (which is why we run conventional dual-stack on our 1,000+ node network here) but the requirement seems to be there. Maybe it's an education issue like NAP. Of course, the DSTM-like protocol and NAT-PT have their own security implications... -- Tim/::1 From owner-v6ops@ops.ietf.org Thu Aug 11 07:06:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Asr-0003An-Vp for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 07:06: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 HAA23621 for ; Thu, 11 Aug 2005 07:05:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3AsE-000ISa-Mh for v6ops-data@psg.com; Thu, 11 Aug 2005 11:05:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3AsC-000IRg-Na for v6ops@ops.ietf.org; Thu, 11 Aug 2005 11:05:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7BB5D732366; Thu, 11 Aug 2005 14:05:15 +0300 Date: Thu, 11 Aug 2005 14:05:13 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue In-Reply-To: <20050811105144.GC21632@login.ecs.soton.ac.uk> Message-ID: References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> <20050810131243.GN14462@login.ecs.soton.ac.uk> <3C78953C-C6AF-41A8-A878-80C2B77B8964@kurtis.pp.se> <20050811105144.GC21632@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 11 Aug 2005, Tim Chown wrote: > There's some overlap betweeen DSTM and conventional dual stack in this > discussion. I'm saying that some (UK) people have mentioned to me that they > do not want to run dual-stack because they believe it adds complexity to > security, and thus would want to run IPv6 only, or at least IPv6-only network > infrastructure. Given the latter, if they have some dual-stack hosts, > something DSTM-like in functionality may be required. They are also > evaluating NAT-PT, etc in light of this. > > The concern expressed was the fact that two protocols are in use, and both > need to be secured, mainly with consistent policies and with some IPv6 > specific policies. So, if I get this correctly, the fear is about attacks on the network infrastructure (routers, etc.), not on the end hosts ? Because as long as you WILL have v6 connectivity through [v4-in-v6 tunneling] on the end hosts, you will STILL have the same security problems? You've just shifted them around to a different place in the topology. But if the assumption is that an enterprise/university could run entirely v6-only core (routers, switches, what have you, without [v4-in-v6 tunneling] for their management or whatever), yes, there might be small differences. My assumption has always been that the network admins should be capable of secuiring the routers, switches, etc. properly (in any case, the same degree they could do so with v6), but maybe my optimism isn't shared everywhere.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 11 07:11:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3Ay6-00050B-D5 for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 07:11: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 HAA23782 for ; Thu, 11 Aug 2005 07:11:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3AxQ-000J1D-C9 for v6ops-data@psg.com; Thu, 11 Aug 2005 11:10:44 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3AxP-000J0j-KE for v6ops@ops.ietf.org; Thu, 11 Aug 2005 11:10:43 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7BBAgqA001936 for ; Thu, 11 Aug 2005 12:10:42 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id MAA18373 for ; Thu, 11 Aug 2005 12:10:18 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7BBAIA23254 for v6ops@ops.ietf.org; Thu, 11 Aug 2005 12:10:18 +0100 Date: Thu, 11 Aug 2005 12:10:18 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Enterprise Analysis DSTM Issue Message-ID: <20050811111018.GF21632@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <936A4045C332714F975800409DE09240C47B2F@tayexc14.americas.cpqcorp.net> <20050809211354.GD27778@login.ecs.soton.ac.uk> <3E118202-8B18-4173-953D-419A2BBD3F74@cisco.com> <20050810131243.GN14462@login.ecs.soton.ac.uk> <3C78953C-C6AF-41A8-A878-80C2B77B8964@kurtis.pp.se> <20050811105144.GC21632@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Aug 11, 2005 at 02:05:13PM +0300, Pekka Savola wrote: > > So, if I get this correctly, the fear is about attacks on the > network infrastructure (routers, etc.), not on the end hosts ? Yes, I think so. > Because as long as you WILL have v6 connectivity through [v4-in-v6 > tunneling] on the end hosts, you will STILL have the same security > problems? You've just shifted them around to a different place in the > topology. > > But if the assumption is that an enterprise/university could run > entirely v6-only core (routers, switches, what have you, without > [v4-in-v6 tunneling] for their management or whatever), yes, there > might be small differences. > > My assumption has always been that the network admins should be > capable of secuiring the routers, switches, etc. properly (in any > case, the same degree they could do so with v6), but maybe my optimism > isn't shared everywhere.. Seems so. As I said, I'm just relaying comments that I have heard. -- Tim/::1 From owner-v6ops@ops.ietf.org Thu Aug 11 14:56:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E3IEY-0002Pp-Sx for v6ops-archive@megatron.ietf.org; Thu, 11 Aug 2005 14:56: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 OAA19536 for ; Thu, 11 Aug 2005 14:56:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E3IBP-00027e-EC for v6ops-data@psg.com; Thu, 11 Aug 2005 18:53:39 +0000 Received: from [64.233.184.200] (helo=wproxy.gmail.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E3IBM-00026k-4m for v6ops@ops.ietf.org; Thu, 11 Aug 2005 18:53:36 +0000 Received: by wproxy.gmail.com with SMTP id 49so120985wri for ; Thu, 11 Aug 2005 11:53:35 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=S3oapgF+5xrWOjwNg5YSE/eKgZUE3dFnOchu9f4n4UGw2Y2cEnBh/zrMoB10hvOcoa2YDrY+iN3xCXX1RDde6oEU4T5RyiYbBWpBxZGqRNzJGgLWYvhZfPISqUTZ2cwRdsoag1Vmtn45Xnf5Ht/Vrjtw9ovJzwNXePmBMV/JDqo= Received: by 10.54.19.46 with SMTP id 46mr52041wrs; Thu, 11 Aug 2005 11:53:35 -0700 (PDT) Received: by 10.54.19.61 with HTTP; Thu, 11 Aug 2005 11:53:34 -0700 (PDT) Message-ID: <9852189205081111535ac3c95c@mail.gmail.com> Date: Thu, 11 Aug 2005 11:53:34 -0700 From: Suresh Satapati To: Stig Venaas Subject: Re: Enterprise Analysis DSTM Issue Cc: Pekka Savola , Tim Chown , v6ops@ops.ietf.org In-Reply-To: <20050810171941.GA3296@storhaugen.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <936A4045C332714F975800409DE09240C47C32@tayexc14.americas.cpqcorp.net> <20050810130130.GL14462@login.ecs.soton.ac.uk> <20050810132326.GA2265@storhaugen.uninett.no> <20050810135957.GR14462@login.ecs.soton.ac.uk> <20050810171941.GA3296@storhaugen.uninett.no> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,RCVD_BY_IP autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On 8/10/05, Stig Venaas wrote: > On Wed, Aug 10, 2005 at 06:31:45PM +0300, Pekka Savola wrote: > [...] > > On Wed, 10 Aug 2005, Tim Chown wrote: > > >We can state in the analysis that we need > > >a protocol for that scenario (#3 of RFC4057) that supports: > > > > > > a) v4-in-v6 tunnels > > > b) automatic set up of v4-in-v6 tunnels when the host > > > doesn't have v4 address and an app wants to create a v4 socket > > > c) authentication for tunnel setup > > > > OK, this is good. Let's try to separate b) into three: > > > > b1) automatic set up of v4-in-v6 tunnels > > > > b2) automatic set up of v4-in-v6 tunnels when the host > > doesn't have v4 address > > > > b3) automatic set up of v4-in-v6 tunnels when the host > > doesn't have v4 address and an app wants to create a v4 socket > > > > What are the requirements, exactly? >=20 > If you have sufficient amount of IPv4 addresses you could probably > use several mechanisms where you set up tunnels and assign addresses > to every client in the network. As I understand it, DSTM is in > particularly useful when you have hosts that rarely need IPv4 > communications, you have enough IPv4 addresses to serve the hosts > using IPv4 at any given time, but not for all the IPv4-capable > hosts simultaneously. Hence the idea of being triggered by apps > trying to use IPv4 (e.g. creation of v4 socket). >=20 > I'm not sure b2 makes sense above. You could automatic setup > v4-in-v6 tunnel when hosts boots provided you have enough IPv4 > addresses. However, I think IPv6-only core only makes sense if > IPv4 is rarely used. In that case it makes sense to have tunneling > state only when needed. And as I said above, this may also make > sense if you have lack of addresses. So the tunnel setup and the > assignment of IPv4 address should only be done when needed. One > way of detecting need, is request an IPv4 socket. Not being judgemental about DSTM, one could argue such a method of detection is outside the scope of this wg, or maybe even outside the scope of IETF.=20 >=20 > I think several networks could manage with little IPv4 traffic > already today. In particular if you have dual-stack mailservers, > dual-stack web proxies etc. You would only need IPv4 to the > internet when using more rare applications. >=20 > There are also some networks today that struggle getting enough > IPv4 addresses for the network infrastructure... >=20 > Stig >=20 > From owner-v6ops@ops.ietf.org Mon Aug 15 17:27:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mUn-0004hx-R3 for v6ops-archive@megatron.ietf.org; Mon, 15 Aug 2005 17:27: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 RAA05471 for ; Mon, 15 Aug 2005 17:27:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4mQr-000HNd-3J for v6ops-data@psg.com; Mon, 15 Aug 2005 21:23:45 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4mQp-000HNA-Dp for v6ops@ops.ietf.org; Mon, 15 Aug 2005 21:23:43 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 15 Aug 2005 14:23:43 -0700 X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="332409008:sNHT33618672" 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 j7FLNYQM019578 for ; Mon, 15 Aug 2005 14:23:34 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7FLJfOv011630 for ; Mon, 15 Aug 2005 14:20:18 -0700 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> Content-Transfer-Encoding: 7bit From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Mon, 15 Aug 2005 15:50:01 -0400 To: i-d-announce@ietf.org X-Mailer: Apple Mail (2.733) Authentication-Results: imail.cisco.com; header.from=Internet-Drafts@ietf.org; dkim=neutral X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,NO_REAL_NAME autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The End to End Problem in a fully generalized IPv4, IPv6, and IPv4+IPv6 network Author(s) : F. Baker Filename : draft-baker-v6ops-end2end-00.txt Pages : 23 Date : 2005-8-15 This note is intended to describe the end to end problem as it applies to a network of networks, wherein some component networks independently run only IPv4 with or without a transition mechanism, some run only IPv6 with or without a transition mechanism and without coordination of transition mechanisms, and some run IPv4 and IPv6 in parallel supporting native routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-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-baker-v6ops-end2end-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-baker-v6ops-end2end-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------------------------------------------------------------------------ - CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY ------------------------------------------------------------------------ - In order to maintain computing infrastructure integrity, Cisco Systems Enterprise Messaging Services and InfoSec teams have set a mail policy disallowing executable attachments in email. This message contained an executable attachment type that is prohibited by this policy. The attachment has been removed from this message and copied to quarantine by our systems. It will be held in quarantine for seven days in the event that the content needs to be retrieved. Please be aware many viruses attempt to look like legitimate email or notifications from anti-virus systems. We will clearly mark a seperation between our notifications and the original email as follows: "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: j7FK4TVS011545 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce From owner-v6ops@ops.ietf.org Mon Aug 15 17:28:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mVL-0004tu-0d for v6ops-archive@megatron.ietf.org; Mon, 15 Aug 2005 17:28: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 RAA05514 for ; Mon, 15 Aug 2005 17:28:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4mU1-000Hf9-G2 for v6ops-data@psg.com; Mon, 15 Aug 2005 21:27:01 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1E4mTy-000Heg-PB for v6ops@ops.ietf.org; Mon, 15 Aug 2005 21:26:59 +0000 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001206110.msg for ; Mon, 15 Aug 2005 23:29:21 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 15 Aug 2005 23:25:54 +0200 Subject: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: 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-MDAV-Processed: consulintel.es, Mon, 15 Aug 2005 23:29:25 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, Nice document. 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. Network B and C are either IPv4 and IPv6 (dual stack) or IPv4 and IPv6 (tunneled), but they appear to network A and D as dual stack. This means that IPv6 traffic leaving the leaf networks will never be "translated", even it can be tunneled in case B or C don't support native IPv6. Meanwhile, IPv4 traffic could be handled in several ways: 1) Tunneling 4-in-6 (from GW-A1 to GW-A2) 2) Tunneling 4-in-6 (from GW-A to GW-B) 3) Translation for some protocols, such as HTTP which typically are already proxied, so we aren't adding an additional breach. Example an IPv4 only web site located outside GW-B, is being proxied (v4 outside-v6 inside thru A) and reached all the way via IPv6. The point here is to have a UNIQUE 4-in-6 protocol which will work the same in 3.2 than 3.3, otherwise we will have some troubles as more and more networks (general internet) have only IPv6 support, which will happen sooner or later. Having a single 4-in-6 mechanism will avoid future problems. I think this is part of the work that we started some time ago with the auto-discovering of tunnel end points, v6tf and recently "softwires". Work already done could be used here, such as DSTM. 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 ? Regards, Jordi ------ Mensaje reenviado De: "Internet-Drafts@ietf.org" Responder a: "Internet-Drafts@ietf.org" Fecha: Mon, 15 Aug 2005 15:50:01 -0400 Para: Asunto: I-D ACTION:draft-baker-v6ops-end2end-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : The End to End Problem in a fully generalized IPv4, IPv6, and IPv4+IPv6 network Author(s) : F. Baker Filename : draft-baker-v6ops-end2end-00.txt Pages : 23 Date : 2005-8-15 This note is intended to describe the end to end problem as it applies to a network of networks, wherein some component networks independently run only IPv4 with or without a transition mechanism, some run only IPv6 with or without a transition mechanism and without coordination of transition mechanisms, and some run IPv4 and IPv6 in parallel supporting native routing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-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-baker-v6ops-end2end-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-baker-v6ops-end2end-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2005-8-15142046.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ************************************ 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 Aug 15 17:48:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E4mod-000891-Lf for v6ops-archive@megatron.ietf.org; Mon, 15 Aug 2005 17:48:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06392 for ; Mon, 15 Aug 2005 17:48:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E4mnT-000JTC-RR for v6ops-data@psg.com; Mon, 15 Aug 2005 21:47:07 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E4mnT-000JSz-4Y for v6ops@ops.ietf.org; Mon, 15 Aug 2005 21:47:07 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 15 Aug 2005 14:47:07 -0700 X-IronPort-AV: i="3.96,108,1122879600"; d="scan'208"; a="654845898:sNHT34210424" 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 j7FLl1QM000155; Mon, 15 Aug 2005 14:47:02 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7FLhfBA011939; Mon, 15 Aug 2005 14:43:41 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <456CB87D-36EE-4282-B390-5E73C9C5F66D@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, 15 Aug 2005 14:47:02 -0700 To: jordi.palet@consulintel.es X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=1638; t=1124142221; x=1124574421; 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,=2015=20Aug=202005=2014=3A47=3A02=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=SFoQGRi7iC4b/izpxF9mVX/sVvZ9zjHa4lsJGTvUOUoW7d53Jiv3ETxd8zD4F8N8CZBKSmDc 0JdHNDHTxo4Hilgpx3gmu7XUM2z3tB+cNXtxcLynyaBGAgrl1b0+vrtBw5fsgr7JdUo9xeDZiQv iACuwbSCPwOHQdqGgW47oxNk= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit 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 Tue Aug 16 12:29:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54Jt-0007PB-Up for v6ops-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:29: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 MAA22208 for ; Tue, 16 Aug 2005 12:29:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E54HU-0005qv-V2 for v6ops-data@psg.com; Tue, 16 Aug 2005 16:27:16 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E54HQ-0005qZ-SW for v6ops@ops.ietf.org; Tue, 16 Aug 2005 16:27:13 +0000 Received: (qmail 21250 invoked by uid 417); 16 Aug 2005 16:27:11 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 16 Aug 2005 16:27:11 -0000 Received: from mehr ([132.70.222.174]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 16 Aug 2005 10:27:05 -0600 Message-ID: <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Tue, 16 Aug 2005 19:27:07 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred, A few comments (mostly nits). 1. This is the first time I have seen a draft that refers to it's self as a note ( in the abstract and introduction), this seems like the wrong word. 2. In the last sentence of section 2.1 it reads: "IPv4, there is at minimum IPv4 connectivity", I recommend it read: "IPv4, there is at a minimum IPv4 connectivity" 3. In the last sentence of section 3 it reads: ' "A satisfactory solution", it could be said, "contains no unnecessary complexity", and "first, does no harm." ' This seems a little confusing, as the one with first is second or last. It may be confusing for non-native English speakers. 4. In section 3.1, in the third paragraph ("If the central IPv4 networks are providing the"), is this referring to the backbone or interconnection points (like the public MAE (east/west) Internet Exchange or any of the hundreds of private ones)? Are there any drafts that talk about converting the backbones or interconnection points to IPv6 using any of the methods used (tunnel broker, etc) or are they all end network based (like Tredeo, etc). If not then this or another one might help solve some of the problems you are discussing. For example MAE (run by MCI http://www.mae.net/svc/mae-ipv6.htm) states: IPv6 and IPv6 peering services reside on the same level 2 exchange switch fabric. IPv6 is transparent to the switching platform and the access type (ATM, Frame, or GigE), and the connections are supported by PeerMaker. Customers may choose to use a separate port for IPv6 or share the same port among IPv6 and IPv4 connections. The service supports native, dual-stack, tunneling connections configurations. Important IPv6 is not supported for interworked connections between a GigE port and either a Frame or ATM port. Please note that they support tunneling, but do not say which type (just as you describe). Eric ----- Original Message ----- From: To: Sent: Monday, August 15, 2005 10:50 PM Subject: I-D ACTION:draft-baker-v6ops-end2end-00.txt > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : The End to End Problem in a fully generalized > IPv4, IPv6, and IPv4+IPv6 network > Author(s) : F. Baker > Filename : draft-baker-v6ops-end2end-00.txt > Pages : 23 > Date : 2005-8-15 > > This note is intended to describe the end to end problem as it > applies to a network of networks, wherein some component networks > independently run only IPv4 with or without a transition mechanism, > some run only IPv6 with or without a transition mechanism and > without > coordination of transition mechanisms, and some run IPv4 and IPv6 in > parallel supporting native routing. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-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-baker-v6ops-end2end-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-baker-v6ops-end2end-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > ------------------------------------------------------------------------ > - > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > ------------------------------------------------------------------------ > - > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. > > This message contained an executable attachment type that is prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. > > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a seperation > between our notifications and the original email as follows: > > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY" > > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: > > http://wwwin.cisco.com/it/ems/services/antiviral > > If your concern isn't addressed by the information in this notification > or the above web page, you may open a support request: > > http://wwwin.cisco.com/support/ > > Select "Messaging", "Email-Related", "Mail Routing" > > Please include in the text of your case the following information: > > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: > > http://wwwin.cisco.com/support/library/faqs/solution002471.html > > * This unique quarantine identifier: j7FK4TVS011545 > > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. > > Americas: > 1 408 526 8888 > > Asiapac > +61 2 8446 8888 > > EMEA > +31 20 485 4888 > > Japan > +81 3 5549 6888 > > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) > > Thank you for your cooperation, > > Enterprise Messaging Services > Cisco Systems, Inc > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce > > From owner-v6ops@ops.ietf.org Tue Aug 16 12:49:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54cb-0002EZ-Dr for v6ops-archive@megatron.ietf.org; Tue, 16 Aug 2005 12:49: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 MAA22971 for ; Tue, 16 Aug 2005 12:49:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E54bd-00079C-DP for v6ops-data@psg.com; Tue, 16 Aug 2005 16:48:05 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E54ba-00078s-91 for v6ops@ops.ietf.org; Tue, 16 Aug 2005 16:48:02 +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 JAA00019 for ; Tue, 16 Aug 2005 09:48:01 -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 j7GGm1s07754 for ; Tue, 16 Aug 2005 09:48:01 -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.211); Tue, 16 Aug 2005 09:48: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: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Tue, 16 Aug 2005 09:48:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FB0@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: I-D ACTION:draft-baker-v6ops-end2end-00.txt Thread-Index: AcWh4bZcrWIi33HcTOyHq14g9nYNrwAnjgzg From: "Templin, Fred L" To: X-OriginalArrivalTime: 16 Aug 2005 16:48:00.0526 (UTC) FILETIME=[431BA2E0:01C5A282] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Fred, I enjoyed reading this informative draft and agree for the most part with its conclusions. I have one doubt about section 2.1, step 5. where it says: > 5. At some point in the (very) distant future, IPv6 connectivity is > sufficiently ubiquitous that IPv4 connectivity becomes > unnecessary. At this point, businesses independently remove IPv4 > from the network as being no longer useful." If and when we reach such a point in the (very) distant future, it seems safe to say that *applications* would cease to use IPv4 but I wonder if we can safely predict that businesses would remove IPv4 from their *networks*? I.e., it seems conceivable that IPv4 might remain in networks for some time (perhaps even indefinitely) after applications cease to use IPv4.=20 Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Monday, August 15, 2005 12:50 PM > To: i-d-announce@ietf.org > Subject: I-D ACTION:draft-baker-v6ops-end2end-00.txt=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts =20 > directories. >=20 >=20 > Title : The End to End Problem in a fully generalized > IPv4, IPv6, and IPv4+IPv6 network > Author(s) : F. Baker > Filename : draft-baker-v6ops-end2end-00.txt > Pages : 23 > Date : 2005-8-15 >=20 > This note is intended to describe the end to end problem as it > applies to a network of networks, wherein some component networks > independently run only IPv4 with or without a transition=20 > mechanism, > some run only IPv6 with or without a transition mechanism and =20 > without > coordination of transition mechanisms, and some run IPv4=20 > and IPv6 in > parallel supporting native routing. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.txt >=20 > 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 =20 > of the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 >=20 > Internet-Drafts are also available by anonymous FTP. Login with the =20 > username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-baker-v6ops-end2end-00.txt". >=20 > 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 >=20 >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-baker-v6ops-end2end-00.txt". >=20 > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail =20 > readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. >=20 >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------- > ----------=20 > - > CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY > -------------------------------------------------------------- > ----------=20 > - > In order to maintain computing infrastructure integrity, Cisco Systems > Enterprise Messaging Services and InfoSec teams have set a mail policy > disallowing executable attachments in email. >=20 > This message contained an executable attachment type that is=20 > prohibited > by this policy. The attachment has been removed from this message and > copied to quarantine by our systems. It will be held in quarantine for > seven days in the event that the content needs to be retrieved. >=20 > Please be aware many viruses attempt to look like legitimate email or > notifications from anti-virus systems. We will clearly mark a=20 > seperation > between our notifications and the original email as follows: >=20 > "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION=20 > TECHNOLOGY" >=20 > For further reference information about viruses and email antivirus > efforts within Cisco, please visit: >=20 > http://wwwin.cisco.com/it/ems/services/antiviral >=20 > If your concern isn't addressed by the information in this=20 > notification > or the above web page, you may open a support request: >=20 > http://wwwin.cisco.com/support/ >=20 > Select "Messaging", "Email-Related", "Mail Routing" >=20 > Please include in the text of your case the following information: >=20 > * Full headers of the message. Documentation on displaying the full > headers is available at this URL: >=20 > http://wwwin.cisco.com/support/library/faqs/solution002471.html >=20 > * This unique quarantine identifier: j7FK4TVS011545 >=20 > If the matter is urgent, you may follow up by calling one of the below > referenced numbers. Please make every effort to provide the above > requested information via the support web tool prior to calling as it > will greatly aid the resolution of your issue. >=20 > Americas: > 1 408 526 8888 >=20 > Asiapac > +61 2 8446 8888 >=20 > EMEA > +31 20 485 4888 >=20 > Japan > +81 3 5549 6888 >=20 > US (Toll Free) > 1| 800| 888| 8187| (ext.68888) >=20 > Thank you for your cooperation, >=20 > Enterprise Messaging Services > Cisco Systems, Inc > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce >=20 >=20 From owner-v6ops@ops.ietf.org Tue Aug 16 13:04:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E54rg-0004ni-21 for v6ops-archive@megatron.ietf.org; Tue, 16 Aug 2005 13:04: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 NAA23611 for ; Tue, 16 Aug 2005 13:04:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E54r7-0008sj-Ce for v6ops-data@psg.com; Tue, 16 Aug 2005 17:04:05 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E54r5-0008sM-9c for v6ops@ops.ietf.org; Tue, 16 Aug 2005 17:04:03 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 16 Aug 2005 10:04:03 -0700 X-IronPort-AV: i="3.96,112,1122879600"; d="scan'208"; a="332713387:sNHT37613252" 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 j7GH40oo013499; Tue, 16 Aug 2005 10:04:01 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7GH0YNt019837; Tue, 16 Aug 2005 10:00:34 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FB0@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FB0@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Tue, 16 Aug 2005 10:03:58 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=5426; t=1124211635; x=1124643835; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20I-D=20ACTION=3Adraft-baker-v6ops-end2end-00.txt=20| From:Fred=20Baker=20| Date:Tue,=2016=20Aug=202005=2010=3A03=3A58=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=eQPEDKo6CkFrvkcgo5+Y34cfjCogdjaRG5yOTdke6ljWmEms3ACF/twLHFXXJ2NCSpUJwg8E IH+P4j3zh2USPdUkzKC4NjbTV+AxcqrRloaW+xYHiL6rWWevCTRdPMm6RKgupcQZIRaqinvSIOA KjiGKrxKaDVXgyeYu7cBcSHI= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit The word "very" is operative in that sentence. That said, yes, of none of the applications are using IPv4, there is an ongoing cost to maintaining it (if nothing else, training, testing, and configuration maintenance), and at some point one must presume that someone will wonder why he's paying the cost. We have people asking that question already, which is the impetus behind the discussion of IPv6-only and IPv6-dominant networks. On Aug 16, 2005, at 9:48 AM, Templin, Fred L wrote: > Hello Fred, > > I enjoyed reading this informative draft and agree for the > most part with its conclusions. I have one doubt about > section 2.1, step 5. where it says: > > >> 5. At some point in the (very) distant future, IPv6 >> connectivity is >> sufficiently ubiquitous that IPv4 connectivity becomes >> unnecessary. At this point, businesses independently remove >> > IPv4 > >> from the network as being no longer useful." >> > > If and when we reach such a point in the (very) distant future, it > seems safe to say that *applications* would cease to use IPv4 but I > wonder if we can safely predict that businesses would remove IPv4 from > their *networks*? I.e., it seems conceivable that IPv4 might remain > in networks for some time (perhaps even indefinitely) after > applications cease to use IPv4. > > Fred > fred.l.templin@boeing.com > > > >> -----Original Message----- >> From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] >> Sent: Monday, August 15, 2005 12:50 PM >> To: i-d-announce@ietf.org >> Subject: I-D ACTION:draft-baker-v6ops-end2end-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> Title : The End to End Problem in a fully generalized >> IPv4, IPv6, and IPv4+IPv6 network >> Author(s) : F. Baker >> Filename : draft-baker-v6ops-end2end-00.txt >> Pages : 23 >> Date : 2005-8-15 >> >> This note is intended to describe the end to end problem as it >> applies to a network of networks, wherein some component networks >> independently run only IPv4 with or without a transition >> mechanism, >> some run only IPv6 with or without a transition mechanism and >> without >> coordination of transition mechanisms, and some run IPv4 >> and IPv6 in >> parallel supporting native routing. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-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-baker-v6ops-end2end-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-baker-v6ops-end2end-00.txt". >> >> NOTE: The mail server at ietf.org can return the document in >> MIME-encoded form by using the "mpack" utility. To use this >> feature, insert the command "ENCODING mime" before the "FILE" >> command. To decode the response(s), you will need "munpack" or >> a MIME-compliant mail reader. Different MIME-compliant mail >> readers >> exhibit different behavior, especially when dealing with >> "multipart" MIME messages (i.e. documents which have been split >> up into multiple messages), so check your local documentation on >> how to manipulate these messages. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> -------------------------------------------------------------- >> ---------- >> - >> CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION TECHNOLOGY >> -------------------------------------------------------------- >> ---------- >> - >> In order to maintain computing infrastructure integrity, Cisco >> Systems >> Enterprise Messaging Services and InfoSec teams have set a mail >> policy >> disallowing executable attachments in email. >> >> This message contained an executable attachment type that is >> prohibited >> by this policy. The attachment has been removed from this message and >> copied to quarantine by our systems. It will be held in quarantine >> for >> seven days in the event that the content needs to be retrieved. >> >> Please be aware many viruses attempt to look like legitimate email or >> notifications from anti-virus systems. We will clearly mark a >> seperation >> between our notifications and the original email as follows: >> >> "CONTENT ABOVE THIS LINE IS *NOT* FROM CISCO INFORMATION >> TECHNOLOGY" >> >> For further reference information about viruses and email antivirus >> efforts within Cisco, please visit: >> >> http://wwwin.cisco.com/it/ems/services/antiviral >> >> If your concern isn't addressed by the information in this >> notification >> or the above web page, you may open a support request: >> >> http://wwwin.cisco.com/support/ >> >> Select "Messaging", "Email-Related", "Mail Routing" >> >> Please include in the text of your case the following information: >> >> * Full headers of the message. Documentation on displaying the full >> headers is available at this URL: >> >> http://wwwin.cisco.com/support/library/faqs/solution002471.html >> >> * This unique quarantine identifier: j7FK4TVS011545 >> >> If the matter is urgent, you may follow up by calling one of the >> below >> referenced numbers. Please make every effort to provide the above >> requested information via the support web tool prior to calling as it >> will greatly aid the resolution of your issue. >> >> Americas: >> 1 408 526 8888 >> >> Asiapac >> +61 2 8446 8888 >> >> EMEA >> +31 20 485 4888 >> >> Japan >> +81 3 5549 6888 >> >> US (Toll Free) >> 1| 800| 888| 8187| (ext.68888) >> >> Thank you for your cooperation, >> >> Enterprise Messaging Services >> Cisco Systems, Inc >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www1.ietf.org/mailman/listinfo/i-d-announce >> >> > From owner-v6ops@ops.ietf.org Tue Aug 16 14:33:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56Fv-0003IJ-QD for v6ops-archive@megatron.ietf.org; Tue, 16 Aug 2005 14:33:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27494 for ; Tue, 16 Aug 2005 14:33:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56EA-000FiZ-5b for v6ops-data@psg.com; Tue, 16 Aug 2005 18:31:58 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E56E8-000Fhn-Vo for v6ops@ops.ietf.org; Tue, 16 Aug 2005 18:31:57 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 16 Aug 2005 11:31:56 -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 j7GIVo2i012251; Tue, 16 Aug 2005 11:31:51 -0700 (PDT) Received: from [10.32.244.218] (stealth-10-32-244-218.cisco.com [10.32.244.218]) by imail.cisco.com (8.12.11/8.12.10) with SMTP id j7GISOLw021318; Tue, 16 Aug 2005 11:28:24 -0700 In-Reply-To: <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> Mime-Version: 1.0 (Apple Message framework v733) X-Priority: 3 Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9393DAD1-0794-4EE9-B779-0EA07B662A7C@cisco.com> Cc: v6ops@ops.ietf.org Content-Transfer-Encoding: quoted-printable From: Fred Baker Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Tue, 16 Aug 2005 11:31:48 -0700 To: "Eric Klein" X-Mailer: Apple Mail (2.733) DKIM-Signature: a=rsa-sha1; q=dns; l=4813; t=1124216904; x=1124649104; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20I-D=20ACTION=3Adraft-baker-v6ops-end2end-00.txt=20| From:Fred=20Baker=20| Date:Tue,=2016=20Aug=202005=2011=3A31=3A48=20-0700| Content-Type:text/plain=3B=20charset=3DWINDOWS-1252=3B=20delsp=3Dyes=3B=20format=3Dfl owed| Content-Transfer-Encoding:quoted-printable; b=qGZDwIhEhkulIvx6IaWTEH7YPvQtcTkoooPATwvAwFaR3Oat/oidIIhjtW+WxeIlBhjNw4Xi uZH0xzwr0e120pn4VV/fGvHOVgnrUE8TlPMRiBbQ1E2dpLBi7gxokkev+zchMdMO/HkIW1lW8lt EDEGZ9No38vxN/h2nCVhoIck= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable On Aug 16, 2005, at 9:27 AM, Eric Klein wrote: > Fred, > > A few comments (mostly nits). > > 1. This is the first time I have seen a draft that refers to it's =20 > self as a > note ( in the abstract and introduction), this seems like the =20 > wrong word. Without taking the time to do a full investigation, I note that RFC =20 #10 opens with the phrase "This note is a revision of NWG/RFC #3", 8 =20 RFCs (997, 1020, 1062, 1117, 1150, 1244, 1311, and 1543) refer to the =20= RFC series as a "series of notes", that 623 RFCs contain the word =20 "note" on the first page (but I didn't check all of them to see =20 whether it was used as an adjective or as a verb), and that a related =20= series was once entitled the Internet Engineering Notes, or IENs. I dunno, what word would you suggest? Some documents refer to =20 themselves as "memos" or "memoranda"... :^) > 2. In the last sentence of section 2.1 it reads: > "IPv4, there is at minimum IPv4 connectivity", > I recommend it read: > "IPv4, there is at a minimum IPv4 connectivity" OK > 3. In the last sentence of section 3 it reads: > ' "A satisfactory solution", it could be said, "contains no =20 > unnecessary > complexity", and "first, does no harm." ' > > This seems a little confusing, as the one with first is second or =20 > last. It > may be confusing for non-native English speakers. I had rather hoped that these were obvious fractured quotes relating =20 to widely-held principles. I'm not finding it on the web at this =20 instant, but one of the various latin statements of Occam's Razor =20 that I have run across translates as "a satisfactory proposition =20 contains no unnecessary complexity". The Hippocratic Oath is often =20 quoted as the source of "First, do no harm"; the words are in fact =20 not found there, but might derive from a related work (also by =20 Hippocrates) called "Epidemics", or from another work by Galen. =20 Galen's words appear to have been "Primum non nocere". If you would like, I can remove the word "first", or directly quote =20 "Epedemics", which says "make a habit of two things=97to help, or at =20 least to do no harm". (punching "Occam's razor" and "Hippocratic Oath do no harm" into =20 google yields an instructive list of references, for those who are =20 interested) > 4. In section 3.1, in the third paragraph ("If the central IPv4 =20 > networks are > providing the"), is this referring to the backbone or =20 > interconnection points > (like the public MAE (east/west) Internet Exchange or any of the =20 > hundreds of > private ones)? Are there any drafts that talk about converting the =20 > backbones > or interconnection points to IPv6 using any of the methods used =20 > (tunnel > broker, etc) or are they all end network based (like Tredeo, etc). There are general comments on tunneling in: http://www.ietf.org/rfc/rfc2893.txt 2893 Transition Mechanisms for IPv6 Hosts and Routers. R. =20 Gilligan, E. Nordmark. August 2000. (Format: TXT=3D62731 bytes) (Obsoletes =20= RFC1933) (Status: PROPOSED STANDARD) and specific comments relating to ISP networks in: http://www.ietf.org/rfc/rfc4029.txt 4029 Scenarios and Analysis for Introducing IPv6 into ISP =20 Networks. M. Lind, V. Ksinant, S. Park, A. Baudot, P. Savola. March =20 2005. (Format: TXT=3D64388 bytes) (Status: INFORMATIONAL) The recommendation of the latter (section 3.2.2) is that the ISP run =20 a native dual stack internally (ie, route both IPv4 and IPv6 prefixes =20= using appropriate routing protocols, and forward both IPv4 and IPv6 =20 datagrams natively) and allow their customers to connect to that =20 (section 3.2.3) using IPv4 initially and IPv6 later as they come up. I can list a number of networks that have literally taken that =20 approach. I can list a number of others that have operational =20 concerns, and have chosen instead to run parallel IPv4 and IPv6 =20 networks internally, and either sell the customer separate IPv4 and =20 IPv6 connections or split the traffic into those networks from their =20 edge router. Perhaps half a dozen that I know of mention running an =20 IPv6-only core and tunneling their IPv4 traffic over it. I obviously =20 can't list my customers here, but if a network wants to identify =20 itself, this would be a good time to do so... I make the point in 2.1 =20= that these networks don't bother me: within a single administration, =20 they can make it operate correctly for themselves, their customers, =20 and their peers. What I *am* concerned about is the number of networks that are =20 telling me that they want to run IPv6-only at this early stage in the =20= transition, and the proposals being made for running IPv4 over those =20 IPv6 networks. DSTM is one example; there are other approaches being =20 discussed as well. In at least some cases, these are themselves =20 networks of networks - a central IPv6-only core operated by one =20 administration is tunneled by its customers (other administrations) =20 to deliver IPv4 service among them. Here, I get very worried very =20 quickly. While it will no doubt work well enough for those that are =20 members of the club, interconnection with anyone else is not =20 guaranteed. In other cases, I am being told by several networks that =20 they expect to have limited IPv4 requirements and expect their =20 supporting networks to make good things happen for them. However, =20 since I talk with all of them, I know that they are supporting =20 networks of each other, and can see that they aren't necessarily =20 providing the supporting services to each other. Again, I get very =20 worried very quickly. I really want to hear that they all will run native IPv4 and IPv6 =20 routing and forwarding at their edges (eg, running dual stack =20 networks), and not expect their customers to tunnel them. I really =20 and truly want to hear that.= From owner-v6ops@ops.ietf.org Tue Aug 16 15:01:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E56gl-0000HS-N2 for v6ops-archive@megatron.ietf.org; Tue, 16 Aug 2005 15:01: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 PAA28854 for ; Tue, 16 Aug 2005 15:01:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E56g0-000IH9-6r for v6ops-data@psg.com; Tue, 16 Aug 2005 19:00:44 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E56fv-000IGP-5A for v6ops@ops.ietf.org; Tue, 16 Aug 2005 19:00:39 +0000 Received: (qmail 30769 invoked by uid 417); 16 Aug 2005 19:00:37 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 16 Aug 2005 19:00:37 -0000 Received: from mehr ([132.70.222.174]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Tue, 16 Aug 2005 13:00:36 -0600 Message-ID: <004501c5a294$ccb4fd00$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> <9393DAD1-0794-4EE9-B779-0EA07B662A7C@cisco.com> Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Tue, 16 Aug 2005 22:00:39 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="WINDOWS-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id PAA28854 Fred Baker wrote: > > > > A few comments (mostly nits). > > > > 1. This is the first time I have seen a draft that refers to it's > > self as a > > note ( in the abstract and introduction), this seems like the > > wrong word. > > Without taking the time to do a full investigation, I note that RFC > #10 opens with the phrase "This note is a revision of NWG/RFC #3", 8 > RFCs (997, 1020, 1062, 1117, 1150, 1244, 1311, and 1543) refer to the > RFC series as a "series of notes", that 623 RFCs contain the word > "note" on the first page (but I didn't check all of them to see > whether it was used as an adjective or as a verb), and that a related > series was once entitled the Internet Engineering Notes, or IENs. > > I dunno, what word would you suggest? Some documents refer to > themselves as "memos" or "memoranda"... :^) Ok, I was thinking memo or document. > > 3. In the last sentence of section 3 it reads: > > ' "A satisfactory solution", it could be said, "contains no > > unnecessary > > complexity", and "first, does no harm." ' > > > > This seems a little confusing, as the one with first is second or > > last. It > > may be confusing for non-native English speakers. > > I had rather hoped that these were obvious fractured quotes relating > to widely-held principles. I'm not finding it on the web at this > instant, but one of the various latin statements of Occam's Razor > that I have run across translates as "a satisfactory proposition > contains no unnecessary complexity". The Hippocratic Oath is often > quoted as the source of "First, do no harm"; the words are in fact > not found there, but might derive from a related work (also by > Hippocrates) called "Epidemics", or from another work by Galen. > Galen's words appear to have been "Primum non nocere". > > If you would like, I can remove the word "first", or directly quote > "Epedemics", which says "make a habit of two things=97to help, or at > least to do no harm". > > (punching "Occam's razor" and "Hippocratic Oath do no harm" into > google yields an instructive list of references, for those who are > interested) > I agree with your ideas in principle, I was thinking more along the lines of: "A satisfactory solution", "first, does no harm" and "contains no unnecessary complexity." > > 4. In section 3.1, in the third paragraph ("If the central IPv4 > > networks are > > providing the"), is this referring to the backbone or > > interconnection points > > (like the public MAE (east/west) Internet Exchange or any of the > > hundreds of > > private ones)? Are there any drafts that talk about converting the > > backbones > > or interconnection points to IPv6 using any of the methods used > > (tunnel > > broker, etc) or are they all end network based (like Tredeo, etc). > > I can list a number of networks that have literally taken that > approach. I can list a number of others that have operational > concerns, and have chosen instead to run parallel IPv4 and IPv6 > networks internally, and either sell the customer separate IPv4 and > IPv6 connections or split the traffic into those networks from their > edge router. Perhaps half a dozen that I know of mention running an > IPv6-only core and tunneling their IPv4 traffic over it. I obviously > can't list my customers here, but if a network wants to identify > itself, this would be a good time to do so... I make the point in 2.1 > that these networks don't bother me: within a single administration, > they can make it operate correctly for themselves, their customers, > and their peers. > > What I *am* concerned about is the number of networks that are > telling me that they want to run IPv6-only at this early stage in the > transition, and the proposals being made for running IPv4 over those > IPv6 networks. DSTM is one example; there are other approaches being > discussed as well. In at least some cases, these are themselves > networks of networks - a central IPv6-only core operated by one > administration is tunneled by its customers (other administrations) > to deliver IPv4 service among them. Here, I get very worried very > quickly. While it will no doubt work well enough for those that are > members of the club, interconnection with anyone else is not > guaranteed. In other cases, I am being told by several networks that > they expect to have limited IPv4 requirements and expect their > supporting networks to make good things happen for them. However, > since I talk with all of them, I know that they are supporting > networks of each other, and can see that they aren't necessarily > providing the supporting services to each other. Again, I get very > worried very quickly. > > I really want to hear that they all will run native IPv4 and IPv6 > routing and forwarding at their edges (eg, running dual stack > networks), and not expect their customers to tunnel them. I really > and truly want to hear that. I know that there was some "madated" conversions being discussed a year o= r so ago (UK by 2008, Japan by 2010 etc - not sure about years for either) = so I was interested in seeing how these conversions would be affected by the plans (i.e. early adoption of IPv6 only) before they were ready. From owner-v6ops@ops.ietf.org Wed Aug 17 03:25:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5IIQ-0005CX-8P for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 03:25:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12020 for ; Wed, 17 Aug 2005 03:25:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5IFY-0000w8-DW for v6ops-data@psg.com; Wed, 17 Aug 2005 07:22:12 +0000 Received: from [193.252.22.29] (helo=smtp2.wanadoo.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5IFW-0000vi-RQ for v6ops@ops.ietf.org; Wed, 17 Aug 2005 07:22:11 +0000 Received: from me-wanadoo.net (unknown [127.0.0.1]) by mwinf0203.wanadoo.fr (SMTP Server) with ESMTP id 847EB1C001C8 for ; Wed, 17 Aug 2005 09:22:09 +0200 (CEST) Received: from [192.168.1.100] (APuteaux-153-1-48-73.w82-124.abo.wanadoo.fr [82.124.136.73]) by mwinf0203.wanadoo.fr (SMTP Server) with ESMTP id 8A6A21C001DD; Wed, 17 Aug 2005 09:22:08 +0200 (CEST) X-ME-UUID: 20050817072208567.8A6A21C001DD@mwinf0203.wanadoo.fr Message-ID: <4302E5A1.9090803@rd-iptech.com> Date: Wed, 17 Aug 2005 09:22:09 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Fred Baker Cc: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt References: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com> In-Reply-To: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com> Content-Type: multipart/alternative; boundary="------------080701060000000103050805" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,HTML_50_60, HTML_MESSAGE,HTML_TITLE_EMPTY autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------080701060000000103050805 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id DAA12020 Fred Baker wrote: > What I am concerned about is the proliferation of inconsistent =20 > strategies, and the set of cases I can come up with in which they do =20 > not work. That is the issue I am trying to raise. Hi Fred, I very much share the concern about end to end connectivity in the=20 complex configurations that are being built for the coexistence of IPv4=20 and IPv6 (Yref=20 http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.txt). Indeed this was the main reason for my I-D=20 http://www.ietf.org/internet-drafts/draft-despres-v6ops-transition-v5road= map-00.txt. After IETF63 in Paris I received about it this comment from Pekka=20 Nikander: =20 " It is very hard to evaluate its potential technical merit; that=20 would take far too much time. I would encourage you to write more=20 introduction, trying to present the ideas without going into too much=20 detail and without using too much new terminology." Here is an attempt at introducing the subject better. * During the v4-v6 coexistence period, there will inevitably be a mix of hosts, customer routers, and provider services having various mixes of coexistence tools. * Due to the highly combinatorial nature of the problem, analysing in all cases which connectivities are possible, along which routes, and using which encapsulations, seems beyond feasibility. * A simplified model would therefore be welcome if with it, for a well chosen set of standard coexistence functions in some hosts, edge routers and ISP gateways: o The above analysis would becomes tractable. o Extensive connectivity would be available, including for legacy v4-only and future v6-only hosts. o Selected routes and encapsulations would be optimum according to natural criteria. The purpose of the I-D was to introduce an approach toward such a=20 simplified model, covering in particular, but not only, IPvX networks=20 across IPvY networks (X and Y being v4, v6 or v4 + v6). =20 This model as it stands needs no new protocol. It only needs that: * a particular v6 address format be defined, upward compatible with all existing ones; * some code be added in those entities (hosts, customer edge routers, ISP gateways) which claim compatibility with the new address format. This code would have to be be carefully specified but, dealing with only a few simple concepts, would not be voluminous. It would maintain upward compatibility with all other existing coexistence tools. If some edge routers and ISP gateways supporting the address format=20 would be deployed, they would provide powerful v6 capabilities to=20 concerned customer sites, independently or in association with whatever=20 transition tools other sites and ISPs may have deployed. =20 Although the I-D is specific on a number of details (some of which are=20 still bugged - my apologies!), the current proposal is just a tentative=20 example of what could be worth standardizing to tame the beast. It already appears, after IETF-63 that, STUN and Teredo should be=20 integrated in some way in the model, and that the distinction between=20 mobile and fixed IPv4 services would advantageously be replaced by that=20 between global v4 address- and private v4 address- Wan services. (The=20 latter implies one or several layers of v4 NATs in the ISP infrastructure= ). Also, as you pointed out to me, the choice of "v5" to name an=20 intermediate status between v4 and v6 is unfortunate because of various=20 connotations. "vB" for example could be better, meaning (standardized)=20 Bistandard. (Not to be confused with Dual stack, which would refer to v4=20 and v6 side by side). Is it appropriate that a discussion on this work starts here ? I am not sure, but your contribution on the End to End Problem, and some=20 of the points made about DSTM, suggest it could be productive for IETF,=20 at leat as long as the LRW BOF hasn't led to a WG. Regards. =20 R=E9mi Despr=E9s --------------080701060000000103050805 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit

Fred Baker wrote:
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.

Hi Fred,

I very much share the concern about end to end connectivity in the complex configurations that are being built for the coexistence of IPv4 and IPv6 (Yref http://www.ietf.org/internet-drafts/draft-baker-v6ops-end2end-00.txt).

Indeed this was the main reason for my I-D http://www.ietf.org/internet-drafts/draft-despres-v6ops-transition-v5roadmap-00.txt.

After IETF63 in Paris I received about it this comment from Pekka Nikander:  

" It is  very hard to evaluate its potential technical merit; that would  take far too much time. I would encourage you to write more introduction, trying to  present the ideas without going into too much detail and without  using too much new terminology."

Here is an attempt at introducing the subject better.

  • During the v4-v6 coexistence period, there will inevitably be a mix of  hosts, customer routers, and provider services having various mixes of coexistence tools.
  • Due to the highly combinatorial nature of the problem, analysing in all cases which connectivities are possible, along which routes, and using which encapsulations, seems  beyond feasibility.
  • A simplified model would therefore be welcome if with it, for a well chosen set of standard coexistence functions in some hosts, edge routers and ISP gateways:
    • The above analysis would becomes tractable.
    • Extensive connectivity would be available, including for legacy v4-only and future v6-only hosts.
    • Selected routes and encapsulations would be optimum according to natural criteria.

The purpose of the I-D was to introduce an approach toward such a simplified model, covering in particular, but not only, IPvX networks across IPvY networks (X and Y being v4, v6 or v4 + v6).  

This model as it stands needs no new protocol. It only needs that:

  • a particular v6 address format be defined, upward compatible with all existing ones;
  • some code be added in those entities (hosts, customer edge routers, ISP gateways) which claim compatibility with the new address format. This code would have to be be carefully specified but, dealing with only a few simple concepts, would not be voluminous. It would maintain upward compatibility with all other existing coexistence tools.

If some edge routers and ISP gateways supporting the address format would be deployed, they would provide powerful v6 capabilities to concerned  customer sites, independently or in association with whatever transition tools other sites and ISPs may have deployed.  

Although the I-D is specific on a number of details (some of which are still bugged - my apologies!), the current proposal is just a tentative example of what could be worth standardizing to tame the beast.

It already appears, after IETF-63 that, STUN and Teredo should be integrated in some way in the model, and that the distinction between mobile and fixed IPv4 services would advantageously be replaced by that between global v4 address- and private v4 address- Wan services. (The latter implies one or several layers of v4 NATs in the ISP infrastructure).

Also, as you pointed out to me, the choice of "v5" to name an intermediate status between v4 and v6 is unfortunate because of various connotations. "vB" for example could be better, meaning (standardized) Bistandard. (Not to be confused with Dual stack, which would refer to v4 and v6 side by side).

Is it appropriate that a discussion on this work starts here ?
I am not sure, but your contribution on the End to End Problem, and some of the points made about  DSTM, suggest it could be productive for IETF, at leat as long as the LRW BOF hasn't led to a WG.

Regards.

 
Rémi Després
--------------080701060000000103050805-- From owner-v6ops@ops.ietf.org Wed Aug 17 04:05:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Ivp-0004ax-F7 for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 04:05:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13957 for ; Wed, 17 Aug 2005 04:05:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Iun-0005Rv-P6 for v6ops-data@psg.com; Wed, 17 Aug 2005 08:04:49 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Iuk-0005RP-KA for v6ops@ops.ietf.org; Wed, 17 Aug 2005 08:04:46 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j7H84EA24521; Wed, 17 Aug 2005 10:04:14 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j7H84ELS079516; Wed, 17 Aug 2005 10:04:14 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508170804.j7H84ELS079516@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-reply-to: Your message of Fri, 05 Aug 2005 22:47:18 +0300. Date: Wed, 17 Aug 2005 10:04:14 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: and in 8.4: DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the enterprise transition or deployment of IPv6-dominant network links is desired. DSTM is to being submitted as an IETF Experimental RFC. ==> as it is, DSTM is a way too overloaded a mechanism to be referred to without more disclaimers or description. => the overload (if any) should be solved by the references... As it is, different people use "DSTM" to mean at least the following things: => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI. a) v4-in-v6 tunnels b) automatically set-up v4-in-v6 tunnels => this (b-a) is DTI c) automatic set up of v4-in-v6 tunnels when the host doesn't have v4 address and an app wants to create a v4 socket => this (c-b) is AIIH d) automatic monitoring and tear-down of said v4-over-v6 tunnel when the host detects it no longer needs the address/connectivity => this (d-c) is an operational consequence of AIIH. e) plus a number of extensions for even more colorful setups. => I believe you mean DSTM+ a) doesn't require DSTM; => I agree, there are 3 kinds of tunnel interface: - static (the state is per interface) - dynamic (the state is in a table, one interface is enough to handle many tunnels. Note this is implementation) - algo (the state (end-point addresses) is taken from the packet (inner addresses). An example is 6to4) DTI is exactly the dynamic flavour and is needed in DSTM for scalable Tunnel End-Points. b) can be achieved using a tunnel broker; => this is both true and false: how the state is managed can be orthogonal to the tunnel interface itself. BTW the point is critical for the interoperability. c) does not require IETF interoperability (a local implementation choice when/how to launch the v4-in-v6 activation). => I don't understand your comment: the idea (AIIH) is more than useful when a global IPv4 address is required. PS: AIIH is the by-need allocation of an IPv4 address. d) could also be considered in the same category (there are no bits in the wire or anything requiring interoperability AFAICS on when the host removes the tunnel), though I'm skeptical whether even providing that would be a good engineering choice. => d is a consequence of the possible allocation of global IPv4 addresses and is managed exactly as DHCPv4 does. To compare with similar mechanisms, IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/... My point is that I'm having hard time figuring out: 1) what the document means when it's recommending DSTM, and => the references 2) based on my analysis above, I do not believe that DSTM (in the way that I think it's being referred to) is even needed. => DTI is needed as soon as the TEP has to be scalable, AIIH is needed as soon as global IPv4 addresses are needed. Note that extra capabilities should not be a problem, i.e., DSTM works well with static IPv4 addresses, and even when they are not needed they can bring some advantages, exactly as DHCPv4 can be used as a management tool where it only gives static addresses (aka BOOTP mode). Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Wed Aug 17 07:01:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Lg8-0005Nh-Uu for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 07:01:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21296 for ; Wed, 17 Aug 2005 07:01:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5Ldf-000Oa3-Fu for v6ops-data@psg.com; Wed, 17 Aug 2005 10:59:19 +0000 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5Ldb-000OZG-Gm for v6ops@ops.ietf.org; Wed, 17 Aug 2005 10:59:15 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 37177B5; Wed, 17 Aug 2005 20:25:34 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 17 Aug 2005 06:59:14 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Subject: RE: WGLC ent-analysis-03 Date: Wed, 17 Aug 2005 06:59:12 -0400 Message-ID: <936A4045C332714F975800409DE09240CCB2AB@tayexc14.americas.cpqcorp.net> Thread-Topic: WGLC ent-analysis-03 Thread-Index: AcWZ9y5I71AlBrtXRGKgzypA5/G+YQJISfLw From: "Bound, Jim" To: "Pekka Savola" , X-OriginalArrivalTime: 17 Aug 2005 10:59:14.0558 (UTC) FILETIME=[B4AC11E0:01C5A31A] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, Others are responding to DSTM below are comments on other points for the work.=20 > Thank you for additional "textual" discussion of the matrix. =20 > IMHO it is > very useful. While I am skeptic about the matrix approach,=20 > modifying that > goes beyond the point of diminishing returns. In general, I think the > document is in a very good shape, though Section 8 (which is a recent > addition) still requires wider review. Thanks. > 1) I still think appendix is a bit inappropriate for this document, > and it be removed from this doc. (I did not review it at length.) Authors feel it is important to keep and we have not seen any pain or issue within the working group keeping an appendix. =20 >=20 > 2) [see separate mail on app vs network-driven] Being responded to by others in the community and a few of the other authors. >=20 > 3) [see separate mail on DSTM] Yep. >=20 > 4) >=20 > 8.2 Recognizing Application incompatibilities > [...] >=20 > This leads us to the third theme represented by Scenario E and G, > i.e. incompatible applications communicating across a homogenous > network. Translation is an obvious solution, but not recommended > except for legacy devices at the network edge which cannot or never > will be upgraded to IPv6. A more scaleable solution would be to > use an Application Layer Gateways (ALG) between the incompatible > hosts. >=20 > =3D=3D> I don't understand this theme. In all scenarios from E=20 > to J, it seems > that the application version between the two endpoints is > different. Is this what you meant in the matrix? I fail to=20 > see how that > kind of situation can be addressed by tunneling. (I don't=20 > think that's what > you're implying, but rather that there are typos in the=20 > matrix or I don't > understand its basic assumptions.) We mean incompatible networks in the matrix we can word smith this yes. >=20 > 5) >=20 > Having IPv6 applications on a Dual-IP host on a v4-only network > lets you use ISATAP [ISTP] or Teredo [TRDO] to tunnel to a v6 end > service. ISATAP [ISTP] can be used to provide end node IPv6 > connectivity from nodes on an isolated IPv4 network, through the > use of automatic tunneling of IPv6 in IPv4. >=20 > Enterprise architects should consider providing a Tunnel Broker > [TBRK, TSPB] as a cost effective service to local users or > applications. Tunnel Brokers can be used to provide tunnel setup > for an enterprise using manual configured tunnels, 6to4, or DSTM. > Tunnel Brokers can automate the use of tunnels across an enterprise > deploying IPv6. >=20 > =3D=3D> I think these paragraphs provide a bit too little=20 > context. The first > paragraph also seems to introduce ISATAP and Teredo with=20 > different manner > compared to the tunnel broker. Here's my attempt at rewording: >=20 > Having IPv6 applications on a Dual-IP host on a v4-only network > requires some form of tunneling. Where configured tunnels [BCNF] > are not sufficient, a more automatic solution may be appropriate. > Typical solutions include a tunnel broker [TBRK, TSPB],=20 > ISATAP [ISTP], > or even Teredo [TRDO]. >=20 > (there is more analysis on the tradeoffs of the solutions=20 > later, so I don't > think it's necessary to do that here.) I don't have problem with this and will suggest to authors. thanks. One author does not believe TRDO should be used. >=20 > 6) >=20 > 11.1 Normative References >=20 >=20 > There are no normative references in this document to depict > correct protocol operation. This document is an analysis technical > effort not a operative or protocol specification. Personally I agree. Will discuss with authors. >=20 > =3D=3D> while the "Normative References" section is not meant to=20 > be normative in > that sense, in documents like this, it is typically intended=20 > to include > those documents which are: > 1) required to be understood for understanding this specification, > 2) are work-in-progress and significantly discussed, and the details > mentioned in this document could change before the other drafts > are complete, so we require that those docs must be published > as RFCs before this is published as an RFC, or > 3) other documents which are appropriate for understanding this one > which should be published as RFCs before this draft is done. >=20 > In that light, I'd suggest moving some documents over to the Normative > references: >=20 > BSCN, 6TO4, TRDO, BCNF (note, I'd also refer to=20 > draft-ietf-v6ops-mech-v2 > instead/in addition because it's replacing BCNF) Will discuss ok. >=20 > Moving these would not hurt: >=20 > CONF, DHCPF, DHCPL, 6TUN, TBRK, ALLOC >=20 > These might also be candidates for moving: >=20 > DNSV6, APPS, NAP, V6SEC, NATDE >=20 > These could probably be removed completely: >=20 > SEC1 (not referred), OSPF, BGP4, ISIS, RIPng Will discuss. > almost substantial > ------------------ >=20 > - The second column represents the IP-capability of the > host network wherein the node originated the packet. > (Host 1 Network) >=20 > =3D=3D> I'm sorry, but I'm still not 100% sure on what you mean here. > Do you mean: >=20 > a) "the network where the host plugs into" (i.e., the=20 > subnet), where the > enterprise might have different network elements, or Yes the above. >=20 > b) "the least common denominator in the whole enterprise network". >=20 > Let me try to take an example from scenario A: >=20 > | IPv6 | |Dual IP | | IPv6 | > A | ---- | IPv4 | or |Dual IP| ---- | > | Dual IP | | IPv4 | | Dual IP | >=20 >=20 > Could network 1 address this problem (if the service=20 > provider is dual-IP) > by configuring a manual tunnel from the host 1 to the=20 > enterprises border > router (assumption a) above) or some other component? (With=20 > interpretation > b) above, this wouldn't be possible because there wouldn't be any IPv6 > connectivity, v6-capable routers, etc. from the enterprise to=20 > the ISP.) >=20 > This is important point to get clarified, though it's not as=20 > critical as > before because the recommendations for solutions are no longer=20 > strongly tied to the scenarios. We can make this clearer I believe per your mail.=20 >=20 > ........ >=20 > If the number of nodes to be using IPv6 is reduced, another option > is to use statically configured tunnels. However automatically > configured tunnels are generally preferred. >=20 > =3D=3D> I'm not sure if I agree completely with this phrasing;=20 > I'd recommend > (unless other considerations are on the table, such as the > dynamicity/nomadicity of nodes/tunnels) using static tunnels=20 > when the number > of tunnels is low. I would suggest below (though I would not=20 > object to > spelling out the different tradeoffs further): >=20 > If the number of nodes to be using IPv6 is low, the first option > is to use statically configured tunnels. However, automatically > configured tunnels may be preferable especially if the number is > higher. Personally I like this wording and will suggest to authors. >=20 > ....... >=20 > A stateless configured node wishing to gain other configuration > information (e.g. DNS, NTP servers) will likely need a Stateful > DHCPv6 [DHCPv6] service available. >=20 > =3D=3D> I'm not sure if this is a typo or is I disagree: "other=20 > configuration" > can very well obtained from a _stateless_ DHCPv6 service. I=20 > think it's also > important to point out, somewhere, that you don't need to config v6 > infortmation (at least at start) if you don't want to. Suggest: >=20 > A stateless configured node wishing to gain other IPv6 configuration > information (e.g. DNS, NTP servers) will likely need at least > stateless DHCPv6 [DHCPL] service. In dual-IP networks,=20 > some enterprises > may also choose to only distribute configuration information using > DHCPv4. I think we disagree many enterprises mean they want to use stateless for addressing and use dhcpv6 stateful for all other parameters. The assumption because a node uses stateless for addresses and not use stateful for other configuration is invalid from our input of the users and operators in enterprises and most enterprises will not use stateless for initial deployment. >=20 > .... >=20 > 7.4.5 Security >=20 > =3D=3D> I think an important pointer to add at the end of this=20 > section would be > something like: >=20 > Specifically, the firewall policies must be configured=20 > appropriately > especially with regard to ICMPv6 [ICMPFIL]. Blocking all=20 > ICMP messages, > as has often been done with IPv4 with disastrous effects=20 > on, e.g., PMTUD, > must be avoided. >=20 > (where ICMPFIL could be an informative ref to elwyn and janos' draft.) We can discuss there are many many issues for security for any transition but this one may rise to the importance of stating. Will discuss. >=20 > .... >=20 > Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism to > develop a test network in the enterprise, but will not scale well > for a complete implementation of an IPv6 network. Manual Configured > Tunnels for IPv6 is an IETF Proposed Standard. >=20 > =3D=3D> I think this deserves more text on which scenarios or=20 > cases it doesn't > scale to be fair. For example, >=20 > Manual Configured Tunnels for IPv6 [BCNF] is a useful mechanism for > tunneling between network segments, but has scalability limitations if > applied to a large number of host-based tunnels, for example=20 > in scenarios A > or C. Manual Configured Tunnels for IPv6 is an IETF Proposed=20 > Standard. We want to keep this document small we will discuss it is a tradeoff and we assume the user reads RFC 4057. We relayed this to the WG at Minneapolis and had consensus we did not have to overstate comparisons as you suggest so we are following that consensus. >=20 > .... >=20 > 6to4 [6t4] is a useful tunneling mechanism for deployment if the > enterprise has not obtained a native IPv6 prefix from their > provider. 6to4 is an IETF Proposed Standard. >=20 > =3D=3D> while I don't have strong qualms with this text, I think=20 > it may mislead > the network admin to think 6to4 is a good replacement for a real IPv6 > prefix. It isn't, due to its unpredictability especially with "return > routing" scenarios. Therefore, I'd suggest adding a bit more=20 > warning here, > for example add "Due to the unpredicatability of "return=20 > path", it may not > be suitable for production use" as a second last paragraph. Yes and it also can be a security breach too by internal users entering the network who did not mean harm actually. >=20 > .... >=20 > NAT-PT [NATPT] can be useful when there is no other means to access > an IPv4 node behind a NAT network that only has a private address. > But, it is recommended that the enterprise also look at the ability > to provide access to that IPv4 node using a Proxy or Application > Layer Gateway as discussed in Section 8.3. NAT-PT is an IETF > Proposed Standard. >=20 > =3D=3D> please also refer to the applicability statement and=20 > state that it is > being reclassified to experimental. Will do. >=20 > ISATAP [ISTP] is a useful tunneling mechanism when the enterprise > has deployed IPv6, and there are particpating nodes for the IPv6 > deployment that exist on IPv4 networks. ISATAP is being submitted as > an IETF Experimental RFC. >=20 > =3D=3D> the last sentence is not pedantically correct, I believe; > RFCs that are submitted through the RFC-editor are not "IETF" > RFCs per se. I suggest: "ISATAP has been submitted as an individual > submission to the RFC editor for Experimenal RFC" or=20 > something like that. > (similar applies to the other mechanisms.) (also s/partic/partici/) This is correct good catch.=20 >=20 > .... >=20 > Tunnel Broker [TBRK, TSPB] is a useful tunneling mechanism, when the > Enterprise wants to automate the setup of tunnels in the enterprise, > and a tunnel broker can be used to support 6to4, ISATAP, and DSTM > mechanisms. Tunnel Broker set-up protocol is being submitted as an > IETF Experimental RFC. >=20 > =3D=3D> I believe at least TSP has considered "Informational"=20 > instead (at least > that's what Florent said). The base spec, AFAICS, does not=20 > include the > 6to4, ISATAP, and DSTM extensions, so I'd suggest removing=20 > that part of the > sentence. Just need to check with TBRK authors. We will review all the valid semi-editorial comments below they add value to the spec so thanks for those below. Thanks for your input, /jim > semi-editorial > -------------- >=20 > -- maybe still not clear enough what the 'host X network' means? >=20 >=20 > [In section 4.4.2.1] > In the widespread dual-IP scenario, a more structured, manageable > method is required, where the administrator has control of the > deployment per-link and (ideally) long-term, aggregatable global > IPv6 addressing is obtained, planned and used from the outset. >=20 > =3D=3D> I don't understand the relevance of v6 addressing to the = tunnel > discussion. Maybe some of this text should be removed or elaborated? > (If obtaining global addresses is/should be mentioned, it=20 > should probably be > done higher in the document hierarchy?; this is mentioned in=20 > 7.3 at least) >=20 > When the enterprise's users are off-site, and using an ISP that > does not support any native IPv6 service or IPv6 transition aids, > the enterprise may consider deploying it's own remote IPv6 access > support, as described in Section 7.5.2 below. >=20 > =3D=3D> there is no section 7.5.2 ..? >=20 > 5.1 Internal versus External Tunnel End Point >=20 > Let's assume the upstream provider has deployed some IPv6 services, > either native IPv6 in its backbone or in the access network, or > some combination of both (Scenario B of Table 1). [...] >=20 > =3D=3D> this has some very good text, but is this (enterprise has=20 > no v6 infra) > on the borderline of being out-of-scope, wrt. the paragraph in Intro: >=20 > We are also assuming that the enterprise deployment is one being > undertaken by the network administration team, i.e. this document > is not discussing the case of an individual user gaining IPv6 > connectivity (to some external IPv6 provider) from within an > enterprise network. [...] >=20 > (these two cases are, at least from the ISP's perspectively,=20 > apparently > pretty close to equivalent..) So, I'm not sure whether=20 > changes or further > applicability text would be useful. I think the external tunnel point > discussion may also apply to Scenario F and some others (e.g., if your > business partner would want to use v6 application to reach=20 > your v6 app, but > you'd have to provide a tunnel to him. >=20 > ..... >=20 > For internal routing, an appropriate interior routing protocol may > be deployed. IPv6 routing protocols that can be used are as > follows: BGP4+ [BGP4], IS-IS [ISIS], OSPFv3 [OSPF] and RIPng > [RIPng]. >=20 > =3D=3D> maybe a more informative way for the reader would be to=20 > point to the ISP > analysis on the routing protocol selection (the only=20 > difference here is that > RIPng may be a bit more applicable in enterprise networks,=20 > but I'm not sure > whether that is worth mentioning), for example: >=20 > For internal routing, an appropriate interior routing protocol may > be deployed. The routing protocol selection and the tradeoffs > have been discussed in Section X of [ISPA], also applicable here. >=20 > .... >=20 >=20 > ... >=20 > Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; > there is support for DHCPv6 to assign privacy addresses to nodes in > managed environments. >=20 > =3D=3D> I'd say more briefly and less controversially: >=20 > Hosts may also generate or request IPv6 Privacy Addresses [PRIVv6]; > there is also support for DHCPv6 to assign privacy addresses. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > editorial > --------- >=20 > The audience for this document is the enterprise network team > considering deployment of IPv6. The document will be useful for > enterprise teams that will have to determine the IPv6 transition > strategy for their enterprise. >=20 > =3D=3D> isn't this saying almost the same thing twice? maybe=20 > slight reword. >=20 > - Requirements or Transtion at the Providers network >=20 > =3D=3D> s/Trans/Transi/ (this seems a bit obvious as well,=20 > because this is an > enterprise doc, not provider doc..) >=20 > We are also assuming that the enterprise deployment is one being > undertaken by the network administration team, i.e. this document >=20 > =3D=3D> remove "one" ? >=20 > enterprise. In sectioin 7 we discuss general issues and >=20 > =3D=3D> s/sectioin/section/ >=20 > The notional enterprise network is comprised of hosts attached to >=20 > =3D=3D> do you mean "notational" with notional or something else? > (many instances of this) >=20 > Obviously Table 1 does not describe every possible scenario. > Trivial notional networks (such as pure IPv4, pure IPv6, and > ubiquitous Dual-IP) are not addressed. However, the authors feel > these ten represent the vast majority of transitional situations > likely to be encountered in today's enterprise. Therefore, we will > use these ten to address the analysis for enterprise deployment. >=20 > =3D=3D> this seems to overlap with an earlier (and more fleshed=20 > out) paragraph > starting with "Addressing every possible combination of network > IP-capability in this notional enterprise network is=20 > impractical, [...]". > I'd suggest some combining to remove the overlap. >=20 > use IPv6 applications, but has yet to transition its internal > networks and it's Service Provider also lags, offering only a v4 > IP-service. >=20 > =3D=3D> s/it's/its/ (the same in a couple of other places) >=20 > Consider the situation where there exists IPv6 edge routers which > are IPv6-capable, while others,and perhaps the enterprise backbone >=20 > =3D=3D> s/,and/, and/ >=20 > There is a need for end-to-end communication with IPv6, but the > infrastructure only supports IPv4 routing. Thus, the only viable > method for end-to-end communication with IPv6 is to tunnel the > traffic over the existing IPv4 infrastructure, within this analysis > documents boundaries defined. >=20 > =3D=3D> I'm not sure if I understand the last part of the last = sentence, > starting from "within ...". Maybe slight reword? >=20 > IPv6-dominant network, except if required at to support edge IPv4 > networks. >=20 > =3D=3D> remove "at" ? >=20 > In each case, communicating with an IPv4 end host or over an IPv4 > network requires a transition point exist within the network to > support that operation. >=20 > =3D=3D> s/a transition point exist/that a transition point exists/ > or s/exist/to exist/ ? >=20 > network must aquire an IPv4 address (to interoperate with the IPv4 >=20 > =3D=3D> s/aquire/acquire/ >=20 > IPv6 Privacy Extensions, end-to-end IPSEC, and, not least, the use >=20 > =3D=3D> s/IPSEC/IPsec/ >=20 > this mechanism provides no automated tunnnel configuration. >=20 > =3D=3D> s/tunnnel/tunnel/ >=20 > driven by the position of the incompatible touchpoint. If a local > network is incompatible than host tunneling is appropriate. If the >=20 > =3D=3D> s/than/then/ >=20 > service both IPv4 and IPv6 data streams that are simulataneously >=20 > =3D=3D> s/simulataneously/simultaneously/ >=20 > The following transition mechanism have at least two independent >=20 > =3D=3D> s/mechanism/mechanisms/ >=20 > --=20 > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings >=20 >=20 From owner-v6ops@ops.ietf.org Wed Aug 17 10:24:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Opo-00048u-Um for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 10:24:07 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04028 for ; Wed, 17 Aug 2005 10:24:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5One-000NXz-4L for v6ops-data@psg.com; Wed, 17 Aug 2005 14:21:50 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5Onb-000NXi-WC for v6ops@ops.ietf.org; Wed, 17 Aug 2005 14:21:48 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7HELkqA027994 for ; Wed, 17 Aug 2005 15:21:46 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA11518 for ; Wed, 17 Aug 2005 15:20:34 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7HEKYl19364 for v6ops@ops.ietf.org; Wed, 17 Aug 2005 15:20:34 +0100 Date: Wed, 17 Aug 2005 15:20:34 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Message-ID: <20050817142034.GU22435@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> <9393DAD1-0794-4EE9-B779-0EA07B662A7C@cisco.com> <004501c5a294$ccb4fd00$0401a8c0@mtc.ki.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004501c5a294$ccb4fd00$0401a8c0@mtc.ki.se> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 16, 2005 at 10:00:39PM +0300, Eric Klein wrote: > > I know that there was some "madated" conversions being discussed a year or > so ago (UK by 2008, Japan by 2010 etc - not sure about years for either) so > I was interested in seeing how these conversions would be affected by the > plans (i.e. early adoption of IPv6 only) before they were ready. UK by 2008? Hmmm. s/K/S?? :) -- Tim/::1 From owner-v6ops@ops.ietf.org Wed Aug 17 17:58:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5Vvs-0004mz-7A for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 17:58:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04602 for ; Wed, 17 Aug 2005 17:58:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5VsY-000J7d-0o for v6ops-data@psg.com; Wed, 17 Aug 2005 21:55:22 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5VsW-000J7H-Ay for v6ops@ops.ietf.org; Wed, 17 Aug 2005 21:55:20 +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 OAA09656 for ; Wed, 17 Aug 2005 14:55:19 -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 j7HLtIv20226 for ; Wed, 17 Aug 2005 16:55:19 -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.211); Wed, 17 Aug 2005 14:55:14 -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: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Date: Wed, 17 Aug 2005 14:55:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FC6@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Thread-Index: AcWjOq66xY2/EK6JQSyw7Tzzx4UE4QAOdbug From: "Templin, Fred L" To: X-OriginalArrivalTime: 17 Aug 2005 21:55:14.0585 (UTC) FILETIME=[59139090:01C5A376] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable A new draft of possible interest to v6ops is available that anticipates MTU-related performance issues for tunnels and proposes a solution. Document location and abstract appear below. Comments? Fred fred.l.templin@boeing.com http://www.ietf.org/internet-drafts/draft-templin-linkadapt-00.txt Abstract IPv6-in-IPv4 tunneling mechanisms support the minimum IPv6 MTU of 1280 bytes via static prearrangements at the tunnel encapsulator and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document proposes a new MTU determination mechanism for IPv6-in-IPv4 tunnels that uses a link adaptation scheme with simplified IPv4 segmentation/reassembly and dynamic segment size probing. From owner-v6ops@ops.ietf.org Wed Aug 17 23:32:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5b8i-0007E9-B9 for v6ops-archive@megatron.ietf.org; Wed, 17 Aug 2005 23:32: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 XAA23381 for ; Wed, 17 Aug 2005 23:32:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5b6W-000PYD-5w for v6ops-data@psg.com; Thu, 18 Aug 2005 03:30:08 +0000 Received: from [203.103.165.130] (helo=smta09.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5b6T-000PVm-Ny for v6ops@ops.ietf.org; Thu, 18 Aug 2005 03:30:06 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta09.mail.ozemail.net with ESMTP id <20050818033003.BWIQ20009.smta09.mail.ozemail.net@ubu.nosense.org>; Thu, 18 Aug 2005 03:30:03 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 174D72F5D7; Thu, 18 Aug 2005 13:00:07 +0930 (CST) Date: Thu, 18 Aug 2005 13:00:06 +0930 From: Mark Smith To: "Templin, Fred L" Cc: v6ops@ops.ietf.org Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Message-Id: <20050818130006.4e18db33.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FC6@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FC6@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, On Wed, 17 Aug 2005 14:55:14 -0700 "Templin, Fred L" wrote: > A new draft of possible interest to v6ops is available > that anticipates MTU-related performance issues for > tunnels and proposes a solution. Document location > and abstract appear below. Comments? > I've had a quick read through. I'm a bit confused by this text : " Implementations MUST configure a minimum per-tunnel interface LinkMTU of 1280 bytes and SHOULD provide a configuration knob to set larger values. A maximum LinkMTU of 9180 bytes (i.e., the same as defined in [RFC1626]) is RECOMMENDED for normal use cases, since it is large enough to encode 8KB network filesystem blocks and take advantage of Gigabit Ethernet Jumbo Frames, yet not so large as to diminsh the effectiveness of 32-bit link layer CRCs [GIGE]. Implementations MAY set even larger LinkMTU values, but are advised that this may lead to unacceptable levels of undetected errors unless all physical segments in the path can provide assured error-free deliverey for large packets." I read it as saying that the initial tunnel MTU, by default, should always be 1280 bytes. However, I think the first part of the next sentence, "A maximum LinkMTU of 9180 bytes (i.e., the same as defined in [RFC1626]) is RECOMMENDED for normal use cases" could possibly be taken to be a statement that for "normal use cases" (which is commonly the "default"), the initial tunnel MTU should be 9180 bytes. The reason that I ask is that if I understand the tunnel MTU probing mechanism in this ID, it relies on the upper layer protocol generating TPDUs that are larger than the current tunnel MTU value. If the upper layer protocol was TCP, it would set it's MSS option to be the current tunnel MTU minus the IPv6 header size. If the initial tunnel MTU is 1280 bytes, as per the first sentence in the above text, and the TCP end points were on the same nodes as the tunnel end points (for example), the MSS value for each end point would be set to 1280 minus 40 bytes for the IPv6 header or 1240 bytes. From that point onwards, the TCP end points would never send a segment larger than the MSS, and therefore never generate a IPv6 packet larger than 1280 bytes or a IPv4 packet larger than 1300 bytes. If the IPv4 path MTU between the two tunnel end points was 1500 bytes, which I think is probably the case for most of the Internet, I don't think the probe mechanism in this ID would ever discover that and then be able to utilise it. TCP or other transport layer protocols would never indirectly attempt to push the tunnel MTU above what the local tunnel interface MTU is set to, and if that is initially 1280 bytes, then I think the tunnel MTU would never increase beyond that value. Rather than the initial MTU being set to 1280 bytes, maybe it should be set to a value that is derived from the common IPv4 path MTUs in the Internet e.g 1500 - 20 bytes or 1480 bytes. This would allow today's common IPv4 path MTU to be taken advantage of by this ID, yet avoid the amount of fragmentation an initial tunnel MTU of 9180 bytes would cause and the associated time it would take for PMTUD to resolve down to today's common IPv4 path MTU. PMTUD and the mechanisms in this draft would cope with IPv4 paths between tunnel end points that have a smaller MTU than the assumed, common, 1500 bytes. If this common IPv4 path MTU figure changes in the future, then the RFC could be updated by a later RFC with an increased initial tunnel MTU recommendation. HTH, Mark. From owner-v6ops@ops.ietf.org Thu Aug 18 04:10:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fUE-00023u-Hb for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 04:10: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 EAA18384 for ; Thu, 18 Aug 2005 04:10:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5fQ7-000Pkq-N1 for v6ops-data@psg.com; Thu, 18 Aug 2005 08:06:39 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5fQ5-000PkO-9i for v6ops@ops.ietf.org; Thu, 18 Aug 2005 08:06:37 +0000 Received: (qmail 642 invoked by uid 417); 18 Aug 2005 08:06:35 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 08:06:35 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 02:06:33 -0600 Message-ID: <014c01c5a3cb$95150b00$0401a8c0@mtc.ki.se> From: "Eric Klein" To: "Tim Chown" , v6ops@ops.ietf.org References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> <9393DAD1-0794-4EE9-B779-0EA07B662A7C@cisco.com> <004501c5a294$ccb4fd00$0401a8c0@mtc.ki.se> <20050817142034.GU22435@login.ecs.soton.ac.uk> Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Thu, 18 Aug 2005 11:04:57 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > > > > I know that there was some "madated" conversions being discussed a year or > > so ago (UK by 2008, Japan by 2010 etc - not sure about years for either) so > > I was interested in seeing how these conversions would be affected by the > > plans (i.e. early adoption of IPv6 only) before they were ready. > > UK by 2008? Hmmm. s/K/S?? :) As I was saying, the dates were from memory, if you have better information I would love to hear about it. Especially in any country where the government has put their 2 cents in about by when the conversion should (must?) be completed. Eric From VIYKMYBSTXH@yahoo.com Thu Aug 18 04:14:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXr-00031d-Gs; Thu, 18 Aug 2005 04:14:39 -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 EAA18586; Thu, 18 Aug 2005 04:14:37 -0400 (EDT) Received: from [63.224.70.149] (helo=SCHDIMENSION) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1E5g7X-00088d-8I; Thu, 18 Aug 2005 04:51:33 -0400 Received: from . ...es ([83.22.90.160] helo=.mail.desty.org) by smtp4.desty.org with esmtp id 2A502j-0431FN-00; Thu, 18 Aug 2005 11:12:32 +0200 Message-Id: Sender: VIYKMYBSTXH@yahoo.com Date: Thu, 18 Aug 2005 02:07:32 -0700 In-Reply-To: Your message of "Thu, 18 Aug 2005 04:09:32 -0500." <20031002150239.GG32185@asuka.tech.sitadelle.com> From: "Cathryn Kincaid" To: smime-archive@ietf.org Subject: Wow...Shiny Teeth YSJTTY X-Spam-Score: 1.1 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 The revolution "Whitelight" teeth whitening which guarantees: - Fast Results and easy to use - works great against all sorts of stains (coffee, smoking) - Boost your confidence with great white smile - Used by dentist and millions worldwide - Satisfaction Guarantees...NO Risk! Why waiting? Check us out! http://e-globalproducts.info/wlr 1o From nsis-bounces@ietf.org Thu Aug 18 04:14:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXd-00030E-6v; Thu, 18 Aug 2005 04:14:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fXb-000301-27 for nsis@megatron.ietf.org; Thu, 18 Aug 2005 04:14:23 -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 EAA18569 for ; Thu, 18 Aug 2005 04:14:21 -0400 (EDT) Received: from thoth.sbs.de ([192.35.17.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E5g7H-00088c-VR for nsis@ietf.org; Thu, 18 Aug 2005 04:51:17 -0400 Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j7I8EEZr004250; Thu, 18 Aug 2005 10:14:14 +0200 Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net [139.25.165.42]) by mail1.siemens.de (8.12.6/8.12.6) with ESMTP id j7I8EE8x014543; Thu, 18 Aug 2005 10:14:14 +0200 Received: from blns00fa.ww002.siemens.net ([147.54.45.102]) by mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211); Thu, 18 Aug 2005 10:12:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Date: Thu, 18 Aug 2005 10:14:13 +0200 Message-ID: <391E6FBF5E786940B9E2F7CA6376C7086C1656@blns00fa.ww002.siemens.net> Thread-Topic: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Thread-Index: AcWd3C0rfXniEI+ZScaG5v9vZ62C3AFJR4nwABQVUxAAHrH4MA== From: "Kappler, Cornelia" To: "Roy, Radhika \(AEAD\)" X-OriginalArrivalTime: 18 Aug 2005 08:12:49.0843 (UTC) FILETIME=[9FBB3830:01C5A3CC] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9404aa2ccc871248c2288463bebdd6b9 Cc: nsis@ietf.org X-BeenThere: nsis@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Next Steps in Signaling List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1716882481==" Sender: nsis-bounces@ietf.org Errors-To: nsis-bounces@ietf.org This is a multi-part message in MIME format. --===============1716882481== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A3CC.D16E5E9C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A3CC.D16E5E9C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Radhika,=20 =20 frankly, I dont see the point of your questions, and my impression is nor does anybody else. Rather than taking a lot of time trying to explain (again) everything I'd like to quote rough working group consensus that the QSPEC is ok the way it is.=20 =20 Cornelia -----Original Message----- From: Roy, Radhika (AEAD) [mailto:RoyR@saic-abingdon.com]=20 Sent: Mittwoch, 17. August 2005 20:17 To: Kappler, Cornelia Cc: Tseno Tsenov; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters =09 =09 Cornelia: In response to one of Tseno's questions, you have mentioned as follows: ".. accommodate as many QoS Models as possible .." In fact, it is NOT true. Even the QOS model like Y.1541 that has been trying to be accommodated fully in the draft has been failed. Please see the following draft:=20 =09 http://www.ietf.org/internet-drafts/draft-ietf-nsis-y1541-qosm-00.txt =20 The above draft shows that more extensions in QSPEC template are needed. The basic question is this: Why do you want to include the QOS model-specific extensions in the "generalized" QSPEC template draft? What you have done is this: Included Y1541 QOS model (which is also incomplete) and DSTE QOS model (a cheap shot - basically only one parameter).=20 Tseno has mentioned the most fundamental QOS models of the IETF: IntServ and DiffServ. You have failed to explain why you have not included those in the draft. What do you mean that you have accommodated as many QOS models as possible? Why do you NOT "delete" all so-called QOS model-specific extensions from this draft? The way you should proceed is as follows: 1. Make the draft-ietf-nsis-y1541-qosm-00.txt complete including "all" extensions QSPEC specific to y1541using all "specific values." Also, show how to create y1541 domains using specific values without contradicting the end-to-end values from end users' and/or applications' point of view so that people can implement without creating any confusions or contradictions. 2. Do the same writing another draft for DSTE model as explained in item 1.=20 3. Delete all QOS model-specific extensions in the generalized QSPEC draft.=20 In this way, all drafts will be clean. If you have any questions, please let us know. Best regards, Radhika PS: I also explained in earlier emails (John L. also agreed) that the use of both generalized QSPEC template and QOS model-specific QSPEC template will create contradictions if domains are not created carefully. The present QSPEC draft does not explain how to create respective QOS domains using specific values in the first place. -----Original Message----- From: nsis-bounces@ietf.org [mailto:nsis-bounces@ietf.org] On Behalf Of Kappler, Cornelia Sent: Wednesday, August 17, 2005 4:22 AM To: Tseno Tsenov; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org Subject: RE: [NSIS] QSPEC extensibility and re-use of multiple instances of defined parameters Hi Tseno - and John and Jerry,=20 so there doesnt seem to be much concrete use for this additional kind of extensibility. Therefore my suggestion is to not support it.=20 Regarding your (Tseno) 2nd paragraph:=20 In the QSPEC we tried to balance two mutually exclusive requirements - accommodate as many QoS Models as possible - make the QSPEC as widely understood as possible without defining too many parameters.=20 We solved this problem by defining mandatory parameters which we expect to be used in most QOSMs (e.g. bandwidth); and by requesting all QNEs to _understand_ the mandatory parameters. That is, for a QOSM that has no use of the mandatory parameters (which is quite unlikely by the way) these parameters _dont need to be included_ in the QSPEC. However this makes it unlikely that this QSPEC will be understood outside the domain of this QOSM.=20 I guess we have to explain this better in our document as this is not the first time somebody (particularly someone really familiar with NSIS) didn't really get the idea. Cornelia > -----Original Message----- > From: Tseno Tsenov [mailto:tseno.tsenov@mytum.de]=20 > Sent: Mittwoch, 10. August 2005 20:30 > To: Kappler, Cornelia; Ash, Gerald R (Jerry), ALABS; nsis@ietf.org > Subject: Re: [NSIS] QSPEC extensibility and re-use of=20 > multiple instances ofdefined parameters >=20 >=20 > Hi Cornelia, >=20 > I agree that currently there might be no QoS model that uses=20 > multiple values > of one QoS parameter (except the DiffServ case). However the current > encoding approach restricts the extensibility of the QSPEC. >=20 > Your example with usage of two different QoS classes which=20 > are mandatory > parameters (and are redundant in some sense) raises other=20 > question for me: > Again, we have a new QoS model does not use any of the mandatory QSPEC > parameters and defines its own set of optional QSPEC=20 > parameters. Then, is it > expected that some mandatory QSPEC parameters will be "artificially" > included which will provide From owner-v6ops@ops.ietf.org Thu Aug 18 04:30:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5fmm-000760-Sj for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 04:30: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 EAA19312 for ; Thu, 18 Aug 2005 04:30:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5flN-0001x4-7H for v6ops-data@psg.com; Thu, 18 Aug 2005 08:28:37 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5flM-0001wp-Fa for v6ops@ops.ietf.org; Thu, 18 Aug 2005 08:28:36 +0000 Received: (qmail 8602 invoked by uid 417); 18 Aug 2005 08:28:35 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 08:28:35 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 02:28:33 -0600 Message-ID: <015201c5a3ce$a6c44c00$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <6136391C-CBD7-499C-9421-EB968DAE98FF@ietf.org> <000d01c5a27f$5b802c00$0401a8c0@mtc.ki.se> <9393DAD1-0794-4EE9-B779-0EA07B662A7C@cisco.com> <004501c5a294$ccb4fd00$0401a8c0@mtc.ki.se> <20050817142034.GU22435@login.ecs.soton.ac.uk> <014c01c5a3cb$95150b00$0401a8c0@mtc.ki.se> Subject: Madated adoption? Date: Thu, 18 Aug 2005 11:27:12 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Based on my memory (and comments about I-D ACTION:draft-baker-v6ops-end2end-00.txt ) Tim Chown seemed surprised that I had heard that there was a mandated adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure about years for either). Now this WG had a conversation thread a little over a year ago where these came up. I was wondering if anyone knew if their (or other) countries had announced compliance dates for the full IPv6 conversions. The truth is that this has dual interest to me, as we as a WG should know what the world (or at least individual nations) are doing or saying about IPv6. But this is also related to a thesis that I am working on and I am interested to see what is being done towards actual adoption at the national levels. Eric From owner-v6ops@ops.ietf.org Thu Aug 18 05:02:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5gIW-000542-J0 for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 05:02: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 FAA20767 for ; Thu, 18 Aug 2005 05:02:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5gGy-0005IP-QS for v6ops-data@psg.com; Thu, 18 Aug 2005 09:01:16 +0000 Received: from [203.103.165.80] (helo=smta04.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5gGv-0005Hx-2g for v6ops@ops.ietf.org; Thu, 18 Aug 2005 09:01:13 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta04.mail.ozemail.net with ESMTP id <20050818090104.UNTT10374.smta04.mail.ozemail.net@ubu.nosense.org> for ; Thu, 18 Aug 2005 09:01:04 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 5254B2F5D7 for ; Thu, 18 Aug 2005 18:31:09 +0930 (CST) Date: Thu, 18 Aug 2005 18:31:09 +0930 From: Mark Smith To: v6ops@ops.ietf.org Subject: Re: Last call on draft-ietf-v6ops-nap-01.txt Message-Id: <20050818183109.58577411.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> References: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Everybody, On Fri, 5 Aug 2005 07:08:20 +0200 Fred Baker wrote: > With this note, I am opening a working group last call on draft-ietf- > v6ops-nap-01.txt. This WGLC will close in two weeks, at close of > business 19 July. Please read the document and comment to the list - > either say that the document is ready, or say what issues you may > have with it. > > Thanks. > Some comments. Mostly editorial / readability related, nothing really that significant I think. Got a bit long unfortunately. I was reading and commenting at the same time. I'm aware of and agree with the the points that were in the IETF63 presentation, so I haven't commented on them. 2.2 Simple security due to stateful filter implementation "What a firewall does is prevent a network administration from having to pay for bandwidth to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary." I'm not sure that bandwidth concerns (presumably caused by the threat of DoS style attacks) are the main reasons why people put firewalls in. Rather, I think in most cases it would be the other way around - people put firewalls in to control the types of traffic that can enter or leave their network, and the reduction in unwanted traffic because of that control is a beneficial side effect. Possibly this text could be rephrased or expanded on, mostly only because it appears to be making an absolute statement of what a firewall is used for, and I don't think unwanted traffic volume reduction is necessarily always the reason. "For these reasons the sense of security provided by NAT are actually false." I'd think it would be better to say something along the following lines, as NAT does provide some security, just as not as much as most people think - "For these reasons the actual level of security provided by NAT can be significantly less than commonly perceived." "The perceived security comes from the lack of pre-established or permanent mapping state." I suggest extending this statement - "The perceived security comes from the lack of pre-established or permanent mapping state, which is only guaranteed to occur when the Network Address Port Translation (NAPT) form of NAT is used." "... however when the merging networks were already using address translation it will create huge problems due to admistrative difficulties of the merged address space." I'm a bit confused by this text. Is the "address translation" being referred to being used towards the Internet, not the address translation that has temporarily been put in place between the two organisations ? I.e. the two organisations are each using 10/8, and have NAT boxes at their Internet connections. They then want to connect together, also using (two instances) of NAT, to make the "other" 10/8 appear to be some other, non-local address space. Assuming that one of the 10/8s is renumbered, and NAT between the organisation is removed, is the "address translation" above referring to the remaining Internet NAT ? 3.3 DHCPv6 prefix delegation At the moment, this section describes what the Prefix Delegation function does, however I don't think it really connects it with the NAT function it is substituting for, namely the ability to just plug a NA(PT) box in and have access to the Internet work straight away. I think a small amount of text exanding that description would be helpful, similar to the first paragraphs of " 3.1 Privacy addresses (RFC 3041)" and "3.2 Unique Local Addresses". 3.4 Untraceable IPv6 addresses I think this section / feature might be misnamed. These addresses aren't completely untraceable, rather, they are only traceable to to the edge of the network assigned the /48. A better description or name might be "Hidden Internal Topology IPv6 addresses". Or maybe not :-) "Opaque Subnet IPv6 Addresses" ? Anyway, something that doesn't suggest that they're completely untraceable. I also think that the last paragraph would be better positioned as the first in this section. I think the statement, "These should be globally routable IPv6 addresses which can be randomly and independently assigned to IPv6 devices." could be a bit more descriptive by adding ", within the internal topology." I think this also further makes it clear that this untraceability property extends to the whole of the Internet. 4.2 IPv6 and Simple security Very minor, "::/64" should probably be "(/64)" eg. "3. The size of the typical subnet (/64) will make a network ping" I realise a few of the authors probably have English as their second language, so I'm guessing this isn't intentional : "This simple rule would create similar protection and security holes the typical IPv4 NAT device will offer ..." This made me chuckle a bit when I first read it, as to a first language English speaker, it reads like the security holes of a typical IPv4 NAT device are something worth aiming for, as though they are good features. Unfortunately some native English speakers who might not be aware of NAT's limitations and may be becoming aware of them via this draft may also read it that using IPv6 in this way is also "as bad as NAT". I'd suggest dropping the "and security holes" : "This simple rule would create similar protection the typical IPv4 NAT device will offer ..." Actually, it may be best to qualify the type of NAT being used. In this section it is only really NAPT that is guaranteed to provide this style of "reflexive" protection. 4.3 User/Application tracking "IPv6 enables the collection of information about data flows." I'm not really sure that IPv6 "enables" it, in the sense that it is a feature of IPv6. Proper end-to-end, visible addressing does facilitate it, although it would either require a host based reporting mechanism, or the insertion of more than just a router e.g. a firewall in line with the traffic flows. I'd suggest slighly refocusing this section to state that assigning and making visible (ie. not NATting them) unique IPv6 end-node addresses can facilitate User/Application tracking, but also make it clear that an additional device or service needs to be added to do that as it is not an inherent feature of IPv6. While I understand the purpose of this section regarding matching a possible use of NAT, it reads a bit too pro-privacy intrusion to me, although that may be a personal value judgment rather than something that needs to be changed in the RFC. It also may be worth adding that Privacy Addresses and IPsec, which _are_ standard features of IPv6, may limit or prevent the ability to perform User / Application tracking, at least by network located devices. (hmm, these days it seems, I keep coming across examples of where things are best done at the ends or on the hosts, this being another one.) 4.4 Privacy and topology hiding using IPv6 Along the lines of using Mobile IPv6, another possibly simpler solution, assuming the administrator is willing to wear the administrative overhead, would be to have hosts act as end-points to statically configured IPv6 in IPv6 or GRE tunnels. I'm not sure how widely implemented Mobile IPv6 is, I know that most IPv6 capable OSes would support this manually configured tunnel method today. 4.5 Independent control of addressing in a private network Sort of minor : " ... and may shrink/grow these as their network user base/etc changes. In v6, it's all /64." conflicts a bit with "3. The size of the typical subnet ::/64 will make a network ping" in "4.2 IPv6 and Simple security" I say "sort of" minor because I think it is necessary to either have the RFC take the position that all IPv6 subnets will be /64s (making the first quote above correct), or take the position that most subnets, but not all, will be /64s. I'm also a bit conscious of this point as I recently saw some IPv6 addressing discussion on the nanog mailing list. I read that somebody was considering allocating out something like /124s to their residential customers, because they couldn't see a need for a customer to connect more than 16 devices to their home LAN. The point that person has missed is that the /64 is a /64 not because it needs to be, rather, it is convenient for it to be, similar to 802.1 MAC addresses being 48 bits in size for convenience rather than necessity. This "give customers _only_ what (I think) they need" mentality is certainly quite understandable for IPv4. It obviously mostly isn't in IPv6. It's possibly out of scope for this RFC, although I think it could be argued that IPv6 Network Architecture Protection could include ensuring that features such as privacy addresses, or easy renumbering of the network without having to renumber subnets is a architectual property of IPv6 that should be preserved, by avoiding naive address allocation methods. Possibly specifying some rules or strong guidelines regarding what prefix lengths are appropriate would be useful, assuming that "all subnets are /64s" isn't the position taken. 4.6 Global address pool conservation I've just got to this section which discusses the global address space size. Possibly a bit of the above text, specifically regarding a /64 being sized mostly for convenience rather than necessity, could be useful to add to this section. 5.2 Small private networks 5.3 Single user connection In 5.2 seems to suggest a single /64 might be satisfactory for a single device in the last paragraph, and I think in 5.3 it implies it. I can imagine a scenario where, specifically in the case of 5.3, a person has a blue tooth capable phone, that could also act as an IPv6 router for other blue tooth devices capable such as a PDA, allowing the PDA to have a "proper" IPv6 connection to the mobile phone network. Technically they're a single user, yet they need more than a single /64. In this case the mobile phone would need to be allocated at least a /63, and therefore, for convenience reasons, a /48 assignment to the phone would probably be better. I think it could be worth describing this or a similar scenario as to why a /48 is a useful prefix length for even a single user. (Technically the blue tooth phone could possible act as a bridge for the PDA, although the PDA and the phone may also have ULAs, so the phone is likely to have IPv6 forwarding / processing / firewalling capabilities anyway. It may be better and more secure to have the blue tooth phone act as a IPv6 router.) 5.4 ISP/Carrier customer networks Minor : "When IPv6 NAP is utilized in these three domains then for the first category it will be possible to use the same solutions as described in chapter 5.1." "section 5.1" rather than "chaper 5.1" ? "Using these local scope addresses would also prevent them from being accessed from the^H^H^H an external network." "These will typically be assigned with prefix lengths terminating on nibble boundaries to be consistent with the DNS PTR records." Is this suggesting non-/48 or /64 assignments to end-users, as /48s and /64s fall on octet rather than nibble boundaries ? This section also mentions 3GPP and multi-subnet scenarios, which I commented on above. I'd think that if this multi-subnet scenario can exist in a 3GPP scenario, it could also exist in others that we haven't thought of (e.g. Wimax maybe ?), so I'd still think some discussion of a "single user, multi-device" scenario could be useful in section 5.3, even if it didn't use a mobile phone / PDA situation as an example, because it is covered in this section. That's it I think. Sorry for the length. Thanks for reading this far, very much appreciated. Namaste. HTH, Mark. From owner-v6ops@ops.ietf.org Thu Aug 18 05:12:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5gSG-0007hD-IO for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 05:12: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 FAA21284 for ; Thu, 18 Aug 2005 05:12:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5gQS-0006Rw-8N for v6ops-data@psg.com; Thu, 18 Aug 2005 09:11:04 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtps (TLSv1:RC4-MD5:128) (Exim 4.50 (FreeBSD)) id 1E5gQP-0006Pi-D5 for v6ops@ops.ietf.org; Thu, 18 Aug 2005 09:11:01 +0000 Received: from [10.10.10.100] by consulintel.es (MDaemon.PRO.v7.2.5.R) with ESMTP id md50001211623.msg for ; Thu, 18 Aug 2005 11:12:53 +0200 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 18 Aug 2005 11:10:04 +0200 Subject: Re: Madated adoption? From: JORDI PALET MARTINEZ To: "v6ops@ops.ietf.org" Message-ID: In-Reply-To: <015201c5a3ce$a6c44c00$0401a8c0@mtc.ki.se> 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, Thu, 18 Aug 2005 11:13:02 +0200 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, I try to keep all this info at http://www.ipv6tf.org, but not sure if this is as much updated as I wish. My feeling is that only Japan has a clear "mandate" as a government decision right now. But there are several related documents for other governmental bodies such as: http://www.ipv6tf.org/meet/policy_recommendations.php If anyone can point out some other documents, I will link them also, to have a more complete picture. For example, I just realized that I'm missing links to Japanese, Korean and Chinese documents, at least. I recall there is also something from German MoD and Switzerland. Also it could be interesting: http://www.ipv6tf.org/news/newsroom.php?id=684 One of the conclusions is that most of the countries, at least in Europe, have concrete government support, but not concrete "mandated" dates, most of the time are suggestions and not widely publicized. Anyway, those suggestions are already achieving results. In Spain most of the public tenders ask for IPv6 support since already 3-4 years ago, but is not being enabled by default by now in most cases (I believe this will change in the next few months). This usually means that the ISPs and vendors have to support IPv6 and clearly, is not smart to have different product lines (or networks) for government business and other customers. For example, the recommendation in 2001 from the Ministry of Public Administration (MAP) was to purchase everything with IPv6 support on it, so it can be enabled when required, also all the acquisitions done by the main Internet and Information Society entity, as well as all the ministries that I'm aware of, are following this. I'm not sure a mandate is required, let's say as a "country" decision. I mean, is enough if the government mandates its usage in their own acquisitions. As said, this is good catalyst for the vendors decide if they want to have two product lines, with and without IPv6 and interoperability problems between both, or whatever. Regards, Jordi > De: Eric Klein > Responder a: > Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > Para: "v6ops@ops.ietf.org" > Asunto: Madated adoption? > > Based on my memory (and comments about I-D > ACTION:draft-baker-v6ops-end2end-00.txt ) > > > Tim Chown seemed surprised that I had heard that there was a mandated > adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure about > years for either). > > Now this WG had a conversation thread a little over a year ago where these > came up. > > I was wondering if anyone knew if their (or other) countries had announced > compliance dates for the full IPv6 conversions. > > The truth is that this has dual interest to me, as we as a WG should know > what the world (or at least individual nations) are doing or saying about > IPv6. But this is also related to a thesis that I am working on and I am > interested to see what is being done towards actual adoption at the national > levels. > > Eric > > ************************************ 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 Thu Aug 18 05:28:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5gha-0002hY-70 for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 05:28: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 FAA22035 for ; Thu, 18 Aug 2005 05:28:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5ggO-000838-0b for v6ops-data@psg.com; Thu, 18 Aug 2005 09:27:32 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5ggK-00082i-1I for v6ops@ops.ietf.org; Thu, 18 Aug 2005 09:27:28 +0000 Received: (qmail 8468 invoked by uid 417); 18 Aug 2005 09:27:26 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 09:27:26 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 03:27:24 -0600 Message-ID: <016a01c5a3d6$dc4a1aa0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: Subject: Re: Madated adoption? Date: Thu, 18 Aug 2005 12:25:54 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Jordi this is very helpful. Eric ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Thursday, August 18, 2005 12:10 PM Subject: Re: Madated adoption? > Hi, > > I try to keep all this info at http://www.ipv6tf.org, but not sure if this > is as much updated as I wish. > > My feeling is that only Japan has a clear "mandate" as a government decision > right now. > > But there are several related documents for other governmental bodies such > as: > http://www.ipv6tf.org/meet/policy_recommendations.php > > If anyone can point out some other documents, I will link them also, to have > a more complete picture. For example, I just realized that I'm missing links > to Japanese, Korean and Chinese documents, at least. I recall there is also > something from German MoD and Switzerland. > > Also it could be interesting: > http://www.ipv6tf.org/news/newsroom.php?id=684 > > One of the conclusions is that most of the countries, at least in Europe, > have concrete government support, but not concrete "mandated" dates, most of > the time are suggestions and not widely publicized. Anyway, those > suggestions are already achieving results. In Spain most of the public > tenders ask for IPv6 support since already 3-4 years ago, but is not being > enabled by default by now in most cases (I believe this will change in the > next few months). This usually means that the ISPs and vendors have to > support IPv6 and clearly, is not smart to have different product lines (or > networks) for government business and other customers. For example, the > recommendation in 2001 from the Ministry of Public Administration (MAP) was > to purchase everything with IPv6 support on it, so it can be enabled when > required, also all the acquisitions done by the main Internet and > Information Society entity, as well as all the ministries that I'm aware of, > are following this. > > I'm not sure a mandate is required, let's say as a "country" decision. I > mean, is enough if the government mandates its usage in their own > acquisitions. As said, this is good catalyst for the vendors decide if they > want to have two product lines, with and without IPv6 and interoperability > problems between both, or whatever. > > Regards, > Jordi > > > > > > De: Eric Klein > > Responder a: > > Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > > Para: "v6ops@ops.ietf.org" > > Asunto: Madated adoption? > > > > Based on my memory (and comments about I-D > > ACTION:draft-baker-v6ops-end2end-00.txt ) > > > > > > Tim Chown seemed surprised that I had heard that there was a mandated > > adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure about > > years for either). > > > > Now this WG had a conversation thread a little over a year ago where these > > came up. > > > > I was wondering if anyone knew if their (or other) countries had announced > > compliance dates for the full IPv6 conversions. > > > > The truth is that this has dual interest to me, as we as a WG should know > > what the world (or at least individual nations) are doing or saying about > > IPv6. But this is also related to a thesis that I am working on and I am > > interested to see what is being done towards actual adoption at the national > > levels. > > > > Eric > > > > > > > > > ************************************ > 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 Thu Aug 18 06:01:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5hCq-0001Rs-FW for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 06:01: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 GAA23454 for ; Thu, 18 Aug 2005 06:01:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5hBF-000BKL-RE for v6ops-data@psg.com; Thu, 18 Aug 2005 09:59:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5hBE-000BJr-SK for v6ops@ops.ietf.org; Thu, 18 Aug 2005 09:59:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7I9wHe01844; Thu, 18 Aug 2005 12:58:17 +0300 Date: Thu, 18 Aug 2005 12:58:17 +0300 (EEST) From: Pekka Savola To: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= cc: Fred Baker , "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: <4302E5A1.9090803@rd-iptech.com> Message-ID: References: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com> <4302E5A1.9090803@rd-iptech.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1589707168-789498285-1124359097=:1622" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1589707168-789498285-1124359097=:1622 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id GAA23454 On Wed, 17 Aug 2005, R=E9mi Despr=E9s wrote: > * some code be added in those entities (hosts, customer edge > routers, ISP gateways) which claim compatibility with the new > address format. This code would have to be be carefully specified > but, dealing with only a few simple concepts, would not be > voluminous. It would maintain upward compatibility with all other > existing coexistence tools. Are you proposing is a format which needs to be (more or less)=20 understood by the whole Internet ? The evaluation of the scenarios where this is or isn't supported (and=20 the mix of these) might call for a bit of description. --=20 Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --1589707168-789498285-1124359097=3D:1622-- --1589707168-789498285-1124359097=:1622-- From owner-v6ops@ops.ietf.org Thu Aug 18 07:49:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5iu9-0001z0-ME for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 07:49:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28505 for ; Thu, 18 Aug 2005 07:49:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5iqt-000MN1-4g for v6ops-data@psg.com; Thu, 18 Aug 2005 11:46:31 +0000 Received: from [38.118.50.125] (helo=va03ex01.si.siroot.com) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5iqo-000MMg-1W for v6ops@ops.ietf.org; Thu, 18 Aug 2005 11:46:26 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Madated adoption? Date: Thu, 18 Aug 2005 07:48:13 -0400 Message-ID: <2A89D6B6FFB96046BE70561B718593F63EDB19@va03ex01.si.siroot.com> Thread-Topic: Madated adoption? thread-index: AcWj2a6CplwqXRPJQFytXvYXfTL7XAAEFMUg From: "Dunn, Jeffrey" To: "Eric Klein" , Cc: "Dunn, Jeffrey" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Eric, The U.S. DoD has also "mandated" adoption of IPv6. Please see the link listed below: http://ipv6.disa.mil/docs/stenbit-ipv6-guidance-20030929.pdf Similarly, U.S. Whitehouse Office of Management and Budget has just recently issued guidance on the adoption of IPv6. Please see the link listed below: http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf Best Regards, Jeffrey Dunn Systems Test Manager -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eric Klein Sent: Thursday, August 18, 2005 5:26 AM To: v6ops@ops.ietf.org Subject: Re: Madated adoption? Thanks Jordi this is very helpful. Eric ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Thursday, August 18, 2005 12:10 PM Subject: Re: Madated adoption? > Hi, > > I try to keep all this info at http://www.ipv6tf.org, but not sure if this > is as much updated as I wish. > > My feeling is that only Japan has a clear "mandate" as a government decision > right now. > > But there are several related documents for other governmental bodies such > as: > http://www.ipv6tf.org/meet/policy_recommendations.php > > If anyone can point out some other documents, I will link them also, to have > a more complete picture. For example, I just realized that I'm missing links > to Japanese, Korean and Chinese documents, at least. I recall there is also > something from German MoD and Switzerland. > > Also it could be interesting: > http://www.ipv6tf.org/news/newsroom.php?id=3D684 > > One of the conclusions is that most of the countries, at least in Europe, > have concrete government support, but not concrete "mandated" dates, most of > the time are suggestions and not widely publicized. Anyway, those > suggestions are already achieving results. In Spain most of the public > tenders ask for IPv6 support since already 3-4 years ago, but is not being > enabled by default by now in most cases (I believe this will change in the > next few months). This usually means that the ISPs and vendors have to > support IPv6 and clearly, is not smart to have different product lines (or > networks) for government business and other customers. For example, the > recommendation in 2001 from the Ministry of Public Administration (MAP) was > to purchase everything with IPv6 support on it, so it can be enabled when > required, also all the acquisitions done by the main Internet and > Information Society entity, as well as all the ministries that I'm aware of, > are following this. > > I'm not sure a mandate is required, let's say as a "country" decision. I > mean, is enough if the government mandates its usage in their own > acquisitions. As said, this is good catalyst for the vendors decide if they > want to have two product lines, with and without IPv6 and interoperability > problems between both, or whatever. > > Regards, > Jordi > > > > > > De: Eric Klein > > Responder a: > > Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > > Para: "v6ops@ops.ietf.org" > > Asunto: Madated adoption? > > > > Based on my memory (and comments about I-D > > ACTION:draft-baker-v6ops-end2end-00.txt ) > > > > > > Tim Chown seemed surprised that I had heard that there was a mandated > > adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure about > > years for either). > > > > Now this WG had a conversation thread a little over a year ago where these > > came up. > > > > I was wondering if anyone knew if their (or other) countries had announced > > compliance dates for the full IPv6 conversions. > > > > The truth is that this has dual interest to me, as we as a WG should know > > what the world (or at least individual nations) are doing or saying about > > IPv6. But this is also related to a thesis that I am working on and I am > > interested to see what is being done towards actual adoption at the national > > levels. > > > > Eric > > > > > > > > > ************************************ > 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 Thu Aug 18 08:42:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jif-0006uA-5K for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 08:42: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 IAA01646 for ; Thu, 18 Aug 2005 08:42:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5jfd-0002HY-3I for v6ops-data@psg.com; Thu, 18 Aug 2005 12:38:57 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5jfZ-0002HG-T6 for v6ops@ops.ietf.org; Thu, 18 Aug 2005 12:38:54 +0000 Received: (qmail 9505 invoked by uid 417); 18 Aug 2005 12:38:52 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 12:38:52 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 06:38:50 -0600 Message-ID: <01ac01c5a3f1$88420100$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <2A89D6B6FFB96046BE70561B718593F63EDB19@va03ex01.si.siroot.com> Subject: Re: Madated adoption? Date: Thu, 18 Aug 2005 15:36:45 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Jeff, So far that makes it: US - DoD by FY 2008 US - The rest of Government agencies by June 2008 China - for Olympics by June 2008 and I will keep looking ----- Original Message ----- From: "Dunn, Jeffrey" To: "Eric Klein" ; Cc: "Dunn, Jeffrey" Sent: Thursday, August 18, 2005 2:48 PM Subject: RE: Madated adoption? Eric, The U.S. DoD has also "mandated" adoption of IPv6. Please see the link listed below: http://ipv6.disa.mil/docs/stenbit-ipv6-guidance-20030929.pdf Similarly, U.S. Whitehouse Office of Management and Budget has just recently issued guidance on the adoption of IPv6. Please see the link listed below: http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf Best Regards, Jeffrey Dunn Systems Test Manager -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eric Klein Sent: Thursday, August 18, 2005 5:26 AM To: v6ops@ops.ietf.org Subject: Re: Madated adoption? Thanks Jordi this is very helpful. Eric ----- Original Message ----- From: "JORDI PALET MARTINEZ" To: Sent: Thursday, August 18, 2005 12:10 PM Subject: Re: Madated adoption? > Hi, > > I try to keep all this info at http://www.ipv6tf.org, but not sure if this > is as much updated as I wish. > > My feeling is that only Japan has a clear "mandate" as a government decision > right now. > > But there are several related documents for other governmental bodies such > as: > http://www.ipv6tf.org/meet/policy_recommendations.php > > If anyone can point out some other documents, I will link them also, to have > a more complete picture. For example, I just realized that I'm missing links > to Japanese, Korean and Chinese documents, at least. I recall there is also > something from German MoD and Switzerland. > > Also it could be interesting: > http://www.ipv6tf.org/news/newsroom.php?id=684 > > One of the conclusions is that most of the countries, at least in Europe, > have concrete government support, but not concrete "mandated" dates, most of > the time are suggestions and not widely publicized. Anyway, those > suggestions are already achieving results. In Spain most of the public > tenders ask for IPv6 support since already 3-4 years ago, but is not being > enabled by default by now in most cases (I believe this will change in the > next few months). This usually means that the ISPs and vendors have to > support IPv6 and clearly, is not smart to have different product lines (or > networks) for government business and other customers. For example, the > recommendation in 2001 from the Ministry of Public Administration (MAP) was > to purchase everything with IPv6 support on it, so it can be enabled when > required, also all the acquisitions done by the main Internet and > Information Society entity, as well as all the ministries that I'm aware of, > are following this. > > I'm not sure a mandate is required, let's say as a "country" decision. I > mean, is enough if the government mandates its usage in their own > acquisitions. As said, this is good catalyst for the vendors decide if they > want to have two product lines, with and without IPv6 and interoperability > problems between both, or whatever. > > Regards, > Jordi > > > > > > De: Eric Klein > > Responder a: > > Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > > Para: "v6ops@ops.ietf.org" > > Asunto: Madated adoption? > > > > Based on my memory (and comments about I-D > > ACTION:draft-baker-v6ops-end2end-00.txt ) > > > > > > Tim Chown seemed surprised that I had heard that there was a mandated > > adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure about > > years for either). > > > > Now this WG had a conversation thread a little over a year ago where these > > came up. > > > > I was wondering if anyone knew if their (or other) countries had announced > > compliance dates for the full IPv6 conversions. > > > > The truth is that this has dual interest to me, as we as a WG should know > > what the world (or at least individual nations) are doing or saying about > > IPv6. But this is also related to a thesis that I am working on and I am > > interested to see what is being done towards actual adoption at the national > > levels. > > > > Eric > > > > > > > > > ************************************ > 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 Thu Aug 18 08:56:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5jwv-0002EM-U9 for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 08:56:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02396 for ; Thu, 18 Aug 2005 08:56:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5juk-0004AW-GY for v6ops-data@psg.com; Thu, 18 Aug 2005 12:54:34 +0000 Received: from [193.252.22.22] (helo=smtp9.wanadoo.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5jug-00049y-Oh for v6ops@ops.ietf.org; Thu, 18 Aug 2005 12:54:32 +0000 Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 9136F1C001F7 for ; Thu, 18 Aug 2005 14:54:29 +0200 (CEST) Received: from [192.168.1.100] (APuteaux-153-1-15-234.w82-124.abo.wanadoo.fr [82.124.57.234]) by mwinf0902.wanadoo.fr (SMTP Server) with ESMTP id 00DE71C001FD; Thu, 18 Aug 2005 14:54:21 +0200 (CEST) X-ME-UUID: 20050818125422381.00DE71C001FD@mwinf0902.wanadoo.fr Message-ID: <430484F8.20206@rd-iptech.com> Date: Thu, 18 Aug 2005 14:54:16 +0200 From: =?ISO-8859-1?Q?R=E9mi_Despr=E9s?= User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Savola , "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt References: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com> <4302E5A1.9090803@rd-iptech.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------090505050604000301050600" X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_30_40, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --------------090505050604000301050600 Content-Type: multipart/alternative; boundary="------------090401010507030709060806" --------------090401010507030709060806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id IAA02396 Pekka Savola wrote: > On Wed, 17 Aug 2005, R=E9mi Despr=E9s wrote: > >> * some code be added in those entities (hosts, customer edge >> routers, ISP gateways) which claim compatibility with the new >> address format. This code would have to be be carefully specified >> but, dealing with only a few simple concepts, would not be >> voluminous. It would maintain upward compatibility with all other >> existing coexistence tools. > > > Are you proposing is a format which needs to be (more or less)=20 > understood by the whole Internet ? Definitely not. (It would have been a very poor design option, right ? :-) ) When I say : "If some edge routers and ISP gateways supporting the=20 address format would be deployed, they would provide powerful v6=20 capabilities to concerned customer sites, independently or in=20 association with whatever transition tools other sites and ISPs may have=20 deployed.", concerned customer sites are those where the edge routers=20 has been upgraded to support the new format, and/or those that have=20 acquired the right to use some gateways where the new format is supported. Their additional connectivities may be incoming as well as outgoing, so=20 that they benefit also to some correspondents of concerned hosts. > The evaluation of the scenarios where this is or isn't supported (and=20 > the mix of these) might call for a bit of description. Yes, certainely. This is part of the next step. In the mean time you could have a look at the attached slides. They were prepared for a verbal presentation. Although they are not self explanatory, Slides 11 to 16 could provide=20 an insight into the kind of E2E paths that become possible. Thanks for your question and comment. Please don't hesitate to ask for more clarifications. I am aware they are needed, and it helps making progress. R=E9mi Despr=E9s --------------090401010507030709060806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pekka Savola wrote:
On Wed, 17 Aug 2005, Rémi Després wrote:
  * some code be added in those entities (hosts, customer edge
    routers, ISP gateways) which claim compatibility with the new
    address format. This code would have to be be carefully specified
    but, dealing with only a few simple concepts, would not be
    voluminous. It would maintain upward compatibility with all other
    existing coexistence tools.

Are you proposing is a format which needs to be (more or less) understood by the whole Internet ?
Definitely not.
 (It would have been a very poor design option, right ? :-) )

When I say : "If some edge routers and ISP gateways supporting the address format would be deployed, they would provide powerful v6 capabilities to concerned  customer sites, independently or in association with whatever transition tools other sites and ISPs may have deployed.", concerned customer sites are those where the edge routers has been upgraded to support the new format, and/or those that have acquired the right to use some gateways where the new format is supported.

Their additional connectivities may be incoming as well as outgoing, so that they benefit also to some correspondents of concerned hosts.
The evaluation of the scenarios where this is or isn't supported (and the mix of these) might call for a bit of description.
Yes, certainely.
This is part of the next step.
In the mean time you could have a look at the attached slides.
They were prepared for a verbal presentation.
Although they are not self explanatory, Slides 11 to 16  could provide an insight into the kind of E2E paths  that become possible.

Thanks for your question and comment.
Please don't hesitate to ask for more clarifications.
I am aware they are needed, and it helps making progress.


Rémi Després


--------------090401010507030709060806-- --------------090505050604000301050600 Content-Type: application/pdf; name="E2E vB path Examples 2005-08-18.pdf" Content-Disposition: inline; filename="E2E vB path Examples 2005-08-18.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIKJcfsj6IKNSAwIG9iago8PC9MZW5ndGggNiAwIFIvRmlsdGVyIC9GbGF0ZURl Y29kZT4+CnN0cmVhbQp4nO1X204bMRB991f4cRcpru+XR9oCEmolCivxgHhACSFQknArbT+k /9vxbtaeJE6K1EqlUkErjey5nDlzsXJPOROS8vjfC8Mp4fQAvityTzxT8a+9wPJwSt825M2x o4EFS5sx6As6EHBlLGfeeSqkZMIE2kzJWSVrwZyXRla8IJkkDeqBZkr7oNG1L10LdH3eHBLF A9Me4jcjiHdcDwBFENJW77tr4dM12DY3ZK8hnyBDEQQLXlNrHAtB0mk+6Y7oLdG2PSqdLKxu yYSc7tAZOQMiObcS0meGnkPAEbFMGvqVCHoI3w181yQqKR88KJbF4wOijZU4xjSfJBwnbQ6/ rpJaK5P1DGIJ6j0zJoiuTA2QqgKXpprUnGmtZZDVZRZpPRBMuqBs9RxFw4WB6g0gV+OdwPe7 YAU4jLfVXXaAxIdYooXGPLu4yBrDFGJShDDO4nzJrwK/1oQyXL3mC/iunrI4xwrQZFIrj+xt 0X7BHLd9XtJDa17kvGbZ7DH5uo66UkrvAkaAjxGaWdvJsZzSrZYzTptVMHVKMqkWU/ejHlhh GLRLiw+AiAgPcrIqhIgOmlhDz4HrJD5GzEKb0OIQTDgrXETHIWZwJh0bcAuFg+5WQpmFCxVM pAV0HZfOVqdtKtxq0ceLGmXdk7pFph20XH/fw4XD5zVgEcEwn2arx5YprZinzQfS7LwKKt7V SfyCkKYQT0h3nhSmsZ0DB7nMCo6wlwjMCLBXhHbD8eUieYM4tCUSj+oCdagWn1fL0ipg6jDw j3FZeKmNRJmPkoQAjpHV92JD5NSvimX4UyStVI++xpbLucp0n8+w5l26vyiyMlmfrWJf/K1M j1JWGf+2dlzNj9bwaEhhXLXfZ5A78SFGh5lQEsYxdWqZqK2r59+dmv1o5ZRyBi2vWYnqDUMz L1h1XP3naDtHaMVgK8WEsDJNlFnG0s2h4+mtyB3b6iKz9UHcsvvmRRfrOyeGQwq/8Qqtb9hX tXh20+IZFfoLPdTFV2NDdcs7qPe0YQdt2Tt7aaa+5YCInc6jCNKjh+B2qSA9CxsQZ6Djpa36 8reo378vf4mw90x5eb+j1kfVRSl2u6j9UfiJ/ATcJiClZW5kc3RyZWFtCmVuZG9iago2IDAg b2JqCjgyOQplbmRvYmoKMTEgMCBvYmoKPDwvTGVuZ3RoIDEyIDAgUi9GaWx0ZXIgL0ZsYXRl RGVjb2RlPj4Kc3RyZWFtCnicxVfNbts4EL7rKXgkuxHDf5G7pxpbBCiaQ1MBOaQ9uLKTphvb bWwkmwfZfd4dkiJFO2ocp0A3gYThzHB+vyHl74hRLhDz/4noFhVDJ/BcVd8rS6X/C4KS7hZo 0lbHZw1y1BnUXoI+RzUHkTaM2sYiLgTl2qF2UV1gQThtrNACsxFKZ6omtaJSWacKsR0T80L8 qX1bSeaosuC/nYG/M1JDFI4Lg/+MYm6zGKJpv1Zv2uo9ZMgdp84qZHRDnRNoMXAiC91UygTW GKffdVN9qc5foWV1AYVkzAhIn2r0CRzOKkOFRvcVR2/h+Vp5BWmdBaVx8uykUtqI0v5i4OQY PoT493dIKcrUVouMo9pZjgRjVDR9i1rCqAEvzOFbIHWjGiPwFEiuuHEaLwdyTWpOpREKX0Mb BNRZ4A2IWcM0Vw1wQa6k1BavRg2gQvncmxCsGfHFhNtS/eDb2kc2H1SKeO9IDiyEALHhLvGK LeuACl8e0fQIro1BtQJUmYihf0htuKZQcPzOG3MKOgQ2Mnk1kNOB7EgNwFfaCfwwOAkNkOBA CqoCCP/1IDw+4zIJBbUZv+dgD6ud7dZQbpLGnSIcalOLqDuF1TJx1nOgbonEd9dE4G6e+B+x fw87/aYZjBS8vH7ti8rxev2RBM81585Dp5acavPMoE+9mWdGvvCvFaw+wwMNk/iGxBieTswn ETIjtcZ7suO7yf0BdcnyrotMFBOOcdZCU5i5EOwmhZi3INh/Ak9INHCvSAxzk5zck6j60Bdy B2bW16yWcCyoR0hrAata2xCxh6J0rgTXciDXA84C1nljeONjYNQ1TDQmsTWYXYEHKiSXujch wxAOuoW1b1lhnqnukTNv9XLcWfdzsIfbAL9+EkBRQzwXJYcjJHX2OIKZ+ysocu5Mor6Vmy49 4Z39TTQeGR9jD0h+sjf5yYuTf1lGQ0W2h6YW5YDEuYjmdsbJxuBTpLPk8sS/2rQaBkn2c1TL OEjroxzBvFfqvpRt3GT5X97Bqp/CXJbtpm/FcDdE3A/+u6p9dfEjdKQzJ5+SsYmHH5J6b5tD eKf/xyF59AsPyR+Omzxk2l5yxhYHa3HcXo1e9pufO9TMk802e7tZ3uXDLGwVYp5ucpTacZsV d25aARiq5SNUHFZtbkOpBZMBDzKUPOTjzTH/Leo/z9+QTC6JgAYY1SNzPY1rGz6l/OdZWs4y FcJZ5mXI8Z5AI8Fk46XWS6BrPa6S4m0fgdHOJ5/pa/8LAlSkSlaZL0yibgbxwAzBPRDjl6bB v+eqnvtbMeqorF0X3o7GVCekkCdvu0om2/uNqL12wKewfhU/yJ2zTZHeehNg7JnzzJxmapYp lPVWocuqgR9NKqH0MksHvSKc05g3wIEX1Th6epPOiq9J3h2r0ji/J1GjeyblnmcHN+zvwRx+ Cb6v/gM5HCi+ZW5kc3RyZWFtCmVuZG9iagoxMiAwIG9iagoxMDczCmVuZG9iagoxNiAwIG9i ago8PC9MZW5ndGggMTcgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJztnN9T 3DYQx9/9V3j6dNeZU62flvpGGiaZDA8tYZqHJA8MEErKQQMknc7wx1c+pNWeTmfuYIFLcDLJ LF+tpT3bn5XWOvylbhgXddP9jcbBtGrqV/7fcfWlskx2f2YN2D6Y1i/2ql9229oxZ+q9T96f 1xPum7RpmG1tzYVgXLt6b1q9H4kxZ60VWoyagqXBmownikllnULNttTMUfPHvTeVbBxT1o+/ d+jH2x1PfBSOCzN6edPMLTSP5Hjvc7W9V/3hPyF3nDmraqNb5pyop0m5kerTSpmZVFLCUafV X9W7n+uz6r0/kU1jhP/4TNcf/YCHlWFC1/9WvH7j/32uOgdpnfVOZXP3VaW0Ebj/aVIghrez +G+/QnLhErX+ynDLa+5UukR7/oRK1yg5uuhOnu9HcDfaHzdMKSWcGJ0l83I84Uw3XI9OOl8h BFdmdNVdHWGFNHPyebGLuutCtM47H0BvX8cTf9q0bTka4ip5oq6mPlxurNGjo3SQj1z6yLU1 sX9/Pr1DKYCr5BCjta1bJh/hD9/dUOH2Mc7NbhbOG9NdlmlShL8jZxfKatVduUUhHHNavfN3 zu2X0h/RMtkaPncxXcta111MoZiS4WLWY8May7UZsRTtKrfLLWMozZo2jDGBMSYz2oRSrZ5T V2+/X0+MrKeniL7H03DDb1R/+ts567b21T3peuruNC3szUwyy8N0sbESdUY4N0+dkTE9BsgW hXAMDXWt1r6zGREeujitzEgzPMsMUUkR8Iab+ZiiQpMbuBeFtMtywzVYNbLSPZrU38D6itov Qb0C6xysKfI8AvXilpFWj2md9ofw7G//E6wjdBdfwL19CdYJaj8H9QysGlnJs75Te9kzcBuh vX+H/e3X2ZSUYYFAAXYBlEWFBOcIynKceSMkBnMKilA8xsRbW1aIcJaGmXYpzuwOt+k2aj8r 4HyCtOT538ojkSw/4ucWzq+S5ZMuP1ZfiGzeVM82ctGwZIqPdKWsAErKAYGugkKTFcJ915MV uNVZVggKmtKlasoKUVbQpivn7j/JP940+RAxfQNL3TP667ufh6Xz3zfUru81k15TT/I4NPNQ k3yOBQIlwRtBWVRocA6g9OAsdZPhHBQEr25ywINChHPrO/tRcf4wAvO0WB4cg7UP1kFx5fFh fIf4/PjJIa1tSiuf8rJ9ChZuP0SL+Wjtg3WFPI9AvYl/TaRj/DPXq5zpNOQFcjtGIaeQUBh3 hzqDA+GSEI64LCo0UAdceqDWXGRQRwWeyHFj2iUKDdROM6l7Vu4Uq+Q4xvCQbli5b8BDukgZ yg5RSbkgUFZQaLJDYKInO5hWZdkhKErZGJMVrqzQZAfBVfc08cec8p/iMd1DrOAXV9P3zNfx qmtpmdb4qj9SRXCX9vU9r+dyQmAL5YSopAwQ2CooJDkhnveenGClyXJCUNCi34Ud4AWFKCdI te6j+y10r/8DarLwijutfQ8KK+6romd6tH/2aDlhC6xNrOq3Nreqx25boJbr+7sXABkWCJQE bwRlUaHBOYDSg7NzNsM5KCkCwbUsK0Q4+856Ht0/9XQ6TPG009+D4kw3x+c4Z1ggUABeAGVR ocE5gLIcZ8FNtmIHBap3IblbotDg3Eqml6/YSep5GGOo59f3HOp58no+UpayAygpFwTKCgpN dghM9GQHKbK1e1RS9S6U5WWFKDs4yRqKr92U218XVuT4qzjDZP809Xy46s+pno9soZwQlZQB AlsFhSYnhPPekxOUzQqAqKDlvlF5ARAUmpwguWCKogD4HawL1J4yQemreAdFz9MnyAkpd21i Pf/6+6jnX4NKXM/nWCBQErwRlEWFBOcISg/OJt+ljwqC1+abjFEhwlly6l36t6g9QYy3waP1 9zDFD/X8KjibfH8elASvzffnF9GhAKUHZ5vvz4OSqneX78+DQoOz5g++Pw9jDPX8+p5DPU9f z9t8fx6UlAtcvj8PCk12CEz0ZAfX5mv3oKTqXXIpywpRdmhnvxL4UPX8W1Dxt+2jdTRM9k9T z8er/qzqedfmBYDLv2Mf2SooNDkhnPflOUFylRUAUUkRSOF0WSHKCa5hLW0BsFOs0kv786cb kxN2wNpFnmpDcsIOat8FtVzZP2EBsANqCtKsHFpPAZBjgUBJ8EZQFhUanAMoPTjLJisAooLg VbotKzQ4K94wvrwAWB2dXbDOUfvXwsSOv36ePI/vBMxznOLvM/19n/V8jgUCJcEbQVlUSHCO oPTgrPL9eVCgepcm358HhQZn4R58fx7GGOr59T2Hep68no+Uoeyg8v35SFlBockOgYme7GDy /fmooOq9zffno0KUHZS7z/48fhlGtC6LD+/xyzCihev5i1tGGiZ7wno+XvXnVM9HtlBOMPn+ fGSroNDkhHDee3JCO//N+SkoaLnvlCkrRDnBWGZpv7OD361xCGpa4B+tQc1j5YRtsDZxf34b tW/w/vw2qMT78zkWCJQEbwRlUaHBOYDSg7PT2atyopIi8GWELStEOFtL88j+ZXHiTi+bKP0i zfDIfqjnV8I5wwKBAvACKIsKDc4BlOU4K86zd9yAAtW7Em2zRCHBWTdt39N2knoexhjq+fU9 h3qevJ6PlKXsAErKBYGygkKSHSITPa+5vPX9w/7wuS5lh5edfz/0zXtN/LFGO798AvNsLJgx xsrRt5OxGF3uw8/H44nyE2388RAsn28FOu6o8/t37E+c73KWjW3X4mZv+hWxh0bAW4+7YafI PuneauxdpIq9eudzsE5TcxJnwXWvqvE/mnb0azdSDf/9NOah4UX6pEmc+XSfNg13mcW6D9Yh WLPDUgifCsNpaE3ahzHOnf8D+ZgIL2VuZHN0cmVhbQplbmRvYmoKMTcgMCBvYmoKMjEzNApl bmRvYmoKMjAgMCBvYmoKPDwvTGVuZ3RoIDIxIDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4K c3RyZWFtCnicvVhLbxs3EL7vr+Bxt8gyy+eSvdWo4TRog8QRkIOTg6KXHVuSE8kO8kPa39sh d5fDXVEPG2ltSBhzOA/OfDND+iupKOOkcr8dMVlmFbmAzyL7mhkq3I9nxPRkSc5G2cvLmlhq NRnNYT8jJQOW0hU1tSGMc8qUJaNldpXzgtHacMXzKkGpQJVFKamQxsqIbVJsFrE/jV5norJU GrA/moK9y6IELyzjOv+9YTMT2LksRl+y81H2Dk7ILKPWSKJVTa3lZIkrzRK5y6T2S6mVVuou u84+/EJW2RUEsqo0h+NTRT6BwWmmKVfke8bIa/h8ydwGYayBTWny8iKTSvNY/xJXgg/vvf/H MyQ4rWQvRVpRsMUIqyQQbYreFpUT51bkY4itttyafFKUDLLJtc5vkZwF/haEjNRci5wUkirL lMn/ArYSVtT5utmoRD4N1A1QFVeQwnkjXPP8B+pG9iqILAJFgsi5d5cboaON28BGNam1WZDY oGXU/TF38IFg1Cq/9luFlHAYRaUwtY6Ftv7UvJJ9Td3iOEivAjUNFFpchDWUQNWzsPbd49qL 4MYfRWc48uFj4XHvAMCrFgCiolySUklXCr5O/i5Ka2sqKp3/6VUbsOgMIr2I6DGEgFWcOVwA Gq2sGFjv7DDjjWhScoC8t5D/40rt5SUTHZeDrq5KL0ALoKUvbzRlutvxh9vRIlMrmz/KglOt dcUheF64DLx1YH0O1E3B8zv4zPpi4/AnHEQ7Utf5BDdtNn7bKiwgawshVh4bkIyOQtPfGod4 JVh+S1w6rDW1C6KMrG4DAyLNKlitRafOeVe6pHZ+oZYOl177m6Jd/a0Ia2+RHEFmHQhQgOwC Ao6iHFlyQ5XegcQI1HHOpGHuXJxCc1C1cy8AYtUBYoOAuAEpKbnV7pzQBRWrVLy47skjTQrj 2kZVx8ruOwMxJCdJY/OUsUkanUwfR+erwk2mA+Dsw2yz7SMLwTPtJ/9bhNlpH5fOJGJpg9j0 upsElozZJmeKwmQ4eoxzrJ7/+TSTBzwKqDOOtnGdLiPZWVKj1xOdAC0sErWJleKdRMYjRvKm Kxso9+eE0/csfSiQj7ofhot+JH1gZ84/7B9j7ALQzIUf441wGEW+++ExBja80jhwaG/uWP7L 5XXit39ONzaXIYWNrXXTf60SQe4343YxDZmEsE4sxt1z7cw+FLstM2RwlQBDWyNNQkpWt5V+ 1W02ojuyESf2ch/P2007UMsGDU+Cy+hEuJRxrgeTzvfzdIYxDhs36wZQc1lPR2o/NgcjqUHo CTMpmqbrhHupeTqJEwu3e5C1aekNGp3vR8yyN/GSaBsghLd3oXHAxX2Cumuc00I2dZSI8nqn UFrmur82TC2quk9QTze8i9RT72LnB4Eq00AdtKKndGueuBidDMBhcxxE9YO7JDR/p0qFYLvb 7Mwej57HeFQcanSIYOTi2vXBQeWb66lTDXE0T5hMn3IP2P3F+j2mKrpjNxgdZJUMBwz68rAL yL39Zs+NursaxF0Y4tJrwN1dFn0kz27I8ifg/Imt82cAlj8TqnvGfTvko2mP2/aM/DSsS/mf 3Ar2TPIECqE/P8RT/SgKe7fD49eAGud///2kTYO9Y8+n+M0UPaUWqdfN9tCD+grQXTJeA8rq Ppze4NsBgrBz3YnmgjTuf32lcl40OnuKogaOWh79owBH5CIKoRFdLo3olbm33rvoEqz1tmBS l634XXCD4w/zicmJpuM6SndvVvwaGlh4ZJ3hGV8ERnTws0E77MNpM/B9nMY0P9KwX3VFq8K2 F4lt5/ioV8Nc+n9ivsv+BeXdj0ZlbmRzdHJlYW0KZW5kb2JqCjIxIDAgb2JqCjEzNjMKZW5k b2JqCjI0IDAgb2JqCjw8L0xlbmd0aCAyNSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0 cmVhbQp4nNVdW5Mst21+n18xj7uq2gnvl0cpVil2JMU+ZxNV6pQfXKvIjmrXieVU9PfNbuID QHbP7Mw5q3IilUpDNBoEQBAECTb2L0dzsu5oln/x4+nlYI5ftf/+ePjLoZz88s/6QP9+ejl+ 8Xj4h3f5WE81HR9/aPj2+GDbo5jMqeRytM6dbKzHx5fDhzt3b0+5uOjuzM6vyL8e7h/CyYdS g3pc9h5b9fj3j785eFNPobT+H79v/b27f2hcVOvS3a/6Y1v4cevv8cfDl4+H3zUJbbWnWsIx xXyq1R1fBNJBx+dDSCtoD0JvPR/+dPjus+OfDx+aIo1Jrol/isfftw6/P6STi8efD/b4m/bf j4cFwZdaGtL+z3dfHUJMTtN/EQjz8L7xb4/Lvz/98eB8ycvjUItZHofsjzb440//cfjhM3BQ jt+sXFzDQSNYiKCdCL4/WLNS+vHgslv1YHNKC9aLQIqN4PPV/poA1oX1PWei75RsiKFDQu2U GiRqSGtnauepvXLzdFCQQBig4KntdftJ8dFptF6drxrS2oXaZWpX0AAkWsKoWrZZ1qdmPdYV wrGZ5Hc+TvK7ajqkD/IKIUqFeqp+apMOM/NWiWouE0YaKeTIGnFay0uvgXCiYz4IxwmE6LqJ E1vHfmxhzoiGBSdmbI8aWrUWTNLSLFaTzDR+wZDEsMgGQd9kFcZO7aHnxpuvQ98Ko44UnGHL c9PoCcQzHwTJAiE6eeKERkeeZ/TDNMBJmNqDhp4OPxyaWw7TXCvOaMjzAnGDzRaHMbdTGxIz hOYFU6DZyX0E8M58sGXFOr4TYd9Ek9vcq0AsYYx8T7KuVpPCYHtN/liKpvuscIpjSNCQ1k5T O+vZ+bS8UYaxYIw+ekIhJ5YmbTSSprnGbznPkKxnn/TbrVGe28qcpcGeWTZuT7OzaS1np+Vd rSZNWmOc/t4KMQPlnMrUnnljCHEvbUftquVfLM/WSUcMYT3yWzkxZBwNadexzePJvNOIs2zc HjS0zrUKfxQjrZButNjnBTLMLce+svsO1abRUJBEGJh7kdpWt58UHwEjU+O4jlWslX00VduB BkM8YRQt2yzrYjXOmKLHd4mvsK5jtBoOjU3xgFhodvWDre00Rmv7UdPdd8toCUb3e0KBPWdN Vmv5WUFiYD7g1yNDsNKFsZ9uneq5Yc6s1oBIa4mzUUOr1niF7dKsVpPH8XO8LtvEEKshjuMO bhfd82JHfph9guHsSMFBz7wKi/UCEiLzgVWLIaCbJ05odLgfxClCoxAnwU7tQUPLXGux56qR IRpdqTR/QCP6/uCiGda6hiX+A/ZX3BChOVkN7dTGKMtqVwgD1pV7e/RIT4oP+CgX6oDT2sOY S5t7FYgljEGSWdbVtmIY7O9loRI03WeFg9XPxTj4utZ2U3sajwYZIhHB6DNQKGD1a9xOkaZA ovCB+eUZMs5A7rfPQHmO+SU0LDgxY3vU0Kq1nK2Wd7EaFyetMQ5WP8erDlGW1Q7tNPHGEOJe 2o7aRcu/WJ4tk44Ywnrkt7D6Cd08cUKjxW0eT1kPwUkd26OGlhn54dhmaY5No9gXO+yKnc2J piZNQ9/2tgRxmKwfCNv7iI0mqZ8hxVpgX4llkiesQFiAEC/XY7GD2XM58VYs2xVsCyYmIKub vhErEhb3SJB1W3kTVswzFiAfg+UJKzCWJyx/G9Yl49pR0lbhbFzG+MkUGZIMM1URM2Pd8BYW H4lmg3gNae1h96HaNEcUxBAGIrlK7SFKeVJ88OyuYdhHtfawE5M2rxt13MELBVo3JllXD1hx csDrRsUazR6w1mGPtELgR4hyHWLo1oYXsaQRw3veOmJQrMAUEMk1PmZ/xxBe0fktFxgy7COk X4p9+Dn7ZqZhwcmwi5o1tGjNW8QFRaxmiKsXq3HDCvWs3uqUWns4b/AW0QSizAaBfI4wBnmF gotseRi9wNaLiIT5sIPun1U/GZwMuyR5XtjCQaPQHEBkVMDZoKFl3fByYka7Jh8SLJTGuEGS hrR21u+odiBOBOIIAxQstYNuPyk+WCMcMdP8dH7YA6u2YxpJ8yEUiM9J1tVqHM4jHMX/fnV8 g9W4krUeVwg0TZT5vBBtO2ra85lbHy3VNiMFxOWe43LRCHsBeEHuxyWGIGoDJ4jZ/NivY60x DeKk1Kk9aGjVWqDFi+RdrGZj48EinrIMGU4qW9tNbat5XeyIIWHCSNSGdJktD3EsNCIQ4WPQ /bPqp4ATo8dPPWcLZxrgJEztQUPLXLs+22N9A5swpHtsE6j4RtHb9n9K93x3/9A4a2u1uwtr +uUhn0I4PrRFJqeeofnuvq3dTcP17pv7B3cqzvhMyK1VGq4/mQJcJhfXnzaFevd5p+xOqVFu EzteohxXZHPK7vjQJqpwoSi311Kz6rsvVtx4co2LJlXacpFWjNY4LnO5hA3CLy51G/cmyeJr vXsDUdZkGCeT6mIsTSofexjdNutHWzMlk5Yskrkyj1VXF6UpZVB6/2lpRuvNKcbSQkBz8pbs TqX9vub8YNiR0Oe+BvtI8U7ISsJrJFMUwkThEyULyy5okczVk4+XJNsbO5fJT5buV/Iyds0W bhDNZXL6pS81eRk0IvH+YBOl0KiDULPuoD1O+uXQpJOXWxi/as0Gv2ott0lrg6N3t0+z5Bw/ Sae+LSuLtSzBdoa1fHmPZHJUikRq8ypNlX5gaKNDSMyQLHsx38NE670lLEBc4WMpW3tw0hNl /aAUkCCHV7kHU3ZddGnHRpDCG5sWx/U3k0OChyFZ7a3P7p+8cWCQspGeIuqBZTY6Rw9NoNDZ quwztllwHFts90bDvMQMzSc2JrM4hX+SqbPrCnzpG0PZCiner3IFvliiQFsc/0byhCaHWe9S lDZQW3l2HYDph/CYRH5N3Ltb5r8hGx4ovMn4NMIhn52Gu8MT6Jgo+B7B5HSjOPsU3mR42nyO totT40YcNTofjrbQVOtz4UY306Nju15N6W6GIK7a7WzMBfOrbx5DuDQbacGw2NCs2O4tnG6s Jxu79dod6/1Yr+uN7xZuHalDIFWOa1hpblaaFaVd9IEj0RftFYsQoBOnGpMekReB+OSU+y56 ar0IJBp2375fQVqwsI8BJJokPU82Na8EL5vuhkMv2498lIu3MKqSr9HPhP6y4XvoDoe7vHA1 SLqluwl9OC+WU9voMg0anUIyZN1iTkzhmQ/uEvY8eW1y01jLfDQby3Ah62cvsgCSLvY72YsH Eq3hbAQ86S12unT8Gga3P0/6fWzc7op0DOJ9XxFbAF85votd6fLQH2uk6I4uoeHUdeQBN8rG p9SnC3TZqfaEdiPZqS4vBjpAqf14b3lG8eR5v2p9z/Eg4FGhWcqbycBjlLLnMeqQjDO59zIA 2bnzQ7Kdl74filo5zZb4bzNRXHKBYjdgMyT7851MSPIa9N2d4hie7msFg+FtP/XRg7FZPmhw vO2nFoyryPg+BHtj2p75m8e07X3Yx9IJSHR2VmQLeeuILZBUz8+7vdd2YmdSO5KLwhJDLnRy 4bXgkhqtLm+Oo+HvjUPpySmNG19TKKuPXtpXaPPqqyH5BKwGyWfVjmchu0vY53M3lc6wavUT U1nuvu5gsZuo4bzi95xxnmfX1nnMpjfYAOLl5LDumj1XM7MyIclrzRbOdoJnCjsZCXouemC2 lcuemC6L+R4zOOvE6rYPxfuLVf2SHuyXm3i0O381s0iHIymBS5y4eMf9IrktWEhEAzLIskOT INmq2PEarCsy7oqA5OC3SyLEcnwFaU/Qq7AuRtmx6vVDcq/eCQFv+j0XwF4271HK3hCMNwZ7 if1+H1ho8WLkHNsZxqs5PbcZwU2Mx89qZWy6mVMlkGSaDsdFwNI9X1LWppvZDZ7pxvTEpXd+ y7rpl198sKJagqSrAvMdAjwOamxmLNZ60C51EzshLqwcO/m+GkW1rZpc/4q1WQxwaVL0Aiyt frcecK2MMpYrGqJ7fIXWJOIZWiQjJJIVU8toS79c+gqWbE2AZfsU8OrDkUujKed82HvWfhvK p8jBKlZkT0d4gyGe3zjNvvaci7/gfUfn8rK56UEzfHufI1Hcq5wS3/6gZ95dwr4QsMRhC395 I8zYIeKezPT+7d3t8LsT6e90g+s+6jxiB+vTMoTOmn4om4rkM75cvuRKYclA/eo+nmJpkcXd V/f2VIpxsT1es1zp5NPxoZ4oeyaY6vV/k5+/vn8Awj/uob7vVNte34Xjw5Ks/H49kQLqv3D/ 7+Wlx/s1mRs9vd7m05JOa1GVztS1oN2Gku4+v29uzsf261tK1JlTUSIowoqxd8zCzdK0kHPJ 7Rnf6au0okjzBb+uaH7NcimaR2QXjWb68/tmxqFt+BsjDdq8WT3L097PI0ZTD+a3e+8/3i/u 0ZqkdSqCiJ7+mX91NbSFxixp4GVkV/JKUsXJbzVTD2J3D00XJkSrRH1U+mmD6Iq3C1PN35ns q0L8d378/sKB7zUHm+zi9UYrbJ33FAxQPLLcdjA7Ecrr0cQmSNW3JZfJ/5FXA1p0mhfmc3MA lSa+zPGvl5Pg2lh2YbBVtjCZSxpVjdstP9/tzPJ/ZZgMtrKbb3cc0y1dvm7hSMI3ltKpmJgu WHiIy0WDtr0LZWPh3+4I8k4rErb6cL8zPRUhbfT9ioN3y5zNDt/VvokWP3miUJSjJgpdMtMT heOjzbmFL1ECUwn08zgLBiwJgiQhWmcsScFQJjvmHgCMee7N2c0G++3y3v6UfDmmZaM4Zqhy yJ+c946ZTzQZou760ilnrIWj3w5JRmJknHMn+fCVIbL/QG4jGT7OZYiTEaeTupgKPjZiSLjK JVKGJxkn0W/ZsDznvZN1dAH0mrx3so6uj7513jsvt5HymGkLzpy5A0OJ72Tp66CPTnwLhbdO fOe2fwp+R6BLmW/Y4MdnvkcKb5n5PjMRL2W+GzP9tt9HZ75HCm+T+XanbLs4UyJ/EeftMt/V kIXNSdzEX5rvZL6TpUuiV2W+QfztM9+L+Va7Y77a8a7q+bnrxdxQIwL56cS3AgQiumF9be4O QOxXXKKqXtHoQ2G8rx795V5GPBnJ1kRaEGTJRIo6FnzBLxDDjh0b6oY15Zob1usZcTjvl013 exlx5fwtG9s1O/MZ/WXD915GXJY0pLiv7U7QExNYScYoKQFktJPF+soQY7eHIfQs1lQvYZ/J iKux3pmnc7YVzyQjDl1czIgPkUI3qOTPZ8RD7belr8uIj9hTRjyUfii2mxGXh9uM+H5Zlos1 VpA9bUvhmFhV2dP2zOLZ1dlThEIqaEt+m1+hOi4xhqmyS1y/OcVhaaDwylceyQ6Jcg7IwxSR dNsbuLN58+ZuQHwnfpzz5i32w1xniL+QEGIk1gogVmahCm/Ted3xkBmf5yE7lzff4Kq8een3 Pnfz5vOza0Y+ZLmb1M9vAdnLmwu2QMKF2SmvOX4Nsfc2nUknwYolhlzoRL3mpteK3CJC3jyE ZIbpcSFvrnGvyZt3ZxHlDHerUHV4E8f9J9jfy5uHEswG+5a8efCcYZnY1HlzhQVL9LacV/ye y97srLYuZja9vZR2m7E4ojZ7DulM3lz5HIKEnLZrjTyzM7ZkTW+pUBUdPuJF9agGQQUJqi8F COpPtXaZ2qj4IpChQlVre2oH3X5SfET0Sl+QAYL6U9F1mVXbgQZDAmFUzdcsa69Q1bPN0SF5 gwpVoPvMVaziWmWqQ/BWJco9LlBt0mEN4K2SxD2lqdp2omBYIxgHg14D4SThg3DwkbTQ9eCE pPFh7Nez5pkGOLFTe9AQVagiqhVBC1Wogm6fuYpV5I+bUcWpQVy3AuM0BupAgde1DpQZpBGM MlGobHnQkVgvIMIHUYHDkn46BJWxMH7qOVs408iEgREHZ4OGdIUqjJ9UqFIjShU3AEH9KbZp acPqBWIIww3zhvuI0BHzwXMt1vGdCBsgmtJ2TMMOfDEF4nuSVVeoipSwlwpVaq4xDlLcqOKE 2YcqTzw2VAcKM0sqVPHcEgwzUiiikbTRSJpGht9CdCd0PTgrgz3Lc8ucJa0Bka0Hg7OGdIWq KFdmqUKV0hrj4CoEqjgxZaqVwT1T3QvFm0D8hBGpXbX8UqFKW6+tkx75rSKQcTSkbae2Z87K MOIsG1nEpCFdoQqzXipUNQi+p2fP1yGOfWNKU5voKogjDFCw1La6/aT4wBE+6ksBgvpTPPe4 nbASCMQRRtGyzbJShaqqx18qVMl6ghpN0PSzequiDpTVGKgDBT+51oHyejQFo5SRQsmsEaz0 XLMLkMR8gAqu+Es/HpwNa4l6bpgzpzWA6luRrrLMGqIKVZBP6poNkcwzV7FCz1KhCnMJVZ6k jTgEa67jSIWkkXaaKGS8gRhErJchFhD0g/v6QreCk2Fuqeds4UwDnNipPWhonWt8UkkXKdu2 pZPXtyxljzgj7d22pKJXw0a9qyRU2Zr+krvjX2JT17cktfBr14ToKHclYYPbOF4U5gLESRgR pjYmrkAMYQwBuJtc+ZPiA84dhbn4nVAH16Xa6DWM00koEN+TrLq0l4QNKO0lC6DgIGxA+SsY KspjsWuL2OZgmUGJLZ4sgmFGCkU04iaNMIRHht9C2CB0PTgbQnL13DJnw/IuspFrmzSkS3tJ 2IDSXkprjIOwwfFyTZQlCDDUThNvAvETRqT24NqktJe2XkBYj/xWEUgaRkPadmp75iwPI86y kUVMGnqttBfdSw4pTpeC24SW65h0+TikgKNmSrwDsndHWrAFou6/X4V1xR1pRYAgcZ1/M1O0 sBhcHVSCemHqGqwrmAIL+wf9872gGKF9gRg+hLkO64qL28Gqa5PdjxuRChe3g5Q/mt7TF7c1 rX4stysgPwtlwlZjdB3WRQENnebyJQc+s5XPts5fHwkpunNjI6dvuAEOiKYpPTOWkflzxc2u 4SjQXdEN3RPXI7i5J174ijtDwlVM7RDgYVcGM2PJkfelm8V0h7rJh7NE3BPPKtk4HXXKrW19 +Imtixp4zwOvbpPTPfHCHyDhbneRu/izyZyhNYl4hhbuiWd8AsT3mZSMfIkwY2LvYm0Sdh95 T1xSq/MVKX1PHImqfUNUOSdDU3YbyqqrQNdhdaFbnCpfWncIV6W9FmsvYh3i01fCYrpk3Z4x wwQxWTN8DRb13NYSWLDwUhVW93SGw3bE2FXO4S9hleu+hWLtxc1IyHSa1v6XzXvTbfzBSb8o iPanl9z2sHLI9fiYd76C52dli33V2owThmIwDy7k/AV7vvyvbzvc1t2OdDvpyum9weJKruex 3ubyfyrpFO3f//J/84A2ffTd/wfbBin8n7n7/9BcqFsu/yeuQfa29/9x7ff/wQcAb3LrXtK0 Q+J2N4KT7wIpvzHGe6/HZpttT1x3xDecdlQckeO0A8Vi5XgQ5WQBQblZ7GxVm/bDAolUehQU qMwm9xFx4MZ88J604rCeTjvqmKBTbcc0huSNUKDTjklWKkiL0wCsXxWHgbxvr0jq8WlHRbqC 9rpU1FW1sfcl3lAYlvfPjFHqSKEUlmbepTOEd/L8lhcIziZ63SXulw5u5TlOFJiGAydpag8a ooK0XssnBWnluBslWSN/gouirTgSRlFX1S5jTygMC24Vhh8pIIWJ8rOD9eIcrTAfBMF1D6Fb Jk766Yf0Uy36AY1KnEBabvvRAqQgrSRJUCxWDpVRThYQlJuFXqUdyU4UJBEGZhJK2AbdflJ8 cBlcPqim+UnlZnn+cptnuEAcYWQt2ywrFaTNerylIK2yGocUJWJML9cBqCckfbg9pfI9p4n6 3BKMkkcKJeENzHnRSJjtSBLzAsE54cRJt1/pBykPoeGIE8jG7UFDVJB2OImTgrTKoqkkK+hI QdoGIavg9AzaduwJhWHBrWDQ3GMKHj6Nys8O1osT2sh8YCwEMmhftcvUrsyZ0zYhsnE7jRaw nCxG0zar/Pfz1j+l9/N6NzpYOs0zuJ7KEC/fmt9yd7uxM4WsscW+y7cH6+fACFl/vYQoJvZv CM1CqaRy97/3do22or7A34IQQ/yvnCtJrvrTfyRQNNi/MCRkq0X8NPGWj/64YO9r4vUL/QvB ppRO8GGp3OPdcflyOFH0+djebZu6mu9+Wi67NzI53v2hRW+puhZo/vl+iSJzCXd/vW8xZou7 Urr7z/a4hXYtoPyf9nZpHtEp2H+pl/HryHhfrry64tP6Fyb7YwUUzP9eH/sWLv6Bf0l/f2LY X0lQtZdZoroWZS/ZPEuhq+xVqHZvCzLS+q31aVuNNyD4XT46bkT867WAw1LMeKkFXPeK+56t gCx7krMVkKlwcAs4d6oWz3WD16F+8Om0rZacqOvm+8Ox7evxUaJopmO4sGwi1j8uOj1/7Pux uOxg9p8/2MVWw4ZmG5Cy/w6p2uayKnD9NnpC6ZtL1wgn/muhm62nK3bRqW06hWl71o1g/3b3 w+LBFWy+objqyw76W5+oBbVcwqdKLwTxiSqMhx5OcjtaWrIZwn/BgiG1b+59GsuqIaeA9kJj xgCFMvTqjZ967V+G6V6XPeP6DkmC4iKQFe0ndTDV1rfplq8u0vPxHyYHqlm+HFJl5eH/nh+M X2cX/Xs7X/AnVnzqNzMAaSPWtVmpzj63M4+Qp/NXx3YBSCK76DdQQzA06v2gG+2FxoxBFEJI YxvpQoaUYKdeCwV6JEmotKEgWdF+eu3w8w3swuZ4sgv9Fgty+eBbJ/5DW/QWn2aXYzl3q/Po XnpJESyrhWWXfiuFh7btOcX1223lmukj82+oGH7rYjnQKmcQvHFL4Xqz/xTyfX14/Gz79MGG ui5LzQJCmD8e737cLBXCeB2Sp+HGWUHnL9ZFpLHorqt1cgp96URmQl8JrO5m948FAZueyQGQ LYlPYH93+BvlpnpbZW5kc3RyZWFtCmVuZG9iagoyNSAwIG9iago2NjQ5CmVuZG9iagoyOCAw IG9iago8PC9MZW5ndGggMjkgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzV Wt1z0zgQf/df4UebqV3r0xI83QFlhrlhSi8391B4CEn6wbVJadICfwj3997KsqR1LMdJeeHK lFlW+6n9aVdR+JJWJaFpZf44YnabVOkb+L1MviSqZOanWcD07Db9fZIcn9WpLrVMJxcgT9KC wJKQValqlRJKSyJ0OrlNzjOak7JWVNCsilDCU0Ve8JJxpTlaVrFlgpY/Tt4mrNIlV+B/Mgd/ Z3kBUWhCZfbKLhPllzOZTz4nryfJe8iQaFJqxVMp6lJrmt4GjmWlNwmXDSvGabVukqvk72fp MjmHjawqSSH9UqQfweE8kSUV6deEpG/h93NiBJjSCoTi5NmbhAtJsf3bwPEx/NnEP14h1q2P KQ9TJKVUldrVZ5KT7N7sGahLobOpoSX4qni2RPT6Oi+IEapItskddZ3TbDWgkXqp0zxqfpYz G3b2z8KyaygWsh4snECUKySDI77tR79lZ90AwewIhc3mZlMKUslSpQXjJbXA+ZEXWtclq2T2 W05LRrWos7sGTUpoyjv0DWTEOdWSwhZ4cpYXUCnNweUUCW/AnBCkElh2hQSWiE698F0uSlLR rq1744JRpYxZlxVRJiWodkFlyRug/2uAfnxGmFukYMGdEQ4+oAaKZd8Q1bVWgxvpFJ6DV4gM /ppahYpCeH3qJqcNJGZBbGO0rs3phX8zDnm7laWnUitDszVQyjC1zh55d33LZMMz/haeHyTW m0jAgReLYYG9wQnXqka8IDcP+yTaBlgIWQoKm89KyT2YCKccip29NhUjNaTe1JHpCo61gQor awHt7ApxU0MTLTnhUJBWADOvjZqQXEGO3gIWwPS73JBc1Co76orUZU0EbY5VqWuz20eBidYn fh3bXaGIAY8C+rLoej5tNgn2g8AG/ZFMnnV2JHhF6dzn7S6FvDbxoJ+2MRfdBKCTVrrWwS1y gP3i6iwGKnUTfGMR7HEzUCJsHsNjieh5iBarhjRR7vM9wsU+cSnjG/9iIPIg3fqhiioE6xXi LhE9R3S754ypTlEd78LObwEtmrtOZEtHiGS90hmVNvIG81dBdNF16kVwkFuqnr+Ie4zaWHb0 TPRFG75pDpVtzT9Ca3YdBAYyo+0V5Z1dRv3FEqEVR+ux7CLJIQaXEuHkcbt6PZRMuwiM0n4/ FlEYxQ/iDphHA7kbgGvoPAN94kPmwnsYcNlpwm7HhuK77GJiCNAeF6HvUyQRuEdIFuthDK0G bI8fs95hbvTu7YmquZlXLaCmSAshBBvDJj7kFtccrtWqgbXp8eOwPunDmhvVAGs0f6J9c6sV x3riwVjZf34cGMlhTRahdmtORVL4mrtuN43MMXyM+uXESN7npDXl97Y3odFiNE6juIvOp8sB uO5zoAbAmVpMc4IuuNcwTbRgugvdXmEb7pDrofOOdecDMo+x3GfRiYnNXQyMlejcQZbHkwwB yd7WwYiSZjYVRLvPQrifxxsm7pIYN8H9A8CU0FoRfD/CagOjaTXgGyM1tPZfdUz1zuUmesHe azL5euGDho/APqPJ9W3bk/fv25On9m3Hvo+VahmtxB5AWexRii1MuFI8CRJbH5xGJ81I//uE RFG233NCSjgrdHgTXfd/yi72hvg+7fZu4B6CEG0vAtQ8r+0PqNPY/ZbQgftt7DPZ/xtRP9lk eo1lNZAX5kM7cQBbxREYwflOFMRx7qbuJyS5C+aNC3Sr2K7sjmttp7L2cyL1IDv/WbT3PvFt P7YVnHOLewFRjD252XfnX+lxTY4/rn3yvFV39aqrG38lK3j82RXuac3HYRV5d33t313xi+jA q6p/Hl2H9Qe0jp5o93iMbW0NvcQG7tSJdl5inWSKKFXCWahqc1lhpRSaaKyzcHZmOHxv22mg 5FC8j7ljLqIBdx+X+4688/ZW0HtEFnT8FfnYFJ/vejbuPOE2wwKCs+WH3r+vCznswuAY1INZ 6R5Zxs2eNLVgjNSHZgLCD1HM99+S8fcUjeJf4bC+gjOJvhkZPEuzWFsAXEhDyhrFYjrEwc3B tATBsJn1IpJTeBW/8NRqO09aMYIk7yIdBEtuvOSodWl5X3O4LIC2OdK8YytE2qZc6xolermF vwOA8jLficFzA8KCMAE9jEGArsWalrsJHXeraY5+BdGmOI+UAoNq0TTadeoCjdl97OGx2bE1 2qgRbOxf8jHJ2W5sYdFg4AFjupUcqHLf5ON13lLTyGqM98ZTE5hNrnXZkheUlNKW/dJ/dzb1 1MYeYsBZ8yWnwyurbTW/RyaiVAZw7eey4Yn4LY8NwdvcOIK7CBv6ehIPCDRMwqx4vnN4/eEm BbZzGZuHaLx8z/tuONKZQHgUfgjN3hktK3EclX3hQwm2kD6aqNPY0IvPzyd+Iyud1eMmqFqS TqhHRpDrppc7SqL1Y889CQkEJnfWY3bsdOIAQn/FPTXYYBWDPWQlZ4pjD/KguGLZjNtyWvEc X/qoZKec9smJwwY0oJfKZoNq2v2+292EMOgwGDcR1PYiastnfDf/++N98h95b0E7ZW5kc3Ry ZWFtCmVuZG9iagoyOSAwIG9iagoxODg3CmVuZG9iagozMiAwIG9iago8PC9MZW5ndGggMzMg MCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzlWNty2zYQfedX8JHsmDQBgrg8 tnXimUzaSRx1+uDkwaFsxakuTik7kw9pv7cLkAQWICRLSvvUZDyzArC4nLO7OOCXtCoJTSv9 fzTaVVKll/C3SL4ksqz1P9OB7XaV/jRLzq9EqkrF09kdjCdpQaCr4VUphUwJpSVpVDpbJdcZ zUkpJG1oVkWsxlpFXrCyZlIx1C1j3QR1f5i9SupKlUzC+rM5rHeVF7ALRSjPLvpuIm13JvLZ 5+TFLHkLJySKlEqylDeiVIqmK9fSN6XLhHHTFGsZvJbJp+T3H9J1cg1AVhWncPyyST/AgvOE l7RJvyYkfQV/nxM9oJZKwqC4eXWZsIZTPP/Ktdg9vDP7f56h2ueH85IJSVIKiEgx8PMmr7Sv hvNGQ8dhmYpl7R+36NcWIIdBFclSa/2i+8Hkjco2aOwc2fd5MQ6/s47f7nOardGoRW8LYArN /zIn2SPqWedUO1Q0a9120AIbb6yzOxMFGg4KSDONSMFF2fC0YKqkfdT8lRdKibKuePbaBJBs FGXZLbIXyL7Jm5JUlGRtXgA3iulj2XWI1IsA+AUFxE3c/a3j7vyK1GMnhanGkGX9yWSdzfR0 cBwioNGfTvKS8NHjiVkwUnCB/Yw/5xHrT8TUrW3tusG1YBovhhxMx4P9uYnOtNWDzEjYtfK6 3HYcad0SSFNKCtS71eyZtvuxcxNxPbPDUmvdWWuyO1rVBI2MzXiLjzqM6+we5hoNPEQzUfQE FASKDetZ2Fje8OF1dC+s872uW2DWDC3vIYB3E1DQbiw5sb23xluvFztjd2YJ6rZ+kASr3umf j/bnMh/c3mfoWL+O6PyYW5DfONPEwPu8h6qPbh391VHh//LE8D88VMcVlPSHiuxrThrdI/qM MG1zRCOGduEv7+F046fSJAsNWkEWDsjCNiU0N7AHPPiUbDJBJ1Q8+t2KHyMh2eUF1yYXuvwF ZWFPTrneG9QWpA5UXcOgF5HAvI3k9khCTexOqNQwcoULEfYOaS1YyGiQLx+93HDkDfEe3C2y D35p6wS6XGaQMZQSJoneEYQiVY3oL97halmPV0vnrpZ78GKMKq53BuqiIVWDGzeev7NTAKKp VSXwZA/jAvhya6OL3cUWa0++57il+0Vuydif6Nxifa4pCRMfzYPkgSPOxVH3qGleumocVMNd VXSa4A9hTJkk3UTS0LW1Lqc2KJbcrTbmvTsfCaOsIJA/EGOHltUo2qj+HQX8bwDPBfy9cVMd QYg7/Q5qHCQn8DOgOJJk6HjQbHtlgdsaO9EStR3XWItFrJgOeU597KlkZiTezw6Z4apk1/ni Yu0LlUA9bP3SOCms/S13cE1112O8phZs/y3pKaGChcI1SLnYqdyEMf0WqLYnK+dafKGFSXWc VHE5dbBSd4lUILiOFvAiptyn2J2o4QeksJA/WXr8Z0IeQflc/iEBhKX44LNDiA+9E9GzIy1b J//XkbNOZboN/39drTvf2Po6K80cnyKdOBrG5B/VU/xJ5wBdRRXtOoLpd4nU9aSWR4LjYiTX vlPeucdJgVzQ8+W1oZaxplR0zNfLsB4zAXruhLfMz4A631cZlt6NhkSLfX+FRWJ8DtoS59Fo XrB7REzsOvBS6hSR4c6Lbv69x0aHOp9s4X8r6UwIHnH9PBtdIazf8YUIfYV4iheOnYF35t8v h9d6V2Q8UkdMoUaT/gPfKEyGD1nf8pGUw1dtdyiowckPCVjjMRIXkbtlEXkbkqbp+Zb2JRx/ HOIXIXooLmJvt+2eB9k1BFRBqACwRPg9J07ZRCKZr+Vvk38A4moTW2VuZHN0cmVhbQplbmRv YmoKMzMgMCBvYmoKMTM1NwplbmRvYmoKMzYgMCBvYmoKPDwvTGVuZ3RoIDM3IDAgUi9GaWx0 ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3RpZzxy37X1+xbx11uhOROoGigI9nBRBUiT2 Anlw8lCsjzTx2omdpum/L3VrNJr9dr1bFLA/GNByKIqkeInSzyObAUfm/tLgeBrY+Bn9fzX8 PJiZu3/+Qz0+nsY/H4ZPnujRzlaNh5eED+Me6JNUbDbajIA4g7Tj4TQ8m3AHszYocWKdkcyj /W4vZi6MFdVn0/sM1efvDp8PnNlZGFr/8JzWe7LbExcWUE1/DZ/B5M804/DD8PgwfE0SgoXZ GjEqqWdrcTwVSACNrwehPKgHibNeD98P3zwa3wzPSJGMKSTxZzl+Rws+H9SMcvz3AOPn9P+H wSFwYw0h9YdPPhuEVFjTPxVI5uGp5//hHUK92iI5M21gBGKS6bhFXzmFKm7t9I/dnoQTxM90 3O1pF4W0OP1Yhi8Kwi9O0VZZTRsxVuMvd2zmBiya6W3Bfu6H3Mrpn24EWio5vfTTNEOtpv+U RSqMN3naqzwaq1mfulmacy2nf2WEMqkS4pdqVrXA286s92XWuJjFZwCFFWb9+UBalFIzOb1z 37USpIykUJno++H7rqxnOWxJ1Cs/3qXlKoQNahvgF13m6kW+nbw3KWQzZmeDMu3bnf/ufSua vRm/9KZ/idmj4swZOWilnJGDZjBybdj47gXZu4tLD1s88BHMwt7Jd2jPiKxgs04h6amzUM6V tE4F0TQi4IWXwkUyMe7lrEQQ9BunFKUUc1uaRm+KxORR9PfuFUUbxp0cgivh5EDDR6G5k+Ll o4s0saYgEoWnV8XnRhXc0rZwM0quSnRWWZjHXinIOEyiJ5cwsORKXiuXMPi/kEsIsn5wclVb 3JXLBwuiZ01fRCNtZFA2DF4qolFsSYHfR0RDPiFJRLQlahcRD7u9JYnSz3EnaKStnv7Yk5J0 5XgkFr2jnQpEauMg5HUQfoPfqCRV+n0cuOWmhlCEh5pC/h3XOA4ZonmgmShoaxZrxN+0RuIi YSQuE4VGjqPbJGA+5FyWaT9eTXx/o7lpUhRFCkHmxoNHTb+qXDk9I/smTxspxseKB1O9c42T EASj2huRXYFzBosyb8ISyLUvjRjYgJUgaZ6nhULWkeeUIYQFGUshDzCRsDJkgSUaWh2svMlG 6MhXhljeYqVw0cd6RtsT1R2UzLlJQpvIAncBwoXAUiEmUglWhO5hCcPNkoUaK4koKdMvhW6w RKSlz2ChEA2tBFliyYZWD6uRu9YEq4zEeFpKCExGEiEuJ0asyyqMTlZ1PmJGKldmCdFXhPMV YOgOVocvvPP87j6+k+1WXGTJAdbHam3ttPK5DT/s2XvjdRv2nrES9z1vLZmKWf8RlYB1KfUs qs0VmYwi/hr7XmWTpI0lFpEcBGLuLcn2LzukTNyrl7TcYOfieqmlIO9UL9GGOp1TdJewUS/5 WnijSOKRK/zA+nZF4U51oAn1LUcq8pJcfyh1++hKfbWzrhpUJhVNWcIznnldVZEcRqSU1FYN C7cSOYYnCNfYOgxgctHsMAKz860TBHJfyHKAEiWCz6K2ZdqmwNnFhVKN00epQpgB3SyTsXAd ZjKtAqloWSsjrTYVnpU0pkLAXMLFBAAWVkmOYCbrQ9aQmoVkl6fVvDq2glF2KXS9YlJN8t0N rJjSKloJssAKu1nRitwj8sJXI3etiVBd3CHJAaXZeP7ISU7Pxtw9yQUr4ihX5mvWdoXQeFBt V2tv7Nlo41V96ytY2ZIzpKwImvNQbVgWsDJEmis3Yt3PQCr5qVTz5Qamk+AX5VzrWzoU3bVr BSXgj3WUW2bNS/ZDeWsTrjXjTQuM4FVrJqcGAGjOz3VqOPP1prAP0vjDCtWAs7ad/Bz10UvS IIVY8nRtkj5D4SapkMpXkKFZg+sT/wPNGrAYWy3SfliSXlO4k1xS+GrKNWsYv6FZAyrmOJVK /wyRIceBZhjTrgy/82FehmMyxIZPxohCZwrpd1zjmNVCR+8wI1Egy1usEX/TjMRFwkhcJgqN HNe3MT5eTdzYxkBks5ShjSH0vdsYWcB8fGpFDtlgE8v6OtxjUVSPJ/qUfxLkbCMAUDX9gwRZ TtsubFUoEehAppLpJEh1IFOhyKqW6WAhUyLSinmvQIxusVJc6WOtJeXhcCctxlIT/NHdtURV zQKPMLPUR4IsWDAcMwu8xUoiSg6NahosHWmZM1gYihApJCS+ZGjFCCYu2ae00WUZX/CWLsqW 1hY6qrVWjiIfWBMCsQSx8aF4XRP6++Q9AJ8l+kvXOzpdtu9ssMXicVMRxnBfwRDS2WmbvLVG elo59oaz9xylce0NR8lYqYPYCwlVxge1fSxvq74z2Ddmdz4r/X8/gud9yOV8m/FqDdPhWjUa FsjbOEBFv272tDoa5B3MR4MCKUcDZNIsD7kF68whF0RInKULQJB4MJWyYoHXsGLjBFEtC+WQ 287zQjf0y4rIGL81cFDF7Po07jAJthM4qDQU4s6Bo1X0aWUkC6eLBtDfoIKV0kw1D6/TTueE 587vBDNmFtxC8KE/7chi3OTpJ+czP8XaGPT02rmUv8U+hira8HRDbfjiZtsjvS0z35The++D npv8ZMS/qXGmocIN+N92/ikAAzHJ8BJgRjHuUXhEj/I4vyORnYodNcZrKhZzeIZQgvJhSFuM io1hSbP693FAK0wN4QywppB/xzWOQ4GYQDNR0CGD5DXib1ojcZEwMt+RQiPHsY6wF9niR6uI Gwt2is6+zeS8DxZ3KTEENIHxImUbHUMZay6S6h7budRfCKTQniBGVs3Uhrf1uu0m+lASsSSX Zsldfc11AXeFAPpmoq8M2TnuFptdplEEy5Vh7bo6fuSpXtAUo/vVRYWdH3pocYebGDIP95bH 5XDFV52e5hXE73MnbMyj8rXfXVin3mvKjqxCq/TSUtLuXJU1Zft2D+lgJV0OptTNivwuwltm LU5f+Zdbmovpt0781SI8bixhJ0Ni0DDug/sdLTSXzTnsWAULCLBw5Zso5N85JBRICBqZQrS8 vEYOO5mLCCl8BwqtHFfH349XETfGX/coVNsz8femEsyYIA4VldE9MsSUa/jO2S1PM2nacjce CJGJAO2MSgQwQDhsh8h2P04rQm7amniv5bCWIbUE6qr7wyODfzZjwEeG3C2uI8PfqXgDK6Q2 FBqcoqxwAdIBlaCKbqzGNI/2h1lt/ZNWqxUVdL9RDBXSshkTXTRYEaPvcfRJIOXXCqGVU0Yz ZtzTDnEMlWJNIyxCe1Ko1TRC337vzj6STgfu5UaqN+eK6+XYTYkzyLgCtqrWrBf4NK/fYV1S Qetutw6PtglUNwsXpQmeez/pFMjt4knMQzl/RaDXDUpGXnoehssFZKMyCEks3RT3745TlYKQ nKN3J5muxxB5fp2lVQ15QNI1gd4yaKBhuRXiNu9y7zAEHVjR2vJw9rzt7aUzPVKzEZeYqnMN RnGX6ht1Cb6rDbka2QLX2+Jy7GlTjFPO+4iZy/BnqbyzCnEJPp18i4ucR/Uu8vXwX3jVCcNl bmRzdHJlYW0KZW5kb2JqCjM3IDAgb2JqCjI2MjAKZW5kb2JqCjQwIDAgb2JqCjw8L0xlbmd0 aCA0MSAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nN1aW49TRwx+P7/iPCZU OYw99z62XZBQkWCJ1IeFh2q5Q0CwlLb/vp77JWeXExL6sCDEjOPx2B77s2eSTyObAEfm/qbB 5W5g433692r4NJiJuz/+g3p8uRt/2Q53z/VoJ6vG7Uvih3ED9JFUbDLajIA4gbTjdjdcrHAN kzYoccVmRjKPNuuNmLgwVlQfm7mPofr42fbBwJmdhKH9t89pv/P1hrSwgGr1W/gYTP54Zdfb t8PZdnhMFoKFyRoxKqkna3HcFUogje8HoTxpjhJXvR9eD3/cGT8MF+RIxhSS+ZMcn9GGzwc1 oRz/HmB8QP/eDo6BG2uIaX54fn8QUmEtf1coWYcnpH8UbcaHXvwS0cCAO0EIAp0gK+TImYbx 8wsSCaP7+/nVAFwIx8aZ4o5tlylojXQUEMyEOWKYG1XPLweQSjQcCnUjIc7THrQiUUCA54gS ODJZ75HmtCJqkTmS3klCZ8fl8PIO+cA77O0ttvI1HeYheQymyWIg3UGSQKlKFp+vcaV8Ovnk uRgFn7QcKQRj0GMK+UWB2Hlylym0oU0xjgx5tEwErkwBgMTlLP22lcD3zFRykk4HJuj/aObX tXWLZW1ryQtg/uwESOZ2R0IKobnLHgqsi2i/S0i2MNdJookSIUjkSeJxR0hHp4kmgRXb1Bon pRTD1dmakRRkHFZizk6p7fV2LrJLGtbaJU5iFxJ+CSowklKB6ZvsurfeoJNoTW3iDWGbceGQ +OVKmzZ+U5a6yAQUtvbCLlNoXY5y0AiBxhNXpgTpkQs7WTNcF+SwaF+0ShgfsnQeslVUguC9 cAmWZeGREipFo4JCcQNXNLGSlSn7XJWsOa5O10p7ZtWpAEBJqteyAQBUS8NmUbTkU+f7cWD2 4yDH1BzXfuQtjIPek3P+7s7zmGjp4RCZZnXvIajtmOk90J1KU5UTJdVURGyqMnKm26qM3MiG QwjTSIjzUjEzJdbUJCFlc9qjVOWkReZIeicJnR1t73F7rTyy96ACOFEc/8jeo/fkLlOa3sPE voxBzLNCURnhvxd6kEQBHNJ7kKf5aXsPkih+RO/hjlBwBwYwV6O36439ESWZDlG1BbIP51lg JCbTFsgsKJYmHw1S8BbyCqVAXoK4iitTCtexMfPtcrXIXYssWqyru9So7hZBcukWQS3uZFIY 3KebO2gFOsY43dTVuNGU8yZc3gvD9nQJr7SsE3dXKADX16tY0zBWvuvqlYEQLdzohBOJwmzI q9hNo/AtC5JX6vnlwBlXNYUW2lpCmYc93IpIEcGkLEGibfaIc0LypEXiSFpGCb0dXb26tVYe Wa+4gkn7pKELCc/1yiGQ0W3R6oBnUeRGA9EEc8jtVnlAAcXYsYDCKc+5DEVIQ1+E5i6GyX2k j+lKxvcWoSLRnrIIuXMJfQQdRQJL0V0UuZJ2YWNxWCnqYn+XKZyzCnC6iOBgZYTkWMEKpXTf WLrvVOdK981PFROuyCi9V2TUYUVmmUVHFBm6UU3UxY5AEJJrYqkhZ6erIfEAqzahA58jLRFc +0c397AFsGfJgdWdGvsYgSoCR6FgdjznRnRcmVK4+rQmc7wksNpHNwDZR7nEQtLuXz1T6nCp w+OdydtFitTycB92kStAeQcqKecidw7OuODh5szDY8LxcEYSMUrURSIeDWeCh6cKgaxEx/8F Z+mUUHPZnlsycx7ODEDdQO0qioUSgyGaKq5MsUe/8aagoD58psQdimaLDLrB68ltIDlrHYmE Ivl5pQrP+N4mEnuikC2+IRIBTYU2fnkSl+bUQjkgrzk0yEZCmsc9aEWi+C+diCNJEOFynPeI c1qRtEgcScskobPjss6u22vkkZ2lS3n/hC8o9aHvLGfhzEhV56lUJFTbhGcH4ZiRuhWlnChx PJCZULBdf5YfB9z7zscMZn/l0Zf1Blcv8nR0018b3g959HW9UW6odLXis/sqOALj1ZtrVl55 Vwb0kLEsg2vnzbhB6iLDxfQfL8rSjQRXkxuDVQJEoruOONGF1GYR/W5Ffxfuw0DRA3QlpsBN V2KsdmbXjGuen8ky0Fw0Ki8Zz5i1eC2Z4hBWIpAlhfyT+xZGKA2wgoo898CVEgil5S0Q0G0d ayBIQdnXpQIEmSOmeZaQ5nGPAgToLnAVECRA7gG6AEHmyHpHCZ0d7UX6kCbi9nniRJCIBMFG zz8OL/qFhcuyqnXfVZTwdk4Jqms0368gT4behXRMcVWiJKmowvfXeZ6P6UlG5Zt/mrGs/9Ez 9wrN3PsE5RhgAdxH7gc0ilu7+nO9oYoiyDurS5erICTl57syfFEYvrgMtspq6bE4jx+67tMA YRrha+Z+7ofcytUbNwItlVy99Ms0Q61W/5ZNKo4PedmrPBqrVf57Xc25llQoEkNZVBnxpVpV bfBxZtVVWTU2qzh12worzvrjLXlRSs2kqzPOoRRP2aEyyffDq1lbb9SwF1HvfLZO21UM10i7 hvxiVrl6k6crn1WKrhyYf1yFZdnTdSycutTNjZBiEoJCjzH3v1+j2jqRa0zIWjRq4tQkq0li w79XIkUskZPFceN+4KBu5r/nmiVtDM5JQdexU6GlqyhGPUWl5yPvk1BFXTtvRaf6BggP9YRp ld/9+lXV1tq61mL7+7C9c1H4qJjm0cyGIvpKOm3JBSZ1Jd9cHnem8mwplnlDjo/wnLAB0L/D L5cb1XJymdV25mQpSV0TQ8vwUG0znD8e/gOXnBecZW5kc3RyZWFtCmVuZG9iago0MSAwIG9i agoyMDQ0CmVuZG9iago0NCAwIG9iago8PC9MZW5ndGggNDUgMCBSL0ZpbHRlciAvRmxhdGVE ZWNvZGU+PgpzdHJlYW0KeJztW9tu2zgQffdXCHmJvVuxJEVSZLG7gIM4yRYpmk2N+qHtQy51 kkUubZLtBfBv7P8uJVFDWhrLcqIYxaItikzPDIdD8sxwLDmfI0oYj2j2txROrno02rX/znqf e5ok2Z9cEconV9HWuPf8MI0MMSoaT609i2JmVVJRolMdMc4JkyYaX/Xe9fmAkVRzyfsUkSRI 8SAWJBHaiECtMTUL1B/GL3sJNURoO//41M53OIhtFIZx1d8u1IxngTo1C4LItKNx7y+7WmYY MVpESqbEGB5deaSAosueUDmEIW7UZe+8N/kluu69s5tKqeJ2K4iMPtjJT3uKcBl97bHopf33 dy8zSLTR1ggXD3d7Qioe+r/yCMTwJo9/+Wkl82elFDFSs4gngujEndV4wPq32f7Z4Uqa/lEm KzsXFf3rQL67GMQsM6Ksfz8opYsB798sGBGBVejzdIF8O0j6H4v/pwnT/bs7P34K0k1gEUZ9 VV9BbnM/d+CS5kenLVfdgTtEMK2KrWWKaxwpR132Jva0l2+/zQlBuLIjwjPIKCaZjkxCEmlY cQbRwLqmRidNUsJbS2LlEV1L644glkTSnHM/xB4wlqQ2AuBem3Rt5ouknIgiZ+0U47+B08om 8zynHWI4tT90xuBUMRzphtOcpkSkCzlNutiHcg7GbJ4bV7timCOG/V+HRNY620MiKPPhB96D PEceImVsEpbjShQXvA2lng9CZS2ACfJBKGFcRXfsx5BiVDf5IGVCpKzmbB5lqtJK1jrER8Bs 34MjHWUtT2xFWZi1s0fcRHsgfXtEJZ0hGGsc0bUWi6DtTTR6sj1oK00gZ76BFKFSNaPeoXaz +TpeZWzIYcgr4HAd6STTHIcbMs1QWsk0h/jbkFOe4khHmZYYe2c98f3o5vh5P/68HxvvR8f+ IGsBKXO0ZD+GdJK1jquLs5bTRM1nbYlwxYWLyV7sONJR1kpJ0qf+pLZeyd/L/naaIHY7IP0Z jOiiSrk9TaxSp65K7cMc242xvAbpEKRXkMlDwMaBlyxmFwwVWSix/ThPtIhikRLJ8/T4N6Pe 80OhvBVnhMNduJc9PqLaaHuP1vxxSXhp+DsYRiCJEKOES9V/3wdsD7F7PygNnyH+ZKn0EOpP zvlz4rN6MDcA3SKzqWWzFVoVTpZtUSwUEXaT7e5Q3WqTR0+3yaOON3m01k0eLdzkJMmeccb5 5uRbE4x6C9IRMvdFqC28XwN0j4Q4XbKSQhkmSt2HD8TPdVp3MkKcvKibbSCHsFHfSB/lR5A+ ZZLtk9L+JUhHIJ0UTjQrRuTYKUgRSMdg9x3RboB2K8ScVLDFDcnzRVOyUrpMHpMurDFdvOtX YeI4u0aec2SyJZ7nU2hxSjan+KR9pD7ploSKZN2cw/LE3TkPERZ4beE6BycgSZD84IAa2Cxb yCzzvp2hLNpA27ZReE2yFc6S0852YRlnPPGqRaTYhAU1pKpsriEvEIw3lr45vhR2WwuOo+ol bctEf76/tmTO1qKYKyewhZ1pVDuCVGYvsqCKL838gyD0WuZLSlJ47YVt+HMkoTRi96XOf6/8 FNKhMPPVdVpnCHYbBIdBkYrPQ23hhSJKAtJvpdmXppLhuXqKSLdwOL7034WSO9k/kOO8AGkK dl57D9I5cr14O18b/IV0jdjdIV5uIeOh+H8Jw3MDTpBF+vpygSzcT+v9iRqPhTF24hWusF3Y 92FwZKtTesGBO+kMpMt6D3MM0lHdDOtcTktlhTSVDuMOkeapX41kitjdl2bnyBRAaT/DRTgy HFA5xZuAMnWqeu20kR+e0neIl12QFBLBGULze4TSX+uU9gO++8u1RsF2pXQfYc6wcwZegnRT ntkJzruW1apQLuNdcbmslJE7MPzgAbswDddZS46v4ZKrK/DL8xy+Ls3OkLk+NX0ewZqP4LqZ 1s8D+1TmvZzXL7m5C7VQ7oQQTodK1fWF3X/m8PT2n1J8Jf4H7LBPLvdIlt4gs7l0cQ8EU2Xy 77xoS4XiUVuJMJGy4sGaNjx7rlYDyjErPGhLSCp1Ov+KmyYkyR60iewNNzxoixnRlCbSiooY zhKzErhEverDrIa4WaqIKr9O0z5YAaButSwuVAGmdsvNHLhE3RXIAFSP9dmoZh5UXSyDJkm5 nUwwt4wMVB4MLZEx7cHQe357MZNVUHiv9ijnWJTMq1WgDlJcm7SS4iVieFJ+I4Ry91asinSU 5EwTlS5O8tVfgjVMkr0Eg8fLsZ8khuxaBXzImAeDGYFjT+AQXKLuCiTd+WxUk46XkdE+9rng QRKC9ZRExyxxuQwkjxveOg7yWO8PWhtSWpRQpnid6BHjmoWykGCIMiu+TmzI+tTew+7Vd7/y JQBqm+CglF0Bwrgqv+bJhMaRjgpgYjvpZHEBnD2oy+miaLrAmOT2J9LGPCSuZvAAQLVCl7Om 1mfW2nIXwKEHBYBHzY5mS7xvALjnwRGAk6rlwlZh1tw/7Hr1EEDhwWNXM20ucN/GNPcps+aI 9pdMedS2GQuWtg/g0IMCwGNs+I0Hb7GJdgA8CNcWfqXc1RFf/zwC1c7VEQzppP65BG6of0yK Sv1zSNDu8TTFkY7qnzDFF98X1L/NTmqZm+T/2QCuqSvcXFMDuLmuBnBz/Q3g5hN3Y+jS1tQA bs4VQFdIggIICJQ7V0gwpJMC6LK+oQByXW0AHZKI8peqmKAaRzoqgEoS3tAAPsljrjWAbTql twBKTD0EcNuD2wAeYv3PGw++wXzuAPjag4cAvsJmH3dyB7lzFgx+y26Ojf8BJYNXc2VuZHN0 cmVhbQplbmRvYmoKNDUgMCBvYmoKMjA4NgplbmRvYmoKNDkgMCBvYmoKPDwvTGVuZ3RoIDUw IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2RlPj4Kc3RyZWFtCnic3X1bkyzHjd77/Ip+nFHE9Ob9 4jfKK2ktS7JEHlvhYOyDPJJWuzEjh2SH+fedWYkPQGZV93SfM1zaFIPiAI1CIpHIG4BC/e1k ztadTP8Hf7y8PZjTL9q///Lwt4dy9v1/2w/675e3008/PfzD1/lUzzWdPv250dvTs20/xWTO JZeTde5sYz19env49tE92XMuLrpHc/BX5L+en57D2YdSg/q5HP1s1c///OmXD97Ucyit/U9/ bO19/fTcpKjWpcd/HD9b1wWln+Vhu/36s08Pv2u9tdWeawmnFPO5Vnd6E8xAnV4fQtpQRxh6 6vXhLw+//8nprw/fNqUak1xTxTme/rk1/seHdHbx9N2DPf2y/ftvD53Al1oa0fGfX//iIcTk NP83wbAM3zT57an/8/d/eQjGpf6zzcb0n23wJ2/N6e9/evjzTx42Yb57KKdfb1LcJIEwtMzQ 1M7wm7uMpZmYNpVQ0zn4cnJNpuTJVEIb48efP9n2Bw8Nd83WtOk61OK6JCH7Jo2jrpFyb+lS Y+T2jPzoUtPVr7fhca7G0fG0KfpNMMUmqP7d9prgxcbNkJyJYXCyxuXOqWHM4NQwVWOs8XbA oS7wJs3Lg8LEQQEOIRCcNfyi5AhkOsX6CVP6TBlwneEhVefBGDco/NS3ta8vbUKUBBpbRv+L qaCyJEkKhCmMAacxSqUPwwQXwJAtgWuuM0XOM4ec0JuE/hZoBDTRQw7QOMaAr1skcWZux1ZI Bh6WJAkLPGuoa632bqn+davxQdvA60PNaBkWWTO3vVlFzXGB55Zf2hNz20IxeiMcnIXljSVh st6kba3LgR5nxoBPXiQZo6N+L5AsTRqQ3hK8aOjl4c8P1m6Doeear0FjXjsmaUyDMRvdAqPH jKHZyByG3UgbgWQXOWBZDTM/YzcDF54Mc6uCcUQxy730tVuNdZZohu29dS5O831VNMUzpmhM 27/NAtNaUyCbc8R16F4oxugJh4z1qu0gq0aAiSwHnnKBMcTXQRJqd1ij+t2wZMTDkiToG8OT hjat+TBppGktGLNojWnGcxsmTJx9cAu8yiYYu1B4gr3u/2Z5ftERY1iP/FTOjJlHg2EaLYHZ wiF7gSRhgScNbXMtYj2KibRWZot97Zh5bhW2WTvDgUZDYTJRYO4lgqOGX5QcASMTPWx+9Ddi r6RWBfbMA5hAFE73be3rZjWxOD2+rf+R93WMFtOUwBhoduzbsSRN0eA8a7phih4toRj7nHDA ytmkjbr/rxoTWQ7CuMQY4uPi3A5Zp/xuWbKoNdBgr+fIqqFNa2OL5d50q8l2Gb/Cc7Qwhlqy ZBXWL7DTLXc7stPsEwrnZg4Oeh7b8Gy9mGuJ5aDRy4JxevYpuM7tYJdSGEgSF3jSUJ9r7exJ x3B1Gt0kGU+P0+jYbfXu52T9IPtrmKgxTnZDt8DUumDG+AiHsQK5ZUV6UXJgjWqYiabB05gL zK0KxhHF1JO1r9222mVisr/WfzOvN6+KBrtfw0xrXYPTAi/j0TBFj6lQjBkoHLD7DXtZNAI9 ixyYX4Ex0wyUdscMVL8blmyaOdI3hicNbVrzIer+blZTF60xDXY/x7sOceY9hWGzyOZ9naQX Cj9zwO7X5LCLjhjDepS9LjPGTKPB7dJo8e88nrIfQhK/wJOG+oz89tRocjy1aydd9R0u+jZH Q1OTpqF3Q4Qx9cdk/ZaoXXW4aEL9wGxLCU3t26iSz0QViQoYkuUOKiwwR0tOuptqKNiWylQD 43y5l6pUouIWCeN8upPKhpUKmM+hykQVmSoTVbiP6opxHSppp3A2rpjzbIqCSZaFijgz876R YfGReDZM1pgGT7cPBdMcURhLFJPXQ7WBFYLl4NkdcXqnfSNib6R9g2HeNwTjiWKWc+nrtgLG VJd9I2Kf5xUwYifhfSPi/lKIc3YLPO3zXTbG2JkiU2+w5+Ek16R1q0aA4R2d23WRMdM9osFB n33U76y1PJ2fpG+AZw1tWkt1Orl2q4nrep3qtENtmOnM2OCwwF7L+tKfQP88UUz9VRwSWx5G DxoRjMgx6f5VtVMgyXRLUr97lsxPI859K5Bs0tB2kuPTH25N3nhYKI2xN9ihBqbB0Gte4Dj4 KownCnBwA+Y2oFWRAxrhEzPNz2KnO7CCPfMwWg7FIRE89XWzmgJ/hKPzvytmuTW5kqzW46t6 qhDnFBY4zpp2Jc2nOIHtwsFwb1YbEUxiOWC9mTE4tUESWHyY23WsNeYBSfwCTxratFZL1f3t VrOz8VpxnnLA4OZI877yDQ5w1LK+PChMXCjywqHA8jzOsRnWyxiRY9L9q2qnQJKgx0/9Hlky 8IAkZYEnDfW5dnt8wvqGNmEKUVgTz9k2jt01gGjW75+em423vdpRkOI5n0M4PbfByGlEmH7/ 1PbuNnb18ddPz+5cnPGZiBtUGu0WjyJaZhe3P20K9fGrwdmdU+PczCmVK5zjRmzO2Z2em+Hm I87tsdR2zMefbrTx7JoUrVdxT5s2iga0bufOcyUYHdk0NkI6z21l6XJ2D1HTxEb/s6dnrymh 23bCMU2hbVU74LxXQNN765RtGzgYf1Gv5nhSD1Z297GPiQ757VBUM8WTeozM3Bili8kunDI4 3Rcj2wVU29YUfLHtNGjaH2SCKsD5Kw5mHkXMvB/bsY909AlZ9fCWnikOceHwhT0LbWUtTePB tS7maz07Grt27B5LZhlLTO5jl0y8o2uNRSAWfrDInUWgMKCjaBo1EGrWDbRbtNEPh9Y7edjZ oTUb/Ka13CxSIpX7X7OEH79Ip66dHntM1eauW9Lpz54QNo9KkYhy3qSpMHyHNjqcjhmT+VrW zGJcerflcvPrAWMLX2xsHOcUayviM4wJTNWU7wln+I5DGJwI+hiV8WRy4MWYrK7Zl69SyUBA utd5OlxPInMAuowfx3278alWDStuXFg49tTuo4a5+xIa51r7KNsxzP8kU+doKXA1btZetkNI lyZAmlvnS41xcAjEgcPvX9gf3yN/sSndWMkaUf05WgBsGv54TCI/JQPclAWQyIYnDh8yPu1Q 7OPFaXi4UhvyGAU/Dvg53dmdYw4f0R3fzse+c27DZPKuO2p0vj21nXpMNXKE3bfMjIPylp2x 5boAY7dUnGU2tvWb5lfdyH3QFr3ORmwYB9Rfqh7TDjd90W1rScp76/3sVTeZIfHW900dhNny YLZko29YRYpqUeP7a+DE9E2vikUWUbiTPC3y1cFRQhifvFq+nZ5ab4KJRvxlOWECJrgPCBNN lpYXm1p3grddc5PAeXh/ZIlvjSSNeU8/C/nbTm7dHPt5eePyLpg7mlvJJ9cxb0m+L5XboCUa NGDaVHE7ofCbCzRox9SLorMf6ReYfdN8NGsjbbuz+rc33gChi8NGDs8DhvZwVpgs+7j0knrm HLDdFnxIjUQvSx4Rn8l3EU6Vz3eWQgY+06Xe04/fcB4aHLCKa3+SkssOfu3xOTPY1hHbbiy5 SWfIl1KHp6//RufJy+tqdTRGdOBRR7OUd5OBxyjlwGM0MNnJCosByM5fHpK9THX4R7djAiVQ 8vlvPy9tLXR2Yzc4MDlcbGQlkseg77EozsfTY61gMLyldCI1GLvtgwan0dqJVrHxYwiOxrT9 Fu4e0+HoHdKTMyS63eRuR16vf3tTmGwvj9bRYwdnZ6id4owiEmOuNHLlseCyGq3h2MlxNvyj cQgjTqVp43sKZfXRQ8cKtWH4k3wClQ3k/z1SO34LmHjH1Jf3lUDurIqFbxVz6GZHxctETZdH 92gxtuvs2i8eq+lNPcZ5OTlk+6SjpWYVZSGSx1yMFxvBb4o6GVmhrq7AvPpfX4kpb8yPJa0Z pp62/CMFzdXqz1b1fa5g39/E8/4m64RzJCVOJCGPi/e8myPOragoJg3M1JcjngOTJSp+G9UN wXdhoMLx+30I3XLIRjrq6G1UV0/Z3uv9Q8Kw3qlm0gj/Afe2e46i94Fwjqn20ftt75t4YTNy TnZKGq+26PndCNqdsvBbrUxNAUvCTDwdu4sq+uXqLcraN7MsgxeaSSOG6ckDNYmeRh6MDxx1 YkwqN43gngGPgxqbHRW0Htzlo3Zbpqte1PvZyYzhi+patSz92ysqu80A+ZOiF1Bp9bcj2aAK nCdcjdMY3eJ1XmsXj3mhj+iR7Ji6jzaMPNPrVOpqQi1mP/LesXu/d80SPx8t3g0zZlqMckKk Hdmb4HaG6C+O5rrWXlrir62+0+Lytkv6oBm+S+0oY6GLZXc/k9+8v0Z9WSjKiMUV/vpFmKlD xLV5ef7+5g7kPTjpHzSDzB/ljzig+sJg4WZ3fV8vEs/4WX9nLYUegfrHp3iOxYXw+Isney7F uNh+3qJc6ezT6bmeKWwllOrx/yZ//qenZxD8xyPSb4hr6aHAZ09c/4lJ/wu3/4089Olpi9RH T4+3S/W5O3Vqj9chmtYOfu2UnB6/eoqbhzM9/obidKYRSw8UXyXX1yzB3Z1pK30P7Rk/+Kvg p3Tmp/y44vkr7pbieUJw0Wihv3pqxhHalG2CNGxbzOpFmY7+PGEw9Vj+5uj5T089dm5N0jqV joie/jP/NdTQ7N70gHB/XXNjr3qqJPmtFupZzO656cKEaFVXPyn9tEFsl0LbhQpNN9lXRfjf +edvrvh7b/K7Y4VX96z55nV45KDjyHaYODigvH+Y2J1Rdd5kn/ufOe/bFEm5CZ/blLA072WK /6o7gmsw1oXJVtnCZC5pUjVu9/z59cEk/6+Mk8FWdvObg3Xpnibft3DE4JtI6VxMTFcsfETv s6w6h5I+Px3MP0X56XjWf7SavnQm4BQjM2Gkk82nGD7/7PwSvkQ5eMpBvsxmrqn4kMNUjFFU EmKhSHXMY4Of49g738yO+uPi2u4cbTn1fLwlApVD/uK4djs74FjAGDnRwIuZDDtNgbGT09QO nOV3gYBJclyh2EXDYTFijDopkycuJvbeMCbctOZRBKcxXeLak8hrXDt5ZIXZK5E0RT2SXba4 9kfEgRHXzmkfBw7OHOe4ILCdvB3Jc1tg+57IKQLbwuGjAsEIbOdYJRCsO3Qtsg0b/PzI9szh IyPbFybitch2EyYMYT43sj1z+JjIdttu+si3ebYE6nt3PjCynWFhvNCMSFqbofs8E0S2QX5b ZPuA+oMi2zmpo402X73wbur5bujF3FHhAvHn5JHYKhj1/gj0JVSM0U69i0uiqr3hkgX/zC1O 6+VRxLv9xvdmwpBXQEe8Y8nyUgZhjHjz6cLcqLBJM+aGiDcW77ddc0cRb1n8EcKeu/duxHti MMl9FPGWLQ0h7BubU+Q4kxDLGMXlj4h18naJYbfnLka8k0lXqS9EvNVYH8zTNZqK3yTiDV1c jXhPJ4WxwCV/OeId6shIuy3iPVMvEe9QAmXEH0S85cd9xPu48srVciqIjgaX58Cpio6Gfr6r d0ZHcRRSh7bk95OBSrbEGJYiLjFUOWLTSDaeS7gsRvHz8TBF5EMcDdzFuHg7L105P65x8Zj4 7S7GXEmjUER2ecw6tYrywSBf1h0PmfFlHbJLcfEdrYqLl1Gf5jAuXsZ71XeNfMhVvLGb9MAc xcWFWjDhsu9WPeb5MRjHrhF4epVIjLnSiHrML48VyblCXDyEZCclXYmLa9pb4uJjsYjsoz1Q qPLOIOpA90+IfxQXb6ztjvqeuHjwvNktYuq4uKKCJXpbL4/u0ZK9u1ntl5jV9I5C1m3G4n6e jhakC3FxteYQJuS0V6v85lZqiYreU4wqOryvi0JR0WUUi6BSUsCg1FR7pi7wUoyqYUbpCOYw dkJpI9GLRkoOahWlpIBBqakGuwX24MGYOCj81Le1r6MYVSAcgjMoRgW+r1ywKjqE1eSpSgWb 0gJnwPS6EopCRTdClgp2CweL3oAHHJsoT9UwLAdo8D608PUkCXozYh3qd2heeJAkcYFnDW3F qDJLDyOnYlTQ7SsXrIr8HrM8NTAo6CRwnGTtJZ/C1BtFUWcOAcU0qPTUZL1J25qUnooOC5a0 U0kSP42f+p3LZMVJAyi01WCSbNaQLkaF8ZNiVDKiKCUFDEpN8UwSmKxeYSxRgAMV9+E2oCOR AzqiUlL8DJWaYp4Ce+YRJ7mEQyJ46qsuRhXllRAqRiVzTWhqZAxxGrMPBZ1AgZJPGDspRoW5 pSjswoE1ko3u76vGYGT4KZzuhK+HZNTusGf1u2PJjNaA9G1EdlcN6WJU6K8Uo1JaYxqkOqBg E3Omgk7cMpW4ULIJJiwUZImjCAb6L8WoJuv1ix75KeQIC9+6SEKjJXBgydw04ty3CskmDeli VJj1UoyqYbiIUMoag1QJrGEKJr4K44kCHKhUD7cBrbIccOGjlBQwKDXFc09gyzzs1CpzoN10 6asuRhU53wfFqNTYMA3SaFCwiTVNBZ1AgZJPWDm3kk95Gk2mKHXmUJZiVK3/Up4ravml9BR2 glfVjodkmDmkE/6dtcY8SK+FtOSmYlT4nYpRoX9YoakYFWzglQtWoWUpRoW5hIJOBzAsmopC cW8ERtEozF5ojV4Kn6wXGMdyeD0Wr6qdCkmmuaV+ZwtnHpAkLvCkoW2usaeSEiVx2p+yKOWO uBIdZVNSfavpoj5UEqpcTb/P2/H3cKkbjsJQy11HdFS2kmOD2y28qMEFjJNDQFxgVB0QjCUK cDAEew2/aDlQD4FqcPEzJk9Ll4I985imk+KQCJ76qqt4ybEBVbxkAxQaHBtQ6QqGikpYoMD4 yDaDalqYLIrCLhxEI5MOXzUmsRxYhjJjsIBAMixlYW4XW7PiAUmmzX3VkK7iJccGVPFSWmMa HBucbPJkBXwIICsJZpGNqmmx9EKRFg6ofUY1uybrtYse5RBgGGOm0eB2abTkd4yn8KA5wEcR SDZp6J0qXsg7DikuSb+hqpeQKbm4USFXjwLvwBzlQCtqxoiz+zaqG3KghQEwMZojoYaeDKcG SkeDEuoGqhuEggjHjv418SdG1j5jjMRdbqK6ITE7WEmLHGmVwai+U2J2kEpHy3M6MVvxosTs ww7yb6HuqFVK+C1UV/MoRx54MJzkwD7bklY97tNHQor+0tgo7xtleAOjeaqWK6vxlpjdQTOL 2+9CM5QHrkdwlwdeeJdmTEg3GcyeAQ+7MpgdFbu8r2QOI0c6eMTCOA88q1yfxdUpWdna+Ymr i+iFqZT6OQ+88PuXyN0uKtd+MZljXmsXj3lxHnjmV3yQz6T6yFmCGRP7iGofsPvMPHAJra4p UjoPHIGqY0NUMadAU3Z/lNW1Dm+jGlua5ZeMgOECtLdSHZxY5/PpO8diSqKO1i0FFaPJSuCb qKjltpfwOR6yyKvFfC4ycmynM3YVP/w1qnLTFiDaS7uRkKvHsve/7Z6bswbytEjLthKDXk+v LdvTziHp7zEfvOXOv5U99S17M/Lh4+YMfy/mL9Rrcr/OdrivuYPeHYQrl+cmiyvFXKb6mOT+ 1GZ98j98cn87SNme218/K7f/2Zp83rLk/p9I7n9ue5br2f3pXML3keCPUmP/H2T4f0haPYdp 58Dt4QlOvfeXD85775/NdteetmLd5+2IcJGztyPjngb3ICrHAoPKsrjZKpjuwwpjiII4jG1d 2ohSadXoJ6T2LPOIcASSt0NgeDsEE4liCoqsfaXas/AG8NoNZyDf26n6qvJ2RIQr6K5L9VsV jLsvywZPC92fhcLMHEpljbhVI4xJLMcUNJDas3B1KtgvsGPJJses9A3wrCGqPTt5c9649qzy KSR4vPCKLeqzwiWM+q0KdnNLqAELaRVFmDkghIlKs5P1IiQglWYJg3QP4VsWScj7we1Ux5IF rQHpG8OLv0tqz0qQBHVhxamMyrHAoLIs9CpwJDtRGFSnJQ5j4ZE2UAVW5MAh27GjmuYnVZZF KwLzDBcMJayBA60RS1+p9qzV4/3GtWeV1RSEKHHGdOx4r9QSgj4MJz1WW4VX6N7MFKXMHErm 3oSdRlY7ooq1EmAXvn6RhLx33A5CHsLDQRK3wJOGRu3ZOnnipPassmiqvgo+Unu2YabKsQqO c0uoAcvznilo7jEH72F5Ht5Xtl5guGIvP1UEM2lfwXWG2e/LPCokmT3Hi4a+vPZsH/TQXytr OzBXFZPDJVWTbTO+v5LTpt2lOq3ttOLCVnHWv1+dNnRuz63Fck9xWvdubVqq49rW5/J+GVe3 vePo0/lSFdfnvh2FU7OVQHKKXgZF26R8P2ak9edP4/Sc+wnu8OdnG9sFJuw4xv427LPhFy/X kXi27ZbUlbe9qbqQjJuAa4wTf6Ryd0/oWYZpq8XS/7PReNaMUP/28DXPoA+Pt58ZvaXKOwGX dW+p1gZhvKVPAIWx4TMcLS2qjOHPCTCmjuuXd3NhK3h9ATceKwVzKFOr3vilVe9xxWdMGIsH eoLyDugr4BflOnBOHCD7Mimf/25ooALS3aHD75f8wO/s3mYX440oX7gInS1eY7wzQ5t1+D4E zhghwoiHTDCJ7GLkCIZgyC6GKxJw57FSEIcQ8gwjoMOYgmRdwVSyC0rwrWPbQV8Bv7zjniof YBc9mmfa4h7b7sFVne+d7c/e97W3Xc9TX13vXDHGwuz92B4sOwLu5fDcXxLK24XYy3pK7/m2 jaDdh9pNS4qUt9a69yFfo8XmFvrN3bxLCAX86uHTT662fpv99ytpGJGq7UqMopobxjpUcWyY UVPCwT9mt9qiCyZrDLI8GlwJdsQVOSx0iG0Y5G+g3bjAmZ8YPBPqQdkyPNiWX5CvduSEWv5m cKVcU2CqDYBHdiNl1jYedASqm2CBuQ7//waHBU54YvBsl8aIVoEZa3S1BfDg4fwEv3Qfxtih IvJdbaDPZkUUoGk0U8p+x4zLUztAIQPUD+kUxoUJUx1TlBnGBRrSS6qJwvjRnwh4ZJEiozfh o73occOMrFFnCR5uFGgA8IvkGiX+cF8ZK1rjgSw8soFk4K9mjDXI+6GXwgxZovMaflFvOmG9 dlvpli1ZnjF41ZA/5hIKXlXERQDvOqqngBm1VhpsCR6HZ27ZIIcO0pnC/fGEqTy3KCWCdD1h DPURb+ck0kHUcBsN1jbSIar36xj7OtmBsqViVnvTmKgxDab3O0Yfbaj0tpXBOMeR49naoSzB 8cJag9MCIxOP2tAzgTGBWrEED43wbMJHfGTG4S1KaEDNWlemma3XE/kIItYc1OZpmKQxDS60 TtHaR3WDE38gtlBNHqoUiDFHeUIF89wgnrwqyxpcd+u0YLLTmAbTqlxhn4lgJJaETO3QdS9k 4kkXRv6dr/PU6jgOje/CO/LHArdFETerqNui61iSuk3sDsfBZVs+3MZ3pLQA48LIFK3bMr3B brSR+AnCUIHoxmGzEWuGZbowLvyAt94mwlBvSe5SicPcj81FEIZDACtD79toJ3lKCwqRXoOj D3mF7DXc2x0uhIYZ4xLxyie52miGYK3pjkNg0JehzwSnGVYaccyEmAhDfYPcJs4wPlqosh3H wbVXRUInGUOm0g5ztD0Pkw3BJg2/PAQaQKFIYeIAmAUQzFjumYMfScvchsdLLiwFKFhu4rD0 42V80eLcX5C+5Xrw49XDX7Zj/S9bW3Rw86j5wRiqaBd8pJJiiXpMFbUDvI1f+n2UHuOzW722 d76PclR1oYmH2I/DEAHjqPNjDfNpWH7ol1UFd4WPtUUoops4MIxPiglmnHeZQx67HLeRseux FKBgKYnD0o9hqqdf3minP1YlsJ16ug4U5EODFpjW2tjycwgabubL113GZZTaAybEmLQEMRia SeR7J/jDrL1vVtburf3go1PtgNa/u7W5CykKTm5KH0N3iEwfQvnbw1bFvucKxXxGfXLC8LUo ULTnAENP9Y389z85/fXhW4REt4VzV2TiJjfLFmrtrTmSyCcqppASuxl+d5uTYahFKbS7j20/ EIhCt69yuXaFH3+dnp67t6n0W71//EPH/+8n//iXJ4ufROmRRqzJZdO4lD/ap0//phtvmmjX e7qw/4en5ww2z91xkEfLv+WW/8eTtY9/Gq1a//hdGzrX4DRwf4UU+NG5x/8JXHv08V/7H/8L Qv8Bz/yx/bsBf3+qG9AfaGq3NW496zzoqa7iYuIAFdm/yp8khe2we/w/T7Yb1Uy9Pa0eEb5b P4h5Jtwf5qaHivuxMbHmDlvZnvsj9e/vTSJwT9u/f9r+u/vc2rNtB6Du4OlxJ/jeJftg+Lab zeTuUF9+PNxWLO2YGS8rhn6wUy98bLZ/Y+mXK9zuW04W249biY9eLLUteVbcrm4YX9OvudA7 qhPt6aWc0FMfwh2liq5w+MIe0Ye92v071/d7dG8RnmDHxd5mpMAFF6rGBD/c581U4gQnfG9T MCMeGxxdLKhuQrAlafjlxvyQJsm41Bre4wK+TYvXnkLA12sHJgR837aaGcZLaQpD+zh/u5f2 ef62L04Cbv4G+GvHeI0JLsw8BE7Mw2k5FIdK8NTXvtMHh6/bxoix4e+ZJ0hC36HlKnKBypwA Exx9h1fgQjBOy4JJC0UgOBHsuTeZ5Aiskazl3+QgDHJImK+JkIR6M/Zc9TtrDTwiJIkLPGlo 01qgEv6W7yhwHBrkXITAX1JOjDGaUwi2LnDRsr7wvQBf6hU4mZkD8hZCwJeUxXqBQS41t8Nl h5ivtZAk6fFTv7OFg4cjSahvAk8a6lddXSWL8sHUJ/gq+QXsTa97rOQbg3GHKpIh9u1KTb9J Qpot8pmIg3WK3oSyOUtg5twDN6YdU3Z/bKs8fU8poai3YOi0Sx93byvZ0C29tA646daSbEyB tQ0c1rVOMMNZJxzs0gbPR5YCFJASHOZ+bFejntHZNpPvfsS97HcfOCv6FWjfUUOOAsJ4Sk2x cXhWBcZnrAUzItaNw+gGLvd2eIX05V5ODWYEcbaXTrZamFmdGj783qEPWa3pcYHYfChT0/3e 8AUHjrB5Yfpn5c6GPzH56em56qKIt93Bh4jW4iNvwVPVeMKwZ8UZO8MIJCll+5IXZZt/L2VL 01C2/Shlt2Wxpwm0fakd7kjZX/WD3VF9UNibNcNYZ3u7+wxOJnTA7YtOrDAg27ZYruWa+Or5 83aLuXAEr5c7d+NR1nwfHeqXitSP4C5IzP4jj+BmJCLKRPHVTxPFUxqiNcNFKjDcQoIZpQXb OjbiB2nYdXAUX0iIJ7Qt1TurcX2CjoMeP0Ve9C2/W8GlwP/PmDBmZeOwmegIbnV4GBngef2k If8h1k+ylY9fP2EtTUX984mH1nI8ufHiN8X7gz95Uz97cl/k9oWTO23X0b7BRlxHN4+FzGvl F2pCuJ6k0/8fX4eHA+TYeU3Z7hWfDAMmGdojyLOfjJviC4AlviAUKUwcCEYbEl+INZDnlN4e r67oNgBLfIEpWG7isPRjOK/vKRz849WEirSAF537GVMy+Zojvd/lqccj0gL4y33PYWy/3bPB 1vy1KnO8hlqUaYfNcTc7ocljh9RXX7Y3wNxZUl+PP9EdLJLGx4WpLfs9Hvn5zrUDbh/jXCu5 R0jbKEW1D1K3fytz+11HW8zIjug3yPgZjrbGIQiHj3O0pZKnjM1beve5TrcYExxbjl5aIkzw nijIrQU4WVy4GOPJFUKBGsoWCpTtCPhep1u0qIsEh1jDsJOCXtshDFxqDfYLzK4PxsAtRxzI HcZtsJtO5GD3UZh5kEst0qfAFCxuqllO4UCOrrmv5HQjGnx2Bk438H1lx1x0yJSBY6ph4ELL mgKurQbDaepQosW5hcLMHJDzABdb5G+iK4y4AxNJL5iiMQoOC+xYsqw1wH2jz1msGiKnm9P9 E6ebkpbcTpE/iwHHVLTkECTHFbdEF0JpibcIm/xCERcOsqVh9NihBgy7KslVF51lB6GdtC+w s1M7TjZb8HAUbsULf2QBi4YWp9vBkoBKP5TSdZN/K+kp/6YwI3EqWCqfl8hvTSdwwJvnx80U WEbAYV1WBOPh+SEOLs9tOPH8pJkCUoLD3I+df+tH2su9f2vtqKFXtAjj8XJSGiF9hqla2ebf Igx9B93g3X46UpF/Sx+p9v4tT0UTfwD/1tR0/ED/VvcaR5xivsS/lWjx2k7oQWPkRI7MJsB4 J+/Iv8U9/vf3b3HT9qOUTf6trmz+jshXcpK65uVqWnJ7q/tcL9cBtw/xcmWnIs3wcqF77/m6 jrt4j6/ro7sF70Vua5at3/MpmPxeMoHg9wIGXq1EDmKBeX1jDAVzye+VPF1Hye8FWPu9gBO/ Fz+F7FGfzQQHPn0zJiLtcRhtoJMlFoeAk+WR3+sHWFdhNx++rrLl9NcYb7g/3bvaOlfWQZuH cYsSElVN9QyX5uzkvP31rSN/QY7nXHs0qMhylthH8A9PSFr7+dOzP4eYU1FIerkp+1N/Owmv el55vNq4f7xs7/O2s6Z3xww2x8WOw/oVtd89/F/YcYBRZW5kc3RyZWFtCmVuZG9iago1MCAw IG9iago5Mjg3CmVuZG9iago1MyAwIG9iago8PC9MZW5ndGggNTQgMCBSL0ZpbHRlciAvRmxh dGVEZWNvZGU+PgpzdHJlYW0KeJzdXVuPZMdtfp9f0Y/bArpd90veZFuwo8iKrd1ECGQ/KCPb sjEjw0pgI/8+deHHYtU53dO9O4ITWZA85OFhsVgs1oU87L8e1Fmbg6r/4I/H5wd1+EX5948P f31IZ1v/1x7Ivx+fDz999/CTL+Ihn3M4vPtDodeHky6PfFDnFNNBG3PWPh/ePT989cYc9Tkm 480btfOX579Ox5M7W5eyE4/T3mMtHv/u3acPVuWzS6X9d9+U9r44nooUWZvw5uf9sTZVUHo8 Xjbt6SfvHn5TequzPufkDsHHc87m8DwwHXV4enChofYw9NbTw7cPX350+O7hq6JUpYIpqjj7 w+9K4988hLPxh78/6MOn5d8/P1QCm3IqRPt/fvGLB+eDkfyfB4ZleFvk14f6z/d/fHAqhPrY uhzq42eBia5inIoEdwZOpSzhxwenlZkotLYTB4Z7G/UNwnhNbxAHb93UBsHlDUjBFCQlOCz9 eHz4w0cPTZd3KvBHq49vy8CroonxxKq1h522msgVPXifQaWzTxXniwZbq9EetDOH739f1U/2 mw6/akOgyhCUF/L2BVtfKNxUo/zzgzG5dV8n43rjAxMtGn9xOIt5pzqVy5w0WlNni2Zd5WS0 os4WTJCYAkeC/QLbrkqB0UQBDopgJ+FHIYdyvdVUBRKYpDJgv8BkVgLTdDc49L6tfa1DngLR qEiaTLWTgm+RJGjC9DGpGHCybahTcBNFCh4wZAvgav1CYRcOBhqxG40wJkMOC+kZ44CZJVEx Tu2o6CGZnTTAvVWRJJs1VLWWI/cmwGqsljbwVGi4ZQMMt92sIkczUeQ4t/xY3lCTtIIiLhwi W57dWC8wCnJAj5YxPJ56aodGRzz3kMxOGuDe0oivGiru9kHrNhhyrtmsJeapYqzEFBgzJS8w ejwwnijQX0ewlvCjkAOWVTDzO7qvicxzwJF5mEku5kByL32tVqNNd+IYzdJ/3b3dmGtMQzOr YYiT65yNjpKiwIngRLINTFgo3MLBcm/iRiNxGRm8pZJmTCKMmtqhuSfgwJJFqQHuG82tVUNN a2Udkv1tVhMXrYGG3msYPXG2Nk8tW7vKZm2cpGcK6h1z6P2vb6S8Wi8wrEe8RbpumHk00C5G azxPLFmeRhx9g0UsGmpzzcMfaUNaS2yx5MV1d4aM0YnnRVxgGg2BsUSBeWMINhJ+FHKwP/Im S0yBp9EUcAYPYLQmiiz7tva1WY2PWY7vc+UyeZKnQUN6rJgEzVJLyU6a9snNmhaYuFBQ7xJp BJ6zSGtWjQCjDcthyNYGxkrr43Zo5RvPY2LJjNRAgdUMzxpqWkt66k2zmiRtoFoNz1HHGLRE VqHVDKtp7lU7UtPsE3BaOEDPfRmerRcYw3LQ6FnGqGn2CdgvMLwAWqbZx30b8KShOtfK3rNp ZNqN6o7B2v/2oa/6cvUzNqvZfxSMkRgz1rK8wNS6wHiigHU5gpWEH4Uc8FFGhclrFXgacwGj 1YHJRDF5wrWv1baMNkpawXPlMvmbp0HDq1/BTL6uwJOvK7CT4/NY3/ByTAWFWzhY1ohdNRLt MjJ4i1c/5kvrA7dLNjyeY34NHl0D3DeaSauGmtasM7K/zWrCojXQ8OpXMGriPFY7shJe6yCb tWGSnimod2M11HgjpdV6gWE9jrXMMiZOo4F2MVrjeWLJ0jTi6BssYtFQnZFfHcqKGP2hHC/p 1sTgzkRHF2lq6q5Qa7oIxaHwufUroi6nSjpWaqifMSHx1L6NKlhHboKW5IGJ+k4qdjA7Lsfe S0XDZlwAFTDZ3U0ViMoyFWGyuZNKu5WKMe9B5YhKMxVhsrqP6opx7Slpq3A2Lh/dbIqMyZrv 4ozX0068UEW37BcKxklMgXH60DOMPZXARKKYbj1GGwoeguXg2e31dI4q8HQSE3BkHtMebHCg dWPpa/OAPsAzQace6zx7QI+VhNcNj/MLeQkf8j7MfsZHrD1dIwOm3mDNwxVbkSNvNLKcCLid sW6ALzyrj1gF0tQun+kHjwhJ4gJPGmpaC3nauTarmdbsp0rjZEsNM+0ZC6wuwNBaSJCtjyjD vb+G7rOxk22Wh13PsF7sUQLLMen+abSDdSJgrenjJ57DwpmHgyRmgScNtZ0c7/5warLKwkJp jAsmSIxVWJ+0XWBaKQema35w6HvZ0YaCVlkO1gh2yJifSU2nJgGj/4whH8AcyEcsfW1Wk/y0 D3+uXJZTE9OQHhsGc4s4B73AZta04XMjrekDjjMH7MsN7+2HRoBhO0I7KlnGYNcGSeY9Gz+P rDXwiJBEzfCsoaa1TIsX9bdaDU7oGjrKKcqWGmbeL+b5BFdgI2V9rG9gLumFws4ckmPLwz52 WC/2uonlmHT/NNrB3GKYfCfaJQt4FDwcJPELPGmozrXb44LaFrRyU2CwLjHWF45FxBApMPjl 8VT0bYw1b1wLxZ3i2ZrDqSxtMfRg3ZfHsnYro/ObXx1P5pyMspGIC5QKbQvtES2z8+1PHVx+ 83HnbM7BHU7FEYd0hbNvxOocixReCSkE5/JaUIXxTxutL60cTlaf/ZY2NIoClG7HynMl6B1p GtOm6utU9V/atqXxqsFK/8nxZEmwSbe2xTxNsX+75bxVgG6MtU5n516hVy1qylFHXwNjyR1s 0LTpr5uiSHGjGjBSN8brfJuvklMEp7cfFpuu09QnXXaDccSmRaz4M44Lu50eWtuX4yJXn8wu ih7e0rMrHD6wZ654CxdT6Vk463ytZ3tjV45T3WXmvmTEOnbFFu7oWmGhZxaRWbx90IaiafTU 5SgbuPa47fGb1rTLTWuxWCQFGMu726dxhB8/SKem7up8OyOePazlkyMyELxQJKKcN2nK9btD 7RNuVYAJlo9lOvcdozYe93qM0Xyw0b7vU4oC6TzCGD0dPVXHhXHGUcSLqbSJnX9IiPUAE404 Zl8+SvkMAelcZ2lzPYkMo+tH73RIjXnhk7UYVpy44DiYugXAKrV5rWEuXjRUg2+BXxrmX46p s+cKTPbN2lNbTqs0Tsh+kxVc5vCB/bHliOGr0pU9W73tz54DKJan5SSyI4Z/Y38KB3OBw4eO T/MJF6fhrqdWdGPkct/gx3Bnd65w+NDhKbNL2d6dmDfdEaPzVaGhqUYXYfe5mb5RzqlPmGfG 9JDeMhuN9TS/epaRdU6kfayzEQvGoH6t0bblCBRq+pgqGzK7td739rpBNYn7CtPUAUzsmOYp obRBtajxJR+4MH2WXtENJwqP2dc9bR1uIYFxOg/33Q/KmFrPA9MSwYgqBkxA3EIC44O4yFps al0JnjfNTQLHfvszXHxpxErMS/pZyJ83csvm+J6XFy5rbLyjuZVcXh2P9dGqnPoYOxo0YHo8 fBGKn4WEs+Me9aLoaHv6BWbfNB/D2kjxDkk+e+YFELrYbWR3P0BruGWFDbePQy/dxLpori3B G2qZ6KXpRsRZOre7Q+b9nabrE35oD9nTi5RvVrj6hWt9k5LLcD0rstFqfE719DXVY9uFZeda t4Wq36WUZ23aFVnQ4mW/mg2NEW14xNYs2s1k4DGKyLobmDg8LA9AzJeHZCtT7vejLWuHclF5 /7edl0VPtHfja3DCRKsuNrISjdeg7+4U5+3pvlZ4MAylE4nB2CwfGBzQjsFhNq4Pwe6YUprj XWNa9tG4IHN0GUKYaUwNhdyZmjHBxMujtfPa3t4Zaqc44xAJmGuNXHnNJStGq1/spL7eXB0H 1+NUTHuLQll99NK+QsuprBmSjaAqmHRR7fwME2+f+vK64vp1llVeL0Klse7uULGb8Oby6O45 47TOrq3zWE1v6jH2yyEh2yfsuZpVlIVovFZ2HhcbwTNJPVLHr3tg9v7XPTHljTmO2A/vv30o vD9b1Q/pwX64idfi5y9bJy5HIpZlvnGxiaVEnFtQUUwamKkvezwJM6Lit1HdEHwfDEQ4frNh G91CNtJeR2+jurrLtkquHyMMa41oJvTwH3DPm/coeq8Jl5hqG7330S+8eA1LnqlovGxUeR1B HTfKArXysN1MEhNm4mn4uihzv/wtyto2s7jBC82EHsMsmK3ooefBWBcxAMB4c5NQOwx4HMTY bKh4CyBd6mbvhH2hh2/Nqg9fEMeqxfU3qs1igPzJoRemEurXyXsSi1eInCVmavEqr7WL+7y4 j0EvK6bso3Y9z/Q6lTiaUIvR9rx3rN4vHbPGPR8ydHxPjLI+DROjFbkcl/LGEK+5+NnXXnLx 17zv5FyeN0kfNMO3qR2B9r3blQTPfMrXqK9clpq+g6Aj/PWD8KDmY/Py/v3N7ci7s9PfaQaZ P+I+YofqA4OFZUvSLmWL2+V4xif187/gagTq50d/9sk49+YXR31OSRlfHrcoVzjbcDjlM4Wt BqV4/d/Hn/98PIHgZ3ukbyks6c7ucKoXUt+0CylQ/is3/3a88+7YEm69pbdriKLfp50Vxx5P JpzLg/Dm42Ox/jJRwpvPKU6nzkn0QDAWcn3BItzdmeKhC3+rbOcvgp+jNz/l1wXPz7hfgucB wUUlhf74aP25HEVMEaRg63Huokx7fx4wmHIsP997/92xGp9WQep0dGTo6V/4r66G1AKspQlN wVPRUyHJr6VQp2F2p6IL5bwWXX0n9FMG0SSrq1Cu6CbaLAj/gx+/vXLfe9O9Ozy8PGdNJ6+9 LQe2I3UzEXc2KC9uJrZ7VJk3Wef+e857m8t8r8LHs8L175jin9WL4OxUWRImW2ULG3NJkopx u+fPL3Zm+b8xbgy2sJvPd/zSPU2+bOGIwReRwjkpH65YeLB1+ug8kikGbQ80FI1HdfZmfUrJ GGU5KANUI0nbKTJEPR13JrCgfLfvNl5bzx86lbANGlOp56PN2yDeQG0uNmxWY+fKJwG+JAFG UPEuiakYI6hGjIZC3T72HcIcCN9c7myoXy8wXj/tT4eQ4xrCKmfDDw6M+8S5vMDEsSXCNWhQ OK8NjNiQ00V4GB/uAaPHAQXBj4LDLg4YSsiSgXHfDr7ycs+HfNPxn0JAQeGuBxvmSeQ1MB50 f9gD45dCcVvq1w6M1zzjuASSnVH7STKIawcdKY/sfSPjhYMbHMwrRsZjGSkTdzp0LTQOG3z/ 0PgOh1cKjV+YiNdC40UY1YV539D4DocPDo2Xtc327iyR/tqdVwyN9z1PsTAOCfRQXOBcz53Q eCFv87+Hxi+6XTptgvnrh8ar+aY985WOt6nn710v6o5iGQhgB8MhaWD00A3ra1ABo2+6rxd1 UEzQxB95R6u/3AuZh5HvzBix/FIM22eL2yxgWj7xHDIvVFikgUk3hMzhvJ83ze2FzIfzRwx8 7t6LIfOJwST3Xsh8LGmIgd/YnCBfQubej5gBQt5BY31ljIqb68LxzMRr1BdC5mKsd+bpGo7F s2exNMoY3IWQ+bRTwOp+OWTuVc+svi1kPqh3QuYuZUqpdyNUh5C5y4ry3i1FVF4q0XK1HgvC q2VjtYnS4uKxPGsv3hVexVZIbNpC3l6bUc0XHxR/RkYY78eGi0bS14UAI0mYcVE4hsmlywN3 MbBe3A2uanf2j2tgvez9cHcIDAl3NSwltAKMHrNQbG/tZd3xkKn8ckAXQwjancB67gVudgPr uX+YfdfIuzTWgH7BC8xeYH1QD4y6fPk7iBC8EHvvi4F1IRJjrjQyiDhCAkx2InjcA+uOyjHd Elhn2hsD681ZuMCXvDsKFdc7CFvQ+RPi7wXWi49JK7UcpBcD685yCGYRUwbWBRU7kxguj+6e y05y4sjA+phMq+ntxbx9dDifhz2HdCGwLnwOYVzSFxtxCRETxoiw6j3VrLw1NOioNFUwSzUr T04btaoK7BcY1WEGxhAFOCiCnYQfhRy4B0QtKmBQq6rAaYaZx8A0FzM4dLnWvvZqVr1ukTcI pKCaFfg+ccUrbxGX47es75ypItSAHWD63glVpbztk2RQ9NVjcHARGrEbjQBjWA7iwh9Uczsm kyQBcNfJeA6tMY9EkpgFnjXUq1lxb2DkVM0Kun3iildoedS3QtuoCDVgtJzpmy9UlUJvBIVf OKAaB9WumqwXGJYDdoDpy+3Q6KCKFkZcPLeQDDw8SeIWeNaQrGYl5hpVmhpaQy0qYFCrCtIP WNNoCEwiCuKgqToQ2tDQEcuBxE/UouJ3qFYV8xxwZh5mkos5kNxLX2U1K1jWqGYFvqOaFWbO qGaFsUBFKAEngsmiB6aPr4DjzMENjRAGc21gMNf4LYPdHfMlexWwmmHMnMEjQRK/wJOGZDUr aGRUsxJaA41BPhAqPjFnqggl4FU2qqPB0jMF9Y45ZHh5ql0ldMQY1iPesgh1M1+MBtrFaPFz Hk/mQSOOvg140pCsZgX7HNWsCoarELHNUm2f2WYFTHwFRhHFPPfSPG8ehRy4wkctKmBQq4rn 3oCZh5nGe3Cgubf0VVaz8pwwhGpW4DuqWUHTrWaUkppERShQoGYUxmpUs+LRHBRh5uCWalZF DtSHYowZchhpe0+jHVpNBpzyAkeWzEoNoFKXp1yXVUNUzQqWBA9N1azG6oF6Tmh5VLPC7ENF KJaNakaNNVdg9EJBlqdJ1uzY8tTGetXiBdAujcUTV83CLmPANJ5ol2fO4OEhCSzAETxpqM01 vqmkTMuy2++fvtc0TL8kcgqi1InEzYIo19qbkQf1rhLvR/zkhzwd/xCHur4JVig5ctsWHaWx xrYBJbrGtgFFvIAxYxuhZxgLuMAkosC0pLJKaAPbhiEHtg0o4sXvKEwW4jlgtKrm6TQ4kNxL X2UZsLFtQBmwYfpMw9sGlMrCIoFSWgJ28zKDclxwboPCxZmDGxqBDlEIgTFYEvkt3jYwX3Ju 3C65h/EcS/PgkSCJXuBJQ7IM2Ng2oAyY0BpoeNuAUlnMeWwTAMdFNirHxdKPbYSZOWDbgKJf QkeMYT2OTUJgTJxGA+1itPg5j+fYSJAkTi3wpKEXyoAhcdlFtWQNe4W6JiOJulDBJVHgHZi9 JGpBDYxIkL+N6oYk6sEAmOJM94SibnFu4eioEkLdQHWDUBBh/6J/zRwqC0Kc9epbvYY57eE6 1Q2Z3U6LvMrux7XoO2V2u1EqaXlPZnYLXpTZvdtBPAvKb6hFTvktVFdzAXoiudOc5ICbMqq0 cj19xEWVL42NuH2jFHFgJE/RcmY16ltE3zazXPtdaIYSyeUIbhLJM6/SjFHmJoPZMsCwizJx Wyq+8r6Seowka2c5NoRE8iSCjctV50jrlpefOLoMvTCVUD8nkmc+bCL5O4tk/cVk9nmtXdzn xYnkib8RQj6T6COnGSZM7D2qbcDuPRPJR2h1TZGSieQIVO0boog5aZqy262sKIN4GxUtlJq/ UmKMNfdR7e1Yp/3pC9tiysIuz1hgYKwU+BYqbjnzPh4YFwWVI6rlM6hClW+hsjctAUN7ZjMS 4+ixrP3Pm/eWdP3JST8LjPSn19z2tHKM/Plyit1+m4VnyW6pb1mbkVDvm9N4KebP1Hn9OkBm O9zX3E7vdsKVy3uTxWUbLlO9ztcBNc7r4j/+64Bequt9vw441YKA/3e+DjgVF1zrj5VlIbn/ N18IoLTa634i8Cp5+SNMOwVud3dw4sPBuLPfe3lvtjn2ePHbPjfddnhcznM144hzGq7gUHqW bxGoNC1OtgKmy0CBCUSBy1BHsJHwo5CDbzu8nnlQaVq+7RhwZh6znMyh923tKxWvnUICz1y8 VpzbqXyruO3wCFfQ2daH6WIPJWLF6djjpsWlmcKFmQMublGqVpzSGcMneSp5Oy5umS/uAwas pnb47kJgIlHgzgGSTRqi4rXTbc4zF68V0lL5Vs/f6KLAK66EUQCWW6ISsaMlFJHF/ceg6OvU 4JA1Wx7u6hRbL27WuFQtQnRI92C+pH0Bx6kdvogfmK4B7hssYNGQLF4L2Ubx2mFrKD0LDErT Qq8CJjsRGJS7BQdDsJfwo5ADm2zDF9U0P6k0Lc+9AWNkBoay2cDBUALb3FdZvNaPj46peK2w GtBwsNjwxTtpmoM+dBPFYSUHi+YwEc2tQeEWDpY1ohcbYQzbEZW89VxpnPnCOgecpnY45DF4 0AygwrwFJslmDVHx2ij7N4rXCmmpfCv4jOK1BUOJ+RyeoTT7ZOaWUESW/cCA88Ihs+VNd9pP EmNZDujeMGbSPreDuTeeR5ZsGmHuGyxg0dCHF681xYC0rt8zl81Y3nyXRuVoy2kt1K9g4/lS odeyXTGulay1L5e3dfWj0VoPNt1T3da8WNyWCsEWv5RergNr+tY2nC+VgS0bKlW2r8WKHMk5 9NIpyvEv1m1GWB+/67tn30r+7j4/aV/ciNuwLKts0fRJ8beb61icah66L1vD9rHrQtLPAqZw 5l8M3RwUynyvGq1pCIG0ZFk1g/rXux+KOrl7vH3TaDXV7nGce62pWgdhysSiUiR9xR9wJK/K GP5BgoHp56/iwPq9EJXGwrUv4MJjpSAOxc/YGcYqyxiHM/7AdF+HnqBABPoK+FHcHRg7bkC2 hVbe/+tSRyWoffl//sDkH/zV72124en60rFdJCUxZcS6NnO//ADslFU8pssVGWMcjQhV4XUu kF30u0jAlcdKQRy8sjOMiA5jEvI5GZMd2QVl+OZEdtH7Cvjxhfsp+wp2UcN7Udc7izzqQt87 2081AFbra9cTmLnXY3TPXGNq9X5C803AvRzKuT3Vr33riXr4U/pSuKwExSmUo9goc27q572x 1lG/TIvVrbQk3OUlusqu6vezh3cfXW38NvNv36z1rXXLaKT6jFSjkjMtuAaj5Zr40QfCOMZY iSmwJrhvNKLLkkc7PETC4GBLPJ1eYMdvdB4urXJwyRrje8BZe28ZYwjTJaNbb033lTjoaTrM t8Ng7y+V3BCwnzkE9IWOcaPgBw5y/RPHCcNXdQMTp+NigUlSLpuCbWPgCpvob+j5U6NEgAma FgdB0x2YA43OvUco/tMwVmJ07tkzZYlRC4xcp5SpSg5nNo26Ocgncn2zaDmfXaNQDWG0i6CI M8z51m7+TKHx6EGvhKBXNj0fV2L0hGkrdofdDOPImDXlwXIqu8Dk/g7lxUb6zEM7wMic1R6Y ninb1NzgxjMbNcEtY4wug5Fvo+mbOx/ygkHoR2L61gVZcgWmTDUbJPxYP8RxElNHy/uFKzAa Fqp7EvIeRrzFmC5LDhRn6tY2Wg5p7jMwtT9ulYUwUgvAUCaap2uugJw3uuYK+L2PgqG4U1+4 8TmaD/jVSNJ9wK+48fgEaClbYDJjYGt+Y324DhwWOjD9GgSYAiOFKhEcCIZluJ4J61KPzBQY n6KYBVb8BmbkmG00m/g3IHmOWp61/fIAGJ3Jf4SeZa67UVcYeXS5+xzrhi3Bn2DuDJ/DvjqY JDHFl4HCzvD4NSVaAfin6ASG3uljrkmrhUeU8CPnBOjk2TMnt/phwghfDUz/utFQvqWmUoaG cjg16ai2Y7Hu8AWipVUCpe5EFarAGFq/Mq2S/YoR5Z8GzJd0kdYMOtC3NZAwWPHGeo0+21aA f2CsVrRae9oYqolHPXQoWp37dtNqRTz7NYCAI7+R5U7iqeac9q+Jiv/ggh7wBpovT5TykuaJ g+uBf0+z22zgX+TsvQn0e/LVIvFVcyafk0FBNp2y5FDf8MQzYK3K+HJ9YOz0VsPEmS/8Lto1 YZXMGMlDdxfDfVs1NOWcWrpriVTxvCyOxfT4M1Zzrt953/PzL4VhG7VIFdc7Q3f/B/T993TG 4a+Z6/I7D++Op7xb9sFRetuoHM4Y3e3cWd+tj9adcvK1En58cK5bG1M4+pUFcABMbdQ3gOn7 TeZQ71hkGwSXNyAFU0Bu4rD047GNyj3VEn68mvi2GdSnD44yB3rNHSN6CExprfta1Ut2M6zh w98+MM6gWD1j6PKCJaCcA7QL+PFDK0SUc3crzFMPx/zjCRd+BQh/HY54+hfGfV9Plf33KMbj XT5+Z+rY1I9Vsa2RdQJr4RFSM71Pb3cHzC0Lbq/gDsqaa3V3BwG6+rj+0NauO9A9y2/fy900 jehr/9d2a9V2ai5EXa591nyn1e4G7Ju/HbW62qNinLRVY3nu7NEOh1fpkQ551H68p0fB5g/s 0ZbDq/TIqFrghnoUyiR787OjnssO3VuvxWkz+ZDidRT5QcJYCo6UPZ6d4IDfUWVM7CmXzCF2 T1bUoiT8KAtiQOuWiqPPWpezHdqdKf2rabd++8ZlnW6xF0s/LZkzO2xgIhYZ32FHixD9gGVG 1Nc5+vFrpqAq6eDAMD6QBcaqfoMPDrhbRxuA68JGiSOgICmZw9KP91nif6yaWJd4mHDtoZ+M urTWNsGGPrRiOOMHMMsST7hRSpsxOmMr1A+qdPRBu5Yjy6+0xNcjj935CcM9Q7c5U6glklvT teL0+y7IzI1u3Zwp3N7jRww3+3PTgjMtguSlk3x31Lu1zNihBC8WoDsXZbpp8HZweB2HH2tf nB6l8xaXtP3lz2oj5lDMDzf3vzxicahJB2XEzNnh/v1kKHy66gRntfjeyzpzeGWdpLbhqplf WuqktF5OulUzVeKkvNTPaskxXpDt1up1g4N7zd65rM6xbu+cCCG10+VuP5LT8yipe/sxOFjM 6dfZFtt2Sq7ZW1xS8OMxNLvzkM41zqCC28CQM6WzmTN8frISHidEpqDzH3NgGL+tzBirojwh 4qsAboPgcUIcFCQlOCz9eP+z8o9PE2Ih7Yt2XHsIDE69jn6Vi2Fj4npWdhaV94BB4ld50u+g bL/FcqYnpAN+hYXUUi5ATQ2eF1JR3VT453qP4MqAC+9MrosCwL4or2b3sJf+8niqv1hYlrCe S1PvAYLw4u052sFUDLa2QHHW3745YuZ9Miahqix/e9wsIC2d1RTNRy7p3H462lT69tfhmPoS 9HVF/ffRvvm2LK6HupocBDtP2vKcIVN4vPuzbKzse0pfScx/Op4iuJT/FP8d+tLdwMf611P9 60+l+d8fw5vvSqO18fb4Pwvw+0pSRfnT8VRORPX5NxDsa2KkN4zbW5Xuj2BBL4TB/WtGt5dp NIx4+A019n1pokn3X+1feo2G+LHgvkY/CPfU4+L1d0kNNPGn8fg7Ekxw+Xrh2kRyFXnicf5L XTTqu0+1y4XQvPmfSiZea8K1/jaZG5cBHo6RWNEgg/NNgqxE17TDS8Ffa3Tl3D798rhDYwx/ I+sozXYHQ2/V+/gvPzp89/AVMtzbBfKmZuhNKyTFYfrWrmUNUI2uEBCFeHtjAk45ifRtvre4 A1V0WCGMzT1uwulODI9TNmFsj5s41WOFfFSgk/x0VLghO8KZnhtgNL40cK5HHQ1HKwoiSEyB I8F2gTXWFGDorpI59M8ERxsKawrLge+sHVXbAca1g3+D4wJn5hGkHIND79va17ouOdPjT4Y/ OnRUxQd8qySB+ODzyIIhTo4493R8ARuCscoyhu6TB0y96Yn1RlsccI3Rq0aAwTcg3K7CT/gx X6rXWmBLsJrapaJ5j4JHJEmobwOeNNS0Zuk3dPgT0nIcV1L3T5UmyJYaxklOjopYCNhIWetO I6N/miim/g4OiIgXwzIb68V4JpZj0v3TaEdbSKLk+I3nTrNkGGFI4hZ40lCNepU9GD6FidBa xCck0JFDVR9DMwfpzCYuMF+EMIZmJ3OgixFuw2DEWQ62Z68lxhk38xgw9DwwPSYzOJDVzH3t VqOQ8g6rMS5Ivk+DhiO7BYNPIWhvhyT/TlFgVBhDvMgqfGBjFwqzcNCsEbfRiJN6bnJQYY/M dkTtGFzfMOyndrl4hsBAEkqCJ6++aKhpzaFelGerSatsoOEyJQUzfcpT4CApetpmEjWKCgb9 CwtFWjjwpV3E6EEjAzPkCFL3T6MdjMaA3QKzhaO0C1mAQ0UtD8kmDbW5RrXpxJpr6KrZ4+xE +V70XfCAY+DRIgxpgNYP/PoZbrYBt7OJoZ8S9IltnM48fnxZ7CiTYPyyGu5N5C+ryTLnFLof v2VtKClJG33TN8ELeWNAWSLjE7+vVmp6Nr4o1Hn8UKg614/NVTlubP5od0mbXQ9jej5d6TPB mmC6kSO4jAD9CsmgwKiaBebzL2Poh0aZgw9zG2xdLAUoIKVbYLRRax6fywpky+D8eHv57Qef kVPNYW8JNMUo6YzsOPj76yOixJ+PC+ifHOer6BbzKofisqmgU+/CoH7Bv8/gZ+u1ds0eqLwU f7iyClN/J+JzcYjvzNZfK/nNw/8CngMa6WVuZHN0cmVhbQplbmRvYmoKNTQgMCBvYmoKOTEz MwplbmRvYmoKNTcgMCBvYmoKPDwvTGVuZ3RoIDU4IDAgUi9GaWx0ZXIgL0ZsYXRlRGVjb2Rl Pj4Kc3RyZWFtCnic3V1fkyW7TX+fT3Eed1I1h/Z/N28JhIQQws3dhRR1i4cwuUlIzYQiUEnx 7ZHb+kmyu8+ZMzuzBG5Sd2uko5Zl2ZZtSa3+j9Nydv60tP/jj8fnu+X0I/rvN3f/cVfPof1v +8H+/fh8+sGnu7/4upzW85pPn35N9O704OinlJdzLfXkvD+7tJ4+Pd9988Hfu3OpPvkPy8Ff Sf56uH+I5xDrGs3P9ehnZ37+l08/uQvLeo6V2v/0K2rv6/sHkmJ1Pn/46/6z801Q/lkfDtuv P/x093PqrVvdea3xlFM5r6s/PSumo05PdzFvqCMMP/V099u7X3zv9Pu7b0ipy5I9qeKcTv9C jf/qLp99Ov3pzp1+Qv/97q4RhLpWIjr+8+sf3cWUveX/rBiR4eMm/0uj5QKJMgxWTOdYqju5 xZ2T48H64f1DoBF7iP2v03398FX745cN9V/34cNv7x1hHzz907TXGSeeCKmeeRhIuZ9+Z5sl PfiIMfjL+4cCLvTPH+9d/hBbCw/Uwr9TC7+n/57uH5z/8N/tt43qPxvBt+2fP9Av/SEFN5J/ pcc2VJPy3xqmMfoVRN46IYT/Jkxbv7bfQP1LYSvPbmwb9Bu00XQjapn4a4+6mnyN5yoz9Jfg 1f7bmvn2PpMouYvTONAscGv68Ei4jfpJcU/3beDrklQm88S/3j+sqjRGEguSQHrNWO67Z25X NYAmHydhDLtv8byyPB0S/n6U+JdTn+1sAKN/b72SSUGEftfH/2RFr+cka900qkJ9q8ueJj/9 /w+/obVeQltV3tFA0aqKheZt9Kc/fHv36+9h4dbT32+L95aFe8wwNIYf79yycfrdnQ9LaVQp RdeonhUTV4/l/WJ71IHq82asks/MyS1h3Tj5nDont0RnMQR7huMEb20/3hnMwhTMIa0dRhsd fjRyJG6VTO2AqT4ALhNcwQOY3qpy6H2b+/pIRrcW0PjS+1/9MvAlSUpkzOqAAaeubdq7Bopa VsALyyaYWkeKWkYONaM3wKQMjdRB/iYHMCEwpkL60CVTeBlhX2fJPEtSAOcOjxpqWltXcFkD Zk1Mdg48EY3DcyswY9trrQPFWssg6+PdWvPQGwPHkUNImHmhzLMXmAQ5pJ1agEnD6Cjcx0/b XT0kK4MGVJK1SzZp6PGOtjK3Kd+utbhki3lqmGIxBGM1LiOMWW8wmSnQ38RwtvCjkQNrzblt IukzruSBp8JoVTAsl3Bguae+tlnjtnGvMrOeG5dg+T4Zmq75DcP962vL+eAshdvmRoMr2xK3 rYYq42vgNHLoNnbTiJs1AoyMjDwVvGCYb3BjO30+q2RYOcqja0D75lmyUUOb1kIqtr9t1jg/ aU1ofBZMHjiHFIeWQwqTbCH5QXqBuXfCIcDKxyXuZm+c9ChPdV0/mXZqGtvh0RLJZDyFB4+4 9G2FZIOGtrWWYI/6qietVZmxbCtdlTm7YVw3hWLDXJU5zHwV0zWvHPqepG0kaFXlQKspBosh GKMZJzgLj2G8DYeV4aGv26xJa7TjT/1PYbATTZJ10PSGSRZDcLkAS/9W1kDftwzMvVlZIzVI b8pOI5OF1nbCIhisFEgCuIztetEaeHhIkiZ40NCmtSrWBxa61mDnwJOh8UUwZZClHzwsHK3s bR75YPunFMGPHAK01rfhcfZi1FWOZMfiybRTIclgK/X3VWY4JFkhSZ7gQUNtrVEnOs6eRvtT cWVpP975pQ57HVHFJVnMU8MMNARXq32FsQ8ZTGaKYbfTNrD7qRywUYQZrBbBYeCpcBUew6xQ Diz31Nc2t7wLgwV+blwGa/JkaLD7EWawdQQP+6PCsJaEWe2YGzgxjDUcpTdlp5EyjYw8hd1P +QY3ttNnuUqGHcZgMlMMe9SsoU1rausXzBrnJq3pXpcFkwbOuttlhqedmTBukF5g7p1wwO5H MytMOhKM6FH3sigYN4yGwmWUTMZTePCIS99WSDZoqK3Ib060Q5R0ousnu5M8nEl0bvO8NGNX aPBpYUzGYv2Gqen0iosmJi0wcRU/0o1UOcJM8KVBMCzLK6hgYI5Mjn81VdeIc6tQdcxS3Kup ui6bJxNUC1OFV1K57CYqYD6DKq1MFUHFmKWk11FdmVyqJH9lJ5DJleo6TkXFxCpCJZyiZd8o aTovEKZajC95sKwGZstiMLFTCIfA8HBKeTRyyOpOYbhH+eTHvUhh7BuC4X1DOPC+MfV1s4AJ u4TsGwn7vFhAocFJjjB+sBqpxgnGWUFkE0yZKLh3dbBlm0ZmeycYsYnyVFAMzjqTJN0roL+L bRYeHpK4CR40tGmt4FzQ+9dmTR529SdD45NgsJPwrMDpQeBphyLMcI8y8DpygE+DZtZwWn+y mCByQPeKGe5R2k4/65nfi0g2nOUJLhNcxxlAJzk5/eHWFJaIWwMb8rBgx+oYgof7ioF5nhiM ZwpwcB2WNnjWGznQfzmp8vqs3tlWDJyFx3BOMBxWhoe+brOmFm/Hm2ZNdcOabpLAZwHvke8O QtGkl1ugwMWOVZMN90ZeWwqHiYOX3uSdRgafzCYHZu8qGNxM6tgOn4P09ySSgQckiRM8aKhp jfYuZ/vXZg3OJCli1oDGQ/5VbnBbHwkuE5zHlggznuqUojBcbW/bzIvD/fzJYpzIAd0rZtC+ geMoaU0iWbVzgnq7TLAbZ8CvXxEwdYHQSxyCcI4Ws0v1lMng+sBBuF/cP9DZmDTsP8QtWLG0 +NpDjOeSe2DjF/e0dS/erR/+voU4ql9CYdoHktAT8RbzZGJhl7Y/XY7rh+9v1O6c6+khlxY0 ucw5dc5bnPiBTpnliDM9l8kCfPgBi0wSh439TJohJ5046HhZ/I4ior3W7XpIctAT6gLhSPNH 1K+UbgwPpW2xxFNI/TxDYp/cWjg81OJCy40BXcOJ7ycVnD6+LfZOeyedfdwp0qKphWeSiYX/ VOLe8aCHIfTrBF1K+hqMrYeZe3hLz4hD2HN4j55Fl8++VOrZeq7hWs+Oxo7GarM2tMg3u1Da 2NFUeEXXDAvfWVRh8fGODtnONkDXL9uA+dn3n4t5mA753Q6Xfq6g4yrihPQs/Rr41y47TXGJ Ir5Jp57mYWl2h46RsUjwv2VYlIgF3xWJYOVNmoqxm9hS5ZoPTJDblVv7oTYvKwfrBOOiXC9c SowLCE4Jpto7WGJckasKY6LcDd3m9iIpcoUbVTDB3JYv34iyg4DcMbrOx53IEk9m91oOpW/Q ZJJ1WHFxguEw1EWp/XsMM0lbXD0VsvAFCTk/7ksn+uXYFvi136lIM7w/RyP8TdNg7VfXAw5v 7FDTZ1lbh/I5uIMOHZkA2iWyXWRBg/E3dshwcBOHt44Q7TutQxcW4qGtXtgxUPr5iHTyyu4Q B7Y6/YRpOLx1fOjw1SZc646cZ7Q7ZnS+OdFW3Rcbe7ReZ2j6+ZVmGNw4sZ+B8+bhnNaj38iU PMRwZT3uqd9t+i51M7tt+pb1YPp+tuHNrq/ZCPskmGDcWtCaUk16fNkMgqmXZgbDODqG+taX XRCXB2OWnIwF75vcdkVhC86YRe184QtNLfAnCmbx2vI0qcxmEGbmJe4ELt2Po1aeGin77l3W z0T+vJPbNgePre5dwSf3iuYMuRMGOydwcAtvLxn3OucCD0zaCYXfFmyVx9STokvsiRRmrA8W JBqhDTzY31qADttpLRcbOTwSON7GdbMXu790hwwduTZDGcu1Ve/4skvUa6f2JmXLdb3GGvgG Hk5rwhFv92PkHz9KIhhxzXsZzK9Ff+Wdn+zB1rfo+7gRS2ny4m9HWoMhWQMnt2QdI97Xctgt BowR/ZZkjDomVXHrygAkOA2OhmQv09r9EWRI6uUjoKxL380OHd9gIgRzZU4aojw9xo7tbhRl b/eXtSIKX/rUawqPl/aPA9o0jmmofYEfjenut1vGNBY5/8bu5gBmGFPfg+VKrZhQL4+WPlbl MRyfd40ggmhEEsyVRsxjdXqsmvN+7I6fGLuz2ipwNw5Ke/siIfV1o5GSv6xQF7vXiw64yDBI PWYC8Qe147ca8o7a6O/yvhK7qyoGl0SoQcyumx0VZmJw8fLoHhnjYBdOe2xvPOapN/QYB+Zc YanzkamZRVGiND4WS9qrVX8rM/WiFuqqBRbrf90Sh2H8aGLq6vdLV5b+6NX6y6z6khbsyy08 3jhfDBd2/0jMEjcO3bzHtco5BhFrooIKOLoMzNAX5SmnQsYkPdrcRnVDGF0ZzIH1SajuRV98 nTtaViPUDVRXT9mxkzthwAHVuJhmcg+nAfe8e47j8GnipXF41WNa+wlmEb+N7GFVd0oeLzJ6 eTeCu9Upv6k1WllixliepmVQLfWmI/e+mckMXmgm9/ikVamInntGS6iyIgRz2z3ggIGMgxnB HZUcAeqV3Xj1C/cPtnV1fTcqUYd0Mv2Nar8ZIBNS9SJURv2u9gsxibVKi9FixiNSdZd5zV08 5oU+hu1eYXdM20cXe7QfuGOq/dWkxL5zYfd+6Zo1ufo251/qzeglUo4JHteso4l42fquOAkf m/hr1newtc+79I2+wiVJQ+7iK7uRgpnSuLnjt7Kj9jeZMOS21gWG+cpFWKnlzKXPh89r7qB3 Byf96bkhq6eWdJnqjWG/vJxDc5PRpWlRN9lDPOfYglB/fZ/OqZK8H3507860Rn2in7egWD6H fHpYJSampOb5f9I///b+AQR/dUT6cWNLh57SQmJrZ/pjofwHaf+jPvPpfvMIpMBPPzTPgG9O Mn/W4JvPZxdr/vD9e7oeB7offvgZUy/n2rrAUUTD2Mj1tYjw6s48uHyOkXqzhN6CCWVqf34g DAzXn0rPDNcTApZLtZr//j31OgYi+Kt7QodIt6RLYh39ecKAZqOMnx09/+m+bd5uyVat2hNV 1d/JX6wJuiQ4Yp9b5Hbjb/pqRPnKSvWgc48GlqZucqavn4yGaCB9Da5JFUk7JayG8J/l549X vL43ed9h5vWyNV2/Ds8dfCbZThQHp5SXTxS7gyoZz2oNwGcu/u0I0YSnSYOgjK7znzZ38BoX 5+MwW2WK6XqypGbcXvPn1wcr/R8Fp4Nt5s3PDozTa5p8eYojFk8i5XNdUr4yxcmU13pqe2fe zXBt6eH+YAEayk/H6/691fTWlYCjjK6Enh02HmXkELRzToSot2hzmnfjNLdUctIRKsEYKg20 cDzbxX5MGOPZOwcNx7eJgqPf7xffDufawvR0NpriUK2CwFvj2y5JYplg9FgD56Zz8vqJYPSm 61IP4xEOh2pgltVcJrvznXByw2XMdnAc49suu8lB53K+ycGU+3nbaSSB31ZyLuyHGRHrssWW /I3x7bIFjfwXiG833ZCyh3haSw25Ft4um2fKc3Daf0Z4e+TwnuFtOqPTzrDvz7XoNpbc50e3 sQzfP7p9YRlei26TAD3LdItNv2Z4EN0eObxPdJuOQ2xVpmB96847Rrd7LGT1fcE0M9PfRKL1 mfdGl+PVZbtB+huj22Xze/gvEN2mQ2ctB7PXWt1NO3/qalleUREFEeiebOVNoHvzNWw1WDTQ bagYA5W+YA9NrRbiv1r+z9ZYmgiX3ERXO1DPiqHdztwxh41Pw9K0U+udna/MRCWvTDAmXY15 jxvE8665KeZdR8vvi8y1m/wPE/nzTu4p5r2O+1nweXlFczO5xrxdXWRDRMx73RKk/RbF9thu d9EK/Q0JacfUc8x7CxhHO9a6TA/iqdHZ31qYhbfYxbqadzHv/TGhB1hdLpdj3t71pOexksml mLdSH8S8fSj9DY+jmLfn9JIt5h3HmPdxNZWrpVHgHaQttVeKOIiP7n67JT6Kc5A5seW8d/xy +ZUeBOCl0zHV6fmaw2PEAactYIp6+mSYiiuXB+5iZHxzinIhKjk87l/sY1+hy/I6m2DylZDP RKSPYVSsvwxn22PdiUPXlZcjsko7R2Tlp9BFOoyMz7/dMvI+OfXH9tme3E6RCHErtWLyZe/t 4WMHB+/R12tEEsyVRq48Fr2J/va4ji9pt3QuRcaJds5QuBoZz/ahY4Ua14zk6PTL56Ha8VvM 5Rr1i5FxvyI0MYtpI+OGSozJulwe3QOTPS59GxlXEzNPvaOgNV2UcTnMRwbpQmQcRPqYT/sN bf7NUmvU7zWFpfwCbxqKPvmtVFDjhLJQwKBsFMFhglFyRDELUzCHftnUNgK/1GXk4BmPslDA oGwUwXGCE3gIpnSKNPRt7msvLBUZh2AbCktp/1FayS8lA1OA6S1xcSaBK3gUyKaYOFH03nGJ KM9vKWthKWj5yWIq5ADGCQaSuEmyvnMZmF/XMjxYkjzBo4Z6YSk39EYLS+n4obQSPcc7K4ov EYbLNZUJHlt+lIJPaNvAaeKQMfO6jwuz5Mlg4E9RObJg0HKZJOmjo+2UAMnqMMLaW8Cjhmxh Kb/IUY/LYACjhaWAQdkozGkDo8eKiUxR7EiYNrA6VQ4eK5SFkme4bJTwVBitKqYwRR3knvpq C0th7mlhKfB9MjSlCIb71wOoKM5kYLY1BbJxgSeMhYHDxEE1AguHsi2KqZADT7lVMMzX1bGd PhtVMpdEMvBgSdA3gQcN2cJS0IgWljJaExqE/lF8SThzcSYDh0k2Lmkh0itcJw4oj8NlpIyO FBNEjmh1/WTaKWFsp6RRMhlP5QFJ8gQPGrKFpfwiPvI6zlgtLCVzuMqcTRPMo4HSU7JOlAMX CJI2UKhH5BB7xNFmWVspDqNp4CI8gFmZIti+zX3lwlLD+GphKdN/Lq3kJUUGxZc8J3SgOBMo UL4Jmn+Ugk8YLQPHiUOQ3hSr5SeDSVpGivXoFYOVMUnCs1PakZ1AMYkpkl0js4ZsYSn0RgtL mfETGucFg7XWx4NfWQcFyjfpDooCTyKbUqAAVLK908JSZs0rxokcjCmKGVaftsNrT39PIlka xpOLZmFtzRra1po4KjmP0vPrI1seZZoyMZFPSUT9VfWWTxnnfEquVTVc1PsBuTpN+PiSt+Mv cKnjQ3BARbLbjuioUqXHBlTL0mODnw4SqLeFxW5gHjaDiUwxHBNMG6htoHLwxEc9LXlmGReL gbPwCINcymFleOiHrcilxwZU5NLFoDQ4NqBqFUwVqlodwJANI8aLwcA8UXGQLKoRmLIgGgGm ihwwQ6tgsOnXsR2XR8lgmAwGkuQJHjRkK3LpsQEVuYzW9JAQBZMGznpMADwdaVAZS6RXuE4c Vpl5YdKRYoLIEayun0w7JYztlDRKJuOpPCBJmuBBQy9U5JK3xDOKriAzjxa0egU5vdhQcdQd mKMs6IFnx5gM99uobsiCVgbAWGs6Z0F7L8mBBx29jeoGoeDWHxz9F7ONXcnLqFcbFriN6obU bDgwNTU7eNN3Ts0OUrVzfs6mZhOuCFXdCyMt10n0A+rbqK5mUvZMcCM6nK9cwGXKHfG7Wbx3 UuO3VfKcOccbmIGnFu1ZRY3xFtH3zUxuvwvNcCZ4kLqDB5ngUbLLBYMKnrdlghsGMuxmKuyo oPVoXYgXMsHhxDSZ4Mkk+kyuTs3Lts5PXGZUL6Cy6pdM8KhZ5Zy9HTWrfJ4yx7zmLh7zkkxw 7pFJZjJ9lBTBq1QmYMcr7tWZ4JIUA5uk+VH2Paw+mksou4m4t1w4uB4dZTUWfCtVN+ROXjMC RkrL30p1cGIdz6cvHIs5jRqhxWfF+GAFvoUKLXt5219kcTrPcU7yEuoDJpjQ+xUqPXffUBxx 0N7BSIyb3fPuuTFroG8iutcpxtrTK2Z7z6AnwLtkSz6O6f0u6QtGR9Qv5tsjW+F6zF+o45ze b7MdXtfcgbwH4cqDZjC/TOrFAdX7pPc7W3blz5ne/9BOyS2/P39Wfn8LPFfqDq2T/wPp/TRn W6mvbdHlL5Hgn//f5Pe/S049wrRT4PbwBGfe/KsH572Xz2a7a489l97k7Uhwmou3o8C9K7UA uQosMKgSK14EhflmZzD9lioc2FMhbcDVa+TAnZSrwAKDKrHCQ2HcQBXTvR3KYWV46KutI2u8 HQkuObm3Cw3e30WtVThqUYtV7roJfhbcdVHPVe7PShEmDkE0Mt/SFaNyMAaOW23HQTLAZYKT SDZ4M1AjV3wQk4ZsHVmvL8tyHVkjm9AgiQe1VqWlsgyyoFqrOpVRz1W8G0LR+6scvMMT8DrA ua2YqHJgLKJggsUYOI/twhFvePAagD+vQrJBQ7aOrAZJUOOVMDzGqAILDKrE4hkDc8hDMV3z yqHPX21D1onIIRoRR3XHoEqsrF+Fq/AAZmWKIUgy95XryA4Bu2epI2tmDVdS9fKOK2qten4P 1kvQhzXN1VpV017CRFwATinSyAFueC8hBaORPM0jeQpJQtqOh2RD0ETbdUUky1YD2jcHyQYN 2TqyXt4DRh1ZlU1pXBHMMrS0SgCnMAzZMKLrGAQysB85+ICZF7EveLQaBwusdWQ1mUP5opgf AkVsO+X3uohkZZgBK4Je/ZYza+jtdWS3z2S5rWbued2/U8YFVX2rPUkb2UGFVCm56uNWPDbc UGk2tK9uPjRjf3N9VjoQL/XFSrOezkWnh7YOXy40G9pRmQ625z1pz8dvNczphk97RuSWVS9c irYprZ0zcOhWgk+doOmMpL9CwSwuNbCekz/1AroTRddlcwFSA7SR552QfDOgydJ+3DXxQ+7l JmK7cZDuNpIgmlLirw7f+Yz2MHn7GTK4HpeNFZf3wFkfwATXJ36s/UggcFnZkAlGPhWgmKW/ jeJ7LDSGXoweXmDAxGOmAIfgRyk8cm2ACSuu/IKp3SijJyj4gL4CfjSuhLRISX99mV9DeJ/9 omjk4tCb9wLFLv/ML/DeNi8yezO9zIs1WkzwfRsNoZcHUhgfAARGPWaK4RFBYd114XnRXZOA G4+ZgjnU7EcYB0XBRCTvKsbxvOCciFB5XvS+An58wV3l32FeODITiYz9VjEexv61qz3Q9YtM El06z/W19oLrgQeyum27cPAKvJYDLTKaYO12jO3mR/LGL20K9GuJyZQfbwaO1kStV4hlq6Om jLG8RNj4NfX+9O7T9642/2W+E33Tcsq517DM8FrTFX0zgR3RX2a68SPQu8nUVlx7aYuWPBkA qa4NE9I3MKIuS9vC+Avb+DW+wjC0u3tE1T/xAsR+V8tSsshg+gkz9pQqggPDhWHcoGIPdmb+ pA/BgeHK8GLhLYkFPCVFJzAG7ktX+StXUgPNYHqCUOWqAJm/rFh7KCBl/T4c6qj13hHsGB6S ZQA/3q2hJ7CmDEf8GiNjJHE29hRdUgwSZ2NPLiXVQXqUnlGM1KBbOCms322JS5lg1qtL/T0y n+RrlIoBjyGHheDhbYhHkYwwbpQePBSj+e94ik4zkr/SNeWyfIErIhOfv+YQAyiWEZY7U+wx WJckZ2Crg7th0E7ipxKSt1CyljCdL0JAackTLH4QfiKu8OKsDPMTgV3lOAT5rUDQ9govPFiB 3z+TN/aIpnORV8sU04NRwoXrtBK8WPjRvEmEqo1urdO7RajDub3DsNkWt3ZPyYDhliRVUDD9 ZkUwy8ZfnpWW5bsuIl2S/ix4sy8Jxs9aEEwfda7v6yKXXg0L6xovDsCn1uduH9GesuakAJqP 3R6QcDK7mIZTuAjm2EJmm9J9bjRzxArxaOQSJ64ZaWA6r/EVyu4EVQzWP8GuwwEwEss3l2AU rmtwgMsEr3jCzStOMdm22nVFsKxafO2oz+62slGt0EW8+STWIW4578YuiRUq1Y8aMBhuGxjI FkvNIwy7tOJ74GoRFdN1gi+E84654ovbOYpOFsYk1rMH7K1GAOuekbImWLp13iH8Mu8igkFC pWMY6ZO8VwXdm3g36zMYCZYoCU17yGLhbf9DG/BhRK6/b3bV7oHBztsOIN2rSet6S47gNw35 JelFVnr3QPdEgY7peticIK2QQx8gOpj165rrqmswkllXtrLL0pNZV47TLb2cFsG1c+xytCe6 t3qNQS1OnDHr8FTLrVsW2zLB2bbb0283WPLzXLKyd99T49nfvZw19EIG2E2HOdSSY6fUkEFw OfZ+WxkWDddUnjNSCLS/jzJVV74SrhnJNwZ9sm/HhF1zlX+bokMpJqGWLODI3i/nOJk5llNY 8DUd2nfbm/fIBj4mrq+vVtA8L/ZuvYZzLtuWqx+SyHRBafdjPtduB+b+XIqb74f+5TPwD5vP iqbgkg6rWMSFa6aHHCE2nQu4j3+Wa0TkyXwgUrs9fLYe09m5XttFrg+f7h/Ww1oltCv3A7DU KgQmL31eRX53JXPx1MjHOMCPdzHydUgoekqwcuCP9q64kSumHzXAIa3dKKMNwO0J/jQ7KERu 5jD143Gbua8p8fHd1cRvt4X5k7teZrTZkJTQw+5TA0Z7tE4wDqwf71QipKoIpnL9gMCfsqt9 w4z4VGnFEfCt358ik5vaRzvosrhM35/aPtrxwqe1OESi6275kqagbpPwJzd/kWwvnnsPs9Au 6akXiJJvdn1fbeahcYDNXLyYep/s6yGv6ZeYO14cg7l708bBBs/Hcwx24zBbwt/IHjLbv8Q5 FsgfVEw/zsfAaZi5H38jv3YBuK3IfiRTip7GLhwExvxXjMMq59TIfqSWNhKO2CIFKERK5jD1 43Ps33dVE8b+Lf0MFKL0sFoMWot87dQerkHtHyTC9zWA8cWxRJETabrVjL5WC7/d/tGlyW0e wuVMp+7d9/d2h6VAx6QW7IsSaPzxPZnOxa0JvtxWPSaIf/YX9w/Htdqi40+RvY9J4C9qv7dJ aL6i7atOdO0sJk6DPn+lhuGP9255rdc0+u63wveZ2xTo3hX9imyMxVlMjPi+K391UGE5CgAT +fAADpEPD2gDOVIqB94qI4y3mMgBF7RiYC88RjmFAx8Jpr625RTxrRGPt/ii5yOARxyfaLqn Vb60HLkyC772SnC2FAQXhkU2+frrMlLwB4GEA3JqSNq80whj4NWip/oRS94PUb4+ju10b7SB F5EsWw1o37pHe9bQprWI7yYjOBvZT47RabOmeyfAp2HYp+EdDqFlaCm6PLYUo0P/3Ejhw8gB 3/+lmVXtHGit5mLn2iYH0xTFDNo38Dq2g5wK5cHFraRvPAMmDbXbPeafl9KdWAekAIwxrxRg sJIIrhMsG5Vgkl1r3kESaQPHbpGjyqyJIw8EN7kVA+vsZMyK1eht3+a+2rXmHRI9sdbAV9ea 98jhw3wEBvPVwD0fxjuRjbNsMM+UIo0cEJrFyho0kq38uta8y4opjBklcalOsFg5bhmXFPRN 4UFDdq15tVC81jA6utbAR9ead7iMuTLBeWwJaw3SGop15JDFymeMnszezDSIpGCdkPSyHt2g fQPnoR2PPDHDA5KsIzxqqGc83ZjtNJ/A6T7mGq9o6mdfOULwS4PGgeRjekU90Ssc3nhs6PfK zRVsjw3twBB2RwXTI44f8cudLiZzobytR3gNcsfhbT1a1u0g1FKVwg09em3xz+gyR2Xk0uAR fcPl3zEF3BOAEQ1RDNtRTvyhJdMtxNJ9z4Af78LKL6IyJlSOI+Y0wkWeEAxTrI5fEGIOK47o eMK4R8O6MvvA0y22nKeDM++eMoHyjVdcf07rlmqpl3dcccN8uUWp1Ffd/hxCsQneL8cB3oTD yUe4grfLVEz84t0ibiBgCtxAnYHvcZGImqdeE7ZuTrm5YHFaEoQz7/MEmxtiSsbepoIF8Wuc NBxHUjJiY4PTnI9qgWuIND+485ec5kfEn1Hi98D30bw6LcwmEyO2iXHR4cErViShSx8dO15l q444vIf19edaWl/Mrfa2S5vdW/o5vHAhl8+wxD3XXznEd7qSui0fOJOhKa/s3WdY5X6OTmsQ q1wtJoa+YyVxmgAOuHsJJvHZlHnmHl+Pjh3XGfH2j3bBHYjABXxpH6hH9sTxvhEX3I485wkw RvaJyGdYgcO8k3CQS/aiyB8axG4VUXFikhlJH4sYgFGo/kpUWsK65NP+j20CciVq3RAFwxd/ GJWUGYblzVC9S2WkwCabJlg6LpjulVEOfDyUNpAGpFKAAlKCw9iPzZ9Ic7XSPP/Td7iXzVco 2IiSEorhCyX4ckKRtMyw6Z1QYOqBwzwVFdMTS5QDO2akjRSm3gkFpMwTLJWfvvcd7txvZ4Oy 6yhXvAQmrIUpVj/AHFFvB01g2HWy4IVmPtyiKHnSyFZEDjobxmeDqegsw2yM+RMtSbzM0bFj SChgbOsEw/gqhq/RwiHWsQ28fqVSgAJSpglGG9YCdHv5Xe3pbirtOrr07BdgApIxSt9PFYbX VDE9uzMu7M1FkNTxDm2CpLtjTS9/5qcr8xeNWOI8pE2b097P33rea9/u2D7hgY9T3HLbjsgi wovSimE/MXIF3cIe0B5kArz5/9aBIiFTiTkILPZIMLx1gMOyDKEuwK0NlkIoICU4jP3oIbtb LyvfWSVotK6//tqzDP0WreuRP2Bw4axb1qjCbkEPP2oI+8+wchDv3jf9xpWDiDfttot81mVL 8TlOd+h778EK/r+R7jCLN6nps9MdIl0ma2kBQCfpDuFVsb4ta2HhxDvE+sIahqQZ6gCn1XTL LrCHJVdM9yzEhfNDA+JN/L5EQESGJm7or9ABt6UjleEpjmHkkPMARxxfFMPRwNDjBDkidM4z NK6yYPaR3v+dhLlxz+Gw8KXEuLcHhttrr+HlW3ieI+kP28sNmYayfcYToXSJuGuwPqT2Xo9r nz3lV3QkPH+YnXTTXPTjvGlzIgyY219jO0orKLGVjaH9IJ/DKs6kJmzwrZiM9OAr+cLWX9yP SQeebgSlvzfLmQZRejszSEt0hsHf3Lf3l9Pq0p4rHdhb9ntuvI+5bnlfXa4SC3PYkDu+G9ao /ud3/wN1CDLbZW5kc3RyZWFtCmVuZG9iago1OCAwIG9iago5NjExCmVuZG9iago2MSAwIG9i ago8PC9MZW5ndGggNjIgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzdXd2T LblNf5+/4jzeSdUc/P3B224IgRDCZu+FFLXFA8wmLKmZUCQU+fex2/pJsrvPmTN3ZkPYpO7W SEcty7Ity5Jb/V8nc7buZPr/8cfj8505/bT9+/e7/7orZ9//t/2g/358Pn356e4vvs6neq7p 9Ok3jd6eHmz7KSZzLrmcrHNnG+vp0/PdNx/cvT3n4qL7YA7+ivzXw/1DOPtQalA/l6Ofrfr5 Xz797M6beg6ltf/p29be1/cPTYpqXfrwV+Nn67qg9LM8HLZff/Lp7pett7bacy3hlGI+1+pO z4IZqNPTXUgb6ghDTz3dfXf3qx+dfnf3TVOqMck1VZzj6V9a49/epbOLpz/e2dPP2r/f3nUC X2ppRMd/fv3TuxCT0/yfBcMyfNzkf2m0rG+iTIMVyrnGYk829T9osH5y/+DbiD2E8dfpvnz4 qv/xrx313/f+w3f3tmEfXPtP195gHGkixHKmYWjK/fRb3WzTgwsYg7+8f8jg0v7z1X0ebX41 2myof2vN/Po+tSat//DHhnEb+OtO9TuIsAm1/fU/9zZ9SAx2If+z/fsDpP4D//Qf/T+KQ1IM Yqf68t4p7t82yv7v9/cPdrT+h/YIsSvjj86yjZqtsbXVBqcWEwft6T4T+K8Q/NtNba6GseY2 dZyEAXeJ4K4HxZ865PZc7QA2Ob+l7tFDizbwsKJQLfxufnaVZ9NTWJDXtMBLrE209v/f//ud Mz73GexsU0KbwSG3ORL86fe/vvvNj7BIyunvt4VyyyJpDMsFhh/vrNk4/fbO+bwt1Rhjl64t JcEYj6X0YnutA4UMQ3SZOFnbOZSOiYNTw0SNaXAmOCzwxuPxTmEsURCHVAkOGn5UcqQ0Wi2l TphSCuC8wODBmGwGRZ36tvb1sRm4Ggzhut57/0uJE9+nu+qJjzeWMHjKm41TDW6BPWAzWqoh ENdaBwXDeeLgaoJG/KqRCprMcoAmeGDAN5Ak6E0wc7u+QjLw8CSJXeBZQ11rbTjHePox2/qs sUbPgadOkwZmtLxhaNRH2w12C2zpCUvzyETiOnqjKMLMIUSeeW43e4EROYhLLYyhdipJEir1 z1I7hmDHklnCQBK/wJOGHu/6thGC1lHTWsir1kJ2GtNgr6UXONFoKEwmCuKQIsFGw49KjgQd bfpVz2wjoHgKXJiHneRiDiT30tdt1rhKko6Z1frvhrUD3yehoZWzYcI0FtsKmeCsx67LVose X0WRJg6uikYIg7UmGKw1eSo4xmQ9X6Vdms/8u2etgYeHJGGBJw1tWgvOaY1ssyYtWgMNPbdh zMQ52LLAq2yCqTMF9S7Yqvvfn0h10RFjWI/8VI2MmUdD4LLAlSUr04ijbwJPGtrWWmJ7BK1V nrFkK+0wfYyxdZ6zCia+gqF9jDnQOqnzunlUciS0mkzRmAbnae0JnMCDMYUoyrT2lr5usyZF 0ruP1P/Eey7GJsWiNf0kT5EmbUpWUzTY6bHqsiU/jaZQhIVDYI1ARwGtMoblAJdgGeP1btJg rBzSCX73rDXw8KTXhBVBks0a2rQ2tli289usyVq3T53G65Y3jNWrr8Fmhgtawoweror0RmA3 cwgeM89jrfHsBYatALdTE2MwwpBkWlv8O68c5kEa4L4JPGmor7XWzYHT3uiQPxoa4493zsZp r2tUYj/IorqQrcY42Q3NDGMfUphMFJhLccBskWiURQ7sfs6GiabBeeIpMFq186wQDiT30tc+ t5pHX/WseO5cwjyCTMO7n3NmsnUNdgvs9Yg+9ieCXqOKIk0cePdr0kKHCXIAA8suT2H3E74B kkzenfyOHUZ4eEgy7VGrhjatBWe1RvqsyXHRGmh493O86xBn2dsAp0U2wdSZgnrH+yd2vzaz yqIjxrAe+SnsfsK3LpLQaAlcWbI8jTj6xvCsob4ivzk1u5HjqR0/KXTjELixxSVamrQxeG8j YRIW6zdE3XjioJmImjGGYza3UTU9eaIKNJSMMfGVVGxgDkyOfy1VGgq2HlMMGFPsq6kiUXGL hDHFv5LKuZUKmM+h8kQVmMoTVXwd1ZXJpZRkL+8EmFzN3Pp5KjImxMJCRfjMGTwL1jv25IaZ TkkNniyrgsk7UJhIFPDkPMFWw49KDt43Yp15RHgGtG8IXJjHLCdzGH1b+7pZwBSmM8Jz52I0 36dOg9OmYcx0SmrwtNM3GL4C7EziM3BeKOLEgT25Jsdq7xjDNpGfCoKpGiPtkuXl37ELCA+y 3ugbeW6rhjat5Tzti9usyYu0OU8e4obBTrL10eU0+YgNLnNLDTOdo4RieHbCIRieeRi9yrMX mMByYCw8MGnSvoLT3A48c8Vj6BW9xQxYNLR5cuxBJtKat3bxURpmOn02eNKrgmmeKIwnCnCw BAcNP2o50H/2XLE+y7QaFcwrvExyKg6V4Kmv26ypPuvx77OmeM33qdNM0YUNM60lx6dA2tMr YiMVM5rPjbS2hMIvHOBt8IlANFLXeTRCdbySNgxm+CLJWFvSDs5AiseYZ9w3T5LNGupa8yYl 3b8+a9YZ3Wii5rNhsGq3PjbYaYoG27mlhpn8RUWRFw6FZ950OnjSGMdyYCwsYybtKzgscGLJ phGWvo0ZsGqor7Xbk5PWN7QJU8KrL5niyyk15UQkvH51/9BO0m3LRj7QnEs4PTTrmNPIzvzq vm3dpjnaH/6+pzhKz18Q7YM9l0brz6aAlrnF7U/bLPOHLzZie47p9NCUGq8xjhttM++9+Z/f ffrRwrQ9kkzj+SUJG5oAzXFIewESRGzC9dFu3VpJqBemp+8eyiHJhW7Y5qR7d0D9Wvnm3FDq s7RJ4WMcZqENl23CjdxQTwqZGzOnaVtzmlNunPJICr0pyd2O/7HnTUNzak2maaSSzj8/SjBz D30YW6qPfPiGXK2Ht/TsCoc39ix0fy6W1rM2afy1nh2NnQvD7LkyzETuY9fmwiu65sKwpMIi M4uPd+0UEfWvoWbdQPs5zT8n9XDzyocRzsOFym0WS9Zx/2uWFOKbdOqK6dPl1C8KpMxZ9n6V IQcs96FIZCpv0lSk+F+uOFoxJsjRygyvL1mD+AljIp8tbBq+RrIBmSnGVDkO+eEtNVzBOQWY yFTWx6HIVMnzFkzgY+2141DKEJCOLp4c5ElkTDpEFpMvtDvbHtumYcWpCYZjT+3ea5ibux1t OWV9meJvxtIJzlywBWacOputgkuj5uRNtkA4JOHg3qFDvoRzyL1D+Zz8QYeOTIDNFFWnOein 1P4tHWoc7AUObx0hW7cOXViIh+NjKe6Th3PYlPza8bnM4c3jU7cJ17sT/K47anS+ObW9eiw2 Cme9ztAM57UtGTY0wyFu5qLs1mPbBGiF5dHhoKf0uh4bddDMfXiv0fbtuNTNbl+P1h5M3882 vCkPkQPsE2O8imlBa0K16PFlMwimjpuZDOMcFTL0W4CdB8bkpCz4OIWVEtiCE8aKnS90vinF 4zwHjHXS8jKp1GawY172Yaw8gjhi5Vsjbt+9y/pZyJ93ck8hWQrXyt7lvT3Q5sXmFLljBrsI sLcjXNAmPx/qMrbWfZwYvxlslcfUi6K3QejXEmWsDxbkNxy6rln/9twxRevisJFDlyDRNs6T QOw+nV1DLduqn6907Xbhy9SNpxuBjVAChSDCqUa4eG4ovf1I8Qh/qnDw6FpZ45qFKzwB3BGb f/V4tAy2biyW1h432X5L9FuefjvSGgyJNZS1STJGtK+lsFsMGKOYQuIxGpiILPNHGYCIiMHR kOzXpRleeTMkcNsOXEBel26Ynea+cTQbmCtzUhHl5TGKag+jyHu7u6wVHgwzpp4ejN3+gcFZ aYWNL9FcGtP2m331mIbM/m8cMQ1gpjH1I1Mu1IIJ9fK6k8fqzn3eNYJ0oRKJMVcaUY/V5bGi /P04oj4hpN2i2I1DHOmmHe01hbo4QlPjRvMlhdo4wkI+JTL0No7wMcSf1I7fCiaiolb6u7yv 0PXq4B1nDmYxh252VJiJ3sXLo3tkjHeHo73xWKfe1GM4zKnCUucjU7OKIkRpfizkdLGRkFNe qa1kna5aYFmzVy1xxfhRetvpZVunwXVWrL/Mqu/Tgn1/C6+Wm2YnxUdCQtIYQZdQK7uVSFc3 KqSrKbUMzNQX4YmMImPEtbmN6oYcujBYs+qzUBRCN7hiLB0tVYS6heqaPrMZ5JYZUDY1GNVM HjdXgHvePUdJeLPwkiS86DFF2t04bsN7WOV5hvFqRi/tRnC3Ovk3tkbekMSE0TylZaYy9ZYj yb6Z1QweN9PUV1aVyjlgXGdp5ytRrdF788sjuGPA46BGcEfFLkC9shtXckW8I1vSMGM3ylGG dDH9G9VuM8A1SNELUyn12zoOxL7yxdWai8ZMLdKUOea1dvGYF/rYerTsmLqP7djjNO6Yan80 2c6VPQpPu/dLU2wJ9W3BvzqakUMkuwku58sT8bL1rewJH5r4K9Z3trXPu7sbtMKnVb/ZFAoC BbXO+D4H/VZ21P4mE4aLrcVy+vXyQVio2eeS5/3nNXfQuwNPf3luutJTSrxM9cac3xb/aTOq ORteveQWzu3Q5N2Hv7qP51jaXvbhp/f2XIpxsf28ZcXS2afTQz1Ttk4o1eP/JH/+7f0DCH58 RPpx49pmbAqnhx6w+3aLSIHyH7j5j/LMp/tt/URPTz+000B/b6x5VTrl2CZ98yjThy/u21nH t7H98AsiNz0/yV1QnJVgX7MMr+7NQzuAht4d40cLKpEpHfqSGSiuP+euKa4nlbIUsb+4b70O vv3+4/uG9cHVi1Id/XnCeOrh/MXR85/uXZt/1iStVemIaOrv+C9SRG3j0rO7/SXHjb/qqhLl Ky3Vg0y9NrBt5kar+vpJKaiNoyvedqna2jbNMijCf+afP14J+t4UfIeV12et6fR16HaQS9Id injgpLzsUOz81GY7i17/n7n2m9+Rt73DSMRflvnPezS4BmNdmCYrTzFZTppUjdtr/vz6YKX/ I+NksNW8+cWBbXpNky9PcaTim0jpXExMV6a4bwu7nHJlw3Mo6cP9wQJUlJ+Ol/17q+mtKwGe jKyEcVds9mTYB9rFJnyQQ7Ry5u08zScqODpCBYyikjwLJaxtGLvunM7exWd21O+X3rbn1BP9 Oa5pqP6m/lvT2zbypTLGqBu6FNu0Dq+eMMbKQdemkSNtOPjBjDFyRKCXgcdrt3QNlzBRvGWK xjUOS3zOpnzTCT4VCINEAr2pZK1EDnbp7bxlgdyN6W2hfu/0dm0bnG8y6HRavxlyLbudt8CU e0N2+4DDO2W3a+43wfb9uZbcxiL6/OT2AYd3Sm5fWIbXkttNmHFj77OT2wcc3jo87YCV7ejO kqvv3XnH5PZIhVQ/Fkw3M+NmdVufaW90Kbmdt0CGuzG5LdTvndxus9fkg9mrre6mnT8OtZhX VB5BArps25FTee7qB0bnuRUVYaDSF+yhqonSTOPE/1kby4OT7MgTYqCeBbNtdnPKGytOstJ2 20/mlHejWpLJNl5Nec8bxPOuuUngMoL4Yvld4bnmbtk6FvLnndxzynu8nCH7mfcuvKK5lVxS 3rZY3qmQ8q7b9WK3JbFH2Kk9l3dC4TeH+2jH1GvK241yCmqsZZnuYse2mqR/63EvbLHmSnLm wE0Y+VWbyuWUd7O847bhTSnvA2pJeTu6GnKY8nZ0u2RLecc55X1cSeVqWRSkR10do3uUHm2/ rVnVl9Oj8IOUx5bKfjFg6eSMSybAFCfKpuxY44khASZLoI+HKbtyeeAuJsbrFqN1s/O4u6yB UKFN/CobY/K1jM9MJI9hVHS4DL7tse44o20LJ1nDC4lxTbsmxv0YqMPEON3eetXIu+gkHGs1 5igxLtSCyZeDt4ePHTjec6hXicSYK41ceSx4lfwdiXGX08sXFCgxvqN9ITFu9UPHClWhGSR+ 6fB5qHb8FrA8j6lfTIy3s6tZhMpJTmR7KkwpY+zl0d2b7GXp68S4mJh16h3lrNuKxeE8Hxmk C4lxEMljbc+52Ah+U9QqLfqaolLO8PZDBZ+cwR6HklDAoGSUMzEsMMqNCMYQBXEYh00UrgL8 qOWgUUVJKGBQMgqtKphe7VGYPCjq1Le1r1tRKQ8aR9MZRaXAV0pItTmVgQGnkdNBYSZQoHST o3dxe+kmcB0JJUXhFg4WGnGrRipoEOdEKaomPWPA1y2SjJygtOMCJHOTBqS3Y0dcNURFpcZW bZBCQVEpzIEnLjzVnrOMoVF3Y1ZQ3BYUKN2ElnvppvGCKaRVFGnhkHjmud3sdXqubXIQJguG +BQztzNGR/2O0ijMY2gABbOG3dngSUO6qJRaa1TwCRgpKgUMSkZhzBWMHgsmEAU4eIKNhh+1 HChQQiWh+BkqGcU8BU7Mw05yCYdK8NRXXVQKoylFpWStCQ1upqDwkqM8PgozgQKlm7D2pKgU j41Q+IWD496knUbSMjL8lBNM1hhpd6w99TsXr2IepFf0zUGySUO6qBT6K0WllNaYxgXGmIkz lbfglqlUhZJNMHmhoJloq4alqJSevYyBHvkp+MTCt/i5HRotgTNLVqYR577RjFg0pItKOcMx 8sozlqw4SkIBg7sS0KuCseoF44gCHCzBVsOPSg62R5Rs5t008V6ZFriABzCJCiqBw+jb2lcq KlX0+EpRKdk9UFbJ8Q0ZFF5ydJ8DhZlY01S6STSN4k5s94QiLhyWolJaI8Agx4FSVM0NFgzx 8WZuZ+x88jvvBMzDkSToLcOThqiolNe9kaJSmANPXHgKK0uKSmHfQmEmBU9rbyvdNK0+RZEX DtAzvdytZy9jLMuBdcEY8C2LJGM0pB3sUooHSYK+MTxpaFtrUmKVDJ4fS3u7Rhl2FzFXIoks 6Kqpw+fWB/UReilwJz5+v6fj7+NQN8y2R+2j21x0VKgSt8HtDC9qaQHjxAkoC4yaC4IJRAEO Y1gWU/6o5UBdAxsmGtTaYp4Co1XBFKKYerL2VVfjErcB1bhkAxQauA2oWAXThYpWoODx4W0G VbGwGBSFXzg41ohbNRLdMjL8lBOM1xhpd8wU9XtkyabtXfrmSO+zhnQ1LnEbUI1LaY1p4DY4 2eRpFrATQLPEpkU2weSFgmYiOx4VT6Sy6EgwnuWYDNeTaqf4uR0aLYEzS5anERdXhCSbNfRC NS5+STwlXoZkgT2K0sglaKFC1h2Yo0vQmidh9AX3m6huuAQtDIDR1nS9BO0c3w086OhtVDcI hbD+FOi/eNnYZpSWYoxOC9xEdcPNbAQw5Wa2d6rvdDPbc8XO9Tl9M7vhsAPQzexZGLRMv7Ho R9S3UV29CDBO5Up0RMqoeMtyd8TtZvH+jUL8VivPeTLzte7GxnPBHlDplm+4tyXNrGG/42Zw EdxTLZrDi+CBL5czJt8i1BEDHnY1FXZU0HrQIcQLF8ERxFQXwaNczllDnXItWwc/cXQRvTCV Uj9fBA9yqZwubwe5VL5OmWNeaxePeXEfqUfqMpPqI18RvEqlEnafeRGcL8UgtaruR+nXsMYU M3ifChNRz3eVczK0ZPeurPC8kSpNmTe5Cu64rPytVEce6+SfvuAW0y1qpBalMKJzqhLIbVRo 2fHL/iyLq4pq+EWOU33AeJV6v0Ll8w1z4Eh7ByOxbHbPu+eW6/aTkX5WGG1Pr5ntPYOxfUZd 7nG+3W+jer/ogPrF6/a4rXA958/UYb3dr287vK65A3kP0pUHzWB+qasXB1Tvc7vfNnfK5P/7 2/0PeSsF9uDTZ13vt72Sk69/Flf7XdnqfPWaSqgK9r6X+7P7f3O7/11u1EuSdkrbHvpv6rW/ eODtveyZ7Q492iu9KdYRESDnWEfBKQ07OOq/AoP6sAiPCowAqsIkokDYFhVlp5Dko5YDJ9KI UD3FOiICYRTrEDgxjyl1ozhUgqe+UgVZJM2wrUQE5PjUnhD94FhHQrKCTrZUhVXBOPnibJw4 wZUWirBw8Nyb9YwumMpyEMYbxkxJA2mXogXyO7TGPBwkSQs8aYgqyE5haqkgK8Fu1FBFS0/q KUcVY5EoA4wImIPWMuIUIywrsDczB2955k2h+SeFQfhb2sG7hsK3QJIpJaJ+LywZ8aiQxC7w pCFdQVZSJKju6gyMBOq/AoP6sM6MrV7BZvAVzNC8cBg+ubQRoVWWgzXC4XGszzIlvBTMKxwY 2ABwgI2Y+0oVZKegu1SQVbOGaqg6fsHVcdh9vASLKqwKtrOmUcmV41ACp5kDgvCOg/CikbrO I24HV4SEr4ckc5yRf0dSQXg4ksTXBZ40RBVko+6vVJCF7p+4yqxcS0CVVXBCFVYFWy3r451g xtpSsCOYeuc9zzy3m72IxmaWY9L9k2qnQJIpbiy/V8OSEQ+uORsWeNLQ2yvI9g+JNGPbK1Of 3f6NMiqn2rPN/SXN1td9hVQuuep6lVl39jdUmfVbFdU+iY4qrl4qMyte5MUys257GbW5GIeF X+dSrr57bM2zPacLlVx7JerGp79ZQS2LZqgWbXOGSnM00vrzp/FzU1jv6GWC7kzxVxP33Os5 uv64dSvFUGQvr9U70baVnYR0LGiz7Vz2LfyEepj7eNm0vcS7kXjWkhB/dfi+Z9Cu5O0epHdU hqfg4O4dFd4gjHdjAYYyHCCBDW3ljOFPBAjGjkXtULFgfHwFEWDAncdCAQ6eSk8DdjCewPjq l1Z9qdRqmGo9oK+AH1UYIRou5S/v8Uv67rNfEg1UFNpbVSjw//jl3dvmhR+xr+B5Xoy8OjBt xIY2ffUzHHiECqJlPELAjLibR8ndOo7sTaNBw43HSgEOJbsZRkqMMSHnpdUwNh30xHnMk9FX wI8vhKr8O8wL26a17dzaLsSm/rWrvUvST7u2S+ZeazEiWX+/vVU+Ds6fxcI3T9Bth25lmemF 37YntF9ziNgTxtbU742Wa8S817WmlL28RAgNjIrmV5rvAd9uo6vnCIEczIehb4PT3Puw/jgZ 2ItH5JvWFsqQkEszRZ8vx21ve4VXDvvjaK9qUtJVxrkw35XD/ky+MRi2Mtr9qzf47Ge0S2wh hsTUf5LvYPvsN7Of5J2hTPU5k2SG1KuKga76ty2IxkMwY60HPxIartjNtoVAqXyCH+9CGI0K BUVWwIFhfLxGMFSmEhzq2DO5DYLbE5ACFCwlcVj68The8Dn3N+B+uH38brPDP2tP0kvo2XAP U9KY1hqlJMbxkuFiKuw+cM2VoWXDGNrFAj6tFwzpjaqEEfz41tcvQ9ud+ocJYtvE1w8ArLW+ b4u1oUQnvrvp4ogsJa4vpjDjRBjHmTJZ+sZIDGRNPO7ExOFcJfr4FhcgtnQK7eIreLtyFjSP frXNUCv8Tck6FyecMOMqW6UaHlSV1Fb6Yl3C13xQgTYm+g5lqZHg6Wob4Me7LZvXv6eckDaz ZuT5Y+ILrgaFYw1ffKeJUZBvsKgTpTFZY9qhzRKXvMC4ohwzMqCJeQy3lq+hSS5VMCNuAEyD KX+M76YC5i+Y1kpJeb7mXAvy5xxvpJZdEEzUmAYTF6qZmEZ8yvPXn122dGOCv82TRxS2YcZc yxTEtviOEsN25mGL5ZgeY+iZcY/Ikp4bjEsnhnmMy4DFUExvHAYsjQRudgCW2Cl4bL1HgtDM GpL8lcJ40ogj2BJM2a2MuFEa88hyVZqGGe1EXD3ll3MDim66Ml5EaJjRTqH31QJ9s0tgjjZF JL0zeATCYK61Y4qbacatFsGMUZGXpgUOpLf2xDYWW9Bp26y9HbNCY+jeJ9eUbk8RH559LF0Q zPRU23gKyeIWmGOOhAn8PbESSG8cH6Z4veVCkQ1DY2TIGo6oYoPJthVkGtkakpYizUehQE4A I4r5SPFuG1GXEfF+PZfCkl0RzEhRu0QaKRw1p1mu4uy4AUYrNtBK4Ui91fAjX2wBjye+1qLX 37DcWKMbBq+EsvQRd0W4h7Ane5tjBRM1psF4xhBM93745aFaDGFoh6DbJ45eHhIYO1HNuIuy s6h87ZqtrmDGRXJgGkwUdD1fYNjYGN2yZ2CHyHXdRRiD3QiYWiPgPMG8ZwzjH9RupTDjdTBy siOVzqr0illMyEmNDaJjRm/G9rDBJEWd4Ef56nLi11PKuLWkdu/xlp3e4QWDq+mJ4EQw+REB V+Ippp/osg4u5qO2vvgVCOuI78GWI9KHTJTH43BKoJn3XcMN3wK4Z4WhfBm9cJs8fZExOvKt +Bt/8KQIM17d3DiQLRmzCN5YfwIYyoJQ1ZDkh4fTekOSBu4fnWcI06R0xIG8tbkfWzzfjStP sME9oDNWLN5QH/tvg7dKjR0e6wZwt+xjTQjF2JWqSzO8CT6eGNal0sGNOWyd39oYO8Mm6HiC pCAMyx3TDFM/phcTAr2LGB3eMfInb6p6M6FXArn1G1+B3u0Tbg7cXufi94CxdvD7UupFI5ua 2gl+OPjh/iF8+Ot7S979FjUaz/XIoTv12B7FJH7S4+ztNGLiYeWd4Mn/rZlyy8AkuicY6IZ0 otvfzalIGu4HN/rUBFPQl42YA619aqM/AUygox4dk+rYd9AG4P4EfTUZFCw3cVj6MY6zr6m/ 88PVBB96A31ltuK1ZsaUTMdT+p58GbtwO65aDb/DcTVtEe7c97F4cFxdP1inpnYzBv2aVOhV PulGk2sjaGtEtNC23Sad3FkSSMfVwILFZ3rpjafG14XwuSt/xy03bvHNK78Hx3yk0FSUbAA6 /ZWs7P+5t+ZCT4fJjBTVsKGH7+IrCmsFOxymxoHeEQ1903mH3oVh1/qnHv3revfa+lHBVoo3 YqsOLk+Y5vETXGY4IdojGFp2bnwfB9/CCI5DD4WXyg0Bl8B1n3FNJYQRqI0WOaVAWzQwgbbw SLfJFUx5DYVxRAEOMERVw49aDnILg6MPDBMmuGx1KwpOzAMY6Mjrvq197aYpeEeSInIcHH2r ie/KB4+PeyOWHDw+/23JCFL9foEzwZDNu0KYSBSA/cLBcW/STiNJy7/JQZgomEyYMrVDhXzU 75ElAw9IEhZ40tCmNYqVon/PfcSTHp0noeGKZc3c06iPI3CD8wKnuSXeIEhaRUFR3FB0b7cN DaOHsRKMZTmge8FM2ldwmCR1El9mHognmwW28wz4jS7wdmASLEwA3nvrCzgaX0067f/YjOv8 OZxnhRkRhGCpJntyBJMxTbinxnKAgs2IX2CYFcGMmzXCYbz9I23gG/QiBSggJTjM/dh8p17U u9nwP/6Ae/ndVu9sy3hs7tG+o6ZMYgVjiGJksRmm8vhNCMaMU8D4BoJyqCxZROVQqQMJfTvN jwxdO+Riq20D8u7pMO3n7JvO8BN69utN55cyvt3ZNlz+0PWn+4eqK2fe5p/zV/awYj2f5cl3 Hsaq7dlhhr3ZKdtXPvZSj+2fStnHTb+LspuF9XYo2+MCyRfiSR2VkuWhpzt086x7/TF45Zbf xV3kadSNM3qW+jFYHXDlRLx6waVcEOp2L7h+H93qPn5/aSQ3p8DW79kL3m4t6QXka5oWkEew zI3jqsAB1ykZQ56noSOyx2GUknTesRfcPGejcd3DxZeC6aloiGKEuRgO7IsxJtLSHmmhFCp5 VTTtCJ7tKoZ/Mm5/GruKefPudpVnjv4m8pWZk9bj9EPPHLQ/m1uaJFbkL9iIEXdOm1/v/pQa vG1m0wdmWbwkq/OXn29ywtn2ysamH7/t8c6l74WMtIdNHD4CxtOZEmks8lApUAO4+7Qocwsf dmxgzIHhJF4wYSqd64gD/Gi0IacaSMEUkJI4LP0YgbQ+GDft0T9UJcjFkTHVxq0WN3roNAat 1eQnuPWHXT4lEUwiMHSFNXjKDIcwHWgBvz0Sl9woa25VWfOvpW63BOIS/3W6x6//ybjf9wt+ oxS6/HzIJx6sGl/oS80l08o1f06GZS+efQ/DkvMW2GuGJVYYli8u2l46l/652t7L4r1BRf2t 3P65nH6KslBR3936vub1jraLd46l7ykBPCnr9X1jbvZ9vb5wDv1DJf0thVxf37uY4+f6scwh fS89agdjPuVt7vmP762bOvP64C3Xsedj+Qi4s200ZO/pXW6BOcsCTKI9xKB0N132ozsngGFd b7quva7uZMbUreesPucBJdi2V7VVol+f6R9JaJr68nU39QIupht8db6pY3obtYfVqLI6YRqc 9TMKxpVKxpBumUOga5BoI3DQF3IEusvRMFljgkPZU+IhMEd7GEOB4jjLufR1BI5RAJFDoA51 tpDJFxpUWW4YenuNAuEeZRILXSFF2cHMgX+8L4YcGcNx5sCzzeFtMdEIMJHlwFMoHyF8nZ3b sXWBM0tmtQZa30hLCHHPGhqBYx91/7d0wypb8Em3tGHC1NL2WodQNBiScBjYo39mpnBu5iC5 U3rxgosFCyaIHNB9YozRGAWXud3CMxw8kArx9M5ggWSThrY39W7yfeejr1yaBuZpPpTS5UdU e7y4UynKd7bZfvMA+8Xn8LpdiF4kyJ8fTUE5JcpKpnfqUTy3Zno4eXp/SvfobXlEuuZFGZW+ FeUJ4/kC2ig+JTBfeGQMYsh0UcwHClOP6Qh4iRB7UpylqXDpykoweCULlP3+jHmHOFza0rb9 VTUflzicXyNwL+VP5q4+KwwFhmwgmOyMpVuCnm0geQdCQff3mEMuszoFE7H3E5z83Aa/mMBS gAJSRn88ZDp/8rpLKD9YleySLbMQ2+49PYLEqafQmcBVEqcDE2hPofLcPkRaSlTeJEReSlMK kFZziKxrqtIW5Ct7b7zu0t/K6os97667rJ92E93cNFECv+oI74cwbRuKOoLglzQy4PfwcX1O 4u7/tBvaC6Gx8V5D9BIVIoyhsR2zYXiflV/1ASz+hFDQ513BgWHPUSFgEvb5wSFin6c2YpGo UJkoWMpkZ9h/VmjsB6oECY3Rmk/43krw5LkQht+OMmGGA1ytt643yhL1l4ac590JEai/uJ8X nq3bi6W9fhWOY0fEP14XbE+PlP6paX4tdH1su8v21/e9WkI7A0aNpXdQu1FLp6ZDVz6TxbbI fnn3vwlp6+VlbmRzdHJlYW0KZW5kb2JqCjYyIDAgb2JqCjk3MzQKZW5kb2JqCjY1IDAgb2Jq Cjw8L0xlbmd0aCA2NiAwIFIvRmlsdGVyIC9GbGF0ZURlY29kZT4+CnN0cmVhbQp4nOVd3Y8k uW1/n7+iH2cMTFvfH3k7Owcnju3Yt5sYwdkPwTjOxZhJYCexkf8+Uok/klJV9/TsztnB5Ra7 12KxKIqSKIqUWL8/mbN1J9P/4MfTy505/aj9/de739+Vs+//bQ/076eX0w8+3n3/q3yq55pO H3/b8O3p0bZHMZlzyeVknTvbWE8fX+6+vncP9pyLi+7eHPyK/Ovx4TGcfSg1qMfl6LFVj3/9 8cd33tRzKK3+j79p9X318Ni4qNal+78ej63rjNJjq6ruT7/8ePeL1lpb7bmWcEoxn2t1pxeB DNDp+S6kDXQEobee7765++X3Tv9+93UTqjHJNVGc4+nXrfLf3KWzi6c/3dnTj9vf3911BF9q aUjHP7/60V2IyWn6LwJhHj5s/L/WW9Y3VqbOCulcbbEn5/w5ZeqsLx8efeuxxzB+nR7K/c/7 j3/uoP968PffPNgGfXTtny69QTjSQIjlTN3QhPvxd7raJgcX0Ad/9fCYB5U/Pth0HzrxrUjV J6n9qT/7j1bpv9Pff+mAJ7Dzb/0tPG4kLJHc4P/MdOXX9jRx8W/7Px96ZT8fNbbi9m6n99uH JupaTLz/Q6PciKT7/xwVT/D/bqhPM7yD/vBQB7OdaOtVWyPECLQhQ1fcmICbbP5Dt1O9upX7 g99QDxAc+M+98Q3m7v9HxrU99T9/+Nc7Z4zpw8bZvA2bkFvHBH/6w7/c/fZ7GJnl9NNtdN4y MhXBshD8cGfNRul3d8770LFi9LFjvQgklITx+2p9rQEl+m02RheJkjUpbZRcrINSgxQNaeVK 5byUt7qf7hQkEAYoeConXX5qfATiI1CtJboJUqIBp2YpO9BgSBgYbmrb2tanplWqAY6zo/0l 5Inuc8OxBCkREFAa0q4mThjVJJTDqKkaUC1uwTAzhVzRmriTSJz473wA4hIgeYJUU1AOo8zP HThLkwSqQU844myWUJeaNTaP/isZoyY7PQb6qLHU584zhN4adbdy1BitHKgcMI6sJ0gkDJTz QqHwyCMasfDoBUT4IEixDCHuCzhDOcz1lsicBS2BVqYRXQqVJwk93XVdbQjGcy14ryHPHRI0 pJWnmaLK1H8KYgiDKIxxI3UEGlnCB0ZWg8TpHWf8RFPKjmn4iS+mQHwvbd1Gzfa78Mh66VSM pvuscIbkN0ie+mLr2alMuqZ48JaM7l8p5zpTyIVbU3YSgcYSPjCe0VdM14W5HhrPzBlmjqJB ckXbLDibJLRJzZeg27uNmrpIjXHGexvET5R9sVPNvpiFN5/rxL1ghIUC5kDwdpERQ1iO/FYu DJl7g+ul3uLn3J9Mo4ATv5QnCW1zLbI+8iS1yiOWLDxbecyOOVznMavK0EcCcYQBCpbKQZef FB8BtcZsNcRGrJWhzOVoQCNN/d0oGN22ta3bqEnO6v5/6VQmPfHccSBpxxCnZd/KYSlH3VdP dwpiZozR361MUs+ZJRJ2Elk1NNfrAkPSNDqlbOd6MXOEhl044fIkoU1qhbUPNHS1Ro+BZ4Xj LEOm2WeH4SG8lYiZA+05TBWZW4KRFgqQ2liG9foqEOHD6b54VvUUcDb1uCoH5sxqCdhhNJ1g 6awS6nOt2Z4Dpq3R8VYovJty1k5rXcMK3mnIc4dMOK0c9chQZZKkghjCmFY7qQOrn/ABHdUg k9ZqZTPRlLJjGtMMFArE99LWPracTZMGbu23szZ5VjhY/Rpk0nWtHJcy7A4P3hhiZ4xMrYM9 hNWvcRt2EsGMFD4wxiNDMAMXTpxfypY5m+aotM2Cs0lCm9QWXb+NmrJIjXGw+jWImyjLWjZq lrUOvPk8WasKIywUIo+8RTMIhOUoa10BBHSpN7he6i1ZDdGfsh6CE7eUJwn1Gfn1Kfhzjqe2 /SR/iYO3pO0rK03NMgTqN9W8QSom69eE7WrCRpOWEYaEanhq34aVMtQEbRoYQry8AQsK5kjl pDdjDQFvk5awBmTbOrwNy2XC4hoJsm1534RlS1mwAPkUrERYmbESYZW3YV0ZXEpIYSfwvBtc ifZMPBQFEiwzFWFF87qRy2IvNMi8TuQyaVZVJs0ikGF1CYVhlUgdgVZg4YNnd4zTPqqVJwtL lR3TmHZzQoHWjaWtmwZMZtojvHQqTtN9VjjFMwR6ZGiJhBVqYLTytON9ulMQM2OQpkp20mW9 NWnVdwxhnchv8brBdF2Y6xnWkXCKVUBokDZP2JsNS26V0Ca1jF3xaF8fNXVa1fuoge1gC0Ow ItEogPVANWW/2IwNMu2jVNnPFODTaOKbrPVnBYFFLG9lgUz7KKmHeoefwzIXGoXmAPwCBZyl eQQ0S46tP+yavMkYsTQjG6RoiDdlGgWqTOOkvYGZkwYGKIRI5aTLT4qPQCrMsaU6IG1YF12L lHmGC2T0DFOgube0dRs1Ff4IVoAlTPbls8KB98ixJU6S5p0mrem8KyzgjfeN1JtSTjOFnFgi fhkjDGEtwG/B4yY1OzfXQ3YQP7eFOZtnwHB+9jI4myTUpeaNK7p9fdTAJgkFowY4NjGEet3S KOD9Go0S5+eaFKTOGI5GIu8BHY+8pfcEEiLzAdkLJGiI1DNmo3pembNpF9zKWY+AVUJ9rt0e EbS+gU2Yokx9A+IbxdQmebQUZfrlw2PTna333X3YghWmB5AeQzjnNKIgv3xoS7dp8rv/aQ91 FGd8JtzHxqlryFtQj5CZXNx+tj1Avf9iw7bn2CinfE7lCuURCmyyT437n9x9/N5CtL2STKP5 A+K2kWxqTEgyagKLrlvI5+x2GNSI0eJyiHKhEbaNfX+E/Ubu5shQrF3nhZOPYUw9n0+2ZooM 9ZCQuTFYuadUQOnD58WVt4Wg2FNoo9N4GkQqzvsTjumGgxZ6P3YSPmLrrVt4S8u8H0tyo2AX Cp/ZstA0RLSltayerb3WsqO+c2Eo9KH86yn3vmtD4Q1NUyTSIFGYxIfuOS66gtDYVxWox2k8 zurlpqvHcpqHSZFjVjHHNgMNPR28tyFug3sHmQ5t2FROqz5HDmz30wM5ZB325zjlbZLKQ7vm zDt8QGAzfuhx0a3RzayF9wQQ63lnYeOwPZpJibgUQzJjtT3JiPXbYnmXQhDPWybr7RBzyvCg MsTzpvbaZih5MEgN83E4OCaWMejgWUs+09rsVLdizwTF0bATYZONYd+rm1uDaiyn3HePmDp/ M6ZOcOZYF7g6tlPJjxCxqwHs3Dph6ti1zhT8OzSo+09aRa1B8dx06b5BRyrAJh6DW+f5KbB/ S4MUhSgU3qWHmsHUG3RhIh7qakM+gTxMI5/TG5vTKEDreKHwHs3ZojdxNIdNGWmO6p2vT22p HpONnFlvUzR1zEef4MGJwxxu89Hu5qPzNWl0H7wa0ut83GO/2/Dt2+E65qPJB8P3kxVv8mPO Bugnhnjl0YLUBGuR4+tqEEQjVzMpxsknFMfS155BzwNicB5l0+BjV1JSZg0+ILmKni+0lynD EfYikFyT1LwMKrUYrMSpuonhPFw4ouVbJXHfvMvyWdBfdnzr6uCslbXLu1zeUJ1Cj0xg5//1 1tNilLClswFL685LzM8Mlspj7EXQ24LfTwKqvt5PSFRiSzL62UuHWC2Lw0qOTAJyPyQniz3r fTN8Mc3k2hTlfKBrtwrTPrdhe8EmpWjtkGsoftjtxZ8qm3i7h+FUIxl4dAasUTV7HtRTu6vT meH0CG70WyPJVR49oxovK9aa6IRR4j6CdZZcudRH7VnlPhqQiBjzB+mACH/BUZfs56UZroim T+DSOzABeV66oXaa+QbnMkOujElB4vYCQj7toRR5bU+XpcICN3QWCwI/Wj8ENy+dg0e+jAl+ 1Kf62c19GjLbv3F4OACZ+tSPOLlgC8S7y/NOXnM783lXCYKFiiWGXKlEveaW14qy98Pw+YQw PJRX+4Fx4zyBrgm0iW8ojRjSZYHaOBxebXHFQZ44nLhgfxI7nhVvdthKfpfXlTi8VKEf4wZT E5sjurLDwkj0plzu3SNlbNbN0V55rENvajEM5pShqdORqllZEaQ6v9a6ci9WeWZXbMPY1zWw zNmrmniEckJxFNz2MuqcSVPnOut43sqo+jY12Lc38WjhfG10kn8kJA4Zh6HeGwHmEsHqhgUR UGAZkKktQrMwTRrxYtrchnVDBF0IrDH1halhOxrndg31iqkbsK5a2eNUWbBMgGKpwahq8oik Afaye49C8G6lxSF4kWMaJ1wbLditvIZl8dtQfzXj36w9GPbLAJ6xNvKGOCaIpik1M5bJN5nc u2pWNXhcTROfXUUqwexxmMUXnhEMuW0fcECA+0F6cI/FJkC5shrXkKl90K01jNUoe2nxovo3 rN1igEOQIhfGUuK3ZWyIG1t8ADNYDZlNpBwv01qbeEwLbfQ5LCumbqMNI9AP2DHWfmuS81i5 sHq/ts1aXH2b88+NamQTyWaCwzbraCBe1r6VLeFDFX9N+0669mV3coNmOM5nYJokCzfSfiXh Z2mPfZMKw7HWXKGYr2yEGbuIzcXv50+r7qB1B5b+8t50oKekchnrMyN+qd8n626yePbiJnsM 5xR6EOqvH+K5bbJCuP/Rgz2XYlxsj7egWDr7dHqsZ4rrCaZ6/R/l598+PALhh0eoHzaqzUjL PSJWB9G/Ycy/5+o/yDsfH7YTkdHT24/dweA2J/FZYm9Nxm1+pvsvHtpq4Zs0739G2OZcegsQ 1VOUFWNfMQ9vbs1jG+ohtOYYP2pQUUxp0A+YgKL6E26aonpCwNIUJfkvHlqrg2/Pf/jQoD64 epGro58n9Kfuzp8dvf/xoZvM1iQtVmmISOrv+BcJosaz7aHdfnduo6+aqlj5uebqUYZe69g2 cqNVbf2oBNQ60hVvO1dNg7d1tCrEf+LHH644fW9yvkPLq73WvPs6NDvIJNkMigMj5XWDYmen xlCtnv+fOPcbzz3s65t6SQjUyjT/SfcG16bTXZgGKw8xmU8aVfXbW35+dTDT/4Fh0tlq3Pzs QDe9pcrXhzhC8Y2ldC4mpitDvO1rSjn1TVXajXCp6fHhYAIqzI/H0/69xfS5MwGWjMyEcS5s tmTYBtr5JnyQTbQY88BiiMJiQ4exGKKwJM5C4ey2EmxWwhzO3vlnKLzdsCn4/X7h7dz0UaPc FvwlDNUvx39ueNtGPlLGEHU+l3yb1uLiiUBko2vjiOJZG2AHA2Kq9BJdBbaGj9UCYr1Yy+SN s9vxS+2fa8blTTovDXPbSiCB7ik1yL6bEd7OWxTI3RjeFmz7TuE0hLdrONvaqOpwWj8Zci26 nbfTeE7Hpt8Y3c45KwrvEz0d0e22bLeVYd+ea8FtTLlPD25jGr5/cPvCNLwW3G4MUKT9U4Pb jUISCu/TPensSKsssfrenPcLbscRCql2TJi+Axl3kNpsrHulS+HqvG0gHQW3LypdxvaE/W6j l4LbtXf6wejVWneTzp+GWMwbkn0gAF225cipOHe1A6Lj3AqLIBDpK/pQpSFpqjFp+i9aWR7t ZJPuqBeBOGuUVrd6xr0oSJXtKu2YMRVeFOR6yHtaIF521c0h73GPSzS/KzzW4i1Lx4L+suN7 DnmPOyiynnlX8huqW9El5G23aueQd90OF7sRxMZya3ZM8TOcRzvGXkPeW7w4TH3NsjgKpxb9 bIuyVC2LSyHvnZkw4qttaWeB7ULezg4f3G0h74adBHsJeTs6QLKFvOMS8paH+5D3cR6Vq0lR 4Bx01XOUdQ2P6mc3h0dhBymLLekTL8vUyTHx1Ak0uETYFB1rFBz35IBkcfRxN21+5ksddzEw vuX6GOpGjMf9lT5yFTbDD3OdIelKxGdBktfQK9pdBtv2WHbsz7Xp9YDsJVxFxg+WNJmLz27p +TYnxR07Rnu0OxWACLdgCyRedt4evXZkeM+uXsUSQ65UcuW1YKPqrU3luRxeP6AguHxA4ZbA uNcvHQtUuWb4iM7YfB6KHc9CstewXw2MN5vcL0zloF3zKxYrkxIu9+6Ryjbr7NqrmHXoHcWs 24zF5jwdKaQLgXEgyWsu7he09ZnGlqDfbSmlhsehyQu6jtI9OQN1hIRQDTKSMVDCqO5vXcqc cIchgTBAgVL2cB10+QfpnhqELB8khAIECaNQqypX0ABk+AGFwmjb2taRUsoSzJAOREopaT+S KjmTDSCglCkNU5owkLjJmUS8IbVTg+QFI45ynMqSUkpLJE78S0opZyxDwIm1cz1j5ZLnJoOz OEkA6bJamTibJUQppag/EUJBSimMAUkg1d4LDKFeH4Yc0jIBA4mbpCakdgK3qlxnCtbwyAt6 rD5riGc+InEvEKo5LZyMlVHqSZk5i1oC0toEziYJ6ZRSaq5RAgzpUSSEAgQJozCmpYxRryCF MNDeRGWvy0+KD4wsJITidyhhFNOUcmUafuKLKRDfS1t1Sin0pqSUUrqGcbJlCFHKRDkWjYHE TZh7klKK+0LKeaaQRCLQT5klUpae4bcsRg3TtW6uZ4xG4cyw1EDDgJO8lCcJ6ZRSaK+klFJS YxyTGeInypSWSZXNwhsls2DuGYNaxxSs55Fnd6PXLnLkt+A/FbrUG1wv9RY/5/5kGhlJp/w0 IhYJ6ZRSjTc+92Aws0iLIyEUIDgrAbmqsiT2mWaOUKB1rvI8oQvkwgfrIwo289yKaepNKQdO S8WQoTcpKRXatraVUkpN/SsppUD3mdNOQY4bBJIdNVFaJlWOs6SR2gm9JWXSi0yBNSclkJok EjT/mg8rkKhHnyrbpWyYM8wJcOKW8jIDJKUUWiMppdSIZhyTGIK5hjRMVmMgcZPMagWpM4ZF Eiqny5JSahq964rLb+FGiHCS4lwPzT15XpkzN/UnpcviubdIaJtrkmCVFJ4fk306Ril7RNKS jHR0nJKyVE0b9WEgF5gTH77d3fG3sakbyt8jF9ltJjryU4nZgDxZonjdYkgg0xYmu5SxgCtI IYzJTJA6YDYIHzAbkEmL37F2Um2qXJmGmfhiCsT30ladi0vMBuTikgVQcGA2IF8VlBvyWQGD +4cHskBSnTHGZEFWLTEbkHlLlINAuGf4LZgNQte6uR5r5rJhqaXJLJC2cXmSkM7FJWYDcnEp qS1GguTiYspiJlA5LyYNcmIx92JGuJkCzAZk3ppG76Jk5S2YDUI3gZMy9RY/5/4UQ4KydaFt GZxNEnolFxdfEk9It4KDec5b1ho4XaywKOoOyNEh6InmgOgD7jdh3XAIWggAorXpegjaOT4b eNDQ27BuYApu/cnRv7sKACm2BWE5zaDDArdh3XAyGw5MOZntnWo7ncwG7GX3nj6Z7S3PQDqZ PTPDNceF9QPs27CuNnDsUxXrcL5S6pbl7EjajeKdN4qfVZz4xRFvQCaanK4HWLrmG85tSTWr 2++4GhwE95SJ5vAgeODD5QyJNzF1QADdrofCDgtSD9qFeOEgOJyY6iB4VAd9FlenHMvWzk9s XUQuwNLi54PgQR0qtxoyhQSu0lqbeEyLD4JTi9RhJtVGPiJ4FUsCdnCLvv0gOA7FQCfJ+Sh9 DWv0psF9KjUQ95oLhuuRKSve/VuxptiaHAV3lHz2dqwji3WyT18xi+kUNUKLkhbROZUJ5DYs 1Oz4sj/zYp3CSoS13H5qWOYWLLG7b0iLOElv3xPLYveye285bp/mtU4gWp9eU9t7AiN2EdNR dfRM3S86wH71uD1OK1yP+Qv2erpfn3Z4W3UH/B6EKw+qwfhSRy8OsN7ndL9tpiinYvoLnu5/ 7CtOP96fPul4v23dVlpr2rbg/8Lpfle2TF/eNK7C/+/z/e9ypp7DtHPg9tCC44t/OFM/23uv 22a7bY+2S2/ydkQ4zQMoZbh3sYYj/ysgyA+Ld1SZdnYKYghj9n5wHZ7CNcIHezsinPXk7aD8 sExDypVpTC5XoUB8Lm3VGWThpnzhDLJq3844cNwiyyoctcjCynvdZCf/iGSQ5f2zlPNMgb0d Ma27dIbwTp7fYm8H07Vurme4NqXMHgXmdUgA2XHZB7FIiDLIRt3+F84gK+5u5FBFTRtkchEj CyswkKdVnMrI5MqtEQw/U7CBR97knH9WEDjA5S3cNpR6EjibgiJSb3bMmZtGQIY/L9McmSWk M8g23nDWjrK7NgiNeuR/BQT5YfEOMsjKGFYQR2+AgqFy0uUnxQdLhB3VNLcoPyzPXyljPAtk tJ8pDD7XtuoMsujfF84gq0YN4+CKK7KsOroG6zjoQ5LmQBMk7ThMhPxvwKC5xxQQLHYcUuA5 z5AgfCBIEhkSNUSV/VwvwgqKhiGMeQYsEtIZZB1fA0YGWcj+WeFYy5CsKSELKzCQpxUzSzLI Yi4pjLRQSHgjo/dk9C79KW9hey71ZHA2eY5VOTBnQUsA2XGdyeBsktDnZ5DtTjYbt2y5Z7e/ U0b5VF3N/SKgbavMQY5UTrrqwpY51t+QZtb3b0o+9l69KUNrKluaWfN6mll3ju702KfkUf7a OZmr73ZgM27Pe9RxJL9v9RpKW8ID1SyioWS0fSPUTY20Pv84nneRNTvuMoLrNyVP5hL5urXH 8D3MtW/6UdlmMT+2wZd2PNLeoB85KPsqvqQ2bhz2LUciq9iznAT554eXPoO2Jm83Ir0dgdlQ sHv3dOwDEO8cZfAZNgGXc6HVnCEBNgJD/NiP+S0XeS+PPPpwA6PcaawYoGBnLhz0JyC+Ys/P kDK0MlqChA9oK8pPypcQDWfzl8v873BTNFBe6N4MW2lW/4Vv8N42Liq5M/EZC++c0xDvxjrq PcYJyo57iFbaWriHAPHUQ0isi3EyfJModxorBlEoMc1ls9YakllqDZZqpWMCPtO4GG1F+ekV f5V7h3FhXd/wlX6YU7T9W2d7E33bzrftemLlfTuJSOrfD3+FZZX+VhJtWrUh1jfIXjQrXfpt i0J7mkPEojDWph7cLeUKMq92rSqlLi8hdnqGU5pfqd42i7Hr6NbhcG7I1nwoetOvAHRVvzyd FOzFXfJNcwu5SMiqmVzQl523t93j5QsxtLtXiSnpPOOcne+yo3xB3wgMXRnN7lw8sNuzxb0Q Q2TsP8v3p32qbjDOF4cSJelMEh76xd32yp+2q2vBjYCOzeiR4EPQkBDgnR36AGWxmhliB9eN wtA6fsRfWx1el7uWaevjyPsSkagTkCZHojJ2hSmMI0DBjfAFyk83a6GjrOxtre3fMY+bNp6z sq+ppW9y7FC0L3m+XkCnbCWBqEDG1U7JGUmfxDAm6PJ2Xmn0nsUmCLdwNISyVVsnkK1LJbuh QOijfpHyrCb6/C0+25j4U7xpnKSOic9eU7AJOB0ycELmjxGnTBA4oy2SCGlI1RAbPTDMXOYP 3EaP8JhhGoDgjKgE2hgyHEuAtDIw4lLGmbqaENe1TIMg+HaYi7T5URByVhDERXJN1GEkOuJ+ 3LseriaPwCe52jwCmn4pW35j0Ijs3BFIoHfo4okhLlzUZenRBvFzj7oofTzuAtiETzvWREFH vvUll0iyQKKG8M3AhFN1KOP0vy0Z1wL5LB9ik/wpIpoN1uLDLZgvDTJcZQb3FckpYub7i093 w6nWL1I6Up6Wbr9rSA36ra0eooPchsKdF36DhrBUiIqU4TjC6cQjSe6ljcVwDEmB1FhQLqOc UMZdDLoH0qiOOxIRNIdkVTnhjbyOA4GMWhPdkqCQm4wl6AsZb/wBq0iLghqz43KZzC+ZTXxG l2ecQGA403loCrO7mtNc5g/B1jF/lL5g7RB2GkRBjIZY4r+Vw1yWj+GOhV/0n2i7zD0KjSgQ N0HQo42KWcpx7h+leQUy9Q80vmhvz6esoeGlvfTJS7VKJKxHcYV4kknGmoaz2UWXn+RjEDxT MJuSlbO9NcwrY09/QasnSekb1sbJcdiU7t4ifXunHRzhJIZEggxn5Oa06+UhzeFy3MpwXxrK L46PzRkHDKIwttaJPjvbx9fYNDVuHbexzhBbye5yPDbq2IKDbmvfkB0+Pk0hpcQfQWtzAZzQ +ftIb9BKuUhoOOI+9TM1TW30nDO9Bzi3/1dr8o5tR9e9QL+9a2qk7WPa5ikEbFIej7/I0czB 4VaJyATAkC2vQTf1KGlVoFvV9DUelDcTM08YdNyTKaAc8VFUgQw9yBQiJUhHHRGObOaCMcA3 UVja8bRdJT/9+Kadz3dXCN9sdnjfSSQKwSKTY/BDvQPCNr/h2i21h4b8bVHU4MhrYRCPDREX 0rDjChEXIIjviOsgY6FUZUhXIIkwphiL1IEYi/ABtRVcnWk4jtOVuYxFREEsYVjdtrWtXd6t DxCXo81GcIgAY8kLPlCsA4stes6ZoWB4l0YYwQfa1+HLcMEHRGLLjEEJF5gCvg3YuEVEIrNE CIKNOvaXziAXp9B1bq5nfBtQyvg2oNRsseNENAWcTRLapBZwNQm5/gMOthmYmCHgMhK+Ddgg iPWMURD4PDvtjlOca2oQRHLqjOHsTAHGU4CpJL3HEHwbsL2FvhBI1BBVznM9+DagQIYEpG00 AhYJvTmyM1YGtab0BvZ9vz37KF8GPE5tFej2RNsC0FXPfHIhqAs2m669MdVOoLsXM7X49kRB S5uiSZv30rYBVrx4tTfvoL//44M1F1o3tIulK+w2dNfTW77jdoXCZ7Yob2nImpEs572utOit SY+CpSQkAYc/g6ONHEGCK4RR/FSO7GFiyDidEuxIiDSM2F4epjjKTzqrjK+026S9SRecd/Fg YF3B/CwR90+P50636XbOJBYeHrfki1q4yNz0lnxbwVo6E4gDu8FSzpWgPialXH6Bknzwt7UF AlNkqE9Ltmpb2oMu3+56O1IK4Ry2TxDW9n85Xuh1hi2VweomESDtWsSdt3VAjANasY1vk077 H32CGkrNJMOUISOYHkyl8lCorLACK1jr/IyBoZ+WMvbeAgk0kEHB+7kODwONuSAM5jIsZdTR c9CcTWk986fvcCu/WQa5HadDMGR7Q900qH2li5KecvVxmeOsgIThGAmUoIH11o6JD3uFP1Ke OL0AtQ5593CAVmNXqu7e/89aK8q2S2wWZOAkebesfp6iDAYxRYEUUjmVnG6WbBNndLlbL8MK FIxhETEFLmMNEIgni4gosC1HdVC525XEBTCYS6KwtOONW8DvqhBkCzh8HHlzlbixyc0agpWm bLnopWw5mPShTTv6Ttqff+b4WpaZk95p5vTk2/2MU9MYTW3SzPn48FiP84iWEUT4C4jgpjBu Gfr8ooL5NBFteVY3ETVDhET0RdcrYXU+bUeRmpLjKwGOccS31UWYTo+O4+1XvietaPfcg73B EtJ/dHRM6dikx/Wf2aR/+4aFqeVvw7zvJhx/c/ZdzXs7BXu3hbZoiIeHnmKjUuZjVIAEj4V2 bFQDbW0NOUUCjhy+bs3Nb7woSBlajIxkF8ZnMQIut1N5s3PyjEFxOaaAMrgSyLBDhUJ0cx0R W3/mgjCYy+SOW66tuT6+vrst/WbexNG56zi8RvMmjgw/ZOGAGh83FztyeKd9nN0yQvdcwSXr fdyXD/kwv3WwiItV3lG+edsPCu+87S/bPsy36esubPvT5237yzIuHaW/wKx2pUyjDmWOKgqE XLDIy0UX59ooK7rc9YLaOvKQivg27/rClH2WnYgVn0ASCO1CPC5p04aA3Ocoi4ueMZCWAhS4 nNii42g/jtuMWKXBMZhRh+f0F+BCMMBlSXMZdcgM+e62sWsLaB1Pn5Xcr8hje2QR+333lbaN rz6Oz3ym6F1X2uE2UwEWQwdTCdIMd7oX5+1Ujjh7IhAKUCBLAZ0KaVvaqMu3rLTzGy8CCSNO 2aYhlcntbMd1LpSf2PYRDO8mCigzVwKhPQooRJemOqi8eRTihMF8E4Vdy/cr7Xe1pctKS2fF rTtwl+5WWkauC/Jne0y97QfWQ98v3bTSjp1k44TX/LeutEwhvrdeiJ1uLhIGed+V1i3jkvJT 8qx2xU2jjsvsoWMIPHLD/4b0Fk02Tpd3Ky0mAu6ayQsqqbhyz1Ho1xskN2MIfbIlUNr/NppG 2Y3gFMrbIVJHl+34k3iBMp4DAqqu2LlcTTpux3BtRORXgNKFa3m2GOzYpyT6JuXmLuAxt0yV PXJ+t+HVFPwpJyNf4+vDqw0SW7cD7FsYzsTL/jlfMx2toZR9wtut3y25TOHzFEHfI8bx+R1W BK/7TVjG9q3tgGuDKZj3aUf2m/+nt8Oil76Qrtm5IcbJmn4Q3rGTg3o0TN8tfLR86UrFVoWF NpK9w02CX90/oMYvpXLTFeuvHt525Dm4MUGjR9aaEMbhrwahw18hjEO2gLRy1e+osoWpCAid 02AKgdyXqCPAVGQ+5BSGqxoSnJtpSBkhDYZEUpBu5nNp63aewGXCkVMY4zwB6D4rHD6F4cY+ Nno6hUGKFxjBjdum0bPJQLHP6HOZMSjOzxTkFIZ3q0QAicIHQfgUBtfjwBnKZq6XT2EIBJyQ lEjZLhIapzBM1u3voyatvDEODpM2SJpqCiZojFYGJ3zWwaB9dsZwfqbgAo88guAIskDkfAje ypkhbuoNKde53sIjnCE0B0akKvoCziYJfd6xvo2LHi/IonbC5vz0LnVF2mzCaGK9/5k4R7// MH+CrO+X+kVZ1jOBvac3Emi9l8oJ10f3r2d//Powi2zJ2+VbzxdYr1HYrm8MEutNjl/c/S9S +ax/ZW5kc3RyZWFtCmVuZG9iago2NiAwIG9iago5NDYwCmVuZG9iago2OSAwIG9iago8PC9M ZW5ndGggNzAgMCBSL0ZpbHRlciAvRmxhdGVEZWNvZGU+PgpzdHJlYW0KeJzlfVuTLMlt3vv8 in6cYcS08n7x21Ji8OIVvdxzLIZipQd6SGrNmJFDpCX+fWdW4gOQWdU9PWdmLceajLMxQKGQ SOQNCaDQ/3YyZ+tOpv8ffzy93JnTz9u/f7n7t7ty9v1/2wP999PL6aef7/7m23yq55pOn//Y 6O3p0bZHMZlzyeVknTvbWE+fX+6+u3cP9pyLi+7eHPwV+a/Hh8dw9qHUoB6Xo8dWPf7nz7+6 86aeQ2ntf/59a+/bh8cmRbUu3f/deGxdF5Qey8tpe/qzz3e/ab211Z5rCacU87lWd3oRzECd nu9C2lBHGHrr+e77u9/+5PSvd981pRqTXFPFOZ7+uTX++7t0dvH01zt7+lX796e7TuBLLY3o +M9vf34XYnKa/4tgWIZPm/yvjZb1TZRpsEI8h1zsyXl7jpUG62cPj76N2GMYf50eyv03/Y/f ddT/fvD33z/Yhn107T9de4NxpIkQy5mGoSn38590s00PLmAM/svDYx5c/uPBpvvQmW8gNZ+k 9af+7H+1Rv+V/v2hI54gzv/sb+FxY2GJ5Yb/HfPdcInBX/b/fOpNfDPaaeD2Rufyx4em4FpM vP9z4zeY/GW0Nz349wdrIQgeNNx4+IfWh7+M9jI9+91M2httY21rvP8fmypdiWqa9j4JMbRO L2w66LL+vv37i0xje+r///O/3DkTTZ8lzqbaZ0nIbRyCP/35D3d//AkmYjn9/TYZb5mIVxh+ urNm4/SnO+dL6FQxum1yvgimTTVM11fbax2oxm+LL7pAnKy1aePkuiSdU8MUjWlwHXCoC7zx eLpTmEQUxCEEgpOGn5ocAXLY0Wo1bsJUYwC7BWYejImDwk19W/v61DaRGkFj/eh/qXni2ySJ ljA5AQNOeXCOcYET4EiyRXDNYaFwCweL3sSdRhjDcgBjCzBox5IkBfDQiTyH1lgSS5KEBZ41 1LVmTcpj/MZs67PGOT0HnjsNjflo+Vm9NdpucFzgQHCieWSSJ0wmCsB15uAMz7ywm72ECSIH YbJnDEmfIQngNLebM0sGHpAkLfCkoae7vjXHrHXUtBaKX7QWStCYBictvYJpNBTGEQU4GIK9 hp+0HNCRi3F6x0U/8RTYMw8/ySUcMsFTX7dZ4w3G21H/3djtwPdZ0eTImDyNhTdlgaseuyab t0aPr4LtwkE0gv3JskaASSwH5jPGivnaNLdD85klw8pRPCBJXuBJQ5vWgg9aI9usqYvWmGa8 t2H8xDl4u8BmkS24OkkvFGnhgDUQil10JBjLclit6w0zjwa3S6MlzzGewgOS+AWeNLSttcT7 EbRWecbSXmkrz9kNY+s8ZxVMfBUmEAU4OIKDhp+UHB6tJmc1xiY+K80CW/Cw03g3DkbLtfZ1 mzUpY7QM9T/xmYuxSXnS9IZxWpMNDpqiwVGPVZeNMXamGPZLg72GN40QT19ZI0FrdZNjOgk2 TNKniYL93K5lrTEPM0tiINmkoU1rlXcf7NA1Tbp+VjTWM2ZafXYYHhpGS5jRw1SR3ghFXjgU nnkYY5m9Ts+KTQ6nx+JZtZMhyTTiCuYZDkkyJPELPGmor7U2kQdOW6PjrZBpjD/dtaGczrpG FcpiM7jlPGxw1NpXMM0/hXFEMZ12qg0aZSUH7UgNY6d3LI+5W2DPPKZZoThkgqd+9Lnltpmp T782+HkeQaHB6ee2WSZ7ndtmzAQnPaJPdwrjFwpLMNa0aATrz7JGgEksB+Z4ZgxW4CLJmOUK 9izZtEalbwxPGtq0Jnt95FlTFq3JWecY4ybOcpYR7JaTuWHKJL1QpIVD5plnFh0JxrIcRuu6 Y/i0gyRlGi15jvEUHpDELfCkob4ivzs13eR4atdPco84OEds8aOBTdiuUO9dJozFYv2OqL2h YY/eEjUw28Ia1LdRtT0I20SloQSGZHkDFTaYoy2nvJlqKNiayFQDY2J6K1XORMUtEsbE8kaq zUCYqID5EqpEVJWpBsYk8zaqK5NLKSldPgkwuVyiOxNPRcF4z0IlM/kSGlWBvYczuWHmc6L4 aWdVMFkHCmOIgjgMq0za8HQCKzmwlpOZeSQz3cQU7JnHdJtTHBLBU1+3HTDhlLAWWjLLyS80 fG6kiH2EOKfpZGnwdOPtsjHGLRTUO5x5sORcsut+JxjsifyWFYzTGAWHWVKcAorH2DMT7maW JJs1tGktl+lc7LMmrNJm2A7WMGayERvsppYy7jdoqWGme5SC48Ih8szD6AWevbgjVJaDMKkw xmrtSzt0jvBzWObCY2igwdMtadXQZsmx9RdIa966aQ4/d8x0/nrrJ70K7GmetDeqXkvCwSeC k4aflBy4NTm2VLE+K6QwC8wrvE5yCofRt7Wv26yp8EfwBlhq1HyfFQ28R44tcdI03zTpTOdb YcaM5nsjrS2Gx3gLh5RZI36nEa/l3+SAHSQYWG1+bmesLfXcsGTzChjOzw5DsklDXWve5KL7 12cNbBLMaKExhTE06uPganDQFA32c0uCGatPwY7g6Wa2zbzpdvCsMD6zHNB9YkzQ2pd2xtqT 5/DVCo8MSbKeAauG+lq7PQBofUObMAWVugPdN46pB5UQAfztw2PTTDuz3X3YghXmXMLpsc2P nEa047cP7eg2ztb7v+9RjuKMz0T7aM+l0W4hPKJlbnH7s10K6v1XG3FrNJ0em3pSucI4brRt wqQm/Nd3n3+yMG2vJNN4/pSEDU2A1h/hybQJIppy6iOX3Y6EemG6/I/lkORCN3pwwh9Rv1W+ OTaUenSk6d9HP7YFn9v1OVFsqAeFzI3RyT2n0jjlERR6VyC5OxJrsafQDGSTaRqpwO7XHMQN Bz30YdwlfMTlO0Ou1sNbeubDOJQPOLyzZ6Gt82jLqd+vjL/Ws6Oxa/bZtqUPM7Gech+7Nhfe 0LU9i8IsPnXfcdFPQxNfNbB/nNXLztEdLg8TKsesoo7OkaHDT5OEEN+lU7ddENum027gKXMk u6cL5IDlPhSJSOVNmmqb8RA44WrFGCtXKzMs2mQK/CfAWMd3C5uG9ZGsRWSKMUlf+UZw32bP 9xTCOKayPg01p0yWt2AcX2uvXYdSgYB0dfFpuDgmkTHp4FtLPtHp7Lp3nIYVtyZsHI06zdT2 o4a5bzexnLbhwNnyi7F0gjMX9gIzLlTJRzJpgpqTN+0FZtxbGwcrHNwHdMg3S7cxbx0K5+QP OnS0Bdg8z0E/hfZv6dAVDu8dIWe3Dl1YiIfjY8krkIdx6HN66/hY3nVWDu8dn2q2Cde7E/yu O2p0vju1ZT0WG7mz3rbRhEozjDeaYRC39eh367EZ1rTC4uhw0DNgXY+KOg7q8FHq2VyOYz1a ezB9v3jjTWWs2YD9iTFe+bSgNaFa9Pj6NgimmZuZNsbZKzSOvmQd9nlgTLRqBx/3khIr7+AD k4vs84VuMyUW3OcIk0uWlpdJpQ6DlTk1NwlchhNHdvnWSNx377J+FvKXndyTS5bctXJ2NUx5 Q3OKPDODnQe4GSB0GEW+1FU6SN3eT4xnBkflMfWi6OJGroka64MFiUZstUY/21IHrdbFYSNH JgE5IJLlSSD7vh3emGaRbat+TunancJ00z2gbjzd0GsoDm7IU40w8eThMOqbHioMPMoCa1yd cIUlcPzU49Xh9mj270ibitKkeuamZ0daw0ZiDUVtkowRnWvJ7hYDxigmZ3mMBiYiyvxJBiDC Y3A0JPt1aYYzopk8MNsOTEBel25sOzEl9mYDc2VOKiK3vEZe7bEp8tmeL2uFFW7G1NODsTs/ LtEKm7YtxUtj2p6lN49pyGz/xuHjAGYaUz8i5UItGBcurzt5LezM510jCBcqkRhzpRH1Wlhe K8rej8PrE0LYLYrdOFyivaZQF0fiRIg+X1aojcPl1aYvbfQ2DjcuxJ/UjmcFE1FRK/1dPlfi 8FMFbywLNYk5dLOjwkz0xlwe3aPN2OiFs/V4t3msU2/qMQzmlLBT56OtZhWFiXjPIUwzHy82 0p65hTpViTpd3YFlzV7bie0I5rTxG/cZq3Z/Z+00uM463v1lVv2QO9gPt/Bquml2kn8kJASN G8YSAzYrEa4O2yGuQ8vATH0RnoZ50owX0+Y2qhti6MJgjaovQg3b0SDFWHU0KKFuoLqmzzzy yoJlBhRNDUY1k0csDbiX3XsUhHcLLwnCix7TyHENhv02fIYlnmcYL5+C3Y3gbnXyM96NvCGJ CaN5SstMZdItV5J9M+s2eNxMU59dVcrjnEc6iy+8Ihhz2z3ggAGPgxrBHRWbAPnKaVzrGCxX K/brOk6j7GVIl61/o9odBkiDFL0wlVK/reNC3MQSKqsxs4mU0mVeaxePeaGPrUfLian7aOMI 9QN3TLW/mmzGV/fC0+n92hRbXH2b88+NZuQSyWaCi+7yRLy8+1a2hA+3+Gu777TXvuxyN2iF I0ODcw8S3EhqnXE+Bz1Le+qbtjAktubC4dfLF2GmLmxzyfvly5o76N2Bpb+8N6X0lGQuU70z 5tesgJS7myycfZQPycI5hR6E+ruHeI5t3ob7nz/YcynGxfZ4i4qls0+nx/b6iFwJpXr9H+TP Xz48guBvj0g/bVxbj1M4PXaH3e83jxQo/xs3/0ne+fyw7VvR09uPti1Du3m4zxJ8axtl/6Dh /quHZln5ps37XxO16eHJymE9xVkJ9i3L8ObePLYVFXp3jB8tqECmdOinzEBx/Zq7prieVMhS NP/VQ+t18O353z40rG/b8UWpjv48YTz1cP766P3PD/1G3RazVqt0RDT1X/kvUkRt49Kju310 Nv6qq0qUb7RUjzL12sC2mRut6utnpaA2kK5426VqBoHJvirCf+THn644fW9yvmOXV3et+fZ1 aHaQSbIZFAdGyusGxc5OjVtGsqz/L1z7bTn0sK/vMXd4/GWZf929wTUY68I0WXmKyXrSpGrc 3vLntwcr/b8zTgZbzZtfH+xNb2ny9SmOUHwTKZ2LienKFG/mQSmnnpORdjNcWnp8OFiAivLz 8bL/aDW9dyXAkpGVMDLDZkuGbaCdb8IHuUSLMQ8qxmgqGDpCBYyikjgLhbNtGKfuHM7e+Wco vC3UHxfebhtX/6o+uzUM1b+Gf294uy1hmBmMURm65Nu0Fp+eCEYuujaNKF7DwQ4GxhS5ItDH wA0HYwQY68RaJm9czysgXoyJN93g0zC3rQQS6Eulhgm7YUZ4O9M39reFt4X6o8Pb1bcdtXHV 4bSeGXItup03x5R7R3T7gMMHRbdr6Jlg+/5cC25jEX15cPuAwwcFty8sw2vB7SbMyNj74uD2 AYd3B7ebfUu7yhKr7935wOD2CIVUgxIWLo6vkNpmYfebLoWr8+bIcDcGt4X6o4PbbfaafDB7 9a67aeevQy3mDdU9EIAu23HkVJx722S2eiIS51ZUhIFKX9kPVd2RtjUmzf9Fb5ZHN9mkB+pF MM44tatbveJeFKbIlZ1uzI1qCSY3qqsh7+mAeNk1N4e8hxNfdn5XMNdcvuXoWMhfdnLPIe/x FYqcZw2T39DcSi4hb5srn1QIeW9B5W3QvK04bt1OKH6GfLRj6jXkvcWLgx5rWaY737Gttuhn W5Slal1cCnnvzIQRX7WqnM0u5O3sSHi+LeR9QC0hb0epIYchb0fZJVvIO84h7+NKKlfLosA5 2AwKqnmxD4+2Z2tU9fXwKOwgZbGluF8MWDo5FF46hKmibIqONQ7swSRMFkcfD1M2/vLAXQyM b584jO1GjMddsgZchc3ww1pnTLwW8ZmJ5DWMinaXwbY91h37c23iIGt4JTCuadfAuB8DdRgY p+ytN428i0bcsV5jjgLjQi2YeNl5e/TakeE9u3qVSIy50siV14JRwd8R1nHZv56gcIn2lcC4 1y8dK1S5ZhD4pcvnodrxLGB5HlO/Ghh3lT8qXsTUgXFFxZtJTpdH92jLNuvq2m8x69Q7ilnb hO8qBaM3pAuBcRDJay7uD7T1maaWoN9tRaWGx8EZPn6o4FPD0KmFklDAoGRUM3jqAqPciGAi URCHcdmUNhx90IWCTw1Do4qSUMCgZBRaFdhb8GAMlZ1yU9/Wvo6iUnac8Vska4sdUVEp8H3m wlPOJAcMOCXazNJEgdJNjr7F7aWbCmFGQEkoIh2EEXBCb+JOI8DAzylvGcZAErNIMmKCeN76 WyFZnDSAglkjQtfhWUNUVIrGEyEUFJXCHJASUiN2SZhEmDEryG8LCpRuQstPXOwJ0gJuvbGa A2ApKjXN3qDn2ibHWL4mCsYTJmpJMDrSTqwsWdQaQG8bDMkmDemiUmqtUQkMYKSoFDAoGYUx VzB6zBhajcxhzBtpw6FACcuBmYWSUPwOlYxingxzq4LxRBEnuZe+6qJSGE0pKiVrDTRYWVJU ylEcH4WZQIHSTVh7UlSKx4bhYecIh5i5N2WnkbKMDL9lGAO+JsztjLUnkhkDyQYPns/UN6yt VUO6qBT6K0WllNaIBu9JUSnmTIWZuGUqVaFko3IWLL1QBM0BsBSVmmavXfTIb8EmFr40Gtwu jRY/5/FkHjTi1DeeEYuGdFGpJhvnKkSsLBTeqjxnURIqa70K7LDqBZOJAusmEew1/KTlwH5E wWY+TZOdRlPBHjwYQwWVnNV9W/tKRaWm8ZWiUnJ6oKyS4wwZFF5ylM+BwkysaSrdJJpGcSfe 9wQ2MwfeOamE1KSRoOXXchjBUMsmzpKMk0/BliULWgMomKXgZQVIUSn0RopKYQ5IUSmsrA0z nVsozKRgM69qYFgWgaeyVOidFJWaZi9O3MRyECYKZlp90s4YDXmOU0p4JEgSFnjS0LbW2FFJ aZTOj6W9pVGGNRGT0imFyPHlRFdNHUrWF/Wh5FzZoP9Bb8c/xKVuHCAetY9uM9FRoUrMBlTK ko3XLYYEam1hsSsYNRcYMya2W8wEaQNmg8iBzR21tPgdOy8WgblVwXiimI6Qta+6GpeYDajG JQcgaMRsQMUqbF2oaAUKHh8+ZhTGzBQ0UR0MSZgNqL01aSQsI8NvGcEkjVGwW2DDkk1mAfqG LWjVkK7GJWYDqnEprYmRUBnjJs50GHPLYiRANqqKxdILRdAcxGxA7a1p9ppFj2IkZGDAl0aD 26XREjMC4ymGBK0B76YZsWjolWpc/JF4CrwMh+POeRSlkSRooULUHZijJOiJJ2FUgvtNVDck QQsDYPRuuiZBO8e5gQcdvY3qBqHg1p8c/ReTjduBsGQzTGGBm6huyMyGA1Mys71TfafMbM8V O9f3dGZ2wzmminthuOU4i35EfRvV1USAcU9VosP5SsVbltyRvJvF+y8K8axmnvO0zde8GxvP BXtApVu+IW9LmlndfsfNIBHcUy2aw0TwwMnljAm3CHXEgIddTYUdFbQetAvxQiI4nJgqETxK cs7q6pS0bO38xNVF9AIqrX5OBA8qqdxqzBQSuMpr7eIxL04Epx6pZCbVR04RvEqlAnZfnAiO pBh8rCD5UfozrDGaBt9TqYm4X9hsuB6YssLzVqoptiap4I7Lyt9KdWSxTvbpK2YxZVEjtCiF EZ1TlUBuo0LLjj/2Z1lMUFSJqDiRnjBehd6vUFl3wxw41N5+JJbD7mX33pJun+azjjFF76fX tu09g+FKirrc45zdb6P6vuiA+tV0e2QrXI/5C/Wa3a+zHd7W3IG8B+HKg2Ywv1TqxQHVx2T3 2zYoJv/nZ/c/tv2op6779EXp/bZXcmrG2P8Lqf3NqO91vppp0Ouh/X+d3P8hCfUco52jtofm m/rqLx0Ye68bZrs7jzZKb3J1JHjM2dVR4NvFAY7yr8CgPCy8owqma53CWKIAB0Pw5JF8UnLw hTQhCkGuDioPy64OhtnVIRhPFFNEZO2rLiArXlsUkFWXdqZhV0dCrIIutglOFobhHMHVOCGO NmxUgWOdOUQ4fxJiG6IRYPgaz28ZLm3L8bowt0POgjTH8zbJJlcGiuMqeNIQFZCNur9SQFZ8 3SihipY2zOQfRhFWBVstqxSQhVdWUcSFQ+KZN3nmnzXGsByT7p9VOwmSTBERaReOC+GRIIlf 4ElDuoCsREhQ3NUZbBIo/woMysM6M056FJDF2utlPP2kecXBEZw0/KTlgEbYS431WSfHlYJ5 hTNm9Fc4JIKnvuoCshhfKSCrZg3T4PtWFFl19A2s44gPw2HWtOMYEbmhhMIuHAxrxO804rX8 UkC2SZ8ZgwgIJAEc5nYRU1A8IIlb4ElDuoCs42+AUUAWun9WNMhKQJFVcEIRVgVPTlIpIIu1 pSjywqFg5jmMnszeKb4nBWSh+2fVToIkk9tYwZElw/hBkrTAk4beX0C2V4Fu191eLPfs9h+U UTXVdvfcvtFs++NBhVQuuerCVjnW31Bl1m9VVPv1+ub6rE0F5vUys277GLUvpKP6tXMpV99t zWbZnvekIx+/+x+bqdg280Ati2qoFq1z/TcYwUEefx6Pm8Z6Ry8TdIdO/zXQC9zrObr+Or7B XIemfybUO9FmY9qJSPeCXkm57Jv4GXUx9wHrd+hERrFnNQnxN4cffAZtTN5uQ3o3grLNWoUL kFI+gPFuTPxQhgnEcC50mDOGfyOAMVt8r79TR3kOP359BS5gwJ3HQsEcqPY0YIftExhf7dKq L4laHT1BsQf0FfCT8iNEw7X85UN+id998VeigapCe6sqBf4nf71727wIcGXyvMhOY9qIjduH T2WGHY8QHbQ18wgBMxxvnovqjju798MvCbjxWCnAoYRJirZh1qXVEN3SahjHDnriPObJ6Cvg p1d8VfYD5kX/DCC3zb7nT/Fm/9bV3r+h6NfdrT6Ee+uOEWn7b5tuPy0sb+lvZdE/GHLbrdvL 1kpf/LZDoT3NIeJQGGdT/2mUUq4Q82nXmlL75SXCzs9wSfMrzfevtvsmXT07N+RqPnZ603P9 +16/PJ122Iu35JsWFwqRkFUz+Z8ve25v+4hX7vvjdq+qUlIy41ya78p9fybfGIzNMtT9xzf4 4c9QF/dCDIGp/6/82rTf6oj18qiBmvCZKnSq4Oxv7rZX/rp9txbc4C9++UCfBAATQkSIPGjY 8c+YMYa+6mocxoaRx7EYkOGYcZ+50VtC2bDJw3HjZGRwTxDMsOlNolI34+PJkSu0wchYq4bq NCLgaZO3K2bcr5NFrbdGM8Y0cTaSYCgzjH5sJFlkrQUN95xa+unhhDuNNVTtNPGPC5pxnwwZ 31S1typhcH+Ow8oPueDWFseNGZgGg8LOcMbNHRgu7cNcObztzYjqNQzfc2zUGE89Ch4/e0Gy evyIhzdU0suPwFmDHcFpgflmRNl+FXEGhaEbCOUHUsEgtOoq/AWQq2EsUdDxO4wo9Azwpg+K 6KJcmIsVMV7GULgocqoLMIG8N5H8EmGslabTrGGZAw1T5jnQuMqsGN7FhPwr+UQD4YK2dzjC cN6epayvTDl3Q0uNIi4w58J5fJjFmX5D09bipx2xfqzFXoYVBgxWILgoGPdwM38O3HmM9TVh kn5raxkfdgaWjlqWXEWbNIa1QlwUjNxwyv870uRe20EwXmMabAgeWYOG8p5T4HGmzOdEPztu hre0wWWGo+U36joPgKEf78SsjbTDYC5Fy6ua5lvEinWR8vTVnKWsWDWvGVNo1tJ6w+6B6G9x 3E4iDOY5rTfef6yGn+5kxWVe1QZrcMEEDoryDuSqSB8JI/uW1xj0psFjfsbxQRt4dOmpWKAb yUENpisWJYUB9uy1BSYrndGOmnjnxj6dZdYEjcGsaXCc4WLmOaDPA2Cc1XMA55CcKSojm84d +Kts4sqnfHY5OvGc2WGQgz3ZQHJGSq74mPNiVGHFJouWsar1eT2uHDjTuz3jzFiByXHxMxPp 5McqdaYOo85VwWR6a4yiGakjDTYED4n5Z8+doeLv+NkxU0BBHMYsTg4X/Cbt6JFHdgTbFwoz fMZod8Okma9DO2O1GIvnSLQ0FhSVKAzxJElnDb3N53b0kzTNsmrTrk/xwx/bGReC7QbXvT5/ 7JHRcA4nxz/f1K7njtw3cwGMYMkvS0nLNnQjO6os6V6V4NbfG2rcEnEb8z00IWJ4e7WH0Q1W QN9Se2UPb1WI+5e9T+2W5+//48GaqbzHW+s8eEpkclzZ0Vf6CoAwvpA3mqrWMlzws66CISum 0ncxdeyPAf7fCtvpkx6G+eGLwowGgvW0iTuCQ9VwM+wtha+YAgeDXWAIwJgyNmPmUIqd2ihY YiwFU5CUzGHtZP96n2pb/Hg7+X0by2AoNproa8BtJVWuYLBd4vDZgSJ2QlzevVBC9VsuSPd1 WFR6DA+PPQcgHxb0CXZcB4fZDkne8ntVioNfOLxz0dtz2CrXpcknqRd9eseiX6dKm47br26r JetxlRnHucD4hUrBjI9cgiPPIKXeBZun1NO+6IehsvlaKaweKFkLmHZFpwoE4wBhOOE411tH GKeRTyi1yphsyCcworw+u5ldBrtAX2kyRRz2LnMAnHiNMGY4HplD8mEWGfkELAVTQG5wmPtB W8evfsQd/H5bIL+6C/RpZrt9RJ4RVmMCpdgnQzOR4BjhImAM1e2AWyekYXAF+pgT8NNb887W nabdErtN0n9Z0HkOAz62g7qZ1vGSsTGM/0gffE17zRcYG5e4vXvfyZtujZQR+6X07Jv+Z63F xPcbHq0PdP1BskhA+VDC+MoRpjrDEe4TxoyE0EAVXPA7FIGSHAAPh140vpp02v8xrJHpjReF ofVjRxJTIxjrh84AwNtB7WcKuvgxB8CBj11gIu2d4EC/kMNtJD7aIQUoIGUMxz3v5V3OprQp wCbJj7Sn309nBPk3jhfe3jYpM/HHGPHdq9br2fXvFEtebBNaWxcslCG8HZe4L7JQyszh464l vUfdn5jr6zvFO60Vv8xUF8q0zr3DrKozzGcEY8YnTWH7Beg+0sMB3OZh1HDfKVRtumDxOr40 kImqfrlFhSvoXFO7GyWvA4NTNFCam5zcnk+p3V213ebpW/184fjAPVQo04cNuN1+4LL1wr7t aFBrsZJsdd+Lm6YC/A17Du9eoGn7tcsqt+zPD4/1uHRmyX7WsXljP/Yc7Mf0oztq4qiYmjFK X8nQhJ27xPWobLsyIZr6iweMKH7i2sct+ux6BBmZP4k5QYR28/fuJET/dP+ARn8m7Zu+5/3T wxsyHfq0ceMmET2qBrZVHAlD7taGyRoTAv2SvR+VxBWMk4gxmSxncMhkWaMNuOVEDjhXg0tF Y4JL4JEXGNY4Y+iCzRxG39a+9tMs+OGwbfYmQp+OArceTupAWRgx4Nu64Om3FMJwyuO+pmBP MMKjjDF1pjAULh3uwQYn1ohbNQJMcSwHYVCnjfnSzyQ2mHpDd0B+Hpa7ZqTcI+4bw7OGNq1R +VX096Xfa6zWfZ81IeuWNkzUnBocFthrWfs8Cugf3U/C1F/hEPm2VIOem88KkwvLMen+WdoJ uPkFq8dPnlue4eBhIUlc4ElD3VnbNDtu8ZxSECIl2nLZ0IbxGhPo9ycdueQVjB5HSnmlH4ZR HCzBVsNPWg6ZR3HiQbMErSh4OfNZTuGA+T31daw1JKZWHPQ01xyHBpjGcvIDf1030vQ5sYAo wrZON5hlw0dqZMUK7BYOjntDGCfrCJjCclDKa+V9gVo2tUztmJomyQyCTooHJUUgrbZCsklD m9Yihciof9usKXp0noXGIDUF63EEQLYdt04thVrmlhQmLhQ0E5FujhJpIcZ19ARjWQ7onveF WqfRQDsWa5qfR7TDPBJJ4qYZsGhoBEa+0P+QzOYd7ElxAcaKOpTXO8Swla1FAarcM+/edIdg DmJ0hY/xNrRjq5uo5xxfD21Ij6hgQRpBwS+5FdHvISBY+WH+E3O2vUdtOpYfIFjTbkIjsSBU +E/J6woMzmhLoXaBg+wjhBlZoYEKDNtIaVOWSphF7AjqHuLpI3EbA9+m2656cA8RymgWyne7 +bcfnGg7ADvftqv05werlYvb21vqwfNMj4Z9IlSZJaqCw+qah5wzWzJMU8I4bOxj+7QexxbV pCIYzsj3bAQ2918zkM9fva4Ar26xt6nAYDrwTXeeEM+3ONHCMk2BieNLlGDHl3/4MFoUb7HV U0EioaCpzxzmpfCkFgcZ8OAQUp7aIHhzLcWZAnKDw9yP2Yn24+3l98skt8OyxJTtntpxugPj 60i8sZ49t8QSNwXBkB1tRuiR962dELP3YxNgpGU6fQDtvR8HlO/fdeAYb8IV/v2TW46qQBXp uBCGYMhVFahsjC1wA1kNd6OHPqRnCpTMB4e5hL6YSZZ+lpA5mBKnNgyynlgKpoCU4DD3Y0So 3rS1/mg1oUJZ205fNgvPjQzlojE4Gyr9ng2fFabwpA+UYXPDXKdcm4+e6/0uWtoJ2w7Ywr8u csUXNlwRx/Le5gsbrtcP70cb6v7zb60f0aIfX/XleuQFi/2LPf5y7BcPTnm4kJXUBHRB+bhU HtLXD22DKC6695sgVKMyVqwT66YT+fbPWo7yqdqM3Gxu57X5BOHbMDctRBPr/a+lc3/zMP/O U0/G69UzlML2LLK/yqK4c/+kxXF1ids50OeGbR22gfD87eI1BsEZRxy2P4P2QL5iyiAdVBJ3 CEPRZTKPHBUZbadl1vB2yJuZApkR4LBmSggmIXGH4GjnNpCUK1KAAlKmBUYb2pS5bWL+WDWx M3fILaRytcqE6SvwQB0mFI3xFdWpRnBUYFR/YAzOFso/52QYO1yHgBejiD5piJbNT8IEaHck fAZ87mKD1XDX1fDLCQVFwZjDGhUTjCMDlThE76c2IpLqWQqmgNxuga0Y2ZI392Pt5G7SrR31 tUwYXyJi02GG4etiDCX7+zo+9OE8GDOunjoPBtc9rWCKtkaps/ibu/8D6Pwl12VuZHN0cmVh bQplbmRvYmoKNzAgMCBvYmoKOTYxNgplbmRvYmoKNCAwIG9iago8PC9UeXBlL1BhZ2UvTWVk aWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2Vz PDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA5IDAgUgo+PgovQ29udGVudHMgNSAwIFIK Pj4KZW5kb2JqCjEwIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4NDJd Ci9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYgL1Rl eHRdCi9Gb250IDE0IDAgUgo+PgovQ29udGVudHMgMTEgMCBSCj4+CmVuZG9iagoxNSAwIG9i ago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDkwL1BhcmVu dCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAxOCAwIFIK Pj4KL0NvbnRlbnRzIDE2IDAgUgo+PgplbmRvYmoKMTkgMCBvYmoKPDwvVHlwZS9QYWdlL01l ZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291cmNl czw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMjIgMCBSCj4+Ci9Db250ZW50cyAyMCAw IFIKPj4KZW5kb2JqCjIzIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5NSA4 NDJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9QREYg L1RleHRdCi9Gb250IDI2IDAgUgo+PgovQ29udGVudHMgMjQgMCBSCj4+CmVuZG9iagoyNyAw IG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDkwL1Bh cmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCAzMCAw IFIKPj4KL0NvbnRlbnRzIDI4IDAgUgo+PgplbmRvYmoKMzEgMCBvYmoKPDwvVHlwZS9QYWdl L01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jlc291 cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgMzQgMCBSCj4+Ci9Db250ZW50cyAz MiAwIFIKPj4KZW5kb2JqCjM1IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAwIDU5 NSA4NDJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0Wy9Q REYgL1RleHRdCi9Gb250IDM4IDAgUgo+PgovQ29udGVudHMgMzYgMCBSCj4+CmVuZG9iagoz OSAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRlIDkw L1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9udCA0 MiAwIFIKPj4KL0NvbnRlbnRzIDQwIDAgUgo+PgplbmRvYmoKNDMgMCBvYmoKPDwvVHlwZS9Q YWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIKL1Jl c291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNDcgMCBSCj4+Ci9Db250ZW50 cyA0NCAwIFIKPj4KZW5kb2JqCjQ4IDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBbMCAw IDU5NSA4NDJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9jU2V0 Wy9QREYgL1RleHRdCi9Gb250IDUxIDAgUgo+PgovQ29udGVudHMgNDkgMCBSCj4+CmVuZG9i ago1MiAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90YXRl IDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQovRm9u dCA1NSAwIFIKPj4KL0NvbnRlbnRzIDUzIDAgUgo+PgplbmRvYmoKNTYgMCBvYmoKPDwvVHlw ZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAwIFIK L1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNTkgMCBSCj4+Ci9Db250 ZW50cyA1NyAwIFIKPj4KZW5kb2JqCjYwIDAgb2JqCjw8L1R5cGUvUGFnZS9NZWRpYUJveCBb MCAwIDU5NSA4NDJdCi9Sb3RhdGUgOTAvUGFyZW50IDMgMCBSCi9SZXNvdXJjZXM8PC9Qcm9j U2V0Wy9QREYgL1RleHRdCi9Gb250IDYzIDAgUgo+PgovQ29udGVudHMgNjEgMCBSCj4+CmVu ZG9iago2NCAwIG9iago8PC9UeXBlL1BhZ2UvTWVkaWFCb3ggWzAgMCA1OTUgODQyXQovUm90 YXRlIDkwL1BhcmVudCAzIDAgUgovUmVzb3VyY2VzPDwvUHJvY1NldFsvUERGIC9UZXh0XQov Rm9udCA2NyAwIFIKPj4KL0NvbnRlbnRzIDY1IDAgUgo+PgplbmRvYmoKNjggMCBvYmoKPDwv VHlwZS9QYWdlL01lZGlhQm94IFswIDAgNTk1IDg0Ml0KL1JvdGF0ZSA5MC9QYXJlbnQgMyAw IFIKL1Jlc291cmNlczw8L1Byb2NTZXRbL1BERiAvVGV4dF0KL0ZvbnQgNzEgMCBSCj4+Ci9D b250ZW50cyA2OSAwIFIKPj4KZW5kb2JqCjMgMCBvYmoKPDwgL1R5cGUgL1BhZ2VzIC9LaWRz IFsKNCAwIFIKMTAgMCBSCjE1IDAgUgoxOSAwIFIKMjMgMCBSCjI3IDAgUgozMSAwIFIKMzUg MCBSCjM5IDAgUgo0MyAwIFIKNDggMCBSCjUyIDAgUgo1NiAwIFIKNjAgMCBSCjY0IDAgUgo2 OCAwIFIKXSAvQ291bnQgMTYKL1JvdGF0ZSA5MD4+CmVuZG9iagoxIDAgb2JqCjw8L1R5cGUg L0NhdGFsb2cgL1BhZ2VzIDMgMCBSCj4+CmVuZG9iago5IDAgb2JqCjw8L1I4CjggMCBSL1I3 CjcgMCBSPj4KZW5kb2JqCjE0IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjcKNyAwIFI+PgplbmRv YmoKMTggMCBvYmoKPDwvUjgKOCAwIFIvUjcKNyAwIFI+PgplbmRvYmoKMjIgMCBvYmoKPDwv UjEzCjEzIDAgUi9SNwo3IDAgUj4+CmVuZG9iagoyNiAwIG9iago8PC9SMTMKMTMgMCBSL1I3 CjcgMCBSPj4KZW5kb2JqCjMwIDAgb2JqCjw8L1IxMwoxMyAwIFIvUjcKNyAwIFI+PgplbmRv YmoKMzQgMCBvYmoKPDwvUjEzCjEzIDAgUi9SNwo3IDAgUj4+CmVuZG9iagozOCAwIG9iago8 PC9SMTMKMTMgMCBSL1I3CjcgMCBSPj4KZW5kb2JqCjQyIDAgb2JqCjw8L1IxMwoxMyAwIFIv UjcKNyAwIFI+PgplbmRvYmoKNDcgMCBvYmoKPDwvUjgKOCAwIFIvUjcKNyAwIFIvUjQ2CjQ2 IDAgUj4+CmVuZG9iago1MSAwIG9iago8PC9SMTMKMTMgMCBSL1I3CjcgMCBSPj4KZW5kb2Jq CjU1IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjcKNyAwIFI+PgplbmRvYmoKNTkgMCBvYmoKPDwv UjEzCjEzIDAgUi9SNwo3IDAgUj4+CmVuZG9iago2MyAwIG9iago8PC9SMTMKMTMgMCBSL1I3 CjcgMCBSPj4KZW5kb2JqCjY3IDAgb2JqCjw8L1IxMwoxMyAwIFIvUjcKNyAwIFI+PgplbmRv YmoKNzEgMCBvYmoKPDwvUjEzCjEzIDAgUi9SNwo3IDAgUj4+CmVuZG9iagoxMyAwIG9iago8 PC9CYXNlRm9udC9IZWx2ZXRpY2EtQm9sZC9UeXBlL0ZvbnQKL1N1YnR5cGUvVHlwZTE+Pgpl bmRvYmoKOCAwIG9iago8PC9CYXNlRm9udC9Db3VyaWVyL1R5cGUvRm9udAovRW5jb2Rpbmcg NzIgMCBSL1N1YnR5cGUvVHlwZTE+PgplbmRvYmoKNzIgMCBvYmoKPDwvVHlwZS9FbmNvZGlu Zy9EaWZmZXJlbmNlc1sKMzkvcXVvdGVzaW5nbGUKMTQ5L2J1bGxldF0+PgplbmRvYmoKNyAw IG9iago8PC9CYXNlRm9udC9IZWx2ZXRpY2EvVHlwZS9Gb250Ci9FbmNvZGluZyA3MyAwIFIv U3VidHlwZS9UeXBlMT4+CmVuZG9iago3MyAwIG9iago8PC9UeXBlL0VuY29kaW5nL0RpZmZl cmVuY2VzWwoxNDkvYnVsbGV0L2VuZGFzaF0+PgplbmRvYmoKNDYgMCBvYmoKPDwvQmFzZUZv bnQvQ291cmllci1Cb2xkL1R5cGUvRm9udAovU3VidHlwZS9UeXBlMT4+CmVuZG9iagoyIDAg b2JqCjw8L1Byb2R1Y2VyKEFGUEwgR2hvc3RzY3JpcHQgOC4xNCkKL0NyZWF0aW9uRGF0ZShE OjIwMDUwODE4MTQ1MTQ3KQovTW9kRGF0ZShEOjIwMDUwODE4MTQ1MTQ3KQovVGl0bGUoTWlj cm9zb2Z0IFBvd2VyUG9pbnQgLSBFMkUgdkIgcGF0aCBFeGFtcGxlcyAyMDA1LTA4LTE4LnBw dCkKL0NyZWF0b3IoUFNjcmlwdDUuZGxsIFZlcnNpb24gNS4yLjIpCi9BdXRob3IoXChSXFwz NTFtaSBEZXNwclxcMzUxc1wpKT4+ZW5kb2JqCnhyZWYKMCA3NAowMDAwMDAwMDAwIDY1NTM1 IGYgCjAwMDAwODI4NzQgMDAwMDAgbiAKMDAwMDA4NDAyMCAwMDAwMCBuIAowMDAwMDgyNjk5 IDAwMDAwIG4gCjAwMDAwODAzODIgMDAwMDAgbiAKMDAwMDAwMDAxNSAwMDAwMCBuIAowMDAw MDAwOTE0IDAwMDAwIG4gCjAwMDAwODM4MDUgMDAwMDAgbiAKMDAwMDA4MzY1MiAwMDAwMCBu IAowMDAwMDgyOTIyIDAwMDAwIG4gCjAwMDAwODA1MjQgMDAwMDAgbiAKMDAwMDAwMDkzMyAw MDAwMCBuIAowMDAwMDAyMDc4IDAwMDAwIG4gCjAwMDAwODM1ODIgMDAwMDAgbiAKMDAwMDA4 Mjk2MCAwMDAwMCBuIAowMDAwMDgwNjY5IDAwMDAwIG4gCjAwMDAwMDIwOTkgMDAwMDAgbiAK MDAwMDAwNDMwNSAwMDAwMCBuIAowMDAwMDgzMDAxIDAwMDAwIG4gCjAwMDAwODA4MTQgMDAw MDAgbiAKMDAwMDAwNDMyNiAwMDAwMCBuIAowMDAwMDA1NzYxIDAwMDAwIG4gCjAwMDAwODMw NDAgMDAwMDAgbiAKMDAwMDA4MDk1OSAwMDAwMCBuIAowMDAwMDA1NzgyIDAwMDAwIG4gCjAw MDAwMTI1MDMgMDAwMDAgbiAKMDAwMDA4MzA4MSAwMDAwMCBuIAowMDAwMDgxMTA0IDAwMDAw IG4gCjAwMDAwMTI1MjQgMDAwMDAgbiAKMDAwMDAxNDQ4MyAwMDAwMCBuIAowMDAwMDgzMTIy IDAwMDAwIG4gCjAwMDAwODEyNDkgMDAwMDAgbiAKMDAwMDAxNDUwNCAwMDAwMCBuIAowMDAw MDE1OTMzIDAwMDAwIG4gCjAwMDAwODMxNjMgMDAwMDAgbiAKMDAwMDA4MTM5NCAwMDAwMCBu IAowMDAwMDE1OTU0IDAwMDAwIG4gCjAwMDAwMTg2NDYgMDAwMDAgbiAKMDAwMDA4MzIwNCAw MDAwMCBuIAowMDAwMDgxNTM5IDAwMDAwIG4gCjAwMDAwMTg2NjcgMDAwMDAgbiAKMDAwMDAy MDc4MyAwMDAwMCBuIAowMDAwMDgzMjQ1IDAwMDAwIG4gCjAwMDAwODE2ODQgMDAwMDAgbiAK MDAwMDAyMDgwNCAwMDAwMCBuIAowMDAwMDIyOTYyIDAwMDAwIG4gCjAwMDAwODM5NTIgMDAw MDAgbiAKMDAwMDA4MzI4NiAwMDAwMCBuIAowMDAwMDgxODI5IDAwMDAwIG4gCjAwMDAwMjI5 ODMgMDAwMDAgbiAKMDAwMDAzMjM0MiAwMDAwMCBuIAowMDAwMDgzMzM2IDAwMDAwIG4gCjAw MDAwODE5NzQgMDAwMDAgbiAKMDAwMDAzMjM2MyAwMDAwMCBuIAowMDAwMDQxNTY4IDAwMDAw IG4gCjAwMDAwODMzNzcgMDAwMDAgbiAKMDAwMDA4MjExOSAwMDAwMCBuIAowMDAwMDQxNTg5 IDAwMDAwIG4gCjAwMDAwNTEyNzIgMDAwMDAgbiAKMDAwMDA4MzQxOCAwMDAwMCBuIAowMDAw MDgyMjY0IDAwMDAwIG4gCjAwMDAwNTEyOTMgMDAwMDAgbiAKMDAwMDA2MTA5OSAwMDAwMCBu IAowMDAwMDgzNDU5IDAwMDAwIG4gCjAwMDAwODI0MDkgMDAwMDAgbiAKMDAwMDA2MTEyMCAw MDAwMCBuIAowMDAwMDcwNjUyIDAwMDAwIG4gCjAwMDAwODM1MDAgMDAwMDAgbiAKMDAwMDA4 MjU1NCAwMDAwMCBuIAowMDAwMDcwNjczIDAwMDAwIG4gCjAwMDAwODAzNjEgMDAwMDAgbiAK MDAwMDA4MzU0MSAwMDAwMCBuIAowMDAwMDgzNzMwIDAwMDAwIG4gCjAwMDAwODM4ODUgMDAw MDAgbiAKdHJhaWxlcgo8PCAvU2l6ZSA3NCAvUm9vdCAxIDAgUiAvSW5mbyAyIDAgUgovSUQg WyiNV1F5nY84hZBrelJg/Bb0KSiNV1F5nY84hZBrelJg/Bb0KV0KPj4Kc3RhcnR4cmVmCjg0 MjY4CiUlRU9GCg== --------------090505050604000301050600-- From owner-v6ops@ops.ietf.org Thu Aug 18 12:34:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5nLj-0004JN-4u for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 12:34: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 MAA16461 for ; Thu, 18 Aug 2005 12:34:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5nId-00020y-Sx for v6ops-data@psg.com; Thu, 18 Aug 2005 16:31:27 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5nIY-00020f-5p for v6ops@ops.ietf.org; Thu, 18 Aug 2005 16:31:22 +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 1E5nIV-0004rN-1a; Thu, 18 Aug 2005 17:31:19 +0100 Message-ID: <4304B825.5000604@dial.pipex.com> Date: Thu, 18 Aug 2005 17:32:37 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Klein CC: v6ops@ops.ietf.org Subject: Re: Madated adoption? References: <2A89D6B6FFB96046BE70561B718593F63EDB19@va03ex01.si.siroot.com> <01ac01c5a3f1$88420100$0401a8c0@mtc.ki.se> In-Reply-To: <01ac01c5a3f1$88420100$0401a8c0@mtc.ki.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Just a word of warning on this: The new CIO of DISA Linton Wells has done a bit of rowing back on the really hard commitment to 2008 originally touted by John Osterholtz. They are still trying for 2008 but may not make it.. see for example: http://www.gcn.com/vol1_no1/defense-technology/35901-1.html Regards, Elwyn Eric Klein wrote: >Thanks Jeff, So far that makes it: > >US - DoD by FY 2008 >US - The rest of Government agencies by June 2008 >China - for Olympics by June 2008 > >and I will keep looking > >----- Original Message ----- >From: "Dunn, Jeffrey" >To: "Eric Klein" ; >Cc: "Dunn, Jeffrey" >Sent: Thursday, August 18, 2005 2:48 PM >Subject: RE: Madated adoption? > > >Eric, > >The U.S. DoD has also "mandated" adoption of IPv6. Please see the link >listed below: > >http://ipv6.disa.mil/docs/stenbit-ipv6-guidance-20030929.pdf > >Similarly, U.S. Whitehouse Office of Management and Budget has just >recently issued guidance on the adoption of IPv6. Please see the link >listed below: > >http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf > >Best Regards, >Jeffrey Dunn >Systems Test Manager >-----Original Message----- >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On >Behalf Of Eric Klein >Sent: Thursday, August 18, 2005 5:26 AM >To: v6ops@ops.ietf.org >Subject: Re: Madated adoption? > >Thanks Jordi this is very helpful. > >Eric >----- Original Message ----- >From: "JORDI PALET MARTINEZ" >To: >Sent: Thursday, August 18, 2005 12:10 PM >Subject: Re: Madated adoption? > > > > >>Hi, >> >>I try to keep all this info at http://www.ipv6tf.org, but not sure if >> >> >this > > >>is as much updated as I wish. >> >>My feeling is that only Japan has a clear "mandate" as a government >> >> >decision > > >>right now. >> >>But there are several related documents for other governmental bodies >> >> >such > > >>as: >>http://www.ipv6tf.org/meet/policy_recommendations.php >> >>If anyone can point out some other documents, I will link them also, >> >> >to >have > > >>a more complete picture. For example, I just realized that I'm missing >> >> >links > > >>to Japanese, Korean and Chinese documents, at least. I recall there is >> >> >also > > >>something from German MoD and Switzerland. >> >>Also it could be interesting: >>http://www.ipv6tf.org/news/newsroom.php?id=684 >> >>One of the conclusions is that most of the countries, at least in >> >> >Europe, > > >>have concrete government support, but not concrete "mandated" dates, >> >> >most >of > > >>the time are suggestions and not widely publicized. Anyway, those >>suggestions are already achieving results. In Spain most of the public >>tenders ask for IPv6 support since already 3-4 years ago, but is not >> >> >being > > >>enabled by default by now in most cases (I believe this will change in >> >> >the > > >>next few months). This usually means that the ISPs and vendors have to >>support IPv6 and clearly, is not smart to have different product lines >> >> >(or > > >>networks) for government business and other customers. For example, >> >> >the > > >>recommendation in 2001 from the Ministry of Public Administration >> >> >(MAP) >was > > >>to purchase everything with IPv6 support on it, so it can be enabled >> >> >when > > >>required, also all the acquisitions done by the main Internet and >>Information Society entity, as well as all the ministries that I'm >> >> >aware >of, > > >>are following this. >> >>I'm not sure a mandate is required, let's say as a "country" decision. >> >> >I > > >>mean, is enough if the government mandates its usage in their own >>acquisitions. As said, this is good catalyst for the vendors decide if >> >> >they > > >>want to have two product lines, with and without IPv6 and >> >> >interoperability > > >>problems between both, or whatever. >> >>Regards, >>Jordi >> >> >> >> >> >> >>>De: Eric Klein >>>Responder a: >>>Fecha: Thu, 18 Aug 2005 11:27:12 +0300 >>>Para: "v6ops@ops.ietf.org" >>>Asunto: Madated adoption? >>> >>>Based on my memory (and comments about I-D >>>ACTION:draft-baker-v6ops-end2end-00.txt ) >>> >>> >>>Tim Chown seemed surprised that I had heard that there was a >>> >>> >mandated > > >>>adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure >>> >>> >about > > >>>years for either). >>> >>>Now this WG had a conversation thread a little over a year ago where >>> >>> >these > > >>>came up. >>> >>>I was wondering if anyone knew if their (or other) countries had >>> >>> >announced > > >>>compliance dates for the full IPv6 conversions. >>> >>>The truth is that this has dual interest to me, as we as a WG should >>> >>> >know > > >>>what the world (or at least individual nations) are doing or saying >>> >>> >about > > >>>IPv6. But this is also related to a thesis that I am working on and >>> >>> >I am > > >>>interested to see what is being done towards actual adoption at the >>> >>> >national > > >>>levels. >>> >>>Eric >>> >>> >>> >>> >> >> >>************************************ >>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 Thu Aug 18 13:22:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5o64-0000lR-Gp for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 13:22:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18778 for ; Thu, 18 Aug 2005 13:22:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5o3t-0009Mn-IP for v6ops-data@psg.com; Thu, 18 Aug 2005 17:20:17 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5o3q-0009MW-Du for v6ops@ops.ietf.org; Thu, 18 Aug 2005 17:20:14 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id KAA28415; Thu, 18 Aug 2005 10:19:53 -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 j7IHK6v09009; Thu, 18 Aug 2005 12:20:06 -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.211); Thu, 18 Aug 2005 10:20:02 -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: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Date: Thu, 18 Aug 2005 10:20:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FCA@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Thread-Index: AcWjpSF8Xz6sxHElSGaUawQXCci6kAAYaSMg From: "Templin, Fred L" To: "Mark Smith" Cc: X-OriginalArrivalTime: 18 Aug 2005 17:20:02.0875 (UTC) FILETIME=[11BE50B0:01C5A419] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Mark, Thanks for the comments. The paragraph you cited needs to be read in conjunction with the one that immediately follows, however, i.e.: Since LinkMTU values larger than 1280 bytes may result in [ICMPv6] "packet too big" messages due to temporary segmentation restrictions (see: section 3.3), ULPs SHOULD employ a probing strategy that begins with a smaller payload size (on the order of 1KB) and probes upward [PMTUD]. (Note that this may not be possible for some ULPs.) This says that ULPs (like TCP) can do their own probing if they want to discover larger MTUs beyond what the initial tunnel interface MTU allows independent of the tunnel segment size probing. BTW, this is true also for the case of no tunnel interfaces in the path, e.g., a TCP could start out on a path with a small MTU and re-routed to an all-GIGE path. The text of these two paragraphs is intentionally worded to allow implementations some freedom in how they configure the initial tunnel MTU, e.g. an implementation might wish to ratchet up the initial MTU by sending a series of IPv6 ND messages using different values for SEGSIZE to determine a larger IPv4 segment size for the path before setting the tunnel MTU. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Wednesday, August 17, 2005 8:30 PM > To: Templin, Fred L > Cc: v6ops@ops.ietf.org > Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" >=20 > Hi Fred, >=20 > On Wed, 17 Aug 2005 14:55:14 -0700 > "Templin, Fred L" wrote: >=20 > > A new draft of possible interest to v6ops is available > > that anticipates MTU-related performance issues for > > tunnels and proposes a solution. Document location > > and abstract appear below. Comments? > >=20 >=20 > I've had a quick read through. >=20 > I'm a bit confused by this text : >=20 > " Implementations MUST configure a minimum per-tunnel=20 > interface LinkMTU > of 1280 bytes and SHOULD provide a configuration knob to set larger > values. A maximum LinkMTU of 9180 bytes (i.e., the same as defined > in [RFC1626]) is RECOMMENDED for normal use cases, since=20 > it is large > enough to encode 8KB network filesystem blocks and take=20 > advantage of > Gigabit Ethernet Jumbo Frames, yet not so large as to diminsh the > effectiveness of 32-bit link layer CRCs [GIGE]. =20 > Implementations MAY > set even larger LinkMTU values, but are advised that this=20 > may lead to > unacceptable levels of undetected errors unless all=20 > physical segments > in the path can provide assured error-free deliverey for large > packets." >=20 > I read it as saying that the initial tunnel MTU, by default, should > always be 1280 bytes. However, I think the first part of the next > sentence, >=20 > "A maximum LinkMTU of 9180 bytes (i.e., the same as defined > in [RFC1626]) is RECOMMENDED for normal use cases" >=20 > could possibly be taken to be a statement that for "normal use cases" > (which is commonly the "default"), the initial tunnel MTU=20 > should be 9180 > bytes. >=20 > The reason that I ask is that if I understand the tunnel MTU probing > mechanism in this ID, it relies on the upper layer protocol generating > TPDUs that are larger than the current tunnel MTU value. If the upper > layer protocol was TCP, it would set it's MSS option to be the current > tunnel MTU minus the IPv6 header size. If the initial tunnel=20 > MTU is 1280 > bytes, as per the first sentence in the above text, and the TCP end > points were on the same nodes as the tunnel end points (for=20 > example), the > MSS value for each end point would be set to 1280 minus 40=20 > bytes for the > IPv6 header or 1240 bytes. >=20 > From that point onwards, the TCP end points would never send a segment > larger than the MSS, and therefore never generate a IPv6 packet larger > than 1280 bytes or a IPv4 packet larger than 1300 bytes. If the IPv4 > path MTU between the two tunnel end points was 1500 bytes,=20 > which I think > is probably the case for most of the Internet, I don't think the probe > mechanism in this ID would ever discover that and then be able to > utilise it. TCP or other transport layer protocols would never > indirectly attempt to push the tunnel MTU above what the local tunnel > interface MTU is set to, and if that is initially 1280 bytes, then I > think the tunnel MTU would never increase beyond that value. >=20 > Rather than the initial MTU being set to 1280 bytes, maybe it=20 > should be > set to a value that is derived from the common IPv4 path MTUs in the > Internet e.g 1500 - 20 bytes or 1480 bytes. This would allow today's > common IPv4 path MTU to be taken advantage of by this ID, yet=20 > avoid the > amount of fragmentation an initial tunnel MTU of 9180 bytes=20 > would cause > and the associated time it would take for PMTUD to resolve down to > today's common IPv4 path MTU. PMTUD and the mechanisms in this draft > would cope with IPv4 paths between tunnel end points that=20 > have a smaller > MTU than the assumed, common, 1500 bytes. >=20 > If this common IPv4 path MTU figure changes in the future,=20 > then the RFC > could be updated by a later RFC with an increased initial tunnel MTU > recommendation. >=20 > HTH, > Mark. >=20 From owner-v6ops@ops.ietf.org Thu Aug 18 14:10:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5oqC-0004XO-Ei for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 14:10: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 OAA20958 for ; Thu, 18 Aug 2005 14:10:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5ond-000Erk-Es for v6ops-data@psg.com; Thu, 18 Aug 2005 18:07:33 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5onZ-000ErA-CY for v6ops@ops.ietf.org; Thu, 18 Aug 2005 18:07:29 +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 1E5onV-0003Ur-RR; Thu, 18 Aug 2005 19:07:26 +0100 Message-ID: <4304CEAC.5050800@dial.pipex.com> Date: Thu, 18 Aug 2005 19:08:44 +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: Fred Baker Subject: Review: draft-ietf-v6ops-nap-01.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fred Baker orinally asked me to comment on this draft in the light of my editorship of the NAT-PT to experimental recommendation. It has turned into a bit of a marathon...I think there is quite a lot of improvements to be made before it moves on, but I would support its going forward. The editorial pieces are mostly language improvements but there are IMO significant substantive issues to sort out. In terms of NAT-PT, I think it would be appropriate to add a section saying why it would be dangerous to constrain future developments of IPv6 networks by eliminating NATs and then adding back the general form of NAT-PT just to do transitions. If it is agreed that this is wanted, I am prepared to draft a suitable piece of text. BTW I did read (lightly) the Appendices but they seem pretty good so there are no comments on them (at present). The comments contain a suggestion that draft-chown-port-scanning-implications should be published as an RFC - it is referenced both here (in what I consider to be a Normative way) and it is relevant to the security overview also. Does anybody else support this? Substantive: s2.2: para 2: should mention need for improved trust in end systems which are not physically secured. s2.3: para 2: last sentence: surely the NAT state database log would amount to exactly the time-correlated list which the admin instance is assumed to have hold of? Clearly if you don't have a sensible log there is a big problem, but I think the 2nd para needs a rethink. Also I am not sure why port mapping makes things more difficult - the mappings may be *finer* grained allowing *better* tracking of what an end host is up to than in an address only NAT. In either case you need to know the outside destination (address and port) when the source mapping is created in order to have an idea of what the end host is doing. s2.5: Maybe the downside of RFC 1918 from this point of view of site merging could be mentioned as well with pointers to s2.7. s2.7: The high probability of address overlaps with RFC1918 addressing needs to be explicitly mentioned (as a new second sentence in para 3). The reason why there are overlapping addresses (in the final words of the para) is not made clear. s2.4 and s3.1: 'device profiling' as used as a shorthand in s3.1 is effectively defined in s2.4 - would be a good idea to say that this term will be used for the process set out in para 2 of s2.4. s3.2: para 1: last sentence: 'as that would have a serious negative impact on global routing': I think this is completely wrong unless we are trying to say something other than what is retailed 4 paras further on. ULAs are specifically designed to be essentially benign should routes to them leak on account of being a.s. unique. s3.4: para 2: I think the term 'aggregation device' is maybe misleading. The actual function is 'indirection device'. A reference to s4.4 for more details would help clarify this rather bald statement (or maybe the 'how it is done' should be here?) s4.1: RFC3484 currently doesn't know about ULAs. There should therefore be a comment about requiring the policy table to be correctly set up so that true globals are distinguished from ULAs and will be used for the source address in preference when the destination is not a (local) ULA. s4.2: (item 1): Need to point out the risk of confusing DDoS detection systems if the address changes too quickly! (xref to draft-ietf-v6ops-security-overview-02.txt). s4.2: Item 3: I am not sure that this doesn't promote [17] to a Normative reference.. either way having recommendations that an administrator should take into consideration in an I-D is not very satisfactory. Some of this was documented in an appendix of draft-ietf-v6ops-security-overview-02.txt (in an abbreviated form)... if we are going to promote the ideas in this draft [17] it should either go to RFC or the ideas should be fully integrated into either the NAP draft or the security overview. I would support publishing draft-chown-port-scanning-implications as an RFC. s4.2: para after Item 3: last sentence: Which thing is opposite to? I think this is not a good statement. What we are trying to say (I think) is: IPv6 security best practices will avoid this kind of illusory security but can only do this if correctly configured firewalls and IDS systems are used at the perimeter where some IPv4 networks have relied on NATs. s4.2: Item 3: Add a new next to last sentence: This protection will also be nullified if IIDs are configured in a group near the start of the IID space. s4.2: The section on firewall rules needs at least to be turned round so that the point of it is clear from the outset... Indeed I am not clear whether there is any real need for the detailed stuff on the plain vanilla setup - taking into account the need for some ICMPv6 traffic to be allowed, more detail might be required to get a sensible answer. I suspect that this document is not the place for that sort of discussion I think it could be replaced with something like: To implement simple security for IPv6 in, for example, a DSL connected home network, the DSL broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration which provides a minimum set of connectivity for users in the home network (e.g., just to external HTTP servers) with incoming traffic limited to return traffic resulting from outgoing packets (sometimes known as reflective session state) with an easy interface which allows users to create additional 'pinholes' for specific purposes. Administrators and the designers of configuration interfaces for simple IPv6 Firewalls need to provide a means of documenting the security caveats that arise from a given set configuration rules so that users (who are normally oblivious to such things) can be made aware of the risks. As rules are improved iteratively, the goal will be to make use of the IPv6 Internet more secure for oblivious users. s4.2: last para: The material from 'This mostly starts..' is essentially covered in draft-chown-port-scanning-implications. If [17] is referenced (and even more so if it becomes an RFC), this material is superfluous. s4.4: The final statement about encryption and overhead is slightly disingenuous. It is true that the data tunnels can be run unencrypted as they are wholly in the local network but the Binding Updates generated by the masked nodes to setup the COA are required to use an SA. This has a limited effect on performance but requires some configuration. Also it should be noted that the pseudo-mobile nodes need to have route optimization turned off for all correspondents, and firewalls need to ensure that the pseudo-mobile nodes cannot move outside the local networks and that the indirection device doesn't accept inappropriate (external) mobile node registrations. s4.7: last para: Given the recent work on renumbering, the words about 'zero-touch external mechanism' may be seen as somewhat optimistic!! s5.1: we would hope that if an enterprise has multiple /48's from an ISP they are generally adjacent (i.e. /47's, /46s etc) (but the nibble alignment of the reverse DNS may have some impact). s6.4: Does this need to be updated in the light of the recent reports on renumbering? s6.5: Site Multihoming: I am (personally) not convinced that what is going on in shim6 coincides with the words in this section. It ought to be updated in the light of developments. Editorial: Global: consistent capitaliuzation (or otherwise) of Home Agent. Global: RFC3177 should be in the references. s1: para 3: I would split up the last sentence which is a bit long and mention the retention of any-to-any connectivity, thus: s/...and privacy and will... translation./...and privacy. NAP will achieve these security goals without address transaltion whilst maintaining any-to-any connectivity./ s2.2: para 3: last sentence: s/are/is/, s/actually false/actually an illusion/ s2.3: para 1: s/of the NAT devices state/from the NAT device's state/ s2.4: para 1: s/reflected/represented/ s2.7: last para: s/This solution/The addition of an extra NAT as a solution/ (Not clear whether 'This' refers to extra NAT or long term solution.) s2.7: last para: 'the merged address space' is misleading : suggest s/merged address space/overlapping address speaces in the merged networks/ s3.1: s/by contacted web sites, so IPv6/by web sites that are accessed from the device: IPv6 / s3.3: last para: s/delegating router/delegating router (incorporating a DHCPv6 server)/, s/across an administrative/possibly across an administrative/ s3.4: para 2: Replace first sentence with: 'The random assignment is intended to mislead the outside world about the structure of the local network.' s3.4: para 2: s/there is a correlation/needs to maintain a correlation/ s3.4: para 2: s/like a/such as a/ s3.4: para 3: s/unpredictable/amorphous/, s/or from mapping/and from mapping of/ s3.4: para 3: s/are reachable on/are allocated to devices on/ s3.4: para 3: s/belonging to the same subnet next to each other/belonging to devices adjacent to each other on the same subnet/ s4.2: para 1: s/similar as for an/similar to that of an/ s4.2: para 1: s/Internet, and firewall and IDS systems are/Internet. The use of firewall and Intrusion Detection Systems (IDS) is/ s4.2: para 1: s/but has/but with/ s4.2: para 1: s/end to end/end-to-end/ s4.2: Item 3: s/amount/number/ s4.2: Item 3: s/This goes from the assumption that the attacker has no/This protection is nullified if the attacker has/ s4.2: para after Item 3: s/pose/offer/ (or provide). s4.2: para after Item 3: s/best- practices/best practices/ s4.2: para after example firewall rules: s/create similar protection and security holes the typical IPv4 NAT device will offer/provide (non-)protection and create security holes similar to those offered to a network using a typical IPv4 NAT device/ s4.2: para next but one after firewall rules: s/What one does when topology probing is to get an idea of the available hosts/The intention of topology probing is to identify a selection of the available hosts/ s4.4: para 2: after 'As discussed above' insert '(see Section 3.1)' s4.4: para 3: s/consolidated on/indirected via/ s4.4: para 3: s/topololgy masked/each topology masked/ s4.4: para 3: Expand acronym COA s4.4: para 3: s/rack mounted/static/ s4.5: last para: s?/etc?, etc.? s4.5: last sentence : s?In v6, it's all /64.?For IPv6 all subnets have /64 prefixes.? s4.6: last para: s/which will lead to the IPv4 practice/which will require the adoption of the IPv4 workaround/ s4.6: s/the IPv4 constricting scenarios of multiple devices sharing a/the constriction of IPv4 scenarios where multiple devies are forced to share a/ s5: Replace first three sentences with: In presenting these case studies we have chosen to consider categories of network divided first according to their function either as carrier/ISP networks or end user (such as enterprise) networks with the latter category broken down according to the number of connected end hosts. s5: bullet points: s/connection/connected end hosts/ s5.1: s/addressing independence/addressing independence when using IPv4/ s5.1: last para: s/is only affecting/will only affect/ s5.2: para 1: s?is too long?is too long (very often just a /32 just giving a single address)? s5.4: s/chapter 5.1/Section 5.1/ s5.4: s/intra- connection/intraconnection/ s5.4:s/prevent from/prevent them from/ s6.2: para 2: The information about how to do topology masking with Mobile IPv6 would be best concentrated in one place. Currently it is spread across three sections. s6.2: para 2: s/rack-mounted/static/ s6.4: s/well solved/completely solved/ From owner-v6ops@ops.ietf.org Thu Aug 18 15:35:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5qAL-0008ON-EO for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 15:35:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26431 for ; Thu, 18 Aug 2005 15:35:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5q7d-000N5F-Hb for v6ops-data@psg.com; Thu, 18 Aug 2005 19:32:17 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5q7b-000N4v-LF for v6ops@ops.ietf.org; Thu, 18 Aug 2005 19:32:15 +0000 Received: (qmail 6180 invoked by uid 417); 18 Aug 2005 19:32:14 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 19:32:14 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 13:32:13 -0600 Message-ID: <008b01c5a42b$86a5f7e0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <4304CEAC.5050800@dial.pipex.com> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Thu, 18 Aug 2005 22:31:59 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Elwyn Davies wrote > In terms of NAT-PT, I think it would be appropriate to add a section > saying why it would be dangerous to constrain future developments of > IPv6 networks by eliminating NATs and then adding back the general form > of NAT-PT just to do transitions. If it is agreed that this is wanted, > I am prepared to draft a suitable piece of text. > I am not exactly sure, but it sounds like what you are proposing is exactly opposite of the goal of this draft. Effectively this draft is saying that NATs should not exist in an IPv6 network and should not be supported as the features and functions that NAT used to provide are now inherent in the IPv6 architecture. In which case (IMHO) NAT-PT is strictly for transition from IPv4 only to IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no need for NAT or NAT-PT. Eric From owner-v6ops@ops.ietf.org Thu Aug 18 16:29:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5r19-00005t-Ls for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 16:29: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 QAA01911 for ; Thu, 18 Aug 2005 16:29:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5qzG-0001wx-T0 for v6ops-data@psg.com; Thu, 18 Aug 2005 20:27:42 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E5qzC-0001wZ-Mw for v6ops@ops.ietf.org; Thu, 18 Aug 2005 20:27:39 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E5qz9-0007wi-Py; Thu, 18 Aug 2005 21:27:35 +0100 Message-ID: <4304EF86.2090602@dial.pipex.com> Date: Thu, 18 Aug 2005 21:28:54 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Klein CC: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt References: <4304CEAC.5050800@dial.pipex.com> <008b01c5a42b$86a5f7e0$0401a8c0@mtc.ki.se> In-Reply-To: <008b01c5a42b$86a5f7e0$0401a8c0@mtc.ki.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Eric Klein wrote: >Elwyn Davies wrote > > >>In terms of NAT-PT, I think it would be appropriate to add a section >>saying why it would be dangerous to constrain future developments of >>IPv6 networks by eliminating NATs and then adding back the general form >>of NAT-PT just to do transitions. If it is agreed that this is wanted, >>I am prepared to draft a suitable piece of text. >> >> > >I am not exactly sure, but it sounds like what you are proposing is exactly >opposite of the goal of this draft. Effectively this draft is saying that >NATs should not exist in an IPv6 network and should not be supported as the >features and functions that NAT used to provide are now inherent in the IPv6 >architecture. > >In which case (IMHO) NAT-PT is strictly for transition from IPv4 only to >IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no >need for NAT or NAT-PT. > >Eric > It's been a long day of reviewing... Read what I wrote by inserting brackets around (eliminating NATS and then adding back the general form of NAT-PT just to do transitions): In terms of NAT-PT, I think it would be appropriate to add a section saying why it would be dangerous to constrain future developments of IPv6 networks by (eliminating NATs and then adding back the general form of NAT-PT just to do transitions). If it is agreed that this is wanted, I am prepared to draft a suitable piece of text. What I thought I was saying is that we should avoid putting 1) any sort of NAT, and 2) any NAT-PT in its general form (the one that is being made experimental) into an IPv6 network There may be (almost certainly is) limited scope for a simplfied translator as a front end for legacy servers, but using NAT-PT as a way to transmit arbitrary protocols between a generic IPv6 network and a generic IPv4 network effectievly condemns IPv6 applications to living with the set of capabilities that IPv4 has. This is NOT a good idea. So I dont think I am trying to say anything other than the draft is a good thing and better if we avoid fully general NAT-PT as well. Regards, Elwyn From owner-v6ops@ops.ietf.org Thu Aug 18 16:55:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5rPo-00074f-SY for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 16:55:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02895 for ; Thu, 18 Aug 2005 16:55:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5rNH-0003vR-Cj for v6ops-data@psg.com; Thu, 18 Aug 2005 20:52:31 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E5rNG-0003v7-7t for v6ops@ops.ietf.org; Thu, 18 Aug 2005 20:52:30 +0000 Received: (qmail 20782 invoked by uid 417); 18 Aug 2005 20:52:28 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 18 Aug 2005 20:52:28 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Thu, 18 Aug 2005 14:52:27 -0600 Message-ID: <00a701c5a436$baff2600$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <4304CEAC.5050800@dial.pipex.com> <008b01c5a42b$86a5f7e0$0401a8c0@mtc.ki.se> <4304EF86.2090602@dial.pipex.com> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Thu, 18 Aug 2005 23:52:17 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Elwyn Davies wrote > > > > > >>In terms of NAT-PT, I think it would be appropriate to add a section > >>saying why it would be dangerous to constrain future developments of > >>IPv6 networks by eliminating NATs and then adding back the general form > >>of NAT-PT just to do transitions. If it is agreed that this is wanted, > >>I am prepared to draft a suitable piece of text. > >> > >> > > > >I am not exactly sure, but it sounds like what you are proposing is exactly > >opposite of the goal of this draft. Effectively this draft is saying that > >NATs should not exist in an IPv6 network and should not be supported as the > >features and functions that NAT used to provide are now inherent in the IPv6 > >architecture. > > > >In which case (IMHO) NAT-PT is strictly for transition from IPv4 only to > >IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no > >need for NAT or NAT-PT. > > > >Eric > > > It's been a long day of reviewing... > > Read what I wrote by inserting brackets around (eliminating NATS and > then adding back the general form of NAT-PT just to do transitions): > > In terms of NAT-PT, I think it would be appropriate to add a section > saying why it would be dangerous to constrain future developments of > IPv6 networks by (eliminating NATs and then adding back the general form > of NAT-PT just to do transitions). If it is agreed that this is wanted, > I am prepared to draft a suitable piece of text. > > What I thought I was saying is that we should avoid putting > 1) any sort of NAT, and > 2) any NAT-PT in its general form (the one that is being made > experimental) > into an IPv6 network > > There may be (almost certainly is) limited scope for a simplfied > translator as a front end for legacy servers, but using NAT-PT as a way > to transmit arbitrary protocols between a generic IPv6 network and a > generic IPv4 network effectievly condemns IPv6 applications to living > with the set of capabilities that IPv4 has. This is NOT a good idea. So > I dont think I am trying to say anything other than the draft is a good > thing and better if we avoid fully general NAT-PT as well. Agreed, this sounds more like what I would be comfortable with adding. I will wait to see what the other co-authors have to say. Thanks for the other comments, they all looked very helpful. And yes it has been a long day of reviewing and writing. Eric From owner-v6ops@ops.ietf.org Thu Aug 18 22:44:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E5wrw-0001WQ-Qd for v6ops-archive@megatron.ietf.org; Thu, 18 Aug 2005 22:44:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23953 for ; Thu, 18 Aug 2005 22:44:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E5wp4-0005wB-UK for v6ops-data@psg.com; Fri, 19 Aug 2005 02:41:34 +0000 Received: from [61.144.161.54] (helo=huawei.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E5wp2-0005vm-2R for v6ops@ops.ietf.org; Fri, 19 Aug 2005 02:41:32 +0000 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILG001O67T1US@szxga02-in.huawei.com> for v6ops@ops.ietf.org; Fri, 19 Aug 2005 10:48:37 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILG005H37T030@szxga02-in.huawei.com> for v6ops@ops.ietf.org; Fri, 19 Aug 2005 10:48:36 +0800 (CST) Received: from c03731 ([10.110.100.86]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILG00L247Y4YI@szxml01-in.huawei.com>; Fri, 19 Aug 2005 10:51:41 +0800 (CST) Date: Fri, 19 Aug 2005 10:42:00 +0800 From: chenhongfei Subject: RE: Review: draft-ietf-v6ops-nap-01.txt In-reply-to: <00a701c5a436$baff2600$0401a8c0@mtc.ki.se> To: "'Eric Klein'" , v6ops@ops.ietf.org Message-id: <000e01c5a467$9afa7860$56646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT Hi all I apologized to submit question before finished review the draft. I'm doubt about this sentence in this mail " once the network moves to fully IPv6 there is no need for NAT or NAT-PT". One of client's reason to choose NAT is security. NAT could hide inner IP address. It is important for some company. There are request of transition IPv6 to IPv6 maybe. Does this request needed in fully IPv6? Best regards Hongfei Chen -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eric Klein Sent: Friday, August 19, 2005 4:52 AM To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Elwyn Davies wrote > > > > > >>In terms of NAT-PT, I think it would be appropriate to add a section > >>saying why it would be dangerous to constrain future developments of > >>IPv6 networks by eliminating NATs and then adding back the general form > >>of NAT-PT just to do transitions. If it is agreed that this is wanted, > >>I am prepared to draft a suitable piece of text. > >> > >> > > > >I am not exactly sure, but it sounds like what you are proposing is exactly > >opposite of the goal of this draft. Effectively this draft is saying that > >NATs should not exist in an IPv6 network and should not be supported as the > >features and functions that NAT used to provide are now inherent in the IPv6 > >architecture. > > > >In which case (IMHO) NAT-PT is strictly for transition from IPv4 only to > >IPv4 and IPv6 networks and once the network moves to fully IPv6 there is no > >need for NAT or NAT-PT. > > > >Eric > > > It's been a long day of reviewing... > > Read what I wrote by inserting brackets around (eliminating NATS and > then adding back the general form of NAT-PT just to do transitions): > > In terms of NAT-PT, I think it would be appropriate to add a section > saying why it would be dangerous to constrain future developments of > IPv6 networks by (eliminating NATs and then adding back the general form > of NAT-PT just to do transitions). If it is agreed that this is wanted, > I am prepared to draft a suitable piece of text. > > What I thought I was saying is that we should avoid putting > 1) any sort of NAT, and > 2) any NAT-PT in its general form (the one that is being made > experimental) > into an IPv6 network > > There may be (almost certainly is) limited scope for a simplfied > translator as a front end for legacy servers, but using NAT-PT as a way > to transmit arbitrary protocols between a generic IPv6 network and a > generic IPv4 network effectievly condemns IPv6 applications to living > with the set of capabilities that IPv4 has. This is NOT a good idea. So > I dont think I am trying to say anything other than the draft is a good > thing and better if we avoid fully general NAT-PT as well. Agreed, this sounds more like what I would be comfortable with adding. I will wait to see what the other co-authors have to say. Thanks for the other comments, they all looked very helpful. And yes it has been a long day of reviewing and writing. Eric From owner-v6ops@ops.ietf.org Fri Aug 19 03:09:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E610b-0007uk-E5 for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 03:09:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17457 for ; Fri, 19 Aug 2005 03:09:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E60xB-0000rM-Ku for v6ops-data@psg.com; Fri, 19 Aug 2005 07:06:13 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.50 (FreeBSD)) id 1E60xA-0000r8-PA for v6ops@ops.ietf.org; Fri, 19 Aug 2005 07:06:13 +0000 Received: (qmail 17485 invoked by uid 417); 19 Aug 2005 07:06:11 -0000 Received: from shunt-smtp-out-0 (HELO softhome.net) (172.16.3.12) by shunt-smtp-out-0 with SMTP; 19 Aug 2005 07:06:11 -0000 Received: from mehr ([132.70.221.61]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 19 Aug 2005 01:06:10 -0600 Message-ID: <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> From: "Eric Klein" To: v6ops@ops.ietf.org References: <000e01c5a467$9afa7860$56646e0a@china.huawei.com> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Fri, 19 Aug 2005 10:05:38 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hongfei Chen Wrote > > I'm doubt about this sentence in this mail " once the network moves to > fully IPv6 there is no need for NAT or NAT-PT". One of client's reason > to choose NAT is security. NAT could hide inner IP address. It is > important for some company. There are request of transition IPv6 to IPv6 > maybe. Does this request needed in fully IPv6? > Part of what this draft was written to explain is that the concept of NAT as a security tool was very limited, and one that is better served by firewalls. The second concept of topology hiding (often confused with security) is one of the inherent features IPv6 by the use of Site-Local addresses. NAT was intended as a patch that would allow a company to have more IP addresses available than they could register (either from a price or scarcity consideration). One of the biggest problems with NAT in the current and future communications world is the high probability that when networks merge (companies combine or interconnect internal networks) then the NAT address pools will overlap. Making the process twice as hard in renumbering. Where in IPv6 both networks would have unique numbers and would be able to be combined without duplicate. I hope this clears it up for you Eric From owner-v6ops@ops.ietf.org Fri Aug 19 03:18:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E618a-0001aE-TL for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 03:18: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 DAA17682 for ; Fri, 19 Aug 2005 03:17:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6176-0001oR-OP for v6ops-data@psg.com; Fri, 19 Aug 2005 07:16:28 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6175-0001o9-Rc for v6ops@ops.ietf.org; Fri, 19 Aug 2005 07:16:28 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7J7GQBr023633 for ; Fri, 19 Aug 2005 08:16:26 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id IAA23487 for ; Fri, 19 Aug 2005 08:16:11 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7J7GBQ30545 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 08:16:11 +0100 Date: Fri, 19 Aug 2005 08:16:11 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-ID: <20050819071611.GB30371@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Aug 19, 2005 at 10:05:38AM +0300, Eric Klein wrote: > > Part of what this draft was written to explain is that the concept of NAT as > a security tool was very limited, and one that is better served by > firewalls. The second concept of topology hiding (often confused with > security) is one of the inherent features IPv6 by the use of Site-Local > addresses. I don't think 'site locals' (ULAs) hide topology, since ULA subnetting will invariably mirror global subnetting. One of the things that worries me about this draft is the suggestion to use host based routing for topology hiding, or indeed permanent use of MIPv6, as neither seems particularly attractive just to serve that purpose. -- Tim/::1 From owner-v6ops@ops.ietf.org Fri Aug 19 04:02:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E61pt-0004HJ-07 for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 04:02:45 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19318 for ; Fri, 19 Aug 2005 04:02:42 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E61nv-0005Vv-UW for v6ops-data@psg.com; Fri, 19 Aug 2005 08:00:43 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E61ns-0005VK-4d for v6ops@ops.ietf.org; Fri, 19 Aug 2005 08:00:40 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7J80dBr024555 for ; Fri, 19 Aug 2005 09:00:39 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA25140 for ; Fri, 19 Aug 2005 09:00:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7J80G531645 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 09:00:16 +0100 Date: Fri, 19 Aug 2005 09:00:16 +0100 From: Tim Chown To: "'v6ops@ops.ietf.org '" Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-ID: <20050819080016.GG30371@login.ecs.soton.ac.uk> Mail-Followup-To: "'v6ops@ops.ietf.org '" References: <4304CEAC.5050800@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4304CEAC.5050800@dial.pipex.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Aug 18, 2005 at 07:08:44PM +0100, Elwyn Davies wrote: > > The comments contain a suggestion that > draft-chown-port-scanning-implications should be published as an RFC - > it is referenced both here (in what I consider to be a Normative way) > and it is relevant to the security overview also. Does anybody else > support this? For info, this can be found here: http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-implications-01.txt It's one of those 'kind of obvious' texts, but has received good comments while it was live. I would be happy to revive it, or work with Gunter/Fred/Elwyn/whoever to merge it into the NAP text itself. There are pros and cons either way. Tim From owner-v6ops@ops.ietf.org Fri Aug 19 04:49:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E62Yx-0007KP-9O for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 04:49:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20967 for ; Fri, 19 Aug 2005 04:49:16 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E62Vl-0009Np-LY for v6ops-data@psg.com; Fri, 19 Aug 2005 08:46:01 +0000 Received: from [61.144.161.53] (helo=huawei.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E62Vj-0009NU-4B for v6ops@ops.ietf.org; Fri, 19 Aug 2005 08:45:59 +0000 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILG00GR4OJSCM@szxga01-in.huawei.com> for v6ops@ops.ietf.org; Fri, 19 Aug 2005 16:50:17 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0ILG005G9OJSSA@szxga01-in.huawei.com> for v6ops@ops.ietf.org; Fri, 19 Aug 2005 16:50:16 +0800 (CST) Received: from c03731 ([10.110.100.86]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0ILG002BYOM34N@szxml02-in.huawei.com>; Fri, 19 Aug 2005 16:51:39 +0800 (CST) Date: Fri, 19 Aug 2005 16:45:21 +0800 From: chenhongfei Subject: RE: Review: draft-ietf-v6ops-nap-01.txt In-reply-to: <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> To: "'Eric Klein'" , v6ops@ops.ietf.org Message-id: <001001c5a49a$559da200$56646e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I understand and agree with draft. Thank you. The problem when networks merge is a big problem for NAT. A good network design should reduce the effect of this problem. I need finished review the draft at first :) Best regards Hongfei Chen -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eric Klein Sent: Friday, August 19, 2005 3:06 PM To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Hongfei Chen Wrote > > I'm doubt about this sentence in this mail " once the network moves to > fully IPv6 there is no need for NAT or NAT-PT". One of client's reason > to choose NAT is security. NAT could hide inner IP address. It is > important for some company. There are request of transition IPv6 to IPv6 > maybe. Does this request needed in fully IPv6? > Part of what this draft was written to explain is that the concept of NAT as a security tool was very limited, and one that is better served by firewalls. The second concept of topology hiding (often confused with security) is one of the inherent features IPv6 by the use of Site-Local addresses. NAT was intended as a patch that would allow a company to have more IP addresses available than they could register (either from a price or scarcity consideration). One of the biggest problems with NAT in the current and future communications world is the high probability that when networks merge (companies combine or interconnect internal networks) then the NAT address pools will overlap. Making the process twice as hard in renumbering. Where in IPv6 both networks would have unique numbers and would be able to be combined without duplicate. I hope this clears it up for you Eric From owner-v6ops@ops.ietf.org Fri Aug 19 05:17:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E630M-0005sL-Ta for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 05:17: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 FAA21793 for ; Fri, 19 Aug 2005 05:17:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E62yU-000CUA-FA for v6ops-data@psg.com; Fri, 19 Aug 2005 09:15:42 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E62yR-000CTm-NI for v6ops@ops.ietf.org; Fri, 19 Aug 2005 09:15:40 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7J9FaBr027439 for ; Fri, 19 Aug 2005 10:15:36 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA00563 for ; Fri, 19 Aug 2005 10:15:09 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7J9F9d01115 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 10:15:09 +0100 Date: Fri, 19 Aug 2005 10:15:09 +0100 From: Tim Chown To: "v6ops@ops.ietf.org" Subject: Re: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Message-ID: <20050819091509.GT30371@login.ecs.soton.ac.uk> Mail-Followup-To: "v6ops@ops.ietf.org" References: <456CB87D-36EE-4282-B390-5E73C9C5F66D@cisco.com> <4302E5A1.9090803@rd-iptech.com> <430484F8.20206@rd-iptech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <430484F8.20206@rd-iptech.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, TO_ADDRESS_EQ_REAL autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA21793 On Thu, Aug 18, 2005 at 02:54:16PM +0200, R=E9mi Despr=E9s wrote: >=20 > Please don't hesitate to ask for more clarifications. > I am aware they are needed, and it helps making progress. The stumbling block to me digging deeply into your work is the terminolog= y used. It's not using conventional language and terms. --=20 Tim/::1 From owner-v6ops@ops.ietf.org Fri Aug 19 05:53:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E63Ym-00066C-D2 for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 05:53: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 FAA23425 for ; Fri, 19 Aug 2005 05:53:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E63XT-000FRW-Bm for v6ops-data@psg.com; Fri, 19 Aug 2005 09:51:51 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E63XR-000FRA-To for v6ops@ops.ietf.org; Fri, 19 Aug 2005 09:51:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7J9pk728707; Fri, 19 Aug 2005 12:51:47 +0300 Date: Fri, 19 Aug 2005 12:51:46 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <200508170804.j7H84ELS079516@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508170804.j7H84ELS079516@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk First off (after writing the response below), let me clarify the list of v4-in-v6 tunnel functions: As it is, different people use "DSTM" to mean at least the following things: a) (manually configured) v4-in-v6 tunnels [RFC2473] b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel server(s) which can happen without user intervention, e.g., using one of the processes described in draft-palet-v6ops-tun-auto-disc-03.txt. This must include a way to auto-configure a v4 address [e.g., DHCPv4]. b.2) the automatic set-up of v4-in-v6 tunnels, so that between each host, an ad-hoc tunnel can be signalled and set up" [6to4-like traffic optimization] c) assignment of an address on top of v4-in-v6 tunnel(s), but deferred until the application wants to create v4 socket. [issues with dual-stack server apps, for example] d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when the host detects it no longer needs the address/connectivity e) plus a number of extensions for even more colorful setups (e.g., instead of just assigning an address, assign only certain _ports_ of an address). Personally, - I believe there is a need for a) [but that's already specified]; - I think there also is a need (now or in the future) for b.1). - b.2) does not seem to be a good way to go (if traffic optimization is needed, maybe you shouldn't be using tunneling in the first place or you should deploy more tunnel servers and make _them_ interconnected). - c) is something implementations may try to do on their own, but I would recommend against it, and the IETF shouldn't work on that - d) doesn't seem to be worth the effort and is probably difficult to get right -- and for addresses, DHCPv4 and other methods already exist; not sure we want/need to do more work on that. I have no problem having the enterprise analysis document include this kind of analysis, and describe the need for a) and b.1) -- and I think this is probably a good thing as it might lessen the confusion on the real requirements for v4-in-v6 tunnels -- but if we go further than that, we may have a problem.... More inline.. On Wed, 17 Aug 2005, Francis Dupont wrote: > DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the > enterprise transition or deployment of IPv6-dominant network links > is desired. DSTM is to being submitted as an IETF Experimental RFC. > > ==> as it is, DSTM is a way too overloaded a mechanism to be referred to > without more disclaimers or description. > > => the overload (if any) should be solved by the references... This is a working group document. I don't think we can just refer to a non-wg, ambiguous document and expect it to clear up the ambiguities and confusion. > As it is, different people use > "DSTM" to mean at least the following things: > > => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent Toutain's DTI. That may be, but many people since have used the term, and may have zero idea what the goals are or may have been. > a) v4-in-v6 tunnels > b) automatically set-up v4-in-v6 tunnels > > => this (b-a) is DTI Based on later messages, I think you misunderstood what I tried to refer to with b). What I meant was like, "b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel server can happen automatically, e.g., using one of the processes described in draft-palet-v6ops-tun-auto-disc-03.txt" But what I think you took it to mean was, "b.2) the automatic set-up of v4-in-v6 tunnels, so that between each host (and/or tunnel server), an ad-hoc tunnel can be signalled and set up" [6to4-like traffic optimization] Is this correct? I was certainly referring to b.1) only. > c) automatic set up of v4-in-v6 tunnels when the host > doesn't have v4 address and an app wants to create a v4 socket [...] > DTI is exactly the dynamic flavour and is needed in DSTM for scalable > Tunnel End-Points. > > b) can be achieved using a tunnel broker; > > => this is both true and false: how the state is managed can be orthogonal > to the tunnel interface itself. > BTW the point is critical for the interoperability. Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between each host or the like, a protocol interoperability that goes beyond the plain tunnel broker would be needed. But I wasn't implying that functionality (nor do I think it is needed). > c) does not require IETF interoperability (a local implementation choice > when/how to launch the v4-in-v6 activation). > > => I don't understand your comment: the idea (AIIH) is more than useful > when a global IPv4 address is required. > PS: AIIH is the by-need allocation of an IPv4 address. What I meant is that if you already have a) and b.1), i.e., an ability for the host to set up a tunnel without manual configuration with a tunnel server, all your implementation needs to do is add a hack which triggers this activation when the v4 socket call is being made. There is no difference between b.1) and c) wrt. bits on the wire, right? > d) could also be considered in > the same category (there are no bits in the wire or anything requiring > interoperability AFAICS on when the host removes the tunnel), though I'm > skeptical whether even providing that would be a good engineering choice. > > => d is a consequence of the possible allocation of global IPv4 addresses > and is managed exactly as DHCPv4 does. To compare with similar mechanisms, > IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/... But if we can already use exactly DHCPv4 on top of the tunnel, why do we need to do anything? If DHCPv4 supports address dynamicity, the only thing left is whether you need to signal the teardown of the tunnel... and that seems hardly sufficiently useful. > My point is that I'm having hard time figuring out: > 1) what the document means when it's recommending DSTM, and > > => the references As said, I don't think a wg doc like this can shrug off these kinds of issues by just referring to non-wg documents and letting them sort things out. Best would probably be summarizing the different requirements or non-requirements (a-d above) in this doc, removing the references altogether, and enhancing the dstm spec (or writing a separate draft describing the scenarios/requirements for v4-in-v6 tunneling) to try to remove any confusion. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 19 09:19:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E66mI-0002OM-AK for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 09:19:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02166 for ; Fri, 19 Aug 2005 09:19:19 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E66jF-000Awd-5Q for v6ops-data@psg.com; Fri, 19 Aug 2005 13:16:13 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E66jB-000AwM-Gy for v6ops@ops.ietf.org; Fri, 19 Aug 2005 13:16:10 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j7JDFv503852; Fri, 19 Aug 2005 15:15:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j7JDFvEV007151; Fri, 19 Aug 2005 15:15:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508191315.j7JDFvEV007151@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-reply-to: Your message of Fri, 19 Aug 2005 12:51:46 +0300. Date: Fri, 19 Aug 2005 15:15:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: First off (after writing the response below), let me clarify the list of v4-in-v6 tunnel functions: As it is, different people use "DSTM" to mean at least the following things: a) (manually configured) v4-in-v6 tunnels [RFC2473] b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel server(s) which can happen without user intervention, e.g., using one of the processes described in draft-palet-v6ops-tun-auto-disc-03.txt. => note this I-D was submitted years after DSTM and is not a complete solution (in fact, today it is not a solution at all :-). This must include a way to auto-configure a v4 address [e.g., DHCPv4]. => I believe you mean something providing the same service than DHCPv4, not DHCPv4 itself. b.2) the automatic set-up of v4-in-v6 tunnels, so that between each host, an ad-hoc tunnel can be signalled and set up" [6to4-like traffic optimization] => I believe you have "direct tunnels" in the b.2 idea? c) assignment of an address on top of v4-in-v6 tunnel(s), but deferred until the application wants to create v4 socket. [issues with dual-stack server apps, for example] => note that c) is needed if allocated IPv4 addresses are global. To come back to the DHCPv4 analogy, with DHCPv4 an address is needed when a node attaches to the network, with c) an address is need when (and only when) a node has to make an IPv4 communication. d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when the host detects it no longer needs the address/connectivity => as I've already explained, d) is a consequence of c). e) plus a number of extensions for even more colorful setups (e.g., instead of just assigning an address, assign only certain _ports_ of an address). Personally, - I believe there is a need for a) [but that's already specified]; - I think there also is a need (now or in the future) for b.1). - b.2) does not seem to be a good way to go (if traffic optimization is needed, maybe you shouldn't be using tunneling in the first place or you should deploy more tunnel servers and make _them_ interconnected). => I agree: traffic optimization is not the problem to solve. - c) is something implementations may try to do on their own, but I would recommend against it, and the IETF shouldn't work on that => c) is *not* an option when you have not one address per node, i.e., when b.1) is not usable. - d) doesn't seem to be worth the effort and is probably difficult to get right -- and for addresses, DHCPv4 and other methods already exist; not sure we want/need to do more work on that. => perhaps I have misunderstood d) but when the IPv4 address expires the tunnel must be torn down... I have no problem having the enterprise analysis document include this kind of analysis, and describe the need for a) and b.1) -- and I think this is probably a good thing as it might lessen the confusion on the real requirements for v4-in-v6 tunnels -- but if we go further than that, we may have a problem.... => we have already a problem with IPv4 global addresses: there are not enough! > => the overload (if any) should be solved by the references... This is a working group document. I don't think we can just refer to a non-wg, ambiguous document and expect it to clear up the ambiguities and confusion. => so your concerns are about the DSTM documents? > => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent > Toutain's DTI. That may be, but many people since have used the term, => the term is not (yet :-) a trade mark... and may have zero idea what the goals are or may have been. => this is a random remark which is not about the WG I-D. > a) v4-in-v6 tunnels > b) automatically set-up v4-in-v6 tunnels > > => this (b-a) is DTI Based on later messages, I think you misunderstood what I tried to refer to with b). => I refer to the b-1 tunnel mechanism only (not the way to setup them). Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between each host or the like, a protocol interoperability that goes beyond the plain tunnel broker would be needed. But I wasn't implying that functionality (nor do I think it is needed). => what I said is the setup mechanism is orthogonal to the tunnel mechanism and the only thing about it is just to have one (zero doesn't work, two or more don't interoperate). BTW to be clearer here I mean the setup of a tunnel between a node and a TEP. What I meant is that if you already have a) and b.1), i.e., an ability for the host to set up a tunnel without manual configuration with a tunnel server, all your implementation needs to do is add a hack which triggers this activation when the v4 socket call is being made. There is no difference between b.1) and c) wrt. bits on the wire, right? => the difference between b.1) and c) is the type of IPv4 addresses. If the IPv4 address can be statically allocated c) (and in fact b.1) too) is not required, if the IPv4 address is global and cannot be statically allocated (because the pool is too small), c) is required (and d) as a consequence of c) too). BTW you could say that a NAT removes the requirement but I don't think you'd like to use this argument. > d) could also be considered in > the same category (there are no bits in the wire or anything requiring > interoperability AFAICS on when the host removes the tunnel), though I'm > skeptical whether even providing that would be a good engineering choice. > > => d is a consequence of the possible allocation of global IPv4 addresses > and is managed exactly as DHCPv4 does. To compare with similar mechanisms, > IKEv2 CFG_REQUEST can allocate home IPv4 addresses with expire/renew/... But if we can already use exactly DHCPv4 on top of the tunnel, => we can't... why do we need to do anything? If DHCPv4 supports address dynamicity, the only thing left is whether you need to signal the teardown of the tunnel... and that seems hardly sufficiently useful. => you make the false assumption DHCPv4 itself can be run over the tunnel. > My point is that I'm having hard time figuring out: > 1) what the document means when it's recommending DSTM, and > > => the references As said, I don't think a wg doc like this can shrug off these kinds of issues by just referring to non-wg documents and letting them sort things out. Best would probably be summarizing the different requirements or non-requirements (a-d above) in this doc, removing the references altogether, and enhancing the dstm spec (or writing a separate draft describing the scenarios/requirements for v4-in-v6 tunneling) to try to remove any confusion. => so you ask for a scenario with global IPv4 addresses (c)) or for clear operational advantages for (c)). IPv6-dominant networks (section 6) are the reason to ask for at least a), the text ("must acquire...locate...") suggests at least b.1). It seems I have now a clear view of the "missing part" in the WG I-D... I propose this scenario: - an IPv4 site with 200 nodes using a /24 is connected to the Internet. - the site grows to 500 nodes, solutions are: * get more IPv4 addresses: I suppose it is not possible. * put a NAT: I suppose we don't want this! Note a NAT on addresses only should be enough. * switch to IPv6, get a /48, take advantages of IPv6 feature, etc, but what to do with partners (perhaps including the ISP :-) still using IPv4: lookup for the solution in the WG I-D? - I assume there is a reasonnable number of "simultaneous" nodes which need an IPv4 address from the /24 pool. This assumption is used for the NAT or the DSTM solution (I have real world figures to support this assumption). - the best solution is DSTM... Regards Francis.Dupont@enst-bretagne.fr PS (for authors): BTW the right spelling of IPsec is IPsec (cf RFC2401bis). From owner-v6ops@ops.ietf.org Fri Aug 19 11:04:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68QA-0004RR-MR for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 11:04:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08434 for ; Fri, 19 Aug 2005 11:04:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E68OC-000MUG-T1 for v6ops-data@psg.com; Fri, 19 Aug 2005 15:02:36 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E68OB-000MTl-U2 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 15:02:36 +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 1E68O7-0002Yu-Al; Fri, 19 Aug 2005 16:02:31 +0100 Message-ID: <4305F4D5.7020809@dial.pipex.com> Date: Fri, 19 Aug 2005 16:03:49 +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 Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> In-Reply-To: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Today is the last day of the wg last call for this document (assuming we actually count forwards ;-) ). I have not seen any comments during the last call, but my own scan of the document has revealed a few nits and I have added an improved example in section 4.3. The changes I am proposing are: Changes: 02 -> 03 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.2: last sentence s/and/ and/ s4.1: last sentence: s/in practice, not much used as a consequence/as a consequence, not much used in practice./ s4.3: added additional example of DHCP servers for guessable addresses - updated text is... Because the unmemorability of complete IPv6 addresses there is a temptation for administrators to use small integers as interface identifiers when manually configuring them, as might happen on point- to-point links or when provisioning complete addresses from a DHCPv6 server. Such allocations make it easy for an attacker to find active nodes that they can then port scan. s4.5:s/in might/it might/ I have a new version ready to go unless there are any last minute comments. Fred Baker wrote: > With this note, I am opening a working group last call on draft-ietf- > v6ops-security-overview-02.txt. This WGLC will close in two weeks, at > close of business 19 July. Please read the document and comment to > the list - either say that the document is ready, or say what issues > you may have with it. > > Thanks. > From owner-v6ops@ops.ietf.org Fri Aug 19 11:17:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E68cO-0007vP-Io for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 11:17: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 LAA09154 for ; Fri, 19 Aug 2005 11:17:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E68bv-000OHn-5V for v6ops-data@psg.com; Fri, 19 Aug 2005 15:16:47 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E68br-000OG0-56 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 15:16:43 +0000 Received: from blv-av-01.boeing.com ([192.42.227.216]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA00238; Fri, 19 Aug 2005 08:16:24 -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 j7JFGbs09928; Fri, 19 Aug 2005 08:16:37 -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.211); Fri, 19 Aug 2005 08:16:34 -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: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Date: Fri, 19 Aug 2005 08:16:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FD2@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Thread-Index: AcWkkNoXhpvTViqNTyuVjeqj8refRwAO2lww From: "Templin, Fred L" To: "Mark Smith" Cc: X-OriginalArrivalTime: 19 Aug 2005 15:16:34.0527 (UTC) FILETIME=[FC6FDEF0:01C5A4D0] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Mark, Understand your point about setting TCP MSS, but regardless of whether the tunnel occurs on the same node as one of the TCPs or somewhere along the path the key point is whether/not the implementation takes the SHOULD and configures the largest possible MTU during tunnel setup time. This might require some pre-probing of SEGSIZE, e.g., when sending IPv6 ND messages during tunnel setup. Alternatively, the tunnel could optimistically set a larger MTU and return locally-generated ICMPv6 "packet too big" messages in case it gets ICMPv4 "fragmentation needed" messages back from the network. But, this method is susceptible to path MTU-related black-holes when the network fails to deliver accurate ICMPv4s. The best implementations might do some kind of fusion of the two approaches, e.g., optimistically set a larger initial MTU and actively probe the tunnel segment size in the early going while watching for ICMPv4's. So, the degree of sophistication here is really up to the implementation rather than being mandated by the spec. Thanks - Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Friday, August 19, 2005 12:38 AM > To: Templin, Fred L > Cc: v6ops@ops.ietf.org > Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" >=20 > Hi Fred, >=20 > On Thu, 18 Aug 2005 10:20:01 -0700 > "Templin, Fred L" wrote: >=20 > > Mark, > >=20 > > Thanks for the comments. The paragraph you cited needs to be read in > > conjunction with the one that immediately follows, however, i.e.: > >=20 > > Since LinkMTU values larger than 1280 bytes may result=20 > in [ICMPv6] > > "packet too big" messages due to temporary segmentation=20 > restrictions > > (see: section 3.3), ULPs SHOULD employ a probing=20 > strategy that begins > > with a smaller payload size (on the order of 1KB) and=20 > probes upward > > [PMTUD]. (Note that this may not be possible for some ULPs.) > >=20 > > This says that ULPs (like TCP) can do their own probing if they want > > to discover larger MTUs beyond what the initial tunnel interface MTU > > allows independent of the tunnel segment size probing. BTW,=20 > this is true > > also for the case of no tunnel interfaces in the path,=20 > e.g., a TCP could > > start out on a path with a small MTU and re-routed to an=20 > all-GIGE path. > >=20 >=20 > Is this based on the assumption that the tunnel is a link within the > path, rather than possibly at one end of it ? >=20 > The reason I ask is that I was looking at this issue in the context of > one end of the TCP connection being on the same node as the tunnel end > point, which happens to be how I'm currently running IPv6 - this PC is > both a tunnel end point and the node where my TCP connections=20 > originate. >=20 > For example, say Node A is both the tunnel end point and one=20 > of the TCP > connection end points. Node A starts the 3 way TCP hand shake=20 > with remote > node B, which is sitting behind, rather than on, the remote tunnel > end-point. In that case, Node A would set it's announced MSS value to > something derived from the initial tunnel MTU i.e. 1280=20 > bytes, or a MSS > value of 1220. The other end might set MSS to 1440, because it is > attached to a 1500 byte MTU ethernet. >=20 > Even though there might be a larger possible path MTU between=20 > Node A and > B, including the tunnel within that path, e.g., 1500 - 20 (IPv4) - 40 > (IPv6) or a path MTU of 1460, Node B would never attempt to or cause a > probe for anything larger, because it would never send a=20 > segment to Node > A that was larger than Node A's initial MSS value.=20 >=20 > I'm not sure if TCP adapts to a larger local interface MTU if=20 > it changes > during the connection. If it does, Node A could send segments larger > than the initial MTU (minus IPv6 and TCP hdrs) to Node B if the local > MTU increases, up to the maximum segment size that Node B=20 > announced. If > TCP doesn't behave that way, then Node A would also never=20 > send a larger > than it's original MTU derived segment to Node B, also never=20 > causing the > tunnel MTU to increase. That would mean that in both directions of the > path, the MTU would never be increased beyond the initial tunnel MTU > value. >=20 > My thoughts were that setting the initial tunnel MTU to a=20 > value derived > from todays common Internet path MTU, rather than IPv6's minimum > required MTU value, might overcome this problem in this scenario where > the TCP and tunnel end points are on the same node, without=20 > it being too > detrimental to any other cases, such as when the tunnel is=20 > within the path, > rather than at one of the ends of it. >=20 > HTH, > Mark. >=20 From owner-v6ops@ops.ietf.org Fri Aug 19 14:43:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6BpW-0004Lx-BG for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 14:43: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 OAA21036 for ; Fri, 19 Aug 2005 14:43:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6BnL-000KkH-0Z for v6ops-data@psg.com; Fri, 19 Aug 2005 18:40:47 +0000 Received: from [194.251.242.241] (helo=fep16.inet.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6BnG-000Kjv-HM for v6ops@ops.ietf.org; Fri, 19 Aug 2005 18:40:42 +0000 Received: from hki1-1-1-35.hoasnet.inet.fi ([80.221.16.53]) by fep16.inet.fi with ESMTP id <20050819184040.IQLF27829.fep16.inet.fi@hki1-1-1-35.hoasnet.inet.fi> for ; Fri, 19 Aug 2005 21:40:40 +0300 From: =?iso-8859-1?q?R=E9mi_Denis-Courmont?= Organization: =?utf-8?q?=C3=89l=C3=A8ve_de_l=27=C3=89cole_Centrale?= Paris To: "'v6ops@ops.ietf.org '" Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Fri, 19 Aug 2005 21:40:54 +0300 User-Agent: KMail/1.7.2 References: <4304CEAC.5050800@dial.pipex.com> <20050819080016.GG30371@login.ecs.soton.ac.uk> In-Reply-To: <20050819080016.GG30371@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200508192140.54672.Remi.Denis-Courmont@via.ecp.fr> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Le Vendredi 19 Ao=FBt 2005 11:00, Tim Chown a =E9crit : > http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-im >plications-01.txt > > It's one of those 'kind of obvious' texts, but has received good > comments while it was live. I'm not decided myself how well that would fit in such a would-be=20 revived document, but, anyway... it might be worth to mention how/why=20 being on-link makes it easier to find out host addresses, e.g. if not=20 by listening to ICMPv6 ND or MLD traffic, by pinging the allnodes=20 multicast addresses. =2D-=20 R=E9mi Denis-Courmont From owner-v6ops@ops.ietf.org Fri Aug 19 14:55:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6C16-00082S-CC for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 14:55: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 OAA21398 for ; Fri, 19 Aug 2005 14:54:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6C0a-000MNh-Ll for v6ops-data@psg.com; Fri, 19 Aug 2005 18:54:28 +0000 Received: from [194.251.242.244] (helo=fep19.inet.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6C0X-000MNC-J6 for v6ops@ops.ietf.org; Fri, 19 Aug 2005 18:54:26 +0000 Received: from hki1-1-1-35.hoasnet.inet.fi ([80.221.16.53]) by fep19.inet.fi with ESMTP id <20050819185423.SUIC9928.fep19.inet.fi@hki1-1-1-35.hoasnet.inet.fi> for ; Fri, 19 Aug 2005 21:54:23 +0300 From: =?utf-8?q?R=C3=A9mi_Denis-Courmont?= Organization: =?utf-8?q?=C3=89l=C3=A8ve_de_l=27=C3=89cole_Centrale?= Paris To: v6ops@ops.ietf.org Subject: Teredo and draft-davies-v6ops-icmpv6-filtering-bcp-00 Date: Fri, 19 Aug 2005 21:54:34 +0300 User-Agent: KMail/1.7.2 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1309184.asGxl9a0fJ"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200508192154.37886.Remi.Denis-Courmont@via.ecp.fr> X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --nextPart1309184.asGxl9a0fJ Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, draft-davies-v6ops-icmpv6-filtering-bcp-00 suggests (=C2=A7 4.2) filtering= =20 incoming ICMPv6 Echo requests, and, optionaly, outgoing ones. I do understand they are security motivation for doing so. Yet, while=20 that might be seen as an abuse of ping6, Teredo tunneling, which seems=20 to be going for RFC, needs ping6 to establish symmetric routing of IPv6=20 packets between a Teredo client and a native (or tunneled otherwise)=20 IPv6 node. If these packets go unresponded, the IPv6 node becomes completely=20 unreachable from the Teredo client (regardless which of both actually=20 is the "initiator" of the data exchange). IMHO, it should at least be worth mentioning as a side effect in the=20 filtering draft, though there my be objections that I'm not aware of. Regards, =2D-=20 R=C3=A9mi Denis-Courmont http://www.simphalempin.com/home/infos/cv.shtml.en --nextPart1309184.asGxl9a0fJ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBDBirtw+xtvt1tEr0RAk/4AJ9WMEXCVTkkgApNDF5oeLuKxid41gCg2du7 BbAsPyhwDc/xokjogLv/Wic= =tyR8 -----END PGP SIGNATURE----- --nextPart1309184.asGxl9a0fJ-- From owner-v6ops@ops.ietf.org Fri Aug 19 16:04:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6D6R-0008JX-Q4 for v6ops-archive@megatron.ietf.org; Fri, 19 Aug 2005 16:04:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28388 for ; Fri, 19 Aug 2005 16:04:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6D56-0005Tg-Ts for v6ops-data@psg.com; Fri, 19 Aug 2005 20:03:12 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E6D54-0005T5-UV for v6ops@ops.ietf.org; Fri, 19 Aug 2005 20:03:11 +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 1E6D51-0007QJ-Q1; Fri, 19 Aug 2005 21:03:07 +0100 Message-ID: <43063B4A.4010308@dial.pipex.com> Date: Fri, 19 Aug 2005 21:04:26 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?R=E9mi_Denis-Courmont?= CC: v6ops@ops.ietf.org Subject: Re: Teredo and draft-davies-v6ops-icmpv6-filtering-bcp-00 References: <200508192154.37886.Remi.Denis-Courmont@via.ecp.fr> In-Reply-To: <200508192154.37886.Remi.Denis-Courmont@via.ecp.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id QAA28388 Thanks for pointing this out. Janos and I are working on a new version=20 of the draft and we will point this out. I'll check the security discussions in the Teredo draft to see what it=20 says on the subject. Regards, elwyn R=E9mi Denis-Courmont wrote: > Hello, > >draft-davies-v6ops-icmpv6-filtering-bcp-00 suggests (=A7 4.2) filtering=20 >incoming ICMPv6 Echo requests, and, optionaly, outgoing ones. > >I do understand they are security motivation for doing so. Yet, while=20 >that might be seen as an abuse of ping6, Teredo tunneling, which seems=20 >to be going for RFC, needs ping6 to establish symmetric routing of IPv6=20 >packets between a Teredo client and a native (or tunneled otherwise)=20 >IPv6 node. > >If these packets go unresponded, the IPv6 node becomes completely=20 >unreachable from the Teredo client (regardless which of both actually=20 >is the "initiator" of the data exchange). > >IMHO, it should at least be worth mentioning as a side effect in the=20 >filtering draft, though there my be objections that I'm not aware of. > >Regards, > > =20 > From owner-v6ops@ops.ietf.org Sat Aug 20 00:54:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6LN4-0007jv-EF for v6ops-archive@megatron.ietf.org; Sat, 20 Aug 2005 00:54: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 AAA22649 for ; Sat, 20 Aug 2005 00:54:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6LKT-000NVI-SA for v6ops-data@psg.com; Sat, 20 Aug 2005 04:51:37 +0000 Received: from [203.103.165.251] (helo=swebmail01.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6LKI-000NU4-PL for v6ops@ops.ietf.org; Sat, 20 Aug 2005 04:51:27 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta02.mail.ozemail.net with ESMTP id <20050819073725.XMEU650.smta02.mail.ozemail.net@ubu.nosense.org>; Fri, 19 Aug 2005 07:37:25 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 23E8E2F5D7; Fri, 19 Aug 2005 17:07:32 +0930 (CST) Date: Fri, 19 Aug 2005 17:07:31 +0930 From: Mark Smith To: "Templin, Fred L" Cc: v6ops@ops.ietf.org Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Message-Id: <20050819170731.24b413b3.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FCA@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FCA@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, On Thu, 18 Aug 2005 10:20:01 -0700 "Templin, Fred L" wrote: > Mark, > > Thanks for the comments. The paragraph you cited needs to be read in > conjunction with the one that immediately follows, however, i.e.: > > Since LinkMTU values larger than 1280 bytes may result in [ICMPv6] > "packet too big" messages due to temporary segmentation restrictions > (see: section 3.3), ULPs SHOULD employ a probing strategy that begins > with a smaller payload size (on the order of 1KB) and probes upward > [PMTUD]. (Note that this may not be possible for some ULPs.) > > This says that ULPs (like TCP) can do their own probing if they want > to discover larger MTUs beyond what the initial tunnel interface MTU > allows independent of the tunnel segment size probing. BTW, this is true > also for the case of no tunnel interfaces in the path, e.g., a TCP could > start out on a path with a small MTU and re-routed to an all-GIGE path. > Is this based on the assumption that the tunnel is a link within the path, rather than possibly at one end of it ? The reason I ask is that I was looking at this issue in the context of one end of the TCP connection being on the same node as the tunnel end point, which happens to be how I'm currently running IPv6 - this PC is both a tunnel end point and the node where my TCP connections originate. For example, say Node A is both the tunnel end point and one of the TCP connection end points. Node A starts the 3 way TCP hand shake with remote node B, which is sitting behind, rather than on, the remote tunnel end-point. In that case, Node A would set it's announced MSS value to something derived from the initial tunnel MTU i.e. 1280 bytes, or a MSS value of 1220. The other end might set MSS to 1440, because it is attached to a 1500 byte MTU ethernet. Even though there might be a larger possible path MTU between Node A and B, including the tunnel within that path, e.g., 1500 - 20 (IPv4) - 40 (IPv6) or a path MTU of 1460, Node B would never attempt to or cause a probe for anything larger, because it would never send a segment to Node A that was larger than Node A's initial MSS value. I'm not sure if TCP adapts to a larger local interface MTU if it changes during the connection. If it does, Node A could send segments larger than the initial MTU (minus IPv6 and TCP hdrs) to Node B if the local MTU increases, up to the maximum segment size that Node B announced. If TCP doesn't behave that way, then Node A would also never send a larger than it's original MTU derived segment to Node B, also never causing the tunnel MTU to increase. That would mean that in both directions of the path, the MTU would never be increased beyond the initial tunnel MTU value. My thoughts were that setting the initial tunnel MTU to a value derived from todays common Internet path MTU, rather than IPv6's minimum required MTU value, might overcome this problem in this scenario where the TCP and tunnel end points are on the same node, without it being too detrimental to any other cases, such as when the tunnel is within the path, rather than at one of the ends of it. HTH, Mark. From owner-v6ops@ops.ietf.org Sat Aug 20 00:54:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E6LNB-0007k7-3a for v6ops-archive@megatron.ietf.org; Sat, 20 Aug 2005 00:54: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 AAA22652 for ; Sat, 20 Aug 2005 00:54:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E6LKJ-000NUX-EC for v6ops-data@psg.com; Sat, 20 Aug 2005 04:51:27 +0000 Received: from [203.103.165.251] (helo=swebmail01.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E6LKH-000NU4-2d for v6ops@ops.ietf.org; Sat, 20 Aug 2005 04:51:25 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta05.mail.ozemail.net with ESMTP id <20050819081302.LZYW9768.smta05.mail.ozemail.net@ubu.nosense.org>; Fri, 19 Aug 2005 08:13:02 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 7E8452F5D7; Fri, 19 Aug 2005 17:43:09 +0930 (CST) Date: Fri, 19 Aug 2005 17:43:09 +0930 From: Mark Smith To: Fred.L.Templin@boeing.com Cc: v6ops@ops.ietf.org Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Message-Id: <20050819174309.5696a78c.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050819170731.24b413b3.ipng@69706e6720323030352d30312d31340a.nosense.org> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FCA@XCH-NW-7V2.nw.nos.boeing.com> <20050819170731.24b413b3.ipng@69706e6720323030352d30312d31340a.nosense.org> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Fri, 19 Aug 2005 17:07:31 +0930 Mark Smith wrote: > > Even though there might be a larger possible path MTU between Node A and > B, including the tunnel within that path, e.g., 1500 - 20 (IPv4) - 40 > (IPv6) or a path MTU of 1460, Node B would never attempt to or cause a > probe for anything larger, because it would never send a segment to Node Oops, that should be 1500 - 20 (IPv4) or a path MTU of 1480 bytes. From owner-v6ops@ops.ietf.org Sun Aug 21 22:50:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E72OI-0000Yz-Nr for v6ops-archive@megatron.ietf.org; Sun, 21 Aug 2005 22:50: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 WAA03085 for ; Sun, 21 Aug 2005 22:50:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E72L9-000HJv-G3 for v6ops-data@psg.com; Mon, 22 Aug 2005 02:47:11 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E72L7-000HJi-SJ for v6ops@ops.ietf.org; Mon, 22 Aug 2005 02:47:09 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-2.cisco.com with ESMTP; 21 Aug 2005 19:47:09 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j7M2l6Z1013720; Sun, 21 Aug 2005 19:47:07 -0700 (PDT) Received: from [10.11.113.209] (sjc-vpn5-410.cisco.com [10.21.89.154]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7M2hInw006914; Sun, 21 Aug 2005 19:43:19 -0700 In-Reply-To: <4305F4D5.7020809@dial.pipex.com> References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> <4305F4D5.7020809@dial.pipex.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 Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt Date: Mon, 22 Aug 2005 10:47:02 +0800 To: Elwyn Davies X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=160; t=1124678600; x=1125110800; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Last=20Call=20on=20draft-ietf-v6ops-security-overview-02.txt| From:Fred=20Baker=20| Date:Mon,=2022=20Aug=202005=2010=3A47=3A02=20+0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=l2vHe5ND33So9ICQNmHQMO9rk5hYQ8Nr73n99EPDxyErJfxd4oEsfjK6jVqNyUzGBZqHjyET KoJZKFjCKFsQSZByeAHL9flC3honx4GxfbMbdiS2DiRopg/Vtvp1j7lAoXm2PpI0RM7i8r7pTJA v59WQj94Pj9FLJ8WpvFwBZs4= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I concur. Go ahead and post your update, and I'll send it to the IESG. On Aug 19, 2005, at 11:03 PM, Elwyn Davies wrote: > I have a new version ready to go unless there are any last minute > comments. > From owner-v6ops@ops.ietf.org Mon Aug 22 04:12:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77Q5-0007Wp-CU for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 04:12:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29873 for ; Mon, 22 Aug 2005 04:12:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E77OJ-0001JQ-LQ for v6ops-data@psg.com; Mon, 22 Aug 2005 08:10:47 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E77OI-0001JD-Io for v6ops@ops.ietf.org; Mon, 22 Aug 2005 08:10:46 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7M8AiBr010070; Mon, 22 Aug 2005 09:10:44 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA08217; Mon, 22 Aug 2005 09:10:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7M8ASH10574; Mon, 22 Aug 2005 09:10:28 +0100 Date: Mon, 22 Aug 2005 09:10:28 +0100 From: Tim Chown To: Elwyn Davies Cc: v6ops@ops.ietf.org Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt Message-ID: <20050822081028.GB9503@login.ecs.soton.ac.uk> Mail-Followup-To: Elwyn Davies , v6ops@ops.ietf.org References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> <4305F4D5.7020809@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4305F4D5.7020809@dial.pipex.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, Aug 19, 2005 at 04:03:49PM +0100, Elwyn Davies wrote: > Today is the last day of the wg last call for this document (assuming we > actually count forwards ;-) ). > > I have not seen any comments during the last call, but my own scan of > the document has revealed a few nits and I have added an improved > example in section 4.3. I agree it's ready. Overall it's an excellent document. A handful of minor comments: One other minor nit: P.12, in 2.1.11 o IPv4 addresses are not universally supported across operating systems, and => 'IPv4 link-local addresses' In 2.1.11.1 In addition to advertising 'routing services which it will not fulfill' a node may be able to DoS by deprecating the existing good prefix. With router preferences (draft-ietf-ipv6-router-selection-07), an attacker may be able to launch a DoS attack, also with load balancing (draft-ietf-ipv6-host-load-sharing-04) there are similar concerns. See the security considerations sections of both documents. I would also say that in the example of IETF WLAN networks, DoS is not (probably) malicious, just misconfiguration with people not turning off their IPv6 configurations from other locations. In 4.1 I think this is a bit wishy-washy. It's really saying that IPv6 firewall, IDS and other security/resilience system implementations are lacking. I think the last paragraph doesn't really fit at all. One recommendation should be that admins support IPv6 deployment such that they control it rather than having (ab)users do so first. Another could be that any tunneled connectivity be terminated outside the site's (native) IPv6 firewall (which may or may not be the same system as the IPv4 firewall). In 4.4 For the security and management perspective, vendors and admins need to assume that multiaddressing is normal in IPv6. Being able to tokenise ACLs and configs in general for multiple prefixes and/or addresses would be generally useful. I think the only way to disable privacy addresses is to use full stateful DHCPv6 (where the client may request provacy addresses to be allocated, but the server need not honour that). I suspect many enterprise admins will wish to disable RFC3041. In 4.7 May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which recommends base security implementation for IPv6 nodes. In 4.8 Seems to overlap 4.1 in scope? I'm not sure the second paragraph really holds true now - at least separate admin experience from vendor experience :) In 4.9 This is already said in 4.4? In Appendix A: "Hosts behind the 6to4 router can use methods such as RFC 3041 addresses to conceal themselves, though." => Only if they are not meant to be reachable - otherwise they will have a static global address for receiving communications initiated inbound, while using 3041 for initiating communications outbound. In Appendix B.2: Just cite NAP here? In Appendix B.3: I would say here most users would *want* a static /48, so they can run services more easily. Cheers, -- Tim/::1 From owner-v6ops@ops.ietf.org Mon Aug 22 04:18:20 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E77Vc-0008Ry-3o for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 04:18: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 EAA00081 for ; Mon, 22 Aug 2005 04:18:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E77V5-0002TZ-8b for v6ops-data@psg.com; Mon, 22 Aug 2005 08:17:47 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E77V2-0002TG-FT for v6ops@ops.ietf.org; Mon, 22 Aug 2005 08:17:44 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7M8HhBr010204 for ; Mon, 22 Aug 2005 09:17:43 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA08716; Mon, 22 Aug 2005 09:17:29 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7M8HTX10732; Mon, 22 Aug 2005 09:17:29 +0100 Date: Mon, 22 Aug 2005 09:17:29 +0100 From: Tim Chown To: "'v6ops@ops.ietf.org '" Subject: Re: Review: draft-ietf-v6ops-nap-01.txt (port-scanning) Message-ID: <20050822081729.GF9503@login.ecs.soton.ac.uk> Mail-Followup-To: "'v6ops@ops.ietf.org '" References: <4304CEAC.5050800@dial.pipex.com> <20050819080016.GG30371@login.ecs.soton.ac.uk> <200508192140.54672.Remi.Denis-Courmont@via.ecp.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <200508192140.54672.Remi.Denis-Courmont@via.ecp.fr> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id EAA00081 On Fri, Aug 19, 2005 at 09:40:54PM +0300, R=E9mi Denis-Courmont wrote: > Le Vendredi 19 Ao=FBt 2005 11:00, Tim Chown a =E9crit : > > http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scanning-im > >plications-01.txt > > > > It's one of those 'kind of obvious' texts, but has received good > > comments while it was live. >=20 > I'm not decided myself how well that would fit in such a would-be=20 > revived document, but, anyway... it might be worth to mention how/why=20 > being on-link makes it easier to find out host addresses, e.g. if not=20 > by listening to ICMPv6 ND or MLD traffic, by pinging the allnodes=20 > multicast addresses. Interesting... it was initially written with the 'from off link' view, but could include on-link briefly, or other methods to discover on link addresses remotely. Thanks, --=20 Tim/::1 From owner-v6ops@ops.ietf.org Mon Aug 22 05:22:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E78Vk-0001Eb-Vd for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 05:22:33 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02508 for ; Mon, 22 Aug 2005 05:22:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E78Ty-000E4s-Lt for v6ops-data@psg.com; Mon, 22 Aug 2005 09:20:42 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E78Tv-000E4V-Kx for v6ops@ops.ietf.org; Mon, 22 Aug 2005 09:20:39 +0000 Received: from [81.187.254.247] (helo=[127.0.0.1]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.43) id 1E78Tt-00064P-NR; Mon, 22 Aug 2005 10:20:37 +0100 Message-ID: <43099934.8040404@dial.pipex.com> Date: Mon, 22 Aug 2005 10:21:56 +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 '" Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> <4305F4D5.7020809@dial.pipex.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I guess I have been overtaken by events.. Tim's comments are useful and looks like will not take long to incorporate. I'll reply to Tim and then get a new version ready. Regards, Elwyn Regards, Elwyn Fred Baker wrote: > I concur. Go ahead and post your update, and I'll send it to the IESG. > > On Aug 19, 2005, at 11:03 PM, Elwyn Davies wrote: > >> I have a new version ready to go unless there are any last minute >> comments. >> > From owner-v6ops@ops.ietf.org Mon Aug 22 06:12:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79IC-0000cj-Dh for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 06:12: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 GAA04651 for ; Mon, 22 Aug 2005 06:12:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E79Hu-000NVg-TF for v6ops-data@psg.com; Mon, 22 Aug 2005 10:12:18 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E79Hs-000NVL-2k for v6ops@ops.ietf.org; Mon, 22 Aug 2005 10:12:16 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7MACFBr014129 for ; Mon, 22 Aug 2005 11:12:15 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA20814 for ; Mon, 22 Aug 2005 11:11:43 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7MABgn14003 for v6ops@ops.ietf.org; Mon, 22 Aug 2005 11:11:42 +0100 Date: Mon, 22 Aug 2005 11:11:42 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Anything happening with lrw/softwires WG? Message-ID: <20050822101142.GM9503@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, Is there anything happening with this WG? There was a BoF in Paris: http://www.ietf.org/ietf/05aug/lrw.txt There seems to be an IETF mailling list: https://www1.ietf.org/mailman/listinfo/softwires The list page suggests the group is chartered... if so what is the charter? The list archive is currently empty. It would be nice to have some charter discussion, if it's not too late. -- Tim/::1 From owner-v6ops@ops.ietf.org Mon Aug 22 06:11:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E79HY-0000Yc-FY for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 06:11:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04581 for ; Mon, 22 Aug 2005 06:11:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E79GZ-000NKE-GV for v6ops-data@psg.com; Mon, 22 Aug 2005 10:10:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E79GW-000NK0-3g for v6ops@ops.ietf.org; Mon, 22 Aug 2005 10:10:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7MAAht26280; Mon, 22 Aug 2005 13:10:44 +0300 Date: Mon, 22 Aug 2005 13:10:43 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <200508191315.j7JDFvEV007151@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508191315.j7JDFvEV007151@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 19 Aug 2005, Francis Dupont wrote: > b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel > server(s) which can happen without user intervention, e.g., using > one of the processes described in > draft-palet-v6ops-tun-auto-disc-03.txt. > > => note this I-D was submitted years after DSTM and is not a complete > solution (in fact, today it is not a solution at all :-). Within an enterprise network (and having to discover v4-in-v6 TEP, so NATs are not an issue), the problem is much more constrained, so e.g., DHCPv6 is a possible solution. Softwires BOF might do something about this, or maybe not -- if folks are interested in this kind of problem, maybe they should speak up at a forum. In any case, the same approaches as are available for "DSTM" are probably also applicable here. > This must include a way to auto-configure a v4 address [e.g., DHCPv4]. > > => I believe you mean something providing the same service than DHCPv4, > not DHCPv4 itself. While DHCPv4 may or may not require minor tweaks (e.g., relating to link-layer adaptation), I think it could basically be used itself, and for the service. Could you elaborate why you think it's inappropriate? > b.2) the automatic set-up of v4-in-v6 tunnels, so that between each > host, an ad-hoc tunnel can be signalled and set up" [6to4-like > traffic optimization] > > => I believe you have "direct tunnels" in the b.2 idea? Yes. > c) assignment of an address on top of v4-in-v6 tunnel(s), but > deferred until the application wants to create v4 socket. > [issues with dual-stack server apps, for example] > > => note that c) is needed if allocated IPv4 addresses are global. > To come back to the DHCPv4 analogy, with DHCPv4 an address is needed > when a node attaches to the network, with c) an address is need > when (and only when) a node has to make an IPv4 communication. No, "global v4 addresses -> c)" does not follow. It is a perfectly fine way to run and use addresses to give each node requiring v4 connectivity a static global address. Those which need them only now and then can also use global addresses, but the easiest would probably be using RFC1918 for those nodes. The issue how aggressively to conserve v4 address space at the cost of more complexity and mechanisms like dynamic assignments/removals is a trade-off. Some may believe it's worth the effort; many others (like me) think it's not (and personally, I think it'll cause more harm than help). I gave further reasons for my belief in my reply to Stig on Aug 10, with subject "Re: Enterprise Analysis DSTM Issue: dynamic setup", especially wrt. who needs a global or private address. > d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) > when the host detects it no longer needs the address/connectivity > > => as I've already explained, d) is a consequence of c). While d) may be desirable by some if you want to release the global address back to the "pool" as soon as possible, it's not a direct consequence AFAICS. It'd be perfectly fine to deploy only c) with the assumption that if the host needs v4 even once, it gets v4 "for good" (at least as long as isn't rebooted). While c) may not conserve address space as effectively as c)+d), it's something to be evaluated based on the tradeoffs. > - c) is something implementations may try to do on their own, but I > would recommend against it, and the IETF shouldn't work on that > > => c) is *not* an option when you have not one address per node, i.e., > when b.1) is not usable. I'm not sure what you meant with "is *not* an option". What is the option then? > - d) doesn't seem to be worth the effort and is probably difficult to > get right -- and for addresses, DHCPv4 and other methods already > exist; not sure we want/need to do more work on that. > > => perhaps I have misunderstood d) but when the IPv4 address expires the > tunnel must be torn down... No, I don't think it follows. I don't see why you couldn't just have a v4-in-v6 tunnel but the host wouldn't have any v4 address, right? An analogue: when my DSL provider's DHCPv4 server goes down or the DSL modem's DHCP snooping breaks, my lease expires and on my BSD router the public v4 address I normally have is changed to "0.0.0.0". If I re-run DHCPv4, I get the address back. Why the same couldn't happen here? Why must the tunnel be removed? > I have no problem having the enterprise analysis document include this > kind of analysis, and describe the need for a) and b.1) -- and I think > this is probably a good thing as it might lessen the confusion on the > real requirements for v4-in-v6 tunnels -- but if we go further than > that, we may have a problem.... > > => we have already a problem with IPv4 global addresses: there are not > enough! IANA has been allocating lots of /8's. Our organization has gotten a new /16 as well. I'd argue that the situation with v4 address availability has gotten better. > > => the overload (if any) should be solved by the references... > > This is a working group document. I don't think we can just refer to > a non-wg, ambiguous document and expect it to clear up the ambiguities > and confusion. > > => so your concerns are about the DSTM documents? You could say so, yes. > > => I saw the birth of DSTM: DSTM is Jim Bound's AIIH + Laurent > > Toutain's DTI. > > That may be, but many people since have used the term, > > => the term is not (yet :-) a trade mark... > > and may have zero idea what the goals are or may have been. > > => this is a random remark which is not about the WG I-D. I think it may still be relevant, though. Lots of people who want just simple v4-in-v6 tunnels, or something slightly more sophisticated (for example a) and b.1) in above terminology) think they need something called "DSTM". Reading the spec does not give them much idea about the goals or the background relevant to their own requirements. The enterprise analysis document seems like a natural place to discuss these requirements in the hopes of lessening the confusion. > Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between > each host or the like, a protocol interoperability that goes beyond > the plain tunnel broker would be needed. But I wasn't implying that > functionality (nor do I think it is needed). > > => what I said is the setup mechanism is orthogonal to the tunnel > mechanism and the only thing about it is just to have one (zero > doesn't work, two or more don't interoperate). BTW to be clearer > here I mean the setup of a tunnel between a node and a TEP. Well, isn't TSP a solution here as well? Jeroen Massar also had done work in this space. Softwires BOF is working on this. In any case, as far as I see, the DSTM spec is mostly just describing the concept and giving a couple of examples here and there which protocols could be used; I don't see how you could write an interoperable implementation based on it. > What I meant is that if you already have a) and b.1), i.e., an ability > for the host to set up a tunnel without manual configuration with a > tunnel server, all your implementation needs to do is add a hack which > triggers this activation when the v4 socket call is being made. > > There is no difference between b.1) and c) wrt. bits on the wire, > right? > > => the difference between b.1) and c) is the type of IPv4 addresses. > If the IPv4 address can be statically allocated c) (and in fact b.1) too) > is not required, if the IPv4 address is global and cannot be statically > allocated (because the pool is too small), c) is required (and d) as > a consequence of c) too). BTW you could say that a NAT removes the > requirement but I don't think you'd like to use this argument. In fact, I *do* like to use that argument :-). In any case, while different kinds of addresses used may or may not affect the weighing of tradeoffs, I don't see how b.1) and c) differ on the wire. The protocol to set up the signalling, the tunneling, etc. can be the same, i.e., there's no difference on the wire, and a decision could be just an implementation decision. I'm not sure if there's anything requiring interoperability in d) either, as I guess you could just remove the tunnel interface if you don't have an address anymore -- I'm not sure if it's even worth the trouble -- but that's debatable. > > My point is that I'm having hard time figuring out: > > 1) what the document means when it's recommending DSTM, and > > > > => the references > > As said, I don't think a wg doc like this can shrug off these kinds of > issues by just referring to non-wg documents and letting them sort > things out. Best would probably be summarizing the different > requirements or non-requirements (a-d above) in this doc, removing the > references altogether, and enhancing the dstm spec (or writing a > separate draft describing the scenarios/requirements for v4-in-v6 > tunneling) to try to remove any confusion. > > => so you ask for a scenario with global IPv4 addresses (c)) or > for clear operational advantages for (c)). I'm only looking for the second, because the first may or may not call for this scenario. > IPv6-dominant networks (section 6) are the reason to ask for at least a), > the text ("must acquire...locate...") suggests at least b.1). > It seems I have now a clear view of the "missing part" in the WG I-D... yes, and these must be clearly separated from each other, especially if there is a scenario calling out for c) or d). > I propose this scenario: > - an IPv4 site with 200 nodes using a /24 is connected to the Internet. > - the site grows to 500 nodes, solutions are: > * get more IPv4 addresses: I suppose it is not possible. > * put a NAT: I suppose we don't want this! > Note a NAT on addresses only should be enough. > * switch to IPv6, get a /48, take advantages of IPv6 feature, etc, > but what to do with partners (perhaps including the ISP :-) still > using IPv4: lookup for the solution in the WG I-D? > - I assume there is a reasonnable number of "simultaneous" nodes which > need an IPv4 address from the /24 pool. This assumption is used for > the NAT or the DSTM solution (I have real world figures to support > this assumption). > - the best solution is DSTM... Frankly, the dominant v6 deployment for this problem seems like shooting birds with 160mm cannon (much much trouble that way), but that aside.. What are the chances that such a site is not already using NAT, or doesn't have the capability of getting more addresses? In university world, lots of places actually use mostly global v4 addresses, but on the other hand, they also seem to be quite capable of obtaining more from their LIRs and RIR as needed. I'd be interested in seeing which kind of figures you have, could you send e.g., offlist if long? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 22 08:37:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BYA-0000VI-Tr for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 08:37: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 IAA12577 for ; Mon, 22 Aug 2005 08:37:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7BW5-000NBk-KU for v6ops-data@psg.com; Mon, 22 Aug 2005 12:35:05 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7BW4-000NAo-5i for v6ops@ops.ietf.org; Mon, 22 Aug 2005 12:35: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 1E7BVw-0001tM-OT; Mon, 22 Aug 2005 13:34:57 +0100 Message-ID: <4309C6BD.2060900@dial.pipex.com> Date: Mon, 22 Aug 2005 13:36:13 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> <4305F4D5.7020809@dial.pipex.com> <20050822081028.GB9503@login.ecs.soton.ac.uk> In-Reply-To: <20050822081028.GB9503@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the comments. Responses in line.. If there is no pushback from the mailing list I will incorporate the changes and send a note of the changes asap Regards, Elwyn Tim Chown wrote: >On Fri, Aug 19, 2005 at 04:03:49PM +0100, Elwyn Davies wrote: > > >>Today is the last day of the wg last call for this document (assuming we >>actually count forwards ;-) ). >> >>I have not seen any comments during the last call, but my own scan of >>the document has revealed a few nits and I have added an improved >>example in section 4.3. >> >> > >I agree it's ready. Overall it's an excellent document. > >A handful of minor comments: > >One other minor nit: P.12, in 2.1.11 > > o IPv4 addresses are not universally supported across operating > systems, and > >=> 'IPv4 link-local addresses' > > Yep. >In 2.1.11.1 > >In addition to advertising 'routing services which it will not fulfill' >a node may be able to DoS by deprecating the existing good prefix. With >router preferences (draft-ietf-ipv6-router-selection-07), an attacker may >be able to launch a DoS attack, also with load balancing >(draft-ietf-ipv6-host-load-sharing-04) there are similar concerns. See >the security considerations sections of both documents. I would also >say that in the example of IETF WLAN networks, DoS is not (probably) >malicious, just misconfiguration with people not turning off their IPv6 >configurations from other locations. > > As an aside, having this section as a 4th level subsection seems a bit peculiar... the relation with 2.1.11 is through SEND but the topic is really unrelated. I propose to promote it to level 3 as 2.1.12, renumbering Mobile IP to 2.1.13. I think it would be useful to add notes pointing to the additional problems highlighted in these drafts, especially as these are headed towards RFC status. I'll draft some text and send it out shortly. >In 4.1 > >I think this is a bit wishy-washy. It's really saying that IPv6 firewall, >IDS and other security/resilience system implementations are lacking. >I think the last paragraph doesn't really fit at all. One recommendation >should be that admins support IPv6 deployment such that they control it >rather than having (ab)users do so first. > This section is trying to a bit more than this: advising people to try and avoid the 'suck it and see approach' but still to 'please actually go and implement IPv6' rather than succumbing to FUD. The emphasis should be on doing it properly, and that there are tools to help. The last para has been around for a while.. it has got separated from the v6onbydefault reference which is where it belongs. I'll try an come up with a better arrangement and a firmer recommendation. >Another could be that any >tunneled connectivity be terminated outside the site's (native) IPv6 firewall >(which may or may not be the same system as the IPv4 firewall). > > This thought is well taken... I think it belongs in 3.3 What we are emphasising is that packets should be routed (at least logically) as follows: 'Inside' <---> IPv6 Firewall <---> v6 in v4 tunnel endpoint <---> IPv4 Firewall <---> Outside A sort of extra DMZ for IPv6. >In 4.4 > >For the security and management perspective, vendors and admins need to >assume that multiaddressing is normal in IPv6. Being able to tokenise ACLs >and configs in general for multiple prefixes and/or addresses would be >generally useful. > Certainly making it even clearer that multiple addresses are a fact of normal life, and not an occasional aberration, for IPv6 would be worthwhile. A few words of advice for vendors on ease of configuration also. > I think the only way to disable privacy addresses is >to use full stateful DHCPv6 (where the client may request provacy addresses >to be allocated, but the server need not honour that). I suspect many >enterprise admins will wish to disable RFC3041. > > Again this would be a useful comment.. I'll add it. >In 4.7 > >May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which >recommends base security implementation for IPv6 nodes. > > It would probably be worth citing this earlier on in a more general context (maybe as well). >In 4.8 > >Seems to overlap 4.1 in scope? > I think the changes I suggested above reduce the (perceived) overlap. I think they are separate issues. >I'm not sure the second paragraph really >holds true now - at least separate admin experience from vendor >experience :) > > The admin experience is certainly still true I believe.. we could alter the software piece to emphasise lower maturity. >In 4.9 > >This is already said in 4.4? > > A different perspective I think.. the issue of fast changing addresses does crop up in a number of places. I don't propose to change this. >In Appendix A: > >"Hosts behind the > 6to4 router can use methods such as RFC 3041 addresses to conceal > themselves, though." > >=> Only if they are not meant to be reachable - otherwise they will have > a static global address for receiving communications initiated inbound, > while using 3041 for initiating communications outbound. > > I'll add a few words. >In Appendix B.2: > >Just cite NAP here? > > The business model discussion doesn't appear in NAP! That being said the business model discussion cannot necessarily be solved by addressing.. Steve Bellovin's work on determining the number of hosts behind a NAT can be extended to IPv6 (although the data will be scarcer than in IPv4 because not all packets contain an IPid) (see the FNAT reference). OTOH it would be worth citing NAP for further discussion of privacy issues for the whole of Appendix B. >In Appendix B.3: > >I would say here most users would *want* a static /48, so they can run >services more easily. > > We could mention the conflict. Regards, Elwyn > >Cheers, > > From owner-v6ops@ops.ietf.org Mon Aug 22 08:44:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7BfZ-00022C-VE for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 08:44: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 IAA12959 for ; Mon, 22 Aug 2005 08:44:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Bf6-000Opf-Es for v6ops-data@psg.com; Mon, 22 Aug 2005 12:44:24 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Bf5-000OpN-6E for v6ops@ops.ietf.org; Mon, 22 Aug 2005 12:44:23 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7MCiLk9020390 for ; Mon, 22 Aug 2005 13:44:21 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id NAA02752 for ; Mon, 22 Aug 2005 13:43:57 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7MChva18343 for v6ops@ops.ietf.org; Mon, 22 Aug 2005 13:43:57 +0100 Date: Mon, 22 Aug 2005 13:43:57 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Last Call on draft-ietf-v6ops-security-overview-02.txt Message-ID: <20050822124357.GZ9503@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <0905E201-12F6-43F8-85D8-8CCF4F2AA3F9@cisco.com> <4305F4D5.7020809@dial.pipex.com> <20050822081028.GB9503@login.ecs.soton.ac.uk> <4309C6BD.2060900@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4309C6BD.2060900@dial.pipex.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks Elwyn, those comments/answers are all fine to me. B.2 is a can of worms, and probably not one to dig too deep into in a document like this. I just hope for IPv6 that ISPs appreciate that a /48 (or /56 by RFC3177-bis) is the norm, and hence a per-device fee is inappropriate. I would assume many dual-stack home networks would run IPv6 on a /56 alongside an IPv4+NAT scheme. Tim On Mon, Aug 22, 2005 at 01:36:13PM +0100, Elwyn Davies wrote: > Thanks for the comments. > > Responses in line.. If there is no pushback from the mailing list I > will incorporate the changes and send a note of the changes asap > > Regards, > Elwyn > > Tim Chown wrote: > > >On Fri, Aug 19, 2005 at 04:03:49PM +0100, Elwyn Davies wrote: > > > > > >>Today is the last day of the wg last call for this document (assuming we > >>actually count forwards ;-) ). > >> > >>I have not seen any comments during the last call, but my own scan of > >>the document has revealed a few nits and I have added an improved > >>example in section 4.3. > >> > >> > > > >I agree it's ready. Overall it's an excellent document. > > > >A handful of minor comments: > > > >One other minor nit: P.12, in 2.1.11 > > > > o IPv4 addresses are not universally supported across operating > > systems, and > > > >=> 'IPv4 link-local addresses' > > > > > Yep. > > >In 2.1.11.1 > > > >In addition to advertising 'routing services which it will not fulfill' > >a node may be able to DoS by deprecating the existing good prefix. With > >router preferences (draft-ietf-ipv6-router-selection-07), an attacker may > >be able to launch a DoS attack, also with load balancing > >(draft-ietf-ipv6-host-load-sharing-04) there are similar concerns. See > >the security considerations sections of both documents. I would also > >say that in the example of IETF WLAN networks, DoS is not (probably) > >malicious, just misconfiguration with people not turning off their IPv6 > >configurations from other locations. > > > > > As an aside, having this section as a 4th level subsection seems a bit > peculiar... the relation with 2.1.11 is through SEND but the topic is > really unrelated. I propose to promote it to level 3 as 2.1.12, > renumbering Mobile IP to 2.1.13. > > I think it would be useful to add notes pointing to the additional > problems highlighted in these drafts, especially as these are headed > towards RFC status. I'll draft some text and send it out shortly. > > >In 4.1 > > > >I think this is a bit wishy-washy. It's really saying that IPv6 firewall, > >IDS and other security/resilience system implementations are lacking. > >I think the last paragraph doesn't really fit at all. One recommendation > >should be that admins support IPv6 deployment such that they control it > >rather than having (ab)users do so first. > > > This section is trying to a bit more than this: advising people to try > and avoid the 'suck it and see approach' but still to 'please actually > go and implement IPv6' rather than succumbing to FUD. The emphasis > should be on doing it properly, and that there are tools to help. > > The last para has been around for a while.. it has got separated from > the v6onbydefault reference which is where it belongs. I'll try an come > up with a better arrangement and a firmer recommendation. > > >Another could be that any > >tunneled connectivity be terminated outside the site's (native) IPv6 > >firewall > >(which may or may not be the same system as the IPv4 firewall). > > > > > This thought is well taken... I think it belongs in 3.3 > > What we are emphasising is that packets should be routed (at least > logically) as follows: > > 'Inside' <---> IPv6 Firewall <---> v6 in v4 tunnel endpoint <---> IPv4 > Firewall <---> Outside > > A sort of extra DMZ for IPv6. > > >In 4.4 > > > >For the security and management perspective, vendors and admins need to > >assume that multiaddressing is normal in IPv6. Being able to tokenise ACLs > >and configs in general for multiple prefixes and/or addresses would be > >generally useful. > > > Certainly making it even clearer that multiple addresses are a fact of > normal life, and not an occasional aberration, for IPv6 would be > worthwhile. A few words of advice for vendors on ease of configuration > also. > > > I think the only way to disable privacy addresses is > >to use full stateful DHCPv6 (where the client may request provacy addresses > >to be allocated, but the server need not honour that). I suspect many > >enterprise admins will wish to disable RFC3041. > > > > > Again this would be a useful comment.. I'll add it. > > >In 4.7 > > > >May wish to look at or cite draft-ietf-ipv6-node-requirements-11 which > >recommends base security implementation for IPv6 nodes. > > > > > It would probably be worth citing this earlier on in a more general > context (maybe as well). > > >In 4.8 > > > >Seems to overlap 4.1 in scope? > > > I think the changes I suggested above reduce the (perceived) overlap. I > think they are separate issues. > > >I'm not sure the second paragraph really > >holds true now - at least separate admin experience from vendor > >experience :) > > > > > The admin experience is certainly still true I believe.. we could alter > the software piece to emphasise lower maturity. > > >In 4.9 > > > >This is already said in 4.4? > > > > > A different perspective I think.. the issue of fast changing addresses > does crop up in a number of places. I don't propose to change this. > > >In Appendix A: > > > >"Hosts behind the > > 6to4 router can use methods such as RFC 3041 addresses to conceal > > themselves, though." > > > >=> Only if they are not meant to be reachable - otherwise they will have > > a static global address for receiving communications initiated inbound, > > while using 3041 for initiating communications outbound. > > > > > I'll add a few words. > > >In Appendix B.2: > > > >Just cite NAP here? > > > > > The business model discussion doesn't appear in NAP! That being said > the business model discussion cannot necessarily be solved by > addressing.. Steve Bellovin's work on determining the number of hosts > behind a NAT can be extended to IPv6 (although the data will be scarcer > than in IPv4 because not all packets contain an IPid) (see the FNAT > reference). > > OTOH it would be worth citing NAP for further discussion of privacy > issues for the whole of Appendix B. > > >In Appendix B.3: > > > >I would say here most users would *want* a static /48, so they can run > >services more easily. > > > > > We could mention the conflict. > > Regards, > Elwyn > > > > >Cheers, > > > > -- Tim/::1 From owner-v6ops@ops.ietf.org Mon Aug 22 12:21:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7F35-0002Ww-Dq for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 12:21: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 MAA26195 for ; Mon, 22 Aug 2005 12:21:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7F0v-000CuM-NM for v6ops-data@psg.com; Mon, 22 Aug 2005 16:19:09 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7F0t-000Cu9-Nl for v6ops@ops.ietf.org; Mon, 22 Aug 2005 16:19:07 +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 JAA04730; Mon, 22 Aug 2005 09:19:02 -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 j7MGJ1s29333; Mon, 22 Aug 2005 09:19:02 -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.211); Mon, 22 Aug 2005 09:19: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: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Date: Mon, 22 Aug 2005 09:19:00 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FD6@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Thread-Index: AcWkkNoXhpvTViqNTyuVjeqj8refRwAO2lwwAJniArA= From: "Templin, Fred L" To: "Mark Smith" Cc: X-OriginalArrivalTime: 22 Aug 2005 16:19:00.0726 (UTC) FILETIME=[3495B960:01C5A735] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Mark, Another implementation option which wasn't mentioned is to designate a tunnel pseudo-interface that acts as a "lid" on the can-of-worms consisting of all active tunnels configured on the endpoint. The lid would present a consistent MTU (e.g., 9180 bytes) to upper layers, e.g., for setting the TCP MSS, but there may be instances of locally-generated ICMPv6 "packet too big" messages coming from tunnels inside the can. Again, this seems outside the scope of the specification - do you concur? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Templin, Fred L=20 > Sent: Friday, August 19, 2005 8:17 AM > To: Mark Smith > Cc: v6ops@ops.ietf.org > Subject: RE: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" >=20 > Mark, >=20 > Understand your point about setting TCP MSS, but regardless of > whether the tunnel occurs on the same node as one of the TCPs > or somewhere along the path the key point is whether/not the > implementation takes the SHOULD and configures the largest > possible MTU during tunnel setup time. This might require some > pre-probing of SEGSIZE, e.g., when sending IPv6 ND messages > during tunnel setup. >=20 > Alternatively, the tunnel could optimistically set a larger MTU > and return locally-generated ICMPv6 "packet too big" messages > in case it gets ICMPv4 "fragmentation needed" messages back > from the network. But, this method is susceptible to path > MTU-related black-holes when the network fails to deliver > accurate ICMPv4s. >=20 > The best implementations might do some kind of fusion of the > two approaches, e.g., optimistically set a larger initial MTU > and actively probe the tunnel segment size in the early going > while watching for ICMPv4's. So, the degree of sophistication > here is really up to the implementation rather than being > mandated by the spec. >=20 > Thanks - Fred > fred.l.templin@boeing.com > =20 >=20 > > -----Original Message----- > > From: Mark Smith=20 > > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > > Sent: Friday, August 19, 2005 12:38 AM > > To: Templin, Fred L > > Cc: v6ops@ops.ietf.org > > Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" > >=20 > > Hi Fred, > >=20 > > On Thu, 18 Aug 2005 10:20:01 -0700 > > "Templin, Fred L" wrote: > >=20 > > > Mark, > > >=20 > > > Thanks for the comments. The paragraph you cited needs to=20 > be read in > > > conjunction with the one that immediately follows, however, i.e.: > > >=20 > > > Since LinkMTU values larger than 1280 bytes may result=20 > > in [ICMPv6] > > > "packet too big" messages due to temporary segmentation=20 > > restrictions > > > (see: section 3.3), ULPs SHOULD employ a probing=20 > > strategy that begins > > > with a smaller payload size (on the order of 1KB) and=20 > > probes upward > > > [PMTUD]. (Note that this may not be possible for some ULPs.) > > >=20 > > > This says that ULPs (like TCP) can do their own probing=20 > if they want > > > to discover larger MTUs beyond what the initial tunnel=20 > interface MTU > > > allows independent of the tunnel segment size probing. BTW,=20 > > this is true > > > also for the case of no tunnel interfaces in the path,=20 > > e.g., a TCP could > > > start out on a path with a small MTU and re-routed to an=20 > > all-GIGE path. > > >=20 > >=20 > > Is this based on the assumption that the tunnel is a link within the > > path, rather than possibly at one end of it ? > >=20 > > The reason I ask is that I was looking at this issue in the=20 > context of > > one end of the TCP connection being on the same node as the=20 > tunnel end > > point, which happens to be how I'm currently running IPv6 -=20 > this PC is > > both a tunnel end point and the node where my TCP connections=20 > > originate. > >=20 > > For example, say Node A is both the tunnel end point and one=20 > > of the TCP > > connection end points. Node A starts the 3 way TCP hand shake=20 > > with remote > > node B, which is sitting behind, rather than on, the remote tunnel > > end-point. In that case, Node A would set it's announced=20 > MSS value to > > something derived from the initial tunnel MTU i.e. 1280=20 > > bytes, or a MSS > > value of 1220. The other end might set MSS to 1440, because it is > > attached to a 1500 byte MTU ethernet. > >=20 > > Even though there might be a larger possible path MTU between=20 > > Node A and > > B, including the tunnel within that path, e.g., 1500 - 20=20 > (IPv4) - 40 > > (IPv6) or a path MTU of 1460, Node B would never attempt to=20 > or cause a > > probe for anything larger, because it would never send a=20 > > segment to Node > > A that was larger than Node A's initial MSS value.=20 > >=20 > > I'm not sure if TCP adapts to a larger local interface MTU if=20 > > it changes > > during the connection. If it does, Node A could send segments larger > > than the initial MTU (minus IPv6 and TCP hdrs) to Node B if=20 > the local > > MTU increases, up to the maximum segment size that Node B=20 > > announced. If > > TCP doesn't behave that way, then Node A would also never=20 > > send a larger > > than it's original MTU derived segment to Node B, also never=20 > > causing the > > tunnel MTU to increase. That would mean that in both=20 > directions of the > > path, the MTU would never be increased beyond the initial tunnel MTU > > value. > >=20 > > My thoughts were that setting the initial tunnel MTU to a=20 > > value derived > > from todays common Internet path MTU, rather than IPv6's minimum > > required MTU value, might overcome this problem in this=20 > scenario where > > the TCP and tunnel end points are on the same node, without=20 > > it being too > > detrimental to any other cases, such as when the tunnel is=20 > > within the path, > > rather than at one of the ends of it. > >=20 > > HTH, > > Mark. > >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 22 13:05:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7FkB-0001rd-I6 for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:05: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 NAA28448 for ; Mon, 22 Aug 2005 13:05:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7FjI-000LjO-5c for v6ops-data@psg.com; Mon, 22 Aug 2005 17:05:00 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7FjE-000Liy-GP for v6ops@ops.ietf.org; Mon, 22 Aug 2005 17:04:57 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j7MH4XK23900; Mon, 22 Aug 2005 19:04:33 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j7MH4Xr5021206; Mon, 22 Aug 2005 19:04:33 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508221704.j7MH4Xr5021206@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-reply-to: Your message of Mon, 22 Aug 2005 13:10:43 +0300. Date: Mon, 22 Aug 2005 19:04:33 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > This must include a way to auto-configure a v4 address [e.g., DHCPv4]. > > => I believe you mean something providing the same service than DHCPv4, > not DHCPv4 itself. While DHCPv4 may or may not require minor tweaks (e.g., relating to link-layer adaptation), => using DHCPv4 over a tunnel is *not* a minor tweak. I think it could basically be used itself, and for the service. => unfortunately this is not true. BTW the code itself can be reused but this is not the case of the protocol. Could you elaborate why you think it's inappropriate? => DHCPv4 can't send a packet over a tunnel which has no addresses, the limitation comes from DHCPv4 itself and from the nature of tunnels. But as I've explained this is not dramatic: we already have the code which provides the service, we only need to add some glue to replace the protocol, or if you prefer this way a small facility for carrying DHCPv4 messages and a translator (better if you can only reuse the binary of the server). No, "global v4 addresses -> c)" does not follow. It is a perfectly fine way to run and use addresses to give each node requiring v4 connectivity a static global address. => you only assume that anybody has already enough global addresses. I'd like that it is true but in fact it is not. Those which need them only now and then can also use global addresses, but the easiest would probably be using RFC1918 for those nodes. => RFC 1918 and a NAT? Is it really your idea?? The issue how aggressively to conserve v4 address space at the cost of more complexity and mechanisms like dynamic assignments/removals is a trade-off. => Do you argue there is not realistic scenarios where there is no choice and the IPv4 address space has to aggressively be conserved? I gave further reasons for my belief in my reply to Stig on Aug 10, with subject "Re: Enterprise Analysis DSTM Issue: dynamic setup", especially wrt. who needs a global or private address. => I should have this message somewhere in my mail box. > d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) > when the host detects it no longer needs the address/connectivity > > => as I've already explained, d) is a consequence of c). While d) may be desirable by some if you want to release the global address back to the "pool" as soon as possible, it's not a direct consequence AFAICS. => it is a direct consequence of the not unlimited lifetime of the allocation. It'd be perfectly fine to deploy only c) with the assumption that if the host needs v4 even once, it gets v4 "for good" (at least as long as isn't rebooted). => allocations with an unlimited lifetime are not enough aggressive. (this is why BOOTP was extended to DHCP). While c) may not conserve address space as effectively as c)+d), it's something to be evaluated based on the tradeoffs. => in the DSTM context, we already studied what should be the size of the pool and the lifetimes (initial/renew) from statistics about some real traffics (it was a good subject for a student training period). > => c) is *not* an option when you have not one address per node, i.e., > when b.1) is not usable. I'm not sure what you meant with "is *not* an option". What is the option then? => not c), i.e., I've tried to mean that c) is required and not optional in this case. > - d) doesn't seem to be worth the effort and is probably difficult to > get right -- and for addresses, DHCPv4 and other methods already > exist; not sure we want/need to do more work on that. > > => perhaps I have misunderstood d) but when the IPv4 address expires the > tunnel must be torn down... No, I don't think it follows. I don't see why you couldn't just have a v4-in-v6 tunnel but the host wouldn't have any v4 address, right? => I don't know how to easily implement tunnels without addresses... But this is an implementation detail, i.e., you can disable the tunnel in place of deleting it. > Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between > each host or the like, a protocol interoperability that goes beyond > the plain tunnel broker would be needed. But I wasn't implying that > functionality (nor do I think it is needed). > > => what I said is the setup mechanism is orthogonal to the tunnel > mechanism and the only thing about it is just to have one (zero > doesn't work, two or more don't interoperate). BTW to be clearer > here I mean the setup of a tunnel between a node and a TEP. Well, isn't TSP a solution here as well? => DSTM can use TSP (there is a discussion about the choice between TSP and DHCPv6, both work but we need one and only one :-). I don't see how you could write an interoperable implementation based on it. => I was able to write one so I could? > BTW you could say that a NAT removes the > requirement but I don't think you'd like to use this argument. In fact, I *do* like to use that argument :-). > => so you ask for a scenario with global IPv4 addresses (c)) or > for clear operational advantages for (c)). I'm only looking for the second, because the first may or may not call for this scenario. => IMHO the first one is better even I nearly used DSTM for the second. > IPv6-dominant networks (section 6) are the reason to ask for at least a), > the text ("must acquire...locate...") suggests at least b.1). > It seems I have now a clear view of the "missing part" in the WG I-D... yes, and these must be clearly separated from each other, especially if there is a scenario calling out for c) or d). > I propose this scenario: > - an IPv4 site with 200 nodes using a /24 is connected to the Internet. > - the site grows to 500 nodes, solutions are: > * get more IPv4 addresses: I suppose it is not possible. > * put a NAT: I suppose we don't want this! > Note a NAT on addresses only should be enough. > * switch to IPv6, get a /48, take advantages of IPv6 feature, etc, > but what to do with partners (perhaps including the ISP :-) still > using IPv4: lookup for the solution in the WG I-D? > - I assume there is a reasonnable number of "simultaneous" nodes which > need an IPv4 address from the /24 pool. This assumption is used for > the NAT or the DSTM solution (I have real world figures to support > this assumption). > - the best solution is DSTM... Frankly, the dominant v6 deployment for this problem seems like shooting birds with 160mm cannon (much much trouble that way), but that aside.. => 160mm? Too small! (:-). What are the chances that such a site is not already using NAT, or doesn't have the capability of getting more addresses? => this is not (yet?) the place where to explain why NATs are bad. Just say there is a binary only application using embedded addresses (unfortunately not a silly assumption, don't forget this is about enterprise scenarios). In university world, lots of places actually use mostly global v4 addresses, but on the other hand, they also seem to be quite capable of obtaining more from their LIRs and RIR as needed. => here I ask my site administrator a /24 or /25, I've still waited for some years, so don't say this is easy everywhere because it is easy where you are, PLEASE. I'd be interested in seeing which kind of figures you have, could you send e.g., offlist if long? => the study was paid by a commercial ISP... Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Mon Aug 22 13:47:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7GOA-0001bj-Lb for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 13:47: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 NAA00500 for ; Mon, 22 Aug 2005 13:47:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7GMR-0003cI-Lw for v6ops-data@psg.com; Mon, 22 Aug 2005 17:45:27 +0000 Received: from [208.17.33.58] (helo=pacdcoavas09.cable.comcast.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7GMP-0003bd-RE for v6ops@ops.ietf.org; Mon, 22 Aug 2005 17:45:26 +0000 X-MIMEOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A741.344B2CB4" Subject: Softwires mailing list Date: Mon, 22 Aug 2005 13:44:53 -0400 Message-ID: <6EEEACD9D7F52940BEE26F5467C02C7301996758@PACDCEXCMB01.cable.comcast.com> Thread-Topic: Softwires mailing list Thread-Index: AcWnQTQGJ4oluvT+R1q5oy89F/OwEQ== From: "Durand, Alain" To: , X-OriginalArrivalTime: 22 Aug 2005 17:44:54.0629 (UTC) FILETIME=[348CE950:01C5A741] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A741.344B2CB4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As a follow-up to the TC bof in Minneapolis and the LRW bof in Paris, we have set-up a mailing list: softwires@ietf.org Hopefully the name will not change, (but we never know... ) once the wg will be ceated by IESG. =20 To subscribe, visit: https://www1.ietf.org/mailman/listinfo/softwires =20 Proposed charter and ML will be posted there shortly. =20 - Alain. ------_=_NextPart_001_01C5A741.344B2CB4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
As a = follow-up to=20 the TC bof in Minneapolis and the LRW bof in Paris, we have set-up a = mailing=20 list:
softwires@ietf.org
Hopefully the name=20 will not change, (but we never know... ) once the wg will be = ceated by=20 IESG.
 
To = subscribe,=20 visit:
https://www1.ie= tf.org/mailman/listinfo/softwires
 
Proposed charter and=20 ML will be posted there shortly.
 
     -=20 Alain.
------_=_NextPart_001_01C5A741.344B2CB4-- From owner-v6ops@ops.ietf.org Mon Aug 22 14:38:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HBS-0003jW-Oq for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 14:38:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03463 for ; Mon, 22 Aug 2005 14:38:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7HAj-000DyQ-Qe for v6ops-data@psg.com; Mon, 22 Aug 2005 18:37:25 +0000 Received: from [131.107.3.123] (helo=mail3.microsoft.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7HAi-000DyC-6i for v6ops@ops.ietf.org; Mon, 22 Aug 2005 18:37:24 +0000 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 11:37:23 -0700 Received: from red-hub-03.redmond.corp.microsoft.com ([157.54.2.25]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 11:37:23 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 11:37:23 -0700 Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.89]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 22 Aug 2005 11:37:11 -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: WGLC ent-analysis-03: DSTM Date: Mon, 22 Aug 2005 11:37:21 -0700 Message-ID: Thread-Topic: WGLC ent-analysis-03: DSTM thread-index: AcWnPE5qIzUctbxnSAe3umTxg4cD9wACrpww From: "Christian Huitema" To: "Francis Dupont" , "Pekka Savola" Cc: X-OriginalArrivalTime: 22 Aug 2005 18:37:11.0241 (UTC) FILETIME=[821DEB90:01C5A748] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > While DHCPv4 may or may not require minor tweaks (e.g., relating to > link-layer adaptation), >=20 > =3D> using DHCPv4 over a tunnel is *not* a minor tweak. Let see. Assume that you have a native IPv6 "site", over which you can reliably send multicast packets. Assume that we have defined IPv6 multicast addresses that reach all the nodes within that scope. Then, you can pretty much port DHCP and ARP over that scope, using the node's IPv6 address instead of the Ethernet address. You obtain a basic "IPv4 over IPv6" solution. It is hard to be simpler than that. Obviously, there are a few tricky issues. We need a payload type for IPv4 (done) and another for ARP (not done). We need a way to properly delineate the scope of the IPv6 "site", probably using an IPv6 prefix that shall be configured on every node. We need to get the multicast addresses registered, and probably registered in a way that attaches them to the selected IPv6 prefix. The design becomes a little bit harder if we cannot use multicast, either because it is not reliable or because it creates too much overhead. But there are solutions -- certainly simpler than doing IPv4 over ATM. -- Christian Huitema From owner-v6ops@ops.ietf.org Mon Aug 22 15:13:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Hjp-0001IG-M8 for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:13: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 PAA05423 for ; Mon, 22 Aug 2005 15:13:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7HiG-000LPe-NI for v6ops-data@psg.com; Mon, 22 Aug 2005 19:12:04 +0000 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7HiB-000LP6-B1 for v6ops@ops.ietf.org; Mon, 22 Aug 2005 19:11:59 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 75AA42000131; Mon, 22 Aug 2005 15:11:55 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 15:11:24 -0400 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: Madated adoption? Date: Mon, 22 Aug 2005 15:11:23 -0400 Message-ID: <936A4045C332714F975800409DE09240D6EEE5@tayexc14.americas.cpqcorp.net> Thread-Topic: Madated adoption? Thread-Index: AcWj8lA6nHW3giJITKu+gKfBNvryPADWuGsA From: "Bound, Jim" To: "Eric Klein" , X-OriginalArrivalTime: 22 Aug 2005 19:11:24.0935 (UTC) FILETIME=[4A36C170:01C5A74D] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable You will see an annoucement I believe in the near future from Australian Defense Organization and more firm posture by NATO. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Eric Klein > Sent: Thursday, August 18, 2005 8:37 AM > To: v6ops@ops.ietf.org > Subject: Re: Madated adoption? >=20 > Thanks Jeff, So far that makes it: >=20 > US - DoD by FY 2008 > US - The rest of Government agencies by June 2008 > China - for Olympics by June 2008 > =20 > and I will keep looking >=20 > ----- Original Message -----=20 > From: "Dunn, Jeffrey" > To: "Eric Klein" ; > Cc: "Dunn, Jeffrey" > Sent: Thursday, August 18, 2005 2:48 PM > Subject: RE: Madated adoption? >=20 >=20 > Eric, >=20 > The U.S. DoD has also "mandated" adoption of IPv6. Please=20 > see the link > listed below: >=20 > http://ipv6.disa.mil/docs/stenbit-ipv6-guidance-20030929.pdf >=20 > Similarly, U.S. Whitehouse Office of Management and Budget has just > recently issued guidance on the adoption of IPv6. Please see the link > listed below: >=20 > http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf >=20 > Best Regards, > Jeffrey Dunn > Systems Test Manager > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > Behalf Of Eric Klein > Sent: Thursday, August 18, 2005 5:26 AM > To: v6ops@ops.ietf.org > Subject: Re: Madated adoption? >=20 > Thanks Jordi this is very helpful. >=20 > Eric > ----- Original Message ----- > From: "JORDI PALET MARTINEZ" > To: > Sent: Thursday, August 18, 2005 12:10 PM > Subject: Re: Madated adoption? >=20 >=20 > > Hi, > > > > I try to keep all this info at http://www.ipv6tf.org, but=20 > not sure if > this > > is as much updated as I wish. > > > > My feeling is that only Japan has a clear "mandate" as a government > decision > > right now. > > > > But there are several related documents for other=20 > governmental bodies > such > > as: > > http://www.ipv6tf.org/meet/policy_recommendations.php > > > > If anyone can point out some other documents, I will link them also, > to > have > > a more complete picture. For example, I just realized that=20 > I'm missing > links > > to Japanese, Korean and Chinese documents, at least. I=20 > recall there is > also > > something from German MoD and Switzerland. > > > > Also it could be interesting: > > http://www.ipv6tf.org/news/newsroom.php?id=3D684 > > > > One of the conclusions is that most of the countries, at least in > Europe, > > have concrete government support, but not concrete "mandated" dates, > most > of > > the time are suggestions and not widely publicized. Anyway, those > > suggestions are already achieving results. In Spain most of=20 > the public > > tenders ask for IPv6 support since already 3-4 years ago, but is not > being > > enabled by default by now in most cases (I believe this=20 > will change in > the > > next few months). This usually means that the ISPs and=20 > vendors have to > > support IPv6 and clearly, is not smart to have different=20 > product lines > (or > > networks) for government business and other customers. For example, > the > > recommendation in 2001 from the Ministry of Public Administration > (MAP) > was > > to purchase everything with IPv6 support on it, so it can be enabled > when > > required, also all the acquisitions done by the main Internet and > > Information Society entity, as well as all the ministries that I'm > aware > of, > > are following this. > > > > I'm not sure a mandate is required, let's say as a=20 > "country" decision. > I > > mean, is enough if the government mandates its usage in their own > > acquisitions. As said, this is good catalyst for the=20 > vendors decide if > they > > want to have two product lines, with and without IPv6 and > interoperability > > problems between both, or whatever. > > > > Regards, > > Jordi > > > > > > > > > > > De: Eric Klein > > > Responder a: > > > Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > > > Para: "v6ops@ops.ietf.org" > > > Asunto: Madated adoption? > > > > > > Based on my memory (and comments about I-D > > > ACTION:draft-baker-v6ops-end2end-00.txt ) > > > > > > > > > Tim Chown seemed surprised that I had heard that there was a > mandated > > > adoption date for the UK (UK by 2008, Japan by 2010 etc=20 > - not sure > about > > > years for either). > > > > > > Now this WG had a conversation thread a little over a=20 > year ago where > these > > > came up. > > > > > > I was wondering if anyone knew if their (or other) countries had > announced > > > compliance dates for the full IPv6 conversions. > > > > > > The truth is that this has dual interest to me, as we as=20 > a WG should > know > > > what the world (or at least individual nations) are doing=20 > or saying > about > > > IPv6. But this is also related to a thesis that I am=20 > working on and > I am > > > interested to see what is being done towards actual=20 > adoption at the > national > > > levels. > > > > > > Eric > > > > > > > > > > > > > > > > ************************************ > > 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. > > > > > > > > > > >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 22 15:17:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Hn2-00025S-UW for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:17: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 PAA05718 for ; Mon, 22 Aug 2005 15:16:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Hml-000MMo-IZ for v6ops-data@psg.com; Mon, 22 Aug 2005 19:16:43 +0000 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7Hmh-000MFR-50 for v6ops@ops.ietf.org; Mon, 22 Aug 2005 19:16:39 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 7FACB2000128; Mon, 22 Aug 2005 15:16:38 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 15:16:26 -0400 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: Madated adoption? Date: Mon, 22 Aug 2005 15:16:25 -0400 Message-ID: <936A4045C332714F975800409DE09240D6EEED@tayexc14.americas.cpqcorp.net> Thread-Topic: Madated adoption? Thread-Index: AcWkEtAYcJqEcn6BQ7eibdrqZI6o2gDOr6ng From: "Bound, Jim" To: "Elwyn Davies" , "Eric Klein" Cc: X-OriginalArrivalTime: 22 Aug 2005 19:16:26.0916 (UTC) FILETIME=[FE356640:01C5A74D] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Saying Dr. Wells is rowing back is not the way I see it. Also recall the statements in the actual mandates is "ipv6 capable". Some programs will move faster than others and the original memo of 2003 called for specific areas within the DOD and to my knowledge all of those targets are on track for IPv6 deployment and some of them as IPv6 Dominant. =20 What is causing more concern is the fact that most all vendors have shipped IPv6 and its base to the product, before anyone turns on IPv6 they must be sure about the security issues as pointed out in the GAO report referenced in the below URL. /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Elwyn Davies > Sent: Thursday, August 18, 2005 12:33 PM > To: Eric Klein > Cc: v6ops@ops.ietf.org > Subject: Re: Madated adoption? >=20 > Just a word of warning on this: The new CIO of DISA Linton Wells has=20 > done a bit of rowing back on the really hard commitment to 2008=20 > originally touted by John Osterholtz. They are still trying for 2008=20 > but may not make it.. see for example: > http://www.gcn.com/vol1_no1/defense-technology/35901-1.html >=20 > Regards, > Elwyn >=20 > Eric Klein wrote: >=20 > >Thanks Jeff, So far that makes it: > > > >US - DoD by FY 2008 > >US - The rest of Government agencies by June 2008 > >China - for Olympics by June 2008 > >=20 > >and I will keep looking > > > >----- Original Message -----=20 > >From: "Dunn, Jeffrey" > >To: "Eric Klein" ; > >Cc: "Dunn, Jeffrey" > >Sent: Thursday, August 18, 2005 2:48 PM > >Subject: RE: Madated adoption? > > > > > >Eric, > > > >The U.S. DoD has also "mandated" adoption of IPv6. Please=20 > see the link > >listed below: > > > >http://ipv6.disa.mil/docs/stenbit-ipv6-guidance-20030929.pdf > > > >Similarly, U.S. Whitehouse Office of Management and Budget has just > >recently issued guidance on the adoption of IPv6. Please=20 > see the link > >listed below: > > > >http://www.whitehouse.gov/omb/memoranda/fy2005/m05-22.pdf > > > >Best Regards, > >Jeffrey Dunn > >Systems Test Manager > >-----Original Message----- > >From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On > >Behalf Of Eric Klein > >Sent: Thursday, August 18, 2005 5:26 AM > >To: v6ops@ops.ietf.org > >Subject: Re: Madated adoption? > > > >Thanks Jordi this is very helpful. > > > >Eric > >----- Original Message ----- > >From: "JORDI PALET MARTINEZ" > >To: > >Sent: Thursday, August 18, 2005 12:10 PM > >Subject: Re: Madated adoption? > > > > > > =20 > > > >>Hi, > >> > >>I try to keep all this info at http://www.ipv6tf.org, but=20 > not sure if > >> =20 > >> > >this > > =20 > > > >>is as much updated as I wish. > >> > >>My feeling is that only Japan has a clear "mandate" as a government > >> =20 > >> > >decision > > =20 > > > >>right now. > >> > >>But there are several related documents for other=20 > governmental bodies > >> =20 > >> > >such > > =20 > > > >>as: > >>http://www.ipv6tf.org/meet/policy_recommendations.php > >> > >>If anyone can point out some other documents, I will link them also, > >> =20 > >> > >to > >have > > =20 > > > >>a more complete picture. For example, I just realized that=20 > I'm missing > >> =20 > >> > >links > > =20 > > > >>to Japanese, Korean and Chinese documents, at least. I=20 > recall there is > >> =20 > >> > >also > > =20 > > > >>something from German MoD and Switzerland. > >> > >>Also it could be interesting: > >>http://www.ipv6tf.org/news/newsroom.php?id=3D684 > >> > >>One of the conclusions is that most of the countries, at least in > >> =20 > >> > >Europe, > > =20 > > > >>have concrete government support, but not concrete "mandated" dates, > >> =20 > >> > >most > >of > > =20 > > > >>the time are suggestions and not widely publicized. Anyway, those > >>suggestions are already achieving results. In Spain most of=20 > the public > >>tenders ask for IPv6 support since already 3-4 years ago, but is not > >> =20 > >> > >being > > =20 > > > >>enabled by default by now in most cases (I believe this=20 > will change in > >> =20 > >> > >the > > =20 > > > >>next few months). This usually means that the ISPs and=20 > vendors have to > >>support IPv6 and clearly, is not smart to have different=20 > product lines > >> =20 > >> > >(or > > =20 > > > >>networks) for government business and other customers. For example, > >> =20 > >> > >the > > =20 > > > >>recommendation in 2001 from the Ministry of Public Administration > >> =20 > >> > >(MAP) > >was > > =20 > > > >>to purchase everything with IPv6 support on it, so it can be enabled > >> =20 > >> > >when > > =20 > > > >>required, also all the acquisitions done by the main Internet and > >>Information Society entity, as well as all the ministries that I'm > >> =20 > >> > >aware > >of, > > =20 > > > >>are following this. > >> > >>I'm not sure a mandate is required, let's say as a=20 > "country" decision. > >> =20 > >> > >I > > =20 > > > >>mean, is enough if the government mandates its usage in their own > >>acquisitions. As said, this is good catalyst for the=20 > vendors decide if > >> =20 > >> > >they > > =20 > > > >>want to have two product lines, with and without IPv6 and > >> =20 > >> > >interoperability > > =20 > > > >>problems between both, or whatever. > >> > >>Regards, > >>Jordi > >> > >> > >> > >> > >> =20 > >> > >>>De: Eric Klein > >>>Responder a: > >>>Fecha: Thu, 18 Aug 2005 11:27:12 +0300 > >>>Para: "v6ops@ops.ietf.org" > >>>Asunto: Madated adoption? > >>> > >>>Based on my memory (and comments about I-D > >>>ACTION:draft-baker-v6ops-end2end-00.txt ) > >>> > >>> > >>>Tim Chown seemed surprised that I had heard that there was a > >>> =20 > >>> > >mandated > > =20 > > > >>>adoption date for the UK (UK by 2008, Japan by 2010 etc - not sure > >>> =20 > >>> > >about > > =20 > > > >>>years for either). > >>> > >>>Now this WG had a conversation thread a little over a year=20 > ago where > >>> =20 > >>> > >these > > =20 > > > >>>came up. > >>> > >>>I was wondering if anyone knew if their (or other) countries had > >>> =20 > >>> > >announced > > =20 > > > >>>compliance dates for the full IPv6 conversions. > >>> > >>>The truth is that this has dual interest to me, as we as a=20 > WG should > >>> =20 > >>> > >know > > =20 > > > >>>what the world (or at least individual nations) are doing or saying > >>> =20 > >>> > >about > > =20 > > > >>>IPv6. But this is also related to a thesis that I am working on and > >>> =20 > >>> > >I am > > =20 > > > >>>interested to see what is being done towards actual adoption at the > >>> =20 > >>> > >national > > =20 > > > >>>levels. > >>> > >>>Eric > >>> > >>> > >>> =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 > >> =20 > >> > >or > >confidential. The information is intended to be for the use of the > >individual(s) named above. If you are not the intended recipient be > >aware > >that any disclosure, copying, distribution or use of the contents of > >this > >information, including attached files, is prohibited. > > =20 > > > >> > >> > >> > >> =20 > >> > > > > > > > > =20 > > >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 22 15:20:35 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7HqV-0002fA-OF for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:20:35 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06157 for ; Mon, 22 Aug 2005 15:20:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7HpX-000Mxb-AH for v6ops-data@psg.com; Mon, 22 Aug 2005 19:19:35 +0000 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7HpS-000Mx6-Gv for v6ops@ops.ietf.org; Mon, 22 Aug 2005 19:19:30 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id C349B2000121; Mon, 22 Aug 2005 15:19:29 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 15:19:29 -0400 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: Review: draft-ietf-v6ops-nap-01.txt Date: Mon, 22 Aug 2005 15:19:28 -0400 Message-ID: <936A4045C332714F975800409DE09240D6EEF3@tayexc14.americas.cpqcorp.net> Thread-Topic: Review: draft-ietf-v6ops-nap-01.txt Thread-Index: AcWklQXIP8Pp5/22T+SvW+0g4OBxrQCuTukA From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 22 Aug 2005 19:19:29.0724 (UTC) FILETIME=[6B2BAFC0:01C5A74E] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable FOlks, favor I really think we deliver NAP to the IESG and to the public. Could all those who find subtle disagreements go offline and come to consensus back to the WG. I think all are in agreement but this spec is very useful to the market can we please ship it. thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > Sent: Friday, August 19, 2005 4:00 AM > To: 'v6ops@ops.ietf.org ' > Subject: Re: Review: draft-ietf-v6ops-nap-01.txt >=20 > On Thu, Aug 18, 2005 at 07:08:44PM +0100, Elwyn Davies wrote: > >=20 > > The comments contain a suggestion that=20 > > draft-chown-port-scanning-implications should be published=20 > as an RFC -=20 > > it is referenced both here (in what I consider to be a=20 > Normative way)=20 > > and it is relevant to the security overview also. Does=20 > anybody else=20 > > support this? >=20 > For info, this can be found here: >=20 > http://www.watersprings.org/pub/id/draft-chown-v6ops-port-scan > ning-implications-01.txt >=20 > It's one of those 'kind of obvious' texts, but has received=20 > good comments > while it was live. >=20 > I would be happy to revive it, or work with=20 > Gunter/Fred/Elwyn/whoever to > merge it into the NAP text itself. There are pros and cons=20 > either way. >=20 > Tim >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 22 15:32:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7I2C-0006BT-Lt for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 15:32: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 PAA07817 for ; Mon, 22 Aug 2005 15:32:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7I1Q-000PYr-UD for v6ops-data@psg.com; Mon, 22 Aug 2005 19:31:52 +0000 Received: from [161.114.80.247] (helo=tayrelbas04.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7I1N-000PYP-0G for v6ops@ops.ietf.org; Mon, 22 Aug 2005 19:31:49 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 069062000090; Mon, 22 Aug 2005 15:31:48 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 22 Aug 2005 15:31:47 -0400 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: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Mon, 22 Aug 2005 15:31:46 -0400 Message-ID: <936A4045C332714F975800409DE09240D6EF00@tayexc14.americas.cpqcorp.net> Thread-Topic: RV: I-D ACTION:draft-baker-v6ops-end2end-00.txt Thread-Index: AcWh4xeiVrX/0ZZAS+y1ZPnbh7liygFbJL1Q From: "Bound, Jim" To: "Fred Baker" , Cc: X-OriginalArrivalTime: 22 Aug 2005 19:31:47.0884 (UTC) FILETIME=[2325F6C0:01C5A750] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I am fine with this spec content and objective. If we have folks use incompatible transition mechanisms that can be a pain. =20 I don't believe IPv6 Dominant networks will cause a problem if there is not IPv4 traffic edge, where there is an IPv4/IPv6 traffic edge like the DSTM Border or a GRE router that must be dual IP capable, which is required for a DSTM border router, so it can be used for dual IP packet types. Suggest adding reference to IPv6 Enterprise Scenarios RFC 4057.=20 thanks /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Fred Baker > Sent: Monday, August 15, 2005 5:47 PM > To: jordi.palet@consulintel.es > Cc: v6ops@ops.ietf.org > Subject: 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 =20 > > is one more scenario, which is the one that we are facing, and =20 > > seems to me the right way to go, actually the natural one, being =20 > > deployed with some of our customers. > > > > ,---. ,---. > > / \ / \ > > / \ / \ > > ; IPv4+6 : ;=20 > IPv4+6 : > > | Network | |=20 > Network | > > : +----+---. ,---. ,---. =20 > ,---+----+ ; > > \ |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+----+--' `---' `---' =20 > `--+----+IPv4+6 : > > | Network | |=20 > Network | > > : ; :=20 > ; > > \ / \ / > > \ / \ / > > `---' `---' > > > > Network A and D are IPv6-only, with GW-A and GW-B taking care of =20 > > the v4-in-v6 tunneling, automatically. >=20 > There are certainly cases in which a consistent transition strategy =20 > is being followed and is working. I think I said something in the =20 > document about granting that the use of a single consistent strategy =20 > that works will probably work :^). >=20 > What I am concerned about is the proliferation of inconsistent =20 > strategies, and the set of cases I can come up with in which they do =20 > not work. That is the issue I am trying to raise. >=20 > > One more comment. I've discovered a lot of confusion in several =20 > > documents regarding 6over4 and 6in4, which is being followed by =20 > > confusing documents from vendors. I think is very important=20 > to make =20 > > a general recommendation, may be not just to this WG, but in =20 > > general to all the IETF documents which mention tunneling, to =20 > > clearly make a distinction between both mechanisms, probably =20 > > avoiding using "over" when actually is referring 6in4 =20 > > encapsulation. Not sure if this should be raised at IESG level or =20 > > whatever. What do you think ? >=20 > What you expect clue? :^) >=20 > Yes, it would be good if people would say clueful things in a=20 > clueful =20 > way. There is probably room for an internet draft on the subject. >=20 >=20 From owner-v6ops@ops.ietf.org Mon Aug 22 21:23:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7NVw-000490-4m for v6ops-archive@megatron.ietf.org; Mon, 22 Aug 2005 21:23: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 VAA09215 for ; Mon, 22 Aug 2005 21:23:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7NSq-000Eu2-Lo for v6ops-data@psg.com; Tue, 23 Aug 2005 01:20:32 +0000 Received: from [203.103.165.110] (helo=smta07.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7NSn-000Etk-UD for v6ops@ops.ietf.org; Tue, 23 Aug 2005 01:20:30 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta07.mail.ozemail.net with ESMTP id <20050823012026.DGMT11916.smta07.mail.ozemail.net@ubu.nosense.org>; Tue, 23 Aug 2005 01:20:26 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id EE6C12F5D7; Tue, 23 Aug 2005 10:50:23 +0930 (CST) Date: Tue, 23 Aug 2005 10:50:23 +0930 From: Mark Smith To: "Templin, Fred L" Cc: v6ops@ops.ietf.org Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Message-Id: <20050823105023.3d1cbd19.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FD6@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FD6@XCH-NW-7V2.nw.nos.boeing.com> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Fred, On Mon, 22 Aug 2005 09:19:00 -0700 "Templin, Fred L" wrote: > Mark, > > Another implementation option which wasn't mentioned is to > designate a tunnel pseudo-interface that acts as a "lid" on > the can-of-worms consisting of all active tunnels configured > on the endpoint. The lid would present a consistent MTU > (e.g., 9180 bytes) to upper layers, e.g., for setting the > TCP MSS, but there may be instances of locally-generated > ICMPv6 "packet too big" messages coming from tunnels inside > the can. I might get you to clarify this a bit further, so I'm sure I'm commenting in the right context. Here is what I understand you're describing : (1) (Probably) Single "parent" tunnel interface on the tunnel-end-point host (2) the parent tunnel interface would be used by the host as the TCP end point, with the MSS value derived from the interface MTU. Normally, the source IPv6 address of the TCP end point would be one of the addresses assigned to this parent tunnel interface. (3) child tunnels are used to manage actual IPv4 tunnel MTUs, and performs fragmentation of the large, assuming the other end also sets MSS to be around 9000 bytes, IPv6 segments into IPv4 path MTU sized IPv4 packets. (4) child tunnels would have to all be from and to the same tunnel end-point, similar to how ATM virtual channels are all part of the same virtual path. I think this would be a requirement because the IPv6 addressing used for the TCP connections would be derived from the parent pseudo-tunnel interface. (5) as a consequence of (4), multiple pseudo tunnel interfaces would have to exist for different sets of tunnel end points. Alternatively, I could see how the pseudo tunnel interface could be used to as the IPv6 MTU / MSS value, yet the source IPv6 address used for TCP connections is the IPv6 address assigned to the child tunnel being used. However, I'd think that would mean modifications to how IPv6 would, by default, pick IPv6 source addresses, as I'd think it would usually select an address from the outgoing interface that the route table has indicated is to be used. If my understanding is correct, then I'd think this parent, psuedo-tunnel interface method could suffer from the "fragmentation considered harmful" issue, i.e., at the IPv6 TCP connection level, the unit of transmission isn't the unit of control. I could be completely confused though :-) > Again, this seems outside the scope of the > specification - do you concur? > I'd agree that how the tunnels are representated within the OS is mostly an implementation detail, although I have had an experience with an IPsec implementation that didn't represent tunnels as virtual interfaces, which caused a number of issues (routing protocol association with the tunnel, applying traffic filtering to traffic before it entered the tunnel - a lot of functions on a router are commonly oriented towards applying the functions to an specified interface). To get around this problem, the vendor recommended solution was to create GRE tunnels and then use IPsec transport mode to the GRE traffic, which is a bit of a kludge. It probably would have been better to have at least a recommendation in the IPsec RFCs as to how to represent the IPsec tunnels within an implementation, similar to the way the IPv6 neighbour discovery RFC describes a conceptual host representation. My original thoughts were that the default, initial tunnel MTU was a protocol constant, making it in the scope of the RFC, and that setting it initially to 1280 bytes would mean that all implementations would use 1280 bytes as the default value. Unfortunately it ends up creating a constraint on the maximum PMTU value possible, at least when the TCP end point is on the same node as the tunnel end-point. Your suggestion in the text to set it higher overcomes that limitation, I was making the suggestion to set it higher to try to optimise for the common case without requiring any further tunnel configuration. Commenting on this from your earlier email : > > Alternatively, the tunnel could optimistically set a larger MTU > > and return locally-generated ICMPv6 "packet too big" messages > > in case it gets ICMPv4 "fragmentation needed" messages back > > from the network. But, this method is susceptible to path > > MTU-related black-holes when the network fails to deliver > > accurate ICMPv4s. When you say "accurate", are you refering to routers sending incorrect link MTU values when they issue an ICMPv4 Fragmentation Required message ? If you are, I personally haven't come across that problem, at least that I'm aware of. Is it common ? The only common problem I'm aware of in this area is misconfigured firewalls blocking incoming these ICMP Fragmentation Required messages, which breaks PMTUD. Thanks, Mark. From owner-v6ops@ops.ietf.org Tue Aug 23 00:45:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7QfH-0003a3-SN for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 00:45: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 AAA29316 for ; Tue, 23 Aug 2005 00:45:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Qc2-0002f7-GQ for v6ops-data@psg.com; Tue, 23 Aug 2005 04:42:14 +0000 Received: from [203.103.165.70] (helo=smta03.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Qc0-0002ek-0Y for v6ops@ops.ietf.org; Tue, 23 Aug 2005 04:42:12 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta03.mail.ozemail.net with ESMTP id <20050823044209.BWMB5688.smta03.mail.ozemail.net@ubu.nosense.org>; Tue, 23 Aug 2005 04:42:09 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id 292D42F5D7; Tue, 23 Aug 2005 14:12:08 +0930 (CST) Date: Tue, 23 Aug 2005 14:12:08 +0930 From: Mark Smith To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-Id: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050819071611.GB30371@login.ecs.soton.ac.uk> References: <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Tim, On Fri, 19 Aug 2005 08:16:11 +0100 Tim Chown wrote: > On Fri, Aug 19, 2005 at 10:05:38AM +0300, Eric Klein wrote: > > > One of the things that worries me about this draft is the suggestion to use > host based routing for topology hiding, or indeed permanent use of MIPv6, > as neither seems particularly attractive just to serve that purpose. > Out of curiosity, are you able to elaborate ? Is it scalability, tunneling overheads, administrative complexity ? I'm interested because I thought of another way the IPv6 topology could be hidden over the weekend, using IPv4, and am interested in any criteria that could be used to judge its value. I'd be interested in yours and other people's opinions of the following method of topology hiding. It was mainly inspired by the way 6to4 works. I'm willing to spend more time on it if it is worth while, I'd prefer to not spend more time on it if it isn't :-) - within the network topology that would be covered by the IPv6 /48, deploy IPv4, using RFC1918 addressing, restricting the IPv4 node addresses to the last 2 octets of the IPv4 address space eg. address the subnets / nodes from out of e.g. 10.0/16. - make sure the 10.0/16 address space is not visible to the Internet ie. don't deploy NAT, no need to even have IPv4 forwarding across the boundary between the Internet and the /48 boundary. - The IPv6 nodes within the /48 would use the last two octets of their IPv4 address as the subnet portion of the IPv6 address ie. the field between /48 to /64. - To obscure the IPv4 topology, the last two octets of the IPv4 address would be encoded using a light weight symmetric cipher. - IPv6 packets travelling within the domain are delivered encapsulated in IPv4. The destination and/or source addresses of IPv4 addresses of these packets is the deciphered value of the IPv6 subnet field, prefixed by the RFC1918 chosen /16 prefix e.g. 10.0/16. This is effectively treating IPv4 operating within the IPv6 /48 domain as a NBMA subnet, encoding the layer 2 addresses in the subnet field of the IPv6 addresses, and then obscuring them such that outside the local IPv6 /48 domain the "layer 2" IPv4 topology and the IPv6 topology is hidden. A normal, global /48 would be used, so it would not be possible to determine on face value if this technique was being used, unlike the 2002::/16 6to4 prefix. Recording IPv6 addresses over a time period could be used to see if the IPv6 "subnets" are random, and although that might indicate this technique was being used, it still doesn't disclose the either the IPv4 and IPv6 topology, as nodes that are adjacent in IPv4 will still have significanly different IPv6 subnet portions, due to the cipher. Privacy addresses can be enabled, and this may also futher enhance the obfuscation. It would appear that multiple hosts are attached to the same subnet, when in reality only one is. Admittedly it would be possible to identify this same host, for example, if some identifyable service is available on it e.g. a web server with a specific web page. However, this possibly isn't a problem anyway, and certainly isn't one that is attempting to be solved by topology hiding. A further enhancement could be to use IKE between the nodes and the edge router(s) and have the light weight cipher key change over time. Then, to external nodes outside the /48, the nodes would also appear to be moving around over time, as the subnet portion would be changing even though the underlying IPv4 address isn't. This solution does restrict the number of IPv6 nodes that can be supported within a /48 to the efficiency of the IPv4 addressing plan. If non-topology hidden IPv6 hosts need to exist, or more IPv6 nodes need to be supported than one IPv4 /16 can support, additional IPv6 /48s could be used. This is probably a drawback, as it would increase the consumption of /48s at a rate above what has been projected by documents such as RFC3177. This certainly isn't a perfect solution, however, it could be an improvement over some of the other techniques mentioned. Any thoughts ? Thanks, Mark. From owner-v6ops@ops.ietf.org Tue Aug 23 02:13:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7S1w-0002yn-Rc for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 02:13: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 CAA14611 for ; Tue, 23 Aug 2005 02:13:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7S0X-00096U-MZ for v6ops-data@psg.com; Tue, 23 Aug 2005 06:11:37 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7S0W-00096G-In for v6ops@ops.ietf.org; Tue, 23 Aug 2005 06:11:37 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7N6AQTb021489; Tue, 23 Aug 2005 08:10:26 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7N6AQ3u015675; Tue, 23 Aug 2005 08:10:26 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7N6AQWu015674; Tue, 23 Aug 2005 08:10:26 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 23 Aug 2005 08:10:26 +0200 From: Stig Venaas To: Mark Smith Cc: Tim Chown , v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-ID: <20050823061026.GA15649@storhaugen.uninett.no> References: <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 23, 2005 at 02:12:08PM +0930, Mark Smith wrote: [...] > This certainly isn't a perfect solution, however, it could be an > improvement over some of the other techniques mentioned. > > Any thoughts ? My thought is basically that it might work, but adds a lot of complexity. As does the other proposed mechanisms. I would not deploy them, but then I never understood why people are so concerned about hiding topology. I guess someone that for some reason think it important might want a solution. I would rather try to understand why people want to hide their topology and hopefully explain why it's not important, rather than presenting solutions adding complexity to the network though... Stig > > Thanks, > Mark. From owner-v6ops@ops.ietf.org Tue Aug 23 03:19:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7T44-0006zk-BG for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 03:19: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 DAA18411 for ; Tue, 23 Aug 2005 03:19:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7T2C-000DaT-6C for v6ops-data@psg.com; Tue, 23 Aug 2005 07:17:24 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7T29-000Da9-Tk for v6ops@ops.ietf.org; Tue, 23 Aug 2005 07:17:22 +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 j7N7HFn17939; Tue, 23 Aug 2005 09:17:15 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp4158.cisco.com [10.61.80.61]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7N7H8p14257; Tue, 23 Aug 2005 09:17:10 +0200 (CEST) Message-Id: <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Aug 2005 09:17:06 +0200 To: Stig Venaas From: "Gunter Van de Velde (gvandeve)" Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Cc: Mark Smith , Tim Chown , v6ops@ops.ietf.org In-Reply-To: <20050823061026.GA15649@storhaugen.uninett.no> References: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 08:10 23/08/2005 +0200, Stig Venaas wrote: >On Tue, Aug 23, 2005 at 02:12:08PM +0930, Mark Smith wrote: >[...] > > This certainly isn't a perfect solution, however, it could be an > > improvement over some of the other techniques mentioned. > > > > Any thoughts ? > >My thought is basically that it might work, but adds a lot of complexity. >As does the other proposed mechanisms. I would not deploy them, but then >I never understood why people are so concerned about hiding topology. I >guess someone that for some reason think it important might want a >solution. I would rather try to understand why people want to hide their >topology and hopefully explain why it's not important, rather than >presenting solutions adding complexity to the network though... I suppose its just the vain feeling/perception of having security by obscurity. Having a hidden topology may make no real difference for a real attack, however it may increase the threshold for the not so expert attackers, while at the same time it provides a comfort feeling to the network administrator that he has one additional (yet virtual) barrier the hacker has to go through. I'm not saying that this is a good thing, however, people are by general behavior consistent in keeping a believe in old habits and convictions. Unfortunatly the industry need for having a tool to provide topology hiding is real.... and is very easy to deploy in the IPv4 world by using address translation, hence the IPv6 community better provides some solution for this and the MIPv6 one seems most appropriate to me at the moment. (The /128 ULA's is a different story) Groetjes, G/ >Stig > > > > > Thanks, > > Mark. From owner-v6ops@ops.ietf.org Tue Aug 23 03:55:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7TdG-0004ir-Jd for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 03:55: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 DAA19865 for ; Tue, 23 Aug 2005 03:55:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7TcO-000FzJ-B9 for v6ops-data@psg.com; Tue, 23 Aug 2005 07:54:48 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7TcM-000Fz1-MJ for v6ops@ops.ietf.org; Tue, 23 Aug 2005 07:54:46 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2005 00:54:46 -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 j7N7shoo003635; Tue, 23 Aug 2005 00:54:44 -0700 (PDT) Received: from [10.11.113.209] (sjc-vpn7-550.cisco.com [10.21.146.38]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7N7optx019071; Tue, 23 Aug 2005 00:50:52 -0700 In-Reply-To: <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> References: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> Cc: Stig Venaas , Mark Smith , Tim Chown , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Tue, 23 Aug 2005 15:54:39 +0800 To: "Gunter Van de Velde (gvandeve)" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=741; t=1124783453; x=1125215653; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Review=3A=20draft-ietf-v6ops-nap-01.txt| From:Fred=20Baker=20| Date:Tue,=2023=20Aug=202005=2015=3A54=3A39=20+0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=DY05fHKnIKJ/C20zaSpA7fOUrQ+ZyrPbZJ9iTvMReN5sZ0jV0wu+tU2UVHViCF/3N2mCiIKv C9OX4f+c8yU6K5mr16iaJD3BaeST+qI/gdFQ9xLHbE9u+ulLRirz5qObmXwlNoTO6Ox+/bXOnwg L7Z4P83h/SokTT30KJ7p2B+I= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote: > Unfortunatly the industry need for having a tool to provide > topology hiding is > real.... and is very easy to deploy in the IPv4 world by using > address translation, hence > the IPv6 community better provides some solution for this and the > MIPv6 > one seems most appropriate to me at the moment. (The /128 ULA's is > a different > story) Compared to having an address space one doesn't advertise outside, mobile ip v6 seems really complex. I'm not fond of ULAs, but as I said in another context, simply having a prefix that is not advertised seems quite sufficient for hiding internal-only systems. And it's only the internal-only systems any of this hides; systems that can be seen from the outside can be seen from the outside, and the fact that they are on the same or different LANs is really window- dressing compared to that. From owner-v6ops@ops.ietf.org Tue Aug 23 04:31:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UCI-0003NN-FL for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 04:31: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 EAA21243 for ; Tue, 23 Aug 2005 04:31:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7UAb-000IpC-U6 for v6ops-data@psg.com; Tue, 23 Aug 2005 08:30:09 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7UAa-000Iop-QM for v6ops@ops.ietf.org; Tue, 23 Aug 2005 08:30:09 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7N8U78M018970 for ; Tue, 23 Aug 2005 09:30:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id JAA09018 for ; Tue, 23 Aug 2005 09:29:40 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7N8TeO15832 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 09:29:40 +0100 Date: Tue, 23 Aug 2005 09:29:40 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-ID: <20050823082940.GK13791@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 23, 2005 at 03:54:39PM +0800, Fred Baker wrote: > > On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote: > > >Unfortunatly the industry need for having a tool to provide > >topology hiding is > >real.... and is very easy to deploy in the IPv4 world by using > >address translation, hence > >the IPv6 community better provides some solution for this and the > >MIPv6 > >one seems most appropriate to me at the moment. (The /128 ULA's is > >a different > >story) > > Compared to having an address space one doesn't advertise outside, > mobile ip v6 seems really complex. I'm not fond of ULAs, but as I > said in another context, simply having a prefix that is not > advertised seems quite sufficient for hiding internal-only systems. > And it's only the internal-only systems any of this hides; systems > that can be seen from the outside can be seen from the outside, and > the fact that they are on the same or different LANs is really window- > dressing compared to that. My view is along those of Stig and Fred. Given how NAP is in itself a 're-education' tool, we could/should use it as an opportunity to highlight what can be done with IPv6. The schemes for topology hiding proposed to date add back a lot of the complexity that IPv6 in principle removes. I really don't agree with the NAP draft's approach on the topology hiding issue, though otherwise I think it's an excellent document. I think some simpler words can be said, and MIPv6 or host routing avoided (or Mark's scheme, sorry :). As an aside, when you say 'topology hiding' Gunter, do you really mean subnet/link topology, or the number of hosts, or...? -- Tim/::1 From owner-v6ops@ops.ietf.org Tue Aug 23 04:57:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UbR-00088e-K6 for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 04:57:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22098 for ; Tue, 23 Aug 2005 04:57:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Uax-000KrQ-CG for v6ops-data@psg.com; Tue, 23 Aug 2005 08:57:23 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Uaw-000Kr7-Dg for v6ops@ops.ietf.org; Tue, 23 Aug 2005 08:57:22 +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 j7N8vLl24234; Tue, 23 Aug 2005 10:57:21 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp4158.cisco.com [10.61.80.61]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7N8vKp05231; Tue, 23 Aug 2005 10:57:20 +0200 (CEST) Message-Id: <4.3.2.7.2.20050823103739.0401c570@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 23 Aug 2005 10:57:18 +0200 To: Tim Chown From: "Gunter Van de Velde (gvandeve)" Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Cc: v6ops@ops.ietf.org In-Reply-To: <20050823082940.GK13791@login.ecs.soton.ac.uk> References: <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >As an aside, when you say 'topology hiding' Gunter, do you really mean >subnet/link topology, or the number of hosts, or...? When i see 'topology hiding' i make a reference that an entity outside the network can not make any correlation between the location of a device and the address of a device on the local network. This is something that can be achieved with MIP without loosing any of the end-to-end aspects. Same for the /128's PI addresses. There could be additional mechanisms, some simple, some more complex. The draft is not to recommend usage of any of these, however it is to inform people that there are possibilities to achieve similar result without address translation. By mentioning that 'topology hiding' is useless, that it makes no sense and is complete brainless nonsense, well in that case many NAT biassed people who sincerely believe in the topology hiding may find IPv6 a 'too risky protocol that does not provide same features and functionality as IPv4 with respect to security' Don't get me wrong.. i do not believe in topology hiding myself, however many people do, and we have to offer alternatives and that is what the document is about. A potential alternate solution is to make a v6ops study on the value of topology hiding when using IPv6? and by that make disarm the motivation to make usage of either MIP, /128 or any other complex mechanisms. Groetjes, G/ At 09:29 23/08/2005 +0100, Tim Chown wrote: >On Tue, Aug 23, 2005 at 03:54:39PM +0800, Fred Baker wrote: > > > > On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote: > > > > >Unfortunatly the industry need for having a tool to provide > > >topology hiding is > > >real.... and is very easy to deploy in the IPv4 world by using > > >address translation, hence > > >the IPv6 community better provides some solution for this and the > > >MIPv6 > > >one seems most appropriate to me at the moment. (The /128 ULA's is > > >a different > > >story) > > > > Compared to having an address space one doesn't advertise outside, > > mobile ip v6 seems really complex. I'm not fond of ULAs, but as I > > said in another context, simply having a prefix that is not > > advertised seems quite sufficient for hiding internal-only systems. > > And it's only the internal-only systems any of this hides; systems > > that can be seen from the outside can be seen from the outside, and > > the fact that they are on the same or different LANs is really window- > > dressing compared to that. > >My view is along those of Stig and Fred. > >Given how NAP is in itself a 're-education' tool, we could/should use it >as an opportunity to highlight what can be done with IPv6. The schemes >for topology hiding proposed to date add back a lot of the complexity that >IPv6 in principle removes. I really don't agree with the NAP draft's >approach on the topology hiding issue, though otherwise I think it's an >excellent document. I think some simpler words can be said, and MIPv6 >or host routing avoided (or Mark's scheme, sorry :). > >As an aside, when you say 'topology hiding' Gunter, do you really mean >subnet/link topology, or the number of hosts, or...? > >-- >Tim/::1 From owner-v6ops@ops.ietf.org Tue Aug 23 05:13:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7UqT-0002oQ-M8 for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 05:13:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22643 for ; Tue, 23 Aug 2005 05:13:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Upy-000MLB-82 for v6ops-data@psg.com; Tue, 23 Aug 2005 09:12:54 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Upw-000MKy-KY for v6ops@ops.ietf.org; Tue, 23 Aug 2005 09:12:52 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7N9CpnD021184 for ; Tue, 23 Aug 2005 10:12:51 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA13162 for ; Tue, 23 Aug 2005 10:12:23 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7N9CNP17139 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 10:12:23 +0100 Date: Tue, 23 Aug 2005 10:12:23 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-ID: <20050823091223.GR13791@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> <4.3.2.7.2.20050823103739.0401c570@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4.3.2.7.2.20050823103739.0401c570@strange-brew> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Aug 23, 2005 at 10:57:18AM +0200, Gunter Van de Velde (gvandeve) wrote: > > >As an aside, when you say 'topology hiding' Gunter, do you really mean > >subnet/link topology, or the number of hosts, or...? > > When i see 'topology hiding' i make a reference that an entity outside > the network can not make any correlation between the location > of a device and the address of a device on the local network. OK. Maybe add that sentence to the draft. Start of section 2.4, add after first sentence. > This is something that can be achieved with MIP without loosing > any of the end-to-end aspects. Same for the /128's PI addresses. > There could be additional mechanisms, some simple, some more complex. And at additional costs, e.g. MIPv6 some would argue breaks 'end to end' in that you rely on a middlebox to establish communication. > The draft is not to recommend usage of any of these, however it is to > inform people that there are possibilities to achieve similar result > without address translation. To me, the table in section 1 suggests that host routes and MIPv6 are the norm for an IPv6 network. The only reason you cite in the text for topology hiding is in section 2: "NAT of course entirely hides the internal subnet topology, which some network managers believe is a useful precaution to mitigate scanning attacks." But the pure size of the address space deters 'random' port scanning anyway. Then again in section 4: "What one does when topology probing is to get an idea of the available hosts inside an enterprise. This mostly starts with a ping-sweep." which suggests topology hiding is all about available/reachable hosts. That should be mitigated by edge firewalls or the v6 link address space size. I don't see any other discussion of topology hiding beyond that one issue. > By mentioning that 'topology hiding' is > useless, that it makes no sense and is complete brainless nonsense, well > in that case many NAT biassed people who sincerely believe in > the topology hiding may find IPv6 a 'too risky protocol that does not > provide same features and functionality as IPv4 with respect to security' Well that is their loss, but my vote is that we don't bend the text in favour of such preconceptions, unless we hear some technically sound reasons to do so. > Don't get me wrong.. i do not believe in topology hiding myself, however > many people do, and we have to offer alternatives and that is what the > document is about. A potential alternate solution is to make a v6ops > study on the value of topology hiding when using IPv6? and by that make > disarm the motivation to make usage of either MIP, /128 or any other complex > mechanisms. But at present NAP says 'topology hiding' = 'host hiding' = 'port scanning resilience via firewalls or link address size'. I don't want to do MIPv6 or host routing for that. Tim From owner-v6ops@ops.ietf.org Tue Aug 23 06:49:02 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7WKz-0004I9-SN for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 06:49: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 GAA25765 for ; Tue, 23 Aug 2005 06:48:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7WJL-0002sQ-3q for v6ops-data@psg.com; Tue, 23 Aug 2005 10:47:19 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7WJI-0002sA-W6 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 10:47:17 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7NAlCQ24922; Tue, 23 Aug 2005 13:47:12 +0300 Date: Tue, 23 Aug 2005 13:47:12 +0300 (EEST) From: Pekka Savola To: Christian Huitema cc: Francis Dupont , v6ops@ops.ietf.org Subject: Issues of DHCPv4 over v4-in-v6 tunnel [RE: WGLC ent-analysis-03: DSTM] In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I've changed the subject line, as a placeholder for future discussions.. On Mon, 22 Aug 2005, Christian Huitema wrote: >> While DHCPv4 may or may not require minor tweaks (e.g., relating to >> link-layer adaptation), >> >> => using DHCPv4 over a tunnel is *not* a minor tweak. [...] > The design becomes a little bit harder if we cannot use multicast, > either because it is not reliable or because it creates too much > overhead. But there are solutions -- certainly simpler than doing IPv4 > over ATM. Well, we could have the same assumptions as DHCPv6 -- either multicast, or relays (certainly not just multicast). But can't we just make the assumptions: 1) the tunnel is point-to-point, so neither side performs ARP (so we may not need to define ARP), just throws the packets over. 2) DHCPv4 server must reside at the tunnel end-point. Isn't it then pretty much irrelevant which L2 addresses are used by the client (in the payload) as long as they're a good identifier in the DHCP server's database? Note that I don't see modifications to DHCPv4 client or server software as a problem (but hopefully the changes should be minimized), because those sites wanting to deploy v6 dominant networks require lots of software updates in any case. Maybe this discussion should go over at DHC WG, though. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 23 08:23:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7Xon-0000Vo-8V for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 08:23:53 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00769 for ; Tue, 23 Aug 2005 08:23:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7Xmv-000AL6-Vd for v6ops-data@psg.com; Tue, 23 Aug 2005 12:21:57 +0000 Received: from [203.103.165.110] (helo=smta07.mail.ozemail.net) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7Xmt-000AKj-S4 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 12:21:56 +0000 Received: from ubu.nosense.org ([210.84.233.205]) by smta07.mail.ozemail.net with ESMTP id <20050823122152.IKAL11916.smta07.mail.ozemail.net@ubu.nosense.org>; Tue, 23 Aug 2005 12:21:52 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by ubu.nosense.org (Postfix) with SMTP id D67C22F5D7; Tue, 23 Aug 2005 21:51:46 +0930 (CST) Date: Tue, 23 Aug 2005 21:51:46 +0930 From: Mark Smith To: Tim Chown Cc: v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Message-Id: <20050823215146.4b2ab130.ipng@69706e6720323030352d30312d31340a.nosense.org> In-Reply-To: <20050823082940.GK13791@login.ecs.soton.ac.uk> References: <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <000e01c5a467$9afa7860$56646e0a@china.huawei.com> <00bd01c5a48c$6e67cbc0$0401a8c0@mtc.ki.se> <20050819071611.GB30371@login.ecs.soton.ac.uk> <20050823141208.1b1d28d3.ipng@69706e6720323030352d30312d31340a.nosense.org> <4.3.2.7.2.20050823085900.03e3cd40@strange-brew> <249C8381-0EA6-45DF-A084-36CE150B4B09@cisco.com> <20050823082940.GK13791@login.ecs.soton.ac.uk> X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Tue, 23 Aug 2005 09:29:40 +0100 Tim Chown wrote: > On Tue, Aug 23, 2005 at 03:54:39PM +0800, Fred Baker wrote: > > > > On Aug 23, 2005, at 3:17 PM, Gunter Van de Velde (gvandeve) wrote: > > > > >Unfortunatly the industry need for having a tool to provide > > >topology hiding is > > >real.... and is very easy to deploy in the IPv4 world by using > > >address translation, hence > > >the IPv6 community better provides some solution for this and the > > >MIPv6 > > >one seems most appropriate to me at the moment. (The /128 ULA's is > > >a different > > >story) > > > > Compared to having an address space one doesn't advertise outside, > > mobile ip v6 seems really complex. I'm not fond of ULAs, but as I > > said in another context, simply having a prefix that is not > > advertised seems quite sufficient for hiding internal-only systems. > > And it's only the internal-only systems any of this hides; systems > > that can be seen from the outside can be seen from the outside, and > > the fact that they are on the same or different LANs is really window- > > dressing compared to that. > > My view is along those of Stig and Fred. > So is mine :-) I don't see much value it in it really either, I was starting from the assumption that if somebody chose to do it, could the be a possibly be another simpler or better solution. > Given how NAP is in itself a 're-education' tool, we could/should use it > as an opportunity to highlight what can be done with IPv6. The schemes > for topology hiding proposed to date add back a lot of the complexity that > IPv6 in principle removes. I really don't agree with the NAP draft's > approach on the topology hiding issue, though otherwise I think it's an > excellent document. I think some simpler words can be said, and MIPv6 > or host routing avoided (or Mark's scheme, sorry :). > One possibly big problem with my scheme, host routing or MIP is that I think they all tend to give the IPv6 domain NBMA like characteristics, meaning that multicasts probably have to be distributed via replicated unicasts. Possibly in my scheme that could be solved by multicast enabling the IPv4 "layer 2", and use that to distribute IPv6 multicasts encapsulated in IPv4 multicast. I don't really know enough about MIP to know exactly how multicasts are handled for that. The host routing option might not have an alternative solution other than replicated unicasts. The other issue is that they all tend to introduce ambiguity into the link multicast scope. As all the nodes are members of a single NBMA like domain, does a link scoped multicast get sent to all of them, possibly via unicast replication ? If not, where does a link scoped multicast get sent to ? Does this mean that link and site scopes are now equal ? I think that if the current topology hiding methods stay in the draft then these multicast issues should also be mentioned in it. I'm really starting to also agree that maybe it would be better to identify the properties that the "toplogy hiding" nature the NAPT provides, and both show they don't have much or any value or how other IPv6 mechanisms can meet those features without having to rely on hiding the toplogy from external entities (e.g., the lack of easy ping scanning ability preventing hosts being found even if the subnet is known, packet filtering to prevent traffic being sent to a subnet's router anycast address.). Regards, Mark. From owner-v6ops@ops.ietf.org Tue Aug 23 09:59:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZJX-0004M1-KA for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 09:59: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 JAA05291 for ; Tue, 23 Aug 2005 09:59:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7ZHO-000HcX-2U for v6ops-data@psg.com; Tue, 23 Aug 2005 13:57:30 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7ZHM-000Hc5-43 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 13:57:28 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 23 Aug 2005 06:57:26 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208"; a="334855646:sNHT2709483466" 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 j7NDvN2i026601; Tue, 23 Aug 2005 06:57:24 -0700 (PDT) Received: from [10.11.113.209] (sjc-vpn7-550.cisco.com [10.21.146.38]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7NDrPoP021336; Tue, 23 Aug 2005 06:53:28 -0700 In-Reply-To: <000001c5a7c1$2c100020$56646e0a@china.huawei.com> References: <000001c5a7c1$2c100020$56646e0a@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v734) X-Priority: 3 (Normal) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0A7A4FAB-F105-4B95-88D6-453CE94C77CE@cisco.com> Cc: "'Eric Klein'" , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Tue, 23 Aug 2005 21:57:14 +0800 To: chenhongfei X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=2745; t=1124805212; x=1125237412; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Review=3A=20draft-ietf-v6ops-nap-01.txt| From:Fred=20Baker=20| Date:Tue,=2023=20Aug=202005=2021=3A57=3A14=20+0800| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=cB6V92JiXRiJnB+TxKVXe5zG4S5cz8pUDMoiZFYWNk+ogLKQg6F7ulUWLtzw2qziszkeCq2X wg8npcn276B8TU81ZR1TVnASGGm/WPtZDao2cJAmYdAhsukL9Id0J9MS9+bfm3wJPL6MlBpV7Je 5Cd/7kOoOgqbdF1l1BXZaSJw= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit If the objective is to not have people on the outside know of the existence or exact value of an address, or be able to attack it by sending traffic to it, then a system that sends packets outside the net would need to change addresses periodically, but a system that doesn't send packets outside the network merely needs to be protected from accidental uses of its address. On Aug 23, 2005, at 5:00 PM, chenhongfei wrote: > I don't confirm I understand your email completely. > I agree with you that internal servers are a great reason (and > perhaps the only real reason) for having some form of stays-inside- > the-site address. Do you mean that the internal servers needn't to > periodically change the address? > > > > Best regards > Hongfei Chen > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Monday, August 22, 2005 5:37 PM > To: chenhongfei > Cc: 'Eric Klein'; v6ops@ops.ietf.org > Subject: Re: Review: draft-ietf-v6ops-nap-01.txt > > one might wonder why one is concerned about a server's address being > known in the network... > > On Aug 22, 2005, at 3:05 PM, chenhongfei wrote: > >> It's a good solution to periodically change the address. But if a >> server(for example DNS server) periodically change the address, The >> services should be interrupt. How to solve this issue? >> > > Any company has a set of systems that are entirely internal. Common > ones at Cisco are either labs, or have names that start in "wwwin", > like wwwin.cisco.com and wwwin-people.cisco.com. You can translate > those names into addresses outside Cisco, but our firewalls prevent > external traffic from reaching them. > > From my perspective, such internal servers are a great reason (and > perhaps the only real reason) for having some form of stays-inside- > the-site address. In a global address space, there are two things one > should do for inside-only systems (servers, clients, or p2p systems): > place the system in an address space that is not advertised in > routing, and prevent DNS requests from outside the company from > translating the name. If the firewall router cannot route to the > address, that's a pretty cheap filter, and if the address is not sent > outside, one won't be exercising the filter very often. > > ULAs are supposed to be a stays-inside-the-site address. Something > that works just as well is a prefix or set of prefixes taken from the > site's global space that are administratively prevented from being > advertised to the DMZ routers. Outside, they advertise the site's > prefix as a /48. Inside, they have routing to individual campuses or > LANs within the site, and they don't have the LANs the internal-only > servers are on. No packet will ever cross that DMZ to those internal- > only servers. > > Notice how these are more effective filters than NAT provides (if > there is a correlated address, the system is reachable by attacking > the correlated address), and are very cheap (you don't even have to > configure an ACL or stateful firewall rule in the data path; the > filter falls out from not having a route). It also has an interesting > effect if the system is infected with some virus or etc that makes it > phone home for instructions: the reply is effectively prevented from > being sent, especially if there is an ingress filter on the ISP end. > From owner-v6ops@ops.ietf.org Tue Aug 23 10:04:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7ZOT-0005VG-Px for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 10:04: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 KAA05720 for ; Tue, 23 Aug 2005 10:04:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7ZOC-000IMH-2H for v6ops-data@psg.com; Tue, 23 Aug 2005 14:04:32 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7ZOB-000ILv-3a for v6ops@ops.ietf.org; Tue, 23 Aug 2005 14:04:31 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-1.cisco.com with ESMTP; 23 Aug 2005 07:04:31 -0700 X-IronPort-AV: i="3.96,135,1122879600"; d="scan'208,217"; a="656214361:sNHT45573512" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j7NE4236028649; Tue, 23 Aug 2005 07:04:28 -0700 (PDT) Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 23 Aug 2005 10:04:21 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5A7EB.8F0957D9" Subject: RE: Review: draft-ietf-v6ops-nap-01.txt Date: Tue, 23 Aug 2005 10:02:47 -0400 Message-ID: <6F66F4F04858B945B836804F0F2AE6BB2C8A72@xmb-rtp-211.amer.cisco.com> Thread-Topic: Review: draft-ietf-v6ops-nap-01.txt Thread-Index: AcWn6xVS3xSgthr8S/mmmIs8/9G8VwAAEJD7 From: "Ralph Droms \(rdroms\)" To: "Fred Baker \(fred\)" , "chenhongfei" Cc: "Eric Klein" , X-OriginalArrivalTime: 23 Aug 2005 14:04:21.0267 (UTC) FILETIME=[8F43DE30:01C5A7EB] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,HTML_10_20, HTML_MESSAGE autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C5A7EB.8F0957D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Is there also the requirement that the address of one device that sends = packets to the outside not give clues about other addresses that might = be in use or the network topology on the inside? - Ralph -----Original Message----- From: owner-v6ops@ops.ietf.org on behalf of Fred Baker (fred) Sent: Tue 8/23/2005 9:57 AM To: chenhongfei Cc: 'Eric Klein'; v6ops@ops.ietf.org Subject: Re: Review: draft-ietf-v6ops-nap-01.txt =20 If the objective is to not have people on the outside know of the =20 existence or exact value of an address, or be able to attack it by =20 sending traffic to it, then a system that sends packets outside the =20 net would need to change addresses periodically, but a system that =20 doesn't send packets outside the network merely needs to be protected =20 from accidental uses of its address. On Aug 23, 2005, at 5:00 PM, chenhongfei wrote: > I don't confirm I understand your email completely. > I agree with you that internal servers are a great reason (and > perhaps the only real reason) for having some form of stays-inside- > the-site address. Do you mean that the internal servers needn't to > periodically change the address? > > > > Best regards > Hongfei Chen > > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com] > Sent: Monday, August 22, 2005 5:37 PM > To: chenhongfei > Cc: 'Eric Klein'; v6ops@ops.ietf.org > Subject: Re: Review: draft-ietf-v6ops-nap-01.txt > > one might wonder why one is concerned about a server's address being > known in the network... > > On Aug 22, 2005, at 3:05 PM, chenhongfei wrote: > >> It's a good solution to periodically change the address. But if a >> server(for example DNS server) periodically change the address, The >> services should be interrupt. How to solve this issue? >> > > Any company has a set of systems that are entirely internal. Common > ones at Cisco are either labs, or have names that start in "wwwin", > like wwwin.cisco.com and wwwin-people.cisco.com. You can translate > those names into addresses outside Cisco, but our firewalls prevent > external traffic from reaching them. > > From my perspective, such internal servers are a great reason (and > perhaps the only real reason) for having some form of stays-inside- > the-site address. In a global address space, there are two things one > should do for inside-only systems (servers, clients, or p2p systems): > place the system in an address space that is not advertised in > routing, and prevent DNS requests from outside the company from > translating the name. If the firewall router cannot route to the > address, that's a pretty cheap filter, and if the address is not sent > outside, one won't be exercising the filter very often. > > ULAs are supposed to be a stays-inside-the-site address. Something > that works just as well is a prefix or set of prefixes taken from the > site's global space that are administratively prevented from being > advertised to the DMZ routers. Outside, they advertise the site's > prefix as a /48. Inside, they have routing to individual campuses or > LANs within the site, and they don't have the LANs the internal-only > servers are on. No packet will ever cross that DMZ to those internal- > only servers. > > Notice how these are more effective filters than NAT provides (if > there is a correlated address, the system is reachable by attacking > the correlated address), and are very cheap (you don't even have to > configure an ACL or stateful firewall rule in the data path; the > filter falls out from not having a route). It also has an interesting > effect if the system is infected with some virus or etc that makes it > phone home for instructions: the reply is effectively prevented from > being sent, especially if there is an ingress filter on the ISP end. > ------_=_NextPart_001_01C5A7EB.8F0957D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Review: draft-ietf-v6ops-nap-01.txt

Is there also the requirement that the address of one = device that sends packets to the outside not give clues about other = addresses that might be in use or the network topology on the = inside?

- Ralph

-----Original Message-----
From: owner-v6ops@ops.ietf.org on behalf of Fred Baker (fred)
Sent: Tue 8/23/2005 9:57 AM
To: chenhongfei
Cc: 'Eric Klein'; v6ops@ops.ietf.org
Subject: Re: Review: draft-ietf-v6ops-nap-01.txt

If the objective is to not have people on the outside know of = the 
existence or exact value of an address, or be able to attack it = by 
sending traffic to it, then a system that sends packets outside = the 
net would need to change addresses periodically, but a system = that 
doesn't send packets outside the network merely needs to be = protected 
from accidental uses of its address.


On Aug 23, 2005, at 5:00 PM, chenhongfei wrote:

> I don't confirm I understand your email completely.
> I agree with you that internal servers are a great reason (and
> perhaps the only real reason) for having some form of = stays-inside-
> the-site address. Do you mean that the internal servers needn't = to
> periodically change the address?
>
>
>
> Best regards
> Hongfei Chen
>
> -----Original Message-----
> From: Fred Baker [mailto:fred@cisco.com]
> Sent: Monday, August 22, 2005 5:37 PM
> To: chenhongfei
> Cc: 'Eric Klein'; v6ops@ops.ietf.org
> Subject: Re: Review: draft-ietf-v6ops-nap-01.txt
>
> one might wonder why one is concerned about a server's address = being
> known in the network...
>
> On Aug 22, 2005, at 3:05 PM, chenhongfei wrote:
>
>> It's a good solution to periodically change the address. But if = a
>> server(for example DNS server) periodically change the address, = The
>> services should be interrupt. How to solve this issue?
>>
>
> Any company has a set of systems that are entirely internal. = Common
> ones at Cisco are either labs, or have names that start in = "wwwin",
> like wwwin.cisco.com and wwwin-people.cisco.com. You can = translate
> those names into addresses outside Cisco, but our firewalls = prevent
> external traffic from reaching them.
>
>  From my perspective, such internal servers are a great reason = (and
> perhaps the only real reason) for having some form of = stays-inside-
> the-site address. In a global address space, there are two things = one
> should do for inside-only systems (servers, clients, or p2p = systems):
> place the system in an address space that is not advertised in
> routing, and prevent DNS requests from outside the company from
> translating the name. If the firewall router cannot route to = the
> address, that's a pretty cheap filter, and if the address is not = sent
> outside, one won't be exercising the filter very often.
>
> ULAs are supposed to be a stays-inside-the-site address. = Something
> that works just as well is a prefix or set of prefixes taken from = the
> site's global space that are administratively prevented from = being
> advertised to the DMZ routers. Outside, they advertise the = site's
> prefix as a /48. Inside, they have routing to individual campuses = or
> LANs within the site, and they don't have the LANs the = internal-only
> servers are on. No packet will ever cross that DMZ to those = internal-
> only servers.
>
> Notice how these are more effective filters than NAT provides = (if
> there is a correlated address, the system is reachable by = attacking
> the correlated address), and are very cheap (you don't even have = to
> configure an ACL or stateful firewall rule in the data path; = the
> filter falls out from not having a route). It also has an = interesting
> effect if the system is infected with some virus or etc that makes = it
> phone home for instructions: the reply is effectively prevented = from
> being sent, especially if there is an ingress filter on the ISP = end.
>

------_=_NextPart_001_01C5A7EB.8F0957D9-- From owner-v6ops@ops.ietf.org Tue Aug 23 12:12:55 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bOR-0006ja-4k for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:12: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 MAA12663 for ; Tue, 23 Aug 2005 12:12:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7bMH-0002YL-36 for v6ops-data@psg.com; Tue, 23 Aug 2005 16:10:41 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7bME-0002Y6-Pa for v6ops@ops.ietf.org; Tue, 23 Aug 2005 16:10:38 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id JAA27767; Tue, 23 Aug 2005 09:10:14 -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 j7NGARv20528; Tue, 23 Aug 2005 11:10:27 -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.211); Tue, 23 Aug 2005 09:10:25 -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: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Date: Tue, 23 Aug 2005 09:10:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FDD@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" Thread-Index: AcWngNpX0VUJuMdzTcWNTF7fZZW+IAAda7OA From: "Templin, Fred L" To: "Mark Smith" Cc: X-OriginalArrivalTime: 23 Aug 2005 16:10:25.0676 (UTC) FILETIME=[2C0114C0:01C5A7FD] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Mark, Thanks for the follow-up; see responses inline below:=20 > -----Original Message----- > From: Mark Smith=20 > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org]=20 > Sent: Monday, August 22, 2005 6:20 PM > To: Templin, Fred L > Cc: v6ops@ops.ietf.org > Subject: Re: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" >=20 > Hi Fred, >=20 > On Mon, 22 Aug 2005 09:19:00 -0700 > "Templin, Fred L" wrote: >=20 > > Mark, > >=20 > > Another implementation option which wasn't mentioned is to > > designate a tunnel pseudo-interface that acts as a "lid" on > > the can-of-worms consisting of all active tunnels configured > > on the endpoint. The lid would present a consistent MTU > > (e.g., 9180 bytes) to upper layers, e.g., for setting the > > TCP MSS, but there may be instances of locally-generated > > ICMPv6 "packet too big" messages coming from tunnels inside > > the can. >=20 > I might get you to clarify this a bit further, so I'm sure I'm > commenting in the right context. Here is what I understand you're > describing : >=20 > (1) (Probably) Single "parent" tunnel interface on the=20 > tunnel-end-point > host >=20 > (2) the parent tunnel interface would be used by the host as the > TCP end point, with the MSS value derived from the interface MTU. > Normally, the source IPv6 address of the TCP end point would=20 > be one of the > addresses assigned to this parent tunnel interface. >=20 > (3) child tunnels are used to manage actual IPv4 tunnel MTUs, and > performs fragmentation of the large, assuming the other end also sets > MSS to be around 9000 bytes, IPv6 segments into IPv4 path MTU=20 > sized IPv4 > packets. Yes to all of the above. =20 > (4) child tunnels would have to all be from and to the same tunnel > end-point, similar to how ATM virtual channels are all part=20 > of the same > virtual path. I think this would be a requirement because the IPv6 > addressing used for the TCP connections would be derived from=20 > the parent > pseudo-tunnel interface. >=20 > (5) as a consequence of (4), multiple pseudo tunnel interfaces would > have to exist for different sets of tunnel end points. Not necessarily on points (4) and (5); I was thinking of having all of the "worms" in a single "can". =20 > Alternatively, I could see how the pseudo tunnel interface=20 > could be used > to as the IPv6 MTU / MSS value, yet the source IPv6 address=20 > used for TCP > connections is the IPv6 address assigned to the child tunnel=20 > being used. > However, I'd think that would mean modifications to how IPv6 would, by > default, pick IPv6 source addresses, as I'd think it would usually > select an address from the outgoing interface that the route table has > indicated is to be used. I was thinking multiple IPv6 addresses per node and the addresses serving more as application endpoint identifiers rather than node identifiers. I haven't looked to see how well this view is supported under existing OS's. =20 > If my understanding is correct, then I'd think this parent, > psuedo-tunnel interface method could suffer from the "fragmentation > considered harmful" issue, i.e., at the IPv6 TCP connection level, the > unit of transmission isn't the unit of control. Independent of whether the pseudo-interface method is used, route changes can certainly occur after a tunnel's IPv4 segment size has been determined which could result in ICMPv4 "fragmentation needed" messages that indicate the loss of a segment smaller than the TCP unit of transmission. The originating tunnel endpoint can then either re-segment and retransmit the IPv6 packet or return an ICMPv6 "packet too big" message back to the original source. But, that would entail caching original IPv6 packets at the encapsulator for up to the tunnel's RTT which could be difficult for large bandwidth*delay tunnels. Another alternative is for the encapsulator to probe the IPv4 segment size periodically in a proactive "black hole detection" sort of posture. The frequency for probing could be based on the arrival of ICMPv4s, which may/may not be accurate (see below). =20 =20 > I could be completely confused though :-) >=20 > > Again, this seems outside the scope of the > > specification - do you concur? > > >=20 > I'd agree that how the tunnels are representated within the=20 > OS is mostly > an implementation detail, although I have had an experience with an > IPsec implementation that didn't represent tunnels as virtual > interfaces, which caused a number of issues (routing protocol > association with the tunnel, applying traffic filtering to traffic > before it entered the tunnel - a lot of functions on a router are > commonly oriented towards applying the functions to an specified > interface). To get around this problem, the vendor=20 > recommended solution > was to create GRE tunnels and then use IPsec transport mode to the GRE > traffic, which is a bit of a kludge. It probably would have=20 > been better > to have at least a recommendation in the IPsec RFCs as to how to > represent the IPsec tunnels within an implementation, similar=20 > to the way > the IPv6 neighbour discovery RFC describes a conceptual host > representation. >=20 > My original thoughts were that the default, initial tunnel MTU was a > protocol constant, making it in the scope of the RFC, and that setting > it initially to 1280 bytes would mean that all=20 > implementations would use > 1280 bytes as the default value. Unfortunately it ends up creating a > constraint on the maximum PMTU value possible, at least when=20 > the TCP end > point is on the same node as the tunnel end-point.=20 >=20 > Your suggestion in the text to set it higher overcomes that=20 > limitation, > I was making the suggestion to set it higher to try to=20 > optimise for the > common case without requiring any further tunnel configuration. >=20 > Commenting on this from your earlier email : >=20 > > > Alternatively, the tunnel could optimistically set a larger MTU > > > and return locally-generated ICMPv6 "packet too big" messages > > > in case it gets ICMPv4 "fragmentation needed" messages back > > > from the network. But, this method is susceptible to path > > > MTU-related black-holes when the network fails to deliver > > > accurate ICMPv4s. >=20 > When you say "accurate", are you refering to routers sending incorrect > link MTU values when they issue an ICMPv4 Fragmentation=20 > Required message > ? If you are, I personally haven't come across that problem, at least > that I'm aware of. Is it common ? The only common problem I'm aware of > in this area is misconfigured firewalls blocking incoming these ICMP > Fragmentation Required messages, which breaks PMTUD. Consider an adversary that can wiretap a path and examine tunneled segments as they fly by. There is nothing to stop such adversaries from sending gratuitous ICMPv4 "fragmentation needed" messages with wrong link MTU values back to the originating tunnel endpoint, i.e., even though the tunneled segments are actually making it through to the other side. I personally know of no real-life examples of such adversaries, but it is easy to postulate their existence. Fred fred.l.templin@boeing.com From owner-v6ops@ops.ietf.org Tue Aug 23 12:20:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7bWE-0002SW-U5 for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 12:20:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13057 for ; Tue, 23 Aug 2005 12:20:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7bVt-0003HN-Fj for v6ops-data@psg.com; Tue, 23 Aug 2005 16:20:37 +0000 Received: from [131.107.3.125] (helo=mail1.microsoft.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7bVq-0003H4-J5 for v6ops@ops.ietf.org; Tue, 23 Aug 2005 16:20:34 +0000 Received: from mailout2.microsoft.com ([157.54.1.120]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Aug 2005 09:20:34 -0700 Received: from red-hub-01.redmond.corp.microsoft.com ([157.54.7.71]) by mailout2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Aug 2005 09:20:33 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Aug 2005 09:20:33 -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); Tue, 23 Aug 2005 09:20:20 -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: Review: draft-ietf-v6ops-nap-01.txt Date: Tue, 23 Aug 2005 09:20:32 -0700 Message-ID: Thread-Topic: Review: draft-ietf-v6ops-nap-01.txt thread-index: AcWn64N0xW5+dVykSiavPO+V5E+oRAAERIfg From: "Christian Huitema" To: "Fred Baker" , "chenhongfei" Cc: "Eric Klein" , X-OriginalArrivalTime: 23 Aug 2005 16:20:20.0621 (UTC) FILETIME=[8E9E7BD0:01C5A7FE] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable > If the objective is to not have people on the outside know of the > existence or exact value of an address, or be able to attack it by > sending traffic to it, then a system that sends packets outside the > net would need to change addresses periodically, but a system that > doesn't send packets outside the network merely needs to be protected > from accidental uses of its address. So far, I have heard the following arguments: 1) Attack surface reduction: hosts that are not reachable at all from the outside are less likely to be attacked. 2) Protection against enumeration: even if hosts are reachable, making their address hard to guess provides protection against systematic attacks such as worms or port scanning. 3) Protection against topology analysis: if the address cannot be correlated with a particular enterprise department, attackers have a harder time figuring out which department is active, or a good target. The solution to number 1 is to provide those hosts that are not meant to be reachable with addresses that are explicitly filtered at the entry points of the organization's network. ULA would do, but are not necessary: any subnet prefix can be filtered. The simple solution is to connect unreachable hosts to an unreachable link. If one must mix reachable and unreachable hosts on the same link, then one has to either forgo the protection, or manage two different subnet prefixes for the same link. The solution to number 2 is well documented in the draft. Problem number 3 only occurs in some networks. It is not an issue if the network is entirely switched (single link), or if the enterprise does not care about hiding its topology. Only then are solutions like flat routing or MIP6 useful.=20 One could make a strong case that topology can be discovered anyhow from analysis of the application traffic, email addresses, web proxy selection and other hints. One could easily argue that the supposed protections are futile. But that amounts to "fighting your customers", which is not a very rewarding exercise. -- Christian Huitema From owner-v6ops@ops.ietf.org Tue Aug 23 18:23:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7hBB-0003Rk-UF for v6ops-archive@megatron.ietf.org; Tue, 23 Aug 2005 18:23:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16647 for ; Tue, 23 Aug 2005 18:23:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7h9H-00048V-K0 for v6ops-data@psg.com; Tue, 23 Aug 2005 22:21:39 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7h9F-00048D-Ve for v6ops@ops.ietf.org; Tue, 23 Aug 2005 22:21:38 +0000 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 23 Aug 2005 15:21:38 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7NMLUQM000631; Tue, 23 Aug 2005 15:21:31 -0700 (PDT) Received: from [10.11.113.209] (sjc-vpn7-550.cisco.com [10.21.146.38]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j7NMHeOb027072; Tue, 23 Aug 2005 15:17:41 -0700 In-Reply-To: <6F66F4F04858B945B836804F0F2AE6BB2C8A72@xmb-rtp-211.amer.cisco.com> References: <000001c5a7c1$2c100020$56646e0a@china.huawei.com> <0A7A4FAB-F105-4B95-88D6-453CE94C77CE@cisco.com> <6F66F4F04858B945B836804F0F2AE6BB2C8A72@xmb-rtp-211.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: multipart/alternative; boundary=Apple-Mail-18-499602585 Message-Id: <8D003A0A-C2C3-4D15-9A9B-459E94E9924A@cisco.com> Cc: "chenhongfei" , "Eric Klein" , From: Fred Baker Subject: Re: Review: draft-ietf-v6ops-nap-01.txt Date: Wed, 24 Aug 2005 06:21:30 +0800 To: "Ralph Droms \(rdroms\)" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=2349; t=1124835462; x=1125267662; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20Review=3A=20draft-ietf-v6ops-nap-01.txt| From:Fred=20Baker=20| Date:Wed,=2024=20Aug=202005=2006=3A21=3A30=20+0800| Content-Type:multipart/alternative=3B=20boundary=3DApple-Mail-18-499602585; b=qCxW2EgVKGfv7uNwSp6FeWbd2NoxkdWTXOEJt7E+i+S7MdznvzT1Bnru6ie8sA/pth+aegZ7 eKmRmeb6Fc3k7B/s0dDK44RiBYnoJFn5nc9kjjno+oA+2dC+KWsLoBQpuSG7JcDg49+NgT0vDZg 6WEquawcYiW3ZP8/uQ37YwSo= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,HTML_40_50, HTML_MESSAGE autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --Apple-Mail-18-499602585 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit On Aug 23, 2005, at 10:02 PM, Ralph Droms ((rdroms)) wrote: > Is there also the requirement that the address of one device that > sends packets to the outside not give clues about other addresses > that might be in use or the network topology on the inside? I'll argue that those clues already exist. The delegated prefix is advertised outside, and a simple traceroute sweep across the network can identify the routers in the network and at least some of the subnets. The routers will respond with "TTL expired", revealing their ingress subnet numbers. If the administration chooses a common host part for routers (such as ::0001or some such thing), it will be trivial for the sweeper to deduce this from the traceroute responses and then ping sweep the routers in the network, determining all subnet numbers. --Apple-Mail-18-499602585 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Aug 23, 2005, = at 10:02 PM, Ralph Droms ((rdroms)) wrote:

= --Apple-Mail-18-499602585-- From owner-v6ops@ops.ietf.org Wed Aug 24 06:49:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E7sp6-0006SP-DY for v6ops-archive@megatron.ietf.org; Wed, 24 Aug 2005 06:49: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 GAA12360 for ; Wed, 24 Aug 2005 06:49:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7smV-00049u-Ml for v6ops-data@psg.com; Wed, 24 Aug 2005 10:46:55 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E7smU-00049a-8L for v6ops@ops.ietf.org; Wed, 24 Aug 2005 10:46:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7OAkn119845; Wed, 24 Aug 2005 13:46:51 +0300 Date: Wed, 24 Aug 2005 13:46:49 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <200508221704.j7MH4Xr5021206@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508221704.j7MH4Xr5021206@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 22 Aug 2005, Francis Dupont wrote: > => using DHCPv4 over a tunnel is *not* a minor tweak. Creating a separate thread out of this. > No, "global v4 addresses -> c)" does not follow. > > It is a perfectly fine way to run and use addresses to give each node > requiring v4 connectivity a static global address. > > => you only assume that anybody has already enough global addresses. > I'd like that it is true but in fact it is not. I think you're assuming that everyone with [not "enough", i.e., basically everyone] global v4 address will want c) as a consenquence. I disagree with that. I agree that some might see c) as a potential solution. A subset of those might even think c) is worth the trouble. But it is IMHO too wide a generalization to just say "global v4 addresses -> c)". > Those which need > them only now and then can also use global addresses, but the easiest > would probably be using RFC1918 for those nodes. > > => RFC 1918 and a NAT? Is it really your idea?? Yes. People use it, and seem to be pretty happy about doing so. Remember, we're offering *v6* as an end-to-end protocol which doesn't have to deal with NAT etc. In that light providing this functionality for v4 might even be counterproductive :) > The issue how aggressively to conserve v4 address space at the cost of > more complexity and mechanisms like dynamic assignments/removals is a > trade-off. > > => Do you argue there is not realistic scenarios where there is no > choice and the IPv4 address space has to aggressively be conserved? No, I'm not saying that. What I'm saying is that people will use different (simpler) tools to perform this conservation. The easiest one at their disposal is RFC1918 and NAT. At some circles, you just apply for more address space, depending on the amount of pressure you can puton your hostmasters (and the size of assignment window right now etc.), you could also get more space to mitigate the need. My argument is that let people use RFC1918, NAT, or whatever mechanisms they want for *v4* address conservation, let us focus on *v6* transition, not finding means how to prolong v4 address usage under aggressive conservation. > > d) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) > > when the host detects it no longer needs the address/connectivity > > > > => as I've already explained, d) is a consequence of c). > > While d) may be desirable by some if you want to release the global > address back to the "pool" as soon as possible, it's not a direct > consequence AFAICS. > > => it is a direct consequence of the not unlimited lifetime of > the allocation. No -- getting an address and keeping it until the node is rebooted (or some other similar event, e.g., DCHPv4-like lease expires or whatever) fulfills that criteria -- the lifetime *is* limited, right? What you want is to get the addresses back to the pool as early as possible, to ensure the most efficient use of address resources. But while that may be your goal, I'm trying to make it clear that there may be people just wanting c), not d). > It'd be perfectly fine to deploy only c) with the > assumption that if the host needs v4 even once, it gets v4 "for good" > (at least as long as isn't rebooted). > > => allocations with an unlimited lifetime are not enough aggressive. > (this is why BOOTP was extended to DHCP). But e.g., DHCP-like mechanisms with lease times do have a limited lifetime, right? Maybe d) could be split off to something like: d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when an address lifetime expires (and is not renewed) d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when the host detects it no longer needs the address/connectivity (I don't see how the host checks that it no longer needs the address in d.2 but that's a separate point -- or how you'd prevent premature revokation of the address w/ a lifetime..) I think you are proposing something that seems to significantly differ from what has been deployed today: DHCPv4 is typically used to give you an address "for good" (to be refreshed periodically though). It doesn't have provisions (AFAICS) to detect whether the address is in use or not when deciding whether to try to refresh the lease or not. You're adding a component of potentially fragile nature in the system. > > Certainly, if you wanted to create ad-hoc tunnels (6to4-like) between > > each host or the like, a protocol interoperability that goes beyond > > the plain tunnel broker would be needed. But I wasn't implying that > > functionality (nor do I think it is needed). > > > > => what I said is the setup mechanism is orthogonal to the tunnel > > mechanism and the only thing about it is just to have one (zero > > doesn't work, two or more don't interoperate). BTW to be clearer > > here I mean the setup of a tunnel between a node and a TEP. > > Well, isn't TSP a solution here as well? > > => DSTM can use TSP (there is a discussion about the choice between > TSP and DHCPv6, both work but we need one and only one :-). > > I don't see how you could write an interoperable implementation > based on it. > > => I was able to write one so I could? See above -- there are lots of places where multiple solutions could be used; if you pick A, you won't interoperate with other implementations which have chosen B. > What are the chances that such a site is not already using NAT, or > doesn't have the capability of getting more addresses? > > => this is not (yet?) the place where to explain why NATs are bad. > Just say there is a binary only application using embedded addresses > (unfortunately not a silly assumption, don't forget this is about > enterprise scenarios). Such applications likely work fine through a TCP proxy or NAT? > In university world, lots of places actually use mostly global v4 > addresses, but on the other hand, they also seem to be quite capable > of obtaining more from their LIRs and RIR as needed. > > => here I ask my site administrator a /24 or /25, I've still waited > for some years, so don't say this is easy everywhere because it is easy > where you are, PLEASE. Maybe you should escalate the issue to your site administrator's boss through your boss. Quite often, the need is not considered significant enough, folks figure out different solutions, or you get more addresses. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 24 10: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 1E7vut-0005qC-Ar for v6ops-archive@megatron.ietf.org; Wed, 24 Aug 2005 10: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 KAA22390 for ; Wed, 24 Aug 2005 10:07:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E7vsN-000Iee-8D for v6ops-data@psg.com; Wed, 24 Aug 2005 14:05:11 +0000 Received: from [161.114.80.244] (helo=tayrelbas01.tay.hp.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E7vsJ-000Ie6-Gi for v6ops@ops.ietf.org; Wed, 24 Aug 2005 14:05:07 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id D81551BA; Thu, 25 Aug 2005 09:17:41 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 24 Aug 2005 10:04:58 -0400 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: Regrets for Mr. Alan E. Beard and some words Date: Wed, 24 Aug 2005 10:04:57 -0400 Message-ID: <936A4045C332714F975800409DE09240D6F457@tayexc14.americas.cpqcorp.net> Thread-Topic: Regrets for Mr. Alan E. Beard and some words Thread-Index: AcWotM81XlLdfn3sR66QvDPafnrf/w== From: "Bound, Jim" To: Cc: "John C. Bogard" X-OriginalArrivalTime: 24 Aug 2005 14:04:58.0783 (UTC) FILETIME=[D00A1AF0:01C5A8B4] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Dear IETF V6OPS colleagues, It is with regret, that I have been asked to inform you that Mr. Alan E. Beard has passed on from a heart attack. Alan was active in our process to define transition scenarios and analysis within V6OPS, and provided significant input to RFC 4057. His dear colleague John C Bogard sent me this notice, and copied in this mail. Alan's professional demeanor and ability to clearly articulate his input to our processes, will be missed, but his contributions have been noted in our community. If you have other information regarding Alan's contributions please send mail to John.C.Bogard@gte.net. Alan was John's mentor and he is greatly missed by John. Sincerely, /jim From owner-v6ops@ops.ietf.org Thu Aug 25 05:08:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Did-000742-Ie for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 05:08:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08295 for ; Thu, 25 Aug 2005 05:08:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Deh-000KQN-PK for v6ops-data@psg.com; Thu, 25 Aug 2005 09:04:15 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Dee-000KPu-Op for v6ops@ops.ietf.org; Thu, 25 Aug 2005 09:04:13 +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 j7P94Be14376 for ; Thu, 25 Aug 2005 11:04:11 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp293.cisco.com [10.61.65.37]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7P94Ap10364 for ; Thu, 25 Aug 2005 11:04:10 +0200 (CEST) Message-Id: <4.3.2.7.2.20050825103827.0342c908@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Aug 2005 11:04:08 +0200 To: v6ops@ops.ietf.org From: "Gunter Van de Velde (gvandeve)" Subject: Issue list of draft-ietf-v6ops-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, During the WGLC (5 August - 19 August) about the draft draft-ietf-v6ops-01.txt there were many suggestions for editorial comments. Lots of these editorials have been included in a first draft for the -nap-02 draft version. In addition we have taken the liberty to make a summary of the more substantial comments. In total we have found 37 substantial comments/issues. The summary list can be found at http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm There is a large variety of comments, some analytical, some less analytical, however we should try to get these worked out by means of WG consensus. Brgds, G/ From owner-v6ops@ops.ietf.org Thu Aug 25 05:11:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8DmB-0000C9-Nh for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 05:11:59 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08491 for ; Thu, 25 Aug 2005 05:11:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Dkl-000Kzd-LH for v6ops-data@psg.com; Thu, 25 Aug 2005 09:10:31 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Dkh-000KzM-Au for v6ops@ops.ietf.org; Thu, 25 Aug 2005 09:10:27 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j7P9AEx26206; Thu, 25 Aug 2005 11:10:14 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j7P9ADJQ033156; Thu, 25 Aug 2005 11:10:13 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-reply-to: Your message of Wed, 24 Aug 2005 13:46:49 +0300. Date: Thu, 25 Aug 2005 11:10:13 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => RFC 1918 and a NAT? Is it really your idea?? Yes. People use it, and seem to be pretty happy about doing so. => this is a philosophical issue... Here is not the right place to discuss it. Remember, we're offering *v6* as an end-to-end protocol which doesn't have to deal with NAT etc. In that light providing this functionality for v4 might even be counterproductive :) => and say that RFC 1918 and a NAT will solve any problem is productive :) ? > => Do you argue there is not realistic scenarios where there is no > choice and the IPv4 address space has to aggressively be conserved? No, I'm not saying that. What I'm saying is that people will use different (simpler) tools to perform this conservation. The easiest one at their disposal is RFC1918 and NAT. => NAT is not a general solution: it doesn't work with embedded addresses. So you have no real counter-argument. My argument is that let people use RFC1918, NAT, or whatever mechanisms they want for *v4* address conservation, let us focus on *v6* transition, not finding means how to prolong v4 address usage under aggressive conservation. => the purpose of the v6ops document is to help to solve problems, not to enforce something. So as the previous scenario is credible DTSM (i.e. c)) has to be referenced. Maybe d) could be split off to something like: d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when an address lifetime expires (and is not renewed) => d.1) is the thing I think about. d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when the host detects it no longer needs the address/connectivity => d.2) should be loosely done by a good choice of parameters (initial and renew lifetimes), i.e., it should not be necessary to be so aggressive. (I don't see how the host checks that it no longer needs the address in d.2 => I know: this is a standard garbage collection problem (see below). but that's a separate point -- or how you'd prevent premature revokation of the address w/ a lifetime..) => I can't see what is the "premature revokation" here: if an address is still in use and is near to expire, just renew? I think you are proposing something that seems to significantly differ from what has been deployed today: DHCPv4 is typically used to give you an address "for good" (to be refreshed periodically though). It doesn't have provisions (AFAICS) to detect whether the address is in use or not when deciding whether to try to refresh the lease or not. => in fact it is very easy to do because the problem is not about the address use but the global IPv4 use. In my implementation I simply use the reference count of the default route because the neighbor cache is implemented as cloned children of it. You're adding a component of potentially fragile nature in the system. => anything is potentially fragile. Do you really believe that a NAT is not fragile? > Just say there is a binary only application using embedded addresses > (unfortunately not a silly assumption, don't forget this is about > enterprise scenarios). Such applications likely work fine through a TCP proxy or NAT? => they don't work through a NAT so an ALG is needed per application... Can I add "encrypted" or "ciphered" before embedded? Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Thu Aug 25 06: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 1E8FNb-0005U3-73 for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 06: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 GAA12162 for ; Thu, 25 Aug 2005 06:54:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8FKn-0001sS-HY for v6ops-data@psg.com; Thu, 25 Aug 2005 10:51:49 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8FKm-0001s6-Gl for v6ops@ops.ietf.org; Thu, 25 Aug 2005 10:51:48 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7PApleB027389 for ; Thu, 25 Aug 2005 11:51:47 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA18224 for ; Thu, 25 Aug 2005 11:51:16 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7PApGY05486 for v6ops@ops.ietf.org; Thu, 25 Aug 2005 11:51:16 +0100 Date: Thu, 25 Aug 2005 11:51:16 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Protocol Action: 'Deprecation of "ip6.int"' to BCP Message-ID: <20050825105116.GK32227@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I think this document release is very welcome. But has anyone a detailed list of usage of .int, i.e. what practical steps need to be taken/encouraged wrt OSes, vendors, etc to get the BCP to reality? Tim On Wed, Aug 24, 2005 at 12:43:39PM -0400, The IESG wrote: > The IESG has approved the following document: > > - 'Deprecation of "ip6.int" ' > as a BCP > > This document has been reviewed in the IETF but is not the product of an > IETF Working Group. > > The IESG contact person is Bert Wijnen. > > A URL of this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-huston-ip6-int-03.txt > > Technical Summary > > This document advises of the deprecation of the use of "ip6.int" for > Standards Conformant IPv6 implementations. > > Working Group Summary > > This is not a Working Group Document. > This memo has been prepared as part of the activities of an ad hoc > advisory committee to advise the IAB on a number of matters relating > to IPv6. > > Protocol Quality > > The document has been reviewed by both OPS Area ADs. > The IETF Last Call has been specifically pointed out to the > DNSOP and IPv6 Working Groups to ensure their attention and > review. Further the IETF Last Call has also been pointed out > to the RIRs for their attention and review. > > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce -- Tim/::1 From owner-v6ops@ops.ietf.org Thu Aug 25 06:54:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8FNg-0005UL-9C for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 06:54:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12168 for ; Thu, 25 Aug 2005 06:54:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8FKM-0001pT-AC for v6ops-data@psg.com; Thu, 25 Aug 2005 10:51:22 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8FKI-0001oe-DU for v6ops@ops.ietf.org; Thu, 25 Aug 2005 10:51:18 +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 j7PApHY21009 for ; Thu, 25 Aug 2005 12:51:17 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp293.cisco.com [10.61.65.37]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7PApFp12831 for ; Thu, 25 Aug 2005 12:51:15 +0200 (CEST) Message-Id: <4.3.2.7.2.20050825125100.03477ac8@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Aug 2005 12:51:13 +0200 To: v6ops@ops.ietf.org From: "Gunter Van de Velde (gvandeve)" Subject: Issue list of draft-ietf-nap-v6ops-01 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Dear All, During the WGLC (5 August - 19 August) about the draft draft-ietf-nap-v6ops-01.txt there were many suggestions for editorial comments. Lots of these editorials have been included in a first draft for the -nap-02 draft version. In addition we have taken the liberty to make a summary of the more substantial comments. In total we have found 37 substantial comments/issues. The summary list can be found at http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm There is a large variety of comments, some analytical, some less analytical, however we should try to get these worked out by means of WG consensus. Brgds, G/ From owner-v6ops@ops.ietf.org Thu Aug 25 07:45:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8GAr-0002vt-4D for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 07:45:37 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13358 for ; Thu, 25 Aug 2005 07:45:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8GA0-0005kj-KU for v6ops-data@psg.com; Thu, 25 Aug 2005 11:44:44 +0000 Received: from [81.187.81.52] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8G9w-0005kN-Bj for v6ops@ops.ietf.org; Thu, 25 Aug 2005 11:44:40 +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 1E8G9x-0000Vo-5W; Thu, 25 Aug 2005 12:44:41 +0100 Message-ID: <430DAF75.80903@dial.pipex.com> Date: Thu, 25 Aug 2005 12:45:57 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" CC: v6ops@ops.ietf.org Subject: Re: Issue list of draft-ietf-nap-v6ops-01 References: <4.3.2.7.2.20050825125100.03477ac8@strange-brew> In-Reply-To: <4.3.2.7.2.20050825125100.03477ac8@strange-brew> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks for the summary... However, I think it misses the discussion over the last couple of days which resulted in the summary from Christian Huitema: If the objective is to not have people on the outside know of the > existence or exact value of an address, or be able to attack it by > sending traffic to it, then a system that sends packets outside the > net would need to change addresses periodically, but a system that > doesn't send packets outside the network merely needs to be protected > from accidental uses of its address. So far, I have heard the following arguments: 1) Attack surface reduction: hosts that are not reachable at all from the outside are less likely to be attacked. 2) Protection against enumeration: even if hosts are reachable, making their address hard to guess provides protection against systematic attacks such as worms or port scanning. 3) Protection against topology analysis: if the address cannot be correlated with a particular enterprise department, attackers have a harder time figuring out which department is active, or a good target. The solution to number 1 is to provide those hosts that are not meant to be reachable with addresses that are explicitly filtered at the entry points of the organization's network. ULA would do, but are not necessary: any subnet prefix can be filtered. The simple solution is to connect unreachable hosts to an unreachable link. If one must mix reachable and unreachable hosts on the same link, then one has to either forgo the protection, or manage two different subnet prefixes for the same link. The solution to number 2 is well documented in the draft. Problem number 3 only occurs in some networks. It is not an issue if the network is entirely switched (single link), or if the enterprise does not care about hiding its topology. Only then are solutions like flat routing or MIP6 useful. One could make a strong case that topology can be discovered anyhow from analysis of the application traffic, email addresses, web proxy selection and other hints. One could easily argue that the supposed protections are futile. But that amounts to "fighting your customers", which is not a very rewarding exercise. -- Christian Huitema Regards, Elwyn Gunter Van de Velde (gvandeve) wrote: > Dear All, > > During the WGLC (5 August - 19 August) about the draft > draft-ietf-nap-v6ops-01.txt > there were many suggestions for editorial comments. Lots of these > editorials > have been included in a first draft for the -nap-02 draft version. > > In addition we have taken the liberty to make a summary of the more > substantial > comments. In total we have found 37 substantial comments/issues. > The summary list can be found at > http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm > > There is a large variety of comments, some analytical, some less > analytical, however > we should try to get these worked out by means of WG consensus. > > Brgds, > G/ > > From owner-v6ops@ops.ietf.org Thu Aug 25 08:19:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8GhM-0004We-M5 for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:19: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 IAA14972 for ; Thu, 25 Aug 2005 08:19:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8GfE-0008U3-4P for v6ops-data@psg.com; Thu, 25 Aug 2005 12:17:00 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8GfA-0008TA-VF for v6ops@ops.ietf.org; Thu, 25 Aug 2005 12:16:57 +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 j7PCGtj26434; Thu, 25 Aug 2005 14:16:55 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp293.cisco.com [10.61.65.37]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7PCGtp20486; Thu, 25 Aug 2005 14:16:55 +0200 (CEST) Message-Id: <4.3.2.7.2.20050825134840.0314cc98@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 25 Aug 2005 14:16:53 +0200 To: Elwyn Davies From: "Gunter Van de Velde (gvandeve)" Subject: Re: Issue list of draft-ietf-nap-v6ops-01 Cc: v6ops@ops.ietf.org In-Reply-To: <430DAF75.80903@dial.pipex.com> References: <4.3.2.7.2.20050825125100.03477ac8@strange-brew> <4.3.2.7.2.20050825125100.03477ac8@strange-brew> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Thanks again for providing the useful input. I did indeed overlook the summary comments from Christian Huitema. However they are probably the consensus summary of issue 24 as that started the discussion initially? I have to think on to modify the text under s4.4 to reflect the words from Christian Huitema. Brgds, G/ At 12:45 25/08/2005 +0100, Elwyn Davies wrote: >Thanks for the summary... > >However, I think it misses the discussion over the last couple of days >which resulted in the summary from Christian Huitema: > >If the objective is to not have people on the outside know of the >>existence or exact value of an address, or be able to attack it by >>sending traffic to it, then a system that sends packets outside the >>net would need to change addresses periodically, but a system that >>doesn't send packets outside the network merely needs to be protected >>from accidental uses of its address. > > >So far, I have heard the following arguments: > >1) Attack surface reduction: hosts that are not reachable at all from >the outside are less likely to be attacked. > >2) Protection against enumeration: even if hosts are reachable, making >their address hard to guess provides protection against systematic >attacks such as worms or port scanning. > >3) Protection against topology analysis: if the address cannot be >correlated with a particular enterprise department, attackers have a >harder time figuring out which department is active, or a good target. > >The solution to number 1 is to provide those hosts that are not meant to >be reachable with addresses that are explicitly filtered at the entry >points of the organization's network. ULA would do, but are not >necessary: any subnet prefix can be filtered. The simple solution is to >connect unreachable hosts to an unreachable link. If one must mix >reachable and unreachable hosts on the same link, then one has to either >forgo the protection, or manage two different subnet prefixes for the >same link. > >The solution to number 2 is well documented in the draft. > >Problem number 3 only occurs in some networks. It is not an issue if the >network is entirely switched (single link), or if the enterprise does >not care about hiding its topology. Only then are solutions like flat >routing or MIP6 useful. >One could make a strong case that topology can be discovered anyhow from >analysis of the application traffic, email addresses, web proxy >selection and other hints. One could easily argue that the supposed >protections are futile. But that amounts to "fighting your customers", >which is not a very rewarding exercise. > >-- Christian Huitema > >Regards, >Elwyn > > > >Gunter Van de Velde (gvandeve) wrote: > >>Dear All, >> >>During the WGLC (5 August - 19 August) about the draft >>draft-ietf-nap-v6ops-01.txt >>there were many suggestions for editorial comments. Lots of these editorials >>have been included in a first draft for the -nap-02 draft version. >> >>In addition we have taken the liberty to make a summary of the more >>substantial >>comments. In total we have found 37 substantial comments/issues. >>The summary list can be found at >>http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm >> >>There is a large variety of comments, some analytical, some less >>analytical, however >>we should try to get these worked out by means of WG consensus. >> >>Brgds, >>G/ >> From owner-v6ops@ops.ietf.org Thu Aug 25 08:25:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Gno-00072r-1s for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:25:52 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15169 for ; Thu, 25 Aug 2005 08:25:50 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Gmu-00091a-Ge for v6ops-data@psg.com; Thu, 25 Aug 2005 12:24:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Gms-00091I-7f for v6ops@ops.ietf.org; Thu, 25 Aug 2005 12:24:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7PCOqM17027 for ; Thu, 25 Aug 2005 15:24:52 +0300 Date: Thu, 25 Aug 2005 15:24:52 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-ipsec-tunnels-01.txt In-Reply-To: <42D8FBBD.2010506@dial.pipex.com> Message-ID: References: <42D8FBBD.2010506@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, There were no WGLC comments. An update has been sent to the secretariat. The issue tracker has been updated at: http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html The updated draft is also available there. On Sat, 16 Jul 2005, Elwyn Davies wrote: > The latest version appears to address all the comments that I and others > made, and generally looks good (give or take a few editorial fixes - see > below). > > One minor issue with regard to the language used about how to model the > tunnel end-point when specific SPD tunnel mode is used: I am not sure that it > is up to this document to 'require' (s5.3, 2nd para) that they are not > modelled as separate interfaces. What we are saying is that it is not really > possible to build specific SPD tunnel mode on end points modelled as > interfaces... Therefore we recommend that specific SPD tunnel mode end points > should not be modelled as separate interfaces. This is followed through into > the reccommendations in s9 para 2: suggest s/support/recommend/. There ought > to be a better way of saying this but I can't think what it is at present. > > Regards, > Elwyn > > A number of language/editorial nits: > > s1: Unexpanded acronyms: SA, SPD, ECN (SA is expanded in s2.1) > s2: para 1: s/was mostly/is mostly/ > > s2: para 3: s/specifies following/specifies the following/, > s/measures./measures:/ > s2: paras4/5: make them bulleted paras to clarify that they are the > 'following measures' > > s2.1: para 1: s/The successful/A successful/ > > s2.1: last para: s/kind/kinds/ > > s2.1: last para: Unexpanded acronyms GRE, L2TP (maybe need references). > > s2.2: para 1: s/The successful/A successful/ > > s3.2: next-to-last para: Unexpanded acronyms ISP, CPE > > s4: The language in this section may become slightly less clear when the > drafts become RFCs > s4: para 2: s/is defined in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]/was > originally defined in [RFC2401] now superseded by > [I-D.ietf-ipsec-rfc2401bis]/ > s4: para 2: s/IPsec security/The IPsec security/, s/difference/differences/ > > s4: para 7: Move the first sentence {'IKE is defined in [RFC2409] (which is > referred to as IKE in this document) and in [I-D.ietf-ipsec-ikev2] (which is > referred to as IKEv2 in this document).'} to be the second sentence of para > 2. Start a new para after this, substituting s/them/the two versions of the > security architecture/. In the rest of the section - do what the IKE > sentence says - use IKE and IKEv2 consistently - IKEv1 -> IKE, places where > the IKE RFC/draft are used replaced by IKE/IKEv2 (e.g., Bullet point 3), para > 6) [Actually IKEv1 seems to be used pretty consistently in the rest of the > document!] > > s5: para 1: s/the IPsec tunnel establishment for/establishment of an IPsec > tunnel for the/, s/we'll/we will/, s/look on/look at/ > > s5: Figure 5: Might be more obvious as a 'boxed' table, maybe with column > headings 'Components (first to last)', 'Contains'. Also presumably the > packet has a payload! > > s5.2: para 1: delete 'kind of' > s5.2: para 3: s/whose tunnel endpoint's IPv4 address is/with tunnel endpoint > IPv4 addresses/ > s5.2: para 3: s/The implementations/Implementations/ > > s5.3.1: para 1: s/routing table/the routing table/, s/is passes/is passed/ > s5.3.1: para 3: s/prevent/prevent an attacker/ > > s7: para 2: s/the same way/in the same way/ > s7: bullet point 2: s/the NAT changes/where the NAT changes/ > s7: last para: s/MOBIKE/The IETF MOBIKE working group/ > > s8: 1st bullet: s/off-band/out-of-band/ > > s9: last para: s/is to either tunnel mode with generic SPDs or transport > mode, and applying/is to use either tunnel mode with generic SPDs or > transport mode, and apply/ > > s11: para 1: s/in the tunnel/into the tunnel/ > s11: para 2: s/to the both,/to both/ > > s11: para 3: IF you use IKE to mean IKEv1 then s/IKE/Either IKE or IKEv2/ - > If you go for IKEv1 explicitly, IKE is finr. > > References: Whether RC2401 and RFC2409 are normative is arguable! > > App A: para 2: s/associations are/association is, s/interfaces/an interface/ > > App A: throughout: s/destination/DST/ in rules (some already do) > > Pekka Savola wrote: > >> On Mon, 11 Jul 2005 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 : Using IPsec to Secure IPv6-in-IPv4 Tunnels >>> Author(s) : P. Savola, et al. >>> Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt >>> Pages : 21 >>> Date : 2005-7-11 >>> >>> This document gives guidance on securing manually configured IPv6-in- >>> IPv4 tunnels using IPsec. No additional protocol extensions are >>> described beyond those available with the IPsec framework. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt >> >> >> The authors believe that this version addresses all comments sent to date. >> >> There has been substantial revision in the draft. Those who previously >> read it are encouraged to take another look and see if it's better. If you >> haven't taken a look yet, now would be a good chance. >> >> The issue list is at: >> http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html >> >> There's also a htmlwdiff there. >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 25 08:26:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8GoF-00075U-Nj for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 08:26:19 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15195 for ; Thu, 25 Aug 2005 08:26:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Go8-0009A5-JF for v6ops-data@psg.com; Thu, 25 Aug 2005 12:26:12 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8Go7-00099o-C2 for v6ops@ops.ietf.org; Thu, 25 Aug 2005 12:26:11 +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 1E8Go8-0006tK-0j; Thu, 25 Aug 2005 13:26:12 +0100 Message-ID: <430DB930.10309@dial.pipex.com> Date: Thu, 25 Aug 2005 13:27:28 +0100 From: Elwyn Davies User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Gunter Van de Velde (gvandeve)" CC: v6ops@ops.ietf.org Subject: Re: Issue list of draft-ietf-nap-v6ops-01 References: <4.3.2.7.2.20050825125100.03477ac8@strange-brew> <4.3.2.7.2.20050825125100.03477ac8@strange-brew> <4.3.2.7.2.20050825134840.0314cc98@strange-brew> In-Reply-To: <4.3.2.7.2.20050825134840.0314cc98@strange-brew> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit That is probably true.. E Gunter Van de Velde (gvandeve) wrote: > Thanks again for providing the useful input. I did indeed overlook the > summary > comments from Christian Huitema. However they are probably the consensus > summary of issue 24 as that started the discussion initially? I have > to think on > to modify the text under s4.4 to reflect the words from Christian > Huitema. > > Brgds, > G/ > > At 12:45 25/08/2005 +0100, Elwyn Davies wrote: > >> Thanks for the summary... >> >> However, I think it misses the discussion over the last couple of >> days which resulted in the summary from Christian Huitema: >> >> If the objective is to not have people on the outside know of the >> >>> existence or exact value of an address, or be able to attack it by >>> sending traffic to it, then a system that sends packets outside the >>> net would need to change addresses periodically, but a system that >>> doesn't send packets outside the network merely needs to be protected >>> from accidental uses of its address. >> >> >> >> So far, I have heard the following arguments: >> >> 1) Attack surface reduction: hosts that are not reachable at all from >> the outside are less likely to be attacked. >> >> 2) Protection against enumeration: even if hosts are reachable, making >> their address hard to guess provides protection against systematic >> attacks such as worms or port scanning. >> >> 3) Protection against topology analysis: if the address cannot be >> correlated with a particular enterprise department, attackers have a >> harder time figuring out which department is active, or a good target. >> >> The solution to number 1 is to provide those hosts that are not meant to >> be reachable with addresses that are explicitly filtered at the entry >> points of the organization's network. ULA would do, but are not >> necessary: any subnet prefix can be filtered. The simple solution is to >> connect unreachable hosts to an unreachable link. If one must mix >> reachable and unreachable hosts on the same link, then one has to either >> forgo the protection, or manage two different subnet prefixes for the >> same link. >> >> The solution to number 2 is well documented in the draft. >> >> Problem number 3 only occurs in some networks. It is not an issue if the >> network is entirely switched (single link), or if the enterprise does >> not care about hiding its topology. Only then are solutions like flat >> routing or MIP6 useful. >> One could make a strong case that topology can be discovered anyhow from >> analysis of the application traffic, email addresses, web proxy >> selection and other hints. One could easily argue that the supposed >> protections are futile. But that amounts to "fighting your customers", >> which is not a very rewarding exercise. >> >> -- Christian Huitema >> >> Regards, >> Elwyn >> >> >> >> Gunter Van de Velde (gvandeve) wrote: >> >>> Dear All, >>> >>> During the WGLC (5 August - 19 August) about the draft >>> draft-ietf-nap-v6ops-01.txt >>> there were many suggestions for editorial comments. Lots of these >>> editorials >>> have been included in a first draft for the -nap-02 draft version. >>> >>> In addition we have taken the liberty to make a summary of the more >>> substantial >>> comments. In total we have found 37 substantial comments/issues. >>> The summary list can be found at >>> http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm >>> >>> There is a large variety of comments, some analytical, some less >>> analytical, however >>> we should try to get these worked out by means of WG consensus. >>> >>> Brgds, >>> G/ >>> > From owner-v6ops@ops.ietf.org Thu Aug 25 10:20:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Iaf-0000Vx-EV for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 10:20:25 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20193 for ; Thu, 25 Aug 2005 10:20:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8IYb-000HwX-1Q for v6ops-data@psg.com; Thu, 25 Aug 2005 14:18:17 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8IYY-000HwH-QD for v6ops@ops.ietf.org; Thu, 25 Aug 2005 14:18:15 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7PEICeB003763 for ; Thu, 25 Aug 2005 15:18:13 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id PAA04203 for ; Thu, 25 Aug 2005 15:17:55 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7PEHti12298 for v6ops@ops.ietf.org; Thu, 25 Aug 2005 15:17:55 +0100 Date: Thu, 25 Aug 2005 15:17:55 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: Last call on draft-ietf-v6ops-nap-01.txt Message-ID: <20050825141755.GA12237@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some more comments on this draft. Apologies for the lateness. -- Tim/::1 1. Introduction Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. The serious disadvantages of ambiguous "private" address space and of Network Address Translation (NAT) [1][5] have been well documented [4][6]. However, given its wide market acceptance NAT undoubtedly has some perceived benefits. Indeed, in an Internet model based on universal any-to-any connectivity, product marketing departments have driven a perception that some connectivity and security concerns can only be solved by using a NAT device or by using logically separated LAN address spaces. This document describes the market-perceived reasons to utilize a NAT device in an IPv4 environment and shows how these needs can be met and even exceeded with IPv6. The use of the facilities from IPv6 described in this document avoids the negative impacts of translation and may be described as Network Architecture Protection (NAP). >> Does it explain why IPv6 NAT is not needed also? >> Add reference to rfc2775 maybe? As far as security and privacy is concerned, this document considers how to mitigate a number of threats. Some are obviously external, such as having a hacker trying to penetrate your network, or having a worm infected machine outside your network trying to attack it. Some are local such as a disgruntled employee disrupting business operations, or the unintentional negligence of a user downloading some malware which then proceeds to attack any device on the LAN. Some may be embedded such as having some firmware in a domestic appliance "call home" to its manufacturer without the user's consent. >> Note the threats that are user-initiated (e.g. web browser download) are >> different to those that are 'pushed' into a site. IPv6 does not really >> help the former, but may help against the latter, and also the internal >> spread of such threats (e.g. worms that search for hosts on a subnet/link >> to infect). IPv6 Network Architecture Protection can be summarized in the following table. It presents the marketed functions of NAT with a cross-reference of how those are delivered in both the IPv4 and IPv6 environments. Function IPv4 IPv6 +------------------+-----------------------+-----------------------+ | Simple Gateway | DHCP - single | DHCP-PD - arbitrary | | as default router| address upstream | length customer | | and address pool | DHCP - limited | prefix upstream | | manager | number of individual | SLAAC via RA | | | devices downstream | downstream | | | see section 2.1 | see section 4.1 | >> Why does DHCP limit the number of downstream devices? Why not use >> DHCP with IPv6? +------------------|-----------------------|-----------------------+ | Topology hiding | NAT transforms | Untraceable addresses| | | subnet bits in the | using IGP host routes| | | address | /or MIPv6 tunnels for| | | | stationary systems | | | see section 2.4 | see section 4.4 | >> Host route scalability limited though? +------------------|-----------------------|-----------------------+ | Addressing | RFC 1918 | RFC 3177 & ULA | | Autonomy | | | | | see section 2.5 | see section 4.5 | >> Or do we encourage all sites to use 3177 addresses even if not connected? +------------------|-----------------------|-----------------------+ | Global Address | RFC 1918 | 340,282,366,920,938, | | Pool | | 463,463,374,607,431, | | Conservation | | 768,211,456 | | | | (3.4*10^38) addresses| | | see section 2.6 | see section 4.6 | >> 2^128 addresses doesn't help if sites get given too big a prefix ;) >> What about internal site benefits? Like resilience to 'ping and infect' >> type worms on a subnet/link do to link size, or port scanning reslience, >> for which IPv4 has no 'equivalent'? Add these to the table and refer >> to text? Should all text sections appear in the summary table? 2.1 Simple gateway between Internet and internal network A NAT device can connect a private network with any kind of address (ambiguous [RFC 1918] or global registered address) towards the Internet. The address space of the private network can be built from globally unique addresses, from ambiguous address space or from both simultaneously. Without specific configuration from public to private, the NAT device enables access between the client side of an application in the private network with the server side in the public Internet. >> Explain somewhere what is meant by 'ambiguous address space'? Additionally, thanks to successful marketing campaigns it is perceived by end users that their equipment is protected from the bad elements and attackers on the public IPv4 Internet. 2.2 Simple security due to stateful filter implementation It is frequently believed that through its session-oriented operation, NAT puts in an extra barrier to keep the private network protected from evil outside influences. Since a NAT device typically keeps state only for individual sessions, attackers, worms, etc. cannot exploit this state to attack a host in general and on any port. This benefit may be partially real, however, experienced hackers are well aware of NAT devices and are very familiar with private address space, and have devised methods of attack (such as trojan horses) that readily penetrate NAT boundaries. For these reasons the sense of security provided by NAT are actually false. >> But aren't these 'trojans' applicable to IPv6 systems too? Is NAT >> a special case? In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case the NAT actually adds management complexity compared to a simple router. In situations where 2 or more devices need to host the same application this complexity shifts from difficult to impossible. >> And the chances for misconfiguration grow. Though for every such >> mapping you are likely? to need an equivalent firewall rule in an >> IPv6 network? 2.4 Privacy and topology hiding There is a similarity with privacy based on application level proxies. When using an application level gateway for browsing the web for example, the 'privacy' of a web user can be provided by masking the true identity of the original web user towards the outside world (although the details of what is - or is not - logged at the NAT/proxy will be different). Some enterprises prefer to hide as much as possible of their internal network topology from outsiders. Mostly this is achieved by blocking "traceroute" etc., but NAT of course entirely hides the internal subnet topology, which some network managers believe is a useful precaution to mitigate scanning attacks. Scanning for IPv6 can be much harder in comparison with IPv4 as described in [17] >> There's a new I-D now on how to best configure IPv6 access devices to >> ensure ICMP filtering is done properly (e.g. doesn't break PMTU >> discovery) - cite it somewhere? 2.5 Independent control of addressing in a private network Many private IPv4 networks take benefit from using the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a clean and hierarchical addressing structure in the network. >> But in some cases even 16M 'net 10' addresses are not enough? Another benefit is due to the usage of independent addresses on majority of the network infrastructure there is an increased ability to change provider with less operational difficulties. >> Only if the site is generally client devices, rather than servers; >> in the latter case you generally wouldn't use NAT though. 2.6 Global address pool conservation Due to the ongoing depletion of the IPv4 address range, the remaining pool of unallocated IPv4 addresses is below 30%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a direct result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will continue increasing in direct response to tightening allocation policies. In response to the increasing administrative overhead many Internet Service Providers (ISPs) have already resorted to the ambiguous addresses defined in RFC 1918 behind a NAT for the various services they provide as well as connections for their end customers. In turn this has restricted the number of and types of applications that can be deployed by these ISPs and their customers. Forced into this limiting situation such customers can rightly claim that despite the optimistic predictions of mathematical models the global pool of IPv4 addresses is effectively already exhausted. >> Note RFC1918 may be used for end customers, or for ISP infrastructure, >> sometimes for one, not the other. Managing two sets of RFC1918 >> networks is more complex. Some ISPs seem to be considering IPv6 for >> their infrastructure management? 2.7 Multihoming and renumbering with NAT This solution may be sufficient for some networks; however when the merging networks were already using address translation it will create huge problems due to admistrative difficulties of the merged address space. >> Especially since they'll often both be using 10.0.0.* for example. 3.1 Privacy addresses (RFC 3041) While the primary implementation and source of randomized RFC 3041 addresses is expected to be from end systems running stateless autoconfiguration, there is nothing that prevents a DHCP server from running the RFC 3041 algorithm for any new IEEE identifier it hears, then remembering that for future queries. This would allow using them in DNS for registered services since the assumption of a server based deployment would be a persistent value that minimizes DNS churn. A DHCP based deployment would also allow for local policy to periodically change the entire collection of end device addresses while maintaining some degree of central knowledge and control over which addresses should be in use at any point in time. >> Yes, DHCPv6 supports allocating privacy addresses. Note 3041 is being updated at this time. Many sites will NOT want to have such addresses used (due to management issues) so would probably run full DHCPv6 for address management. 3.2 Unique Local Addresses Local network and application services stability during periods of intermittent connectivity between one or more providers requires address management autonomy. Such autonomy in a single routing prefix environment would lead to massive expansion of the global routing tables, so IPv6 provides for simultaneous use of multiple prefixes. The Unique Local Address prefix (ULA) [12] has been set aside for use in local communications. The ULA address prefix for any network is routable over a locally defined collection of routers. These prefixes are NOT to be routed on the public global Internet as that would have a serious negative impact on global routing. >> Well, they can be routed anywhere you can convince ISPs to do so for you... :) ULAs have the following characteristics: o Globally unique prefix * Allows networks to be combined or privately interconnected without creating any address conflicts or requiring renumbering of interfaces using these prefixes * If accidentally leaked outside of a network via routing or DNS, there is no conflict with any other addresses o ISP independent and can be used for communications inside of a network without having any permanent or intermittent Internet connectivity >> delete 'or intermittent' o Well known prefix to allow for easy filtering at network boundaries o In practice, applications may treat these addresses like global scoped addresses >> They should treat them as globals, because they have *global* scope, but the reality is more complex :( 3.4 Untraceable IPv6 addresses These should be globally routable IPv6 addresses which can be randomly and independently assigned to IPv6 devices. The random assignment has as purpose to confuse the outside world on the structure of the local network. However for the local network there is a correlation between the location of the device and the untraceable IPv6 address. This correlation could be done by generating IPv6 host route entries or by utilizing an aggregation device like a Mobile IPv6 Home Agent. >> I really don't like this text being in the draft. 4.2 IPv6 and Simple security The vulnerability of an IPv6 host is similar as for an IPv4 host directly connected towards the Internet, and firewall and IDS systems are recommended. A proxy may be used for certain applications, but has the caveat that the end to end transparancy is broken. However, with IPv6, the following protections are available without the use of NAT while maintaining end-to-end reachability: 1. Short lifetimes on privacy extension suffixes reduce the attack profile since the node will not respond to the address once the address is no longer valid. >> Is 'suffix' the right word? 2. IPsec is a mandatory service for IPv6 implementations. IPsec functions to prevent session hijacking, prevent content tampering, and optionally masks the packet contents. While IPsec might be available in IPv4 implementations, deployment in NAT environments either breaks the protocol or requires complex helper services with limited functionality or efficiency. >> Availability of AH and ESP functionality is 'mandated', usage is not. 4.3 User/Application tracking IPv6 enables the collection of information about data flows. Due to the fact that all addresses used for Internet and intra-/inter- site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. This enhances the capability of data-flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses. >> So long as 3041 isn't used. 4.4 Privacy and topology hiding using IPv6 When a network manager also wishes to conceal the internal IPv6 topology, by using explicit host routes it is possible to locate nodes on one segment while they appear externally to be on another. An alternative method to hide the internal topology would be to use Mobile IPv6 internally without route optimization where the public facing addresses are consolidated on an edge Home Agent (HA), then use MIPv6 in bidirectional tunnel mode between the HA and topology masked node using the ULA as a COA. This truly masks the internal topology as all nodes with global access appear to share a common subnet. There is no reason that rack mounted devices couldn't be considered mobile nodes to mask the internal topology. It looks equivalent to running a VPN to a central server, however it does not involve any encryption or significant overhead. >> Again, I don't like this. The 'cost' for the gain is very, very high. 4.5 Independent control of addressing in a private network IPv6 provides sufficient space to completely avoid the need for overlapping address space, 340,282,366,920,938,463,463,374,607,431,768,211,456 (3.4*10^38) total possible addresses. As previously discussed, the serious disadvantages of ambiguous address space have been well documented, and with sufficient space there is no need to continue the increasingly aggressive conservation practices that are necessary with IPv4. While IPv6 allocation policies and ISP business practice will continue to evolve, the recommendations in RFC 3177 are based on the technical potential of the vast IPv6 address space. That document demonstrates that there is no resource limitation which will lead to the IPv4 practice of ambiguous space behind a NAT. As an example of the direct contrast, many expansion oriented IPv6 deployment scenarios result in multiple IPv6 addresses per device, as opposed to the IPv4 constricting scenarios of multiple devices sharing a scarce global address. >> Note RFC3177 is under -bis revision at the moment. 4.7 Multihoming and renumbering Multihoming and renumbering remain technically challenging with IPv6 (see the Gap Analysis below). However, IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-like prefixes and thus with several simultaneous ISPs. An address selection mechanism [9] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in this regard therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and Van de Velde, et al. Expires December 3, 2005 [Page 16] Internet-Draft IPv6 Network Architecture Protection june 2005 the processes for adding and removing active prefixes at a site have been documented [11] and [18]. >> IPv4 has no lifetime or deprecation indicators like IPv6. With IPv6 multiaddressing is likely to be common. The IPv6 address space allocated by the ISP will be dependent upon the connecting Service provider. This may result in a renumbering effort if the network changes from Service Provider. When changing ISPs or ISPs readjusting their addressing pool, DHCP-PD [10] can be used as the zero-touch external mechanism for prefix change in conjunction with a ULA prefix for internal connection stability. With appropriate management of the lifetime values and overlap of the external prefixes, a smooth make-before-break transition is possible as existing communications will continue on the old prefix as long as it remains valid, while any new communications will use the new prefix. >> I think the renumbering tests we did show that ULAs are not necessary. ULA also adds 'cost' in terms of complexity, since they are *global* scope addresses now. 5. Case Studies It is possible to divide the type of networks in different categories. This can be done on various criteria. The criteria used within this document are based on the number of components or connections. For each of these category of networks we can use IPv6 Network Architecture Protection to achieve a secure and flexible infrastructure, which provides an enhanced network functionality in comparison with the usage of address translation. o Medium/large private networks (typically >10 connections) o Small private networks (typically 1 to 10 connections) o Single user connection (typically 1 connection) o ISP/Carrier customer networks >> You mean devices/nodes, or connections as in network links offsite? >> Our site has 20,000 nodes, and 1 connection. It is not 'small private'. The summarization benefit for the ISP is happening based on the IPv6 allocation rules. This means that the ISP will provide the enterprise with an IPv6 address-range (typically a one or multiple range(s) of '/48') from its RIR assigned IPv6 address-space. The goal of this allocation mechanism is to decrease the total amount of entries in the internet routing table. >> summarization -> aggregation? To mask the identity of a user on a network of this type, the usage of IPv6 privacy extensions may be advised. This technique is useful when an external element wants to track and collect all information sent and received by a certain host with known IPv6 address. Privacy extensions add a random factor to the host part of an IPv6 address and will make it very hard for an external element to keep correlating the IPv6 address to a host on the inside network. The usage of IPv6 privacy extensions does not mask the internal network structure of an enterprise network. >> And the ISP just tracks prefix usage for billing/etc? If there is need to mask the internal structure towards the external IPv6 internet, then some form of 'Untraceable' addresses may be used. These addresses will be derived from a local pool, and may be assigned to those hosts for which topology masking is required or which want to reach the IPv6 Internet or other external networks. The technology to assign these addresses to the hosts could be based on DHCPv6. To complement the 'Untraceable' addresses it is needed to have at least awareness of the IPv6 address location when routing an IPv6 packet through the internal network. This could be achieved by 'route-injection' in the network infrastructure. This route- injection could be done based on /128 host-routes to each device that wants to connect to the Internet using an untraceable address. >> Again, yuk. Do we need this? 5.2 Small private networks o DHCPv6 Prefix-Delegation o ISP provides a static IPv6 address-range For the DHCPv6-PD solution, a dynamic address allocation approach >> dynamic, or automatic? I hope it's automatic and static. >> DHCP-PD != dynamic/changing allocations ? is chosen. By means of the enhanced DHCPv6 protocol it is possible to have the ISP push down an IPv6 prefix range automatically towards the small private network and populate all interfaces in that small private network dynamically. This reduces the burden for administrative overhead because everything happens automatically. For the static configuration the mechanisms used could be the same as for the medium/large enterprises. Typically the need for masking the topology will not be of high priority for these users, and the usage of IPv6 privacy extensions could be sufficient. >> A manual rather than static setup? For both alternatives the ISP has the unrestricted capability for summarization of its RIR allocated IPv6 prefix, while the small >> summarization -> aggregation? While a full prefix is expected to be the primary deployment model there may be cases where the ISP provides a single IPv6 address for use on a single piece of equipment (PC, PDA, etc.). This is expected to be rare though, because in the IPv6 world the assumption is that there is an unrestricted availability of a large amount of globally routable and unique address space. If scarcity was the motivation with IPv4 to provide RFC 1918 addresses, in this environment the ISP will not be motivated to allocate private addresses towards the single user connection because there are enough global addresses available at essentially the same cost. Also if the single device wants to mask its identity to the called party or its attack profile over a short time window it will need to enable IPv6 privacy extensions, which in turn leads to the need for a minimum allocation of a /64 prefix rather than a single address. >> Agree we should emphasise a minimum /64. 5.3 Single user connection In IPv6 world the assumption is that there is unrestricted availability of a large amount of globally routable and unique IPv6 addresses. The ISP will not be motivated to allocate private addresses towards the single user connection because he has enough global addresses available, if scarcity was the motivation with IPv4 to provide RFC 1918 addresses. If the single user wants to mask his identity, he may choose to enable IPv6 privacy extensions. >> Can he, if the ISP may try to enforce the use of a single address? 5.4 ISP/Carrier customer networks When looking in chapter 2.3 of RFC3314 'Recommendations for IPv6 in 3GPP Standards' [14] it is found that the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary PDP context. This will allow sufficient address space for a 3GPP- attached node to allocate privacy addresses and/or route to a multi- link subnet, and will discourage the use of NAT within 3GPP-attached devices. >> I guess an ISP/carrier may use RFC1918 addresses for its infrastructure >> independently of assignemnts to end customers. 6. IPv6 gap analysis Like IPv4 and any major standards effort, IPv6 standardization work continues as deployments are ongoing. This section discusses several topics for which additional standardization, or documentation of best practice, is required to fully realize the benefits of NAP. None of these items are show-stoppers for immediate usage of NAP in roles where there are no current gaps. >> Maybe this should all be punted to a separate draft?? It would be >> nice to see NAP as a long-lived document, and this section will be >> quite fluid? Or call 'Recommendations for further work'? Hmmm. Other comments: >> Maybe mention that in the 'real world' IPv4 NAT + IPv6 globals are likely >> to run dual-stack. What is the implication on security there? How can >> firewalls/CPE equipment be configured consistently between the two? From owner-v6ops@ops.ietf.org Thu Aug 25 12:14:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8KN1-0000LW-K9 for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:14: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 MAA26929 for ; Thu, 25 Aug 2005 12:14:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8KKv-0000cK-Q9 for v6ops-data@psg.com; Thu, 25 Aug 2005 16:12:17 +0000 Received: from [81.187.81.51] (helo=smtp.aaisp.net.uk) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8KKu-0000by-BD for v6ops@ops.ietf.org; Thu, 25 Aug 2005 16:12:16 +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 1E8KKs-0007ev-Gs; Thu, 25 Aug 2005 17:12:14 +0100 Message-ID: <430DEE2D.5080904@dial.pipex.com> Date: Thu, 25 Aug 2005 17:13:33 +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 '" Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi. The intention of this draft is excellent - using a single scheme for connecting across IPv4 clouds is clearly essential to achieve e2e interoperability in the world encapsulated in the diagrams. The question that comes to my mind is just how much does this represent a time that has already gone by? The scenarios do not include situations where the IPv4 cloud is a convenient substrate to build a tunnel between an IPv6 enabled stub and 'the' IPv6 transit backbone (which will be used until such time as native IPv6 connectivity arrives at the stub's attachment point(s)). There are already global IPv6 transit providers, and sitting here in front of my home system, my ISP provides me with an IPv6 prefix and capability to use an IPv6-in-IPv4 tunnel to an endpoint in their network which then connects me onto the IPv6 backbone. Hence before expending a lot of effort on determining (and 'marketing') whatever might be the 'best' solution in the pure IPv4 core case I believe we should get some idea of the relative importance of the pure IPv4 core case as compared with IPv4 providing a tunnel substrate for connecting to the IPv6 transit backbone. Be that as it may, I suspect I may be lucky in having an 'enlightened' ISP and it might be necesssary for less lucky users to connect to a gateway onto the IPv6 backbone in some other domain than their own ISP's. In this case the thoughts in the draft probably apply to the connection between the "own ISP's" domain and the domain with the IPv6 backbone gateway. Regards, Elwyn From owner-v6ops@ops.ietf.org Thu Aug 25 12:36:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Ki0-0001bl-Ts for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:36:09 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28571 for ; Thu, 25 Aug 2005 12:36:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Kgy-0002FX-Sb for v6ops-data@psg.com; Thu, 25 Aug 2005 16:35:04 +0000 Received: from [194.138.37.39] (helo=lizzard.sbs.de) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Kgx-0002Ed-DP for v6ops@ops.ietf.org; Thu, 25 Aug 2005 16:35:03 +0000 Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id j7PGYuNm007166; Thu, 25 Aug 2005 18:34:56 +0200 Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net [157.163.133.201]) by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id j7PGYsgh026775; Thu, 25 Aug 2005 18:34:54 +0200 Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Aug 2005 18:34:53 +0200 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: I-D ACTION:draft-baker-v6ops-end2end-00.txt Date: Thu, 25 Aug 2005 18:34:53 +0200 Message-ID: Thread-Topic: I-D ACTION:draft-baker-v6ops-end2end-00.txt Thread-Index: AcWpkTGkeigqmRCBTSah52uDPlkAOAAALYEA From: "Sofia, Rute" To: "Elwyn Davies" , "Fred Baker" Cc: X-OriginalArrivalTime: 25 Aug 2005 16:34:53.0876 (UTC) FILETIME=[EBF21F40:01C5A992] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello, While I have to agree that the intention of pin-pointing failures in IPv4/IPv6 transition from an e2e perspective, this document falls short in doing so... What is currently missing in terms of e2e transition analysis is a doc which not only points out problems but also provides some guidelines in what concerns e2e transition, namely: - current mechanisms and onto which e2e scenarios they apply best; - approach multihoming scenarios=20 - approach multicast and current support for it in the transition (done in section 2.4 but in a very light way) - bi-directional transition (which is still weak even though some support is provided, e.g., by NAT64-46 or 6to4) - interworking between the different solutions, given that it is highly unlikely that a single transition mechanism is pursued by different operators, as we are currently seeing. Regards, Rute Sofia =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Elwyn Davies > Sent: Thursday, August 25, 2005 6:14 PM > To: Fred Baker > Cc: 'v6ops@ops.ietf.org ' > Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt >=20 > Hi. >=20 > The intention of this draft is excellent - using a single scheme for=20 > connecting across IPv4 clouds is clearly essential to achieve e2e=20 > interoperability in the world encapsulated in the diagrams. The=20 > question that comes to my mind is just how much does this represent a=20 > time that has already gone by? >=20 > The scenarios do not include situations where the IPv4 cloud is a=20 > convenient substrate to build a tunnel between an IPv6=20 > enabled stub and=20 > 'the' IPv6 transit backbone (which will be used until such time as=20 > native IPv6 connectivity arrives at the stub's attachment point(s)). >=20 > There are already global IPv6 transit providers, and sitting here in=20 > front of my home system, my ISP provides me with an IPv6 prefix and=20 > capability to use an IPv6-in-IPv4 tunnel to an endpoint in=20 > their network=20 > which then connects me onto the IPv6 backbone. >=20 > Hence before expending a lot of effort on determining (and=20 > 'marketing')=20 > whatever might be the 'best' solution in the pure IPv4 core case I=20 > believe we should get some idea of the relative importance of=20 > the pure=20 > IPv4 core case as compared with IPv4 providing a tunnel substrate for=20 > connecting to the IPv6 transit backbone. >=20 > Be that as it may, I suspect I may be lucky in having an=20 > 'enlightened'=20 > ISP and it might be necesssary for less lucky users to connect to a=20 > gateway onto the IPv6 backbone in some other domain than their own=20 > ISP's. In this case the thoughts in the draft probably apply to the=20 > connection between the "own ISP's" domain and the domain with=20 > the IPv6=20 > backbone gateway. >=20 > Regards, > Elwyn >=20 >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Thu Aug 25 12:47:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Kst-00061K-QS for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:47: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 MAA29198 for ; Thu, 25 Aug 2005 12:47:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8KsO-0003BS-VI for v6ops-data@psg.com; Thu, 25 Aug 2005 16:46:52 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8KsM-0003Au-09 for v6ops@ops.ietf.org; Thu, 25 Aug 2005 16:46:50 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7PGkjO22590; Thu, 25 Aug 2005 19:46:45 +0300 Date: Thu, 25 Aug 2005 19:46:45 +0300 (EEST) From: Pekka Savola To: Elwyn Davies cc: Fred Baker , "'v6ops@ops.ietf.org '" Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt In-Reply-To: <430DEE2D.5080904@dial.pipex.com> Message-ID: References: <430DEE2D.5080904@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 25 Aug 2005, Elwyn Davies wrote: > Hence before expending a lot of effort on determining (and 'marketing') > whatever might be the 'best' solution in the pure IPv4 core case I believe we > should get some idea of the relative importance of the pure IPv4 core case as > compared with IPv4 providing a tunnel substrate for connecting to the IPv6 > transit backbone. I had a little bit of the same concern. It seemed as if document was discussing solutions for end-to-end IPv6 connectivity mechanisms between two or more v4 islands (or vice versa for v4 and v6 islands). My take was similar to yours: we don't need end-to-end v6 connectivity *mechanisms* (provided by one site to another). We'll just ask the sites to connect to the v6 internet. They might do it via their direct upstream or someone else, but which one doesn't matter that much as long as the "v6 backbone" doesn't get fragmented. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Aug 25 12:55:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8L0K-00006i-8m for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 12:55: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 MAA29815 for ; Thu, 25 Aug 2005 12:55:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Kzy-0003xq-9j for v6ops-data@psg.com; Thu, 25 Aug 2005 16:54:42 +0000 Received: from [66.94.9.112] (helo=mailrelay.t-mobile.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Kzx-0003xZ-M1 for v6ops@ops.ietf.org; Thu, 25 Aug 2005 16:54:41 +0000 Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 94F6A99DA; Thu, 25 Aug 2005 11:45:59 -0500 (CDT) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13041-01; Thu, 25 Aug 2005 11:45:58 -0500 (CDT) Received: from [10.242.56.82] (82.56.242.10.in-addr.arpa [10.242.56.82]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Thu, 25 Aug 2005 11:45:58 -0500 (CDT) In-Reply-To: <936A4045C332714F975800409DE09240D6F457@tayexc14.americas.cpqcorp.net> References: <936A4045C332714F975800409DE09240D6F457@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7D6B395B-F36A-4582-AC72-00F4C939BFBA@cisco.com> Cc: , "John C. Bogard" Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Regrets for Mr. Alan E. Beard and some words Date: Thu, 25 Aug 2005 08:30:26 -0700 To: "Bound, Jim" X-Mailer: Apple Mail (2.734) X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Jim. I'm sure I speak for the working group, as you do, in mourning his passing. Our best to his family. On Aug 24, 2005, at 11:04 PM, Bound, Jim wrote: > Dear IETF V6OPS colleagues, > > It is with regret, that I have been asked to inform you that Mr. > Alan E. Beard has passed on from a heart attack. Alan was active > in our process to define transition scenarios and analysis within > V6OPS, and provided significant input to RFC 4057. His dear > colleague John C Bogard sent me this notice, and copied in this > mail. Alan's professional demeanor and ability to clearly > articulate his input to our processes, will be missed, but his > contributions have been noted in our community. If you have other > information regarding Alan's contributions please send mail to > John.C.Bogard@gte.net. Alan was John's mentor and he is greatly > missed by John. > > Sincerely, > /jim > > From owner-v6ops@ops.ietf.org Thu Aug 25 15:52:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Nlu-0007i8-Fd for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 15:52:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11523 for ; Thu, 25 Aug 2005 15:52:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Njf-000HVr-CF for v6ops-data@psg.com; Thu, 25 Aug 2005 19:50:03 +0000 Received: from [132.151.6.50] (helo=newodin.ietf.org) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8Nje-000HVN-KO for v6ops@ops.ietf.org; Thu, 25 Aug 2005 19:50:02 +0000 Received: from mlee by newodin.ietf.org with local (Exim 4.43) id 1E8Njd-0007X2-DV; Thu, 25 Aug 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-ipsec-tunnels-01.txt Message-Id: Date: Thu, 25 Aug 2005 15:50:01 -0400 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,MIME_BOUND_NEXTPART, NO_REAL_NAME autolearn=no version=3.0.2 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 : Using IPsec to Secure IPv6-in-IPv4 Tunnels Author(s) : P. Savola, et al. Filename : draft-ietf-v6ops-ipsec-tunnels-01.txt Pages : 22 Date : 2005-8-25 This document gives guidance on securing manually configured IPv6-in- IPv4 tunnels using IPsec. No additional protocol extensions are described beyond those available with the IPsec framework. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-01.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-v6ops-ipsec-tunnels-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --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-8-25144553.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-ipsec-tunnels-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-ipsec-tunnels-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-8-25144553.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Aug 25 19:14:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8Qvn-0005Oc-66 for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 19:14: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 TAA26787 for ; Thu, 25 Aug 2005 19:14:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8QtY-0007Sm-Fc for v6ops-data@psg.com; Thu, 25 Aug 2005 23:12:28 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8QtW-0007SP-Kf for v6ops@ops.ietf.org; Thu, 25 Aug 2005 23:12:26 +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 SAA22508; Thu, 25 Aug 2005 18:12: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 j7PNCLv13907; Thu, 25 Aug 2005 18:12:21 -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.211); Thu, 25 Aug 2005 16:12: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: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Date: Thu, 25 Aug 2005 16:12:19 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FE9@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Thread-Index: AcWjOq66xY2/EK6JQSyw7Tzzx4UE4QAOdbugAZTt7JA= From: "Templin, Fred L" To: , Cc: , "Templin, Fred L" X-OriginalArrivalTime: 25 Aug 2005 23:12:21.0636 (UTC) FILETIME=[72518440:01C5A9CA] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hello Fred and Kurt, On 8/17/05, I announced a new I-D on the v6ops list which (IMHO) identifies operational issues and proposes improvements for tunnel path mtu determination. Some on-list discussion followed. I would like to now ask whether this work can be taken as a v6ops WG item, given that it addresses operational aspects of mechanisms associated with the wg? Fred L. Templin fred.l.templin@boeing.com =20 -----Original Message----- From: Templin, Fred L=20 Sent: Wednesday, August 17, 2005 2:55 PM To: v6ops@ops.ietf.org Subject: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels"=20 A new draft of possible interest to v6ops is available that anticipates MTU-related performance issues for tunnels and proposes a solution. Document location and abstract appear below. Comments? Fred fred.l.templin@boeing.com http://www.ietf.org/internet-drafts/draft-templin-linkadapt-00.txt Abstract IPv6-in-IPv4 tunneling mechanisms support the minimum IPv6 MTU of 1280 bytes via static prearrangements at the tunnel encapsulator and/or dynamic MTU determination based on ICMPv4 messages, but these methods have known operational limitations. This document proposes a new MTU determination mechanism for IPv6-in-IPv4 tunnels that uses a link adaptation scheme with simplified IPv4 segmentation/reassembly and dynamic segment size probing. From owner-v6ops@ops.ietf.org Thu Aug 25 19:39:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8RK8-0005gs-19 for v6ops-archive@megatron.ietf.org; Thu, 25 Aug 2005 19:39:56 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28107 for ; Thu, 25 Aug 2005 19:39:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8RJV-0009KL-Pj for v6ops-data@psg.com; Thu, 25 Aug 2005 23:39:17 +0000 Received: from [203.101.113.39] (helo=wip-ec-wd.wipro.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8RJR-0009Jp-GD for v6ops@ops.ietf.org; Thu, 25 Aug 2005 23:39:14 +0000 Received: from wip-ec-wd.wipro.com (localhost.wipro.com [127.0.0.1]) by localhost (Postfix) with ESMTP id 84C4120620 for ; Fri, 26 Aug 2005 04:58:14 +0530 (IST) Received: from blr-ec-bh01.wipro.com (blr-ec-bh01.wipro.com [10.201.50.91]) by wip-ec-wd.wipro.com (Postfix) with ESMTP id 6931A2061E for ; Fri, 26 Aug 2005 04:58:14 +0530 (IST) Received: from chn-snr-bh1.wipro.com ([10.145.50.91]) by blr-ec-bh01.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 26 Aug 2005 05:09:10 +0530 Received: from mail pickup service by chn-snr-bh1.wipro.com with Microsoft SMTPSVC; Fri, 26 Aug 2005 05:08:56 +0530 Received: from wip-cdctls-mx15.wipro.com ([203.101.73.133]) by chn-snr-bh2.wipro.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 25 Aug 2005 18:18:08 +0530 Received: from wip-cdctls-mx4.wipro.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with ESMTP id 2D8252A800E; Thu, 25 Aug 2005 18:17:58 +0530 (IST) Received: from psg.com (psg.com [147.28.0.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by wip-cdctls-mx4.wipro.com (Postfix) with ESMTP id 8E9043F400F; Thu, 25 Aug 2005 18:15:35 +0530 (IST) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Gmu-00091a-Ge for v6ops-data@psg.com; Thu, 25 Aug 2005 12:24:56 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8Gms-00091I-7f for v6ops@ops.ietf.org; Thu, 25 Aug 2005 12:24:54 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7PCOqM17027 for ; Thu, 25 Aug 2005 15:24:52 +0300 Date: Thu, 25 Aug 2005 15:24:52 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: draft-ietf-v6ops-ipsec-tunnels-01.txt In-Reply-To: <42D8FBBD.2010506@dial.pipex.com> Message-ID: References: <42D8FBBD.2010506@dial.pipex.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 25 Aug 2005 12:48:08.0276 (UTC) FILETIME=[3E605140:01C5A973] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=unavailable version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, There were no WGLC comments. An update has been sent to the secretariat. The issue tracker has been updated at: http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html The updated draft is also available there. On Sat, 16 Jul 2005, Elwyn Davies wrote: > The latest version appears to address all the comments that I and others > made, and generally looks good (give or take a few editorial fixes - see > below). > > One minor issue with regard to the language used about how to model the > tunnel end-point when specific SPD tunnel mode is used: I am not sure that it > is up to this document to 'require' (s5.3, 2nd para) that they are not > modelled as separate interfaces. What we are saying is that it is not really > possible to build specific SPD tunnel mode on end points modelled as > interfaces... Therefore we recommend that specific SPD tunnel mode end points > should not be modelled as separate interfaces. This is followed through into > the reccommendations in s9 para 2: suggest s/support/recommend/. There ought > to be a better way of saying this but I can't think what it is at present. > > Regards, > Elwyn > > A number of language/editorial nits: > > s1: Unexpanded acronyms: SA, SPD, ECN (SA is expanded in s2.1) > s2: para 1: s/was mostly/is mostly/ > > s2: para 3: s/specifies following/specifies the following/, > s/measures./measures:/ > s2: paras4/5: make them bulleted paras to clarify that they are the > 'following measures' > > s2.1: para 1: s/The successful/A successful/ > > s2.1: last para: s/kind/kinds/ > > s2.1: last para: Unexpanded acronyms GRE, L2TP (maybe need references). > > s2.2: para 1: s/The successful/A successful/ > > s3.2: next-to-last para: Unexpanded acronyms ISP, CPE > > s4: The language in this section may become slightly less clear when the > drafts become RFCs > s4: para 2: s/is defined in [RFC2401] and [I-D.ietf-ipsec-rfc2401bis]/was > originally defined in [RFC2401] now superseded by > [I-D.ietf-ipsec-rfc2401bis]/ > s4: para 2: s/IPsec security/The IPsec security/, s/difference/differences/ > > s4: para 7: Move the first sentence {'IKE is defined in [RFC2409] (which is > referred to as IKE in this document) and in [I-D.ietf-ipsec-ikev2] (which is > referred to as IKEv2 in this document).'} to be the second sentence of para > 2. Start a new para after this, substituting s/them/the two versions of the > security architecture/. In the rest of the section - do what the IKE > sentence says - use IKE and IKEv2 consistently - IKEv1 -> IKE, places where > the IKE RFC/draft are used replaced by IKE/IKEv2 (e.g., Bullet point 3), para > 6) [Actually IKEv1 seems to be used pretty consistently in the rest of the > document!] > > s5: para 1: s/the IPsec tunnel establishment for/establishment of an IPsec > tunnel for the/, s/we'll/we will/, s/look on/look at/ > > s5: Figure 5: Might be more obvious as a 'boxed' table, maybe with column > headings 'Components (first to last)', 'Contains'. Also presumably the > packet has a payload! > > s5.2: para 1: delete 'kind of' > s5.2: para 3: s/whose tunnel endpoint's IPv4 address is/with tunnel endpoint > IPv4 addresses/ > s5.2: para 3: s/The implementations/Implementations/ > > s5.3.1: para 1: s/routing table/the routing table/, s/is passes/is passed/ > s5.3.1: para 3: s/prevent/prevent an attacker/ > > s7: para 2: s/the same way/in the same way/ > s7: bullet point 2: s/the NAT changes/where the NAT changes/ > s7: last para: s/MOBIKE/The IETF MOBIKE working group/ > > s8: 1st bullet: s/off-band/out-of-band/ > > s9: last para: s/is to either tunnel mode with generic SPDs or transport > mode, and applying/is to use either tunnel mode with generic SPDs or > transport mode, and apply/ > > s11: para 1: s/in the tunnel/into the tunnel/ > s11: para 2: s/to the both,/to both/ > > s11: para 3: IF you use IKE to mean IKEv1 then s/IKE/Either IKE or IKEv2/ - > If you go for IKEv1 explicitly, IKE is finr. > > References: Whether RC2401 and RFC2409 are normative is arguable! > > App A: para 2: s/associations are/association is, s/interfaces/an interface/ > > App A: throughout: s/destination/DST/ in rules (some already do) > > Pekka Savola wrote: > >> On Mon, 11 Jul 2005 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 : Using IPsec to Secure IPv6-in-IPv4 Tunnels >>> Author(s) : P. Savola, et al. >>> Filename : draft-ietf-v6ops-ipsec-tunnels-00.txt >>> Pages : 21 >>> Date : 2005-7-11 >>> >>> This document gives guidance on securing manually configured IPv6-in- >>> IPv4 tunnels using IPsec. No additional protocol extensions are >>> described beyond those available with the IPsec framework. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ipsec-tunnels-00.txt >> >> >> The authors believe that this version addresses all comments sent to date. >> >> There has been substantial revision in the draft. Those who previously >> read it are encouraged to take another look and see if it's better. If you >> haven't taken a look yet, now would be a good chance. >> >> The issue list is at: >> http://www.netcore.fi/pekkas/ietf/temp/ipsec-tunnels.html >> >> There's also a htmlwdiff there. >> > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Aug 26 04:02:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ZAr-0000pk-Sq for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 04:02: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 EAA03774 for ; Fri, 26 Aug 2005 04:02:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8Z7r-000JXy-HV for v6ops-data@psg.com; Fri, 26 Aug 2005 07:59:47 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.50 (FreeBSD)) id 1E8Z7q-000JXa-Bm for v6ops@ops.ietf.org; Fri, 26 Aug 2005 07:59:46 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.12.10/8.12.10) with ESMTP id j7Q7xhO0141072 for ; Fri, 26 Aug 2005 07:59:43 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j7Q7xhk3169764 for ; Fri, 26 Aug 2005 09:59:43 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.13.3) with ESMTP id j7Q7xhpp008356 for ; Fri, 26 Aug 2005 09:59:43 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j7Q7xgR7008345; Fri, 26 Aug 2005 09:59:42 +0200 Received: from zurich.ibm.com (sig-9-145-248-142.de.ibm.com [9.145.248.142]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA57474; Fri, 26 Aug 2005 09:59:40 +0200 Message-ID: <430ECBE5.1000108@zurich.ibm.com> Date: Fri, 26 Aug 2005 09:59:33 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Tim Chown CC: v6ops@ops.ietf.org Subject: Re: Last call on draft-ietf-v6ops-nap-01.txt References: <4B69BB71-F055-4216-B76A-3B3894EDB58C@cisco.com> <20050825141755.GA12237@login.ecs.soton.ac.uk> In-Reply-To: <20050825141755.GA12237@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > > +------------------|-----------------------|-----------------------+ > | Global Address | RFC 1918 | 340,282,366,920,938, | > | Pool | | 463,463,374,607,431, | > | Conservation | | 768,211,456 | > | | | (3.4*10^38) addresses| > | | see section 2.6 | see section 4.6 | > > >>>>> 2^128 addresses doesn't help if sites get given too big a prefix ;) Yes, this is a fairly silly way to state it. We should perhaps put ULAs, draft-narten-iana-rir-ipv6-considerations, and draft-narten-ipv6-3177bis-48boundary as the references here. Brian From owner-v6ops@ops.ietf.org Fri Aug 26 05:57:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8axV-0001J6-Fv for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 05:57: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 FAA08245 for ; Fri, 26 Aug 2005 05:57:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8avd-0001Zj-36 for v6ops-data@psg.com; Fri, 26 Aug 2005 09:55:17 +0000 Received: from [144.254.15.119] (helo=av-tac-bru.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8ava-0001ZF-OR for v6ops@ops.ietf.org; Fri, 26 Aug 2005 09:55:15 +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 j7Q9tDd11857 for ; Fri, 26 Aug 2005 11:55:13 +0200 (CEST) Received: from gvandeve-w2k01.cisco.com (ams-clip-vpn-dhcp293.cisco.com [10.61.65.37]) by strange-brew.cisco.com (8.11.7p1+Sun/8.11.7) with ESMTP id j7Q9tCp05625 for ; Fri, 26 Aug 2005 11:55:12 +0200 (CEST) Message-Id: <4.3.2.7.2.20050826101446.030f0008@strange-brew> X-Sender: gvandeve@strange-brew X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 26 Aug 2005 11:55:10 +0200 To: v6ops@ops.ietf.org From: "Gunter Van de Velde (gvandeve)" Subject: [ietf-v6ops-nap-01.txt] Proposed Resolution of Issues [1 - 10] Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Issue list to be found at: http://www.vandevelde.cc/ietf/NAP-Issue-Log.htm Issue 1: The idea is that the NAP draft will be Informational and hence i would not like to see it as Normative reference. It would however be good to see the draft from Tim published. Issue 2: Precisely *not*. A commodity boundary box can be configured to do all this without NAT - that is exactly why we have always said that the longest allocation by an ISP should be a /64 Isssue 3: Firewalls can do more as explained in the section, however the intention of s2.2 is to speak on the NAT vector as when used on a firewall and not to analyze all functions of the firewall. Issue 4: I'm unsure on how to interpret this issue so i could potentially integrate in the text if relevant. Issue 5: A solution without a NAT can provide indeed user/application tracking and that is amongst other concepts what the draft is about. Issue 6: from the issue I am not sure why port mapping makes things more difficult - the mappings may be *finer* grained allowing *better* tracking I don't completely agree that the mappings are *finer* grained or allow *better* tracking. My believe is that in both instances the available tracking information is identical as in both cases there is similar information. The difference is in the translations-slot and how the mapping list is constructed. One uses a mapping (assume traffic being sent from inside to outside the local network) purely based on IP addresses and keeping the source-port# unchanged, while the NAPT has in addition the source-port# changed. Hence i believe that the creation of a mapping list where two variables change (source IP address and source port numbers) is more difficult to achieve then one where the only one variable changes (source-IP address), so looking at this the text seems correct as it is. Any other opinions? Issue 7: The comment mentioned is correct, however i don't feel that s2.5 is the right place to mention this issue, as it is already mentioned in s2.7 and would potentially create additional repetitiveness. Issue 8: This item was discussed on the v6ops alias. My understanding of consensus was that it is widely used. Hence the text should remain unchanged for this issue. (if there are stats out there available, then we could potentially add some if that provides a stranger result?) Issue 9: Add context around the motivation on why multihoming: s/highly desirable to be/highly desirable due to resiliency and load-balancing to be/ I believe the 2th para of the issue is covered by: to be connected to more than one Internet Service Provider (ISP) and to be able to change ISPs at will. Issue 10: propose the following change of the text: Original: Similarly, if two enterprise IPv4 networks need to be merged, it may well be that installing a NAT box between them will avoid the need to renumber one or both. For any enterprise, this can be a short term financial saving, and allow more time to renumber the network components. The long term solution is a single network without usage of NAT to avoid the ongoing operational complexity of overlapping addresses. Revised: Similarly, if two enterprise IPv4 networks need to be merged and RFC1918 addresses are used, there is a probability to have address overlaps. In those situations it may well be that installing a NAT box between them will avoid the need to renumber one or both. For any enterprise, this can be a short term financial saving, and allow more time to renumber the network components. The long term solution is a single network without usage of NAT to avoid the ongoing operational complexity of overlapping addresses. Kind Regards, G/ From owner-v6ops@ops.ietf.org Fri Aug 26 11:38:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gHJ-00021f-5K for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:38: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 LAA27451 for ; Fri, 26 Aug 2005 11:37:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8gEM-0000eS-Lo for v6ops-data@psg.com; Fri, 26 Aug 2005 15:34:58 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8gEK-0000e9-Ka for v6ops@ops.ietf.org; Fri, 26 Aug 2005 15:34:56 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7QFYtmx007080 for ; Fri, 26 Aug 2005 16:34:55 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA22376 for ; Fri, 26 Aug 2005 16:34:46 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7QFYkE25213 for v6ops@ops.ietf.org; Fri, 26 Aug 2005 16:34:46 +0100 Date: Fri, 26 Aug 2005 16:34:46 +0100 From: Tim Chown To: "'v6ops@ops.ietf.org '" Subject: Re: I-D ACTION:draft-baker-v6ops-end2end-00.txt Message-ID: <20050826153446.GY5428@login.ecs.soton.ac.uk> Mail-Followup-To: "'v6ops@ops.ietf.org '" References: <430DEE2D.5080904@dial.pipex.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Aug 25, 2005 at 07:46:45PM +0300, Pekka Savola wrote: > On Thu, 25 Aug 2005, Elwyn Davies wrote: > >Hence before expending a lot of effort on determining (and 'marketing') > >whatever might be the 'best' solution in the pure IPv4 core case I believe > >we should get some idea of the relative importance of the pure IPv4 core > >case as compared with IPv4 providing a tunnel substrate for connecting to > >the IPv6 transit backbone. > > I had a little bit of the same concern. It seemed as if document was > discussing solutions for end-to-end IPv6 connectivity mechanisms > between two or more v4 islands (or vice versa for v4 and v6 islands). > > My take was similar to yours: we don't need end-to-end v6 connectivity > *mechanisms* (provided by one site to another). We'll just ask the > sites to connect to the v6 internet. They might do it via their > direct upstream or someone else, but which one doesn't matter that > much as long as the "v6 backbone" doesn't get fragmented. Seems we all got different thoughts from the document, which is probably a good sign :) It seemed to me that the less clear scenario was the one where an IPv6 only backbone is deployed and IPv4 transit still required. -- Tim/::1 From owner-v6ops@ops.ietf.org Fri Aug 26 11:52:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8gV7-0005vY-Cj for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 11:52: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 LAA28136 for ; Fri, 26 Aug 2005 11:52:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8gUU-0001tv-SN for v6ops-data@psg.com; Fri, 26 Aug 2005 15:51:38 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8gUR-0001tZ-U8 for v6ops@ops.ietf.org; Fri, 26 Aug 2005 15:51:35 +0000 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2005 08:51:35 -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 j7QFpXoo012874; Fri, 26 Aug 2005 08:51:33 -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 j7QFlTCV023258; Fri, 26 Aug 2005 08:47:30 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FE9@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FE9@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: <3369A5DD-B9CD-4398-9C5B-56BF23A35A1B@cisco.com> Cc: Lindqvist Erik Kurt , v6ops@ops.ietf.org Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Date: Fri, 26 Aug 2005 08:51:30 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=4191; t=1125071250; x=1125503450; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20=22Link=20Adaptation=20for=20IPv6-in-IPv4=20Tunnels=22=20as=20WG =20item?| From:Fred=20Baker=20| Date:Fri,=2026=20Aug=202005=2008=3A51=3A30=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=a1VWYtpMvoJ4UsVsVkg/JVIBKRladoaBDA6m3TMFiIcPQJCozCbc7uEy6/AW2ZXdJVT4Nn2o 3aIt3bjUX25cZ214K7jo2bYhaA+x5tm62dKWGTtyQaqbiCXu55WvCl3KwLnjlNXz7+Jaf0hBj4d fkcrFcXHaZG89du30walPX68= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Let me see first if I understand the protocol you are proposing. My simple network diagram is: +--------+ +--------+ | 6A | | 6B | +---+----+ +----+---+ | IPv6 IPv6 | /----+-----------+-----/ /-----+----------+----/ | | +---+----+ +----+---+ | 4A | | 4B | +---+----+ +----+---+ | IPv4 | /----+---------------+----/ 6A is sending IPv6 datagrams to 6B through the IPv4-only domain containing 4A and 4B. The means by which 4A determines 4B is not specified, but one might suggest that the tunnel is preconfigured and routing determines it through its mechanisms. So 6A sends IPv6 datagrams up to 9180 bytes in size, through a route containing 4A. 4A breaks the 9180 byte datagram up into 7 1280 byte segments plus a final 220 byte segment. It encapsulates the 8 segments into 8 successive tunnel datagrams, and uses the flags field to indicate that the IPv4 packet represents a single fragmented IPv4 datagram, but uses the IPv4 fragment offset field to indicate that they represent the blocks starting at bytes 0, 8, 16, 24, 32, 40, 48, and 56 of that datagram. Since the IPv4 implementation in 4B will reassemble the IPv4 datagram before attempting to interpret it (per RFCs 791, 1122, and 1812) or delivering it to anyone else to interpret, this last statement is a matter of some concern. 4B must implement a modified IPv4 reassembly algorithm, and it is not clear that there is a way in the IPv4 header to identify the packets to which that algorithm should be applied. The specification also expects that the data crossing the IPv4 domain will not be reordered. That is not per the Internet Architecture, which presumes a best effort service. The term "Best Effort" describes a network in which packets may be reordered, duplicated, or dropped at the network layer, and as a result higher layer protocols must provide coping mechanisms for these issues, not legislate them away. One thing that wasn't clear to me: where does the Fletcher Checksum get stored? I didn't see a specification for the protocol header containing that field. With that commentary, now I will return to your administrative question. I would say that this is not describing an operational procedure, but a protocol between IPv6-in-IPv4 tunnel endpoints. Our charter reads: 4. Publish Informational or BCP RFCs that identify and analyze solutions for deploying IPv6 within common network environments, such as ISP Networks, Enterprise Networks, Unmanaged Networks (Home/ Small Office), and Cellular Networks. These documents should serve as useful guides to network operators and users on possible ways how to deploy IPv6 within their existing IPv4 networks, as well as in new network installations. These documents should not be normative guides for IPv6 deployment, and the primary intent is not capture the needs for new solutions, but rather describe which approaches work and which do not. IPv6 operational and deployment issues with specific protocols or technologies (such as Applications, Transport Protocols, Routing Protocols, DNS or Sub-IP Protocols) are the primary responsibility of the groups or areas responsible for those protocols or technologies. However, the v6ops WG may provide input to those areas/ groups, as needed, and cooperate with those areas/groups in reviewing solutions to IPv6 operational and deployment problems. I would understand that we are authorized to provide commentary to some other working group regarding such a protocol, but not to develop it ourselves. If I am misunderstanding anything, please advise. On Aug 25, 2005, at 4:12 PM, Templin, Fred L wrote: > Hello Fred and Kurt, > > On 8/17/05, I announced a new I-D on the v6ops list which (IMHO) > identifies operational issues and proposes improvements for tunnel > path mtu determination. Some on-list discussion followed. > > I would like to now ask whether this work can be taken as a v6ops > WG item, given that it addresses operational aspects of mechanisms > associated with the wg? > > > Fred L. Templin > fred.l.templin@boeing.com > > > -----Original Message----- > From: Templin, Fred L > Sent: Wednesday, August 17, 2005 2:55 PM > To: v6ops@ops.ietf.org > Subject: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" > > A new draft of possible interest to v6ops is available > that anticipates MTU-related performance issues for > tunnels and proposes a solution. Document location > and abstract appear below. Comments? > > Fred > fred.l.templin@boeing.com > > http://www.ietf.org/internet-drafts/draft-templin-linkadapt-00.txt > > Abstract > IPv6-in-IPv4 tunneling mechanisms support the minimum IPv6 MTU of > 1280 bytes via static prearrangements at the tunnel encapsulator > and/or dynamic MTU determination based on ICMPv4 messages, but > these > methods have known operational limitations. This document > proposes a > new MTU determination mechanism for IPv6-in-IPv4 tunnels that > uses a > link adaptation scheme with simplified IPv4 segmentation/reassembly > and dynamic segment size probing. > From owner-v6ops@ops.ietf.org Fri Aug 26 18:00:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mF8-0005NL-GR for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 18:00:10 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24835 for ; Fri, 26 Aug 2005 18:00:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8mCu-000588-7m for v6ops-data@psg.com; Fri, 26 Aug 2005 21:57:52 +0000 Received: from [130.76.96.56] (helo=stl-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8mCr-00057g-Ko for v6ops@ops.ietf.org; Fri, 26 Aug 2005 21:57:49 +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 QAA22099; Fri, 26 Aug 2005 16:57:41 -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 j7QLvev13392; Fri, 26 Aug 2005 16:57:40 -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.211); Fri, 26 Aug 2005 14:57:27 -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: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Date: Fri, 26 Aug 2005 14:57:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FED@XCH-NW-7V2.nw.nos.boeing.com> Thread-Topic: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Thread-Index: AcWqVgrf/55b2y9jRH63XTiPwBdpmgAIbJOw From: "Templin, Fred L" To: "Fred Baker" Cc: "Lindqvist Erik Kurt" , X-OriginalArrivalTime: 26 Aug 2005 21:57:27.0005 (UTC) FILETIME=[25B900D0:01C5AA89] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred, Thank you for the feedback. It looks like you have identified an issue regarding the proposed use of fragment offset bits. The intention is not to re-write IPv4 fragmentation/reassembly but rather to aviod it and perform link adaptation (i.e., segmentation/reassembly) at a "layer 2.5" that sits above IPv4 but below IPv6. So, instead of (re)using the IPv4 header bits as currently specified, a small (8 bytes or less) L2.5 header that sits above the IPv4 header could be defined with: - a segment ID field (i.e., instead of using the fragment offset bits as in the current draft) - a "more fragments" bit - flow identifier fields - a next header field - etc. About packet reordering, there are some words about that throughout the document and also in the 4th paragraph of Appendix A. But, along with the new L2.5 header described above, the document could be re-worded to say that the IPv4 Identification field carries an ID used to protect against packet splicing errors due to reordering. (Idea is to have all L2.5 segments of the same L3 packet encode the same ID value in the Identification field of the IPv4 header.) About the checksum, it is encoded as a trailing 4-byte field immediately following the upper layer payload, i.e., it occurs as the final 4 bytes of the final segment in multi-segment datagrams rather than in a header field of some sort. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, August 26, 2005 8:52 AM > To: Templin, Fred L > Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org > Subject: Re: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? >=20 > Let me see first if I understand the protocol you are proposing. >=20 > My simple network diagram is: >=20 > +--------+ +--------+ > | 6A | | 6B | > +---+----+ +----+---+ > | IPv6 IPv6 | > /----+-----------+-----/ /-----+----------+----/ > | | > +---+----+ +----+---+ > | 4A | | 4B | > +---+----+ +----+---+ > | IPv4 | > /----+---------------+----/ >=20 > 6A is sending IPv6 datagrams to 6B through the IPv4-only domain =20 > containing 4A and 4B. The means by which 4A determines 4B is not =20 > specified, but one might suggest that the tunnel is=20 > preconfigured and =20 > routing determines it through its mechanisms. >=20 > So 6A sends IPv6 datagrams up to 9180 bytes in size, through a route =20 > containing 4A. 4A breaks the 9180 byte datagram up into 7 1280 byte =20 > segments plus a final 220 byte segment. It encapsulates the 8 =20 > segments into 8 successive tunnel datagrams, and uses the=20 > flags field =20 > to indicate that the IPv4 packet represents a single fragmented IPv4 =20 > datagram, but uses the IPv4 fragment offset field to indicate that =20 > they represent the blocks starting at bytes 0, 8, 16, 24, 32,=20 > 40, 48, =20 > and 56 of that datagram. >=20 > Since the IPv4 implementation in 4B will reassemble the IPv4=20 > datagram =20 > before attempting to interpret it (per RFCs 791, 1122, and 1812) or =20 > delivering it to anyone else to interpret, this last statement is a =20 > matter of some concern. 4B must implement a modified IPv4 reassembly =20 > algorithm, and it is not clear that there is a way in the=20 > IPv4 header =20 > to identify the packets to which that algorithm should be applied. >=20 > The specification also expects that the data crossing the=20 > IPv4 domain =20 > will not be reordered. That is not per the Internet Architecture, =20 > which presumes a best effort service. The term "Best Effort" =20 > describes a network in which packets may be reordered,=20 > duplicated, or =20 > dropped at the network layer, and as a result higher layer protocols =20 > must provide coping mechanisms for these issues, not legislate them =20 > away. >=20 > One thing that wasn't clear to me: where does the Fletcher Checksum =20 > get stored? I didn't see a specification for the protocol header =20 > containing that field. >=20 > With that commentary, now I will return to your administrative =20 > question. I would say that this is not describing an operational =20 > procedure, but a protocol between IPv6-in-IPv4 tunnel endpoints. Our =20 > charter reads: >=20 > 4. Publish Informational or BCP RFCs that identify=20 > and analyze > solutions > for deploying IPv6 within common network=20 > environments, such as > ISP Networks, Enterprise Networks, Unmanaged Networks (Home/=20 > Small > Office), and Cellular Networks. >=20 > These documents should serve as useful guides to network > operators and users on possible ways how to deploy IPv6 =20 > within their > existing IPv4 networks, as well as in new network =20 > installations. >=20 > These documents should not be normative guides for IPv6 =20 > deployment, > and the primary intent is not capture the needs for new =20 > solutions, > but rather describe which approaches work and which do not. >=20 > IPv6 operational and deployment issues with specific =20 > protocols or > technologies (such as Applications, Transport Protocols, =20 > Routing > Protocols, DNS or Sub-IP Protocols) are the primary =20 > responsibility of > the groups or areas responsible for those protocols or =20 > technologies. > However, the v6ops WG may provide input to those areas/=20 > groups, as > needed, and cooperate with those areas/groups in reviewing =20 > solutions > to IPv6 operational and deployment problems. >=20 > I would understand that we are authorized to provide commentary to =20 > some other working group regarding such a protocol, but not to =20 > develop it ourselves. >=20 > If I am misunderstanding anything, please advise. >=20 > On Aug 25, 2005, at 4:12 PM, Templin, Fred L wrote: >=20 > > Hello Fred and Kurt, > > > > On 8/17/05, I announced a new I-D on the v6ops list which (IMHO) =20 > > identifies operational issues and proposes improvements for tunnel =20 > > path mtu determination. Some on-list discussion followed. > > > > I would like to now ask whether this work can be taken as a v6ops =20 > > WG item, given that it addresses operational aspects of mechanisms =20 > > associated with the wg? > > > > > > Fred L. Templin > > fred.l.templin@boeing.com > > > > > > -----Original Message----- > > From: Templin, Fred L > > Sent: Wednesday, August 17, 2005 2:55 PM > > To: v6ops@ops.ietf.org > > Subject: New draft: "Link Adaptation for IPv6-in-IPv4 Tunnels" > > > > A new draft of possible interest to v6ops is available > > that anticipates MTU-related performance issues for > > tunnels and proposes a solution. Document location > > and abstract appear below. Comments? > > > > Fred > > fred.l.templin@boeing.com > > > > http://www.ietf.org/internet-drafts/draft-templin-linkadapt-00.txt > > > > Abstract > > IPv6-in-IPv4 tunneling mechanisms support the minimum IPv6 MTU of > > 1280 bytes via static prearrangements at the tunnel encapsulator > > and/or dynamic MTU determination based on ICMPv4 messages, but =20 > > these > > methods have known operational limitations. This document =20 > > proposes a > > new MTU determination mechanism for IPv6-in-IPv4 tunnels that =20 > > uses a > > link adaptation scheme with simplified IPv4=20 > segmentation/reassembly > > and dynamic segment size probing. > > >=20 From owner-v6ops@ops.ietf.org Fri Aug 26 18:14:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8mT6-0000Ux-Lj for v6ops-archive@megatron.ietf.org; Fri, 26 Aug 2005 18:14: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 SAA26029 for ; Fri, 26 Aug 2005 18:14:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E8mSV-0006bd-Vs for v6ops-data@psg.com; Fri, 26 Aug 2005 22:13:59 +0000 Received: from [171.71.176.71] (helo=sj-iport-2.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E8mSU-0006bN-C0 for v6ops@ops.ietf.org; Fri, 26 Aug 2005 22:13:58 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 26 Aug 2005 15:13:58 -0700 Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j7QMDq0J023980; Fri, 26 Aug 2005 15:13:52 -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 j7QM9pH5027700; Fri, 26 Aug 2005 15:09:51 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FED@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FED@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: <991DEC30-0DC2-4E9E-94D7-C2E443D2F04F@cisco.com> Cc: "Lindqvist Erik Kurt" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? Date: Fri, 26 Aug 2005 15:13:53 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=527; t=1125094191; x=1125526391; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20=22Link=20Adaptation=20for=20IPv6-in-IPv4=20Tunnels=22=20as=20WG =20item?| From:Fred=20Baker=20| Date:Fri,=2026=20Aug=202005=2015=3A13=3A53=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=ZbtLVBWA2W6nT1KWQ0vw9pSMJxzuPCvGDQh10NmJDr6U1p77S445G4p5M3loIYOYk/FbT7MK JldXtpTEJLUU+LgUqeby1cvt4BkMCfh0GIe1EFOfIzCi+4DKkzhIZDdQii67nyM/j0QpmEIIz/a j6N+sifF2ye40z+cHMx9ZKTQ= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit yup, it's a protocol. We're not chartered to do protocols; in fact, our charter specifically says we are NOT to do protocols. I'm going to have to ask you to take it elsewhere. I'd suggest a discussion with the AD as to where he would recommend it go. On Aug 26, 2005, at 2:57 PM, Templin, Fred L wrote: > instead of (re)using the IPv4 header > bits as currently specified, a small (8 bytes or less) L2.5 > header that sits above the IPv4 header could be defined with: > > - a segment ID field (i.e., instead of using the > fragment offset bits as in the current draft) > - a "more fragments" bit > - flow identifier fields > - a next header field > - etc. > From owner-v6ops@ops.ietf.org Mon Aug 29 03:38:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9eDw-00029y-Pr for v6ops-archive@megatron.ietf.org; Mon, 29 Aug 2005 03:38:32 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22399 for ; Mon, 29 Aug 2005 03:38:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9eAM-00076R-Jr for v6ops-data@psg.com; Mon, 29 Aug 2005 07:34:50 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9eAL-00076A-Bh for v6ops@ops.ietf.org; Mon, 29 Aug 2005 07:34:49 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7T7YdI21577; Mon, 29 Aug 2005 10:34:41 +0300 Date: Mon, 29 Aug 2005 10:34:39 +0300 (EEST) From: Pekka Savola To: Francis Dupont cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> Message-ID: References: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 25 Aug 2005, Francis Dupont wrote: > Remember, we're offering *v6* as an end-to-end protocol which doesn't > have to deal with NAT etc. In that light providing this functionality > for v4 might even be counterproductive :) > > => and say that RFC 1918 and a NAT will solve any problem is productive :) ? Yes -- at least it will encourage people to see the benefits of v6 in a different light :) > > => Do you argue there is not realistic scenarios where there is no > > choice and the IPv4 address space has to aggressively be conserved? > > No, I'm not saying that. What I'm saying is that people will use > different (simpler) tools to perform this conservation. The easiest > one at their disposal is RFC1918 and NAT. > > => NAT is not a general solution: it doesn't work with embedded addresses. > So you have no real counter-argument. Yes, it doesn't work, but what I'm asking here is a reality check. I guess what you're saying is that some sites have binary-only, 10+ old applications which have embedded addresses. Those applications work just fine if you use them internally in the site only (using RFC1918 addresses). Do you want to provide such an application to the outside? -- REALLY? Even if you do, I don't think a site has dozens of such applications on dozens of hosts. Those applications are required to work reliably (otherwise they would not still be provided, at great pains). Thus I don't see why the addresses would need to be set up and torn down dynamically -- manual config would probably be more reliable and more useful. Or do you want to use such an application (provided by someone else) from the outside? Again, I'm not sure if I'd buy the argument that these are commonplace enough to be worth the trouble -- remember that NATs are already so widely deployed, that these applications cannot be used from the majority of the networks. > My argument is that let people use RFC1918, NAT, or whatever > mechanisms they want for *v4* address conservation, let us focus on > *v6* transition, not finding means how to prolong v4 address usage > under aggressive conservation. > > => the purpose of the v6ops document is to help to solve problems, > not to enforce something. So as the previous scenario is credible > DTSM (i.e. c)) has to be referenced. I don't think the purpose of any v6ops document is solve problems in one's *v4* network by *v4* mechanisms, so it's not entirely clear if the mechanism is in the scope of this WG. > but that's a separate point -- or how you'd prevent premature > revokation of the address w/ a lifetime..) > > => I can't see what is the "premature revokation" here: if an address > is still in use and is near to expire, just renew? If an application is still in use (but the host may have very much difficulty in figuring out whether it's used or not!), the address lease should not expire, otherwise you've prematurely taken off an address and the application ceases to work. > I think you are proposing something that seems to significantly differ > from what has been deployed today: DHCPv4 is typically used to give > you an address "for good" (to be refreshed periodically though). It > doesn't have provisions (AFAICS) to detect whether the address is in > use or not when deciding whether to try to refresh the lease or not. > > => in fact it is very easy to do because the problem is not about > the address use but the global IPv4 use. In my implementation I > simply use the reference count of the default route because the > neighbor cache is implemented as cloned children of it. I'm not sure I understand the implementation well enough to say whether that would work or not (I guess it will work as long as the application regularly sends packets and "uses" the default route), but how would that work for a server application which just binds to an address and doesn't send out anything? Or a client application which just happens to sit quietly for some time? > You're adding a component of potentially fragile nature in the system. > > => anything is potentially fragile. Do you really believe that a NAT > is not fragile? Sure, NAT can be fragile as well. The users and administrators typically understand the main fragilities of NATs though. This is of a different kind. The mechanisms used by DSTM are typically implementation-dependent (such as the way you use the default route refcount). So, every implementor has to figure out his/her own mechanisms on your own, and each approach is likely to have some issues; the specification cannot help here as there we're too deep in the realm of implementation-specificity. As I said earlier, this approach may or may not be something that a vendor could implement, but there don't seem to be bits in the wire that need standardizing, and the generic concept is probably NOT something we want to specify due to its fragilities, implementation-specificity, etc. > > Just say there is a binary only application using embedded addresses > > (unfortunately not a silly assumption, don't forget this is about > > enterprise scenarios). > > Such applications likely work fine through a TCP proxy or NAT? > > => they don't work through a NAT so an ALG is needed per application... > Can I add "encrypted" or "ciphered" before embedded? Are we talking about the same (very old, binary-only) applications? The strongest encryption in these I've seen has been "XOR" (for just a part of the payload), and even that was a surprise :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 29 06:02:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gTY-0004r4-OS for v6ops-archive@megatron.ietf.org; Mon, 29 Aug 2005 06:02:48 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27859 for ; Mon, 29 Aug 2005 06:02:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9gRM-000N78-5l for v6ops-data@psg.com; Mon, 29 Aug 2005 10:00:32 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9gRJ-000N6h-0l for v6ops@ops.ietf.org; Mon, 29 Aug 2005 10:00:29 +0000 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j7TA0BL30557; Mon, 29 Aug 2005 12:00:11 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j7TA0Bu3050073; Mon, 29 Aug 2005 12:00:11 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200508291000.j7TA0Bu3050073@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Savola cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-reply-to: Your message of Mon, 29 Aug 2005 10:34:39 +0300. Date: Mon, 29 Aug 2005 12:00:11 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: > => NAT is not a general solution: it doesn't work with embedded addresses. > So you have no real counter-argument. Yes, it doesn't work, but what I'm asking here is a reality check. => sorry but I am tired to discuss about this topics. You don't want to consider cases where NATs cannot be used or where people don't want to use NATs, and this point is obviously NOT in the scope of the WG. > => the purpose of the v6ops document is to help to solve problems, > not to enforce something. So as the previous scenario is credible > DTSM (i.e. c)) has to be referenced. I don't think the purpose of any v6ops document is solve problems in one's *v4* network by *v4* mechanisms, => DSTM is not a *v4* mechanism. so it's not entirely clear if the mechanism is in the scope of this WG. => DSTM and relevant scenarios are, this discussion is not. I'm not sure I understand the implementation well enough to say whether that would work or not => it works even the implementation way I discribed works only for some kernels (for other kernels the PCB table has to be scanned for instance because routes are not referenced by PCBs). Do you claim that DSTM is not implementable? Regards Francis.Dupont@enst-bretagne.fr PS: this is my final message about the topics. From owner-v6ops@ops.ietf.org Mon Aug 29 06:03:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9gU6-0004tk-J0 for v6ops-archive@megatron.ietf.org; Mon, 29 Aug 2005 06:03:22 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27872 for ; Mon, 29 Aug 2005 06:03:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9gTt-000NXG-UA for v6ops-data@psg.com; Mon, 29 Aug 2005 10:03:09 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9gTs-000NWy-12 for v6ops@ops.ietf.org; Mon, 29 Aug 2005 10:03:08 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7TA37YO010009 for ; Mon, 29 Aug 2005 11:03:07 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id LAA01128 for ; Mon, 29 Aug 2005 11:02:58 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7TA2w925774 for v6ops@ops.ietf.org; Mon, 29 Aug 2005 11:02:58 +0100 Date: Mon, 29 Aug 2005 11:02:58 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM Message-ID: <20050829100258.GB25556@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote: > > I don't think the purpose of any v6ops document is solve problems in > one's *v4* network by *v4* mechanisms, so it's not entirely clear if > the mechanism is in the scope of this WG. If you deplay a v6-only network infrastructure then v4 transport is a 'v6 problem'. I guess he crux of your argument is a) why not run dual stack, even with v4+NAT b) why can't apps be updated to use IPv6 Tim From owner-v6ops@ops.ietf.org Mon Aug 29 06:38:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9h1z-0000pY-3G for v6ops-archive@megatron.ietf.org; Mon, 29 Aug 2005 06:38: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 GAA29160 for ; Mon, 29 Aug 2005 06:38:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9h15-0001KZ-Cg for v6ops-data@psg.com; Mon, 29 Aug 2005 10:37:27 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9h13-0001HP-BT for v6ops@ops.ietf.org; Mon, 29 Aug 2005 10:37:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7TAbIN24978; Mon, 29 Aug 2005 13:37:20 +0300 Date: Mon, 29 Aug 2005 13:37:18 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <20050829100258.GB25556@login.ecs.soton.ac.uk> Message-ID: References: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> <20050829100258.GB25556@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 29 Aug 2005, Tim Chown wrote: > On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote: >> I don't think the purpose of any v6ops document is solve problems in >> one's *v4* network by *v4* mechanisms, so it's not entirely clear if >> the mechanism is in the scope of this WG. > > If you deplay a v6-only network infrastructure then v4 transport is a 'v6 > problem'. I guess he crux of your argument is > a) why not run dual stack, even with v4+NAT > b) why can't apps be updated to use IPv6 Depends on what you mean by 'dual stack'. For this particular thread, I think my main arguments are: - if you want to run v6-only network but dual-stack hosts, that's fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario a) or b.1) from the list below. HOWEVER, I don't see why you [in practical scenarios] need mechanisms to give (very) temporary global v4 addresses on the nodes, and then take them away (e.g., c) or d) from the list below). You can just deploy private v4 addresses if you have address shortage, or use more stable v4 global addresses. - the mechanisms which go beyond DHCPv4-like functions for address assignment on v4-in-v6 tunnels do not have any bits-on-the-wire interoperability requirements, and thus do not require standardization. Such mechanisms can also be brittle and very implementation-specific, and I'd be hesitant to even try to encourage them. - the DSTM spec is not clear enough on its scope and intent and should not be referred to in a WG document. My own take here is (if I understand the intent of the spec) that we don't (anymore) require a document like that, but rather should concentrate (in some other WG like softwires, it's out of charter here) on creating the actual protocol specification(s). ......................... a) (manually configured) v4-in-v6 tunnels [RFC2473] b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel server(s) which can happen without user intervention, e.g., using a process described in draft-palet-v6ops-tun-auto-disc-03.txt. This must include a way to auto-configure a v4 address [e.g., DHCPv4-like method]. b.2) the automatic set-up of v4-in-v6 tunnels, so that between each host, an ad-hoc tunnel can be signalled and set up" [6to4-like traffic optimization] [ everything below here doesn't have any direct bits-on-the-wire interop requirement (maybe except e), it can be just a local vendor's optimization ] c) assignment of an address on top of v4-in-v6 tunnel(s), but deferred until the application wants to create v4 socket. [issues with dual-stack server apps, for example] d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when an address lifetime expires (and is not renewed) d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) when the host detects it no longer needs the address/connectivity e) plus a number of extensions for even more colorful setups (e.g., instead of just assigning an address, assign only certain _ports_ of an address). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Mon Aug 29 22:33:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9vw0-0000rH-Ln for v6ops-archive@megatron.ietf.org; Mon, 29 Aug 2005 22:33: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 WAA01395 for ; Mon, 29 Aug 2005 22:33:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9vtO-0005CL-IA for v6ops-data@psg.com; Tue, 30 Aug 2005 02:30:30 +0000 Received: from [130.76.32.69] (helo=blv-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9vtK-00057V-K7 for v6ops@ops.ietf.org; Tue, 30 Aug 2005 02:30:26 +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 TAA13592; Mon, 29 Aug 2005 19:30:17 -0700 (PDT) Received: from XCH-NWBH-10.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 j7U2UGv01676; Mon, 29 Aug 2005 21:30:16 -0500 (CDT) 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.0); Mon, 29 Aug 2005 19:30:14 -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 Date: Mon, 29 Aug 2005 19:30:14 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF1@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcWtCsCYh0pvLF3tTLi3sP7iUlYvvw== From: "Templin, Fred L" To: "Fred Baker" Cc: "Lindqvist Erik Kurt" , X-OriginalArrivalTime: 30 Aug 2005 02:30:14.0602 (UTC) FILETIME=[C0CF5AA0:01C5AD0A] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,MISSING_SUBJECT autolearn=no version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred, Agree that moving fragmentation bits to an ULP header would constitute a new IP protocol, however I believe there are other alternatives which would not. One way would be to perform host- based vanilla IPv4 fragmentation at the tunnel encapsulator (and set the DF flag in each fragment) but that has the limitation that often only first-fragments of fragmented datagrams are able to pass through firewalls and NATs. Another method would be to define a new form of IPv4 fragmentation ("Type-2 IPv4 fragmentation") that works as follows: - at the tunnel encapslator: - fragment packets into segments no larger than the IPv4 path MTU minus protocol headers. Each segment is encapsulated in an IPv4 header *plus* the protocol header indicated by the ip-protocol field. - set the DF flag in the encapsulating IPv4 header of each fragment and set the MF flag in each fragment except the final one. Also, set the Reserved fragmentation flag in each fragment to indicate Type-2 IPv4 fragmentation. - Redefine the 16-bit IPv4 Identification field as an 11-bit ID in the least-significant bits and a 5-bit Segment number in the most significant bits. For each segment in a multi-segment packet, the value in the ID field would be the same, and the value in the Segment field would encode 0, 1, 2, etc. up to 31. - Set the 13-bit Fragment Offset field to 0 in each fragment=20 - at the tunnel decapsulator, intercept Type-2 IPv4 fragments before they are handled by the vanilla IPv4 reassembly engine and reassemble them accordingly=20 This Type-2 IPv4 fragmentation would only be supported by tunnel decapsulators that provide instrumentation to intercept fragments with the Reserved flag set, but encapsulators could probe to detect whether individual decapsulators are "Type-2 enabled" and drop back to the default behavior for those that do not. Type-2 fragmentation also has the feature that each fragment in a multi-fragment tunneled packet would appear to the network as though it were a first-fragment since the ULP header is included and the Fragment Offset field is zero in each fragment, so all fragments would pass through firewalls and NATs. In terms of v6ops charter requirements, Type-2 IPv4 fragmentation would not introduce any new header fields outside of the IPv4 header and would be used with pre-existing protocols that already have ip-protocol numbers assigned in the registry. So, can we call this a new (extension, mechanism, method, etc.) instead of a new protocol and run it past the v6ops charter again? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Friday, August 26, 2005 3:14 PM > To: Templin, Fred L > Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org > Subject: Re: "Link Adaptation for IPv6-in-IPv4 Tunnels" as WG item? >=20 > yup, it's a protocol. >=20 > We're not chartered to do protocols; in fact, our charter =20 > specifically says we are NOT to do protocols. I'm going to have to =20 > ask you to take it elsewhere. I'd suggest a discussion with=20 > the AD as =20 > to where he would recommend it go. >=20 > On Aug 26, 2005, at 2:57 PM, Templin, Fred L wrote: >=20 > > instead of (re)using the IPv4 header > > bits as currently specified, a small (8 bytes or less) L2.5 > > header that sits above the IPv4 header could be defined with: > > > > - a segment ID field (i.e., instead of using the > > fragment offset bits as in the current draft) > > - a "more fragments" bit > > - flow identifier fields > > - a next header field > > - etc. > > >=20 From owner-v6ops@ops.ietf.org Tue Aug 30 00:28:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9xjJ-0000jP-C3 for v6ops-archive@megatron.ietf.org; Tue, 30 Aug 2005 00:28: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 AAA05881 for ; Tue, 30 Aug 2005 00:28:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1E9xhp-000NE3-94 for v6ops-data@psg.com; Tue, 30 Aug 2005 04:26:41 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1E9xho-000NDo-Cs for v6ops@ops.ietf.org; Tue, 30 Aug 2005 04:26:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7U4OBr13636; Tue, 30 Aug 2005 07:24:15 +0300 Date: Tue, 30 Aug 2005 07:24:11 +0300 (EEST) From: Pekka Savola To: "Templin, Fred L" cc: Fred Baker , Lindqvist Erik Kurt , v6ops@ops.ietf.org Subject: Re: your mail In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF1@XCH-NW-7V2.nw.nos.boeing.com> Message-ID: References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF1@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 29 Aug 2005, Templin, Fred L wrote: > So, can we call this a new (extension, mechanism, method, etc.) > instead of a new protocol and run it past the v6ops charter again? I do not think this fits in the charter of the group no matter how it's termed; I don't think we do either mechanisms (encapsulations) OR v4 enhancements. -- 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 Aug 30 05:28:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA2Q7-0004nM-TS for v6ops-archive@megatron.ietf.org; Tue, 30 Aug 2005 05:28: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 FAA01412 for ; Tue, 30 Aug 2005 05:28:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EA2N3-000JH4-Ab for v6ops-data@psg.com; Tue, 30 Aug 2005 09:25:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EA2N2-000JB6-7h for v6ops@ops.ietf.org; Tue, 30 Aug 2005 09:25:32 +0000 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id j7U9PUYO005139 for ; Tue, 30 Aug 2005 10:25:30 +0100 (BST) Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id KAA25128 for ; Tue, 30 Aug 2005 10:24:56 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id j7U9Oti00547 for v6ops@ops.ietf.org; Tue, 30 Aug 2005 10:24:55 +0100 Date: Tue, 30 Aug 2005 10:24:55 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM Message-ID: <20050830092455.GH32000@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> <20050829100258.GB25556@login.ecs.soton.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 29, 2005 at 01:37:18PM +0300, Pekka Savola wrote: > On Mon, 29 Aug 2005, Tim Chown wrote: > >On Mon, Aug 29, 2005 at 10:34:39AM +0300, Pekka Savola wrote: > >>I don't think the purpose of any v6ops document is solve problems in > >>one's *v4* network by *v4* mechanisms, so it's not entirely clear if > >>the mechanism is in the scope of this WG. > > > >If you deplay a v6-only network infrastructure then v4 transport is a 'v6 > >problem'. I guess he crux of your argument is > >a) why not run dual stack, even with v4+NAT > >b) why can't apps be updated to use IPv6 > > Depends on what you mean by 'dual stack'. Sorry, I meant 'on the wire'. To agree that something 'DSTM-like' is going to be necessary, we have to assume and agree that IPv6-only infrastructures will be deployed where some nodes have to use IPv4 communications. I think we agree on that. > For this particular thread, I think my main arguments are: > > - if you want to run v6-only network but dual-stack hosts, that's > fine, you can run stuff in v4-in-v6 tunnels -- for example, scenario > a) or b.1) from the list below. So far so good :) > HOWEVER, I don't see why you [in > practical scenarios] need mechanisms to give (very) temporary global > v4 addresses on the nodes, and then take them away (e.g., c) or d) > from the list below). You can just deploy private v4 addresses if you > have address shortage, or use more stable v4 global addresses. Well, there is a tradeoff. You could run IPv4+NAT on all the nodes that need IPv4. If you have enough IPv4 global addresses you could run stable permanent addresses on all those nodes. Either of these could/should use tunnel setup and address allocation mechanisms that could also be used by something 'DSTM-like'. But if you have limited IPv4 global addresses, and would like to avoid NAT, then some form of dynamic, short-term addressing is desirable. I guess the question then is how realistic a scenario is that? > - the mechanisms which go beyond DHCPv4-like functions for address > assignment on v4-in-v6 tunnels do not have any bits-on-the-wire > interoperability requirements, and thus do not require > standardization. Such mechanisms can also be brittle and very > implementation-specific, and I'd be hesitant to even try to encourage > them. Agreed, whether the protocol is used for short-term or long-term addressing, the mechanism can be the same. Something 'DSTM-like' *could* be used for scenarios with long-term stable addresses in use. In principle there could be a mix of long-term stable global addresses (servers) and IPv4+NAT (clients) on the network. If the site's only IPv4 communication requirements over IPv6 infrastructure are internal, then private IPv4 addresses should be just fine. > - the DSTM spec is not clear enough on its scope and intent and > should not be referred to in a WG document. My own take here is (if I > understand the intent of the spec) that we don't (anymore) require a > document like that, but rather should concentrate (in some other WG > like softwires, it's out of charter here) on creating the actual > protocol specification(s). Which is exactly what was suggested - take the 'DSTM-like' requirements and potential solutions into the softwires WG. But I would still maintain that the ent-analysis must include the 'IPv6 dominant' scenario, talk about the issues we've discussed on this list, and can cite DSTM as an example (the only example to date?) of a solution approach. The text can also say that further work on nailing down the 'DSTM-like' protocol details is required, and could even recommend that that happens in softwires. That's pretty similar to how Teredo was supported in the unman analysis I recall. What actually emerges from softwires, well, we'll just have to wait and see; so far there hasn't been any charter discussion. -- Tim/::1 > ......................... > > a) (manually configured) v4-in-v6 tunnels [RFC2473] > > b.1) the set-up of the bidirectional v4-in-v6 tunnel with the tunnel > server(s) which can happen without user intervention, e.g., using > a process described in draft-palet-v6ops-tun-auto-disc-03.txt. > This must include a way to auto-configure a v4 address [e.g., > DHCPv4-like method]. > > b.2) the automatic set-up of v4-in-v6 tunnels, so that between each > host, an ad-hoc tunnel can be signalled and set up" [6to4-like > traffic optimization] > > [ everything below here doesn't have any direct bits-on-the-wire > interop requirement (maybe except e), it can be just a local vendor's > optimization ] > > c) assignment of an address on top of v4-in-v6 tunnel(s), but > deferred until the application wants to create v4 socket. > [issues with dual-stack server apps, for example] > > d.1) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) > when an address lifetime expires (and is not renewed) > > d.2) automatic monitoring and tear-down of said v4-over-v6 tunnel(s) > when the host detects it no longer needs the address/connectivity > > e) plus a number of extensions for even more colorful setups (e.g., > instead of just assigning an address, assign only certain _ports_ > of an address). > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Aug 30 05:43:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EA2eP-0000dT-L3 for v6ops-archive@megatron.ietf.org; Tue, 30 Aug 2005 05:43:29 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01935 for ; Tue, 30 Aug 2005 05:43:26 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EA2dw-000Lu0-1D for v6ops-data@psg.com; Tue, 30 Aug 2005 09:43:00 +0000 Received: from [158.38.60.10] (helo=tyholt.uninett.no) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EA2dt-000Lti-UM for v6ops@ops.ietf.org; Tue, 30 Aug 2005 09:42:58 +0000 Received: from storhaugen.uninett.no (storhaugen.uninett.no [IPv6:2001:700:1:7:211:d8ff:fe8f:1f9b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id j7U9guTb016610; Tue, 30 Aug 2005 11:42:56 +0200 Received: from storhaugen.uninett.no (localhost.localdomain [127.0.0.1]) by storhaugen.uninett.no (8.13.1/8.12.9) with ESMTP id j7U9guId017153; Tue, 30 Aug 2005 11:42:56 +0200 Received: (from venaas@localhost) by storhaugen.uninett.no (8.13.1/8.13.1/Submit) id j7U9gtTw017152; Tue, 30 Aug 2005 11:42:55 +0200 X-Authentication-Warning: storhaugen.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 30 Aug 2005 11:42:55 +0200 From: Stig Venaas To: Christian Huitema Cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM Message-ID: <20050830094255.GA17023@storhaugen.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Aug 22, 2005 at 11:37:21AM -0700, Christian Huitema wrote: > > > While DHCPv4 may or may not require minor tweaks (e.g., relating to > > link-layer adaptation), > > > > => using DHCPv4 over a tunnel is *not* a minor tweak. > > Let see. Assume that you have a native IPv6 "site", over which you can > reliably send multicast packets. Assume that we have defined IPv6 > multicast addresses that reach all the nodes within that scope. Then, > you can pretty much port DHCP and ARP over that scope, using the node's > IPv6 address instead of the Ethernet address. You obtain a basic "IPv4 > over IPv6" solution. It is hard to be simpler than that. Sounds quite a bit like 6over4 (: Stig From owner-v6ops@ops.ietf.org Tue Aug 30 18:19:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAESF-0000IN-4l for v6ops-archive@megatron.ietf.org; Tue, 30 Aug 2005 18:19: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 SAA13442 for ; Tue, 30 Aug 2005 18:19:39 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAEQC-000G5O-Lk for v6ops-data@psg.com; Tue, 30 Aug 2005 22:17:36 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAEQC-000G5B-2k for v6ops@ops.ietf.org; Tue, 30 Aug 2005 22:17:36 +0000 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Aug 2005 15:17:35 -0700 X-IronPort-AV: i="3.96,154,1122879600"; d="scan'208"; a="337289339:sNHT33264904" 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 j7UMHWoo022121; Tue, 30 Aug 2005 15:17:32 -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 j7UMDDr5031221; Tue, 30 Aug 2005 15:13:14 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF1@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF1@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: <38233BA8-40CD-49E0-AEA5-9E9BA84EB858@cisco.com> Cc: "Lindqvist Erik Kurt" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: Date: Tue, 30 Aug 2005 15:17:30 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=434; t=1125439994; x=1125872194; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20| From:Fred=20Baker=20| Date:Tue,=2030=20Aug=202005=2015=3A17=3A30=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=RKkH7NppxH0h8eP//KhIaS9C1tj5NU6serQqXnIrpe/RnClUAvFboonsUMmxNciL+FK1sWUj E3qUJEVFMw3m4ThWaHNkUReyma398+Fs9E6W8pJdW2RQOZSUP0ldgkId4eH0KugYYbRoDS8M/8I SRhQPehxx+NHxwLjTjBRT5fQ= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit On Aug 29, 2005, at 7:30 PM, Templin, Fred L wrote: > So, can we call this a new (extension, mechanism, method, etc.) > instead of a new protocol and run it past the v6ops charter again? If it uses IPv4 fields but re-interprets them in a way that RFCs 791, 1122/3, 1812, 1349, and 2474 don't discuss, it is a change to IPv4. I would suggest discussing it in a working group that suggests modifications to IPv4. If it's implemented in a header outside of IPv4, it's a new protocol, and needs to be discussed in a WG that deals with that. From owner-v6ops@ops.ietf.org Wed Aug 31 02:25:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAM25-0002mB-Rt for v6ops-archive@megatron.ietf.org; Wed, 31 Aug 2005 02:25: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 CAA27125 for ; Wed, 31 Aug 2005 02:25:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EALzf-0002qK-I4 for v6ops-data@psg.com; Wed, 31 Aug 2005 06:22:43 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EALzc-0002pj-EU for v6ops@ops.ietf.org; Wed, 31 Aug 2005 06:22:40 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id j7V6MVq11998; Wed, 31 Aug 2005 09:22:35 +0300 Date: Wed, 31 Aug 2005 09:22:31 +0300 (EEST) From: Pekka Savola To: Tim Chown cc: v6ops@ops.ietf.org Subject: Re: WGLC ent-analysis-03: DSTM In-Reply-To: <20050830092455.GH32000@login.ecs.soton.ac.uk> Message-ID: References: <200508250910.j7P9ADJQ033156@givry.rennes.enst-bretagne.fr> <20050829100258.GB25556@login.ecs.soton.ac.uk> <20050830092455.GH32000@login.ecs.soton.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 30 Aug 2005, Tim Chown wrote: >> HOWEVER, I don't see why you [in >> practical scenarios] need mechanisms to give (very) temporary global >> v4 addresses on the nodes, and then take them away (e.g., c) or d) >> from the list below). You can just deploy private v4 addresses if you >> have address shortage, or use more stable v4 global addresses. > > Well, there is a tradeoff. You could run IPv4+NAT on all the nodes that > need IPv4. If you have enough IPv4 global addresses you could run stable > permanent addresses on all those nodes. Either of these could/should use > tunnel setup and address allocation mechanisms that could also be used > by something 'DSTM-like'. > > But if you have limited IPv4 global addresses, and would like to avoid NAT, > then some form of dynamic, short-term addressing is desirable. I guess the > question then is how realistic a scenario is that? Yes that's the question, and in addition, "is this something v6ops WG should be concerned about?" I don't think that's given -- our business is (IMHO) not extending the life of (public) IPv4 addresses, becuase there are alternatives (get more addresses; use private addresses; use proxies) If someone wants to create a clear specification how you do that, get a WG started or whatever, that's OK, but let's not discuss or recommend it here. >> - the DSTM spec is not clear enough on its scope and intent and >> should not be referred to in a WG document. My own take here is (if I >> understand the intent of the spec) that we don't (anymore) require a >> document like that, but rather should concentrate (in some other WG >> like softwires, it's out of charter here) on creating the actual >> protocol specification(s). > > Which is exactly what was suggested - take the 'DSTM-like' requirements and > potential solutions into the softwires WG. > > But I would still maintain that the ent-analysis must include the 'IPv6 > dominant' scenario, talk about the issues we've discussed on this list, I've no objection with this. > and > can cite DSTM as an example (the only example to date?) of a solution > approach. I do object to this though, as I think DSTM will do more to confuse the readers than help -- becuase it seems to be trying to describe both a number of concepts and a bunch or protocols that could be used to fulfill the concepts (and the protocols are not interoperable). Note that TSP for example (which can be one implementation of DSTM "concept") already includes most if not functionality -- certainly (AFAICS) everything that's needed for interoperability. > The text can also say that further work on nailing down the > 'DSTM-like' protocol details is required, and could even recommend that that > happens in softwires. That's pretty similar to how Teredo was supported > in the unman analysis I recall. > > What actually emerges from softwires, well, we'll just have to wait and see; > so far there hasn't been any charter discussion. Lot's of stuff should happen on softwires (or somewhere else but not here, as we're explicitly chartered NOT to do protocols). But IMHO, we just can't reference a half-baked spec at this point. It's fine (and recommended!) to discuss these requirements in the enterprise analysis, e.g., based on the list of a) - d) goals I included in the previous message. But pointing at specs should be done with great care because many of those specs may not be clear enough on what their scope is (for example, I think TSP spec is clear enough -- it's clearly defines a protocol specification with a definite scope). -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Wed Aug 31 18:34:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbAE-0001LS-09 for v6ops-archive@megatron.ietf.org; Wed, 31 Aug 2005 18:34:38 -0400 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22129 for ; Wed, 31 Aug 2005 18:34:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAb5L-000AkC-2g for v6ops-data@psg.com; Wed, 31 Aug 2005 22:29:35 +0000 Received: from [130.76.64.48] (helo=slb-smtpout-01.boeing.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAb5J-000Aju-4q for v6ops@ops.ietf.org; Wed, 31 Aug 2005 22:29:33 +0000 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA19515; Wed, 31 Aug 2005 15:29: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 j7VMTPv27673; Wed, 31 Aug 2005 17:29:25 -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.211); Wed, 31 Aug 2005 15:29:20 -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: Date: Wed, 31 Aug 2005 15:29:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF2@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcWtsKELbGf1ORW0RhmurU/VNIfXowAwmogg From: "Templin, Fred L" To: "Fred Baker" Cc: "Lindqvist Erik Kurt" , X-OriginalArrivalTime: 31 Aug 2005 22:29:20.0888 (UTC) FILETIME=[6E8D1F80:01C5AE7B] X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Fred, What I suggested in my previous message was more dramatic (and complicated) than what is really needed. If the tunnel encapsulator simply defines for itself a coding for the 16-bit IPv4 Identification field such as the following: 0 1 =20 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |A|Segment #| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ then the requirements of RFC 791 (and the others) are observed and there is no change to IPv4. The bits encoded in the field would include a 10-bit ID, a 1-bit Auxilliary fragmentation flag and a 5-bit Segment number for use by the tunnel decapsulator to reassemble a packet that was segmented according to the link adaptation spec. There is no need for a "Type-2 IPv4 fragmentation", there is no need to set the Reserved fragmentation bit and there is no interaction with ordinary IPv4 fragmentation/reassembly regardless of the setting of the DF bit. All that is needed is for the decapsulator to have a means for receiving the 16-bit Identification field intact following IPv4 reassembly and a means for the encapsulator to discover whether the decapsulator implements the link adaptation scheme. One concern is that the actual Identifier is shrunk down to 10 bits instead of 16, meaning that the degree of packet reordering in the network should be such that packets are rarely mis-ordered by more than 1024 places. This is part of the motivation for using a checksum to detect packet splicing errors such as suggested by the link adapatation document. Does this help address your concerns regarding changes to IPv4 and defining new protocols? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Fred Baker [mailto:fred@cisco.com]=20 > Sent: Tuesday, August 30, 2005 3:18 PM > To: Templin, Fred L > Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org > Subject: Re:=20 >=20 > On Aug 29, 2005, at 7:30 PM, Templin, Fred L wrote: > > So, can we call this a new (extension, mechanism, method, etc.) =20 > > instead of a new protocol and run it past the v6ops charter again? >=20 > If it uses IPv4 fields but re-interprets them in a way that=20 > RFCs 791, =20 > 1122/3, 1812, 1349, and 2474 don't discuss, it is a change to=20 > IPv4. I =20 > would suggest discussing it in a working group that suggests =20 > modifications to IPv4. If it's implemented in a header outside of =20 > IPv4, it's a new protocol, and needs to be discussed in a WG that =20 > deals with that. >=20 From owner-v6ops@ops.ietf.org Wed Aug 31 19:01:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAbaP-0000TR-BL for v6ops-archive@megatron.ietf.org; Wed, 31 Aug 2005 19:01: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 TAA24870 for ; Wed, 31 Aug 2005 19:01:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.50 (FreeBSD)) id 1EAbZm-000HWU-KI for v6ops-data@psg.com; Wed, 31 Aug 2005 23:01:02 +0000 Received: from [171.71.176.72] (helo=sj-iport-3.cisco.com) by psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1EAbZk-000HW5-Lm for v6ops@ops.ietf.org; Wed, 31 Aug 2005 23:01:00 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 31 Aug 2005 16:01:00 -0700 X-IronPort-AV: i="3.96,158,1122879600"; d="scan'208"; a="337738917:sNHT33940972" 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 j7VN0sQM029863; Wed, 31 Aug 2005 16:00:54 -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 j7VMuYOC011492; Wed, 31 Aug 2005 15:56:35 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF2@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A10D4FF2@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: <687055A0-2F5D-46A0-977A-FBC606E89C23@cisco.com> Cc: "Lindqvist Erik Kurt" , Content-Transfer-Encoding: 7bit From: Fred Baker Subject: Re: RE: Date: Wed, 31 Aug 2005 16:00:54 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.734) DKIM-Signature: a=rsa-sha1; q=dns; l=2765; t=1125528995; x=1125961195; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=fred@cisco.com; z=Subject:Re=3A=20RE=3A=20| From:Fred=20Baker=20| Date:Wed,=2031=20Aug=202005=2016=3A00=3A54=20-0700| Content-Type:text/plain=3B=20charset=3DUS-ASCII=3B=20delsp=3Dyes=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=A7GyAfY3leSQ/4L0PJRIMBFBReXO9u0gsvKn/RFlFbGABeCM/ePfDyNosVZkS176kyfPEbsA HvCiLXK3Y7YOIu9i+3Tkd1+OCsp941jjlJVBJ1mVLI72eBsvda0Q2jqelxfevav3Rsrky+x1tkf Zvi9S7Tph9oYm9vyOHMN0OMs= Authentication-Results: imail.cisco.com; header.From=fred@cisco.com; dkim=pass ( message from cisco.com verified; ); X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on psg.com X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit no, it doesn't, for two reasons. First, in a best effort network, it is invalid to presume that order will be preserved in the network. Second, changing the identifier field in IPv4 from 16 bits to 10 and using the remaining bits to indicate something else is a change to the identifier field in IPv4. RFC 791 and RFC 1122 merely specify that the identifiers should be locally unique within a field of time, not that they have certain characteristics from which other functionality may be deduced. I really not trying to be a pain here, but you really need to take this to a working group that does protocols, and specifically in this case, does changes to IPv4. v6ops can develop requirements for such a protocol if you like, but the protocol work needs to be done somewhere appropriate to the protocol. On Aug 31, 2005, at 3:29 PM, Templin, Fred L wrote: > Fred, > > What I suggested in my previous message was more dramatic > (and complicated) than what is really needed. If the tunnel > encapsulator simply defines for itself a coding for the > 16-bit IPv4 Identification field such as the following: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Identification |A|Segment #| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > then the requirements of RFC 791 (and the others) are observed > and there is no change to IPv4. > > The bits encoded in the field would include a 10-bit ID, a > 1-bit Auxilliary fragmentation flag and a 5-bit Segment number > for use by the tunnel decapsulator to reassemble a packet that > was segmented according to the link adaptation spec. There is > no need for a "Type-2 IPv4 fragmentation", there is no need to > set the Reserved fragmentation bit and there is no interaction > with ordinary IPv4 fragmentation/reassembly regardless of the > setting of the DF bit. > > All that is needed is for the decapsulator to have a means for > receiving the 16-bit Identification field intact following IPv4 > reassembly and a means for the encapsulator to discover whether > the decapsulator implements the link adaptation scheme. > > One concern is that the actual Identifier is shrunk down to > 10 bits instead of 16, meaning that the degree of packet > reordering in the network should be such that packets are > rarely mis-ordered by more than 1024 places. This is part of > the motivation for using a checksum to detect packet splicing > errors such as suggested by the link adapatation document. > > Does this help address your concerns regarding changes to IPv4 > and defining new protocols? > > Fred > fred.l.templin@boeing.com > > >> -----Original Message----- >> From: Fred Baker [mailto:fred@cisco.com] >> Sent: Tuesday, August 30, 2005 3:18 PM >> To: Templin, Fred L >> Cc: Lindqvist Erik Kurt; v6ops@ops.ietf.org >> Subject: Re: >> >> On Aug 29, 2005, at 7:30 PM, Templin, Fred L wrote: >> >>> So, can we call this a new (extension, mechanism, method, etc.) >>> instead of a new protocol and run it past the v6ops charter again? >>> >> >> If it uses IPv4 fields but re-interprets them in a way that >> RFCs 791, >> 1122/3, 1812, 1349, and 2474 don't discuss, it is a change to >> IPv4. I >> would suggest discussing it in a working group that suggests >> modifications to IPv4. If it's implemented in a header outside of >> IPv4, it's a new protocol, and needs to be discussed in a WG that >> deals with that. >> >