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 >
- [v6ops] 464xlat case study (was reclassify 464XLA… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Simon Hobson
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… james woodyatt
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Lorenzo Colitti
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Fred Baker
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… JORDI PALET MARTINEZ
- Re: [v6ops] 464xlat case study (was reclassify 46… Ole Troan
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Mark Andrews
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] 464xlat case study (was reclassify 46… Rajiv Asati (rajiva)
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Heatley,N,Nick,TQB R
- Re: [v6ops] 464xlat case study (was reclassify 46… Mikael Abrahamsson
- Re: [v6ops] 464xlat case study (was reclassify 46… Gert Doering
- Re: [v6ops] 464xlat case study (was reclassify 46… Ca By
- Re: [v6ops] 464xlat case study (was reclassify 46… Alexandre Petrescu
- Re: [v6ops] DHCPv6-PD presence on OSs, and GTP qu… Alexandre Petrescu
- Re: [v6ops] 464xlat case study (was reclassify 46… Erik Kline
- Re: [v6ops] DHCPv6-PD presence on OSs, and GTP qu… Mikael Abrahamsson
- Re: [v6ops] GTP questions Alexandre Petrescu
- Re: [v6ops] GTP questions Ca By
- Re: [v6ops] GTP questions Rajiv Asati (rajiva)
- Re: [v6ops] GTP questions Alexandre Petrescu