Re: Comments on the NAT66 draft

EricLKlein@softhome.net Sun, 09 November 2008 06:42 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 16B783A68CF for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 8 Nov 2008 22:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[AWL=-0.453, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, 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 TnaHhF69i--Q for <ietfarch-v6ops-archive@core3.amsl.com>; Sat, 8 Nov 2008 22:42:18 -0800 (PST)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 34F2A3A63EC for <v6ops-archive@lists.ietf.org>; Sat, 8 Nov 2008 22:42:18 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.69 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Kz3z7-0005Ky-La for v6ops-data@psg.com; Sun, 09 Nov 2008 06:41:21 +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 1Kz3z2-0005Jk-BC for v6ops@ops.ietf.org; Sun, 09 Nov 2008 06:41:18 +0000
Received: (qmail 12901 invoked by uid 417); 9 Nov 2008 06:40:46 -0000
Received: from mambo- (HELO softhome.net) (172.16.2.15) by shunt-smtp-out-0 with SMTP; 9 Nov 2008 06:40:46 -0000
Received: from localhost (localhost [127.0.0.1]) (uid 417) by softhome.net with local; Sat, 08 Nov 2008 23:40:46 -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> <courier.4915760A.00007FB9@softhome.net> <20081108134500.GX89033@Space.Net>
In-Reply-To: <20081108134500.GX89033@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 23:40:46 -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.175.130]
Message-ID: <courier.491685EE.00003026@softhome.net>
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Gert Doering writes: 

On Sat, Nov 08, 2008 at 04:20:42AM -0700, EricLKlein@softhome.net wrote:
>> 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. 
> 
> Well, the thing that I keep hearing is "we want to be able to change
> providers at our whim and not renumber" (not from "SOHO" customers, but
> from "a bit larger networks").

Having worked for 2 telecom operators and supported multiple ISPs I have 
never heard this request from customer. Renumbering has always been a 
problem and all of the DHCP solutions to fix it still exist. 

What I am guessing that they are saying is "I don't want to be tied to a 
specific ISP forever so I want an easy way to reconfigure when I change". 
And for the occasional change (maximum of what 1 time per year?) I do not 
think that breaking end-to-end links is the answer. 

If this is what they want then lets bring back site locals (I am sure that 
some people will implement them and not notice that they were depreciated 
anyway). This at least is a straight forward fix that will not require 
bringing back NAT into v6. 

> 
> Two possible answers 
> 
>   - IPv6 PI space ("everybody's routing table gets hit")
>   - ULA space inside, NAT66 outside 
> 
> so what's the smaller evil?  I can't say. 
> 
> (Regarding the "renumbering" bit: I didn't write "we can't renumber" - 
> but for a largish network, renumbering can incur much much higher costs
> than just finding a vendor that provides a NAT66 box... and as soon as
> enterprise customers are going to ask vendors about it, one of them will
> build one.  Well, I think you could already do that today with BSD 
> pf(4)...)

I disagree, if it is understood that using "a NAT66 box" means that VoIP, 
Video, PTP, and firewalls will not work as expected then the cost will be 
much higher than reassigning numbers in the DHCP pool. 

> From an ISP point of view, I'd actually prefer NAT66 before IPv6 PI.   
> 
> Of course "everyone of our customers will stay there forever, so there's
> no need to ever renumber" would be much preferred, but I think this is
> about as unrealistic as assuming that there won't be NAT66 boxes.

As I said above, Site locals are preferable to NAT or IPv6 PI, don't break 
the end to end connectivity and don't undermine the security benefits of a 
consistent address through out the link.