Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)

Ca By <cb.list6@gmail.com> Wed, 27 September 2017 23:37 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E302913515A for <v6ops@ietfa.amsl.com>; Wed, 27 Sep 2017 16:37:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cA7ISDa29QtA for <v6ops@ietfa.amsl.com>; Wed, 27 Sep 2017 16:37:30 -0700 (PDT)
Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0272E135187 for <v6ops@ietf.org>; Wed, 27 Sep 2017 16:37:29 -0700 (PDT)
Received: by mail-yw0-x229.google.com with SMTP id u11so10427873ywh.7 for <v6ops@ietf.org>; Wed, 27 Sep 2017 16:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RL+HXgy38zavVDx0CF1iB1SIK6U2W7EZ4jtoSbYhjPk=; b=BceEAqq1F0YRYmUAFVsSUgoC1Dka53Dy2LjTFMUp7g3f+4gN9mu2zS2vnXI/lAM37z bVk1A83VMYiKf1AW13cISWqF1Gl5oqKz8WnP0yx2D8LNMeWo+4IdwyeyJjzMUIPRnUrY X0xLeFG5BVk1TREK01tgUC17ZC88MFXNJZscJ4/yEib6PpIZR3PMsW/HrIhhJ8921RRX y8J2Zk8tcU6N3YdzkE/JPmMESxjv5SA2j6kAdu3lquEMFJSDNC8DUFzJokHIfGMEkKot zk2egPPrCNchZFXeI0xWAN8jOxmoTLmSnpOOVLyRzfs6O04FwEGObjtnY2WUako2eOWf CeMw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RL+HXgy38zavVDx0CF1iB1SIK6U2W7EZ4jtoSbYhjPk=; b=W6JJts3/J02TX9/oTVl/Pr6sjOKxfrnh+94YCv9P7nVGR3q2SdqBYVKB9n01m1LdPX mAX5yS8wYULqjNpduqXBPob4sK/uD00Gs0I0pEMzuBQtHab1COfrj2mDVua/EOwvbX9A ZxtpOm/ebWBfQnJXbM8MMlol2p8GWxBgbL9uuBNMpZMu8l/8gSqsquBcYJ5GaEQ3HBJi m2xHtLzfdNcSsQqRKQBZPwfkhBLawyWz6OYWJdO3N/WxlT69RF7lGQDuAN0UjgY3mpJ1 Dp/yzHMARRULdhby3aAQrYkSYlLdnRQCzcH2lc0oiqwFIES3qWoHTOt+4759hg7qOTzu OxFQ==
X-Gm-Message-State: AHPjjUiDpOuWOntivhBCATawisOWqltS5rg3Ci5ybMYf/QeRDCvYnWsd xBuRICiKBLQaaM+ZQ+7uJKGJtUyqo+gx9SstHbA=
X-Google-Smtp-Source: AOwi7QAsGYN2A81Z5pbDERPgVQTnpRcG8MEpQCifuhlTFmL3iRuRZstjv3P2jqxwiMdvR7owqEGxwRAqeBeRlvajxdM=
X-Received: by 10.13.239.2 with SMTP id y2mr2173000ywe.65.1506555449133; Wed, 27 Sep 2017 16:37:29 -0700 (PDT)
MIME-Version: 1.0
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <46045DAA-9096-43BA-A5FD-571232767726@google.com> <CAKD1Yr3vziaHfkR+hQ7QHXaz7QraKH2HLUVXUW63GpnOAj4JoQ@mail.gmail.com> <E72C3FBE-57A4-4058-B9E5-F7392C9E9101@google.com> <LO1P123MB0116805F9A18932E2D0694FEEA780@LO1P123MB0116.GBRP123.PROD.OUTLOOK.COM> <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org>
In-Reply-To: <1496304E-54BE-47FA-A7F1-1AA6E163DAB1@employees.org>
From: Ca By <cb.list6@gmail.com>
Date: Wed, 27 Sep 2017 23:37:18 +0000
Message-ID: <CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com>
To: "Heatley, N, Nick, TQB R" <nick.heatley@bt.com>, Ole Troan <otroan@employees.org>
Cc: IPv6 Ops WG <v6ops@ietf.org>, james woodyatt <jhw@google.com>
Content-Type: multipart/alternative; boundary="94eb2c0350586155d6055a3446a5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/zrOx4tOvLsbziYl-paswhq1XB2s>
Subject: Re: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Sep 2017 23:37:33 -0000

On Wed, Sep 27, 2017 at 3:43 PM Ole Troan <otroan@employees.org> wrote:

> > A specific example: certain vpn clients, still in service, fail when
> tethered to a nat64/dns64 device. Typically, a customer is tethering their
> work machine to their personal handset. NAT64/DNS64 does not provide what
> the client needs and neither can the OS. Such client SW may be older but is
> still in service, they are not yet end of support.
> >
> > Customers care if this breaks. So do I, this is doing harm. And no, they
> won't revert to their corp IT dept. They know this relates to their
> provider.
> > With 464xlat these usecases simply work.
> > I have zero calls into customer services concerning devices with 464xlat.
> >
> > 464xlat is the reason why IPv6-only can work where the end OS is unknown.
> > IPv6-only for the handset mass-market is the way to mitigate exhaustion.
>
> 464xlat is a mechanism to deliver IPv4 service across an IPv6 transport.
> Yes, it mitigates exhaustion. - By sharing a single IPv4 address among
> more and more end-users.
> It's just like any other CGN, with the differences being that you need CE
> support and you can disable IPv4 in the access network.
>
> MAP-E, MAP-T, DS-lite, Configured tunnels, L2 NAT... pretty much all do
> the same.
> The main difference is where session state is kept.
>
> 464XLAT or more commonly deployed 44464XLAT is the worst of any
> combination. It keeps sessions state both at the CE/CLAT and the BR/PLAT.
> Building scalable stateful devices is hard and expensive. And in the case
> of IPv4 sharing mechanisms unnecessary.
>
> Ole


Ole, Mark, and James — always good to have the non-operator viewpoint.
Insightful observations as always.

Nick has offered the “hey we did 464xlat, it worked, no regrets” case
study, also insightful.

I am trying to stay out of this discussion about purity of one solution vs
the other.  I was happy to leave that discussion years ago and move on with
real work.

But i like helping people, so i can share some insight

Slide 4 of a deck

https://www.ietf.org/proceedings/98/slides/slides-98-maprg-measuring-trends-in-ipv6-support-tommy-pauly-00.pdf

The blue area is not one of constant growth.  The lesson is that what James
said does not fly with mobile subscribers that can change carriers.  They
want their “broken” apps. That said, i have it on good word that blue blob
is  thriving now that we added some additional control points to allows
people to use “broken” apps.  Life is good.

Another data point

http://www.worldipv6launch.org/measurements/

As of today in the top 25, Numbers 7, 11, 17, 18 (i think), and 20 have
deployed 464xlat.  Pretty good real world stats moving real v6 packets for
what Ole calls “the worst” and Mark calls “sexy”.

And, i will reinterate an important point Nick made. The majority of
traffic goes e2e ipv6. A minority of traffic requires NAT64/DNS64. And a
sliver of traffic requires 464XLAT or 4464.  Those numbers are all growing
in the right direction, more e2e v6.




> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>