Re: [BEHAVE] Comments on the NAT66 draft

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 06 November 2008 20:29 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A51B3A696C for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 6 Nov 2008 12:29:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.522
X-Spam-Level:
X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=-1.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1]
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 YIpPzlTYnI97 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 6 Nov 2008 12:29:46 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id E9A133A6950 for <v6ops-archive@lists.ietf.org>; Thu, 6 Nov 2008 12:29:45 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KyBPS-0001ZA-CS for v6ops-data@psg.com; Thu, 06 Nov 2008 20:24:54 +0000
Received: from [209.85.198.227] (helo=rv-out-0506.google.com) by psg.com with esmtp (Exim 4.69 (FreeBSD)) (envelope-from <brian.e.carpenter@gmail.com>) id 1KyBPN-0001YL-8L for v6ops@ops.ietf.org; Thu, 06 Nov 2008 20:24:51 +0000
Received: by rv-out-0506.google.com with SMTP id b25so821653rvf.41 for <v6ops@ops.ietf.org>; Thu, 06 Nov 2008 12:24:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=INKZ54TssTW8boE+JDb9n/z08NIG69HqXyZizfodwk8=; b=t78Z4E0CpcnUgH8MYwWJ8Zm4sGiX8kGb7a4WGrntnQOTZohYUFQ4fYCgmVQ7Rkg8uI VxN5nPfDBJRjp/xGPq0JJ5ZR1R5wdz4Tc7tL86Z5pkkv3x0GvghEKZ5cu/fCoE3k+A14 uhnguY7gM9tiFuyrSKGZXddhs1s8DORvVypU8=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=tAVBR2BeUwOgSvy84tpUGyXYKFQkN3L+bKYBEmQ7z9wCW5+G+48e5UwtxlIN5YM2PS /r1EHcbAaScZ+lZkHFNqkqr863X+wa04DQMhnAWjwj9V8MSQFRrvAKBg92M6xemKxjXP LF7BPy07m5sLWwwlrvQqvkc84fyZRctoo32G4=
Received: by 10.141.76.21 with SMTP id d21mr1442953rvl.154.1226003087632; Thu, 06 Nov 2008 12:24:47 -0800 (PST)
Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id l31sm5584780rvb.2.2008.11.06.12.24.45 (version=SSLv3 cipher=RC4-MD5); Thu, 06 Nov 2008 12:24:47 -0800 (PST)
Message-ID: <4913528C.2000207@gmail.com>
Date: Fri, 07 Nov 2008 09:24:44 +1300
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Wes Beebee (wbeebee)" <wbeebee@cisco.com>
CC: Iljitsch van Beijnum <iljitsch@muada.com>, Margaret Wasserman <mrw@lilacglade.org>, v6ops@ops.ietf.org, Behave WG <behave@ietf.org>, EricLKlein@softhome.net
Subject: Re: [BEHAVE] Comments on the NAT66 draft
References: <4911B9E7.8090108@free.fr> <BB56240F3A190F469C52A57138047A03014762B5@xmb-rtp-211.amer.cisco.com> <courier.4912CE09.00003CB8@softhome.net> <BB56240F3A190F469C52A57138047A03014765AF@xmb-rtp-211.amer.cisco.com> <6BB0BB30-7AA4-4821-B9EB-4703794F3C87@muada.com> <BB56240F3A190F469C52A57138047A03014765DF@xmb-rtp-211.amer.cisco.com>
In-Reply-To: <BB56240F3A190F469C52A57138047A03014765DF@xmb-rtp-211.amer.cisco.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Wes,

On 2008-11-07 03:40, Wes Beebee (wbeebee) wrote:
> I guess RFC 4864 doesn't go quite far enough - it says (paraphrasing): 
> You shouldn't need NAT66 because there are other ways to accomplish your
> goals which may be existing or under development at IETF.  

And the weakness in that is that although we have the gap analysis
in 4864, we do *not* have an adequate work plan to fill those gaps.
(ADs: I hope you are reading this.) Until we do, the emperor is
missing a few vital items of clothing.

> 
> Are we prepared to make a stronger statement here?  Are we prepared to
> say: 
> If you use NAT66, then be prepared for interoperability problems with
> IETF specifications because we WILL NOT design around your box, and,
> furthermore, that all the reasons you would want such a box have been
> fully accomodated through other means which are all in a good enough
> state for you to deploy today.

I think it's unrealistic to say that. We can put strong health warnings
in the draft, but we can't assert that other means exist for everything
until that becomes true (see above). We know very well that we can't
make that 'WILL NOT' assertion, because that isn't how our industry,
or the IETF, works. I'm unhappy about this but we have to be realistic.

MAT66 works for me because it makes it clear that this is not NAPT66.

   Brian

> 
> - Wes
> 
> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch@muada.com] 
> Sent: Thursday, November 06, 2008 9:15 AM
> To: Wes Beebee (wbeebee)
> Cc: EricLKlein@softhome.net; Margaret Wasserman; v6ops@ops.ietf.org;
> Behave WG
> Subject: Re: [BEHAVE] Comments on the NAT66 draft
> 
> On 6 nov 2008, at 14:59, Wes Beebee (wbeebee) wrote:
> 
>> As we move to IPv6, NAT44, NAT64, and NAT46 will eventually go away.  
>> The problem with helping NAT66 (even when that is not your
>> intent) is that once it catches on, it'll be in the Internet forever 
>> and will never go away.
> 
>> "NATs necessary for IPv6, says IETF chair"
>> http://www.networkworld.com/news/2008/072109-nat-housley-qna.html
> 
>> Once NAT66 gets out, I can imagine even more damaging headlines (which
> 
>> conveniently miss all the subtleties of the message in section 3 of 
>> http://www.ietf.org/internet-drafts/draft-mrw-behave-nat66-00.txt)
>> : "IETF Standardizes IPv6-to-IPv6 NAT".
> 
> Well, if that's what we want to avoid, we shouldn't be coy and come out
> and say that IPv6 NAT won't be accommodated in IETF protocols.
> 
> What seems to be happening today is that we all look the other way and
> pretend the issue doesn't exist, because we either assume that of course
> there won't be any IPv6 NAT or of course there will. So we are on our
> way ending up with the same situation that we encountered with
> IPv4: suddenly, it's no longer realistically possible to deploy a
> protocol that isn't NAT-friendly, but there are so many different NATs
> that it's impossible to be friendly to them all, and many of them
> operate is very suboptimal ways that could have been avoided with some
> forethought.
> _______________________________________________
> Behave mailing list
> Behave@ietf.org
> https://www.ietf.org/mailman/listinfo/behave
>