Re: [v4v6interim] [BEHAVE] [46translation] Proposal for new BEHAVE charter

Mark Townsley <townsley@cisco.com> Thu, 23 October 2008 14:48 UTC

Return-Path: <v4v6interim-bounces@ietf.org>
X-Original-To: v4v6interim-archive@ietf.org
Delivered-To: ietfarch-v4v6interim-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A9653A696E; Thu, 23 Oct 2008 07:48:56 -0700 (PDT)
X-Original-To: v4v6interim@core3.amsl.com
Delivered-To: v4v6interim@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2983A6883; Thu, 23 Oct 2008 07:48:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.539
X-Spam-Level:
X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 RbQhGEe1bI1b; Thu, 23 Oct 2008 07:48:54 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 6F27F3A6823; Thu, 23 Oct 2008 07:48:53 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.33,470,1220227200"; d="scan'208";a="23535722"
Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 23 Oct 2008 14:50:10 +0000
Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m9NEo9At031630; Thu, 23 Oct 2008 16:50:09 +0200
Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m9NEo9Dp018038; Thu, 23 Oct 2008 14:50:09 GMT
Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 16:50:09 +0200
Received: from ams-townsley-8711.cisco.com ([10.55.233.226]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Oct 2008 16:50:09 +0200
Message-ID: <49008F1E.3010804@cisco.com>
Date: Thu, 23 Oct 2008 16:50:06 +0200
From: Mark Townsley <townsley@cisco.com>
User-Agent: Thunderbird 2.0.0.17 (Macintosh/20080914)
MIME-Version: 1.0
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
References: <48F8539D.90608@ericsson.com> <48FB9C5E.8070402@gmail.com> <3E041E8D-8539-4A16-9188-86A1DCEEE62B@muada.com> <200810201358.29295.remi.denis-courmont@nokia.com> <8E5328A8-4937-41A8-A650-204795E074D1@muada.com> <5B78195C-1318-4325-8F98-BC19F59E1532@cisco.com> <01462145-8E18-465A-8989-D1C98D421DED@muada.com> <B5A2E7E1-7FAE-48B6-85E2-B1300DF1458D@cisco.com> <9E0384AB-A20B-44E7-8575-9275101FF920@muada.com> <49008B8E.9080408@ericsson.com>
In-Reply-To: <49008B8E.9080408@ericsson.com>
X-OriginalArrivalTime: 23 Oct 2008 14:50:09.0172 (UTC) FILETIME=[A515A540:01C9351E]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2543; t=1224773409; x=1225637409; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20<townsley@cisco.com> |Subject:=20Re=3A=20[v4v6interim]=20[BEHAVE]=20[46translati on]=20Proposal=20for=20new=20BEHAVE=0A=20charter |Sender:=20; bh=D9VQ6yVggQPHgrYrhFWxhY43h2ko8OHMzXZIEkdLe3M=; b=hNpwmygYT+G9TYZ8f0KYao18rFxQih30EU1/a2ZKuaervROVN2zdVNMd/n +Db/CT0uTnvSeOivqERnTvcdO8tEOZULkWq1zGW28/AXfjT6jOh4D2obtKX9 cU880CpQjc;
Authentication-Results: ams-dkim-1; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; );
Cc: v4v6interim@ietf.org, Behave WG <behave@ietf.org>, 46Translation <46translation@employees.org>
Subject: Re: [v4v6interim] [BEHAVE] [46translation] Proposal for new BEHAVE charter
X-BeenThere: v4v6interim@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of coexistence topics for the 01-Oct-2008 v4-v6 coexistence interim meeting <v4v6interim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/v4v6interim>
List-Post: <mailto:v4v6interim@ietf.org>
List-Help: <mailto:v4v6interim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v4v6interim>, <mailto:v4v6interim-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

Magnus Westerlund wrote:
> Anyway,
>
> Are anyone that thinks that NAT66 is so important that it takes
> precedence over the NAT46 translator work? If not, can we postpone this
> until we are ready to publish something on address family translators?
>
> The reason I ask the above is that we will have enough work for all the
> people in the translator work. Thus trying to avoid splitting the forces
> to thinly.
>   
The NAT66 should be relatively straightforward, and could actually help 
highlight some of the reasons why 46 and 64 become problematic. NAT66 is 
a question that comes up again and again when talking about deploying 
IPv6, and I honestly think it would be useful to have a document to 
point to that brought light to and articulated some of the issues, gave 
strong warning where necessary, and described what was relatively safe 
and what not.

It doesn't really have to be part of behave though.  Magnus, I fully 
understand if you are looking at this new behave charter and can't 
imagine another thing on your plate. As Margaret and others mentioned, 
this can go through int-area, 6man, or some such.

- Mark
> Magnus
>
> Iljitsch van Beijnum skrev:
>   
>> On 21 okt 2008, at 11:50, Fred Baker wrote:
>>
>>     
>>> As to the rest of what you said, I'll agree with you that in a very
>>> real sense that ship has sailed, and I'll point out that we run the
>>> same protocols on IPv6 that we run on IPv4. If we have indeed made the
>>> protocols NAT-accepting for IPv4, I'll bet they are NAT-accepting on
>>> IPv6 as well.
>>>       
>> If only things were this simple.
>>
>> Many apps that break with NAT do referrals by IP address. So they must
>> be updated to work with IPv6, and gain significant additional logic to
>> work in a dual stack world. Things like STUN and ICE and their
>> proprietary counterparts thus need to be reinvented/implemented for v6
>> to make referrals work, and/or the UPnP/NAT-PMP protocols that open up
>> ports in NAT devices must be recreated for IPv6 if port overloading
>> NAT66s happen.
>>
>> Today the routing people are complaining that the IPv6 builders didn't
>> fix routing. I wonder if in 10 years the apps people are going to
>> complain that we didn't fix NAT but just let the same thing happen as in
>> IPv4 which BEHAVE has been trying to clean up.
>> _______________________________________________
>> Behave mailing list
>> Behave@ietf.org
>> https://www.ietf.org/mailman/listinfo/behave
>>
>>     
>
>
>   

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