Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP

Chris Grundemann <cgrundemann@gmail.com> Thu, 16 February 2012 15:43 UTC

Return-Path: <cgrundemann@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 667BE21F85DA for <ietf@ietfa.amsl.com>; Thu, 16 Feb 2012 07:43:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.669
X-Spam-Level:
X-Spam-Status: No, score=-3.669 tagged_above=-999 required=5 tests=[AWL=-0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnQwcVyW0yBq for <ietf@ietfa.amsl.com>; Thu, 16 Feb 2012 07:43:14 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id C46DA21F85AE for <ietf@ietf.org>; Thu, 16 Feb 2012 07:43:14 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so2796215pbc.31 for <ietf@ietf.org>; Thu, 16 Feb 2012 07:43:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=obGLsgEhJFB+mI6MxtOwtiqn6EOtmBusF8j04D5hFuE=; b=RnJsNXEqxnEaxpH5QTvyUtXsTa9q2bgtOgDe4KGlLTKEiY0ar8jNzDuDCnmUbAxByE sEK/zvdG6WN+BUob1TfcAatmwLyaYCLxbxTabcqLPjzJoM56Vpc6bGUIRVLBjd/jx2iH TWeWzTvsMWbart7OJ4tmxQ+LR94vDiZYbM9zo=
MIME-Version: 1.0
Received: by 10.68.193.232 with SMTP id hr8mr9278596pbc.158.1329406994627; Thu, 16 Feb 2012 07:43:14 -0800 (PST)
Received: by 10.68.60.200 with HTTP; Thu, 16 Feb 2012 07:43:14 -0800 (PST)
In-Reply-To: <1329388980.5382.44.camel@davinci.millnert.se>
References: <CB5FF399.1B4E7%jeff.finkelstein@cox.com> <4F3AAA08.2040204@qualcomm.com> <01OBZ9WQSHWY00ZUIL@mauve.mrochek.com> <4F3ABF6C.1030803@qualcomm.com> <m2d39hi267.wl%randy@psg.com> <4F3B09C3.1090005@qualcomm.com> <1329388980.5382.44.camel@davinci.millnert.se>
Date: Thu, 16 Feb 2012 08:43:14 -0700
Message-ID: <CAC1-dtnJ77PgMmfeYJHZfO13C10ckznuseVyEECAb8dUPoj1ew@mail.gmail.com>
Subject: Re: Last Call: <draft-weil-shared-transition-space-request-14.txt> (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
From: Chris Grundemann <cgrundemann@gmail.com>
To: Martin Millnert <martin@millnert.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Feb 2012 15:43:19 -0000

On Thu, Feb 16, 2012 at 03:43, Martin Millnert <martin@millnert.se> wrote:

> This is 100% matched by an allocation of globally unique space from a
> RIR, shared by whoever the interested parties are.
>  The IETF *need not* specify any BCP on how to improve NAT444
> "CGN"-scale alone, because such action is attached with high risk of
> leading to a local maximum in a plot of the state of the Internet,
> rather than towards a global maximum.
>
> Citing RFC6264, "An Incremental Carrier-Grade NAT (CGN) for IPv6
> Transition" warns:
>   Carrier-Grade NAT (CGN) [CGN-REQS], also called NAT444 CGN or Large
>   Scale NAT, compounds IPv4 operational problems when used alone but
>   does nothing to encourage IPv4 to IPv6 transition.  Deployment of
>   NAT444 CGN allows ISPs to delay the transition and therefore causes
>   double transition costs (once to add CGN and again to support IPv6).
>
> The draft as written, makes no effort to require the RFC6264 or
> equivalent approaches to a IPv6 transition, to the CGN deployments it
> specifies v4 address space for. All carrot, no stick.
>  I believe the state of the Internet would be much more reliably
> improved by the RIRs each having (for the purpose of being able to serve
> their own users) one /10 special allocation for this purpose, which they
> can assign to multiple users upon demonstrating, under contract, they
> are transitioning to IPv6 according to 6264, or equivalent.
>
> As written there is no effort to mitigate the risk mentioned in the
> quote above, and I can't support a draft that will hurt the Internet and
> neither should you.

Apologies for my bluntness, but this argument is a complete
misinterpretation of the facts on the ground. This draft is not about
encouraging nor facilitating CGN deployments. Allocating a /10 for
inside CGN addressing use _will not_ make anyone deploy CGN who would
not have otherwise done so. Not allocating a /10 for inside CGN
addressing use _will not_ stop anyone from deploying CGN who would
have otherwise done so. In fact, neither you nor I nor the IETF can
stop operators who must deploy CGN for business continuity from doing
so. What we can do, is ensure that when those folks who must deploy
CGN do so, that they break the Internet as little as possible. And
_that_ is what this I-D seeks to accomplish. And that is why I support
it, and why you should too.

Cheers,
~Chris


> Best,
> Martin
>
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf
>



-- 
@ChrisGrundemann
http://chrisgrundemann.com