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

Alain Durand <alain_durand@cable.comcast.com> Thu, 23 October 2008 16:57 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 19EBF3A6912; Thu, 23 Oct 2008 09:57:39 -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 BE4BC3A6960; Thu, 23 Oct 2008 09:57:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.104
X-Spam-Level: **
X-Spam-Status: No, score=2.104 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, J_CHICKENPOX_13=0.6, RCVD_NUMERIC_HELO=2.067]
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 yAGOTo7jyrhf; Thu, 23 Oct 2008 09:57:36 -0700 (PDT)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by core3.amsl.com (Postfix) with ESMTP id 91C7A3A6912; Thu, 23 Oct 2008 09:57:35 -0700 (PDT)
Received: from ([10.52.116.30]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.17436103; Thu, 23 Oct 2008 12:58:22 -0400
Received: from PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) by PAOAKEXCSMTP01.cable.comcast.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Oct 2008 12:58:21 -0400
Received: from 147.191.223.149 ([147.191.223.149]) by PACDCEXCMB06.cable.comcast.com ([24.40.15.22]) via Exchange Front-End Server webmail.comcast.com ([24.40.8.152]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Oct 2008 16:58:21 +0000
User-Agent: Microsoft-Entourage/12.12.0.080729
Date: Thu, 23 Oct 2008 12:58:19 -0400
From: Alain Durand <alain_durand@cable.comcast.com>
To: Cullen Jennings <fluffy@cisco.com>, Mark Townsley <townsley@cisco.com>
Message-ID: <C526256B.1C487%alain_durand@cable.comcast.com>
Thread-Topic: [v4v6interim] [BEHAVE] [46translation] Proposal for new BEHAVEcharter
Thread-Index: Ack1KXRIt+5f0az+SxaeSi3vqUz1XQABxhP4
In-Reply-To: <A1BB57A1-8B5F-44FF-85BE-C533D0FAE85D@cisco.com>
Mime-version: 1.0
X-OriginalArrivalTime: 23 Oct 2008 16:58:21.0490 (UTC) FILETIME=[8E103920:01C93530]
Cc: v4v6interim@ietf.org, 46Translation <46translation@employees.org>, Behave WG <behave@ietf.org>
Subject: Re: [v4v6interim] [BEHAVE] [46translation] Proposal for new BEHAVEcharter
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-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: v4v6interim-bounces@ietf.org
Errors-To: v4v6interim-bounces@ietf.org

I'm going to jump into this and probably not make friends...

IPv6 is just like IPv4 with longer addresses. This is where deployment
reality trumps architectural purity.

What I've seen in the last 3 years is that it is much, much easier to deploy
IPv6 if you keep the exact same operational model as in IPv4. This is one
(among many) reason why we pushed for DHCPv6.

Many folks are considering NAT44 as a simple solution where they just have
to put a box in front of their network to make whatever problem they think
they have go away. I can easily see that the same people would like to do
the same thing with IPv6. Which exact problem they were solving is
irrelevant to this discussion, the point is about preserving the same
operational model.

That, and Cullen Jennings point #2 argue for defining NAT66 exactly the same
way as NAT44, ie with (optional) port translation. We have the opportunity
to explain why some choices are less worse than others in doing so and put
all the caveats in place. That is, make sure all the behave work done for
NAT44 is immediately integrated in NAT66, or in  other words, lets define
NAT66 in behave. Now, we may argue about the urgency of doing this... Ie
should this be done in parallel as NAT64 & NAT46 or after.

   - Alain.


On 10/23/08 12:06 PM, "Cullen Jennings" <fluffy@cisco.com> wrote:

> 
> 
> On Oct 23, 2008, at 9:47 AM, Mark Townsley wrote:
> 
>> 
>> 
>> Cullen Jennings wrote:
>>> 
>>> I'm not worked up one way or the other about if we should specify
>>> NAT66 or not - however, if we do specify it, I am very concerned
>>> about how we do that. I see one good reason not to specify NAT66
>>> and two good reasons to.
>> 
>> Since saying nothing and hoping folks will abstain doesn't work very
>> well in practice, I'd rather we go in and describe safe NAT66 the
>> best we can. I agree that we have to be careful to do a good job, as
>> teaching bad NAT66 could be worse than not teaching it at all.
>> 
>>> 
>>> Reasons not to do NAT 66:
>>> 1) All the reasons explained in RFC 4864
>>> 
>>> Reason to do it:
>>> 1) Limitations of RFC 4864 as explained in 4864
>>> 2) Large vendors are building nat66 today and they are doing it in
>>> a way that breaks applications and leaves the application designers
>>> with no idea about what they can count on working and what they
>>> can't count on.
>>> 
>>> If #2 does not remind you of how we got into so much trouble nat44,
>>> well it should. Because of the impact on NAT66 on applications, if
>>> IETF does decide to do NAT66 specifications, I think it is very
>>> important that the specification is developed not only in the
>>> context of v6ops people but is also developed with input of folks
>>> from applications that need to use it. Today that would roughly
>>> mean behave.
>> I think that something that operates only at the IP layer could stay
>> in the int-area.
> 
> If the mapping was purely and 1:1 mapping between internal and
> external IPs I would agree with you but unfortunately, I worry that
> meeting the requirement that drive section 4.4 of 4864 (privacy and
> topology hiding) really complicate trying to do it with 1:1 mapping at
> IP level.
> 
> If you want to be able hide that two uncorrelated sessions are
> actually coming from the same internal host, well, I'm not sure I see
> how to do this with 1:1 mappings. One might argue that one should
> ignore these requirements but this is one of key areas where some
> people feel that 4864 has limitations that drive the deployment of
> NAT66. Two solutions I have seen for this are a) different external IP
> for every internal flow b) doing port address translation similar to
> NAPT in NAT44. Either of these choices has some pretty substantial
> impacts on how to make applications like VoIP work.
> 
> 
> 
> 
> 
> _______________________________________________
> v4v6interim mailing list
> v4v6interim@ietf.org
> https://www.ietf.org/mailman/listinfo/v4v6interim

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