Re: Comments on the NAT66 draft

EricLKlein@softhome.net Sat, 08 November 2008 11:24 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 BF1DF3A68BE for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 8 Nov 2008 03:24:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.626
X-Spam-Level:
X-Spam-Status: No, score=-0.626 tagged_above=-999 required=5 tests=[AWL=-0.789, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_13=0.6, 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 8J+loA9TnuwG for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 8 Nov 2008 03:24:27 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 21BA43A67A6 for <v6ops-archive@lists.ietf.org>; Sat, 8 Nov 2008 03:24:22 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1KylsW-0003yq-KF for v6ops-data@psg.com; Sat, 08 Nov 2008 11:21:20 +0000
Received: from [66.54.152.27] (helo=jive.SoftHome.net) by psg.com with smtp (Exim 4.69 (FreeBSD)) (envelope-from <EricLKlein@softhome.net>) id 1KylsR-0003yD-As for v6ops@ops.ietf.org; Sat, 08 Nov 2008 11:21:17 +0000
Received: (qmail 13376 invoked by uid 417); 8 Nov 2008 11:20:42 -0000
Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 8 Nov 2008 11:20:42 -0000
Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Sat, 08 Nov 2008 04:20:42 -0700
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> <courier.4914868B.00003F53@softhome.net> <20081108093045.GV89033@Space.Net>
In-Reply-To: <20081108093045.GV89033@Space.Net>
From: EricLKlein@softhome.net
To: Gert Doering <gert@space.net>
Cc: Iljitsch van Beijnum <iljitsch@muada.com>, Margaret Wasserman <mrw@lilacglade.org>, v6ops@ops.ietf.org, Behave WG <behave@ietf.org>, "Wes Beebee \\\"\\(wbeebee\\)" <wbeebee@cisco.com>
Subject: Re: Comments on the NAT66 draft
Date: Sat, 08 Nov 2008 04:20:42 -0700
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Sender: EricLKlein@softhome.net
X-Originating-IP: [62.219.107.149]
Message-ID: <courier.4915760A.00007FB9@softhome.net>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Gert, 

4 years ago we had this discussion on the v6OPS and in spite of the various 
arguments Site Local addresses were depreciated, and RFC4864 -  Local 
Network Protection for IPv6 was approved. 

Back then I proposed that we just allocate 0::(RFC 1918 address) as a 
necessary fix to the perceived need for NAT. After much debate and 
discussion I joined the team writing RFC 4864 on why NAT was not needed and 
thus was not part of v6. 

Unlike the historical development of 1918, here the WG took a serious look 
and made a preemptive decision about NAT addresses and thus should not need 
to back fill to fit a solution that will be industry dictated due to lack of 
available addresses. 

I have yet to hear one serious reason why we need NAT in v6 given that all 
of the requirements that lead to it and have kept it alive for years in v4 
do not exist in v6 and in some cases using it will break v6 functionality. I 
agree that NAT64 and NAT46 are needed during the transition period, but why 
break v6 as it is being adopted to meet some outdated technical and 
extensive marketing related requirements? 

Gert Doering writes: 

> We have seen in IPv4 how well that approach works "close our eyes and
> pretend that NAT is not going to happen". 
> 
> I agree with those posts that said "NAT66 will appear, and the IETF should
> make sure that it's done in a way that will have predictible effects on
> applications". 
> 
Yes I anticipate that people will try to find a loophole to get the 
perceived benefits of NAT in v6, and yes I am sure that some vendors will be 
willing to put marketing over good engineering. But I think we need to make 
a clear statement that v6 NAT IS NOT supported and WILL cause unpredictable 
problems that can lead to loss of connectivity or failure of services, 
otherwise v6 is just v6 on steroids and loosed most of the end-to-end 
connectivity and security features that will make it useful for the next 
generation of applications. 

> As for the specifics: having 1:1 NAT without port rewriting, maybe even
> just swapping the first /64 bits, is what should serve the purpose of
> "I want to be able to change providers, on a whim, without renumbering
> my internal network", while at the same time having fairly little impact
> on applications.   
> 

This is why they have DHCPv6, one small change on the DHCP server and the 
whole network should renumbered. 

> Regarding the "topology hiding" argument - well, people can use privacy 
> extentions on their hosts, no? 
>

Yes, and it does away with one of the myths that NAT is needed for security. 

Eric