From owner-v6ops@ops.ietf.org Fri Oct 1 01:19:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07552 for ; Fri, 1 Oct 2004 01:19:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDFmW-000Fp6-Rb for v6ops-data@psg.com; Fri, 01 Oct 2004 05:16:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDFmL-000Fmp-Sk for v6ops@ops.ietf.org; Fri, 01 Oct 2004 05:16:26 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i915GLc32307; Fri, 1 Oct 2004 08:16:22 +0300 Date: Fri, 1 Oct 2004 08:16:21 +0300 (EEST) From: Pekka Savola To: Erik Nordmark cc: v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement In-Reply-To: <415C606B.1040901@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 30 Sep 2004, Erik Nordmark wrote: > > I was saying that with s/mechanism/requirements/ > > > > I.e., having requirements in separate documents, allowing them to be > > developed separately, does not mean that the solutions need to be > > different. Similarly, if all the requirements for different scenarios > > were in the same document, it wouldn't mean that one solution would > > have to fulfill all the requirements. > > But you were excluding the "simple" from the assisted tunneling > requirements, and I don't understand why. If this is all about > allowing different communities needing to express their requirements in > a separate document, then don't exclude things from the documents. This is probably a terminology issue. 'simple assisted tunneling' (providing simple access by 1st hop ISPs) is considered pretty much synonomous with 'generic zero-configutation tunneling', so if a new generic zct requirements document ends up being written, it would cover 'simple' as well, just under a different name. Removing it from the 'assisted tunneling' document would help focus the document to be solely about 'registered assisted tunneling', which is often a completely different problem space (providing access by 3rd party ISPs). > > (Completely personal opinion below) > > The critical thing will be whether the IETF 'honors' the 3GPP > > deadlines for a [standards track] solution (November this year). As > > you write, doing so would be very counterproductive. On the other > > hand, it could be also considered practical and admitting the reality. > > However, as such ISATAP will already go for Experimental RFC, so there > > will exist some documentation to create interoperable implementations > > in any case. There doesn't seem to be any particular reason to move > > it to standards track just because of 3GPP. > > If the purpose of the 3GPP requirements is solely to convince the IETF > that they will use ISATAP (which they might have already decided), why > are we wasting time on a 3GPP requirements document? It's already pretty much done except for the fact that a more generic solution would also fit the bill, if not for the timing considerations. > A requirements document makes sense when multiple answers are > acceptable, but you seem to be saying that only one answer would be > acceptable. Depends on how people interpret 'acceptable'. :) -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Fri Oct 1 09:35:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28587 for ; Fri, 1 Oct 2004 09:35:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDNWB-0001rz-4U for v6ops-data@psg.com; Fri, 01 Oct 2004 13:32:15 +0000 Received: from [193.180.251.49] (helo=albatross.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDNVh-0001pE-Bu for v6ops@ops.ietf.org; Fri, 01 Oct 2004 13:31:45 +0000 Received: from esealmw141.al.sw.ericsson.se ([153.88.254.120]) by albatross.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i91DViWR008791 for ; Fri, 1 Oct 2004 15:31:44 +0200 (MEST) Received: from esealnt610.al.sw.ericsson.se ([153.88.254.120]) by esealmw141.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Fri, 1 Oct 2004 15:31:44 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt610.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id TNGMBVAT; Fri, 1 Oct 2004 15:31:42 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Oct 2004 15:31:42 +0200 Message-ID: X-Sybari-Trust: 2d4eb288 74898554 9c4ef71b 00000139 From: "Karen E. Nielsen (AH/TED)" To: "'Erik Nordmark'" , Pekka Savola , "'Tim Chown'" Cc: v6ops@ops.ietf.org Subject: RE: Going forward with zero-config tunneling requirement Date: Fri, 1 Oct 2004 15:31:40 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-OriginalArrivalTime: 01 Oct 2004 13:31:44.0354 (UTC) FILETIME=[FE302420:01C4A7BA] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Erik, Pekka, All It is true that some, me included, find Isatap to be an adequate solution for 3GPP. It is, however, not so that the 3GPP requirements/goals in zeroconf are specified with Isatap in mind. In any case not more so that in the complex process of distinguishing nice-to-have from need-to-have things then one, of several, things that you may squint at is what is known to be achievable, and in this respect the features provided by Isatap is _one_ example of the latter. But as the authors of zero-conf can testify then we have been extremely careful with not adding something as a requirement simply because it is achievable - and likewise the other way around. The background behind the 3GPP requirements document, read zero-conf, is the following: For some time now 3GPP has asked for the support of the IETF to produce a standardised, solid tunnelling solution that meets its needs. Isatap has been identified by some as a potential solution, and have been successfully deployed in proto-type like 3GPP deployment environments. Consequently people have pressed for the standardization of Isatap and by standardisation here then I do not mean "rubber stamping" of the draft but about qualified technical challenging, tie of loose ends, adjustments of possible problems - all the things that the IETF normally do when making a "standard". v6ops have been reluctant to do so, and the answer has been a mixture of the following: * must wait until all scenarios have been considered, should find unified solution that fits all * the requirements of 3GPP aren't clear - why do you think Isatap is good for you ? * Isatap is limited, bad, not the right solution Here it is probably important for me to emphasize that I absolutely agree that finding one unified solution and/or limiting the solution space the best we can, would be great, from a pure technical, from an implementation as well as from a deployment perspective. The problem we have, however, is the following: No adequate standard has been produced which suits the needs of 3GPP and without a trusted and consolidated IETF solution then in turn the transition scenario and its solution space risk being completely written out of the 3GPP releases (to the extend that is hasn't already been suppressed as a feasible and recommendable scenario). Release 6 still include the transition scenario, but the absolutely HARD deadline of this is November something. Furthermore, Ipv6 and Ipv6/Ipv4 transition 3GPP deployment trials are starting up, the latter obviously also in need of a solution, preferably a committed IETF solution. Zero-conf aims to specify requirements of a simple tunnelling mechanism, which would suit the needs of 3GPP (possibly also other scenarios). Now that the requirements at least are written down, the hope was this could facilitate and speed up the process towards finding a solution. It has been discussed how to proceed from here and an attempted resolution was to split the 3GPP requirements in one separate document and produce another one which would detail the other scenarios needs in the area of zero-configuration tunnelling. The objective of isolating the 3GPP requirements is not because the same split is envisaged as automatically mapping over to the solution space. It is done first and foremost because of the following: * The timing requirements of 3GPP are very harsh and it was thought that we could not afford to loose time by potentially blurring the requirements by the addition of various other aspects to the document. That being said, it is clear, of course, that in order for us to be able knowingly to choose a solution which applies not only to the 3GPP scenario, but also to e.g. the simple enterprise scenario, then the requirements work of these other scenarios must move very fast too. BR, Karen > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On > Behalf Of Erik Nordmark > Sent: Thursday, September 30, 2004 9:37 PM > To: Pekka Savola > Cc: v6ops@ops.ietf.org > Subject: Re: Going forward with zero-config tunneling requirement > > > Pekka Savola wrote: > > > I was saying that with s/mechanism/requirements/ > > > > I.e., having requirements in separate documents, allowing > them to be > > developed separately, does not mean that the solutions need to be > > different. Similarly, if all the requirements for > different scenarios > > were in the same document, it wouldn't mean that one solution would > > have to fulfill all the requirements. > > But you were excluding the "simple" from the assisted tunneling > requirements, and I don't understand why. If this is all about > allowing different communities needing to express their > requirements in > a separate document, then don't exclude things from the documents. > > > > (Completely personal opinion below) > > The critical thing will be whether the IETF 'honors' the 3GPP > > deadlines for a [standards track] solution (November this year). As > > you write, doing so would be very counterproductive. On the other > > hand, it could be also considered practical and admitting > the reality. > > However, as such ISATAP will already go for Experimental > RFC, so there > > will exist some documentation to create interoperable > implementations > > in any case. There doesn't seem to be any particular reason to move > > it to standards track just because of 3GPP. > > If the purpose of the 3GPP requirements is solely to convince the IETF > that they will use ISATAP (which they might have already > decided), why > are we wasting time on a 3GPP requirements document? > A requirements document makes sense when multiple answers are > acceptable, but you seem to be saying that only one answer would be > acceptable. > > I don't have a problem with an experimental RFC describing ISATAP as > currently implemented, and perhaps a separate document describing its > limitations. > > Erik > > From owner-v6ops@ops.ietf.org Fri Oct 1 12:28:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21033 for ; Fri, 1 Oct 2004 12:28:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDQEo-0004zV-Ch for v6ops-data@psg.com; Fri, 01 Oct 2004 16:26:30 +0000 Received: from [192.18.42.14] (helo=nwkea-mail-2.sun.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDQEd-0004yc-NW for v6ops@ops.ietf.org; Fri, 01 Oct 2004 16:26:19 +0000 Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id i91GQ335019331; Fri, 1 Oct 2004 09:26:04 -0700 (PDT) Received: from [192.9.61.11] (punchin-nordmark.SFBay.Sun.COM [192.9.61.11]) by bebop.France.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id i91GQ1JQ013785; Fri, 1 Oct 2004 18:26:02 +0200 (MEST) Message-ID: <415D8541.9030004@sun.com> Date: Fri, 01 Oct 2004 09:26:41 -0700 From: Erik Nordmark User-Agent: Mozilla Thunderbird 0.8 (X11/20040916) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Karen E. Nielsen (AH/TED)" CC: Pekka Savola , "'Tim Chown'" , v6ops@ops.ietf.org Subject: Re: Going forward with zero-config tunneling requirement References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Karen E. Nielsen (AH/TED) wrote: > For some time now 3GPP has asked for the support of the IETF > to produce a standardised, solid tunnelling solution that > meets its needs. > > Isatap has been identified by some as a potential solution, > and have been successfully deployed in > proto-type like 3GPP deployment environments. > Consequently people have pressed for the standardization of Isatap and > by standardisation here then I do not mean "rubber stamping" of the draft but > about qualified technical challenging, tie of loose ends, adjustments of possible > problems - all the things that the IETF normally do when making a "standard". 1. 3GPP wants quality output from the IETF. > * The timing requirements of 3GPP are very harsh and it was thought that we could not afford to loose time > by potentially blurring the requirements by the addition of various other aspects to the document. 2. 3GPP needs it by November. > That being said, it is clear, of course, that in order for us to be able knowingly to choose a solution which > applies not only to the 3GPP scenario, but also to e.g. the simple enterprise scenario, then the requirements work > of these other scenarios must move very fast too. 3. We would all want to avoid too many mechanisms i.e. try to have mechanisms which apply for multiple scenarios. 1-3 is an overconstrained problem. I would argue that 2 is incompatible with 1. Why can't 3GPP just define a way to carry the IPv4 address of a tunnel endpoint in the 3GPP protocol which configures the IPv4 address of the terminal (whatever this protocol is called)? That would provide one solution which satisfies #2. Then we have time to work on a solution which satisfies #1 and #3. Erik From owner-v6ops@ops.ietf.org Fri Oct 1 14:27:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04361 for ; Fri, 1 Oct 2004 14:27:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDS54-000Ll1-3K for v6ops-data@psg.com; Fri, 01 Oct 2004 18:24:34 +0000 Received: from [66.218.79.80] (helo=web80510.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CDS4V-000LeI-D7 for v6ops@ops.ietf.org; Fri, 01 Oct 2004 18:23:59 +0000 Message-ID: <20041001182359.37645.qmail@web80510.mail.yahoo.com> Received: from [63.197.18.101] by web80510.mail.yahoo.com via HTTP; Fri, 01 Oct 2004 11:23:59 PDT Date: Fri, 1 Oct 2004 11:23:59 -0700 (PDT) From: Fred Templin Subject: Re: Going forward with zero-config tunneling requirement To: Erik Nordmark , "Karen E. Nielsen \(AH/TED\)" Cc: Pekka Savola , "'Tim Chown'" , v6ops@ops.ietf.org In-Reply-To: <415D8541.9030004@sun.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1179569193-1096655039=:4589" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1179569193-1096655039=:4589 Content-Type: text/plain; charset=us-ascii Erik Nordmark wrote: > 2. 3GPP needs it by November. The only reasons I could see for such a hard-and-fast deadline would be if: a) there were near-unanimous agreement that the best possible solution was in-hand, and the issue becomes one of time-to-market, or: b) a better (and perhaps inevitable) technical solution were looming on the horizon, and some would try to block it from happening to protect selfish interests. I have received quite a bit of feedback about ISATAP - both positive and negative. But, I have not seen compelling evidence to support a) - only evidence to the contrary. If the nature of the push is instead about b), and the b) people get their way, then the enduring legacy of the IETF will be one of having snatched defeat from the jaws of victory. > 3. We would all want to avoid too many mechanisms i.e. try to have > mechanisms which apply for multiple scenarios. I may have been one of the first to use the phrase: "no one-size-fits-all" in relation to transition mechanisms almost exactly 2 years ago. I did not know what I was talking about at the time, and (like the bad dog that gets his nose rubbed in it) have spent the better part of these past 2 years eating those words through a painful discovery process. It seems to me that there is a unified solution on the horizon that can apply to all scenarios. I'm still not 100% certain as to whether ancillary mechanisms are needed, but if they are then: 1) they are *very* few in number, and 2) the big picture has to be about the unified solution; *not* the ancillary mechanisms. Thanks - Fred osprey67@yahoo.com --0-1179569193-1096655039=:4589 Content-Type: text/html; charset=us-ascii


Erik Nordmark <erik.nordmark@sun.com> wrote:
 
> 2. 3GPP needs it by November.
 
 
The only reasons I could see for such a hard-and-fast deadline would be if:
a) there were near-unanimous agreement that the best possible solution
was in-hand, and the issue becomes one of time-to-market, or: b) a better
(and perhaps inevitable) technical solution were looming on the horizon,
and some would try to block it from happening to protect selfish interests.
 
I have received quite a bit of feedback about ISATAP - both positive and
negative. But, I have not seen compelling evidence to support a) - only
evidence to the contrary.
 
If the nature of the push is instead about b), and the b) people get their
way, then the enduring legacy of the IETF will be one of having snatched
defeat from the jaws of victory.


> 3. We would all want to avoid too many mechanisms i.e. try to have
> mechanisms which apply for multiple scenarios.
 
 
I may have been one of the first to use the phrase: "no one-size-fits-all"
in relation to transition mechanisms almost exactly 2 years ago. I did
not know what I was talking about at the time, and (like the bad dog
that gets his nose rubbed in it) have spent the better part of these past
2 years eating those words through a painful discovery process.
 
It seems to me that there is a unified solution on the horizon that can
apply to all scenarios. I'm still not 100% certain as to whether ancillary
mechanisms are needed, but if they are then: 1) they are *very* few
in number, and 2) the big picture has to be about the unified solution;
*not* the ancillary mechanisms.
 
Thanks - Fred
--0-1179569193-1096655039=:4589-- From owner-v6ops@ops.ietf.org Sat Oct 2 15:01:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02276 for ; Sat, 2 Oct 2004 15:01:01 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CDp46-000KFF-2k for v6ops-data@psg.com; Sat, 02 Oct 2004 18:57:06 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CDp45-000KEy-3F for v6ops@ops.ietf.org; Sat, 02 Oct 2004 18:57:05 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i92Iv3514564 for ; Sat, 2 Oct 2004 21:57:03 +0300 Date: Sat, 2 Oct 2004 21:57:02 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: PS on vacation Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk FYI, (I'm posting on the list because the deadlines are getting nearer and I hope nobody expects quick response..) I'll be leaving for a week's vacation tomorrow. I may or may not have access to email. btw. enterprise analysis doc (in particular) STILL needs review! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 5 05:19:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA06052 for ; Tue, 5 Oct 2004 05:19:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CElPn-00086E-3G for v6ops-data@psg.com; Tue, 05 Oct 2004 09:15:23 +0000 Received: from [158.182.6.1] (helo=karpos.comp.hkbu.edu.hk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CElPl-00085f-Q3 for v6ops@ops.ietf.org; Tue, 05 Oct 2004 09:15:22 +0000 Received: from chenyan (cs7135.comp.hkbu.edu.hk [158.182.7.135]) by karpos.comp.hkbu.edu.hk (8.12.11/8.12.11) with SMTP id i959FGl8001411 for ; Tue, 5 Oct 2004 17:15:16 +0800 (CST) Message-ID: <001401c4aabb$6ce59cd0$8707b69e@chenyan> From: "Chen Yan" To: References: <20041001182359.37645.qmail@web80510.mail.yahoo.com> Subject: why the usagi-linux26-s****.tar.bz2 is unavailable? Date: Tue, 5 Oct 2004 17:12:23 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C4AAFE.7AE43DD0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C4AAFE.7AE43DD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear All, I am just a newer to study Linux for IPV6. My linux core is 2.6.I want to add usagi to support IPV6 appication. But = I try several usagi such as: usagi-linux26-s****.tar.bz2, all are = unavailable. Whould you please tell me why and what I should do ? And another question: How can I add a 6to4 tunnel?=20 Thank you ! Yale RRS716 CS Department HKBU ------=_NextPart_000_0011_01C4AAFE.7AE43DD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear All,
 
I am just a newer to study Linux for = IPV6.
 
My linux core is 2.6.I want to add usagi to support = IPV6=20 appication. But I try several usagi such as: = usagi-linux26-s****.tar.bz2, all=20 are unavailable.
Whould you please tell me why and what I should do=20 ?
 
And another question:
How can I add a 6to4 tunnel?
 
Thank you !
 
Yale
RRS716
CS Department
HKBU
 
------=_NextPart_000_0011_01C4AAFE.7AE43DD0-- From owner-v6ops@ops.ietf.org Tue Oct 5 09:31:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27062 for ; Tue, 5 Oct 2004 09:31:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CEpMf-0009fJ-7o for v6ops-data@psg.com; Tue, 05 Oct 2004 13:28:25 +0000 Received: from [24.110.4.55] (helo=sleekfreak.ath.cx) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CEpMe-0009f5-Ig for v6ops@ops.ietf.org; Tue, 05 Oct 2004 13:28:24 +0000 Received: from localhost ([127.0.0.1]) by sleekfreak.ath.cx with esmtp (Exim 3.36 #1 (Debian)) id 1CEkfE-0004cn-00; Tue, 05 Oct 2004 04:27:16 -0400 Date: Tue, 5 Oct 2004 04:27:15 -0400 (EDT) From: shogunx To: Chen Yan cc: v6ops@ops.ietf.org Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? In-Reply-To: <001401c4aabb$6ce59cd0$8707b69e@chenyan> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.5 required=5.0 tests=BAYES_00,WEIRD_PORT autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 5 Oct 2004, Chen Yan wrote: > Dear All, > > I am just a newer to study Linux for IPV6. > > My linux core is 2.6.I want to add usagi to support IPV6 appication. But I try several usagi such as: usagi-linux26-s****.tar.bz2, all are unavailable. > Whould you please tell me why and what I should do ? You simply need to compile v6 support into your kernel, which is native to the 2.6 series of kernels, meaning that you do not need to patch the kernel. > > And another question: > How can I add a 6to4 tunnel? Please search google for "ipv6 tunnel broker." You can then choose which tunnel broker you would like to tunnel to. The broker you choose will forward you a script for tunnel setup. Scott > > Thank you ! > > Yale > RRS716 > CS Department > HKBU > sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ From owner-v6ops@ops.ietf.org Wed Oct 6 06:41:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10093 for ; Wed, 6 Oct 2004 06:41:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CF9Bo-000BUO-TU for v6ops-data@psg.com; Wed, 06 Oct 2004 10:38:32 +0000 Received: from [158.182.6.1] (helo=karpos.comp.hkbu.edu.hk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CF9Bn-000BU8-Ep for v6ops@ops.ietf.org; Wed, 06 Oct 2004 10:38:31 +0000 Received: from chenyan (cs7135.comp.hkbu.edu.hk [158.182.7.135]) by karpos.comp.hkbu.edu.hk (8.12.11/8.12.11) with SMTP id i96AcIGP029301; Wed, 6 Oct 2004 18:38:18 +0800 (CST) Message-ID: <002301c4ab90$048175d0$8707b69e@chenyan> From: "Chen Yan" To: , , "shogunx" References: <20041001182359.37645.qmail@web80510.mail.yahoo.com> <001401c4aabb$6ce59cd0$8707b69e@chenyan> <046b01c4ab78$968cc690$0e00a8c0@consulintel.es> Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? Date: Wed, 6 Oct 2004 18:34:01 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C4ABD3.0CB2CC70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C4ABD3.0CB2CC70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thank you very much! Your tunnel-broker is very easy to use! But I think what I need is not to use tunnel toker. My task is to set up 6to4 tunnel mechanism (RFC 3056). I think it is = default supported in linux 2.6 kernel. I have three PC,all have supported ipv6. one has been configured to be = ipv6 router.(by IPV6FORWARDING=3Dyes) the other two are hosts which are in different v6 subnet with different = netmask. Now my problem is=20 1: configure ipv6 router to be 6to4 router.How to do it?or it is default = 6to4 router because linux2.6 support RFC 3056 default.right? 2:set up 6to4 tunnel on one host. I have done it refering to "LINUX IPV6 = HOWTO",but it doesn't work. I really don't know how to do!Would please = help me? Thank you=20 Yale ----- Original Message -----=20 From: Miguel Angel Diaz=20 To: chenyan@Comp.HKBU.Edu.HK=20 Sent: Wednesday, October 06, 2004 3:46 PM Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? Why don't you try our tunnel-broker? = http://tb.consulintel.euro6ix.org/in/index.php It is friendly and easy to use. Let me know any issue you have about = it. Regards ************************************ Miguel A. Diaz Telecommunication Engineer Support and R&D ----- Original Message -----=20 From: Chen Yan=20 To: v6ops@ops.ietf.org=20 Sent: Tuesday, October 05, 2004 11:12 AM Subject: why the usagi-linux26-s****.tar.bz2 is unavailable? Dear All, I am just a newer to study Linux for IPV6. My linux core is 2.6.I want to add usagi to support IPV6 appication. = But I try several usagi such as: usagi-linux26-s****.tar.bz2, all are = unavailable. Whould you please tell me why and what I should do ? And another question: How can I add a 6to4 tunnel?=20 Thank you ! Yale RRS716 CS Department HKBU ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. ------=_NextPart_000_0020_01C4ABD3.0CB2CC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thank you very much!
Your tunnel-broker is very easy to use!
But I think what I need is not to use tunnel=20 toker.
 
My task is to set up 6to4 tunnel mechanism (RFC = 3056). I think=20 it is default supported in linux 2.6 kernel.
I have three PC,all have supported ipv6. = one has been configured to be ipv6 router.(by=20 IPV6FORWARDING=3Dyes)
the other two are hosts which are in different v6 = subnet with=20 different netmask.
 
Now my problem is
1: configure ipv6 router to be 6to4 router.How to do = it?or it=20 is default 6to4 router because linux2.6 support RFC 3056=20 default.right?
2:set up 6to4 tunnel on one host. I have done it = refering to=20 "LINUX IPV6 HOWTO",but it doesn't work. I really don't know how to = do!Would=20 please help me?
 
Thank you
 
Yale
 
----- Original Message -----
From:=20 Miguel Angel Diaz =
Sent: Wednesday, October 06, = 2004 3:46=20 PM
Subject: Re: why the=20 usagi-linux26-s****.tar.bz2 is unavailable?

Why don't you try our tunnel-broker? http://tb.consuli= ntel.euro6ix.org/in/index.php
 
It is friendly and easy to use. Let me know any issue you have = about=20 it.
 
Regards

************************************
Miguel A. Diaz
Telecommunication Engineer
Support and R&D
 
----- Original Message -----
From:=20 Chen Yan
Sent: Tuesday, October 05, = 2004 11:12=20 AM
Subject: why the=20 usagi-linux26-s****.tar.bz2 is unavailable?

Dear All,
 
I am just a newer to study Linux for = IPV6.
 
My linux core is 2.6.I want to add usagi to = support IPV6=20 appication. But I try several usagi such as: = usagi-linux26-s****.tar.bz2,=20 all are unavailable.
Whould you please tell me why and what I should = do=20 ?
 
And another question:
How can I add a 6to4 tunnel?
 
Thank you !
 
Yale
RRS716
CS Department
HKBU
 


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

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

------=_NextPart_000_0020_01C4ABD3.0CB2CC70-- From owner-v6ops@ops.ietf.org Wed Oct 6 21:05:33 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06004 for ; Wed, 6 Oct 2004 21:05:32 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFMgt-00045y-KS for v6ops-data@psg.com; Thu, 07 Oct 2004 01:03:31 +0000 Received: from [158.182.6.1] (helo=karpos.comp.hkbu.edu.hk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFMgs-00045Y-8T for v6ops@ops.ietf.org; Thu, 07 Oct 2004 01:03:30 +0000 Received: from chenyan (cs7135.comp.hkbu.edu.hk [158.182.7.135]) by karpos.comp.hkbu.edu.hk (8.12.11/8.12.11) with SMTP id i9713KqN025431; Thu, 7 Oct 2004 09:03:20 +0800 (CST) Message-ID: <000e01c4ac09$0b6fb590$8707b69e@chenyan> From: "Chen Yan" To: "Zhenyu Wu" , References: <297110634.26001@njupt.edu.cn> Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? Date: Thu, 7 Oct 2004 09:00:22 +0800 MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thank you very much! I share the idea with you.and I have configured sit0 and tun6to4. But maybe I think what I should do is to set up a IPv6 router in my network enviroment. I have modified /proc/sys/net/ipv6/conf/all/forwarding=1,then it is a router.right? but I think it is not a 6to4 router,I find it cann't handle packets whose protocol code is 41.I want to know how to configure it to be a IPv6 router support sit0 or tun6to4.Would you give me some suggestions? Thank you very much! Yale ----- Original Message ----- From: "Zhenyu Wu" To: Sent: Thursday, October 07, 2004 8:57 AM Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? > Hello, > > Do you just want to set up a 6to4 tunnel? But is there a IPv6 router which you > will connect to? > > I know, in the old version of linux which can support the IPv6, sit0 is reserved > for 6to4. But now, there is a new tunnel interface "tun6to4" which can be used to > set up a 6to4 tunnel. I can give you examples: > > <1>use sit0 > ifconfig eth0 localipv4address netmask 255.255.255.0 > ifconfig sit0 up > ifconfig sit0 add yourIPv6address > route -A inet6 add 2002::/16 dev sit0 > <2>tun6to4 > ip tunnel add tun6to4 mode sit ttl 64 remote any local localipv4addr > ip link set dev tun6to4 up > ip -f inet6 addr add yourIPv6address dev tun6to4 > ip -f inet6 route add 2002::/16 dev tun6to4 metric 1 > > I think it can help you. > > Best, > Zhenyu Wu > NJUPT,China > > > >From: "Chen Yan" > >Reply-To: > >To: , , > "shogunx" > >Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? > >Date:Wed, 6 Oct 2004 18:34:01 +0800 > > > >Thank you very much! > >Your tunnel-broker is very easy to use! > >But I think what I need is not to use tunnel toker. > > > >My task is to set up 6to4 tunnel mechanism (RFC 3056). I think it is default > supported in linux 2.6 kernel. > >I have three PC,all have supported ipv6. one has been configured to be ipv6 > router.(by IPV6FORWARDING=yes) > >the other two are hosts which are in different v6 subnet with different netmask. > > > >Now my problem is > >1: configure ipv6 router to be 6to4 router.How to do it?or it is default 6to4 > router because linux2.6 support RFC 3056 default.right? > >2:set up 6to4 tunnel on one host. I have done it refering to "LINUX IPV6 > HOWTO",but it doesn't work. I really don't know how to do!Would please help me? > > > >Thank you > > > >Yale > > > > ----- Original Message ----- > > From: Miguel Angel Diaz > > To: chenyan@Comp.HKBU.Edu.HK > > Sent: Wednesday, October 06, 2004 3:46 PM > > Subject: Re: why the usagi-linux26-s****.tar.bz2 is unavailable? > > > > > > Why don't you try our tunnel-broker? http://tb.consulintel.euro6ix.org/in/index.php > > > > It is friendly and easy to use. Let me know any issue you have about it. > > > > Regards > > > > ************************************ > > Miguel A. Diaz > > Telecommunication Engineer > > Support and R&D > > > > ----- Original Message ----- > > From: Chen Yan > > To: v6ops@ops.ietf.org > > Sent: Tuesday, October 05, 2004 11:12 AM > > Subject: why the usagi-linux26-s****.tar.bz2 is unavailable? > > > > > > Dear All, > > > > I am just a newer to study Linux for IPV6. > > > > My linux core is 2.6.I want to add usagi to support IPV6 appication. But I > try several usagi such as: usagi-linux26-s****.tar.bz2, all are unavailable. > > Whould you please tell me why and what I should do ? > > > > And another question: > > How can I add a 6to4 tunnel? > > > > Thank you ! > > > > Yale > > RRS716 > > CS Department > > HKBU > > > > > > > > ********************************** > > Madrid 2003 Global IPv6 Summit > > Presentations and videos on line at: > > http://www.ipv6-es.com > > > > This electronic message contains information which may be privileged or > confidential. The information is intended to be for the use of the individual(s) > named above. If you are not the intended recipient be aware that any disclosure, > copying, distribution or use of the contents of this information, including > attached files, is prohibited. > > > > > > From owner-v6ops@ops.ietf.org Thu Oct 7 08:40:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11629 for ; Thu, 7 Oct 2004 08:40:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFXWO-0000SB-TH for v6ops-data@psg.com; Thu, 07 Oct 2004 12:37:24 +0000 Received: from [131.228.20.21] (helo=mgw-x1.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFXWD-0000R0-S1 for v6ops@ops.ietf.org; Thu, 07 Oct 2004 12:37:14 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97CbCh12949 for ; Thu, 7 Oct 2004 15:37:12 +0300 (EET DST) X-Scanned: Thu, 7 Oct 2004 15:36:45 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i97Cajkl027204 for ; Thu, 7 Oct 2004 15:36:45 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00BsxNKH; Thu, 07 Oct 2004 15:36:42 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97Ca8Y11112 for ; Thu, 7 Oct 2004 15:36:08 +0300 (EET DST) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 15:32:34 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 15:32:33 +0300 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.115 172.21.154.115 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok154115.ntc.nokia.com by ESEBE054.noe.nokia.com; 07 Oct 2004 15:32:33 +0300 Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) From: "Soininen Jonne (Nokia-NET/Helsinki)" To: v6ops@ops.ietf.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1097152352.4591.310.camel@essrv103nok154115.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 15:32:33 +0300 X-OriginalArrivalTime: 07 Oct 2004 12:32:33.0165 (UTC) FILETIME=[B7FE33D0:01C4AC69] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, I'm wondering why there are no comments to this draft. To kick-off the discussion I'm going to provide some of my own. However, please, comment the draft! We cannot move forward if people don't comment! I'm not going to comment much on the details. As it is the first version, I'm just trying to express my opinion on the general direction of the draft. First of all, there is a lot of information in the draft about how the transition/deployment of IPv6 in enterprise environment is to be done. However, the conclusions seem not to be clearly derivable from the text. I think the goal of the document is to have clear conclusions what is expected from the IETF to be done (nothing - everything is already done, requirements for transition protocols/mechanisms, identifying the protocol needed). I think this is somewhat in the document, but not clearly enough. So, what I would like to see is more clearly the link between the actual text of the document and the conclusions in the section 8. At least to me it is not clear how the conclusions have been reached. Cheers, Jonne. On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote: > Folks, > > (co-chair hat on) > > There haven't been any reviews on the list. That's not good. We need > the reviews to make this go forward. Otherwise we cannot go forward > with this, and we cannot go forward with the transition mechanisms for > the enterprises. > > PLEASE provide feedback ASAP! > > (co-chair hat off) > > ---------- Forwarded message ---------- > Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) > From: Pekka Savola > To: v6ops@ops.ietf.org > Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt > > Hi, > > (co-chair hat on) > > This is the initial draft on Enterprise network analysis, and is still > being improved. We need input from the WG to make it better. Please > read and comment ASAP, preferably within a week. We hope to get this > in the shape for WG last call reasonably soon. > > Again, please send feedback. This is very important work! > > (hat off) > > > On Thu, 16 Sep 2004 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 : IPv6 Enterprise Network Analysis > > Author(s) : J. Bound, et al. > > Filename : draft-ietf-v6ops-ent-analysis-00.txt > > Pages : 30 > > Date : 2004-9-16 > > > > This document analyzes the transition to IPv6 in enterprise > > networks. These networks are characterized as a network that has > > multiple internal links, one or more router connections, to one or > > more Providers, and is managed by a network operations entity. The > > analysis will focus on a base set of transition units and > > requirements expanded from a previous Enterprise Scenarios > > document, and will depict a set of components and transition > > methods required for the enterprise to transition to IPv6 within > > each scenario and then common to all scenarios. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00.txt > [...] > -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Oct 7 10:19:19 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19180 for ; Thu, 7 Oct 2004 10:19:18 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFZ5X-000GlT-4Y for v6ops-data@psg.com; Thu, 07 Oct 2004 14:17:47 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFZ5W-000Gl9-92 for v6ops@ops.ietf.org; Thu, 07 Oct 2004 14:17: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 i97EHjGn028307 for ; Thu, 7 Oct 2004 15:17:45 +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 PAA16109 for ; Thu, 7 Oct 2004 15:17:43 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i97EHhE13584 for v6ops@ops.ietf.org; Thu, 7 Oct 2004 15:17:43 +0100 Date: Thu, 7 Oct 2004 15:17:43 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041007141743.GM9985@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1097152352.4591.310.camel@essrv103nok154115.ntc.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1097152352.4591.310.camel@essrv103nok154115.ntc.nokia.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Oct 07, 2004 at 03:32:33PM +0300, Soininen Jonne (Nokia-NET/Helsinki) wrote: > > First of all, there is a lot of information in the draft about how the > transition/deployment of IPv6 in enterprise environment is to be done. > However, the conclusions seem not to be clearly derivable from the text. > I think the goal of the document is to have clear conclusions what is > expected from the IETF to be done (nothing - everything is already done, > requirements for transition protocols/mechanisms, identifying the > protocol needed). > > I think this is somewhat in the document, but not clearly enough. So, > what I would like to see is more clearly the link between the actual > text of the document and the conclusions in the section 8. At least to > me it is not clear how the conclusions have been reached. Hi Jonne, I'm sure Jim can answer, but my $.2c The idea was that we'd pump out a first draft quickly so people could comment on its direction. It wasn't meant to include all solutions. So for example I wrote sections 4 and 7, others added other sections, but without adding an analysis/recommendation on top. Once we have agreement on direction (which should have happened on list some time ago now, but noone commented) we could add the text for the actual recommendations (section 8). If you feel we should just press on in the absence of feedback, then let the authors know. Time to get a revised version in by 18th is running out. Tim From owner-v6ops@ops.ietf.org Thu Oct 7 11:32:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27148 for ; Thu, 7 Oct 2004 11:32:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFaE1-0003PM-8d for v6ops-data@psg.com; Thu, 07 Oct 2004 15:30:37 +0000 Received: from [131.228.20.26] (helo=mgw-x3.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFaE0-0003Op-8k for v6ops@ops.ietf.org; Thu, 07 Oct 2004 15:30:36 +0000 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97FUWC24886; Thu, 7 Oct 2004 18:30:32 +0300 (EET DST) X-Scanned: Thu, 7 Oct 2004 18:28:42 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id i97FSgfY029217; Thu, 7 Oct 2004 18:28:42 +0300 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00GgpDBi; Thu, 07 Oct 2004 18:28:40 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97FSeS27414; Thu, 7 Oct 2004 18:28:40 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 18:21:42 +0300 Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 18:21:42 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 18:21:42 +0300 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.154.115 172.21.154.115 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok154115.ntc.nokia.com by ESEBE054.noe.nokia.com; 07 Oct 2004 18:21:42 +0300 Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) From: "Soininen Jonne (Nokia-NET/Helsinki)" To: ext Tim Chown Cc: v6ops@ops.ietf.org In-Reply-To: <20041007141743.GM9985@login.ecs.soton.ac.uk> References: <1097152352.4591.310.camel@essrv103nok154115.ntc.nokia.com> <20041007141743.GM9985@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1097162501.4591.444.camel@essrv103nok154115.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 18:21:42 +0300 X-OriginalArrivalTime: 07 Oct 2004 15:21:42.0639 (UTC) FILETIME=[598D07F0:01C4AC81] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim, On Thu, 2004-10-07 at 17:17, ext Tim Chown wrote: > Hi Jonne, > > I'm sure Jim can answer, but my $.2c > > The idea was that we'd pump out a first draft quickly so people could > comment on its direction. It wasn't meant to include all solutions. > So for example I wrote sections 4 and 7, others added other sections, > but without adding an analysis/recommendation on top. I understand and agree with the approach, of course. > > Once we have agreement on direction (which should have happened on list > some time ago now, but noone commented) we could add the text for the > actual recommendations (section 8). > > If you feel we should just press on in the absence of feedback, then let > the authors know. Time to get a revised version in by 18th is running > out. As nobody commented the document, I decided to comment first myself, and then start to complain that other people do not comment. If nobody comments, I guess you have to work forward and hope that people agree. Cheers, Jonne. > > Tim -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Oct 7 12:50:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03872 for ; Thu, 7 Oct 2004 12:50:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFbRr-000H1X-5O for v6ops-data@psg.com; Thu, 07 Oct 2004 16:48:59 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CFbRp-000H10-Rw for v6ops@ops.ietf.org; Thu, 07 Oct 2004 16:48:58 +0000 Received: (qmail 94915 invoked by uid 1007); 7 Oct 2004 16:48:56 -0000 Date: Thu, 7 Oct 2004 18:48:56 +0200 From: Gert Doering To: Pekka Savola Cc: Salman Asadullah , Adeel Ahmed , Ciprian Popoviciu , v6ops@ops.ietf.org, Patrick Grossetete Subject: Re: Draft on ISP broad-band deployment scenarios Message-ID: <20041007164856.GJ10500@Space.Net> References: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, answering a specific bit out of this... On Fri, Sep 24, 2004 at 10:32:22AM +0300, Pekka Savola wrote: > > This is true but we have observed many of the BB ISPs are interested in > > deploying native IPv6, driven by new services such as VoD using Multicast > > and etc. Some of the examples for these BB ISPs, who are deploying IPv6 > > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in > > France, XS4ALL in The Netherlands and etc. > > Sure. But do these ISPs use a link-layer which supports multicast, > e.g., bridged-mode DSL (I think it does..)? > > That is, if you do something like L2TPoE (which I think many are > doing), doesn't that require that multicast transmission be > duplicated (on a lower layer) in any case, causing equal amount of > traffic as a tunneling based distribution? Our (SpaceNet's) DSL stuff is either PPPoE/L2TP based or ATM-PVC-based (bridged or routed mode). Neither has native support for Multicast (in the sense of "the network duplicates the packets"), so the benefits of multicasts are only in the uplink towards the DSL aggregation routers, and possibly if multiple users behind the same DSL line (small offices) are receiving the same multicast data stream. [..] > Extra investment is always possible, and many will certainly do it. > The question is just how the ISPs would transition from "v4-only" to > "v4+v6 natively". My argument is that it would be easier for the ISPs > to start with tunneling and native v6 where possible, than to require > through-out upgrade to native v6. Full ACK here. Some parts are just hard/expensive to get v6 on, while others can be done fairly easily. So you end up tunneling around those "difficult" bits, even if the rest of the network is already native. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Thu Oct 7 13:34:01 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07346 for ; Thu, 7 Oct 2004 13:34:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFc8f-000PHv-5h for v6ops-data@psg.com; Thu, 07 Oct 2004 17:33:13 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFc8e-000PHf-3q for v6ops@ops.ietf.org; Thu, 07 Oct 2004 17:33:12 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A1C6DA082; Thu, 7 Oct 2004 13:33:11 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 13:33:11 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Date: Thu, 7 Oct 2004 13:33:12 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A08A@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Thread-Index: AcSsaumkZ3QCRxmoThmpCH7hJmLC/gAKE/Lg From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" , X-OriginalArrivalTime: 07 Oct 2004 17:33:11.0523 (UTC) FILETIME=[B7B13330:01C4AC93] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Jonne, Sorry for late response I am traveling yet again. I agree with what Tim stated and also the team is ready to go. Before we solidified the recommendations we wanted the WG to respond as Tim pointed out. We can move forward but that has more risk. I can present our status and results at D.C and suggest that I should if you and Pekka agree. But let us know ok. Seems like we should move forward. I suggest we give WG till next Tuesday to respond ok? Then we have no choice but to go to next rev. Its to bad we just lost at least 2 weeks from no input of stagnation? Thanks /jim=20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Soininen Jonne=20 > (Nokia-NET/Helsinki) > Sent: Thursday, October 07, 2004 8:33 AM > To: v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) >=20 > Hello, >=20 > > I'm wondering why there are no comments to this draft. To=20 > kick-off the discussion I'm going to provide some of my own.=20 > However, please, comment the draft! We cannot move forward if=20 > people don't comment! > >=20 > I'm not going to comment much on the details. As it is the=20 > first version, I'm just trying to express my opinion on the=20 > general direction of the draft. >=20 > First of all, there is a lot of information in the draft=20 > about how the transition/deployment of IPv6 in enterprise=20 > environment is to be done. > However, the conclusions seem not to be clearly derivable=20 > from the text. > I think the goal of the document is to have clear conclusions=20 > what is expected from the IETF to be done (nothing -=20 > everything is already done, requirements for transition=20 > protocols/mechanisms, identifying the protocol needed).=20 >=20 > I think this is somewhat in the document, but not clearly=20 > enough. So, what I would like to see is more clearly the link=20 > between the actual text of the document and the conclusions=20 > in the section 8. At least to me it is not clear how the=20 > conclusions have been reached. >=20 > Cheers, >=20 > Jonne. > On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote: > > Folks, > >=20 > > (co-chair hat on) > >=20 > > There haven't been any reviews on the list. That's not=20 > good. We need=20 > > the reviews to make this go forward. Otherwise we cannot=20 > go forward=20 > > with this, and we cannot go forward with the transition=20 > mechanisms for=20 > > the enterprises. > >=20 > > PLEASE provide feedback ASAP! > >=20 > > (co-chair hat off) > >=20 > > ---------- Forwarded message ---------- > > Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) > > From: Pekka Savola > > To: v6ops@ops.ietf.org > > Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt > >=20 > > Hi, > >=20 > > (co-chair hat on) > >=20 > > This is the initial draft on Enterprise network analysis,=20 > and is still=20 > > being improved. We need input from the WG to make it=20 > better. Please=20 > > read and comment ASAP, preferably within a week. We hope=20 > to get this=20 > > in the shape for WG last call reasonably soon. > >=20 > > Again, please send feedback. This is very important work! > >=20 > > (hat off) > >=20 > >=20 > > On Thu, 16 Sep 2004 Internet-Drafts@ietf.org wrote: > > > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > > > This draft is a work item of the IPv6 Operations Working=20 > Group of the IETF. > > >=20 > > > Title : IPv6 Enterprise Network Analysis > > > Author(s) : J. Bound, et al. > > > Filename : draft-ietf-v6ops-ent-analysis-00.txt > > > Pages : 30 > > > Date : 2004-9-16 > > > =09 > > > This document analyzes the transition to IPv6 in enterprise =20 > > > networks. These networks are characterized as a network=20 > that has =20 > > > multiple internal links, one or more router connections,=20 > to one or =20 > > > more Providers, and is managed by a network operations=20 > entity. The =20 > > > analysis will focus on a base set of transition units and =20 > > > requirements expanded from a previous Enterprise Scenarios =20 > > > document, and will depict a set of components and transition =20 > > > methods required for the enterprise to transition to IPv6 within =20 > > > each scenario and then common to all scenarios. > > >=20 > > > A URL for this Internet-Draft is: > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00 > > > .txt > > [...] > >=20 > -- > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 >=20 From owner-v6ops@ops.ietf.org Thu Oct 7 15:24:45 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14935 for ; Thu, 7 Oct 2004 15:24:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFcVt-0003v8-5U for v6ops-data@psg.com; Thu, 07 Oct 2004 17:57:13 +0000 Received: from [213.200.88.213] (helo=mx1.ip.tiscali.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CFcVs-0003up-6H for v6ops@ops.ietf.org; Thu, 07 Oct 2004 17:57:12 +0000 Received: (qmail 84704 invoked from network); 7 Oct 2004 17:57:11 -0000 Received: from unknown (HELO shekinah.ip.tiscali.net) (213.200.88.76) by smtp.ip.tiscali.net with SMTP; 7 Oct 2004 17:57:11 -0000 Received: from ako by shekinah.ip.tiscali.net with local (Exim 4.34 #1) id 1CFcVr-0006dN-TE; Thu, 07 Oct 2004 19:57:11 +0200 Date: Thu, 7 Oct 2004 19:57:11 +0200 From: Alexander Koch To: Gert Doering Cc: Pekka Savola , v6ops@ops.ietf.org Subject: Re: Draft on ISP broad-band deployment scenarios Message-ID: <20041007175711.GB25383@shekinah.ip.tiscali.net> References: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> <20041007164856.GJ10500@Space.Net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041007164856.GJ10500@Space.Net> Organization: Tiscali International Network B.V. X-NCC-RegID: eu.nacnet User-Agent: Mutt/1.5.6+20040907i X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk All, On Thu, 7 October 2004 18:48:56 +0200, Gert Doering wrote: > answering a specific bit out of this... that applies for me, too. > Neither has native support for Multicast (in the sense of "the network > duplicates the packets"), so the benefits of multicasts are only > in the uplink towards the DSL aggregation routers, and possibly if > multiple users behind the same DSL line (small offices) are receiving > the same multicast data stream. That being said, take also into consideration that bitstream access is not widely available yet in Europe or the invests are just not worth it. so the next option would be to get the traffic via L2TP, and the multicast buys you absolutely nothing as too many DSL providers effectively do not save a penny. And of course this applies to IPv4, and I do not see it changing anytime soon. (Despite the effort by BBC, for example, or AMT which is promising, all v4 though) > [..] > > Extra investment is always possible, and many will certainly do it. > > The question is just how the ISPs would transition from "v4-only" to > > "v4+v6 natively". My argument is that it would be easier for the ISPs > > to start with tunneling and native v6 where possible, than to require > > through-out upgrade to native v6. > > Full ACK here. Some parts are just hard/expensive to get v6 on, > while others can be done fairly easily. So you end up tunneling > around those "difficult" bits, even if the rest of the network is > already native. Take the Juniper ERX for an example. J's licensing model is a major showstopper for several operators to even consider providing IPv6 to their end users. ;-\ With the typical end user setup if the typical vendors (J, Redback, Cisco, you name it) get this working normally that will be the main driving factor in my view for operators to actually try it at all. Mind you, my 2 cents worth, we run IPv6 natively for some time now in all our core, and that is what we encounter when trying to convince the powers that be. AS-TISCALI-V6PEERS. :-) Regards, Alexander -- Alexander Koch / ako4-ripe Tiscali Int., Peering Coordination Phone +49 6103 916 480, Fax +49 6103 916 464 From owner-v6ops@ops.ietf.org Thu Oct 7 16:27:14 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21829 for ; Thu, 7 Oct 2004 16:27:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFeoZ-0001FF-Ff for v6ops-data@psg.com; Thu, 07 Oct 2004 20:24:39 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFeoY-0001Ez-1O for v6ops@ops.ietf.org; Thu, 07 Oct 2004 20:24:38 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97KOaW05171; Thu, 7 Oct 2004 23:24:36 +0300 (EET DST) X-Scanned: Thu, 7 Oct 2004 23:21:56 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i97KLuGU023308; Thu, 7 Oct 2004 23:21:56 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00P5B3zI; Thu, 07 Oct 2004 23:21:56 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i97KLsY22246; Thu, 7 Oct 2004 23:21:54 +0300 (EET DST) Received: from esebe010.NOE.Nokia.com ([172.21.138.49]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 23:21:54 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe010.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 7 Oct 2004 23:21:53 +0300 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 10.162.253.239 10.162.253.239 via HTTP with MS-WebStorage 6.0.6249 Received: from localhost.localdomain by ESEBE054.noe.nokia.com; 07 Oct 2004 23:21:54 +0300 Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) From: "Soininen Jonne (Nokia-NET/Helsinki)" To: "ext Bound, Jim" Cc: v6ops@ops.ietf.org In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0784A08A@tayexc13.americas.cpqcorp.net> References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A08A@tayexc13.americas.cpqcorp.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1097180513.4359.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Thu, 07 Oct 2004 23:21:54 +0300 X-OriginalArrivalTime: 07 Oct 2004 20:21:53.0513 (UTC) FILETIME=[48DE4D90:01C4ACAB] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jim, your proposal sounds like a plan. If the WG decides to remain silent until next week, please produce another draft without comments. I guess, the WG will speak up sooner or later! Cheers, Jonne. On Thu, 2004-10-07 at 20:33, ext Bound, Jim wrote: > Hi Jonne, > > Sorry for late response I am traveling yet again. I agree with what Tim > stated and also the team is ready to go. Before we solidified the > recommendations we wanted the WG to respond as Tim pointed out. We can > move forward but that has more risk. I can present our status and > results at D.C and suggest that I should if you and Pekka agree. But > let us know ok. > > Seems like we should move forward. I suggest we give WG till next > Tuesday to respond ok? Then we have no choice but to go to next rev. > Its to bad we just lost at least 2 weeks from no input of stagnation? > > Thanks > /jim > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Soininen Jonne > > (Nokia-NET/Helsinki) > > Sent: Thursday, October 07, 2004 8:33 AM > > To: v6ops@ops.ietf.org > > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) > > > > Hello, > > > > > > I'm wondering why there are no comments to this draft. To > > kick-off the discussion I'm going to provide some of my own. > > However, please, comment the draft! We cannot move forward if > > people don't comment! > > > > > > I'm not going to comment much on the details. As it is the > > first version, I'm just trying to express my opinion on the > > general direction of the draft. > > > > First of all, there is a lot of information in the draft > > about how the transition/deployment of IPv6 in enterprise > > environment is to be done. > > However, the conclusions seem not to be clearly derivable > > from the text. > > I think the goal of the document is to have clear conclusions > > what is expected from the IETF to be done (nothing - > > everything is already done, requirements for transition > > protocols/mechanisms, identifying the protocol needed). > > > > I think this is somewhat in the document, but not clearly > > enough. So, what I would like to see is more clearly the link > > between the actual text of the document and the conclusions > > in the section 8. At least to me it is not clear how the > > conclusions have been reached. > > > > Cheers, > > > > Jonne. > > On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote: > > > Folks, > > > > > > (co-chair hat on) > > > > > > There haven't been any reviews on the list. That's not > > good. We need > > > the reviews to make this go forward. Otherwise we cannot > > go forward > > > with this, and we cannot go forward with the transition > > mechanisms for > > > the enterprises. > > > > > > PLEASE provide feedback ASAP! > > > > > > (co-chair hat off) > > > > > > ---------- Forwarded message ---------- > > > Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) > > > From: Pekka Savola > > > To: v6ops@ops.ietf.org > > > Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt > > > > > > Hi, > > > > > > (co-chair hat on) > > > > > > This is the initial draft on Enterprise network analysis, > > and is still > > > being improved. We need input from the WG to make it > > better. Please > > > read and comment ASAP, preferably within a week. We hope > > to get this > > > in the shape for WG last call reasonably soon. > > > > > > Again, please send feedback. This is very important work! > > > > > > (hat off) > > > > > > > > > On Thu, 16 Sep 2004 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 : IPv6 Enterprise Network Analysis > > > > Author(s) : J. Bound, et al. > > > > Filename : draft-ietf-v6ops-ent-analysis-00.txt > > > > Pages : 30 > > > > Date : 2004-9-16 > > > > > > > > This document analyzes the transition to IPv6 in enterprise > > > > networks. These networks are characterized as a network > > that has > > > > multiple internal links, one or more router connections, > > to one or > > > > more Providers, and is managed by a network operations > > entity. The > > > > analysis will focus on a base set of transition units and > > > > requirements expanded from a previous Enterprise Scenarios > > > > document, and will depict a set of components and transition > > > > methods required for the enterprise to transition to IPv6 within > > > > each scenario and then common to all scenarios. > > > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00 > > > > .txt > > > [...] > > > > > -- > > Jonne Soininen > > Nokia > > > > Tel: +358 40 527 46 34 > > E-mail: jonne.soininen@nokia.com > > > > -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Oct 7 16:36:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23137 for ; Thu, 7 Oct 2004 16:36:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CFf05-0002wY-Co for v6ops-data@psg.com; Thu, 07 Oct 2004 20:36:33 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CFf03-0002vv-SD for v6ops@ops.ietf.org; Thu, 07 Oct 2004 20:36:32 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 75E0BF1; Thu, 7 Oct 2004 16:36:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 7 Oct 2004 16:36: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: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Date: Thu, 7 Oct 2004 16:36:32 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A0FE@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Thread-Index: AcSsq7CuBID6Yh4fTFK9lGCsLmtu3wAAZlrw From: "Bound, Jim" To: "Soininen Jonne (Nokia-NET/Helsinki)" Cc: X-OriginalArrivalTime: 07 Oct 2004 20:36:31.0390 (UTC) FILETIME=[541FB3E0:01C4ACAD] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Jonne, Will do and have to coordinate with authors of course. /jim=20 > -----Original Message----- > From: Soininen Jonne (Nokia-NET/Helsinki)=20 > [mailto:jonne.soininen@nokia.com]=20 > Sent: Thursday, October 07, 2004 4:22 PM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) >=20 > Jim, >=20 > your proposal sounds like a plan. If the WG decides to remain=20 > silent until next week, please produce another draft without=20 > comments. I guess, the WG will speak up sooner or later!=20 >=20 > Cheers, >=20 > Jonne. >=20 > On Thu, 2004-10-07 at 20:33, ext Bound, Jim wrote: > > Hi Jonne, > >=20 > > Sorry for late response I am traveling yet again. I agree=20 > with what=20 > > Tim stated and also the team is ready to go. Before we=20 > solidified the=20 > > recommendations we wanted the WG to respond as Tim pointed out. We=20 > > can move forward but that has more risk. I can present our status=20 > > and results at D.C and suggest that I should if you and=20 > Pekka agree. =20 > > But let us know ok. > >=20 > > Seems like we should move forward. I suggest we give WG till next=20 > > Tuesday to respond ok? Then we have no choice but to go to=20 > next rev. > > Its to bad we just lost at least 2 weeks from no input of=20 > stagnation? > >=20 > > Thanks > > /jim > >=20 > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Soininen Jonne > > > (Nokia-NET/Helsinki) > > > Sent: Thursday, October 07, 2004 8:33 AM > > > To: v6ops@ops.ietf.org > > > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt=20 > > > (fwd) > > >=20 > > > Hello, > > >=20 > > > > > > I'm wondering why there are no comments to this draft. To=20 > kick-off=20 > > > the discussion I'm going to provide some of my own. > > > However, please, comment the draft! We cannot move=20 > forward if people=20 > > > don't comment! > > > > > >=20 > > > I'm not going to comment much on the details. As it is the first=20 > > > version, I'm just trying to express my opinion on the general=20 > > > direction of the draft. > > >=20 > > > First of all, there is a lot of information in the draft=20 > about how=20 > > > the transition/deployment of IPv6 in enterprise=20 > environment is to be=20 > > > done. > > > However, the conclusions seem not to be clearly derivable=20 > from the=20 > > > text. > > > I think the goal of the document is to have clear=20 > conclusions what=20 > > > is expected from the IETF to be done (nothing - everything is=20 > > > already done, requirements for transition protocols/mechanisms,=20 > > > identifying the protocol needed). > > >=20 > > > I think this is somewhat in the document, but not clearly enough.=20 > > > So, what I would like to see is more clearly the link between the=20 > > > actual text of the document and the conclusions in the=20 > section 8. At=20 > > > least to me it is not clear how the conclusions have been reached. > > >=20 > > > Cheers, > > >=20 > > > Jonne. > > > On Mon, 2004-09-27 at 12:29, ext Pekka Savola wrote: > > > > Folks, > > > >=20 > > > > (co-chair hat on) > > > >=20 > > > > There haven't been any reviews on the list. That's not > > > good. We need > > > > the reviews to make this go forward. Otherwise we cannot > > > go forward > > > > with this, and we cannot go forward with the transition > > > mechanisms for > > > > the enterprises. > > > >=20 > > > > PLEASE provide feedback ASAP! > > > >=20 > > > > (co-chair hat off) > > > >=20 > > > > ---------- Forwarded message ---------- > > > > Date: Sat, 18 Sep 2004 21:24:32 +0300 (EEST) > > > > From: Pekka Savola > > > > To: v6ops@ops.ietf.org > > > > Subject: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt > > > >=20 > > > > Hi, > > > >=20 > > > > (co-chair hat on) > > > >=20 > > > > This is the initial draft on Enterprise network analysis, > > > and is still > > > > being improved. We need input from the WG to make it > > > better. Please > > > > read and comment ASAP, preferably within a week. We hope > > > to get this > > > > in the shape for WG last call reasonably soon. > > > >=20 > > > > Again, please send feedback. This is very important work! > > > >=20 > > > > (hat off) > > > >=20 > > > >=20 > > > > On Thu, 16 Sep 2004 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. > > > > >=20 > > > > > Title : IPv6 Enterprise Network Analysis > > > > > Author(s) : J. Bound, et al. > > > > > Filename : draft-ietf-v6ops-ent-analysis-00.txt > > > > > Pages : 30 > > > > > Date : 2004-9-16 > > > > > =09 > > > > > This document analyzes the transition to IPv6 in enterprise=20 > > > > > networks. These networks are characterized as a network > > > that has > > > > > multiple internal links, one or more router connections, > > > to one or > > > > > more Providers, and is managed by a network operations > > > entity. The > > > > > analysis will focus on a base set of transition units and=20 > > > > > requirements expanded from a previous Enterprise Scenarios=20 > > > > > document, and will depict a set of components and transition=20 > > > > > methods required for the enterprise to transition to=20 > IPv6 within=20 > > > > > each scenario and then common to all scenarios. > > > > >=20 > > > > > A URL for this Internet-Draft is: > > > > >=20 > > >=20 > http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-analysis-00 > > > > > .txt > > > > [...] > > > >=20 > > > -- > > > Jonne Soininen > > > Nokia > > >=20 > > > Tel: +358 40 527 46 34 > > > E-mail: jonne.soininen@nokia.com > > >=20 > > >=20 > -- > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com >=20 From owner-v6ops@ops.ietf.org Fri Oct 8 17:44:05 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20392 for ; Fri, 8 Oct 2004 17:44:04 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CG2Tq-000L3O-9J for v6ops-data@psg.com; Fri, 08 Oct 2004 21:40:50 +0000 Received: from [66.218.79.75] (helo=web80505.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CG2Tp-000L3B-OO for v6ops@ops.ietf.org; Fri, 08 Oct 2004 21:40:49 +0000 Message-ID: <20041008214049.3841.qmail@web80505.mail.yahoo.com> Received: from [63.197.18.101] by web80505.mail.yahoo.com via HTTP; Fri, 08 Oct 2004 14:40:49 PDT Date: Fri, 8 Oct 2004 14:40:49 -0700 (PDT) From: Fred Templin Subject: Re: IPvLX To: ipv6@ietf.org, v6ops@ops.ietf.org, rbridge@postel.org, pmtud@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1980266083-1097271649=:1569" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.8 required=5.0 tests=BAYES_00,FROM_ENDS_IN_NUMS, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --0-1980266083-1097271649=:1569 Content-Type: text/plain; charset=us-ascii Hello, On August 23, 2004 I announced to this distribution a -00 document entitled: "IPvLX: IPv6 Addressing in the IPv4 Internet" Since that time, a -01 revision of the base document has obsoleted the -00 version, and a new document entitled: "IPvLX Errata" that specifies patches to be applied against the base document has been submitted to internet-drafts@ietf.org. The documents are currently available at the following URLs (the latter of the two should soon be appearing in the I-D repository): http://www.ietf.org/internet-drafts/draft-templin-ipvlx-01.txt http://www.geocities.com/osprey67/ipvlx/ipvlx_errata-00.txt Sincerely, Fred L. Templin osprey67@yahoo.com --0-1980266083-1097271649=:1569 Content-Type: text/html; charset=us-ascii
Hello,
 
On August 23, 2004 I announced to this distribution a -00 document entitled:
 
  "IPvLX: IPv6 Addressing in the IPv4 Internet"
 
Since that time, a -01 revision of the base document has obsoleted the
-00 version, and a new document entitled: "IPvLX Errata" that specifies
patches to be applied against the base document has been submitted
 
The documents are currently available at the following URLs (the latter
of the two should soon be appearing in the I-D repository):
 
 
Sincerely,
 
Fred L. Templin
--0-1980266083-1097271649=:1569-- From owner-v6ops@ops.ietf.org Fri Oct 8 19:18:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27907 for ; Fri, 8 Oct 2004 19:18:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CG3yi-0004Za-5Q for v6ops-data@psg.com; Fri, 08 Oct 2004 23:16:48 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CG3yh-0004ZN-1O for v6ops@ops.ietf.org; Fri, 08 Oct 2004 23:16:47 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 08 Oct 2004 16:17:39 -0700 X-BrightmailFiltered: true Received: from ssenthil-w2k.cisco.com (dhcp-128-107-163-246.cisco.com [128.107.163.246]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i98NGigS013590; Fri, 8 Oct 2004 16:16:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20041008161243.030f3538@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Oct 2004 16:17:25 -0700 To: "Cedric Aoun" From: Senthil Sivakumar Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Cc: V6OPS , "Elwyn Davies" In-Reply-To: References: <200409211938.PAA14143@ietf.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_69130203==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=BAYES_00,HTML_FONTCOLOR_RED, HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_69130203==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I see that the draft has consolidated all the previous drafts that highlighted the issues of NAT-PT and DNS ALG, which is a good thing. However, most of the issues mentioned here as NAT-PT issues are known issues with address translation (NAT) itself, so attributing them to NAT-PT is not correct. Those should be categorized as generic address translation issues. Some specfic comments on the following issues. * Disruption of all protocols which embed IP addresses (and/or ports) in packet payloads or which apply integrity mechanisms using IP addresses (and ports). (not NAT-PT specific). * Requirement for applications to use keep alive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout. (not NAT-PT specific). * Inability to redirect packet fragments after the first with NAPT-PT. (not NAT-PT specific). o Issues which are exacerbated by the use of a DNS-ALG: * Constraints on network topology. (not NAT-PT specific). * Scalability concerns together with introduction of single point of failure and security attack nexus.(not NAT-PT specific). * Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keeping it alive once they start using it.(not NAT-PT specific). * Creation of a DOS threat relating to exhaustion of memory and address/port pool resources on the translator.(not NAT-PT specific). Regarding the conclusion, I don't agree with the fact that only applicable scenario is in 3G networks. During the past couple of years of my experience I have seen customers using it between isolated IPv6 networks to talk to existing IPv4 networks. A lot of cases it is not about the nodes being dual stack or not, it is the network that is not dual stacked for operational reasons. I have been gathering some inputs from the customers who are using NAT-PT currently regarding this draft. I can consolidate and forward the comments if you are interested in knowing and understanding why they think they are moving forward with NAT-PT. The point I am trying to stress is deprecating this would leave us with no workable solution for communicating between IPv4 only networks/nodes/apps IPv6 only networks/nodes/apps. As remote as it might seem for some, that is the use case scenario we have encountered as the applicability of NAT-PT. Senthil At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: >Hi, >As discussed at IETF 60, the WG agreed to continue the NAT-PT deprecation >analysis. >We would really appreciate if you could provide us your feedback on the >initial version of the deprecation analysis by Monday October 4th. >Regards >Cedric Aoun >------ Forwarded Message >From: >Reply-To: >Date: Tue, 21 Sep 2004 21:38:33 +0200 >To: >Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > > > Title : Reasons to Deprecate NAT-PT > Author(s) : C. Aoun, E. Davies > Filename : draft-aoun-v6ops-natpt-deprecate-00.txt > Pages : 24 > Date : 2004-9-21 > >This document discusses reasons why use of the specific form of > IPv6-IPv4 protocol translation mechanism implemented by the Network > Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766 > should be deprecated and RFC2766 moved to historic status. > Description of an alternative protocol translation mechanism is out > of scope for this document. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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. > > > > >------ End of Forwarded Message > --=====================_69130203==_.ALT Content-Type: text/html; charset="us-ascii" I see that the draft has consolidated all the previous drafts that highlighted the issues
of NAT-PT and DNS ALG, which is a good thing. However, most of the issues mentioned
here as NAT-PT issues are known issues with address translation (NAT) itself, so
attributing them to NAT-PT is not correct.  Those should be categorized as generic address
translation issues.

Some specfic comments on the following issues.

     *  Disruption of all protocols which embed IP addresses (and/or
         ports) in packet payloads or which apply integrity mechanisms
         using IP addresses (and ports). (not NAT-PT specific).

      *  Requirement for applications to use keep alive mechanisms to
         workaround connectivity issues caused by premature NAT-PT state
         timeout. (not NAT-PT specific).

       *  Inability to redirect packet fragments after the first with
         NAPT-PT. (not NAT-PT specific).
       
   o  Issues which are exacerbated by the use of a DNS-ALG:
      *  Constraints on network topology. (not NAT-PT specific).
      *  Scalability concerns together with introduction of single point
         of failure and security attack nexus.(not NAT-PT specific).
      *  Lack of address mapping persistence: Some applications require
         address retention between sessions.  The user traffic will be
         disrupted if a different mapping is used.  The use of the
         DNS-ALG to create address mappings with limited lifetimes means
         that applications must start using the address shortly after
         the mapping is created, as well as keeping it alive once they
         start using it.(not NAT-PT specific).
      *  Creation of a DOS threat relating to exhaustion of memory and
         address/port pool resources on the translator.(not NAT-PT specific).

Regarding the conclusion, I don't agree with the fact that only applicable scenario
is in 3G networks. During the past couple of years of my experience I have seen
customers using it between isolated IPv6 networks to talk to existing IPv4 networks.
A lot of cases it is not about the nodes being dual stack or not, it is the network
that is not dual stacked for operational reasons.

I have been gathering some inputs from the customers who are using NAT-PT currently
regarding this draft. I can consolidate and forward the comments if you are interested in
knowing and understanding why they think they are moving forward with NAT-PT.

The point I am trying to stress is deprecating this would leave us with no workable
solution for communicating between IPv4 only networks/nodes/apps IPv6 only
networks/nodes/apps. As remote as it might seem for some, that is the use case
scenario we have encountered as the applicability of NAT-PT.

Senthil

At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
Hi,
As discussed at IETF 60, the WG agreed to continue the NAT-PT deprecation analysis.
We would really appreciate if you could provide us your feedback on the initial version of the deprecation analysis by Monday October 4th.
Regards
Cedric Aoun
------ Forwarded Message
From: <Internet-Drafts@ietf.org>
Reply-To: <internet-drafts@ietf.org>
Date: Tue, 21 Sep 2004 21:38:33 +0200
To: <i-d-announce@ietf.org>
Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

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



        Title           : Reasons to Deprecate NAT-PT
        Author(s)       : C. Aoun, E. Davies
        Filename        : draft-aoun-v6ops-natpt-deprecate-00.txt
        Pages           : 24
        Date            : 2004-9-21
       
This document discusses reasons why use of the specific form of
   IPv6-IPv4 protocol translation mechanism implemented by the Network
   Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766
   should be deprecated and RFC2766 moved to historic status.
   Description of an alternative protocol translation mechanism is out
   of scope for this document.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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.

 


------ End of Forwarded Message

--=====================_69130203==_.ALT-- From owner-v6ops@ops.ietf.org Sat Oct 9 09:12:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12266 for ; Sat, 9 Oct 2004 09:12:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGGz1-0006pu-8y for v6ops-data@psg.com; Sat, 09 Oct 2004 13:09:59 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGGyz-0006pR-ET for v6ops@ops.ietf.org; Sat, 09 Oct 2004 13:09:58 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i99D9ZFW139748; Sat, 9 Oct 2004 13:09:35 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i99D9YbA098414; Sat, 9 Oct 2004 15:09:34 +0200 Received: from zurich.ibm.com (sig-9-146-217-195.de.ibm.com [9.146.217.195]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA68354; Sat, 9 Oct 2004 15:09:32 +0200 Message-ID: <4167E30B.70007@zurich.ibm.com> Date: Sat, 09 Oct 2004 15:09:31 +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: Senthil Sivakumar CC: Cedric Aoun , V6OPS , Elwyn Davies Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt References: <200409211938.PAA14143@ietf.org> <4.3.2.7.2.20041008161243.030f3538@mira-sjcd-2.cisco.com> In-Reply-To: <4.3.2.7.2.20041008161243.030f3538@mira-sjcd-2.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > The point I am trying to stress is deprecating this would leave us with no workable > solution for communicating between IPv4 only networks/nodes/apps IPv6 only > networks/nodes/apps. As remote as it might seem for some, that is the use case > scenario we have encountered as the applicability of NAT-PT. But there is a workable alternative, which is an application level proxy. This too has its disadvantages, of course. Brian Senthil Sivakumar wrote: > I see that the draft has consolidated all the previous drafts that > highlighted the issues > of NAT-PT and DNS ALG, which is a good thing. However, most of the > issues mentioned > here as NAT-PT issues are known issues with address translation (NAT) > itself, so > attributing them to NAT-PT is not correct. Those should be categorized > as generic address > translation issues. > > Some specfic comments on the following issues. > > * Disruption of all protocols which embed IP addresses (and/or > ports) in packet payloads or which apply integrity mechanisms > using IP addresses (and ports). (not NAT-PT specific). > > * Requirement for applications to use keep alive mechanisms to > workaround connectivity issues caused by premature NAT-PT state > timeout. (not NAT-PT specific). > > * Inability to redirect packet fragments after the first with > NAPT-PT. (not NAT-PT specific). > > o Issues which are exacerbated by the use of a DNS-ALG: > * Constraints on network topology. (not NAT-PT specific). > * Scalability concerns together with introduction of single point > of failure and security attack nexus.(not NAT-PT specific). > * Lack of address mapping persistence: Some applications require > address retention between sessions. The user traffic will be > disrupted if a different mapping is used. The use of the > DNS-ALG to create address mappings with limited lifetimes means > that applications must start using the address shortly after > the mapping is created, as well as keeping it alive once they > start using it.(not NAT-PT specific). > * Creation of a DOS threat relating to exhaustion of memory and > address/port pool resources on the translator.(not NAT-PT > specific). > > Regarding the conclusion, I don't agree with the fact that only > applicable scenario > is in 3G networks. During the past couple of years of my experience I > have seen > customers using it between isolated IPv6 networks to talk to existing > IPv4 networks. > A lot of cases it is not about the nodes being dual stack or not, it is > the network > that is not dual stacked for operational reasons. > > I have been gathering some inputs from the customers who are using > NAT-PT currently > regarding this draft. I can consolidate and forward the comments if you > are interested in > knowing and understanding why they think they are moving forward with > NAT-PT. > > The point I am trying to stress is deprecating this would leave us with > no workable > solution for communicating between IPv4 only networks/nodes/apps IPv6 only > networks/nodes/apps. As remote as it might seem for some, that is the > use case > scenario we have encountered as the applicability of NAT-PT. > > Senthil > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > >> Hi, >> As discussed at IETF 60, the WG agreed to continue the NAT-PT >> deprecation analysis. >> We would really appreciate if you could provide us your feedback on >> the initial version of the deprecation analysis by Monday October 4th. >> Regards >> Cedric Aoun >> ------ Forwarded Message >> From: >> Reply-To: >> Date: Tue, 21 Sep 2004 21:38:33 +0200 >> To: >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> >> >> Title : Reasons to Deprecate NAT-PT >> Author(s) : C. Aoun, E. Davies >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt >> Pages : 24 >> Date : 2004-9-21 >> >> This document discusses reasons why use of the specific form of >> IPv6-IPv4 protocol translation mechanism implemented by the Network >> Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766 >> should be deprecated and RFC2766 moved to historic status. >> Description of an alternative protocol translation mechanism is out >> of scope for this document. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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-aoun-v6ops-natpt-deprecate-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. >> >> >> >> >> ------ End of Forwarded Message >> > From owner-v6ops@ops.ietf.org Sat Oct 9 10:19:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16453 for ; Sat, 9 Oct 2004 10:19:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGI2b-000DD8-Rr for v6ops-data@psg.com; Sat, 09 Oct 2004 14:17:45 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGI2a-000DCs-Rb for v6ops@ops.ietf.org; Sat, 09 Oct 2004 14:17:45 +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 i99EHZGn011694; Sat, 9 Oct 2004 15:17:35 +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 PAA29039; Sat, 9 Oct 2004 15:17:31 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i99EHVx00811; Sat, 9 Oct 2004 15:17:31 +0100 Date: Sat, 9 Oct 2004 15:17:31 +0100 From: Tim Chown To: Brian E Carpenter Cc: Senthil Sivakumar , Cedric Aoun , V6OPS , Elwyn Davies Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Message-ID: <20041009141730.GB586@login.ecs.soton.ac.uk> Mail-Followup-To: Brian E Carpenter , Senthil Sivakumar , Cedric Aoun , V6OPS , Elwyn Davies References: <200409211938.PAA14143@ietf.org> <4.3.2.7.2.20041008161243.030f3538@mira-sjcd-2.cisco.com> <4167E30B.70007@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4167E30B.70007@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sat, Oct 09, 2004 at 03:09:31PM +0200, Brian E Carpenter wrote: > >The point I am trying to stress is deprecating this would leave us with no > >workable > >solution for communicating between IPv4 only networks/nodes/apps IPv6 only > >networks/nodes/apps. As remote as it might seem for some, that is the use > >case > >scenario we have encountered as the applicability of NAT-PT. > > But there is a workable alternative, which is an application level proxy. > This too has its disadvantages, of course. I agree with Brian. Our experience is that translation is only needed for "legacy" apps. The large majority of such legacy apps have a ALG capability (web, mail, news, ftp, sip, ...). There are also TCP-relays... What is the specific application scenario that you have? Tim From owner-v6ops@ops.ietf.org Sat Oct 9 13:37:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27927 for ; Sat, 9 Oct 2004 13:37:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGL7E-0005dW-D0 for v6ops-data@psg.com; Sat, 09 Oct 2004 17:34:44 +0000 Received: from [192.160.51.65] (helo=smtp-bedford-dr.mitre.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGL7D-0005dF-3G for v6ops@ops.ietf.org; Sat, 09 Oct 2004 17:34:43 +0000 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with SMTP id i99HYgM09991 for ; Sat, 9 Oct 2004 13:34:42 -0400 Received: from smtp-bedford-dr.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford-dr.mitre.org (Postfix) with ESMTP id 6E8894F8E3 for ; Sat, 9 Oct 2004 13:34:42 -0400 (EDT) Received: from MAILHUB2 (mailhub2.mitre.org [129.83.221.18]) by smtp-bedford-dr.mitre.org (8.11.6/8.11.6) with ESMTP id i99HYfv09917; Sat, 9 Oct 2004 13:34:41 -0400 Received: from unity-18-108.mitre.org (129.83.18.108) by mailhub2.mitre.org with SMTP id 5151826; Sat, 09 Oct 2004 13:34:36 -0400 From: "Sham Chakravorty" To: "'Brian E Carpenter'" , "'Senthil Sivakumar'" Cc: "'Cedric Aoun'" , "'V6OPS'" , "'Elwyn Davies'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Sat, 9 Oct 2004 13:34:32 -0400 Message-ID: <000b01c4ae26$3ea61ac0$6701a8c0@MITRE.ORG> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 In-reply-to: <4167E30B.70007@zurich.ibm.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Shivkumar that deprecating NAT-PT really doesn't earn us anything but removes one tool that could be used in specific instances. Application gateways are not in the same usage "level" as NAT-PT - they occur in different points of the network. Also, the underlying algorithm = of SIIT would still be available. =20 Sham -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf Of Brian E Carpenter Sent: Saturday, October 09, 2004 9:10 AM To: Senthil Sivakumar Cc: Cedric Aoun; V6OPS; Elwyn Davies Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > The point I am trying to stress is deprecating this would leave us = with no workable > solution for communicating between IPv4 only networks/nodes/apps IPv6 = only > networks/nodes/apps. As remote as it might seem for some, that is the = use case > scenario we have encountered as the applicability of NAT-PT.=20 But there is a workable alternative, which is an application level = proxy. This too has its disadvantages, of course. Brian Senthil Sivakumar wrote: > I see that the draft has consolidated all the previous drafts that=20 > highlighted the issues > of NAT-PT and DNS ALG, which is a good thing. However, most of the=20 > issues mentioned > here as NAT-PT issues are known issues with address translation (NAT)=20 > itself, so > attributing them to NAT-PT is not correct. Those should be = categorized=20 > as generic address > translation issues. >=20 > Some specfic comments on the following issues. >=20 > * Disruption of all protocols which embed IP addresses (and/or > ports) in packet payloads or which apply integrity mechanisms > using IP addresses (and ports). (not NAT-PT specific). >=20 > * Requirement for applications to use keep alive mechanisms to > workaround connectivity issues caused by premature NAT-PT = state > timeout. (not NAT-PT specific). >=20 > * Inability to redirect packet fragments after the first with > NAPT-PT. (not NAT-PT specific). >=20 > o Issues which are exacerbated by the use of a DNS-ALG: > * Constraints on network topology. (not NAT-PT specific). > * Scalability concerns together with introduction of single = point > of failure and security attack nexus.(not NAT-PT specific). > * Lack of address mapping persistence: Some applications = require > address retention between sessions. The user traffic will be > disrupted if a different mapping is used. The use of the > DNS-ALG to create address mappings with limited lifetimes = means > that applications must start using the address shortly after > the mapping is created, as well as keeping it alive once they > start using it.(not NAT-PT specific). > * Creation of a DOS threat relating to exhaustion of memory and > address/port pool resources on the translator.(not NAT-PT=20 > specific). >=20 > Regarding the conclusion, I don't agree with the fact that only=20 > applicable scenario > is in 3G networks. During the past couple of years of my experience I=20 > have seen > customers using it between isolated IPv6 networks to talk to existing=20 > IPv4 networks. > A lot of cases it is not about the nodes being dual stack or not, it = is=20 > the network > that is not dual stacked for operational reasons. >=20 > I have been gathering some inputs from the customers who are using=20 > NAT-PT currently > regarding this draft. I can consolidate and forward the comments if = you=20 > are interested in > knowing and understanding why they think they are moving forward with=20 > NAT-PT. >=20 > The point I am trying to stress is deprecating this would leave us = with=20 > no workable > solution for communicating between IPv4 only networks/nodes/apps IPv6 = only > networks/nodes/apps. As remote as it might seem for some, that is the=20 > use case > scenario we have encountered as the applicability of NAT-PT. >=20 > Senthil >=20 > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: >=20 >> Hi, >> As discussed at IETF 60, the WG agreed to continue the NAT-PT=20 >> deprecation analysis. >> We would really appreciate if you could provide us your feedback on=20 >> the initial version of the deprecation analysis by Monday October = 4th. >> Regards >> Cedric Aoun >> ------ Forwarded Message >> From: >> Reply-To: >> Date: Tue, 21 Sep 2004 21:38:33 +0200 >> To: >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts=20 >> directories. >> >> >> >> Title : Reasons to Deprecate NAT-PT >> Author(s) : C. Aoun, E. Davies >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt >> Pages : 24 >> Date : 2004-9-21 >> >> This document discusses reasons why use of the specific form of >> IPv6-IPv4 protocol translation mechanism implemented by the = Network >> Address Translator - Protocol Translator (NAT-PT) defined in RFC = 2766 >> should be deprecated and RFC2766 moved to historic status. >> Description of an alternative protocol translation mechanism is = out >> of scope for this document. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-deprecate-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=20 >> 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=20 >> username >> "anonymous" and a password of your e-mail address. After logging in, >> type "cd internet-drafts" and then >> "get draft-aoun-v6ops-natpt-deprecate-00.txt". >> >> A list of Internet-Drafts directories can be found in >> http://www.ietf.org/shadow.html >> or=20 >> ftp://ftp.ietf.org/ietf/1shado= w-s ites.txt=20 >> >> >> >> >> Internet-Drafts can also be obtained by e-mail. >> >> Send a message to: >> mailserv@ietf.org. >> In the body type: >> "FILE = /internet-drafts/draft-aoun-v6ops-natpt-deprecate-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=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. >> >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> >> ------ End of Forwarded Message >> >=20 From owner-v6ops@ops.ietf.org Sun Oct 10 04:19:04 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22137 for ; Sun, 10 Oct 2004 04:19:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGYsI-0009mS-Ju for v6ops-data@psg.com; Sun, 10 Oct 2004 08:16:14 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGYsG-0009lW-76 for v6ops@ops.ietf.org; Sun, 10 Oct 2004 08:16:12 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9A8G5m23384; Sun, 10 Oct 2004 10:16:05 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Sun, 10 Oct 2004 10:16:03 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D4580A3@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Sham Chakravorty'" , "'Brian E Carpenter'" , "'Senthil Sivakumar'" Cc: "Cedric Aoun" , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Sun, 10 Oct 2004 10:16:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AEA1.6276807C" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4AEA1.6276807C Content-Type: text/plain Three points: - The object of the draft was to summarize in one place all the problems with NAT-PT rather than being yet another delta on previous work. The introduction notes that several of the points are indeed generic address translation problems. This doesn't make them any less relevant. - The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG solution intended for use as a generic inter-cloud translator. It is clear to me that a 'cut down' form has a use as a legacy v4 'server adaptor' front end where there is only one v4 address (or maybe a server cluster) on one side, it only has to handle a pre-defined set of protocols, and it doesn't need a DNS-ALG. I think this should be the subject of a separate draft. - The fundamental point is whether v6ops should still be continuing to support a technology which will, if widely deployed, effectively stifle innovation in v6 networks. The need for applications to be aware that NAT-PT exists effectively condemns v6 to be just v4 with larger addresses at the application level. Is this what is wanted? Or should we really be trying to put the architectural flexibility back into the Internet? It would be useful to see Shivkumar's use cases so that they could be considered for inclusion in the relevant transition analysis. If people are using NAT-PT in a particular way then we need to give them a workable alternative before ditching NAT-PT. Regards, Elwyn > -----Original Message----- > From: Sham Chakravorty [mailto:schakra@mitre.org] > Sent: 09 October 2004 18:35 > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > [HAL02:0S00:EXCH] > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > I agree with Shivkumar that deprecating NAT-PT really doesn't earn us > anything but removes one tool that could be used in specific > instances. > Application gateways are not in the same usage "level" as > NAT-PT - they > occur in different points of the network. Also, the > underlying algorithm of > SIIT would still be available. > > Sham > > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf > Of Brian E Carpenter > Sent: Saturday, October 09, 2004 9:10 AM > To: Senthil Sivakumar > Cc: Cedric Aoun; V6OPS; Elwyn Davies > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > The point I am trying to stress is deprecating this would > leave us with no > workable > > solution for communicating between IPv4 only > networks/nodes/apps IPv6 only > > networks/nodes/apps. As remote as it might seem for some, > that is the use > case > > scenario we have encountered as the applicability of NAT-PT. > > But there is a workable alternative, which is an application > level proxy. > This too has its disadvantages, of course. > > Brian > > Senthil Sivakumar wrote: > > I see that the draft has consolidated all the previous drafts that > > highlighted the issues > > of NAT-PT and DNS ALG, which is a good thing. However, most of the > > issues mentioned > > here as NAT-PT issues are known issues with address > translation (NAT) > > itself, so > > attributing them to NAT-PT is not correct. Those should be > categorized > > as generic address > > translation issues. > > > > Some specfic comments on the following issues. > > > > * Disruption of all protocols which embed IP addresses (and/or > > ports) in packet payloads or which apply integrity > mechanisms > > using IP addresses (and ports). (not NAT-PT specific). > > > > * Requirement for applications to use keep alive > mechanisms to > > workaround connectivity issues caused by premature > NAT-PT state > > timeout. (not NAT-PT specific). > > > > * Inability to redirect packet fragments after the > first with > > NAPT-PT. (not NAT-PT specific). > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > * Constraints on network topology. (not NAT-PT specific). > > * Scalability concerns together with introduction of > single point > > of failure and security attack nexus.(not NAT-PT specific). > > * Lack of address mapping persistence: Some > applications require > > address retention between sessions. The user > traffic will be > > disrupted if a different mapping is used. The use of the > > DNS-ALG to create address mappings with limited > lifetimes means > > that applications must start using the address > shortly after > > the mapping is created, as well as keeping it > alive once they > > start using it.(not NAT-PT specific). > > * Creation of a DOS threat relating to exhaustion of > memory and > > address/port pool resources on the translator.(not NAT-PT > > specific). > > > > Regarding the conclusion, I don't agree with the fact that only > > applicable scenario > > is in 3G networks. During the past couple of years of my > experience I > > have seen > > customers using it between isolated IPv6 networks to talk > to existing > > IPv4 networks. > > A lot of cases it is not about the nodes being dual stack > or not, it is > > the network > > that is not dual stacked for operational reasons. > > > > I have been gathering some inputs from the customers who are using > > NAT-PT currently > > regarding this draft. I can consolidate and forward the > comments if you > > are interested in > > knowing and understanding why they think they are moving > forward with > > NAT-PT. > > > > The point I am trying to stress is deprecating this would > leave us with > > no workable > > solution for communicating between IPv4 only > networks/nodes/apps IPv6 only > > networks/nodes/apps. As remote as it might seem for some, > that is the > > use case > > scenario we have encountered as the applicability of NAT-PT. > > > > Senthil > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > >> Hi, > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > >> deprecation analysis. > >> We would really appreciate if you could provide us your > feedback on > >> the initial version of the deprecation analysis by Monday > October 4th. > >> Regards > >> Cedric Aoun > >> ------ Forwarded Message > >> From: > >> Reply-To: > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > >> To: > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > >> directories. > >> > >> > >> > >> Title : Reasons to Deprecate NAT-PT > >> Author(s) : C. Aoun, E. Davies > >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt > >> Pages : 24 > >> Date : 2004-9-21 > >> > >> This document discusses reasons why use of the specific form of > >> IPv6-IPv4 protocol translation mechanism implemented by > the Network > >> Address Translator - Protocol Translator (NAT-PT) > defined in RFC 2766 > >> should be deprecated and RFC2766 moved to historic status. > >> Description of an alternative protocol translation > mechanism is out > >> of scope for this document. > >> > >> A URL for this Internet-Draft is: > >> > precate-00.txt > >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > precate-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-aoun-v6ops-natpt-deprecate-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-s ites.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-aoun-v6ops-natpt-deprecate-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. >> >> >> >> >> ------ End of Forwarded Message >> > ------_=_NextPart_001_01C4AEA1.6276807C Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

Three points:
- The object of the draft was to summarize in one = place all the problems with NAT-PT rather than being yet another delta = on previous work.  The introduction notes that several of the = points are indeed generic address translation problems.  This = doesn't make them any less relevant.

- The draft is specifically targeting the NAT-PT =3D = SIIT + DNS-ALG solution intended for use as a generic inter-cloud = translator.  It is clear to me that a 'cut down' form has a use as = a legacy v4 'server adaptor' front end where there is only one v4 = address (or maybe a server cluster) on one side, it only has to handle = a pre-defined set of protocols, and it doesn't need a DNS-ALG.  I = think this should be the subject of a separate draft.

- The fundamental point is whether v6ops should still = be continuing to support a technology which will, if widely deployed, = effectively stifle innovation in v6 networks.  The need for = applications to be aware that NAT-PT exists effectively condemns v6 to = be just v4 with larger addresses at the application level. Is this what = is wanted? Or should we really be trying to put the architectural = flexibility back into the Internet?

It would be useful to see Shivkumar's use cases so = that they could be considered for inclusion in the relevant transition = analysis.  If people are using NAT-PT in a particular way then we = need to give them a workable alternative before ditching = NAT-PT.

Regards,
Elwyn

> -----Original Message-----
> From: Sham Chakravorty [mailto:schakra@mitre.org]
> Sent: 09 October 2004 18:35
> To: 'Brian E Carpenter'; 'Senthil = Sivakumar'
> Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; = Davies, Elwyn
> [HAL02:0S00:EXCH]
> Subject: RE: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> I agree with Shivkumar that deprecating NAT-PT = really doesn't earn us
> anything but removes one tool that could be = used in specific
> instances.
> Application gateways are not in the same usage = "level" as
> NAT-PT - they
> occur in different points of the network. Also, = the
> underlying algorithm of
> SIIT would still be available. 
>
> Sham
>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org= ] On Behalf
> Of Brian E Carpenter
> Sent: Saturday, October 09, 2004 9:10 AM
> To: Senthil Sivakumar
> Cc: Cedric Aoun; V6OPS; Elwyn Davies
> Subject: Re: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> > The point I am trying to stress is = deprecating this would
> leave us with no
> workable
> > solution for communicating between IPv4 = only
> networks/nodes/apps IPv6 only
> > networks/nodes/apps. As remote as it might = seem for some,
> that is the use
> case
> > scenario we have encountered as the = applicability of NAT-PT.
>
> But there is a workable alternative, which is = an application
> level proxy.
> This too has its disadvantages, of = course.
>
>      Brian
>
> Senthil Sivakumar wrote:
> > I see that the draft has consolidated all = the previous drafts that
> > highlighted the issues
> > of NAT-PT and DNS ALG, which is a good = thing. However, most of the
> > issues mentioned
> > here as NAT-PT issues are known issues = with address
> translation (NAT)
> > itself, so
> > attributing them to NAT-PT is not = correct.  Those should be
> categorized
> > as generic address
> > translation issues.
> >
> > Some specfic comments on the following = issues.
> >
> >      *  = Disruption of all protocols which embed IP addresses (and/or
> = >          ports) in = packet payloads or which apply integrity
> mechanisms
> = >          using IP = addresses (and ports). (not NAT-PT specific).
> >
> >       = *  Requirement for applications to use keep alive
> mechanisms to
> = >          workaround = connectivity issues caused by premature
> NAT-PT state
> = >          timeout. = (not NAT-PT specific).
> >
> >        = *  Inability to redirect packet fragments after the
> first with
> = >          NAPT-PT. = (not NAT-PT specific).
> >
> >    o  Issues which are = exacerbated by the use of a DNS-ALG:
> >       = *  Constraints on network topology. (not NAT-PT specific).
> >       = *  Scalability concerns together with introduction of
> single point
> = >          of failure = and security attack nexus.(not NAT-PT specific).
> >       = *  Lack of address mapping persistence: Some
> applications require
> = >          address = retention between sessions.  The user
> traffic will be
> = >          disrupted if = a different mapping is used.  The use of the
> = >          DNS-ALG to = create address mappings with limited
> lifetimes means
> = >          that = applications must start using the address
> shortly after
> = >          the mapping = is created, as well as keeping it
> alive once they
> = >          start using = it.(not NAT-PT specific).
> >       = *  Creation of a DOS threat relating to exhaustion of
> memory and
> = >          address/port = pool resources on the translator.(not NAT-PT
> > specific).
> >
> > Regarding the conclusion, I don't agree = with the fact that only
> > applicable scenario
> > is in 3G networks. During the past couple = of years of my
> experience I
> > have seen
> > customers using it between isolated IPv6 = networks to talk
> to existing
> > IPv4 networks.
> > A lot of cases it is not about the nodes = being dual stack
> or not, it is
> > the network
> > that is not dual stacked for operational = reasons.
> >
> > I have been gathering some inputs from the = customers who are using
> > NAT-PT currently
> > regarding this draft. I can consolidate = and forward the
> comments if you
> > are interested in
> > knowing and understanding why they think = they are moving
> forward with
> > NAT-PT.
> >
> > The point I am trying to stress is = deprecating this would
> leave us with
> > no workable
> > solution for communicating between IPv4 = only
> networks/nodes/apps IPv6 only
> > networks/nodes/apps. As remote as it might = seem for some,
> that is the
> > use case
> > scenario we have encountered as the = applicability of NAT-PT.
> >
> > Senthil
> >
> > At 10:12 AM 9/22/2004 +0200, Cedric Aoun = wrote:
> >
> >> Hi,
> >> As discussed at IETF 60, the WG agreed = to continue the NAT-PT
> >> deprecation analysis.
> >> We would really appreciate if you = could provide us your
> feedback on
> >> the initial version of the deprecation = analysis by Monday
> October 4th.
> >> Regards
> >> Cedric Aoun
> >> ------ Forwarded Message
> >> From: = <Internet-Drafts@ietf.org>
> >> Reply-To: = <internet-drafts@ietf.org>
> >> Date: Tue, 21 Sep 2004 21:38:33 = +0200
> >> To: = <i-d-announce@ietf.org>
> >> Subject: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> >>
> >> A New Internet-Draft is available from = the on-line Internet-Drafts
> >> directories.
> >>
> >>
> >>
> = >>         = Title           : = Reasons to Deprecate NAT-PT
> = >>         = Author(s)       : C. Aoun, E. = Davies
> = >>         = Filename        : = draft-aoun-v6ops-natpt-deprecate-00.txt
> = >>         = Pages           : = 24
> = >>         = Date            = : 2004-9-21
> >>
> >> This document discusses reasons why = use of the specific form of
> >>    IPv6-IPv4 protocol = translation mechanism implemented by
> the Network
> >>    Address Translator - = Protocol Translator (NAT-PT)
> defined in RFC 2766
> >>    should be deprecated = and RFC2766 moved to historic status.
> >>    Description of an = alternative protocol translation
> mechanism is out
> >>    of scope for this = document.
> >>
> >> A URL for this Internet-Draft = is:
> >>
> <http://www.ietf.org/internet-drafts/draft-aoun-v6ops-n= atpt-de
> precate-00.txt
> >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-n= atpt-de
> precate-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-aoun-v6ops-natpt-deprecate-00.txt".
> >>
> >> A list of Internet-Drafts directories = can be found in
> >> <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> >> or
> >>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/
ietf/1shadow-s
ites.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-aoun-v6ops-natpt-deprecate-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.
>>
>>
>>
>>
>> ------ End of Forwarded Message
>>
>




------_=_NextPart_001_01C4AEA1.6276807C-- From owner-v6ops@ops.ietf.org Sun Oct 10 05:24:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA25929 for ; Sun, 10 Oct 2004 05:24:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGZuI-000GRF-Vu for v6ops-data@psg.com; Sun, 10 Oct 2004 09:22:22 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGZuI-000GQp-5u for v6ops@ops.ietf.org; Sun, 10 Oct 2004 09:22: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 i9A9MKGn023751 for ; Sun, 10 Oct 2004 10:22: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 KAA09947 for ; Sun, 10 Oct 2004 10:22:19 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9A9MJJ28279 for v6ops@ops.ietf.org; Sun, 10 Oct 2004 10:22:19 +0100 Date: Sun, 10 Oct 2004 10:22:19 +0100 From: Tim Chown To: "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Message-ID: <20041010092219.GA28145@login.ecs.soton.ac.uk> Mail-Followup-To: 'V6OPS' References: <8F20221FB47FD51190AD00508BCF36BA0D4580A3@znsgy0k3.europe.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4580A3@znsgy0k3.europe.nortel.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Sun, Oct 10, 2004 at 10:16:04AM +0200, Elwyn Davies wrote: > > It would be useful to see Shivkumar's use cases so that they could be > considered for inclusion in the relevant transition analysis. If > people are using NAT-PT in a particular way then we need to give them > a workable alternative before ditching NAT-PT. I think this is key - the enterprise analysis in v6ops is happening now. However, a) noone is commenting on the work b) at present, there is no cited case for NAT-PT in the solutions I would thus strongly urge those who feel NAT-PT is important to state the scenarios and cases where it should be recommended. It is not at all clear what those cases are at present. Tim From owner-v6ops@ops.ietf.org Sun Oct 10 10:23:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13794 for ; Sun, 10 Oct 2004 10:23:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGeZB-000HrQ-TY for v6ops-data@psg.com; Sun, 10 Oct 2004 14:20:53 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGeZA-000HrC-U0 for v6ops@ops.ietf.org; Sun, 10 Oct 2004 14:20:53 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 1EE78CBCF; Sun, 10 Oct 2004 10:20:52 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 10 Oct 2004 10:20:51 -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: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Sun, 10 Oct 2004 10:20:57 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A272@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Thread-Index: AcSuqvVdEV4gz64zQY62K3sIHxHyXQAJ5Zyg From: "Bound, Jim" To: "Tim Chown" , "V6OPS" X-OriginalArrivalTime: 10 Oct 2004 14:20:51.0970 (UTC) FILETIME=[58D26620:01C4AED4] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable I agree with Tim below and key point Elwyn made regarding stifling IPv6 deployment. NAT-PT should be deprecated and SIIT should be left as tool to build translation when no other choice is possible. =20 Lets also be clear about proxies to they are a performance nightmare worse than NAT and will not solve the E2E security trust problem, when IPsec is used, unless a decrypt engine is supported on the inbound and encrypt engine on the outbound. I can get into more technical details if we must but I think that should be clear. Proxies should also not be elevated as a solution for IPv6 either I detest them as bas as NAT. But, a use case is as follows: Premise 1: Embedded hardware system cannot be upgraded to be IPv6 capable, which means can support a dual stack. Reasons could be it uses ASIC IP stack technology, or the download software or firmware simply cannot add a new stack to create an IPv6 capable node. Premise 2: The network function or applicability to the user provided by the IPv4 legacy system is absolutely required for operations and must be supported as legacy system. Premise 3: The new IPv6 capable systems simply have no more IPv4 addresses to communicate with the legacy IPv4 system above. Premise 4: The new IPv6 capable systems network simply is unable to receive IPv4 packets from any legacy system. /jim =20 > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > Sent: Sunday, October 10, 2004 5:22 AM > To: 'V6OPS' > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >=20 > On Sun, Oct 10, 2004 at 10:16:04AM +0200, Elwyn Davies wrote: > >=20 > > It would be useful to see Shivkumar's use cases so that=20 > they could be > > considered for inclusion in the relevant transition=20 > analysis. If > > people are using NAT-PT in a particular way then we=20 > need to give them > > a workable alternative before ditching NAT-PT. >=20 > I think this is key - the enterprise analysis in v6ops is=20 > happening now. > However, >=20 > a) noone is commenting on the work >=20 > b) at present, there is no cited case for NAT-PT in the=20 > solutions >=20 > I would thus strongly urge those who feel NAT-PT is important=20 > to state the > scenarios and cases where it should be recommended. It is=20 > not at all clear > what those cases are at present. >=20 > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Sun Oct 10 13:06:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24648 for ; Sun, 10 Oct 2004 13:06:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGh7x-0009GV-9g for v6ops-data@psg.com; Sun, 10 Oct 2004 17:04:57 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGh7v-0009GC-AY for v6ops@ops.ietf.org; Sun, 10 Oct 2004 17:04:55 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 10 Oct 2004 10:06:06 -0700 X-BrightmailFiltered: true Received: from ssenthil-w2k.cisco.com (stealth-10-32-254-220.cisco.com [10.32.254.220]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id i9AH4gmR004267; Sun, 10 Oct 2004 10:04:43 -0700 (PDT) Message-Id: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 10 Oct 2004 10:05:20 -0700 To: "Elwyn Davies" From: Senthil Sivakumar Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Cc: "'Sham Chakravorty'" , "'Brian E Carpenter'" , "Cedric Aoun" , "'V6OPS'" In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4580A3@znsgy0k3.europe.n ortel.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_42852047==_" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_42852047==_ Content-Type: multipart/alternative; boundary="=====================_42852058==_.ALT" --=====================_42852058==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: >Three points: >- The object of the draft was to summarize in one place all the problems >with NAT-PT rather than being yet another delta on previous work. The >introduction notes that several of the points are indeed generic address >translation problems. This doesn't make them any less relevant. I am fine with summarizing the issues in one draft. But the draft points out those as reasons to deprecate which is what I am pointing out. >- The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG solution >intended for use as a generic inter-cloud translator. It is clear to me >that a 'cut down' form has a use as a legacy v4 'server adaptor' front end >where there is only one v4 address (or maybe a server cluster) on one >side, it only has to handle a pre-defined set of protocols, and it doesn't >need a DNS-ALG. I think this should be the subject of a separate draft. While I agree with you the cut-down solution does not need a DNS-ALG, I don't think it has to handle a specific set of protocols. I could still be a generic purpose translator for facilitating transition. I am attaching a document which was one of the use case scenario we are aware of. >- The fundamental point is whether v6ops should still be continuing to >support a technology which will, if widely deployed, effectively stifle >innovation in v6 networks. The need for applications to be aware that >NAT-PT exists effectively condemns v6 to be just v4 with larger addresses >at the application level. Is this what is wanted? Or should we really be >trying to put the architectural flexibility back into the Internet? I am not understanding why you say applications have to aware of existence of NAT-PT. >It would be useful to see Shivkumar's use cases so that they could be >considered for inclusion in the relevant transition analysis. If people >are using NAT-PT in a particular way then we need to give them a workable >alternative before ditching NAT-PT. Exactly. We should not prematurely deprecate the solution without an alternative in place. Thnks Senthil >Regards, >Elwyn > > > -----Original Message----- > > From: Sham Chakravorty > [mailto:schakra@mitre.org] > > Sent: 09 October 2004 18:35 > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > [HAL02:0S00:EXCH] > > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > I agree with Shivkumar that deprecating NAT-PT really doesn't earn us > > anything but removes one tool that could be used in specific > > instances. > > Application gateways are not in the same usage "level" as > > NAT-PT - they > > occur in different points of the network. Also, the > > underlying algorithm of > > SIIT would still be available. > > > > Sham > > > > -----Original Message----- > > From: owner-v6ops@ops.ietf.org > > [mailto:owner-v6ops@ops.ietf.org] On > Behalf > > Of Brian E Carpenter > > Sent: Saturday, October 09, 2004 9:10 AM > > To: Senthil Sivakumar > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > The point I am trying to stress is deprecating this would > > leave us with no > > workable > > > solution for communicating between IPv4 only > > networks/nodes/apps IPv6 only > > > networks/nodes/apps. As remote as it might seem for some, > > that is the use > > case > > > scenario we have encountered as the applicability of NAT-PT. > > > > But there is a workable alternative, which is an application > > level proxy. > > This too has its disadvantages, of course. > > > > Brian > > > > Senthil Sivakumar wrote: > > > I see that the draft has consolidated all the previous drafts that > > > highlighted the issues > > > of NAT-PT and DNS ALG, which is a good thing. However, most of the > > > issues mentioned > > > here as NAT-PT issues are known issues with address > > translation (NAT) > > > itself, so > > > attributing them to NAT-PT is not correct. Those should be > > categorized > > > as generic address > > > translation issues. > > > > > > Some specfic comments on the following issues. > > > > > > * Disruption of all protocols which embed IP addresses (and/or > > > ports) in packet payloads or which apply integrity > > mechanisms > > > using IP addresses (and ports). (not NAT-PT specific). > > > > > > * Requirement for applications to use keep alive > > mechanisms to > > > workaround connectivity issues caused by premature > > NAT-PT state > > > timeout. (not NAT-PT specific). > > > > > > * Inability to redirect packet fragments after the > > first with > > > NAPT-PT. (not NAT-PT specific). > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > * Constraints on network topology. (not NAT-PT specific). > > > * Scalability concerns together with introduction of > > single point > > > of failure and security attack nexus.(not NAT-PT specific). > > > * Lack of address mapping persistence: Some > > applications require > > > address retention between sessions. The user > > traffic will be > > > disrupted if a different mapping is used. The use of the > > > DNS-ALG to create address mappings with limited > > lifetimes means > > > that applications must start using the address > > shortly after > > > the mapping is created, as well as keeping it > > alive once they > > > start using it.(not NAT-PT specific). > > > * Creation of a DOS threat relating to exhaustion of > > memory and > > > address/port pool resources on the translator.(not NAT-PT > > > specific). > > > > > > Regarding the conclusion, I don't agree with the fact that only > > > applicable scenario > > > is in 3G networks. During the past couple of years of my > > experience I > > > have seen > > > customers using it between isolated IPv6 networks to talk > > to existing > > > IPv4 networks. > > > A lot of cases it is not about the nodes being dual stack > > or not, it is > > > the network > > > that is not dual stacked for operational reasons. > > > > > > I have been gathering some inputs from the customers who are using > > > NAT-PT currently > > > regarding this draft. I can consolidate and forward the > > comments if you > > > are interested in > > > knowing and understanding why they think they are moving > > forward with > > > NAT-PT. > > > > > > The point I am trying to stress is deprecating this would > > leave us with > > > no workable > > > solution for communicating between IPv4 only > > networks/nodes/apps IPv6 only > > > networks/nodes/apps. As remote as it might seem for some, > > that is the > > > use case > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > Senthil > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > >> Hi, > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > >> deprecation analysis. > > >> We would really appreciate if you could provide us your > > feedback on > > >> the initial version of the deprecation analysis by Monday > > October 4th. > > >> Regards > > >> Cedric Aoun > > >> ------ Forwarded Message > > >> From: > > >> Reply-To: > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > >> To: > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > >> > > >> A New Internet-Draft is available from the on-line Internet-Drafts > > >> directories. > > >> > > >> > > >> > > >> Title : Reasons to Deprecate NAT-PT > > >> Author(s) : C. Aoun, E. Davies > > >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt > > >> Pages : 24 > > >> Date : 2004-9-21 > > >> > > >> This document discusses reasons why use of the specific form of > > >> IPv6-IPv4 protocol translation mechanism implemented by > > the Network > > >> Address Translator - Protocol Translator (NAT-PT) > > defined in RFC 2766 > > >> should be deprecated and RFC2766 moved to historic status. > > >> Description of an alternative protocol translation > > mechanism is out > > >> of scope for this document. > > >> > > >> A URL for this Internet-Draft is: > > >> > > > <http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > precate-00.txt > > >http://w > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > precate-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-aoun-v6ops-natpt-deprecate-00.txt". > > >> > > >> A list of Internet-Drafts directories can be found in > > >> > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html > > > >> or > > >> > > > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > >ietf/1shadow-s >ites.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-aoun-v6ops-natpt-deprecate-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. > >> > >> > >> > >> > >> ------ End of Forwarded Message > >> > > > > --=====================_42852058==_.ALT Content-Type: text/html; charset="us-ascii" At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote:

Three points:
- The object of the draft was to summarize in one place all the problems with NAT-PT rather than being yet another delta on previous work.  The introduction notes that several of the points are indeed generic address translation problems.  This doesn't make them any less relevant.

I am fine with summarizing the issues in one draft. But the draft points out those as reasons to deprecate
which is what I am pointing out.

- The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG solution intended for use as a generic inter-cloud translator.  It is clear to me that a 'cut down' form has a use as a legacy v4 'server adaptor' front end where there is only one v4 address (or maybe a server cluster) on one side, it only has to handle a pre-defined set of protocols, and it doesn't need a DNS-ALG.  I think this should be the subject of a separate draft.

While I agree with you the cut-down solution does not need a DNS-ALG, I don't think it has to handle a
specific set of protocols. I could still be a generic purpose translator for facilitating transition. I am attaching
a document which was one of the use case scenario we are aware of.

- The fundamental point is whether v6ops should still be continuing to support a technology which will, if widely deployed, effectively stifle innovation in v6 networks.  The need for applications to be aware that NAT-PT exists effectively condemns v6 to be just v4 with larger addresses at the application level. Is this what is wanted? Or should we really be trying to put the architectural flexibility back into the Internet?

I am not understanding why you say applications have to aware of existence of NAT-PT.


It would be useful to see Shivkumar's use cases so that they could be considered for inclusion in the relevant transition analysis.  If people are using NAT-PT in a particular way then we need to give them a workable alternative before ditching NAT-PT.

Exactly. We should not prematurely deprecate the solution without an alternative in place.

Thnks
Senthil

Regards,
Elwyn

> -----Original Message-----
> From: Sham Chakravorty [mailto:schakra@mitre.org]
> Sent: 09 October 2004 18:35
> To: 'Brian E Carpenter'; 'Senthil Sivakumar'
> Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn
> [HAL02:0S00:EXCH]
> Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> I agree with Shivkumar that deprecating NAT-PT really doesn't earn us
> anything but removes one tool that could be used in specific
> instances.
> Application gateways are not in the same usage "level" as
> NAT-PT - they
> occur in different points of the network. Also, the
> underlying algorithm of
> SIIT would still be available. 
>
> Sham
>
> -----Original Message-----
> From: owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org] On Behalf
> Of Brian E Carpenter
> Sent: Saturday, October 09, 2004 9:10 AM
> To: Senthil Sivakumar
> Cc: Cedric Aoun; V6OPS; Elwyn Davies
> Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> > The point I am trying to stress is deprecating this would
> leave us with no
> workable
> > solution for communicating between IPv4 only
> networks/nodes/apps IPv6 only
> > networks/nodes/apps. As remote as it might seem for some,
> that is the use
> case
> > scenario we have encountered as the applicability of NAT-PT.
>
> But there is a workable alternative, which is an application
> level proxy.
> This too has its disadvantages, of course.
>
>      Brian
>
> Senthil Sivakumar wrote:
> > I see that the draft has consolidated all the previous drafts that
> > highlighted the issues
> > of NAT-PT and DNS ALG, which is a good thing. However, most of the
> > issues mentioned
> > here as NAT-PT issues are known issues with address
> translation (NAT)
> > itself, so
> > attributing them to NAT-PT is not correct.  Those should be
> categorized
> > as generic address
> > translation issues.
> >
> > Some specfic comments on the following issues.
> >
> >      *  Disruption of all protocols which embed IP addresses (and/or
> >          ports) in packet payloads or which apply integrity
> mechanisms
> >          using IP addresses (and ports). (not NAT-PT specific).
> >
> >       *  Requirement for applications to use keep alive
> mechanisms to
> >          workaround connectivity issues caused by premature
> NAT-PT state
> >          timeout. (not NAT-PT specific).
> >
> >        *  Inability to redirect packet fragments after the
> first with
> >          NAPT-PT. (not NAT-PT specific).
> >
> >    o  Issues which are exacerbated by the use of a DNS-ALG:
> >       *  Constraints on network topology. (not NAT-PT specific).
> >       *  Scalability concerns together with introduction of
> single point
> >          of failure and security attack nexus.(not NAT-PT specific).
> >       *  Lack of address mapping persistence: Some
> applications require
> >          address retention between sessions.  The user
> traffic will be
> >          disrupted if a different mapping is used.  The use of the
> >          DNS-ALG to create address mappings with limited
> lifetimes means
> >          that applications must start using the address
> shortly after
> >          the mapping is created, as well as keeping it
> alive once they
> >          start using it.(not NAT-PT specific).
> >       *  Creation of a DOS threat relating to exhaustion of
> memory and
> >          address/port pool resources on the translator.(not NAT-PT
> > specific).
> >
> > Regarding the conclusion, I don't agree with the fact that only
> > applicable scenario
> > is in 3G networks. During the past couple of years of my
> experience I
> > have seen
> > customers using it between isolated IPv6 networks to talk
> to existing
> > IPv4 networks.
> > A lot of cases it is not about the nodes being dual stack
> or not, it is
> > the network
> > that is not dual stacked for operational reasons.
> >
> > I have been gathering some inputs from the customers who are using
> > NAT-PT currently
> > regarding this draft. I can consolidate and forward the
> comments if you
> > are interested in
> > knowing and understanding why they think they are moving
> forward with
> > NAT-PT.
> >
> > The point I am trying to stress is deprecating this would
> leave us with
> > no workable
> > solution for communicating between IPv4 only
> networks/nodes/apps IPv6 only
> > networks/nodes/apps. As remote as it might seem for some,
> that is the
> > use case
> > scenario we have encountered as the applicability of NAT-PT.
> >
> > Senthil
> >
> > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
> >
> >> Hi,
> >> As discussed at IETF 60, the WG agreed to continue the NAT-PT
> >> deprecation analysis.
> >> We would really appreciate if you could provide us your
> feedback on
> >> the initial version of the deprecation analysis by Monday
> October 4th.
> >> Regards
> >> Cedric Aoun
> >> ------ Forwarded Message
> >> From: <Internet-Drafts@ietf.org>
> >> Reply-To: <internet-drafts@ietf.org>
> >> Date: Tue, 21 Sep 2004 21:38:33 +0200
> >> To: <i-d-announce@ietf.org>
> >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> >> directories.
> >>
> >>
> >>
> >>         Title           : Reasons to Deprecate NAT-PT
> >>         Author(s)       : C. Aoun, E. Davies
> >>         Filename        : draft-aoun-v6ops-natpt-deprecate-00.txt
> >>         Pages           : 24
> >>         Date            : 2004-9-21
> >>
> >> This document discusses reasons why use of the specific form of
> >>    IPv6-IPv4 protocol translation mechanism implemented by
> the Network
> >>    Address Translator - Protocol Translator (NAT-PT)
> defined in RFC 2766
> >>    should be deprecated and RFC2766 moved to historic status.
> >>    Description of an alternative protocol translation
> mechanism is out
> >>    of scope for this document.
> >>
> >> A URL for this Internet-Draft is:
> >>
> <http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> precate-00.txt
> >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> precate-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-aoun-v6ops-natpt-deprecate-00.txt".
> >>
> >> A list of Internet-Drafts directories can be found in
> >> <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
> >> or
> >>
> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/
ietf/1shadow-s
ites.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-aoun-v6ops-natpt-deprecate-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.
>>
>>
>>
>>
>> ------ End of Forwarded Message
>>
>


--=====================_42852058==_.ALT-- --=====================_42852047==_ Content-Type: application/msword; name="nat-pt-scenario.doc"; x-mac-type="42494E41"; x-mac-creator="4D535744" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="nat-pt-scenario.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAwwAAAAAAAAAA EAAAxQAAAAEAAAD+////AAAAAMEAAADCAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAVUAJBAAA+BK/AAAAAAAAEAAAAAAABgAAIxAAAA4AYmpiaqybrJsAAAAAAAAAAAAAAAAAAAAA AAAJBBYAIhoAAM7xAADO8QAAIwgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAIgAAAAAAIQBAAAAAAAAhAEAAIQB AAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAhAEAABQAAAAAAAAAAAAAAJgBAAAAAAAAgAgA AAAAAACACAAAAAAAAIAIAAAAAAAAgAgAAAwAAACMCAAAFAAAAJgBAAAAAAAA/wkAALYAAACsCAAA AAAAAKwIAAAAAAAArAgAAAAAAACsCAAAAAAAAKwIAAAAAAAArAgAAAAAAACsCAAAAAAAAKwIAAAA AAAAfgkAAAIAAACACQAAAAAAAIAJAAAAAAAAgAkAAAAAAACACQAAAAAAAIAJAAAAAAAAgAkAACQA AAC1CgAAUgIAAAcNAAC2AAAApAkAABUAAAAAAAAAAAAAAAAAAAAAAAAAhAEAAAAAAACsCAAAAAAA AAAAAAAAAAAAAAAAAAAAAACsCAAAAAAAAKwIAAAAAAAArAgAAAAAAACsCAAAAAAAAKQJAAAAAAAA AAAAAAAAAACEAQAAAAAAAIQBAAAAAAAArAgAAAAAAAAAAAAAAAAAAKwIAAAAAAAAuQkAABYAAAA2 CQAAAAAAADYJAAAAAAAANgkAAAAAAACsCAAAAAAAAIQBAAAAAAAArAgAAAAAAACEAQAAAAAAAKwI AAAAAAAAfgkAAAAAAAAAAAAAAAAAADYJAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAArAgAAAAAAAB+CQAAAAAAADYJAAAsAAAANgkAAAAAAAAAAAAA AAAAAGIJAAAAAAAAhAEAAAAAAACEAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYgkAAAAAAACsCAAAAAAAAKAIAAAMAAAAoHBnh+qu xAEAAAAAAAAAAIAIAAAAAAAArAgAAHYAAABiCQAAAAAAAAAAAAAAAAAAfgkAAAAAAADPCQAAMAAA AP8JAAAAAAAAYgkAAAAAAAC9DQAAAAAAACIJAAAKAAAAvQ0AAAAAAABiCQAAAAAAAAAAAAAAAAAA mAEAAAAAAACYAQAAAAAAAIQBAAAAAAAAhAEAAAAAAACEAQAAAAAAAIQBAAAAAAAAAAAAAAAAAAAA AAAAAAAAAL0NAAAAAAAAAAAAAAAAAACEAQAAAAAAAGIJAAAcAAAArAgAAAAAAACsCAAAAAAAADYJ AAAAAAAArAgAAAAAAACsCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAArAgA AAAAAACsCAAAAAAAAKwIAAAAAAAApAkAAAAAAACkCQAAAAAAAJgBAAAAAAAAmAEAAIQDAAAcBQAA ZAMAAAAAAAAAAAAALAkAAAoAAACYAQAAAAAAAJgBAAAAAAAAHAUAAAAAAAACAAEBAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFRoZSBw b3RlbnRpYWwgbWlncmF0aW9uIG9wdGlvbnMgYXJlOg0xLiBSZW51bWJlciBhbGwgcHJpdmF0ZSBJ UHY0IGFkZHJlc3NpbmcgdG8gYmUgY29tcGF0aWJsZTsNMi4gSW1wbGVtZW50IGEgcHJveHkgc2Vy dmljZSBhdCB0aGUgaW5ncmVzcy9lZ3Jlc3Mgb2YgZWFjaCBwcml2YXRlIG5ldHdvcms7DTMuIExl YXZlIHRoZSBwcml2YXRlIElQdjQgaW50ZXJmYWNlIHVuY2hhbmdlZCBhbmQgaW1wbGVtZW50IGEg bmV3IElQdjYgaW50ZXJmYWNlIChkdWFsc3RhY2spDW9uIGVuZC1zeXN0ZW1zIG9yDTQuIExlYXZl IHRoZSBwcml2YXRlIElQdjQgaW50ZXJmYWNlIHVuY2hhbmdlZCBhbmQgaW1wbGVtZW50IGRvdWJs ZSBOZXR3b3JrIEFkZHJlc3MNVHJhbnNsYXRpb24gKE5BVCkuDU9mIHRoZXNlIG9wdGlvbnMsIHRo ZSBmaXJzdCB3YXMgY29uc2lkZXJlZCB1bi1yZWFsaXN0aWMuIFRoZSBzZWNvbmQgY2FuIGJlIHVu c2NhbGFibGUgZm9yDWluZ3Jlc3MgZmxvd3MgYW5kIGltcG9zZXMgdG9wb2xvZ3kgcmVzdHJpY3Rp b25zLiBUaGUgdGhpcmQgbWF5IGludm9sdmUgYXBwbGljYXRpb25zIG9uIGxlZ2FjeQ1zeXN0ZW1z IHRoYXQgY2Fubm90IG1pZ3JhdGUgdG8gYSBkdWFsIHN0YWNrIElQdjQvSVB2NiBlbnZpcm9ubWVu dC4gQXMgYSByZXN1bHQsIHRoZSBYWFhYDWFyY2hpdGVjdHVyZSBpcyBiYXNlZCBvbiB0aGUgZm91 cnRoIG9wdGlvbiBvZiBkb3VibGUtTkFUIGJ5IGltcGxlbWVudGluZyBOQVQtUFQuIFRoaXMgZG9l cyBub3QgcHJldmVudCB0aGUgZGVwbG95bWVudCBvZiB0aGUgdGhpcmQgb3B0aW9uIHdoZXJlIGZl YXNpYmxlLiCFhYUNDQ0BDQ1CZWxvdyBhcmUgc29tZSBjb21tZW50cyBvbiB0aGUgcmVmZXJyZWQg cHJvcG9zYWwgdG8gZGVwcmVjYXRlIE5BVC1QVC4gDQ1DdXJyZW50bHksIE5BVC1QVCBpcyB0aGlz IG9ubHkgdG9vbCB0byBhbGxvdyBJUHY0IChvbmx5KSBhbmQgSVB2NiAob25seSkgZW5kLXN5c3Rl bXMgY29tbXVuaWNhdGUgd2l0aCBlYWNoIG90aGVyIHdpdGhvdXQgaW1wbGVtZW50aW5nIGR1YWwt c3RhY2tzLiBUaGlzIHByb3Bvc2FsIGRvZXMgbm90IGluY2x1ZGUgYW55IGFsdGVybmF0aXZlIG1l Y2hhbmlzbS4gRm9yIG1lIHRoZSBhdXRob3JzIGRvIG5vdCByZWNvZ25pc2UgdGhlIG5lZWQgZm9y IE5BVC1QVCBmb3IgdGhlIHRyYW5zaXRpb25hbCBwZXJpb2QgdG8gYWxsb3cgYW4gSVB2NCAob25s eSkgaG9zdCBjb21tdW5pY2F0ZSB3aXRoIGFuIElQdjYgKG9ubHkpIGhvc3QuDQ1EdWFsIHN0YWNr aW5nIGVuZC1zeXN0ZW1zIGlzIG5vdCBhbHdheXMgcG9zc2libGUsIGZvciBleGFtcGxlIHdlIG9w ZXJhdGUgYSBzZXJpZXMgb2YgT1MncyB3aGljaCBvbmx5IHN1cHBvcnQgSVB2NC4gT3ZlciB0aW1l IHRoZXNlIHdpbGwgYmUgdXBncmFkZWQgYnV0IHdlIG5lZWQgYSBzb2x1dGlvbiBmb3IgdGhlIGlu dGVyaW0uDQ1Jc3N1ZSBvZiBlbWJlZGRlZCBhZGRyZXNzZXMgKDIuMSk6IFdlIGRvIG5vdCBleHBl Y3QgTkFULVBUIHRvIHJlc29sdmUgYWxsIGludGVyb3BlcmFiaWxpdHkgY29uY2VybnMgd2l0aCBB TEdzDQ1Jc3N1ZSBvZiBiaW5kaW5nIGRlY2F5ICgyLjQpOiBBZ3JlZSB0aGF0IHRoaXMgaXMgcG9z c2libGUuIEZvciBjcml0aWNhbCBjbGllbnQvc2VydmVyIGFwcGxpY2F0aW9ucyB3ZSB3b3JrIG9u IHRoZSBiYXNpcyBvZiBzdGF0aWMgdHJhbnNsYXRpb25zIGFzIG9wcG9zZWQgdG8gZHluYW1pYy4g V2UgY291bGQgZW52aXNpb24gYSBwcm94eSBzZXJ2aWNlIHdpdGggb25lIElQIGFkZHJlc3MgZm9y IHNjYWxhYmlsaXR5IHB1cnBvc2VzLg0NU2luZ2xlLXBvaW50IG9mIGZhaWx1cmUgKDMuMikgOiBB Z3JlZSB0aGlzIGZlYXR1cmUgaXMgbGFja2luZy4gT3VyIGN1cnJlbnQgc29sdXRpb24gaXMgdG8g aGF2ZSB0d28gaW5kZXBlbmRlbnQgcm91dGVycyB3aXRoIHRoZSBzYW1lIHN0YXRpYyB0cmFuc2xh dGlvbnMgd29ya2luZyB3aXRoIGRpZmZlcmVudCByb3V0aW5nIG1ldHJpY3MuIEl0IHdvdWxkIGJl IG5pY2UgdG8gaGF2ZSBIU1JQdjYgYW5kIGNvbnRleHQgbWFuYWdlbWVudCBmb3IgdGhlIGR5bmFt aWMgTkFULVBUIHRyYW5zbGF0aW9ucy4NDQ0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAMAsAADEL AAAyCwAAIhAAACMQAADy7N/s2wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGFmjXHwQAABkDagAAAAAVaOgPawAWaNcfBABV CAFeSgIAChZo1x8EAF5KAgAAGhZo1x8EAENKFQBPSgIAUUoCAF5KAgBhShUABQAGAAAlCAAAXwgA AKsIAAAICQAAGgkAAG0JAACACQAA2gkAADgKAACRCgAALwsAADALAAAxCwAAMwsAADQLAAB7CwAA fAsAAOAMAADhDAAAnQ0AAJ4NAAAMDgAADQ4AAAMPAAAEDwAAIRAAACIQAAD2AAAAAAAAAAAAAAAA 9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAA AAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAA AAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEA AAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAA AAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAA APEAAAAAAAAAAAAAAADxAAAAAAAAAAAAAAAA8QAAAAAAAAAAAAAAAPEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAQPAGdk1x8EAAkAADckADgkAEgkAGdk1x8EAAAbAAYAACMQAAD9AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEBAABAQEiEAAAIxAAAP0AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAASAAMZBoAR+w0C8gsOA9 IbAIByKwCAcjkKAFJJCgBSWwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUTQBAEQAZAAAAAAAAAAI AAAAAAAAAAAAAAAAAP8stRzuAu4CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAATw XgAAALIECvAIAAAAAQQAAAAKAABDAAvwOgAAAARBAQAAAAXBIgAAAAYBAgAAAP8BAAAIAG4AYQB0 AC0AcAB0AC0AZABlAHAAcgBlAGMAYQB0AGUAAAAAABDwBAAAAAAAAIBiAAfwnzMBAAYGDr4ziidH /eYcK28Yy7PSVP8AezMBAAEAAABEAAAAAADKAgBuHvBzMwEADr4ziidH/eYcK28Yy7PSVP+JUE5H DQoaCgAAAA1JSERSAAADAAAAAeoIAgAAADyjvhQAAAABc1JHQgCuzhzpAAAACXBIWXMAAA7EAAAO xAGVKw4bAAD/tUlEQVR4Xuz9D3Bd133nCT5poMxDmsoC3VIW6BanDbXlNthW2uBaboOxnBW0clZk yVkRK/eIWLvHhqysBVldFhlPYjKuxCGdbodUumXS3rEFu8Yu0tVWgaqKilSVtYKmIhfhibKEa6Qh VC2toG1xGtgWq4GKuc2XGLH38zu/c8899897eAAe/v+uWE8P95177jnfc+49v/P9/bvu0isXK3YY AoaAIWAIGAKGgCGwbRB49LFD1yEA9b6vb9t02TpqCBgChoAhYAgYAtsagWN/dGz8xXEvAE29Ormt wbDOGwKGgCFgCBgChsD2QODsM+cRgCqmAtsew229NAQMAUPAEDAEDIEUgesNDEPAEDAEDAFDwBAw BLYbAiYAbbcRt/4aAoaAIWAIGAKGQMUEIJsEhoAhYAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAw BEwAsjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo 2w25ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aA IWAIGAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFD wBAwBAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwAsjlgCBgChoAhYAgY AtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25ddgQMAQMAUPAEDAE TACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAIGAKGgCGw7RAwAWjb Dbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAh YAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwAsjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPA EDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC 2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAIGAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARM ALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsN uXXYEDAEDAFDwBAwBEwAsjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFg CBgChoAhsO0QMAFo2w25ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQ MAQMAUPABCCbA4aAIWAIGAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALb DgETgLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwA sjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25 ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAI GAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAw BAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwAsjlgCBgChoAhYAgYAtsO AROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25ddgQMAQMAUPAEDAETACy OWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAIGAKGgCGw7RAwAWjbDbl1 2BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAhYAgY AoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwAsjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAE DAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4B E4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAIGAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5 YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsNuXXY EDAEDAFDwBAwBEwAsjlgCBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgC hoAhsO0QMAFo2w25ddgQMAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQM AUPABCCbA4aAIWAIGAKGgCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgET gLbdkFuHDQFDwBAwBAwBQ8AEIJsDhoAhYAgYAoaAIbDtEDABaNsNuXXYEDAEDAFDwBAwBEwAsjlg CBgChoAhYAgYAtsOAROAtt2QW4cNAUPAEDAEDAFDwAQgmwOGgCFgCBgChoAhsO0QMAFo2w25ddgQ MAQMAUPAEDAETACyOWAIGAKGgCFgCBgC2w4BE4C23ZBbhw0BQ8AQMAQMAUPABCCbA4aAIWAIGAKG gCGw7RAwAWjbDbl12BAwBAwBQ8AQMARMALI5YAgYAoaAIWAIGALbDgETgLbdkFuHDQFDwBAwBAwB Q8AEIJsDhoAhYAgYAoaAIbDtELju0isXe9/XN/XqJF3fdfvubQfARurwL37xi43UHGuLIWAIGAKG gCGwIRC47rrrtB1Hv3xUvxz+/cMquugRCzAINnGjzz5z/siXjsTSDmfGXxw3BmhDDK01whAwBAwB Q8AQMARWjkBO+mlQoTFAK0e7ZTUYA9QyKK0iQ8AQMAS2IgKBCNmKnVvdPhkDtLr4Wu2GgCFgCBgC hoAhsCkQMBXYphgma6QhYAgYAoaAIWAItBIBE4BaiabVZQgYAoaAIWAIGAKbAgETgDbFMFkjDQFD wBAwBAwBQ6CVCJgA1Eo0rS5DwBAwBAwBQ8AQ2BQImAC0KYbJGmkIGAKGgCFgCBgCy0Rg4K6B4pUm AC0Tze152fTl6TPfOTP6nVE+zz5zdv7KvOJw5ntnpt+Ybjkms7Oz1Nzyaq1CQ2B1EVio1Nyxunex 2g0BQ2BlCJgAtDL8ttnVU69MDX166KFPP8Tn4P7B3XfsVhlo5PGR88+fT8FYqIOLO19baHZhOPLl I9S8zTC27m4yBOL5PH91HqmdY57jivt+ZXbx52KT9diaawhsEQRMANoiA7mW3Th3/tzc3Nyl1y9d q1079a1Tcmu35T3z/TNnnz7LO7/SJmcINH7qG6c4M/2WkEMUGH9pfPRbo+PPjbNOaIP5CY6Hkrnt 8uzl2X1795175hz12GEIbGQEqm1VbR6zunbVCffM//C5UGEyZ85v5M5Y2wyB7YSACUDbabRb1NfO Gzs7Ojo6q51ILR07OvRdf/yrx889e27408N77tzDidHvjSLBXJi4AIuz7759nHn0kUcHPz448fLE oS8eGvzYIGcmfjyxq3fX6e+d5vy+j0mZcMxcmdl//36yt6gsZYchsMERgOkRKUfnau6zrQIf5GWg Dd4Na54hsJ0QMAFoO412i/q697693Td399zWQ3181zf+o5959PSZ04e+cAhjIEiggTsHzv3ZudPf PX3ki0dmZmcogjDUfVN3/539Y98f4zxnjn7lKILU2Hn5c/z5cXig0MC+9/cNf2ZY9tasJbqftsMQ 2KgICH/JRA1zNWaAku/ztfmN2nxrlyGwTREwAWibDvxKuo1ocuhLh6B8EFl63iViEDJKR3cH/692 OHUAGrGF2rE/PnZrz60Hv3CwWpGTx584Pnd17qFPPgRFdPKbJzmDRRE741237YI3kj9fm9JrwyHW FW1LsBlaSae29rXwE3Jc9p9B4di8PdbWxmepvcvhhvLr2sI1KtFPncPxdxWPFHbDfKloa3mxr0om MPPYbMyXB6NdFSNgApDNhyUjgALr4OcOjnxuBJ7GX7xQUUsIlXWQWk49eYrPi5MXz37/bK0i7/3d fbsvPH8B+6G99+499kfHpl6d6rgJAqjjwksXoH8uvnJx+BMiBsV8jzJAwcZiyQ21C3TlwFBdxcrA RoiN7ryMV2K/YlAtCYEYN1ZijOHaK+3UIJ/KAy1U2tvS74q8rtmG+ZKg1sLMYdEhRtQaEzhjYL6M Su2SbY+ACUDbfgq0BICEp1FZh71vdUd1+vVpWKLjTx7XV//Bxw/uvnM3sg5vrv4P9Xe/q5tf9fzQ p4aGPzWsS3J8KAOkB773t952a0sau10qcayD7JWBsWCbwnJi60fpTBD/dbVljg4wVMcuzPbDP+/t dXUeucczQJWUBypyQlSrYyG3aNoXcrtM10I/A0Qi/WhMgdw0dtPbbAS37QxZecevixPE77p998pr tBqWjcAvfvGLZV+7NheyZE6/Nt37vl6Ym/iOEz+a6HlvT9dNXXDULA/9H+7n5XX+2fO8m/bev3fy x5N9H+irVquYB+EI1t3VDQmkl7OmnH/uPBcO3FMSpYrbXXrt0sCH5af4+9p0dgvcRUSc2DYl16WF CuOIqLoFetqSLrDKzlye8Xb3bZX2antXV5fO0rn5ufgWIvE4WYeDYukarDb7bbIHUE6Ig5JaXjih 7CE+BG0VHo2WtH9LVuKlnwTYYh+ZwN4VY0v2v9Cp6667bnt0tMW9JBDiySeP976vb+rVSao++8x5 TDhMAGoxyiupbuMLQCvpXf7aZqybmynTyjZtqbpYzlk8Mqtvop0JazyrddctssbbAT0j1vqOy/TW 94BSrWC5r1JRej4sxui5ql6yUYknRdtxQkg84TPVi1FtVIPYz+0wMTSBNzsRRSS9MpMBNqdYREVe raJM3z4T2ASg5Y11qQBkKrDlgWlXrRiBZny7mimz4oZsjQpE3OG46qx7EmWirsd0MLZNSVdftxKb MalOABZaRSbje7hQCZxQ5nxESKitT8A5ljhjGUitgkQvVvARkwBC2z5sNPCG2RsiKgFLkH5kGhek H3OS2Bqvr/XqhQlA64X8Zr1vC2wXLK7Pcgef9QCtVggqo2PBn6gdYS9Q08xdmZPP+TnOQP80Y5sS S07baxmO/Q1dCB/F039GHlvxeVZcWB9WYj71fM76x2O+kJyPvMN8yVreX4xby5huDxlI55uETYr6 y3dmbJi9fEEe5YwYmCfUWgp1weFOgzDpBmCbwLjcV4hdl0HABCCbEEtDoAU+LMbrLA1yKS2iz+VZ 2IhrV6/55eHyNC99srOJeUqpTOlwFgsVZYDcZ0ZH41ZiscyVRcl9FFampbd081wRzUMxNEHzVamm n23J94o77z5V9AnxfogFWqrzUgiCDZBHJGvA6+2Bsm5NLdhdbGT4nc2ySOpX5pjGTGa179GJXWy4 n7o6gSHPIjrTw66SENO45sJwO+t1P4cLZuwbGRhr23ohYALQeiG/uvedfHXy1NdOnfjTE3wSlFl8 JVZwkOeLelZQwapfOvkT6S+3wbv+xNek13ziOIZ80ODepOmg5NQbLv7Qxj5YIeZqYoebshE1p7Vh ZY54i7DWim1KkXvQzTTnI36CP71eRldo1pKsg/EmXpUTuVBIssvT2OATa0oCdTr6wffLlcljG6L1 YKEc4jsgrCRxyQO2pXxPMQ5QhltaYMV2mCejEJybEEM39jRcUeumZ6eRe2IoZuZnMhPbjUVqKu7s 93NQK3QptRkmuRr7KyHnGLWQqnlFjbaLtzQCJgBtzeG9+PLFRx979PhXjpNNgtiDvb29mpBrecf5 Z85LVooNfNBfbeGFly8ceuwQ349/+ThJW3ffvrueDETQagIwUnLPHXt8DMaN2kG16Qk8RPn3NsdP qHYmsUqpa4+S5SdSCyGqVk6CzXqSxbMFnN96AessnJB4gqRIX1iAr81fUxWhtMv1NxPFyrWWM50d nR7PHe2gH3M/watLrXxk2U58vnydWXvz3NilNkMRn+TNWbaoglg0U066azCNVb3oP5OhSWlLhTqY UmUnVTCuCtQaA23pR9brydss9zUBaLOM1BLbiXfPTV0z78yQtfSFl17g4hNPntCFjTcRXuueE1qo IB8ErTnfNU0pK+74jyRgj941jscjl//lBIyLP4+Dusv1yIoSxIiYM5DyP56oJ2FwXqvStnHAXVE+ ZEvVUCsSecVxOfVqi1uISwi9pu9Pffsprp14cSL0ixp8hW9Mw/0Qo4ho1ERonHm7hIFfIuLLLJ7B SmPDFJZAtAasHkE7E3/XUWC19u993QS3eSuTko2yqgyycYqV/ygGWdns5hTMIoEu0W2FGauYozpk 6qYzPLA+ykM4zYvXdmlUQ3fkuZ/oTMAwx/f4MXL6Nf2uCh1fm/OZD9fOzq+IrF3mLFz9y1TJ2Hga h4ACqeucg7d0GhdDW+VDb7v32Or3zO6wORB4YVzWwdxhAtDmGLyltpI3rN9wVSrE0SHM4MWJi1SC eEH+0YF7B8jkNfmXk+zyNR0pPxGi8Nadt449M8aX7u7uofuH+JRYPro/dqsCgsiu23dBmSA0cCEv NZaQ7p3d+/bvg2vhDOyLL+9azOab8sT44Sdyo8a9YHEd3D/IeWojE6qGeYW1op49/Xt6e3r11nBX e+/ZS7ETXz2BqMSveDPyZ04ll/oth2jUlQr1UANL4N133q2Rh5B+6PjRrx6dmJgQB5O29rFnJRNZ aRSipWK+vPKeX4G0vzI/89YM+riUnEhqDBGxgye2Zyxc/BhfQ+yXlESd8fxE4qPk68v6YHu/J36L Q62475t9/ZibnWOUlfUpcjz0mNwsQQYScBIEJDBPzlcrichQl/uJUA0kh1oOyWfSBm2JRo72Ri1x zGjasGkZILEhI1AkekbmMFupbP5XoC6Zxg5n0AYWDKpScTOYrCWhBPIPV1lAh5iiS4Oeux2dHYaA hv/JHSYAbc2JIbGYNSuFO3p6ejRk6uD9g3yH8EA7hhhEHLyRz46cfeYsZU594xSJvZB7yN9Omovp tyWOM9/5KfArZDbl8jen37z0+iVeZ/KrWydgXC5OXSS5KZY3WpsebMFRM01PTe9/YD8BD+PFhsKc QSonCQahEaGCsDQiTyrKrJmZGSSSwQODorZrE46KdBnkFBt8YLCjq4NfybDB5YElilvId/bQd3/0 bv4hKtFB0rWOPDaCtAexRL56mo2UJjqRSuX0909PTk4iEkke1jVfeIK3EcsGawb2EIGroHkAItRa mS+SLCRoZHY4bZdqZwoWP3U3zTlfJ+Uk3F3yG2i3om9SEki9ikqZGJmXbqxjHki+J8jwUxrbMLJc bsz95O6l9tT+LgXM+QnWLURTVPVNwH8zYs7rRVwR3RwWJF1QJbW7Ck9WDqLOHZ3qTMcn3wNtqVPR m0llp2W9AfUTuMy9Tm38t+Zb3nq1FAQIgVgsbgLQUiDcRGWxflCVuzvQB6EY0pcU0gPUCIQK72hW 2SNfOEJ0ZpRiCC5Hv3xUUli8Nj36rVE4HrRm87PzXB74lclXJocfHEZO6n1379DDQzNvzOjbjcI9 t/RoMq+czQ054fvu6JuacobGkd8N4gg7P2SU3vf2PvXNpwgVzX2hi/hC+F0oK8nVMC1Cm57kFcnL lDK779g99OAQLzX4ktDBmAEirNyBBw/QzlNfP4W0RP1kLkPGIhsrIhcCH/Vr6Ngjv3OEWyMkkbc1 btvajLOwAqwTl2cQd+LNsd6d0WHTrJ7Aufao6BPwzMehKW6aw3Y5qdkzE8HvCU4iiVa8NaIEqXtR vAfwGMY8TcJrogvLGKZAS4QInHV4tXREEmz1Xjm+R9i1aB+SGUfMe0OEaJdBLENgrM0UbNFdkNQF w7LMfYgspdaH2FfJTItotmBK5UNml9GWnkiLoVbHPUewpZ5i8fDRxzXf27QIV6umlQgYA9RKNDd6 XdGbFz0X7k4ojzT5KOTKpalLGAadf/E82UzJ3448RIJ3JUvoV+dNnfBDUua5F849d44zgQHq2dlz YfKC9h1NmeR+d68w9WKFy+EzDUu/UDn0+CEx33l9WvO9+z2uuxwpRDxgyVR1tTb48UEkMGQvbqqV T/xkQpaTTle/e39pvFcyyb/5+pvIcIgyZOQIo6At9PY0bRXkpwOfOrD//v2aZID1/sAnDqBTm3x5 cuiTQ5zpebcksZ+56kWo9QqlL2qCOPZMZAPk++JUYzGX4LtcZCYKWahinqMRP+HGl1GIjS2CgYVv xrKn+2qsPRF/U9ou5hWyo467FIjKl1AIrkzg3nyFyazTa4vcjxbL1FaoJ/41boN8TzihfJAbxwM1 i3mMQ0Oc4wrrVd7sTQuIi/SjaOe8EZPmeRkoosHkqSyj1mKo09dFdviUWlNbogCjJ/NoRjb8kt7F a3JXYyou+7mwC9ccgVIGyFJhrPk41L9hC1NhnPnOmeGHh7tv6eYVwOaMFwRaHlKQIpGg6jr4+YMQ MNeuXbswIdIMudlxhkLtdfLJk/yJngsHcj5PnzndfXP32J+NPfrwo6efPo2eC796akCfxdv+7LNn x86OYcGDDRBvNGQO7Ie4HSyRZlDiwLiH+6KuGn1yFC3PpVcuBakFnRTSTN/7+to722kGxWCV0EYh qHE5wgq/kjq+s7MTyueFH4r92qOPP3r6W6dpJ2ITrBWSUMASygqvLlooLf/CERivHMy8pjEnIgMr bdCfqBav4+6ebiQ5zVG/xlOB9zJyoRpACFXABtpJk2yORx4ZyWVLCOYRfusc2hq91mPTUf+72wr7 1V3tUZLtshZQxsJ/V81ayFqVbKPDaK4xPvVuB26y4joxggMdimSDipLTIfFfu3ItlX5im6ek0tQ6 J4nxo8iAAFxj5tYqAylbE7NrEa+WMmqOisi3vMxgRcDfIabrxVwlIutnc+1tEOSLzVBVoxIw6a86 J7OmZjLPkVscFDKH4wkcggsEkN0kxFAPnXXxptDGvBzim8bTWLRpScSgQOtutDm8kgG1VBjLQ4+0 p1yYywX2X4088ts3/2r3lf8krgenvvE/LK9qu6olCPzBH/xBS+qhknf+f+9cd/11Pf+op/e23o/c 85ET//bEHbvv4PxHf/Oj7f91+4s/erH31t5T/8OpHTt2cPLmv3cz769/+di/vLnj5sr1ld3/h921 /1J7/v/5/M6enf/qq/+KtxVLDiokroUr2vkPdr7yv7yy8POFf/WVf7V/cP/V/3L1xIkTH3/w49yO n0b/x1EUZKEXlOfat//D2whYN/zSDbv+ya6dt+zUX7v/fvfd/8e7X7n0SvX66r958t985Nc/wivy N/f+5l9M/MWV+StDnx76N0/8m7a2tiv/6QrtUXPmvb+5929v+NuXf/Qydz/1b09RQ7jR/LX5G6s3 0sK//uu/XmhboGQOyR2/suNvr/vb37r3t27/J7fTR45/vv+fT/37KXpKHz9238fk1by2CmFWjtGn Rp//n56HP+P762++/vob8g/YQaP281pbpa34yQp9w/U3aGtZj2+o3MDrXj6dJxHISN/cr4yp1uDt Ua6vLCzIr3EZOUOvXfmrf3OVIeBM+/Xt134udVZ+Lud1knAwlBf+8kLPfyPjK655b0zf/Ks3c+38 f56f/F8mdWQRNP/if/mL2f8w+/p/eJ1P7iWrHWX+Sq7V852/0smNEMFff0vKaMmd/42fGPUeAbrD ZHjnyjvYfrUtJMggvbnKr85f/euf//WOX5amMt/SfsFMxEiCyfVtIutc79Zsh4n/ztL8y20i/ehM 4PPnFcVB5B4wiRAWbNukHkE41FbE392rfBy53S+1yVi4NsSYc76YHhUPAFi69l9pb/t52/iF8Z6/ 3yNDXKv9+Y//nGuZ3vz653/x54Ln//v12f9t9spfXen+Vf+A4Prw1r9/S3D+T7M7//5OJhtnAvI8 mGGIl/r+efuyQB3PqKBvyk3dyt8kA/E3tRt33JiZwAnICoVMUTctX/rRS3/xP//Fi//Ti/J0uEfj lVdf6by5E3zQucc3vbpwlWH1A3d9RcDUh4Ka3cPCJRxL7d3GLP+Hf/iHG7NhG7xVJ7/+/0DOCdLO 1GuvM6+MAdpAo9ZCBmjNeqVeYGjQMKZZs5tughuxKtfmQ5RCbTCrGpt+dUdCgMBKFLNu/oQhCz3C D27gzoGRx0dST6KEs6Ekh1g96xExEE0yE+lGeSmcRMiWCkt398Ddh3/vMA1GZTn67VECDdAQ4i1h To5eEnMrzkMcws91d3T33t4LWch+nTKcZ9eOUhJ5CKYQhg/WDRC4EIsu+oWFVoNhzbA+QT/lLshx WpK71Fm4x/hk+J4Iz8y1bZL3NNOGlXA/0ehonTmWSPPAp9lSo4zxDHQxuydG/ThyomXmEp44/BgY F+z2hg4MASwUKU8i48Kk4iR0bF9fH1yp3nrfR/dxdxhWxghYDn3xEKwn/o+MEdeiFIYbLgVflEeR bbjMYSYwRzSH87MxGp1S2CG3fIgBd2VQAnqCzXE/Onx0hLkENUsj9S44Q0AkiwGiU2SnQxzdlAmW YYDcQGyljPHGADV4UTT4qZQBWts97/IabldtYAQwAyKazoEHDmzgNq5p01hT1dhcElbMu8wVVyXw P4pISW9EGGIXe0bc/p2dltcdqNZAV1znwZexL3H6BdGYIP1kS2r58Km/hmtz9cwvzMe/pt/Vztrt kIMlUPAji+Fj7UMNivYznMTmHSEGQefEExJoqv/D/Se/fhIZbu/H98oXJ/2EA/3pyW+epBIsyVit KcByxWdj6Qc8Nd2H9Cux9FINV0764YxkdM9Z59SJA+RR0r6HHKjRKAgaiVKmHsK5e+XwbzAWevec dZFizkDHoPnvtHBHVaJ9BsPhhcrY02OcQSxAoEEe4kkEYcqDbZB+pA3YwD14AJwpTBAvSYv99ZPE ktjdv5svpdKPzOE3JMtKfg7j2+XmsBhaJTlYinPVD41O48j6B7EvE7CqToyftMJg2JdMbD+l6yVu c0ZU5S6QJZjaqW2EgHmBbaPBXrOu8kbDx2od4+isWU+bvBE2yxJp0G1JxUwhsrzRM8hDON9pGX5F TiIOEyZW+kkZieGk9ii6KieH3zfn/JKSSMS+lFsdY1+ktNnJGp/xV4qsgiQQiyZdKo1u7CpCE4ob HVZWcz91sRMrlTPfO4Op2aOPPEr747hBwfuJxZJDt/Ujnx9BNqIYn03iKdc69+Ygo4SIPiG+Tqaq BPkcDqU+SnJhJE/E31PrnBwaWYRzY+THPdgVFSIAaavk042sz9HWEPMwsrCDkxOT3svSERsY9R/8 nYMQJGe+f0brDPQJf4KzQD87yx3x+oRDgjjR2BApnoVhUNeEkjns+hLmsESYdLG7MvM8me1BMM2F XxIJPgI8NjhLHRuTaa/X0uXwgPDdD3qUoC2+l1CkwVQr5A5Lglg2OeWs2JZEwLzAtuSwrn+nSqw+ 179R69MCWTmuugyjiUeM37AG3iLx86KA/KvV8LnDaFekBPdJmCXRU+R8algSYseZJGZMXvNVxv0o EMU9uiwbWZ4pZSPcesxVfjWNsOQ87ALXnviTE/rr6DdH6TLLMH2BCgplg211b18vETXnZ+b5idUX u298/XA/bGaEYukn5X5y2IaKsuyX9rqUS4t5mvR7wfPLEwkR2iUjm40f7XFO5IB6yIfzIR60yp2l mPv+LYh/JUwb3glypq1C3CykENRbxHoAeZU+fUYOJ2TgXAny2M8xFmjE0D+eevIUmkdfYSBXopGQ 6BKzQls26Knvo5N+6nGNpR2PyUtPdhYItniiSoByvLpuuBYeEMzS0P1pgIPSKR0AzPFA6+Xm2cwk tzJrg4AxQGuD85a6i7ipF71aXBdDmL6YpdiYnZf0F6sfEFacjyLuBygCE1PkCViuEB0kf8irU+gv MK/xny+OswLh5J8iqdYkbs3zny5EioZLSSML6F48ijsc15ByUVlOQst4tsbVX9xAx2PKHRHF8Bak wZSknTBY+N8NfXyIGAqjXx8NhQMDNPbMeXQ0atSy92N7MReLzeQbTRgWPxcxOfS6yP1k5l4D7ieK D56pLbHU8XGkcuyaQ1g4uWIboujSvgsx/gmvpiOS6WO4Y5BoI9ZNNW4iFxcfOjc6uHYCpnzDROb7 Z4llilgz8vCIaBVf9vEp9FcOAplSGNmINsDRQt2hCEvNq7P8ojbSc3hlSJZzXYHjjPih/JjGXdZp nEzpMNn8JYH7qVRxJoXvwfSbVDbxA4LtPCf5tUjpxVDnjKsaTTP7bXsgYAzQVhnnaKdb7FJ4dcKK +wymcXm1ICkedeqUjBk/LokgTgXs7I/+SWq9G15had0k1Lw8+9AjD/HOqgt93J4ltq2p4XR1sgk+ +qVsU+vdy+l0yNERKm+S3xLpJ7tvpoYS24gE5+lpMRI6+cRJAkWyKT/8+4fJ3YaRB5+oCfDVzxlP yJqRWAhRc2ybUs/uR7tQb4/u++XqxDYoRJJMOQnNG1/15kqUh05guaU8dqlY7fT19+G/hvRDVAWJ ofDEyd47ejXpG4BrpCWOgQ/3YxjEtVjm5q2MKxWtsPTQbKyxTqcu3xDZRTXT3xLyQGWOyHI5QyEk ZrmNx1R+rcP95G2DlDsJ7t+JFZcKBBpGWVPWB2Qgz4CUcKNImcS4kvNtFSKXgjz/GA6NWYqgCc5M JOqHZgN5THz23LNn1227ciCTYYYIpfE8R/oJ2sYi3xb6XpxvuruIUZVqi4RcYm5F5YFupI9eiM+W ZyIRtIJAG/qAILrB4nhb5moFEtHfLtSZDfsUG1dJX9xRb6bZ+e2AgMUB2uij3IwXmGj026q4QhAc mSTtCChBmwCXwMaIxQkdP8XYkRO3EBmIJ58zeOiI9eLsLO9EgEAowZlCwkNfmR1/bhyHHa2H1woS D3t0tvjsLyUn13PnuUSEmIWK2EsmzqRE6MHiUq9if6k7S96hlOdVxbW0E7qeIMvYZu6/b7/c2jmb yK3f20uT4D+QkDjJCzS+SppRq+EoRPO8Fe1CBeNN7kUxqtWAjeGgX7p6sQned88+rEFpBmjQC85A /nMXAoEgWHBHbQP1E4iIZvBKZZeMXQWFuRcF1OVe4hK9t5elCEUDNXPHomdyaID4KM2nmQ081e9+ Fi1MMUoK1huTk1wSuBAag8OLxgSiwZxHCFMNjt6FlZXFT1fo1E45MEDufND4pHcsO1/qCyYuZtje hq15YpUSHGo0EOWaPUIMkFhTaZZQPXSBzEYzKulLM2VysZGSOpmT4gYfySUpxxbJRrGUs7y2qS9V QFsryZAWSZZ4MF8bhlWVXxm0S2dU2VjAZUJNZcaCYgmMsS+YRCZLhlKnFqIbmWqKMOICJjHDkgkJ 3YXhPFDQSBR5vAAlcFcYFKWs3BFeUB7S2L2OeFEuBPymPswLbHnDV+oFZm7wywNzVa5qRgAi4h/r HDs/1kgRIK7MkjyLcILHvnzsyB8d4Q3OK4DFm0X9oYcfopVqnozinD0TQQsRI4gf2NnV2dPdM/X6 FNfiRksBSdr1qWG8mhFTcLKFh+ALlSDHIB6d++E5giXCqGPqoT1XPoAvvJJY/pHGoKkRRPbctYc3 ES9TfJsPf/kw2VUpw0uHrGEIQ9Ae4gbS2Y7PPLcjR+n07PSFFy9AJoWraINIIXfuYf3jWnh7cpfy nTCGvBBVhsMSYuwHY2EMiNM49tyYbPGu1kQX8NIFmkQNChEVIqgNPTCEbzkIkOMMlIARfMAE613C MKrISPzrqekpfqJmmnf4S4dpoeSpqEqw7NR4ojD4Pth/2RpZLotUauRHEz/kxO9a8iiRkV6Fy/bK rnfv8itK7AO/oyouvsHJJSwwaukScQ9hjErP67LhpaXEmLSro0vNS0tW5cSYVGZX0UFJaxMd0yJH tswiVxStfzJ9CfY6es8y2ShtTbRMZnqdcDCxhCoR8/BOL4t5WCJfJs9CszgnOVlBMs6QmjbV9StN 6eBc/+KgiCpP+/KJcLAY8MnvDcsvYw4H+zYkEgndGY2FvCKydsreXNqJ0SERLJNZrnUCUA5eBKC5 d3w4b26E2ovArRIA+kqNdxovH91ixQOqMSb8NE46ndOFiUDptmpLPeT95lITBqkLYW7to6fSbBOA ljp2Wp7lFS1YLhCiucEvD8z1vIqHnOUBGUgSXb27VwkMtFFoIljdWSMRNYY+MQRtQ3IuBAU+lWsh +hnvCGK0cAlPLy9W4g0KMzQzffT3jxJDmYwZqmpBLEALQw28ek7/4DTSD5UH6YfO60q59669tAFP WqK8IEYMf3aYuyPlcBDrhc20ujePfndUNR28RJRQ4QvCCpHxhj85jF808UjCVcgux75yTOLsvT4N +43TNfm/uIQz9Ivb0SpkpngAeOXxSiXdGJXwhoJKUb0JLzvytu67b5++FukppDq0mTTpm6PyZ1c3 tSEvUi0cOxIhehyIFiQnpD0cZ8Rx3R3EXwG90lFHdowdWFSIKbHFyfrLQN0xLrzK9R+NgauTf188 cuTzRwgrENdA+xkjGqk8E/XHtik5yxi9u45RxgcttvVJbFP0Lh3VjjCmpRto6VKbSMklCPj+Lv5E ZJedRRYhr4tx91Xrk3RBLeacKmCecT6KFq1YUqEM4jiSXxAy5NdaklIq8szKtCFn/VNsW32ctVVe +mGMcl5+am+UxIZWzMXTKjryNk+Lox6VSLjb4kXaa71jkIAXncNBYi6VyXJQ+0GUJBZREjQcHpN0 JUF2USEP2UL/7b93Pw8IzylPB4ps6GToWKGcs9IPLfeDHjtOFtzrYkfFJYF35ukzPluZA4rv+KYt qQYrvL4ImA3Q+uLfsrvzghDdkKN2YGv4RKYRnc5PJo88fgQva2QRcQdtlzzhIcPX6PeE2IDJEHtb 1Ft3DaB2gVlBBmIZkMh71apIJ2pr+ZlhzVnB6+nU107xJad10ncl2ST4P1onPtHZq3c3PtKid1uo KbOib3zNnwrnIXzV+/smXpo4+9xZ2ky1kkuoJoa04Sqax9sTCe/Ut+TW9E7ebjvkncifu3t3F+1y enp7YK2ABcsGpEOVEpCuuC/ng70Lvx7/5nG0YzBh7DtpGE40iFkwQ2p3rBQ6G1OqEnVbVSKv0DbW oYsviXNWycELXTU1CbMiuEX+R/6SxMQh7JuJactGVo/2GyW6nZ7p7Ea72KnLgK7NmqFW/Z+DjU74 HvgPvW/86bmNrA9avgyzxA26WqXE2MZ+Sfq9aEgRsHWzpTVHZpXKafGy7j8ZQ5PAgWVjBZWOi2r0 JEr1DsnMgLAuKXJvkTPFQDIBsZxPX8qlJVrOjB1MwkspKCKVMo07UtLCzxmdORqBSRfsJBigYI7c 6dy74nEJHnatgdtprkvmcBmnmJvb+f5G88crcNvk8ddpHKx24jg9Akt2iP0tqlUeBHk2dnajypcH JDl4TFLpJ7EW5yUWQkMFYGM3yfDgLM8fQicMW6bwGcI5Fl9HrRoXq6eFCJgXWAvBXLeqUj1FeKuS 2rNLDE4RLPY/uB99EKIDf8p7J9lxQsDAeSD0oFHCtoa9i2qIhFqYkmVVMqsvVLD40Xex/3Rvbexz ufyhTz6kEfzSY6ECJ8GfGPPyyauBVYR/tAE2BTEInVWc9AedDsQPchgKKRT56JtQnEk2Vt50Ozo1 f7tepebA6LnQW9EXMQOKvGlyFLe2R9ly5caKFLffobZViIMy9ZMpcopp7npERnBAUoT98hKee1/r Vo8VkQshY2gbMlAIR5sb+1QmiLmKiCeIfazCrjq3+1dGLWyauQUtREGmazOfvHYZZb6noVO0HYle QxcSZEc5mXgkiQiV1Cz4eCsJx6Yg6iEfO8PSwK+EVhV5JuWcpgg0/NoU/864T/6deHV+8C8rQ69W +Bz+iXwOZT+j8tN8n5jNzqKyJ0khlTYk2quwuc/ogEJP6/NDKkQq2aMkAUwh7KYoPS+LkhdXIyTs S69Lhrg4GHG83acZ2GxNvTIlDtgRninOan0SGB3wZyJhMsUdndyTGvBGjFEYKRVAi45LinlMbIAe GJ5/bTrgn0M7h/+xn0j5ZLwE/ymnWc49yHX5tkTjFjhFmUWJp2GmbWGk3K86TCor6ATmkxcOs5q4 D9pZpbtU7E4nv3tlZShMZxgXk0xeXetoToCFv1TpKm6Yh7QsJtDyraGVQos/3YkMLVc2n+3cRkCA KPbFZpgKbCMMzRLaEPageo1uemCDWL/hS7BfgbFQ9xnNOUDwNL5jkYMWjE9KinkpkejuGcBYGP+R E187AS20+87d+Jigw8o93tQPR3Lqm6d4RXpbRZWQ3IsAuYFYI/iYILIgpqA2ggRCaUWQGPIk8O5T ggrpQdrwqSG1bOXWez60B+Hj0GPuPEKJuwotnl7F5aIIw3r6ieMSLJg3posZGGDKbbnERODVSXqh /BbGATlA/WbUyYgwW8hhB794MJizYNzDfTkpkW2R5Lq7kc/Q+hHwhs0i1kukj6VrNKx0nIKhbmBQ cjxBhnHJegnJ8uwyX9IYlJKyUa66jXKiIArOLDLWSezgjPNwlt1hkZZGBu4hwc2jR8s4kmwG8uJO uB9dPMK1cUyg8flrx2dn9r8yN3K5cv6liY6ZmY4d3dO1zuMT84PTvUfe7jr7TuXM25WzM+5Tvyef 0zOTrLg9C7UD7+3d/96e/e/t7e/qGp+dv+7Zyt3PTR350XjJegwX4iIfypY9snNSBDynlYxEDnOP vHsuQFUkyJucBOk+GUHw1YDILL3oXpm9/MOHn5cjNmGpdXnWBoiHiFmKtdy++/fNzsvDFWOlbRFg I2t3kbeI3ONs8jhSDilS3PgxjWyupdcFBujIq5PHfjQBYkgz48+cG0BnfbUC/sPPzIB/EfN4LK5d vTT18uT+d/eC/973doN/700dx16tSW0/mgB/7ig5W2I8Y/6ylDsszGGGSR72m7p1DqvYLYHLq0lw oyhYeS7clAqUCmk8fGG4FdtANAqp7ARKZYVlhiQudSntGiB1UyiGVO4V3mClz3ODk/HmcNmVLPWm Vn41EbBkqKuJ7hLrbiYZ6nX/9XW3/cPbuv9h955/Js5KpBV8zz9+D3koB+8b3PkPd87+51lIlN/+ 7d/mp53dO1HcEFhvz6/v4afu/3031jA3/d2buBZN0Efu/AhlyB4qeTdrtX/x3/6LE//mBC+XhcoC F+7+Z7urvySLcOeNnfjKkkBx1+27Ov93ne/5J+8J/MoN7Tf8y8/9y6tXr37wjg+iJiM1ae8/6aU2 MlPu/NWdf3DsD2gVF5Ih9cZfuZHbkajy1n9460fu+gii0s737Pxg3wclE1a1SrH8Vf/Nzn3/530/ vfbTnn/Yg/BBJbSq++91f/CffZAm7aju+LXbf02/60FmBnRG/+K/+xfX/fy63/3i7+7/rf0kSrzt H92Ghk4zdN74d278yG98hNSwfP/g7g/efvvtQ0OSf4q39q/9018jH+ptvbf97u/+LhklSbK465/u QgoB1Y/91sfu/j/dfcPCDVz1r//kX9/2ntuK44mExOVIJLRQ0zGS+ZJifJcsm21VzXYp58nF+HP5 VV7011cpcPPfvRnHNBaJG9puwLj7Pf/oPe2/3N7+S+3VX65Sku98aq5T6n/9379O+R2dO1KewK2U 3EWycpLx9Hq518v/r5cZDrnjzwUovug4SipIWuO219qSOPNrygDJz66X11fm29rP/8er//f/b+fp /9z90l91X67cPHV1R+WmmxduuLqr48YD7+ka7tv5B7dVfvOdiZ6/t1D58+cqL/67gc7a3t4bp/6K 9rT1Pn3sI+1XfuPNif5bupir8+Ra/tHE+f9weeI/Xr585UrPGy+f3fGRlxZ6Tv2H6g//4+yu697Z mWQIZzb+be1vfapL1xLBLemjykD8ymKZYq7YapbTtirjSL5VSeaa9CUwSaD978b+3V//1V8PPzT8 0gsvzfynmT9/6c9/+6HfJhvomX935rcf/m1ul0G4rR1I/+2f/lsEa2bpuXPnbu+9nafJzwTXNnki 3EZSkpiy8P+yZ4NUeqPlC38j04JDJaQYbRmLrG1ysAG6OD/3zdrC8P/a/dLf9Iz/l53UMD6/o+Pv X3flf3tr5EN9A107fvfOHvC/8eL5j/S0TY9+vfMnPzy0d1fluoXphWrH38x3j506snP2uouTh8kI dn1l/K3pH7z2xg/fEvyr/5/JH/5SL3WC/x++Vnn7yvSem2+88ec3eDzdLC2Zw25Wx3OYUUDoYQ7/ xct/wUtG5znzlrTE0uufL9AX5nY8jUP4hgDy+MS4+F3qo5EMroClj4xO3ba2t998+7Z/fJsku3VI hsymOg1kSrjHzf8UQ8qjlDWroswykr+iEKcB+mjo59SlKV4RxXfCap+xZKjLQ5ilcO+9H7VkqMtD by2uasYLLN+Oep4drfIQaaaeZtrQTD2ub3kdx2LAUx6Tbfgt8kHWK7vUOhe7Z/p76qzkXtnS/qyf tr7KdZOqG1xdBb3/V2JzClc3eP9g2KrGbjK6VEBQsb3effvujGd41FAl9tWnxjNe3C9o4kIblKXQ fXCwinW6oViJUKu0PzpdGb8qLlGJ9ICqIvERE7VF9XD37NH3d8VYnX9revCV7u5XJw/eND3yGYlV A8dAX07/tGuq4n34K8JjOYIr2aZrDQPV6XP39EBOSmCYJPdFilvBHsXft4AtdfuM7rr1V3/yEDmp ck3Y0DemJYnEFw+qvyR3mX1rFhUnUWdgJbEnw0sRGpV9AoVhBDkvPgezM7JUR6bEOppKpPk5Fs+B xA0qh7bfQoSSZZ53567OPfp6jzCBKf6RhbJoS2tjt8/sfZcPtuQmXmXf89MXat17vn/08CP7CL+E 0DN+eRr8j8z1RWOXqUfrp7aTt00TykJHJyZjSnBOxkI4UYc//KiwvBHOKeDBsElDNmQHPcxY/5gE U6dkWJVI4yo2OYTSKHJFYRp7OhMX1IbOjBo+VHz9lnjAAjIf4uHAT02TAa/xYV5gywNcUuA9edy8 wJaH3ka9KnodZ5pY73y9fqyknmaubbo9S1Woq6lB4zfaUutsZrDhfsQtNmbCdZcfLCQcdS/WD+hf OjqReLwpKNoZR+DHL1NVBKRyT5IiIGyUteYg/fjYxKGhsfWJGiWoU0zI8enXOS/lePnD1ak2WNxI Q+AoVheuzFyYd41MbDuyK6jUfGymC03Kdc9Vbj1w5O4/OtP5x+P7pmTNnn5///jtA+hrjvxkun3H rsqOrqHu9sPd00d3zg7cOC/1BOlHZ4X7vHS1fZrQf1dF+kk9khIDi4AqzSNnmTcribF1mkSkEM1o pi330o+rP2Ar3xNKoDZfI+7lme+cwcmRy/tu70M/q2EUkDj5RLNMrAQEJnwFWALhLNUtK7WJScbR 67/iOaC+eImRr3xPFEM0QLNieQVQ0sKkbZUzU0ghXvqp6thlJSF+BW3w7/7jCfAf/Mb57m9MjS8I /hcfPHJ+R4/oy+Yriv/RnfPgf7BntgNtV5lExVVTV1Wa8W1WMUL+5eYwOGNujB+GBtTJ1Zbg7Jme JFh5Oo1DWO1k6qbqbKeu9Y+qq1acE5Ppl4ExesR08sgExuvD/asDqQ8pHgTiZp7xfJlousZy8HKq sms2BgJmA7QxxqEVrchZxrSiyrp1rORe8bUrqSc0DntqjHia7e+Klfe0WfKTX5nT13q4r7fzcC9x eRej3lLX4sR0QE62tYvWgIyN2SzuOfue3K96F83lrrXNLbhcpI7Iie8bb4j9eccMKT/EAiPyAeuu O0TiqXqNj97RN5gMlNNzlbcmK/Pk0UxloL7KfO+VycrE2cqLZ4YXpg5fHX+qdvaFnZOnv3l0+FP7 Bz/U3VOZpfLe2cmR93b13NS1u6tn4F0dw+/vGXlfF3ZVl6bniHXUdXW2g4YEuUrqr3GjGmHuFpyE l4QJDrhpy2Vho7WaTTMQCQFbh7a30yKHRqnRica2VuRdGSAiwAE20d093XgJ8BOpyviEGSLdB16H RCvgjhotE1sxJCFiOqgOS5dAkcwShNPvGsHStVNajlkMMZycfBk7QMVynrTKxW6QVrVVLr48Ubk8 TdXSd6VDLk/v3VnpemMC/PtA+PL5kwuC/+Tv9B9/4uggnuHvlaaA7ZGbp/dgMu/wH36/4D/87o7Z iamZqx1U0nGVMY3wp5FEN7g8VZu+qDyWzueAdn4OJzjLHE5w9txPFM/ad7POQIRpHEyjdBoHilQa gN2PM0rz8Kp7o0ZzDh7vbg5TMnaN1AJ6ZMKaJ+G847hKvlyT/0smW679TV5txTYgAhYIcQMNynJU YBuo+dulKZKpYH4mjpUX/JaFdWCFbnxEa3/YKI8/K7bbOfueOBcpJggSSuC23syeO7mR11lUaqNP jg4/5mLyJro2JB6th8VDnPKy+qBMLyIf7FOTsydexj2wo3IjrmJwV50QLMM7ZkbuSnUu1Dn51vTp p8+PT87Mf+JokGk6arMsU7UdXbKJvzrdWZsd6O3t6ajuf69EoMOEeORHNeQrWddhYDA8n4FIq3Ut zI0/vq/TLZk5yVJQdSJj2vciwilTlXiVhxDAkUUzNeNdiP/XCy+9cOxLx849fw4vsEzOV5itrx5D AELWIT4CPokEgCH7xAsvvgCAWJXhPDjyhRHPSEU4exUMDXMIS4Oz6p6i+UvR710ubGtHth148txs GwIT+jyE1I7qLT29C/ODO+cOfECCU4Rj/LWpY188MdM/Untfn+JfZdyvTNZu6qs5/q/nimShGb6z v7ej0ndTZR5/T5wSXqzNXHX4z06LQCH4zx+8o2ekzyuGgoN3uBFpXk59/VQJe5QdCJ2H4ZwqWwnf QAiMMCFTQyg3RQmWQRCKMIFTYBMFIoEzvOZRhSS13C9sY+JbazG85fHfVEhjRmoZ+i8qwXdVIo9E imOSrJ3+7jqEAjIV2PJWmlIVmAlAywNzVa5atgDEA0/+Cry6YBcu/OSCrGo/u9Z9c7fG8mlw8E4n GuHu9+32SpkldmuFtjWokHg57nn/npL4ws20xOXH4JWkyT0WPyj/44m+D/WtUCNGm/0GN/ciLq7T 0aqcW+0ysYbJ7P3s+XxU2ehacCb2I/G7+3r7MktFFCdaFpu2yqknTh18/GDYxwvr4OQG5TwCA1GU MMLapmOK9HNqcl64GVlH3Sd78rZaNwvoDdXKz2odO3tYQZ2WpB3fqvPV7kQHJOWL37m+843zFYx7 flab7h6ovD3laxaJQervqM1c+MJQtRbxaokhSKzVKtXglGBb0CEGro4YoQg3rLvEnAw2QAqOkhDE wxz82GDP+3rOPX0OtMVv8S7JOSoJW549/9R3n5L1WL3ZI74klnh8e0Kq87IFO+XAYvshR13Uqp17 vjo2D1cX8BdlUK2jrdZZmRP8q+0dGrm7Au7dM9XOKaeucnOgHP/u2kxl6gJ24dd+Vpvv3F17h7Dj MEFOI+muGunrQAbyolth3mprG+BcKpRQG2rEi5MXB+4cCPDmZB2NIh1LRbmqcEHFsSNjHlcUkfXh zz4yGV1YIgMtOxI0Rk7ai3CX00+bALT4S3fjlDABaOOMRXlLli0ASf6K7m5Ie/You3rTrIfEF8a6 ls96Peepxuf8hfEXfMqtpSCE8QTkM/vppVyUKYvvGHYV2Fg0aGHjyiXVRluFcM9NtoFwagSYXt4W UG8hbl9YgSiPkn0Ri7KgrYKprEaLKd/yBm/zuMXE73lpPH29Jj+l29ZKOwVoNiRQ+w0i3aacU2J1 oReRARclDncntqQqL+J1Or1nWM/QyVQrRDGIdVIsUaOT8ycmXWaojAyU2C9rRVHI3VzN5cMhoKmG Ja7Hf+9YmLtQxgCleqJo852pv2nuRxdR4hoQ4JuHBbUpsUDxio8XTh1ZIkUhj0q4YcfxYA9EWHDE dJZqznMm5dWczORpvyK3V4ht6Fuea3NYVpUBaqsMPOEYoDpYlSNfDnpy1stqinYJ/gfv6IYB0jlc d/hii58oI2/MXOauFQHo5YuBO1ERU8uoJHTiyRMHHxOR3T8yLk+F1xEjLiPTP3lK42XkKbQkXGQ5 pEFtGjFAubwijQHL/WoM0JLg2oCFLRfYBhyUTJOWLwBdlgReEiT+nr0IQOSs2PuxvVOTU4gXkMCk hijt+fiPxgnizGrdQACqx/HAgiB8sHgQWXHZsJYLQPXWOX1pxiHRKpVbe25lVZMsWtHRgJfCq584 eFBly24zfIDIFu7lG+w5tDZdPM49e06ykoUXeiLxSIAi3UFyFNa/4sLA8sC6i2BaT5bSm6rKQL4R HKXaQdYORDQUN+l5LRetzTkOCbkKB6hYa8YdT708deIVGCAn5cQy0Kp976jNXfjCIAxQSgAoZaVL ch2JoYHfXDknUSAJvOlJNnFVhpDIzZW21Mss5UWi+ZBn1yL8F7lXagLcvvsJGCCskiMGbpW/j/R1 H7zD5UFL8rDGmDfCOYdP8vzqI8DzgpWVn2C5RLZuk4BmLeQRU+O5nJL36BNHCXBfqhjNs0op9ahm 424TohKVY4DEEWFZicCoocgAkTgIOnDZb5JlX2gqsOVBV5oLzFRgywNzVa5avgCUZYDY3RLhkFcP kQ8gV0gmSrQ32HsSocP3EF0Qi05eNCQuZUkmmGFOAKKwiBrzYh/KAoz8xDaOl9TEyxO8U6B8iCPH haiTWDvZGOEEy2Yac1Fec1hIUD+SDes9CnJKSn4xDGN7e4krSBxCyqN9gLIi5zmVI6KJMuJLR679 9BotQToh3Q8bNWl8b8/YmbGidgwDjuFHhon4RwZ7OoJdCwwQLqnUrH5Ao98YRSm267ZdEoaxrYKJ KzeCSJc8rAkDRHihE0+cQHLAvgJVCJ3CEIGOH/69w8RURI6kRyWZDhcqtNzrArJrXsm+OcsH4GrE XdBJpXqEbN4DP6WiFZoWyua4bNnwL/eIT1L7HnFZujy97959GVufXE71XCbUnB7NtaPW1jn09IWp n4Z5XsIZaMGIUWhcRqvKlHFSmj/f11kde3APnFWMjwp2JUdORxPGor7mK60kJwNlCYnGvB3LZ2of U68NUSTDvFIm8jAvl2uxUm/rvIbX91tzh/5sMmJ6itjW5XKWMy4LtZMf6xt8l5hpZ44GfUzSbAXZ KIOwDhwp/K46BuiugdJpTCkIHj/Jg/SjFSW31nTxpUrbjECZDZIZbwBE6HHm5y1ggCJ0zAZoVVbB Vau0lAEyL7BVw3sNK1b7Bs8EEHzlS0ckgc5tPbx9ZONy1wCqE+QYiAneJqyOBH0mCAoLvPq85A5J w75QIQM8UgXhN/gVEYfvLzz/AvQGIZKRaUSscTeCbWrvaOddQGAVdEN8kZfaN09hLnr0T48S3/nk t0/Kqjw9LS7ECzXxHr88jVAS/LbgkMjhSv3IakhptBz5CetU8rEHG4u4hdBOUCMYpfJFYsa4viP9 EKkFawPyfyFpcQY1B/el15gPoxiSzIUu1wTlOUPoILixN99+E7kHEDAKIVMHRq+UOf1tEfiErSki g79MFFjW80CEu00cTPyLO3l9e58jXZV/5n18wqs89lRSeUX7m/tUbqber9rGEPlG50CoOeWo4vrR 0GmdwYMs9hTTKEG1mbH7ek/f1dHT6WPDuAgxTiMmft25782UKblW+9XXXT33sd6xB/sy0k9s9ax4 Zj9zfUyzWBT8v1JsqSSLc4xtMzir65NvSeKtJn776l+WdXrKjFoR88itKfiRUcPMVezrK/vfVX3z 8YHD/WL6k0ROqoO5j9+9/HHZ28O99nrpZzGc49mV+x5j2+Q05hK2MeLeqJ59ibGUH9zaNZ4shTEN DRVN2tJpLM1A8KJOLek+Y5Vx8blu6kzB8bCpq6zQhkHAcoFtmKFodUO8tUeyl8X2mcDQJDQlNqDa 6KBEhyxByIDAYOHnExmCwGJwPPxKctC4RexN1SSIxD2qsBdb40qFXAH84wuChe4U1ZqYCsWY9OUL 4l8zO4sQg3UzbBMZT6GIYFPYgZFGACFDRCuXzTTeipETA92N2uVgK4CxC8KTJrUo5athnjS7qmbL 0r7jlI4G8O6P3o1chZWPtg1tINYtoMEnuZyEMCdvfFs7LaEATeKTNosl+MQF5DO4H+QzUCL6S6ld tvZX7+ilnyQ1tMARwoQkm9dMXJ8bfBLpYI3rMY/0O8IKRLoY7UXQ6MX+NXJtomvwCddcPRouJWNh HUqGXGOR9W5aT7LyxW44fd3dLzzQO7a/7+AdHf09bjH2UXycHcnKvrO6H72r58Ine88/sHv3LTKO GqROsA3ST4yqfk96ncE2ZiOS0fHwJmPhLd+D73rAOWutJZhHfkzpGKmUGbchxG2K88YX0Y48xXxt 4X9lej2R0Z3ETHDxo/cN/OKrB0DpKJKQ2u4UMS+cT3paf4wWaowmY3qwv2fmkb7R+3a3J179+Tkc xU/yo6PRlXJHYQ6n01indL1pjLXTnQM8/hrIJ8CbPlxxgCudoqr2LSRF0Ynhhc7sQ6QGW/nQWfk+ LPZ3MvFSiBa7wn7fUAhYNvgNNRwtbYzua5NsWeQ2gh2BttGM8Rws8wglsCBwP5y89MYlJBXEBYgQ ftXkqeEI9ajEwHlN5Xj4S4cpif+wmNlGGY727d0ncg+0ysOPIpcc+qLEhCWnBFdBpWjuZZJN6iV5 25RKhRh0yEDovyiGLIWgRhxeLocHQhZJm5W8/kTPBWPh/kSY8PJEm+R+p4Wo/05+56SgsVBDrSZf rgrtpAKWyge6QkA78YnNMp+SDPymrr739tF4SZr2CZGNioffjCrHoK/Uwo45NCyU8dvZhAHK96g+ J6G9yH3mOAzv2Z5sTzMtDDnq43qSDXQp58Rwp8yQbp3b2vtuqR66o+f8g3tYjOe+vP94f4fILnf2 uM9u/V7GD1UGdmrJuHzHxUf2/OIrB37xlf2s7ofv6e+9qVvwCbxaHCy4OWxz0l6eVyvNZpWEnClF 2M//aFxkhiSZOnShLXJsSlEswtWFOgONUeCBRMuWNe89fG//YSShr+wHN9ALmAdswTnG3/OmC7Vk jFL8GbuZL+6deXzg9H29h+7YNYLRT9kcDiOij1gcu0jPLDqHF6XWMnRRMIzLBsfyxHb2EfBTNMQE cnyPhz3QbDoQer6a5gJbtgGQ9NcYoNJ34uY5aQzQ5hmrpbY02dfWu44nn50WMsrhxw9TZuDDAxgO c4z92Rh/orEqvzDJwU5CAMib8fPjMCVD9w9hqaNZHomhomQPZsVzs3Nkd4c7gU+Cv6EAYgSSysin R1SUwZFYZJdspBDui+6JjOuo6rjFQ59+CJdXLoe+on6EEnRtCGrIUcE6AapGU6VyCYKX7keFMXpJ si5g3HPmu2dE1mmrQlyhpMMEimaoSkvWtrYKOdFoCayY5I794hFUb5oKHqMo7Ifoy/57y13bcgyQ fy3qyzG8It33HD8hrIxjgDJHxGdkwp/EEZzjC7L7bOmjchVxPRFHJT8l29awafb1BV4ka5XiOaTk pvQ32Tq7ALuIwm2Vg/cNiOxyb3/8iWwkK3Tmc/8Ln93rysTlB/piC/SEkxN8Wsv91MHK4xxlCPF8 ietyyv3EvNFCxP0kaAeKIpUGlIELHJ5a6ydPUDoWgYdTGiMbSUgkTkeElLAsroWgl0VesAXnMvwP JCVT/Bk7RjDUn4nEGM1htYMOnFxT3E+IgR5lg9fu5xXZ8dC4wvW4H+VsAozKJKWQJvXkrIs81OHB CVOrSFzlH8iGf6uGTidAeOiWVIMVXlcEjAFaV/hX+eZQL7q/Yf0uVd+Qsx36h3TWlOGVRDEOYgVJ 9KDuTJ5zxA5fAw4vXUL7QyDB/UDSYEJEnD21DiZ31dizY6pvwl5nd/9uEbOwN7ql58AnJP4YEg92 0JhO43iMcTSRduW+N3URikPB4C7S2rYqvAsczKnvSAyb6XemEUSwuUZ+wqp67uocnJCPAOuugiXC xBuF18zlGQQXrY3moeTiz8lXJkceFsc07oXNNdLY6e+c5lclw2ibQoSeTmSgLxwiySuRAiTs7EJN cv2gGntgqNzwNtnfew6gGbuf2B7FMUD+KFr8ZDNsa/vTZkRcSI5jUNOTwEnEDFApxyMNyN09awkU G09I5GVlI8Lbf6nTOOHt6lznl7SYUwktLLJrGZuqsljPXOslklghkqUQ/JKcZYa0eXGs7RjntM5F 7asac0tJS8rtjVz0hAyDtVS0mykf6JayiNuVKBL3krmfOF9bBK9KLX5K56gvdwnPeBj0OKZzKQPk 6wlkmw+WnRKluXuJ20ESYrsZeOqVUfI4PzlXUqNdu7YIlDJA5gW2toPQ8G7L9gLbQH1odVPQjqHL q+fJ3+BuyHYINzi4NdkiQsKMnhk9/a3TFyYvELi23lXiBaYyRMS7ZM5EeTdj7cyZb5/Z//H9qWwa akgCogSzBjWYoE7NbJq5V6LrTBkj4uNVO7BVh5abw0PfHSIUEgX4XT3qYJwxmIjvGxtSFNqj2RvC 7n8lsQMaDAFkXirdBjOL3AVR2+LYSDnX6FRzFI2OZ1lKvdxzMZniMc3iLP6DaqGiitdCBAQdoxyj k5sVJUSFdjPqHT6J3mClTSi3sFVocg43WQw/ynT2xpg3h3N6l/pzmDI6RTnEDf4OCR2ZapFcFTEg /ORNrHLhtRYktNX+B/d7qiwMWTxAKnR6Y/Co5kqtq6NLhXg521ZZSQAwqGL2YzHCWBQs473U5Bg1 KGZu8MvD0LzAloebXbWeCJDdiexLy2gBltQwQM1fyF3Gnxs//YPTDaQfea2nGdHdWqgETMTBpOHa 4sxTmpYoa0YQOIZyTiJwGGEznWx2c/wB6SQIXozfnAgTjjfiC0wY3nayzET8h98ci8ThbH2CIYUu SJymhcRF7BCWznvsu16wMPvtb/OANl8y2lgXuRYvc0R2VzFHEtujlHI/6cJZ5GbiJbPoZxfxGeCJ iU+Rf9Iu5sdxMUsgL/C5aROPQir96Mxx6s3VOEQKj2Wd+nPYz/BF7X4CVlE2MZVIeF4k00UMr2b4 yg4HmOC2mYKsbq3uKnXjyBGf/Jmrk055XZsLiMV/PV09zOdULFbqayWHMUArQW+9rzUboPUeAbv/ 0hFg0xZbaTRfAakrUdg1Xx7rabzbSmL/ZKuQxSMyBVA7CSkSTA00Jk3OM8hZBeV4o8b2KCoteaMH zdGdc6iJ7Uuc1QiGU1iU67/+O/qRYLzZhHYh2euLKTqZE9wCK993SB51JB6g5v/dHRI8KeOT5diI emrB5hEuLakxWuQItlNqB612MEmbfXsSbFO0Y5+vgi9SDmFlwqTXsXARcE68GmN2LeAvwiWZ6qM4 Q747RbufBO269kDBYj1EeHKp7GNnJfrr062vEN/Sy7PmLGEOe51XyKGWWAL5sYhnUZhLRRuyXHzw GF6dcrkEatFw4KwgxxX58JM/2AB59zfv6igTmJmTPAJiklgRk0GmsXyHvFTPr8i1cPk5UF3H1Xww TNRVehxWY7StTkXAbIBsJjSHgG50mj+aKd9MmXp3VLpbY8/ERzN1NlNGX3DF+svakzqSJKxP2GKq H1AuYH+oI44V5DevhX2zb0PU35ghyG2a/UuZ/yXxjeReWTYlNUGN+CRKybq+Q5z7ZDlKTDS0qRmf rMT6Z0XuM40nUsyKYZWiqy9I5ni1xBepeZ+vnBxTJCHq2UilOOc8yK7WiA6qBisp8xeTGYH/CGjL sikLp95dA94omCqNBbkTFVuQPwSwldMVRdiTZ0FFBz9bcnGtkiiOpTjHvNEicziZigF24WwC95Mo eUvoyYQrEmHI/QuJZdLp7XhKDpnAOo2z+jW//YjDtScJ5BtPxga/mg3QsqHbIBcaA7RBBmIVm0GM HFHwu2P2yiyhdIKBBV/4E5Ma/ZVXD3+GfxMvTvBdNl7JyzcuwFX6ExF09BItz7+p18hq2USP6pSZ +NGERuVpdLhrS3igtgo+aHEfm2hHUoT0W/TXxSXSo3meyW8lY2+amPWJco/H7WFFCZvIcp+vULrI STSIVaNrrYtvNPb0mCRoxDTh6dOowDgTpDrvw0VOzYjnSHtd8AzyPlmOAxBDilU7ZCsPqaazLnLY iXm1OJV3sPsJ0ZjCtYEzi2MpqZyxOPcTyIk4aE0IQqPdB2d3KEWh8R3igDeBkAgtEXaN/1ymUhF3 dsBOiPtkKvckcaTSGEjuzKrQP8kzmFoXLXEOx3Zvi8zhZEADDSaTTemi4nDohHdcYKDoZOqqlBap 1ZSJ9GUSWtRPAL2jZr3QFGxJ7B+h0xLHixVNZGOAVgTfOl9sDNA6D8Aa3B4lSN8dfSqsEIH+7gFx INdVkPWeP7HjU3oZPp8/w789A3v4fvFViYuox/zsfPiVqDx4iuE5hUGintTy/CP9+FL7FXMt+G1R 51JrCOVpUtzHXD2ka8U3rbTy6dlpLiR4Y/mtG/JGsoB1uE0nh/sssj6xLYv2lzKp7U6pz1doSpEB ipaNsPPW4l6FhJjS1cVPsjY7PULvbb1x7wIPoQsSF3ppLOppnvtxvZOeNiPgLnsIWey5hSKpfkmB B6pIIOAQZ7mc+wm+eLHbUSHjhPRXqYXGdj91fLhSrihor9zyPDs/CyfETiO15gn1J1K7l70Ye6d5 TO3AHGKlmIuksNyUVc2OA4YyychmMM96gYUZnnKTuWCDBcRCAwK7k8o99ae9uGFqgAzkGwTiqos9 pnqu5MiogGOr50AiJpDGClOl3FTqahaceuWyNkDxBmOlNdv1q4+AMUCrj/EGuANuSpnAhskultDP Eobnag3fdV4KfJdAQG/P4KBO5iz9PvChKP+De4PjgcV57Gn4jh/EyOdHJHrQWYkeRMYJvpOqMNdp GuCZpOgHFonARcnLiOCETkqrx7to9EJZsdA7kH09rurybDgz9Kkh2hDbCSlnrsVpcMzxuG271MmB P7z01wW81kN29u6Ociy25EuMIg03kOVOcvt4ZSlUxxSCmuQ5g2JO9Yjx8pY6utl1i0GgE8LyQPY0 YiDRfvKNgAbRnpALCbxEZCbCExS3y/GZXPupP+V+HA6lIRXi4WjJ97AYhwg00hLnvJNu6ENm9WD3 E6S3UkOThgGIUxOTQEssVh7yJiiwYv6jyNaEkQo2WH6eByulLM55zFdb+tFZ5OJsMb4ZzKPI5nGr vJ40wTmewym7FttXJa+dlNFJUr36CayTeYfjxpKJ7R+WQFJGj0bgjUogTR7Y0OCY+9F3Xah5+dM1 azglD05V3k7Lr9CuXFsEjAFaW7zX4268l3naCQYYVF1hLT/73FkEI5bt0Se9U5UEAiIqHW6i7e3+ e7TwK4ehoXowDcYbCzcN3vUaPYif9Ht4+/MeRB126223whVxaKIJOJjOzs6hTw6JU/ptu8g/z0lW aBJ+cQzuH0xlDgeX/NTdTYbUzps7uYQ4PZTkO6m++BUFn1wYnSHGD2lWEbmIUbT79t1k6uAqkqCh B6QS3KDQkRHtmi9KYnFoNg8K9Pb1woppC4mXyF3IHYtKrvlxk02q4+3z/kHRGanNcRvVG6Wkty/J 5jdN7xhtMSnpeXvdcydrZ2yMqefB8MD9BxhcpFU+w4h039It4mMhL33OYIK7l/MQycrRPCDLLulJ tQSrHJ4qA/l2Jmmh5hbS4DGKQ8zxpHY89bifHGMUmIxsPYHnCxSFLMBBWQNEGKBkj3Spjtyz4xHU 4kXM9YywboU6lw3sohcuaQ5nSJ1sFEdulDHoiamyiAzzryN9ENQUKTu9PeCu3Z6uU/N/ncZJOIPw WMXlU/VoCF5F0K+bhBldFIemCmQZoHqbt6aqskJrjoAxQGsO+ZrfkBcEsgJvlkOfE4nBvyYwgH9j au7yHDGUifJHfGRi3oSm1XuMdTtFEELiOCM0IEkgQ/h3t+odCu99WAfELxKdEv9Qs6jySoJ0ISAN IaSRn0589QQnibaMjzqJS8nSFUc41Po00A6/UhVMBg0giDMinWRaPXOaPGJvvv6mRAZyWVc5VKPH PzJ58bJD7wNzQGxDJDCR6rq69h/YT8RqXoJUJeEcvzWqGd2VHNIWIrpdmrxESGjCRi9p0FQXFu+V 633Hm1f3vtTfyBiCn5MFQ4TIiA2q9x13X0JHhqUlZbl29pBpMigO5L7BlSa5S2BZOJHZ8TvXsFVX xERYexmozBqpLq8WYVXC6ASfr5hjC1xRoChU+RIZlGQMTVTWcVZKmTJCW5RTF+lSnaszYF5kWRKu S6Sfro4lzcCVF1Z5q5k5nEOprkEP1alVcjA9bmIax5Oz/EbZYQoTPm58ZqoQ+OcmMV9rmaSStQFq mVy18iG0GppAwBigJkDazEX0gWTJJyHo+I/HvYjgNlgnvnKClzi53PWtofnS9cjs2yoV8k4QP5BP 3VqhVZE0ouRl/MrREPWrXlpBtGmQOiTWgI+JPY3JTUa6DDgkZYyRUQ5+7qBIG9AVav+RPYgHza80 A4slhKSBewfU+JSwfn0f6jvx5AnJERZyWnGt6yN8CURO3/v6enol3HP/B/oleB3ZFj88QD0HHzlI w84/f15vFceP4U8y0hMmGw5pGZy2Rh0s8kApbxHkxWSzW9QghM2uR2IxHVwMGC995Ev+IefxScxr InGL8stFRkk3zUH/Etv9OD+vnP+R9yVOFDFr9qIXGegmJ3WV4RkjLN0P5EEhSEx5XCWFLHIXCrxR CKOXsZ5WjZgapjRBVKRMm9IVDY1Ucpj7GFGwql3izl18Ilb3jEp4rZ3DS5nA/kWUpDL09jrKEmXT AxeJNK7NKEkRJV13hJ9G+ll6MxpBbQzQ6k7E1a3dGKDVxXfda9eNDq8DclAc/p3DKHf0jQ/VgTCE 1QvmxqjGkC0QIOCEtMEZixBNNPHwCJ/67iDv6VPffop/h3/vcE5Yya/ZlQoWzQhJiC9IYJlf9TWk a4/L9a0x+oKBdg463Yyme/qEt9h3zz60YIhN/PO7z8TmVG0UvDFBkiGLBmtV9IhsGzSMADlas7fO CYvNDUkTlv7GFFsKl2k1t4duwFvkuAQ/CrpdLnNyyfMT2VHDBgiuiFyw+z+5n0/y4HLm8Bclc+3x rxzPjG+0hQ2tJfAPFB2KTmaIJEjBLiRrg9KyDXQTTwj30jguRTxLz5Qi4xmdghmK3D+ywkmvrYd5 GYHhryozWwlzMjZqKSUq0r4k3A/VelO2pc/AJnBdpIiqsxefwyE5V4EPy83h3Iul8QQu5Xsa1JB/ 0BausbmSCeymsYazWhXbNWOAVj7V1q8GY4DWD/u1ujPbR+U2WO993Pe2CnwM9Mmpb50iL8QL519A B0QB9EHaqNz+HuaATFt8aj0Ndv/FrSrGKHNX5sjJABMjglewKdY7JWYB/Xf2szaj1UK6KmdckheN 91dKYhbTpLl35iA5SASmBJVvQzAjyPYIsx7agx5NLaNpmPZdQrmop1Wy6Uw5rYb+X3WHMfjUFPyY 2nckTrm5HNrBpifxTsr5FecYBW8/pM4sYXMc+XhnrIsiP69005xtfTCYWEs9V5PPgW9Sk5wElcZs UM6+KmfTo/MwfMYNihmyZK4WS4Y52SxR0dDPLuRZa42fdpP4lhWjXyG+Q8YGK4rq6WMT6OWBS8v5 hTn8FZzi5+LTOE5aErvUJdsn7hxye3nup9q+RnPYGKAVTLB1v9QYoHUfglVvALY1mL5yG7Z0+ECh DeHVMD01vf++/T4vRFsFny8IHvHddUff7X2lKSOIIyyZTd8l6qTcwe6KmjVPanwoz4QREj7YsEEk K+2+qVvbIDe6o4908XxBH4e+iURXtJY88PEtsEdOy7+vj3ooT520RIy7yVq/UMEyGksmzkAg0QYt TyWSb8gdqm7jC5IcaOAhRZRnbq155ik//fa0dOGuAW7nW+goB6yntYXLONSnRuL57uj0DFO1QuWc 9E65keVHvAY32BwXbVPiMynfULA1KdaJHAYmRY6KFrZYTbAM7IoTTAMNOCmkGV4tto4qZ2gW5dUS 1pC2NDBGCb+GpT09o5GE6gen4deimxL0Gz1VU5X1PWi5cpmaA05byxlaCK2y1DnceKI2ntj1YIQ5 1uc6A6Nr5BpBF9GHKsmt0X3tNq1AoJQBsmSorYC2RXW0MBmqbr+C1qm0gb5Mw8Y3U6ZeBfWubabO Zsos9b4l5aNtZYvGsKQa9H2ZGDYxu0DxaCcdmIwMGxSi2mQ3xyVlQoi5uE7Xos6OTgmC4IL4hTBx cnINHY6WirBoSDFhSnggjbgdIxmsrHzNWU4ij0/I/JrYQdfjxvLtLJRPiY3SEan33Ll6WMLXbsFe KuLZ8vEz6DOBJJEIApubuSI7k/MGVc1NY6kwIThzry+FTrKGzc4Eux8KryTFafMIwWrLFiuiCXFZ xTLShwRbQ8WlJUNtftTikiyvyEDwQCoJnX3mPF7A1y+vLrtqgyMQ72LrNbUZ245myiy1/mbqbKbM Uu9bUn5NXlvCsizmZdMkJ0Q9zZhTeCMqtbhqa2fr7EOhuPBFLCT8Ca+2kaUfWq6WHCoulPBAmjui OV5tSZRDI7uiCH9vH102IvU8qpA4N4v0E2aaPjVhFEot2+L5FmZyMxM1X4YZ6yatno9hhJTyllWO 7kVjKNOYIOXOdGmNjqwNEO2Zm3exGNbkNbJGfdy6tzEboK07ttazDYyA+kt7w4Uih6H5tnJHeNUW +KEiY1Tk+YKthiwhhS2ytEazT2z4Q3JHaHpLpxSTlvOxQxJ9s/LF7j95DLO4CWeT2EWVM2fB5ytk nI28wHJkBrClNvg5yyEl25wre5y1Q7+X+jxu+EHwApDO4bo8XKkQsKRpXAAitfXZkc9loc/USrZJ S4W9/QaXmpcjfJrcs1QQ17W82QCtK/x2822MAKt4sKsABrHTIv5kSFW9WCQh7z2nznEJr5N+x9u/ DsMkcSzXcou8OkPspR/NWo9IFHI4xOm+yzBsilfL2u404HXydEXIFJb1rVNBTS2u4oTk627mvMLB kTlc9bZBVAWD2GAOl07IRaZxaRDqtgoPzkawkbr2s2SjEkl19QKCrBBqu3w1EDAGaDVQtTrFm12C Ci7Pf2rb4Ce2rs5BV3Jo4PPc0VUvx2caI9itoAGh0u/KgsA6UC2frDHhjHInW3hcWI/zWdhyMbjj 2VVmaxUkpGJMoGLsn0wQmjrWY4FaE4NiRgTFDTbFbnTWkq5o5VMVPdcyo9ykkgjyLsxgvTnszbPK hqPeNBZi7109CpcQZvh27aiiPt4ggmMpA5Rxi2sl6FZX6xEwBqj1mG63Gn1soajbxInW9BRE6GkS DSqhfJOFV14MXzPNy8Hx0Kcf2tW7S4NN60Eu+n0f3SfuYN3doXd333n3rTtvvbXnVoIxrrwBaQ0u L6P/s03sYfmec2mJbSzy9hbOk4slgRWi86ZOPnV5EJMIF09SZSwNiKI8hNxr6xL1Po/VYvZVje2E UqOTbNwgNXcteoRl4vqECM5JG3JmVSIsONaqlbNojevKzh9VPYUm1JvD9UyF1JNLp246jV0UnzCH xUCNiD4azmfNPLwWQ7WUAVrsIvt9AyFgDNAGGoxWNUXC27w2RZ6KUGFIOyouPy73p2Ye1ZKaeoK9 rIbG0SwQgSSQ81fmQ4xESmox/JioliA6xBIM/vNST602+s1R3u9knlcHcnJsUWGIAKS35pI4PSph eCSuc+JEiggSRwzSdvrmJZGEpFVJ47WnUuzVqZDrNJP01OW4CAfhAIgAeeyPjyGijT09RpxA0Qol +9rBBwenpqfGfjCG9/7IYyNUi3hEHG2Jp/zpA8MHhlfP2VVj36mMkrGuiC0tkigswiK4EIUS5TbR BAUb4VZNp81Vj1+MHXq0XDFUqSjY3wi2mkesLH9L2t96tlYNEdEoPt4Wm6gHLgLFtjriOUzHg4VQ aioUqSlVIVtUaG4cKafB2JkN0Gaf2MYAbfYRzLcfqULyRfTv4VOJDaQEsoFqEowTf3JCs3dJStHu btJBUIZ8n8gNvLa4avBjg5zn5NCnPUFy6DFJPkrWUk4il3Dt0H6JuAMdQnRpMoIhyvT1ppFyuAUZ uLgvlVOYPBhyOXfZ2YOPKGf2fWwfyUoJ50MMntB69c/nk9qk8X27aMaxPzlGASQtWkizuYRruTsn uZZq8UGlGI6LUuyNaWL2cC3n+VXSjfX0qBRI2EMSYMVI0XLiOiIGkdJ17/17fQb4ZF9LO5HeEHf4 Vfx+q1UJEemCSne2dQ59Zmh1NRfOQnkRJqOtEjierTaDV9wfJb2IVUNNElNHtX7OvkrW4/DpNIOZ MzneSO2oip/ZqxBDiaiUqwc9F/cV8dQF8t52RzKHMyY+OR8u9Fo6NJv2MBugTTt0vuHGAG32Ecy3 X4WMmZkZlnBybRJ4MFciRHOG2Bh+eJhiMCuPfvZRiuELMz0zTc7Rc+fPnX/mPCIFBA/RmY/8zpGL r1wkgDLUCMWwCUWwoAyqroO/d5BX2Okf+Cyk/ErOKU04ithx9umzZNh46ptPzbw9gzxBtENpTJsk NyUhw/Bjw6Ft3paiUuE8qTlInkrEQrI3SBu+OQppRDsJ98x57i6UzPwskaPhafgOl0M9Dz3yEFlR iWeIZDP6fYlz3fPeHtogAtBz5xGMcjhwOQINchKZ4XM2MRq9UGB5/FGyrop05QQpkDnylSNIS8V0 rS2fRmrYK/vgnO+Sozi2gBVzyxHLVSjUAkY2ic+82Mw6LU0Dr6XYSCVvsOKysuc4JLXjEXnrJskZ oqYq6o/m85etdic3Wv1Zmz8/h0llpnM4OMcRJN1ZDgWaZ/Uo1VVFCC25J6oTLzDk3bkF5wZvx2ZA wBigzTBKS2lj/x39c7Nz8CKPPvYotE0xirHuepXDIHoyBfbfu//iqxdVsiFDFnnBYD4wKJmYmEB8 Ya09/OXD5BMd/swwGeORXZCT9t27jzJEi5a4zOQWvUukBD1gJjTMDNGlNbs7F7JOQLdc+IlLtbEg lpLDnx2mznCVj9DohBVeiyK4kNm0ViNkMxo0hCfqoWaqkpj61SrRxlhpRj4t+intC5nb4ZxYjdBn IW/RbFp46uun+Ik88HzPoTj6PRGSOIlcVdyjQ0TBXV2cuCgZPADqE0OaW3T0yVHYMpWrVvsQvQAs gstkFD43+6Z5tUFrUL/6DeXsq/RM7JkVn+E75ilMPP5B6mCkIlLOTfIlz8C5zCd6bEfKR3EvcF0y h8kppnM4TON1TS3X2hkYEu/47lfFuqC1t7DaVg8BY4BWD9v1qZm38+h3R6E3RFx4eBgVVdqOhcrc 3Fycz0tjdsGm8J7STRjUEZ98v1a7pg4XwWwImUANLEIEOUqKS0sxVXViY8ELUega90bg1n7DVxYw PvW40QQU7+5BS0a2CqyVuYr889KLhcrUT6a4O0o9FGqopchuhkDgt4/c9JoYdiCgwFohqKHOoyQE DzQPIlQ8Hpj+INmgCNPkoLGFE7VBQaFcI8UYieLJocF9VfqhBkLOKD7rM7p215UhIJwQpJrm03BR pKmvga2VSDyJya0Qcomt1aawUFkZVHZ1Uwj4V0EcDaip66zQhkDAGKANMQwtbMSFly+Q/VtkiB7J 2AVDo7T8sa8cQyzAEihmgBCPcIYaf35cmBXHo2AXDHU0uHeQRYJkYWICvFDD/mbo40Oow2BxZBlw Aey1zRjciBbpYdGgpUcSf4XK0cHBD+FpBaEy/Amn8wp+NNEVwQYIuYQKaRLZ4/nOCgR5g0RCGxCG IITk7ldFrIJ8Pnf2HN+vzbtUr48fooOIO8g6qt6C3Op9dy8ni/nLUK5BdJ3+7unDv38YYQsmTFLD fu0UnDYVDt4/iM6L4PpDDw5h6kR7+JP66cXIIyMQV+gWWzhkVtVaIpCSNI1tgKoVNFkm6Kzl0GzG e2XC62vE6uKGcDN2bHu02RigrTbOe+/ZS170s8+ehSCBQTn4OwchnhEment6J1+ZRCWki7duXCgM r3P8ieNIDCKXVKqHf++w/Fqpnf3+WWQgZAiYD5KYwhLhFaW/Dtw7EHReECSoh2auzMRmMZgB6V3Q kdEMbJMxZBabHu5SqcC7eFuiiEfp6e3Bdkd+vW//2NkxKBnleCB4uDs2RlAyGG4PPjCIWw2teuq7 T9HK9hvbTz5xsvvdYu5KTykA5UMZ5CQ1rhx+ROqkhfEw05jud3Ujz2mAFlqFaIWMhc0Q14IMsCAR 7rtvH7IUnQWHg58/+NS3n0KYo+WipHPC4mocG5lb2shtW9JYqBGVjH7Bzwt+VD2SRF+2DY2Xl4Tj +hWOp+L6TsscAwStGDaH6weP3blZBEoZIEuG2ix8a1CuhclQ49bClECNoJaKvTBwHMMGCEllDfrV /C1O/OkJqBpay5qE/IEkhJVPM5cjDEHhCJfz9sxmyfPQTL+sTGsREEIxyWC6ucPztBYXq20xBHg1 qfF7KMh2Eaqbjd9il7b4d0uGujxAL70ixq+WDHV56G3Kq4LFTGo9k/SDt7/PjlTHxqVks9VMrOdC mSVt4OCEYJhw47r1tlvnZ+eHP536jvmG12kDltrIQGouvaGGCvskLLs54KJKGwY+/LpkX7OGYyGx l1ywR9HoEcPJHc3AonGbmim5ScuIZc8OZ9+TBCdcX1JhU8CIAlrncINZ1OQEa76/TMUwh/XxafIW tFbCnq2C6Z7ZADU/fBuwpNkAbcBBWd0mqfoG7RhGvrl8OmxfDn7uIL/WU/GUnG9GTVD0DYlUSIuq k7DRgcKBrOJ48+03i35t9VQV+MxzychnNxahJRuO3l7UgoQm2tMncYxQxuWGHG87fuWzmamAnIQN lqwEDccC+y3uS4XsUDFsov6+vj5snuACGywMtKG7p5trm2nJlimz6JzcMj1ddkcwicP+j1nEPzTR TKqilAxZ26SAgmRDhcWY8rnmwbhoPIvT3zvNgyOxwW7vJcjZ3R+9u8GNkH4IZkELV2NYzQZo2VNo I1xoNkAbYRSsDYsj4G1XFy+YlmgmJvJqbAoXb2Nbhfc4AujMOzOD9w1iuiSRtd+Yhq/CeGv8R+MY aBOHCZeliR9NBJZIonu7QJSsNIQ+IkKBLjnEgTz1rVMSz8n9iTETC0mRWwp+dshJgCl3n5nB3Bvd IrZW3JQNvbZ84i8n/I2uzGOApRqixTtlJbYTAmrqO/XK1NzMHLsmZiPBJlA341+JAR/zE7EDlwto Zs4EUZ45zJTmQuQV4lBQTCcqRnsIN0TN0IBbfLIr0JK5wzuxugl54cULTOMjXz6CzwQiEXeJH5bg 2on4zkOxGhZd8hxddVF/Ei+w9vb2+Zo8hnZsCgSMAdoUw2SNXC0EVmNTuHhbo6yZ+NWLaLJQOfHE Cdmnfmzw2JeP4clPTKOpqSnkjyOPe/YFjd7EyxOsDXj24Z2Hrx+MTnDBI0a2BCh67jz26Qe/cJDQ 20ShjFsS/OxiLzy1AEP8OvalY8R45LuEDLhrgAWJ7yOPjxBMAcrNHFsWH9NtVsLLxG4mwyPqLELy xmcT4gc9NXIzDgSko8EDQ2KHulgYzGHkFb5whnDtFCN4KcK3zlVkIJxVkWaYvXiA4oKA82kOV+/E qp5WjvKUFPTu7ke/ehQaSctzo8mXhUCdeHECWUrCgDWjrF/6IEru9/A4KwW7OjdaetPsisURMAZo cYysRIwAvuLFqMqtgghaW15hS3yDsNfUnBiakowaeCMLnV6o58TXTnTezI+d4VMzm641D9QmQaXh 7e8euBs8cTqDrKINLCqXpi4ROFvj0+COROAAOCGEEraw165ew4GO73ioTb8+jW0T22gJ2/3cOQrz pe9DfYQw4FeoHRz7wSFva6Uv6DbJ5sbdkbFYcvCHYjXiKhYefmQfL0vXnQNCMj19lsWDTa0xQK2a 4VusnqFPDjGLEFaYwHCZzFvmJ16l8JES6BkxZaGCpM58IzwH4UMR30c+M8K85UKCtjNp+Wlqckq9 NZnSXAudKSHsZ2bG/mzszNNncorgmAHCb5RpTKwNnhRNXMMt9GGBmJGH5cr8/gP7ceHE63M1GCDa rKnfAgMkZ34mD68dmwIBY4A2xTBtrEauXqhTTc611FcVtqts/nirQoNrFESMA3DFL9Yz0D9ABCD8 3mvzNZZ8XtzKr6w1D+QiDujGERMlfNy0DWLT8F4JeC3bSpdFcvDAIFvbsWfHiEGgMSFxMKEYW2eC QEqZG9qJ88QXCVk5L3o0FgzCOyEhoQ6YeStNhBJibQffbyQb4hpg+EW1Bx44gICFhoJACf0f6Cec 5sHHDgIRX0QYQwKy+LYb6yncGK35WYVZhCBCzHQ0tsxYOEX+JG47803k5rYKEeH5UyJ7fWeUuQ2p icwtkeUPDCMzyfajUlPzc0mdsaNDpu70NKZpp78jz4WGZg1HngFaqKDGPff8OeJxIIrxsCAD8bCw I2JWQ2HydBAPVjRm14TdbDlq+qj6V43bYEiGVDs2CQLGAG2SgVqdZvKygGQm+CHvDngdzSqKJEEO LJZbdlfBPlezqGJISBnlA1hreUlRTJQvZI8ni8Xz5ykgGVX3D2ITIE12HAw8BH9Smy6i/ArxIJm2 HntU78uZUIN+QRKiVeztYGiO/ZGkRBUzyS8cojAnsfnlM4YEDoPoR8e/enzf/fsIFHT6jLw6uQUi DpfQcrWzQZuDkz//eDnu/dhebBcOfOrA6kBbv1Yn99CvF8ZfeOH8C2x51UktZmt8hOKFa7zW2Q2T Q41tsUYzoiPkqQ1BlSiJEs1HN66KcQ824wcePLB3/17QaO9I38WxDRCLE3cnmxt7btYkfYOjNWBA kSBRUpD3rbOrExsLNtYXf3IRWojBXWug7H4bFgGV4DFGfvr0Cz98gbAUiDj8qXRImMmUUcKGqcir Bv0sqlvmKqQmQgnJcDRDsya3kUfAvVjgZ2FzmfZINhKn9DY3P5MjZoBGvzHKNCYk2MCHJc47UU+5 iikdHhb1DEDMYgIzjYOCrIW46qMaGCDpsjFALcR3lasyBmiVAd7Y1RPsGJIZXzBeT6rCp71Qx2Pf G0P0kQjODz/Evg3iWlJGfO04eUnZnOm7j9cTwhAvtb47+nQnR954aG0sasXC94qzDdTQqG1VQgiy BdQ3I1exyaMY2h/+8YW3p27O2EcSrZEv2OES5RmzmIOPH4Td4QzaK4QwqHJMBzCfJE9ZDlqkGVgQ xDI2jporlC9cggw09vQYHdSsXnrwqvVbt7UfoJASMsFHmxCzUPG2ElkQoZDR0XRmnTdKrGqWEMaC P+ffmRcX7mqVUZt+TcJVn3v2HOPIeGHHE3v5FW2AcrzX/gf3MzSMBTdCisKHjgy4fCLjEk6J+tce KrvjBkUAKUft4rNaZjWICfNKnjKXeZAZxW6Ex1NjjHVUO1BO8UIY+fwIsxdXAE05cuqJU2x7EN95 Ws9854yIMgRndwRnOIo2QPGv+rDQNH1YEM50GjOBmcbEMm05njkGSLpsDFDLUV61Co0BWjVoN0PF SCSo6tF0wBzwgqDJmNGgQR/61BCqFvQjSBLYgky8NIEqhG2WFMa8sVLj/YWTBX+yh5ufke+SsvSu AfWahrVuZCfk9ohk6uCVRzGxwlmQFKoil0SBOgY/Ocjd992zT+Ut2Aj+xCam9/29LM9xRjN9C9OG qbeEPSKQtGI/OTmplgGU59OTUu4n2ajp1m09DqQTMM/dee/9e4PHPtoE4hRoMhMGgh326NdHGSPw IeA1f7LGsKmlDHtlyiAjwnLRK3bM4rLeJntuFAHxLahf431zl0Nfcrai2dUL/SAsGkuOXhXGgvIm /azHNNnQ90RnymxJw6i6uaRZaMK8IsteyCXCpD35bZm3WoxrmWCn/vQUXzB5hgQVW+l7BjThsQj3 1QrKMvSzupnRgwKHvyjB6HlZMflzspE+LE99/SnUuHF8V84zgZnGq2Hql2OAuJcxQBt64mYbV8oA VQiPSABiPjVOoh3riAADsXoH9ra8KbR+XhAo73Er5Z2F6KMnNac6Riq8mPQM7x3091JsRxXtPn/q vzen3+RXclbw2tJkAohBoeUUAENJxXpNUg1wLzfBLrFg884KZyRL/GeG+Yk3HZfwhUq4EV9oBr9q hQg0oT3hFohfGNDQJGrjvcl5ukNjtAByA1eFwtQJ87R6wFrNhoAhsOURgFLiH6rk8A/W6sL4OrxY 1nGF2tS3ViHHLUbyBfGddeT6Td0la3zzCKhdiB66PcKgBEEBtRe2INDRKNHZPPXf2U8sZqxAJHrH t0fFaPGmDrxP0VthmCLCxMsXkEgGPz6IsgkCBhKCnyTVfJZjQJUGYySJTBdqBPngWkx58ASBoEYZ p20IHtfKsUtuJscAEQ8adoqasXFGz6UMUKifBqO+wf2bL5xG9OEmWA9As4vG7Y1pVHXsWQMyMQPE r+jXzMi3+WljJQ0BQ4CXFRSUf28kcYCguPyryQDaDAiYDdBmGKVVayNSCw7PWn3f7X3EleEBxogE iQTpBK3TyW+ehJKhGGw2xjfYMMLEoCuhPN7XhBIW1dLTZzXNOw6ufO67ax/yEBsj+JggXWEwhPyB BYA4pj6wX+71vl71vr77zrsRlbDt5VpJ297r9T4a3qNzR+eeuyT269BnhrAXnnx1EiMkeCn9VetH +4Z6izbQbAwhsYAmkSpyEjwTxA8yE5bR++/dH9sAUSdmB9px5KrxZ7190qohbRUbAobAlkKgGAOa 1xH0M9ZOW6qfW7ozpTZAlgx1A4057Ny6tSaK19faNgjTs8SE6gg0ahON4xhCmyjmnKvXso9ltGHZ 97ILDQFDYOshwL6LYBNsukJoCUhuvFDX3mbOkqEub3axvCIDWTLU5aG31a9qJs/XsjBYqvTDTXA0 w2EEL6fdt+/u7uoWW8uVHctow8puaFcbAobAVkPAcoFt6hE1L7BNPXzbqPE4RmEtRFZUDsIlS2hX jiXGjN5GeFlXDQFDYA0QSKx/wuvIwqavAeqtuoXZALUKSatnLRDA+FrdYjMbr7W4s93DEDAEDIEC Akl6Gflh1Shzw32VEDAGaJWAtWoNAUPAEDAEtjgCPrZQzAO5Hq9GzKEtDuV6dM8YoPVA3e5pCBgC hoAhsMkRkDCPKvrEPJA7YSaGm2JsjQHaFMNkjTQEDAFDwBDYWAggABFvTNoUxQHyZzZWS6015QgY A2QzwxAwBAwBQ8AQWA4CeS+wauVabd1y7CynA9v7GmOAtvf4W+8NAUPAEDAElotAiQ2QuaYuF8y1 v84YoLXH3O5oCBgChoAhsBUQKMYB0nz1dmwKBIwB2hTDZI00BAwBQ8AQ2HAIFBkgywW24QapfoOM AdpEg2VNNQQMAUPAENhACJRmBNtA7bOmNETAGCCbIIaAIWAIGAKGwHIQMBug5aC2Ya4xBmjDDIU1 xBAwBAwBQ2DzINDenpj7RHGAzAZo8wxgxRigTTRY1lRDwBAwBAyBjYIAcYCuXXNO70kcoPZq+8zV mY3SPmvHYggYA7QYQva7IWAIGAKGgCFQhkD7DY4ECgwQX8wNfvNMFWOANs9YWUsNAUPAEDAENhIC 136WYYCqlSQ5xkZqpLWlHgLGANncMAQMAUPAEDAEloNAjgGqVWqWBWw5OK7TNcYArRPwdltDwBAw BAyBTY5AkQGyPPCbaEiNAdpEg2VNNQQMAUPAENhACBQZIG8PtIHaaE2pi4AxQDY5DAFDwBAwBAyB 5SBgNkDLQW3DXGMM0IYZCmuIIWAIGAKGwOZBoGNHh/f5SrzAzAZo84yetNQYoM01XtZaQ8AQMAQM gY2BQFulVqtJU5I4QFhAz9fmN0bjrBWLI2AM0OIYWQlDwBAwBAwBQ6AEgSgGNNY/hEa0OECbaJ4Y A7SJBsuaaggYAoaAIbCREEi4n8ADeaugjdRGa0s9BIwBsrlhCBgChsBqIYCKZH5+fvbyrB58X607 Wb3rgkCWAaIJ3i9sXRpjN10iAsYALREwK24IGAKGQHMIqPRTu1oT12hHFfAdMcgbjjRXiZWqi4BC uuCscNbrMAZovZBvxX2NAWoFilaHIWAIGAJZBGavJHxPgSQQqUiNZ+1YCQIO2HWOvGwM0EpGcL2v NQZovUfA7m8IrCsC67yBXte+r97NRdW1ULm2kEkUJbdzhAHnPTO0ei3YBjWv89SN+aeIBzIboE00 9YwB2kSDZU01BFqGwPxVluB5UcdcrfG9ZfVaRU4pIwTPQqW9rV0kniJJwPlKBdjXeQnf7IO1UBGz qisyk0XPuMZHW6Wzo7Oit42G2GyA1ngcVnI7Y4BWgp5dawhsMgR0bcYmlwVD1wz9ImcSWwpblVc4 qCCs3E/8GbifwAPJGWUO7GgegQQxkXuuiOAuE9rZWumfKbzN17mCkv5hMQZoBRiu46XGAK0j+HZr Q2CtEahWqrJOFDgJzgQHpXU2qlhrSJZ/P7/uuqVXDhgdZ9nDZ3ul/VrlGp/8KZ/KAxU4IbMEWjL6 buoK5YO8np3GnPFzWM+vyeEflrgla3Jfu0lLEDAGqCUwWiWGwOZAYHZ+lmWj3DYFhcKV2c3RjbVq pbBlHFe8B3sI+8taO315emZ2Zm5+Tv5ddZ9X5jgz/dY0ahEQVhmIlvrPHCfkLISkfmcrHUSoNSYw 1grIlt0H5EHMK7wKHliizw08UMvu2aiiIgNkrN6aAN+amxgD1BocrRZDYOMjIOs3DEXMQyTMhN9M L4hhysbvyNq0ELhmLs9cq127Nn+NT5VvVGSZeWumuM55vqfqWB/9dLY+gQdSTsh/qoSEVLTgtJBO NWlO8ouPLMJlLTEt1+ACOR7Iwbh4PS0qUWSAdNDt2BQIGAO0KYbJGmkINI1AZFbiFDOpQFNim5Is ISkntHZrR9M9Wo+CYAXHw511ix8+EYnge3Lng32Pt3rOWv8ESyAv8cS/wgOxnGc5uYw5y3r0fUPd 08dSSqIGzFyZSam1iFQL2bhiZa50ZJVjBZXYAKnrnx2bAQFjgDbDKFkbDYH6CKjHdXo4ax4UMfxj K4xqBgPn8J0VWhiIwEwUbFPi9X47o44mBXspSe5dqYJDyfc2yfoEAQDZ076jXSBVOcYREinT49AW jVjyKQycsw1KD+XkOBJ5VAihNaQx1n2gi4GR1EWReSus29Uan0xjTnoYYxOr4GoXsUECoPrirXKs oBIboDW0QFr3gdvsDTAGaLOPoLV/myIgxhCzs1NvTCHiTL01xXcVg+AtOBP7HCkDMTM/w1Kt0o/n JNRCRbfRTq0gn1gCsdJcSbI3YG+xLUP2AQUIi9yTMEAl39u84BLknhTPoOGqwwbJUCUmLGIkFMxZ kpjRWz9YYjJdkXJUvcjEAxW1u+KMzsYYUhUKvRAfTKxi4yp3iYRZwizd2VbxOPB99aRJswHa1O9f Y4A29fBZ47cpAuLwMjt/7eo12YA6HoLvsmNGa6PO1ck6GgBS7Yz/DJYoapUS8RNeF6ZshFukc3q0 LYK4s3byNjeY4GSFPHUyAtWSTzghPV+pKuuTotomPFAOz1K+JzA96UgFc5aIxhB7rC3tJ5+brsy9 6TdEXmEyZyBycy4lySLjqpxBVcoPBSqurV2UaC7qVcvB7Ojo8AZJcRwgswHaPO8IY4A2z1hZSw2B ZDkU3VbBEmWuNoeNc2AsRDXDeow1rltTc5FpggVuMWKNWuamnISLFSTb6PVNurSS0c+KEVAOwpzN zrEAs9byKf/QGCZiUM7uR2gJJw8BZueOTvkkAh5rXgHVmK7IfY+NUYr1pzZYQXJ1QyBee1v0mJ4V d7kiFDKNowxfql5MacuYsGxAs8VhuB2kQiw5MFs8jQueaHML0n47NgUCxgBtimGyRhoCDoHEvAAl l/AQzkKl9LOz6ldoYSB2ZH2RYnuUxEcph6/X6cRGFWvrXNPi8U5wQ5KDY6ArOXZHpJNaRS2lRHC5 ktqxehsgJ/2kDkeg6iTLYE0VdIslTkARu1PPrsgb9hbdmrYwAyQuiXUnsMCOhjER35UBSt3oIrMq nSolZlUh/FJ4cKD9MO2CNG3hUQippRPGjk2BgDFAm2KYrJHbEQGJEIMtjvvMeaeLzqaBbUqCViP/ o2D3E+WrkjrZK7uaUxmIP5wkJN7am9keCAzFotYF0CvheFxSA5WB2jucSXLsQOT4nthSp5w5Syx+ GvA9akvE2p/aGDm6IviIxdybDMdmtoaO53D8DGsakHITK5WKFmp58jJR1/rJmYXa8y7RkBXDcOvc 1jncMh6oGIto8xKl2+8tawzQ9htz6/GGRwB7BXQ0hJ/B6Vc/0deoiWg4gvWPamc40MtA9qCjkZ8S 25TipjmtImd3gi1R5PcUxy8OzMfmXYxFaTg7p1iJ1VTpNt3JeaCtZYIZiiq/BLew3XfcT4xtYIM8 vA7b+F4e28SuSH8NNkb8GSJHp+Yv7o6bVOik2bk5PPXaVDyHQ/cDFExd/SfDU02HIBM8SU3Zghtd MkzxkCnUPvxSIR2b4tkyHqjIALWWYdrwL6tN3UBjgDb18FnjtxoCEn7Guf7Gm2PdsGL0o+obDe3j N7JKyVSTvJsOD/H2Slxj8rY+IYhcLsJNsi0O9627gd6chARiTZH1KeVpRE2GeUqEj6ciEk6oMa9W XmfM95Qi72JUlmYQaxlXsVbPis5h/uXmMPdnDosYhMdidgLTR5F79HDCpWoSlwx1NI1LwQz3bRkY xgC1DMp1qMgYoHUA3W5pCJQiwMpBnL1goaJlYq6CdQIZKN4cwxAIP5ELheK2yKmDTBSPOHauSe2H ih5P2WxWmWC7m3DwSpR3sV1OxAkVbXQ62jrU3lmOMl4t7+el3E+wzQqck+N78uBFPBPjXmSVgtXX JkK9OIdzjceCrTbvIvQE/ga+JwuydtxP4yRwQ5CQYifHetNY5K3aXAkPlMherYHUGKDW4Lg+tRgD tD64b+G7jn5v9NTXTp342gk+x380rj09+/TZ0W+NLrvXpZtgiJBT3zjFP43Yu8mO2Lg18u2KWYqM DUpk3IBmgc6m3l7YOEfraONNc44FKfJMoWZdPIo8UCa0dOmKvqSRKBj5LoPwCLm0NK9WMaMZMZCk UbFNT/TdY+JsgIqGKV5Xlg1Ik4/p7CIqSf2JBVVaT9beqHEbgiVQzh4oxrwE3UK/ljQCYcQzbVtq FUl5lFzFOeytmiKIRAaKQmyruJO6wmW5n3PPnzv15KkTT5zQzxNPntDvahiXG7L40RDFYi4FW3aY ltvL6DpjgFoA4rpVUcoAXXfplYv8oMLRrtt3r1vr7MaVyi9+8YvNBcPu23ezQnfs6NDX07k/Ozdw z8DdA3dPT0+/Of1mq/rCksCNYNSFL6lWL758sefdPa2qfL3qQTug29m0AZFk49enJDaxvOgrNfgJ b7Gr1+g6nY3u489nIwMF65MQ1abkvm0VvMmKtildXV3rBVHuvihTfLi8pHfesQiVSkdnaCfA+gvr 4BmuynmHMbXUhy5g6GWUhgjnawtjmrt7ts0IAaiBfEymJJO8Uh3Em6nu2AS+RZ6hrDeHATE3TIkX WPdN3fkBiqYx4s7Uq1Nzc96ES6dud3f3wd85yKcOWfmEhIqDW0JBrDZDCecEmLygWjKHH/rkQ/sf 3B9XdeGlC0e/crQllTdfyXXXXdd8YSsZEEDU4XuQds4+c378xfHrDSBDYNkI8PY//tXj0zPTvLB6 39d74k9O6KtHwrPOz0/8aCIYdSIhTfx4gn+pT1OtNvmXk75Mwg3w7ksXsKRZY0+PQfyMPz/O64Zq z3z/zLIbvMYX1mMplLfwr/IiP1HP56vNvfpjfqLgLCN1lvo9ZbNchXrC1pylI6z3/JrxC3Oowfbt uXOPArhv7z44P7321ttu3dW7Swd61+27Om/ulOPmTpargPaxPz4Wzj/62KNnvndGy+jniT9106b+ IWFdLqfST2BxPKfVVpEA2a9Nee+5JvFMltI8u6YIuzns4xyWcWMxbuX2RnVGIba7ilM9BMyLCzzc KijptB/9zuihxw8pVGefPct5NbLRMgHVUIYHJ5xnmFCqMnZxSb283kFjNHd9kWnz1mkqjhQw51wp RB3VjtTxLQqtFNNgFycvso8aOjA0+PHB4QPDdMorgssemRwVV5KCrRUJ77QvMWvVDIV2/rnzjSe2 /bqWCJgN0FqivS3uJW9zFzOGt2HnjZ1hRefM8MPDw58a7rmth3cugnbPzh5EpSNfPNJ9c/f0a9Pn nz+/67Zdx588fvLrJ3ffsVtWuCuz+z66b/gzw4MPDLLQxu9l6kHA6vtA38w7ot3oedeGpn804rBY hr4hkfckzP/8NXiy2bc47RcbiX7LURYzpi4/0VH1pqM52xQX6cfPtsgXSeoJXkjxZAzMhFu3UjsY l+pBV31+Sf3CkmvbF9qRVhFlwtpG/SglqQFyjiHm/MWJi9OvT8PHnPr6qamphIlxN4LDgxekwPln zu9/YD/fj37pKDVQfuSzI3UXYMzAr4hDuw/YWM/mxumusEcR6Tn4ZEVZvWIOLDgi6U3V7sqTBLH1 j1pWhaxeWlrRCzUXEW5uTIVtiqNyR5gX6QpKAsLIIyNsD2hAiJLAA9Xd1X3yyZO0Z+DDAyC5u2/3 4L2Dgm1CS9B+rj393dNIFVx76punxs6OnX/2PA8s2wlKljJ88jxqcq63JB2sn8POsYvn1D/mVx0g dfpbnMZCbu3oEI6tDsh+Drhfd/fu7nt/H/9639/bdYvjIPWqMASJY10YRJ3wOVKN7rfEsU79yOL4 1M0YbI0/560C6k1vO7+WCJgN0FqivS3uxUvn0BcOsUVju39h4sLxJ47rq4r3++kzp5FveGOyNO7p 38Mnb2HkG17f029P8/LFVYfXN+LOhRcvQFOf/s5ppCLsh9BwsYzpaz28E9ELwB4N7h/ce+/eA584 sGHBZdmQ1drllqKR8SYYOxtPVCTpipq30QFSb/tc31mmyEPk7TMim5Vc24JZRmnusMA5Af7RLx8V WSdh7FBYjDw+glzLwIlYgLqBjAEL11jqOMIwIUkgvMJeYMzBd6aHKnpooXxBc1HnYJ3WKNgqeRS5 n9imp8hDBJORoDop2qzUs2IJukVuHsdursf9NLh7bC0UkJekYK7mHObFlZWSHTd1DD04NPjgoGiB ncQGuwCBigwEf6aCtQe86pRoAVI3UhQe/foobFDvbb0KPieRU/0lkW2W90y8LHM41yMwVGFIU1jM XJXdSL05XOyyCHY6znVMrFJmiBBNV8Q7Uv/VpZocFDTAh1nSeBAKaUzaBclpxW8NHbK4neFB4LUm 0qFLUCP/c9/na/MrvqdV0DIEjAFqGZRWkSLAC+jAgwdOf/v0U99+6tLUJXZs+oLAl5jXJZyQ/Nkm EeeEDertge/Rqx595NGBOwdQoyDTKN8z9boQBnvu2sMulhpyxs4UGPrEECXHfjC2McGXTfNbTk1T ZCCyPAGSX6MyyuJkD8nG4JDkyHsPJSX1qhCBRtkd/2OOt3DLRiYyjSsX2I5gCZTb8sK9wdYwdtd+ JivB1E+mWAtnON6eQUEZmhwYKWzhb+259dadt9Z+Kim+RYNZm1dRyc+fhmFUWPl89iXtu276k9B5 ITZSClWuTMSBlRuOxOyFtiScUaekmF0LbVCfrxz3E1yc4mjdUZl8LKJE5ihiXpzeysZB6iB8oPZS +63T3z/dfUu3Ml5jzyQPRbTY8xyB/IWXL1AY+gfmhqePHUhaf5B7oqu8CXaEQz6mkbs+xE/KzTqd VyoW5Los0XqUqowpzJhgS2yGOm/qHDszFuygmV2IF1JbPfot+8jkIG0gXhehbnwmtS7SXoTPSoU9 QF9fX29v756+PXzq93PPnFvqLaz86iFgDNDqYbtNa+alBrtz4FMHRL5xmim1QfHuGG6ZFOL966co CUV/+nunpUylxqt8+LPDLJ2nf3AaXoS3OXtTfoIN4mWNlANVoNdqnUOfHOJFdu7suY1pHyo+7RA/ 0QZxOTxBdj9dstFMts6lHlslDJBaWGftM0p9weptyj3zobPb1XPkS0cYL7gHvp997mzPLT3oxSb+ cgJugC9aMFyFSRD80MEvHOQk6zHKl6e++VT/B/rD01Iul7ifgVQS3ddrf31/q8D6+NmYNRyJUa1n u5P61gWX7BjDRALL1B+1RxFugLOsnclin/HjY/5US2IhyrxqE16Hh0JVjewHkCO7buqC2mEI/MPi sApiBzpokFdLLIQnkOchDcjLlwI14s3MF5szjbiuKOxyUIgrUEEwque6SBnZCL0midsmX52UJG6v TqGD4wyiM2diwBeZxsGEy0HXqqMBAwRjDceJpj7+hLFr1a2tnpUjYAzQyjG0GjII5Pe1GnQ1ZE26 wVmTtLUju8xdngv2m1jJjH53FO4HfQr2MSx1SFHYhfCKZ72EYLj7o3ejUAvv6LPfPwvBgIUHVpww Coe+eIifsL0NK+66j0rGdbkJG5F03xwxMfQiz9nEnkS6YoWoP3GQ3Jj5SDLGe0ziTXO9e2XXwngD 3d2RGjLr9p0xwjNZ7SoYo6NfPfrC+Asv/PAFmKHRb/vYB4EB6v9Q/8HPHRz53IhwgWV8Q4MQvSmk ZbyOskHpuDdZJsHQ80lRLGxfWxbhlAEq5Z+S8crEgI4jPsfzMsc2JeOiRVJr6No1yYgym9jZ6K+a 6KpS4RlR8RFqgYEYf2kc5Nk8ICKoYCRawsSvkBEBed2W5JNn6V0jzRd/ZaSfZuaw4xdjfkhrTedw KcEWZ3cvmK+d/OZJzJJ4wI9/5fiRLxyB4pIKq1V05VAsObuiGF3fnchOKBClLQsDHWCMuZ+G0lXx 9Zhvs/29hgiUMkDmBr+GI7DYrTadG/yZp8/09fbh/0XP/CbPGRzwEsdSh1fquWfPobfi/YX0w6qJ cweEdvfObt7jWPxAJLDGYL85cNcANbDnO/vMWerZe9de0aYlLxde7hIWOVm/Maft/3A/nkTUthGc tOHnIbTCK7hod+KHfaGCmg+r8DiYW25GxBvlOHlktaM6Mz0jtlZd3bFtil7u7xgxE+GO8mvxfLgq aCswGgkZIZI2+SXEya8st+IHtFBRwNmad3Z1wtD0vqtXhwl5BQ6s970yE1iPWbq8Ma9b6XVxzViv O2NehFqZPFlpQGvz9E8yrxqgqrZBGVQTfiXFQcuodJKNW6icJW2ASknzXSRGJOUIh/oTyyTP+uSc tONfo1SgjGaqqQwzIFYMOftrpE/lOz1QDlvJL6EMKw1OvAEAXAMB8AShfY4fCnrHs+OHI9hRoWJ+ Y1ofWz1SwIttjt3Oo18npyZ59gOqoarwHshATRCHHR1ixe8aP/HiRP+d/YEG0wlA+fNPn5dWOSj4 Ey8w9f9i+mEsCKeVEdqyTe3q6FLVZPpMJZBSIUjy0wrVYfDQWGL56eruzsbMGz7mnmT3J457WAiU /bKic+YGvzz4WF6RgXJu8CYALQ/MVblq0wlAq4LCZquUVSdtsupKIjuVsAxwHtEQO+LGa3n6eg31 sHhUOzDmYIWGA6Oe2HI2U76wVgVtRT6ASrR4qHolJ4XkLY3aKihc1mxkxOld87bqEZiwSB7K/Vou 2ZTVoOeKbkqskWJrpXrGEPvHySK+DfFVcbyf5C5FaSAs7UHq0pVYrnCCYxz+uBgbuqOro4UERt3h y5nclUl12v54LNjAsG8pnVcivmRDWKmAKBKbqxzbbRz147ALCjsSQxBDcRrAuJANA+XVwQ0BqNgM HUpCZImwGJku5d33HOAr3C899OmHIOFiGFHZQ4JyBoEy9fEMgZ0qFbZqLX9qTABaHqQWB2h5uNlV S0AgVvwv4TJdkxqnVs4y9kutfJXKF2Mlp4xLHTuVUragaI8S25FIPm2OJBhJ8BsK62tAD3OrdLVu IvaP3KXqg8vF+OcNNSBsXFYyf6zmWIjtc5S1Pm/DlGVZlL9JZUq30KZzKWv/pIul/qpLKZJfKC/3 deEJMgGFnfTjy8TWP7F9VVJnvfsGgxUKqB13KJmzN4qzmtCvjANUPIMb4r/Ic1R4EkrjJ/k2N4xt nZN+wlhIN6OBCN/hCFMDQY3anBUuoX9IzSa+VLOowqaRfjAj45PYRdDGYfjyU4K7OWkykHk6iEWX xhBBYEVvAwXffQY/L/S/xEjEUYPPhz4h8RL5PvSpoRXdyC5uKQJmA9RSOK2yMgTi3e1SEVpks9s6 Y8alNqxB+XixqeuHFW1MizYTWnm4NiweqAzUq1wtWzU3ez4yjdqmJH5JaTuzNhyZ87ncVS4xkxor xPir171a8+j3TDyV1RwLlF+xu5CubaW+SL7NieVv3jOLnxPbHa0hxhbHcsgGKB9oCYgBcOZTI0HH fc+NTtDveEjr4Bw81GKeiZMibwVdWKRzTGMCJeSBj3rgNEElz0Vj05OlpijXFT2LlVcnBVurwhxW uTOdWlEMKk4GRzk0UwK9NokUsDXxUU89wjgZmanhOXXggQP779/PPxTcOIruv2//0P1De+/byxd/ r9isTXVeLu5GaHBKrakMFEGqD9FKj9gGKKkLM3OU+4S/jz/ffL1l0fBX2ma7XhT3YkefOywS9Hac GkvdI8bll3rtIviuJpewnKFdSnuQCXxIwyzTkG5/I61BYBpiPkAWhQJPwxkWY9Zm+bdDVmisRliw ZW3ORiUuMhPx5lglm8DJhf26X1PRfCFjufQBqXZDF6TcBjpJsTSLqz9mKOHfQuXsbOXM5XqftYmr obC7UDQj9Q+Hg+7RS+LuFHyvvDlIonNUJEs4iSzCcz+dky53SABPLLcQtvBfEzv9HZJltp7/V2Bi 0vrDiLMcimyVTdHA3y7KkfziNIyi+XJMW6mtUhoTKDu+PvxjMicVQ/cpeKJ5dfjX6o1CWj4Zsjz6 ruZspCU5E9uNhfkTJJ6Ym9QKc3NYZRERMdF57aiQ+wLbNVSoHbd0qEQCCOWhlQK9l4jpucrlZkHw crmBBfoE6rSpCbcUa9n0jiuJi9jACwyHDIKCEvch/lxJSsTlvLvsmoYIGAO0rScIgQQfevghfKz4 PPHHJ/izSTgkJzkRe9+Y5lrJYFXYX2IEQ50UaLJCNP1EAPKFl84laK4MPmlP8zddtG3YM+J9tqQ8 G5rTW1/KwsRoJJ460YFTViDZ08uSuKPKFpn/BxNOkX46uqTayIlGrEeT+lNWJtGnBJ1apiW6LS7c S9ZjscJ1ko9bQlJzjTITiulqZXZH9/HZ6vm3asNfOHLuRxPDfzo6/LUze79xfuB7E4MvV4ZeqdT5 rJ5+bWrsxxPjP5oY//EkF47/eGLqrenzl2tHXpPFOz9dkjhG6UglqGZYk8BU1eHVxNaV1XdHB4su HI//vKUbmRK0H334UWzqwRDHQ9Qr2FRhU8/36SlpTs4iR9dLphkFsOXHEiXlY6IR72yTXA3huVBZ R8fU4xz5i3mpKPGXVLpCj8j/LiS06qRZ5+drJ16dP/OT2T0fvXv0ufGhr50Z+tb5gW+N3/0d8K8N vVItxf/IW5WTDnOH/wT4XyARTaVy6tX50cs1qp138xbZLjuHpSX1bLRLeTjfUzeTdUYxVxF6MMf2 JKITs/gzKPi0s/F0DYxReC3omRhYqbajWyJskk8jmcaaWyMmUPOQqjmXC+otQvNSdji5l0YxDlAY 9GvXxCxdpKvkk3DbISHJoi8fK7AGCBgDtAYgb9xbEF+HHcnYs2Os9BC2WOM2TgOkPcHxQTPa4ATE taWpqglaSM3Ed26y8xdfuYgHb5OFc8XIJDV4v0TXoCW0p5iiaPFq4zdg9F1CDbltq9TQ3FsS/mCR jaxrTbo/1s2r++Q1jljDPxYGsb2tiheSxvCtuZxfGUsU3bwWbIDSvXjYFgcLVidPIAf4bXHiHCNn NKdY0rbAAMUmFET5neroPH65cvDla0PPTZ14p+PCTb0jXzk+8OH+k58fPvm5A4O3dO/v7+/6ydme +eme2rR+dhD6ViSDWk9ttusvz57/4qOVqUsHPty/90P9XNj34f6Od/VMXZ4+Nl25263fSEKwRL41 alThGKDQttS+p5QBKosNzSVE0pPVV8cxiUol53d0Ktel2KJkwYXn4OcPEtZv6NNirpEPIkwEna9K 5GuKsXwS9DxmQXzbXPoF6bWTOP2CXZhjqe1RIQdZ6K/Wo22brlbHFqonZquD358cem769NXquWoX Tu/77xt46nMHRvp6hu7cc6C/r+uNCw75Wf2E1xLJoDbPWMydOTb70njXz66B/4DDv/dD/Tyik9PT R16aufs748PPT4skqu1PsFqEpwyj4OQ2piuCDrM3zGHETf6JbF1mSlWENzXSz1Jo8cQOGjRu55vK lI0M11JqMzKuUlTDHT11mlPbBeiX9CWyAQp0OHOJoAP8wxES6yVCRczMzRDsY0kVW+FVRcAYoFWF d6NXrpuVyZcnUVTziLJZOfecBCrlC97s+J8HeQg6l+/4mcMSTU7wwpyG4+HBJh5P77udL66Lw0YB vSTNHpVggHSCizvSCWUmfzzJa4L6Q2rAkU9L8gQtKzd6+gzvQW7KXfCfl7tflvqF3UHJ8sxZXOiV r+IMiVEROyhDS6Q9zjeYgwKhPdLNn0ziqk0zqEdDqKWHe3dTFdWGxKsE2KUl2GCy15efl8pLxVxF gQFKWZbETsLvj4MxgVrb8LmjnZ8on/HH1s2rO4Jpp57xBhBx7J/EKih0QXbMqLoii5N4u+z5qmAD 5CSG2Wr70VeusUCeeqdrYqFnuqOPtp2Zrgw/M7XvOxOjr1XOvFEZvq/v6HsrU7+//4UHew68NX5g dnzkrp7e7o7KM6N7Zy8ceOvcJD/98IW9nxpmlT3043nEHa7lc/wdYQimbxmYvqkfSWj/M1Mn3hC1 jpctlC1wubECZybfk+jVmXGMtv6eMCD+eIiarcYiAduAmIulRD2EWsCpB4KHL5Iw6+nTuPmoRgwX J0hNrmW3wK9779mLtE3EnZjnU+srP1tcKnJlLLxRi95d/yWHRz4YrIS4WZoLLLG7mlyojjw/c2iy dmqmOnVT//xNvZPvVMEf9B59dgr8q+/tO/je6tH3Vic/P3CyZx60hy+P7+/vqLw1Vfn+iUNt04zI xa8fPvx7h+dvHwD/oWenFH/+ze3onq92T3cNnK31gP/gM5Nna8iFcaztDIsZ24elzJAm9kLKLMxh zmi+99SgO7jUJXGfUxsgNaJSGjKiAAOZqoBz+KwdEfGmtw6EayAy9Vr/UlIboMiUrUhgZ14OzfwR 2wAlg8urhvcPaQ1Jltd7ey8hsgjeiCVTM/VZmbVBwOIArQ3Oy7/LqrrBo5zmXY+NHskFeVx7enrg gQhrweOKbaDkGKpW8bVGsGi/sR02AuGAQHYqeRBBf/iTw2gBiHrHr6wHusljwcbQj0zUd995Nz9p OB8Ozgw9MMT7EWGFe8E2STD+2Vl222ymRV/21jSrI3IMP8kb85ZuJBL8JgibcffA3QgiiC80j/Qa SDAShGZ2llC2Ey9PqFqdM4QVpiRvGRxN2ZpLVk7WlauSnZ4QcHfvvZueInhho0MDLr1+iR6FgZHy XzslpgO1GiHXJFLfzZ0sgRR44aUXiEuUajrqDCaynbf+cQWC9Ym3BdHXdHYtpAysOBDR+FjDFcwU Yg8gb4+iWh6F9PlxUMJKNNOiZI3XNvBJUGCyZnqrlCj2TBxVKGxbZf0gK2fV2b4k9ra1hcrolcqJ d7orSZQguWPUEuV49lZn+nb2dC/MV2tIDBAJnScJ4Vvt3nt1Zm9vO5k7LkxfmiJoDbJmV7+TCdqn RXOBfEA7g9wAYyFnju+cH34XqabQIOS93wMZ4Jc6h6oneOBLXMoqykinUJF0dafyR/BmD0qQSju5 VkYeHkHuwa1aUo4/MDQzP3Pk8SNMhtFvju772D5C+mJye+gxIXsIe41ALHv6tyTDK1M3xT8xHA7S bQbhBHmvc0mWai8xuFFD0oqlUh1WHfdDl9vPznX5gY40oX4U4Hjmp0fuEJfygP+las+pV2Y726r7 d8z1dko941MXp6/Mz1W75jt2gepctXO+TTRHKf56A2q7OjveX+2oSSyr2IcxP4d1jjm0mcPsZ4SL TTi2nLhDVakfVjx53D1llj7mMuAWJrA2ilvMvTPHK4hXzeLAMoedyjjkL4uFzkixKJJQKktlHqSm /vBu8KHNbRWeaE3vwzuNmGckQAzvwKZqXFYhc4NfFmyV0jhAZgS9PDA331W69Rm4dwDTB4Qe7BOR fpAYTj1xSkL6fuWoJoimDKs4+iDyVPCO63tfHyIFq4I3AHRaFZYKLsHzk0B2sDXFOLOSv5raJi5g NkF5lhBqYycNnSP1JysrchUrFpIKtxAJLLEu4iXC6w85hhYiOfGWQSSanJykGTQbUQZOKgwAjTzx JyfItMotqBC9u+QRW6hI8qkXL0jcxZu640xVWp5U5JQ/+cRJykMXacdZ4ZB+fAvrj7DmqPLbygJX gZ6Fl6zqBRAQw6ec31HFiCFn39Ngo+zZC10SYgPiQMLHdjCJBVIs/eho+s2x2mc4oUda6NrjDTXo BRqiNpdxrNp++sXJqlpLRPv78L3K+vfyeO2t2ennz3bX5jpnpontePH1KXgF7tVdrQ2+v2vg/V1H 7h84/bkDY587cOGBnr3V2Z6eDuESpM6UNVEZi3vNzMyJh05p7i2lB5ygFlCVdiq740DmvFjaQjxE ixNF8thifqv0gKMEmB6IOCzGSEVMaR4KpiizmqmIipbpJ9sCkpxcmWEG4owtkmXgnBJtV0o8ZLOA iUbMWSPRNkG7KlrOoOGiHjmjvUiOsFSfn8Tqzp0tk36qb01VXyEM4QT4d87P7O6oXOL7zPR8tWtu dnqwv2fwAz3gf/TBveA//pmBp+6q9lVmSXya1JbgH+oX538XDTKxVRLlbFVs8DNz2OGsKVRFkgic YohOrqY2zo47Q1UmlFvoaWxYHaZZyvrwkkFWjk3cYte5AKw+aCiRE4M5/6UM0mAD5Jmk+k93g190 15c+FJHjJK8OtmpsFxGdmVS8cEqtBZZ1W7uoNQiUMkBL5fpb0xSrZe0R0JcO2Se6b2ZzX5GY+mzc 56excuBZJXufNEl9Wyo1HFA1aJiuPbL8uJWeg/WAWPVIAJRRq5EgG4VOSf7qHeJXrO8L3TfDskge UF3L3bzjTyphGWafHZT6nKcxaouDwMS+StOjakuUL4nfYlNvuCyq1NBWhU+C2hHxyMV+heuS1ygr b2SToeX3PrCX8lDWdIH88/vu28dJH7xYccg+GYETgigiRFvqjRUCmeh6vKMdzRopgTIrcbIqg/PU 1FTqBxQxNEDB+p0ySXHMYvcdEkJi6d4kq2bqtxVNIwQ+aiCASpwZKqd/KdlMY6/T06Ncferk8s5c 7afnO3b2zJMKA8vWhUrvq+MnH+yZf3kS+y3E04EvCW935rWpqSuzRyoDYs/cJgHrOrDg6Z7vfWZ+ 3pmmHu2coM6jHx44eZ9MtiPfP9ve23f6nc6pBRd30eFcfWOiNjNd6e+5tpD6YWm3vL0wsoKzAS+V BuLzmeiFSUrwwKXpkhzsqKh/8BODBx87GJMQ0BLs8tHPIrJ394g8xzxERicg4cCHBmRVuzovJuRR vgv9rm0LHJUnJIIbtqp+kAyc3Oxthgp2Zt4GCCJjZqZydbx6U08NQsvJGSNvnTn52QOoV0hDyyNc qfSKOfOPxseu1c5O9Va6eipXBZ/d7+44MjE9XhOys7dteujG2f5bugbe1TPwQD920JM3dkxXO0df x8jMx72sEt378qXaO9OVe+BynJ1ZpRbQhn9F8tNHOEPVuHnLjGUy55hFRaA2XwO3DC0a0sc6MZEn jlynpdNYh549DJMZknXyFdFfe5BdS7zaMZBV2aCje+7YIzGmkyOYVXnhUi3DlnsU5bYQB4hnEypa wx5CV6MwRQziyYITWu7d7LoWIxBiQMf1WiToFqO8kupWVQWG8gieFtojDofKU3rsj45Bk/CywweK 0KtkNiVz09hzY8qFoGbae/9eMjqhrlIVGJdoDnA2x8hSvARZm/npwviF/rv8q0d0W/fvhcWhBspA L8HNUBWiCRZI6k1GVXBRVHLplUsIOkMHhthzo5ugGLnlSdwIJYDMBAPEaoR8gxgE2yyp49+affPt NzFNpSQaq/l35kkrhkINjQZLF4sEWjnRsrl70QDugo6DfunQcC/KUxW3w+eL+/I6FuPNnd2SMDJO l10cS5yQndlTMR8FJ71epnQGROt3qc5r/LlxyDm/OuZqcNdK2st39WjKWD1yaw+vWvqlVs+6YGjm ATkWnGltW8SIRGHicnertXXueWJsXvgJr6vq2MlyW9tzU23AZQZjnfTLCKkAnjw317dv8r1JWoMy xoJL+trmB9slb/kc+rWZ3tqVGbbS82+ztnnb7IN3dB+6AxnIywfK3GjDlKPKyaOZNudko+S3VB5K TE+of9+9+4Y/PYzmiwwuzLG8IqatgjKX1RetqMhGlQqyPkIA+3tJ6Hu1du75c8EaqQTnBOrUZqtg /uLNeBN2KtMRsQESBLq/7hLhiVwlxJdIQpXakT5RPzkOCQbLSyTgP/6Jo4tKhwd2TPXcgLdXZfyn XReudFbmEbDmRe5RS/mF2vhjezsWRGrXSEjlR2EOa7Eiziz/otoOR0F4RfpReDlKRSjQhm8TxoVJ q95bTsMlD0h9SIvNDqSa/KTxCJTFWdbBiwv1aHxpUIHhnDH2/bHcBoZmE3ZhWbdqdJGpwJYHqUWC Xh5uW+SqdPsSvZg0tQICCg8wX+A29JUkwcocYwSPcuqrp5AqwkW7btsFk/Ho448SnpUNEBvBEMUk lNFQH55PCtHSEg+XwAChh0KWQrmAUKX3jbHWMIDsd3nvoKXS9iCccUdEHy1JO3nVsvFCZ4dsRDuR YHreLWxEWGnSoCPuEi2P5otKeMlSPs471niw4VcoUJqNy7+m+Tnop7Lfg1eXj3qnEV9UNIk8vKQB ysMpbtF3PRM+Q+yZ9Ix6tquNrb7ok/oVq/iOYjAR1+9sO4Rp8/d10o/G5pmerL09Pf7y9JHzM0fO T594qXL0lerRVzqOTlYv3jk0hdf35anqW5MdfL4xmX5/S79Pdbw1NfWau/bs9InzM/Mvn6+9PUWd oX69S+wDFbiosPjVQ1XPB2zj77mYSVpG11S+65cYT/2uSXkRuBUH5glaYGYgrAZiUIp5iCidLKge W2dyKzqgiqiBAv6+hRHmcwgckVWNGwuEVI1FxEB466jatZriD3qC4Z9Nn3LIB/xBvoC5G4uA/+Wp M385f8zhP/7iZG1S8PfSj59RfgZ6WbPpOax9zOOsfWw4detNY9GCuQksI9UmjGDYEmSE4yQwlQx3 w2mc2iG5Fq1E+gltjqeif1jcKxQdPbvBC5MX+NTvF6cueijsfxsAgVIvsP9q5JHfvvlXu6/8J9nX nvrG/7AB2rl9m/AHf/AHq9f5G9tvRBXFm73tlxLtzvWV22+//T3/+D3v/Od3/tW//le9/6QXC+ie f9SDkNF3R9/Nf/dmGkP2dWh/iOXbem+77R/d9sFf/+Bv3fdb7X+n/ep/vvrbn/nt3/zN37z55ptv /fu3Qvb+xp2/seNXdmj7269vv/kf3vzBOz7I9xv/zo0fvPOD3b/afWP1xj2/LkTOjl/e8Wu9v8bt ev6xBLm/7bbbYG5OnTqFnTX139Yjd6E81/76h3/9lf/1lY/8+kd+9wu/e/Ov3kz7d//T3W3Vtp5b e/Z8ZA90iLTzppthcW78r2/828rfHvndI//97/73XHhD9QauEt0ZDbjxRlrC5dq2trY2yr/nH72H fg3934ZEoXA977SFnd07tZ31hgCy6m//5m8rP6/cULlBZKDr2xd+vsALms+269tu+KUbqEeO3Kdu f8NVaidxvdOJuGv18/U3XwcHf2tqWJB2+p39z6mgjQI3/8rNN958Y/V6H91Ht5sLCwt80oA3Xnuj 75/2tf9y+w1tN7T/UjuNTO9b5Huym3LqDxvxhevb/8f/+fXaL93o+kLTa5XrnSyl37HY+ZurC381 v/BXlxf+6mrtr67o97a/unr1P19e+C/85M7z/ap+n5cy4tyerSeu8/rqnn9w42/svJlRUFT9LPol 52TUANWG2KYIV9qpWev85//tPxeF7PWV4f9u+IP/7IMeZ4ewzI1K26/d8WtYSd/8D25WnGHU9v1f 9jFPSETFDJHp9Cs3imXMLznrLsbu+gUApx4/K5yUKecXFpAMwn3l3kXMf57GRaRJ7iq59sTL0ynm KglF+AfMszinY+HGRUYh4F+poSGr0aMFX1tmLHZUbvgX/+y2m+lFY7QLc1j6mLBrMpO1v9dXXn/t dd4VqjhjGtdcNxVenWYT//PER/o/EvMlOo3hnwCTf3/x8l/8xq//htaQAzZsbAKk1CPD5wYxGHHT Wc4wTP5xq1zb+fdl+FZy/PC5H972j2+LJyT7t737hBOq/lKVtx9H5690yv+S7yu5Xb1r//AP/3A1 qt3ydf7z/+tv0ccg7Uy99jq6C1OBbaBxX1UV2AbqZ9IUttdYzMDB8B7B8fjcn51bAx+KZeMA75Xm o0jWOb/FDGHWEt1ETpvjWZ/69h9w6cKuJzZYcbxg1Weh8kNPl/cCc53RlePkt04OPzjMQuPXJOV7 tD3hcGuw2tbk/H1iWI68OH12et57bKnf1ip/Hr6jZ/gOCf+YWd4i9UcsPZTqEBvY1sTXZvoee8mF XPGRTU9uqqghdl7fVNABNUa7aDOkY+S9yZyP29AzkxMzq455GFP8+C5+YbC64DKQ5PRcwXopq3jK zyvtc3KtT/pbH17VcMXwyhxWp3pXCYaJqK1LFM2heZHDWgxp8elGEaz1qEXg8g6V1VCsi7VcBBH6 dPTm1AmDLumKu3vE53TqEsaFlJ96fQr9vl67vPuWXmUqsOWBaV5gy8PNrlotBNApYLmC8Q1qKd4U G1n6AQKRfhx3lgaWVQsVXac5Is8dXUtChKRMDq8kx1ZupfQv1shvS4Oj6AtU/qlqILGbCZf7DFZJ LJmglUi1cmF9SiyLvRwQadl8bU5aOnRX70hfV1dtxr24lYFIeIhWf8f7+mA/Yf16vHmHhmxx5Eoe VUU4ZCjT/iZBflXiDL9qd9LQvcmi5V2NQl6wyL0oJiREIsni7KWfpA1BAsiZpOTGNCdrpsa8muoh p+Wkka53R+7p20s0wcD9LB/zxceOUT7+8T1VtN5B+olxXu4c1oma8jGR2Tg/SWCqAK+bcjKHo8dH 1NaJyFWEVB7GrO2zlKmnek5yga0kEVjsoZa2M/ICgx6GOCQ2B4wySLKX4/veuxw51FLpZ7Xexdug XosEvQ0GeVN0MeIkEH2wsCZtsqQN2uCH2hU5rzdvpRv4lejlm7FHcZa8qZ1EYpnkeY5g35PU08C+ Bwsn9Izy6o+lFnzXifundjA/y94rsYyJLXtyVkRh2ciVwSp2+PbO048MjvR19N9IZGF897w9kI8i U7ATWtJ5lvauqzNdiD53dJ9+eB8hbTqxVRJU3WfMsmQXtiVg6+ZSinM2q7lam8VSYBGZDM7BFlvb kx3HuFXya2JHJZEdVMoJZ6Kxm1+Y96MZW185m63dHe2jnxoYe2Tg8F09IoaKZd7y8E+iLmXHC3vn jqszAzdXR+7oPv+locFbOkWWjMiVJeBcx0atAbxCcX1yKMCrCe/CVNRbqxli/jGJhywC2V+bBdnn /Epc9KVMqzyeo4c92ACl7c/mt9/gr7Rt1TyLBL2thnsDd7bwJtosm6SYY2jAT6iExACU8BOJB5V/ IyexoXW0QqRdT5uHXNzxYEaeVn7lUF7kBrFbD7o2f0XQrYRIyjG3EXiReLOuJYnoszB3qH/X6Kf2 jn9p+PBdvUfv7TvQ29G1cI0lOf7skDuV8EPZknNc1bMwp/WMPTww9eTI5FeHD/X37N7hfJo8VgUu Laxb2scE1XJsk3jZKVoRVl7HlI3W0xTOmN6rlBkzfFF6qTQOVlImP47x8MWYx7pIR2l4DSYcCTEd 3tV19J6+ySdGxh7Zp7jt7a4U8S/n5xAxMyMl+O/t6UDiPHhn7+inBxjTkw8OHOnv6XbZM1L5oBmO rXQOJ9yk9j1Dp+VYkOygyN0LwGYcF1RFmOWTwvRWla7KTN5BL5nq0oYdQprqAK3QAjoDUTIt4xeX vhDSrVEZWbuBX8pbv2kWCXqjj/Eq2QDh1ovreO/7e9M4N80gEexFyihcccuq1TRUtDIcvKL63tun b5wGBxfiZVPK9yxBWR5Wo7I7NahHcmi8r3dpwdCSe4kDfLL7L+pWlBVI7W9yNhOhnZEBQawfOfvc 2f337g/LRr5b0VjEV8nCrPettJ/85kmsyONtbk7/EurMn8/ZCWk5lhzcu4iU6FZ6jaPNOjNfAPzC G7NT03PXZMuO2kKWGv0+fE82aLVcWOtgGUpqYP5I9O2k/SFUXTAEWabdTzxvlZ9oYOuT6040Onp3 sMrFV4z5vFTtEji8UtVMzu4qVya5FrQJP6jSs7pA5lpXiv/J5ycd8op/+KwM3+Mie0WHKDJbMoeT GZK3J0v6RcAkYlJk7l1n2lNDEC5j1S02QAcf9yGaAlEXKxAXN2Vzd4whXYkNkPbFu8HHNkBPnyVm h/z08KM4ZGDOSBD8hz7xkAbgwDCI2K1lr6gVnTMboOXBZzZAy8Nt019F/q/hzw7PXWkqIgXLPAkB pM9uW1aPmyGbBMFUKMDnvnv2UT8WuJ2dnbwjGuBF3B0cykiaU1qmMQ9EvCLyXfgLG7LZDeoh1g5J NpoZUYwZIerljuFeyYtPrVXK9831bCbq2KPUW5sF+dhIIrGTDbYpaRA5ZzUiq6YyQIEFyXI/aZcX 5YQomiweKud5nskF7cGONPdv/7u7Dt/TC1fhPnvD92LJrkj6Sccx2PTkbFB0BmYx94xa0e6nHq+m c7iM9QnKi4ytT3RHvbv/NW5JkfsJv+q9EnvquI8ZAiNXJrkL8zZwh6VzuBT/BHnFP3z2FfHvSKIA pJZSUctT+6pF53AyQwSfJIFXiVFO/JjVoeIoEkz1Y7rUdz/mfpIksmFKZAz5tUnhSDYtXqDUUNEr PtJWJa/HUCXBxIk3xp+737f79Pd88EO8TVd8T6ugZQiYDVDLoNxQFbGiE+SQzTSfmmuCg+ye7MNY v/HIwHWI7RRe35L+08VB5sDtSLOEkrWU6MmU1BB/RAjkEkpqXm4q5Fdom3yXI40AUV8xYSboBeIF 9VBYksOTytQdo98b9Tf6ySQx6NSGJn5V0QBai0fiia+dwNcp/EQLJazzW1IPfYThIGEFFI5madU+ IlH5u9DgeWkw96KegAPsF+WplqpI4KXGldoqzrNWURXl+TW+NQVAjwLckS0df0p012fG6BdpxVQX ExsoNLKZCFFqopjROVufYkQf7hjboJRaqHAVeay4td86JzZA4drYxkWXB19PsE1Jzog9SmxU4ULG eTK/dK77xUZUD/6Ilx9/Sn+tW0ZUEjm7k8BFBTOLyNomlX6KsWdiwwsXlzmHWCnC2sxFcZZCCfPH 18xYRzGcJGuGU/1k6owMU/JtoLjWvFAR/FM9oItX1JBJjTAtHZ58v0IhWcLrYO7t2zTETs52Ldvr zFxK+htLfhnpLQxlIYSVXCI0YI2MgXrT8FjVG778rdOwVUmXwxlnah3qFDxLpmhd9Ep/iKdKrjaS GEKHcxUPjsSDdvfSM3ZsEARKbYDMDX6DjI40Y3kqMBZvuFaJ/kdOpcszR758hCzQhHUmwDFvIjKM 7r5999Cnh8jMhZsVIW5JvEVJgiyz5JO0Ab5H0j2+Nk2aBUka2tNDei8eYwJ5IQxROeoqxCaSbcXJ jal/emqaiMz4cME6KOVLaEHq5DuZJbgX9C/iBZGHzv3wHCkv4H7YJ51/5jwhVQ7//uGAO9QOvmC8 XHhhIejgREpfYJIQwvhCj4iSjIspnBOXEL6ZPE1EKiKQdHd3N0IP8aaRcqh/5p0ZxC9c69FZaJKN sT8bQ7qCjdf4yCQmI78BtY1+dxRRZuwHY3QWh1ViXvP2p6nnzp8LEWxxeaUMizR3JMoZvaAlrFLc kXRRVB50XrGmRl98+WC1Ia5xtPbojhkZTiUPwOzpJaeW2E8Qqtsnpa+jOIgNLBQ3IWfcrf0SEnQu MRuRyECpKiEkGXCZRnwCJuQSfOmVU3ESycp1B/WesaBVzGAYl44Q09N1sdWfczqsgrtQ3Pf0PvVw Vruc2NI8aDbjMa3nlFTQi5XcMTklEqcmalhNzEXecPuEEqyymtDF53AhnkLwWBRRMGZcCtO+SBdx LbqwoEQO4kUarCFgl4g4+aFU+UbjKPJ+o7bEFI+TK4wBrTfnNZuJcM0eLFGB1Zvhq3HeVGDLQ9Ui QS8Pt81xFeQKksfB3znotc4LFQQXUiQSZFn3rCyTpFaGnuX1dObpM0gJREBub29ndUdUGvnCCFzL /Oz82e+fZbeEYMR7RJKGfvUoyShY74lVmAEiYYCQfshCRbxExBGkH14Q3JcgH5peFCGDegb6BxBf ePNK1MGy3GHcmsyU3AgyiUpIlIEoQ184Q22HvnQIuQ1hCNENz3ksXRDmEJWUsiKAENcix0BZHfmC pO++NH1JeKznz/N64iVIf0//4DSZMaic9QwBEcmGeoj5K3fs6Bh5fITCNBVJMfRRTBBIj8odvypp DiXz0fQUchigCcUdLFfioLTJ9yCFeLagyP0k1hLcFOEPj1lybPFJO8+dPQcD59en0k1zNh40JQEW /k8201drEss7kn74NbOZhvtxcaK1m7JTZ21w8pOkuHJGP5wJ3I+0v9Smq+nNdIarKF6lBrAFfsXL kTG29TiJJrmfLCeUSgB8i7kxtUrOfmo+VGHaIooixKoWhJPRDGgvTlRE4yKXu6y0gVta1JCuuVdS CU8U4l9nMHfBlOO5mto5Nc1fBnFE5ptKP0XupwBUUETyhdeIQq1cWg7YAKlK/7H0I0717pBp7JJd MJd9F5LpEacabA69slJRj8JWZ/m12ZVri4B5ga0t3mt7N00BuLt/N2IBFA7vIOIg85oQU8rEyQJL HX6EdWAJVytFpApWTRJinPjqCWlvYjPBVyQMXkRkyYbX0YRf3rNU+xVpK0TEuWdg8L5B7AFZxfmR LO6Upxmnv396+BPDvNok4OEjw9RJ6PrZt2dzqZIJ8ac0AywUEhXyDd8RO4gTDbuDfk1W62Qp5l4q 09B4xBGkN+S5PR/Yc/EnF5GBEGuE93pgiNciXJHak0JHqUkpL1bNDK9W2AJCW4UUWiQsQ+TSTCD5 gwxKL40jw1EhudwhzCTZahSNZsk+X5G3Fw3mHw3AXEA/0dOluT+VoSnEqim2UGgkd8gX4hXxXxJ+ TXFTrYSCILIOa4QuFS4jRPeOblmD1Y0lcWbR7+W+M01bVGTEp8JVwjkl9EB639yZyLkmxB0O7fRQ xDZSsVVKEn6Gu5RY1cS2O2U4pxguVGXGOh/12MoqPC+hpLQnaIcdVxHfV/EPPmI6Cl03damVVYx/ yTxc8qlyd4Qustsmz2+4Y905nLQqj3Pw+VLcAs6x7VoCb8bQzRUuGQ4HmobqkU/UgjWvls3YA7lo WF7W2dHBI+kh5dSOKtM4B6N20JdZcTyeog1Q6gC45NGxC9YaAbMBWmvE1/J+U5NTvDWwvJFXAqnU o31t2IpBz7DkH//KcQgPBAXOE7wLhoOM6we/IIQH73dJ4+y2X0gkvFU0byi/QpmU0NruTcqrh3Co x79+nOySul7SBO5FPlSWDfgVSabRvwdqB/aF74ggqJPC5k/vq1ip+6tKJ9Rw8omTME8u/XViFUFm 8vf2omWHxUElB++FaIXA1P/R/l3v2kVjJickaxhUDTfC+InoOLGVK9/pr2TBfGQErJAYyJ3O5Wi1 pt+eFikwwS1Y/nJrcm5MTonXG+0TPVo3ObrTHbPyPSwhsX9QnvvJMTGRyy6IIcbRKf0MNdez14lx S78nDAe9FjWH+1SBNeV74H5UI5asWEGKTW0+kljM4YyXUXJTuS4DFLMOTViqMFlyDJAyPTEnUY9X 0zkT5nk9u58muZ+CXVTR7gqajYN8cMq3KdMWu3z79iR31KVa0ZYJ7L6L3ImHl1u5hXIjunQB88UZ oKYZOD9ucflESdTsHM7hHGZyw1hK8dDEpJpMyJyZlA5iIq3pryJuCrJZgyrdnqmw5ZTFvrZEsM6Y LiWUoUC8mGtqsy/qArPV7IVWbgMgYAzQBhiEVWsCmizoH3RAKJt0W68vCz7jiDWYB2GkjIQhYZfb hAiRzKaPPXr2jFhPw9l039LN++jWnbdy1cHPH1RxAYsc0r9n9tARA6T153bY++7fh/0NFki6tJOt Xf9BoiC14Iselw+7anmptVVoGw6lUDJ8YtMjjrJkld/ZjTpPLYFwOoXKGvr4EMZGLPasJQMfGkBi O/7l46efPr2rZxfUEfo+zHfENyqyw+U7ohhaQuQboi/SdxpDJEYMnKGp+vtdVnPXFwRBVim54+OH qIeTGAz17OyB09I/M3xJwp14hiBebxI+w6+COX4iWR0DSxdqTiWVeptmx+WIAMpBg4MmK7A7eq/k 08s9YT2O5kaGCYh4IAZLGlbke+oyQDHrUM5AxE+A6DKc0q2IZ4g2uXgsJe1jziMpkfMW537UR6xO +dQLjCYGnsmxFHB1GPDyL+Y/0jKMi9PUyBipasb9STW4Jqnco732/v/JjGJmlpBVufdG0wycvy5b XmWvBnNYrmp+Dme5Ri/RJjRYoLu8IJij4vRxc5SOHjqlRavlpEP5VSlMTfSbndLpKy4Jg17sVMuk H50Auc/cuNifGxgBiwO0gQfHNW0lRtDIFmidUCGpqTJ6ru7ObvFHQJn12hQkB7ICZDt/4tzEUq4/ 8ZrDH4r/77t337nnzmFJQ+5rMXmZnRl8cJDyaJfmZudQNsHHxHw+9bMGHHjgAAW4HCeIDLgw2Ffn x54eI36xsBrRgd8W6d/7P+AcJdwLBTmJpDlaA95b0DZ6Cd/Rf+3p26NNRW7Drqj7Xd3779uP4IKP 2IFPyCVUKOZNJNJyB1o2+C3i1gjFValQw8SLE1pS+95/Vz+/YvKMtfXg/YNwUedfPM9LVmv2LXVt ox5sw5ERqVy9wECA8PZIb4EDCKYGwe6ndOVQtiDnKcMZBESgRs4IagK+V28UmiqvOEi2vKH+nHYs 6JKK8kpYoWNtWqqpcX0O2iVdj+kX67RQiat/MEYhD0Mpnp4jyVrpZvqrPFA23k/gt3IzM5zPm+Im 8k3MsYW7KH8jGsZsJjWVPluAeeJd3xJz3WYGTWjCedlvNDOHU7v7QoKLPM7Jc50BqmxoMhM4EUPL p3EYmrieZGOQyiUhJEQCpkhUhXBKzYBTWoa9kCjNI5N5tkN4hyy7wuVdaEbQy8OtNA6QeYEtD8xV uWolAhDCgZdpVqVpVmkBgYUKHICcjZxccr4z6TVFRxisPmdmcKbLCEzuAkQujLS8HjPYqUSv3fza X+ADUokn6LxyC0whSnXKuLh4PKWB+FZpErBSYn0fdGGleOqtg7YoI71FyOSlkxA8JonQk7tLafmc kkXQ0PCNWetyTsSiz8oxV7JNdylrdqgnQQbzEM8zyoTqyyTNysmO2vfMbHdwlUzU5U1jdccLR2S8 lScIozLK47YQSejnXL5CXEae+u5TLbxFM1WZANQMSsUy5gW2PNw23lVZCwBom8NfPryor3LmDdW4 T0u1MGgaoSW0oWGdvp5Va2dTHXLGT/qKDxY/Of8vX48aeGYD9mNXjnnTyGfEx55/6BnhvRhEPq9d vYbzXbx4yLXBpDT6nmNxQrO1fGrxU5b7PWf3E6LsyLqOHqJ1++ZFwWShwvPf623r4KmVpLGXEjwV gWBWkvHhyq7KeQxDYqmsjXk8UnpTz/1oedWUOdYnKJq1WAbzLEsUOJJ6mPtggBjera30Q7NloHOY q01SNKule4pz7JwVLMlCLKUIh1LpJx6CpQnxweLHqch9PTolXEhS7z+vdj/ujHA/LZV+PAgKRfKZ CWm26ES3AuuKgNkArSv8Lbx5dsdPuK2jv3900WSiixsWhBYu1cKg6a4toQ0N6/T1rFo7m+yQWipQ uNQeKHc+Y77gGAUiTaNcw0CKfygl0VRig8Un8SSJmaTEfj2jhxiBfJn6phJaMtfa2AYF0Yc1eGkp U5oEq3ExF6lFVqwye6BShNXuRxfaEBRYEUv1NYnFldw8GHAEa6GiQUkwRlFvI5VyFhuFxmPUAPOM 9Q/cT9eacj86IEFJtOQ5HKymsvNNo0lpzQH2IkSZ6V0GcqnJWlxP2uDIJZM7YkQFkqsiwRdsgMwL rCVP/9pUYl5ga4PzRr1LM3xJM2U2av/WpV0+ykAZb5Hz7tHFIN0EZ2MQsxZitIQhlNhCRaOQs+AO fUx9u5TnCHxPNr+mlI+VDu76mIeQZElY3eKXhNG3s/vWlalVXN2SBiUIHI15tTQGT4JnsP7RlgeN TGDdPA4x5lkFzSIcW2LXksM/lrSCNk3aEBMVbjQ3IPeTDo1KMPW5TLXUzs2lvIlPVu7MKcUaTeNo 6pbTlg7MWEmnLQ80FU4SYjFNVIcdVTjUVRF99JYR96PfjQFa0gO+voWNAVpf/Ft5d80IQY2Sd+I7 o2e+c4ZP3Ms1f0W9A7NiDJxzMXgozFVEfJar1ptTWQlGAZOVVNL8tXj1c0fK1/OpyXn3+JTUGoyE 0Ds7u2emZ4h5SD181t6pEQyJ6JSYsfPpTWub4B5SL+s6DjIp81FkqpR3cUe4oyLQKq6ueTy1pF+9 lsgDBWKglDbwbQiMWsJYxMgUGbWSXyNkGt9R5Yly7kctbJIgxUJjrBP3E4ZGtUWN/cIyMYrqc5MB /0WnZY4TypePgldl6N6yieFncBITaKlTrvnyKemYvCqNAWoevXUvaV5g6z4EizSgeSNo/MDx9yZe 85E/OnLsS8dCvdjokSOi9DbkdtAsfbwvcAqLVWbE1GEZ1nwUy175Sq4t7Jt9w+qdrwdPcf9d1s6A SbEaxER81xH+FrWUqjtChTYgtRCTGv81XbM19A7LXvCpUe99yXOkzilJrCO5RT273ZyTS5Q1M6fZ KbHvKcZLTO7SvsPdXfevbjOta7BKWhvtqZA4Ri5LfOAk4ixgwZ4mbrafe66DOV+wGLfSa5fT/chf TOovuCal7Yl2FBk/O+emJP7wibP3cprR6mtCoox0Dlc7hZW5WkuTVISbNpzD6UAkhFz5BM4Z6Zel rdVpIJGyXXQofyTTWES3tZrD3gg66rh6ga3ktbmMMTQj6GWAxiXmBbY83NbuquYFIKSZc8+cI/sV ibQIUSixifEAn5za89E95IWY++kcidk1FR+SDbFwWKTxSJ96ZYpXCSa3RNCJXcb46dSfnur7QB/l 1T+c2NB6ucSDdu93lZlI5sWLDHmCeIAs7cTUwSdc70KMHLzlsWIhqwMmLIS05yBpFyICli7kop+Y mODa3r7e3ndnHONhpCQ04vzM7t7d2iqECeI7E6iQBMshoSAtGZ8Y51puyiuPO1I5bcaNhYwWZLHA m5oDFRLva37Fvby9o12TdhHsB7d5JDxN5YN/O4bGoY9S1c2d0sfJC0R8lqxqLiQSXWZJ6Ovr0z7S nslJibKIlKnmGjSPaEMSIrLOoaH9M1k8I0kozTYaa6ly35OadRT0r/R7qaNNckmoH24J5GfnZ7nS cw/qbbRhCT887GgtUBTQyPnZNZAsVeBrIA81WpIbL9u5sYgzjMYSTy5rvePbgt36mi3bK31/EV51 drreHE4rL87byGy/ZOrq0OSgK6hrqV9vLfHJXPglXjsqvms4pVaG+VkMKbwWeFXGpcwLbDHMNtDv 5gW2gQZj5U1R+wZ1eVASuHKDZ92hOlikeVlgUUtIQHKRSgLRjk4CMSOLpEGAXCOIHsTSrtIP4hTi BZF1uFxDDp74+onBeweJGUi8H3y2qRnpgSQbRA9CoCH0osRTXqg99OmHRr8v8YQIJsQdL752URNZ cDuiSIso07uL8IOnvnUKSSWXW37w44OSjeuZ87xcJK39/DzyE9dKM+7xOcgkqeqdIttRmGQU3Ijo QZyhKm4BE4NsQDRn4jvz06EvHqKnEy9PHP3i0d7bey9NXuJCzmtLCDN08LGDyEP0UdWIGCNrH099 9dSuvl1IVAguVI4rFlGwkXLoC0jyhTOoGjWLCCsZciR/ykDUsZ3i/ZyuHEl8nSB2pAYEDexR1AAi yYmR/16UnKKJpfWL9OOCyCHxQIARA4nPdbG3XcKcD/JZxAPpbFc/u5RNqc+rCXVRh5vJ2+4U7Kgy NlXBuiXES4ycknyO91IjldhBaeGakj3+c61IiyVgXr8ookYcJSH4rGWuyMnikbmbkmTl07jo0lig WkXWwcpHo0p2dLAN02kc1HYt6WMzlWScT9UGKJ5+zVRhZdYPAbMBWj/sV+HO3sKg0o6+gFRWUD54 D8FeQKIIC1KTdBAapIs4zqzQCDq8PkSyefwQK3poEbQQdif6J+s98gQxFUc+PzL6jVFEKM2GDR/D SVZNBAhiA/Ial8Tyj4xcevkSOzPdxqX5w92mTaojluBz59XShVtDtFAJbMr5sy7ZpzsQdyBaJl+e JBM7+TRoP/EGkTbO/dk5dHlk7TjxpycItwNrRdBCKBx6BF1EVcgrWOwiriEJIfqo/7BiQmxDslUQ 1XDs2THCIyGvEG+Q89xlZm4G+Qbph5xl9JEcIJxXOwz6CJdDly+9cYkGw7dzhrZxaxYtLqELFycE B17mklCMRfqWLtoP1dSASsE209tP1A9Wq1j5lgT7m8jSIiweoeSihhFaG4qDukzDhqV/krkh/mgq 2UfWS5LyCTKAfPWFGMp5q5063l6xuUnRZqhovJKeKRimxIYsenclKkr97NbBt64lrx0X7mGpczg8 jI2nblPTeIcQ2C3pygorKbZ243KoK+zqVrzcvMC2zqj6fafbE7PCkS+dhFmEDx5/TjJ9suQTTgYp QbkcCbLiNk+a25w/4S0EC7eJkfXbHZJFdXZWoi3v7Eb6QQ8lCVArNQI3e+DcK37wgUHoIqQo4g8R LdpfHnK8R84R3BQHb2qYeXsGQQESiJrRZMGoh5G4+OpF+qKEBIkvaC3EEns7pZp73tuDJHfptUtI aQhG5JxHmcV5JCRWRzgqUVF9oE/DQAdMaCECCkQRTBWwINOErdvMW9JZCmgfp96e4k/JPqZ9VCmk 0o42LQiFJA9BcUYqeLrQ3dNNG6bemkIQDF3QDI71Du9XFfDB/Pmm7hBtOY1x7K5fiVNJzs+IvohT zHp4VrfwMVPKRAgrR1+pe7NM5h0dIfNaXgumty9wY95XLuGEKJLnh2IDlBzHk8S/kasaxmGivVBu MpGyEZZbH5OmhSgvVpVjrmQj5OeYsx7L83CJPL2SOewfgRDXh3DkHZ1rHxupHh5FBqge9bsYovb7 OiBgDNA6gL5Ktwy7Usl2Xq2SzWrkcyPY+QYjX7Q8kkrirWlNXEWeB//u1gZFAS3CSq9RbRBBYEoQ nt58/U3kD2GAEv2O7gIphsvYm1NvQhdJmvdvellKWR/NXxh7PAl37QLrIVppzfA6AZaem0TEUcc0 Ggz1gi0RnBY8E2fEGBYx6Cahu8k2Tw1INtgYkWFePNe+foq+wwBxoV/PHANEFyBv4HhISo8ICIvj 5QBMKTukkRiDa0vOPy1clM/DEA0V7dWOcKCVoxJyaNMFrqIN8ECDnxgMxRc15lAmQ3JcEGXHRfxj jfQykNOL+TY0F0+oWF58xzo6sXTWekRlsENcyTbIvrk1j0COr2IoEwYo720X4dkkJ0QLc05Ji56J a9bZTnvU7J3xZZQZAug3nh7GXfMKtwaHdapFqTidw6ifZA4HOb5sDi91SgMdFYJYOr2BrmtjzWFj gNZp9rXmtsYAtQbHDVJLbANUbBIrNNJJYEeEE3pf77679mHHw9KONV+4BIMb8VRy6dY5Lznbv3QE zgNLmlh5TwFVeGMDhGXxo194FF6HFxbGOpzsv7N/9Luj4mj2A1G66S4wxJIZPjDMTYcfGaZ+rIbR zYW7I2OhuaN5WBHB7tDmA586gBaPk5yRVPBfOdr97m5JWf/8OTHf/tQQQZMRmKB2aA/mz2oDNPnq ZLgj7UfnhdxDbWI0cJskMeVXdHa9Pb3gcPB3Doo51L178aTz/cqur1BE9P3uvXdDI5EpljKDBwal Cw8PcyG8l7I+EGayKjitR/mhdrhY1DomIyhBqJwFMrWryFrLFvfWkpkLM4gOuYo11X+6M5hEaNoK xKyMecQmX3FzeObiEslShAykuEVWQZ53CXFrcrWU2ow7rqheHKASvqdg76V2eDoKgSSQEXHE1WYX fcL+Jz+HXQSpenM4UJup+5iDCCknncAuABVSjgbv8VRfMFMDOrefWZeQVKWPszFAG2TtW14zShkg ywW2PDBX5armvcBQwbD6IiiICfPl6YEPO7Pc7IGySQjkW3x4WdZvmBLeKUgbOW5AjJq/M4q6Shb1 y7PIQFgKq1k0N4Jr0Z+wROaVrgnkKYPYBNcS3OmpHMsbVG9otXa/bze/UlXwNVNXL3GhulPStsct 5SSaO7yl+Ek9sDiwbka4QThTDyxpyVvT4mt2S4/aII//aHzXu3fRHrF2+ssLnOdNrZjor7OvzyIf IOXoCoQRD23Ye/9epBCxTJqdwRw7OL5Rhj5COKFc447gkzY48fnSXiP6IHIpgOAGAg28wBrPkpBR tZ6vk7/cGblv+nV0FZ4YycWmnmLhYKgTT7ecHBlrylL/u8TJSCtofN5bXpdJq2vpjL0KQC6/Sh4H oW+LkqWrMoQ74vsWgIidFUaHMViWDHX5U2fNryz1AjMBaM3Hof4NmxeAWttonL/wnIdlaabaZoJe LFKm4Ojh71s4X6+eZtpQry/NXFsSx6XQNkQlDJXQtS2ahKQBqo1i3ii3UbnW09Vjtpb1MGT1BUOf ux6ptE2EYB+NKclplcZh0nV65UeIpYQ/WlVMdLezeFo6h4P0owrKTQ+Re/y9G3wcB+h7p/HMWPmE WlINFgdoSXCFwqVxgK5fXl121VZCAK8xPKea7FEzkRIXKVPP/6hwvl49zbShXneauTaj7NeKCm3D LvvQY4dWIv1Qq9iLYCBCQrHICyyYQai9hUk/DWamaprUKVqBEvvoglWKPxOSRi3R7gpdDwPNP/Q1 2MypiZX6o/k0rk0+PFuxmJ/DzkqaQ2dv+CImUJrpdlMfkdFkbP5lz+YmGlWzAdpEg9Wipja330Xx hAVPs7eM62zme7P1rqhciaHAStpWwK1YP6m7Dv/+4RU1OrmYNVsWCRcnRvfKLOfi8URmrujYOMYQ Len1KlUi2c1c3Brqb9LKSnVb6IuBXRNLxZ/IPcGHS4bGpVxQi5+MkUpzz9oq9Xrdq1VJ1M9eNZnm jAr3W+bQIY4+4f+Ct8SW6eVW7Yh5gW3Vka3fr6ZjvTTDi/jbxHU2831NUC9p/0ra1jQX1cLOZVbW sh3zEsaohc3ahFUhr0A80PCMx1ziqxXzQ8EXD14nt3gni3hGBi0Fo4Qv3ISgtaTJXoJHlN9IKT5a 0rUwnXKuhbYtaRW8q12PMUCrjbDVbwgsF4GW8gf2UtbE4BqPx+cU07jMiWVV4Ic4KRq0LNm23FHc eNe1dF4trXtN0KiZClfc1HrTfqmPQ8bbK2qij/scMUBiLJgkqFkaOFZ6zREwBmjNIbcbbnsE8KIn EjcBAvgkpFARD7zb+JXPJqESs9+GoReph0jf6r1PxCa9O4ErT33jlMZVanAQd5ugR022ZOMX0whM pfZVNB5NmaoaN35HltdC/C6ZBjr3mAlx9M5Q4YmvLW3Ep96Q2KENDianzj28U/XWfDKvaExjCpPy zNLl9VSvon5mLz2NK6ExGvien7Q9Ho36TxyPCUFWj/3xMTGoj4+CJZCRsisZrzW+tpQBquAbhnU0 n+okZsc6IsBA2LHFEFDvX43QwxeiXUsHf5b2ksiK/PrCSy+EU9d+dq0eCDjrEWiALLONUeIu3Jcy GjJA7u6WeVz9r12rW/nYn41RZvizroVb6wA3PYBOvzfAYct0nex7DKiEI3JzD1aMPMe53h144MDB 3zvYZJcJoDXymZHGhQkPBp1GGVLZcHe+S6gqp9IlSFjda3/2C2JSILA22ZJ6xWgecz7+lQdBHzo+ lRfUZ4FPpkGxnjen3+QnnjIK06T4USUoPBl7yNITPqnz2k/rPlAr7Eu9y9dxhdrUt1Y5Rz/5RyQ5 gpiYF9imHlNr/IZHYKGCtzxvVRYGwjOee+YcVpNsdvGiJxyRhFx6Xy+RqXe9a5fELnI7TraV/Kqc EHwPO1cNYsSfZHXlJyJJ6p+EeiKfa36fqnGNE6KeRUXuPjNDAEmiKxEfcuJHE4RoUuA4o3t6YuqM PDwiy+RWpPTVvsob6qoV82b3S2p64hPtk7mHMAQ3w0TiOpkAs7PMHKE6vnho5NMjTAOifGmVTDwK 6PyBtjnznTOavZg5g7BOvC5mnZ+Z3zsjSfFyh8tBy7n2G8QdjOClTL9Lr1wCcJLPULlerlMu3PTY nxxjYuuF8aFtJkpZoK/kMbk8q/HfgwEy3aGM1pCfwFFKOKL4AAUHogyX8PTRU0+LLjhYLs+SWJCb 8hOCDgskUdBCe9rbfYpDOZOk6iu2uemRsYJrioDZAK0p3HYzQ0BflOwReTXz3ic4pJoXHPvKMd7F bEF4iRM3UuIJvXLxoU89hGcZv/Ja33fPvunpad7yPT09yEyEn+YLi8fo90SJRtZ6RKgTf3JCsp69 NE7GeyI5ZZYNzVfl7s4duTtrGEuXLEvt7eQwOfj4Qb5znoRu+POzFJHZnq0zrbIX+habt7NvzzL3 vJTcJpop1nX+SSqbKzOi63niGNldGHqJ81mr3X3P3cw3Zs7QJ4cQj5hg/IQiiSmqwjceowgKu/t3 Ux49ETn+Yr0YhjIqgkBk8jnzzgxXTUw66YrZeLXGbFfx/cjjRzSIKCI+8tnRLx3NyS5cSBh31Gfk B2SiqrREUmTCmR5/8jiB44lEioBCbHpS+/EonfjqCdIb5yewhvl2EaWh/YAiRoOqRh6XZEFnnjnD /J+7OicyIiF/vnSEVhG2Po4Zqz2KvcDMBmgTPSylNkCmAttAI7hKlKlVu44IxC9QNsFsK2kMCdqE XXcHu2qm4IXxCyS6ly8TF8bOjMHA668ITyw8BGqSn9h/vy1CDJ+8yqmN7TXfya3G95iKp37uy+Ws c2F+U+bw7xwWBnjqErQQb3Pyx1GMC6lf20N5rl1HuOzWLURAVWDh2H/ffsYa/oMzlya9LiyMOLEw CJvO9ONXtFfaDMgbAv0xSVSvhECg6iQCQPR/qF/ZFH7lz9BszqA8ChM73L333b2kF9Q5RsOkWLU6 9oMxQolSHvUr01v1tvEh+sp35sjrh6H6U99+ip+43f779/NFhSehNj8zTPx3vYotBI2Ma6C8TmnN iqgHjCCEqHTk9w7znUp4BLRrEnmrUkHJRQFaCAKhNnYsovyK/lEnLWzhkDVT1QZasTZVU1TzJS9A U4FtqoGzxm5mBNoqyBa83FlUIHU0cT0bx85OSZzJESLWSIaNHR0sCae+c0ptd9iqsvEdemBIt++a c0qOtgp7dzbrrAHsp49//TgB+tguB5h8BitXkgVA7v7SC7zlj371KOeQriiP3m3s6TG0cmQFYbNL e8QW+/VpdvxBMbGZcbe2ewRgehh9hA+EDInK43Rb1ZtceB7Ng+YUT0gAMDqIGkwPlZshh+B+mCS+ pGQZ8QomJiScInOv744+Yiapfio4T3kGyIViOvj5g5I/ePLipdcvaaKb/rv6SWNMEgm+77lrD1wL 5cefHWdyMqW5aRg5KE+kGQhO1FvqgaUTO+Rv9g1bqGiyPw7CHzRggPo/0A8U0p5XLiJOUZ7sftRJ H+k7KQU5o9GMkAUBhPbEOr4iA4SEZHGANsuTZl5gm2WkrJ1bCIGFCrKFpHdNcorJ8uOyPOqhucQ5 eO2yB0XJxS5c5SQInrkrcyweygBRUqxXcNjmjX+L2DUf+cIR2aN/+zSSkOY10yO2AeK73P3DmQRw CFgnvnKCZUxe+m0VkbcWxPhjrjZXm6+x595CA7Ddu4IAweiHLHuZeM0uRoDKK4Q15/P0d06PPCZM CVotdKxIKohEYi/lJG+ysqh40cfxvj7mHvrTg184yERNZ3WwAXITG9Ut00+TCeqBehdhffTro/JE 3CTmxmjTuJ3Mulpl5q00JD1WSsjiao6DmBUmtj4+IfwSzZucnFTxa+qtqQY2QO2d7UBBe0IAd77Q jBNPnCBklKYR3HPPHskqeHlWMs0hUUWpjtWqKR8JesXe+9t9gq5V/80GaK2QtvsYAuG1WJZ/Kg40 ogyQHkMHhsQkE7vpOyTnItYVvIXJQHTsq2LiMz0zrUsRPD8LA968bJof+vRDg/sHWbdiyGMGqDRG NhtclhxkJv6JD9oPX4Cg4lPSu943oOKXHVsDgSBhK/eTCWbjlnOVaVA/MStm52cxspGFv6sbUZvQ CcxJSA5VnCEpYWTDxKMM82fw44NMFXzXsSsKWKU2QG5ix3yMTkWEIcR3LledFLK7Tj+kKMR7PMVC VSqmQBFxR8p7riXY9LhmczuZzK9NkUoZRgpr6wYMUDqgkdSC2yOiv3KuHJiEUwN/4hPA0xErkYsM kE9jvDUmylbvhWWD3+gjjHpyozfR2rfGCCxU5mvzmTB9nLk6702L4u9r3DC73TZAAGvl2IiNHssZ OEhHCPFd3AZX2Z+u2IZS4Jss1uSgySNW9d0Ml+BqEPOsnIedQv5b41BSlgy1yUHMFSvNBm9u8MsD 064yBNYEAYx4ckGKnVmPv3f8fU2aYzfZVgjkpB/6HgJL6vfVln78HZsAvdjUJi6qWyQIefkSUEe5 jGBNpxtaSXvs2pUjYDZAK8fQajAEDAFDwBDYjgggFUHHmg3QJh17swHapANnzTYEDAFDwBBYPwQc 6+Oj/hgDtH7jsJI7GwO0EvTsWkPAEDAEDIFtiUAIK4rldZQRTDSA+eDV2xKfzdBpY4A2wyhZGw0B Q8AQMAQ2IAIaMiBmgIjz7gIU2bHxETAGaOOPkbXQEDAEDAFDYCMiQOQh8bGPGCAfGWgjNtbalEfA GCCbE4aAIWAIGAKGwHIQKNoA+chAy6nMrllrBIwBWmvE7X6GgCFgCBgCWwQBDRppDNDmHE5jgDbn uFmrDQFDwBAwBNYbAZ9hJrIBMgZovcdkCfc3BmgJYFlRQ8AQMAQMAUMgINC5o/NaLU1IzHmzAdpE 08MYoE00WNZUQ8AQMAQMgQ2EQCaNmiZW+5m5gG2gAWrcFGOANs1QWUMNAUPAEDAENhYCkfWPWgK1 t7f7FK0bq6HWmhIEjAGyaWEIGAKGgCFgCCwLgVwMaK0jSiy/rErtojVCwBigNQLabmMIGAKGgCGw xRBob2uXHsWRoNuqW6yPW7g7xgBt4cG1rhkChoAhYAisIgJFGyAiA63i/azqliJgDFBL4bTKDAFD wBAwBLYPAgUbIHGMt2OTIGAM0CYZKGumIWAIGAKGwAZDoL3aLqlPI0sgY4A22BA1ao4xQJtosKyp hoAhYAgYAhsIgY5qh0g8ZgO0gcZkCU0xBmgJYFlRQ8AQMAQMAUMgICB5MDiMAdqcc8IYoM05btZq Q8AQMAQMgQ2CQMQAdezosDhAG2RYFm2GMUCLQmQFDAFDwBAwBAyB+gjEDFClZmZAm2WuGAO0WUbK 2mkIGAKGgCGwsRCoVpzPl9kAbaxhabY1xgA1i5SVMwQMAUPAEDAEPAKO9SnaAGEPZJ7wm2WSGAO0 WUbK2mkIGAKGgCGwYRBQ1kePbDQgU4FtmEFapCHGAG2WkbJ2GgKGgCFgCGwsBDo6OmpXa3kvsFg2 2ljttdZkEDAGyCaEIWAIGAKGgCGwHATab2gXLVjOBsiSoS4Hy3W4xhigdQDdbmkIGAKGgCGwBRC4 9rNr0otsTnizAdosI2sM0GYZKWunIWAIGAKGwMZCAAZIGhQzQNWqxQHaWINUvzXGAG2WkbJ2GgKG wJZCwExlt8BwwgCJJ3zMALVVhBYyLdhmGF1jgDbDKFkbDQFDYDMjACVQZAVMUbKZh9S3vWgD1F6J OKEt0MMt3QVjgLb08FrnDAFDYP0QQOiZvzI/e3l2fn5+5srM7Owsf65fc+zOrUegaAN0reKsguzY DAgYA7QZRsnaaAgYApsNAZF+5udDqvD2NiEG+BMxyJRfm20w67a3aAPkGaAt08Mt3RFjgLb08Frn DIFSBAoGCrYkt3amIPpw5JyD5BYOeeGBzEakRYiv19TV+1arzgAosgEyBqhFA7sW1RgDtBYo2z0M gY2FQCFQm9mjtHCAvMUPi2I2QLDcIkEeHqiFd9zOVa3X1NX78ilasGigjQHaRLPRGKBNNFjWVEOg NQhATrAAY5uin+a12xpYk1oIDXxtQQxB5DNLD6RUQVtl9orJQMsFfoGU66JMDNNY+Lb1OIq5wIwB Wo9xWOY9jQFaJnB2mSGwSRFA/+IlnmTbypn1Wj82KYaNmz1Xm1MaIOMQBNrKCQVmyLRgyx3++avR jHWQqsXVcutb8XURA9RZ7bQdxYoBXaMKjAFaI6DtNobARkDAm+VmA9eyKkNasKhshBZuljboijv9 1nT4J9i6A7nHM0DOIUi/K/cTf9dle7P0d+O0UyR40m8lkAaxsjTWwBo0W8Tc6IESTshE2zXAvRW3 MAaoFShaHYbAZkAgY5sSW6i472lOx83Ql7Vo44JoqVARIuKoK7u/KednZ2dmZ+bm5/SMMj0AyEl1 dFefr/QzWRFFNlI3aYe5MhniHu8Ov66vRd826z1UyswQaRH74n9dw84RBVEGNJcLbA0bYLdaCQLG AK0EPbvWENhMCLA2p7YphQ00J8wyV4cTBx8O5J5rV6+hz+LMtdo1xJ3py9PK+vCndz6KeB2wVYmH 5VClnBjt8F35IQpQCWSBCj18KqUkTvJGC9V7qhYqc1fdcAQTq3gau+9rrAgr2gCtl1faZnoTbZi2 GgO0YYbCGmIItA4BXU2VYNAFlU8W3bxtSs4qBR7IVl/n2iNEjjMuEWefgBIL8JW5/HmYnmqiBHHS D+UDzoq5ykbxp5RxZ4qeYjJmFi/RzVglxpjGYQ4rhebhRdyMJ3BCaq4lkZZODx16N3la9xxbTauL gDFAq4uv1W4IrB4C4ghzRbQnsdTCagFFoQoaVms++c4ZipXapuQ3024PnTEyXb0ObIyai1t2UA0c j/5a/smC1+akH5WB3JGz/kkxj0iLDDOEXFqgMbjdGjMZ6zYUbr7lHOKUZvNz2E1jP4evCoUZ1Iil BBsdma+JMjGWnFajdz4O0I6qfIltgNyEsWNTIGAM0KYYJmukIZBHQMxQLs+IjsYtDyoDcVIoiuQo hiTJ2KYkm+nAUsjioZa8TiOjtilbnhMq2bKLYqOGeUfjT8AMOi+RgWB0lO8psD7yq6aIyh1h4SxG DNoGhrQi6FyeZsYyjaffmFYNLCfjORyg81NXxU01sUpc7XKwM3hKGnkxaHXCTuq08RbQZgO0Od/Q xgBtznGzVm9LBAJXgYpEjSECM4EwpDYrfj+qtimJvS38RNEvyW+mo4g1Ypvi/snFroawk95KeCtz loaQCXEBXCf5VbDFRcvt7DOfSEUa/s7JRt4UN2J9FuV7PKqh5mQEi0Yt2B5tbb88piuCTkytATti EEnTwsRWuOYWnN3PYmZVFNbAS3H4Jb5L+pErs6ukF/MW0MYAbc4XhDFAm3PcrNXbEoHAVaDYCvxE uh67t7CeR+Lx/9grJ1YpdfmJxGbFg6qx+6JNrRJCWwNy8eq6PH1tXoya1bRZrJudn5d2ELEjSDmh y6DauaOTf4LqDvlHuJdggJJjfYINUIpY1lQlN3beqMVZBQXk+b6F/fJEtkO4rEOz6TTmU6CutgO7 fHfglBJsXmSPaLZgXOUhdcO6WlrF7MPS0dGxZR6WrfHIN+iFMUBbfoitg1sNAdnOwlMsOB0N/krR d906pzqdSI2S53sCb+FsUDKsjxoxZGMFbQFdmFhHvTENzaC4BZpBv3N+6rUplq70VxbogAPLscYw DGfc15xvV3om+LrXsR+K25DhjfAgixi4rUkCASOzNhkChSL+1Cc2mJYH43GFt5RmK4ZZSmFMIF0t OT43MbaB7nLLvFKNAdoyQ2kd2VIIoOSCk5h6Y0oi0GR1NLIuO+8kL+uop5LmZWyT77LrjSIOe9uU xAspz0/kIhRTG6FN1DspxwNtZhKIxW9uVhQuKW4JzRDPG7GmUrlHD4dAdUfV2zgHVixBxhMSAdvY 1idhfeSOMdURtUHbAxEV7IfUOywgv6m5BOYtEmeYwymqztlQ/afCcAgUOoGrMrFT46rYpS5xpvMS UjCrKvqC6VXJ+VBby0mgog2QhNSKp9CWei1ttc4YA7TVRtT6s9kRYNmAihDVjOMq+MQqQty4Etfo nPWPXwxQFmCTi4loxFXU5ScCx6A2LjmWwr2+Yx4i2ANt3vVYGKw6/lypXY6zeeqodqQxfpzEE9Qo MQO0OLYB1ZhVSqSfGHNux5hmnJuyPNCmm9LME53DSu3oHOZM7O2VGw5RL7oJzKfovBzypYZrAQ21 DcoMXzTEqc1QwtBobS2bw8HMrsAAqf7Ojo2PgDFAG3+MrIXbBQGx1rw8y1IRb4u187xSVQwqYsGO GVMJOR+v1vo9ikCTXpiN/ZP3dXIrlr9WQ9xGPFDLFo+1HVJxLEKazAVoydnlJPF+ADnop+i7LMYx E1af+/F9ihDz2Ga5uqLXvV4YHLyVVEhJi02VokSD9wiGSa/j/mL1DCfEmVzGUDGocjEFwjTOG66F IJNh5oQQTckD4mm2RJuWhrzK8UCtUlHpI1Ztl4ei6MS3tjPc7rY8BIwBWh5udpUh0HoEir5dcg/1 xtKt7VUJTyyaAj3vfkqj8OmWtE68mZKNsgZITBYMMUpNNtCyREXGFoH52EwCULTOqVt1yuvod1QV 9WP8pDIQV2a3+PW4n9La8vZGqkaMxjT97tyXckFuPPKtn2urVSNzGDViOmNjezINsb1Qm35tmm7G w+EFiIYTuGimlk5XZwYXT2AagMgrLo3BdywZRKIEtbDz8jAmT2LRRKyFN7KqVgMBY4BWA1Wr0xBY MgLifY1vV1v1yBePnHjixImvnjjxFff5pHye+vop5SG8IWfCQ3hhKLJNyXskhYYkcY1Te5TCHj2l 7hN636/HMQ/Uqg30khEqv0BjBUtG0jfkX5rZXjFxUmMqRkR2OWKA4riukng/gbOJaYnGdj8JIZHW Fmm70qZHFldxjGn5TkzFOJJQZAnUIqhWvRoxtEqYtowaSHsdhdXWqe5NrFzfY3ud1F0x8fzyTQ/D F0I0qcl/YganxcKteabyPFAifbYQCxWm5Ug+zQaohfCualXGAK0qvFa5IdAsAmHfPP329Oi3Rke/ Mzr6Pff5rdGxp8eKdj+6/fWKEhVKYqmlkCwp53QjkkHEf5RwEo6rKPJAOb8koumcfeZsbFuKLDL+ 4vjEjybGfzTepM1pPa1QY+xU7pFo1yGcTEWESJCMzU3Egz/wEDnWx1k7pRxY/N0tZp0dTv+l2CZ2 OeWOSFHNOdYnJgYacE6KdhHzBgYl488LzjFKEz+eUOQn/nJieezR8sZC7zUzX879hDrLu48UGuB1 IDfw82pmGs8vzKePg0IaxRBaHiwNpqKX5JIHMAjWzT75Vm79EDAGaP2wtztvMwSUq5DjSklIkqBd 4kvf+/vOnT8X/nV2iX1oMWhKxmwi5idyBhPK/RQ3zbGpZtEXzG2sY04izYGVDByr0d579x7/6vHe 3t4g65x/9vy+j+0benDooQcf6unpgZVZdJwffeTRRcvEBTRKtSRjD0xYFJ9QbX3E3OStaUpKYL0s 71LPJ0uJBJGHXN9F+uEosmuRz5dvVYxwqCG0OL57fc6J4j7UTcID6d3r0QmD+wcffezR/Q/sP/O9 M+FWwL73/r0PfeKhgTsHKLAoqif+5MSpr52KizVOZZWbw2l0QYdS+mfOvsrNvfKoP8FpMRfpR7mf JLlsOtA6jYsgq/yR0JwZPslJVAJv8AtbFJelFChhgCwbxlIAXMeyxgCtI/h26y2NQKIqUtNmyW10 ZUbSVvCpLMUbU5qiSwpcmQ0cTGyBKwAFv3TlbJLYxKykGX6izPon5nVyPIcsV4EBKvUFc7/mOInx l8aPfuUo5898/wwL5+nvnN59+27OoKSLmQNiwb359puXXr+Ehu788+cpf+pbp5By0O5peg2+gwl0 xaEvHoIuGntmjJ84f+yPjrGon/pTWZK5BX8eevxQbpZQDPQklbrqBLN2PLHtDtKPF79iO6qsT1YG h9hvC+/0KJZPcEfKkRONGZ0c/vG9MixRosGpZ13EheAGaCplAsvZp8+C28lvnURb2tvXGyCihtPf Pf3m9Jt8nn3uLBIJMHLhQw8/BJtIe8ATfkgq+eNj4H/8yeOnf3AaJgmxlTL8qogd+dIRroLb0zZz XxpQnMPTs9PqnyhlXGzDcjydnVmuyypoapDDeoZrpXY/aT2JEVu9QVTSziedzfFArXv3FBkgLzS3 7hZW0yohYAzQKgFr1W57BNye2GfschH6M/Fg1ABiocJaPj/rkh9FNjokc2RBQnTQT5YK5QbS3Xmb 807iiIwPgs9XCn2BmUh/iswpOJnhh9wmWxxzCpxE7229J/70BGsk8gq81OTkJMswy+TIYyNBsyB7 /fnarTtvhf7ZdfuuoQeGoCiOfvEoayoXDh0YQi459Y1TKPUuTV06+/2zu+/Y3X1Tt8g93zgF6XXy iZN0efIvpWZW8eFHhuOZJP5cED96JL3z7c/G+InLKEqlPlkl01SRcRY54S4pExazazm7n4IxSmhh qd2VN15RHk5dipSoyEUVclJFV1eXSoqTP5m8MHFBs7+d+eaZ408cv/DihdALrh365FB3dzcjcvTL RxGyRx4eAcODjx9EuEEvhhg0/bqIOOf+7Fzf+/p23bZr3959e/r3IInC5DFkg/cLbzT6jdHhh4eh kfgutvkuanbdOYx/IhEms3O4aAsVqLWg1BMJXjseR3kutfvR4cuZVUV8T4kzYxviN2EhJAlMGmYp aI1LBn6Zp4oMUMu1bMtsmV22GALGAC2GkP1uCCwXAaQfWTYiriXvE6QxiN2KHhs3VDuqWLFcnLyo nz239SArSJnEhyi36UyZA7d2Snuze/GMT1MTsYkpn9uUqzV0d1c3iyUW2fy6/779MD1779uLyII0 xtqsOMlev6N67rlznTd1jnxmpOOmDngjJCGW8IF7Bi6+cjG2iaGejh0dyAf8yroOYnvu2jMzMzP1 +hT1dPd09767NxWtnJ146J3vY7DjcWqRgGR8l2YMR4p2QlqDxoRMDVPiCD2Bf9I4h3VsqoJ7djzK ue/pvdTuKhlHMAdkBRaZZvTro6PfHR24a4AmEZ7x5LdPIrUgGIUZyrWc2XPnHkbkwCcOgCRjgaDT +95eBM1Lr1wKHm0iTOwQ2UvwX6ghUTGUp8+cVo0bgRXQwzJ2Tc5hISYTW6t6XGOuy6kzYzJd46S8 Mf1WpNkaUE2eIg1J1hLrnxx1t9xnuuS6EhugXMCFFt7MqmopAsYAtRROq8wQSBAIK0dgbgIDkeFy KJ9sZFEinH/mvCga3ppBGoAFufDyhamfTKlkwGdsy1LPNsXfP/b5yhlMhMjRWXOKoMPyG/QcJ+Ey nFP5wd85iHX28CeGWcB29+1WOxvWXVicMPis373v6z3yhSOwCBTo7+9HgIO8mZiYQKBh3dXFb+qV KWVZqgsiPex5/x4Rg166AL0E98BKLNKP4uMOavA51YNVTZbX0WJp+4OFUMFwpOijlPPJCsFd6pIT gX6IyIl0+jdjd6ULf9SXQIfEpIUoSXFkq1TgZmB0xr43hhy55449EhPhNVE/5ZBHSB395ii5VA89 dqjz5k4uF5Pw2Vkk6V29u1Q+kMRYs/OKLT1FxqKS8efGMQli1DjNQPC5jDkcc135eR7QyVnqJEOc pzDj4YsTvIRHpqEvWPwqCqSaT7vWuteUxK0uxAGK1cGtu5XV1HoEjAFqPaZWoyHAqqPcT85OpRFP QHyU6WkMMoY+NYRlxsmvnxz+7DDLEi9TPtmgY/YRb3wznIGTTjz349BvzHnUs1wpqb+wgd57z140 F+hZuAsWuFQFQQXlAH8Q7qvUAr/2vLvn0BcOYZkLb0QxZDhUMMIb3bsXpmfq1SktCUuxp2/PgYcP sJagvsFgCO4BZiK2pVBIU2KgzOtKJ17K5TTAIcrzVY6GU1BylFj/lOX5UrNcP+LhvgVmqLRtwZIp zwO5MUXQwbsKKzGEksEHBuHV4Gb6PtA38rkRYIcW2vuAIK/XelKnowPtoTBDCxUB/849WKmji+z/ UP/QJ4aQLwc/NgjmlIccQjV54msn+BWWjiFTf0OalJnD9XsUz5nJVyZLOc6Uw8sFXlLhz4FMa2Pq K//glMIbQliVuTT6t1CBxmttlGYEIG+OlgyBF2rtJbgZEChlgK679MpFflDhaNftuzdDR7ZsG3/x i19s2b5t3Y6Rb7x9QXRGYWUKa3O6UuqpxJKXlYP1A0MKhAb9BQYIdYYKAYgXPe/qYd3ymLVV2Ojr tUE7E/QmcZ0Zs4noXuG88lKhJf713SaakTA++Q10tdLV0eWlE6f70HW38QHrENcpV2lERweCtMf9 yXqvOaHig5OyHgftXrJwpsF/leUq9sWl3YzNR0r7G66NLVdorTdSSRbRFOEwdlH9aYNV/7jofZMy nhJLCA+tp0haCG/WUY29tFQlmsJYZwByxQThaLwAVrVswjO5VFzyHaXY5ZkQlTFIMPpTvTmMMTXq Oe+iVTYWKuoF+q37FscaOrgwZsJKKRbig4qz1GB8UXgFVY0wlByxS6PGng7qxcUmb6PfMWtDrIxL AOmBBw+spM6lXnvdddct9RIrDwKIOnwGaefsM+cRxK83aAyBpSKAT9DdA3ff/VH5x6Z/0knP6hG9 1KqK5eN9My8XtrDcS/2GVl55y2tAccC7O2OLU7BTyRkxhFc8HIm45Dx/nk90Fuzd+Yc+CJ8pjpSr oP6r5bYpi3I/Dfbo6bXZDXfGDgapribKEW+Q5IxRmsEwln7yy3ZbKgxVd6Q6r1AtwlMs/fh2FvmV SJJr3u4nZ7MS8OGmGk2YZuTJiTJuSVtbt21lUadFFHD5a2MWSutxmDsDXmd9JTVLmgknqiaHiERB iKyfgDNbLD9eQQiIi2niudI5HPpYPocjuyhpZuSppxcqvGIpTwY0bKuLcXpiGCOOh6rmZubU4Ck3 ZJyR2D9ZZ0YVfWJtVDqUlXZUhBJMAe/Llhzq8pl8Ng4l0JIbWiUtQcBsgFoCo1VSgb2QdxMv6oUK wpCu2ShuMOlYOTr+heLeaJAiqFGgQ3BHwm9o5ZW3vgZ9Dza0Uwl2P7HNhOgpPjGEhQdqJnbSGK6O fHYEO+Khzwwd/PzBAw8ciPMrIfxJarCaBHkLdircVrFK7Y0Sm5h650vbSeHUJkYBKsQECslZWwFg LELlxSmxMVJ9YoJq3p8u6XWmTD27n+K4JCWpFmYrmCgJhoQS1qg8ceyfRe2rkGkSlyUdi7jludFR G3A/Om7sgi9YJeu+pPY69e1LmhJDGw1WzLrVn8NpDTEOob9JfG2dM7EfXMzZqHmQbGDcjdIuJ5PN D3FsvqaufJwpxgHKuViqWKkhlyJ75BBmSe6ogbYTmWmlczg4Y2YFvpVWa9evMgJmA7TKAG+b6vV1 c/rp0y+Mv4D/La+2sWfH5GXdJmwBkgoRjYMT05mnJYqMRhnh4Dx2tXLmWX+Gk3yPywQg8dTFxvOp bz+1//796tC7gY4FZzkRaWqKPITvcpKLKsfHYAEjx83d3Tu7229s52tnd2dPdw/WrPxjbWa/rowL NV98+SLeUql7S5ltipZs/lN8uBIlSGqb4hod2Ah/R2cmUgA/Q1EsZ2h06Y2OECLS9yJRoxS9qzKc ROCHipxEgadhmcTqCK0i3k+ovTC6wuCmelOVM6n/V8yIhDbkPL/iuETZGEXpuCcEhnpyxWRGYhAj VjiBc8JKPE5olQYbTCCqi3hMS2QRzUOcxVyt2qVMtJxn2umu16c7PR/pJfPXurFQuksnMJ9+Wjr7 7tjlMKfAzU/dOmZVeRoP2+SCU17GvS4h9uLZtZzpqtcEqBMQYqXh8qu1K1cZAbMBWmWAV1z9ZrEB kkhrJG34wRiLx/E/PY74MnZ2DIsWwqkhqXS/u/v0t04Pf2aYoHmDHx+cnpoeuHeAWCODDw4+9c2n 7r7z7o6bO/AbImDM8KeHD//+YQwzsfnlQjyosZ8VU5jsioi5AMLW2HfHqGfFGLeygkzC9iZsbsKL O2NF616jMGpYCquExIIhgX8Ce+FqxtW855aent6e1AI62XPrsqF1QsKBoVe1OAoh5oeEVFAGQjfN qpFxy4zgkviC5ViQGSckVdvIflCrtXXMs7y5khcI+fjTucSSRrQylAuf3bX5/dJaYgySpEk+e+iX s8btqD8IUImxJijwCnEf06tjBIIVTrBHcb3TGtBw0c7/f3vfHxrXlaX50uOwJVBDaXF2JTaGVLYz mwqT3pRpz44044HIOINlMtAWyRKLniHRTDfdcofplrdhYnXozsgZ6LHS4JYSthMl0I0c2GD5j2AF Jlj+I8EKpIkGEiyDQ5chAYmNQQUtcMGIZb9zz733nfejSqWyql7JPq+rK+XSe/e+991b7573ne+c s/rVKqgs8G0UfLdKlRzwJ9idAJYWZlaXO4251wCtrKwANjB2kpPzqz5/SSIn70k0mipKFQgs8Dln WR87RhJtpwSy/UazQvOZwzhjz816BfroisR/5Wblk69Wo/jzaFLP+7ty/b1dqfhjB88gMeAW0i3n sFA7kQbosPg9Ci0UDfHevC3cG53GbCtMvjI58eOJmNPNEmlu+FAlZvXz1f39+6UICfY6DyVNSNg9 QZXg5cnPE9tD6mi8MBbMaJ4aVQJtBnhyA6sNwXjv/b1+ytXXAOEhAflCMWq41/XuDY/ayZtOEKgG qDk8VQPUHG56VDoCMG4GBgcWlxbH/3Ec5gs/I868OXPm5TNHv32UxDFBACMJtgsWD3ymIGrILW9S 1DfuU4h+gvWD72EJIaM/UrTh5jL39lysMxxSKpUQNwTeqKNGIs5VSLFCjA/gtSEaxkKOJ9yOQUXs 7SN9qPek5EzCXFGLitZms0ShhUjwsIyNcqsv0hXynmTNsDDC6UXI3WO0otbnZXbwFpJd0cUDejXX db6aO7OWG36/PLlcnkPWYLincrlyNTjz7tLE5fL89Vvz1eK5jYJ5L8rPixuF/H29C0tXrpY/KTzQ m38gj/ee7lz5y7WB1xZOfx5MXAtA6EVEGaZ4uJSJxHUn3sIw88BzEnFs99hIbwALJBFIhXeYOFj5 kFdw4qUJ7I+wO8xeeh0bhr2IMDf43Sy2PpmewRwSN56ZMOiTNAOfAw2kODfSP22SDcQ6mxgn53XZ dozM3PCsj0hgE8DuBP7AauD1xdkPl+beW6iskdUG/Edfnz/5QXl6pbqwIfAXnxc2Clc3A+Dfa5DP P5Aj/POE/+Br8yc+qnj8vfWT5HhSrldqvY3BwSYFoM73EtljbUTkJMzZQEXJ9/jPACHV+rHD6n8s kIsJgRpDypJ81s7bv6ZRU1ID5AMUGmeAYP2gcTimp389DRsxcueJaoDkn+Z+O4ewBryQLivydNRR d6679WRUA3S3jnxrrhu6XTxGr36xCosHPdi7oYkn8s54rBxYYJY+XiJXjnHeX3z3Ir6BpgdRTlA3 Y2eITyGgJh7owjyKLcROFodg7Rn70ZhMAdeaC9peq7w88CZVHfwYahFI0wZhf445woueks0++AYu GM7Iwt+EbARn5TFtCl+J/SYukjBGDx6L6az8hoWKQ9BZSOsEFtxmhAEyD9Brua7Zmz0nl29NrFSn VvPlfGnxZv7cp9XFoIC/jn4jWPz7/ovPFCa7106BOnnndPDbieJn8/1fr/ZuVouVleCdqaEbi12X lyaeOUZ5/BDjthbMXgtmbgQLG/m+/qGJlWCqHBx6a2ns8tqil/oCN6PCCYeBz7OGvkfi7LkZfMBi bFF1SFo8u7vYUrEIg8H64ApeiLnD1JKB2V4DtPDeArhJOHln35xdu7EWccJ6DHkCwNGD5dm4e0I1 DKB2hISfIR5tSVfwJXsF0pXN3MzN/Mj75YlPq8CqfP/g7PVgpXfgk3ypkM8B/5WfHrv0VGF23/rE Q1XGf3BtabAP+FcY/4EvFx/5mPDnluc/zxH+nxP+1Vxh9qv8aYP/6Hvlhc2uKudn4nnr0K4/h4mn xByGcenmMKao9yf6CUwX5Uk1Qa3xxfqBkCQlH0snYx4JCFIKhzPAOvENS+xD3Y9PdiUYoAikLC2P BhuG0yzxCWVDqIK9+cngZoVHuMic9BognmBuA8kNQPj8Ec0A3/2OKufqnK/+qSEEVAPUEEy605YI 8K2HF2wfmWKfaM3BbBwgJxuKE8GyeePVN/hmB4oYiwqequGMQOwoJf27uYYMeCCQWE6ERCayd0SZ 4Ut8g+z7tKphKf23ZdyeOsHpHtFnOI6Hr10+tjLLQt+7p2fcyr3dQxcrpZTwyOwlJQq+TupRuJ2Q I+GlIpqVOM43mCWf1Sfclz83v2eMk8B+Z5bXT6/mFoJCJTAGGdRO+UJ5bz9WzZH3yoNvLc3fpK9L T/aPPhz8/jenfn9u8sz3j619sbr23vnSjcWrvxmf/OHQrSePY8U99PoiLbQfrOFYrOWT14PF62sG k6Dc2z+/0YsGF0xr5EaCytu7Y5IxVnX0PS51Hq1AzKk4DGOfPQ74Hgtr7wO9XAIC8xB5d6iEljn2 0OFDkLUheSNOtf8v+sEPXbp8CcmN/OSU5q//HMcWY+61Mow/e+WYmWOWzityRI6DSRiIX+RW8iXC n/apAnxgdfp6MHxhGfgvGsQKf1Y8/nCO8R97sgRfM/AfLVSB//T3h4Ijxzz+QN7gXwX+ZRjHpl+0 ubBZmPg0mP1SaICi8fyx+SnnMEMhiRz72VVuqTWNkxogGgs3jcOfw73uhyPCBsPp7QrHev+XhTQR CyaJPT989T/AGqaEk47pAX14+l9O8yG2xqr5UVhwzH8pRCNnIu3dz7mrq0umfW+wa92tdQgoA9Q6 bO+ulsNcMuK67ROt+YafdxG9BQsJ/BDsGPwTXBFuEDCA4FZH0SJ8TanQHwAAM0ZJREFUQIo8eMrh gEBFTGiDUG/hynIkjuzYkWOo4/hg4UHYTEg0jEYo1d5TI40/zLViYLBQE7/tly70EeUqCAFs3Tn2 v+BmSo+wpgoB3kPrR8gjiN1J06DIYJbwFuyvyrixLLvgA2GMttk+RjuVjFyb/f74wE/wnCiFR7C8 ESxW4ZIL2Qu7TpuzreYLK3v7xy+vDb++cOKF0xhZDBDeJy4slbsLvUeGoQBb/mhp8cOlLlrRg9HH B5EbeqTUW0K1MVq0ckF3r+dIiG3qLi5XyDKmKlQb60wMcKBQ/LqCAOdJqBryjLDdG8E2rOjOpcVd gXFPQlgWzZEB58+dP/cWFdhCX0gSCPYR1SHwGXYPBG2IzgPHiXMAiwkVGnRvjHpIPKTi7BIW2z0d A8RTAlDjxGgC4FgpWDEMHzNAyzery5vWRnHIh6xVZW+J8H+/PPLa/MSvZhn/kR+cPPn+SjlfLBw5 mtusAv8rHy5hBC3+B/uPF5GAG/YW2L4cRtDzUvRMsqe3vGky9Hh72sepGb6QaZ5wDmMKmDnM528D rKR6zNAtUkbGtKUfDnQVmo+OTfHBcSED5Ekp9oIJcz92q6EJ3E3TWBKxYak1DpxkzqkxEujUP55C ci9POGHKkQ30T2QDhUyS4IFgNxP1iGRdDkakdMfNjbN8WdKxFXcibXM7CKQyQJoIcTsQtnjf3SKC BrUD3xfIYU//ABjcMuAmwOMyLSHXVvAODzpWNVR4QKATxC7IfQxmGLcDVKiu/qHa09ODZLWMKHHO 6+v4E3bwKzrfKJEhEH/q+XpP6c9K2AElHnEnRW7crG4rlDDmJq3TMa4ipPG5sqbX5worx1sSkRgr Y/eAbxh+cpjalKyAn29GJY07bPHRIj/y+gdNp4G1i8TM2Znx58fjieM44trJMnyrMlkcfWlMuoXr ayc+Q32EYiCyI/bfXO57qO/KwhX0PnSgWP1yZeRgf99mZTWPNTU4Xy2ubASrX1XGNj4ZPrJ/5SaU uUEBWYyNDnTmwnx5ozr/abDafwwSIvAZoXUFRmqtPJZfO9lfSLl2r6sV55+KrV9igV4SW+83hD9r 5tczl96/hGqgqMwK5xf5CnPB0cNHYaUhuQMkQciqDJcHJjYk/BD1Q+oLHRuWQCiB8A3SE4SLsfMe es6PrUzmeAhbxPMbCzVWpFMGKMXuKDhqcunq7FpP9YGiRyn/+fLQgQK02KvXV/sQQLCn8sjDhWIV Wbl7q91d5Y31OeCPXDcbweR95UI+qBiNc6m3D7onjOnMu/MrG9W5jVLlfrQZxqubrqsITx/cLE8/ 3ktnTtYbqd35/CEBRuxh8ur4G8QkolyuOyp0B6NRm26x9k8ADz8IaLDSe0GOegChgMb9AT/8wr6C PAFvYYS4OZuGfwiwVPAbkahGMiJ29zQogsaNixNweFMVp4HiJFeXrxJLLWCE+750sGQZIyO3R3Eb UNo+x+mOLxoqgm4OUiyvsIFiiRDVAGoOzJYctVsMoJZc/G5olCsVhOuZyFxHD7jGSVfvKdMvCYmY I9RmwpJg1ScuG56EBGsGbsdYcmJrWJhbyCwAs2dnUQ/cLiQubx4oK19PPmIfuEqcst+FcuXE+7Bf yWbK7ytU9hZgCQ3uWbl0OLKuYJWdeHvx/I1g7bHBOtbeYG6lv6sy8nCxuBfBUAH01HC7YP/8lyv4 Z/ULdFQdP1AYO9DrUCXeKNwY1foP7rGFNoatkJ5AYg81D+LpkFcTzlmUC43kddwM4AVDX6jaAZU0 1EtTr0whOwNKqSMrAcz9yZ9OHvubY6HFKbxF9gzNmUf8m+ZKYpFlYd5nOX+cBmjm47WpjyEQz+W+ DvOsrwJfTHd+sm/t1GORqKLFtcrMhStXvqiuHTxWB//J+5aA56R5LKmF/1Chd/qw8e4B7W5nu9f6 Pdaew/66YM2D/whTS3NTYpgALErWSw41Mo03qygEy9PYmo+A0M8EJxuP/Ax9zFcapL6oHB7DtvXg hHJpCFCQNlMkp7m8LvMZ9wcYSaf+16kGqabm7nlqADWHm0aBNYfbXXGU1DTIC5aaie0CUavN7bbT CfvjWrB564eZBl7bwpUDnzx/IyQCqXoUEe9DFH1c38MLhsjrE9f6mMII9vnbJUGR+5BTgL0tRpNh z8HFOqHxyFmZ3IPrm1x9nVgA8x5UyivB8mJw+dyV3612vbZiX+9W73k36HkvmOkeXPsTYf1EFzle 8BarxdN/6H/kctDz2krPa8tXPq8EH8wHS/OV8jJZP6Yv/F8sZuFo4+qsTenQiAgvvNYnFjHnLR6O 53J10/h6U7Q7Amd4u8A4YjeqPwqu68gQqCCI2JCaAR9K/aUUzNmxxb4tWA/GVvPYkjMI/aahzfke kxoaqKMY/+ofkP5ymfGffK8M8IHhPW+V73kvAP6HlvPz9w/Vt35wMhNf9QP/rrfKdfA3ppGxfjBb hH0j0d5yDsur5iGUlxZqd8SUrje9nWSKaMs9t7wR7EGLDav9PjKN7TlIO2xb1g+ORzFg0GA+hSO5 UFnYLiek+MnDM45DWmr9hD8P/bRNBDQP0DYBa/vuygC1HfJtdAhym4TPbt2VXjApL4CDjFKVOG9I SOD7/DTJPuHh+mCR1bh28ZB6oH+/1XVvF3aAoAokkLyhRz7fS6svGI7jf3OcHnlF1YVIh2aFkzwQ VlvKWeL8TYvl6onLzAAZS8huLfw8fqBPMEBhRYitRRu1uJ8Ys+WqTFx8/yJcWpO/mETmhYsLF1m6 IRk1DBzyccP6GX1+lK1JpBWA5wvgjP9knKrWuypmtHgj90+Qs0ZPkhfx5xDj82o5hmxFsGBmuTz1 sclRtAP486htMXZDhTwYoHpoS6uIjZtotqSYRxheIS6XK1kfNtZ5Nk2dnSJHrQsXiLgODY0KixOV X71B5g1ZSZ6FszoxDWyoHTsiOYiSJ3lTG1hA8mcJOVdqM4jPgOcLfv+mOtnGQcoAbQMssWsqA6Qu sObAbMlRnWgAJX72VuXQEgDijUq9S1s6rNcJMhvFbsR+b7t4GKzA/1PEl6zWafajVIdQTUVXXOwv F4aYIwCHhPUmhUUVP0vOtmeWEwitsIpz4qW4Z8SLLaKRPlgYWJvFLcxfXzv5wapT6rBep2XvZm0e K/VNpGqA6qqp6mh9aumovK0Ts0qljkparvF2OL5JLLdezSMzKMZHR1gPMX+lTf3nk/gZG2hyqTyz vB382b65jTEaKuSmDxchWkc9sqQ3bRs4uyul+IYnh/xPIAnvzKszYz8Yk0ABdhkcAAOIqqUmklLa Q5KQ+tBL1krzZDYuYLaBoOMmvVdjIujYCOKHP312Gr+RyO0oanWhHiLsY1ZAtnpTA6g5hFUD1Bxu 7TuqnQYQghpsMlxzfUTyp9W5xNMPsjaTHuKXU+tfrdPTcGMbwrUQ6tWcEpBjrHAshBqgoFEbq7E+ I3vhgQxPY1Km3UQj4SGbVOXDr4jhyufTmUhLMbZGmpgm8A3HnjrG3qh0rU/iQdY+KMcqjcdqobuo Y7Z4rq5chRodql6/eMhL8OefVEn75aq6Jzf29uLyrS6K2KKthdwPWs9trk//9cDRBxAkJipCuJpc KUOWwDY9ei5NR5W0CLn9dDSiOHMMV+R8JJdWd0zrmAJhlqOg2rOnh9w9QdfAW4urt8gzKPBviMtp fLxY72zwr46WChMHKcNT8uoYsS11Y7E5BgaovsYZv2v8Fqh3l3aIiDS/mSypJ58/KadErAvv/K1P tXLWK0BqUzQ1ewuAJhoCMgTEJTXUOJPytTIMvjZwP3z6agA1N4yqAWoOtzvzKMS2fPIphXiQe752 mUCUuYAmFBDgqW57uZjRZo2a1fW1QUiH+EjxEZv20GcUTBuEWvokfI/Y4P2l/bHyVfX7rT/MlWol tH58vUyveo4pJ4QqJRQr/Huo+YinQomWto4LJmr/FedMEexClMCjKXUnES2RUw75EefcuPzORbaD amXmqcHJoeJgTzVfXQ82rR5IaoN25HNvdXXwvuD8c0cHY9aPQdVGe+FTTHIhFDaR3M1RrY/XZtHV uRxI/nMM4fq5lGhiYBFlfYw7n7imKpp5SP6m2FMWfuNH048F44/650DbeJcufn9o/PFCYaMM69Dp sXgUdmwscD6M/+zxfvSVol1LzGEpOmbTxL/H9GrWskmTpvEQkPXjpVcm6MwD67+38impJRLQpUvi xDS2gCO15jazIKbeB5AyauyHY7c2bq1+uRq57SBtxLUy/tQ26+fOXI3aclWaB6gtMO+STmCdjDw9 guJceCHdOxUK+GwZfA9ncAddgZhhvpHZC3JZVfz1IVs8zBSYGhM/mcCxSx8uIWwYdhLvAC8Mrc1I Mbe2BjYIqgvEuqN9OGiQfhfHogvIS3HrX3h/AQfiM/QZ+Of5d87jHS1jf1Thsdk1jAsJuVhAXPEZ InMdUq8i3h5VyXA4W2m8VdYqUHjwVSCNPW5Y6B3HTv3zFI5qbnysfFLmO5ExXz4piLOEZPCt5Xug 0XEJcH1YihcW0IMsMz0ytiiaCyc8c9cLZb7h9cPxT3yenPjELirR/C4RKzBqt/nesdYiQHz6qcGF F0fG+/uG9uWwWPZu3gJbQB4xyu9nZsV2PuPY3uAW2um/Lzf5eHHySAmNv/Gdwf3dOFtb5Z64nJhN Sb2YCxHXmIKtqN9useXLdw6REB+PsCgzbl0bcrZ7rE0LPJPlmVifl6wbjx0cnkmnD7cnf01Se2Q+ 2yrxaLmnWp08XPrk7Pj5HwyferzYu7nO+Ecw3+5YOPwLm+tjB/rG+4sLLwD/oUGqF+awkji7vESx K7UZB6L4hDi7a5QJytPhdQPKKXzCITYmIAFlkqFHprHLl8isT+zn4O2SSJhezqTXYtfebWz8s0JK evJZm5KuPBlw/yGuy4Vb3kYPemjLEdA8QC2H+DY7aKcL7JFHH4GNgjgX3BoQ6okPMBf+7rm/g3UC TzZyD6ISO7IzI9Ma8hPiEQcf4F5BMkN/jfgGmeKQLw6MN24B8FjB1oHHCvmdS4+VkPtn7v/MgYZB Wg6sH32FPkQd0w6rq6jHdP5tqh6PHNDnL5zHPugdaU7gtMKxEBJiNwh+4W5DDQ3kgL70r5dgGx09 dhTN4p9kHn2wiFsSiCK45xAZjqOgDqYSY2aDKQZGGvQPvkR1HuyMdNJ07I0yrhqtNTFMuOvBdIto h6OrhV/P4johFyQCeTKCjOy9spYuJCoLDaUSwu/j/SmUj45zu5mbO3uCwOrhIdVWqeSHbFFSWy4n Eb9MLCuxydpH3joWkOaRvTCPYxc/K19drcj6mvh85l2MBWV2lu/IFVTo7YnuGRw/XMKCBksob5YT q6lyCmVZtDKpRJHXWF+BK4+t43tK1wkxQAZtv2yTlZn0uzmfV2R/Yb/G2/dtSgvMMEPOiQPMKcEg X50swGlt9s1g9vKKryzL2JbX1hc+XkniP1AslL7R10W5EG0lWiB/rB9pe8jSyhNN6Cq/xnU/MLNc RVgnweFriSmdQ0wS2jKqk4q6xUmbIzGN4ZlKKp3R3dQvXJx8Wp2vcBon3Jcx2CnrutcAibxWTdwB /CFeEw3rB3eVSEXY22m34WPVBdYwVJEdVQPUHG7tO6rNBpBnTfAbhlnABtClDy4N/sXgg/seROFx fHn0iaMwJsgAGjwEge3vy78PDaDBQ7i/oA485EFQLHJpMOSLe+PNN0afHUXqlIULCzgEiZ7ZqILB hDsjTChYNugLf0JajmqlijUbGiPIAmAfwOSCmYLTmHtz7vizx4naubaCL2Ek7T+wH2QVVk1YZtgf CXxhACFnK1qD1wx6I5TX8OfG9erRFxYSGHMI4UF0Dx27j+wk5FHc7qDC6rIONX9bF5yEXwXrrNNg oWDbhUKr2kJO/4DrsxpG2ncWD6lSfNYWtoE2b6EeAjRAdFOW7Seqc1hHQ0xdJOLUqNwSQrsNTL29 UI/6cLA4crw8c6wRb/jMr/obl8uV51lToyqupVa+bG+bpmLFZ5Kq9XHnTNxb8tgwuzTvJ2xNG+bt vxdLtbVpPJ5bjTVL402uJrI/CHNRgbwOjDjjShr++C6fOIyN+Pg1yt22wjneZA07Hn5zyiAQ42kE UN7E7OvusxNFio02b2HmIwrMAx4OnITUnY03IuOnh8IyeZudmYu1bTEjG/sz7gNQTCJPI24jXOqu zZsaQM0Brhqg5nC7M48CUQzTAblWIW2+OE8OI96YdiYJheMP7B+cJoD/SYQzbtm9xjVgNuRgRb5m /0+0j0a4Gg7fzW3eZ1PEx9YR25NDZh14pmAkgQqyx7q1nHrhakomzTTlAKTFuBfudthMtlNTngls U7reyByLuHSEX/Gx4LpgqPmTbOiDFytgb75Nu9w/MeWEzwwUT1LCaglogFw1q5hmwgoakjXkkVgW upwaqVMwBNRjNAvOlnqXSGtRPQprgFg8gQ3zwF5pTeuHLAYMLV5594E+U4WytI1tRzuv3OdERiW/ TzJHTsj9xBQ/MT1KFEmv+EnV+sixiI0LjZrIze1VL35808fRjVfq2NURr5j2iX0Jk81sNUGBcwr+ adaP/TX5OcwONTEi4ITs9abVoYtbe7E5KVhGz5zFp2JMymakUSx7smalSNrEv/qYVCv5DX71dh+j /gmHw/SFsC+ewDh5Lg+8Ixue+uDTB8WVifWzI5dwdzaiGqC7c9zTrxr3DjwS0YbsqCL+CywOHs2p jrG5B9XSAHE1Bv6r1Mf4ztA+1gnWBsJHhvxyoGT4JsUOft7wp/Vb66g/QBW+zAZeh/6DNczcInlP tAP2CB8gDAIn5Hf23YXnab4qPUocD6dHg9GDysx87OrN1aNPHt3ePDA42Buo9wX44tKp2pRE8SO0 QJYla7r5uVmEwNg1I6b4FvoVRjiuLAFAG1VcI1pGbpujR46CJ4Mpibsz2DK8wJ/51cgjLx+mLQ7u Od6H5OR7nS9mi/JJNVieWsHGXs3D/JBTL7FiifEJdTZeBy11V+ydkYqfWPV4fy1SUxXNycRIhnPA j2BsXJhs4InK4y56t4dLfZXzZ3lUJQ9kI959yU/eyZ4tWfkUBy5j32phuL25G9nbUiDhHI7pq6xG zSLspDOhnsw35memmJMoJALaZuaVGbxD1Uefz87Ak1X5iqxqP4Fj0x5/wvOJM7htCijsQ0HysdL0 fCuICtr8Lcg/ilinJwRPyPqTs49zWyeU2iaquGuieNw2D9LdM0ZAq8FnPACd1j2zJl5OiNhpWEJY QcGX2MRfzMHwFmWA+BvZQkSWaO6MuJPCFwPl4InnT+CBCYocKq5I1aMsr4M24ERH4UCs1nBp4Y9Y 0ckgy+WweMPX7veE3hmsD9xqeOqC7gdrfAzMGAPEngs0C1E26h7A48bHjn5nFDxQ8wPhbsGWAyBF RYiMV//EWBnuLhmX5G/Wnhnakr+Jc0XGMQcbCAsMKomyo5BfPmRXtolYthgDwZokikLC0oJy1jky iWVWm2YEnt5LWBdosimjPpcYo+aJAUYvnVczNq5kMmJ8j7U8nDvG/tV7uxyXGSEbBJ9Bwq8Nk805 eg71uZ+tOacI95bjLDjhNW7pPqwRX7nlxA7tb7LnbLRg6hyOoW1blhxeNMgLnmtU/UOsOF5wefMH ELdXb1z1N5lUWPAlaGDMXg+yH9A4A2SIPX75NkGzhb42kxCLa5diBx//1cwc3hJK3WG3IaCZoDt9 xNqpAUJV0UJvISY1APeDSknI6MW5jGFqgG4hgfMDBSiUsUz68qWAEt/gmZK0z1+u4fYHlQ8WY+iK qAj8/b1QIuNw3KoQJoqFDRQOrJaLFy5CqQMhM6KxwkqoHy7hS4gG0CDuXHTsR0vQsvQfpKxiOBMY SfjA5wbfGQm3zfewnLgv6vfaijw37ADTBzwWdqY6rJ+XIYX2xzY3D2wmaD5YSBbon3VzpfAR5948 N/T0ED2FO9+iXJtTA1usEqKB/SGXphzHL0/6PCVQf2NNhfjJn21Yxsisvqw7IaOTU/Ry2lzW9rL2 2VwXGmzR+hHKqiSeifi10PJIyz5sFznXAo+LtSzr508S4yjtsFo5gbCwxuLAI30lVFaEtmSeaotX SG+ed3rzNmPurDoea2txNohzVPsM3Q+m6+hzo/gJs62P8nZoE8RkqRSSJXF4Y+nRzfDZOexcz+FP w3+DSeuSC/gJT4MuMh96ug4XBUbTstTN/fI77CjVADU3IJoJujnc2ndUOw0gXFXEP9L4VXo/hV91 5Foi2qFnuxurCLwC9TLw+MCZl8/ADIIGWfa7xTnIvuQZ1jqHWvs0fnV194SpZ22daOyStBsiagmB DNxwUHkb70sY6x5yHrH12KwuVBLyu66yKXMYbpWyp+nWezQO6xAeBzKwzD54/sYHsF/hOs1+tKhv KPQ6cYvCx8fBww2qcbcBsBg7xlNak9L2iuXfC8+N9SsJC6aO3RM/vaSdFLWWkjjT4or/cSkok+Mq 9HDJcXEtS98Z9c5lpEwQNc95WFSh71jEnGNfIilb4AJjECgThGAupVUX5heQMW5b4cxYwdyZfGUS GTGogro5+bl35gATOGAqrBaDNzYeseFw2dKJMPZKau+LdA44btNPWomYTJSAEFQ8Am1jfnb8rmoA NTdEqVFgX2uuLT3qDkCgyacieWuu9dmgg/bBD8HiIbVgNQBLwVmCZL9bnEN9NQmPQSP77NBo8crE loFXroSqFK6+yYqWhDaFv4kkKWEdlZQYC0WRlU3E9CtOd8VrKl27of25R5BAQBiyKryvXF+xPZr2 uQ5ARIoh1EjynMPPeHTOt2DlEONlVyZnddFV+AzOXnPjlDeMeYiw46j8EhhRSjWg+6klTLH6tui4 UC1cRFGtgW2sED/KkhRnCcXEKGTfwMLpRv4AWsLp1U3f0Jd785hFeOfcQknkSZDXMusHPfbmjQtY Yu60R7EMDsk5zEclbWj+BvtDQYgsDOCD8UKAJw9oaJi6QeEfgv9RsmnI09i6aI3j3btr7U3DT2Bn yoc/fxaKuZ+eN6PxDQzNHfr1azO7GwHVAO3u8evws49pgOwKbVQ+qJB86qenjj9zXJLbt3M5sq+U fhNNN7JPQ+ezx5VUZEUUZ/Bzdo/Mjcv661B/4xRUMiuPlDLY3oUmxqtV7ENwWowY2TROq4s1FRJv qC74hYB/jnfzOi27p4+tE0yMjyaT9gct12nVURoCqrGdeOWLaFBcFVhOBOzPx3JsMlLJx+IlIpIY eU8epOt+EkFGW8SISfxRF8WaQhUyjFiSIqPojYVhnTKGN2KHo6WFDDipmIcOoMYAbGYvmBpgRLx2 zc9hpy635+ZiCOQcThXxeJzJef27pXMXziEtBV4wE8E24TJDg0lod/xPMmJOGZqNDEezeWGf3SdW BEb8WBgHP0mk+qfJx7xmkNVjOhoBjQLr6OHZ7SeXcqNpGTezDQ7JwLqzN0EEmKDBCA8k4nfsc7O5 duYS/Bof5noW3E9NBkhE2Hk2iCweYzQQo2CoBfQC3yIlgURW/nIZqY8gQcULbBAkUNCS89IbthCN 2kvnfrAP8qa0xXFANnH08R1XxAoky/eY6LD6kV8xLoeR997VZMzXFlxRgpNj/iykKHzObrZsxMYy lFpop1yp5AvNsLbhPoDTAwtl57DITm6TJkd5KTmHvbHi5zbjjK18vQxN3pXLVz5Z+oRm4JL9QNV5 KyQotIf4qWigqwVXDEBrzhq3Y/hz5ttLkvvxkILC3KHcP20YFO2i1QgoA9RqhO/89qFxnvrVFK4T FDeitJACEe8zr81Ag1zn4vE4iKOgRG4OIMTPc12OTtn4Gdq4n2LxQanZcvlht6urS8ZCx/gJyw14 BYm5VBgHVvcjYub96u7tKsjDkawS2a6Rnw3vaIrdNEF3UP6i7B0QODCpIkryEPTIDk9NK5xfaeNn qRH8ScbTiRzESV5NJo/hK5IcjL3exPeMcGz/SIxYkmPj/XMugyIWYLY+jU1JREUiQ5JnnjzfFlrA 7vJTMee55DXyLZ/qZg6z/RGPcUtmZmJkZFLmKMcGiweO15MvnESSd7wPfGuAky6iC5TKYdkfHS4M R7ZdwgkpnL80TC5A1Ruy/lg6sAHuh7TP/CPVTREwCCgDpBPhdhFYXFo889IZtAL5KoLbJ1+cRA0v 0AwIwJbVuGQ30EVC/Is9sU9zNtDpl0/DxrrdU9/p41lLEWNQaj5DBwE8gFbUKapQkTUTE3KyKshY V0hJYJfYGJ8UZXEQd0MqK/dAbLP94gf/ULH/QP82uB/Du7RfNApGLZ0HEuyIxDnkJBzHlsropOir auzPNqV9FxSFtXKMjifcx4p5nPw2wfewPtrv78clMlu8hkzQFbbsXRvXbDZza7GAScz9dYUacDYB 9wSnXjoFZze/bMYHhGpWTFU+htRN7PiUjk7mOPfDPxand5bH1uN+4KoGxaUlunb6prer21MGaFcP X0ecvNdJ8D0O1b6QShoZenBjmj03i2oPiIblE0UoO4gf5D88/cvTyHMITS7C4MNM/GYf/BNVUfGM iD25IDki4TlrIr4E8cPVJ/iJGQ2ifW4c/JP/nBUulElSailEnhjPA8mc0fGHYK/SFZmWeC1J3wTh H9sBjAgestnvgHesQCCE8GKEI9oUDqUxW4oGBaMLN09bPF+RSzARUnbFqs8DiRzchGcsubCJ549w PLGSmejV80Aiihtfh+QEx+j5Rddzcp6iEBjyVYSsTwMiFWZ6OEzJjoJpxIdq75herbEfhteh1+Iy vTXjCRvpybV+Roii1igXBr+QER5JMfCCac6li+tNbJlsTFB0fghC7ifKEvlp7F2llEQbruHuHGVB bKMd2RjSulfGCGgeoIwHYMvu2xwGv+X5JHeAUYLIaqTtQZqfgYMDc+fmkDQIKXaQ/wNJaODvn3uL bB0sZsjFN/bcGG5e4IcQCotKqCPPjCDboW8Tt07Ex+L+iFQ9MJvQDh4WUewd+yCBEP4E1gd9QT3N lVlRj2z42DDaoUSIPz4JpxuXfM94w62fK8wLWj5erdNHNvG5ClWQXY8TdeDja2o0pinlr6KFEJC0 BQN/9XoaEvoYL1vSlZMVqlQgLIFPo3i6k97aIomtjrEea6ydoVdLaIxCeYrLbmAX+2gGB495GOfv zQLkGmhl3PvWQ9nIHDbxd2FTUcQoKdenK94nK7XeOKTwUAEWSUNTOjaNpdHJWp9oKnCAiWpfJJyK or31Je/mPTQMvrnR01pgzeGmR0UQ4CdUfi6Eb6tvXx8XOUfReHzArRAJaehx8Fr56LeP8q0Q6X9g ykAwZKthmPaQqQ98z5mzZ2BFjf9onOK33zdB8rkcBLwwg5BsHhIW6sswQLC38KfZ31BRC6QYwT87 YmDqxtRYa4N5C96kJtpFD8nMQKHowccxucrkoQ4jaQ+JGuPohDNoJxU/9nwcA8EeEOtR6gg0TeB9 alyYyEwTchISTy8ccR7GmDaIri/GojGXk7R+EhwPYxMJSvKaGJlXiSPy0riiFN0PV1OBswaV8rKl Kzj3YJJ7E1VHalk/fDeACdLf3186UKL3Er2H/zxQYuvHSohcOqv6RnyctnQBdJ42CwXytZjRGoPY GdNczyIDBFQDlAHod1iXXt/AcTowXFD7HQXhwf0g5Q9yMeNFWYnfWwQD5J9rUQUd/A3+CVeXBwQy SXwG8ePfkUGEVmhUBeCMrl/vYmaC461wG4XSBS3AFwYFUudUIsRJYg3DGkDVvFnbkaMy1PRljuqB RDIDift1Up0T01hY68RnL5RKFF53o9/I/f1n9A5xSSRFivG/IA94ODmzXYDFj8QGxpsFbwt9VSwP UFrsFaupaqHEZkdSkiK/Tz3Wc2ZeexRDPl33I+KtsD9mC8wOctZ0wEYuSD+H+TzdHGZv3TbmsFPe WB9WdKImJ22daSxhREU/eytgCpNPiVNTpm4dM6U7YHj1FAgB1QDpPLhdBEINEGqbw3xBqa9nR2Hf +KAhhIFADT3+4ji+pB2MOBdMDzxWUPnwXYw3yhgbUHZE0EXn3j4HAwIqaXwTPmu6WmP89IxVB/mE 4DIb+/sxUEr936JCGZ2zcWVZrCK0IU7exDNTdjiZJWgrz4sNfnGOAG4hkjvRlQ6IBMVgv2RAjYMm t5dUu5R5r7uHM+tgZ9hnGbMOtUeO0DP5YFLjwqQvKWyjKV6ND/e8Tvyzr3WVSlpEx4iOTebpNu37 5DR9e8kmhtaHJgk+tKzGSNM/itQ5jHlSbw6buZfkNWtNXTmZ5T50zkm5lbsSerTApMXdA/VNXTJM q/Vp+mr1wLsMAWWA7rIBb83lWlbmXlMrKrENHR6CCBfi5aFvkwgXlsobr76BQDDUeIfFg4w1/giK 3H55Ek6xvr6+i+9ehCOMa37ZPDrmhsgRUswAoV+YU7B7lj9bpgoPu+EJDytKalyYfZ5GdSleP9xV 12cs0pkM40bBFrJlhkXjNvGBU6GwDcSl00hu3JZ8M01PQKZG+CQjPJCpGEqW3PY5iVRCwvJDLrI9 xF98k05RxLI0OZ6pqzvMAy5ZN5yzzHnTNDLtP5BV0vUjxZJzuA7xFp/GDuqUaWxC5IgqQ8S+yXqF WYEJTNMY2bTblamh/Zhrj61AIJUBugfKIFhG/LdHHqVHcN2yQqDzRdBUwPJmBfcgPO/iA6VCSSyl FHlUqcoaUrHqpxJerp9afKzI6zSnD+GC7RwChtscKCKfmWb46WGEiSHh/u64/ZnoGKvhTasxWW+m pWpTErLQWi3wirXzlbza+NuwcV6UZq8KHoVoAGPJYYMPNMwN7QQi9tQSuNnMQGlcWpJd28Y30SyX ZCXAe9udW7+5zhZDmJh4T5dPutNG/HasK/zSEWloBciC0bTRjjH8fbeNTOA64mV2g3Z3dYiXcMfQ vO2GVATdHIRaC6w53PSoEAHWCtA6xMlk04gEmDKxdZflQak4wo5BuKxP2Eq0trF+2PRhK4ef9hAb f3ToKDIiIppsd1g/OHUjkQ6rPoHG73U0fpTDqPWELZ+ta31OP9akQtnVc5ce+k1KRlwIAqp5PljN B9euZwyTOXUM8rQJbmxLvVSYbCY1B/eW+Z2DLjq/boi/SHFlK8SZM9zV1g/9EqOVy+CKwu90C/wd +JbQFTRno9N4MyCnYWdopHb170hPnhFQDZDOhF2MAO65uPPCazZ9dnoXXQb7nngJ5FQ3nKQkHtDr o5yieWL4SmXcU+QzeJF8D8xNvFObhnXAZ664uSu8hM0NpVWXi6BoXKzMrxNpNo0T8soVjmPyLBF9 jsXQ1U5YHOnFCXL5IYF8XtDFm9Eho22XByXZOYznE1zOHpMovO4c9nOv5tR1oZGYtAAKXi0yquDi ND8E+rGbRwXdFIGdQkDzAO0Ukq1qp/NdYK268ruvXUp4g82sixEfmasGKpWnPXuN9wdqXKSLNBXI uWZCh0t5Wjeq5IqFh1TmdUzzMFo/VCwPU/K0ajlral9AzH7ljEqtu97ObLnOHMYJx1xmBFF3Ht5x Tl/JJWJJKqT5mrc5uuoC2yZgdnfNA9QcbnqUIrDzCNhktTK9G/MZ8p0Znb09FJ5jSmSTkwXsjomT qmf97HK+YUu4vSbMJoYxuAEZqbypxwnFOpC5ZGrllYkeQv06zonYkZj1c6fiH70uyzKmzeHYNPYQ 2UAzFD8BJ4qszfWtnzsVxi3nt+7QAgQ0CqwFoGqTikBzCECjwwn7hTwiqeaB16+Zita7IUSuOdj8 UexbpHh+EyjEnia2gYh+cO/1ovBq1BpL1VTBmZUa4ZUezX6n4p+4Lhusl5jDcghCCdR2Ydnu/rc5 pfTwOxoB1QDd0cOrF7cLEaCwXgiD8i6Xv/fFGA8B6y124WW16ZSZBuOcOtwlMQoGsDqRdz52ScaR 1fuMVAKG48FgQZjCyh4SqZi8PnevF9LVWaOgB46H8Lmk2ayHeyvvSry1aUZoN4pATQRUA9Tpk0M1 QJ0+Qq08P4769glUWtnVHd22ST3gNc4296O54ppaK+QWglWzN28i7k0lVJPVkMPQ7miwdv7iSKbm siLtfOvaYhCoBqi5WaAaoOZw06MUgXYgwKneQspHBRDNoc7x/0xCIELeKaDrWT8m1R4RSCa+iRXN LLqSpyDrtNvPOkaJMSKbUWnL5qauHtVKBFQD1Ep0tW1F4PYRkKIHFUA0jafRV3GoNmcHQEvp77mA MwzZrupiLtd1WUGs6dPUAxUBRaBtCKgGqG1Qa0eKgCKQKQLIEcCJl5w2Rdar4upyJF7RPHuZjpJ2 rgi0DQFlgNoGtXakCCgCmSLguBzOS26zSBvfFqXdu5+KSd21+uVMB0Y7VwSyQUAZoGxw114VgSYQ gMoEYl4qrFatovQVtvKXZfxzy5zCJAFWbUoUcY4X49J1zaQVaGL89BCDAKYuyaLxAZuZxlzjr/6G 3fgo3RSBnUJAGaCdQlLbUQRajsDyR8t9fX3n3zm/eHmxb19fsVgcKA0UC8WB/gEsJKndn3vn3IOF BwcfH8SBs2/NtvwUtQNFYCsESqXS3G/nYNBgTmIOFx8tFgoFzOf5C/Oph86/Pf/gPprDhYcKKP+3 VfP6d0WgUQSUAWoUKd1PEcgcAVtEyXE5C+8urH61Wsb2ZXnu7bnlf1te+miJT7J8o7z04RIYo4kX Jk69eOrqytWJFydqGUmZX5eewF2FgAyXG35meP2rdUzh6kZ17PkxTFGew9gH2+KHi/hm5LmRwSOD Vz+9OvXSVHm1fFdhpRfbUgSUAWopvNq4IrCTCCB+G83ZYtquHioXjFz/wzrsIU8FjTw1MvrsKHZe XVtFTmRYP6ieceqnp3bybLQtRaApBCipkikui41D58gdaarDrlfXhw4PwSOG72HTHzp4aHFpEZYQ 5Fmn//k0kigee/JYU33qQYpACgLKAOm0UAR2DQK2yhXilcw28aOJQ4OH9pf2gwEa/uvh488exyoC 79jKZytLv1sa+/FYZa2CB+uTPzkJQmj0udETz5/YNZeqJ3rnIsB1TynsLgjOv3v+0BOH9h/YD4/Y yDMjxW8U+x7oO3/hPP40++ps8eEiB+VN/csUWEzMYbh071xg9MrajYAyQO1GXPtTBJpGgBkgfnTG xo/RPff1zP1mrvStEuKYoJO48vGVuXNzoIWGvz3MWfumz05jh7Hvj82+Pqsy0qbB1wN3CgFmfcIk TJtBYV9h+tXpM6+cwfdggGZ/PctG/Pjz48G91O3YD8cwq0e+MzL9i+mdOg1tRxHAA2QShK8pLoqA ItCBCMQ0QDO/nLn0r5fwOvaU8QtsBpMvT+LpGWJnmDtcUAzvFCbGJbGMtKIDr0tP6a5CQGqABg8P Xlq8dHHhImYsgzByfARqNrCVMOiHvzO8/+H9toaJmcOVKk1mDWm8qyZMmy9WDaA2A67dKQINIZCq ASLjhusM7AlKj5UKvQVIKCZ+MsHfw60w9t0xaCmmfjUFVZDGezcEtO7USgSSGiDZG7jM4p8U4ckd f2Ec0xUFSWAbTf1yCnN45lczky9N8lTXTRFoEQJ/NPaD7933n/pu/l8KrJ157X+3qBttthEEfvaz nzWym+5zNyCw+f82H/qvD+3/8/37/vO+fQ/tGzgwgCLksQvvK/T91eG/OvA/DvD3f/nnf3nPf7gH C8b3vvu9iQmyinRTBLJCANzPnq/tuafrnicOPtHzH3v2/Zd9f3rwTzGlY+fzzW9+s/jfi3878rdM Ww4dGfrj//bHIDL/4cQ/PP0/n87q5Du535///OedfHode27IvzB05Alv7axcuw655D0okQpxEAuk H3l0f8ee/d1wYloN/m4YZb1GRUARUASaRkCrwTcHHUST02fPeGtn/sICqEd1gTUHph6lCLQFgbo5 nVXl05Yx0E52HoGUqavpy3ceZm1xCwTUANIpogh0MAIN1yfv4GvQU1ME4ghYKZv8WrU+Ok3ajoAa QG2HXDtUBBQBRUARUAQUgawRUAMo6xHQ/hUBRUARUAQUAUWg7QioAdR2yLVDRUARUAQUAUVAEcga ATWAsh4B7V8RUAQUAUVAEVAE2o6AGkBth1w7VAQUAUVAEVAEFIGsEVADKOsR0P4VAUVAEVAEFAFF oO0IqAHUdsi1Q0VAEVAEFAFFQBHIGgE1gLIeAe1fEVAEFAFFQBFQBNqOgBpAbYdcO1QEFAFFQBFQ BBSBrBFQAyjrERD9o8hL6oZKbY2/Dg0e4spu+q4IKAKKgCJw5yHQQYvW7jkVVP5KOVkUQ0UNTrzj tXuu5c48Ux6F1BfGqJFt8qVJlHzjAdV3RUARUAQUgTsMgTtz8Wv9VfHC6q0dXittNXgtMNt6/LUH RUARUAQUAUVAEcgSAeZ6tBp8lmOgfSsCioAioAgoAopAhgioBihD8LVrRUARUAQUAUVAEcgGATWA ssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQ AyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgG ATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSB DBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVA EcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQ BBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQU AUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFF QBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUAR UAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UE FAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVr RUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFd e1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD 8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWA ssFde1UEFAFFQBFQBBSBDBFQAyhD8LVrRUARUAQUAUVAEcgGATWAssFde1UEFAFFQBFQBBSBDBEg A+j0P53O8Ay0a0VAEVAEFAFFQBFQBNqAwPyFBby4oz9auXa9fKOMVxs61i4UAUVAEVAEFAFFQBHI EAFv8/x/nJsHMGK591kAAAAASUVORK5CYIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABQAEAASAAEAnAAPAAMAAAAAAAAAAABAAABg8f8CAEAADAAAANcfBAAAAAYATgBvAHIAbQBhAGwA AAACAAAAGABDShgAX0gBBGFKGABtSAkEc0gJBHRICQQAAAAAAAAAAAAAAAAAAAAAAABEAEFA8v+h AEQADAEAAAAAAAAAABYARABlAGYAYQB1AGwAdAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4A dAAAAAAAUgBpQPP/swBSAAwBAAAAAAAAAAAMAFQAYQBiAGwAZQAgAE4AbwByAG0AYQBsAAAAHAAX 9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAAAgALAAAAKABrQPT/wQAoAAABAAAAAAAAAAAHAE4A bwAgAEwAaQBzAHQAAAACAAAAAAAAAFAA/m/x//IAUAAMAAAA1x8EAAAACQBIAFQATQBMACAAQgBv AGQAeQAAAAsADwA3JAA4JABIJAAAGABPSgIAUUoCAF9IAQRtSAkEc0gJBHRICQQAAAAAIwgAAAYA ABoAAAAA/////wAAAAAlAAAAXwAAAKsAAAAIAQAAGgEAAG0BAACAAQAA2gEAADgCAACRAgAALwMA ADADAAAxAwAAMwMAADQDAAB7AwAAfAMAAOAEAADhBAAAnQUAAJ4FAAAMBgAADQYAAAMHAAAEBwAA IQgAACIIAAAlCAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAAMAAAAAAAAACAAAAA gAAAAHgAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAB4AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACA AAAAeAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAAHgAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAA AAB4AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAA AHgAAAAAAACYAAAAADAAAAAAAAAAgAAAAIAAAAAgAAAAAIAAmAAAAAAwAAAAAAAAAIAAAACAAAAA eAAAAAAAAJgAAAAAMAAAAAAAAACAAAAAgAAAABAAAAAAgACYAAAAADAAAAAAAAAAgAAAAIAAAAAA AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAeAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgA AAAAAACYAAAADzAAAAAAAAAAgAAAAIAAAAAQAAAAAIAAmAAAAA8wAAAAAAAAAIAAAACAAAAAEAAA AACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAA AAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAEAAAAACAAJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAA gACYAAAADzAAAAAAAAAAgAAAAIAAAAB4AAAAAAAAmAAAAA8wAAAAAAAAAIAAAACAAAAAEAAAAACA AJgAAAAPMAAAAAAAAACAAAAAgAAAACAAAAAAgACYAAAADzAAAAAAAAAAgAAAAIAAAAAAAAAAAAAA mAAAAA8wAAAAAAAAAIAAAACAAAAAAAAAAAAAAJgAAAAPMAAAAAAAAACAAAAAgAAAAHgAAAAAAACY AAAADzAAAAAAAAAAgAAAAIAAAAB4AAAAAAAAmAAAAAAwAAAAAAAAAIAAAACAAAAAeAAAAAAAAAAA AAAlAAAAXwAAAKsAAAAIAQAAGgEAAG0BAACAAQAA2gEAADgCAACRAgAALwMAADADAAAxAwAAMwMA ADQDAAB7AwAAfAMAAOAEAADhBAAAnQUAAJ4FAAANBgAAAwcAAAQHAAAhCAAAIggAACUIAAAPewEw AQAAAAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAEAAAAAAAAAAQAAAAEAAAAAAAAAAACABw97ATAB AAAAAAAAAAEAAAABAAAAAAAAAAAAgAcPewEwAQAAAAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAEA AAAAAAAAAQAAAAEAAAAAAAAAAACABw97ATABAAAAAAAAAAEAAAABAAAAAAAAAAAAgAcPewEwAQAA AAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAEAAAAAAAAAAQAAAAEAAAAAAAAAAACABw97ATABAAAA AAAAAAEAAAABAAAAAAAAAAAAgAcPewEwAQAAAAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAoAAAAA AAAAAgAAAAEAAAAAAAAAAACABw97ATAKAAAAAAAAAAIAAAABAAAAAAAAAAAAgAcPewEwDAAAAAAA AAABAAAAAQAAAAAAAAAAAIAHD3sBMAwAAAAAAAAAAQAAAAEAAAAAAAAAAACABw97ATAMAAAAAAAA AAEAAAABAAAAAAAAAAAAgAcPewEwAQAAAAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAoAAAAAAAAA AQAAAAEAAAAAAAAAAACABw97ATAKAAAAAAAAAAEAAAABAAAAAAAAAAAAgAcPewEwCgAAAAAAAAAB AAAAAQAAAAAAAAAAAIAHD3sBMAoAAAAAAAAAAQAAAAEAAAAAAAAAAACABw97ATAKAAAAAAAAAAEA AAABAAAAAAAAAAAAgAcPewEwCgAAAAAAAAABAAAAAQAAAAAAAAAAAIAHD3sBMAoAAAAAAAAAAQAA AAEAAAAAAAAAAACABw97ATAKAAAAAAAAAAEAAAABAAAAAAAAAAAAgAcPewEwCgAAAAAAAAABAAAA AQAAAAAAAAAAAIAHD3sBMAoAAAAAAAAAAQAAAAEAAAAAAAAAAACABwoAAAAAAAAAAAAAAAAAAAAA AM8AiCjhAhsAAAcABgAAIxAAAAkAAAAABgAAIhAAACMQAAAKAAAADAAAAAAGAAAjEAAACwAAAAAA AADdAAAA5gAAAAgBAAAKAQAATAEAAFUBAABtAQAAfwEAANoBAADhAQAAOAIAAD8CAACRAgAAnQIA AKYEAADFBAAAIAcAACMHAAAlCAAABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMA BwAAAAAAJQgAAAcAAAAAACUIAAAHAP//AgAAABEAUwBlAG4AdABoAGkAbAAgAFMAaQB2AGEAawB1 AG0AYQByAAAAAQAAAAQAAAAIAAAA5QAAAAAAAAAAAAAA1x8EAP9AA4ABACIIAAAiCAAA4HoMBgEA AQAiCAAAAAAAACIIAAAAAAAAAhAAAAAAAAAAIwgAAGAAABAAQAAA//8BAAAABwBVAG4AawBuAG8A dwBuAP//AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABH FpABAAACAgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcA IABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5 AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkA YQBsAAAAIgAEADEIiBgA8NACAABoAQAAAAB7UooGe1KKBgAAAAABAAAAAAA2AQAA7QYAAAEABAAA AAQAAxAOAAAANgEAAO0GAAABAAQAAAAOAAAAAAAAACQDAPAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAKUGwAe0ALQAgYEyNAAAAAAAAAAAAAAAAAAAHwgAAB8IAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATOD EQDwEAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAAAAAp8P8PAQABPwAA5AQAAP// /3////9/////f////3////9/////f////3/XHwQA//8SAAAAAAAAACQAVABoAGUAIABwAG8AdABl AG4AdABpAGEAbAAgAG0AaQBnAHIAYQB0AGkAbwBuACAAbwBwAHQAaQBvAG4AcwAgAGEAcgBlADoA AAAAAAAAEQBTAGUAbgB0AGgAaQBsACAAUwBpAHYAYQBrAHUAbQBhAHIAEQBTAGUAbgB0AGgAaQBs ACAAUwBpAHYAYQBrAHUAbQBhAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQAC AAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACkAQAAEQAAAAEAAACQAAAA AgAAAJgAAAADAAAAyAAAAAQAAADUAAAABQAAAPAAAAAGAAAA/AAAAAcAAAAIAQAACAAAABwBAAAJ AAAAOAEAABIAAABEAQAACgAAAGABAAAMAAAAbAEAAA0AAAB4AQAADgAAAIQBAAAPAAAAjAEAABAA AACUAQAAEwAAAJwBAAACAAAA5AQAAB4AAAAlAAAAVGhlIHBvdGVudGlhbCBtaWdyYXRpb24gb3B0 aW9ucyBhcmU6AHNvZh4AAAABAAAAAGhlIB4AAAASAAAAU2VudGhpbCBTaXZha3VtYXIAYXQeAAAA AQAAAABlbnQeAAAAAQAAAABlbnQeAAAACwAAAE5vcm1hbC5kb3QAYR4AAAASAAAAU2VudGhpbCBT aXZha3VtYXIAYXQeAAAAAgAAADEAbnQeAAAAFAAAAE1pY3Jvc29mdCBXb3JkIDEwLjAAQAAAAAAA AAAAAAAAQAAAAADiIHDqrsQBQAAAAADiIHDqrsQBAwAAAAEAAAADAAAANgEAAAMAAADtBgAAAwAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAUAAgAAAAAAAAAA AAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss+a4wAAAAHAEAAAwAAAABAAAAaAAAAA8AAABwAAAA BQAAAIwAAAAGAAAAlAAAABEAAACcAAAAFwAAAKQAAAALAAAArAAAABAAAAC0AAAAEwAAALwAAAAW AAAAxAAAAA0AAADMAAAADAAAAP0AAAACAAAA5AQAAB4AAAAUAAAAQ2lzY28gU3lzdGVtcywgSW5j LgADAAAADgAAAAMAAAAEAAAAAwAAAB8IAAADAAAAexAKAAsAAAAAAAAACwAAAAAAAAALAAAAAAAA AAsAAAAAAAAAHhAAAAEAAAAlAAAAVGhlIHBvdGVudGlhbCBtaWdyYXRpb24gb3B0aW9ucyBhcmU6 AAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAA AAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0AAAD+////DwAAABAAAAARAAAAEgAAABMAAAAUAAAA FQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAj AAAAJAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEA AAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAA AEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAA TgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABc AAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoA AABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAAdQAAAHYAAAB3AAAAeAAA AHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIAAACDAAAAhAAAAIUAAACGAAAA hwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAACV AAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMA AACkAAAApQAAAKYAAACnAAAAqAAAAP7///+qAAAAqwAAAKwAAACtAAAArgAAAK8AAACwAAAA/v// /7IAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAD+////ugAAALsAAAC8AAAAvQAAAL4AAAC/AAAA wAAAAP7////9/////f///8QAAAD+/////v////7///////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAAAYJ AgAAAAAAwAAAAAAAAEYAAAAAAAAAAAAAAABAYYGH6q7EAcYAAACAAAAAAAAAAEQAYQB0AGEAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAAFE0AQAA AAAAMQBUAGEAYgBsAGUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA4AAgEBAAAABgAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAACpAAAAABAAAAAAAABXAG8AcgBkAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQIAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAiGgAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB////////////////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAAAQAAAAAAAABQBEAG8AYwB1AG0A ZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEE AAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC5AAAAABAAAAAA AAABAEMAbwBtAHAATwBiAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAABqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAP7///////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////8BAP7/AwoAAP////8GCQIAAAAAAMAAAAAAAABG GAAAAE1pY3Jvc29mdCBXb3JkIERvY3VtZW50AAoAAABNU1dvcmREb2MAEAAAAFdvcmQuRG9jdW1l bnQuOAD0ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA== --=====================_42852047==_-- From owner-v6ops@ops.ietf.org Sun Oct 10 15:56:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06650 for ; Sun, 10 Oct 2004 15:55:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGjl1-000PtJ-0y for v6ops-data@psg.com; Sun, 10 Oct 2004 19:53:27 +0000 Received: from [161.114.64.104] (helo=zmamail04.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGjks-000PsB-MY for v6ops@ops.ietf.org; Sun, 10 Oct 2004 19:53:19 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id B981E5BE2; Sun, 10 Oct 2004 15:53:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Sun, 10 Oct 2004 15:53:17 -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_01C4AF02.C8C031DB" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Sun, 10 Oct 2004 15:53:22 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A280@tayexc13.americas.cpqcorp.net> Thread-Topic: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Thread-Index: AcSu66I7CrTKgbzlTwyJRMxyrqCmDQAFr3ZA From: "Bound, Jim" To: "Senthil Sivakumar" , "Elwyn Davies" Cc: "Sham Chakravorty" , "Brian E Carpenter" , "Cedric Aoun" , "V6OPS" X-OriginalArrivalTime: 10 Oct 2004 19:53:17.0459 (UTC) FILETIME=[C9427E30:01C4AF02] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. ------_=_NextPart_001_01C4AF02.C8C031DB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable the other important point of this discussion is if users have deployed NAT-PT and why? What we do not want is for NAT-PT to be used if it does not have to be intially when the dual stacked consensus view of this WG can be accomplished. Also with NAT-PT the user has no chance to begin adopting an E2E encrypted trust model using IPsec. Also it will break hopes of real QOS from use of IPv6 QOS label and where all data is encrypted as peeking at transport layer data is history once the payload is encrypted E2E. This is a very important discussion for the WG I think is my input. =20 /jim ________________________________ From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Senthil Sivakumar Sent: Sunday, October 10, 2004 1:05 PM To: Elwyn Davies Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS' Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt =09 =09 At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: =09 =09 Three points:=20 - The object of the draft was to summarize in one place all the problems with NAT-PT rather than being yet another delta on previous work. The introduction notes that several of the points are indeed generic address translation problems. This doesn't make them any less relevant. =09 I am fine with summarizing the issues in one draft. But the draft points out those as reasons to deprecate which is what I am pointing out.=20 =09 =09 - The draft is specifically targeting the NAT-PT =3D SIIT + DNS-ALG solution intended for use as a generic inter-cloud translator. It is clear to me that a 'cut down' form has a use as a legacy v4 'server adaptor' front end where there is only one v4 address (or maybe a server cluster) on one side, it only has to handle a pre-defined set of protocols, and it doesn't need a DNS-ALG. I think this should be the subject of a separate draft. =09 While I agree with you the cut-down solution does not need a DNS-ALG, I don't think it has to handle a specific set of protocols. I could still be a generic purpose translator for facilitating transition. I am attaching a document which was one of the use case scenario we are aware of. =09 =09 - The fundamental point is whether v6ops should still be continuing to support a technology which will, if widely deployed, effectively stifle innovation in v6 networks. The need for applications to be aware that NAT-PT exists effectively condemns v6 to be just v4 with larger addresses at the application level. Is this what is wanted? Or should we really be trying to put the architectural flexibility back into the Internet? I am not understanding why you say applications have to aware of existence of NAT-PT. =09 =09 =09 It would be useful to see Shivkumar's use cases so that they could be considered for inclusion in the relevant transition analysis. If people are using NAT-PT in a particular way then we need to give them a workable alternative before ditching NAT-PT. =09 Exactly. We should not prematurely deprecate the solution without an alternative in place. =09 Thnks Senthil =09 =09 Regards,=20 Elwyn=20 =09 > -----Original Message-----=20 > From: Sham Chakravorty [mailto:schakra@mitre.org]=20 > Sent: 09 October 2004 18:35=20 > To: 'Brian E Carpenter'; 'Senthil Sivakumar'=20 > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn=20 > [HAL02:0S00:EXCH]=20 > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt=20 >=20 >=20 > I agree with Shivkumar that deprecating NAT-PT really doesn't earn us=20 > anything but removes one tool that could be used in specific=20 > instances.=20 > Application gateways are not in the same usage "level" as=20 > NAT-PT - they=20 > occur in different points of the network. Also, the=20 > underlying algorithm of=20 > SIIT would still be available. =20 >=20 > Sham=20 >=20 > -----Original Message-----=20 > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf=20 > Of Brian E Carpenter=20 > Sent: Saturday, October 09, 2004 9:10 AM=20 > To: Senthil Sivakumar=20 > Cc: Cedric Aoun; V6OPS; Elwyn Davies=20 > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt=20 >=20 >=20 > > The point I am trying to stress is deprecating this would=20 > leave us with no=20 > workable=20 > > solution for communicating between IPv4 only=20 > networks/nodes/apps IPv6 only=20 > > networks/nodes/apps. As remote as it might seem for some,=20 > that is the use=20 > case=20 > > scenario we have encountered as the applicability of NAT-PT.=20 >=20 > But there is a workable alternative, which is an application=20 > level proxy.=20 > This too has its disadvantages, of course.=20 >=20 > Brian=20 >=20 > Senthil Sivakumar wrote:=20 > > I see that the draft has consolidated all the previous drafts that=20 > > highlighted the issues=20 > > of NAT-PT and DNS ALG, which is a good thing. However, most of the=20 > > issues mentioned=20 > > here as NAT-PT issues are known issues with address=20 > translation (NAT)=20 > > itself, so=20 > > attributing them to NAT-PT is not correct. Those should be=20 > categorized=20 > > as generic address=20 > > translation issues.=20 > >=20 > > Some specfic comments on the following issues.=20 > >=20 > > * Disruption of all protocols which embed IP addresses (and/or=20 > > ports) in packet payloads or which apply integrity=20 > mechanisms=20 > > using IP addresses (and ports). (not NAT-PT specific).=20 > >=20 > > * Requirement for applications to use keep alive=20 > mechanisms to=20 > > workaround connectivity issues caused by premature=20 > NAT-PT state=20 > > timeout. (not NAT-PT specific).=20 > >=20 > > * Inability to redirect packet fragments after the=20 > first with=20 > > NAPT-PT. (not NAT-PT specific).=20 > >=20 > > o Issues which are exacerbated by the use of a DNS-ALG:=20 > > * Constraints on network topology. (not NAT-PT specific).=20 > > * Scalability concerns together with introduction of=20 > single point=20 > > of failure and security attack nexus.(not NAT-PT specific).=20 > > * Lack of address mapping persistence: Some=20 > applications require=20 > > address retention between sessions. The user=20 > traffic will be=20 > > disrupted if a different mapping is used. The use of the=20 > > DNS-ALG to create address mappings with limited=20 > lifetimes means=20 > > that applications must start using the address=20 > shortly after=20 > > the mapping is created, as well as keeping it=20 > alive once they=20 > > start using it.(not NAT-PT specific).=20 > > * Creation of a DOS threat relating to exhaustion of=20 > memory and=20 > > address/port pool resources on the translator.(not NAT-PT=20 > > specific).=20 > >=20 > > Regarding the conclusion, I don't agree with the fact that only=20 > > applicable scenario=20 > > is in 3G networks. During the past couple of years of my=20 > experience I=20 > > have seen=20 > > customers using it between isolated IPv6 networks to talk=20 > to existing=20 > > IPv4 networks.=20 > > A lot of cases it is not about the nodes being dual stack=20 > or not, it is=20 > > the network=20 > > that is not dual stacked for operational reasons.=20 > >=20 > > I have been gathering some inputs from the customers who are using=20 > > NAT-PT currently=20 > > regarding this draft. I can consolidate and forward the=20 > comments if you=20 > > are interested in=20 > > knowing and understanding why they think they are moving=20 > forward with=20 > > NAT-PT.=20 > >=20 > > The point I am trying to stress is deprecating this would=20 > leave us with=20 > > no workable=20 > > solution for communicating between IPv4 only=20 > networks/nodes/apps IPv6 only=20 > > networks/nodes/apps. As remote as it might seem for some,=20 > that is the=20 > > use case=20 > > scenario we have encountered as the applicability of NAT-PT.=20 > >=20 > > Senthil=20 > >=20 > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:=20 > >=20 > >> Hi,=20 > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT=20 > >> deprecation analysis.=20 > >> We would really appreciate if you could provide us your=20 > feedback on=20 > >> the initial version of the deprecation analysis by Monday=20 > October 4th.=20 > >> Regards=20 > >> Cedric Aoun=20 > >> ------ Forwarded Message=20 > >> From: =20 > >> Reply-To: =20 > >> Date: Tue, 21 Sep 2004 21:38:33 +0200=20 > >> To: =20 > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt=20 > >>=20 > >> A New Internet-Draft is available from the on-line Internet-Drafts=20 > >> directories.=20 > >>=20 > >>=20 > >>=20 > >> Title : Reasons to Deprecate NAT-PT=20 > >> Author(s) : C. Aoun, E. Davies=20 > >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt=20 > >> Pages : 24=20 > >> Date : 2004-9-21=20 > >>=20 > >> This document discusses reasons why use of the specific form of=20 > >> IPv6-IPv4 protocol translation mechanism implemented by=20 > the Network=20 > >> Address Translator - Protocol Translator (NAT-PT)=20 > defined in RFC 2766=20 > >> should be deprecated and RFC2766 moved to historic status.=20 > >> Description of an alternative protocol translation=20 > mechanism is out=20 > >> of scope for this document.=20 > >>=20 > >> A URL for this Internet-Draft is:=20 > >>=20 > precate-00.txt=20 > >http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de=20 > precate-00.txt=20 >=20 > >>=20 > >>=20 > >> To remove yourself from the I-D Announcement list, send a=20 > message to=20 > >> i-d-announce-request@ietf.org with the word unsubscribe in=20 > the body of=20 > >> the message.=20 > >> You can also visit=20 > https://www1.ietf.org/mailman/listinfo/I-D-announce=20 > >> to change your subscription settings.=20 > >>=20 > >>=20 > >>=20 > >> Internet-Drafts are also available by anonymous FTP. Login=20 > with the=20 > >> username=20 > >> "anonymous" and a password of your e-mail address. After=20 > logging in,=20 > >> type "cd internet-drafts" and then=20 > >> "get draft-aoun-v6ops-natpt-deprecate-00.txt".=20 > >>=20 > >> A list of Internet-Drafts directories can be found in=20 > >> http://www.ietf.org/shadow.html=20 > >> or=20 > >>=20 > ftp://ftp.ietf.org/=20 ietf/1shadow-s=20 ites.txt=20 >>=20 >>=20 >>=20 >>=20 >> Internet-Drafts can also be obtained by e-mail.=20 >>=20 >> Send a message to:=20 >> mailserv@ietf.org.=20 >> In the body type:=20 >> "FILE /internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt".=20 >>=20 >> NOTE: The mail server at ietf.org can return the document in=20 >> MIME-encoded form by using the "mpack" utility. To use this=20 >> feature, insert the command "ENCODING mime" before the "FILE"=20 >> command. To decode the response(s), you will need "munpack" or=20 >> a MIME-compliant mail reader. Different MIME-compliant mail=20 >> readers=20 >> exhibit different behavior, especially when dealing with=20 >> "multipart" MIME messages (i.e. documents which have been split=20 >> up into multiple messages), so check your local documentation on=20 >> how to manipulate these messages.=20 >>=20 >>=20 >> Below is the data which will enable a MIME compliant mail reader=20 >> implementation to automatically retrieve the ASCII version of the=20 >> Internet-Draft.=20 >>=20 >>=20 >>=20 >>=20 >> ------ End of Forwarded Message=20 >>=20 >=20 =09 =09 =09 ------_=_NextPart_001_01C4AF02.C8C031DB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
the other important point of this discussion is = if users=20 have deployed NAT-PT and why?  What we do not want is for NAT-PT to = be used=20 if it does not have to be intially when the dual stacked consensus view = of this=20 WG can be accomplished.  Also with NAT-PT the user has no chance to = begin=20 adopting an E2E encrypted trust model using IPsec.   Also it = will=20 break hopes of real  QOS from use of IPv6 QOS label and where all = data is=20 encrypted as peeking at transport layer data is history once the payload = is=20 encrypted E2E.  This is a very important discussion for = the WG I=20 think is my input.
 
/jim

From: owner-v6ops@ops.ietf.org=20 [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Senthil=20 Sivakumar
Sent: Sunday, October 10, 2004 1:05 = PM
To: Elwyn=20 Davies
Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric = Aoun;=20 'V6OPS'
Subject: RE: FW: I-D=20 ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote:

Three = points:
- The object of the draft was to summarize in one place all = the=20 problems with NAT-PT rather than being yet another delta on previous = work.  The introduction notes that several of the points are = indeed=20 generic address translation problems.  This doesn't make them = any less=20 relevant.

I am fine with summarizing the = issues in=20 one draft. But the draft points out those as reasons to = deprecate
which is=20 what I am pointing out.

- The draft is = specifically=20 targeting the NAT-PT =3D SIIT + DNS-ALG solution intended for use as = a generic=20 inter-cloud translator.  It is clear to me that a 'cut down' = form has a=20 use as a legacy v4 'server adaptor' front end where there is only = one v4=20 address (or maybe a server cluster) on one side, it only has to = handle a=20 pre-defined set of protocols, and it doesn't need a DNS-ALG.  I = think=20 this should be the subject of a separate=20 draft.

While I agree with you the cut-down = solution=20 does not need a DNS-ALG, I don't think it has to handle a
specific = set of=20 protocols. I could still be a generic purpose translator for = facilitating=20 transition. I am attaching
a document which was one of the use case = scenario we are aware of.

- The fundamental = point is=20 whether v6ops should still be continuing to support a technology = which will,=20 if widely deployed, effectively stifle innovation in v6 = networks.  The=20 need for applications to be aware that NAT-PT exists effectively = condemns v6=20 to be just v4 with larger addresses at the application level. Is = this what=20 is wanted? Or should we really be trying to put the architectural=20 flexibility back into the Internet?

I am not=20 understanding why you say applications have to aware of existence of=20 NAT-PT.


It would be useful = to see=20 Shivkumar's use cases so that they could be considered for inclusion = in the=20 relevant transition analysis.  If people are using NAT-PT in a=20 particular way then we need to give them a workable alternative = before=20 ditching NAT-PT.

Exactly. We should not = prematurely=20 deprecate the solution without an alternative in=20 place.

Thnks
Senthil

Regards, =
Elwyn

> -----Original=20 Message-----
> From: Sham Chakravorty = [mailto:schakra@mitre.org]=20
> Sent: 09 October 2004 18:35 =
> To: 'Brian E Carpenter'; 'Senthil Sivakumar' =
> Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, = Elwyn=20
> [HAL02:0S00:EXCH]
>=20 Subject: RE: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt=20
>
> =
> I agree with Shivkumar that deprecating NAT-PT really = doesn't=20 earn us
> anything but removes one tool = that=20 could be used in specific
> = instances.=20
> Application gateways are not in the same = usage "level"=20 as
> NAT-PT - they
>=20 occur in different points of the network. Also, the
> underlying algorithm of
> = SIIT would=20 still be available. 
> =
> Sham
>
>=20 -----Original Message-----
> From:=20 owner-v6ops@ops.ietf.org
> [mailto:owner-v6ops@ops.ietf.org<= /A>]=20 On Behalf
> Of Brian E Carpenter =
> Sent: Saturday, October 09, 2004 9:10 AM =
> To: Senthil Sivakumar
> = Cc: Cedric=20 Aoun; V6OPS; Elwyn Davies
> Subject: = Re: FW: I-D=20 ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>=20
>
> > = The point I=20 am trying to stress is deprecating this would
>=20 leave us with no
> workable =
> > solution for communicating between IPv4 only=20
> networks/nodes/apps IPv6 only =
> > networks/nodes/apps. As remote as it might seem = for some,=20
> that is the use
>=20 case
> > scenario we have = encountered as the=20 applicability of NAT-PT.
> =
> But there is a workable alternative, which is an = application=20
> level proxy.
> This=20 too has its disadvantages, of course.
> =
>      = Brian=20
>
> Senthil = Sivakumar=20 wrote:
> > I see that the draft has=20 consolidated all the previous drafts that
> >=20 highlighted the issues
> > of NAT-PT = and DNS=20 ALG, which is a good thing. However, most of the
> > issues mentioned
> = > here as=20 NAT-PT issues are known issues with address
>=20 translation (NAT)
> > itself, = so=20
> > attributing them to NAT-PT is not = correct. =20 Those should be
> categorized =
> > as generic address
> = >=20 translation issues.
> > =
> > Some specfic comments on the following = issues.=20
> >
>=20 >      *  Disruption of all = protocols which=20 embed IP addresses (and/or
>=20 >          ports) in = packet=20 payloads or which apply integrity
>=20 mechanisms
>=20 >          using IP=20 addresses (and ports). (not NAT-PT specific).
>=20 >
> = >      =20 *  Requirement for applications to use keep alive =
> mechanisms to
>=20 >          = workaround=20 connectivity issues caused by premature
> NAT-PT=20 state
>=20 >          timeout. = (not=20 NAT-PT specific).
> > =
> >        *  = Inability=20 to redirect packet fragments after the
> first=20 with
>=20 >          NAPT-PT. = (not=20 NAT-PT specific).
> > =
> >    o  Issues which are = exacerbated by=20 the use of a DNS-ALG:
>=20 >       *  Constraints on = network=20 topology. (not NAT-PT specific).
>=20 >       *  Scalability = concerns=20 together with introduction of
> single=20 point
>=20 >          of = failure and=20 security attack nexus.(not NAT-PT specific).
>=20 >       *  Lack of address = mapping=20 persistence: Some
> applications = require=20
>=20 >          address = retention=20 between sessions.  The user
> = traffic will=20 be
>=20 >          disrupted = if a=20 different mapping is used.  The use of the
>=20 >          DNS-ALG = to create=20 address mappings with limited
> = lifetimes=20 means
>=20 >          that = applications=20 must start using the address
> shortly=20 after
>=20 >          the = mapping is=20 created, as well as keeping it
> alive = once=20 they
>=20 >          start = using=20 it.(not NAT-PT specific).
>=20 >       *  Creation of a DOS = threat=20 relating to exhaustion of
> memory = and=20
>=20 >          = address/port pool=20 resources on the translator.(not NAT-PT
> >=20 specific).
> >
>=20 > Regarding the conclusion, I don't agree with the fact that only =
> > applicable scenario =
> > is in 3G networks. During the past couple of = years of my=20
> experience I
> >=20 have seen
> > customers using it = between=20 isolated IPv6 networks to talk
> to = existing=20
> > IPv4 networks.
> > A lot of cases it is not about the nodes being = dual stack=20
> or not, it is
> >=20 the network
> > that is not dual = stacked for=20 operational reasons.
> > =
> > I have been gathering some inputs from the = customers who=20 are using
> > NAT-PT = currently=20
> > regarding this draft. I can consolidate = and=20 forward the
> comments if you =
> > are interested in
> = > knowing=20 and understanding why they think they are moving
> forward with
> > = NAT-PT.=20
> >
> > The = point I am=20 trying to stress is deprecating this would
>=20 leave us with
> > no workable =
> > solution for communicating between IPv4 only=20
> networks/nodes/apps IPv6 only =
> > networks/nodes/apps. As remote as it might seem = for some,=20
> that is the
> >=20 use case
> > scenario we have = encountered as=20 the applicability of NAT-PT.
> >=20
> > Senthil
> >=20
> > At 10:12 AM 9/22/2004 +0200, = Cedric Aoun=20 wrote:
> >
>=20 >> Hi,
> >> As discussed at = IETF 60,=20 the WG agreed to continue the NAT-PT
> = >>=20 deprecation analysis.
> >> We = would really=20 appreciate if you could provide us your
>=20 feedback on
> >> the initial = version of the=20 deprecation analysis by Monday
> = October=20 4th.
> >> Regards =
> >> Cedric Aoun
> = >>=20 ------ Forwarded Message
> >> = From:=20 <Internet-Drafts@ietf.org>
> = >>=20 Reply-To: <internet-drafts@ietf.org>
>=20 >> Date: Tue, 21 Sep 2004 21:38:33 +0200
>=20 >> To: <i-d-announce@ietf.org>
>=20 >> Subject: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt=20
> >>
> = >> A New=20 Internet-Draft is available from the on-line Internet-Drafts=20
> >> directories. =
> >>
> = >>
> >>
>=20 >>        =20 Title           : = Reasons=20 to Deprecate NAT-PT
>=20 >>        =20 Author(s)       : C. Aoun, E. = Davies=20
>=20 >>        =20 Filename        :=20 draft-aoun-v6ops-natpt-deprecate-00.txt
>=20 >>        =20 Pages           :=20 24
>=20 >>        =20 = Date            : = 2004-9-21
> >>
>=20 >> This document discusses reasons why use of the specific = form=20 of
> >>    = IPv6-IPv4=20 protocol translation mechanism implemented by
>=20 the Network
> = >>    Address=20 Translator - Protocol Translator (NAT-PT)
>=20 defined in RFC 2766
> = >>   =20 should be deprecated and RFC2766 moved to historic status. =
> >>    Description of an = alternative=20 protocol translation
> mechanism is = out=20
> >>    of scope for this = document.
> >>
>=20 >> A URL for this Internet-Draft is:
>=20 >>
> <ht= tp://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de=20
> precate-00.txt
> >ht= tp://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de=20
> precate-00.txt
>=20
> >>
>=20 >>
> >> To remove yourself = from the=20 I-D Announcement list, send a
> message = to=20
> >> i-d-announce-request@ietf.org with = the word=20 unsubscribe in
> the body of =
> >> the message.
> = >> You=20 can also visit
> https://www1= .ietf.org/mailman/listinfo/I-D-announce=20
> >> to change your subscription = settings.=20
> >>
> = >>=20
> >>
> = >>=20 Internet-Drafts are also available by anonymous FTP. Login =
> with the
> >> = username=20
> >> "anonymous" and a password of your = e-mail=20 address. After
> logging in, =
> >> type "cd internet-drafts" and then =
> = >>         "get=20 draft-aoun-v6ops-natpt-deprecate-00.txt".
>=20 >>
> >> A list of = Internet-Drafts=20 directories can be found in
> >> = <http://www.ietf.org/shadow.html<= /A>>http://www.ietf.org/shadow.html =
> >> or
> = >>=20
> <ftp://ftp.ietf.org/iet= f/1shadow-sites.txt>ftp://ftp.ietf.org/=20
ietf/1shadow-s
ites.txt =
>>
>>=20
>>
>>
>> Internet-Drafts can also be obtained by = e-mail.=20
>>
>> Send = a message=20 to:
>>        =20 mailserv@ietf.org.
>> In the body = type:=20
>>        =20 "FILE = /internet-drafts/draft-aoun-v6ops-natpt-deprecate-00.txt".=20
>>
>> = NOTE:  =20 The mail server at ietf.org can return the document in =
>>         = MIME-encoded=20 form by using the "mpack" utility.  To use this =
>>         = feature,=20 insert the command "ENCODING mime" before the "FILE" =
>>        =20 command.  To decode the response(s), you will need "munpack" = or=20
>>         a=20 MIME-compliant mail reader.  Different MIME-compliant mail=20
>> readers
>>         = exhibit=20 different behavior, especially when dealing with
>>         = "multipart"=20 MIME messages (i.e. documents which have been split
>>         up = into=20 multiple messages), so check your local documentation on =
>>         = how to=20 manipulate these messages.
>> =
>>
>> Below is the = data which=20 will enable a MIME compliant mail reader
>>=20 implementation to automatically retrieve the ASCII version of = the=20
>> Internet-Draft.
>>
>> =
>>
>> =
>> ------ End of Forwarded Message
>>
>=20


------_=_NextPart_001_01C4AF02.C8C031DB-- From owner-v6ops@ops.ietf.org Mon Oct 11 07:18:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24988 for ; Mon, 11 Oct 2004 07:18:08 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGy8M-000O1x-HO for v6ops-data@psg.com; Mon, 11 Oct 2004 11:14:30 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGy8J-000O1f-JY for v6ops@ops.ietf.org; Mon, 11 Oct 2004 11:14:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9BBEQ403350 for ; Mon, 11 Oct 2004 14:14:26 +0300 Date: Mon, 11 Oct 2004 14:14:26 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) In-Reply-To: <1097180513.4359.34.camel@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, 7 Oct 2004, Soininen Jonne (Nokia-NET/Helsinki) wrote: > your proposal sounds like a plan. If the WG decides to remain silent > until next week, please produce another draft without comments. I guess, > the WG will speak up sooner or later! I had been waiting for comments from the WG participants, but we haven't yet had much much of that.. Below are my personal comments. I agree that the document needs to continue spinning forward. There are many issues that still need fleshing out even under this restricted applicability. In short, I think the doc is a good start, but obviously as all initial documents, can always find a room for improvement. Hopefully my comments below help in that. substantial ----------- 1) 1.a) the matrix in section 3 (and sect 8) appears to be out of sync from the description of section 3 (see below for 'v6 to v4'), for example because the text says trivial scenarios have been removed, but matrix lines 1,2,12, and 13 (at least) are extremely trivial. What has happened? 1.b) Further than that, one thing I'd like to see is slightly more text (if that's not too difficult to manage) describing as precisely as reasonable how the table has been 'derived', in a manner that the reader would be able to follow which combinations have been omitted and due to what reasons. That would allow one to better analyze that all the cases have been dealt with (in one manner or another). Please also remember that even the trivial tunneling/translation scenarios will need to be described if we need a (new) solution to them. 1.c) you may need to end up having to define the columns of the matrix carefully. In particular 'Host X network' (I read it as "the enterprise network originating the packets") has at least one ambiguity. How do you represent the fact that the first-hop link of a dual-stack node supports only one protocol version, but further down the enterprise network both protocols are supported ? 1.d) there also seem to be some scenarios which are either too far in the future or easily worked around which might be decreed out of scope. For the former, consider the cases of v6-only ISPs -- I don't think these are worth the energy at this point of time. Or do you refer to *dual-stack* ISPs who are offering only v6 services (and provide translation/tunneling for v4 legacy)? For the latter, consider the scenario 4, i.e., v6-only application run on a dual-stack host, towards an IPv4-only application. I mean, what would the point of creating v6-only application which needs to talk to v4-only application, because doing such would nullify all the benefits of IPv6 -- couldn't one just say that one should do a dual-stack app in that case? [IMHO, v6-only apps should never be used if that necessitated the translation to v4, because doing so would nullify the usefulness of v6-only app to begin with, or requiring embedding a lot of v4 hacks in the translator -- both would seem like non-starters to me] 2) section 4.5 and 7.5.2 describe some approaches to remote IPv6 access support, but Introduction ruled IPv6 VPN's as out of scope. These could be seen as contradictory (but maybe the latter referred to v6-in-v6 VPNs, I don't know).. maybe it needs to be clarified what's in scope and what's not? (Section 4.5 is not clear whether you're addressing the 'branch office' or 'home user' case.. probably the latter?) 3) section 4.1 says that ULAs are not considered or advocated in this doc, while 7.3.2 says they should not be used. These appear to be conflicting statements. I think it'd be useful to mention ULAs, state that they are not *necessary* but could be used under specific conditions, and possibly to point to another document to come [on NAT-PT/RFC1918 alternatives]. 4) 7.4.1 IPv6 DNS The enterprise site should deploy a DNS service that is capable of both serving IPv6 DNS records (of the AAAA format, see RFC????) and of communicating over IPv6 transport. Specific IPv6 DNS issues are reported in [DNSV6]. ==> I think it would be useful to make it clearer here that while the v6 transport is nice, it's in no way requirement for anything, except for deploying v6-only nodes. (For example, in our enterprises, we haven't been able to field v6 transport resolver support in 2-3 years due to a number of reasons, but that hasn't stopped us from deploying v6 -- the document should (IMHO) give as few as possible requirements for "moving forward" with IPv6. The similar occurs in 7.4.3: A stateless configured node wishing to gain other configuration information (e.g. DNS, NTP servers) will likely need a Stateless DHCPv6 service available. , where this doesn't clearly identify that these are not strictly necessary for dual-stack systems.. because they are already configured using v4 protocols and means. Just to make it clearer that these are not a strict requirement for v6 deployment.. 5) a few further comments on the matrix in section 8: ====================================================================== | IPv6 | | | | IPv6 |IPv6 Host Tunnel 3 | ---- | IPv4 |Dual IP |Dual IP| ---- |(Brokered atISP) | Dual | | | | IPv6 | ==> isn't this a conflict with this statement in Introduction: 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. (i.e., it seems as if there is zero v6 support in the home enterprise, so the host gets it from the ISP-- but this was considered out of scope...) | IPv6 | | | |IPv4 IPv4|Translation on 4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6 | Dual | | | |IPv4 Dual|domain ==> as said, IMHO this nullifies the usefulness of creating v6-only applications so wouldn't it be better to just require such apps to support v4 as well? (there may be a couple of rare exceptions to this, like 3GPP IMS, but those are another story) | IPv6 | | | | IPv6 |IPv6 Host Tunnel 5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at | Dual | | | | IPv6 |Net2) ==> this would appear to be case where the host tunnel is brokered across the Internet. What reason would Net2 have for providing this to other enterprises? Do you have specific assumptions about their relations? |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site 6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel| |IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?) ==> wouldn't this be creating something like 'v6 6bone mess' (especially if sites are 'v6 only', which we all probably want to avoid? I mean, is there a specific problem in the current approach, i.e., the enterprises which want to connect other v6 enterprises to get v6 ISPs which are globally connected throughout the Internet ? | IPv6 |Dual IP| IPv4, | | IPv4 |Translation on 7 | ---- | or | IPv6 or| IPv4 | ---- |local IPv6 | IPv6 |v6 only|Dual IP | | IPv4 |domain ==> isn't this a regular 'why don't you just run dual-stack instead' argument ? | Dual | | | | IPv4 |DSTM for 10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6 | Dual | | | | IPv4 | ====================================================================== | Dual | | | | IPv4 |DSTM for 11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6 | Dual | | | | IPv4 | ==> you are proposing to run DSTM over Internet, right? I don't think it was ever (except for separate DSTM VPN I-D) designed to run like that, and it would likely have significant amount of security issues. I also don't see the element in the middle which would support dual-stack?!? i.e., how does v6 only site talk through v6-only ISP to a v4-only site, for example? Also, (repeating from matrix line 5 above), what would be the justification for Net2 to provide such Interdomain service ? 6) I'm having slight problems, at least yet, at seeing what is the role of appendix B in this document. This seems to be partially duplicating the text from enterprise scenarios, or..? It also has some specific discussion and good analysis. Should some parts of this be in the body, in a separate document, or..? [also note, the text is rather unreadable because some lines are wrapped oddly -- are you using good tools e.g. xml2rfc for editing?] semi-substantial ---------------- IPv6 Enterprise Network Analysis ==> given that the document restricts itself to (mainly) L3 considerations, would there be simple ways to try to reflect that somehow in the title of the draft and intro/abstract? For example insert 'connectivity' there? Not a big issue. ==> s/Analysis/Transition Analysis/ ? Abstract and introduction say: This document analyzes the transition to IPv6 in enterprise networks. ==> should one say "to using IPv6" instead, given that the focus of the document is not go all the way to the get to IPv6(-only), but the first step being providing the IPv6 capability? ... As an example, Scenario 1 is an IPv6 application trying to establish a communications exchange with a destination v4 only application. ==> uhh?? Not by the matrix at least -- maybe some matrix lines were removed? (see also substantial issue 1 above) Then, the IPv6 intranet communication will not be efficient, as it will require all the traffic to be forwarded by the IPv4 infrastructure to the Tunnel-End-Point located at the ISP. This could be acceptable if the IPv6 applications do not require intranet communication at all, for example in the case the application server that is located outside of the enterprise network, or in other networks of the same enterprise. ==> this section discusses only efficiency (AFAICS), but a major factor whether to pass internal traffic to the ISP (and back) is about trust. For most enterprises I know (and all the big ones, I'd suspect), they don't want to give external folks any chance of intercepting internal communications, which might or might not be encrypted, and might or might not contain classified information. If the tunnel end-point is at the ISP, there is no way to prevent this. Thus I can imagine no scenario, where an enterprise (which would have more than a couple of employees, or operate w/ encryption) would want to put the end-point out of it's own trusted network. This also becomes an issues of redundancy; if the communications to the ISP breaks down e.g., temporarily, is the internal traffic affected? Having internal tunnel endpoint would ensure that one would be able to continue without disruptions. ........ 5.2 Manual versus Autoconfigured If the number of nodes to be using IPv6 is reduced, an option is to use statically configured tunnels. However, in general automatic configured tunnels will be preferred. Section 5 doesn't yet discuss pros and cons of connecting sparse nodes, nor management/security issues. We need to add that in -01. ==> this isn't complete yet, so I don't know if you intended to discuss these or not but here are a couple of potential considerations: - are you considering just autoconfigured set-up ('assisted tunneling' or 'zero-conf tunneling'), or also "direct tunneling" ? - are you considering whether there are internal NATs in the enterprise or not (I don't personally know whether this is typical or not) ? - do you consider whether there are multiple boxes or just one (and if multiple, how are would they be distributed [e.g., geographically]) i.e., the number of users? ....... 7.4 Phase 2: Deploying generic basic service components Most of these are discussed in Section 4 of [BSCN]. Here we comment on those aspects that we believe are in scope for this analysis document. Thus we have not included network management, multihoming, multicast or application transition analysis here, but these aspects should be addressed in Phase 2. ==> I may be misunderstanding the last line, but isn't that saying that section 7.4 should be addressing this, or are you referring to the "next round" of enterprise evaluation (beyond the basic concepts) ? ........... .... For secure autoconfiguration, the SEND protocol is defined (now at RFC????). ==> because deploying SEND is not necessarily quite as trivial as this, maybe a placeholder should be put here, like 'The best practices for deploying the necessary certificates need to be analyzed.' ........ Hosts may also generate or request IPv6 Privacy Addresses (RFC3041); there is support for DHCPv6 to assign privacy addresses to nodes in managed environments. ==> is there actually any justification for using RFC3041 in enterprise environments? Should one put such a doubt here if not? Personally, I'm having trouble figuring out the actual problem... .... Use of [NAT-PT] is discouraged [cite the I-D on this?]. A recommended solution is the use of ALGs. Many applications naturally have an ALG behavior, and can be used to offer access for "legacy" IPv4 services such as SMTP (dual-stack email server, see [cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache), and are already operated by many enterprise sites. By dual-stacking the servers, an IPv6 only node can reach an external IPv4-only web site (for example) via the proxy without any additional (Layer 3 or 4) translation being required. ==> it would be worth mentioning (at least as a problem, if not further discussed) in a new paragraph how one would configure such proxies or translators on the v6-only nodes. Manually? Using yet-to-be-defined DHCPv6 options? Using unspecified means? Such an aid may be either a tunnel broker [TBRK], ideally one that supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If a 6to4 relay is offered, the site should be aware of security issues with operating 6to4 relays [cite ref?]. ==> are you referring to the 6to4 relay usage in a manner where the enterprise would provide a 'private' 6to4 relay, just for its own users who would need to know its v4 address, and manually configure it on their laptops (w/ using public addresses)? Note that there is no provision for access control here. Considering how common the NATs are, this seems like something that doesn't have sufficient "return value" for the enterprise, considering that there are plenty of free relays reachable through the anycast prefix. There is ongoing work on auto-transition and assisted tunneling tools that may also be applicable as remote access aids [cite refs?]. ==> possibly, but please note that most of those focus on the scenario where the access is provided by the first-hop ISP. What you're looking for is something like assited tunneling registered mode ('TSP') or v6-supporting L2TP (which is not a necessarily a big problem, as PPP supports v6 trivially). procedural ---------- ==> there is one author too many (6 > 5). If it is not possible to reduce the number of authors, the alternative would be just listing the editor in the front page, and the authors in the contact information or contributors. ==> there are a lot of documents in 'normative references'. These are meant to be documents which are required to be read to understand the document. Please note that this doc cannot be published until all of these are also published. Is that intentional? Maybe some shuffling around would be warranted? editorial --------- ==> there are quite a few references with 'RFC????' or the like -- these should be filled in (naturally ;-), and maybe put in as informative references explicitly. (Also a mention of I-D in 7.4.6, that would be draft-motonori-dualstack-smtp-requirement-01.txt) ==> Introduction and Abstract use the term 'Provider' before it's defined, and as such, it isn't clear to the reader that you refer to the ISP with it. Two possible fixes: 1) rename Provider to ISP (because the terminology requires providing connectivity in any case, so this looks pretty close to ISP to me), or 2) expand Provider to ISP in abstract/introduction. ... 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. ==> there appears to be some overlap with these sentences ? The enterprise analysis will begin by describing a matrix tool to be used to portray the different IPv4 and IPv6 possibilities for deployment. The first column (Application/Host 1 OS) represents the IP-capability offered by the node that originates IP packets. The second to last column (Application/Host 2 OS) represents the IP- capability offered by the node that terminates the IP packet. In between are three columns that represent the IP-capability of typical networks traversed by the packet, including an originating host network (Host 1 Network),Service Provider Network and Destination Host Network (Host 2 Network). Each row (1 through 13) is one possible scenario and the final column shows the recommended transition mechanism to use for that particular scenario. ==> in the matrix in section 3, there it's the last column. (This also applies in the text in section 3) ==> actually, I think the discussion here is slightly out of place, as it's already there in section 3 (where it's better placed). I'd consider just summarizing this paragraph here to one or two sentences, and referring to fuller description in section 3. IPv6 only - A node or network capable of supporting only IPv6. This does not imply an IPv6 only stack, in this document. ==> I find the last sentence slightly confusing, maybe it would better read like 'In this document, a dual-stack node which has disabled IPv4 stack is also considered IPv6 only.' Many router platforms can tag multiple VLAN IDs on a single physical interface based on the subnet/link the packet is destined for ==> 'Many' ? Are there platforms which *can't* do it? I'd be surprised :). Maybe just remove 'Many' or replace with 'Practically all'. The parallel infrastructure would only ever be seen as an interim step towards a full dual-stack deployment on a unified infrastructure. ==> could 'would only ever be seen' be reworded? That seems like a complex structure of words for us foreigners.. The upstream provider could have already deployed some IPv6 service, either native IPv6 in its backbone or in the access network, or a combination of both. Also, or alternatively, could have deployed one or several transition mechanisms based upon tunnels, for example in the case where the access network doesn't support IPv6. In this case, the enterprise could decide to use those available transition services from the ISP. However, this will usually mean that the each of the different nodes in the network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6 intranet communication will not be efficient, as it will require all the traffic to be forwarded by the IPv4 infrastructure to the Tunnel-End-Point located at the ISP. This could be acceptable if the IPv6 applications do not require intranet communication at all, for example in the case the application server that is located outside of the enterprise network, or in other networks of the same enterprise. ==> s/could/it could/ ? ==> could this paragraph be broken into two (or three), making it more digestible? :-) The enterprise could also decide to deploy its own transition box and possibly collocate it adjacent to the border router that ==> s/collo/co-lo/ IPv6 communications between IPv6 nodes will use IPv6 to communicate. ==> sounds like a no-op ? Author's Address ==> make that "Authors' 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 Mon Oct 11 08:37:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02120 for ; Mon, 11 Oct 2004 08:37:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGzOe-0007YU-Oh for v6ops-data@psg.com; Mon, 11 Oct 2004 12:35:24 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CGyaq-0001NB-Dt for v6ops@ops.ietf.org; Mon, 11 Oct 2004 11:43:57 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9BBhiFW125294; Mon, 11 Oct 2004 11:43:45 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9BBhiZf211816; Mon, 11 Oct 2004 13:43:44 +0200 Received: from zurich.ibm.com (sig-9-145-134-42.de.ibm.com [9.145.134.42]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA82242; Mon, 11 Oct 2004 13:43:42 +0200 Message-ID: <416A71ED.5020402@zurich.ibm.com> Date: Mon, 11 Oct 2004 13:43:41 +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: Senthil Sivakumar CC: Elwyn Davies , "'Sham Chakravorty'" , Cedric Aoun , "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt References: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> In-Reply-To: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > 1. Renumber all private IPv4 addressing to be compatible; > 2. Implement a proxy service at the ingress/egress of each private network; > 3. Leave the private IPv4 interface unchanged and implement a new IPv6 interface (dualstack) > on end-systems or > 4. Leave the private IPv4 interface unchanged and implement double Network Address > Translation (NAT). > Of these options, the first was considered un-realistic. The second can be unscalable for > ingress flows and imposes topology restrictions. Exactly the same concerns arise for NAT-PT, and it isn't at all clear that scaling is any worse in the case of a proxy. Highly scaleable proxies are common today. > The third may involve applications on legacy > systems that cannot migrate to a dual stack IPv4/IPv6 environment. Nevertheless, it is the preferred strategy whenever it can be applied - what we are talking about is how to catch the cases where this is simply impossible. > As a result, the XXXX > architecture is based on the fourth option of double-NAT by implementing NAT-PT. This does not prevent the deployment of the third option where feasible. ……… But you have another option that will allow legacy to speak to legacy - an IPv4-in-IPv6 tunnel. That's a no-brainer that we haven't really discussed much, and as far as I can see it can do everything double-NAT-PT can do. Brian Senthil Sivakumar wrote: > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > >> Three points: >> - The object of the draft was to summarize in one place all the >> problems with NAT-PT rather than being yet another delta on previous >> work. The introduction notes that several of the points are indeed >> generic address translation problems. This doesn't make them any less >> relevant. > > > I am fine with summarizing the issues in one draft. But the draft points > out those as reasons to deprecate > which is what I am pointing out. > >> - The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG >> solution intended for use as a generic inter-cloud translator. It is >> clear to me that a 'cut down' form has a use as a legacy v4 'server >> adaptor' front end where there is only one v4 address (or maybe a >> server cluster) on one side, it only has to handle a pre-defined set >> of protocols, and it doesn't need a DNS-ALG. I think this should be >> the subject of a separate draft. > > > While I agree with you the cut-down solution does not need a DNS-ALG, I > don't think it has to handle a > specific set of protocols. I could still be a generic purpose translator > for facilitating transition. I am attaching > a document which was one of the use case scenario we are aware of. > >> - The fundamental point is whether v6ops should still be continuing to >> support a technology which will, if widely deployed, effectively >> stifle innovation in v6 networks. The need for applications to be >> aware that NAT-PT exists effectively condemns v6 to be just v4 with >> larger addresses at the application level. Is this what is wanted? Or >> should we really be trying to put the architectural flexibility back >> into the Internet? > > > I am not understanding why you say applications have to aware of > existence of NAT-PT. > > >> It would be useful to see Shivkumar's use cases so that they could be >> considered for inclusion in the relevant transition analysis. If >> people are using NAT-PT in a particular way then we need to give them >> a workable alternative before ditching NAT-PT. > > > Exactly. We should not prematurely deprecate the solution without an > alternative in place. > > Thnks > Senthil > >> Regards, >> Elwyn >> >> > -----Original Message----- >> > From: Sham Chakravorty >> [mailto:schakra@mitre.org] >> > Sent: 09 October 2004 18:35 >> > To: 'Brian E Carpenter'; 'Senthil Sivakumar' >> > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn >> > [HAL02:0S00:EXCH] >> > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> > >> > >> > I agree with Shivkumar that deprecating NAT-PT really doesn't earn us >> > anything but removes one tool that could be used in specific >> > instances. >> > Application gateways are not in the same usage "level" as >> > NAT-PT - they >> > occur in different points of the network. Also, the >> > underlying algorithm of >> > SIIT would still be available. >> > >> > Sham >> > >> > -----Original Message----- >> > From: owner-v6ops@ops.ietf.org >> > [mailto:owner-v6ops@ops.ietf.org] >> On Behalf >> > Of Brian E Carpenter >> > Sent: Saturday, October 09, 2004 9:10 AM >> > To: Senthil Sivakumar >> > Cc: Cedric Aoun; V6OPS; Elwyn Davies >> > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> > >> > >> > > The point I am trying to stress is deprecating this would >> > leave us with no >> > workable >> > > solution for communicating between IPv4 only >> > networks/nodes/apps IPv6 only >> > > networks/nodes/apps. As remote as it might seem for some, >> > that is the use >> > case >> > > scenario we have encountered as the applicability of NAT-PT. >> > >> > But there is a workable alternative, which is an application >> > level proxy. >> > This too has its disadvantages, of course. >> > >> > Brian >> > >> > Senthil Sivakumar wrote: >> > > I see that the draft has consolidated all the previous drafts that >> > > highlighted the issues >> > > of NAT-PT and DNS ALG, which is a good thing. However, most of the >> > > issues mentioned >> > > here as NAT-PT issues are known issues with address >> > translation (NAT) >> > > itself, so >> > > attributing them to NAT-PT is not correct. Those should be >> > categorized >> > > as generic address >> > > translation issues. >> > > >> > > Some specfic comments on the following issues. >> > > >> > > * Disruption of all protocols which embed IP addresses (and/or >> > > ports) in packet payloads or which apply integrity >> > mechanisms >> > > using IP addresses (and ports). (not NAT-PT specific). >> > > >> > > * Requirement for applications to use keep alive >> > mechanisms to >> > > workaround connectivity issues caused by premature >> > NAT-PT state >> > > timeout. (not NAT-PT specific). >> > > >> > > * Inability to redirect packet fragments after the >> > first with >> > > NAPT-PT. (not NAT-PT specific). >> > > >> > > o Issues which are exacerbated by the use of a DNS-ALG: >> > > * Constraints on network topology. (not NAT-PT specific). >> > > * Scalability concerns together with introduction of >> > single point >> > > of failure and security attack nexus.(not NAT-PT specific). >> > > * Lack of address mapping persistence: Some >> > applications require >> > > address retention between sessions. The user >> > traffic will be >> > > disrupted if a different mapping is used. The use of the >> > > DNS-ALG to create address mappings with limited >> > lifetimes means >> > > that applications must start using the address >> > shortly after >> > > the mapping is created, as well as keeping it >> > alive once they >> > > start using it.(not NAT-PT specific). >> > > * Creation of a DOS threat relating to exhaustion of >> > memory and >> > > address/port pool resources on the translator.(not NAT-PT >> > > specific). >> > > >> > > Regarding the conclusion, I don't agree with the fact that only >> > > applicable scenario >> > > is in 3G networks. During the past couple of years of my >> > experience I >> > > have seen >> > > customers using it between isolated IPv6 networks to talk >> > to existing >> > > IPv4 networks. >> > > A lot of cases it is not about the nodes being dual stack >> > or not, it is >> > > the network >> > > that is not dual stacked for operational reasons. >> > > >> > > I have been gathering some inputs from the customers who are using >> > > NAT-PT currently >> > > regarding this draft. I can consolidate and forward the >> > comments if you >> > > are interested in >> > > knowing and understanding why they think they are moving >> > forward with >> > > NAT-PT. >> > > >> > > The point I am trying to stress is deprecating this would >> > leave us with >> > > no workable >> > > solution for communicating between IPv4 only >> > networks/nodes/apps IPv6 only >> > > networks/nodes/apps. As remote as it might seem for some, >> > that is the >> > > use case >> > > scenario we have encountered as the applicability of NAT-PT. >> > > >> > > Senthil >> > > >> > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: >> > > >> > >> Hi, >> > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT >> > >> deprecation analysis. >> > >> We would really appreciate if you could provide us your >> > feedback on >> > >> the initial version of the deprecation analysis by Monday >> > October 4th. >> > >> Regards >> > >> Cedric Aoun >> > >> ------ Forwarded Message >> > >> From: >> > >> Reply-To: >> > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 >> > >> To: >> > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> > >> >> > >> A New Internet-Draft is available from the on-line Internet-Drafts >> > >> directories. >> > >> >> > >> >> > >> >> > >> Title : Reasons to Deprecate NAT-PT >> > >> Author(s) : C. Aoun, E. Davies >> > >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt >> > >> Pages : 24 >> > >> Date : 2004-9-21 >> > >> >> > >> This document discusses reasons why use of the specific form of >> > >> IPv6-IPv4 protocol translation mechanism implemented by >> > the Network >> > >> Address Translator - Protocol Translator (NAT-PT) >> > defined in RFC 2766 >> > >> should be deprecated and RFC2766 moved to historic status. >> > >> Description of an alternative protocol translation >> > mechanism is out >> > >> of scope for this document. >> > >> >> > >> A URL for this Internet-Draft is: >> > >> >> > >> <http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de >> >> > precate-00.txt >> > >> >http://w >> ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de >> > precate-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-aoun-v6ops-natpt-deprecate-00.txt". >> > >> >> > >> A list of Internet-Drafts directories can be found in >> > >> >> <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html >> >> > >> or >> > >> >> > >> <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ >> >> ietf/1shadow-s >> ites.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-aoun-v6ops-natpt-deprecate-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. >> >> >> >> >> >> >> >> >> >> ------ End of Forwarded Message >> >> >> > >> >> > From owner-v6ops@ops.ietf.org Mon Oct 11 08:49:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03182 for ; Mon, 11 Oct 2004 08:49:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CGzcE-00094w-MJ for v6ops-data@psg.com; Mon, 11 Oct 2004 12:49:26 +0000 Received: from [209.123.233.211] (helo=smtp-out1.oct.nac.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CGzcD-00094i-PB for v6ops@ops.ietf.org; Mon, 11 Oct 2004 12:49:26 +0000 Received: (qmail 99185 invoked by uid 1000); 11 Oct 2004 12:49:22 -0000 Received: from rfgraveman@nac.net by smtp-out1.oct by uid 1002 with NIZZACK qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4291. sophie: 2.14/3.73. f-prot: 4.1.1/3.13.4. Clear:RC:1:. Processed in 0.026549 secs); 11 Oct 2004 12:49:22 -0000 Received: from unknown (HELO webmail.nac.net) (64.21.52.85) by smtp-out1.oct.nac.net with SMTP; 11 Oct 2004 12:49:22 -0000 Received: from 67.84.243.204 (SquirrelMail authenticated user rfgraveman) by webmail.nac.net with HTTP; Mon, 11 Oct 2004 08:49:24 -0400 (EDT) Message-ID: <33309.67.84.243.204.1097498964.squirrel@webmail.nac.net> In-Reply-To: References: <1097180513.4359.34.camel@localhost.localdomain> Date: Mon, 11 Oct 2004 08:49:24 -0400 (EDT) Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) From: rfgraveman@nac.net To: "Pekka Savola" Cc: v6ops@ops.ietf.org User-Agent: SquirrelMail/1.4.2 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 Importance: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME, PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit > ... [Section 5.1] > Then, the IPv6 > intranet communication will not be efficient, as it will require > all the traffic to be forwarded by the IPv4 infrastructure to the > Tunnel-End-Point located at the ISP. This could be acceptable if > the IPv6 applications do not require intranet communication at all, > for example in the case the application server that is located > outside of the enterprise network, or in other networks of the same > enterprise. > > ==> this section discusses only efficiency (AFAICS), but a major factor > whether to pass internal traffic to the ISP (and back) is about trust. > For > most enterprises I know (and all the big ones, I'd suspect), they don't > want > to give external folks any chance of intercepting internal communications, > which might or might not be encrypted, and might or might not contain > classified information. I agree this is more about trust than efficiency, and I would suggest, at a minimum, deleting: ", or in other networks of the same enterprise" Also, it is often about weak authentication on internal networks (intranets) as much as about intercepted message contents. It's likely preferable to use the word "proprietary" rather than "classified." Regards, Richard From owner-v6ops@ops.ietf.org Mon Oct 11 09:59:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07461 for ; Mon, 11 Oct 2004 09:59:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH0gK-000HTJ-Gs for v6ops-data@psg.com; Mon, 11 Oct 2004 13:57:44 +0000 Received: from [66.218.92.37] (helo=web40426.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CH0gJ-000HT4-6I for v6ops@ops.ietf.org; Mon, 11 Oct 2004 13:57:43 +0000 Message-ID: <20041011135742.379.qmail@web40426.mail.yahoo.com> Received: from [24.5.84.18] by web40426.mail.yahoo.com via HTTP; Mon, 11 Oct 2004 06:57:42 PDT Date: Mon, 11 Oct 2004 06:57:42 -0700 (PDT) From: Pyda Srisuresh Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt To: Senthil Sivakumar , Elwyn Davies Cc: "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" In-Reply-To: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Folks, As Senthil points out, the assumption that NAT-PT deployment will stifle innovation in v6 seems flawed. NAT-PT is a transition mechanism which is essential for wider V6 deployment. Without NAT-PT, you will see bigger resistance to deploying V6 . You need NAT-PT for legacy applications (ex: e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts or applications. This is the attraction of NAT-PT. This is not the same as the proxy solution that will require applications to be changed/recompiled. cheers, suresh --- Senthil Sivakumar wrote: > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > >Three points: > >- The object of the draft was to summarize in one place all the problems > >with NAT-PT rather than being yet another delta on previous work. The > >introduction notes that several of the points are indeed generic address > >translation problems. This doesn't make them any less relevant. > > I am fine with summarizing the issues in one draft. But the draft points > out those as reasons to deprecate > which is what I am pointing out. > > >- The draft is specifically targeting the NAT-PT = SIIT + DNS-ALG solution > >intended for use as a generic inter-cloud translator. It is clear to me > >that a 'cut down' form has a use as a legacy v4 'server adaptor' front end > >where there is only one v4 address (or maybe a server cluster) on one > >side, it only has to handle a pre-defined set of protocols, and it doesn't > >need a DNS-ALG. I think this should be the subject of a separate draft. > > While I agree with you the cut-down solution does not need a DNS-ALG, I > don't think it has to handle a > specific set of protocols. I could still be a generic purpose translator > for facilitating transition. I am attaching > a document which was one of the use case scenario we are aware of. > > >- The fundamental point is whether v6ops should still be continuing to > >support a technology which will, if widely deployed, effectively stifle > >innovation in v6 networks. The need for applications to be aware that > >NAT-PT exists effectively condemns v6 to be just v4 with larger addresses > >at the application level. Is this what is wanted? Or should we really be > >trying to put the architectural flexibility back into the Internet? > > I am not understanding why you say applications have to aware of existence > of NAT-PT. > > > >It would be useful to see Shivkumar's use cases so that they could be > >considered for inclusion in the relevant transition analysis. If people > >are using NAT-PT in a particular way then we need to give them a workable > >alternative before ditching NAT-PT. > > Exactly. We should not prematurely deprecate the solution without an > alternative in place. > > Thnks > Senthil > > >Regards, > >Elwyn > > > > > -----Original Message----- > > > From: Sham Chakravorty > > [mailto:schakra@mitre.org] > > > Sent: 09 October 2004 18:35 > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > [HAL02:0S00:EXCH] > > > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really doesn't earn us > > > anything but removes one tool that could be used in specific > > > instances. > > > Application gateways are not in the same usage "level" as > > > NAT-PT - they > > > occur in different points of the network. Also, the > > > underlying algorithm of > > > SIIT would still be available. > > > > > > Sham > > > > > > -----Original Message----- > > > From: owner-v6ops@ops.ietf.org > > > [mailto:owner-v6ops@ops.ietf.org] On > > Behalf > > > Of Brian E Carpenter > > > Sent: Saturday, October 09, 2004 9:10 AM > > > To: Senthil Sivakumar > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > The point I am trying to stress is deprecating this would > > > leave us with no > > > workable > > > > solution for communicating between IPv4 only > > > networks/nodes/apps IPv6 only > > > > networks/nodes/apps. As remote as it might seem for some, > > > that is the use > > > case > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > But there is a workable alternative, which is an application > > > level proxy. > > > This too has its disadvantages, of course. > > > > > > Brian > > > > > > Senthil Sivakumar wrote: > > > > I see that the draft has consolidated all the previous drafts that > > > > highlighted the issues > > > > of NAT-PT and DNS ALG, which is a good thing. However, most of the > > > > issues mentioned > > > > here as NAT-PT issues are known issues with address > > > translation (NAT) > > > > itself, so > > > > attributing them to NAT-PT is not correct. Those should be > > > categorized > > > > as generic address > > > > translation issues. > > > > > > > > Some specfic comments on the following issues. > > > > > > > > * Disruption of all protocols which embed IP addresses (and/or > > > > ports) in packet payloads or which apply integrity > > > mechanisms > > > > using IP addresses (and ports). (not NAT-PT specific). > > > > > > > > * Requirement for applications to use keep alive > > > mechanisms to > > > > workaround connectivity issues caused by premature > > > NAT-PT state > > > > timeout. (not NAT-PT specific). > > > > > > > > * Inability to redirect packet fragments after the > > > first with > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > * Constraints on network topology. (not NAT-PT specific). > > > > * Scalability concerns together with introduction of > > > single point > > > > of failure and security attack nexus.(not NAT-PT specific). > > > > * Lack of address mapping persistence: Some > > > applications require > > > > address retention between sessions. The user > > > traffic will be > > > > disrupted if a different mapping is used. The use of the > > > > DNS-ALG to create address mappings with limited > > > lifetimes means > > > > that applications must start using the address > > > shortly after > > > > the mapping is created, as well as keeping it > > > alive once they > > > > start using it.(not NAT-PT specific). > > > > * Creation of a DOS threat relating to exhaustion of > > > memory and > > > > address/port pool resources on the translator.(not NAT-PT > > > > specific). > > > > > > > > Regarding the conclusion, I don't agree with the fact that only > > > > applicable scenario > > > > is in 3G networks. During the past couple of years of my > > > experience I > > > > have seen > > > > customers using it between isolated IPv6 networks to talk > > > to existing > > > > IPv4 networks. > > > > A lot of cases it is not about the nodes being dual stack > > > or not, it is > > > > the network > > > > that is not dual stacked for operational reasons. > > > > > > > > I have been gathering some inputs from the customers who are using > > > > NAT-PT currently > > > > regarding this draft. I can consolidate and forward the > > > comments if you > > > > are interested in > > > > knowing and understanding why they think they are moving > > > forward with > > > > NAT-PT. > > > > > > > > The point I am trying to stress is deprecating this would > > > leave us with > > > > no workable > > > > solution for communicating between IPv4 only > > > networks/nodes/apps IPv6 only > > > > networks/nodes/apps. As remote as it might seem for some, > > > that is the > > > > use case > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > Senthil > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > >> Hi, > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > >> deprecation analysis. > > > >> We would really appreciate if you could provide us your > > > feedback on > > > >> the initial version of the deprecation analysis by Monday > > > October 4th. > > > >> Regards > > > >> Cedric Aoun > > > >> ------ Forwarded Message > > > >> From: > > > >> Reply-To: > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > >> To: > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > >> > > > >> A New Internet-Draft is available from the on-line Internet-Drafts > > > >> directories. > > > >> > > > >> > > > >> > > > >> Title : Reasons to Deprecate NAT-PT > > > >> Author(s) : C. Aoun, E. Davies > > > >> Filename : draft-aoun-v6ops-natpt-deprecate-00.txt > > > >> Pages : 24 > > > >> Date : 2004-9-21 > > > >> > > > >> This document discusses reasons why use of the specific form of > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > the Network > > > >> Address Translator - Protocol Translator (NAT-PT) > > > defined in RFC 2766 > > > >> should be deprecated and RFC2766 moved to historic status. > > > >> Description of an alternative protocol translation > > > mechanism is out > > > >> of scope for this document. > > > >> > > > >> A URL for this Internet-Draft is: > > > >> > > > > > > <http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > precate-00.txt > > > >http://w > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > precate-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-aoun-v6ops-natpt-deprecate-00.txt". > > > >> > > > >> A list of Internet-Drafts directories can be found in > > > >> > > > <http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html > > > > > > >> or > > > >> > > > > > > <ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > >ietf/1shadow-s > >ites.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-aoun-v6ops-natpt-deprecate-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. > > >> > > >> > > >> > > >> > > >> ------ End of Forwarded Message > > >> > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; x-mac-type=42494E41; x-mac-creator=4D535744 ===== From owner-v6ops@ops.ietf.org Mon Oct 11 13:35:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25442 for ; Mon, 11 Oct 2004 13:35:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH42c-000IVV-P6 for v6ops-data@psg.com; Mon, 11 Oct 2004 17:32:58 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH42Z-000IV2-KV for v6ops@ops.ietf.org; Mon, 11 Oct 2004 17:32:56 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9BHOYw07486; Mon, 11 Oct 2004 19:24:34 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Oct 2004 19:24:32 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: "'Pyda Srisuresh'" , Senthil Sivakumar Cc: "'Sham Chakravorty'" , "'Brian E Carpenter'" , "Cedric Aoun" , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Mon, 11 Oct 2004 19:24:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4AFB7.2CBD1D26" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4AFB7.2CBD1D26 Content-Type: text/plain That NAT-PT may stifle innovation is not an assumption but a deduction. As is pointed out in the draft, NAT-PT cannot support all of the current features of v6 (eg flow labels, MIPv6) and is unlikely to support any new features. If the NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to help), then all applications may well have to decide to just use the subset of features supported by NAT-PT. If they can detect that there is a NAT-PT box in the way then special case code may be needed for destinations accessed through the NAT-PT to limit the capabilities used. However if a proxy is used, all the special casing can be confined to the proxy - the original application should be able to work untramelled (i.e. as if working on a pure native v6 network when communicating with v6 addresses - v4 functionality is unchanged). Hence I think the situation as regards extra code is exactly the reverse of what you say: applications operating with proxies can be unaware and unchanged; applications operating through NAT-PT may need special case coding. The lack of compelling use cases for NAT-PT indicates that it isn't an essential mechanism. Apart from a very limited set of cases dual-stack + tunelling solves working across multiple realms. We need to get the message out that NAT-PT is not a good thing and that there are other, better solutions. That is the way to overcome resistance! Regards, Elwyn > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: 11 October 2004 14:58 > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric > [ADC:7Q30:EXCH]; 'V6OPS' > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > Folks, > > As Senthil points out, the assumption that NAT-PT deployment > will stifle > innovation in v6 seems flawed. NAT-PT is a transition > mechanism which is > essential for wider V6 deployment. Without NAT-PT, you will see bigger > resistance to deploying V6 . You need NAT-PT for legacy > applications (ex: > e-mail, ftp) to work as is across V4 and V6 realms. No change > to end-hosts or > applications. This is the attraction of NAT-PT. This is not > the same as the > proxy solution that will require applications to be > changed/recompiled. > > > cheers, > suresh > > > --- Senthil Sivakumar wrote: > > > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > > > >Three points: > > >- The object of the draft was to summarize in one place > all the problems > > >with NAT-PT rather than being yet another delta on > previous work. The > > >introduction notes that several of the points are indeed > generic address > > >translation problems. This doesn't make them any less relevant. > > > > I am fine with summarizing the issues in one draft. But the > draft points > > out those as reasons to deprecate > > which is what I am pointing out. > > > > >- The draft is specifically targeting the NAT-PT = SIIT + > DNS-ALG solution > > >intended for use as a generic inter-cloud translator. It > is clear to me > > >that a 'cut down' form has a use as a legacy v4 'server > adaptor' front end > > >where there is only one v4 address (or maybe a server > cluster) on one > > >side, it only has to handle a pre-defined set of > protocols, and it doesn't > > >need a DNS-ALG. I think this should be the subject of a > separate draft. > > > > While I agree with you the cut-down solution does not need > a DNS-ALG, I > > don't think it has to handle a > > specific set of protocols. I could still be a generic > purpose translator > > for facilitating transition. I am attaching > > a document which was one of the use case scenario we are aware of. > > > > >- The fundamental point is whether v6ops should still be > continuing to > > >support a technology which will, if widely deployed, > effectively stifle > > >innovation in v6 networks. The need for applications to > be aware that > > >NAT-PT exists effectively condemns v6 to be just v4 with > larger addresses > > >at the application level. Is this what is wanted? Or > should we really be > > >trying to put the architectural flexibility back into the Internet? > > > > I am not understanding why you say applications have to > aware of existence > > of NAT-PT. > > > > > > >It would be useful to see Shivkumar's use cases so that > they could be > > >considered for inclusion in the relevant transition > analysis. If people > > >are using NAT-PT in a particular way then we need to give > them a workable > > >alternative before ditching NAT-PT. > > > > Exactly. We should not prematurely deprecate the solution > without an > > alternative in place. > > > > Thnks > > Senthil > > > > >Regards, > > >Elwyn > > > > > > > -----Original Message----- > > > > From: Sham Chakravorty > > > [mailto:schakra@mitre.org] > > > > Sent: 09 October 2004 18:35 > > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > > [HAL02:0S00:EXCH] > > > > Subject: RE: FW: I-D > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really > doesn't earn us > > > > anything but removes one tool that could be used in specific > > > > instances. > > > > Application gateways are not in the same usage "level" as > > > > NAT-PT - they > > > > occur in different points of the network. Also, the > > > > underlying algorithm of > > > > SIIT would still be available. > > > > > > > > Sham > > > > > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org > > > > > [mailto:owner-v6ops@ops.ietf.org] On > > > Behalf > > > > Of Brian E Carpenter > > > > Sent: Saturday, October 09, 2004 9:10 AM > > > > To: Senthil Sivakumar > > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > > Subject: Re: FW: I-D > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > leave us with no > > > > workable > > > > > solution for communicating between IPv4 only > > > > networks/nodes/apps IPv6 only > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > that is the use > > > > case > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > But there is a workable alternative, which is an application > > > > level proxy. > > > > This too has its disadvantages, of course. > > > > > > > > Brian > > > > > > > > Senthil Sivakumar wrote: > > > > > I see that the draft has consolidated all the > previous drafts that > > > > > highlighted the issues > > > > > of NAT-PT and DNS ALG, which is a good thing. > However, most of the > > > > > issues mentioned > > > > > here as NAT-PT issues are known issues with address > > > > translation (NAT) > > > > > itself, so > > > > > attributing them to NAT-PT is not correct. Those should be > > > > categorized > > > > > as generic address > > > > > translation issues. > > > > > > > > > > Some specfic comments on the following issues. > > > > > > > > > > * Disruption of all protocols which embed IP > addresses (and/or > > > > > ports) in packet payloads or which apply integrity > > > > mechanisms > > > > > using IP addresses (and ports). (not NAT-PT > specific). > > > > > > > > > > * Requirement for applications to use keep alive > > > > mechanisms to > > > > > workaround connectivity issues caused by premature > > > > NAT-PT state > > > > > timeout. (not NAT-PT specific). > > > > > > > > > > * Inability to redirect packet fragments after the > > > > first with > > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > > * Constraints on network topology. (not NAT-PT > specific). > > > > > * Scalability concerns together with introduction of > > > > single point > > > > > of failure and security attack nexus.(not > NAT-PT specific). > > > > > * Lack of address mapping persistence: Some > > > > applications require > > > > > address retention between sessions. The user > > > > traffic will be > > > > > disrupted if a different mapping is used. > The use of the > > > > > DNS-ALG to create address mappings with limited > > > > lifetimes means > > > > > that applications must start using the address > > > > shortly after > > > > > the mapping is created, as well as keeping it > > > > alive once they > > > > > start using it.(not NAT-PT specific). > > > > > * Creation of a DOS threat relating to exhaustion of > > > > memory and > > > > > address/port pool resources on the > translator.(not NAT-PT > > > > > specific). > > > > > > > > > > Regarding the conclusion, I don't agree with the fact > that only > > > > > applicable scenario > > > > > is in 3G networks. During the past couple of years of my > > > > experience I > > > > > have seen > > > > > customers using it between isolated IPv6 networks to talk > > > > to existing > > > > > IPv4 networks. > > > > > A lot of cases it is not about the nodes being dual stack > > > > or not, it is > > > > > the network > > > > > that is not dual stacked for operational reasons. > > > > > > > > > > I have been gathering some inputs from the customers > who are using > > > > > NAT-PT currently > > > > > regarding this draft. I can consolidate and forward the > > > > comments if you > > > > > are interested in > > > > > knowing and understanding why they think they are moving > > > > forward with > > > > > NAT-PT. > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > leave us with > > > > > no workable > > > > > solution for communicating between IPv4 only > > > > networks/nodes/apps IPv6 only > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > that is the > > > > > use case > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > Senthil > > > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > > > >> Hi, > > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > > >> deprecation analysis. > > > > >> We would really appreciate if you could provide us your > > > > feedback on > > > > >> the initial version of the deprecation analysis by Monday > > > > October 4th. > > > > >> Regards > > > > >> Cedric Aoun > > > > >> ------ Forwarded Message > > > > >> From: > > > > >> Reply-To: > > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > > >> To: > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > >> > > > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > > > >> directories. > > > > >> > > > > >> > > > > >> > > > > >> Title : Reasons to Deprecate NAT-PT > > > > >> Author(s) : C. Aoun, E. Davies > > > > >> Filename : > draft-aoun-v6ops-natpt-deprecate-00.txt > > > > >> Pages : 24 > > > > >> Date : 2004-9-21 > > > > >> > > > > >> This document discusses reasons why use of the > specific form of > > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > > the Network > > > > >> Address Translator - Protocol Translator (NAT-PT) > > > > defined in RFC 2766 > > > > >> should be deprecated and RFC2766 moved to historic status. > > > > >> Description of an alternative protocol translation > > > > mechanism is out > > > > >> of scope for this document. > > > > >> > > > > >> A URL for this Internet-Draft is: > > > > >> > > > > > > > > > > < e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > > > > precate-00.txt > > > > > > e>http://w > > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > precate-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://w ww1.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-aoun-v6ops-natpt-deprecate-00.txt". > > > > >> > > > > >> A list of Internet-Drafts directories can be found in > > > > >> > > > > > > <http://www.ietf.org/shadow.h > tml>http://www.ietf.org/shadow.html > > > > > > > > > >> or > > > > >> > > > > > > > > > > <ftp://ftp.ietf.org > /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > > > > >ietf/1shadow-s > > >ites.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-aoun-v6ops-natpt-deprecate-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. > > > >> > > > >> > > > >> > > > >> > > > >> ------ End of Forwarded Message > > > >> > > > > > > > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; > x-mac-type=42494E41; x-mac-creator=4D535744 > > > > ===== > > > ------_=_NextPart_001_01C4AFB7.2CBD1D26 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

That NAT-PT may stifle innovation is not an = assumption but a deduction.  As is pointed out in the draft, = NAT-PT cannot support all of the current features of v6 (eg flow = labels, MIPv6) and is unlikely to support any new features.  If = the NAT-PT boxes operate autonomously (without something like STUN, = midcom or nsis to help), then all applications may well have to decide = to just use the subset of features supported by NAT-PT.  If they = can detect that there is a NAT-PT box in the way then special case code = may be needed for destinations accessed through the NAT-PT to limit the = capabilities used.

However if a proxy is used, all the special casing = can be confined to the proxy - the original application should be able = to work untramelled (i.e. as if working on a pure native v6 network = when communicating with v6 addresses - v4 functionality is = unchanged).  Hence I think the situation as regards extra code is = exactly the reverse of what you say: applications operating with = proxies can be unaware and unchanged; applications operating through = NAT-PT may need special case coding.

The lack of compelling use cases for NAT-PT indicates = that it isn't an essential mechanism. Apart from a very limited set of = cases dual-stack + tunelling solves working across multiple = realms.  We need to get the message out that NAT-PT is not a good = thing and that there are other, better solutions.  That is the way = to overcome resistance!

Regards,
Elwyn

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] =
> Sent: 11 October 2004 14:58
> To: Senthil Sivakumar; Davies, Elwyn = [HAL02:0S00:EXCH]
> Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; = Aoun, Cedric
> [ADC:7Q30:EXCH]; 'V6OPS'
> Subject: RE: FW: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> Folks,
>
> As Senthil points out, the assumption that = NAT-PT deployment
> will stifle
> innovation in v6 seems flawed. NAT-PT is a = transition
> mechanism which is
> essential for wider V6 deployment. Without = NAT-PT, you will see bigger
> resistance to deploying V6 . You need NAT-PT = for legacy
> applications (ex:
> e-mail, ftp) to work as is across V4 and V6 = realms. No change
> to end-hosts or
> applications. This is the attraction of NAT-PT. = This is not
> the same as the
> proxy solution that will require applications = to be
> changed/recompiled.
>
>
> cheers,
> suresh
>
>
> --- Senthil Sivakumar = <ssenthil@cisco.com> wrote:
>
> > At 10:16 AM 10/10/2004 +0200, Elwyn Davies = wrote:
> >
> > >Three points:
> > >- The object of the draft was to = summarize in one place
> all the problems
> > >with NAT-PT rather than being yet = another delta on
> previous work.  The
> > >introduction notes that several of the = points are indeed
> generic address
> > >translation problems.  This = doesn't make them any less relevant.
> >
> > I am fine with summarizing the issues in = one draft. But the
> draft points
> > out those as reasons to deprecate
> > which is what I am pointing out.
> >
> > >- The draft is specifically targeting = the NAT-PT =3D SIIT +
> DNS-ALG solution
> > >intended for use as a generic = inter-cloud translator.  It
> is clear to me
> > >that a 'cut down' form has a use as a = legacy v4 'server
> adaptor' front end
> > >where there is only one v4 address (or = maybe a server
> cluster) on one
> > >side, it only has to handle a = pre-defined set of
> protocols, and it doesn't
> > >need a DNS-ALG.  I think this = should be the subject of a
> separate draft.
> >
> > While I agree with you the cut-down = solution does not need
> a DNS-ALG, I
> > don't think it has to handle a
> > specific set of protocols. I could still = be a generic
> purpose translator
> > for facilitating transition. I am = attaching
> > a document which was one of the use case = scenario we are aware of.
> >
> > >- The fundamental point is whether = v6ops should still be
> continuing to
> > >support a technology which will, if = widely deployed,
> effectively stifle
> > >innovation in v6 networks.  The = need for applications to
> be aware that
> > >NAT-PT exists effectively condemns v6 = to be just v4 with
> larger addresses
> > >at the application level. Is this what = is wanted? Or
> should we really be
> > >trying to put the architectural = flexibility back into the Internet?
> >
> > I am not understanding why you say = applications have to
> aware of existence
> > of NAT-PT.
> >
> >
> > >It would be useful to see Shivkumar's = use cases so that
> they could be
> > >considered for inclusion in the = relevant transition
> analysis.  If people
> > >are using NAT-PT in a particular way = then we need to give
> them a workable
> > >alternative before ditching = NAT-PT.
> >
> > Exactly. We should not prematurely = deprecate the solution
> without an
> > alternative in place.
> >
> > Thnks
> > Senthil
> >
> > >Regards,
> > >Elwyn
> > >
> > > > -----Original = Message-----
> > > > From: Sham Chakravorty
> > > [<mailto:schakra@mitre.org>mailto:schakra@mitre.org]
> > > > Sent: 09 October 2004 = 18:35
> > > > To: 'Brian E Carpenter'; = 'Senthil Sivakumar'
> > > > Cc: Aoun, Cedric = [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn
> > > > [HAL02:0S00:EXCH]
> > > > Subject: RE: FW: I-D
> = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > I agree with Shivkumar that = deprecating NAT-PT really
> doesn't earn us
> > > > anything but removes one tool = that could be used in specific
> > > > instances.
> > > > Application gateways are not in = the same usage "level" as
> > > > NAT-PT - they
> > > > occur in different points of the = network. Also, the
> > > > underlying algorithm of
> > > > SIIT would still be = available.
> > > >
> > > > Sham
> > > >
> > > > -----Original = Message-----
> > > > From: = owner-v6ops@ops.ietf.org
> > > >
> [<mailto:owner-v6ops@ops.ietf.org= >mailto:owner-v6ops@ops.ietf.org= ] On
> > > Behalf
> > > > Of Brian E Carpenter
> > > > Sent: Saturday, October 09, 2004 = 9:10 AM
> > > > To: Senthil Sivakumar
> > > > Cc: Cedric Aoun; V6OPS; Elwyn = Davies
> > > > Subject: Re: FW: I-D
> = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > > The point I am trying to = stress is deprecating this would
> > > > leave us with no
> > > > workable
> > > > > solution for communicating = between IPv4 only
> > > > networks/nodes/apps IPv6 = only
> > > > > networks/nodes/apps. As = remote as it might seem for some,
> > > > that is the use
> > > > case
> > > > > scenario we have encountered= as the applicability of NAT-PT.
> > > >
> > > > But there is a workable = alternative, which is an application
> > > > level proxy.
> > > > This too has its disadvantages, = of course.
> > > >
> > > >      = Brian
> > > >
> > > > Senthil Sivakumar wrote:
> > > > > I see that the draft has = consolidated all the
> previous drafts that
> > > > > highlighted the = issues
> > > > > of NAT-PT and DNS ALG, = which is a good thing.
> However, most of the
> > > > > issues mentioned
> > > > > here as NAT-PT issues are = known issues with address
> > > > translation (NAT)
> > > > > itself, so
> > > > > attributing them to NAT-PT = is not correct.  Those should be
> > > > categorized
> > > > > as generic address
> > > > > translation issues.
> > > > >
> > > > > Some specfic comments on = the following issues.
> > > > >
> > > > = >      *  Disruption of all protocols = which embed IP
> addresses (and/or
> > > > = >          ports) in = packet payloads or which apply integrity
> > > > mechanisms
> > > > = >          using IP = addresses (and ports). (not NAT-PT
> specific).
> > > > >
> > > > = >       *  Requirement for = applications to use keep alive
> > > > mechanisms to
> > > > = >          workaround = connectivity issues caused by premature
> > > > NAT-PT state
> > > > = >          timeout. = (not NAT-PT specific).
> > > > >
> > > > = >        *  Inability to = redirect packet fragments after the
> > > > first with
> > > > = >          NAPT-PT. = (not NAT-PT specific).
> > > > >
> > > > >    o  = Issues which are exacerbated by the use of a DNS-ALG:
> > > > = >       *  Constraints on network = topology. (not NAT-PT
> specific).
> > > > = >       *  Scalability concerns = together with introduction of
> > > > single point
> > > > = >          of failure = and security attack nexus.(not
> NAT-PT specific).
> > > > = >       *  Lack of address = mapping persistence: Some
> > > > applications require
> > > > = >          address = retention between sessions.  The user
> > > > traffic will be
> > > > = >          disrupted if = a different mapping is used. 
> The use of the
> > > > = >          DNS-ALG to = create address mappings with limited
> > > > lifetimes means
> > > > = >          that = applications must start using the address
> > > > shortly after
> > > > = >          the mapping = is created, as well as keeping it
> > > > alive once they
> > > > = >          start using = it.(not NAT-PT specific).
> > > > = >       *  Creation of a DOS = threat relating to exhaustion of
> > > > memory and
> > > > = >          address/port = pool resources on the
> translator.(not NAT-PT
> > > > > specific).
> > > > >
> > > > > Regarding the conclusion, I = don't agree with the fact
> that only
> > > > > applicable scenario
> > > > > is in 3G networks. During = the past couple of years of my
> > > > experience I
> > > > > have seen
> > > > > customers using it between = isolated IPv6 networks to talk
> > > > to existing
> > > > > IPv4 networks.
> > > > > A lot of cases it is not = about the nodes being dual stack
> > > > or not, it is
> > > > > the network
> > > > > that is not dual stacked = for operational reasons.
> > > > >
> > > > > I have been gathering some = inputs from the customers
> who are using
> > > > > NAT-PT currently
> > > > > regarding this draft. I can = consolidate and forward the
> > > > comments if you
> > > > > are interested in
> > > > > knowing and understanding = why they think they are moving
> > > > forward with
> > > > > NAT-PT.
> > > > >
> > > > > The point I am trying to = stress is deprecating this would
> > > > leave us with
> > > > > no workable
> > > > > solution for communicating = between IPv4 only
> > > > networks/nodes/apps IPv6 = only
> > > > > networks/nodes/apps. As = remote as it might seem for some,
> > > > that is the
> > > > > use case
> > > > > scenario we have = encountered as the applicability of NAT-PT.
> > > > >
> > > > > Senthil
> > > > >
> > > > > At 10:12 AM 9/22/2004 = +0200, Cedric Aoun wrote:
> > > > >
> > > > >> Hi,
> > > > >> As discussed at IETF = 60, the WG agreed to continue the NAT-PT
> > > > >> deprecation = analysis.
> > > > >> We would really = appreciate if you could provide us your
> > > > feedback on
> > > > >> the initial version of = the deprecation analysis by Monday
> > > > October 4th.
> > > > >> Regards
> > > > >> Cedric Aoun
> > > > >> ------ Forwarded = Message
> > > > >> From: = <Internet-Drafts@ietf.org>
> > > > >> Reply-To: = <internet-drafts@ietf.org>
> > > > >> Date: Tue, 21 Sep 2004 = 21:38:33 +0200
> > > > >> To: = <i-d-announce@ietf.org>
> > > > >> Subject: I-D = ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > >>
> > > > >> A New Internet-Draft is = available from the on-line
> Internet-Drafts
> > > > >> directories.
> > > > >>
> > > > >>
> > > > >>
> > > > = >>         = Title           : = Reasons to Deprecate NAT-PT
> > > > = >>         = Author(s)       : C. Aoun, E. = Davies
> > > > = >>         = Filename        :
> draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > = >>         = Pages           : = 24
> > > > = >>         = Date            = : 2004-9-21
> > > > >>
> > > > >> This document discusses = reasons why use of the
> specific form of
> > > > >>    = IPv6-IPv4 protocol translation mechanism implemented by
> > > > the Network
> > > > >>    = Address Translator - Protocol Translator (NAT-PT)
> > > > defined in RFC 2766
> > > > >>    = should be deprecated and RFC2766 moved to historic status.
> > > > >>    = Description of an alternative protocol translation
> > > > mechanism is out
> > > > >>    of = scope for this document.
> > > > >>
> > > > >> A URL for this = Internet-Draft is:
> > > > >>
> > > >
> > >
> >
> <<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-n= atpt-d
> e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-n= atpt-de
> >
> > >
> > > > precate-00.txt
> > > >
> ><http://www.ietf.org/internet-drafts/draft-aoun-v6ops-n= atpt-d
> e>http://w
> > > = ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> > > > precate-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>https://w
ww1.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-aoun-v6ops-natpt-deprecate-00.txt".
> > > > >>
> > > > >> A list of = Internet-Drafts directories can be found in
> > > > >>
> > >
> >
> <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.h
> tml>http://www.ietf.org/shadow.html
> >
> > >
> > > > >> or
> > > > >>
> > > >
> > >
> >
> <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org
> /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/
> >
> > >
> > >ietf/1shadow-s
> > >ites.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-aoun-v6ops-natpt-deprecate-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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ------ End of Forwarded = Message
> > > >>
> > > >
> > >
> > >
> >
>
> > ATTACHMENT part 2 application/msword = name=3Dnat-pt-scenario.doc;
> x-mac-type=3D42494E41; = x-mac-creator=3D4D535744
>
>
>
> =3D=3D=3D=3D=3D
>
>
>

------_=_NextPart_001_01C4AFB7.2CBD1D26-- From owner-v6ops@ops.ietf.org Mon Oct 11 14:27:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00467 for ; Mon, 11 Oct 2004 14:27:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH4sR-000Pmu-V2 for v6ops-data@psg.com; Mon, 11 Oct 2004 18:26:31 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH4sQ-000Pmg-OE for v6ops@ops.ietf.org; Mon, 11 Oct 2004 18:26:30 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 11 Oct 2004 11:26:44 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn1-443.cisco.com [10.21.97.187]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9BIQPmR016899; Mon, 11 Oct 2004 11:26:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20041011112342.024b2928@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Oct 2004 11:26:25 -0700 To: Gert Doering From: Salman Asadullah Subject: Re: Draft on ISP broad-band deployment scenarios Cc: Pekka Savola , Adeel Ahmed , Ciprian Popoviciu , v6ops@ops.ietf.org, Patrick Grossetete In-Reply-To: <20041007164856.GJ10500@Space.Net> References: <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_138375243==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.0 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_138375243==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks for your feedback Gert. We are working on the second version of our draft and integrating all the feedback we have received. Regards, Salman At 06:48 PM 10/7/2004 +0200, Gert Doering wrote: >Hi, > >answering a specific bit out of this... > >On Fri, Sep 24, 2004 at 10:32:22AM +0300, Pekka Savola wrote: > > > This is true but we have observed many of the BB ISPs are interested in > > > deploying native IPv6, driven by new services such as VoD using > Multicast > > > and etc. Some of the examples for these BB ISPs, who are deploying IPv6 > > > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in > > > France, XS4ALL in The Netherlands and etc. > > > > Sure. But do these ISPs use a link-layer which supports multicast, > > e.g., bridged-mode DSL (I think it does..)? > > > > That is, if you do something like L2TPoE (which I think many are > > doing), doesn't that require that multicast transmission be > > duplicated (on a lower layer) in any case, causing equal amount of > > traffic as a tunneling based distribution? > >Our (SpaceNet's) DSL stuff is either PPPoE/L2TP based or ATM-PVC-based >(bridged or routed mode). > >Neither has native support for Multicast (in the sense of "the network >duplicates the packets"), so the benefits of multicasts are only >in the uplink towards the DSL aggregation routers, and possibly if >multiple users behind the same DSL line (small offices) are receiving >the same multicast data stream. > >[..] > > Extra investment is always possible, and many will certainly do it. > > The question is just how the ISPs would transition from "v4-only" to > > "v4+v6 natively". My argument is that it would be easier for the ISPs > > to start with tunneling and native v6 where possible, than to require > > through-out upgrade to native v6. > >Full ACK here. Some parts are just hard/expensive to get v6 on, >while others can be done fairly easily. So you end up tunneling >around those "difficult" bits, even if the rest of the network is >already native. > >Gert Doering > -- NetMaster >-- >Total number of prefixes smaller than registry allocations: 66629 (65398) > >SpaceNet AG Mail: netmaster@Space.Net >Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 >80807 Muenchen Fax : +49-89-32356-299 --=====================_138375243==_.ALT Content-Type: text/html; charset="us-ascii" Thanks for your feedback Gert.

We are working on the second version of our draft and integrating all the feedback we have received.

Regards,
Salman


At 06:48 PM 10/7/2004 +0200, Gert Doering wrote:
Hi,

answering a specific bit out of this...

On Fri, Sep 24, 2004 at 10:32:22AM +0300, Pekka Savola wrote:
> > This is true but we have observed many of the BB ISPs are interested in
> > deploying native IPv6, driven by new services such as VoD using Multicast
> > and etc. Some of the examples for these BB ISPs, who are deploying IPv6
> > are NTT in Japan, Spacenet in Germany, Dolphin in Switzerland, Nerim in
> > France, XS4ALL in The Netherlands and etc.
>
> Sure. But do these ISPs use a link-layer which supports multicast,
> e.g., bridged-mode DSL (I think it does..)?
>
> That is, if you do something like L2TPoE (which I think many are
> doing), doesn't that require that multicast transmission be
> duplicated (on a lower layer) in any case, causing equal amount of
> traffic as a tunneling based distribution?

Our (SpaceNet's) DSL stuff is either PPPoE/L2TP based or ATM-PVC-based
(bridged or routed mode).

Neither has native support for Multicast (in the sense of "the network
duplicates the packets"), so the benefits of multicasts are only
in the uplink towards the DSL aggregation routers, and possibly if
multiple users behind the same DSL line (small offices) are receiving
the same multicast data stream.

[..]
> Extra investment is always possible, and many will certainly do it.
> The question is just how the ISPs would transition from "v4-only" to
> "v4+v6 natively". My argument is that it would be easier for the ISPs
> to start with tunneling and native v6 where possible, than to require
> through-out upgrade to native v6.

Full ACK here. Some parts are just hard/expensive to get v6 on,
while others can be done fairly easily. So you end up tunneling
around those "difficult" bits, even if the rest of the network is
already native.

Gert Doering
       -- NetMaster
--
Total number of prefixes smaller than registry allocations: 66629 (65398)

SpaceNet AG                Mail: netmaster@Space.Net
Joseph-Dollinger-Bogen 14  Tel : +49-89-32356-0
80807 Muenchen             Fax : +49-89-32356-299
--=====================_138375243==_.ALT-- From owner-v6ops@ops.ietf.org Mon Oct 11 14:50:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03223 for ; Mon, 11 Oct 2004 14:50:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH4v2-00006k-KD for v6ops-data@psg.com; Mon, 11 Oct 2004 18:29:12 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH4v1-00006X-HK for v6ops@ops.ietf.org; Mon, 11 Oct 2004 18:29:11 +0000 Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-4.cisco.com with ESMTP; 11 Oct 2004 11:29:11 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn1-443.cisco.com [10.21.97.187]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id i9BIT7mR017563; Mon, 11 Oct 2004 11:29:08 -0700 (PDT) Message-Id: <4.3.2.7.2.20041011112643.025eed28@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 11 Oct 2004 11:29:07 -0700 To: Alexander Koch From: Salman Asadullah Subject: Re: Draft on ISP broad-band deployment scenarios Cc: Gert Doering , Pekka Savola , v6ops@ops.ietf.org In-Reply-To: <20041007175711.GB25383@shekinah.ip.tiscali.net> References: <20041007164856.GJ10500@Space.Net> <4.3.2.7.2.20040923134651.026cfe20@ce-nfs-1.cisco.com> <20041007164856.GJ10500@Space.Net> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_138537125==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_138537125==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Thanks for your feedback Alexander. We are working on the second version of our draft and integrating all the feedback we have received. Regards, Salman At 07:57 PM 10/7/2004 +0200, Alexander Koch wrote: >All, > >On Thu, 7 October 2004 18:48:56 +0200, Gert Doering wrote: > > answering a specific bit out of this... > >that applies for me, too. > > > Neither has native support for Multicast (in the sense of "the network > > duplicates the packets"), so the benefits of multicasts are only > > in the uplink towards the DSL aggregation routers, and possibly if > > multiple users behind the same DSL line (small offices) are receiving > > the same multicast data stream. > >That being said, take also into consideration that bitstream >access is not widely available yet in Europe or the invests >are just not worth it. so the next option would be to get the >traffic via L2TP, and the multicast buys you absolutely nothing >as too many DSL providers effectively do not save a penny. And >of course this applies to IPv4, and I do not see it changing >anytime soon. (Despite the effort by BBC, for example, or AMT >which is promising, all v4 though) > > > [..] > > > Extra investment is always possible, and many will certainly do it. > > > The question is just how the ISPs would transition from "v4-only" to > > > "v4+v6 natively". My argument is that it would be easier for the ISPs > > > to start with tunneling and native v6 where possible, than to require > > > through-out upgrade to native v6. > > > > Full ACK here. Some parts are just hard/expensive to get v6 on, > > while others can be done fairly easily. So you end up tunneling > > around those "difficult" bits, even if the rest of the network is > > already native. > >Take the Juniper ERX for an example. J's licensing model is >a major showstopper for several operators to even consider >providing IPv6 to their end users. ;-\ With the typical end >user setup if the typical vendors (J, Redback, Cisco, you >name it) get this working normally that will be the main >driving factor in my view for operators to actually try it >at all. > >Mind you, my 2 cents worth, we run IPv6 natively for some >time now in all our core, and that is what we encounter when >trying to convince the powers that be. AS-TISCALI-V6PEERS. :-) > >Regards, >Alexander > >-- >Alexander Koch / ako4-ripe >Tiscali Int., Peering Coordination >Phone +49 6103 916 480, Fax +49 6103 916 464 --=====================_138537125==_.ALT Content-Type: text/html; charset="us-ascii" Thanks for your feedback Alexander.

We are working on the second version of our draft and integrating all the feedback we have received.

Regards,
Salman


At 07:57 PM 10/7/2004 +0200, Alexander Koch wrote:
All,

On Thu, 7 October 2004 18:48:56 +0200, Gert Doering wrote:
> answering a specific bit out of this...

that applies for me, too.

> Neither has native support for Multicast (in the sense of "the network
> duplicates the packets"), so the benefits of multicasts are only
> in the uplink towards the DSL aggregation routers, and possibly if
> multiple users behind the same DSL line (small offices) are receiving
> the same multicast data stream.

That being said, take also into consideration that bitstream
access is not widely available yet in Europe or the invests
are just not worth it. so the next option would be to get the
traffic via L2TP, and the multicast buys you absolutely nothing
as too many DSL providers effectively do not save a penny. And
of course this applies to IPv4, and I do not see it changing
anytime soon. (Despite the effort by BBC, for example, or AMT
which is promising, all v4 though)

> [..]
> > Extra investment is always possible, and many will certainly do it.
> > The question is just how the ISPs would transition from "v4-only" to
> > "v4+v6 natively". My argument is that it would be easier for the ISPs
> > to start with tunneling and native v6 where possible, than to require
> > through-out upgrade to native v6.
>
> Full ACK here. Some parts are just hard/expensive to get v6 on,
> while others can be done fairly easily. So you end up tunneling
> around those "difficult" bits, even if the rest of the network is
> already native.

Take the Juniper ERX for an example. J's licensing model is
a major showstopper for several operators to even consider
providing IPv6 to their end users. ;-\ With the typical end
user setup if the typical vendors (J, Redback, Cisco, you
name it) get this working normally that will be the main
driving factor in my view for operators to actually try it
at all.

Mind you, my 2 cents worth, we run IPv6 natively for some
time now in all our core, and that is what we encounter when
trying to convince the powers that be. AS-TISCALI-V6PEERS. :-)

Regards,
Alexander

--
Alexander Koch <koch@tiscali.net> / ako4-ripe
Tiscali Int., Peering Coordination
Phone +49 6103 916 480, Fax +49 6103 916 464
--=====================_138537125==_.ALT-- From owner-v6ops@ops.ietf.org Mon Oct 11 15:30:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08054 for ; Mon, 11 Oct 2004 15:30:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH5qM-0006hY-I0 for v6ops-data@psg.com; Mon, 11 Oct 2004 19:28:26 +0000 Received: from [130.230.4.14] (helo=mail2.cs.tut.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH4rb-000Pep-Ob for v6ops@ops.ietf.org; Mon, 11 Oct 2004 18:25:39 +0000 Received: from viherkiuru (viherkiuru.cs.tut.fi [130.230.4.36]) by mail2.cs.tut.fi (Postfix) with SMTP id B4F9E157931 for ; Mon, 11 Oct 2004 21:25:38 +0300 (EEST) Received: by viherkiuru (sSMTP sendmail emulation); Mon, 11 Oct 2004 21:25:38 EEST To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) References: From: Heikki Vatiainen Date: 11 Oct 2004 21:25:38 +0300 In-Reply-To: Message-ID: Lines: 115 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Here are my comments on the enterprise network analysis draft. They are based on our experience on enabling IPv6 on a part of our university's network. What we have been doing falls nicely under the wide-scale dual-stack deployment category with work-arounds to cope with routing infrastructure that is not IPv6 capable. Here are the comments: 4.4.2 Deploy a parallel IPv6 infrastructure [cut] Such an approach means acquiring additional hardware, but it has the advantage that the existing IPv4 routing platforms are not disturbed by the introduction of IPv6. I think dual stack has been available long enough that the potential for disturbance is not great enough to justify a parallel infrasturcture for IPv6. In fact, I would recommend that parallel infrasturcture is only built if no other options, such as upgrading to dual stack routers, are available. The problems we have noticed with running a parallel infrastructure touch many areas. I try to enumerate our findings in the following paragraphs. The parallel infrastructure forces you to have two times the documentation about the network. If e.g. intra-organization packet filtering is done, you have to literally think and check twice that the filters are set up as required. With dual stack you may need to create two sets of filters, one for IPv4 and one for IPv6, but at least they apply to the same interface on the same router. If the network is built using VLANs one can extend (trunk) the VLANs to the new IPv6-only routers. If the new IPv6 routers are physically and/or network topologically close to the existing IPv4 routers, this may be easy to accomplish. The fourth paragraph discusses the use of one router to serve many VLANs by "collapsing" them to one router interface. If the VLANs are not already topologically close to the new IPv6 router one has to grow the existing VLAN coverage. Nobody wants to do this since this is yet another step to a VLAN spaghetti network. When thinking about the routers, IPv6-only router may cause surprisingly many problems with network and router management. Our IPv6 only router does not do at least SNMP, Syslog or NTP over IPv6 transport. One may think this is only a short term problem, but the router is only half of the problem. The other half are the management applications that are used to monitor and manage the routers. If dual stack routers are used, management applications can use IPv4 transport making the lack of IPv6 transport a less or even a non problem. In conclusion, I think building a parallel IPv6 infrastructure initially looks like a non-disturbing approach but a closer looks shows that it does contains many issues that may cause disturbance later on. Finally, the last paragraph of 4.4.2 mentions that the parallel approach should be viewed only as an interim step. The history shows that interim tends to become Integrated or permanent or otherwise established, so why not use the resources to do dual stack. 7.3.1 Obtaining external connectivity [cut] It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] for an enterprise deployment. The enterprise has a requirement for long-term, stable IPv6 connectivity. 6to4 and the tunnel broker are more appropriate for SOHO or single node environments. Use of 6to4 also prevents the enterprise adopting aggregatable global IPv6 addressing from the outset. I think the stability and availability of 6to4 relays is more of a problem than the availability of stable 6to4 prefix. I do not see enterprise chancing its IPv4 addressing and thus is 6to4 prefix very often. However, with 6to4 the enterprise is putting its reachability towards non-6to4 IPv6 Internet into hands of the closest 6to4 relay operator. This should not cause problems if the relay is well supported. The reachability from the non-6to4 IPv6 Internet back to the enterprise depends on the relay closest to whoever someone from the enterprise was communicating with. I would prefer tunnel broker over 6to4 in the draft. 7.5.2 Supporting remote access [cut] Such an aid may be either a tunnel broker [TBRK], ideally one that supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If a 6to4 relay is offered, the site should be aware of security issues with operating 6to4 relays [cite ref?]. I see enterprise's user working off-site as someone who establishes a VPN connection back to the enterprise. When the VPN connection has been established, the user gets an IP address from the enterprise and all or some of the traffic is tunneled back to the enterprise over the VPN connection. Even if the user is behind a NAT he can still access 6to4 relay over the VPN connection. The 6to4 relay could even use the well-known anycast address if all traffic is tunneled or the route towards the well known address can be set to point to the tunnel. If the user does not have VPN access and NATs and other filters and packet manglers cause problems then the enterprise should provide VPN service for the user. Advanced VPN implementations may support IPv6 over IPv4 VPNs directly making the need for remote access aid non-existent. -- Heikki Vatiainen * hessu@cs.tut.fi Tampere University of Technology * Tampere, Finland From owner-v6ops@ops.ietf.org Mon Oct 11 17:02:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27439 for ; Mon, 11 Oct 2004 17:02:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CH7HP-000HfN-FP for v6ops-data@psg.com; Mon, 11 Oct 2004 21:00:27 +0000 Received: from [195.212.29.153] (helo=mtagate4.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CH7HN-000Hew-MW for v6ops@ops.ietf.org; Mon, 11 Oct 2004 21:00:26 +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 i9BL0NLi107598 for ; Mon, 11 Oct 2004 21:00:23 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9BL0Nu0108284 for ; Mon, 11 Oct 2004 23:00:23 +0200 Received: from zurich.ibm.com (sig-9-145-250-211.de.ibm.com [9.145.250.211]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id XAA67568 for ; Mon, 11 Oct 2004 23:00:21 +0200 Message-ID: <416AF467.3020408@zurich.ibm.com> Date: Mon, 11 Oct 2004 23:00:23 +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: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit I have a number of concerns about this document, and some smaller items. 1) My first concern is that somehow it misses the most important case and the way I would recommend any enterprise to go. In the terminology of the document that case is ====================================================== |Application |Host 1 |Service |Host 2 |Application | |----------- |Network|Provider|Network|---------- | | Host 1 OS | | | | Host 2 OS | =====================================+================ |Dual or IPv4| | |Dual IP|Dual IPv4| 0 | ---- |Dual IP|Dual IP | or |---- or ----| | Dual | | |v4 only|Dual IPv4| ====================================================== In other words, why would an enterprise choose to paint itself into any of the awkward corners of the other 13 scenarios? Just go for a dual stack operating system and routing system, and keep calling your software suppliers until they upgrade to the new API. Why make it harder than it needs to be? In fact, sections 4 and 7 are written in this spirit - they refer essentially to what I have shown above as secnario 0. I just don't get what are the drivers for the other 13 scenarios. Why would an enterprise accept any of them, rather than beating on its suppliers for dual stack solutions? 2) My second main concern is these two statements: > 4.1 Phased Dual-Stack Deployment ... > In this document we do not advocate or discuss the deployment of > Unique Local IPv6 Unicast Addresses [ULA]. > 7.3.2 Obtaining global IPv6 address space ... > Unique Local Addressing [ULAs] should not be used for enterprise > networks. Not true and not OK. They were to a considerable extent designed for enterprise networks. There will be a draft soon that discusses how they could be used in enterprise networks, precisely to respond to some of the reasons people use NATs. It isn't OK for this draft to make such a statement about ULAs. The simplest solution is to remove both these references to ULAs. 3) My third main concern is that the draft doesn't discuss the deployment of DMZs, which are a feature of all major enterprise networks. A related point is that it doesn't discuss how an enterprise will offer an IPv6 "web presence" (or email presence) regardless of the state of its internal transition. Maybe converting all its DMZ servers to dual stack would be the first essential step for many enterprises. Details: The summary at the end of section 1 doesn't mention section 7. > 4.6 Other considerations > > There are some identified issues with turning IPv6 on by default, > including application connection delays, poor connectivity, and > network insecurity, as discussed in [V6DEF]. The issues can be > worked around or mitigated by following the advice in [V6DEF]. > > At least DNS, network management, and security policies need to be covered. > 5.1 Internal versus External Tunnel-End-Point > > > The upstream provider could have already deployed some IPv6 > service, either native IPv6 in its backbone or in the access > network, or a combination of both. Also, or alternatively, could > have deployed one or several transition mechanisms based upon > tunnels, for example in the case where the access network doesn't > support IPv6. In this case, the enterprise could decide to use > those available transition services from the ISP. However, this > will usually mean that the each of the different nodes in the > network will have their own IPv6-in-IPv4 tunnel. Then, the IPv6 > intranet communication will not be efficient, as it will require > all the traffic to be forwarded by the IPv4 infrastructure to the > Tunnel-End-Point located at the ISP. This would be unacceptable to 99% of enterprise security managers. > 7.3.1 Obtaining external connectivity > > > The enterprise service provider would typically be a > topographically close (to minimize connectivity RTT) IPv6 provider > that is able to provide an IPv6 upstream link. > > It would be expected that the enterprise would use either native > IPv6 upstream connectivity or, in its absence, a manually > configured tunnel [BCNF] to the upstream provider. > > It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] > for an enterprise deployment. The enterprise has a requirement for > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker > are more appropriate for SOHO or single node environments. Sorry, but that's wrong. First of all, single-node 6to4 isn't an IETF solution - it has never been documented - so it's not accurate to cite the RFC. Secondly, 6to4 as described in RFC 3056 will work just fine for an enterprise - until the day its own ISP provides native connectivity, of course. I'd say a SOHO user has less chance of setting up RFC 3056 correctly than a large enterprise. > ...Use of > 6to4 also prevents the enterprise adopting aggregatable global IPv6 > addressing from the outset. True... but so what? It's a solution you use only as long as you have to, and then you switch to an aggregatable prefix. This wouldn't affect internal network usage at all, apart from updating the prefix. > 7.3.2 Obtaining global IPv6 address space > > > The enterprise will obtain global IPv6 address space from its > selected upstream provider, as provider assigned (PA) address > space. > > The enterprise should receive at least a /48 allocation from its > provider, as described in [ALLOC]. I think you should refer to RIR policy directly; that RFC is only a recommendation to the RIRs. > 7.4.6 IPv4-IPv6 interworking > > > In the case of an IPv6 only node in an IPv6-dominant or dual-stack > enterprise, wishing to communicate with external IPv4-only systems, > some interworking (translation) method is required. The > translation could be applied at Layer 3 (e.g. [NAT-PT]), Layer 4 > (e.g. [SOCKS]) or Layer 7 (a dual-stack application layer gateway - > ALG). I would also refer to a Layer 7 proxy. Also, since we seem to be about to deprecate NAT-PT, it probably should not be mentioned. > 7.5.2 Supporting remote access > > Where an enterprise's users may be working off-site, and their > transient ISP has no IPv6 support (natively or through transition > aids) the enterprise should consider deploying its own transition > (remote access) aid. > > Such an aid may be either a tunnel broker [TBRK], ideally one that > supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site should be aware of security > issues with operating 6to4 relays [cite ref?]. I think it's much more likely to be an IPSEC or IP-over-TLS tunnel, which could be v6-in-v4 or v6-in-v6. That's how many enterprises offer secure IPv4 "call home" today. > 8 Applicable Transition Mechanisms ... > Basic Configured Tunnels: > > 6to4: > > Tunnel Broker: > > Teredo: > > DSTM: > > ISATAP: > > NAT-PT: Well, again, if we are deprecating NAT-PT, we can't include it here. And the ALG/proxy alternative to NAT-PT needs to be listed. Probably, IPv4-in-IPv6 tunnels should be listed too. > > ====================================================================== > |Application |Host 1 |Service |Host 2 |Application | Recommended > |----------- |Network|Provider|Network|---------- | Transition > | Host 1 OS | | | | Host 2 OS | Mechanism > =====================================+================================ You need to give some rationale for the recommendations in the last column. But in any case, my main concern 1) applies to this whole table. Scenario 0 is the interesting one, and it's missing. The issue with NAT-PT applies to the entries for "translation", all of which I would replace by "ALG/proxy." > Appendix B - Crisis Management Network Scenarios What's the value-add of this material in this document? It seems that it should be published separately. Brian From owner-v6ops@ops.ietf.org Mon Oct 11 20:20:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13042 for ; Mon, 11 Oct 2004 20:20:33 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHAND-000DAp-At for v6ops-data@psg.com; Tue, 12 Oct 2004 00:18:39 +0000 Received: from [203.254.224.33] (helo=mailout3.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHANA-000DAJ-QH for v6ops@ops.ietf.org; Tue, 12 Oct 2004 00:18:37 +0000 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5G006NA3IYX0@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 12 Oct 2004 09:18:34 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5G007573H8FL@mailout3.samsung.com> for v6ops@ops.ietf.org; Tue, 12 Oct 2004 09:17:33 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I5G0056G3H6IS@mmp2.samsung.com> for v6ops@ops.ietf.org; Tue, 12 Oct 2004 09:17:32 +0900 (KST) Date: Tue, 12 Oct 2004 09:18:55 +0900 From: Soohong Daniel Park Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-reply-to: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.nortel.com> To: Elwyn Davies , "'Pyda Srisuresh'" , Senthil Sivakumar Cc: "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: multipart/alternative; boundary="Boundary_(ID_/JGxvgwrYHofTlOerpw7hg)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_/JGxvgwrYHofTlOerpw7hg) Content-type: text/plain; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txtIt was not the original goal of NAT-PT to support all of the IPv6 features. It is one of possible transition mechanisms althouth there are several restrictions originated from the traditional NAT architecture. Nevertheless, I know several sites are using NAT-PT efficiently on their use cases. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. -----Original Message----- From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Elwyn Davies Sent: Tuesday, October 12, 2004 2:25 AM To: 'Pyda Srisuresh'; Senthil Sivakumar Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS' Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt That NAT-PT may stifle innovation is not an assumption but a deduction. As is pointed out in the draft, NAT-PT cannot support all of the current features of v6 (eg flow labels, MIPv6) and is unlikely to support any new features. If the NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to help), then all applications may well have to decide to just use the subset of features supported by NAT-PT. If they can detect that there is a NAT-PT box in the way then special case code may be needed for destinations accessed through the NAT-PT to limit the capabilities used. However if a proxy is used, all the special casing can be confined to the proxy - the original application should be able to work untramelled (i.e. as if working on a pure native v6 network when communicating with v6 addresses - v4 functionality is unchanged). Hence I think the situation as regards extra code is exactly the reverse of what you say: applications operating with proxies can be unaware and unchanged; applications operating through NAT-PT may need special case coding. The lack of compelling use cases for NAT-PT indicates that it isn't an essential mechanism. Apart from a very limited set of cases dual-stack + tunelling solves working across multiple realms. We need to get the message out that NAT-PT is not a good thing and that there are other, better solutions. That is the way to overcome resistance! Regards, Elwyn > -----Original Message----- > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > Sent: 11 October 2004 14:58 > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric > [ADC:7Q30:EXCH]; 'V6OPS' > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > Folks, > > As Senthil points out, the assumption that NAT-PT deployment > will stifle > innovation in v6 seems flawed. NAT-PT is a transition > mechanism which is > essential for wider V6 deployment. Without NAT-PT, you will see bigger > resistance to deploying V6 . You need NAT-PT for legacy > applications (ex: > e-mail, ftp) to work as is across V4 and V6 realms. No change > to end-hosts or > applications. This is the attraction of NAT-PT. This is not > the same as the > proxy solution that will require applications to be > changed/recompiled. > > > cheers, > suresh > > > --- Senthil Sivakumar wrote: > > > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > > > >Three points: > > >- The object of the draft was to summarize in one place > all the problems > > >with NAT-PT rather than being yet another delta on > previous work. The > > >introduction notes that several of the points are indeed > generic address > > >translation problems. This doesn't make them any less relevant. > > > > I am fine with summarizing the issues in one draft. But the > draft points > > out those as reasons to deprecate > > which is what I am pointing out. > > > > >- The draft is specifically targeting the NAT-PT = SIIT + > DNS-ALG solution > > >intended for use as a generic inter-cloud translator. It > is clear to me > > >that a 'cut down' form has a use as a legacy v4 'server > adaptor' front end > > >where there is only one v4 address (or maybe a server > cluster) on one > > >side, it only has to handle a pre-defined set of > protocols, and it doesn't > > >need a DNS-ALG. I think this should be the subject of a > separate draft. > > > > While I agree with you the cut-down solution does not need > a DNS-ALG, I > > don't think it has to handle a > > specific set of protocols. I could still be a generic > purpose translator > > for facilitating transition. I am attaching > > a document which was one of the use case scenario we are aware of. > > > > >- The fundamental point is whether v6ops should still be > continuing to > > >support a technology which will, if widely deployed, > effectively stifle > > >innovation in v6 networks. The need for applications to > be aware that > > >NAT-PT exists effectively condemns v6 to be just v4 with > larger addresses > > >at the application level. Is this what is wanted? Or > should we really be > > >trying to put the architectural flexibility back into the Internet? > > > > I am not understanding why you say applications have to > aware of existence > > of NAT-PT. > > > > > > >It would be useful to see Shivkumar's use cases so that > they could be > > >considered for inclusion in the relevant transition > analysis. If people > > >are using NAT-PT in a particular way then we need to give > them a workable > > >alternative before ditching NAT-PT. > > > > Exactly. We should not prematurely deprecate the solution > without an > > alternative in place. > > > > Thnks > > Senthil > > > > >Regards, > > >Elwyn > > > > > > > -----Original Message----- > > > > From: Sham Chakravorty > > > [mailto:schakra@mitre.org] > > > > Sent: 09 October 2004 18:35 > > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > > [HAL02:0S00:EXCH] > > > > Subject: RE: FW: I-D > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really > doesn't earn us > > > > anything but removes one tool that could be used in specific > > > > instances. > > > > Application gateways are not in the same usage "level" as > > > > NAT-PT - they > > > > occur in different points of the network. Also, the > > > > underlying algorithm of > > > > SIIT would still be available. > > > > > > > > Sham > > > > > > > > -----Original Message----- > > > > From: owner-v6ops@ops.ietf.org > > > > > [mailto:owner-v6ops@ops.ietf.org] On > > > Behalf > > > > Of Brian E Carpenter > > > > Sent: Saturday, October 09, 2004 9:10 AM > > > > To: Senthil Sivakumar > > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > > Subject: Re: FW: I-D > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > leave us with no > > > > workable > > > > > solution for communicating between IPv4 only > > > > networks/nodes/apps IPv6 only > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > that is the use > > > > case > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > But there is a workable alternative, which is an application > > > > level proxy. > > > > This too has its disadvantages, of course. > > > > > > > > Brian > > > > > > > > Senthil Sivakumar wrote: > > > > > I see that the draft has consolidated all the > previous drafts that > > > > > highlighted the issues > > > > > of NAT-PT and DNS ALG, which is a good thing. > However, most of the > > > > > issues mentioned > > > > > here as NAT-PT issues are known issues with address > > > > translation (NAT) > > > > > itself, so > > > > > attributing them to NAT-PT is not correct. Those should be > > > > categorized > > > > > as generic address > > > > > translation issues. > > > > > > > > > > Some specfic comments on the following issues. > > > > > > > > > > * Disruption of all protocols which embed IP > addresses (and/or > > > > > ports) in packet payloads or which apply integrity > > > > mechanisms > > > > > using IP addresses (and ports). (not NAT-PT > specific). > > > > > > > > > > * Requirement for applications to use keep alive > > > > mechanisms to > > > > > workaround connectivity issues caused by premature > > > > NAT-PT state > > > > > timeout. (not NAT-PT specific). > > > > > > > > > > * Inability to redirect packet fragments after the > > > > first with > > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > > * Constraints on network topology. (not NAT-PT > specific). > > > > > * Scalability concerns together with introduction of > > > > single point > > > > > of failure and security attack nexus.(not > NAT-PT specific). > > > > > * Lack of address mapping persistence: Some > > > > applications require > > > > > address retention between sessions. The user > > > > traffic will be > > > > > disrupted if a different mapping is used. > The use of the > > > > > DNS-ALG to create address mappings with limited > > > > lifetimes means > > > > > that applications must start using the address > > > > shortly after > > > > > the mapping is created, as well as keeping it > > > > alive once they > > > > > start using it.(not NAT-PT specific). > > > > > * Creation of a DOS threat relating to exhaustion of > > > > memory and > > > > > address/port pool resources on the > translator.(not NAT-PT > > > > > specific). > > > > > > > > > > Regarding the conclusion, I don't agree with the fact > that only > > > > > applicable scenario > > > > > is in 3G networks. During the past couple of years of my > > > > experience I > > > > > have seen > > > > > customers using it between isolated IPv6 networks to talk > > > > to existing > > > > > IPv4 networks. > > > > > A lot of cases it is not about the nodes being dual stack > > > > or not, it is > > > > > the network > > > > > that is not dual stacked for operational reasons. > > > > > > > > > > I have been gathering some inputs from the customers > who are using > > > > > NAT-PT currently > > > > > regarding this draft. I can consolidate and forward the > > > > comments if you > > > > > are interested in > > > > > knowing and understanding why they think they are moving > > > > forward with > > > > > NAT-PT. > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > leave us with > > > > > no workable > > > > > solution for communicating between IPv4 only > > > > networks/nodes/apps IPv6 only > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > that is the > > > > > use case > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > Senthil > > > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > > > >> Hi, > > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > > >> deprecation analysis. > > > > >> We would really appreciate if you could provide us your > > > > feedback on > > > > >> the initial version of the deprecation analysis by Monday > > > > October 4th. > > > > >> Regards > > > > >> Cedric Aoun > > > > >> ------ Forwarded Message > > > > >> From: > > > > >> Reply-To: > > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > > >> To: > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > >> > > > > >> A New Internet-Draft is available from the on-line > Internet-Drafts > > > > >> directories. > > > > >> > > > > >> > > > > >> > > > > >> Title : Reasons to Deprecate NAT-PT > > > > >> Author(s) : C. Aoun, E. Davies > > > > >> Filename : > draft-aoun-v6ops-natpt-deprecate-00.txt > > > > >> Pages : 24 > > > > >> Date : 2004-9-21 > > > > >> > > > > >> This document discusses reasons why use of the > specific form of > > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > > the Network > > > > >> Address Translator - Protocol Translator (NAT-PT) > > > > defined in RFC 2766 > > > > >> should be deprecated and RFC2766 moved to historic status. > > > > >> Description of an alternative protocol translation > > > > mechanism is out > > > > >> of scope for this document. > > > > >> > > > > >> A URL for this Internet-Draft is: > > > > >> > > > > > > > > > > < e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > > > > precate-00.txt > > > > > > e>http://w > > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > precate-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://w ww1.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-aoun-v6ops-natpt-deprecate-00.txt". > > > > >> > > > > >> A list of Internet-Drafts directories can be found in > > > > >> > > > > > > <http://www.ietf.org/shadow.h > tml>http://www.ietf.org/shadow.html > > > > > > > > > >> or > > > > >> > > > > > > > > > > <ftp://ftp.ietf.org > /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > > > > >ietf/1shadow-s > > >ites.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-aoun-v6ops-natpt-deprecate-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. > > > >> > > > >> > > > >> > > > >> > > > >> ------ End of Forwarded Message > > > >> > > > > > > > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; > x-mac-type=42494E41; x-mac-creator=4D535744 > > > > ===== > > > --Boundary_(ID_/JGxvgwrYHofTlOerpw7hg) Content-type: text/html; charset=ks_c_5601-1987 Content-Transfer-Encoding: 7BIT RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
It was not the original goal of NAT-PT to support all of the IPv6 features.
It is one of possible transition mechanisms althouth there are several
restrictions originated from the traditional NAT architecture.
 
Nevertheless, I know several sites are using NAT-PT efficiently on their use cases.
 
 

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.

-----Original Message-----
From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Elwyn Davies
Sent: Tuesday, October 12, 2004 2:25 AM
To: 'Pyda Srisuresh'; Senthil Sivakumar
Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS'
Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt

That NAT-PT may stifle innovation is not an assumption but a deduction.  As is pointed out in the draft, NAT-PT cannot support all of the current features of v6 (eg flow labels, MIPv6) and is unlikely to support any new features.  If the NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to help), then all applications may well have to decide to just use the subset of features supported by NAT-PT.  If they can detect that there is a NAT-PT box in the way then special case code may be needed for destinations accessed through the NAT-PT to limit the capabilities used.

However if a proxy is used, all the special casing can be confined to the proxy - the original application should be able to work untramelled (i.e. as if working on a pure native v6 network when communicating with v6 addresses - v4 functionality is unchanged).  Hence I think the situation as regards extra code is exactly the reverse of what you say: applications operating with proxies can be unaware and unchanged; applications operating through NAT-PT may need special case coding.

The lack of compelling use cases for NAT-PT indicates that it isn't an essential mechanism. Apart from a very limited set of cases dual-stack + tunelling solves working across multiple realms.  We need to get the message out that NAT-PT is not a good thing and that there are other, better solutions.  That is the way to overcome resistance!

Regards,
Elwyn

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> Sent: 11 October 2004 14:58
> To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric
> [ADC:7Q30:EXCH]; 'V6OPS'
> Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> Folks,
>
> As Senthil points out, the assumption that NAT-PT deployment
> will stifle
> innovation in v6 seems flawed. NAT-PT is a transition
> mechanism which is
> essential for wider V6 deployment. Without NAT-PT, you will see bigger
> resistance to deploying V6 . You need NAT-PT for legacy
> applications (ex:
> e-mail, ftp) to work as is across V4 and V6 realms. No change
> to end-hosts or
> applications. This is the attraction of NAT-PT. This is not
> the same as the
> proxy solution that will require applications to be
> changed/recompiled.
>
>
> cheers,
> suresh
>
>
> --- Senthil Sivakumar <ssenthil@cisco.com> wrote:
>
> > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote:
> >
> > >Three points:
> > >- The object of the draft was to summarize in one place
> all the problems
> > >with NAT-PT rather than being yet another delta on
> previous work.  The
> > >introduction notes that several of the points are indeed
> generic address
> > >translation problems.  This doesn't make them any less relevant.
> >
> > I am fine with summarizing the issues in one draft. But the
> draft points
> > out those as reasons to deprecate
> > which is what I am pointing out.
> >
> > >- The draft is specifically targeting the NAT-PT = SIIT +
> DNS-ALG solution
> > >intended for use as a generic inter-cloud translator.  It
> is clear to me
> > >that a 'cut down' form has a use as a legacy v4 'server
> adaptor' front end
> > >where there is only one v4 address (or maybe a server
> cluster) on one
> > >side, it only has to handle a pre-defined set of
> protocols, and it doesn't
> > >need a DNS-ALG.  I think this should be the subject of a
> separate draft.
> >
> > While I agree with you the cut-down solution does not need
> a DNS-ALG, I
> > don't think it has to handle a
> > specific set of protocols. I could still be a generic
> purpose translator
> > for facilitating transition. I am attaching
> > a document which was one of the use case scenario we are aware of.
> >
> > >- The fundamental point is whether v6ops should still be
> continuing to
> > >support a technology which will, if widely deployed,
> effectively stifle
> > >innovation in v6 networks.  The need for applications to
> be aware that
> > >NAT-PT exists effectively condemns v6 to be just v4 with
> larger addresses
> > >at the application level. Is this what is wanted? Or
> should we really be
> > >trying to put the architectural flexibility back into the Internet?
> >
> > I am not understanding why you say applications have to
> aware of existence
> > of NAT-PT.
> >
> >
> > >It would be useful to see Shivkumar's use cases so that
> they could be
> > >considered for inclusion in the relevant transition
> analysis.  If people
> > >are using NAT-PT in a particular way then we need to give
> them a workable
> > >alternative before ditching NAT-PT.
> >
> > Exactly. We should not prematurely deprecate the solution
> without an
> > alternative in place.
> >
> > Thnks
> > Senthil
> >
> > >Regards,
> > >Elwyn
> > >
> > > > -----Original Message-----
> > > > From: Sham Chakravorty
> > > [<mailto:schakra@mitre.org>mailto:schakra@mitre.org]
> > > > Sent: 09 October 2004 18:35
> > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar'
> > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn
> > > > [HAL02:0S00:EXCH]
> > > > Subject: RE: FW: I-D
> ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > I agree with Shivkumar that deprecating NAT-PT really
> doesn't earn us
> > > > anything but removes one tool that could be used in specific
> > > > instances.
> > > > Application gateways are not in the same usage "level" as
> > > > NAT-PT - they
> > > > occur in different points of the network. Also, the
> > > > underlying algorithm of
> > > > SIIT would still be available.
> > > >
> > > > Sham
> > > >
> > > > -----Original Message-----
> > > > From: owner-v6ops@ops.ietf.org
> > > >
> [<mailto:owner-v6ops@ops.ietf.org>mailto:owner-v6ops@ops.ietf.org] On
> > > Behalf
> > > > Of Brian E Carpenter
> > > > Sent: Saturday, October 09, 2004 9:10 AM
> > > > To: Senthil Sivakumar
> > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies
> > > > Subject: Re: FW: I-D
> ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > > The point I am trying to stress is deprecating this would
> > > > leave us with no
> > > > workable
> > > > > solution for communicating between IPv4 only
> > > > networks/nodes/apps IPv6 only
> > > > > networks/nodes/apps. As remote as it might seem for some,
> > > > that is the use
> > > > case
> > > > > scenario we have encountered as the applicability of NAT-PT.
> > > >
> > > > But there is a workable alternative, which is an application
> > > > level proxy.
> > > > This too has its disadvantages, of course.
> > > >
> > > >      Brian
> > > >
> > > > Senthil Sivakumar wrote:
> > > > > I see that the draft has consolidated all the
> previous drafts that
> > > > > highlighted the issues
> > > > > of NAT-PT and DNS ALG, which is a good thing.
> However, most of the
> > > > > issues mentioned
> > > > > here as NAT-PT issues are known issues with address
> > > > translation (NAT)
> > > > > itself, so
> > > > > attributing them to NAT-PT is not correct.  Those should be
> > > > categorized
> > > > > as generic address
> > > > > translation issues.
> > > > >
> > > > > Some specfic comments on the following issues.
> > > > >
> > > > >      *  Disruption of all protocols which embed IP
> addresses (and/or
> > > > >          ports) in packet payloads or which apply integrity
> > > > mechanisms
> > > > >          using IP addresses (and ports). (not NAT-PT
> specific).
> > > > >
> > > > >       *  Requirement for applications to use keep alive
> > > > mechanisms to
> > > > >          workaround connectivity issues caused by premature
> > > > NAT-PT state
> > > > >          timeout. (not NAT-PT specific).
> > > > >
> > > > >        *  Inability to redirect packet fragments after the
> > > > first with
> > > > >          NAPT-PT. (not NAT-PT specific).
> > > > >
> > > > >    o  Issues which are exacerbated by the use of a DNS-ALG:
> > > > >       *  Constraints on network topology. (not NAT-PT
> specific).
> > > > >       *  Scalability concerns together with introduction of
> > > > single point
> > > > >          of failure and security attack nexus.(not
> NAT-PT specific).
> > > > >       *  Lack of address mapping persistence: Some
> > > > applications require
> > > > >          address retention between sessions.  The user
> > > > traffic will be
> > > > >          disrupted if a different mapping is used. 
> The use of the
> > > > >          DNS-ALG to create address mappings with limited
> > > > lifetimes means
> > > > >          that applications must start using the address
> > > > shortly after
> > > > >          the mapping is created, as well as keeping it
> > > > alive once they
> > > > >          start using it.(not NAT-PT specific).
> > > > >       *  Creation of a DOS threat relating to exhaustion of
> > > > memory and
> > > > >          address/port pool resources on the
> translator.(not NAT-PT
> > > > > specific).
> > > > >
> > > > > Regarding the conclusion, I don't agree with the fact
> that only
> > > > > applicable scenario
> > > > > is in 3G networks. During the past couple of years of my
> > > > experience I
> > > > > have seen
> > > > > customers using it between isolated IPv6 networks to talk
> > > > to existing
> > > > > IPv4 networks.
> > > > > A lot of cases it is not about the nodes being dual stack
> > > > or not, it is
> > > > > the network
> > > > > that is not dual stacked for operational reasons.
> > > > >
> > > > > I have been gathering some inputs from the customers
> who are using
> > > > > NAT-PT currently
> > > > > regarding this draft. I can consolidate and forward the
> > > > comments if you
> > > > > are interested in
> > > > > knowing and understanding why they think they are moving
> > > > forward with
> > > > > NAT-PT.
> > > > >
> > > > > The point I am trying to stress is deprecating this would
> > > > leave us with
> > > > > no workable
> > > > > solution for communicating between IPv4 only
> > > > networks/nodes/apps IPv6 only
> > > > > networks/nodes/apps. As remote as it might seem for some,
> > > > that is the
> > > > > use case
> > > > > scenario we have encountered as the applicability of NAT-PT.
> > > > >
> > > > > Senthil
> > > > >
> > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
> > > > >
> > > > >> Hi,
> > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT
> > > > >> deprecation analysis.
> > > > >> We would really appreciate if you could provide us your
> > > > feedback on
> > > > >> the initial version of the deprecation analysis by Monday
> > > > October 4th.
> > > > >> Regards
> > > > >> Cedric Aoun
> > > > >> ------ Forwarded Message
> > > > >> From: <Internet-Drafts@ietf.org>
> > > > >> Reply-To: <internet-drafts@ietf.org>
> > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200
> > > > >> To: <i-d-announce@ietf.org>
> > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > >>
> > > > >> A New Internet-Draft is available from the on-line
> Internet-Drafts
> > > > >> directories.
> > > > >>
> > > > >>
> > > > >>
> > > > >>         Title           : Reasons to Deprecate NAT-PT
> > > > >>         Author(s)       : C. Aoun, E. Davies
> > > > >>         Filename        :
> draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > >>         Pages           : 24
> > > > >>         Date            : 2004-9-21
> > > > >>
> > > > >> This document discusses reasons why use of the
> specific form of
> > > > >>    IPv6-IPv4 protocol translation mechanism implemented by
> > > > the Network
> > > > >>    Address Translator - Protocol Translator (NAT-PT)
> > > > defined in RFC 2766
> > > > >>    should be deprecated and RFC2766 moved to historic status.
> > > > >>    Description of an alternative protocol translation
> > > > mechanism is out
> > > > >>    of scope for this document.
> > > > >>
> > > > >> A URL for this Internet-Draft is:
> > > > >>
> > > >
> > >
> >
> <<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d
> e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> >
> > >
> > > > precate-00.txt
> > > >
> ><http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d
> e>http://w
> > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> > > > precate-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>https://w
ww1.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-aoun-v6ops-natpt-deprecate-00.txt".
> > > > >>
> > > > >> A list of Internet-Drafts directories can be found in
> > > > >>
> > >
> >
> <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.h
> tml>http://www.ietf.org/shadow.html
> >
> > >
> > > > >> or
> > > > >>
> > > >
> > >
> >
> <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org
> /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/
> >
> > >
> > >ietf/1shadow-s
> > >ites.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-aoun-v6ops-natpt-deprecate-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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ------ End of Forwarded Message
> > > >>
> > > >
> > >
> > >
> >
>
> > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc;
> x-mac-type=42494E41; x-mac-creator=4D535744
>
>
>
> =====
>
>
>

--Boundary_(ID_/JGxvgwrYHofTlOerpw7hg)-- From owner-v6ops@ops.ietf.org Mon Oct 11 21:07:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16732 for ; Mon, 11 Oct 2004 21:07:30 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHB7o-000IPo-Bu for v6ops-data@psg.com; Tue, 12 Oct 2004 01:06:48 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CHB7l-000IPO-Ad for v6ops@ops.ietf.org; Tue, 12 Oct 2004 01:06:47 +0000 Received: (eyou send program); Tue, 12 Oct 2004 09:43:33 +0800 Message-ID: <297545413.18638@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Tue, 12 Oct 2004 09:43:33 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: soohong.park@samsung.com Cc: schakra@mitre.org, brc@zurich.ibm.com, Cedric@njupt.edu.cn, Aoun@njupt.edu.cn, cedric.aoun@nortelnetworks.com, v6ops@ops.ietf.org Date: Tue, 12 Oct 2004 09:43:33 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: ** X-Spam-Status: No, hits=2.6 required=5.0 tests=AWL,BAYES_00,FROM_ENDS_IN_NUMS, MSGID_FROM_MTA_HEADER,PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >From: Soohong Daniel Park >Reply-To: >To: Elwyn Davies , 'Pyda Srisuresh' , Senthil Sivakumar >Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >Date:Tue, 12 Oct 2004 09:18:55 +0900 > >RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txtIt was not the original goal of NAT-PT to support all of the IPv6 features. >It is one of possible transition mechanisms althouth there are several >restrictions originated from the traditional NAT architecture. > >Nevertheless, I know several sites are using NAT-PT efficiently on their use cases. I agree. NAT-PT is only a transiton mechanism. We use it to solve one scenario(NAT), at last we will use the IPv6 and its new features. I don't think restictions such as E2E should be considered more. > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics. > > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Elwyn Davies > Sent: Tuesday, October 12, 2004 2:25 AM > To: 'Pyda Srisuresh'; Senthil Sivakumar > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Cedric Aoun; 'V6OPS' > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > That NAT-PT may stifle innovation is not an assumption but a deduction. As is pointed out in the draft, NAT-PT cannot support all of the current features of v6 (eg flow labels, MIPv6) and is unlikely to support any new features. If the NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to help), then all applications may well have to decide to just use the subset of features supported by NAT-PT. If they can detect that there is a NAT-PT box in the way then special case code may be needed for destinations accessed through the NAT-PT to limit the capabilities used. > > However if a proxy is used, all the special casing can be confined to the proxy - the original application should be able to work untramelled (i.e. as if working on a pure native v6 network when communicating with v6 addresses - v4 functionality is unchanged). Hence I think the situation as regards extra code is exactly the reverse of what you say: applications operating with proxies can be unaware and unchanged; applications operating through NAT-PT may need special case coding. > > The lack of compelling use cases for NAT-PT indicates that it isn't an essential mechanism. Apart from a very limited set of cases dual-stack + tunelling solves working across multiple realms. We need to get the message out that NAT-PT is not a good thing and that there are other, better solutions. That is the way to overcome resistance! > > Regards, > Elwyn > > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: 11 October 2004 14:58 > > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] > > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric > > [ADC:7Q30:EXCH]; 'V6OPS' > > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > Folks, > > > > As Senthil points out, the assumption that NAT-PT deployment > > will stifle > > innovation in v6 seems flawed. NAT-PT is a transition > > mechanism which is > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > resistance to deploying V6 . You need NAT-PT for legacy > > applications (ex: > > e-mail, ftp) to work as is across V4 and V6 realms. No change > > to end-hosts or > > applications. This is the attraction of NAT-PT. This is not > > the same as the > > proxy solution that will require applications to be > > changed/recompiled. > > > > > > cheers, > > suresh > > > > > > --- Senthil Sivakumar wrote: > > > > > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > > > > > >Three points: > > > >- The object of the draft was to summarize in one place > > all the problems > > > >with NAT-PT rather than being yet another delta on > > previous work. The > > > >introduction notes that several of the points are indeed > > generic address > > > >translation problems. This doesn't make them any less relevant. > > > > > > I am fine with summarizing the issues in one draft. But the > > draft points > > > out those as reasons to deprecate > > > which is what I am pointing out. > > > > > > >- The draft is specifically targeting the NAT-PT = SIIT + > > DNS-ALG solution > > > >intended for use as a generic inter-cloud translator. It > > is clear to me > > > >that a 'cut down' form has a use as a legacy v4 'server > > adaptor' front end > > > >where there is only one v4 address (or maybe a server > > cluster) on one > > > >side, it only has to handle a pre-defined set of > > protocols, and it doesn't > > > >need a DNS-ALG. I think this should be the subject of a > > separate draft. > > > > > > While I agree with you the cut-down solution does not need > > a DNS-ALG, I > > > don't think it has to handle a > > > specific set of protocols. I could still be a generic > > purpose translator > > > for facilitating transition. I am attaching > > > a document which was one of the use case scenario we are aware of. > > > > > > >- The fundamental point is whether v6ops should still be > > continuing to > > > >support a technology which will, if widely deployed, > > effectively stifle > > > >innovation in v6 networks. The need for applications to > > be aware that > > > >NAT-PT exists effectively condemns v6 to be just v4 with > > larger addresses > > > >at the application level. Is this what is wanted? Or > > should we really be > > > >trying to put the architectural flexibility back into the Internet? > > > > > > I am not understanding why you say applications have to > > aware of existence > > > of NAT-PT. > > > > > > > > > >It would be useful to see Shivkumar's use cases so that > > they could be > > > >considered for inclusion in the relevant transition > > analysis. If people > > > >are using NAT-PT in a particular way then we need to give > > them a workable > > > >alternative before ditching NAT-PT. > > > > > > Exactly. We should not prematurely deprecate the solution > > without an > > > alternative in place. > > > > > > Thnks > > > Senthil > > > > > > >Regards, > > > >Elwyn > > > > > > > > > -----Original Message----- > > > > > From: Sham Chakravorty > > > > [mailto:schakra@mitre.org] > > > > > Sent: 09 October 2004 18:35 > > > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > > > [HAL02:0S00:EXCH] > > > > > Subject: RE: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really > > doesn't earn us > > > > > anything but removes one tool that could be used in specific > > > > > instances. > > > > > Application gateways are not in the same usage "level" as > > > > > NAT-PT - they > > > > > occur in different points of the network. Also, the > > > > > underlying algorithm of > > > > > SIIT would still be available. > > > > > > > > > > Sham > > > > > > > > > > -----Original Message----- > > > > > From: owner-v6ops@ops.ietf.org > > > > > > > [mailto:owner-v6ops@ops.ietf.org] On > > > > Behalf > > > > > Of Brian E Carpenter > > > > > Sent: Saturday, October 09, 2004 9:10 AM > > > > > To: Senthil Sivakumar > > > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > > > Subject: Re: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with no > > > > > workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the use > > > > > case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > But there is a workable alternative, which is an application > > > > > level proxy. > > > > > This too has its disadvantages, of course. > > > > > > > > > > Brian > > > > > > > > > > Senthil Sivakumar wrote: > > > > > > I see that the draft has consolidated all the > > previous drafts that > > > > > > highlighted the issues > > > > > > of NAT-PT and DNS ALG, which is a good thing. > > However, most of the > > > > > > issues mentioned > > > > > > here as NAT-PT issues are known issues with address > > > > > translation (NAT) > > > > > > itself, so > > > > > > attributing them to NAT-PT is not correct. Those should be > > > > > categorized > > > > > > as generic address > > > > > > translation issues. > > > > > > > > > > > > Some specfic comments on the following issues. > > > > > > > > > > > > * Disruption of all protocols which embed IP > > addresses (and/or > > > > > > ports) in packet payloads or which apply integrity > > > > > mechanisms > > > > > > using IP addresses (and ports). (not NAT-PT > > specific). > > > > > > > > > > > > * Requirement for applications to use keep alive > > > > > mechanisms to > > > > > > workaround connectivity issues caused by premature > > > > > NAT-PT state > > > > > > timeout. (not NAT-PT specific). > > > > > > > > > > > > * Inability to redirect packet fragments after the > > > > > first with > > > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > > > * Constraints on network topology. (not NAT-PT > > specific). > > > > > > * Scalability concerns together with introduction of > > > > > single point > > > > > > of failure and security attack nexus.(not > > NAT-PT specific). > > > > > > * Lack of address mapping persistence: Some > > > > > applications require > > > > > > address retention between sessions. The user > > > > > traffic will be > > > > > > disrupted if a different mapping is used. > > The use of the > > > > > > DNS-ALG to create address mappings with limited > > > > > lifetimes means > > > > > > that applications must start using the address > > > > > shortly after > > > > > > the mapping is created, as well as keeping it > > > > > alive once they > > > > > > start using it.(not NAT-PT specific). > > > > > > * Creation of a DOS threat relating to exhaustion of > > > > > memory and > > > > > > address/port pool resources on the > > translator.(not NAT-PT > > > > > > specific). > > > > > > > > > > > > Regarding the conclusion, I don't agree with the fact > > that only > > > > > > applicable scenario > > > > > > is in 3G networks. During the past couple of years of my > > > > > experience I > > > > > > have seen > > > > > > customers using it between isolated IPv6 networks to talk > > > > > to existing > > > > > > IPv4 networks. > > > > > > A lot of cases it is not about the nodes being dual stack > > > > > or not, it is > > > > > > the network > > > > > > that is not dual stacked for operational reasons. > > > > > > > > > > > > I have been gathering some inputs from the customers > > who are using > > > > > > NAT-PT currently > > > > > > regarding this draft. I can consolidate and forward the > > > > > comments if you > > > > > > are interested in > > > > > > knowing and understanding why they think they are moving > > > > > forward with > > > > > > NAT-PT. > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with > > > > > > no workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the > > > > > > use case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > > > Senthil > > > > > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > > > > > >> Hi, > > > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > > > >> deprecation analysis. > > > > > >> We would really appreciate if you could provide us your > > > > > feedback on > > > > > >> the initial version of the deprecation analysis by Monday > > > > > October 4th. > > > > > >> Regards > > > > > >> Cedric Aoun > > > > > >> ------ Forwarded Message > > > > > >> From: > > > > > >> Reply-To: > > > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > > > >> To: > > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> > > > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > > >> directories. > > > > > >> > > > > > >> > > > > > >> > > > > > >> Title : Reasons to Deprecate NAT-PT > > > > > >> Author(s) : C. Aoun, E. Davies > > > > > >> Filename : > > draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> Pages : 24 > > > > > >> Date : 2004-9-21 > > > > > >> > > > > > >> This document discusses reasons why use of the > > specific form of > > > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > > > the Network > > > > > >> Address Translator - Protocol Translator (NAT-PT) > > > > > defined in RFC 2766 > > > > > >> should be deprecated and RFC2766 moved to historic status. > > > > > >> Description of an alternative protocol translation > > > > > mechanism is out > > > > > >> of scope for this document. > > > > > >> > > > > > >> A URL for this Internet-Draft is: > > > > > >> > > > > > > > > > > > > > > < > e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > > > > > > > precate-00.txt > > > > > > > > > e>http://w > > > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > precate-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://w > ww1.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-aoun-v6ops-natpt-deprecate-00.txt". > > > > > >> > > > > > >> A list of Internet-Drafts directories can be found in > > > > > >> > > > > > > > > > <http://www.ietf.org/shadow.h > > tml>http://www.ietf.org/shadow.html > > > > > > > > > > > > >> or > > > > > >> > > > > > > > > > > > > > > <ftp://ftp.ietf.org > > /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > > > > > > > >ietf/1shadow-s > > > >ites.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-aoun-v6ops-natpt-deprecate-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. > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> ------ End of Forwarded Message > > > > >> > > > > > > > > > > > > > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; > > x-mac-type=42494E41; x-mac-creator=4D535744 > > > > > > > > ===== > > > > > > From owner-v6ops@ops.ietf.org Tue Oct 12 00:55:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA01350 for ; Tue, 12 Oct 2004 00:55:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHEey-000IL0-00 for v6ops-data@psg.com; Tue, 12 Oct 2004 04:53:16 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHEew-000IKi-KI for v6ops@ops.ietf.org; Tue, 12 Oct 2004 04:53:14 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0A939CC11; Tue, 12 Oct 2004 00:53:14 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 00:53:13 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Date: Tue, 12 Oct 2004 00:53:20 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A461@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Thread-Index: AcSv1a86mKGVszWjR1asCUHwX23wggAPwDoQ From: "Bound, Jim" To: "Brian E Carpenter" , X-OriginalArrivalTime: 12 Oct 2004 04:53:13.0846 (UTC) FILETIME=[616C9960:01C4B017] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, Responding to Pekka's draft tomorrow and others which is more difficult. = But here is my response to you.=20 > 1) My first concern is that somehow it misses the most=20 > important case and the way I would recommend any enterprise to go. >=20 > In the terminology of the document that case is >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > |Application |Host 1 |Service |Host 2 |Application | > |----------- |Network|Provider|Network|---------- | > | Host 1 OS | | | | Host 2 OS | > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > |Dual or IPv4| | |Dual IP|Dual IPv4| > 0 | ---- |Dual IP|Dual IP | or |---- or ----| > | Dual | | |v4 only|Dual IPv4| > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D >=20 > In other words, why would an enterprise choose to paint=20 > itself into any of the awkward corners of the other 13 scenarios? Sorry I cannot respond to such a general statement ok. Will continue to = respond. All these cases are real cases and you or I or the IETF cannot = second guess or mandate any transition to the enterprise. > Just go for a dual stack operating system and routing system,=20 > and keep calling your software suppliers until they upgrade=20 > to the new API. Why make it harder than it needs to be?\ This ia really na=EFve view it don't work that way at all and your = assumption is one as casual and many are looking at ways to reduce cost = and thus the 13 scenarios. >=20 > In fact, sections 4 and 7 are written in this spirit - they=20 > refer essentially to what I have shown above as secnario 0. Not really reread the vlan discussion. >=20 > I just don't get what are the drivers for the other > 13 scenarios.=20 I can tell but they are all in ent scenarios doc. >Why would an enterprise accept any of them,=20 > rather than beating on its suppliers for dual stack solutions? Well because many of them have told us they are doing it. How about = that for an answer. Every author is working on real deployment not = fantasy abstractions. Don't shoot the messengers. >=20 > 2) My second main concern is these two statements: >=20 > > 4.1 Phased Dual-Stack Deployment > ... > > In this document we do not advocate or discuss the=20 > deployment of > Unique Local IPv6 Unicast Addresses [ULA]. >=20 > > 7.3.2 Obtaining global IPv6 address space ... > > Unique Local Addressing [ULAs] should not be used for=20 > enterprise > networks. >=20 > Not true and not OK. They were to a considerable extent=20 > designed for enterprise networks. There will be a draft soon=20 > that discusses how they could be used in enterprise networks,=20 > precisely to respond to some of the reasons people use NATs.=20 > It isn't OK for this draft to make such a statement about ULAs. I believe this is a partial bug the idea is to use global addresses = within a distributed enterprise across a wide Internet. We need to just = clean this up. > The simplest solution is to remove both these references to ULAs. That may be an option. >=20 > 3) My third main concern is that the draft doesn't discuss=20 > the deployment of DMZs, which are a feature of all major=20 > enterprise networks. Nor should we and we do not intend to. > A related point is that it doesn't=20 > discuss how an enterprise will offer an IPv6 "web presence" > (or email presence) regardless of the state of its internal=20 > transition. Maybe converting all its DMZ servers to dual=20 > stack would be the first essential step for many enterprises. This draft is only dealing with Layer 3. Except in cases below like = ALG/Proxy. >=20 > Details: >=20 > The summary at the end of section 1 doesn't mention section 7. Will fix. >=20 > > 4.6 Other considerations > > > > There are some identified issues with turning IPv6 on by=20 > default, > including application connection delays, poor=20 > connectivity, and > network insecurity, as discussed in=20 > [V6DEF]. The issues can be > worked around or mitigated by=20 > following the advice in [V6DEF]. > > > > >=20 > At least DNS, network management, and security policies need=20 > to be covered. Not really we can mention them this is layer 3. >=20 > > 5.1 Internal versus External Tunnel-End-Point > > > =20 > The upstream provider could have already deployed some IPv6 =20 > > service, either native IPv6 in its backbone or in the=20 > access > network, or a combination of both. Also, or=20 > alternatively, could > have deployed one or several=20 > transition mechanisms based upon > tunnels, for example in=20 > the case where the access network doesn't > support IPv6.=20 > In this case, the enterprise could decide to use > those=20 > available transition services from the ISP. However, this > =20 > will usually mean that the each of the different nodes in the=20 > > network will have their own IPv6-in-IPv4 tunnel. Then,=20 > the IPv6 > intranet communication will not be efficient, as=20 > it will require > all the traffic to be forwarded by the=20 > IPv4 infrastructure to the > Tunnel-End-Point located at the ISP. >=20 > This would be unacceptable to 99% of enterprise security managers. Thanks for your opinion we should discuss for sure. >=20 > > 7.3.1 Obtaining external connectivity > > > The=20 > enterprise service provider would typically be a > =20 > topographically close (to minimize connectivity RTT) IPv6=20 > provider > that is able to provide an IPv6 upstream link. > > > > It would be expected that the enterprise would use either=20 > native > IPv6 upstream connectivity or, in its absence, a=20 > manually > configured tunnel [BCNF] to the upstream provider. > > > > It is not recommended to use 6to4 [6TO4] or a tunnel=20 > broker [TBRK] > for an enterprise deployment. The=20 > enterprise has a requirement for > long-term, stable IPv6=20 > connectivity. 6to4 and the tunnel broker > are more=20 > appropriate for SOHO or single node environments. >=20 > Sorry, but that's wrong. First of all, single-node 6to4 isn't=20 > an IETF solution - it has never been documented - so it's not=20 > accurate to cite the RFC. Secondly, 6to4 as described in RFC=20 > 3056 will work just fine for an enterprise - until the day=20 > its own ISP provides native connectivity, of course. I'd say=20 > a SOHO user has less chance of setting up RFC 3056 correctly=20 > than a large enterprise. Uh OH but good there will be strong disagreement. I am just editor. I see both views. Both are required. >=20 > > ...Use of > > 6to4 also prevents the enterprise adopting aggregatable=20 > global IPv6 > addressing from the outset. >=20 > True... but so what? It's a solution you use only as long as=20 > you have to, and then you switch to an aggregatable prefix.=20 > This wouldn't affect internal network usage at all, apart=20 > from updating the prefix. Point was to not mix the two we can make that clear. Once ISP has IPv6 = 6to4 is not required. >=20 > > 7.3.2 Obtaining global IPv6 address space > > > The=20 > enterprise will obtain global IPv6 address space from its > =20 > selected upstream provider, as provider assigned (PA) address=20 > > space. > > > > The enterprise should receive at least a /48 allocation=20 > from its > provider, as described in [ALLOC]. >=20 > I think you should refer to RIR policy directly; that RFC is=20 > only a recommendation to the RIRs. Agreed. >=20 > > 7.4.6 IPv4-IPv6 interworking > > > > > > In the case of an IPv6 only node in an IPv6-dominant or=20 > dual-stack > enterprise, wishing to communicate with=20 > external IPv4-only systems, > some interworking=20 > (translation) method is required. The > translation could=20 > be applied at Layer 3 (e.g. [NAT-PT]), Layer 4 > (e.g.=20 > [SOCKS]) or Layer 7 (a dual-stack application layer gateway -=20 > > ALG). >=20 > I would also refer to a Layer 7 proxy. Also, since we seem to=20 > be about to deprecate NAT-PT, it probably should not be mentioned. In this case I agree because it is an "assist to layer 3". Good idea. >=20 > > 7.5.2 Supporting remote access > > > > Where an enterprise's users may be working off-site, and=20 > their > transient ISP has no IPv6 support (natively or=20 > through transition > aids) the enterprise should consider=20 > deploying its own transition > (remote access) aid. > > > > Such an aid may be either a tunnel broker [TBRK], ideally=20 > one that > supports operation through an IPv4 NAT, or a=20 > 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site=20 > should be aware of security > issues with operating 6to4=20 > relays [cite ref?]. >=20 > I think it's much more likely to be an IPSEC or IP-over-TLS=20 > tunnel, which could be v6-in-v4 or v6-in-v6. That's how many=20 > enterprises offer secure IPv4 "call home" today. Good point. >=20 > > 8 Applicable Transition Mechanisms > ... > > Basic Configured Tunnels: > > > > 6to4: > > > > Tunnel Broker: > > > > Teredo: > > > > DSTM: > > > > ISATAP: > > > > NAT-PT: >=20 > Well, again, if we are deprecating NAT-PT, we can't include it here. > And the ALG/proxy alternative to NAT-PT needs to be listed. Probably, > IPv4-in-IPv6 tunnels should be listed too. I agree. DSTM is v4-in-v6 as a note. >=20 > > > > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > |Application |Host 1 |Service |Host 2 |Application | =20 > Recommended > > |----------- |Network|Provider|Network|---------- | =20 > Transition > > | Host 1 OS | | | | Host 2 OS | Mechanism > > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > You need to give some rationale for the recommendations in=20 > the last column. > But in any case, my main concern 1) applies to this whole=20 > table. Scenario 0 is the interesting one, and it's missing. Its not missing it is not clear. >=20 > The issue with NAT-PT applies to the entries for=20 > "translation", all of which I would replace by "ALG/proxy." Personally I agree we can discuss with all authors. >=20 > > Appendix B - Crisis Management Network Scenarios >=20 > What's the value-add of this material in this document? It=20 > seems that it should be published separately. Maybe but it depicts a real use case not a partial or abstract one and = we authors want it in the spec. Thanks /jim >=20 > Brian >=20 >=20 From owner-v6ops@ops.ietf.org Tue Oct 12 01:06:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02184 for ; Tue, 12 Oct 2004 01:06:05 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHEqx-000KHH-0p for v6ops-data@psg.com; Tue, 12 Oct 2004 05:05:39 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHEqv-000KGo-Kx for v6ops@ops.ietf.org; Tue, 12 Oct 2004 05:05:37 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 34ED4AEC9; Tue, 12 Oct 2004 01:05:37 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 01:05:37 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Date: Tue, 12 Oct 2004 01:05:42 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A462@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Thread-Index: AcSvyMK/a7W0w0rbRgemK6yjaJAOQQATr7zw From: "Bound, Jim" To: "Heikki Vatiainen" , X-OriginalArrivalTime: 12 Oct 2004 05:05:37.0055 (UTC) FILETIME=[1C694AF0:01C4B019] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable =20 > Here are the comments: >=20 >=20 > 4.4.2 Deploy a parallel IPv6 infrastructure [cut] > Such an approach means acquiring additional hardware, but it has the > advantage that the existing IPv4 routing platforms are not disturbed > by the introduction of IPv6. >=20 > I think dual stack has been available long enough that the=20 > potential for disturbance is not great enough to justify a=20 > parallel infrasturcture for IPv6. In fact, I would recommend=20 > that parallel infrasturcture is only built if no other=20 > options, such as upgrading to dual stack routers, are available. That is not the objective. Users will use the capability of dual stack in different ways and we are addressing all those ways. To not do that is not useful one-size-does-not-fit-all for transition. >=20 > The problems we have noticed with running a parallel=20 > infrastructure touch many areas. I try to enumerate our=20 > findings in the following paragraphs. >=20 > The parallel infrastructure forces you to have two times the=20 > documentation about the network. If e.g. intra-organization=20 > packet filtering is done, you have to literally think and=20 > check twice that the filters are set up as required. With=20 > dual stack you may need to create two sets of filters, one=20 > for IPv4 and one for IPv6, but at least they apply to the=20 > same interface on the same router. Agreed and you just provide the exact operational business case for Ipv6 Dominant network transition and the market and users are seeing this now. The faster they move to IPv6 the quicker the deployment of the reason they want IPv6 and at a reduced cost. Thanks for helping that case. >=20 > If the network is built using VLANs one can extend (trunk)=20 > the VLANs to the new IPv6-only routers. If the new IPv6=20 > routers are physically and/or network topologically close to=20 > the existing IPv4 routers, this may be easy to accomplish. =20 > The fourth paragraph discusses the use of one router to serve=20 > many VLANs by "collapsing" them to one router interface. If=20 > the VLANs are not already topologically close to the new IPv6=20 > router one has to grow the existing VLAN coverage. Nobody=20 > wants to do this since this is yet another step to a VLAN=20 > spaghetti network. This is valid in my view but the flip side is what is the cost to drop extended vlan boxes into the network and then add the tags to reach those routers. Your only then touch two points on your network and minimal cost to add a complete IPv6 site theoretically???????????? >=20 > When thinking about the routers, IPv6-only router may cause=20 > surprisingly many problems with network and router management. Hmm we assumed no IPv6 only anything? But rather use of IPv6 dominantly over IPv4? > Our > IPv6 only router does not do at least SNMP, Syslog or NTP=20 > over IPv6 transport. One may think this is only a short term=20 > problem, but the router is only half of the problem. The=20 > other half are the management applications that are used to=20 > monitor and manage the routers. If dual stack routers are=20 > used, management applications can use IPv4 transport making=20 > the lack of IPv6 transport a less or even a non problem. Hmmm I did not know of IPv6 ONLY router? But generally I agree with you and so does the draft? >=20 > In conclusion, I think building a parallel IPv6=20 > infrastructure initially looks like a non-disturbing approach=20 > but a closer looks shows that it does contains many issues=20 > that may cause disturbance later on. Finally, the last=20 > paragraph of 4.4.2 mentions that the parallel approach should=20 > be viewed only as an interim step. The history shows that=20 > interim tends to become Integrated or permanent or otherwise=20 > established, so why not use the resources to do dual stack. I think we need to clean up the word parallel we were not using it this way so you found a bug. Thanks. > 7.3.1 Obtaining external connectivity > [cut] > It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] > for an enterprise deployment. The enterprise has a requirement for > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker > are more appropriate for SOHO or single node environments. Use of > 6to4 also prevents the enterprise adopting aggregatable global IPv6 > addressing from the outset. >=20 > I think the stability and availability of 6to4 relays is more=20 > of a problem than the availability of stable 6to4 prefix. I=20 > do not see enterprise chancing its IPv4 addressing and thus=20 > is 6to4 prefix very often. I think I agree. Every user I know that wants to use IPv6 have obtained or are obtaining IPv6 prefixes and in that case 6to4 is not required. Tunnel Broker plays well to legacy systems to reach IPv6 applications. >=20 > However, with 6to4 the enterprise is putting its reachability towards > non-6to4 IPv6 Internet into hands of the closest 6to4 relay operator. > This should not cause problems if the relay is well=20 > supported. The reachability from the non-6to4 IPv6 Internet=20 > back to the enterprise depends on the relay closest to=20 > whoever someone from the enterprise was communicating with. Well stated. >=20 > I would prefer tunnel broker over 6to4 in the draft. We have ended up there too. But we all need to discuss. >=20 > 7.5.2 Supporting remote access > [cut] > Such an aid may be either a tunnel broker [TBRK], ideally one that > supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site should be aware of security > issues with operating 6to4 relays [cite ref?]. >=20 > I see enterprise's user working off-site as someone who=20 > establishes a VPN connection back to the enterprise. When=20 > the VPN connection has been established, the user gets an IP=20 > address from the enterprise and all or some of the traffic is=20 > tunneled back to the enterprise over the VPN connection. This is the case where 6to4 could be requried by the enterprise at least at the edge then it just becomes an 2002 prefix address. Good point. >=20 > Even if the user is behind a NAT he can still access 6to4=20 > relay over the VPN connection. The 6to4 relay could even use=20 > the well-known anycast address if all traffic is tunneled or=20 > the route towards the well known address can be set to point=20 > to the tunnel. Yes. >=20 > If the user does not have VPN access and NATs and other=20 > filters and packet manglers cause problems then the=20 > enterprise should provide VPN service for the user. Advanced=20 > VPN implementations may support IPv6 over IPv4 VPNs directly=20 > making the need for remote access aid non-existent. Or just use Teredo and the Enterprise can support Teredo Server/Relay too. Thanks /jim >=20 > --=20 > Heikki Vatiainen * hessu@cs.tut.fi > Tampere University of Technology * Tampere, Finland >=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Oct 12 01:28:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03857 for ; Tue, 12 Oct 2004 01:28:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHFCM-000MeR-02 for v6ops-data@psg.com; Tue, 12 Oct 2004 05:27:46 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHFCK-000MeC-Q4 for v6ops@ops.ietf.org; Tue, 12 Oct 2004 05:27:45 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9C5RTf28523; Tue, 12 Oct 2004 08:27:30 +0300 Date: Tue, 12 Oct 2004 08:27:29 +0300 (EEST) From: Pekka Savola To: Pyda Srisuresh cc: Senthil Sivakumar , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-Reply-To: <20041011135742.379.qmail@web40426.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a fundamental deployment argument than one about NAT-PT, but nevertheless I guess this should be said.. On Mon, 11 Oct 2004, Pyda Srisuresh wrote: > As Senthil points out, the assumption that NAT-PT deployment will stifle > innovation in v6 seems flawed. NAT-PT is a transition mechanism which is > essential for wider V6 deployment. Without NAT-PT, you will see bigger > resistance to deploying V6 . You need NAT-PT for legacy applications (ex: > e-mail, ftp) to work as is across V4 and V6 realms. This ('NAT-PT.. essential for wider V6 deployment') may or may not be true if you assume that there will be strong incentives for deploying IPv6-only systems which need to talk to a vast majority of v4 systems in the near future. If that's not the case, it's certainly not correct -- you can deploy IPv6 as dual-stack without any need for NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > No change to end-hosts or > applications. This is the attraction of NAT-PT. This is not the same as the > proxy solution that will require applications to be changed/recompiled. You don't need to change end-hosts or applications (in the manner you probably mean) if you deploy dual-stack. If you deploy v6-only, you need to change end-hosts MORE than with dual-stack. I have the feeling that most typical applications applications already support proxies or have inherent support for middleboxes (e.g., http, smtp, dns, ftp). Changes are only necessary if one would like to pursue a generic 'SOCKS' -like approach for IPv6 deployment, but that has not gotten much deployment AFAICS. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 12 04:48:51 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00251 for ; Tue, 12 Oct 2004 04:48:51 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHIJG-000KTU-3N for v6ops-data@psg.com; Tue, 12 Oct 2004 08:47:06 +0000 Received: from [193.180.251.47] (helo=penguin.ericsson.se) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHIJE-000KTF-UR for v6ops@ops.ietf.org; Tue, 12 Oct 2004 08:47:05 +0000 Received: from esealmw140.al.sw.ericsson.se ([153.88.254.121]) by penguin.ericsson.se (8.12.10/8.12.10/WIREfire-1.8b) with ESMTP id i9C8l3fM023751 for ; Tue, 12 Oct 2004 10:47:03 +0200 (MEST) Received: from esealnt613.al.sw.ericsson.se ([153.88.254.125]) by esealmw140.al.sw.ericsson.se with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 10:47:03 +0200 Received: from ESEALNT746.al.sw.ericsson.se ([153.88.251.6]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id 4KB0VWDA; Tue, 12 Oct 2004 10:47:03 +0200 Received: by ESEALNT746.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Oct 2004 10:47:03 +0200 Message-ID: X-Sybari-Trust: 3243ff8a 47b3073a 27116da7 00000138 From: "Karen E. Nielsen (AH/LMD)" To: v6ops@ops.ietf.org Subject: FW: I-D ACTION:draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt Date: Tue, 12 Oct 2004 10:46:54 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C4B038.0672D36A" X-OriginalArrivalTime: 12 Oct 2004 08:47:03.0755 (UTC) FILETIME=[0BE6D1B0:01C4B038] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C4B038.0672D36A Content-Type: text/plain; charset="iso-8859-1" Dear All, We have revised the "old" zeroconf draft (draft-nielsen-v6ops-zeroconf-goals-01.txt) and restricted it to the 3GPP case, only. The resulting draft is draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt, as announced below. The motivation for limiting the scope of the draft to the 3GPP case only has been a desire to make sure that the requirements (goals) of the v6 in v4 tunnelling mechs demanded by the 3GPP environment are clear. This due to the severe timing constrains of 3GPP. The isolation of the 3GPP requirements in one separate document is first and foremost an administrative choice. Hence, the isolation of the 3GPP requirements should not be read as something that by default maps to an isolation of the 3GPP case in solution space also (although the latter of course could be the case). WG comments are as always most appreciated. BR, Karen -----Original Message----- From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, October 11, 2004 9:39 PM To: i-d-announce@ietf.org Subject: I-D ACTION:draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Goals for Zero-Configuration Tunneling in 3GPP Author(s) : k. Nielsen, et al. Filename : draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt Pages : 20 Date : 2004-10-11 Various types of IPv6-IPv4 tunneling are envisaged to be required in the transition period from IPv4 networking to IPv6 networking, or more precisely, in the transition period from IPv4 only networking to dual or mixed IPv6 and IPv4 networking. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-goals-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-nielsen-v6ops-3GPP-zeroconf-goals-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-nielsen-v6ops-3GPP-zeroconf-goals-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_000_01C4B038.0672D36A Content-Type: message/rfc822 To: Subject: Date: Tue, 12 Oct 2004 10:47:03 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C4B038.0672D36A" ------_=_NextPart_002_01C4B038.0672D36A Content-Type: text/plain ------_=_NextPart_002_01C4B038.0672D36A Content-Type: application/octet-stream; name="ATT53088" Content-Disposition: attachment; filename="ATT53088" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-11155239.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt ------_=_NextPart_002_01C4B038.0672D36A Content-Type: message/external-body; site="internet-drafts"; dir="draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C4B038.0672D36A-- ------_=_NextPart_000_01C4B038.0672D36A Content-Type: text/plain; name="ATT5308843.txt" Content-Disposition: attachment; filename="ATT5308843.txt" _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------_=_NextPart_000_01C4B038.0672D36A-- From owner-v6ops@ops.ietf.org Tue Oct 12 07:14:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08840 for ; Tue, 12 Oct 2004 07:14:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHKZZ-000B4d-Nr for v6ops-data@psg.com; Tue, 12 Oct 2004 11:12:05 +0000 Received: from [141.116.59.230] (helo=dadc014.hqda.pentagon.mil) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHKZX-000B4J-H8 for v6ops@ops.ietf.org; Tue, 12 Oct 2004 11:12:03 +0000 Received: by dadc014.hqda.pentagon.mil with Internet Mail Service (5.5.2657.72) id <4HB4HKZV>; Tue, 12 Oct 2004 07:11:27 -0400 Message-ID: From: "Klynsma, Steven L Mr CIO/G6/MITRE" To: "'Bound, Jim'" , Brian E Carpenter , v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) Date: Tue, 12 Oct 2004 07:11:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B04C.3B1E96C0" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B04C.3B1E96C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Classification: UNCLASSIFIED=20 Caveats: NONE Brian, I work for the military and would dearly love to go to a dual-stack = everywhere, but as Jim mentioned, that's simply not feasible. Unlike = commercial users, we typically must develop our own unique comms = networks that support unique military requirements (i.e. extremely = constrained bandwidth (we feel lucky to have 16KBPS "pipes"), = unpredictable, but inevitable and often lengthy, disconnects from = network services, and a need for both host and routing infrastructure = to be mobile). In such an environment, operating two routing = protocols, as you must with dual-stack becomes quite problematic. In = addition, because of the lengthy life cycles of weapon systems (15-20 = years), you find yourself working with processors that are overloaded = already. Throw a dual-stack requirement on this tactical environment = and you break the camels back. =20 So we are typically looking at replacing the entire tactical comms = infrastructure. Given the other constraints on bandwidth, mobility, = etc., it becomes very attractive to make the leap from IPv4 directly to = IPv6 without a lengthy dual-stack transition period. However, that = essentially creates an IPv6-only ISP supporting our weapon systems on = the battlefield. Of course, this, in turn, comes with another set of = problems, primarily for interoperablity with IPv4-based current systems = and allies, but we hope by aggressively migrating the force to = IPv6-dominance that these additional problems become manageable. Vr, Steve =20 -----Original Message----- From: Bound, Jim [mailto:jim.bound@hp.com]=20 Sent: Tuesday, October 12, 2004 12:53 AM To: Brian E Carpenter; v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Brian, Responding to Pekka's draft tomorrow and others which is more = difficult. But here is my response to you.=20 > 1) My first concern is that somehow it misses the most important case = > and the way I would recommend any enterprise to go. >=20 > In the terminology of the document that case is >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > |Application |Host 1 |Service |Host 2 |Application | > |----------- |Network|Provider|Network|---------- | > | Host 1 OS | | | | Host 2 OS | > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > |Dual or IPv4| | |Dual IP|Dual IPv4| > 0 | ---- |Dual IP|Dual IP | or |---- or ----| > | Dual | | |v4 only|Dual IPv4| > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >=20 > In other words, why would an enterprise choose to paint itself into=20 > any of the awkward corners of the other 13 scenarios? Sorry I cannot respond to such a general statement ok. Will continue = to respond. All these cases are real cases and you or I or the IETF = cannot second guess or mandate any transition to the enterprise. > Just go for a dual stack operating system and routing system, and = keep=20 > calling your software suppliers until they upgrade to the new API. = Why=20 > make it harder than it needs to be?\ This ia really na=EFve view it don't work that way at all and your = assumption is one as casual and many are looking at ways to reduce cost = and thus the 13 scenarios. >=20 > In fact, sections 4 and 7 are written in this spirit - they refer=20 > essentially to what I have shown above as secnario 0. Not really reread the vlan discussion. >=20 > I just don't get what are the drivers for the other > 13 scenarios.=20 I can tell but they are all in ent scenarios doc. >Why would an enterprise accept any of them, rather than beating on = its=20 >suppliers for dual stack solutions? Well because many of them have told us they are doing it. How about = that for an answer. Every author is working on real deployment not = fantasy abstractions. Don't shoot the messengers. >=20 > 2) My second main concern is these two statements: >=20 > > 4.1 Phased Dual-Stack Deployment > ... > > In this document we do not advocate or discuss the deployment of = > > Unique Local IPv6 Unicast Addresses [ULA]. >=20 > > 7.3.2 Obtaining global IPv6 address space ... > > Unique Local Addressing [ULAs] should not be used for enterprise = > > networks. >=20 > Not true and not OK. They were to a considerable extent designed for=20 > enterprise networks. There will be a draft soon that discusses how=20 > they could be used in enterprise networks, precisely to respond to=20 > some of the reasons people use NATs. > It isn't OK for this draft to make such a statement about ULAs. I believe this is a partial bug the idea is to use global addresses = within a distributed enterprise across a wide Internet. We need to = just clean this up. > The simplest solution is to remove both these references to ULAs. That may be an option. >=20 > 3) My third main concern is that the draft doesn't discuss the=20 > deployment of DMZs, which are a feature of all major enterprise=20 > networks. Nor should we and we do not intend to. > A related point is that it doesn't > discuss how an enterprise will offer an IPv6 "web presence" > (or email presence) regardless of the state of its internal=20 > transition. Maybe converting all its DMZ servers to dual stack would=20 > be the first essential step for many enterprises. This draft is only dealing with Layer 3. Except in cases below like = ALG/Proxy. >=20 > Details: >=20 > The summary at the end of section 1 doesn't mention section 7. Will fix. >=20 > > 4.6 Other considerations > > > > There are some identified issues with turning IPv6 on by default, = > > including application connection delays, poor connectivity, and >=20 > network insecurity, as discussed in [V6DEF]. The issues can be >=20 > worked around or mitigated by following the advice in [V6DEF]. > > > > >=20 > At least DNS, network management, and security policies need to be=20 > covered. Not really we can mention them this is layer 3. >=20 > > 5.1 Internal versus External Tunnel-End-Point > > > The=20 > upstream provider could have already deployed some IPv6 > > service, either native IPv6 in its backbone or in the > access > network, or a combination of both. Also, or alternatively, = > could > have deployed one or several transition mechanisms based=20 > upon > tunnels, for example in the case where the access network=20 > doesn't > support IPv6. > In this case, the enterprise could decide to use > those available=20 > transition services from the ISP. However, this > will usually mean=20 > that the each of the different nodes in the > network will have=20 > their own IPv6-in-IPv4 tunnel. Then, the IPv6 > intranet=20 > communication will not be efficient, as it will require > all the=20 > traffic to be forwarded by the > IPv4 infrastructure to the > Tunnel-End-Point located at the ISP. >=20 > This would be unacceptable to 99% of enterprise security managers. Thanks for your opinion we should discuss for sure. >=20 > > 7.3.1 Obtaining external connectivity > > > The enterprise=20 > service provider would typically be a > topographically close (to=20 > minimize connectivity RTT) IPv6 provider > that is able to provide=20 > an IPv6 upstream link. > > > > It would be expected that the enterprise would use either native = > > IPv6 upstream connectivity or, in its absence, a manually > =20 > configured tunnel [BCNF] to the upstream provider. > > > > It is not recommended to use 6to4 [6TO4] or a tunnel broker = [TBRK] =20 > > for an enterprise deployment. The enterprise has a requirement = for =20 > > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker = > =20 > are more appropriate for SOHO or single node environments. >=20 > Sorry, but that's wrong. First of all, single-node 6to4 isn't an IETF = > solution - it has never been documented - so it's not accurate to = cite > the RFC. Secondly, 6to4 as described in RFC > 3056 will work just fine for an enterprise - until the day its own = ISP=20 > provides native connectivity, of course. I'd say a SOHO user has less = > chance of setting up RFC 3056 correctly than a large enterprise. Uh OH but good there will be strong disagreement. I am just editor. I see both views. Both are required. >=20 > > ...Use of > > 6to4 also prevents the enterprise adopting aggregatable global=20 > IPv6 > addressing from the outset. >=20 > True... but so what? It's a solution you use only as long as you have = > to, and then you switch to an aggregatable prefix. > This wouldn't affect internal network usage at all, apart from=20 > updating the prefix. Point was to not mix the two we can make that clear. Once ISP has IPv6 = 6to4 is not required. >=20 > > 7.3.2 Obtaining global IPv6 address space > > > The enterprise = > will obtain global IPv6 address space from its > selected upstream=20 > provider, as provider assigned (PA) address > space. > > > > The enterprise should receive at least a /48 allocation from its = > > provider, as described in [ALLOC]. >=20 > I think you should refer to RIR policy directly; that RFC is only a=20 > recommendation to the RIRs. Agreed. >=20 > > 7.4.6 IPv4-IPv6 interworking > > > > > > In the case of an IPv6 only node in an IPv6-dominant or = dual-stack =20 > > enterprise, wishing to communicate with external IPv4-only = systems, =20 > > some interworking > (translation) method is required. The > translation could be=20 > applied at Layer 3 (e.g. [NAT-PT]), Layer 4 > (e.g. > [SOCKS]) or Layer 7 (a dual-stack application layer gateway - > =20 > ALG). >=20 > I would also refer to a Layer 7 proxy. Also, since we seem to be = about=20 > to deprecate NAT-PT, it probably should not be mentioned. In this case I agree because it is an "assist to layer 3". Good idea. >=20 > > 7.5.2 Supporting remote access > > > > Where an enterprise's users may be working off-site, and their > = =20 > transient ISP has no IPv6 support (natively or through transition > = > aids) the enterprise should consider deploying its own transition > = > (remote access) aid. > > > > Such an aid may be either a tunnel broker [TBRK], ideally one = that =20 > > supports operation through an IPv4 NAT, or a > 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site should = be=20 > aware of security > issues with operating 6to4 relays [cite ref?]. >=20 > I think it's much more likely to be an IPSEC or IP-over-TLS tunnel,=20 > which could be v6-in-v4 or v6-in-v6. That's how many enterprises = offer=20 > secure IPv4 "call home" today. Good point. >=20 > > 8 Applicable Transition Mechanisms ... > > Basic Configured Tunnels: > > > > 6to4: > > > > Tunnel Broker: > > > > Teredo: > > > > DSTM: > > > > ISATAP: > > > > NAT-PT: >=20 > Well, again, if we are deprecating NAT-PT, we can't include it here. > And the ALG/proxy alternative to NAT-PT needs to be listed. Probably, > IPv4-in-IPv6 tunnels should be listed too. I agree. DSTM is v4-in-v6 as a note. >=20 > > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > |Application |Host 1 |Service |Host 2 |Application | =20 > Recommended > > |----------- |Network|Provider|Network|---------- | =20 > Transition > > | Host 1 OS | | | | Host 2 OS | = Mechanism > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=20 > You need to give some rationale for the recommendations in the last=20 > column. > But in any case, my main concern 1) applies to this whole table.=20 > Scenario 0 is the interesting one, and it's missing. Its not missing it is not clear. >=20 > The issue with NAT-PT applies to the entries for "translation", all = of=20 > which I would replace by "ALG/proxy." Personally I agree we can discuss with all authors. >=20 > > Appendix B - Crisis Management Network Scenarios >=20 > What's the value-add of this material in this document? It seems that = > it should be published separately. Maybe but it depicts a real use case not a partial or abstract one and = we authors want it in the spec. Thanks /jim >=20 > Brian >=20 >=20 Classification: UNCLASSIFIED=20 Caveats: NONE ------_=_NextPart_001_01C4B04C.3B1E96C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt = (UNCLASSIFIED)

Classification:  = UNCLASSIFIED
Caveats: NONE

Brian,

I work for the military and would dearly love to go = to a dual-stack everywhere, but as Jim mentioned, that's simply not = feasible.  Unlike commercial users, we typically must develop our = own unique comms networks that support unique military requirements = (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS = "pipes"), unpredictable, but inevitable and often lengthy, = disconnects from network services, and a need for both host and routing = infrastructure to be mobile).  In such an environment, operating = two routing protocols, as you must with dual-stack becomes quite = problematic.  In addition, because of the lengthy life cycles of = weapon systems (15-20 years), you find yourself working with processors = that are overloaded already.  Throw a dual-stack requirement on = this tactical environment and you break the camels back.  =

So we are typically looking at replacing the entire = tactical comms infrastructure.  Given the other constraints on = bandwidth, mobility, etc., it becomes very attractive to make the leap = from IPv4 directly to IPv6 without a lengthy dual-stack transition = period.  However, that essentially creates an IPv6-only ISP = supporting our weapon systems on the battlefield.  Of course, = this, in turn, comes with another set of problems, primarily for = interoperablity with IPv4-based current systems and allies, but we hope = by aggressively migrating the force to IPv6-dominance that these = additional problems become manageable.

Vr,

Steve        =

-----Original Message-----
From: Bound, Jim [mailto:jim.bound@hp.com]
Sent: Tuesday, October 12, 2004 12:53 AM
To: Brian E Carpenter; v6ops@ops.ietf.org
Subject: RE: REVIEW NEEDED: = draft-ietf-v6ops-ent-analysis-00.txt

Brian,

Responding to Pekka's draft tomorrow and others which = is more difficult.  But here is my response to you.

> 1) My first concern is that somehow it misses = the most important case
> and the way I would recommend any enterprise to = go.
>
> In the terminology of the document that case = is
>
>
>   = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>     |Application |Host 1 = |Service |Host 2 |Application |
>     |----------- = |Network|Provider|Network|----------  |
>     | Host 1 OS  = |       = |        = |       | Host 2 OS  |
>   = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
>     |Dual or = IPv4|       = |        |Dual = IP|Dual    IPv4|
>   0 |    = ----    |Dual IP|Dual IP |  or   |---- or = ----|
>     |    = Dual    |       = |        |v4 = only|Dual    IPv4|
>   = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D
>
> In other words, why would an enterprise choose = to paint itself into
> any of the awkward corners of the other 13 = scenarios?

Sorry I cannot respond to such a general statement = ok.  Will continue to respond.  All these cases are real = cases and you or I or the IETF cannot second guess or mandate any = transition to the enterprise.

> Just go for a dual stack operating system and = routing system, and keep
> calling your software suppliers until they = upgrade to the new API. Why
> make it harder than it needs to be?\

This ia really na=EFve view it don't work that way at = all and your assumption is one as casual and many are looking at ways = to reduce cost and thus the 13 scenarios.

>
> In fact, sections 4 and 7 are written in this = spirit - they refer
> essentially to what I have shown above as = secnario 0.

Not really reread the vlan discussion.

>
> I just don't get what are the drivers for the = other
> 13 scenarios.

I can tell but they are all in ent scenarios = doc.

>Why would an enterprise accept any of them,  = rather than beating on its
>suppliers for dual stack solutions?

Well because many of them have told us they are doing = it.  How about that for an answer.  Every author is working = on real deployment not fantasy abstractions.  Don't shoot the = messengers.

>
> 2) My second main concern is these two = statements:
>
>  > 4.1  Phased Dual-Stack = Deployment
> ...
>  >  In this document we do not = advocate or discuss the deployment of 
> >  Unique Local IPv6 Unicast Addresses = [ULA].
>
>  > 7.3.2 Obtaining global IPv6 address = space ...
>  >  Unique Local Addressing [ULAs] = should not be used for enterprise 
> >  networks.
>
> Not true and not OK. They were to a = considerable extent designed for
> enterprise networks. There will be a draft soon = that discusses how
> they could be used in enterprise networks, = precisely to respond to
> some of the reasons people use NATs.
> It isn't OK for this draft to make such a = statement about ULAs.

I believe this is a partial bug the idea is to use = global addresses within a distributed enterprise across a wide = Internet.  We need to just clean this up.

> The simplest solution is to remove both these = references to ULAs.

That may be an option.

>
> 3) My third main concern is that the draft = doesn't discuss the
> deployment of DMZs, which are a feature of all = major enterprise
> networks.

Nor should we and we do not intend to.

>  A related point is that it doesn't
> discuss how an enterprise will offer an IPv6 = "web presence"
> (or email presence) regardless of the state of = its internal
> transition. Maybe converting all its DMZ = servers to dual stack would
> be the first essential step for many = enterprises.

This draft is only dealing with Layer 3. Except in = cases below like ALG/Proxy.

>
> Details:
>
> The summary at the end of section 1 doesn't = mention section 7.

Will fix.

>
>  > 4.6  Other = considerations
>  >
>  > There are some identified issues = with turning IPv6 on by default, 
> > including application connection delays, = poor connectivity, and  >
> network insecurity, as discussed in [V6DEF]. = The issues can be  >
> worked around or mitigated by following the = advice in [V6DEF].
>  >
>  > <more to go here>
>
> At least DNS, network management, and security = policies need to be
> covered.

Not really we can mention them this is layer = 3.

>
>  > 5.1  Internal versus External = Tunnel-End-Point  >  >  > The
> upstream provider could have already deployed = some IPv6
> >  service, either native IPv6 in its = backbone or in the
> access  >  network, or a = combination of both. Also, or alternatively,
> could  >  have deployed one or = several transition mechanisms based
> upon  >  tunnels, for example in = the case where the access network
> doesn't  >  support IPv6.
> In this case, the enterprise could decide to = use  >  those available
> transition services from the ISP. However, = this  > will usually mean
> that the each of the different nodes in = the  >  network will have
> their own IPv6-in-IPv4 tunnel. Then, the = IPv6  >  intranet
> communication will not be efficient, as it will = require  >  all the
> traffic to be forwarded by the
> IPv4 infrastructure to the  >  = Tunnel-End-Point located at the ISP.
>
> This would be unacceptable to 99% of enterprise = security managers.

Thanks for your opinion we should discuss for = sure.

>
>  > 7.3.1 Obtaining external = connectivity  >  >  >  The enterprise =
> service provider would typically be a  = > topographically close (to
> minimize connectivity RTT) IPv6 provider  = >  that is able to provide
> an IPv6 upstream link.
>  >
>  >  It would be expected that the = enterprise would use either native 
> >  IPv6 upstream connectivity or, in = its absence, a manually  > 
> configured tunnel [BCNF] to the upstream = provider.
>  >
>  >  It is not recommended to use = 6to4 [6TO4] or a tunnel broker [TBRK] 
> >  for an enterprise deployment.  = The enterprise has a requirement for 
> >  long-term, stable IPv6 = connectivity.  6to4 and the tunnel broker  > 
> are more appropriate for SOHO or single node = environments.
>
> Sorry, but that's wrong. First of all, = single-node 6to4 isn't an IETF
> solution - it has never been documented - so = it's not accurate to cite
> the RFC. Secondly, 6to4 as described in = RFC
> 3056 will work just fine for an enterprise - = until the day its own ISP
> provides native connectivity, of course. I'd = say a SOHO user has less
> chance of setting up RFC 3056 correctly than a = large enterprise.

Uh OH but good there will be strong = disagreement.  I am just editor.

I see both views.  Both are required.

>
>  >  ...Use of
>  >  6to4 also prevents the = enterprise adopting aggregatable global
> IPv6  >  addressing from the = outset.
>
> True... but so what? It's a solution you use = only as long as you have
> to, and then you switch to an aggregatable = prefix.
> This wouldn't affect internal network usage at = all, apart from
> updating the prefix.

Point was to not mix the two we can make that = clear.  Once ISP has IPv6 6to4 is not required.

>
>  > 7.3.2 Obtaining global IPv6 address = space  >  >  >  The enterprise
> will obtain global IPv6 address space from = its  > selected upstream
> provider, as provider assigned (PA) = address  >  space.
>  >
>  >  The enterprise should receive = at least a /48 allocation from its 
> >  provider, as described in = [ALLOC].
>
> I think you should refer to RIR policy = directly; that RFC is only a
> recommendation to the RIRs.

Agreed.

>
>  > 7.4.6  IPv4-IPv6 = interworking
>  >
>  >
>  >  In the case of an IPv6 only = node in an IPv6-dominant or dual-stack 
> >  enterprise, wishing to communicate = with external IPv4-only systems, 
> >  some interworking
> (translation) method is required.  = The  >  translation could be
> applied at Layer 3 (e.g. [NAT-PT]), Layer = 4  >  (e.g.
> [SOCKS]) or Layer 7 (a dual-stack application = layer gateway -  > 
> ALG).
>
> I would also refer to a Layer 7 proxy. Also, = since we seem to be about
> to deprecate NAT-PT, it probably should not be = mentioned.

In this case I agree because it is an "assist to = layer 3".  Good idea.

>
>  > 7.5.2  Supporting remote = access
>  >
>  >  Where an enterprise's users = may be working off-site, and their  > 
> transient ISP has no IPv6 support (natively or = through transition  > 
> aids) the enterprise should consider deploying = its own transition  > 
> (remote access) aid.
>  >
>  >  Such an aid may be either a = tunnel broker [TBRK], ideally one that 
> >  supports operation through an IPv4 = NAT, or a
> 6to4 relay [6TO4].  If  >  a = 6to4 relay is offered, the site should be
> aware of security  >  issues with = operating 6to4 relays [cite ref?].
>
> I think it's much more likely to be an IPSEC or = IP-over-TLS tunnel,
> which could be v6-in-v4 or v6-in-v6. That's how = many enterprises offer
> secure IPv4 "call home" today.

Good point.

>
>  > 8  Applicable Transition = Mechanisms ...
>  >  Basic Configured = Tunnels:
>  >
>  >  6to4:
>  >
>  >  Tunnel Broker:
>  >
>  >  Teredo:
>  >
>  >  DSTM:
>  >
>  >  ISATAP:
>  >
>  >  NAT-PT:
>
> Well, again, if we are deprecating NAT-PT, we = can't include it here.
> And the ALG/proxy alternative to NAT-PT needs = to be listed. Probably,
> IPv4-in-IPv6 tunnels should be listed = too.

I agree. DSTM is v4-in-v6 as a note.

>
>  >
>  >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>  >    |Application |Host = 1 |Service |Host 2 |Application |  
> Recommended
>  >    |----------- = |Network|Provider|Network|----------  |  
> Transition
>  >    | Host 1 OS  = |       = |        = |       | Host 2 OS  |   = Mechanism
>  >
> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
>
> You need to give some rationale for the = recommendations in the last
> column.
> But in any case, my main concern 1) applies to = this whole table.
> Scenario 0 is the interesting one, and it's = missing.

Its not missing it is not clear.

>
> The issue with NAT-PT applies to the entries = for "translation", all of
> which I would replace by = "ALG/proxy."

Personally I agree we can discuss with all = authors.

>
>  > Appendix B - Crisis Management = Network Scenarios
>
> What's the value-add of this material in this = document? It seems that
> it should be published separately.

Maybe but it depicts a real use case not a partial or = abstract one and we authors want it in the spec.

Thanks
/jim
>
>     Brian
>
>
Classification:  = UNCLASSIFIED
Caveats: NONE

------_=_NextPart_001_01C4B04C.3B1E96C0-- From owner-v6ops@ops.ietf.org Tue Oct 12 08:17:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13187 for ; Tue, 12 Oct 2004 08:17:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHLXx-000IB5-Hj for v6ops-data@psg.com; Tue, 12 Oct 2004 12:14:29 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHLXv-000IAc-Lv for v6ops@ops.ietf.org; Tue, 12 Oct 2004 12:14:28 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id EBD40AD; Tue, 12 Oct 2004 08:14:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 08:14: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSIFIED) Date: Tue, 12 Oct 2004 08:14:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A47D@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSIFIED) Thread-Index: AcSwTFCv+30ndb/lTtKFdgSYR2KK/gAB8peQ From: "Bound, Jim" To: "Klynsma, Steven L Mr CIO/G6/MITRE" , "Brian E Carpenter" , X-OriginalArrivalTime: 12 Oct 2004 12:14:26.0696 (UTC) FILETIME=[0478F080:01C4B055] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable To add to what Steve has so elegantly stated. I work with Defense = industry worldwide and others as SME and this is the case for all of = them. It is also one of the largest Enterprise revenue streams for IPv6 = TODAY worldwide for products and services that require transition. In = addition similar operational needs for many Crisis Management = enterprises, First Responders, Intelligence Organizations, Health Care, = Aviation, Fire Departments, Local Police Departments, etc. Also I = believe 3G will run Dominant IPv6 nets in IMS initially and then = further. Point is there is a business case for this and we shall = proceed with that as one of our customers for specs as IETF engineers.=20 Thanks /jim=20 > -----Original Message----- > From: Klynsma, Steven L Mr CIO/G6/MITRE=20 > [mailto:Steven.Klynsma@US.Army.Mil]=20 > Sent: Tuesday, October 12, 2004 7:12 AM > To: Bound, Jim; Brian E Carpenter; v6ops@ops.ietf.org > Subject: RE: REVIEW NEEDED:=20 > draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSIFIED) >=20 > Classification: UNCLASSIFIED > Caveats: NONE=20 >=20 > Brian,=20 >=20 > I work for the military and would dearly love to go to a=20 > dual-stack everywhere, but as Jim mentioned, that's simply=20 > not feasible. Unlike commercial users, we typically must=20 > develop our own unique comms networks that support unique=20 > military requirements (i.e. extremely constrained bandwidth=20 > (we feel lucky to have 16KBPS "pipes"), unpredictable, but=20 > inevitable and often lengthy, disconnects from network=20 > services, and a need for both host and routing infrastructure=20 > to be mobile). In such an environment, operating two routing=20 > protocols, as you must with dual-stack becomes quite=20 > problematic. In addition, because of the lengthy life cycles=20 > of weapon systems (15-20 years), you find yourself working=20 > with processors that are overloaded already. Throw a=20 > dual-stack requirement on this tactical environment and you=20 > break the camels back. =20 >=20 > So we are typically looking at replacing the entire tactical=20 > comms infrastructure. Given the other constraints on=20 > bandwidth, mobility, etc., it becomes very attractive to make=20 > the leap from IPv4 directly to IPv6 without a lengthy=20 > dual-stack transition period. However, that essentially=20 > creates an IPv6-only ISP supporting our weapon systems on the=20 > battlefield. Of course, this, in turn, comes with another=20 > set of problems, primarily for interoperablity with=20 > IPv4-based current systems and allies, but we hope by=20 > aggressively migrating the force to IPv6-dominance that these=20 > additional problems become manageable. >=20 > Vr,=20 >=20 > Steve =20 >=20 > -----Original Message----- > From: Bound, Jim [mailto:jim.bound@hp.com] > Sent: Tuesday, October 12, 2004 12:53 AM > To: Brian E Carpenter; v6ops@ops.ietf.org > Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt=20 >=20 > Brian,=20 >=20 > Responding to Pekka's draft tomorrow and others which is more=20 > difficult. But here is my response to you.=20 >=20 > > 1) My first concern is that somehow it misses the most=20 > important case=20 > > and the way I would recommend any enterprise to go. > >=20 > > In the terminology of the document that case is > >=20 > >=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > > |Application |Host 1 |Service |Host 2 |Application |=20 > > |----------- |Network|Provider|Network|---------- |=20 > > | Host 1 OS | | | | Host 2 OS |=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=20 > > |Dual or IPv4| | |Dual IP|Dual IPv4|=20 > > 0 | ---- |Dual IP|Dual IP | or |---- or ----|=20 > > | Dual | | |v4 only|Dual IPv4|=20 > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >=20 > > In other words, why would an enterprise choose to paint itself into=20 > > any of the awkward corners of the other 13 scenarios? >=20 > Sorry I cannot respond to such a general statement ok. Will=20 > continue to respond. All these cases are real cases and you=20 > or I or the IETF cannot second guess or mandate any=20 > transition to the enterprise. >=20 > > Just go for a dual stack operating system and routing=20 > system, and keep=20 > > calling your software suppliers until they upgrade to the=20 > new API. Why=20 > > make it harder than it needs to be?\ >=20 > This ia really na=EFve view it don't work that way at all and=20 > your assumption is one as casual and many are looking at ways=20 > to reduce cost and thus the 13 scenarios. >=20 > >=20 > > In fact, sections 4 and 7 are written in this spirit - they refer=20 > > essentially to what I have shown above as secnario 0. >=20 > Not really reread the vlan discussion.=20 >=20 > >=20 > > I just don't get what are the drivers for the other > > 13 scenarios.=20 >=20 > I can tell but they are all in ent scenarios doc.=20 >=20 > >Why would an enterprise accept any of them, rather than=20 > beating on its=20 > >suppliers for dual stack solutions? >=20 > Well because many of them have told us they are doing it. =20 > How about that for an answer. Every author is working on=20 > real deployment not fantasy abstractions. Don't shoot the messengers. >=20 > >=20 > > 2) My second main concern is these two statements:=20 > >=20 > > > 4.1 Phased Dual-Stack Deployment > > ...=20 > > > In this document we do not advocate or discuss the deployment of > > > Unique Local IPv6 Unicast Addresses [ULA].=20 > >=20 > > > 7.3.2 Obtaining global IPv6 address space ...=20 > > > Unique Local Addressing [ULAs] should not be used for=20 > enterprise =20 > > > networks.=20 > >=20 > > Not true and not OK. They were to a considerable extent=20 > designed for=20 > > enterprise networks. There will be a draft soon that discusses how=20 > > they could be used in enterprise networks, precisely to respond to=20 > > some of the reasons people use NATs.=20 > > It isn't OK for this draft to make such a statement about ULAs.=20 >=20 > I believe this is a partial bug the idea is to use global=20 > addresses within a distributed enterprise across a wide=20 > Internet. We need to just clean this up. >=20 > > The simplest solution is to remove both these references to ULAs.=20 >=20 > That may be an option.=20 >=20 > >=20 > > 3) My third main concern is that the draft doesn't discuss the=20 > > deployment of DMZs, which are a feature of all major enterprise=20 > > networks.=20 >=20 > Nor should we and we do not intend to.=20 >=20 > > A related point is that it doesn't=20 > > discuss how an enterprise will offer an IPv6 "web presence"=20 > > (or email presence) regardless of the state of its internal=20 > > transition. Maybe converting all its DMZ servers to dual=20 > stack would=20 > > be the first essential step for many enterprises.=20 >=20 > This draft is only dealing with Layer 3. Except in cases=20 > below like ALG/Proxy.=20 >=20 > >=20 > > Details:=20 > >=20 > > The summary at the end of section 1 doesn't mention section 7.=20 >=20 > Will fix.=20 >=20 > >=20 > > > 4.6 Other considerations=20 > > >=20 > > > There are some identified issues with turning IPv6 on by=20 > default, =20 > > > including application connection delays, poor=20 > connectivity, and >=20 > > network insecurity, as discussed in [V6DEF]. The issues can be >=20 > > worked around or mitigated by following the advice in [V6DEF].=20 > > >=20 > > > =20 > >=20 > > At least DNS, network management, and security policies need to be=20 > > covered.=20 >=20 > Not really we can mention them this is layer 3.=20 >=20 > >=20 > > > 5.1 Internal versus External Tunnel-End-Point > > > The=20 > > upstream provider could have already deployed some IPv6=20 > > > service, either native IPv6 in its backbone or in the=20 > > access > network, or a combination of both. Also, or=20 > alternatively,=20 > > could > have deployed one or several transition mechanisms based=20 > > upon > tunnels, for example in the case where the access network=20 > > doesn't > support IPv6.=20 > > In this case, the enterprise could decide to use > those=20 > available=20 > > transition services from the ISP. However, this > will=20 > usually mean=20 > > that the each of the different nodes in the > network will have=20 > > their own IPv6-in-IPv4 tunnel. Then, the IPv6 > intranet=20 > > communication will not be efficient, as it will require > all the=20 > > traffic to be forwarded by the=20 > > IPv4 infrastructure to the > Tunnel-End-Point located at the ISP.=20 > >=20 > > This would be unacceptable to 99% of enterprise security managers.=20 >=20 > Thanks for your opinion we should discuss for sure.=20 >=20 > >=20 > > > 7.3.1 Obtaining external connectivity > > > The enterprise=20 > > service provider would typically be a > topographically close (to=20 > > minimize connectivity RTT) IPv6 provider > that is able=20 > to provide=20 > > an IPv6 upstream link.=20 > > >=20 > > > It would be expected that the enterprise would use=20 > either native =20 > > > IPv6 upstream connectivity or, in its absence, a manually > =20 > > configured tunnel [BCNF] to the upstream provider.=20 > > >=20 > > > It is not recommended to use 6to4 [6TO4] or a tunnel=20 > broker [TBRK] =20 > > > for an enterprise deployment. The enterprise has a=20 > requirement for =20 > > > long-term, stable IPv6 connectivity. 6to4 and the=20 > tunnel broker > =20 > > are more appropriate for SOHO or single node environments.=20 > >=20 > > Sorry, but that's wrong. First of all, single-node 6to4=20 > isn't an IETF=20 > > solution - it has never been documented - so it's not=20 > accurate to cite=20 > > the RFC. Secondly, 6to4 as described in RFC=20 > > 3056 will work just fine for an enterprise - until the day=20 > its own ISP=20 > > provides native connectivity, of course. I'd say a SOHO=20 > user has less=20 > > chance of setting up RFC 3056 correctly than a large enterprise.=20 >=20 > Uh OH but good there will be strong disagreement. I am just editor.=20 >=20 > I see both views. Both are required.=20 >=20 > >=20 > > > ...Use of=20 > > > 6to4 also prevents the enterprise adopting aggregatable global=20 > > IPv6 > addressing from the outset.=20 > >=20 > > True... but so what? It's a solution you use only as long=20 > as you have=20 > > to, and then you switch to an aggregatable prefix.=20 > > This wouldn't affect internal network usage at all, apart from=20 > > updating the prefix.=20 >=20 > Point was to not mix the two we can make that clear. Once=20 > ISP has IPv6 6to4 is not required.=20 >=20 > >=20 > > > 7.3.2 Obtaining global IPv6 address space > > > The=20 > enterprise=20 > > will obtain global IPv6 address space from its > selected upstream=20 > > provider, as provider assigned (PA) address > space.=20 > > >=20 > > > The enterprise should receive at least a /48 allocation=20 > from its =20 > > > provider, as described in [ALLOC].=20 > >=20 > > I think you should refer to RIR policy directly; that RFC is only a=20 > > recommendation to the RIRs.=20 >=20 > Agreed.=20 >=20 > >=20 > > > 7.4.6 IPv4-IPv6 interworking=20 > > >=20 > > >=20 > > > In the case of an IPv6 only node in an IPv6-dominant or=20 > dual-stack =20 > > > enterprise, wishing to communicate with external=20 > IPv4-only systems, =20 > > > some interworking=20 > > (translation) method is required. The > translation could be=20 > > applied at Layer 3 (e.g. [NAT-PT]), Layer 4 > (e.g.=20 > > [SOCKS]) or Layer 7 (a dual-stack application layer gateway - > =20 > > ALG).=20 > >=20 > > I would also refer to a Layer 7 proxy. Also, since we seem=20 > to be about=20 > > to deprecate NAT-PT, it probably should not be mentioned.=20 >=20 > In this case I agree because it is an "assist to layer 3". =20 > Good idea.=20 >=20 > >=20 > > > 7.5.2 Supporting remote access=20 > > >=20 > > > Where an enterprise's users may be working off-site,=20 > and their > =20 > > transient ISP has no IPv6 support (natively or through=20 > transition > =20 > > aids) the enterprise should consider deploying its own=20 > transition > =20 > > (remote access) aid.=20 > > >=20 > > > Such an aid may be either a tunnel broker [TBRK],=20 > ideally one that =20 > > > supports operation through an IPv4 NAT, or a=20 > > 6to4 relay [6TO4]. If > a 6to4 relay is offered, the=20 > site should be=20 > > aware of security > issues with operating 6to4 relays=20 > [cite ref?].=20 > >=20 > > I think it's much more likely to be an IPSEC or IP-over-TLS tunnel,=20 > > which could be v6-in-v4 or v6-in-v6. That's how many=20 > enterprises offer=20 > > secure IPv4 "call home" today.=20 >=20 > Good point.=20 >=20 > >=20 > > > 8 Applicable Transition Mechanisms ...=20 > > > Basic Configured Tunnels:=20 > > >=20 > > > 6to4:=20 > > >=20 > > > Tunnel Broker:=20 > > >=20 > > > Teredo:=20 > > >=20 > > > DSTM:=20 > > >=20 > > > ISATAP:=20 > > >=20 > > > NAT-PT:=20 > >=20 > > Well, again, if we are deprecating NAT-PT, we can't include=20 > it here.=20 > > And the ALG/proxy alternative to NAT-PT needs to be listed.=20 > Probably,=20 > > IPv4-in-IPv6 tunnels should be listed too.=20 >=20 > I agree. DSTM is v4-in-v6 as a note.=20 >=20 > >=20 > > >=20 > > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=20 > > > |Application |Host 1 |Service |Host 2 |Application | =20 > > Recommended=20 > > > |----------- |Network|Provider|Network|---------- | =20 > > Transition=20 > > > | Host 1 OS | | | | Host 2 OS | =20 > Mechanism=20 > > >=20 > >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > =3D=3D=3D=3D=3D=3D=3D=3D=20 > >=20 > >=20 > > You need to give some rationale for the recommendations in the last=20 > > column.=20 > > But in any case, my main concern 1) applies to this whole table.=20 > > Scenario 0 is the interesting one, and it's missing.=20 >=20 > Its not missing it is not clear.=20 >=20 > >=20 > > The issue with NAT-PT applies to the entries for=20 > "translation", all of=20 > > which I would replace by "ALG/proxy."=20 >=20 > Personally I agree we can discuss with all authors.=20 >=20 > >=20 > > > Appendix B - Crisis Management Network Scenarios=20 > >=20 > > What's the value-add of this material in this document? It=20 > seems that=20 > > it should be published separately.=20 >=20 > Maybe but it depicts a real use case not a partial or=20 > abstract one and we authors want it in the spec.=20 >=20 > Thanks=20 > /jim=20 > >=20 > > Brian=20 > >=20 > >=20 > Classification: UNCLASSIFIED=20 > Caveats: NONE=20 >=20 >=20 From owner-v6ops@ops.ietf.org Tue Oct 12 09:41:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20256 for ; Tue, 12 Oct 2004 09:41:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHMrY-0001mu-BB for v6ops-data@psg.com; Tue, 12 Oct 2004 13:38:48 +0000 Received: from [66.218.78.101] (helo=web40404.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CHMrW-0001me-R4 for v6ops@ops.ietf.org; Tue, 12 Oct 2004 13:38:46 +0000 Message-ID: <20041012133846.89655.qmail@web40404.mail.yahoo.com> Received: from [24.5.84.18] by web40404.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 06:38:46 PDT Date: Tue, 12 Oct 2004 06:38:46 -0700 (PDT) From: Pyda Srisuresh Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt To: Elwyn Davies , Senthil Sivakumar Cc: "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.nortel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Elwyn Davies wrote: > That NAT-PT may stifle innovation is not an assumption but a deduction. As > is pointed out in the draft, NAT-PT cannot support all of the current > features of v6 (eg flow labels, MIPv6) and is unlikely to support any new > features. If the NAT-PT boxes operate autonomously (without something like > STUN, midcom or nsis to help), then all applications may well have to decide > to just use the subset of features supported by NAT-PT. If they can detect > that there is a NAT-PT box in the way then special case code may be needed > for destinations accessed through the NAT-PT to limit the capabilities used. > [suresh] As Soohong and others pointed out, supporting all V6 features was not the goal of NAT-PT. Making large no. of legacy apps work between V4 and V6 realms was the goal of NAT-PT. I..e, be a transition tool between v4 legacy and V6. Large number of commonly used apps work as is, with no change. But, not all of them. This has been a known limitation with NATs in general, NAT-PT included. > However if a proxy is used, all the special casing can be confined to the > proxy - the original application should be able to work untramelled (i.e. as > if working on a pure native v6 network when communicating with v6 addresses > - v4 functionality is unchanged). Hence I think the situation as regards > extra code is exactly the reverse of what you say: applications operating > with proxies can be unaware and unchanged; applications operating through > NAT-PT may need special case coding. [Suresh] If proxies are used in your enterprise and your apps (TCP and UDP) are all redone to work through proxies, you can be proxy happy. But, that is not a universal case. There are several setups where there is no proxy support and apps are not redone to be proxy-friendly (i.e.,apps do not use proxy). This is the scenario that NAT-PT addresses. > > The lack of compelling use cases for NAT-PT indicates that it isn't an > essential mechanism. Apart from a very limited set of cases dual-stack + > tunelling solves working across multiple realms. We need to get the message > out that NAT-PT is not a good thing and that there are other, better > solutions. That is the way to overcome resistance! [suresh] You miles may vary on the transition mechanims you choose to go with. NAT-PT is a transition mechanism that addresses real scenarios not addressed by others. Denying the real scenarios or deprecating NAT-PT is not a smart move to transition, IMHO. > > Regards, > Elwyn > regards, suresh > > -----Original Message----- > > From: Pyda Srisuresh [mailto:srisuresh@yahoo.com] > > Sent: 11 October 2004 14:58 > > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] > > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric > > [ADC:7Q30:EXCH]; 'V6OPS' > > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > Folks, > > > > As Senthil points out, the assumption that NAT-PT deployment > > will stifle > > innovation in v6 seems flawed. NAT-PT is a transition > > mechanism which is > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > resistance to deploying V6 . You need NAT-PT for legacy > > applications (ex: > > e-mail, ftp) to work as is across V4 and V6 realms. No change > > to end-hosts or > > applications. This is the attraction of NAT-PT. This is not > > the same as the > > proxy solution that will require applications to be > > changed/recompiled. > > > > > > cheers, > > suresh > > > > > > --- Senthil Sivakumar wrote: > > > > > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > > > > > >Three points: > > > >- The object of the draft was to summarize in one place > > all the problems > > > >with NAT-PT rather than being yet another delta on > > previous work. The > > > >introduction notes that several of the points are indeed > > generic address > > > >translation problems. This doesn't make them any less relevant. > > > > > > I am fine with summarizing the issues in one draft. But the > > draft points > > > out those as reasons to deprecate > > > which is what I am pointing out. > > > > > > >- The draft is specifically targeting the NAT-PT = SIIT + > > DNS-ALG solution > > > >intended for use as a generic inter-cloud translator. It > > is clear to me > > > >that a 'cut down' form has a use as a legacy v4 'server > > adaptor' front end > > > >where there is only one v4 address (or maybe a server > > cluster) on one > > > >side, it only has to handle a pre-defined set of > > protocols, and it doesn't > > > >need a DNS-ALG. I think this should be the subject of a > > separate draft. > > > > > > While I agree with you the cut-down solution does not need > > a DNS-ALG, I > > > don't think it has to handle a > > > specific set of protocols. I could still be a generic > > purpose translator > > > for facilitating transition. I am attaching > > > a document which was one of the use case scenario we are aware of. > > > > > > >- The fundamental point is whether v6ops should still be > > continuing to > > > >support a technology which will, if widely deployed, > > effectively stifle > > > >innovation in v6 networks. The need for applications to > > be aware that > > > >NAT-PT exists effectively condemns v6 to be just v4 with > > larger addresses > > > >at the application level. Is this what is wanted? Or > > should we really be > > > >trying to put the architectural flexibility back into the Internet? > > > > > > I am not understanding why you say applications have to > > aware of existence > > > of NAT-PT. > > > > > > > > > >It would be useful to see Shivkumar's use cases so that > > they could be > > > >considered for inclusion in the relevant transition > > analysis. If people > > > >are using NAT-PT in a particular way then we need to give > > them a workable > > > >alternative before ditching NAT-PT. > > > > > > Exactly. We should not prematurely deprecate the solution > > without an > > > alternative in place. > > > > > > Thnks > > > Senthil > > > > > > >Regards, > > > >Elwyn > > > > > > > > > -----Original Message----- > > > > > From: Sham Chakravorty > > > > [mailto:schakra@mitre.org] > > > > > Sent: 09 October 2004 18:35 > > > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > > > [HAL02:0S00:EXCH] > > > > > Subject: RE: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really > > doesn't earn us > > > > > anything but removes one tool that could be used in specific > > > > > instances. > > > > > Application gateways are not in the same usage "level" as > > > > > NAT-PT - they > > > > > occur in different points of the network. Also, the > > > > > underlying algorithm of > > > > > SIIT would still be available. > > > > > > > > > > Sham > > > > > > > > > > -----Original Message----- > > > > > From: owner-v6ops@ops.ietf.org > > > > > > > [mailto:owner-v6ops@ops.ietf.org] On > > > > Behalf > > > > > Of Brian E Carpenter > > > > > Sent: Saturday, October 09, 2004 9:10 AM > > > > > To: Senthil Sivakumar > > > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > > > Subject: Re: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with no > > > > > workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the use > > > > > case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > But there is a workable alternative, which is an application > > > > > level proxy. > > > > > This too has its disadvantages, of course. > > > > > > > > > > Brian > > > > > > > > > > Senthil Sivakumar wrote: > > > > > > I see that the draft has consolidated all the > > previous drafts that > > > > > > highlighted the issues > > > > > > of NAT-PT and DNS ALG, which is a good thing. > > However, most of the > > > > > > issues mentioned > > > > > > here as NAT-PT issues are known issues with address > > > > > translation (NAT) > > > > > > itself, so > > > > > > attributing them to NAT-PT is not correct. Those should be > > > > > categorized > > > > > > as generic address > > > > > > translation issues. > > > > > > > > > > > > Some specfic comments on the following issues. > > > > > > > > > > > > * Disruption of all protocols which embed IP > > addresses (and/or > > > > > > ports) in packet payloads or which apply integrity > > > > > mechanisms > > > > > > using IP addresses (and ports). (not NAT-PT > > specific). > > > > > > > > > > > > * Requirement for applications to use keep alive > > > > > mechanisms to > > > > > > workaround connectivity issues caused by premature > > > > > NAT-PT state > > > > > > timeout. (not NAT-PT specific). > > > > > > > > > > > > * Inability to redirect packet fragments after the > > > > > first with > > > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > > > * Constraints on network topology. (not NAT-PT > > specific). > > > > > > * Scalability concerns together with introduction of > > > > > single point > > > > > > of failure and security attack nexus.(not > > NAT-PT specific). > > > > > > * Lack of address mapping persistence: Some > > > > > applications require > > > > > > address retention between sessions. The user > > > > > traffic will be > > > > > > disrupted if a different mapping is used. > > The use of the > > > > > > DNS-ALG to create address mappings with limited > > > > > lifetimes means > > > > > > that applications must start using the address > > > > > shortly after > > > > > > the mapping is created, as well as keeping it > > > > > alive once they > > > > > > start using it.(not NAT-PT specific). > > > > > > * Creation of a DOS threat relating to exhaustion of > > > > > memory and > > > > > > address/port pool resources on the > > translator.(not NAT-PT > > > > > > specific). > > > > > > > > > > > > Regarding the conclusion, I don't agree with the fact > > that only > > > > > > applicable scenario > > > > > > is in 3G networks. During the past couple of years of my > > > > > experience I > > > > > > have seen > > > > > > customers using it between isolated IPv6 networks to talk > > > > > to existing > > > > > > IPv4 networks. > > > > > > A lot of cases it is not about the nodes being dual stack > > > > > or not, it is > > > > > > the network > > > > > > that is not dual stacked for operational reasons. > > > > > > > > > > > > I have been gathering some inputs from the customers > > who are using > > > > > > NAT-PT currently > > > > > > regarding this draft. I can consolidate and forward the > > > > > comments if you > > > > > > are interested in > > > > > > knowing and understanding why they think they are moving > > > > > forward with > > > > > > NAT-PT. > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with > > > > > > no workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the > > > > > > use case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > > > Senthil > > > > > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > > > > > >> Hi, > > > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > > > >> deprecation analysis. > > > > > >> We would really appreciate if you could provide us your > > > > > feedback on > > > > > >> the initial version of the deprecation analysis by Monday > > > > > October 4th. > > > > > >> Regards > > > > > >> Cedric Aoun > > > > > >> ------ Forwarded Message > > > > > >> From: > > > > > >> Reply-To: > > > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > > > >> To: > > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> > > > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > > >> directories. > > > > > >> > > > > > >> > > > > > >> > > > > > >> Title : Reasons to Deprecate NAT-PT > > > > > >> Author(s) : C. Aoun, E. Davies > > > > > >> Filename : > > draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> Pages : 24 > > > > > >> Date : 2004-9-21 > > > > > >> > > > > > >> This document discusses reasons why use of the > > specific form of > > > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > > > the Network > > > > > >> Address Translator - Protocol Translator (NAT-PT) > > > > > defined in RFC 2766 > > > > > >> should be deprecated and RFC2766 moved to historic status. > > > > > >> Description of an alternative protocol translation > > > > > mechanism is out > > > > > >> of scope for this document. > > > > > >> > > > > > >> A URL for this Internet-Draft is: > > > > > >> > > > > > > > > > > > > > > < > e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > > > > > > > precate-00.txt > > > > > > > > > e>http://w > > > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > precate-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://w > ww1.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-aoun-v6ops-natpt-deprecate-00.txt". > > > > > >> > > > > > >> A list of Internet-Drafts directories can be found in > > > > > >> > > > > > > > > > <http://www.ietf.org/shadow.h > > tml>http://www.ietf.org/shadow.html > > > > > > > > > > > > >> or > > > > > >> > > > > > > > > > > > > > > <ftp://ftp.ietf.org > > /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > > > > > > > >ietf/1shadow-s > > > >ites.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-aoun-v6ops-natpt-deprecate-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. > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> ------ End of Forwarded Message > > > > >> > > > > > > > > > > > > > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; > > x-mac-type=42494E41; x-mac-creator=4D535744 > > > > > > > > ===== > > > > > > > ===== From owner-v6ops@ops.ietf.org Tue Oct 12 09:52:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20718 for ; Tue, 12 Oct 2004 09:52:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHN4N-0003M1-RY for v6ops-data@psg.com; Tue, 12 Oct 2004 13:52:03 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHN4L-0003Lc-9x for v6ops@ops.ietf.org; Tue, 12 Oct 2004 13:52:01 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A959EA336 for ; Tue, 12 Oct 2004 09:52:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Tue, 12 Oct 2004 09:52:00 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Date: Tue, 12 Oct 2004 09:52:08 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A4A3@tayexc13.americas.cpqcorp.net> Thread-Topic: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Thread-Index: AcSvhBEB09Ix0mvARayDVm4lfT7yNAAiJ1rAABUP6uA= From: "Bound, Jim" To: X-OriginalArrivalTime: 12 Oct 2004 13:52:00.0504 (UTC) FILETIME=[A59D2780:01C4B062] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Pekka, Responses in line. > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Pekka Savola > Sent: Monday, October 11, 2004 7:14 AM > To: v6ops@ops.ietf.org > Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) >=20 > In short, I think the doc is a good start, but obviously as all=20 > initial documents, can always find a room for improvement. Hopefully=20 > my comments below help in that. They did yes. Thank You. Reflect belows mean we need to think on how to fix or make more clear in the spec. >=20 > substantial > ----------- >=20 > 1) > 1.a) the matrix in section 3 (and sect 8) appears to be out of sync=20 > from the description of section 3 (see below for 'v6 to v4'), for=20 > example because the text says trivial scenarios have been removed, but > matrix lines 1,2,12, and 13 (at least) are extremely trivial. What=20 > has happened? We need to add more text to sect 3 and 8. If trivial but pivotal to the analysis we kept them in the draft for later context and why we have more writing to do. >=20 > 1.b) Further than that, one thing I'd like to see is slightly more=20 > text (if that's not too difficult to manage) describing as precisely=20 > as reasonable how the table has been 'derived', in a manner that the=20 > reader would be able to follow which combinations have been omitted=20 > and due to what reasons. > That would allow one to better analyze that all the cases have been=20 > dealt with (in one manner or another). I think we can enhance that text but don't think it wise to discuss that which is omitted because that can cause a rathole. Would suggest that WG tell us what needs to be added? >=20 > Please also remember that even the trivial tunneling/translation=20 > scenarios will need to be described if we need a (new) solution to=20 > them. We believe we have that covered. What do you mean by new solution that may help? >=20 > 1.c) you may need to end up having to define the columns of the=20 > matrix carefully. In particular 'Host X network' (I read it as "the=20 > enterprise network originating the packets") has at least one=20 > ambiguity. How do you represent the fact that the first-hop link of a > dual-stack node supports only one protocol version, but further down=20 > the enterprise network both protocols are supported ? We do that by the protocol in the cell but we can explain that better for further input to see if WG believes it is correct. Seems we need to describe the cells better from recent input. >=20 > 1.d) there also seem to be some scenarios which are either too far in > the future or easily worked around which might be decreed out of=20 > scope. For the former, consider the cases of v6-only ISPs -- I don't=20 > think these are worth the energy at this point of time. Or do you=20 > refer to *dual-stack* ISPs who are offering only v6 services (and=20 > provide translation/tunneling for v4 legacy)? For the latter,=20 > consider the scenario 4, i.e., v6-only application run on a dual-stack > host, towards an IPv4-only application. I mean, what would the point=20 > of creating v6-only application which needs to talk to v4-only=20 > application, because doing such would nullify all the benefits of IPv6 > -- couldn't one just say that one should do a dual-stack app in that=20 > case? I would agree on v6 only ISPs and that really is dual stack for some time. But we as a team and many in this WG do believe IPv6 dominant networks will be supported and we intend to leave that scenario and matrix cell in the spec but we can keep discussing. =20 We do need to make it clear an ISP will not be v6 only that was not our intention either. >=20 > [IMHO, v6-only apps should never be used if that necessitated the=20 > translation to v4, because doing so would nullify the usefulness of=20 > v6-only app to begin with, or requiring embedding a lot of v4 hacks in > the translator -- both would seem like non-starters to me] V6only apps implies a dual stack. It should say v6 apps. =20 >=20 > 2) section 4.5 and 7.5.2 describe some approaches to remote > IPv6 access support, but Introduction ruled IPv6 VPN's as out of=20 > scope. These could be seen as contradictory (but maybe the latter=20 > referred to v6-in-v6 VPNs, I don't know).. maybe it needs to be=20 > clarified what's in scope and what's not? Scoping for most sections is still required I agree. >=20 > (Section 4.5 is not clear whether you're addressing the 'branch=20 > office' or 'home user' case.. probably the latter?) We are addressing the enterprise and enterprise remote sites. We need to make that clear this section is incomplete now. Most enterprises run their own Internet Walmart, GM, DOD, Renault, Boeing, etc and each will have different views and business reasons for deploying IPv6. Again one-size-does-not-fit-all. >=20 > 3) section 4.1 says that ULAs are not considered or advocated in this=20 > doc, while 7.3.2 says they should not be used. These appear to be=20 > conflicting statements. I think it'd be useful to mention ULAs, state > that they are not > *necessary* but could be used under specific conditions, and possibly=20 > to point to another document to come [on > NAT-PT/RFC1918 alternatives]. Good catch. >=20 > 4) > 7.4.1 IPv6 DNS > =20 > =20 > =20 > The enterprise site should deploy a DNS service that is capable of =20 > both serving IPv6 DNS records (of the AAAA format, see RFC????) and =20 > of communicating over IPv6 transport. > =20 > =20 > =20 > Specific IPv6 DNS issues are reported in [DNSV6]. >=20 > =3D=3D> I think it would be useful to make it clearer here that while = the=20 > v6 transport is nice, it's in no way requirement for anything, except=20 > for deploying v6-only nodes. Not sure I agree. V4 or v6 transport is a choice we assume dual stacks? >=20 > (For example, in our enterprises, we haven't been able to field v6=20 > transport resolver support in 2-3 years due to a number of reasons,=20 > but that hasn't stopped us from deploying > v6 -- the document should (IMHO) give as few as possible requirements=20 > for "moving forward" with IPv6. Agree. >=20 > The similar occurs in 7.4.3: >=20 > A stateless configured node wishing to gain other configuration =20 > information (e.g. DNS, NTP servers) will likely need a Stateless > DHCPv6 service available. >=20 > , where this doesn't clearly identify that these are not strictly=20 > necessary for dual-stack systems.. because they are already configured > using v4 protocols and means. Just to make it clearer that these are=20 > not a strict requirement for > v6 deployment.. Agree. >=20 > 5) a few further comments on the matrix in section 8: >=20 > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | IPv6 | | | | IPv6 |IPv6=20 > Host Tunnel > 3 | ---- | IPv4 |Dual IP |Dual IP| ---- =20 > |(Brokered atISP) > | Dual | | | | IPv6 | >=20 > =3D=3D> isn't this a conflict with this statement in Introduction: >=20 > We are also assuming that the enterprise deployment is one being =20 > undertaken by the network administration team, i.e. > this document is not discussing the case of an individual user=20 > gaining IPv6 connectivity (to some external IPv6 > provider) from within an enterprise network. >=20 > (i.e., it seems as if there is zero v6 support in the home enterprise, > so the host gets it from the ISP-- but this was considered out of=20 > scope...) >=20 > | IPv6 | | | |IPv4 IPv4|Translation on > 4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6 > | Dual | | | |IPv4 Dual|domain >=20 > =3D=3D> as said, IMHO this nullifies the usefulness of creating = v6-only=20 > applications so wouldn't it be better to just require such apps to=20 > support > v4 as well? (there may be a couple of rare exceptions to this, like=20 > 3GPP IMS, but those are another story) I think first we need to provide support for all possibilities and we cannot require users to deploy our view, only provide mechanisms for scenarios we believe we have heard. And there are enough users want to run IPv6 dominant subnets immediately and this does not mean nor to we imply v6 only anything if so we need to fix it. We should not be doing business cases for IPv6 in the IETF. That is what will determine how transition is done in the market. Out of scope for the IETF. >=20 > | IPv6 | | | | IPv6 |IPv6=20 > Host Tunnel > 5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at > | Dual | | | | IPv6 |Net2) >=20 > =3D=3D> this would appear to be case where the host tunnel is brokered = > across the Internet. What reason would Net2 have for providing this=20 > to other enterprises? Do you have specific assumptions about their=20 > relations? We can do that but point is decap via Tunnel Broker at remote site is something we have heard. I agree with all the security concerns when Enterprise is going to public Internet. >=20 > |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site > 6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel| > |IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?) >=20 > =3D=3D> wouldn't this be creating something like 'v6 6bone mess'=20 > (especially if sites are 'v6 only', which we all probably want to=20 > avoid? I mean, is there a specific problem in the current approach,=20 > i.e., the enterprises which want to connect other v6 enterprises to=20 > get v6 ISPs which are globally connected throughout the Internet ? We have heard it is a requirement and it is an option. >=20 > | IPv6 |Dual IP| IPv4, | | IPv4 |Translation on > 7 | ---- | or | IPv6 or| IPv4 | ---- |local IPv6 > | IPv6 |v6 only|Dual IP | | IPv4 |domain >=20 > =3D=3D> isn't this a regular 'why don't you just run dual-stack = instead'=20 > argument ? Good point we need to discuss this as authors given the NAT-PT discussion. One issue is if the dual stack node cannot get a required routable address to communcate with the legacy IPv4 only stack node. >=20 > | Dual | | | | IPv4 |DSTM for > 10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6 > | Dual | | | | IPv4 | > =20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > | Dual | | | | IPv4 |DSTM for > 11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6 > | Dual | | | | IPv4 | >=20 > =3D=3D> you are proposing to run DSTM over Internet, right? No DSTM just provides address on the link or subnet. Nomenclature positioning needs work. > I > don't think it was ever (except for separate DSTM VPN I-D) designed to > run like that, and it would likely have significant amount of security > issues. That was old AIIH proprosal but that is not being suggested at all. > I also don't see the element in the middle which would support=20 > dual-stack?!? i.e., how does v6 only site talk through v6-only ISP to > a v4-only site, for example? Also, (repeating from matrix line 5=20 > above), what would be the justification for Net2 to provide such=20 > Interdomain service ? This is a bug. The v4 is encaped in v6 to the edge, and we can define the edge better. Good catch. >=20 > 6) I'm having slight problems, at least yet, at seeing what is the=20 > role of > appendix B in this document. This seems to be partially=20 > duplicating the > text from enterprise scenarios, or..?=20 Not really it is an example of a real network reinforcing the enterprise and the objective of the appendix. > It also has some > specific discussion and good analysis. Should some parts of this be=20 > in the body, in a separate document, or..? [also note, the text is=20 > rather unreadable because some lines are wrapped oddly -- are you=20 > using good tools e.g. xml2rfc for editing?] I think so too but we ran out of writing time for last draft :--) >=20 > semi-substantial > ---------------- >=20 > IPv6 Enterprise Network Analysis >=20 > =3D=3D> given that the document restricts itself to (mainly) L3=20 > considerations, would there be simple ways to try to reflect that=20 > somehow in the title of the draft and intro/abstract? > For example insert 'connectivity' there? Not a big issue. We want to talk among authors on that one I can't comment on this other than from the recent input it might make it more clear that this spec is about Layer 3 with a few exceptions. >=20 > =3D=3D> s/Analysis/Transition Analysis/ ? Thanks. >=20 > Abstract and introduction say: >=20 > This document analyzes the transition to IPv6 in enterprise networks. >=20 > =3D=3D> should one say "to using IPv6" instead, given that the focus = of=20 > the document is not go all the way to the get to IPv6(-only), but the=20 > first step being providing the IPv6 capability? I think so yes. >=20 > ... >=20 > As an example, Scenario 1 is an IPv6 application trying to establish=20 > a communications exchange with a destination v4 only application. >=20 > =3D=3D> uhh?? Not by the matrix at least -- maybe some matrix lines = were=20 > removed? (see also substantial issue 1 above) Will fix. >=20 > Then, the IPv6 > intranet communication will not be efficient, as it will require all > the traffic to be forwarded by the IPv4 infrastructure to the =20 > Tunnel-End-Point located at the ISP. > This could be acceptable if the IPv6 applications do not require=20 > intranet communication at all, for example in the case the=20 > application server that is located outside of the enterprise network, > or in other networks of the same enterprise. Need to reflect more and thanks. >=20 > =3D=3D> this section discusses only efficiency (AFAICS), but a major=20 > factor whether to pass internal traffic to the ISP (and > back) is about trust. For most enterprises I know (and all the big=20 > ones, I'd suspect), they don't want to give external folks any chance=20 > of intercepting internal communications, which might or might not be=20 > encrypted, and might or might not contain classified information. Agreed. >=20 > If the tunnel end-point is at the ISP, there is no way to prevent=20 > this. > Thus I can imagine no scenario, where an enterprise (which would have=20 > more than a couple of employees, or operate w/ > encryption) would want to put the end-point out of it's own trusted=20 > network. OK needs reflection yes. >=20 > This also becomes an issues of redundancy; if the communications to=20 > the ISP breaks down e.g., temporarily, is the internal traffic=20 > affected? Having internal tunnel endpoint would ensure that one would > be able to continue without disruptions. Needs reflection yes. >=20 > ........ >=20 > 5.2 Manual versus Autoconfigured > =20 > =20 > =20 > =20 > =20 > =20 > If the number of nodes to be using IPv6 is reduced, an option is to =20 > use statically configured tunnels. > =20 > =20 > =20 > However, in general automatic configured tunnels will be preferred. > =20 > =20 > =20 > Section 5 doesn't yet discuss pros and cons of connecting sparse =20 > nodes, nor management/security issues. We need to add that in -01. >=20 > =3D=3D> this isn't complete yet, so I don't know if you intended to=20 > discuss these or not but here are a couple of potential > considerations: >=20 > - are you considering just autoconfigured set-up ('assisted=20 > tunneling' or 'zero-conf tunneling'), or also "direct tunneling" ? > - are you considering whether there are internal NATs in the=20 > enterprise or not (I don't personally know whether this is typical or=20 > not) ? > - do you consider whether there are multiple boxes or just one (and=20 > if multiple, how are would they be distributed [e.g., geographically]) > i.e., the number of users? All of the above have to be part of our analysis but how we present that is TBD. >=20 >=20 > ....... >=20 > 7.4 Phase 2: Deploying generic basic service components > =20 > =20 > =20 > =20 > =20 > =20 > Most of these are discussed in Section 4 of [BSCN]. Here we > comment on those aspects that we believe are in scope for this =20 > analysis document. Thus we have not included network management, =20 > multihoming, multicast or application transition analysis here, but =20 > these aspects should be addressed in Phase 2. >=20 > =3D=3D> I may be misunderstanding the last line, but isn't that saying = > that section 7.4 should be addressing this, or are you referring to=20 > the "next round" of enterprise evaluation (beyond the basic concepts)=20 > ? This is a huge bug we need to fix this. Good catch. This was mean't to say these are next level common transition issues for deployment all our v6ops docs have not addressed so lets not pick on enterprise analysis. =20 >=20 > ........... >=20 > .... >=20 > For secure autoconfiguration, the SEND protocol is defined (now at =20 > RFC????). >=20 > =3D=3D> because deploying SEND is not necessarily quite as trivial as=20 > this, maybe a placeholder should be put here, like 'The best practices > for deploying the necessary certificates need to be analyzed.' Yes. >=20 > ........ >=20 > Hosts may also generate or request IPv6 Privacy Addresses (RFC3041); > there is support for DHCPv6 to assign privacy addresses to nodes in=20 > managed environments. >=20 > =3D=3D> is there actually any justification for using RFC3041 in=20 > enterprise environments? Should one put such a doubt here if not? =20 > Personally, I'm having trouble figuring out the actual problem... Me to I defer to my co-authors :--) >=20 > .... >=20 > Use of [NAT-PT] is discouraged [cite the I-D on this?]. A recommended > solution is the use of ALGs. Many applications naturally have an ALG=20 > behavior, and can be used to offer access for "legacy" IPv4 services=20 > such as SMTP (dual-stack email server, see [cite I-D, by Alain I=20 > think?]) or HTTP (a dual-stack web cache), and are already operated=20 > by many enterprise sites. By dual-stacking the servers, an IPv6 only=20 > node can reach an external IPv4-only web site (for example) via the=20 > proxy without any additional (Layer 3 or > 4) translation being required. >=20 > =3D=3D> it would be worth mentioning (at least as a problem, if not=20 > further > discussed) in a new paragraph how one would configure such proxies or=20 > translators on the v6-only nodes. Manually? > Using yet-to-be-defined DHCPv6 options? Using unspecified means? Hmmmm to some degree yes but we don't want to own that one in this spec we may need some WG help on this one. >=20 > Such an aid may be either a tunnel broker [TBRK], ideally one that =20 > supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If a > 6to4 relay is offered, the site should be aware of security issues=20 > with operating 6to4 relays [cite ref?]. >=20 > =3D=3D> are you referring to the 6to4 relay usage in a manner where = the=20 > enterprise would provide a 'private' 6to4 relay, just for its own=20 > users who would need to know its v4 address, and manually configure it > on their laptops (w/ using public addresses)? Note that there is no=20 > provision for access control here. Considering how common the NATs=20 > are, this seems like something that doesn't have sufficient "return=20 > value" for the enterprise, considering that there are plenty of free=20 > relays reachable through the anycast prefix. I agree and we need more reflection ok. >=20 > There is ongoing work on auto-transition and assisted tunneling =20 > tools that may also be applicable as remote access aids [cite refs?]. Yikes. I don't think so nor that auto transtion can ever achieve consensus as its an implementation issue. But if WG goes forward so will we but I don't think so. As my input. >=20 > =3D=3D> possibly, but please note that most of those focus on the = scenario > where the access is provided by the first-hop ISP. > What you're looking for is something like assited tunneling registered > mode ('TSP') or v6-supporting L2TP (which is not a necessarily a big=20 > problem, as PPP supports v6 trivially). I agree. >=20 >=20 >=20 >=20 > procedural > ---------- >=20 > =3D=3D> there is one author too many (6 > 5). If it is not possible = to=20 > reduce the number of authors, the alternative would be just listing=20 > the editor in the front page, and the authors in the contact=20 > information or contributors. I want to fight for an exception on this ok. So I will get ready to ask. I understand but these folks names all should be listed. =20 >=20 > =3D=3D> there are a lot of documents in 'normative references'. =20 > These are meant to be documents which are required to be read to=20 > understand the document. > Please note that this doc cannot be published until all of these are=20 > also published. Is that intentional? Maybe some shuffling around=20 > would be warranted? Thanks we need to address that process. >=20 > editorial > --------- >=20 > =3D=3D> there are quite a few references with 'RFC????' or the like -- = > these should be filled in (naturally ;-), and maybe put in as=20 > informative references explicitly. (Also a mention of I-D in 7.4.6,=20 > that would be > draft-motonori-dualstack-smtp-requirement-01.txt) Thanks. >=20 > =3D=3D> Introduction and Abstract use the term 'Provider' before it's=20 > defined, and as such, it isn't clear to the reader that you refer to=20 > the ISP with it. Gee wizzzzzzzzzzzzzzz ok. >=20 > Two possible fixes: > 1) rename Provider to ISP (because the terminology requires providing > connectivity in any case, so this looks pretty close to ISP to me), or > 2) expand Provider to ISP in abstract/introduction. Will reflect on this. >=20 > ... >=20 > The audience for this document is the enterprise network team =20 > considering deployment of IPv6. The document will be useful for =20 > enterprise teams that will have to determine the > IPv6 transition strategy for their enterprise. >=20 > =3D=3D> there appears to be some overlap with these sentences ? Agreed. >=20 > The enterprise analysis will begin by describing a matrix tool to be > used to portray the different IPv4 and IPv6 possibilities for =20 > deployment. The first column (Application/Host 1 OS) represents the =20 > IP-capability offered by the node that originates IP packets. The =20 > second to last column (Application/Host 2 OS) represents the IP- =20 > capability offered by the node that terminates the IP packet. In=20 > between are three columns that represent the IP-capability of typical > networks traversed by the packet, including an originating host=20 > network (Host 1 Network),Service Provider Network and Destination=20 > Host Network (Host 2 Network). Each row (1 through 13) is one=20 > possible scenario and the final column shows the recommended =20 > transition mechanism to use for that particular scenario. >=20 > =3D=3D> in the matrix in section 3, there it's the last column.=20 > (This also applies in the text in section 3) OK. >=20 > =3D=3D> actually, I think the discussion here is slightly out of = place, as > it's already there in section 3 (where it's better placed). I'd=20 > consider just summarizing this paragraph here to one or two sentences, > and referring to fuller description in section 3. Need to reflect. >=20 > IPv6 only - A node or network capable of supporting only > IPv6. This does not imply an IPv6 only > stack, in this document. >=20 > =3D=3D> I find the last sentence slightly confusing, maybe it would = better > read like 'In this document, a dual-stack node which has disabled IPv4 > stack is also considered IPv6 only.' That is better yes. >=20 > Many router platforms can tag multiple VLAN IDs on a single physical=20 > interface based on the subnet/link the packet is destined for >=20 > =3D=3D> 'Many' ? Are there platforms which *can't* do it? I'd be=20 > surprised :). > Maybe just remove 'Many' or replace with 'Practically all'. Yep. >=20 > The parallel infrastructure would only ever be seen as an interim step > towards a full dual-stack deployment on a unified infrastructure. >=20 > =3D=3D> could 'would only ever be seen' be reworded? That seems like = a=20 > complex structure of words for us foreigners.. Will reflect. >=20 > =20 > =20 > =20 > The upstream provider could have already deployed some IPv6 service,=20 > either native IPv6 in its backbone or in the access network, or a=20 > combination of both. Also, or alternatively, could have deployed one=20 > or several transition mechanisms based upon tunnels, for example in=20 > the case where the access network doesn't support IPv6. In this case, > the enterprise could decide to use those available transition=20 > services from the ISP. However, this will usually mean that the each=20 > of the different nodes in the network will have their own > IPv6-in-IPv4 tunnel. Then, the IPv6 intranet communication will not=20 > be efficient, as it will require all the traffic to be forwarded by=20 > the IPv4 infrastructure to the Tunnel-End-Point located at the ISP.=20 > This could be acceptable if the IPv6 applications do not require=20 > intranet communication at all, for example in the case the=20 > application server that is located outside of the enterprise network, > or in other networks of the same enterprise. >=20 > =3D=3D> s/could/it could/ ? > =3D=3D> could this paragraph be broken into two (or three), making it = more > digestible? :-) Yes. >=20 > The enterprise could also decide to deploy its own transition box =20 > and possibly collocate it adjacent to the border router that >=20 > =3D=3D> s/collo/co-lo/ >=20 > IPv6 communications between IPv6 nodes will use IPv6 to communicate. >=20 > =3D=3D> sounds like a no-op ? >=20 > Author's Address >=20 > =3D=3D> make that "Authors' Addresses" ;-) Thanks /jim From owner-v6ops@ops.ietf.org Tue Oct 12 10:02:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21225 for ; Tue, 12 Oct 2004 10:02:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHNEN-000512-Pb for v6ops-data@psg.com; Tue, 12 Oct 2004 14:02:23 +0000 Received: from [66.218.92.33] (helo=web40422.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CHNEM-00050N-I1 for v6ops@ops.ietf.org; Tue, 12 Oct 2004 14:02:22 +0000 Message-ID: <20041012140221.61106.qmail@web40422.mail.yahoo.com> Received: from [24.5.84.18] by web40422.mail.yahoo.com via HTTP; Tue, 12 Oct 2004 07:02:21 PDT Date: Tue, 12 Oct 2004 07:02:21 -0700 (PDT) From: Pyda Srisuresh Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt To: Pekka Savola Cc: Senthil Sivakumar , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Pekka Savola wrote: > This is a fundamental deployment argument than one about NAT-PT, but > nevertheless I guess this should be said.. > [suresh] Thanks. Hence the argument for not deprecating it. > On Mon, 11 Oct 2004, Pyda Srisuresh wrote: > > As Senthil points out, the assumption that NAT-PT deployment will stifle > > innovation in v6 seems flawed. NAT-PT is a transition mechanism which is > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > resistance to deploying V6 . You need NAT-PT for legacy applications (ex: > > e-mail, ftp) to work as is across V4 and V6 realms. > > This ('NAT-PT.. essential for wider V6 deployment') may or may not be > true if you assume that there will be strong incentives for deploying > IPv6-only systems which need to talk to a vast majority of v4 systems > in the near future. [suresh] Not sure what you meant. I am not making any assumptions about the size of deployments, given the early stage yet for V6. I am merely refering to the likely scenario of V6-only and V4-only nodes. > If that's not the case, it's certainly not > correct -- you can deploy IPv6 as dual-stack without any need for > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about difficulties the defence dept faces to transition to dual stacks. It just goes to show that the IETF can only offer transition mechanims, but not mandate one. When the choices are comprehensive, the customers will pick the one that best suits their environment. > > No change to end-hosts or > > applications. This is the attraction of NAT-PT. This is not the same as the > > proxy solution that will require applications to be changed/recompiled. > > You don't need to change end-hosts or applications (in the manner you > probably mean) if you deploy dual-stack. If you deploy v6-only, you > need to change end-hosts MORE than with dual-stack. > [suresh] Please see my comment above. > I have the feeling that most typical applications applications already > support proxies or have inherent support for middleboxes (e.g., http, > smtp, dns, ftp). [suresh] Disagree with your comment about proxies. What did you mean by "inherent support for middleboxes"? Middleboxes refer to many things including proxies, NATs and NAT-PTs. > Changes are only necessary if one would like to > pursue a generic 'SOCKS' -like approach for IPv6 deployment, but that > has not gotten much deployment AFAICS. [suresh] I cant quite parse what you are saying here. Please see my earlier comments about deployment scenarios and need to have a comprehensive choices for users to transition to. It would be a mistake for the IETF to deprecate NAT-PT. As vendors had done in the past, vendors will deploy solutions that fits customer needs, irrespective of what the IETF does. It would help if the IETF was not oblivion to real-world customer needs. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > regards, suresh ===== From owner-v6ops@ops.ietf.org Tue Oct 12 13:21:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10477 for ; Tue, 12 Oct 2004 13:21:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CHQHv-0003N6-Em for v6ops-data@psg.com; Tue, 12 Oct 2004 17:18:15 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CHQHt-0003Mq-9B for v6ops@ops.ietf.org; Tue, 12 Oct 2004 17:18:13 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 12 Oct 2004 10:18:38 -0700 X-BrightmailFiltered: true Received: from ssenthil-w2k.cisco.com (dhcp-128-107-163-197.cisco.com [128.107.163.197]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9CHI9gS004366; Tue, 12 Oct 2004 10:18:09 -0700 (PDT) Message-Id: <4.3.2.7.2.20041012101337.02ee0eb0@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Oct 2004 10:18:54 -0700 To: "Elwyn Davies" From: Senthil Sivakumar Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Cc: "'Pyda Srisuresh'" , "'Sham Chakravorty'" , "'Brian E Carpenter'" , "Cedric Aoun" , "'V6OPS'" In-Reply-To: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.n ortel.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_216459632==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_216459632==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed The deployments that I am aware of use the legacy apps like FTP, Telnet and HTTP and they have not modified their apps to work with NAT-PT. If flow labels and MIPv6 and end-to-end security are important to them they would not be using NAT-PT. That is why we have an applicability statement suggesting where NAT-PT could be used. I am pretty sure any presented use cases can be shrugged off by saying not compelling enough and suggesting alternatives. As people pointed out proxies are not a viable solution in all cases. Thanks Senthil At 07:24 PM 10/11/2004 +0200, Elwyn Davies wrote: >That NAT-PT may stifle innovation is not an assumption but a >deduction. As is pointed out in the draft, NAT-PT cannot support all of >the current features of v6 (eg flow labels, MIPv6) and is unlikely to >support any new features. If the NAT-PT boxes operate autonomously >(without something like STUN, midcom or nsis to help), then all >applications may well have to decide to just use the subset of features >supported by NAT-PT. If they can detect that there is a NAT-PT box in the >way then special case code may be needed for destinations accessed through >the NAT-PT to limit the capabilities used. > >However if a proxy is used, all the special casing can be confined to the >proxy - the original application should be able to work untramelled (i.e. >as if working on a pure native v6 network when communicating with v6 >addresses - v4 functionality is unchanged). Hence I think the situation >as regards extra code is exactly the reverse of what you say: applications >operating with proxies can be unaware and unchanged; applications >operating through NAT-PT may need special case coding. > >The lack of compelling use cases for NAT-PT indicates that it isn't an >essential mechanism. Apart from a very limited set of cases dual-stack + >tunelling solves working across multiple realms. We need to get the >message out that NAT-PT is not a good thing and that there are other, >better solutions. That is the way to overcome resistance! > >Regards, >Elwyn > > > -----Original Message----- > > From: Pyda Srisuresh > [mailto:srisuresh@yahoo.com] > > Sent: 11 October 2004 14:58 > > To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH] > > Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric > > [ADC:7Q30:EXCH]; 'V6OPS' > > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > Folks, > > > > As Senthil points out, the assumption that NAT-PT deployment > > will stifle > > innovation in v6 seems flawed. NAT-PT is a transition > > mechanism which is > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > resistance to deploying V6 . You need NAT-PT for legacy > > applications (ex: > > e-mail, ftp) to work as is across V4 and V6 realms. No change > > to end-hosts or > > applications. This is the attraction of NAT-PT. This is not > > the same as the > > proxy solution that will require applications to be > > changed/recompiled. > > > > > > cheers, > > suresh > > > > > > --- Senthil Sivakumar wrote: > > > > > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote: > > > > > > >Three points: > > > >- The object of the draft was to summarize in one place > > all the problems > > > >with NAT-PT rather than being yet another delta on > > previous work. The > > > >introduction notes that several of the points are indeed > > generic address > > > >translation problems. This doesn't make them any less relevant. > > > > > > I am fine with summarizing the issues in one draft. But the > > draft points > > > out those as reasons to deprecate > > > which is what I am pointing out. > > > > > > >- The draft is specifically targeting the NAT-PT = SIIT + > > DNS-ALG solution > > > >intended for use as a generic inter-cloud translator. It > > is clear to me > > > >that a 'cut down' form has a use as a legacy v4 'server > > adaptor' front end > > > >where there is only one v4 address (or maybe a server > > cluster) on one > > > >side, it only has to handle a pre-defined set of > > protocols, and it doesn't > > > >need a DNS-ALG. I think this should be the subject of a > > separate draft. > > > > > > While I agree with you the cut-down solution does not need > > a DNS-ALG, I > > > don't think it has to handle a > > > specific set of protocols. I could still be a generic > > purpose translator > > > for facilitating transition. I am attaching > > > a document which was one of the use case scenario we are aware of. > > > > > > >- The fundamental point is whether v6ops should still be > > continuing to > > > >support a technology which will, if widely deployed, > > effectively stifle > > > >innovation in v6 networks. The need for applications to > > be aware that > > > >NAT-PT exists effectively condemns v6 to be just v4 with > > larger addresses > > > >at the application level. Is this what is wanted? Or > > should we really be > > > >trying to put the architectural flexibility back into the Internet? > > > > > > I am not understanding why you say applications have to > > aware of existence > > > of NAT-PT. > > > > > > > > > >It would be useful to see Shivkumar's use cases so that > > they could be > > > >considered for inclusion in the relevant transition > > analysis. If people > > > >are using NAT-PT in a particular way then we need to give > > them a workable > > > >alternative before ditching NAT-PT. > > > > > > Exactly. We should not prematurely deprecate the solution > > without an > > > alternative in place. > > > > > > Thnks > > > Senthil > > > > > > >Regards, > > > >Elwyn > > > > > > > > > -----Original Message----- > > > > > From: Sham Chakravorty > > > > > [<mailto:schakra@mitre.org>mailto:schakra@mitre.org] > > > > > Sent: 09 October 2004 18:35 > > > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar' > > > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn > > > > > [HAL02:0S00:EXCH] > > > > > Subject: RE: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > I agree with Shivkumar that deprecating NAT-PT really > > doesn't earn us > > > > > anything but removes one tool that could be used in specific > > > > > instances. > > > > > Application gateways are not in the same usage "level" as > > > > > NAT-PT - they > > > > > occur in different points of the network. Also, the > > > > > underlying algorithm of > > > > > SIIT would still be available. > > > > > > > > > > Sham > > > > > > > > > > -----Original Message----- > > > > > From: owner-v6ops@ops.ietf.org > > > > > > > > [<mailto:owner-v6ops@ops.ietf.org>mailto:owner-v6ops@ops.ietf.org] > On > > > > Behalf > > > > > Of Brian E Carpenter > > > > > Sent: Saturday, October 09, 2004 9:10 AM > > > > > To: Senthil Sivakumar > > > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies > > > > > Subject: Re: FW: I-D > > ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with no > > > > > workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the use > > > > > case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > But there is a workable alternative, which is an application > > > > > level proxy. > > > > > This too has its disadvantages, of course. > > > > > > > > > > Brian > > > > > > > > > > Senthil Sivakumar wrote: > > > > > > I see that the draft has consolidated all the > > previous drafts that > > > > > > highlighted the issues > > > > > > of NAT-PT and DNS ALG, which is a good thing. > > However, most of the > > > > > > issues mentioned > > > > > > here as NAT-PT issues are known issues with address > > > > > translation (NAT) > > > > > > itself, so > > > > > > attributing them to NAT-PT is not correct. Those should be > > > > > categorized > > > > > > as generic address > > > > > > translation issues. > > > > > > > > > > > > Some specfic comments on the following issues. > > > > > > > > > > > > * Disruption of all protocols which embed IP > > addresses (and/or > > > > > > ports) in packet payloads or which apply integrity > > > > > mechanisms > > > > > > using IP addresses (and ports). (not NAT-PT > > specific). > > > > > > > > > > > > * Requirement for applications to use keep alive > > > > > mechanisms to > > > > > > workaround connectivity issues caused by premature > > > > > NAT-PT state > > > > > > timeout. (not NAT-PT specific). > > > > > > > > > > > > * Inability to redirect packet fragments after the > > > > > first with > > > > > > NAPT-PT. (not NAT-PT specific). > > > > > > > > > > > > o Issues which are exacerbated by the use of a DNS-ALG: > > > > > > * Constraints on network topology. (not NAT-PT > > specific). > > > > > > * Scalability concerns together with introduction of > > > > > single point > > > > > > of failure and security attack nexus.(not > > NAT-PT specific). > > > > > > * Lack of address mapping persistence: Some > > > > > applications require > > > > > > address retention between sessions. The user > > > > > traffic will be > > > > > > disrupted if a different mapping is used. > > The use of the > > > > > > DNS-ALG to create address mappings with limited > > > > > lifetimes means > > > > > > that applications must start using the address > > > > > shortly after > > > > > > the mapping is created, as well as keeping it > > > > > alive once they > > > > > > start using it.(not NAT-PT specific). > > > > > > * Creation of a DOS threat relating to exhaustion of > > > > > memory and > > > > > > address/port pool resources on the > > translator.(not NAT-PT > > > > > > specific). > > > > > > > > > > > > Regarding the conclusion, I don't agree with the fact > > that only > > > > > > applicable scenario > > > > > > is in 3G networks. During the past couple of years of my > > > > > experience I > > > > > > have seen > > > > > > customers using it between isolated IPv6 networks to talk > > > > > to existing > > > > > > IPv4 networks. > > > > > > A lot of cases it is not about the nodes being dual stack > > > > > or not, it is > > > > > > the network > > > > > > that is not dual stacked for operational reasons. > > > > > > > > > > > > I have been gathering some inputs from the customers > > who are using > > > > > > NAT-PT currently > > > > > > regarding this draft. I can consolidate and forward the > > > > > comments if you > > > > > > are interested in > > > > > > knowing and understanding why they think they are moving > > > > > forward with > > > > > > NAT-PT. > > > > > > > > > > > > The point I am trying to stress is deprecating this would > > > > > leave us with > > > > > > no workable > > > > > > solution for communicating between IPv4 only > > > > > networks/nodes/apps IPv6 only > > > > > > networks/nodes/apps. As remote as it might seem for some, > > > > > that is the > > > > > > use case > > > > > > scenario we have encountered as the applicability of NAT-PT. > > > > > > > > > > > > Senthil > > > > > > > > > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote: > > > > > > > > > > > >> Hi, > > > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT > > > > > >> deprecation analysis. > > > > > >> We would really appreciate if you could provide us your > > > > > feedback on > > > > > >> the initial version of the deprecation analysis by Monday > > > > > October 4th. > > > > > >> Regards > > > > > >> Cedric Aoun > > > > > >> ------ Forwarded Message > > > > > >> From: > > > > > >> Reply-To: > > > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200 > > > > > >> To: > > > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> > > > > > >> A New Internet-Draft is available from the on-line > > Internet-Drafts > > > > > >> directories. > > > > > >> > > > > > >> > > > > > >> > > > > > >> Title : Reasons to Deprecate NAT-PT > > > > > >> Author(s) : C. Aoun, E. Davies > > > > > >> Filename : > > draft-aoun-v6ops-natpt-deprecate-00.txt > > > > > >> Pages : 24 > > > > > >> Date : 2004-9-21 > > > > > >> > > > > > >> This document discusses reasons why use of the > > specific form of > > > > > >> IPv6-IPv4 protocol translation mechanism implemented by > > > > > the Network > > > > > >> Address Translator - Protocol Translator (NAT-PT) > > > > > defined in RFC 2766 > > > > > >> should be deprecated and RFC2766 moved to historic status. > > > > > >> Description of an alternative protocol translation > > > > > mechanism is out > > > > > >> of scope for this document. > > > > > >> > > > > > >> A URL for this Internet-Draft is: > > > > > >> > > > > > > > > > > > > > > > <<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d > > > > e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > > > > > > > > > precate-00.txt > > > > > > > ><http://w > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d > > e>http://w > > > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de > > > > > precate-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>https://w > >ww1.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-aoun-v6ops-natpt-deprecate-00.txt". > > > > > >> > > > > > >> A list of Internet-Drafts directories can be found in > > > > > >> > > > > > > > > > > <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.h > > > tml>http://www.ietf.org/shadow.html > > > > > > > > > > > > >> or > > > > > >> > > > > > > > > > > > > > > > <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org > > > /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ > > > > > > > > > > >ietf/1shadow-s > > > >ites.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-aoun-v6ops-natpt-deprecate-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. > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> ------ End of Forwarded Message > > > > >> > > > > > > > > > > > > > > > > > > > > > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc; > > x-mac-type=42494E41; x-mac-creator=4D535744 > > > > > > > > ===== > > > > > > --=====================_216459632==_.ALT Content-Type: text/html; charset="us-ascii" The deployments that I am aware of use the legacy apps like FTP, Telnet and HTTP and
they have not modified their apps to work with NAT-PT. If flow labels and MIPv6 and
end-to-end security are important to them they would not be using NAT-PT.
That is why we have an applicability statement suggesting where NAT-PT could be used.
I am pretty sure any presented use cases can be shrugged off by saying not compelling enough
and suggesting alternatives. As people pointed out proxies are not a viable solution in all cases.

Thanks
Senthil

At 07:24 PM 10/11/2004 +0200, Elwyn Davies wrote:

That NAT-PT may stifle innovation is not an assumption but a deduction.  As is pointed out in the draft, NAT-PT cannot support all of the current features of v6 (eg flow labels, MIPv6) and is unlikely to support any new features.  If the NAT-PT boxes operate autonomously (without something like STUN, midcom or nsis to help), then all applications may well have to decide to just use the subset of features supported by NAT-PT.  If they can detect that there is a NAT-PT box in the way then special case code may be needed for destinations accessed through the NAT-PT to limit the capabilities used.

However if a proxy is used, all the special casing can be confined to the proxy - the original application should be able to work untramelled (i.e. as if working on a pure native v6 network when communicating with v6 addresses - v4 functionality is unchanged).  Hence I think the situation as regards extra code is exactly the reverse of what you say: applications operating with proxies can be unaware and unchanged; applications operating through NAT-PT may need special case coding.

The lack of compelling use cases for NAT-PT indicates that it isn't an essential mechanism. Apart from a very limited set of cases dual-stack + tunelling solves working across multiple realms.  We need to get the message out that NAT-PT is not a good thing and that there are other, better solutions.  That is the way to overcome resistance!

Regards,
Elwyn

> -----Original Message-----
> From: Pyda Srisuresh [mailto:srisuresh@yahoo.com]
> Sent: 11 October 2004 14:58
> To: Senthil Sivakumar; Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: 'Sham Chakravorty'; 'Brian E Carpenter'; Aoun, Cedric
> [ADC:7Q30:EXCH]; 'V6OPS'
> Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
>
>
> Folks,
>
> As Senthil points out, the assumption that NAT-PT deployment
> will stifle
> innovation in v6 seems flawed. NAT-PT is a transition
> mechanism which is
> essential for wider V6 deployment. Without NAT-PT, you will see bigger
> resistance to deploying V6 . You need NAT-PT for legacy
> applications (ex:
> e-mail, ftp) to work as is across V4 and V6 realms. No change
> to end-hosts or
> applications. This is the attraction of NAT-PT. This is not
> the same as the
> proxy solution that will require applications to be
> changed/recompiled.
>
>
> cheers,
> suresh
>
>
> --- Senthil Sivakumar <ssenthil@cisco.com> wrote:
>
> > At 10:16 AM 10/10/2004 +0200, Elwyn Davies wrote:
> >
> > >Three points:
> > >- The object of the draft was to summarize in one place
> all the problems
> > >with NAT-PT rather than being yet another delta on
> previous work.  The
> > >introduction notes that several of the points are indeed
> generic address
> > >translation problems.  This doesn't make them any less relevant.
> >
> > I am fine with summarizing the issues in one draft. But the
> draft points
> > out those as reasons to deprecate
> > which is what I am pointing out.
> >
> > >- The draft is specifically targeting the NAT-PT = SIIT +
> DNS-ALG solution
> > >intended for use as a generic inter-cloud translator.  It
> is clear to me
> > >that a 'cut down' form has a use as a legacy v4 'server
> adaptor' front end
> > >where there is only one v4 address (or maybe a server
> cluster) on one
> > >side, it only has to handle a pre-defined set of
> protocols, and it doesn't
> > >need a DNS-ALG.  I think this should be the subject of a
> separate draft.
> >
> > While I agree with you the cut-down solution does not need
> a DNS-ALG, I
> > don't think it has to handle a
> > specific set of protocols. I could still be a generic
> purpose translator
> > for facilitating transition. I am attaching
> > a document which was one of the use case scenario we are aware of.
> >
> > >- The fundamental point is whether v6ops should still be
> continuing to
> > >support a technology which will, if widely deployed,
> effectively stifle
> > >innovation in v6 networks.  The need for applications to
> be aware that
> > >NAT-PT exists effectively condemns v6 to be just v4 with
> larger addresses
> > >at the application level. Is this what is wanted? Or
> should we really be
> > >trying to put the architectural flexibility back into the Internet?
> >
> > I am not understanding why you say applications have to
> aware of existence
> > of NAT-PT.
> >
> >
> > >It would be useful to see Shivkumar's use cases so that
> they could be
> > >considered for inclusion in the relevant transition
> analysis.  If people
> > >are using NAT-PT in a particular way then we need to give
> them a workable
> > >alternative before ditching NAT-PT.
> >
> > Exactly. We should not prematurely deprecate the solution
> without an
> > alternative in place.
> >
> > Thnks
> > Senthil
> >
> > >Regards,
> > >Elwyn
> > >
> > > > -----Original Message-----
> > > > From: Sham Chakravorty
> > > [<mailto:schakra@mitre.org>mailto:schakra@mitre.org]
> > > > Sent: 09 October 2004 18:35
> > > > To: 'Brian E Carpenter'; 'Senthil Sivakumar'
> > > > Cc: Aoun, Cedric [ADC:7Q30:EXCH]; 'V6OPS'; Davies, Elwyn
> > > > [HAL02:0S00:EXCH]
> > > > Subject: RE: FW: I-D
> ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > I agree with Shivkumar that deprecating NAT-PT really
> doesn't earn us
> > > > anything but removes one tool that could be used in specific
> > > > instances.
> > > > Application gateways are not in the same usage "level" as
> > > > NAT-PT - they
> > > > occur in different points of the network. Also, the
> > > > underlying algorithm of
> > > > SIIT would still be available.
> > > >
> > > > Sham
> > > >
> > > > -----Original Message-----
> > > > From: owner-v6ops@ops.ietf.org
> > > >
> [<mailto:owner-v6ops@ops.ietf.org>mailto:owner-v6ops@ops.ietf.org] On
> > > Behalf
> > > > Of Brian E Carpenter
> > > > Sent: Saturday, October 09, 2004 9:10 AM
> > > > To: Senthil Sivakumar
> > > > Cc: Cedric Aoun; V6OPS; Elwyn Davies
> > > > Subject: Re: FW: I-D
> ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > >
> > > >
> > > > > The point I am trying to stress is deprecating this would
> > > > leave us with no
> > > > workable
> > > > > solution for communicating between IPv4 only
> > > > networks/nodes/apps IPv6 only
> > > > > networks/nodes/apps. As remote as it might seem for some,
> > > > that is the use
> > > > case
> > > > > scenario we have encountered as the applicability of NAT-PT.
> > > >
> > > > But there is a workable alternative, which is an application
> > > > level proxy.
> > > > This too has its disadvantages, of course.
> > > >
> > > >      Brian
> > > >
> > > > Senthil Sivakumar wrote:
> > > > > I see that the draft has consolidated all the
> previous drafts that
> > > > > highlighted the issues
> > > > > of NAT-PT and DNS ALG, which is a good thing.
> However, most of the
> > > > > issues mentioned
> > > > > here as NAT-PT issues are known issues with address
> > > > translation (NAT)
> > > > > itself, so
> > > > > attributing them to NAT-PT is not correct.  Those should be
> > > > categorized
> > > > > as generic address
> > > > > translation issues.
> > > > >
> > > > > Some specfic comments on the following issues.
> > > > >
> > > > >      *  Disruption of all protocols which embed IP
> addresses (and/or
> > > > >          ports) in packet payloads or which apply integrity
> > > > mechanisms
> > > > >          using IP addresses (and ports). (not NAT-PT
> specific).
> > > > >
> > > > >       *  Requirement for applications to use keep alive
> > > > mechanisms to
> > > > >          workaround connectivity issues caused by premature
> > > > NAT-PT state
> > > > >          timeout. (not NAT-PT specific).
> > > > >
> > > > >        *  Inability to redirect packet fragments after the
> > > > first with
> > > > >          NAPT-PT. (not NAT-PT specific).
> > > > >
> > > > >    o  Issues which are exacerbated by the use of a DNS-ALG:
> > > > >       *  Constraints on network topology. (not NAT-PT
> specific).
> > > > >       *  Scalability concerns together with introduction of
> > > > single point
> > > > >          of failure and security attack nexus.(not
> NAT-PT specific).
> > > > >       *  Lack of address mapping persistence: Some
> > > > applications require
> > > > >          address retention between sessions.  The user
> > > > traffic will be
> > > > >          disrupted if a different mapping is used. 
> The use of the
> > > > >          DNS-ALG to create address mappings with limited
> > > > lifetimes means
> > > > >          that applications must start using the address
> > > > shortly after
> > > > >          the mapping is created, as well as keeping it
> > > > alive once they
> > > > >          start using it.(not NAT-PT specific).
> > > > >       *  Creation of a DOS threat relating to exhaustion of
> > > > memory and
> > > > >          address/port pool resources on the
> translator.(not NAT-PT
> > > > > specific).
> > > > >
> > > > > Regarding the conclusion, I don't agree with the fact
> that only
> > > > > applicable scenario
> > > > > is in 3G networks. During the past couple of years of my
> > > > experience I
> > > > > have seen
> > > > > customers using it between isolated IPv6 networks to talk
> > > > to existing
> > > > > IPv4 networks.
> > > > > A lot of cases it is not about the nodes being dual stack
> > > > or not, it is
> > > > > the network
> > > > > that is not dual stacked for operational reasons.
> > > > >
> > > > > I have been gathering some inputs from the customers
> who are using
> > > > > NAT-PT currently
> > > > > regarding this draft. I can consolidate and forward the
> > > > comments if you
> > > > > are interested in
> > > > > knowing and understanding why they think they are moving
> > > > forward with
> > > > > NAT-PT.
> > > > >
> > > > > The point I am trying to stress is deprecating this would
> > > > leave us with
> > > > > no workable
> > > > > solution for communicating between IPv4 only
> > > > networks/nodes/apps IPv6 only
> > > > > networks/nodes/apps. As remote as it might seem for some,
> > > > that is the
> > > > > use case
> > > > > scenario we have encountered as the applicability of NAT-PT.
> > > > >
> > > > > Senthil
> > > > >
> > > > > At 10:12 AM 9/22/2004 +0200, Cedric Aoun wrote:
> > > > >
> > > > >> Hi,
> > > > >> As discussed at IETF 60, the WG agreed to continue the NAT-PT
> > > > >> deprecation analysis.
> > > > >> We would really appreciate if you could provide us your
> > > > feedback on
> > > > >> the initial version of the deprecation analysis by Monday
> > > > October 4th.
> > > > >> Regards
> > > > >> Cedric Aoun
> > > > >> ------ Forwarded Message
> > > > >> From: <Internet-Drafts@ietf.org>
> > > > >> Reply-To: <internet-drafts@ietf.org>
> > > > >> Date: Tue, 21 Sep 2004 21:38:33 +0200
> > > > >> To: <i-d-announce@ietf.org>
> > > > >> Subject: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > >>
> > > > >> A New Internet-Draft is available from the on-line
> Internet-Drafts
> > > > >> directories.
> > > > >>
> > > > >>
> > > > >>
> > > > >>         Title           : Reasons to Deprecate NAT-PT
> > > > >>         Author(s)       : C. Aoun, E. Davies
> > > > >>         Filename        :
> draft-aoun-v6ops-natpt-deprecate-00.txt
> > > > >>         Pages           : 24
> > > > >>         Date            : 2004-9-21
> > > > >>
> > > > >> This document discusses reasons why use of the
> specific form of
> > > > >>    IPv6-IPv4 protocol translation mechanism implemented by
> > > > the Network
> > > > >>    Address Translator - Protocol Translator (NAT-PT)
> > > > defined in RFC 2766
> > > > >>    should be deprecated and RFC2766 moved to historic status.
> > > > >>    Description of an alternative protocol translation
> > > > mechanism is out
> > > > >>    of scope for this document.
> > > > >>
> > > > >> A URL for this Internet-Draft is:
> > > > >>
> > > >
> > >
> >
> <<http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d
> e>http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> >
> > >
> > > > precate-00.txt
> > > >
> ><http://www.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-d
> e>http://w
> > > ww.ietf.org/internet-drafts/draft-aoun-v6ops-natpt-de
> > > > precate-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>https://w
ww1.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-aoun-v6ops-natpt-deprecate-00.txt".
> > > > >>
> > > > >> A list of Internet-Drafts directories can be found in
> > > > >>
> > >
> >
> <<http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.h
> tml>http://www.ietf.org/shadow.html
> >
> > >
> > > > >> or
> > > > >>
> > > >
> > >
> >
> <<ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org
> /ietf/1shadow-sites.txt>ftp://ftp.ietf.org/
> >
> > >
> > >ietf/1shadow-s
> > >ites.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-aoun-v6ops-natpt-deprecate-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.
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> ------ End of Forwarded Message
> > > >>
> > > >
> > >
> > >
> >
>
> > ATTACHMENT part 2 application/msword name=nat-pt-scenario.doc;
> x-mac-type=42494E41; x-mac-creator=4D535744
>
>
>
> =====
>
>
>
--=====================_216459632==_.ALT-- From owner-v6ops@ops.ietf.org Thu Oct 14 04:03:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17266 for ; Thu, 14 Oct 2004 04:03:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI0Xi-000AOr-83 for v6ops-data@psg.com; Thu, 14 Oct 2004 08:00:58 +0000 Received: from [195.212.29.151] (helo=mtagate2.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI0Xh-000AOQ-4M for v6ops@ops.ietf.org; Thu, 14 Oct 2004 08:00:57 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate2.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9E80sFW144040 for ; Thu, 14 Oct 2004 08:00:54 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9E80r8d112936 for ; Thu, 14 Oct 2004 10:00:54 +0200 Received: from zurich.ibm.com (sig-9-145-229-220.de.ibm.com [9.145.229.220]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA110386 for ; Thu, 14 Oct 2004 10:00:53 +0200 Message-ID: <416E3232.6090701@zurich.ibm.com> Date: Thu, 14 Oct 2004 10:00:50 +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: IPv6 Operations Subject: IPv6 Network Architecture Protection draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, The authors would be interested in comments on the draft below. Brian > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : IPv6 Network Architecture Protection > Author(s) : G. Van de Velde, et al. > Filename : draft-vandevelde-v6ops-nap-00.txt > Pages : 25 > Date : 2004-10-12 > > Although there are many perceived benefits to Network Address > Translation (NAT), the primary benefit of "amplifying" available > address space is not needed in IPv6. In addition to its many serious > disadvantages there is a perception that other benefits exist, such > as a variety of management and security reasons that could be useful > for an Internet Protocol. IPv6 does not support NAT by design and > this document shows how Network Architecture Protection (NAP) using > IPv6 can provide the benefits without the need for NAT. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-vandevelde-v6ops-nap-00.txt From owner-v6ops@ops.ietf.org Thu Oct 14 09:01:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11088 for ; Thu, 14 Oct 2004 09:01:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI5Bf-000Gg2-R9 for v6ops-data@psg.com; Thu, 14 Oct 2004 12:58:31 +0000 Received: from [195.212.29.134] (helo=mtagate1.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI5Be-000Gfe-5f for v6ops@ops.ietf.org; Thu, 14 Oct 2004 12:58:30 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate1.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9ECvlDq028896; Thu, 14 Oct 2004 12:57:56 GMT Received: from mail-gw2.hursley.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9ECvkoe143798; Thu, 14 Oct 2004 13:57:46 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CI5Aw-0004D3-00; Thu, 14 Oct 2004 13:57:46 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CI5Aw-0004Cy-00; Thu, 14 Oct 2004 13:57:46 +0100 Received: from zurich.ibm.com (sig-9-146-231-179.de.ibm.com [9.146.231.179]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i9ECvja475420; Thu, 14 Oct 2004 13:57:46 +0100 Message-ID: <416E77C5.10804@zurich.ibm.com> Date: Thu, 14 Oct 2004 14:57:41 +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: "Bound, Jim" CC: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A461@tayexc13.americas.cpqcorp.net> In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0784A461@tayexc13.americas.cpqcorp.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 8bit Jim, Thanks for your reply. Further comments where I think I need to clarify (points where there is no more to say deleted): Bound, Jim wrote: ... > >>1) My first concern is that somehow it misses the most >>important case and the way I would recommend any enterprise to go. >> >>In the terminology of the document that case is >> >> >> ====================================================== >> |Application |Host 1 |Service |Host 2 |Application | >> |----------- |Network|Provider|Network|---------- | >> | Host 1 OS | | | | Host 2 OS | >> =====================================+================ >> |Dual or IPv4| | |Dual IP|Dual IPv4| >> 0 | ---- |Dual IP|Dual IP | or |---- or ----| >> | Dual | | |v4 only|Dual IPv4| >> ====================================================== >> >>In other words, why would an enterprise choose to paint >>itself into any of the awkward corners of the other 13 scenarios? > > > Sorry I cannot respond to such a general statement ok. Let me rephrase my concern. Somebody reading this draft without the background knowledge of this WG will simply not realise that the fundamental coexistence model is dual stack. They will find themselves right in the discussion of the 13 scenarios and think that they must pick one of them - but the first question anyone should ask is "can I just do a straightforward dual stack model?" I would argue that for the large majority of enterprise customers the answer will be yes, except for the corner cases where they will have to do something special. So I think the draft needs to start out by saying this - either by inserting my Scenario 0 or by saying it in words. I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt, which starts out with base scenario 1, widespread dual stack. > Will continue to respond. All these cases are real cases Not denying that they will all exist somewhere. > and you or I or the IETF cannot second guess or mandate any transition to the enterprise. No, but we can advise our customers on the simplest, cheapest solution. > > >>Just go for a dual stack operating system and routing system, >>and keep calling your software suppliers until they upgrade >>to the new API. Why make it harder than it needs to be?\ > > > This ia really naïve view Yes. I think most enterprises would prefer it that way. > ...it don't work that way at all and your assumption is one as casual > and many are looking at ways to reduce cost and thus the 13 scenarios. It's not only that. Enterprises are not going to voluntarily add IPv6 support if they perceive it as adding great operational complexity, which is an ongoing cost. They will simply wait until it becomes simple. > > >>In fact, sections 4 and 7 are written in this spirit - they >>refer essentially to what I have shown above as secnario 0. > > > Not really reread the vlan discussion. As far as I can see, that only splits the routing. As far as hosts, DNS and middleware is concerned it's still a dual stack model. > > >>I just don't get what are the drivers for the other >>13 scenarios. > > > I can tell but they are all in ent scenarios doc. True, I think my problem here is what I have said at the beginning of this message. ... > >>3) My third main concern is that the draft doesn't discuss >>the deployment of DMZs, which are a feature of all major >>enterprise networks. > > > Nor should we and we do not intend to. Well, I think then that we have to add it to draft-vandevelde-v6ops-nap-00.txt, because it is one of the first things enterprise network security managers will ask about. ... >> > It is not recommended to use 6to4 [6TO4] or a tunnel >>broker [TBRK] > for an enterprise deployment. The >>enterprise has a requirement for > long-term, stable IPv6 >>connectivity. 6to4 and the tunnel broker > are more >>appropriate for SOHO or single node environments. >> >>Sorry, but that's wrong. First of all, single-node 6to4 isn't >>an IETF solution - it has never been documented - so it's not >>accurate to cite the RFC. Secondly, 6to4 as described in RFC >>3056 will work just fine for an enterprise - until the day >>its own ISP provides native connectivity, of course. I'd say >>a SOHO user has less chance of setting up RFC 3056 correctly >>than a large enterprise. > > > Uh OH but good there will be strong disagreement. I am just editor. > > I see both views. Both are required. As a matter of fact I agree with the recommendation; I just want to avoid mischaracterization of 6to4. Of course, if you simply can't find an ISP to support you properly, a tunnel broker or 6to4 would always be possible. That's it for now. Brian From owner-v6ops@ops.ietf.org Thu Oct 14 09:02:50 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11245 for ; Thu, 14 Oct 2004 09:02:49 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI5FX-000HCx-Tp for v6ops-data@psg.com; Thu, 14 Oct 2004 13:02:31 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI5FT-000HCD-Iw for v6ops@ops.ietf.org; Thu, 14 Oct 2004 13:02:28 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9ED2MQi449124; Thu, 14 Oct 2004 13:02:22 GMT Received: from mail-gw2.hursley.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9ED2LSr150426; Thu, 14 Oct 2004 14:02:21 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CI5FN-0004LK-00; Thu, 14 Oct 2004 14:02:21 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CI5FN-0004LD-00; Thu, 14 Oct 2004 14:02:21 +0100 Received: from zurich.ibm.com (sig-9-146-231-179.de.ibm.com [9.146.231.179]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i9ED2La555886; Thu, 14 Oct 2004 14:02:21 +0100 Message-ID: <416E78D9.7070909@zurich.ibm.com> Date: Thu, 14 Oct 2004 15:02:17 +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: "Klynsma, Steven L Mr CIO/G6/MITRE" CC: "'Bound, Jim'" , v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Steve, Yes, I am fully aware of Network Centric Operations requirements. Somehow I don't think of the DoD as an "enterprise" and my comments are all in the context of my understanding of enterprises. Obviously, a solution is needed in the scenario you describe, but I'd like to think of it as separable. Brian Klynsma, Steven L Mr CIO/G6/MITRE wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Brian, > > I work for the military and would dearly love to go to a dual-stack everywhere, but as Jim mentioned, that's simply not feasible. Unlike commercial users, we typically must develop our own unique comms networks that support unique military requirements (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS "pipes"), unpredictable, but inevitable and often lengthy, disconnects from network services, and a need for both host and routing infrastructure to be mobile). In such an environment, operating two routing protocols, as you must with dual-stack becomes quite problematic. In addition, because of the lengthy life cycles of weapon systems (15-20 years), you find yourself working with processors that are overloaded already. Throw a dual-stack requirement on this tactical environment and you break the camels back. > > So we are typically looking at replacing the entire tactical comms infrastructure. Given the other constraints on bandwidth, mobility, etc., it becomes very attractive to make the leap from IPv4 directly to IPv6 without a lengthy dual-stack transition period. However, that essentially creates an IPv6-only ISP supporting our weapon systems on the battlefield. Of course, this, in turn, comes with another set of problems, primarily for interoperablity with IPv4-based current systems and allies, but we hope by aggressively migrating the force to IPv6-dominance that these additional problems become manageable. > > Vr, > > Steve From owner-v6ops@ops.ietf.org Thu Oct 14 09:37:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15841 for ; Thu, 14 Oct 2004 09:37:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI5n8-000Kuy-4v for v6ops-data@psg.com; Thu, 14 Oct 2004 13:37:14 +0000 Received: from [141.116.59.230] (helo=dadc014.hqda.pentagon.mil) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI5n4-000KuV-24 for v6ops@ops.ietf.org; Thu, 14 Oct 2004 13:37:10 +0000 Received: by dadc014.hqda.pentagon.mil with Internet Mail Service (5.5.2657.72) id <4HB4JFK5>; Thu, 14 Oct 2004 09:36:10 -0400 Message-ID: From: "Klynsma, Steven L Mr CIO/G6/MITRE" To: "'Brian E Carpenter'" Cc: "'Bound, Jim'" , v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) (UNCLASSIFIED) Date: Thu, 14 Oct 2004 09:36:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4B1F2.CA2DFCF0" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C4B1F2.CA2DFCF0 Content-Type: text/plain Classification: UNCLASSIFIED Caveats: NONE Brian, I'm sure you're aware that the military has much to gain by taking on a "commercial" flavor. By that I mean reducing our dependence on government-developed equipment and using the stuff already available in commercial sector. Therefore, we take great pains to use commercial terminology (as opposed to military) and would hope that a separate solution for our environment can be avoided. Steve -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com] Sent: Thursday, October 14, 2004 9:02 AM To: Klynsma, Steven L Mr CIO/G6/MITRE Cc: 'Bound, Jim'; v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) Steve, Yes, I am fully aware of Network Centric Operations requirements. Somehow I don't think of the DoD as an "enterprise" and my comments are all in the context of my understanding of enterprises. Obviously, a solution is needed in the scenario you describe, but I'd like to think of it as separable. Brian Klynsma, Steven L Mr CIO/G6/MITRE wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Brian, > > I work for the military and would dearly love to go to a dual-stack everywhere, but as Jim mentioned, that's simply not feasible. Unlike commercial users, we typically must develop our own unique comms networks that support unique military requirements (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS "pipes"), unpredictable, but inevitable and often lengthy, disconnects from network services, and a need for both host and routing infrastructure to be mobile). In such an environment, operating two routing protocols, as you must with dual-stack becomes quite problematic. In addition, because of the lengthy life cycles of weapon systems (15-20 years), you find yourself working with processors that are overloaded already. Throw a dual-stack requirement on this tactical environment and you break the camels back. > > So we are typically looking at replacing the entire tactical comms infrastructure. Given the other constraints on bandwidth, mobility, etc., it becomes very attractive to make the leap from IPv4 directly to IPv6 without a lengthy dual-stack transition period. However, that essentially creates an IPv6-only ISP supporting our weapon systems on the battlefield. Of course, this, in turn, comes with another set of problems, primarily for interoperablity with IPv4-based current systems and allies, but we hope by aggressively migrating the force to IPv6-dominance that these additional problems become manageable. > > Vr, > > Steve Classification: UNCLASSIFIED Caveats: NONE ------_=_NextPart_001_01C4B1F2.CA2DFCF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt = (UNCLASSI FIED) (UNCLASSIFIED)

Classification:  = UNCLASSIFIED
Caveats: NONE

Brian,

I'm sure you're aware that the military has much to = gain by taking on a "commercial" flavor.  By that I mean = reducing our dependence on government-developed equipment and using the = stuff already available in commercial sector.  Therefore, we take = great pains to use commercial terminology (as opposed to military) and = would hope that a separate solution for our environment can be = avoided.

Steve

-----Original Message-----
From: Brian E Carpenter [mailto:brc@zurich.ibm.com] =
Sent: Thursday, October 14, 2004 9:02 AM
To: Klynsma, Steven L Mr CIO/G6/MITRE
Cc: 'Bound, Jim'; v6ops@ops.ietf.org
Subject: Re: REVIEW NEEDED: = draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED)

Steve,

Yes, I am fully aware of Network Centric Operations = requirements.
Somehow I don't think of the DoD as an = "enterprise" and my comments are all in the context of my = understanding of enterprises.

Obviously, a solution is needed in the scenario you = describe, but I'd like to think of it as separable.

    Brian


Klynsma, Steven L Mr CIO/G6/MITRE wrote:
> Classification:  UNCLASSIFIED
> Caveats: NONE
>
> Brian,
>
> I work for the military and would dearly love = to go to a dual-stack everywhere, but as Jim mentioned, that's simply = not feasible.  Unlike commercial users, we typically must develop = our own unique comms networks that support unique military requirements = (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS = "pipes"), unpredictable, but inevitable and often lengthy, = disconnects from network services, and a need for both host and routing = infrastructure to be mobile).  In such an environment, operating = two routing protocols, as you must with dual-stack becomes quite = problematic.  In addition, because of the lengthy life cycles of = weapon systems (15-20 years), you find yourself working with processors = that are overloaded already.  Throw a dual-stack requirement on = this tactical environment and you break the camels back.  =

>
> So we are typically looking at replacing the = entire tactical comms infrastructure.  Given the other constraints = on bandwidth, mobility, etc., it becomes very attractive to make the = leap from IPv4 directly to IPv6 without a lengthy dual-stack transition = period.  However, that essentially creates an IPv6-only ISP = supporting our weapon systems on the battlefield.  Of course, = this, in turn, comes with another set of problems, primarily for = interoperablity with IPv4-based current systems and allies, but we hope = by aggressively migrating the force to IPv6-dominance that these = additional problems become manageable.

>
> Vr,
>
> Steve


<snip>
Classification:  = UNCLASSIFIED
Caveats: NONE

------_=_NextPart_001_01C4B1F2.CA2DFCF0-- From owner-v6ops@ops.ietf.org Thu Oct 14 10:36:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24780 for ; Thu, 14 Oct 2004 10:36:45 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI6gv-00036P-K3 for v6ops-data@psg.com; Thu, 14 Oct 2004 14:34:53 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI6gj-00033N-8b for v6ops@ops.ietf.org; Thu, 14 Oct 2004 14:34:41 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 95A7224; Thu, 14 Oct 2004 10:34:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 10:34:40 -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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Date: Thu, 14 Oct 2004 10:34:40 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A8A3@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Thread-Index: AcSx7YLsUDVUgirxSm2elchd0KgNXAADEY8A From: "Bound, Jim" To: "Brian E Carpenter" Cc: X-OriginalArrivalTime: 14 Oct 2004 14:34:40.0443 (UTC) FILETIME=[F04858B0:01C4B1FA] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian,=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Thursday, October 14, 2004 8:58 AM > To: Bound, Jim > Cc: v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt >=20 > Jim, >=20 > Thanks for your reply. Further comments where I think I need=20 > to clarify (points where there is no more to say deleted): >=20 > Bound, Jim wrote: > ... > >=20 > >>1) My first concern is that somehow it misses the most=20 > important case=20 > >>and the way I would recommend any enterprise to go. > >> > >>In the terminology of the document that case is > >> > >> > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> |Application |Host 1 |Service |Host 2 |Application | > >> |----------- |Network|Provider|Network|---------- | > >> | Host 1 OS | | | | Host 2 OS | > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> |Dual or IPv4| | |Dual IP|Dual IPv4| > >> 0 | ---- |Dual IP|Dual IP | or |---- or ----| > >> | Dual | | |v4 only|Dual IPv4| > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > >> > >>In other words, why would an enterprise choose to paint itself into=20 > >>any of the awkward corners of the other 13 scenarios? > >=20 > >=20 > > Sorry I cannot respond to such a general statement ok. =20 >=20 > Let me rephrase my concern. Somebody reading this draft=20 > without the background knowledge of this WG will simply not=20 > realise that the fundamental coexistence model is dual stack.=20 > They will find themselves right in the discussion of the 13=20 > scenarios and think that they must pick one of them - but the=20 > first question anyone should ask is "can I just do a=20 > straightforward dual stack model?" I would argue that for the=20 > large majority of enterprise customers the answer will be=20 > yes, except for the corner cases where they will have to do=20 > something special. So I think the draft needs to start out by=20 > saying this - either by inserting my Scenario 0 or by saying=20 > it in words. What we can do is add discussion of dual stack up front and I can write = that for sure. I agree with your concern. What I don't agree with is your belief of corner cases. I am seeing = these cases in the following DOD, FAA, Homeland Securitiy, Satcom IXs, = Providers, CEA-to-Provider evolution, and 3G. But it is not the = business of the IETF to begin to define markets or trends we just come = here and support what we believe are requirements. We can provide = balance here for the norm and the more aggressive early adopters moving = to dominant IPv6. >=20 > I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt, > which starts out with base scenario 1, widespread dual stack. Understand. >=20 > > Will continue to respond. All these cases are real cases >=20 > Not denying that they will all exist somewhere. Good. >=20 >=20 > > and you or I or the IETF cannot second guess or mandate any=20 > transition to the enterprise. >=20 > No, but we can advise our customers on the simplest, cheapest=20 > solution. I am different I "listen" to my customers business case and then give = them input. I see completely the need for dominant IPv6 view. >=20 > >=20 > >=20 > >>Just go for a dual stack operating system and routing=20 > system, and keep=20 > >>calling your software suppliers until they upgrade to the=20 > new API. Why=20 > >>make it harder than it needs to be?\ > >=20 > >=20 > > This ia really na=EFve view >=20 > Yes. I think most enterprises would prefer it that way. Those who don't are as important as those who do prefer different. >=20 > > ...it don't work that way at all and your assumption is one=20 > as casual > > and many are looking at ways to reduce cost and thus the=20 > 13 scenarios. >=20 > It's not only that. Enterprises are not going to voluntarily=20 > add IPv6 support if they perceive it as adding great=20 > operational complexity, which is an ongoing cost. They will=20 > simply wait until it becomes simple. We simply do not agree. >=20 > >=20 > >=20 > >>In fact, sections 4 and 7 are written in this spirit - they refer=20 > >>essentially to what I have shown above as secnario 0. > >=20 > >=20 > > Not really reread the vlan discussion. >=20 > As far as I can see, that only splits the routing. As far as=20 > hosts, DNS and middleware is concerned it's still a dual stack model. For the apps I agree. I think you and a very few are trying to KILL the = IPv6 Dominant model and we as authors are standing on our position. I = am willing to make it clear why the different models exist but not kill = the IPv6 dominant scenarios if my co-authors agree. >=20 > >=20 > >=20 > >>I just don't get what are the drivers for the other > >>13 scenarios.=20 > >=20 > >=20 > > I can tell but they are all in ent scenarios doc. >=20 > True, I think my problem here is what I have said at the=20 > beginning of this message. Yes and I think we can fix that and from that view your 100% correct. >=20 > ... > >=20 > >>3) My third main concern is that the draft doesn't discuss the=20 > >>deployment of DMZs, which are a feature of all major enterprise=20 > >>networks. > >=20 > >=20 > > Nor should we and we do not intend to. >=20 > Well, I think then that we have to add it to=20 > draft-vandevelde-v6ops-nap-00.txt, because it is one of the=20 > first things enterprise network security managers will ask about. Good I just saw that and what we can do is reference that work ok? >=20 > ... > >> > It is not recommended to use 6to4 [6TO4] or a tunnel > >>broker [TBRK] > for an enterprise deployment. The=20 > enterprise has a=20 > >>requirement for > long-term, stable IPv6 connectivity. =20 > 6to4 and the=20 > >>tunnel broker > are more appropriate for SOHO or single node=20 > >>environments. > >> > >>Sorry, but that's wrong. First of all, single-node 6to4=20 > isn't an IETF=20 > >>solution - it has never been documented - so it's not=20 > accurate to cite=20 > >>the RFC. Secondly, 6to4 as described in RFC > >>3056 will work just fine for an enterprise - until the day=20 > its own ISP=20 > >>provides native connectivity, of course. I'd say a SOHO=20 > user has less=20 > >>chance of setting up RFC 3056 correctly than a large enterprise. > >=20 > >=20 > > Uh OH but good there will be strong disagreement. I am just editor. > >=20 > > I see both views. Both are required. >=20 > As a matter of fact I agree with the recommendation; I just=20 > want to avoid mischaracterization of 6to4. Of course, if you=20 > simply can't find an ISP to support you properly, a tunnel broker or > 6to4 would always be possible. Again completely agree. >=20 > That's it for now. >=20 > Brian Good input and directtion. Thanks /jim >=20 From owner-v6ops@ops.ietf.org Thu Oct 14 10:48:52 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26316 for ; Thu, 14 Oct 2004 10:48:52 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI6tl-00057i-D6 for v6ops-data@psg.com; Thu, 14 Oct 2004 14:48:09 +0000 Received: from [161.114.64.103] (helo=zmamail03.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI6tk-00057T-4l for v6ops@ops.ietf.org; Thu, 14 Oct 2004 14:48:08 +0000 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id A501D2B; Thu, 14 Oct 2004 10:48:07 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Thu, 14 Oct 2004 10:48:07 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) Date: Thu, 14 Oct 2004 10:48:06 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784A8AF@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) Thread-Index: AcSx7hM3XVIKjRUsQQCnikrEuE3QcwADQitw From: "Bound, Jim" To: "Brian E Carpenter" , "Klynsma, Steven L Mr CIO/G6/MITRE" Cc: X-OriginalArrivalTime: 14 Oct 2004 14:48:07.0479 (UTC) FILETIME=[D1504470:01C4B1FC] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Brian, I run into what your saying all the time, usually can clear it up with the mail I am sending you. Its not just DOD for NCO and I speak as SME on NCO here for the network plumbing part of that model/architecture/view not the SOA part to make that clear. NCO and such enterprises are not just appearing in the DOD but also for HLS (all first responders, EMS, Fireman, Police) etc the model helps a focus and infrastructure that permits discovery, connectivity, interoperability, and E2E security. All our work in IETF is the plumbing and some APIs we do not do here. Also FAA/Euro-Control type operations worldwide require it and will push IPv6 native / dominant network deployment. The key to understand is the operational benefits of IPv6 override the business case in these environments as lives are at stake within mission critical scenarios. I don't want to have discussion here in IETF why some may not believe IPv6 is that powerful and better than IPv4 that is not the purpose of the IETF so I will not play in that debate. I state it so you know where these users/target markets are coming from ok. Another point is I have seen the above network topologies and they are the same as Enterprise at GM, JC Penney, Burger King, Home Depot, large Bank, or Manufacturing plant. DOD et al are an enterprise as anyother Enterprise and DOD may in fact be the largest Internet network in the world. Another point is for you and I as vendors. The above scenarios do not require custom products at all what we build for them is the same as what we will build for private/commerical market and so the products are for a horizontal market from technology infrastructure perspective. The final point is that I agree we need to make it clear dual stack is what is being done here. Also to execute and implement dominant IPv6 networks is just a use and view of dual stack that permits faster evolution to dominant IPv6 networks and that we can fix in the draft too and explain it better. Whether this can all be done by the Oct 25th deadline is debateable as we got all this great input and discussion rather late in the game. Thanks /jim > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Thursday, October 14, 2004 9:02 AM > To: Klynsma, Steven L Mr CIO/G6/MITRE > Cc: Bound, Jim; v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED:=20 > draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) >=20 > Steve, >=20 > Yes, I am fully aware of Network Centric Operations requirements. > Somehow I don't think of the DoD as an "enterprise" and my=20 > comments are all in the context of my understanding of enterprises. > Obviously, a solution is needed in the scenario you describe,=20 > but I'd like to think of it as separable. >=20 > Brian >=20 >=20 > Klynsma, Steven L Mr CIO/G6/MITRE wrote: > > Classification: UNCLASSIFIED > > Caveats: NONE > >=20 > > Brian, > >=20 > > I work for the military and would dearly love to go to a=20 > dual-stack everywhere, but as Jim mentioned, that's simply=20 > not feasible. Unlike commercial users, we typically must=20 > develop our own unique comms networks that support unique=20 > military requirements (i.e. extremely constrained bandwidth=20 > (we feel lucky to have 16KBPS "pipes"), unpredictable, but=20 > inevitable and often lengthy, disconnects from network=20 > services, and a need for both host and routing infrastructure=20 > to be mobile). In such an environment, operating two routing=20 > protocols, as you must with dual-stack becomes quite=20 > problematic. In addition, because of the lengthy life cycles=20 > of weapon systems (15-20 years), you find yourself working=20 > with processors that are overloaded already. Throw a=20 > dual-stack requirement on this tactical environment and you=20 > break the camels back. =20 > >=20 > > So we are typically looking at replacing the entire=20 > tactical comms infrastructure. Given the other constraints=20 > on bandwidth, mobility, etc., it becomes very attractive to=20 > make the leap from IPv4 directly to IPv6 without a lengthy=20 > dual-stack transition period. However, that essentially=20 > creates an IPv6-only ISP supporting our weapon systems on the=20 > battlefield. Of course, this, in turn, comes with another=20 > set of problems, primarily for interoperablity with=20 > IPv4-based current systems and allies, but we hope by=20 > aggressively migrating the force to IPv6-dominance that these=20 > additional problems become manageable. > >=20 > > Vr, > >=20 > > Steve >=20 >=20 > >=20 From owner-v6ops@ops.ietf.org Thu Oct 14 11:38:21 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00861 for ; Thu, 14 Oct 2004 11:38:20 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI7eW-000DtI-6a for v6ops-data@psg.com; Thu, 14 Oct 2004 15:36:28 +0000 Received: from [130.230.4.14] (helo=mail2.cs.tut.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI7bc-000DOW-JE for v6ops@ops.ietf.org; Thu, 14 Oct 2004 15:33:28 +0000 Received: from viherkiuru (viherkiuru.cs.tut.fi [130.230.4.36]) by mail2.cs.tut.fi (Postfix) with SMTP id A8641157931; Thu, 14 Oct 2004 18:33:26 +0300 (EEST) Received: by viherkiuru (sSMTP sendmail emulation); Thu, 14 Oct 2004 18:33:26 EEST To: "Bound, Jim" Cc: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A462@tayexc13.americas.cpqcorp.net> From: Heikki Vatiainen Date: 14 Oct 2004 18:33:26 +0300 In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0784A462@tayexc13.americas.cpqcorp.net> Message-ID: Lines: 122 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk "Bound, Jim" writes: > > > Here are the comments: > > > > > > 4.4.2 Deploy a parallel IPv6 infrastructure [cut] > > Such an approach means acquiring additional hardware, but it has the > > advantage that the existing IPv4 routing platforms are not disturbed > > by the introduction of IPv6. > > > > I think dual stack has been available long enough that the > > potential for disturbance is not great enough to justify a > > parallel infrasturcture for IPv6. In fact, I would recommend > > that parallel infrasturcture is only built if no other > > options, such as upgrading to dual stack routers, are available. > > That is not the objective. Users will use the capability of dual stack > in different ways and we are addressing all those ways. To not do that > is not useful one-size-does-not-fit-all for transition. I agree that one size does not fit all. My point was to remind that if no IPv6-capable existing routing infrastructure is available, one simple possibility is to consider upgrading to such an infrastructure. This is what section 4.4 or its subsections are not currently mentioning. Currently the draft makes building parallel IPv6 infrastructure to look fairly simple when I think it is not. My current opinion is to prefer upgrade to dual stack over building parallel if those are the choices and if there are resources to do the both and no special reason to select one over the other. When I wrote the original paragraph, I had dual stack vs parallel in mind. > > > > The problems we have noticed with running a parallel > > infrastructure touch many areas. I try to enumerate our > > findings in the following paragraphs. > > > > The parallel infrastructure forces you to have two times the > > documentation about the network. If e.g. intra-organization > > packet filtering is done, you have to literally think and > > check twice that the filters are set up as required. With > > dual stack you may need to create two sets of filters, one > > for IPv4 and one for IPv6, but at least they apply to the > > same interface on the same router. > > Agreed and you just provide the exact operational business case for Ipv6 > Dominant network transition and the market and users are seeing this > now. The faster they move to IPv6 the quicker the deployment of the > reason they want IPv6 and at a reduced cost. Thanks for helping that > case. Ok, that works for IPv6 Dominant Network Deployment too. My original thought was to reduce the effort by not building parallel infra. One way to achieve that is to go IPv6 dominant. I have to admit I did not think IPv6 Dominant very much when reading the draft since it feels like a option that is very much in the future. > > > > If the network is built using VLANs one can extend (trunk) > > the VLANs to the new IPv6-only routers. If the new IPv6 > > routers are physically and/or network topologically close to > > the existing IPv4 routers, this may be easy to accomplish. > > The fourth paragraph discusses the use of one router to serve > > many VLANs by "collapsing" them to one router interface. If > > the VLANs are not already topologically close to the new IPv6 > > router one has to grow the existing VLAN coverage. Nobody > > wants to do this since this is yet another step to a VLAN > > spaghetti network. > > This is valid in my view but the flip side is what is the cost to drop > extended vlan boxes into the network and then add the tags to reach > those routers. Your only then touch two points on your network and > minimal cost to add a complete IPv6 site theoretically???????????? This would, in other words, be the so called "router-on-a-stick" configuration to route IPv6 between VLANs? This configuration would allow minimal cost IPv6 coverage if the VLANs are easily available where the IPv6 router is put to. E.g. here that is not the case, since we have quite a number of IP subnets, and respectively VLANs, and effort is made to keep the VLANs as local as possible. If we would route IPv6 between all or even most of the VLANs with a "router-on-a-stick" method, we would have to give up this VLAN locality and that would cause plenty of resistance. It is not seen as simple and secure to have all VLANs available on every campus Ethernet switch. > > > > When thinking about the routers, IPv6-only router may cause > > surprisingly many problems with network and router management. > > Hmm we assumed no IPv6 only anything? But rather use of IPv6 dominantly > over IPv4? I was thinking IPv6 only router when building a parallel IPv6 network. The first paragraph of section 4.4.2 mentions the possibility of IPv6 only routing. > > Our > > IPv6 only router does not do at least SNMP, Syslog or NTP > > over IPv6 transport. One may think this is only a short term > > problem, but the router is only half of the problem. The > > other half are the management applications that are used to > > monitor and manage the routers. If dual stack routers are > > used, management applications can use IPv4 transport making > > the lack of IPv6 transport a less or even a non problem. > > Hmmm I did not know of IPv6 ONLY router? But generally I agree with you > and so does the draft? We took a commercial router, as opposed to using a linux or bsd router, and experimented with building parallel IPv6 routing using a router that has IPv4 routing disabled. IPv6 routing works very well, but the router management was quite heavily tied to IPv4. Thanks, -- Heikki Vatiainen * hessu@cs.tut.fi Tampere University of Technology * Tampere, Finland From owner-v6ops@ops.ietf.org Thu Oct 14 12:59:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07240 for ; Thu, 14 Oct 2004 12:59:22 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI8v2-0000P1-Kq for v6ops-data@psg.com; Thu, 14 Oct 2004 16:57:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI8ut-0000NB-A9 for v6ops@ops.ietf.org; Thu, 14 Oct 2004 16:57:27 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9EGv9f13300; Thu, 14 Oct 2004 19:57:12 +0300 Date: Thu, 14 Oct 2004 19:57:09 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: "Bound, Jim" , Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt In-Reply-To: <416E77C5.10804@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 14 Oct 2004, Brian E Carpenter wrote: > >>In the terminology of the document that case is > >> > >> > >> ====================================================== > >> |Application |Host 1 |Service |Host 2 |Application | > >> |----------- |Network|Provider|Network|---------- | > >> | Host 1 OS | | | | Host 2 OS | > >> =====================================+================ > >> |Dual or IPv4| | |Dual IP|Dual IPv4| > >> 0 | ---- |Dual IP|Dual IP | or |---- or ----| > >> | Dual | | |v4 only|Dual IPv4| > >> ====================================================== > >> > >>In other words, why would an enterprise choose to paint > >>itself into any of the awkward corners of the other 13 scenarios? > > > > > > Sorry I cannot respond to such a general statement ok. > > Let me rephrase my concern. Somebody reading this draft without > the background knowledge of this WG will simply not realise > that the fundamental coexistence model is dual stack. They will > find themselves right in the discussion of the 13 scenarios > and think that they must pick one of them - but the first question > anyone should ask is "can I just do a straightforward dual stack > model?" I would argue that for the large majority of enterprise > customers the answer will be yes, except for the corner cases > where they will have to do something special. So I think the draft > needs to start out by saying this - either by inserting my Scenario 0 > or by saying it in words. > > I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt, > which starts out with base scenario 1, widespread dual stack. I have the same concern as Brian. The authors note in the draft that there are a lot of combinations, (like close to a hundred, I recall from IETF60) and listing them all the matrix doesn't make sense. That's OK. What I was writing in my review comment is that because the matrix shows a number [less than all] of entries, it should be sufficiently clearly explained what those rest are, and properly bring forward those ones that clearly make sense even if that requires only relatively small amount of text. For example, one approach I could see might be having two matrices: one for the "really common and simple" cases (which a lot of enterprises would probably look for), and "more complex" cases which require need to be analyzed in more depth, and solutions provided for. That might be one way to clearly show that there are both very simple approaches and and more complex/advanced approaches, without having to list every possible combination out there. There might be other ways to do that as well. -- 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 Oct 14 13:13:53 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08591 for ; Thu, 14 Oct 2004 13:13:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CI9AI-0002zz-GV for v6ops-data@psg.com; Thu, 14 Oct 2004 17:13:22 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CI9AH-0002zB-1o for v6ops@ops.ietf.org; Thu, 14 Oct 2004 17:13:21 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9EHCvp13760; Thu, 14 Oct 2004 20:12:57 +0300 Date: Thu, 14 Oct 2004 20:12:57 +0300 (EEST) From: Pekka Savola To: Pyda Srisuresh cc: Senthil Sivakumar , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-Reply-To: <20041012140221.61106.qmail@web40422.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > If that's not the case, it's certainly not > > correct -- you can deploy IPv6 as dual-stack without any need for > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > difficulties the defence dept faces to transition to dual stacks. It just goes > to show that the IETF can only offer transition mechanims, but not mandate one. > When the choices are comprehensive, the customers will pick the one that best > suits their environment. Such networks are likely to require something like tunneling or translation, yes. But the real problem with NAT-PT is that all the people who don't need it, and shouldn't need it were they to deploy IPv6 as dual-stack, want to try to fit it in their deployment plans because, "well, it exists.. so there must be some use for it for us here". NAT-PT like translation needs to be the last choice, not to dictate or give inappropriate direction to the deployment. > > I have the feeling that most typical applications applications already > > support proxies or have inherent support for middleboxes (e.g., http, > > smtp, dns, ftp). > > [suresh] Disagree with your comment about proxies. What did you mean by > "inherent support for middleboxes"? Middleboxes refer to many things including > proxies, NATs and NAT-PTs. Web proxies are common. FTP proxies are common. Mail submission (a function of SMTP) is submitted to a 'proxy'. DNS lookups are usually done from a recursive name server. Lots of protocols are already using explicit middleboxes such as recursive DNS servers, web proxies, etc. -- that's a good thing. Leveraging these for transition makes great deal of sense. NAT-PT (and NAT) try to act as a middlebox transparently, without the consent of the host or the application. This causes a lot of problems. Explicit middleboxes, above, do not have this problem. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 14 14:08:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12324 for ; Thu, 14 Oct 2004 14:08:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIA0F-0009v2-0E for v6ops-data@psg.com; Thu, 14 Oct 2004 18:07:03 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIA0C-0009uO-SD for v6ops@ops.ietf.org; Thu, 14 Oct 2004 18:07:01 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9EI6h515323; Thu, 14 Oct 2004 21:06:45 +0300 Date: Thu, 14 Oct 2004 21:06:43 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: v6ops@ops.ietf.org Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0784A4A3@tayexc13.americas.cpqcorp.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Inline, (I've removed discussions on which no further comments seemed necessary) On Tue, 12 Oct 2004, Bound, Jim wrote: > > 1) > > 1.a) the matrix in section 3 (and sect 8) appears to be out of sync > > from the description of section 3 (see below for 'v6 to v4'), for > > example because the text says trivial scenarios have been removed, but > > > matrix lines 1,2,12, and 13 (at least) are extremely trivial. What > > has happened? > > We need to add more text to sect 3 and 8. If trivial but pivotal to the > analysis we kept them in the draft for later context and why we have > more writing to do. Yes, it makes sense to keep the important cases even if they were trivial. But my nit was just on the wording, which said that trivial cases were already removed.. it shouldn't have said that, or it should have been more exact in describing what actually was removed (and why exactly). > > 1.b) Further than that, one thing I'd like to see is slightly more > > text (if that's not too difficult to manage) describing as precisely > > as reasonable how the table has been 'derived', in a manner that the > > reader would be able to follow which combinations have been omitted > > and due to what reasons. > > That would allow one to better analyze that all the cases have been > > dealt with (in one manner or another). > > I think we can enhance that text but don't think it wise to discuss that > which is omitted because that can cause a rathole. Would suggest that > WG tell us what needs to be added? I see a problem with not discussion the omitted ones at all. You've been through the though exercise of going through all the combinations, and using some methodology, picked the ones that you felt were interesting. I think that methodology needs to be carefully described because otherwise the people who might have different assumptions than you (on what they consider important or not) probably arrive in a different result. What I'd like to see is the clear "derivation" of the table, in a sense as a mathematical proof is derived. Each step can be reasonably easily understood, and by following the steps, the correctness of the final result can be evaluated. > > Please also remember that even the trivial tunneling/translation > > scenarios will need to be described if we need a (new) solution to > > them. > > We believe we have that covered. > > What do you mean by new solution that may help? Sorry, I don't understand your question. > > 1.c) you may need to end up having to define the columns of the > > matrix carefully. In particular 'Host X network' (I read it as "the > > enterprise network originating the packets") has at least one > > ambiguity. How do you represent the fact that the first-hop link of a > > > dual-stack node supports only one protocol version, but further down > > the enterprise network both protocols are supported ? > > We do that by the protocol in the cell but we can explain that better > for further input to see if WG believes it is correct. Seems we need to > describe the cells better from recent input. OK. > > 1.d) there also seem to be some scenarios which are either too far in > > > the future or easily worked around which might be decreed out of > > scope. For the former, consider the cases of v6-only ISPs -- I don't > > think these are worth the energy at this point of time. Or do you > > refer to *dual-stack* ISPs who are offering only v6 services (and > > provide translation/tunneling for v4 legacy)? For the latter, > > consider the scenario 4, i.e., v6-only application run on a dual-stack > > > host, towards an IPv4-only application. I mean, what would the point > > of creating v6-only application which needs to talk to v4-only > > application, because doing such would nullify all the benefits of IPv6 > > > -- couldn't one just say that one should do a dual-stack app in that > > case? > > I would agree on v6 only ISPs and that really is dual stack for some > time. > > But we as a team and many in this WG do believe IPv6 dominant networks > will be supported and we intend to leave that scenario and matrix cell > in the spec but we can keep discussing. > > We do need to make it clear an ISP will not be v6 only that was not our > intention either. My main concern was on v6 ISPs, though I'd be a bit concerned of the v6-only -> v4-only app scenario. That would seem to be like generic v6-only + NAT-PT direction, which folks may or may not agree with. But that can certainly be discussed. > > [IMHO, v6-only apps should never be used if that necessitated the > > translation to v4, because doing so would nullify the usefulness of > > v6-only app to begin with, or requiring embedding a lot of v4 hacks in > > > the translator -- both would seem like non-starters to me] > > V6only apps implies a dual stack. It should say v6 apps. Not sure if I understood your comment. I was saying that there are different cases like: 1) all the applications on a node are IPv6-only, and the node is IPv6-only, with only v6 network connectivity 2) all the applications on a node are IPv6-only, and the node is dual-stack 3) some apps on a node are v6, some v4, and some dual-stack; the node is dual-stack, with v4 connectivity through tunnel or natively I am rather concerned about the usefulness of 1) having to talk to v4 hosts or apps (the NAT-PT model). 2) makes seemingly little sense for the same reason, because if the nodes are dual-stack, why not have some of the apps (at least) dual-stack or v4 as well? 3) makes most sense of these particular examples. > > (Section 4.5 is not clear whether you're addressing the 'branch > > office' or 'home user' case.. probably the latter?) > > We are addressing the enterprise and enterprise remote sites. We need > to make that clear this section is incomplete now. Most enterprises run > their own Internet Walmart, GM, DOD, Renault, Boeing, etc and each will > have different views and business reasons for deploying IPv6. Again > one-size-does-not-fit-all. Sure, but the point is that the doc should be consistent on what it says it's covering (and what not). What actually is covered is a separate issue. > > 4) > > 7.4.1 IPv6 DNS > > > > > > > > The enterprise site should deploy a DNS service that is capable of > > both serving IPv6 DNS records (of the AAAA format, see RFC????) and > > of communicating over IPv6 transport. > > > > > > > > Specific IPv6 DNS issues are reported in [DNSV6]. > > > > ==> I think it would be useful to make it clearer here that while the > > v6 transport is nice, it's in no way requirement for anything, except > > for deploying v6-only nodes. > > Not sure I agree. V4 or v6 transport is a choice we assume dual stacks? I meant, v6 transport for DNS is not required when you run dual-stack. It's nice, of course, but not required. It's only required with v6-only. > > > so the host gets it from the ISP-- but this was considered out of > > scope...) > > > > | IPv6 | | | |IPv4 IPv4|Translation on > > 4 | ---- | IPv4 |Dual IP |Dual IP|---- or ----|local IPv6 > > | Dual | | | |IPv4 Dual|domain > > > > ==> as said, IMHO this nullifies the usefulness of creating v6-only > > applications so wouldn't it be better to just require such apps to > > support > > v4 as well? (there may be a couple of rare exceptions to this, like > > 3GPP IMS, but those are another story) > > I think first we need to provide support for all possibilities and we > cannot require users to deploy our view, only provide mechanisms for > scenarios we believe we have heard. And there are enough users want to > run IPv6 dominant subnets immediately and this does not mean nor to we > imply v6 only anything if so we need to fix it. > > We should not be doing business cases for IPv6 in the IETF. That is > what will determine how transition is done in the market. Out of scope > for the IETF. Sure, but the doc should probably include some analysis on what each approach implies. > > | IPv6 | | | | IPv6 |IPv6 > > Host Tunnel > > 5 | ---- | IPv4 | IPv4 |Dual IP| ---- |(Brokered at > > | Dual | | | | IPv6 |Net2) > > > > ==> this would appear to be case where the host tunnel is brokered > > across the Internet. What reason would Net2 have for providing this > > to other enterprises? Do you have specific assumptions about their > > relations? > > We can do that but point is decap via Tunnel Broker at remote site is > something we have heard. I agree with all the security concerns when > Enterprise is going to public Internet. Yes -- so if these are described, these issues should probably be described at some length, because this is a non-trivial approach and fundamentally requires some kind of association with Net1 and Net2, which may not be valid in some cases where this comes up. > > |IPv6 IPv6|Dual IP| |Dual IP|IPv6 IPv6|Site-to-Site > > 6 |---- or ----| or | IPv4 | or |---- or ----|Tunnel| > > |IPv6 Dual|v6 only| |v6 only|IPv6 Dual|(Brokered?) > > > > ==> wouldn't this be creating something like 'v6 6bone mess' > > (especially if sites are 'v6 only', which we all probably want to > > avoid? I mean, is there a specific problem in the current approach, > > i.e., the enterprises which want to connect other v6 enterprises to > > get v6 ISPs which are globally connected throughout the Internet ? > > We have heard it is a requirement and it is an option. Same argument as above. > > | Dual | | | | IPv4 |DSTM for > > 10| ---- |Dual IP| v6 Only| IPv4 | ---- |v4 thru v6 > > | Dual | | | | IPv4 | > > > > ====================================================================== > > | Dual | | | | IPv4 |DSTM for > > 11| ---- |v6 only| v6 only| IPv4 | ---- |v4 thru v6 > > | Dual | | | | IPv4 | > > > > ==> you are proposing to run DSTM over Internet, right? > > No DSTM just provides address on the link or subnet. Nomenclature > positioning needs work. This is probably a moot point due to the bug below. > > dual-stack?!? i.e., how does v6 only site talk through v6-only ISP to > > > a v4-only site, for example? Also, (repeating from matrix line 5 > > above), what would be the justification for Net2 to provide such > > Interdomain service ? > > This is a bug. The v4 is encaped in v6 to the edge, and we can define > the edge better. > > Good catch. OK. > > 6) I'm having slight problems, at least yet, at seeing what is the > > role of > > appendix B in this document. This seems to be partially > > duplicating the > > text from enterprise scenarios, or..? > > Not really it is an example of a real network reinforcing the enterprise > and the objective of the appendix. Not sure if I understand your comment. The text might perhaps be better placed & expanded in a separate doc (like Tim Chown's campus transition), or maybe some parts generalized in the body.. [...] > > tunneling' or 'zero-conf tunneling'), or also "direct tunneling" ? > > - are you considering whether there are internal NATs in the > > enterprise or not (I don't personally know whether this is typical or > > not) ? > > - do you consider whether there are multiple boxes or just one (and > > if multiple, how are would they be distributed [e.g., geographically]) > > i.e., the number of users? > > All of the above have to be part of our analysis but how we present that > is TBD. OK great. > > Use of [NAT-PT] is discouraged [cite the I-D on this?]. A recommended > > > solution is the use of ALGs. Many applications naturally have an ALG > > behavior, and can be used to offer access for "legacy" IPv4 services > > such as SMTP (dual-stack email server, see [cite I-D, by Alain I > > think?]) or HTTP (a dual-stack web cache), and are already operated > > by many enterprise sites. By dual-stacking the servers, an IPv6 only > > node can reach an external IPv4-only web site (for example) via the > > proxy without any additional (Layer 3 or > > 4) translation being required. > > > > ==> it would be worth mentioning (at least as a problem, if not > > further > > discussed) in a new paragraph how one would configure such proxies or > > translators on the v6-only nodes. Manually? > > Using yet-to-be-defined DHCPv6 options? Using unspecified means? > > Hmmmm to some degree yes but we don't want to own that one in this spec > we may need some WG help on this one. Well, at least it could be noted as an open issue, even if nothing concrete is done or decided in this document. (In any case, this doc should not give "normative" guidance on which way to go, because we'll likely need IETF process to run on this). > > procedural > > ---------- > > > > ==> there is one author too many (6 > 5). If it is not possible to > > reduce the number of authors, the alternative would be just listing > > the editor in the front page, and the authors in the contact > > information or contributors. > > I want to fight for an exception on this ok. So I will get ready to > ask. I understand but these folks names all should be listed. I think exceptions are only rarely granted, but of course, this is a moot point before this ready to the IESG. -- 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 Oct 14 14:21:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13082 for ; Thu, 14 Oct 2004 14:21:03 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIADN-000BhY-9C for v6ops-data@psg.com; Thu, 14 Oct 2004 18:20:37 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIADM-000Bgo-3c for v6ops@ops.ietf.org; Thu, 14 Oct 2004 18:20:36 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9EIKLY15569; Thu, 14 Oct 2004 21:20:21 +0300 Date: Thu, 14 Oct 2004 21:20:21 +0300 (EEST) From: Pekka Savola To: "Klynsma, Steven L Mr CIO/G6/MITRE" cc: "'Brian E Carpenter'" , "'Bound, Jim'" , Subject: RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 14 Oct 2004, Klynsma, Steven L Mr CIO/G6/MITRE wrote: > I'm sure you're aware that the military has much to gain by taking > on a "commercial" flavor. By that I mean reducing our dependence on > government-developed equipment and using the stuff already available > in commercial sector. Therefore, we take great pains to use > commercial terminology (as opposed to military) and would hope that > a separate solution for our environment can be avoided. I'm not sure how to read this. This could be read as: 'so, if we want to use a "commercial flavour" but have already decided on which model we want to adopt, we need to push our deployment model to the commercial sector, so that they'll have something in common with us, and we don't need any special software or hardware'. That would seem to be .. rather questionable, but here are probably other interpretations as well. -- 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 Oct 14 15:21:48 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18318 for ; Thu, 14 Oct 2004 15:21:47 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIB7N-000IFs-4S for v6ops-data@psg.com; Thu, 14 Oct 2004 19:18:29 +0000 Received: from [66.218.92.40] (helo=web40429.mail.yahoo.com) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CIB7M-000IFa-64 for v6ops@ops.ietf.org; Thu, 14 Oct 2004 19:18:28 +0000 Message-ID: <20041014191827.29699.qmail@web40429.mail.yahoo.com> Received: from [66.224.113.195] by web40429.mail.yahoo.com via HTTP; Thu, 14 Oct 2004 12:18:27 PDT Date: Thu, 14 Oct 2004 12:18:27 -0700 (PDT) From: Pyda Srisuresh Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt To: Pekka Savola Cc: Senthil Sivakumar , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --- Pekka Savola wrote: > On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > > If that's not the case, it's certainly not > > > correct -- you can deploy IPv6 as dual-stack without any need for > > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > > difficulties the defence dept faces to transition to dual stacks. It just > goes > > to show that the IETF can only offer transition mechanims, but not mandate > one. > > When the choices are comprehensive, the customers will pick the one that > best > > suits their environment. > > Such networks are likely to require something like tunneling or > translation, yes. But the real problem with NAT-PT is that all the > people who don't need it, and shouldn't need it were they to deploy > IPv6 as dual-stack, want to try to fit it in their deployment plans > because, "well, it exists.. so there must be some use for it for us > here". > > NAT-PT like translation needs to be the last choice, not to dictate or > give inappropriate direction to the deployment. > [suresh] I agree. My point is simply that deprecating or not identifying NAT-PT as a solution in the scenarios it really is the only option would be a diservice to the transition strategy and wouldnt be the right thing to do for the IETF. > > > I have the feeling that most typical applications applications already > > > support proxies or have inherent support for middleboxes (e.g., http, > > > smtp, dns, ftp). > > > > [suresh] Disagree with your comment about proxies. What did you mean by > > "inherent support for middleboxes"? Middleboxes refer to many things > including > > proxies, NATs and NAT-PTs. > > Web proxies are common. FTP proxies are common. Mail submission (a [Suresh] Web proxies are relatively more common. Even these are not universal. Certainly not with the customers I had talked to. As for FTP proxies, these are relatively rare, in my experience. > function of SMTP) is submitted to a 'proxy'. DNS lookups are usually > done from a recursive name server. > [Suresh] So, how does that eliminate the need for NAT-PT? > Lots of protocols are already using explicit middleboxes such as > recursive DNS servers, web proxies, etc. -- that's a good thing. [suresh] Hmm... I wouldnt call the DNS servers middleboxes. They simply provide a namelookup service. Middleboxes are assumed to be in the end-2-end path and perform packet forwarding. > Leveraging these for transition makes great deal of sense. > [Suresh] As I said earlier, if a customer has the proxy servers for all the applications he uses, that is not an issue. > NAT-PT (and NAT) try to act as a middlebox transparently, without the > consent of the host or the application. This causes a lot of > problems. Explicit middleboxes, above, do not have this problem. > [suresh] I understand what you say. Transparancy provided by NAT-PT is desirable in certain scenarios as was described in 2766. It is not evenryone's cup of tea. Midcom extension to such a middlebox can help more applications use the NAT-PT middlebox effectively. > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > regards, suresh ===== From owner-v6ops@ops.ietf.org Thu Oct 14 18:12:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12783 for ; Thu, 14 Oct 2004 18:12:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIDny-0009pu-D8 for v6ops-data@psg.com; Thu, 14 Oct 2004 22:10:38 +0000 Received: from [171.71.176.70] (helo=sj-iport-1.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIDnx-0009pf-7V for v6ops@ops.ietf.org; Thu, 14 Oct 2004 22:10:37 +0000 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 14 Oct 2004 15:17:36 -0700 X-BrightmailFiltered: true Received: from ssenthil-w2k.cisco.com (dhcp-128-107-178-164.cisco.com [128.107.178.164]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id i9EM8Jk3020665; Thu, 14 Oct 2004 15:08:19 -0700 (PDT) Message-Id: <4.3.2.7.2.20041014125913.01ccab68@mira-sjcd-2.cisco.com> X-Sender: ssenthil@mira-sjcd-2.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 14 Oct 2004 15:09:08 -0700 To: Pekka Savola From: Senthil Sivakumar Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Cc: Pyda Srisuresh , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" In-Reply-To: References: <20041012140221.61106.qmail@web40422.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk At 08:12 PM 10/14/2004 +0300, Pekka Savola wrote: >On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > > If that's not the case, it's certainly not > > > correct -- you can deploy IPv6 as dual-stack without any need for > > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > > difficulties the defence dept faces to transition to dual stacks. It > just goes > > to show that the IETF can only offer transition mechanims, but not > mandate one. > > When the choices are comprehensive, the customers will pick the one > that best > > suits their environment. > >Such networks are likely to require something like tunneling or >translation, yes. But the real problem with NAT-PT is that all the >people who don't need it, and shouldn't need it were they to deploy >IPv6 as dual-stack, want to try to fit it in their deployment plans >because, "well, it exists.. so there must be some use for it for us >here". We all agree that NAT-PT should not be used when it does not have to be and I think there are enough documents out there to describe all the issues with NAT-PT. But we should not discount the fact that there are use case scenarios and this is a real life use case scenarios. >NAT-PT like translation needs to be the last choice, not to dictate or >give inappropriate direction to the deployment. Nevertheless, it has to be a choice. Most of the people agree that it is the last choice. Senthil > > > I have the feeling that most typical applications applications already > > > support proxies or have inherent support for middleboxes (e.g., http, > > > smtp, dns, ftp). > > > > [suresh] Disagree with your comment about proxies. What did you mean by > > "inherent support for middleboxes"? Middleboxes refer to many things > including > > proxies, NATs and NAT-PTs. > >Web proxies are common. FTP proxies are common. Mail submission (a >function of SMTP) is submitted to a 'proxy'. DNS lookups are usually >done from a recursive name server. > >Lots of protocols are already using explicit middleboxes such as >recursive DNS servers, web proxies, etc. -- that's a good thing. >Leveraging these for transition makes great deal of sense. > >NAT-PT (and NAT) try to act as a middlebox transparently, without the >consent of the host or the application. This causes a lot of >problems. Explicit middleboxes, above, do not have this problem. > >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 14 20:42:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25369 for ; Thu, 14 Oct 2004 20:42:57 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIG9f-000OQD-CG for v6ops-data@psg.com; Fri, 15 Oct 2004 00:41:11 +0000 Received: from [203.254.224.25] (helo=mailout2.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIG9e-000OPp-8a for v6ops@ops.ietf.org; Fri, 15 Oct 2004 00:41:10 +0000 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I5L009BGOKKKI@mailout2.samsung.com> for v6ops@ops.ietf.org; Fri, 15 Oct 2004 09:41:08 +0900 (KST) Received: from ep_mmp1 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I5L00DM5OK0G4@mailout2.samsung.com> for v6ops@ops.ietf.org; Fri, 15 Oct 2004 09:40:48 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I5L009QQOJZIX@mmp1.samsung.com> for v6ops@ops.ietf.org; Fri, 15 Oct 2004 09:40:47 +0900 (KST) Date: Fri, 15 Oct 2004 09:42:12 +0900 From: Soohong Daniel Park Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-reply-to: To: Pekka Savola , Pyda Srisuresh Cc: Senthil Sivakumar , Elwyn Davies , "'Sham Chakravorty'" , "'Brian E Carpenter'" , Cedric Aoun , "'V6OPS'" Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7BIT I am really not sure why you insist all the people don't need it. It's so dangerous assertion. Are you trying to search for 100% completed transition tool ? As you know, it is not possible. Again, NAT-PT is one of transition mechanisms. Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. > -----Original Message----- > From: owner-v6ops@ops.ietf.org > [mailto:owner-v6ops@ops.ietf.org]On Behalf Of Pekka Savola > Sent: Friday, October 15, 2004 2:13 AM > To: Pyda Srisuresh > Cc: Senthil Sivakumar; Elwyn Davies; 'Sham Chakravorty'; 'Brian E > Carpenter'; Cedric Aoun; 'V6OPS' > Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > > On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > > If that's not the case, it's certainly not > > > correct -- you can deploy IPv6 as dual-stack without any need for > > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > > difficulties the defence dept faces to transition to dual > stacks. It just goes > > to show that the IETF can only offer transition mechanims, but > not mandate one. > > When the choices are comprehensive, the customers will pick the > one that best > > suits their environment. > > Such networks are likely to require something like tunneling or > translation, yes. But the real problem with NAT-PT is that all the > people who don't need it, and shouldn't need it were they to deploy > IPv6 as dual-stack, want to try to fit it in their deployment plans > because, "well, it exists.. so there must be some use for it for us > here". > > NAT-PT like translation needs to be the last choice, not to dictate or > give inappropriate direction to the deployment. > > > > I have the feeling that most typical applications applications already > > > support proxies or have inherent support for middleboxes (e.g., http, > > > smtp, dns, ftp). > > > > [suresh] Disagree with your comment about proxies. What did you mean by > > "inherent support for middleboxes"? Middleboxes refer to many > things including > > proxies, NATs and NAT-PTs. > > Web proxies are common. FTP proxies are common. Mail submission (a > function of SMTP) is submitted to a 'proxy'. DNS lookups are usually > done from a recursive name server. > > Lots of protocols are already using explicit middleboxes such as > recursive DNS servers, web proxies, etc. -- that's a good thing. > Leveraging these for transition makes great deal of sense. > > NAT-PT (and NAT) try to act as a middlebox transparently, without the > consent of the host or the application. This causes a lot of > problems. Explicit middleboxes, above, do not have this problem. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Thu Oct 14 21:23:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27978 for ; Thu, 14 Oct 2004 21:23:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIGnV-0002fH-QW for v6ops-data@psg.com; Fri, 15 Oct 2004 01:22:21 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CIGnU-0002ez-7e for v6ops@ops.ietf.org; Fri, 15 Oct 2004 01:22:21 +0000 Received: (eyou send program); Fri, 15 Oct 2004 09:59:41 +0800 Message-ID: <297805581.09679@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Fri, 15 Oct 2004 09:59:41 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: ssenthil@cisco.com Cc: Pyda@njupt.edu.cn, Srisuresh@njupt.edu.cn, srisuresh@yahoo.com, Elwyn@njupt.edu.cn, Davies@njupt.edu.cn, elwynd@nortelnetworks.com, schakra@mitre.org, brc@zurich.ibm.com, Cedric@njupt.edu.cn, Aoun@njupt.edu.cn, cedric.aoun@nortelnetworks.com, v6ops@ops.ietf.org Date: Fri, 15 Oct 2004 09:59:41 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Level: * X-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_00,FROM_ENDS_IN_NUMS, MSGID_FROM_MTA_HEADER,PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk We are all talking about wheather the NAT-PT should be chosen. But there are lots of transimisms besides NAT-PT, do you think they are all helpful to a special circumstance? A special transition mechanism solves a special condition, if there a mechanism that can replace NAT-PT much better, we can consider to deprecate it. Best, >From: Senthil Sivakumar >Reply-To: >To: Pekka Savola >Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >Date:Thu, 14 Oct 2004 15:09:08 -0700 > >At 08:12 PM 10/14/2004 +0300, Pekka Savola wrote: > >On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > > > If that's not the case, it's certainly not > > > > correct -- you can deploy IPv6 as dual-stack without any need for > > > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > > > > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > > > difficulties the defence dept faces to transition to dual stacks. It > > just goes > > > to show that the IETF can only offer transition mechanims, but not > > mandate one. > > > When the choices are comprehensive, the customers will pick the one > > that best > > > suits their environment. > > > >Such networks are likely to require something like tunneling or > >translation, yes. But the real problem with NAT-PT is that all the > >people who don't need it, and shouldn't need it were they to deploy > >IPv6 as dual-stack, want to try to fit it in their deployment plans > >because, "well, it exists.. so there must be some use for it for us > >here". > > We all agree that NAT-PT should not be used when it does not have to be > and I think there are enough documents out there to describe all the > issues with NAT-PT. But we should not discount the fact that there > are use case scenarios and this is a real life use case scenarios. > > > > >NAT-PT like translation needs to be the last choice, not to dictate or > >give inappropriate direction to the deployment. > > Nevertheless, it has to be a choice. Most of the people agree that it is the > last choice. > > Senthil > > > > > I have the feeling that most typical applications applications already > > > > support proxies or have inherent support for middleboxes (e.g., http, > > > > smtp, dns, ftp). > > > > > > [suresh] Disagree with your comment about proxies. What did you mean by > > > "inherent support for middleboxes"? Middleboxes refer to many things > > including > > > proxies, NATs and NAT-PTs. > > > >Web proxies are common. FTP proxies are common. Mail submission (a > >function of SMTP) is submitted to a 'proxy'. DNS lookups are usually > >done from a recursive name server. > > > >Lots of protocols are already using explicit middleboxes such as > >recursive DNS servers, web proxies, etc. -- that's a good thing. > >Leveraging these for transition makes great deal of sense. > > > >NAT-PT (and NAT) try to act as a middlebox transparently, without the > >consent of the host or the application. This causes a lot of > >problems. Explicit middleboxes, above, do not have this problem. > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Thu Oct 14 21:24:43 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28245 for ; Thu, 14 Oct 2004 21:24:43 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIGpd-0002ow-45 for v6ops-data@psg.com; Fri, 15 Oct 2004 01:24:33 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CIGpb-0002oW-Fm for v6ops@ops.ietf.org; Fri, 15 Oct 2004 01:24:32 +0000 Received: (eyou send program); Fri, 15 Oct 2004 10:01:57 +0800 Message-ID: <297805717.09853@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Fri, 15 Oct 2004 10:01:57 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: v6ops@ops.ietf.org Date: Fri, 15 Oct 2004 10:01:57 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,BAYES_00,FROM_ENDS_IN_NUMS, MSGID_FROM_MTA_HEADER,PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk It just goes to show that the IETF can only offer transition mechanisms, but not mandate one. When the choices are comprehensive, the customers will pick the one that best suits their environment. Disagree with your comment about proxies. What did you mean by "inherent support for middleboxes"? Middleboxes refer to many things including proxies, NATs and NAT-PTs We are all talking about wheather the NAT-PT should be chosen. But there are lots of transimisms besides NAT-PT, do you think they are all helpful to a special circumstance? A special transition mechanism solves a special condition, if there a mechanism that can replace NAT-PT much better, we can consider to deprecate it. Best, >From: Senthil Sivakumar >Reply-To: >To: Pekka Savola >Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >Date:Thu, 14 Oct 2004 15:09:08 -0700 > >At 08:12 PM 10/14/2004 +0300, Pekka Savola wrote: > >On Tue, 12 Oct 2004, Pyda Srisuresh wrote: > > > > If that's not the case, it's certainly not > > > > correct -- you can deploy IPv6 as dual-stack without any need for > > > > NAT-PT. And dual-stack is definitely the simplest way to deploy IPv6. > > > > > > [suresh] You might refer comments from Steve Klynsma & Jim Bound - about > > > difficulties the defence dept faces to transition to dual stacks. It > > just goes > > > to show that the IETF can only offer transition mechanims, but not > > mandate one. > > > When the choices are comprehensive, the customers will pick the one > > that best > > > suits their environment. > > > >Such networks are likely to require something like tunneling or > >translation, yes. But the real problem with NAT-PT is that all the > >people who don't need it, and shouldn't need it were they to deploy > >IPv6 as dual-stack, want to try to fit it in their deployment plans > >because, "well, it exists.. so there must be some use for it for us > >here". > > We all agree that NAT-PT should not be used when it does not have to be > and I think there are enough documents out there to describe all the > issues with NAT-PT. But we should not discount the fact that there > are use case scenarios and this is a real life use case scenarios. > > > > >NAT-PT like translation needs to be the last choice, not to dictate or > >give inappropriate direction to the deployment. > > Nevertheless, it has to be a choice. Most of the people agree that it is the > last choice. > > Senthil > > > > > I have the feeling that most typical applications applications already > > > > support proxies or have inherent support for middleboxes (e.g., http, > > > > smtp, dns, ftp). > > > > > > [suresh] Disagree with your comment about proxies. What did you mean by > > > "inherent support for middleboxes"? Middleboxes refer to many things > > including > > > proxies, NATs and NAT-PTs. > > > >Web proxies are common. FTP proxies are common. Mail submission (a > >function of SMTP) is submitted to a 'proxy'. DNS lookups are usually > >done from a recursive name server. > > > >Lots of protocols are already using explicit middleboxes such as > >recursive DNS servers, web proxies, etc. -- that's a good thing. > >Leveraging these for transition makes great deal of sense. > > > >NAT-PT (and NAT) try to act as a middlebox transparently, without the > >consent of the host or the application. This causes a lot of > >problems. Explicit middleboxes, above, do not have this problem. > > > >-- > >Pekka Savola "You each name yourselves king, yet the > >Netcore Oy kingdom bleeds." > >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > From owner-v6ops@ops.ietf.org Fri Oct 15 08:33:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23202 for ; Fri, 15 Oct 2004 08:33:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIRCX-000KD9-0I for v6ops-data@psg.com; Fri, 15 Oct 2004 12:28:53 +0000 Received: from [195.212.29.136] (helo=mtagate3.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIRCP-000KCQ-Hd for v6ops@ops.ietf.org; Fri, 15 Oct 2004 12:28:46 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9FCSfrT162906; Fri, 15 Oct 2004 12:28:41 GMT Received: from mail-gw2.hursley.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9FCSfQG148686; Fri, 15 Oct 2004 13:28:41 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CIRCL-0000MA-00; Fri, 15 Oct 2004 13:28:41 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CIRCL-0000M5-00; Fri, 15 Oct 2004 13:28:41 +0100 Received: from zurich.ibm.com (sig-9-145-251-158.de.ibm.com [9.145.251.158]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i9FCSfa352938; Fri, 15 Oct 2004 13:28:41 +0100 Message-ID: <416FC274.9060909@zurich.ibm.com> Date: Fri, 15 Oct 2004 14:28:36 +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: "Klynsma, Steven L Mr CIO/G6/MITRE" CC: "'Bound, Jim'" , v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) (UNCLASSIFIED) References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Fully understand in terms of solutions. I meant "separable" for the purposes of analysis. Brian Klynsma, Steven L Mr CIO/G6/MITRE wrote: > Classification: UNCLASSIFIED > Caveats: NONE > > Brian, > > I'm sure you're aware that the military has much to gain by taking on a "commercial" flavor. By that I mean reducing our dependence on government-developed equipment and using the stuff already available in commercial sector. Therefore, we take great pains to use commercial terminology (as opposed to military) and would hope that a separate solution for our environment can be avoided. > > Steve > > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Thursday, October 14, 2004 9:02 AM > To: Klynsma, Steven L Mr CIO/G6/MITRE > Cc: 'Bound, Jim'; v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) > > Steve, > > Yes, I am fully aware of Network Centric Operations requirements. > Somehow I don't think of the DoD as an "enterprise" and my comments are all in the context of my understanding of enterprises. > Obviously, a solution is needed in the scenario you describe, but I'd like to think of it as separable. > > Brian > > > Klynsma, Steven L Mr CIO/G6/MITRE wrote: > >>Classification: UNCLASSIFIED >>Caveats: NONE >> >>Brian, >> >>I work for the military and would dearly love to go to a dual-stack everywhere, but as Jim mentioned, that's simply not feasible. Unlike commercial users, we typically must develop our own unique comms networks that support unique military requirements (i.e. extremely constrained bandwidth (we feel lucky to have 16KBPS "pipes"), unpredictable, but inevitable and often lengthy, disconnects from network services, and a need for both host and routing infrastructure to be mobile). In such an environment, operating two routing protocols, as you must with dual-stack becomes quite problematic. In addition, because of the lengthy life cycles of weapon systems (15-20 years), you find yourself working with processors that are overloaded already. Throw a dual-stack requirement on this tactical environment and you break the camels back. >> >>So we are typically looking at replacing the entire tactical comms infrastructure. Given the other constraints on bandwidth, mobility, etc., it becomes very attractive to make the leap from IPv4 directly to IPv6 without a lengthy dual-stack transition period. However, that essentially creates an IPv6-only ISP supporting our weapon systems on the battlefield. Of course, this, in turn, comes with another set of problems, primarily for interoperablity with IPv4-based current systems and allies, but we hope by aggressively migrating the force to IPv6-dominance that these additional problems become manageable. >> >>Vr, >> >>Steve > > > > > Classification: UNCLASSIFIED > Caveats: NONE > > From owner-v6ops@ops.ietf.org Fri Oct 15 09:33:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27336 for ; Fri, 15 Oct 2004 09:32:59 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CISAZ-0000W0-3L for v6ops-data@psg.com; Fri, 15 Oct 2004 13:30:55 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CISAL-0000UJ-Mi for v6ops@ops.ietf.org; Fri, 15 Oct 2004 13:30:41 +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 i9FDUeGn021177 for ; Fri, 15 Oct 2004 14:30:40 +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 OAA09418 for ; Fri, 15 Oct 2004 14:30:38 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9FDUcx30344 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 14:30:38 +0100 Date: Fri, 15 Oct 2004 14:30:38 +0100 From: Tim Chown To: "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Message-ID: <20041015133038.GE29992@login.ecs.soton.ac.uk> Mail-Followup-To: 'V6OPS' References: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> <416A71ED.5020402@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416A71ED.5020402@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 11, 2004 at 01:43:41PM +0200, Brian E Carpenter wrote: > > But you have another option that will allow legacy to speak to legacy - > an IPv4-in-IPv6 tunnel. That's a no-brainer that we haven't really > discussed much, and as far as I can see it can do everything double-NAT-PT > can do. As an aside, I think this is being covered in the zero-config tunnelling discussions now, which I feel is important (i.e. automatic IPv4-in-IPv6 tunnelling). Tim From owner-v6ops@ops.ietf.org Fri Oct 15 09:47:03 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29342 for ; Fri, 15 Oct 2004 09:47:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CISPd-0001yN-2Y for v6ops-data@psg.com; Fri, 15 Oct 2004 13:46:29 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CISPZ-0001xx-1e for v6ops@ops.ietf.org; Fri, 15 Oct 2004 13:46:25 +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 i9FDkOGn021449 for ; Fri, 15 Oct 2004 14:46:24 +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 OAA10576 for ; Fri, 15 Oct 2004 14:46:23 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9FDkNl30787 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 14:46:23 +0100 Date: Fri, 15 Oct 2004 14:46:23 +0100 From: Tim Chown To: "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Message-ID: <20041015134623.GG29992@login.ecs.soton.ac.uk> Mail-Followup-To: 'V6OPS' References: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.nortel.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Soohong Daniel Park wrote: > > Nevertheless, I know several sites are using NAT-PT efficiently on > their use cases. It would be interesting, with the enterprise analysis in mind, to know why these sites used NAT-PT, and what they could not solve in other ways. We used to run NAT-PT, but no longer do. As Pekka points out, we should also consider how IPv4 and IPv6 will be adopted. IPv4 may remain the protocol to access legacy apps (like web, mail, ftp). But these are also the ones that lend themselves to natural proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). IPv6 may become more popular for specific new applications, which do not require access to IPv4 services, as Pekka is hinting. Suresh wrote: > As Senthil points out, the assumption that NAT-PT deployment will stifle > innovation in v6 seems flawed. NAT-PT is a transition mechanism which is > essential for wider V6 deployment. Without NAT-PT, you will see bigger > resistance to deploying V6 . You need NAT-PT for legacy applications (ex: > e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts or > applications. This is the attraction of NAT-PT. This is not the same as the > proxy solution that will require applications to be changed/recompiled. Proxies can be deployed transparently. SMTP naturally so, Web caches also, there doesn't necessarily have to be any client side alterations. Tim From owner-v6ops@ops.ietf.org Fri Oct 15 10:30:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06338 for ; Fri, 15 Oct 2004 10:30:54 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIT5v-0006WK-5U for v6ops-data@psg.com; Fri, 15 Oct 2004 14:30:11 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIT5u-0006W4-0M for v6ops@ops.ietf.org; Fri, 15 Oct 2004 14:30:10 +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 i9FEU9Gn022341 for ; Fri, 15 Oct 2004 15:30:09 +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 PAA14665 for ; Fri, 15 Oct 2004 15:30:05 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9FEU4q31810 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 15:30:04 +0100 Date: Fri, 15 Oct 2004 15:30:04 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI FIED) (UNCLASSIFIED) Message-ID: <20041015143004.GO29992@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <416FC274.9060909@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416FC274.9060909@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk I see no reason why the scenario should not be included in ent-analysis, after all it is Scenario 3 of the ent-scenarios document. See page 7 of: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ent-scenarios-05.txt Thus my view is it must be in this analysis. Tim On Fri, Oct 15, 2004 at 02:28:36PM +0200, Brian E Carpenter wrote: > Fully understand in terms of solutions. I meant "separable" for > the purposes of analysis. > > Brian > > Klynsma, Steven L Mr CIO/G6/MITRE wrote: > >Classification: UNCLASSIFIED > >Caveats: NONE > > > >Brian, > > > >I'm sure you're aware that the military has much to gain by taking on a > >"commercial" flavor. By that I mean reducing our dependence on > >government-developed equipment and using the stuff already available in > >commercial sector. Therefore, we take great pains to use commercial > >terminology (as opposed to military) and would hope that a separate > >solution for our environment can be avoided. > > > >Steve > > > >-----Original Message----- > >From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > >Sent: Thursday, October 14, 2004 9:02 AM > >To: Klynsma, Steven L Mr CIO/G6/MITRE > >Cc: 'Bound, Jim'; v6ops@ops.ietf.org > >Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (UNCLASSI > >FIED) > > > >Steve, > > > >Yes, I am fully aware of Network Centric Operations requirements. > >Somehow I don't think of the DoD as an "enterprise" and my comments are > >all in the context of my understanding of enterprises. > >Obviously, a solution is needed in the scenario you describe, but I'd like > >to think of it as separable. > > > > Brian > > > > > >Klynsma, Steven L Mr CIO/G6/MITRE wrote: > > > >>Classification: UNCLASSIFIED > >>Caveats: NONE > >> > >>Brian, > >> > >>I work for the military and would dearly love to go to a dual-stack > >>everywhere, but as Jim mentioned, that's simply not feasible. Unlike > >>commercial users, we typically must develop our own unique comms networks > >>that support unique military requirements (i.e. extremely constrained > >>bandwidth (we feel lucky to have 16KBPS "pipes"), unpredictable, but > >>inevitable and often lengthy, disconnects from network services, and a > >>need for both host and routing infrastructure to be mobile). In such an > >>environment, operating two routing protocols, as you must with dual-stack > >>becomes quite problematic. In addition, because of the lengthy life > >>cycles of weapon systems (15-20 years), you find yourself working with > >>processors that are overloaded already. Throw a dual-stack requirement > >>on this tactical environment and you break the camels back. > >>So we are typically looking at replacing the entire tactical comms > >>infrastructure. Given the other constraints on bandwidth, mobility, > >>etc., it becomes very attractive to make the leap from IPv4 directly to > >>IPv6 without a lengthy dual-stack transition period. However, that > >>essentially creates an IPv6-only ISP supporting our weapon systems on the > >>battlefield. Of course, this, in turn, comes with another set of > >>problems, primarily for interoperablity with IPv4-based current systems > >>and allies, but we hope by aggressively migrating the force to > >>IPv6-dominance that these additional problems become manageable. > >> > >>Vr, > >> > >>Steve > > > > > > > > > >Classification: UNCLASSIFIED > >Caveats: NONE > > > > -- Tim North American IPv6 Task Force Technologist Seminar More info at http://www.ipv6seminar.com/ From owner-v6ops@ops.ietf.org Fri Oct 15 11:02:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11089 for ; Fri, 15 Oct 2004 11:02:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CITZB-0009xT-GL for v6ops-data@psg.com; Fri, 15 Oct 2004 15:00:25 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CITZ3-0009wa-T8 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 15:00:18 +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 i9FF0GGn023050 for ; Fri, 15 Oct 2004 16:00:17 +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 QAA16790 for ; Fri, 15 Oct 2004 16:00:13 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9FF0Dx32492 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 16:00:13 +0100 Date: Fri, 15 Oct 2004 16:00:13 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041015150013.GR29992@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <1097180513.4359.34.camel@localhost.localdomain> 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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 11, 2004 at 02:14:26PM +0300, Pekka Savola wrote: > > substantial > ----------- > 1.a) the matrix in section 3 (and sect 8) appears to be out of sync from the > description of section 3 (see below for 'v6 to v4'), for example because the > text says trivial scenarios have been removed, but matrix lines 1,2,12, and 13 > (at least) are extremely trivial. What has happened? I think the doc needs to clarify a) why the cases that are being focused on are being focused on b) show that no corner cases are being overlooked that may require additional transition functionality not yet available. > 1.c) you may need to end up having to define the columns of the matrix > carefully. In particular 'Host X network' (I read it as "the enterprise > network originating the packets") has at least one ambiguity. How do you > represent the fact that the first-hop link of a dual-stack node supports > only one protocol version, but further down the enterprise network both > protocols are supported ? A full matrix of posisbilities is big :) > 1.d) there also seem to be some scenarios which are either too far in > the future or easily worked around which might be decreed out of scope. On the contrary I think 4-in-6 tunnelling must be considered now. It is the end-game for some, for others it's on the near term radar. But more importantly it would be nice to have solutions that cater for both from the outset, rather than discovering something in 2-3 years that we could have thought about now. > 2) section 4.5 and 7.5.2 describe some approaches to remote IPv6 access > support, but Introduction ruled IPv6 VPN's as out of scope. These could be > seen as contradictory (but maybe the latter referred to v6-in-v6 VPNs, I > don't know).. maybe it needs to be clarified what's in scope and what's not? Remote access doesn't imply VPN for everyone. My view on 4.5 and 7.5.2 is providing IPv6 access in general, i.e. where the user's point-of-attachment ISP offers no IPv6 service, but the user's home ISP (enterprise) can (e.g. a broker or 6to4 relay). > (Section 4.5 is not clear whether you're addressing the 'branch office' or > 'home user' case.. probably the latter?) By "site" I'd include branch offices. For 4.5 I mean a user at home, or a hotspot, or any case as per my text immediately above. > 3) section 4.1 says that ULAs are not considered or advocated in this doc, > while 7.3.2 says they should not be used. These appear to be conflicting > statements. I think it'd be useful to mention ULAs, state that they are not > *necessary* but could be used under specific conditions, and possibly to > point to another document to come [on NAT-PT/RFC1918 alternatives]. Hmm, I don't remember writing that, good spot :) I suggest removing the reference to ULAs in 7.3.2. > 7.4.1 IPv6 DNS > > The enterprise site should deploy a DNS service that is capable of > both serving IPv6 DNS records (of the AAAA format, see RFC????) and > of communicating over IPv6 transport. > > ==> I think it would be useful to make it clearer here that while the v6 > transport is nice, it's in no way requirement for anything, except for > deploying v6-only nodes. OK, so say "The enterprise site should deploy a DNS service that is capable of serving IPv6 DNS records (of the AAAA format, see RFC????) to facilitate DNS lookups of IPv6 addresses for nodes. Where IPv6-only nodes are deployed on site, the DNS server(s) should be capable of communicating over IPv6 transport. It is thus prudent that the site's DNS servers should be planned to be dual-stack." > (For example, in our enterprises, we haven't been able to field v6 transport > resolver support in 2-3 years due to a number of reasons, but that hasn't > stopped us from deploying v6 -- the document should (IMHO) give as few as > possible requirements for "moving forward" with IPv6. OK, well, we run local dual-stack resolvers, and also put these in the global DNS. We're deploying dual-stack to facilitate the easy deployment of IPv6 only nodes in due course. > The similar occurs in 7.4.3: > > A stateless configured node wishing to gain other configuration > information (e.g. DNS, NTP servers) will likely need a Stateless > DHCPv6 service available. > > , where this doesn't clearly identify that these are not strictly necessary > for dual-stack systems.. because they are already configured using v4 > protocols and means. Just to make it clearer that these are not a strict > requirement for v6 deployment.. So "An IPv6-only stateless configured..." Also we should state (if the ent team agrees) that a goal of dual-stack everywhere (Sect.4) is to prepare for v6 only devices to be added easily, thus all key services (DNS, NTP, etc) should be available over v6 transport. > 6) I'm having slight problems, at least yet, at seeing what is the role of > appendix B in this document. This seems to be partially duplicating the > text from enterprise scenarios, or..? It also has some specific discussion > and good analysis. Should some parts of this be in the body, in a separate > document, or..? [also note, the text is rather unreadable because some > lines are wrapped oddly -- are you using good tools e.g. xml2rfc for > editing?] I think we could integrate Appendix B's thinking into the main text? But that's a big chunk of work... > ==> given that the document restricts itself to (mainly) L3 considerations, > would there be simple ways to try to reflect that somehow in the title of > the draft and intro/abstract? For example insert 'connectivity' there? Not > a big issue. Right, but the ISP analysis also focuses on L3, as does unmanaged, and they have a similar title? This is also why we consider L3 and only basic services (DNS), and not VPNs etc in the doc. > 7.4 Phase 2: Deploying generic basic service components > > Most of these are discussed in Section 4 of [BSCN]. Here we > comment on those aspects that we believe are in scope for this > analysis document. Thus we have not included network management, > multihoming, multicast or application transition analysis here, but > these aspects should be addressed in Phase 2. > > ==> I may be misunderstanding the last line, but isn't that saying that > section 7.4 should be addressing this, or are you referring to the "next > round" of enterprise evaluation (beyond the basic concepts) ? In 7.4. > For secure autoconfiguration, the SEND protocol is defined (now at > RFC????). > > ==> because deploying SEND is not necessarily quite as trivial as this, > maybe a placeholder should be put here, like 'The best practices for > deploying the necessary certificates need to be analyzed.' The above line was only ever meant to be such a thing, so any wording is OK as long as it makes the point clear. > Hosts may also generate or request IPv6 Privacy Addresses > (RFC3041); there is support for DHCPv6 to assign privacy addresses > to nodes in managed environments. > > ==> is there actually any justification for using RFC3041 in enterprise > environments? Should one put such a doubt here if not? Personally, I'm > having trouble figuring out the actual problem... It is a currently valid RFC that should be considered in host address configuration, hence it's in 7.4.3. > Use of [NAT-PT] is discouraged [cite the I-D on this?]. A > recommended solution is the use of ALGs. Many applications > naturally have an ALG behavior, and can be used to offer access for > "legacy" IPv4 services such as SMTP (dual-stack email server, see > [cite I-D, by Alain I think?]) or HTTP (a dual-stack web cache), > and are already operated by many enterprise sites. By dual-stacking > the servers, an IPv6 only node can reach an external IPv4-only web > site (for example) via the proxy without any additional (Layer 3 or > 4) translation being required. > > ==> it would be worth mentioning (at least as a problem, if not further > discussed) in a new paragraph how one would configure such proxies or > translators on the v6-only nodes. Manually? Using yet-to-be-defined DHCPv6 > options? Using unspecified means? I agree it should be included. Not sure on exact wording. > Such an aid may be either a tunnel broker [TBRK], ideally one that > supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site should be aware of security > issues with operating 6to4 relays [cite ref?]. > > ==> are you referring to the 6to4 relay usage in a manner where the > enterprise would provide a 'private' 6to4 relay, just for its own users who > would need to know its v4 address, and manually configure it on their > laptops (w/ using public addresses)? Note that there is no provision for > access control here. Considering how common the NATs are, this seems like > something that doesn't have sufficient "return value" for the enterprise, > considering that there are plenty of free relays reachable through the > anycast prefix. Yes, manually configured. We do this now and it is used. Up to the user to choose that (or whoever admins their machine) or to use a "near" relay offered by some other ISP. > ==> there are a lot of documents in 'normative references'. These are meant > to be documents which are required to be read to understand the document. > Please note that this doc cannot be published until all of these are also > published. Is that intentional? Maybe some shuffling around would be > warranted? Good point :) Thanks for the feedback! -- Tim From owner-v6ops@ops.ietf.org Fri Oct 15 11:09:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11524 for ; Fri, 15 Oct 2004 11:09:24 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIThX-000Awa-P9 for v6ops-data@psg.com; Fri, 15 Oct 2004 15:09:03 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIThW-000AwH-JV for v6ops@ops.ietf.org; Fri, 15 Oct 2004 15:09:02 +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 i9FF91Gn023237 for ; Fri, 15 Oct 2004 16:09:01 +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 QAA17567 for ; Fri, 15 Oct 2004 16:09:00 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9FF90532708 for v6ops@ops.ietf.org; Fri, 15 Oct 2004 16:09:00 +0100 Date: Fri, 15 Oct 2004 16:09:00 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041015150900.GS29992@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A4A3@tayexc13.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B0784A4A3@tayexc13.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Oct 12, 2004 at 09:52:08AM -0400, Bound, Jim wrote: > > > > Most of these are discussed in Section 4 of [BSCN]. Here we > > comment on those aspects that we believe are in scope for this > > analysis document. Thus we have not included network management, > > multihoming, multicast or application transition analysis here, but > > these aspects should be addressed in Phase 2. > > > > ==> I may be misunderstanding the last line, but isn't that saying > > that section 7.4 should be addressing this, or are you referring to > > the "next round" of enterprise evaluation (beyond the basic concepts) > > ? > > This is a huge bug we need to fix this. Good catch. This was mean't to > say these are next level common transition issues for deployment all our > v6ops docs have not addressed so lets not pick on enterprise analysis. Ooops, yes, I misread too, so I agree it's not in 7.4, instead say something like "these aspects are of general applicability and thus out of scope for this specific enterprise analysis". Thanks Pekka. > > ==> is there actually any justification for using RFC3041 in > > enterprise environments? Should one put such a doubt here if not? > > Personally, I'm having trouble figuring out the actual problem... > > Me to I defer to my co-authors :--) While it exists, we cite it, I think? (i.e. we kind of take the node requirements viewpoint?) > > ==> there is one author too many (6 > 5). If it is not possible to > > reduce the number of authors, the alternative would be just listing > > the editor in the front page, and the authors in the contact > > information or contributors. > > I want to fight for an exception on this ok. So I will get ready to > ask. I understand but these folks names all should be listed. Pekka, you have never met Jim Bound Yanick Pouffary? That's one person :) > > The parallel infrastructure would only ever be seen as an interim step > > > towards a full dual-stack deployment on a unified infrastructure. > > > > ==> could 'would only ever be seen' be reworded? That seems like a > > complex structure of words for us foreigners.. > > Will reflect. "would typically be deployed as an interim" ? -- Tim From owner-v6ops@ops.ietf.org Fri Oct 15 23:48:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04129 for ; Fri, 15 Oct 2004 23:48:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CIfW1-0005kM-6g for v6ops-data@psg.com; Sat, 16 Oct 2004 03:45:57 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CIfW0-0005k5-2c for v6ops@ops.ietf.org; Sat, 16 Oct 2004 03:45:56 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 56699AD54; Fri, 15 Oct 2004 23:45:55 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.0); Fri, 15 Oct 2004 23:45:55 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Date: Fri, 15 Oct 2004 23:45:58 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B0784AB59@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Thread-Index: AcSyDuRZUyKXhu0VSiuUtMapYZiJoABI1oAA From: "Bound, Jim" To: "Pekka Savola" , "Brian E Carpenter" Cc: X-OriginalArrivalTime: 16 Oct 2004 03:45:55.0239 (UTC) FILETIME=[A3E11370:01C4B332] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Pekka,=20 > -----Original Message----- > From: Pekka Savola [mailto:pekkas@netcore.fi]=20 > Sent: Thursday, October 14, 2004 12:57 PM > To: Brian E Carpenter > Cc: Bound, Jim; v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt >=20 > On Thu, 14 Oct 2004, Brian E Carpenter wrote: > > >>In the terminology of the document that case is > > >> > > >> > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > >> |Application |Host 1 |Service |Host 2 |Application | > > >> |----------- |Network|Provider|Network|---------- | > > >> | Host 1 OS | | | | Host 2 OS | > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > >> |Dual or IPv4| | |Dual IP|Dual IPv4| > > >> 0 | ---- |Dual IP|Dual IP | or |---- or ----| > > >> | Dual | | |v4 only|Dual IPv4| > > >> = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > >> > > >>In other words, why would an enterprise choose to paint=20 > itself into=20 > > >>any of the awkward corners of the other 13 scenarios? > > >=20 > > >=20 > > > Sorry I cannot respond to such a general statement ok. =20 > >=20 > > Let me rephrase my concern. Somebody reading this draft without the=20 > > background knowledge of this WG will simply not realise that the=20 > > fundamental coexistence model is dual stack. They will find=20 > themselves=20 > > right in the discussion of the 13 scenarios and think that=20 > they must=20 > > pick one of them - but the first question anyone should ask=20 > is "can I=20 > > just do a straightforward dual stack model?" I would argue that for=20 > > the large majority of enterprise customers the answer will be yes,=20 > > except for the corner cases where they will have to do something=20 > > special. So I think the draft needs to start out by saying this -=20 > > either by inserting my Scenario 0 or by saying it in words. > >=20 > > I don't have this problem with=20 > draft-ietf-v6ops-ent-scenarios-05.txt, > > which starts out with base scenario 1, widespread dual stack. >=20 > I have the same concern as Brian. Responded to Brian on that one. >=20 > The authors note in the draft that there are a lot of=20 > combinations, (like close to a hundred, I recall from IETF60)=20 > and listing them all the matrix doesn't make sense. That's=20 > OK. What I was writing in my review comment is that because=20 > the matrix shows a number [less than all] of entries, it=20 > should be sufficiently clearly explained what those rest are,=20 > and properly bring forward those ones that clearly make sense=20 > even if that requires only relatively small amount of text. We will not discuss what is not there only what is there if the WG sees cells we missed please tell us.=20 >=20 > For example, one approach I could see might be having two matrices: =20 > one for the "really common and simple" cases (which a lot of=20 > enterprises would probably look for), and "more complex"=20 > cases which require need to be analyzed in more depth, and=20 > solutions provided for. There are solutions for all combinations except true v6 only and v4 only. Suggest you see next draft and it will be more clear. =20 >=20 > That might be one way to clearly show that there are both=20 > very simple approaches and and more complex/advanced=20 > approaches, without having to list every possible combination=20 > out there. There might be other ways to do that as well. Also what is simple to one is complex to the other we clearly need to make it clear. And will do our best as quick as possible. Thanks /jim >=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 Sat Oct 16 22:35:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27961 for ; Sat, 16 Oct 2004 22:35:28 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJ0oe-000A3c-56 for v6ops-data@psg.com; Sun, 17 Oct 2004 02:30:36 +0000 Received: from [195.212.29.137] (helo=mtagate4.uk.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJ0od-000A3L-4r for v6ops@ops.ietf.org; Sun, 17 Oct 2004 02:30:35 +0000 Received: from d06nrmr1307.portsmouth.uk.ibm.com (d06nrmr1307.portsmouth.uk.ibm.com [9.149.38.129]) by mtagate4.uk.ibm.com (8.12.10/8.12.10) with ESMTP id i9H2USQi413824; Sun, 17 Oct 2004 02:30:28 GMT Received: from mail-gw2.hursley.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1307.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9H2UR0p139184; Sun, 17 Oct 2004 03:30:28 +0100 Received: from localhost.localdomain ([127.0.0.1] helo=mail-gw2.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CJ0oV-0002PK-00; Sun, 17 Oct 2004 03:30:27 +0100 Received: from [9.20.136.27] (helo=sp15en17.hursley.ibm.com) by mail-gw2.hursley.ibm.com with esmtp (Exim 4.12) id 1CJ0oV-0002PF-00; Sun, 17 Oct 2004 03:30:27 +0100 Received: from zurich.ibm.com (sig-9-145-128-88.de.ibm.com [9.145.128.88]) by sp15en17.hursley.ibm.com (AIX5.1/8.11.6p2/8.11.0) with SMTP id i9H2UQa550268; Sun, 17 Oct 2004 03:30:27 +0100 Message-ID: <4170C045.4030803@zurich.ibm.com> Date: Sat, 16 Oct 2004 08:31: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'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt References: <4.3.2.7.2.20041010095109.030c92c0@mira-sjcd-2.cisco.com> <416A71ED.5020402@zurich.ibm.com> <20041015133038.GE29992@login.ecs.soton.ac.uk> In-Reply-To: <20041015133038.GE29992@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_12_24 autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > On Mon, Oct 11, 2004 at 01:43:41PM +0200, Brian E Carpenter wrote: > >>But you have another option that will allow legacy to speak to legacy - >>an IPv4-in-IPv6 tunnel. That's a no-brainer that we haven't really >>discussed much, and as far as I can see it can do everything double-NAT-PT >>can do. > > > As an aside, I think this is being covered in the zero-config tunnelling > discussions now, which I feel is important (i.e. automatic IPv4-in-IPv6 > tunnelling). I was actually thinking of a configured router-to-router 4-in-6 tunnel as an alternative to double-NAT-PT, but of course an automatic one would be even nicer. Brian From owner-v6ops@ops.ietf.org Sun Oct 17 05:55:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08255 for ; Sun, 17 Oct 2004 05:55:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJ7hW-0001V1-62 for v6ops-data@psg.com; Sun, 17 Oct 2004 09:51:42 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJ7hV-0001Ug-0g for v6ops@ops.ietf.org; Sun, 17 Oct 2004 09:51:41 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9H9pdr07345; Sun, 17 Oct 2004 12:51:39 +0300 Date: Sun, 17 Oct 2004 12:51:39 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com Subject: Send in requests for agenda slots for IETF61 Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, (co-chair hat on) We currently have one slot scheduled for IETF61, 2.5 hours on Wednesday morning. Please send in agenda requests to the co-chairs. Describe at least: - the title of the talk - the amount of time you'd want - which draft (or other) would be basis for discussion [operational presentations would also be OK] - who would be presenting/leading the discussion - what is the goal of the agenda item - (if relevant) how this relates to the business of the WG We may need to restrict the agenda to ensure sufficient discussion and resolution of the 'critical path' (scenarios/analysis) work items. (hat off) -- 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 Oct 18 02:46:13 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19494 for ; Mon, 18 Oct 2004 02:46:13 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJRCn-0002Js-Bm for v6ops-data@psg.com; Mon, 18 Oct 2004 06:41:17 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJRCl-0002JU-Iw for v6ops@ops.ietf.org; Mon, 18 Oct 2004 06:41:16 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9I6fDx01186 for ; Mon, 18 Oct 2004 09:41:13 +0300 Date: Mon, 18 Oct 2004 09:41:13 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, A couple of comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt. In short, this seems like a start in narrowing down the list of methods given in draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-), and 2) the draft doesn't sufficiently describe the mechanism/protocol/implementation requirements, and how those interoperate with whatever the ISPs would deploy. substantial ----------- 1) the most fundamental issue I see with this draft builds on text in section 4 about what is the mandatory-to-implement mechanism and what is not. That's important. There are two perspectives here: 'mandatory to implement' in the specific service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy' in the ISP. I think you've only focused on what the ISP should deploy. You'll also need to discuss what should be mandatory to implement in the protocols/mechanisms, because this is where interop problems happen. (I.e., I think the document too much deployment-centric, not focusing sufficiently on what must be implemented and how that would operate with different modes of deployment.) My fundamental concern is that if you say "ISP can implement any of the proposed approaches, or preferably all of them", that means that for a mechanism to be interoperable with what the ISPs are offering, the mechanisms/protocols would need to implement EVERYTHING. And that seems like a potentially bad tradeoff to me. The fewer autodiscovery mechanisms there are, the fewer combinations there are that something would not work. For example, if we just specified DNS lookup in a certain way, the ISP would only have one way to deploy it and the mechanism one way to implement it, and interoperability would be guaranteed. "Less is more" ;-). The current draft is IMHO not a clear solution. It's a "kitchen sink" description of best solutions, which may or may not work together, and it may or may not be possible to get a well-interoperable mechanism out of it. I'd try to narrow down the number of different discovery mechanisms used as much as possible. 2. Section 5.4 seems to be proposing using dual-faced DNS towards the Internet vs own customers to control the visibility of the TEP addresses in the DNS. This seems completely wrong direction to take, because the addresses will still be available even if they are not made available in the public DNS. The last paragraph says it all: it would be much better to forget about dual-faced DNS completely in this context, and just perform filtering for the service. It offers complete solution to the "theft-of-service" problems, and is easier and more correct way to deploy to boot. So, please remove dual-faced DNS, unless there are some very strong unstated assumptions what benefits it gives instead of just filtering (and state them). 3. In section 7, you mention alternative DHCP-based solution. Because the people not familiar with the tun-auto-disc background will first ask "why not just use DHCPv4 and forget about everything else?", this section probably needs to include much better justification (to be gathered from the tun-auto-disc document, for example) why it's not the main proposal. Heck, it might even make sense to put some text, or at least referral to section 7, in the introduction. semi-substantial ---------------- On the other hand, shared anycast is also a very useful approach since it can globally identify a specific service (TEP or transition mechanism). ==> I think you're assuming that anycast (shared-unicast) would be allocated an interdomain range, because otherwise it can't be globally identified. This doesn't need to be the case. For example the records for 6in4, tsp, teredo, isatap and 6to4 would result: 6in4_srv.ispname.com, tsp_srv.ispname.com, teredo_srv.ispname.com, isatap_srv.ispname.com, 6to4_srv.ispname.com, etc. ==> you forgot the protocol (_tcp, _udp, etc.) which you had in the examples below? Also, did you find a source where "_ipv4" protocol comes from? Is there an example of this being used somewhere, or did you just make it up? :-) Note: The use of the underscore character minimizes the probability of conflict with DNS names already defined. ==> this belongs at the end of section 3.2, rather than at the end of 3.3, or..? To do that, the ISP's domain name is essential for prefixing the DNS search path, so the client (or rather the operating system) firstly learns the domain name of the ISP. There are several ways to do it, but in general it will be learned by making NS RR queries to the DNS. ==> You have assumptions in the last sentence, that the user looks up the IP address and its corresponding NS records to get the domain name. That's certainly one approach. But as currently deployed, folks just depend on the DNS search path. So, I think the last sentence needs to be expanded or removed. the client (rather the operating system) makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN, and QTYPE=A or QTYPE=CNAME. ==> which QTYPE is it? Are you saying the implementations need to query both? That's not good. Note that if you do a QTYPE=A query, that should also match CNAME and give the A record in the answer section, so there is no need to query CNAME explicitly. Try e.g. 'dig aaaa ftp.ipv6.funet.fi'. editorial --------- 4. It is topologically correct: Provides the nearest TEP to the user in terms of hops. ==> for the sake of clarify, please expand 'hops'. However anycast routes not always are well configured and stable, so connection with the server belonging to an anycast group could not be always possible, which means that is not necessarily the most topologically correct. ==> s/could/might/ ? The DNS will redirect to a TEP (or alternatively a TB more sophistication is required) located within the ISP or a third party (other near ISP, roaming TEP service, etc.) ==> s/TB/TB if/ ? The solution consequently, makes use of existing protocols, not requiring modifications or any new protocol. ==> remove ','. When looking for a specific TEP within the ISP the user belongs to, the first step is always the same because the user does not know (and neither has to know) which is the transition mechanism deployment status within its ISP, so the user always query firstly for a DNS SRV RR to its ISP DNS server. ==> you say 'user', but you probably referred to the application/stack ? the ISP DNS server. To discover the specific TEP within the ISPb@Ys ==> some corrupted chars around 'ISP'. It is also possible that ISPs are interested to offer IPv6 transition mechanisms by means of third party agreements or even through well know and convenient near TEPs which are for free. ==> some rewording near the end.. This section list de transition mechanisms and the service names to ==> s/list de/lists the/ ? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Tue Oct 19 11:42:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08049 for ; Tue, 19 Oct 2004 11:42:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CJw5h-0001ft-3A for v6ops-data@psg.com; Tue, 19 Oct 2004 15:40:01 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CJw5c-0001fO-PA for v6ops@ops.ietf.org; Tue, 19 Oct 2004 15:39:57 +0000 Received: from zctfc006.europe.nortel.com (zctfc006.europe.nortel.com [47.164.129.47]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9JFdrG24828 for ; Tue, 19 Oct 2004 17:39:54 +0200 (MEST) Received: from zctfc004.europe.nortel.com ([47.164.129.45]) by zctfc006.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id TH4S74KQ; Tue, 19 Oct 2004 17:39:54 +0200 Received: from [192.168.201.6] (actft015.europe.nortel.com [47.164.193.29]) by zctfc004.europe.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id T7MTBFY4; Tue, 19 Oct 2004 17:39:53 +0200 User-Agent: Microsoft-Entourage/11.0.0.040405 Date: Tue, 19 Oct 2004 17:39:51 +0200 Subject: Responses to comments sent on ml for the draft-aoun-natpt-deprecate draft X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Cedric Aoun To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Thanks for all your comments on the draft. Sorry for not responding before I was ooo and came back today. Going through all the email threads I can see that several people are keen on preserving a protocol translator for scenarios where application proxies are not applicable/possible. As we state in the introduction of the draft, the draft does not condemn all protocol translators but is explicitly targeted at the NAT-PT specification. I do recognize that application proxies could have a certain hidden complexity especially when the application has both a control plane and data plane (case of FTP, VoIP, RTSP Video over IP etc ...), but this complexity may not necessarily result in lower performance than adopting a generic protocol translator communicating with application proxies or with the application client themselves (ref NSIS or MIDCOM models), or indeed any greater/different complexity in either the application or the translator/proxy. As we stated in the draft all forms of IPv4<->IPv6 translators, induce a loss of information during the protocol translation, and break applications embedding IP addresses and port. If ALGs are used for these applications end to end security can't be used and a hop by hop security model needs to be used - in that case it is possible that we are better off with making the applications aware of proxies. If a protocol translator is really inevitable - and we still need to prove that it is REALLY required as the authors believe that we have not yet seen appealing reasons on the ml- then a simple translator using an updated SIIT specification could be used with the option of using Middlebox communication protocols to avoid autonomous allocation of binds. If folks on the mailing list agree that a new translator specification (without the DNS-ALG part) is needed with the interaction with Middlebox communication protocols or with reflector protocols such as STUN then the WG should decide to work on an alternative translator solution. The latter is definitely not mutually exclusive with the current NAT-PT specification deprecation draft. Regards Cedric Aoun From owner-v6ops@ops.ietf.org Wed Oct 20 04:40:34 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11608 for ; Wed, 20 Oct 2004 04:40:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKByp-0008Ce-QW for v6ops-data@psg.com; Wed, 20 Oct 2004 08:37:59 +0000 Received: from [131.228.20.22] (helo=mgw-x2.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKByo-0008CP-LD for v6ops@ops.ietf.org; Wed, 20 Oct 2004 08:37:58 +0000 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9K8bvq17227 for ; Wed, 20 Oct 2004 11:37:57 +0300 (EET DST) X-Scanned: Wed, 20 Oct 2004 11:37:44 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id i9K8bi43022561 for ; Wed, 20 Oct 2004 11:37:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00k8vSZ9; Wed, 20 Oct 2004 11:37:36 EEST Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9K8bZa25226 for ; Wed, 20 Oct 2004 11:37:35 +0300 (EET DST) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Oct 2004 11:37:27 +0300 Received: from esebe054.NOE.Nokia.com ([172.21.143.44]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 20 Oct 2004 11:37:26 +0300 Received: ESEBE054.noe.nokia.com 172.21.143.44 from 172.21.149.37 172.21.149.37 via HTTP with MS-WebStorage 6.0.6249 Received: from essrv103nok14937.ntc.nokia.com by ESEBE054.noe.nokia.com; 20 Oct 2004 11:37:27 +0300 Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt From: "Soininen Jonne (Nokia-NET/Helsinki)" To: "'V6OPS'" In-Reply-To: <20041015134623.GG29992@login.ecs.soton.ac.uk> References: <8F20221FB47FD51190AD00508BCF36BA0D4580B2@znsgy0k3.europe.nortel.com> <20041015134623.GG29992@login.ecs.soton.ac.uk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1098261447.4003.16.camel@essrv103nok14937.ntc.nokia.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 20 Oct 2004 11:37:27 +0300 X-OriginalArrivalTime: 20 Oct 2004 08:37:26.0860 (UTC) FILETIME=[0759A0C0:01C4B680] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hello, in Asia there seem to be emerging _large_ IPv6 only networks that may need some connectivity to the IPv4 Internet. Example of these is for instance is CNGI. They have been extensively looking for a NAT-PT type solution and are considering to use NAT-PT. I think we should have some sort of proposal what to do if we decide that NAT-PT is not the way to go. I wish the people that are involved in these projects would speak up and explain their requirements. Cheers, Jonne. On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote: > Soohong Daniel Park wrote: > > > > Nevertheless, I know several sites are using NAT-PT efficiently on > > their use cases. > > It would be interesting, with the enterprise analysis in mind, to know > why these sites used NAT-PT, and what they could not solve in other ways. > > We used to run NAT-PT, but no longer do. > > As Pekka points out, we should also consider how IPv4 and IPv6 will be > adopted. IPv4 may remain the protocol to access legacy apps (like web, > mail, ftp). But these are also the ones that lend themselves to natural > proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). > IPv6 may become more popular for specific new applications, which do not > require access to IPv4 services, as Pekka is hinting. > > Suresh wrote: > > As Senthil points out, the assumption that NAT-PT deployment will stifle > > innovation in v6 seems flawed. NAT-PT is a transition mechanism which is > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > resistance to deploying V6 . You need NAT-PT for legacy applications (ex: > > e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts or > > applications. This is the attraction of NAT-PT. This is not the same as the > > proxy solution that will require applications to be changed/recompiled. > > Proxies can be deployed transparently. SMTP naturally so, Web caches also, > there doesn't necessarily have to be any client side alterations. > > Tim -- Jonne Soininen Nokia Tel: +358 40 527 46 34 E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Wed Oct 20 04:59:49 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12563 for ; Wed, 20 Oct 2004 04:59:48 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKCJO-000B3n-Sb for v6ops-data@psg.com; Wed, 20 Oct 2004 08:59:14 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKCJN-000B3S-Iq for v6ops@ops.ietf.org; Wed, 20 Oct 2004 08:59:13 +0000 Received: from [10.10.10.102] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000513325.msg for ; Wed, 20 Oct 2004 11:04:18 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 20 Oct 2004 10:59:00 +0200 Subject: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <1098261447.4003.16.camel@essrv103nok14937.ntc.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Wed, 20 Oct 2004 11:04:18 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 20 Oct 2004 11:04:21 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi, Agree, is better to heard the people that is doing that. Probably I'm one of those ;-) We are deploying networks for 5.000 IPv6 sites (not a joke !). At the time being dual stack, but the aim in a short term is to disable IPv4 from the access and core network. As today we need still dual stack in the hosts because there may be some specific applications that could still be only IPv4, it seems to us that NAT-PT is a bad solution, as probably will fail for those applications, unless they are the typical HTTP applications, and in that case, we don't need NAT-PT (it can be done with a much more simple proxy !). So looking for simplicity, we use a proxy for all the "old" IPv4 traffic, so in our network (core and access) we only see IPv6 as much as possible. Alternatively for those applications that are still not ported, we use an automatic 4in6 tunneling mechanism from the "client" to the other host (if is located inside of our network), or from the client to the "border" of our network (the point where we connect to Internet), if the other host is located outside our network. DSTM may be a good candidate. I only see NAT-PT useful if the host can't be upgraded to IPv6 (dual stack actually) and the translation is simple and don't break anything, which may be easy because old IPv4-only devices should not use non-translatable header fields, BUT may be not the case also ;-) A very convenient alternative could be that the 4in6 tunneling for those devices is done by the border device (IPv6 router of the network ?). I think this will alleviate any need for NAT-PT. I'm missing any possible scenario where this couldn't work ? Regards, Jordi > De: "Soininen Jonne (Nokia-NET/Helsinki)" > Responder a: owner-v6ops@ops.ietf.org > Fecha: Wed, 20 Oct 2004 11:37:27 +0300 > Para: "'V6OPS'" > Asunto: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt > > Hello, > > in Asia there seem to be emerging _large_ IPv6 only networks that may > need some connectivity to the IPv4 Internet. Example of these is for > instance is CNGI. They have been extensively looking for a NAT-PT type > solution and are considering to use NAT-PT. I think we should have some > sort of proposal what to do if we decide that NAT-PT is not the way to > go. > > I wish the people that are involved in these projects would speak up and > explain their requirements. > > Cheers, > > Jonne. > > On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote: >> Soohong Daniel Park wrote: >>> >>> Nevertheless, I know several sites are using NAT-PT efficiently on >>> their use cases. >> >> It would be interesting, with the enterprise analysis in mind, to know >> why these sites used NAT-PT, and what they could not solve in other ways. >> >> We used to run NAT-PT, but no longer do. >> >> As Pekka points out, we should also consider how IPv4 and IPv6 will be >> adopted. IPv4 may remain the protocol to access legacy apps (like web, >> mail, ftp). But these are also the ones that lend themselves to natural >> proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). >> IPv6 may become more popular for specific new applications, which do not >> require access to IPv4 services, as Pekka is hinting. >> >> Suresh wrote: >>> As Senthil points out, the assumption that NAT-PT deployment will stifle >>> innovation in v6 seems flawed. NAT-PT is a transition mechanism which is >>> essential for wider V6 deployment. Without NAT-PT, you will see bigger >>> resistance to deploying V6 . You need NAT-PT for legacy applications (ex: >>> e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts >>> or >>> applications. This is the attraction of NAT-PT. This is not the same as the >>> proxy solution that will require applications to be changed/recompiled. >> >> Proxies can be deployed transparently. SMTP naturally so, Web caches also, >> there doesn't necessarily have to be any client side alterations. >> >> Tim > -- > Jonne Soininen > Nokia > > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Oct 20 10:10:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05020 for ; Wed, 20 Oct 2004 10:10:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKH8m-000NpZ-Mc for v6ops-data@psg.com; Wed, 20 Oct 2004 14:08:36 +0000 Received: from [195.212.29.150] (helo=mtagate1.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKH8k-000Nns-Rx for v6ops@ops.ietf.org; Wed, 20 Oct 2004 14:08:35 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9KE8UEA035060; Wed, 20 Oct 2004 14:08:31 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12nrmr1607.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9KE8UkJ176874; Wed, 20 Oct 2004 16:08:30 +0200 Received: from zurich.ibm.com (sig-9-145-128-178.de.ibm.com [9.145.128.178]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA64016; Wed, 20 Oct 2004 16:08:28 +0200 Message-ID: <4176715C.2030606@zurich.ibm.com> Date: Wed, 20 Oct 2004 16:08:28 +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: jordi.palet@consulintel.es CC: v6ops@ops.ietf.org Subject: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Jordi, are you using ayiya for this deployment? If so, what's your experience? Brian JORDI PALET MARTINEZ wrote: > Hi, > > Agree, is better to heard the people that is doing that. > > Probably I'm one of those ;-) > > We are deploying networks for 5.000 IPv6 sites (not a joke !). At the time > being dual stack, but the aim in a short term is to disable IPv4 from the > access and core network. > > As today we need still dual stack in the hosts because there may be some > specific applications that could still be only IPv4, it seems to us that > NAT-PT is a bad solution, as probably will fail for those applications, > unless they are the typical HTTP applications, and in that case, we don't > need NAT-PT (it can be done with a much more simple proxy !). > > So looking for simplicity, we use a proxy for all the "old" IPv4 traffic, so > in our network (core and access) we only see IPv6 as much as possible. > > Alternatively for those applications that are still not ported, we use an > automatic 4in6 tunneling mechanism from the "client" to the other host (if > is located inside of our network), or from the client to the "border" of our > network (the point where we connect to Internet), if the other host is > located outside our network. > > DSTM may be a good candidate. > > I only see NAT-PT useful if the host can't be upgraded to IPv6 (dual stack > actually) and the translation is simple and don't break anything, which may > be easy because old IPv4-only devices should not use non-translatable header > fields, BUT may be not the case also ;-) > > A very convenient alternative could be that the 4in6 tunneling for those > devices is done by the border device (IPv6 router of the network ?). I think > this will alleviate any need for NAT-PT. I'm missing any possible scenario > where this couldn't work ? > > Regards, > Jordi > > > >>De: "Soininen Jonne (Nokia-NET/Helsinki)" >>Responder a: owner-v6ops@ops.ietf.org >>Fecha: Wed, 20 Oct 2004 11:37:27 +0300 >>Para: "'V6OPS'" >>Asunto: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >> >>Hello, >> >>in Asia there seem to be emerging _large_ IPv6 only networks that may >>need some connectivity to the IPv4 Internet. Example of these is for >>instance is CNGI. They have been extensively looking for a NAT-PT type >>solution and are considering to use NAT-PT. I think we should have some >>sort of proposal what to do if we decide that NAT-PT is not the way to >>go. >> >>I wish the people that are involved in these projects would speak up and >>explain their requirements. >> >>Cheers, >> >>Jonne. >> >>On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote: >> >>>Soohong Daniel Park wrote: >>> >>>> Nevertheless, I know several sites are using NAT-PT efficiently on >>>> their use cases. >>> >>>It would be interesting, with the enterprise analysis in mind, to know >>>why these sites used NAT-PT, and what they could not solve in other ways. >>> >>>We used to run NAT-PT, but no longer do. >>> >>>As Pekka points out, we should also consider how IPv4 and IPv6 will be >>>adopted. IPv4 may remain the protocol to access legacy apps (like web, >>>mail, ftp). But these are also the ones that lend themselves to natural >>>proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). >>>IPv6 may become more popular for specific new applications, which do not >>>require access to IPv4 services, as Pekka is hinting. >>> >>>Suresh wrote: >>> >>>> As Senthil points out, the assumption that NAT-PT deployment will stifle >>>> innovation in v6 seems flawed. NAT-PT is a transition mechanism which is >>>> essential for wider V6 deployment. Without NAT-PT, you will see bigger >>>> resistance to deploying V6 . You need NAT-PT for legacy applications (ex: >>>> e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts >>>>or >>>> applications. This is the attraction of NAT-PT. This is not the same as the >>>> proxy solution that will require applications to be changed/recompiled. >>> >>>Proxies can be deployed transparently. SMTP naturally so, Web caches also, >>>there doesn't necessarily have to be any client side alterations. >>> >>>Tim >> >>-- >>Jonne Soininen >>Nokia >> >>Tel: +358 40 527 46 34 >>E-mail: jonne.soininen@nokia.com >> >> > > > > > ********************************** > Madrid 2003 Global IPv6 Summit > Presentations and videos on line at: > http://www.ipv6-es.com > > This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. > > > > From owner-v6ops@ops.ietf.org Wed Oct 20 10:31:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09062 for ; Wed, 20 Oct 2004 10:31:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKHUO-00018Z-LC for v6ops-data@psg.com; Wed, 20 Oct 2004 14:30:56 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKHUA-00017e-Ia for v6ops@ops.ietf.org; Wed, 20 Oct 2004 14:30:42 +0000 Received: from [10.10.10.102] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000514603.msg for ; Wed, 20 Oct 2004 16:35:46 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 20 Oct 2004 16:30:23 +0200 Subject: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <4176715C.2030606@zurich.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Spam-Processed: consulintel.es, Wed, 20 Oct 2004 16:35:46 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 20 Oct 2004 16:35:51 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Hi Brian, No at the time being. May be in the future, if there are interoperable implementations ;-) But my feeling is that it can be done in a much more simply way. Actually in our case all the users in the 5.000 sites are already "authenticated" so that will fall in the scope of the zeroconfiguration tunneling protocol that has been submitted yesterday to the ID editor. I will upload it somewhere else in case is not published already. Regards, Jordi > De: Brian E Carpenter > Organizaci=F3n: IBM > Responder a: owner-v6ops@ops.ietf.org > Fecha: Wed, 20 Oct 2004 16:08:28 +0200 > Para: jordi.palet@consulintel.es > CC: v6ops@ops.ietf.org > Asunto: Re: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >=20 > Jordi, are you using ayiya for this deployment? If so, what's > your experience? >=20 > Brian >=20 > JORDI PALET MARTINEZ wrote: >> Hi, >>=20 >> Agree, is better to heard the people that is doing that. >>=20 >> Probably I'm one of those ;-) >>=20 >> We are deploying networks for 5.000 IPv6 sites (not a joke !). At the time >> being dual stack, but the aim in a short term is to disable IPv4 from the >> access and core network. >>=20 >> As today we need still dual stack in the hosts because there may be some >> specific applications that could still be only IPv4, it seems to us that >> NAT-PT is a bad solution, as probably will fail for those applications, >> unless they are the typical HTTP applications, and in that case, we don't >> need NAT-PT (it can be done with a much more simple proxy !). >>=20 >> So looking for simplicity, we use a proxy for all the "old" IPv4 traffic, so >> in our network (core and access) we only see IPv6 as much as possible. >>=20 >> Alternatively for those applications that are still not ported, we use an >> automatic 4in6 tunneling mechanism from the "client" to the other host (if >> is located inside of our network), or from the client to the "border" of our >> network (the point where we connect to Internet), if the other host is >> located outside our network. >>=20 >> DSTM may be a good candidate. >>=20 >> I only see NAT-PT useful if the host can't be upgraded to IPv6 (dual stack >> actually) and the translation is simple and don't break anything, which may >> be easy because old IPv4-only devices should not use non-translatable header >> fields, BUT may be not the case also ;-) >>=20 >> A very convenient alternative could be that the 4in6 tunneling for those >> devices is done by the border device (IPv6 router of the network ?). I think >> this will alleviate any need for NAT-PT. I'm missing any possible scenario >> where this couldn't work ? >>=20 >> Regards, >> Jordi >>=20 >>=20 >>=20 >>> De: "Soininen Jonne (Nokia-NET/Helsinki)" >>> Responder a: owner-v6ops@ops.ietf.org >>> Fecha: Wed, 20 Oct 2004 11:37:27 +0300 >>> Para: "'V6OPS'" >>> Asunto: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >>>=20 >>> Hello, >>>=20 >>> in Asia there seem to be emerging _large_ IPv6 only networks that may >>> need some connectivity to the IPv4 Internet. Example of these is for >>> instance is CNGI. They have been extensively looking for a NAT-PT type >>> solution and are considering to use NAT-PT. I think we should have some >>> sort of proposal what to do if we decide that NAT-PT is not the way to >>> go.=20 >>>=20 >>> I wish the people that are involved in these projects would speak up and >>> explain their requirements. >>>=20 >>> Cheers, >>>=20 >>> Jonne. >>>=20 >>> On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote: >>>=20 >>>> Soohong Daniel Park wrote: >>>>=20 >>>>> Nevertheless, I know several sites are using NAT-PT efficiently on >>>>> their use cases. >>>>=20 >>>> It would be interesting, with the enterprise analysis in mind, to know >>>> why these sites used NAT-PT, and what they could not solve in other ways. >>>>=20 >>>> We used to run NAT-PT, but no longer do. >>>>=20 >>>> As Pekka points out, we should also consider how IPv4 and IPv6 will be >>>> adopted. IPv4 may remain the protocol to access legacy apps (like web, >>>> mail, ftp). But these are also the ones that lend themselves to natural >>>> proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). >>>> IPv6 may become more popular for specific new applications, which do not >>>> require access to IPv4 services, as Pekka is hinting. >>>>=20 >>>> Suresh wrote: >>>>=20 >>>>> As Senthil points out, the assumption that NAT-PT deployment will stifle >>>>> innovation in v6 seems flawed. NAT-PT is a transition mechanism which is >>>>> essential for wider V6 deployment. Without NAT-PT, you will see bigger >>>>> resistance to deploying V6 . You need NAT-PT for legacy applications (ex: >>>>> e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts >>>>> or >>>>> applications. This is the attraction of NAT-PT. This is not the same as >>>>> the >>>>> proxy solution that will require applications to be changed/recompiled. >>>>=20 >>>> Proxies can be deployed transparently. SMTP naturally so, Web caches also, >>>> there doesn't necessarily have to be any client side alterations. >>>>=20 >>>> Tim >>>=20 >>> --=20 >>> Jonne Soininen >>> Nokia >>>=20 >>> Tel: +358 40 527 46 34 >>> E-mail: jonne.soininen@nokia.com >>>=20 >>>=20 >>=20 >>=20 >>=20 >>=20 >> ********************************** >> Madrid 2003 Global IPv6 Summit >> Presentations and videos on line at: >> http://www.ipv6-es.com >>=20 >> This electronic message contains information which may be privileged or >> confidential. The information is intended to be for the use of the >> individual(s) named above. If you are not the intended recipient be aware >> that any disclosure, copying, distribution or use of the contents of this >> information, including attached files, is prohibited. >>=20 >>=20 >>=20 >>=20 >=20 >=20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Oct 20 11:27:00 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14506 for ; Wed, 20 Oct 2004 11:27:00 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKILF-0009MW-92 for v6ops-data@psg.com; Wed, 20 Oct 2004 15:25:33 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKILB-0009M7-Bd for v6ops@ops.ietf.org; Wed, 20 Oct 2004 15:25: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 i9KFPSGn025549 for ; Wed, 20 Oct 2004 16:25: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 QAA19421 for ; Wed, 20 Oct 2004 16:25:26 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9KFPQF23936 for v6ops@ops.ietf.org; Wed, 20 Oct 2004 16:25:26 +0100 Date: Wed, 20 Oct 2004 16:25:26 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: IPv6 renumbering draft Message-ID: <20041020152526.GW14932@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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, We have submitted a new draft on "Things to think about when Renumbering an IPv6 network", which complements Fred Baker's document on procedures for renumbering. The draft went in on Monday, but hasn't been announced. It is in the IETF repository though: http://www.ietf.org/internet-drafts/draft-chown-v6ops-renumber-thinkabout-00.txt Abstract This memo presents a summary of scenarios, issues for consideration and IPv6-specific tools for IPv6 network renumbering, i.e. achieving the transition from the use of an existing network prefix to a new prefix in an IPv6 network. Its focus lies not in the procedure for renumbering, but as a set of "things to think about" when undertaking such a renumbering exercise. The document is not intended to be complete at the -00 phase, and will be enhanced as further operational experience is gathered. Comments welcome. I will invite multi6-ers to comment here, if they so wish. Pekka - would it be possible to have a small slot at Washington to present it? -- Tim From owner-v6ops@ops.ietf.org Wed Oct 20 16:59:16 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25832 for ; Wed, 20 Oct 2004 16:59:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKNVX-00063E-CQ for v6ops-data@psg.com; Wed, 20 Oct 2004 20:56:31 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKNVM-000610-Rm for v6ops@ops.ietf.org; Wed, 20 Oct 2004 20:56:21 +0000 Received: from [10.10.10.102] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000515652.msg for ; Wed, 20 Oct 2004 23:01:22 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Wed, 20 Oct 2004 22:56:03 +0200 Subject: Zero-Configuration Tunneling Requirements From: JORDI PALET MARTINEZ To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Wed, 20 Oct 2004 23:01:22 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Wed, 20 Oct 2004 23:01:29 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, Zero-Configuration Tunneling Requirements was submitted a couple of days ago, is already in the RFC Editor, but still hasn't been announced ;-) You can already take a look at: http://www.ietf.org/internet-drafts/draft-suryanarayanan-v6ops-zeroconf-reqs -00.txt And provide comments ! Regards, Jordi ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Wed Oct 20 23:15:44 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA18923 for ; Wed, 20 Oct 2004 23:15:44 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKTNc-000Ah5-MR for v6ops-data@psg.com; Thu, 21 Oct 2004 03:12:44 +0000 Received: from [159.226.39.7] (helo=ict.ac.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CKTNb-000Agj-56 for v6ops@ops.ietf.org; Thu, 21 Oct 2004 03:12:43 +0000 Received: (qmail 6093 invoked by uid 507); 21 Oct 2004 02:48:21 -0000 Received: from unknown (HELO ThinkPadX31) (liumin@159.226.39.104) by ict.ac.cn with SMTP; 21 Oct 2004 02:48:21 -0000 From: "Liu Min" To: "'Soininen Jonne \(Nokia-NET/Helsinki\)'" , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Date: Thu, 21 Oct 2004 11:12:29 +0800 Message-ID: <000001c4b71b$cf895360$4b74a8c0@ThinkPadX31> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal In-Reply-To: <1098261447.4003.16.camel@essrv103nok14937.ntc.nokia.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable As far as I know, there will be a specific project to research and = develop high performance IPv4/IPv6 translation gateway in CNGI. Because there = are fewer IPv6 applications and resources than IPv4 in the current Internet, = it is difficult to persuade people to use IPv6.Most IPv6 users want to = access IPv4 resources. In order to spread IPv6, we must tell the users that = they can access all IPv4 resources. In addition, they can do what they can = not do by IPv4, such as p2p applications (Many people only have private IPv4 addresses).=20 =20 Best Wishes, =20 Liu Min =20 Institute of Computing Technology Chinese Academy of Sciences Tel: (86-10) 6256 5533-9240=20 E-mail: liumin@ict.ac.cn > -----Original Message----- > From: owner-v6ops@ops.ietf.org [mailto:owner-v6ops@ops.ietf.org] On = Behalf > Of Soininen Jonne (Nokia-NET/Helsinki) > Sent: Wednesday, October 20, 2004 4:37 PM > To: 'V6OPS' > Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt >=20 > Hello, >=20 > in Asia there seem to be emerging _large_ IPv6 only networks that may > need some connectivity to the IPv4 Internet. Example of these is for > instance is CNGI. They have been extensively looking for a NAT-PT type > solution and are considering to use NAT-PT. I think we should have = some > sort of proposal what to do if we decide that NAT-PT is not the way to > go. >=20 > I wish the people that are involved in these projects would speak up = and > explain their requirements. >=20 > Cheers, >=20 > Jonne. >=20 > On Fri, 2004-10-15 at 16:46, ext Tim Chown wrote: > > Soohong Daniel Park wrote: > > > > > > Nevertheless, I know several sites are using NAT-PT = efficiently on > > > their use cases. > > > > It would be interesting, with the enterprise analysis in mind, to = know > > why these sites used NAT-PT, and what they could not solve in other ways. > > > > We used to run NAT-PT, but no longer do. > > > > As Pekka points out, we should also consider how IPv4 and IPv6 will = be > > adopted. IPv4 may remain the protocol to access legacy apps (like = web, > > mail, ftp). But these are also the ones that lend themselves to = natural > > proxying (and sure FTP proxies are rare, but so are NAT-PT boxes :). > > IPv6 may become more popular for specific new applications, which do = not > > require access to IPv4 services, as Pekka is hinting. > > > > Suresh wrote: > > > As Senthil points out, the assumption that NAT-PT deployment will stifle > > > innovation in v6 seems flawed. NAT-PT is a transition mechanism = which is > > > essential for wider V6 deployment. Without NAT-PT, you will see bigger > > > resistance to deploying V6 . You need NAT-PT for legacy = applications (ex: > > > e-mail, ftp) to work as is across V4 and V6 realms. No change to end-hosts > or > > > applications. This is the attraction of NAT-PT. This is not the = same as > the > > > proxy solution that will require applications to be changed/recompiled. > > > > Proxies can be deployed transparently. SMTP naturally so, Web = caches also, > > there doesn't necessarily have to be any client side alterations. > > > > Tim > -- > Jonne Soininen > Nokia >=20 > Tel: +358 40 527 46 34 > E-mail: jonne.soininen@nokia.com From owner-v6ops@ops.ietf.org Thu Oct 21 00:26:25 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23560 for ; Thu, 21 Oct 2004 00:26:25 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKUVd-000Lvt-4r for v6ops-data@psg.com; Thu, 21 Oct 2004 04:25:05 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKUVb-000Luz-Rj for v6ops@ops.ietf.org; Thu, 21 Oct 2004 04:25:04 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9L4Oqq03317; Thu, 21 Oct 2004 07:24:52 +0300 Date: Thu, 21 Oct 2004 07:24:52 +0300 (EEST) From: Pekka Savola To: Liu Min cc: "'Soininen Jonne (Nokia-NET/Helsinki)'" , "'V6OPS'" Subject: RE: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-Reply-To: <000001c4b71b$cf895360$4b74a8c0@ThinkPadX31> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Oct 2004, Liu Min wrote: > As far as I know, there will be a specific project to research and develop > high performance IPv4/IPv6 translation gateway in CNGI. Because there are > fewer IPv6 applications and resources than IPv4 in the current Internet, it > is difficult to persuade people to use IPv6.Most IPv6 users want to access > IPv4 resources. In order to spread IPv6, we must tell the users that they > can access all IPv4 resources. In addition, they can do what they can not do > by IPv4, such as p2p applications (Many people only have private IPv4 > addresses). What I don't understand in your comment is why you implicitly assume that the IPv6 users would not have IPv4 access at all, and therefore their IPv6 access must be able to react all the IPv4 services. AFAICS, there is nothing stopping from deploying IPv4 w/ private addresses alongside with IPv6, and IPv6 could even be used dominantly in the network (if that's felt to be desirable for a political reasons, or to gain experience) if the typically used services such as HTTP, SMTP, DNS, etc. could be proxied by ALGs at the border. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From owner-v6ops@ops.ietf.org Thu Oct 21 02:35:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14507 for ; Thu, 21 Oct 2004 02:35:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKWW9-000F0Z-Ur for v6ops-data@psg.com; Thu, 21 Oct 2004 06:33:45 +0000 Received: from [195.30.1.100] (helo=moebius2.Space.Net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CKWW8-000F09-Mb for v6ops@ops.ietf.org; Thu, 21 Oct 2004 06:33:45 +0000 Received: (qmail 87102 invoked by uid 1007); 21 Oct 2004 06:33:43 -0000 Date: Thu, 21 Oct 2004 08:33:43 +0200 From: Gert Doering To: Pekka Savola Cc: Liu Min , "'Soininen Jonne \(Nokia-NET/Helsinki\)'" , "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt Message-ID: <20041021063343.GL55181@Space.Net> References: <000001c4b71b$cf895360$4b74a8c0@ThinkPadX31> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-NCC-RegID: de.space X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, On Thu, Oct 21, 2004 at 07:24:52AM +0300, Pekka Savola wrote: > AFAICS, there is nothing stopping from deploying IPv4 w/ private > addresses alongside with IPv6, and IPv6 could even be used dominantly > in the network (if that's felt to be desirable for a political > reasons, or to gain experience) if the typically used services such as > HTTP, SMTP, DNS, etc. could be proxied by ALGs at the border. I'm not sure if this is *better* than IPv6-only with NAT-PT at the border. If the network is large enough, the effort for maintaining IPv4 addresses and a dual-stack network infrastructure can be significantly higher than for an IPv6-only network. IPv4 with private addresses uses NAT, IPv6->IPv4 uses NAT-PT - both are evil, can't say one of them is "worse". Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 From owner-v6ops@ops.ietf.org Thu Oct 21 03:53:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18858 for ; Thu, 21 Oct 2004 03:53:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKXjz-000PzE-LJ for v6ops-data@psg.com; Thu, 21 Oct 2004 07:52:07 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKXjy-000Pyf-0d for v6ops@ops.ietf.org; Thu, 21 Oct 2004 07:52:06 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9L7pvQ07873; Thu, 21 Oct 2004 10:51:57 +0300 Date: Thu, 21 Oct 2004 10:51:57 +0300 (EEST) From: Pekka Savola To: Gert Doering cc: Liu Min , "'Soininen Jonne (Nokia-NET/Helsinki)'" , "'V6OPS'" Subject: Re: FW: I-D ACTION:draft-aoun-v6ops-natpt-deprecate-00.txt In-Reply-To: <20041021063343.GL55181@Space.Net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, 21 Oct 2004, Gert Doering wrote: > On Thu, Oct 21, 2004 at 07:24:52AM +0300, Pekka Savola wrote: > > AFAICS, there is nothing stopping from deploying IPv4 w/ private > > addresses alongside with IPv6, and IPv6 could even be used dominantly > > in the network (if that's felt to be desirable for a political > > reasons, or to gain experience) if the typically used services such as > > HTTP, SMTP, DNS, etc. could be proxied by ALGs at the border. > > I'm not sure if this is *better* than IPv6-only with NAT-PT at the border. > > If the network is large enough, the effort for maintaining IPv4 addresses > and a dual-stack network infrastructure can be significantly higher than > for an IPv6-only network. > > IPv4 with private addresses uses NAT, IPv6->IPv4 uses NAT-PT - both are > evil, can't say one of them is "worse". That's a valid argument, though I'd be interested in hearing more detailed analysis on the actual amount of added maintenance due to [private] v4. [I also argue that you'll have to waste more energy trying to get things to work completely in a v6-only environment than just running v4 where needed.] However, my main argument in this kind of situation is that we might not want to proliferate the v4 NAT behaviour to v6->v4 NAT behaviour. As soon as we start doing NAT-PT people that are using IPv6-ony start expecting that their applications will work through the NAT-PT. For example, their peer-to-peer application. This results in either a LOT of code in NAT-PT, and/or a lot of code in the applications. (This is discussed a bit in the nat-pt deprecation draft.) And what I'd like to avoid is requiring IPv6 applications to deal with NATs. But if we do NAT-PT and the like, that seems inevitable and a major benefit of IPv6 applications goes away. Hence, I think there is some weight in trying to keep IPv6 free of generic translators such as NAT-PT, or IPv6 NAT which would break some applications. (Application proxies are already designed with those applications in mind, so those are OK.) -- 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 Oct 21 13:32:17 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26223 for ; Thu, 21 Oct 2004 13:32:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKglE-0008An-S3 for v6ops-data@psg.com; Thu, 21 Oct 2004 17:30:00 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKglC-0008AJ-SX for v6ops@ops.ietf.org; Thu, 21 Oct 2004 17:29:59 +0000 Received: from [10.0.0.112] by consulintel.es (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000518923.msg for ; Thu, 21 Oct 2004 19:35:03 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Thu, 21 Oct 2004 19:29:45 +0200 Subject: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Thu, 21 Oct 2004 19:35:03 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 10.0.0.112 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, 21 Oct 2004 19:35:08 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, Sorry, too busy the last days ;-) Thanks a lot for your comments. See my comments in-line below. Regards, Jordi > De: Pekka Savola > Responder a: owner-v6ops@ops.ietf.org > Fecha: Mon, 18 Oct 2004 09:41:13 +0300 (EEST) > Para: v6ops@ops.ietf.org > Asunto: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt > > Hi, > > A couple of comments on > draft-palet-v6ops-solution-tun-auto-disc-00.txt. In short, this seems > like a start in narrowing down the list of methods given in > draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems > with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-), Our view is that if we want a resilience solution, we need some complementarily between DNS and anycast. It can be done just with DNS, but then it will work only within the ISP. In our opinion we need a solution that works also outside the "customer" ISP. > and 2) the draft doesn't sufficiently describe the > mechanism/protocol/implementation requirements, and how those > interoperate with whatever the ISPs would deploy. I'm not sure what do you mean here, but providing more details about DNS SRV RR and anycast seems to us out of the scope of this document. There are no _new_ requirements for the ISP, neither the client, because we are using existing mechanism (DNS and anycast). > > substantial > ----------- > > 1) the most fundamental issue I see with this draft builds on text in > section 4 about what is the mandatory-to-implement mechanism and what is > not. That's important. > > There are two perspectives here: 'mandatory to implement' in the specific > service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy' > in the ISP. > > I think you've only focused on what the ISP should deploy. You'll also need > to discuss what should be mandatory to implement in the > protocols/mechanisms, because this is where interop problems happen. I think you're missing somehow the point. We are trying to do in such way that no modification is required for the existing transition mechanisms. Instead, the Operating System will require to replace the actual defaults for the TEPs (6to4, Teredo, etc.), which the name to be defined by IANA as part of the process of getting this document further. > > (I.e., I think the document too much deployment-centric, not focusing > sufficiently on what must be implemented and how that would operate with > different modes of deployment.) > > My fundamental concern is that if you say "ISP can implement any of the > proposed approaches, or preferably all of them", that means that for a > mechanism to be interoperable with what the ISPs are offering, the > mechanisms/protocols would need to implement EVERYTHING. > > And that seems like a potentially bad tradeoff to me. The fewer > autodiscovery mechanisms there are, the fewer combinations there are that > something would not work. > > For example, if we just specified DNS lookup in a certain way, the ISP would > only have one way to deploy it and the mechanism one way to implement it, > and interoperability would be guaranteed. > > "Less is more" ;-). The current draft is IMHO not a clear solution. It's a > "kitchen sink" description of best solutions, which may or may not work > together, and it may or may not be possible to get a well-interoperable > mechanism out of it. I'd try to narrow down the number of different > discovery mechanisms used as much as possible. We are using a single name for each protocol, so whatever is implemented in the ISP, will work for the client. I think this provides complete interoperability ! > > 2. Section 5.4 seems to be proposing using dual-faced DNS towards the > Internet vs own customers to control the visibility of the TEP addresses in > the DNS. This seems completely wrong direction to take, because the > addresses will still be available even if they are not made available in the > public DNS. > > The last paragraph says it all: it would be much better to forget about > dual-faced DNS completely in this context, and just perform filtering for > the service. It offers complete solution to the "theft-of-service" > problems, and is easier and more correct way to deploy to boot. > > So, please remove dual-faced DNS, unless there are some very strong unstated > assumptions what benefits it gives instead of just filtering (and state > them). > Our intend here is to offer two options: 1) No service at all outside the ISP (then filtering will make it) 2) An ISP that offers services (some, may be not the same) to users outside its own network. I think this is a possibility and we must support it in a clear way, in case somebody want to make use of it. We can further clarify it in the document probably (working on a new version right now). > 3. In section 7, you mention alternative DHCP-based solution. Because the > people not familiar with the tun-auto-disc background will first ask "why > not just use DHCPv4 and forget about everything else?", this section > probably needs to include much better justification (to be gathered from > the tun-auto-disc document, for example) why it's not the main proposal. We wanted to avoid duplicating text from the requirements document ;-) > > Heck, it might even make sense to put some text, or at least referral to > section 7, in the introduction. Ok. Will do it. > > > semi-substantial > ---------------- > > On the other hand, shared anycast is also a very useful approach > since it can globally identify a specific service (TEP or transition > mechanism). > > ==> I think you're assuming that anycast (shared-unicast) would be allocated > an interdomain range, because otherwise it can't be globally identified. > This doesn't need to be the case. Our intend is to use the same prefix as for 6to4, for all the mechanisms (so we can allocate for example up to 254 new mechanisms, more than enough). > > For example the records for 6in4, tsp, teredo, isatap and 6to4 would > result: 6in4_srv.ispname.com, tsp_srv.ispname.com, > teredo_srv.ispname.com, isatap_srv.ispname.com, 6to4_srv.ispname.com, > etc. > > ==> you forgot the protocol (_tcp, _udp, etc.) which you had in the examples > below? Yes, we discovered already after sending the draft, that was a mistake forgetting the protocol sequence. > > Also, did you find a source where "_ipv4" protocol comes from? Is there an > example of this being used somewhere, or did you just make it up? :-) In the SRV RR description is not indicated that ipv4 could be used, but is also not explicitly excluded, so should be an option. In fact, if the mechanism is used for autodiscovering IPv6 TEPs (when you want to tunnel 4in6, for example), it will be possible to use ipv6. Actually, anyway, all them are possible examples, and in the case of TSP, it could be also _udp, _ipv4, _ipv6, etc. > > Note: The use of the underscore character minimizes the probability > of conflict with DNS names already defined. > > ==> this belongs at the end of section 3.2, rather than at the end of 3.3, > or..? > Actually this belongs to the complete section 3. > To do that, the ISP's domain name is essential for prefixing the DNS > search path, so the client (or rather the operating system) firstly > learns the domain name of the ISP. There are several ways to do it, > but in general it will be learned by making NS RR queries to the DNS. > > ==> You have assumptions in the last sentence, that the user looks up the IP > address and its corresponding NS records to get the domain name. That's > certainly one approach. But as currently deployed, folks just depend on the > DNS search path. So, I think the last sentence needs to be expanded or > removed. > We are not referring to the IP address, but to the search path, as you say, so ? > the client (rather the operating system) > makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN, > and QTYPE=A or QTYPE=CNAME. > > ==> which QTYPE is it? Are you saying the implementations need to query > both? That's not good. Note that if you do a QTYPE=A query, that should > also match CNAME and give the A record in the answer section, so there is no > need to query CNAME explicitly. Try e.g. 'dig aaaa ftp.ipv6.funet.fi'. > No, just query one of both, the one the OS prefers ;-) > > > editorial > --------- > > 4. It is topologically correct: Provides the nearest TEP to the user > in terms of hops. > > ==> for the sake of clarify, please expand 'hops'. > IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6). > However anycast routes not always are well configured and stable, so > connection with the server belonging to an anycast group could not be > always possible, which means that is not necessarily the most > topologically correct. > > ==> s/could/might/ ? Ok. > > The DNS will redirect to a TEP (or alternatively a TB > more sophistication is required) located within the ISP or a third > party (other near ISP, roaming TEP service, etc.) > > ==> s/TB/TB if/ ? Right. > > The solution consequently, makes use of existing protocols, not > requiring modifications or any new protocol. > > ==> remove ','. Ok. > > When looking for a specific TEP within the ISP the user belongs to, > the first step is always the same because the user does not know (and > neither has to know) which is the transition mechanism deployment > status within its ISP, so the user always query firstly for a DNS SRV > RR to its ISP DNS server. > > ==> you say 'user', but you probably referred to the application/stack ? Right. > > the ISP DNS server. To discover the specific TEP within the ISPb@Ys > > ==> some corrupted chars around 'ISP'. Ok. > > It is also possible that > ISPs are interested to offer IPv6 transition mechanisms by means of > third party agreements or even through well know and convenient near > TEPs which are for free. > > ==> some rewording near the end.. Will reword. > > This section list de transition mechanisms and the service names to > > ==> s/list de/lists the/ ? Some Spanglish went there by mistake ;-) Should be "list the" > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Thu Oct 21 15:54:10 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13502 for ; Thu, 21 Oct 2004 15:54:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKizQ-0005DG-Tz for v6ops-data@psg.com; Thu, 21 Oct 2004 19:52:48 +0000 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKizQ-0005Cs-0q for v6ops@ops.ietf.org; Thu, 21 Oct 2004 19:52:48 +0000 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 21 Oct 2004 15:52:48 -0400 X-BrightmailFiltered: true Received: from fruitpie.cisco.com (IDENT:mirapoint@fruitpie.cisco.com [64.102.16.27]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id i9LJqi7K025147; Thu, 21 Oct 2004 15:52:45 -0400 (EDT) Received: from CPOPOVIC-W2K1.cisco.com (dhcp-64-102-39-109.cisco.com [64.102.39.109]) by fruitpie.cisco.com (MOS 3.4.6-GR) with ESMTP id BCV72697; Thu, 21 Oct 2004 12:52:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20041021152613.0257d200@fruitpie.cisco.com> X-Sender: cpopovic@fruitpie.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 21 Oct 2004 15:46:51 -0400 To: v6ops@ops.ietf.org From: Ciprian Popoviciu Subject: ISP IPv6 Deployment Scenarios in Broadband Access Cc: Salman Asadullah , adeel Ahmed Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello! We integrated the feedback received on the first version of the "ISP IPv6 Deployment Scenarios in Broadband Access" draft and posted the updated document. You can also find it at: http://www.netcore.fi/pekkas/ietf/temp/draft-asadullah-v6ops-bb-deployment-scenarios-01.txt We would like to thank Brian Carpenter, Patrick Grossetete, Benoit Lourdelet, Tschofenig Hannes, Gert Doering, Alexander Koch for their feedback and particularly Pekka for all his help along with his feedback. Feedback on this iteration will be most welcomed! Thank you! Chip From owner-v6ops@ops.ietf.org Fri Oct 22 02:51:39 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA04896 for ; Fri, 22 Oct 2004 02:51:38 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CKtEG-000NyU-R2 for v6ops-data@psg.com; Fri, 22 Oct 2004 06:48:48 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CKtEF-000Ny0-0X for v6ops@ops.ietf.org; Fri, 22 Oct 2004 06:48:47 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9M6mgU08882; Fri, 22 Oct 2004 09:48:42 +0300 Date: Fri, 22 Oct 2004 09:48:42 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk in-line, On Thu, 21 Oct 2004, JORDI PALET MARTINEZ wrote: > > A couple of comments on > > draft-palet-v6ops-solution-tun-auto-disc-00.txt. In short, this seems > > like a start in narrowing down the list of methods given in > > draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems > > with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-), > > Our view is that if we want a resilience solution, we need some > complementarily between DNS and anycast. It can be done just with DNS, but > then it will work only within the ISP. > > In our opinion we need a solution that works also outside the "customer" > ISP. There are a lot of nuances to 'working outside the "customer" ISP', for example: Does the solution have to support complete 3rd parties, such as anycasting 6to4 relays now? (Remember that 6to4 relays are stateless, while the tunnel servers typically aren't, and this would cause additional implications on the mechanisms.) Does the solution have to support those customers which momentarily roam outside of their ISP's access network? [E.g., as solution based on DNS records would probably still be at least partially applicable here] I'm concerned that because there is significantly smaller amount of incentive, and more technical challenges, for ISPs to deploy an inter-domain anycast solution for tunnel servers, so that it would not be actually usable for discovery. > > and 2) the draft doesn't sufficiently describe the > > mechanism/protocol/implementation requirements, and how those > > interoperate with whatever the ISPs would deploy. > > I'm not sure what do you mean here, but providing more details about DNS SRV > RR and anycast seems to us out of the scope of this document. There are no > _new_ requirements for the ISP, neither the client, because we are using > existing mechanism (DNS and anycast). No, I didn't mean that, but rather what mechanisms must be implemented in the mechanism or the host stack. I'll try to explain below. > > substantial > > ----------- > > > > 1) the most fundamental issue I see with this draft builds on text in > > section 4 about what is the mandatory-to-implement mechanism and what is > > not. That's important. > > > > There are two perspectives here: 'mandatory to implement' in the specific > > service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy' > > in the ISP. > > > > I think you've only focused on what the ISP should deploy. You'll also need > > to discuss what should be mandatory to implement in the > > protocols/mechanisms, because this is where interop problems happen. > > I think you're missing somehow the point. We are trying to do in such way > that no modification is required for the existing transition mechanisms. > Instead, the Operating System will require to replace the actual defaults > for the TEPs (6to4, Teredo, etc.), which the name to be defined by IANA as > part of the process of getting this document further. Maybe I did not write clearly enough, without assumptions. Whether or not this discovery process is done in the host stack, or the transition mechanism, is relatively irrelevant. However, it is VERY MUCH relevant to this draft WHAT must be implemented in the host stack or the mechanism to make these work. For example, if the host would just implement DNS lookups and the ISP just anycast, discovery process should fail. So, when there are multiple mechanisms, one must specify what is the mandatory-to-implement part of them, and how different combinations of support in the stack/mechanism interoperate with different combinations of support in the ISP. > > For example, if we just specified DNS lookup in a certain way, the ISP would > > only have one way to deploy it and the mechanism one way to implement it, > > and interoperability would be guaranteed. > > > > "Less is more" ;-). The current draft is IMHO not a clear solution. It's a > > "kitchen sink" description of best solutions, which may or may not work > > together, and it may or may not be possible to get a well-interoperable > > mechanism out of it. I'd try to narrow down the number of different > > discovery mechanisms used as much as possible. > > We are using a single name for each protocol, so whatever is implemented in > the ISP, will work for the client. I think this provides complete > interoperability ! Yes, but you also specify the inter-domain anycast in addition to DNS lookups using SRV or A records. Which ones must be supported in the client? Which ones in the ISP? There are probably half a dozen non-interoperable combinations here. Maybe your implicit assumption is that the client supports all of them: interdomain anycast, DNS with SRV, and DNS with A records, and maybe even DHCP to the boot -- and tries them in some particular order, and then it would just depend on what the ISP supports. I don't have that assumption. On the contrary, I think there must be a minimal set of approaches so that 1) very little is required to implement & deploy, and 2) there are as few interop problems as possible. > > 2. Section 5.4 seems to be proposing using dual-faced DNS towards the > > Internet vs own customers to control the visibility of the TEP addresses in > > the DNS. This seems completely wrong direction to take, because the > > addresses will still be available even if they are not made available in the > > public DNS. > > > > The last paragraph says it all: it would be much better to forget about > > dual-faced DNS completely in this context, and just perform filtering for > > the service. It offers complete solution to the "theft-of-service" > > problems, and is easier and more correct way to deploy to boot. > > > > So, please remove dual-faced DNS, unless there are some very strong unstated > > assumptions what benefits it gives instead of just filtering (and state > > them). > > Our intend here is to offer two options: > 1) No service at all outside the ISP (then filtering will make it) > 2) An ISP that offers services (some, may be not the same) to users outside > its own network. I think this is a possibility and we must support it in a > clear way, in case somebody want to make use of it. I can understand these options, but AFAIK dual-faced DNS does not offer any better means to achieve 2), while being a lot worse. Sure, you can hide the tunnel endpoint (so that it can only be looked up in the local net) and still keep it operational if you move away from the network, but that allows a lot of abuse (such as local customers telling their friends outside the IP address to use for their tunnels). Doing dual-faced DNS here would be security by obscurity and that would not be good. The only practical solution to the 3rd party case appears to be some form of registered mode, i.e., the tunnel endpoint being accessible to anyone, but only allowing certain registered users. > > 3. In section 7, you mention alternative DHCP-based solution. Because the > > people not familiar with the tun-auto-disc background will first ask "why > > not just use DHCPv4 and forget about everything else?", this section > > probably needs to include much better justification (to be gathered from > > the tun-auto-disc document, for example) why it's not the main proposal. > > We wanted to avoid duplicating text from the requirements document ;-) Worthy goal, but something DHCP proponents will jump on :-) > > semi-substantial > > ---------------- > > > > On the other hand, shared anycast is also a very useful approach > > since it can globally identify a specific service (TEP or transition > > mechanism). > > > > ==> I think you're assuming that anycast (shared-unicast) would be allocated > > an interdomain range, because otherwise it can't be globally identified. > > This doesn't need to be the case. > > Our intend is to use the same prefix as for 6to4, for all the mechanisms (so > we can allocate for example up to 254 new mechanisms, more than enough). Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for X, .101.0/24 for Y, etc. The former would definitely not work. > > Also, did you find a source where "_ipv4" protocol comes from? Is there an > > example of this being used somewhere, or did you just make it up? :-) > > In the SRV RR description is not indicated that ipv4 could be used, but is > also not explicitly excluded, so should be an option. In fact, if the > mechanism is used for autodiscovering IPv6 TEPs (when you want to tunnel > 4in6, for example), it will be possible to use ipv6. > > Actually, anyway, all them are possible examples, and in the case of TSP, it > could be also _udp, _ipv4, _ipv6, etc. OK, it seems that the SRV spec does not allocate a namespace for "protocol values" such as _tcp, so if something else than _udp or _tcp are used, they just need to be made up in such a manner that they don't conflict. > > To do that, the ISP's domain name is essential for prefixing the DNS > > search path, so the client (or rather the operating system) firstly > > learns the domain name of the ISP. There are several ways to do it, > > but in general it will be learned by making NS RR queries to the DNS. > > > > ==> You have assumptions in the last sentence, that the user looks up the IP > > address and its corresponding NS records to get the domain name. That's > > certainly one approach. But as currently deployed, folks just depend on the > > DNS search path. So, I think the last sentence needs to be expanded or > > removed. > > We are not referring to the IP address, but to the search path, as you say, > so ? If you have the search path, you don't need to make a NS RR query. NS RR query would only be needed if you wanted to look up the responsible party for your IP address. I couldn't figure out why you mentioned 'NS RR' there, so I made some conclusions. I think the above is clarified if you remove or reword the text around NS RRs. > > the client (rather the operating system) > > makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN, > > and QTYPE=A or QTYPE=CNAME. > > > > ==> which QTYPE is it? Are you saying the implementations need to query > > both? That's not good. Note that if you do a QTYPE=A query, that should > > also match CNAME and give the A record in the answer section, so there is no > > need to query CNAME explicitly. Try e.g. 'dig aaaa ftp.ipv6.funet.fi'. > > No, just query one of both, the one the OS prefers ;-) Uhh, you need to specify better what to do so that it can be done in an interoperable manner. Or if you specify you have to query both, that's OK too, but causes significant issues because it takes additional packets and additional latency. > > editorial > > --------- > > > > 4. It is topologically correct: Provides the nearest TEP to the user > > in terms of hops. > > > > ==> for the sake of clarify, please expand 'hops'. > > IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6). Yes, so s/hops/IP hops/ -- 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 Oct 22 16:13:02 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06597 for ; Fri, 22 Oct 2004 16:13:02 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CL5kf-0004e3-R5 for v6ops-data@psg.com; Fri, 22 Oct 2004 20:11:05 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CL5ke-0004dk-PY for v6ops@ops.ietf.org; Fri, 22 Oct 2004 20:11:05 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06306; Fri, 22 Oct 2004 16:11:03 -0400 (EDT) Message-Id: <200410222011.QAA06306@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-assisted-tunneling-requirements-01.txt Date: Fri, 22 Oct 2004 16:11:02 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Goals for Registered Assisted Tunneling Author(s) : F. Parent, et al. Filename : draft-ietf-v6ops-assisted-tunneling-requirements-01.txt Pages : 14 Date : 2004-10-22 This document defines requirements for a tunnel set-up protocol that could be used by an ISP to jumpstart its IPv6 offering to its customers by providing them IPv6 connectivity through tunneling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-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-assisted-tunneling-requirements-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-assisted-tunneling-requirements-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: <2004-10-22162006.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-assisted-tunneling-requirements-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-assisted-tunneling-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-22162006.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Sun Oct 24 12:48:28 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11600 for ; Sun, 24 Oct 2004 12:48:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLlVA-0009yD-4Z for v6ops-data@psg.com; Sun, 24 Oct 2004 16:45:52 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLlV8-0009wN-2H for v6ops@ops.ietf.org; Sun, 24 Oct 2004 16:45:50 +0000 Received: from [10.10.10.102] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000524998.msg for ; Sun, 24 Oct 2004 18:51:03 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Sun, 24 Oct 2004 18:45:40 +0200 Subject: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Sun, 24 Oct 2004 18:51:03 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Sun, 24 Oct 2004 18:51:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi Pekka, My comment in-line below. Regards, Jordi > De: Pekka Savola > Responder a: owner-v6ops@ops.ietf.org > Fecha: Fri, 22 Oct 2004 09:48:42 +0300 (EEST) > Para: JORDI PALET MARTINEZ > CC: v6ops@ops.ietf.org > Asunto: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt > > in-line, > > On Thu, 21 Oct 2004, JORDI PALET MARTINEZ wrote: >>> A couple of comments on >>> draft-palet-v6ops-solution-tun-auto-disc-00.txt. In short, this seems >>> like a start in narrowing down the list of methods given in >>> draft-palet-v6ops-tun-auto-disc-01.txt, but there are two problems >>> with this: 1) IMHO it isn't yet sufficiently far narrowed down ;-), >> >> Our view is that if we want a resilience solution, we need some >> complementarily between DNS and anycast. It can be done just with DNS, but >> then it will work only within the ISP. >> >> In our opinion we need a solution that works also outside the "customer" >> ISP. > > There are a lot of nuances to 'working outside the "customer" ISP', > for example: > > Does the solution have to support complete 3rd parties, such as > anycasting 6to4 relays now? (Remember that 6to4 relays are stateless, > while the tunnel servers typically aren't, and this would cause > additional implications on the mechanisms.) As explained in the Case Studies section, is up to each ISP to decide if they want to support external users or not. > > Does the solution have to support those customers which momentarily > roam outside of their ISP's access network? [E.g., as solution based > on DNS records would probably still be at least partially applicable > here] From the users point of view, yes. Of course, users always need to rely into available services, but if we don't provide this part of the solution, they will never have it. Providing it, they might have it (up to the providers, even if a few that with to provide the service). > > I'm concerned that because there is significantly smaller amount of > incentive, and more technical challenges, for ISPs to deploy an > inter-domain anycast solution for tunnel servers, so that it would not > be actually usable for discovery. I don't agree, 6to4 is working, and we are just extending the applicability of 6to4 to other mechanisms. > >>> and 2) the draft doesn't sufficiently describe the >>> mechanism/protocol/implementation requirements, and how those >>> interoperate with whatever the ISPs would deploy. >> >> I'm not sure what do you mean here, but providing more details about DNS SRV >> RR and anycast seems to us out of the scope of this document. There are no >> _new_ requirements for the ISP, neither the client, because we are using >> existing mechanism (DNS and anycast). > > No, I didn't mean that, but rather what mechanisms must be implemented > in the mechanism or the host stack. I'll try to explain below. Ok. We can work on that in a new section, with concrete examples for different mechanisms. > >>> substantial >>> ----------- >>> >>> 1) the most fundamental issue I see with this draft builds on text in >>> section 4 about what is the mandatory-to-implement mechanism and what is >>> not. That's important. >>> >>> There are two perspectives here: 'mandatory to implement' in the specific >>> service (e.g., 6to4, TSP, Teredo, ISATAP, etc.), and 'mandatory to deploy' >>> in the ISP. >>> >>> I think you've only focused on what the ISP should deploy. You'll also need >>> to discuss what should be mandatory to implement in the >>> protocols/mechanisms, because this is where interop problems happen. >> >> I think you're missing somehow the point. We are trying to do in such way >> that no modification is required for the existing transition mechanisms. >> Instead, the Operating System will require to replace the actual defaults >> for the TEPs (6to4, Teredo, etc.), which the name to be defined by IANA as >> part of the process of getting this document further. > > Maybe I did not write clearly enough, without assumptions. > > Whether or not this discovery process is done in the host stack, or > the transition mechanism, is relatively irrelevant. > > However, it is VERY MUCH relevant to this draft WHAT must be > implemented in the host stack or the mechanism to make these work. > > For example, if the host would just implement DNS lookups and the ISP > just anycast, discovery process should fail. Understood now. The client must implement the complete picture, but not the server. I'm about to finish an updated version of the document, and will make sure this is clear. > > So, when there are multiple mechanisms, one must specify what is the > mandatory-to-implement part of them, and how different combinations of > support in the stack/mechanism interoperate with different > combinations of support in the ISP. > >>> For example, if we just specified DNS lookup in a certain way, the ISP would >>> only have one way to deploy it and the mechanism one way to implement it, >>> and interoperability would be guaranteed. >>> >>> "Less is more" ;-). The current draft is IMHO not a clear solution. It's a >>> "kitchen sink" description of best solutions, which may or may not work >>> together, and it may or may not be possible to get a well-interoperable >>> mechanism out of it. I'd try to narrow down the number of different >>> discovery mechanisms used as much as possible. >> >> We are using a single name for each protocol, so whatever is implemented in >> the ISP, will work for the client. I think this provides complete >> interoperability ! > > Yes, but you also specify the inter-domain anycast in addition to DNS > lookups using SRV or A records. > > Which ones must be supported in the client? Which ones in the ISP? > There are probably half a dozen non-interoperable combinations here. > > Maybe your implicit assumption is that the client supports all of > them: interdomain anycast, DNS with SRV, and DNS with A records, and > maybe even DHCP to the boot -- and tries them in some particular > order, and then it would just depend on what the ISP supports. > > I don't have that assumption. On the contrary, I think there must be > a minimal set of approaches so that 1) very little is required to > implement & deploy, and 2) there are as few interop problems as > possible. My point of view is that both the ability to resolve SRV/A and anycast are already available today in all the clients, so making both as part of the requirement, will not add actually any new requirements. I'm not considering DHCP at all. May be need to be further clarified. Is one more option, but more related, in my opinion, to very controlled networks where you are sure that DHCP options are relayed. We can even delete this section if it creates confusion. Thoughts from the WG well be needed here ! > >>> 2. Section 5.4 seems to be proposing using dual-faced DNS towards the >>> Internet vs own customers to control the visibility of the TEP addresses in >>> the DNS. This seems completely wrong direction to take, because the >>> addresses will still be available even if they are not made available in the >>> public DNS. >>> >>> The last paragraph says it all: it would be much better to forget about >>> dual-faced DNS completely in this context, and just perform filtering for >>> the service. It offers complete solution to the "theft-of-service" >>> problems, and is easier and more correct way to deploy to boot. >>> >>> So, please remove dual-faced DNS, unless there are some very strong unstated >>> assumptions what benefits it gives instead of just filtering (and state >>> them). >> >> Our intend here is to offer two options: >> 1) No service at all outside the ISP (then filtering will make it) >> 2) An ISP that offers services (some, may be not the same) to users outside >> its own network. I think this is a possibility and we must support it in a >> clear way, in case somebody want to make use of it. > > I can understand these options, but AFAIK dual-faced DNS does not > offer any better means to achieve 2), while being a lot worse. Sure, > you can hide the tunnel endpoint (so that it can only be looked up in > the local net) and still keep it operational if you move away from the > network, but that allows a lot of abuse (such as local customers > telling their friends outside the IP address to use for their > tunnels). Doing dual-faced DNS here would be security by obscurity > and that would not be good. > > The only practical solution to the 3rd party case appears to be some > form of registered mode, i.e., the tunnel endpoint being accessible to > anyone, but only allowing certain registered users. I'm not really sure about this point of view. Need to think about it. More opinions from the WG, please ? > >>> 3. In section 7, you mention alternative DHCP-based solution. Because the >>> people not familiar with the tun-auto-disc background will first ask "why >>> not just use DHCPv4 and forget about everything else?", this section >>> probably needs to include much better justification (to be gathered from >>> the tun-auto-disc document, for example) why it's not the main proposal. >> >> We wanted to avoid duplicating text from the requirements document ;-) > > Worthy goal, but something DHCP proponents will jump on :-) Ok. Now this will depend on what the people think about keeping the DHCP solution in the document or not ... > >>> semi-substantial >>> ---------------- >>> >>> On the other hand, shared anycast is also a very useful approach >>> since it can globally identify a specific service (TEP or transition >>> mechanism). >>> >>> ==> I think you're assuming that anycast (shared-unicast) would be allocated >>> an interdomain range, because otherwise it can't be globally identified. >>> This doesn't need to be the case. >> >> Our intend is to use the same prefix as for 6to4, for all the mechanisms (so >> we can allocate for example up to 254 new mechanisms, more than enough). > > Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for > Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for > X, .101.0/24 for Y, etc. > > The former would definitely not work. You're right. I was actually thinking in the option that you describe in first place, but I now realize that precisely because that problem, we use a prefix for 6to4, instead of just one address. So need to double-check if we need to move to the 2nd way, or there is an alternative. > >>> Also, did you find a source where "_ipv4" protocol comes from? Is there an >>> example of this being used somewhere, or did you just make it up? :-) >> >> In the SRV RR description is not indicated that ipv4 could be used, but is >> also not explicitly excluded, so should be an option. In fact, if the >> mechanism is used for autodiscovering IPv6 TEPs (when you want to tunnel >> 4in6, for example), it will be possible to use ipv6. >> >> Actually, anyway, all them are possible examples, and in the case of TSP, it >> could be also _udp, _ipv4, _ipv6, etc. > > OK, it seems that the SRV spec does not allocate a namespace for > "protocol values" such as _tcp, so if something else than _udp or _tcp > are used, they just need to be made up in such a manner that they > don't conflict. > >>> To do that, the ISP's domain name is essential for prefixing the DNS >>> search path, so the client (or rather the operating system) firstly >>> learns the domain name of the ISP. There are several ways to do it, >>> but in general it will be learned by making NS RR queries to the DNS. >>> >>> ==> You have assumptions in the last sentence, that the user looks up the IP >>> address and its corresponding NS records to get the domain name. That's >>> certainly one approach. But as currently deployed, folks just depend on the >>> DNS search path. So, I think the last sentence needs to be expanded or >>> removed. >> >> We are not referring to the IP address, but to the search path, as you say, >> so ? > > If you have the search path, you don't need to make a NS RR query. > NS RR query would only be needed if you wanted to look up the > responsible party for your IP address. > > I couldn't figure out why you mentioned 'NS RR' there, so I made some > conclusions. I think the above is clarified if you remove or reword > the text around NS RRs. > Ok, need to double-check and/or will do that. >>> the client (rather the operating system) >>> makes a DNS query [6][7] for QNAME=teredo_srv.ispname.com, QCLASS=IN, >>> and QTYPE=A or QTYPE=CNAME. >>> >>> ==> which QTYPE is it? Are you saying the implementations need to query >>> both? That's not good. Note that if you do a QTYPE=A query, that should >>> also match CNAME and give the A record in the answer section, so there is no >>> need to query CNAME explicitly. Try e.g. 'dig aaaa ftp.ipv6.funet.fi'. >> >> No, just query one of both, the one the OS prefers ;-) > > Uhh, you need to specify better what to do so that it can be done in > an interoperable manner. Or if you specify you have to query both, > that's OK too, but causes significant issues because it takes > additional packets and additional latency. Yes, you're right. I guess it will be simple to stick to A, if we care so much about the extra packets. WG opinion ? > >>> editorial >>> --------- >>> >>> 4. It is topologically correct: Provides the nearest TEP to the user >>> in terms of hops. >>> >>> ==> for the sake of clarify, please expand 'hops'. >> >> IPv4 hops if looking for an IPv4 TEP (to gain access to IPv6). > > Yes, so s/hops/IP hops/ Ok. > > -- > Pekka Savola "You each name yourselves king, yet the > Netcore Oy kingdom bleeds." > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings > > > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Sun Oct 24 21:08:47 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15178 for ; Sun, 24 Oct 2004 21:08:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLtJP-000G09-15 for v6ops-data@psg.com; Mon, 25 Oct 2004 01:06:15 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLtJN-000FzQ-LK for v6ops@ops.ietf.org; Mon, 25 Oct 2004 01:06:14 +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 i9P16AGn025174 for ; Mon, 25 Oct 2004 02:06:10 +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 CAA12432 for ; Mon, 25 Oct 2004 02:06:08 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9P168k17642 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 02:06:08 +0100 Date: Mon, 25 Oct 2004 02:06:08 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041025010608.GR9200@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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 11, 2004 at 09:25:38PM +0300, Heikki Vatiainen wrote: > > I think dual stack has been available long enough that the potential > for disturbance is not great enough to justify a parallel > infrasturcture for IPv6. In fact, I would recommend that parallel > infrasturcture is only built if no other options, such as upgrading to > dual stack routers, are available. Hi Heikki, I think this is made clear in 4.2 and 4.3? > The parallel infrastructure forces you to have two times the > documentation about the network. If e.g. intra-organization packet > filtering is done, you have to literally think and check twice that > the filters are set up as required. With dual stack you may need to > create two sets of filters, one for IPv4 and one for IPv6, but at > least they apply to the same interface on the same router. Yes, this sort of issue should be reflected in the draft. However, we are deploying this way and having (for example) two firewalls rather than one is not a big issue; the firewalls are only implementing policy. At this stage commercial IPv6 firewalls are still lacking (in our case Nokia IP740 + Checkpoint FW). > If the network is built using VLANs one can extend (trunk) the VLANs > to the new IPv6-only routers. If the new IPv6 routers are physically > and/or network topologically close to the existing IPv4 routers, this > may be easy to accomplish. I'm not sure I follow this. Do you refer to the fact that some equipment has trunking limits on (the number of) VLANs? > The fourth paragraph discusses the use of > one router to serve many VLANs by "collapsing" them to one router > interface. If the VLANs are not already topologically close to the > new IPv6 router one has to grow the existing VLAN coverage. Nobody > wants to do this since this is yet another step to a VLAN spaghetti > network. For a large site this may be a concern. In such cases the site can either a) defer v6 deployment until their routing platform supports it b) deploy IPv6 incrementally to parts of the network using a combination of tunnels and VLANs c) use some sparse deployment technology like ISATAP Given we want to run IPv6, and introduce it in a structured, managed way, we have gone with (b). > When thinking about the routers, IPv6-only router may cause > surprisingly many problems with network and router management. Our > IPv6 only router does not do at least SNMP, Syslog or NTP over IPv6 > transport. One may think this is only a short term problem, but the > router is only half of the problem. The other half are the management > applications that are used to monitor and manage the routers. If dual > stack routers are used, management applications can use IPv4 transport > making the lack of IPv6 transport a less or even a non problem. Yes, if dual-stack routers are available. Note the parallel infrastructure could be dual-stack to the router, with the interfaces injecting the RAs being v6 only. If you want to deploy IPv6-only WLAN today, you have to do that as no APs have v6 transport management (or do they?). > In conclusion, I think building a parallel IPv6 infrastructure > initially looks like a non-disturbing approach but a closer looks > shows that it does contains many issues that may cause disturbance > later on. Finally, the last paragraph of 4.4.2 mentions that the > parallel approach should be viewed only as an interim step. The > history shows that interim tends to become Integrated or permanent or > otherwise established, so why not use the resources to do dual stack. The "disturbance later on" should be a non-issue as the site can upgrade to dual-stack on the infrastructure in its next procurement cycle. The parallel network is only a stepping stone (as would be ISATAP, tunnels, or any other interim solution). The text could emphasise that. > 7.3.1 Obtaining external connectivity > [cut] > It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] > for an enterprise deployment. The enterprise has a requirement for > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker > are more appropriate for SOHO or single node environments. Use of > 6to4 also prevents the enterprise adopting aggregatable global IPv6 > addressing from the outset. > > I think the stability and availability of 6to4 relays is more of a > problem than the availability of stable 6to4 prefix. I do not see > enterprise chancing its IPv4 addressing and thus is 6to4 prefix very > often. Yes, that is what is implied in the text. > However, with 6to4 the enterprise is putting its reachability towards > non-6to4 IPv6 Internet into hands of the closest 6to4 relay operator. > This should not cause problems if the relay is well supported. The > reachability from the non-6to4 IPv6 Internet back to the enterprise > depends on the relay closest to whoever someone from the enterprise > was communicating with. In our case JANET runs a 6to4 relay. In fact, we run one for our staff and students, which they can manually point to. > I would prefer tunnel broker over 6to4 in the draft. But the draft is talking about enterprise, not soho; thus I don't think we should recommend either. However, if one must be used of those two, I would say a broker is better. But a large enterprise will most likely have an ISP that can offer a tunnel. > 7.5.2 Supporting remote access > [cut] > Such an aid may be either a tunnel broker [TBRK], ideally one that > supports operation through an IPv4 NAT, or a 6to4 relay [6TO4]. If > a 6to4 relay is offered, the site should be aware of security > issues with operating 6to4 relays [cite ref?]. > > I see enterprise's user working off-site as someone who establishes a > VPN connection back to the enterprise. When the VPN connection has > been established, the user gets an IP address from the enterprise and > all or some of the traffic is tunneled back to the enterprise over the > VPN connection. Yes, that is one solution; the text should have that added. However, many of our staff and students don't use VPN, or want to access IPv6 resources off-site, and thus a supported broker/6to4 relay is useful for them if their own (ADSL/cable) provider offers nothing. > Even if the user is behind a NAT he can still access 6to4 relay over > the VPN connection. The 6to4 relay could even use the well-known > anycast address if all traffic is tunneled or the route towards the > well known address can be set to point to the tunnel. This requires some geekdom though. Our students have no problem doing this... > If the user does not have VPN access and NATs and other filters and > packet manglers cause problems then the enterprise should provide VPN > service for the user. Advanced VPN implementations may support IPv6 > over IPv4 VPNs directly making the need for remote access aid > non-existent. Yes, we also offer this option, using IPv6 over and OpenVPN service. Thanks for the good comments! -- Tim From owner-v6ops@ops.ietf.org Sun Oct 24 21:15:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15578 for ; Sun, 24 Oct 2004 21:15:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLtST-000Hbw-C3 for v6ops-data@psg.com; Mon, 25 Oct 2004 01:15:37 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLtSS-000Hbb-4o for v6ops@ops.ietf.org; Mon, 25 Oct 2004 01:15:36 +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 i9P1FZGn025232 for ; Mon, 25 Oct 2004 02:15:35 +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 CAA12484 for ; Mon, 25 Oct 2004 02:15:34 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9P1FY517765 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 02:15:34 +0100 Date: Mon, 25 Oct 2004 02:15:34 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041025011534.GS9200@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A462@tayexc13.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Oct 14, 2004 at 06:33:26PM +0300, Heikki Vatiainen wrote: > > I agree that one size does not fit all. My point was to remind that > if no IPv6-capable existing routing infrastructure is available, one > simple possibility is to consider upgrading to such an infrastructure. > This is what section 4.4 or its subsections are not currently > mentioning. Currently the draft makes building parallel IPv6 > infrastructure to look fairly simple when I think it is not. But 4.2 and 4.3 state this reasonably clearly? Perhaps removing the word "existing" would make it clearer? > My current opinion is to prefer upgrade to dual stack over building > parallel if those are the choices and if there are resources to do the > both and no special reason to select one over the other. When I wrote > the original paragraph, I had dual stack vs parallel in mind. Of course. > Ok, that works for IPv6 Dominant Network Deployment too. My original > thought was to reduce the effort by not building parallel infra. One > way to achieve that is to go IPv6 dominant. I have to admit I did not > think IPv6 Dominant very much when reading the draft since it feels > like a option that is very much in the future. Our (my) view is to deploy dual-stack with IPv6 capbility in all (or as much as possible) of the infrastructure to enable IPv6-only nodes to be deployed, and a gradual phase over to IPv6 dominant. However, one scenario in the analysis is IPv6 dominant from the start, and so we must cater for that too. > If we would route IPv6 between all or even most of the > VLANs with a "router-on-a-stick" method, we would have to give up this > VLAN locality and that would cause plenty of resistance. It is not > seen as simple and secure to have all VLANs available on every campus > Ethernet switch. And there will be some equipment that does not support VLANs, so it is not a perfect solution by any means. But for some (many?) people it will be good enough (the method is widely used in those European universities that are deploying IPv6). > > Hmm we assumed no IPv6 only anything? But rather use of IPv6 dominantly > > over IPv4? > > I was thinking IPv6 only router when building a parallel IPv6 > network. The first paragraph of section 4.4.2 mentions the possibility > of IPv6 only routing. Yes, that is what we do. As a bonus we also gain experience in IPv6-only networking for future wider deployment. > We took a commercial router, as opposed to using a linux or bsd > router, and experimented with building parallel IPv6 routing using a > router that has IPv4 routing disabled. IPv6 routing works very well, > but the router management was quite heavily tied to IPv4. Yes, this is the case with many commercial products today (but not all!) and is an issue to be resolved in due time. -- Tim From owner-v6ops@ops.ietf.org Sun Oct 24 21:30:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16351 for ; Sun, 24 Oct 2004 21:30:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLtfw-000JbB-Sf for v6ops-data@psg.com; Mon, 25 Oct 2004 01:29:32 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLtfv-000Jax-Lr for v6ops@ops.ietf.org; Mon, 25 Oct 2004 01:29: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 i9P1TUGn025385 for ; Mon, 25 Oct 2004 02:29: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 CAA12541 for ; Mon, 25 Oct 2004 02:29:28 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9P1TSj17942 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 02:29:28 +0100 Date: Mon, 25 Oct 2004 02:29:28 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Message-ID: <20041025012928.GT9200@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <416AF467.3020408@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416AF467.3020408@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 11, 2004 at 11:00:23PM +0200, Brian E Carpenter wrote: > > In other words, why would an enterprise choose to paint itself > into any of the awkward corners of the other 13 scenarios? > Just go for a dual stack operating system and routing system, > and keep calling your software suppliers until they > upgrade to the new API. Why make it harder than it needs to > be? I think because there is no one-size solution. I suspect that Scenario O may be the most common though, but by how much, it's hard to tell. > In fact, sections 4 and 7 are written in this spirit - > they refer essentially to what I have shown above as > secnario 0. That is baed on our experience (in 6NET), but as Jim says others contributing to the analysis are doing things a different way and that experience is being reflected. > > 4.1 Phased Dual-Stack Deployment > ... > > In this document we do not advocate or discuss the deployment of > > Unique Local IPv6 Unicast Addresses [ULA]. > > > 7.3.2 Obtaining global IPv6 address space > ... > > Unique Local Addressing [ULAs] should not be used for enterprise > > networks. > > Not true and not OK. They were to a considerable extent designed for > enterprise networks. There will be a draft soon that discusses > how they could be used in enterprise networks, precisely to > respond to some of the reasons people use NATs. It isn't OK for > this draft to make such a statement about ULAs. Mea culpa. Both references should have read as per 4.1, but it could better say in both places: "In this document we do not discuss the deployment of Unique Local IPv6 Unicast Addresses [ULA]." > The simplest solution is to remove both these references to > ULAs. I would prefer to mention them, but just leaving it out is OK too. > 3) My third main concern is that the draft doesn't discuss > the deployment of DMZs, which are a feature of all major > enterprise networks. A related point is that it doesn't > discuss how an enterprise will offer an IPv6 "web presence" > (or email presence) regardless of the state of its internal > transition. Maybe converting all its DMZ servers to dual > stack would be the first essential step for many enterprises. That is what we did, so I would agree with adding such text. However, note (again as Jim said) this is a more Layer-3 oriented view, so beyond basic services like DNS we shouldn't get lost in application space too much. (ISP, 3GPP and unmanaged alos stayed in Layer 3 I believe). Otherwise it'll be a big document :) > > It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] > > for an enterprise deployment. The enterprise has a requirement for > > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker > > are more appropriate for SOHO or single node environments. > > Sorry, but that's wrong. First of all, single-node 6to4 isn't > an IETF solution - it has never been documented - so it's not accurate > to cite the RFC. Secondly, 6to4 as described in RFC 3056 will work > just fine for an enterprise - until the day its own ISP provides > native connectivity, of course. I'd say a SOHO user has less chance of > setting up RFC 3056 correctly than a large enterprise. Well, 6to4 and the tunnel broker *are* being used for both network and single node access to remote sites. If you want the text changed so that 6to4 is only for networks, and the broker is for hosts or networks, that's fine. Just reporting actual usage... 6to4 is bad for a number of reasons, reliance on the relay being one. Why use 6to4 or a broker for a large enterprise when a specific tunnel can be set up? > > ...Use of > > 6to4 also prevents the enterprise adopting aggregatable global IPv6 > > addressing from the outset. > > True... but so what? It's a solution you use only as long as you have > to, and then you switch to an aggregatable prefix. This wouldn't affect > internal network usage at all, apart from updating the prefix. Well, "apart from updating the prefix" menas a whole site renumbering exercise, and that's uncessary pain when you can use 2001: space from an ISP who is quite likely to be your future native IPv6 provider. > > 7.3.2 Obtaining global IPv6 address space > > > > The enterprise will obtain global IPv6 address space from its > > selected upstream provider, as provider assigned (PA) address > > space. > > > > The enterprise should receive at least a /48 allocation from its > > provider, as described in [ALLOC]. > > I think you should refer to RIR policy directly; that RFC is > only a recommendation to the RIRs. Fair point; could cite both? > > 7.4.6 IPv4-IPv6 interworking > > > > > > In the case of an IPv6 only node in an IPv6-dominant or dual-stack > > enterprise, wishing to communicate with external IPv4-only systems, > > some interworking (translation) method is required. The > > translation could be applied at Layer 3 (e.g. [NAT-PT]), Layer 4 > > (e.g. [SOCKS]) or Layer 7 (a dual-stack application layer gateway - > > ALG). > > I would also refer to a Layer 7 proxy. Also, since we seem to be about > to deprecate NAT-PT, it probably should not be mentioned. There seem to be a few people who think NAT-PT should live on (though I'm not one of them, I felt the solution should be mentioned, but I personally wouldn't put it in the recommendations section of the analysis - and that WILL be a hot potato in this draft!). > > 7.5.2 Supporting remote access > > > I think it's much more likely to be an IPSEC or IP-over-TLS tunnel, > which could be v6-in-v4 or v6-in-v6. That's how many enterprises offer > secure IPv4 "call home" today. Yes, I agree we should add some IPv6 over IPv4-VPN text here. Thanks for the comments Brian. -- Tim From owner-v6ops@ops.ietf.org Sun Oct 24 21:39:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17087 for ; Sun, 24 Oct 2004 21:39:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLtpT-000KwM-1Y for v6ops-data@psg.com; Mon, 25 Oct 2004 01:39:23 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLtpR-000Kw1-SH for v6ops@ops.ietf.org; Mon, 25 Oct 2004 01:39: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 i9P1dKGn025458 for ; Mon, 25 Oct 2004 02:39: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 CAA12568 for ; Mon, 25 Oct 2004 02:39:18 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9P1dIQ15100 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 02:39:18 +0100 Date: Mon, 25 Oct 2004 02:39:18 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Message-ID: <20041025013918.GU9200@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A461@tayexc13.americas.cpqcorp.net> <416E77C5.10804@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <416E77C5.10804@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Oct 14, 2004 at 02:57:41PM +0200, Brian E Carpenter wrote: > > Let me rephrase my concern. Somebody reading this draft without > the background knowledge of this WG will simply not realise > that the fundamental coexistence model is dual stack. They will > find themselves right in the discussion of the 13 scenarios > and think that they must pick one of them - but the first question > anyone should ask is "can I just do a straightforward dual stack > model?" I would argue that for the large majority of enterprise > customers the answer will be yes, except for the corner cases > where they will have to do something special. So I think the draft > needs to start out by saying this - either by inserting my Scenario 0 > or by saying it in words. > > I don't have this problem with draft-ietf-v6ops-ent-scenarios-05.txt, > which starts out with base scenario 1, widespread dual stack. Three points: a) There are many deployment models, all valid ones. b) Dual-stack is the one that most sites will follow, for the foreseeable future c) IPv6 dominant has enough usage cases to be included So I would agree with adding an ent-scenarios like wording to indicate that dual-stack is the way to go for the more common sites, but there's more to the analysis (IPv6 dominant was one of the three ent-scenarios scenarios after all). > It's not only that. Enterprises are not going to voluntarily add IPv6 > support if they perceive it as adding great operational complexity, > which is an ongoing cost. They will simply wait until it becomes simple. Absolutely, as per the othr email on parallel networking (as an example) if you can upgrade that's great. If you need to wait to a procurement cycle, so be it, but many sites will want to jump in ahead of the commercial availability, and that's where some of the interim methods described in ent-analysis come in (else it is a short document :) > >Not really reread the vlan discussion. > > As far as I can see, that only splits the routing. As far as hosts, > DNS and middleware is concerned it's still a dual stack model. Yes. And that's the advantage, but deploying parallel now we get ahead of the game for when we can slot in dual-stack routing infrastructure, and we already have all our services IPv6-capable (and some interesting experience from running v6-only on the parallel routing infrastructure). -- Tim From owner-v6ops@ops.ietf.org Sun Oct 24 21:50:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18006 for ; Sun, 24 Oct 2004 21:50:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CLu04-000Mhd-Bp for v6ops-data@psg.com; Mon, 25 Oct 2004 01:50:20 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CLu03-000MhK-5L for v6ops@ops.ietf.org; Mon, 25 Oct 2004 01:50:19 +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 i9P1oIGn025787 for ; Mon, 25 Oct 2004 02:50:18 +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 CAA12845 for ; Mon, 25 Oct 2004 02:50:15 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9P1oFZ15445 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 02:50:15 +0100 Date: Mon, 25 Oct 2004 02:50:15 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Message-ID: <20041025015015.GV9200@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <9C422444DE99BC46B3AD3C6EAFC9711B0784A4A3@tayexc13.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Thu, Oct 14, 2004 at 09:06:43PM +0300, Pekka Savola wrote: > > I see a problem with not discussion the omitted ones at all. You've > been through the though exercise of going through all the > combinations, and using some methodology, picked the ones that you > felt were interesting. I think that methodology needs to be carefully > described because otherwise the people who might have different > assumptions than you (on what they consider important or not) probably > arrive in a different result. The reality of course is that ent-scenarios was written before we had the very thorough (and useful!) matrix presented to the WG. Thus we have ent-scenarios with three broad scenarios (two of which are dual stack and IPv6 dominant), and now the added "complexity" of what some would call "corner cases". The thing is, more than one of these cases are being deployed now... > My main concern was on v6 ISPs, though I'd be a bit concerned of the > v6-only -> v4-only app scenario. That would seem to be like generic > v6-only + NAT-PT direction, which folks may or may not agree with. > But that can certainly be discussed. But this is a real scenario that needs to be addressed. You either have translation (at layer 3/4/7) between v4 and v6 only networks, or on the v6 network you run v4+NAT in parallel for those users to get *out* of their network to run legacy web/ftp/mail apps. I'm sure we'll see both cases in the wild, in not insignificant volume. > > Not sure I agree. V4 or v6 transport is a choice we assume dual stacks? > > I meant, v6 transport for DNS is not required when you run dual-stack. > It's nice, of course, but not required. It's only required with > v6-only. Or if you want a dual-stack network (infrastructure including routers, links and services) into which a v6-only node can connect and run with all services available. In our deployment, that's our goal. > > > ==> it would be worth mentioning (at least as a problem, if not > > > further > > > discussed) in a new paragraph how one would configure such proxies or > > > translators on the v6-only nodes. Manually? > > > Using yet-to-be-defined DHCPv6 options? Using unspecified means? > > > > Hmmmm to some degree yes but we don't want to own that one in this spec > > we may need some WG help on this one. > > Well, at least it could be noted as an open issue, even if nothing > concrete is done or decided in this document. (In any case, this doc > should not give "normative" guidance on which way to go, because we'll > likely need IETF process to run on this). Fair point. It's an important part of the translation vs dual-stack puzzle referred to above. -- Tim From owner-v6ops@ops.ietf.org Mon Oct 25 08:07:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19115 for ; Mon, 25 Oct 2004 08:07:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM3a7-000117-2O for v6ops-data@psg.com; Mon, 25 Oct 2004 12:04:11 +0000 Received: from [32.97.182.102] (helo=e2.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM3a3-00010E-4M for v6ops@ops.ietf.org; Mon, 25 Oct 2004 12:04:07 +0000 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e2.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9PC3sBF543320; Mon, 25 Oct 2004 08:03:54 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9PC3rdh143658; Mon, 25 Oct 2004 08:03:54 -0400 Received: from zurich.ibm.com (sig-9-146-221-79.de.ibm.com [9.146.221.79]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA70472; Mon, 25 Oct 2004 14:03:52 +0200 Message-ID: <417CEBAD.8060407@zurich.ibm.com> Date: Mon, 25 Oct 2004 14:03:57 +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: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt References: <416AF467.3020408@zurich.ibm.com> <20041025012928.GT9200@login.ecs.soton.ac.uk> In-Reply-To: <20041025012928.GT9200@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Thanks Tim, just one follow-up > Why use 6to4 or a broker for a large enterprise when a specific tunnel > can be set up? Indeed, that is better if possible. But with a disobliging ISP, it might not be possible. > >>>> > ...Use of >>>> > 6to4 also prevents the enterprise adopting aggregatable global IPv6 >>>> > addressing from the outset. >> >>> >>> True... but so what? It's a solution you use only as long as you have >>> to, and then you switch to an aggregatable prefix. This wouldn't affect >>> internal network usage at all, apart from updating the prefix. > > > Well, "apart from updating the prefix" menas a whole site renumbering > exercise, and that's uncessary pain when you can use 2001: space from an > ISP who is quite likely to be your future native IPv6 provider. Again, that doesn't work with a disobliging ISP. And we just *have* to make prefix updates a feasible option for IPv6; otherwise we will slowly slide back to a pre-CIDR state as sites wave money at ISPs. Brian From owner-v6ops@ops.ietf.org Mon Oct 25 10:05:08 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27264 for ; Mon, 25 Oct 2004 10:05:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM5RY-000JE7-S4 for v6ops-data@psg.com; Mon, 25 Oct 2004 14:03:28 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM5RX-000JDZ-Ni for v6ops@ops.ietf.org; Mon, 25 Oct 2004 14:03:28 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9PE3Io14450; Mon, 25 Oct 2004 17:03:19 +0300 Date: Mon, 25 Oct 2004 17:03:18 +0300 (EEST) From: Pekka Savola To: Brian E Carpenter cc: Tim Chown , Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt In-Reply-To: <417CEBAD.8060407@zurich.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, 25 Oct 2004, Brian E Carpenter wrote: > Thanks Tim, just one follow-up > > Why use 6to4 or a broker for a large enterprise when a specific tunnel > > can be set up? > > Indeed, that is better if possible. But with a disobliging ISP, it > might not be possible. I'm not sure if I understand your comment. Even if your own ISP would not be willing to set up a configured v6-in-v4 tunnel, there could be some other ISPs (for example, the ones for whom the enterprise pays for this :), which is willing to set up a configured v6-in-v4 tunnel. Yes, this takes some effort from the enterprise, but if enterprise is doing anything with IPv6 except testing it out, that seems like the only manageable alternative, with some guarantee of actually working reliably. So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't think it would be a good idea to recommend it for much more than that. -- 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 Oct 25 10:54:27 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01691 for ; Mon, 25 Oct 2004 10:54:27 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM6Di-0000iE-J7 for v6ops-data@psg.com; Mon, 25 Oct 2004 14:53:14 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM6Dh-0000hq-CO for v6ops@ops.ietf.org; Mon, 25 Oct 2004 14:53:13 +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 i9PErCGn013866 for ; Mon, 25 Oct 2004 15:53:12 +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 PAA17378 for ; Mon, 25 Oct 2004 15:53:09 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9PEr9j31141 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 15:53:09 +0100 Date: Mon, 25 Oct 2004 15:53:09 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Message-ID: <20041025145309.GJ20487@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <416AF467.3020408@zurich.ibm.com> <20041025012928.GT9200@login.ecs.soton.ac.uk> <417CEBAD.8060407@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417CEBAD.8060407@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 25, 2004 at 02:03:57PM +0200, Brian E Carpenter wrote: > Thanks Tim, just one follow-up > > > >Why use 6to4 or a broker for a large enterprise when a specific tunnel > >can be set up? > > Indeed, that is better if possible. But with a disobliging ISP, it > might not be possible. Well, I admit in the academic networking world we have it easy(er) in that our NRENs offer v4 and v6, so we just get a tunnel if needed (as it happens we're native, if 6PE counts as native). However, I don't see it as a big problem for a site to get a tunnel set up. A very successful IPv6 deployment in Europe was in Germany on the 6WiN where they had 300+ commercial and academic tunnels to end sites, thanks to the JOIN project. > >Well, "apart from updating the prefix" menas a whole site renumbering > >exercise, and that's uncessary pain when you can use 2001: space from an > >ISP who is quite likely to be your future native IPv6 provider. > > Again, that doesn't work with a disobliging ISP. And we just *have* to > make prefix updates a feasible option for IPv6; otherwise we will slowly > slide back to a pre-CIDR state as sites wave money at ISPs. I agree, hence draft-chown-v6ops-renumber-thinkabout-00 to complement Fred's work... but I would rather recommend tools that reduce the likelihood of renumbering in the first place. -- Tim From owner-v6ops@ops.ietf.org Mon Oct 25 10:54:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01736 for ; Mon, 25 Oct 2004 10:54:36 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM6ET-0000pK-0r for v6ops-data@psg.com; Mon, 25 Oct 2004 14:54:01 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM6ER-0000ow-SX for v6ops@ops.ietf.org; Mon, 25 Oct 2004 14:54:00 +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 i9PErxGn013888 for ; Mon, 25 Oct 2004 15:53:59 +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 PAA17524 for ; Mon, 25 Oct 2004 15:53:57 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9PErvv31145 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 15:53:57 +0100 Date: Mon, 25 Oct 2004 15:53:57 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Message-ID: <20041025145357.GK20487@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <417CEBAD.8060407@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Mon, Oct 25, 2004 at 05:03:18PM +0300, Pekka Savola wrote: > > So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't > think it would be a good idea to recommend it for much more than that. Yes, and then the "test" is little more than a SOHO-like testbed, where 6to4 may be commonly used anyway... -- Tim From owner-v6ops@ops.ietf.org Mon Oct 25 14:55:18 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23409 for ; Mon, 25 Oct 2004 14:55:17 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CM9wx-000Bfz-L8 for v6ops-data@psg.com; Mon, 25 Oct 2004 18:52:11 +0000 Received: from [171.68.10.87] (helo=sj-iport-5.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CM9wt-000BeQ-J9 for v6ops@ops.ietf.org; Mon, 25 Oct 2004 18:52:07 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 25 Oct 2004 11:52:51 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn4-104.cisco.com [10.21.80.104]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9PIps9c025486; Mon, 25 Oct 2004 11:51:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20041025114052.01d98310@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Oct 2004 11:51:53 -0700 To: Pekka Savola From: Salman Asadullah Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Cc: Brian E Carpenter , Tim Chown , In-Reply-To: References: <417CEBAD.8060407@zurich.ibm.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_76264923==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.5 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_76264923==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 05:03 PM 10/25/2004 +0300, Pekka Savola wrote: >On Mon, 25 Oct 2004, Brian E Carpenter wrote: > > Thanks Tim, just one follow-up > > > Why use 6to4 or a broker for a large enterprise when a specific tunnel > > > can be set up? > > > > Indeed, that is better if possible. But with a disobliging ISP, it > > might not be possible. > >I'm not sure if I understand your comment. Even if your own ISP would >not be willing to set up a configured v6-in-v4 tunnel, there could be >some other ISPs (for example, the ones for whom the enterprise pays >for this :), which is willing to set up a configured v6-in-v4 tunnel. > >Yes, this takes some effort from the enterprise, but if enterprise is >doing anything with IPv6 except testing it out, that seems like the >only manageable alternative, with some guarantee of actually working >reliably. > >So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't >think it would be a good idea to recommend it for much more than that. Right. This was one of the main idea of using 6to4 while testing it among several enterprise campuses and using a 2002 followed by global IPv4 address (forming a fake global IPv6 address). So, if the the enterprise did not get a a chance to get a real IPv6 address, they can just use 6to4 tunneling address and test things out among several sites and also connect to IPv6 Internet by using a 6to4 Relay. But, if the enterprise planning to move to the next step, then they should plan of getting a real global IPv6 address (2001:). Regards, Salman >-- >Pekka Savola "You each name yourselves king, yet the >Netcore Oy kingdom bleeds." >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings --=====================_76264923==_.ALT Content-Type: text/html; charset="us-ascii" At 05:03 PM 10/25/2004 +0300, Pekka Savola wrote:
On Mon, 25 Oct 2004, Brian E Carpenter wrote:
> Thanks Tim, just one follow-up
> > Why use 6to4 or a broker for a large enterprise when a specific tunnel
> > can be set up?
>
> Indeed, that is better if possible. But with a disobliging ISP, it
> might not be possible.

I'm not sure if I understand your comment. Even if your own ISP would
not be willing to set up a configured v6-in-v4 tunnel, there could be
some other ISPs (for example, the ones for whom the enterprise pays
for this :), which is willing to set up a configured v6-in-v4 tunnel.

Yes, this takes some effort from the enterprise, but if enterprise is
doing anything with IPv6 except testing it out, that seems like the
only manageable alternative, with some guarantee of actually working
reliably.

So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't
think it would be a good idea to recommend it for much more than that.

Right.  This was one of the main idea of using 6to4 while testing it among several enterprise campuses and using a 2002 followed by global IPv4 address (forming a fake global IPv6 address).  So, if the the enterprise did not get a a chance to get a real IPv6 address, they can just use 6to4 tunneling address and test things out among several sites and also connect to IPv6 Internet by using a 6to4 Relay.

But, if the enterprise planning to move to the next step, then they should plan of getting a real global IPv6 address (2001:).

Regards,
Salman


--
Pekka Savola                "You each name yourselves king, yet the
Netcore Oy                   kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--=====================_76264923==_.ALT-- From owner-v6ops@ops.ietf.org Mon Oct 25 19:21:57 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13200 for ; Mon, 25 Oct 2004 19:21:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CME88-000NFf-LJ for v6ops-data@psg.com; Mon, 25 Oct 2004 23:20:00 +0000 Received: from [63.103.94.23] (helo=ftmailgfi.flariontech.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CME87-000NFM-NE for v6ops@ops.ietf.org; Mon, 25 Oct 2004 23:19:59 +0000 Received: from ftmailserver.flariontech.com ([10.10.1.140]) by ftmailgfi.flariontech.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 25 Oct 2004 19:19:58 -0400 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: MIP and transition issues X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Date: Mon, 25 Oct 2004 19:19:58 -0400 Message-ID: Thread-Topic: MIP and transition issues Thread-Index: AcS66R10DpafzyueS8WJQO1BVKyGow== From: "Soliman, Hesham" To: , , , CC: "Tsirtsis George" X-OriginalArrivalTime: 25 Oct 2004 23:19:58.0275 (UTC) FILETIME=[24EB1930:01C4BAE9] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Folks,=20 Sorry for the cross posting, but this issue is being discussed in all WG listed.=20 I submitted the following two drafts last night: draft-tsirtsis-dsmip-problem draft-soliman-v4v6-mipv6- The first deals with the problem statement and the=20 second is one of the solution for using MIPv6 only. There is another draft that proposes using MIPv4 only: draft-tsirtsis-v4v6-mipv4 I hope we can discuss the problem statement and scenarios=20 in the next meeting. While the problem statement is on the mip6 charter, it would be useful if we can have a slot allocated for=20 this in v6ops.=20 thx Hesham =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D This email may contain confidential and privileged material for the sole = use of the intended recipient. Any review or distribution by others is = strictly prohibited. If you are not the intended recipient please contact the = sender and delete all copies. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D From owner-v6ops@ops.ietf.org Mon Oct 25 21:53:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29966 for ; Mon, 25 Oct 2004 21:53:34 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMGU3-000JWS-Sk for v6ops-data@psg.com; Tue, 26 Oct 2004 01:50:47 +0000 Received: from [202.119.230.11] (helo=njupt.edu.cn) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CMGU1-000JTk-QW for v6ops@ops.ietf.org; Tue, 26 Oct 2004 01:50:47 +0000 Received: (eyou send program); Tue, 26 Oct 2004 10:30:53 +0800 Message-ID: <298757853.24762@njupt.edu.cn> Received: from 10.10.136.115 by em.njupt.edu.cn with HTTP; Tue, 26 Oct 2004 10:30:53 +0800 X-WebMAIL-MUA: [10.10.136.115] From: "Zhenyu Wu" To: sasad@cisco.com Cc: v6ops@ops.ietf.org Date: Tue, 26 Oct 2004 10:30:53 +0800 Reply-To: "Zhenyu Wu" X-Priority: 3 Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Content-Type: text/plain X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-0.1 required=5.0 tests=AWL,BAYES_00, FROM_ENDS_IN_NUMS,MSGID_FROM_MTA_HEADER,PRIORITY_NO_NAME autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk >Right. This was one of the main idea of using 6to4 while testing it among >several enterprise campuses and using a 2002 followed by global IPv4 >address (forming a fake global IPv6 address). So, if the the enterprise >did not get a a chance to get a real IPv6 address, they can just use 6to4 >tunneling address and test things out among several sites and also connect >to IPv6 Internet by using a 6to4 Relay. What conditions do you think the enterprise did not get a chance to get a real IPv6 address? As there are so large amount of IPv6 addresses, enterprises can easily get a real IPv6 addresses, can't they? From owner-v6ops@ops.ietf.org Tue Oct 26 02:56:09 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03763 for ; Tue, 26 Oct 2004 02:56:09 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMLDI-000Hcv-0j for v6ops-data@psg.com; Tue, 26 Oct 2004 06:53:48 +0000 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMLDH-000Hce-5m for v6ops@ops.ietf.org; Tue, 26 Oct 2004 06:53:47 +0000 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 25 Oct 2004 23:55:14 -0700 X-BrightmailFiltered: true Received: from sasad-w2k01.cisco.com (sjc-vpn4-104.cisco.com [10.21.80.104]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id i9Q6rb9c006979; Mon, 25 Oct 2004 23:53:44 -0700 (PDT) Message-Id: <4.3.2.7.2.20041025234733.02c2be50@ce-nfs-1.cisco.com> X-Sender: sasad@ce-nfs-1.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 25 Oct 2004 23:53:36 -0700 To: "Zhenyu Wu" From: Salman Asadullah Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Cc: v6ops@ops.ietf.org In-Reply-To: <298757853.24762@njupt.edu.cn> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_119567549==_.ALT" X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk --=====================_119567549==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 10:30 AM 10/26/2004 +0800, Zhenyu Wu wrote: > >Right. This was one of the main idea of using 6to4 while testing it among > >several enterprise campuses and using a 2002 followed by global IPv4 > >address (forming a fake global IPv6 address). So, if the the enterprise > >did not get a a chance to get a real IPv6 address, they can just use 6to4 > >tunneling address and test things out among several sites and also connect > >to IPv6 Internet by using a 6to4 Relay. > >What conditions do you think the enterprise did not get a chance to get a real >IPv6 address? As there are so large amount of IPv6 addresses, enterprises can >easily get a real IPv6 addresses, can't they? They can ... I'm not aware of any real problems of getting a IPv6 address. One day the person in charge decide that they want to start testing IPv6 and using 2002: they can pretty much get started right away :-) Regards, Salman --=====================_119567549==_.ALT Content-Type: text/html; charset="us-ascii" At 10:30 AM 10/26/2004 +0800, Zhenyu Wu wrote:

>Right. This was one of the main idea of using 6to4 while testing it among
>several enterprise campuses and using a 2002 followed by global IPv4
>address (forming a fake global IPv6 address). So, if the the enterprise
>did not get a a chance to get a real IPv6 address, they can just use 6to4
>tunneling address and test things out among several sites and also connect
>to IPv6 Internet by using a 6to4 Relay.

What conditions do you think the enterprise did not get a chance to get a real
IPv6 address? As there are so large amount of IPv6 addresses, enterprises can
easily get a real IPv6 addresses, can't they?

They can ...

I'm not aware of any real problems of getting a IPv6 address.

One day the person in charge decide that they want to start testing IPv6 and using 2002: they can pretty much get started right away :-)

Regards,
Salman



--=====================_119567549==_.ALT-- From owner-v6ops@ops.ietf.org Tue Oct 26 04:22:30 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09261 for ; Tue, 26 Oct 2004 04:22:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMMZS-000Afa-Tt for v6ops-data@psg.com; Tue, 26 Oct 2004 08:20:46 +0000 Received: from [32.97.182.105] (helo=e5.ny.us.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMMZR-000AfL-RF for v6ops@ops.ietf.org; Tue, 26 Oct 2004 08:20:46 +0000 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by e5.ny.us.ibm.com (8.12.10/8.12.9) with ESMTP id i9Q8KdpA764812; Tue, 26 Oct 2004 04:20:39 -0400 Received: from sihl.zurich.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay04.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9Q8KbUp286688; Tue, 26 Oct 2004 04:20:38 -0400 Received: from zurich.ibm.com (sig-9-145-248-112.de.ibm.com [9.145.248.112]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA38408; Tue, 26 Oct 2004 10:20:36 +0200 Message-ID: <417E08DA.3020806@zurich.ibm.com> Date: Tue, 26 Oct 2004 10:20:42 +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: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt References: <417CEBAD.8060407@zurich.ibm.com> <20041025145357.GK20487@login.ecs.soton.ac.uk> In-Reply-To: <20041025145357.GK20487@login.ecs.soton.ac.uk> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Tim Chown wrote: > On Mon, Oct 25, 2004 at 05:03:18PM +0300, Pekka Savola wrote: > >>So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't >>think it would be a good idea to recommend it for much more than that. > > > Yes, and then the "test" is little more than a SOHO-like testbed, where > 6to4 may be commonly used anyway... > We don't have to agree on this. If an enterprise can find a configured tunnel provider, fine. If they can't, they may choose a tunnel broker or a 6to4 relay. It isn't the IETF's job to tell them. Brian From owner-v6ops@ops.ietf.org Tue Oct 26 05:25:06 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16061 for ; Tue, 26 Oct 2004 05:25:06 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMNY6-000P2r-M6 for v6ops-data@psg.com; Tue, 26 Oct 2004 09:23:26 +0000 Received: from [195.212.29.152] (helo=mtagate3.de.ibm.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMNY5-000P2P-Ke for v6ops@ops.ietf.org; Tue, 26 Oct 2004 09:23:25 +0000 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id i9Q9NGru031060; Tue, 26 Oct 2004 09:23:16 GMT Received: from sihl.zurich.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id i9Q9NF08199784; Tue, 26 Oct 2004 11:23:15 +0200 Received: from zurich.ibm.com (sig-9-145-248-112.de.ibm.com [9.145.248.112]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA33974; Tue, 26 Oct 2004 11:23:14 +0200 Message-ID: <417E1787.9060109@zurich.ibm.com> Date: Tue, 26 Oct 2004 11:23:19 +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: Salman Asadullah CC: Zhenyu Wu , v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt References: <4.3.2.7.2.20041025234733.02c2be50@ce-nfs-1.cisco.com> In-Reply-To: <4.3.2.7.2.20041025234733.02c2be50@ce-nfs-1.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit > I'm not aware of any real problems of getting a IPv6 address. I assure you that it depends entirely on your ISP. Brian From owner-v6ops@ops.ietf.org Tue Oct 26 06:55:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22840 for ; Tue, 26 Oct 2004 06:55:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMOy2-0004Hx-5l for v6ops-data@psg.com; Tue, 26 Oct 2004 10:54:18 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMOy1-0004HX-4b for v6ops@ops.ietf.org; Tue, 26 Oct 2004 10:54:17 +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 i9QAsFGn007024 for ; Tue, 26 Oct 2004 11:54: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 LAA18600 for ; Tue, 26 Oct 2004 11:54:14 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9QAsEs18057 for v6ops@ops.ietf.org; Tue, 26 Oct 2004 11:54:14 +0100 Date: Tue, 26 Oct 2004 11:54:14 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt Message-ID: <20041026105414.GL16533@login.ecs.soton.ac.uk> Mail-Followup-To: v6ops@ops.ietf.org References: <417CEBAD.8060407@zurich.ibm.com> <20041025145357.GK20487@login.ecs.soton.ac.uk> <417E08DA.3020806@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <417E08DA.3020806@zurich.ibm.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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, Oct 26, 2004 at 10:20:42AM +0200, Brian E Carpenter wrote: > Tim Chown wrote: > >On Mon, Oct 25, 2004 at 05:03:18PM +0300, Pekka Savola wrote: > > > >>So, IMHO, enterprises can certainly test IPv6 using 6to4, but I don't > >>think it would be a good idea to recommend it for much more than that. > > > > > >Yes, and then the "test" is little more than a SOHO-like testbed, where > >6to4 may be commonly used anyway... > > > > We don't have to agree on this. If an enterprise can find a configured > tunnel provider, fine. If they can't, they may choose a tunnel broker > or a 6to4 relay. It isn't the IETF's job to tell them. As it's an analysis document making recommendations, just as per the other three analysis docs we should do that... e.g. just as we made Teredo a last resort mechanism for unmanaged, we might agree to place 6to4 as last resort for an enterprise. My ordering would be (topology being alike): 1. native 2. manually configured tunnel 3. tunnel broker 4. 6to4 i.e. put native, managed connectivity ahead of automatic, esp. where the automatic has less predictable behaviour. Other factors also come to bear, like using 2002::/16 and heaving to renumber... -- Tim From owner-v6ops@ops.ietf.org Tue Oct 26 09:17:42 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04279 for ; Tue, 26 Oct 2004 09:17:41 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMR9y-000GKT-GH for v6ops-data@psg.com; Tue, 26 Oct 2004 13:14:46 +0000 Received: from [161.114.64.105] (helo=zmamail05.zma.compaq.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMR9x-000GKE-3V for v6ops@ops.ietf.org; Tue, 26 Oct 2004 13:14:45 +0000 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 948B3AC99; Tue, 26 Oct 2004 09:14:44 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Oct 2004 09:14:44 -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 NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Date: Tue, 26 Oct 2004 09:14:47 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B07A4CC33@tayexc13.americas.cpqcorp.net> Thread-Topic: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) Thread-Index: AcS6L0Rglzhpk7LjSjCG9nk5cm89wwBLjBfw From: "Bound, Jim" To: "Tim Chown" , X-OriginalArrivalTime: 26 Oct 2004 13:14:44.0496 (UTC) FILETIME=[C2A1E900:01C4BB5D] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: quoted-printable Good comments and good response. One important point to note that was noted to Pekka in my response. No one is assuming an IPv6 ONLY anything. The entire spec assumes dual stack. What we do believe is users will move services and routing to IPv6 and not IPv4 on points of the network in several cases immediately as part of the transition and definitely as a plan. This does not imply IPv6 only but dominant use of IPv6. /jim > -----Original Message----- > From: owner-v6ops@ops.ietf.org=20 > [mailto:owner-v6ops@ops.ietf.org] On Behalf Of Tim Chown > Sent: Sunday, October 24, 2004 9:06 PM > To: v6ops@ops.ietf.org > Subject: Re: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd) >=20 > On Mon, Oct 11, 2004 at 09:25:38PM +0300, Heikki Vatiainen wrote: > >=20 > > I think dual stack has been available long enough that the=20 > potential=20 > > for disturbance is not great enough to justify a parallel=20 > > infrasturcture for IPv6. In fact, I would recommend that parallel=20 > > infrasturcture is only built if no other options, such as=20 > upgrading to=20 > > dual stack routers, are available. >=20 > Hi Heikki, >=20 > I think this is made clear in 4.2 and 4.3? >=20 > > The parallel infrastructure forces you to have two times the=20 > > documentation about the network. If e.g. intra-organization packet=20 > > filtering is done, you have to literally think and check twice that=20 > > the filters are set up as required. With dual stack you=20 > may need to=20 > > create two sets of filters, one for IPv4 and one for IPv6, but at=20 > > least they apply to the same interface on the same router. >=20 > Yes, this sort of issue should be reflected in the draft. =20 > However, we are deploying this way and having (for example)=20 > two firewalls rather than one is not a big issue; the=20 > firewalls are only implementing policy. > At this stage commercial IPv6 firewalls are still lacking (in=20 > our case Nokia IP740 + Checkpoint FW). > =20 > > If the network is built using VLANs one can extend (trunk)=20 > the VLANs=20 > > to the new IPv6-only routers. If the new IPv6 routers are=20 > physically=20 > > and/or network topologically close to the existing IPv4=20 > routers, this=20 > > may be easy to accomplish. >=20 > I'm not sure I follow this. Do you refer to the fact that=20 > some equipment has trunking limits on (the number of) VLANs? >=20 > > The fourth paragraph discusses the use of one router to serve many=20 > > VLANs by "collapsing" them to one router interface. If the=20 > VLANs are=20 > > not already topologically close to the new IPv6 router one=20 > has to grow=20 > > the existing VLAN coverage. Nobody wants to do this since=20 > this is yet=20 > > another step to a VLAN spaghetti network. >=20 > For a large site this may be a concern. In such cases the=20 > site can either >=20 > a) defer v6 deployment until their routing platform supports it >=20 > b) deploy IPv6 incrementally to parts of the network using a=20 > combination > of tunnels and VLANs >=20 > c) use some sparse deployment technology like ISATAP >=20 > Given we want to run IPv6, and introduce it in a structured,=20 > managed way, we have gone with (b). >=20 > > When thinking about the routers, IPv6-only router may cause=20 > > surprisingly many problems with network and router management. Our > > IPv6 only router does not do at least SNMP, Syslog or NTP over IPv6=20 > > transport. One may think this is only a short term=20 > problem, but the=20 > > router is only half of the problem. The other half are the=20 > management=20 > > applications that are used to monitor and manage the=20 > routers. If dual=20 > > stack routers are used, management applications can use=20 > IPv4 transport=20 > > making the lack of IPv6 transport a less or even a non problem. >=20 > Yes, if dual-stack routers are available. >=20 > Note the parallel infrastructure could be dual-stack to the=20 > router, with > the interfaces injecting the RAs being v6 only. If you want=20 > to deploy > IPv6-only WLAN today, you have to do that as no APs have v6=20 > transport management (or do they?). >=20 > > In conclusion, I think building a parallel IPv6 infrastructure=20 > > initially looks like a non-disturbing approach but a closer looks=20 > > shows that it does contains many issues that may cause disturbance=20 > > later on. Finally, the last paragraph of 4.4.2 mentions that the=20 > > parallel approach should be viewed only as an interim step. The=20 > > history shows that interim tends to become Integrated or=20 > permanent or=20 > > otherwise established, so why not use the resources to do=20 > dual stack. >=20 > The "disturbance later on" should be a non-issue as the site=20 > can upgrade to dual-stack on the infrastructure in its next=20 > procurement cycle. The parallel network is only a stepping=20 > stone (as would be ISATAP, tunnels, or any other interim solution). >=20 > The text could emphasise that. >=20 > > 7.3.1 Obtaining external connectivity [cut] > > It is not recommended to use 6to4 [6TO4] or a tunnel broker [TBRK] > > for an enterprise deployment. The enterprise has a=20 > requirement for > > long-term, stable IPv6 connectivity. 6to4 and the tunnel broker > > are more appropriate for SOHO or single node environments. Use of > > 6to4 also prevents the enterprise adopting aggregatable=20 > global IPv6 > > addressing from the outset. > >=20 > > I think the stability and availability of 6to4 relays is more of a=20 > > problem than the availability of stable 6to4 prefix. I do not see=20 > > enterprise chancing its IPv4 addressing and thus is 6to4=20 > prefix very=20 > > often. >=20 > Yes, that is what is implied in the text. > =20 > > However, with 6to4 the enterprise is putting its=20 > reachability towards > > non-6to4 IPv6 Internet into hands of the closest 6to4 relay=20 > operator. > > This should not cause problems if the relay is well supported. The=20 > > reachability from the non-6to4 IPv6 Internet back to the enterprise=20 > > depends on the relay closest to whoever someone from the enterprise=20 > > was communicating with. >=20 > In our case JANET runs a 6to4 relay. In fact, we run one for=20 > our staff and students, which they can manually point to. > =20 > > I would prefer tunnel broker over 6to4 in the draft. >=20 > But the draft is talking about enterprise, not soho; thus I=20 > don't think we should recommend either. However, if one must=20 > be used of those two, > I would say a broker is better. But a large enterprise will most > likely have an ISP that can offer a tunnel. > =20 > > 7.5.2 Supporting remote access > > [cut] > > Such an aid may be either a tunnel broker [TBRK], ideally one that > > supports operation through an IPv4 NAT, or a 6to4 relay=20 > [6TO4]. If > > a 6to4 relay is offered, the site should be aware of security > > issues with operating 6to4 relays [cite ref?]. > >=20 > > I see enterprise's user working off-site as someone who=20 > establishes a=20 > > VPN connection back to the enterprise. When the VPN connection has=20 > > been established, the user gets an IP address from the=20 > enterprise and=20 > > all or some of the traffic is tunneled back to the=20 > enterprise over the=20 > > VPN connection. >=20 > Yes, that is one solution; the text should have that added. =20 > However, many of our staff and students don't use VPN, or=20 > want to access IPv6 resources off-site, and thus a supported=20 > broker/6to4 relay is useful for them if their own=20 > (ADSL/cable) provider offers nothing. > =20 > > Even if the user is behind a NAT he can still access 6to4=20 > relay over=20 > > the VPN connection. The 6to4 relay could even use the well-known=20 > > anycast address if all traffic is tunneled or the route towards the=20 > > well known address can be set to point to the tunnel. >=20 > This requires some geekdom though. Our students have no=20 > problem doing this... > =20 > > If the user does not have VPN access and NATs and other filters and=20 > > packet manglers cause problems then the enterprise should=20 > provide VPN=20 > > service for the user. Advanced VPN implementations may=20 > support IPv6=20 > > over IPv4 VPNs directly making the need for remote access aid=20 > > non-existent. >=20 > Yes, we also offer this option, using IPv6 over and OpenVPN service. > =20 > Thanks for the good comments! >=20 > -- > Tim >=20 >=20 From owner-v6ops@ops.ietf.org Tue Oct 26 17:41:40 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29160 for ; Tue, 26 Oct 2004 17:41:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMZ0Z-0006SD-6o for v6ops-data@psg.com; Tue, 26 Oct 2004 21:37:35 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMZ0X-0006Rl-O4 for v6ops@ops.ietf.org; Tue, 26 Oct 2004 21:37:34 +0000 Received: from [200.122.143.213] ([200.122.143.213]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000531732.msg for ; Tue, 26 Oct 2004 23:42:45 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 26 Oct 2004 15:37:19 -0600 Subject: FW: I-D ACTION:draft-palet-v6ops-tun-auto-disc-02.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <200410262002.QAA09568@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Tue, 26 Oct 2004 23:42:45 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 200.122.143.213 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: v6ops@ops.ietf.org Reply-To: jordi.palet@consulintel.es X-MDAV-Processed: consulintel.es, Tue, 26 Oct 2004 23:42:50 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, In case you've not seen the announcement, we have submitted a new version of this document. Now it comes with the analysis of SLP, which Brian suggested several times, and we had not previously documented. Regards, Jordi ------ Mensaje reenviado De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Fecha: Tue, 26 Oct 2004 16:02:28 -0400 Para: i-d-announce@ietf.org Asunto: I-D ACTION:draft-palet-v6ops-tun-auto-disc-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Analysis of IPv6 Tunnel End-point Discovery Mechanisms Author(s) : J. Palet, et al. Filename : draft-palet-v6ops-tun-auto-disc-02.txt Pages : 16 Date : 2004-10-26 Tunneling is commonly used in several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is being able to automatically determine the tunnel end-point for the tunneling mechanism. This memo analyses the different approaches for configuring the IPv6 tunnel endpoint on a node. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palet-v6ops-tun-auto-disc-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-26160532.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-palet-v6ops-tun-auto-disc-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Oct 26 18:53:46 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18814 for ; Tue, 26 Oct 2004 18:53:46 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMaAu-000G6Y-QH for v6ops-data@psg.com; Tue, 26 Oct 2004 22:52:20 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMaAt-000G61-BU for v6ops@ops.ietf.org; Tue, 26 Oct 2004 22:52:19 +0000 Received: from [200.122.143.213] ([200.122.143.213]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000531812.msg for ; Wed, 27 Oct 2004 00:57:34 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 26 Oct 2004 16:52:11 -0600 Subject: FW: I-D ACTION:draft-palet-v6ops-solution-tun-auto-disc-01.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <200410262007.QAA10094@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Wed, 27 Oct 2004 00:57:34 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 200.122.143.213 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, Wed, 27 Oct 2004 00:57:36 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Second document regarding the auto discovery of the tunnel end point. Please, provide inputs ! Regards, Jordi ------ Mensaje reenviado De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Fecha: Tue, 26 Oct 2004 16:07:26 -0400 Para: i-d-announce@ietf.org Asunto: I-D ACTION:draft-palet-v6ops-solution-tun-auto-disc-01.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Tunnel End-point Automatic Discovery Mechanism Author(s) : J. Palet, M. Diaz Filename : draft-palet-v6ops-solution-tun-auto-disc-01.txt Pages : 15 Date : 2004-10-26 Tunneling is commonly used by several IPv6 transition mechanisms. To be able to automate setting up tunnels, one critical component is a solution to automatically discover the tunnel end-point (TEP) for the transition mechanism. This memo proposes a solution for discovering the IPv6 TEP in a simple an efficient way. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-solution-tun-auto-disc -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-palet-v6ops-solution-tun-auto-disc-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-palet-v6ops-solution-tun-auto-disc-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. Content-Type: text/plain Content-ID: <2004-10-26160647.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-palet-v6ops-solution-tun-auto-disc-01.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Oct 26 18:53:54 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18859 for ; Tue, 26 Oct 2004 18:53:53 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMaC3-000GGF-K1 for v6ops-data@psg.com; Tue, 26 Oct 2004 22:53:31 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMaC2-000GFt-8U for v6ops@ops.ietf.org; Tue, 26 Oct 2004 22:53:30 +0000 Received: from [200.122.143.213] ([200.122.143.213]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000531813.msg for ; Wed, 27 Oct 2004 00:58:45 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 26 Oct 2004 16:53:21 -0600 Subject: FW: I-D ACTION:draft-palet-v6ops-auto-trans-02.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <200410262006.QAA09937@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Wed, 27 Oct 2004 00:58:45 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 200.122.143.213 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, Wed, 27 Oct 2004 00:58:47 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit This is also a new version of the auto-transition document. The main change here is the incorporation of the description of an "auto-transitioning" server in addition to the PBN option. Regards, Jordi ------ Mensaje reenviado De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Fecha: Tue, 26 Oct 2004 16:06:17 -0400 Para: i-d-announce@ietf.org Asunto: I-D ACTION:draft-palet-v6ops-auto-trans-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Evaluation of IPv6 Auto-Transition Algorithm Author(s) : J. Palet, et al. Filename : draft-palet-v6ops-auto-trans-02.txt Pages : 23 Date : 2004-10-26 This memo evaluates a method called 'auto-transition' to ensure that any device can obtain IPv6 connectivity at any time and whatever network is attached to, even if such network is connected to Internet only with IPv4 or already offers IPv6 but with poor performance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-palet-v6ops-auto-trans-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-palet-v6ops-auto-trans-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-palet-v6ops-auto-trans-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-26160627.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-palet-v6ops-auto-trans-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Oct 26 18:54:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19244 for ; Tue, 26 Oct 2004 18:54:56 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMaDH-000GTo-Pn for v6ops-data@psg.com; Tue, 26 Oct 2004 22:54:47 +0000 Received: from [213.172.48.142] (helo=consulintel.es) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMaDG-000GT3-58 for v6ops@ops.ietf.org; Tue, 26 Oct 2004 22:54:46 +0000 Received: from [200.122.143.213] ([200.122.143.213]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000531819.msg for ; Wed, 27 Oct 2004 01:00:00 +0200 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 26 Oct 2004 16:54:34 -0600 Subject: FW: I-D ACTION:draft-vives-v6ops-ipv6-security-ps-02.txt From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: <200410262007.QAA10069@ietf.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Wed, 27 Oct 2004 01:00:00 +0200 (not processed: message from valid local sender) X-MDRemoteIP: 200.122.143.213 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, Wed, 27 Oct 2004 01:00:03 +0200 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Hi again, This is an updated version of the IPv6 Distributed Security Problem Statement document. Please, provide your inputs ! Regards, Jordi ------ Mensaje reenviado De: Internet-Drafts@ietf.org Responder a: internet-drafts@ietf.org Fecha: Tue, 26 Oct 2004 16:07:02 -0400 Para: i-d-announce@ietf.org Asunto: I-D ACTION:draft-vives-v6ops-ipv6-security-ps-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Security Problem Statement Author(s) : A. Vives, et al. Filename : draft-vives-v6ops-ipv6-security-ps-02.txt Pages : 17 Date : 2004-10-26 Today, each network is often secured by a unique device (i.e. security gateway or firewall) that becomes a bottleneck for the end-to-end security model with IPv6. The deployment of IPv6 enabled devices and networks bring some issues, which must be addressed by security administrators in order to guarantee at least the same level of security that is obtained nowadays with IPv4 and network-based (including perimetral-based) security schemes, allowing at the same time all the IPv6 advantages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-vives-v6ops-ipv6-security-ps-02.tx t 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-vives-v6ops-ipv6-security-ps-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-vives-v6ops-ipv6-security-ps-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2004-10-26160642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-vives-v6ops-ipv6-security-ps-02.txt _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce ------ Fin del mensaje reenviado ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. From owner-v6ops@ops.ietf.org Tue Oct 26 21:57:37 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20319 for ; Tue, 26 Oct 2004 21:57:37 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMd0t-000D3N-E9 for v6ops-data@psg.com; Wed, 27 Oct 2004 01:54:11 +0000 Received: from [202.32.8.202] (helo=tyo202.gate.nec.co.jp) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMd0s-000D2c-8d for v6ops@ops.ietf.org; Wed, 27 Oct 2004 01:54:10 +0000 Received: from mailgate3.nec.co.jp (mailgate53.nec.co.jp [10.7.69.162] (may be forged)) by tyo202.gate.nec.co.jp (8.11.7/3.7W01080315) with ESMTP id i9R1rJn26272; Wed, 27 Oct 2004 10:53:21 +0900 (JST) Received: (from root@localhost) by mailgate3.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id i9R1rJg07967; Wed, 27 Oct 2004 10:53:19 +0900 (JST) Received: from dns02.ubq.nec.co.jp (dns02.ubq.nec.co.jp [10.17.225.2]) by mailsv.nec.co.jp (8.11.7/3.7W-MAILSV-NEC) with ESMTP id i9R1rIx28641; Wed, 27 Oct 2004 10:53:18 +0900 (JST) Received: from dns03.ubq.nec.co.jp (dns03.ubq.nec.co.jp [10.17.225.65]) by dns02.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3I09112; Wed, 27 Oct 2004 10:53:03 +0900 (JST) Received: from localhost ([10.17.226.96]) by dns03.ubq.nec.co.jp (8.11.7/8.11.7) with ESMTP id i9R1r3W27699; Wed, 27 Oct 2004 10:53:03 +0900 (JST) To: ipv6@ietf.org, v6ops@ops.ietf.org, mip6@ietf.org Cc: anycast@anarg.jp Subject: Call for Participation on IPv6 Anycast discussion ML X-Mailer: Mew version 1.94.2 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20041027105303P.kitamura@da.jp.nec.com> Date: Wed, 27 Oct 2004 10:53:03 +0900 From: Hiroshi KITAMURA X-Dispatcher: imput version 20000228(IM140) Lines: 46 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit Dear All, People, who are interested in IPv6 Anycast discussion, please read this mail. I thing there are many people who are interested in IPv6 Anycast. Since IPv6 Anycast has many good potential functionalities, many people are expecting that it will be widely used in the real-world. Currently, IPv6 Anycast is only used at limited area for limited purpose. It is a pity that IPv6 Anycast is not widely used. This situation should be changed. A small IPv6 Anycast discussion team has been made by people who are interested in this topic. http://anycast.anarg.jp/ is a web site for IPv6 Anycast discussion. anycast@anarg.jp is a ML for it. People, who are interested in IPv6 Anycast discussion, please join this ML and let us know your comments. Let's discuss on IPv6 Anycast issues at this ML. (Instruction how to join the ML is written in above web site.) We have already issued four I-Ds on IPv6 Anycast. (Of course, they are under construction.) 1. IPv6 Anycast Terminology Definition 2. Applicability Statement of IPv6 Anycasting 3. A Protocol for Anycast Address Resolving 4. Possible Deployment Scenarios for IPv6 Anycasting You can find them at above web site. We'd like to have a Practical Anycasting BoF in the near future. We have already talked with Internet Area Directors on this issue. A draft for charter proposal is written in above web site, please read them and let us know your comments. Regards, Hiroshi From owner-v6ops@ops.ietf.org Tue Oct 26 22:14:24 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21347 for ; Tue, 26 Oct 2004 22:14:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMdK8-000G6w-2z for v6ops-data@psg.com; Wed, 27 Oct 2004 02:14:04 +0000 Received: from [221.249.121.227] (helo=coconut.itojun.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMdK7-000G6i-Bl for v6ops@ops.ietf.org; Wed, 27 Oct 2004 02:14:03 +0000 Received: by coconut.itojun.org (Postfix, from userid 1001) id 419051C0CE; Wed, 27 Oct 2004 11:14:02 +0900 (JST) To: kitamura@da.jp.nec.com Cc: ipv6@ietf.org, v6ops@ops.ietf.org, mip6@ietf.org, anycast@anarg.jp Subject: draft-ata-ipv6-anycast-resolving-02.txt In-Reply-To: Your message of "Wed, 27 Oct 2004 10:53:03 +0900" <20041027105303P.kitamura@da.jp.nec.com> References: <20041027105303P.kitamura@da.jp.nec.com> X-Mailer: Cue version 0.8 (041013-0602/itojun) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Message-Id: <20041027021402.419051C0CE@coconut.itojun.org> Date: Wed, 27 Oct 2004 11:14:02 +0900 (JST) From: itojun@itojun.org (Jun-ichiro itojun Hagino) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (sorry to spam 3 wgs, i have not received response to subscription request for anycast@anarg.jp yet) > draft-ata-ipv6-anycast-resolving-02.txt > A Protocol for Anycast Address Resolving due to the way the proposal resolves (or hides) anycast address into unicast address, we will experience a severe problem. application thinks that it is communicating with anycast address AA, but ARL (basically a NAT within client) translates it into unicast address. therefore, applications which embeds address into its protocol payload (like ftp) won't work as expected. section 4 (applicability statement) is not true. appendix A (how to map anycast address into unicast) basically has no security considerations. section 5 (security consideration) is also too weak. another issue with this approach is, that anycast is being used as service discovery mechnaism on the first contact only. anycast has other benefits such as failure recovery/tolerance. these benefits are gone with this draft. itojun From owner-v6ops@ops.ietf.org Wed Oct 27 02:20:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA27281 for ; Wed, 27 Oct 2004 02:20:12 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMh85-000LEa-2Q for v6ops-data@psg.com; Wed, 27 Oct 2004 06:17:53 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMh83-000LEG-RH for v6ops@ops.ietf.org; Wed, 27 Oct 2004 06:17:52 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9R6Gvf06835; Wed, 27 Oct 2004 09:16:59 +0300 Date: Wed, 27 Oct 2004 09:16:57 +0300 (EEST) From: Pekka Savola To: "Bound, Jim" cc: Tim Chown , v6ops@ops.ietf.org Subject: dominant v6 assumptions [RE: REVIEW NEEDED: draft-ietf-v6ops-ent-analysis-00.txt (fwd)] In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B07A4CC33@tayexc13.americas.cpqcorp.net> Message-ID: References: <9C422444DE99BC46B3AD3C6EAFC9711B07A4CC33@tayexc13.americas.cpqcorp.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Tue, 26 Oct 2004, Bound, Jim wrote: > Good comments and good response. One important point to note that was > noted to Pekka in my response. No one is assuming an IPv6 ONLY anything. > The entire spec assumes dual stack. What we do believe is users will > move services and routing to IPv6 and not IPv4 on points of the network > in several cases immediately as part of the transition and definitely as > a plan. This does not imply IPv6 only but dominant use of IPv6. Different people have different assumptions about 'dominant IPv6', which might be confusing here. For example, a couple of possibilities: 1) both v4 and v6 routing and addressing is provided, but most services have been made available using v6, v6 ALGs have been configured (e.g., web proxies), so consequently, the majority of the traffic is going as v6. 2) both v4 and v6 routing and addressing is provided, but there are some nodes which are v6-only 3) in some places in the network, v4 routing/addressing has been disabled. This case must somehow answer the question how hosts or routers in those places in the network will talk to v4 nodes if they need to (or is it assumed they won't need to?) 4) v4 addressing/routing has been disabled everywhere except for a couple of boxes near the border. See 3). In other words, even if the nodes are dual-stack capable, if you switch off v4 routing or addressing, you'll have a couple things to think about: a) is it worth it to turn v4 off, would it be easier if you didn't? (in very many cases, it seems that turning v4 off prematurely results in highly increased complexity in the network) b) if you do, can you make the assumption that those parts of networks don't need to talk to v4-only hosts/routers? (then it would be OK to turn it off IMHO) c) if communication with v4 nodes/apps is still needed, will you perform tunneling or translation. If translation, is it application-specific (e.g., ALG/proxy; that's OK) or generic (oh no, NAT-PT, see argument a)? If tunneling, couldn't the hosts always have an IPv4 address, but just over the tunnel (also see argument a) -- what would be the point in that)? -- 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 Oct 27 03:12:07 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11610 for ; Wed, 27 Oct 2004 03:12:07 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CMhxg-0002MG-Pg for v6ops-data@psg.com; Wed, 27 Oct 2004 07:11:12 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CMhxf-0002Lw-4s for v6ops@ops.ietf.org; Wed, 27 Oct 2004 07:11:11 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9R7B6R07980; Wed, 27 Oct 2004 10:11:06 +0300 Date: Wed, 27 Oct 2004 10:11:06 +0300 (EEST) From: Pekka Savola To: JORDI PALET MARTINEZ cc: v6ops@ops.ietf.org Subject: Re: comments on draft-palet-v6ops-solution-tun-auto-disc-00.txt In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Some comments below.. (Btw, as a couple of subjects were left in as 'waiting for more feedback', it would be useful to have some kind of issue tracker or web page, summary in the following drafts, or the like to keep track of comments which have been submitted but haven't been reflected..) On Sun, 24 Oct 2004, JORDI PALET MARTINEZ wrote: >> Does the solution have to support complete 3rd parties, such as >> anycasting 6to4 relays now? (Remember that 6to4 relays are stateless, >> while the tunnel servers typically aren't, and this would cause >> additional implications on the mechanisms.) > > As explained in the Case Studies section, is up to each ISP to decide if > they want to support external users or not. Certainly, but remember that some of the solutions we're discussing are 'inter-domain', while some others are not (like ISATAP, a possible zero-conf tunneling solution). These two different kinds of mechanisms do have different kinds of requirements for the discovery process: certainly, something like 6to4 is pretty likely to be completely different than the rest. But we don't need an interdomain solution to 6to4 because we have one already... >> Does the solution have to support those customers which momentarily >> roam outside of their ISP's access network? [E.g., as solution based >> on DNS records would probably still be at least partially applicable >> here] > > From the users point of view, yes. Of course, users always need to rely into > available services, but if we don't provide this part of the solution, they > will never have it. Providing it, they might have it (up to the providers, > even if a few that with to provide the service). But then you assume that the mechanism you're discovering supports this feature, which may not be true ? My point is, that if the discovery is relatively simple, it could also be implemented (with just a couple of dozen or a hundred lines of code) in the mechanisms themselves, not a generic 'library' or the like. >> I'm concerned that because there is significantly smaller amount of >> incentive, and more technical challenges, for ISPs to deploy an >> inter-domain anycast solution for tunnel servers, so that it would not >> be actually usable for discovery. > > I don't agree, 6to4 is working, and we are just extending the applicability > of 6to4 to other mechanisms. You don't have to renumber your network when you happen to switch 6to4 relay providers, either by manually or because the routing changes. That would be inevitable with other kinds of mechanisms. Therefore such an interdomain anycast address would have limited applicability IMHO. (Only even marginally feasible if anycast was used just for discovery, and unicast used for real communication) >>>> and 2) the draft doesn't sufficiently describe the >>>> mechanism/protocol/implementation requirements, and how those >>>> interoperate with whatever the ISPs would deploy. >>> >>> I'm not sure what do you mean here, but providing more details about DNS SRV >>> RR and anycast seems to us out of the scope of this document. There are no >>> _new_ requirements for the ISP, neither the client, because we are using >>> existing mechanism (DNS and anycast). >> >> No, I didn't mean that, but rather what mechanisms must be implemented >> in the mechanism or the host stack. I'll try to explain below. > > Ok. We can work on that in a new section, with concrete examples for > different mechanisms. OK. >> Maybe I did not write clearly enough, without assumptions. >> >> Whether or not this discovery process is done in the host stack, or >> the transition mechanism, is relatively irrelevant. >> >> However, it is VERY MUCH relevant to this draft WHAT must be >> implemented in the host stack or the mechanism to make these work. >> >> For example, if the host would just implement DNS lookups and the ISP >> just anycast, discovery process should fail. > > Understood now. The client must implement the complete picture, but not the > server. I'm about to finish an updated version of the document, and will > make sure this is clear. Good to make it clear. FWIW, I personally aren't that fond of the requirement that the protocols/mechanisms would have to implement everything -- because that would add complexity, and might have significant disadvantages (e.g., relating to the latency of the set-up, if you have to try e.g. 3 different methods sequentially). >>> We are using a single name for each protocol, so whatever is implemented in >>> the ISP, will work for the client. I think this provides complete >>> interoperability ! >> >> Yes, but you also specify the inter-domain anycast in addition to DNS >> lookups using SRV or A records. >> >> Which ones must be supported in the client? Which ones in the ISP? >> There are probably half a dozen non-interoperable combinations here. >> >> Maybe your implicit assumption is that the client supports all of >> them: interdomain anycast, DNS with SRV, and DNS with A records, and >> maybe even DHCP to the boot -- and tries them in some particular >> order, and then it would just depend on what the ISP supports. >> >> I don't have that assumption. On the contrary, I think there must be >> a minimal set of approaches so that 1) very little is required to >> implement & deploy, and 2) there are as few interop problems as >> possible. > > My point of view is that both the ability to resolve SRV/A and anycast are > already available today in all the clients, so making both as part of the > requirement, will not add actually any new requirements. Having to look up both SRV and A records adds at least (and possibly more) one round-trip. SRV requires the use of non-standard APIs AFAIR (e.g., getrrsetbyname), which may or may not be present. And then there is inter-domain anycast.. >>>> semi-substantial >>>> ---------------- >>>> >>>> On the other hand, shared anycast is also a very useful approach >>>> since it can globally identify a specific service (TEP or transition >>>> mechanism). >>>> >>>> ==> I think you're assuming that anycast (shared-unicast) would be allocated >>>> an interdomain range, because otherwise it can't be globally identified. >>>> This doesn't need to be the case. >>> >>> Our intend is to use the same prefix as for 6to4, for all the mechanisms (so >>> we can allocate for example up to 254 new mechanisms, more than enough). >> >> Uhh, I didn't quite understand: did you mean 192.88.99.2 for X, .3 for >> Y, .4 for Z, or "similar prefix as for 6to4", like 192.88.100.0/24 for >> X, .101.0/24 for Y, etc. >> >> The former would definitely not work. > > You're right. I was actually thinking in the option that you describe in > first place, but I now realize that precisely because that problem, we use a > prefix for 6to4, instead of just one address. So need to double-check if we > need to move to the 2nd way, or there is an alternative. A prefix might be possible for some inter-domain services, but for those that aren't, IMHO it should be dropped completely. And even for inter-domain, I don't think there are any which would need it: Teredo had it before, but it was removed due to review from routing people (because one would need to send packet with the anycast address as the source to pierce the NATs), or just as a discovery method. For something like TSP, this wouldn't make sense because you could end up with different providers, with different prefixes. Again, this would only make marginal sense as 'discovery of the unicast address', not much else. Hence, I'm not so sure that inter-domain anycast address is really needed now. -- 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 Oct 28 10:57:29 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20856 for ; Thu, 28 Oct 2004 10:57:29 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBJi-0007Mb-0D for v6ops-data@psg.com; Thu, 28 Oct 2004 14:31:54 +0000 Received: from [152.78.70.1] (helo=raven.ecs.soton.ac.uk) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBJg-0007M0-SY for v6ops@ops.ietf.org; Thu, 28 Oct 2004 14:31:53 +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 i9SEVpGn017887 for ; Thu, 28 Oct 2004 15:31: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 PAA22666 for ; Thu, 28 Oct 2004 15:31:50 +0100 (BST) Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id i9SEVo613800 for v6ops@ops.ietf.org; Thu, 28 Oct 2004 15:31:50 +0100 Date: Thu, 28 Oct 2004 15:31:50 +0100 From: Tim Chown To: v6ops@ops.ietf.org Subject: vlan-usage draft Message-ID: <20041028143150.GA13696@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 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I submitted a new version, with some clarifications (I hope!) and also an Appendix with a BSD example. http://www.ietf.org/internet-drafts/draft-chown-v6ops-vlan-usage-02.txt It would be nice to have this available in some form as an Informational document... I hope it answers questions that Fred and others had. It is a method in usage in universities that I know of. Any thoughts? Pekka? -- Tim From owner-v6ops@ops.ietf.org Thu Oct 28 10:59:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21161 for ; Thu, 28 Oct 2004 10:59:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNBja-000Alf-OV for v6ops-data@psg.com; Thu, 28 Oct 2004 14:58:38 +0000 Received: from [132.151.1.176] (helo=ietf.org) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNBjZ-000AlF-9T for v6ops@ops.ietf.org; Thu, 28 Oct 2004 14:58:38 +0000 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21049; Thu, 28 Oct 2004 10:58:34 -0400 (EDT) Message-Id: <200410281458.KAA21049@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-v6ops-3gpp-analysis-11.txt Date: Thu, 28 Oct 2004 10:58:34 -0400 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.2 required=5.0 tests=AWL,BAYES_00, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=2.64 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 : Analysis on IPv6 Transition in 3GPP Networks Author(s) : J. Wiljakka Filename : draft-ietf-v6ops-3gpp-analysis-11.txt Pages : 22 Date : 2004-10-27 This document analyzes the transition to IPv6 in Third Generation Partnership Project (3GPP) packet networks. These networks are based on General Packet Radio Service (GPRS) technology, and the radio network architecture is based on Global System for Mobile Communications (GSM), or Universal Mobile Telecommunications System (UMTS) / Wideband Code Division Multiple Access (WCDMA) technology. The focus is on analyzing different transition scenarios, applicable transition mechanisms and finding solutions for those transition scenarios. In these scenarios, the User Equipment (UE) connects to other nodes, e.g. in the Internet, and IPv6/IPv4 transition mechanisms are needed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-3gpp-analysis-11.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-3gpp-analysis-11.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-3gpp-analysis-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2004-10-28110100.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-v6ops-3gpp-analysis-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-v6ops-3gpp-analysis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-10-28110100.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-v6ops@ops.ietf.org Thu Oct 28 13:18:59 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23990 for ; Thu, 28 Oct 2004 13:18:58 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNDtt-0002tw-ND for v6ops-data@psg.com; Thu, 28 Oct 2004 17:17:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNDtC-0002mw-9M; Thu, 28 Oct 2004 17:16:42 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9SHGbt20090; Thu, 28 Oct 2004 20:16:37 +0300 Date: Thu, 28 Oct 2004 20:16:37 +0300 (EEST) From: Pekka Savola To: "Soliman, Hesham" cc: v6ops@ops.ietf.org, mip6@ietf.org, nemo@ietf.org, mip4@ietf.org, Tsirtsis George , miptrans@ops.ietf.org Subject: Re: MIP and transition issues In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hi, I've created a new mailing list to discuss Mobile IP transition issues. There is no single good mailing list to do that, and crossposting to upto 4 WGs is not a good idea. Address: miptrans@ops.ietf.org To subscribe: 'subscribe miptrans' in the body to majordomo@psg.com Web archives: http://ops.ietf.org/lists/miptrans/ **** DO NOT POST ANY FURTHER MESSAGES ON V6OPS LIST! **** (if you respond, please remove the other lists from Cc:) FWIW, I also noticed there is another related draft: Use of MIPv6 in IPv4 and MIPv4 in IPv6 networks draft-larsson-v6ops-mip-scenarios-00.txt (Larsson, Gustafsson, Levkowetz) As there have been various presentations on v6ops two times already, with no clear resolution, it would seem to be useful to have various people working on different documents bang their heads together on miptrans or offlist on which document(s) describing the problems and scenarios is the most appropriate as a basis for discussion. On Mon, 25 Oct 2004, Soliman, Hesham wrote: > Sorry for the cross posting, but this issue is being > discussed in all WG listed. > > I submitted the following two drafts last night: > draft-tsirtsis-dsmip-problem > draft-soliman-v4v6-mipv6- > > The first deals with the problem statement and the > second is one of the solution for using MIPv6 only. > There is another draft that proposes using MIPv4 > only: draft-tsirtsis-v4v6-mipv4 > > I hope we can discuss the problem statement and scenarios > in the next meeting. While the problem statement is on the mip6 > charter, it would be useful if we can have a slot allocated for > this in v6ops. > > thx > Hesham > > =========================================================== > This email may contain confidential and privileged material for the sole use > of the intended recipient. Any review or distribution by others is strictly > prohibited. If you are not the intended recipient please contact the sender > and delete all copies. > =========================================================== > > -- 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 Oct 28 23:48:12 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05081 for ; Thu, 28 Oct 2004 23:48:11 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNNhp-000FcM-Fo for v6ops-data@psg.com; Fri, 29 Oct 2004 03:45:37 +0000 Received: from [203.253.3.140] (helo=cns.ssu.ac.kr) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CNNho-000Fbt-1b for v6ops@ops.ietf.org; Fri, 29 Oct 2004 03:45:36 +0000 Received: from cnsljjang (203.253.3.137) by cns.ssu.ac.kr (203.253.3.140) with [Nmail V3.2 20020608(S)] for from ; Fri, 29 Oct 2004 12:51:40 +0900 From: =?ks_c_5601-1987?B?w9bAzryu?= To: Subject: RE: IPsec support for NAT-PT in IPv6 Date: Fri, 29 Oct 2004 12:45:33 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01C4BDB5.2E332310" X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcS69mxhet298fHlSqWdwkqirlRjkACc0KwA X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-1.1 required=5.0 tests=AWL,BAYES_00,HTML_70_80, HTML_FONTCOLOR_UNKNOWN,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Message-Id: This is a multi-part message in MIME format. ------=_NextPart_000_002E_01C4BDB5.2E332310 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit Hi, We have submitted a new draft on " IPsec support for NAT-PT in IPv6" The draft went in on Monday, but hasn't been announced. It is in the IETF repository though: http://www.ietf.org/internet-drafts/draft-choi-v6ops-natpt-ipsec-00.txt Abstract The NAT-PT, one of the IPv6 transition mechanisms, supports IPv6 node in a NAT-PT domain to communicate with IPv4-only node outside. However, due to the IP datagram conversion at the NAT-PT server, NAT-PT node has a problem in establishing the end-to-end security using the IPsec IKE and AH mode. This memo describes the reason why the problem is caused and proposes a solution for assuring the end-to-end security using IPsec in the NAT-PT environment. Comments welcome. -- Choi ------=_NextPart_000_002E_01C4BDB5.2E332310 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: quoted-printable

Hi,=

 

We have submitted a new draft on " = IPsec = support for NAT-PT in IPv6"

 

The draft went in on Monday, but hasn't been announced.  It is in the = IETF repository though:

 

http://www.ietf.org/internet-drafts/draft-c= hoi-v6ops-natpt-ipsec-00.txt

 

Abstract

 

   The NAT-PT, one of the IPv6 transition mechanisms, supports IPv6 = node

   in a NAT-PT domain to communicate with IPv4-only node = outside.

   However, due to the IP datagram conversion at the NAT-PT server,
   NAT-PT node has a problem in establishing the end-to-end = security
   using the IPsec IKE and AH mode. This memo describes the = reason why
   the problem is caused and proposes a solution for assuring = the
   end-to-end security using IPsec in the NAT-PT = environment.

 

Comments welcome.

 

 

 

--<= /p>

Choi

 

------=_NextPart_000_002E_01C4BDB5.2E332310-- From owner-v6ops@ops.ietf.org Fri Oct 29 04:15:56 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06375 for ; Fri, 29 Oct 2004 04:15:55 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNRtS-0003dJ-19 for v6ops-data@psg.com; Fri, 29 Oct 2004 08:13:54 +0000 Received: from [203.254.224.24] (helo=mailout1.samsung.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNRtQ-0003d2-JI for v6ops@ops.ietf.org; Fri, 29 Oct 2004 08:13:52 +0000 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6C00KEI6V2VM@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 29 Oct 2004 17:13:51 +0900 (KST) Received: from ep_mmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6C00AFS6QV93@mailout1.samsung.com> for v6ops@ops.ietf.org; Fri, 29 Oct 2004 17:11:19 +0900 (KST) Received: from Radhakrishnan ([107.108.71.64]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6C00KWZ6QU2P@mmp2.samsung.com> for v6ops@ops.ietf.org; Fri, 29 Oct 2004 17:11:19 +0900 (KST) Date: Fri, 29 Oct 2004 13:39:26 +0530 From: Radhakrishnan Suryanarayanan Subject: Revised version of draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt To: V6OPS WG Reply-to: Radhakrishnan Suryanarayanan Message-id: <087801c4bd8e$9c7beef0$40476c6b@sisodomain.com> Organization: SAMSUNG India Software Operations MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook Express 6.00.2800.1437 Content-type: multipart/alternative; boundary="Boundary_(ID_gDmnGvnAuN2qj4+YGG53qA)" X-Priority: 3 X-MSMail-priority: Normal X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.6 required=5.0 tests=AWL,BAYES_00, HTML_FONTCOLOR_BLUE,HTML_FONT_BIG,HTML_MESSAGE autolearn=no version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This is a multi-part message in MIME format. --Boundary_(ID_gDmnGvnAuN2qj4+YGG53qA) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [zct] draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - Unofficial = version {01}Hi all A revised version of = http://www.ietf.org/internet-drafts/draft-suryanarayanan-v6ops-zeroconf-r= eqs-00.txt is now available in=20 http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-req= s-01.txt=20 Please provide feedback on this draft. Regards Radhakrishnan From: Miguel =C1ngel Morales=20 To: Radhakrishnan Suryanarayanan=20 Cc: JORDI PALET MARTINEZ=20 Sent: Friday, October 29, 2004 1:02 PM Subject: Re: Please use this draft version Hi Radhakrishnan, the version of the draft you sent me is already uploaded, so you can = access to it at = http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-req= s-01.txt=20 Regads, Miguel =C1ngel=20 ----- Original Message -----=20 From: Radhakrishnan Suryanarayanan=20 To: Miguel Angel Morales=20 Cc: JORDI PALET MARTINEZ=20 Sent: Friday, October 29, 2004 6:53 AM Subject: Please use this draft version Hi Miguel, can you upload this .txt instead of the earlier one sent by Jordi = for placing in = http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-req= s-01.txt ????? Regards Radhakrishnan ----- Original Message -----=20 From: JORDI PALET MARTINEZ=20 To: zct@v6ops.euro6ix.net=20 Cc: Miguel Angel Morales=20 Sent: Friday, October 29, 2004 10:04 AM Subject: [zct] draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - = Unofficial version {02} Hi, I've read all the thread, and I mostly agree with the final shape of = the draft, except regarding the MUST (in my opinion) to support other = encapsulation methods. Anyway, as Pekka seems to be impatient ;-) I just uploaded this = version to: = http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-req= s-01.txt But for some reason I'm getting an error. Miguel Angel will take a = look first thing in the morning when he comes into the office, in about = 2-3 hours maximum. It will be the same URL, so by then you can announce = it. Regards, Jordi -------------------------------------------------------------------------= --- De: Radhakrishnan Suryanarayanan Organizaci=F3n: SAMSUNG India Software Operations Responder a: zct@v6ops.euro6ix.net Fecha: Thu, 28 Oct 2004 19:17:34 +0530 Para: zct@v6ops.euro6ix.net CC: Syam Madanapalli Asunto: [zct] draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - = Unofficial version {01} Hi all, I am herewith attaching the unofficial version 01 of = draft-suryanarayanan-v6ops-zeroconf-reqs-01. Please provide your inputs/comments. Regards Radhakrishnan =20 ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged = or confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or = confidential. The information is intended to be for the use of the = individual(s) named above. If you are not the intended recipient be = aware that any disclosure, copying, distribution or use of the contents = of this information, including attached files, is prohibited. --Boundary_(ID_gDmnGvnAuN2qj4+YGG53qA) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [zct] = draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - Unofficial version = {01}
Hi all
  A revised version of http://www.ietf.org/internet-drafts/draft-suryanarayanan-v6ops-zeroconf-reqs-00.txt is now available in=20
http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt=20
 
Please provide feedback on this = draft.
 
Regards
Radhakrishnan
 
From: Miguel =C1ngel = Morales
Sent: Friday, October 29, 2004 1:02 PM
Subject: Re: Please use this draft version

Hi Radhakrishnan,
 
the version of the draft you = sent=20 me is already uploaded, so you can access to it at http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt=20
 
Regads,
 
Miguel =C1ngel 
----- Original Message -----
From:=20 Radhakrishnan = Suryanarayanan
To: Miguel Angel = Morales=20
Sent: Friday, October 29, 2004 = 6:53=20 AM
Subject: Please use this draft=20 version

Hi Miguel,
  can you upload this = .txt=20 instead of the earlier one sent by Jordi for placing in http://www.v6ops.euro6ix.net/= ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt=20 ?????
 
Regards
Radhakrishnan
----- Original Message -----
From:=20 JORDI PALET MARTINEZ =
Cc: Miguel Angel = Morales=20
Sent: Friday, October 29, = 2004 10:04=20 AM
Subject: [zct]=20 draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - Unofficial version = {02}

Hi,

I=92ve read all the thread, and = I mostly=20 agree with the final shape of the draft, except regarding the MUST = (in my=20 opinion) to support other encapsulation methods.

Anyway, as = Pekka=20 seems to be impatient ;-) I just uploaded this version=20 to:
http://www.v6ops.euro6ix.net/= ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt

But=20 for some reason I=92m getting an error. Miguel Angel will take a = look first=20 thing in the morning when he comes into the office, in about 2-3 = hours=20 maximum. It will be the same URL, so by then you can announce=20 it.

Regards,
Jordi


De: Radhakrishnan Suryanarayanan=20 <rkrishnan.s@samsung.com>
Organizaci=F3n: SAMSUNG = India=20 Software Operations
Responder a:=20 zct@v6ops.euro6ix.net
Fecha: Thu, 28 Oct 2004 19:17:34 = +0530
Para: zct@v6ops.euro6ix.net
CC: Syam = Madanapalli=20 <smpalli@yahoo.com>
Asunto: [zct]=20 draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - Unofficial version = {01}

Hi=20 all,
  I am herewith attaching the unofficial version = 01 of=20 draft-suryanarayanan-v6ops-zeroconf-reqs-01.
Please provide your=20 inputs/comments.

Regards
Radhakrishnan
 




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

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



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

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

--Boundary_(ID_gDmnGvnAuN2qj4+YGG53qA)-- From owner-v6ops@ops.ietf.org Fri Oct 29 04:49:31 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08765 for ; Fri, 29 Oct 2004 04:49:31 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSR2-0008Py-NO for v6ops-data@psg.com; Fri, 29 Oct 2004 08:48:36 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSR0-0008PR-LC for v6ops@ops.ietf.org; Fri, 29 Oct 2004 08:48:35 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9T8mWF10091; Fri, 29 Oct 2004 11:48:33 +0300 Date: Fri, 29 Oct 2004 11:48:32 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org cc: jonne.soininen@nokia.com, agenda@ietf.org Subject: IETF61 draft agenda for v6ops Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Hello all, Find below the draft agenda for v6ops session at IETF61. Comments etc. are welcome either on or off-list, BUT REMOVE agenda@ietf.org FROM CC:! ============= * DRAFT * DRAFT * DRAFT * Wednesday 10th November -- 0900-1130 ==================================== (The date & time is still tentative.) *** CRITICAL PATH ACTIVITIES *** Introduction, agenda bashing, document status - 10 mins, Chairs/Savola - Scribes! (Jabber also?) Enterprise Analysis Discussion, 15 mins, Bound - draft-ietf-v6ops-ent-analysis-00.txt - GOAL: discuss issues, so that the revision can be WGLC'ed Generic Zero-Configuration Tunneling, 15 mins, ??? - http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt - GOAL: Present and discuss WG LC issues Goals for Zero-Configuration Tunneling in 3GPP, 10 mins, Nielsen - draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt> - present the 3GPP tunneling case and the technical goals/requirements - GOAL: To highlight the particularities of the 3GPP case Assisted Registered Tunneling Requirements - 10 mins, Parent - draft-ietf-v6ops-assisted-tunneling-requirements-01.txt - go through open issues, discuss - GOAL: discuss WGLC issues, if any *** OTHER IMPORTANT WORK *** IPv6 Network Architecture Protection, 10 mins, Van de Velde - draft-vandevelde-v6ops-nap-00.txt - GOAL: introduce and start the discussion about v4 NAT alternatives in IPv6 Reason to Deprecate NAT-PT, 15 mins, Davies - draft-aoun-v6ops-natpt-deprecate-00.txt - GOAL: 5 mins presentation, 10 mins trying to decide next steps ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt - GOAL: get feedback; gauge interest and the direction IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins, Tatuya - A new WIDE project to fix practical IPv6 deployment issues - GOAL: inform the WG of activities, solicit the interested people Discussion of Teredo IETF LC comments, 5 mins, Huitema - draft-huitema-v6ops-teredo-02.txt - GOAL: describe and discuss the important IETF LC comments IPv6 Security Overview - 5-7 mins, Davies - draft-savola-v6ops-security-overview-03.txt - GOAL: talk about differences, solicit more feedback Things to think about when renumbering, 5-7 mins, Thompson - draft-chown-v6ops-renumber-thinkabout-00.txt - GOAL: introduce the draft, solicit feedback for next revision IP Mobility Scenarios discussion, 5 mins, Someone? - draft-larsson-v6ops-mip-scenarios-00.txt ? - GOAL: update from the IP mobility scenarios/requirements discussion From owner-v6ops@ops.ietf.org Fri Oct 29 04:51:35 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08996 for ; Fri, 29 Oct 2004 04:51:35 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSTl-0008mX-Vt for v6ops-data@psg.com; Fri, 29 Oct 2004 08:51:25 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSTk-0008m9-M1 for v6ops@ops.ietf.org; Fri, 29 Oct 2004 08:51:25 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9T8pNR10200 for ; Fri, 29 Oct 2004 11:51:23 +0300 Date: Fri, 29 Oct 2004 11:51:23 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: WG last call on tunneling scenarios Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk (co-chair hats on) Hello, In the interest of moving forward from the tunneling requirements, we have discussed the situation with ADs, and will be proposing some actions. One of these is getting a reasonable consensus on the requirements for zero-config and registered assisted tunneling. In order to be able to discuss whether existing solutions fit the requirements, how they need to be modified, or which kind of new solutions should be specified, we'll have to get the requirements to a closure. But finishing the requirements will have to happen fast: in the event that there are issues for which there is no consensus, it'll be better to just document both sides of the argument fairly, and move on and evaluate the tradeoffs when selecting or specifying the solution(s). In order to achive this, we propose adopting the following as WG items: http://www.ietf.org/internet-drafts/draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt Please speak up if you object to this. In addition, we are issuing WG last call (for Informational) for: draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt draft-ietf-v6ops-assisted-tunneling-requirements-01.txt Please send the comments on the list, but specify clearly which document you're commenting on. Now is the last chance to speak up! The WG last call expires on Monday, 8th November (the IETF week). Pekka & Jonne co-chairs From owner-v6ops@ops.ietf.org Fri Oct 29 05:09:11 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09897 for ; Fri, 29 Oct 2004 05:09:10 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSkU-000BED-Ga for v6ops-data@psg.com; Fri, 29 Oct 2004 09:08:42 +0000 Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.41 (FreeBSD)) id 1CNSkT-000BDu-G5 for v6ops@ops.ietf.org; Fri, 29 Oct 2004 09:08:41 +0000 Received: (qmail 26018 invoked by uid 417); 29 Oct 2004 09:05:15 -0000 Received: from charleston-.softhome.net (HELO softhome.net) (172.16.2.12) by shunt-smtp-out-0 with SMTP; 29 Oct 2004 09:05:15 -0000 Received: from XPNERICK ([132.70.219.170]) (AUTH: LOGIN ericlklein@softhome.net) by softhome.net with esmtp; Fri, 29 Oct 2004 03:05:13 -0600 Message-ID: <003301c4bd96$41a653a0$0401a8c0@ttitelecom.com> From: "EricLKlein" To: "Pekka Savola" , v6ops@ops.ietf.org Cc: jonne.soininen@nokia.com, agenda@ietf.org References: Subject: Re: IETF61 draft agenda for v6ops Date: Fri, 29 Oct 2004 11:04:09 +0200 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.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Content-Transfer-Encoding: 7bit A small comment, I would think that putting these two sessions back to back would facilitate discussion: IPv6 Security Overview - 5-7 mins, Davies IPv6 Network Architecture Protection, 10 mins, Van de Velde I would recommend this sequence as they tend to flow one from the other. Eric ----- Original Message ----- From: "Pekka Savola" To: Cc: ; Sent: 29 October, 2004 10:48 AM Subject: IETF61 draft agenda for v6ops > Hello all, > > Find below the draft agenda for v6ops session at IETF61. Comments > etc. are welcome either on or off-list, BUT REMOVE agenda@ietf.org > FROM CC:! > > ============= > > * DRAFT * DRAFT * DRAFT * > > Wednesday 10th November -- 0900-1130 > ==================================== > (The date & time is still tentative.) > > *** CRITICAL PATH ACTIVITIES *** > > Introduction, agenda bashing, document status - 10 mins, Chairs/Savola > - Scribes! (Jabber also?) > > Enterprise Analysis Discussion, 15 mins, Bound > - draft-ietf-v6ops-ent-analysis-00.txt > - GOAL: discuss issues, so that the revision can be WGLC'ed > > Generic Zero-Configuration Tunneling, 15 mins, ??? > - http://www.v6ops.euro6ix.net/ietf/draft-suryanarayanan-v6ops-zeroconf-reqs-01.txt > - GOAL: Present and discuss WG LC issues > > Goals for Zero-Configuration Tunneling in 3GPP, 10 mins, Nielsen > - draft-nielsen-v6ops-3GPP-zeroconf-goals-00.txt> > - present the 3GPP tunneling case and the technical goals/requirements > - GOAL: To highlight the particularities of the 3GPP case > > Assisted Registered Tunneling Requirements - 10 mins, Parent > - draft-ietf-v6ops-assisted-tunneling-requirements-01.txt > - go through open issues, discuss > - GOAL: discuss WGLC issues, if any > > *** OTHER IMPORTANT WORK *** > > IPv6 Network Architecture Protection, 10 mins, Van de Velde > - draft-vandevelde-v6ops-nap-00.txt > - GOAL: introduce and start the discussion about v4 NAT alternatives in IPv6 > > Reason to Deprecate NAT-PT, 15 mins, Davies > - draft-aoun-v6ops-natpt-deprecate-00.txt > - GOAL: 5 mins presentation, 10 mins trying to decide next steps > > ISP IPv6 Deployment Scenarios in Broadband Access Networks, 15 mins, Popoviciu > - draft-asadullah-v6ops-bb-deployment-scenarios-01.txt > - GOAL: get feedback; gauge interest and the direction > > IPv6 Fix: an activity to solve barriers to IPv6 transition, 7-10 mins, Tatuya > - A new WIDE project to fix practical IPv6 deployment issues > - GOAL: inform the WG of activities, solicit the interested people > > Discussion of Teredo IETF LC comments, 5 mins, Huitema > - draft-huitema-v6ops-teredo-02.txt > - GOAL: describe and discuss the important IETF LC comments > > IPv6 Security Overview - 5-7 mins, Davies > - draft-savola-v6ops-security-overview-03.txt > - GOAL: talk about differences, solicit more feedback > > Things to think about when renumbering, 5-7 mins, Thompson > - draft-chown-v6ops-renumber-thinkabout-00.txt > - GOAL: introduce the draft, solicit feedback for next revision > > IP Mobility Scenarios discussion, 5 mins, Someone? > - draft-larsson-v6ops-mip-scenarios-00.txt ? > - GOAL: update from the IP mobility scenarios/requirements discussion > > > From owner-v6ops@ops.ietf.org Fri Oct 29 05:11:23 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10005 for ; Fri, 29 Oct 2004 05:11:23 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNSmq-000Blp-Gm for v6ops-data@psg.com; Fri, 29 Oct 2004 09:11:08 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNSmp-000Bkr-8l for v6ops@ops.ietf.org; Fri, 29 Oct 2004 09:11:07 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9T9B1w10817; Fri, 29 Oct 2004 12:11:02 +0300 Date: Fri, 29 Oct 2004 12:11:01 +0300 (EEST) From: Pekka Savola To: EricLKlein cc: v6ops@ops.ietf.org, jonne.soininen@nokia.com Subject: Re: IETF61 draft agenda for v6ops In-Reply-To: <003301c4bd96$41a653a0$0401a8c0@ttitelecom.com> Message-ID: References: <003301c4bd96$41a653a0$0401a8c0@ttitelecom.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk DO NOT COPY agenda@ietf.org! Inline, On Fri, 29 Oct 2004, EricLKlein wrote: > A small comment, I would think that putting these two sessions back to back > would facilitate discussion: > > IPv6 Security Overview - 5-7 mins, Davies > IPv6 Network Architecture Protection, 10 mins, Van de Velde > > I would recommend this sequence as they tend to flow one from the other. True, however, if we run out of time, it's more important to be able to discuss NAP than the security overview, hence that order. We'll consider whether to reorder these or not. -- 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 Oct 29 05:36:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11674 for ; Fri, 29 Oct 2004 05:36:15 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNTA9-000F79-2Y for v6ops-data@psg.com; Fri, 29 Oct 2004 09:35:13 +0000 Received: from [47.164.128.120] (helo=zctfs063.nortelnetworks.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNTA8-000F6k-05 for v6ops@ops.ietf.org; Fri, 29 Oct 2004 09:35:12 +0000 Received: from zctfc040.europe.nortel.com (zctfc040.europe.nortel.com [47.164.129.95]) by zctfs063.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i9T9Z9r13684 for ; Fri, 29 Oct 2004 11:35:09 +0200 (MEST) Received: by zctfc040.europe.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 29 Oct 2004 11:35:07 +0200 Message-ID: <8F20221FB47FD51190AD00508BCF36BA0D4581B2@znsgy0k3.europe.nortel.com> From: "Elwyn Davies" To: v6ops@ops.ietf.org Subject: New version of IPv6 Transition/Coexistence Security overview avai lable Date: Fri, 29 Oct 2004 11:34:59 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk This draft will be discussed at IETF61.. A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IPv6 Transition/Co-existence Security Considerations Author(s) : P. Savola, et al. Filename : draft-savola-v6ops-security-overview-03.txt Pages : 25 Date : 2004-10-27 The transition from a pure IPv4 network to a network where IPv4 and IPv6 co-exist brings a number of extra security considerations that need to be taken into account when deploying IPv6 and operating the dual-protocol network and the associated transition mechanisms. This document attempts to give an overview of the various issues grouped into three categories: Issues due to the IPv6 protocol itself, due to transition mechanisms, and due to the way in which IPv6 is being deployed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-savola-v6ops-security-overview-03. txt From owner-v6ops@ops.ietf.org Fri Oct 29 08:46:22 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25199 for ; Fri, 29 Oct 2004 08:46:21 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNW6m-000AKX-Bm for v6ops-data@psg.com; Fri, 29 Oct 2004 12:43:56 +0000 Received: from [192.44.77.17] (helo=laposte.rennes.enst-bretagne.fr) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNW6l-000AKF-2R for v6ops@ops.ietf.org; Fri, 29 Oct 2004 12:43:55 +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 i9TChnQ25657; Fri, 29 Oct 2004 14:43:49 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.12.3/8.12.3) with ESMTP id i9TChmSj037070; Fri, 29 Oct 2004 14:43:49 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200410291243.i9TChmSj037070@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: =?ks_c_5601-1987?B?w9bAzryu?= cc: v6ops@ops.ietf.org Subject: Re: IPsec support for NAT-PT in IPv6 In-reply-to: Your message of Fri, 29 Oct 2004 12:45:33 +0900. Date: Fri, 29 Oct 2004 14:43:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk In your previous mail you wrote: Comments welcome. => in section 2.1: The IP addresses are usually used as the ID values in this procedure. this is not true: draft-ietf-pki4ipsec-ikecert-profile-03.txt: ... Of these types, FQDN and USER_FQDN are RECOMMENDED over IP addresses (see discussion in Section 3.1.1). and in section 3.1.1 there is the rationale: Implementations SHOULD NOT populate ID payload with IP addresses due to interoperability issues such as problems with NAT traversal, and problems with IP verification behavior. So the solution is simple: avoid (put a MUST NOT) ID payload with IP addresses as it is already done for the NAT traversal. => section 2.2 describes a NAT problem, not a NAT-PT problem. I don't understand why section 3 doesn't try to extend the NAT traversal mechanism... => section 4 doesn't make sense : IKE already works well through a NAT. => idem for section 5. If the only issue is the transport checksum the current NAT traversal has NAT-OA payloads to fix it. So my recommendation is to refer to RFC 3715 (IPsec-Network Address Translation (NAT) Compatibility Requirements) and its companion solution I-D draft-ietf-ipsec-nat-t-ike-08.txt Regards Francis.Dupont@enst-bretagne.fr From owner-v6ops@ops.ietf.org Sat Oct 30 00:10:15 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12327 for ; Sat, 30 Oct 2004 00:10:14 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNkWA-0008Aq-CA for v6ops-data@psg.com; Sat, 30 Oct 2004 04:07:06 +0000 Received: from [131.228.20.27] (helo=mgw-x4.nokia.com) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNkW9-0008AW-3X for v6ops@ops.ietf.org; Sat, 30 Oct 2004 04:07:05 +0000 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9U472l06309; Sat, 30 Oct 2004 07:07:02 +0300 (EET DST) X-Scanned: Sat, 30 Oct 2004 07:06:44 +0300 Nokia Message Protector V1.3.31 2004060815 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id i9U46ij0029561; Sat, 30 Oct 2004 07:06:44 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00mshxsd; Sat, 30 Oct 2004 07:05:13 EEST Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id i9U45Ca25247; Sat, 30 Oct 2004 07:05:12 +0300 (EET DST) Received: from dadhcp-172019068136.americas.nokia.com ([172.19.68.140]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 29 Oct 2004 23:05:11 -0500 Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8) with ESMTP id i9U45A1H003530; Fri, 29 Oct 2004 21:05:10 -0700 Received: (from kessens@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.8/8.12.8/Submit) id i9U456Xb003528; Fri, 29 Oct 2004 21:05:06 -0700 Date: Fri, 29 Oct 2004 21:05:06 -0700 From: David Kessens To: Pekka Savola Cc: v6ops@ops.ietf.org Subject: Re: WG last call on tunneling scenarios Message-ID: <20041030040506.GA3476@nokia.com> 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-OriginalArrivalTime: 30 Oct 2004 04:05:11.0350 (UTC) FILETIME=[A6C21D60:01C4BE35] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk Pekka, Jonne, On Fri, Oct 29, 2004 at 11:51:23AM +0300, Pekka Savola wrote: > > But finishing the requirements will have to happen fast: in the event that > there are issues for which there is no consensus, it'll be better to just > document both sides of the argument fairly, and move on and evaluate the > tradeoffs when selecting or specifying the solution(s). While we appreciate your speed, and we don't have objections to adopting these documents, we think that it would be better to give people a couple of days to comment whether they agree that these documents should be adopted as working group documents and only issue a last call after that has been done. David Kessens & Bert Wijnen --- From owner-v6ops@ops.ietf.org Sat Oct 30 02:38:41 2004 Received: from psg.com (mailnull@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03082 for ; Sat, 30 Oct 2004 02:38:40 -0400 (EDT) Received: from majordom by psg.com with local (Exim 4.41 (FreeBSD)) id 1CNmqa-000Pjc-BG for v6ops-data@psg.com; Sat, 30 Oct 2004 06:36:20 +0000 Received: from [193.94.160.1] (helo=netcore.fi) by psg.com with esmtp (Exim 4.41 (FreeBSD)) id 1CNmqZ-000PjN-5C for v6ops@ops.ietf.org; Sat, 30 Oct 2004 06:36:19 +0000 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id i9U6aHH07114 for ; Sat, 30 Oct 2004 09:36:17 +0300 Date: Sat, 30 Oct 2004 09:36:17 +0300 (EEST) From: Pekka Savola To: v6ops@ops.ietf.org Subject: Re: WG last call on tunneling scenarios In-Reply-To: <20041030040506.GA3476@nokia.com> Message-ID: References: <20041030040506.GA3476@nokia.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on psg.com X-Spam-Status: No, hits=-4.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=2.64 Sender: owner-v6ops@ops.ietf.org Precedence: bulk On Fri, 29 Oct 2004, David Kessens wrote: > On Fri, Oct 29, 2004 at 11:51:23AM +0300, Pekka Savola wrote: >> >> But finishing the requirements will have to happen fast: in the event that >> there are issues for which there is no consensus, it'll be better to just >> document both sides of the argument fairly, and move on and evaluate the >> tradeoffs when selecting or specifying the solution(s). > > While we appreciate your speed, and we don't have objections to > adopting these documents, we think that it would be better to give > people a couple of days to comment whether they agree that these > documents should be adopted as working group documents and only issue > a last call after that has been done. Fair enough. Please send the objections (if any) on document adoption by the end of Tuesday 2nd November at the latest. Comments/review on the drafts themselves are still welcome! -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings