RE: [BEHAVE] Can we have on NAT66 discussion?

"Hallam-Baker, Phillip" <pbaker@verisign.com> Thu, 13 November 2008 15:06 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418163A690F; Thu, 13 Nov 2008 07:06:07 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE9193A68AF; Thu, 13 Nov 2008 07:06:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.202
X-Spam-Level:
X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rZ6T6wAvTU5R; Thu, 13 Nov 2008 07:06:05 -0800 (PST)
Received: from colibri.verisign.com (colibri.verisign.com [65.205.251.74]) by core3.amsl.com (Postfix) with ESMTP id 2C8B23A6806; Thu, 13 Nov 2008 07:06:05 -0800 (PST)
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by colibri.verisign.com (8.13.6/8.13.4) with ESMTP id mADEk2Dq025246; Thu, 13 Nov 2008 06:46:02 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 13 Nov 2008 07:06:04 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [BEHAVE] Can we have on NAT66 discussion?
Date: Thu, 13 Nov 2008 07:06:04 -0800
Message-ID: <2788466ED3E31C418E9ACC5C316615572FFB3F@mou1wnexmb09.vcorp.ad.vrsn.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [BEHAVE] Can we have on NAT66 discussion?
Thread-Index: AclFmpO0RJD4VnciSMKbgqpSsFwe6gABGaBb
References: <CA10A01F-D7A4-4769-BB06-7AF0FCC61F75@muada.com> <courier.491ACAEB.000010B8@softhome.net> <courier.491AEBCE.000003E0@softhome.net> <21E58B55-65E2-4E95-9876-B9418A983BC8@lilacglade.org> <491BFCCD.1040005@cisco.com> <18d24aa20811130428g38183456ia296294bec0a1bf8@mail.gmail.com> <491C3569.4010803@cisco.com>
From: "Hallam-Baker, Phillip" <pbaker@verisign.com>
To: Mark Townsley <townsley@cisco.com>, Eric Klein <ericlklein.ipv6@gmail.com>
X-OriginalArrivalTime: 13 Nov 2008 15:06:04.0994 (UTC) FILETIME=[59794220:01C945A1]
Cc: Routing Research Group Mailing List <rrg@irtf.org>, Behave WG <behave@ietf.org>, v6ops@ietf.org, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2040528775=="
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

I beleive that the question would not arise If we had a coherent Internet architecture
 
The idea that an application can or should care that the IP address of a packet is constant from source to destination is plain bonkers. It was no an assumption in the original Internet architecture and should not be an assumption that any application should rely on.
 
If you want to effect a transition from IPv4 to IPv6, the only way to do that effectively is to design a protocol stack in which the applications simply do not care whether their packets are routed over IPv4, IPv6 or carrier pidgeon.
 
NAT66 is in fact a security requirement in many applications and in others it is a compliance requirement. Stampy feet protests that the idea is profane don't change those facts.
 
I know that there are some people in the security area who claim otherwise but they have been wrong on many issues in the past and they are likely wrong on this one. Let us consider for a minute the list of real world security measures that the IETF has successfully deployed, well there is DKIM (sort of) and there is the post-facto cleanup of SSL after it was successful and the post facto cleanup of X.509 after that was successful. IPSEC is used as a VPN solution despite being unsuited for the role as originally designed. 
 
On the negative side the same consensus that opposes NAT66 has in the past opposed firewalls, the single most widely used network security control. It has also promoted the idea of algorithm proliferation and negotiation as a good thing (these days we consider it bad). It has promoted the idea that the most important feature in a security protocol is that it be absolutely secure against theoretical attacks rather than easy enough to deploy and use that people actually use it.
 
And yes, I have been guilty of many of the same mistakes. But unlike some folk I am not about to compound that mistake by telling the folk who want NAT66 that they should visit a re-education camp and unlearn their heretical thoughts. 
 
The only reason NAT is bad in practice is because some people were so opposed to the concept that they decided it would be a good thing to allow designs that were purposefully designed to be NAT-unfriendly. 
 
 
If we don't want to have these discussions on the IETF list we should have a separate architecture list. 
 
NAT66 is a reasonable protocol proposal to make. If BEHAVE does not like the idea let the advocates start a new group.

________________________________

From: ietf-bounces@ietf.org on behalf of Mark Townsley
Sent: Thu 11/13/2008 9:10 AM
To: Eric Klein
Cc: Routing Research Group Mailing List; Behave WG; v6ops@ietf.org; ietf@ietf.org
Subject: Re: [BEHAVE] Can we have on NAT66 discussion?



Eric Klein wrote:
> Mark,
> 
> I agree with the sentiment, the problem is that the 5 different groups
> are doing different things that all relate back to NAT in v6 (rather
> than just coexistence) each under their own charter.
> 
> I have had suggestions that I bring this to ietf or inter-area mailing
> lists for general consensus on a need and IETF overall position prior
> to defining a solution.
> Behave seems a little limited in scope for the decision about do we or
> don't we want to allow any form of native mode NAT into v6.
I agree, and it is not behave's place to make that decision at this
time. I had originally proposed that this be discussed in int-area (if
nothing else because behave's plate is rather full), but some folks
pointed out that some modes may have affects on applications and that
behave was best able to determine that, particularly within context of
the other NATxy work. I'm looking forward to that assessment. So for now
this should remain discussion to understand the problem space and
potential solution space better, not a final referendum on whether or
not the IETF is going to charter work in or otherwise endorse NAT66 in
any manner.

Thanks,

- Mark
> 
> Eric
> On Thu, Nov 13, 2008 at 12:09 PM, Mark Townsley <townsley@cisco.com
> <mailto:townsley@cisco.com>> wrote:
>
>
>     I would prefer not to have the same discussion again and again in
>     multiple places. Let's just try and stick to behave for the
>     moment, though at some point if the work continues it would need
>     to be passed around elsewhere. We are not chartering the work one
>     way or another at the moment, for now this is merely "discussion"
>     of the topic.
>
>     - Mark
>
>
>
>
>
>     Margaret Wasserman wrote:
>
>
>         Hi Eric,
>
>         According to the ADs and WG chairs, the correct forum for the
>         NAT66 discussion is the BEHAVE WG.  So, let's discuss it there.
>
>         Margaret
>
>         On Nov 12, 2008, at 9:44 AM, EricLKlein@softhome.net
>         <mailto:EricLKlein@softhome.net> wrote:
>
>             Cross posted to several lists
>             Can we keep the NAT66 discussion to less than WGs at a time?
>             I am trying to keep up with multiple threads on this and
>             trying to explain that we do not have a valid requirement
>             for NAT66 defined on any of the mailing lists (v6OPS,
>             BEHAVE, Softwires, RRG, and now v6).
>             Le's get this to one group (maybe we need a new mailing
>             list just for NAT66 discussions, but this is getting out
>             of hand.
>             Until now the simple response is that "the IETF does not
>             support NAT in the v6 architecture." If this needs
>             changing lets do it right with proper gap analysis and
>             needs assessment, and then seeing if there is a solution
>             (several have been proposed that are not NAT) or if we
>             need to create one, and if those fail then see about
>             changing the architecture of IPv6.
>             Eric _______________________________________________
>             Behave mailing list
>             Behave@ietf.org <mailto:Behave@ietf.org>
>             https://www.ietf.org/mailman/listinfo/behave
>
>
>         _______________________________________________
>         Behave mailing list
>         Behave@ietf.org <mailto:Behave@ietf.org>
>         https://www.ietf.org/mailman/listinfo/behave
>
>
>     _______________________________________________
>     Behave mailing list
>     Behave@ietf.org <mailto:Behave@ietf.org>
>     https://www.ietf.org/mailman/listinfo/behave
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>  

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf