Re: IPv6 NAT?

Stjepan Gros <sgros@zemris.fer.hr> Fri, 15 February 2008 09:06 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietfarch-ietf-archive@core3.amsl.com
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 108FC28CF73; Fri, 15 Feb 2008 01:06:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.641
X-Spam-Level:
X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GUARANTEED_100_PERCENT=0.012, HELO_MISMATCH_ORG=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 SI2l6alFJWgg; Fri, 15 Feb 2008 01:06:19 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7AE3A6958; Fri, 15 Feb 2008 01:06:18 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 011423A67A1 for <ietf@core3.amsl.com>; Fri, 15 Feb 2008 01:06:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 4ed0kyxHlMPJ for <ietf@core3.amsl.com>; Fri, 15 Feb 2008 01:06:16 -0800 (PST)
Received: from iluvatar.zemris.fer.hr (iluvatar.zemris.fer.hr [161.53.65.13]) by core3.amsl.com (Postfix) with ESMTP id C59463A63EC for <ietf@ietf.org>; Fri, 15 Feb 2008 01:06:15 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 5F183100090; Fri, 15 Feb 2008 09:01:04 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at zemris.fer.hr
Received: from iluvatar.zemris.fer.hr ([127.0.0.1]) by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eURwEXRri-2; Fri, 15 Feb 2008 10:00:59 +0100 (CET)
Received: from [197.100.1.8] (78-0-129-193.adsl.net.t-com.hr [78.0.129.193]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id D352E10000E; Fri, 15 Feb 2008 10:00:58 +0100 (CET)
Subject: Re: IPv6 NAT?
From: Stjepan Gros <sgros@zemris.fer.hr>
To: Dan York <dyork@voxeo.com>
In-Reply-To: <249EE7D5-250E-446A-8B12-35DB0E8CD303@voxeo.com>
References: <47B2B315.7050107@gmx.net> <158a01c86e3b$dbd9d0b0$6401a8c0@china.huawei.com> <D03E4899F2FB3D4C8464E8C76B3B68B001F2BBDF@E03MVC4-UKBR.domain1.systemhost.net> <873arvp8kv.fsf@mid.deneb.enyo.de> <1128DF92-CFB4-47A3-BBA3-DA86754630A0@muada.com> <249EE7D5-250E-446A-8B12-35DB0E8CD303@voxeo.com>
Organization: FER - ZEMRIS
Date: Fri, 15 Feb 2008 10:06:36 +0100
Message-Id: <1203066396.4860.15.camel@fedora.centrala.partner-banka.hr>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-1.fc8)
Cc: Florian Weimer <fw@deneb.enyo.de>, Iljitsch van Beijnum <iljitsch@muada.com>, ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

On Thu, 2008-02-14 at 17:12 -0500, Dan York wrote:
> 
> On Feb 14, 2008, at 4:16 PM, Iljitsch van Beijnum wrote:
> 
> > On 14 feb 2008, at 21:49, Florian Weimer wrote:
> > 
> > 
> > > The prevailing assumption is that IPv6 end nodes will be globally
> > > addressable for practical purporses.  I think this is a very
> > > unlikely
> > > outcome.
> > 
> > 
> > Are you saying that there will be IPv6 NAT?
> 
> 
> Absolutely.  100% guaranteed that some organizations out there will
> continue to use NAT even with IPv6.  
> 
> 
> In my opinion, anyone who thinks otherwise does not understand how
> wedded corporate enterprises are to NAT and how NAT will only be
> removed when the keyboard is pulled from the cold, dead fingers of the
> last remaining sysadmins.
> 
> 
> Instead of the "private addresses" of IPv4 as defined in RFC1918 it
> will simply be the "Unique Local Addresses" of IPv6 as defined in
> RFC4193 - http://tools.ietf.org/rfcmarkup?doc=rfc4193  Instead of
> starting with 10. (or 192. or 172.), the address block will start with
> FC00... but the end result will be the same.  (And look, this time
> around it even has it's own TLA ("ULA")!)
> 
> 
> Corporate enterprises love NAT for several reasons. Here are two:
> 
> 
> 1. "SECURITY" - There is this belief that an organization is more
> secure by hiding the topology of their entire network behind a few
> public addresses that can be locked down and secured by appropriate
> firewalls and gateways.  IT staff don't give a darn about our glorious
> visions of end-to-end connectivity... they only care about "securing
> the perimeter" and many (most?) see NAT as one way of doing that.  We
> can argue endlessly that this may simply be an illusion (delusion?) on
> their part and that NAT really doesn't provide real security, but from
> what I have seen it *is* the prevailing view out there within the IT
> community.
> 
> 
> 2. CONTROL - Organizations like the control that comes with defining
> their own address ranges.  They don't need to obtain permission from
> anyone to number certain networks.  They just do it.  Simple. Easy.
>  They can create a master plan across all their locations on their
> WAN.  As they add more networks through growth (either new
> installations or through mergers/acquisitions), they can simply assign
> those new networks numbering blocks out of their master plan.  In
> fact, I would argue that ULA addressing (there I go with that TLA!)
> makes that even nicer since the recommended means of generation of the
> ULA block (in RFC4193) *should* wind up reducing the conflicts we have
> today where merging entities are both using identical sections of the
> RFC1918 10.x block. In theory the networks should be even easier to
> merge.  Likewise, if a network gets split off from another one, it may
> be able to be merged into its new owner very easily (and without
> renumbering) via ULA addressing.
> 
> 
> In this last instance, think of what happens if I'm using assigned
> IPv6 addresses from Company A and now my network is sold to Company B.
> Now I have to renumber my entire network to use Company B's assigned
> IPv6 addresses.  If I just use ULA addressing I don't have to renumber
> (unless by some freak chance I happen to be using the same ULA block
> that some other network in Company A is using).
> 
> 
> So yes, I absolutely think that NAT will continue in IPv6.  Corporate
> enterprises are comfortable with it and expect it.  That's the
> reality.

All that said, what happens when organizations would like to use multihoming?
In that case NATs create problems as flows have to use the same
exit/entry point, and when one of the connections breaks all the flows
going through the given connection will also be broken?

How is this problem solved in current IPv4 networks?

Thanks,
Stjepan

_______________________________________________
Ietf mailing list
Ietf@ietf.org
http://www.ietf.org/mailman/listinfo/ietf