Re: there _is_ IPv6 NAT - just look for it (was: A Plea for Architectural & Specification Stability with IPv6)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 14 March 2014 21:30 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAD981A01E4 for <ipv6@ietfa.amsl.com>; Fri, 14 Mar 2014 14:30:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WbGXw2uUQcuA for <ipv6@ietfa.amsl.com>; Fri, 14 Mar 2014 14:30:10 -0700 (PDT)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB041A01D1 for <ipv6@ietf.org>; Fri, 14 Mar 2014 14:30:09 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id s2ELU1FG028082 for <ipv6@ietf.org>; Fri, 14 Mar 2014 22:30:01 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id F10682081ED for <ipv6@ietf.org>; Fri, 14 Mar 2014 22:31:18 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id E9867207FC3 for <ipv6@ietf.org>; Fri, 14 Mar 2014 22:31:18 +0100 (CET)
Received: from [127.0.0.1] ([132.166.86.2]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id s2ELToZW030755 for <ipv6@ietf.org>; Fri, 14 Mar 2014 22:30:01 +0100
Message-ID: <532374CD.3040100@gmail.com>
Date: Fri, 14 Mar 2014 22:29:49 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: ipv6@ietf.org
Subject: Re: there _is_ IPv6 NAT - just look for it (was: A Plea for Architectural & Specification Stability with IPv6)
References: <E2C06D73-99FF-42B5-A3BE-337C307BCB0E@gmail.com> <CAKD1Yr0fjSWfPDkvc9Z53xBKxMGzYcVGzH3tLUGbjCKmgR_Duw@mail.gmail.com>
In-Reply-To: <CAKD1Yr0fjSWfPDkvc9Z53xBKxMGzYcVGzH3tLUGbjCKmgR_Duw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ipv6/OMfHk88Jtk-JaxFoo4XaDQiIAbg
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Mar 2014 21:30:13 -0000

Le 13/03/2014 15:27, Lorenzo Colitti a écrit :
[...]
> It's true that those that want IPv6 to be exactly like IPv4 are
> disappointed, because IPv6 is not IPv4. No, you can't do routing without
> RAs. No, you can't "save addresses" by making host subnets /120s (at
> least not easily). No, there is no RFC1918. No, ULAs are not the same as
> RFC1918. No, there is no NAT.

Yes there is IPv6 NAT an dit works just like in IPv4.

Alex


  But I think that in a lot of scenarios
> those are advantages, not disadvantages.
>
> When people say that IPv6 can't be deployed in ISPs, in enterprise
> networks, in content providers, in home networks, or in mobile networks
> because it lacks feature X, we'd do well to remember that there are
> large deployments of IPv6 in all these areas. I know, because I've
> personally been involved in all of the above. In my experience, excuses
> for not deploying IPv6 are, to a great extent, just that: excuses. They
> have no relationship to the actual reason for not deploying it, which
> is, and has always been, "we see no benefit" (or, to a lesser extent,
> "our code doesn't support it", and "our code has bugs" -- both of which
> are temporary). These excuses mislead the IETF into thinking that the
> lack of IPv6 deployment means that there is somehow something wrong with
> the protocol. This in turn causes hand-wringing and standards-writing,
> but in my experience, that doesn't help: when we remove an excuse,
> people move on to another excuse -- because the excuse wasn't the real
> reason anyway.
>
> Continued tinkering with IPv6 - especially tinkering with it to make it
> look more and more like IPv4 in order to reduce imagined "barriers to
> adoption" - will just erode IPv6's long-term advantages by eliminating
> the simplification, robustness, and benefits that IPv6 as it is today
> *does* provide -- and it won't lead to adoption anyway, because lack of
> adoption is not a technical issue.
>
> What we need to do now is stick to the protocols as designed and wait
> until the combination of ever-increasing pain caused by IPv4 exhaustion,
> and exponentially-increasing IPv6 deployment in the Internet at large
> (or at least in the consumer space), change the "there's no benefit"
> equation. That *does* have the power to cause deployment in a way which
> changing the standards will never have -- and as you put it, the more we
> change now, the more we *delay* deployment, by causing vendors to write
> code that then needs to be waited for, tested, and debugged before
> operators can deploy.
>
> Personally, I think 6man has the duty to ensure that no radical changes
> go into the core protocols until *real deployment experience* -- not of
> the "I can't deploy because..." kind, but only of the "I deployed *and
> it didn't work because...*" kind -- shows that there is really a gap in
> functionality, and even then, to think extremely carefully whether the
> long-term effects will be beneficial or not. We're hoping that this IPv6
> thing is going to last us for the next 30 years. Let's not get too hung
> up on the next 3.
>
>
> Cheers,
> Lorenzo
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>