IETF Logo Mail Archive

Re: [v6ops] reclassify 464XLAT as standard instead of info

Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com> Mon, 25 September 2017 09:06 UTC

Return-Path: <Tomasz.Kossut@orange.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 BF29F13314B for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 02:06:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 GyBpojYr5jvJ for <v6ops@ietfa.amsl.com>; Mon, 25 Sep 2017 02:06:08 -0700 (PDT)
Received: from mailin.tpsa.pl (mailout.tpsa.pl [212.160.172.10]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92C6F133091 for <v6ops@ietf.org>; Mon, 25 Sep 2017 02:06:07 -0700 (PDT)
Received: from 10.236.51.103 (EHLO PE16MR03.tp.gk.corp.tepenet) ([10.236.51.103]) by mailin.tpsa.pl (MOS 4.4.2a-FCS FastPath queued) with ESMTP id HHB29683; Mon, 25 Sep 2017 11:05:29 +0200 (CEST)
From: Kossut Tomasz - Hurt <Tomasz.Kossut@orange.com>
To: Lorenzo Colitti <lorenzo@google.com>, Mark Andrews <marka@isc.org>, "Erik Kline (ek@google.com)" <ek@google.com>
CC: Gert Doering <gert@space.net>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
Thread-Index: AQHTNaKV6eV3QehFxE+9XU+uWne+sqLFQOLw
Date: Mon, 25 Sep 2017 09:05:12 +0000
Message-ID: <4bf16a40ffd44e9498babf7094b1e526@orange.com>
References: <E48DDA04-C058-4992-906E-8C8BC0E102AB@consulintel.es> <1BFA3605-4B16-4331-A7BA-3BDECBCA64EC@gmail.com> <85868796-18C7-48F4-BE69-8D50A1F47EF3@jisc.ac.uk> <472CC0F7-73C2-4A21-8F96-BBC966B01B77@employees.org> <de6b9aac-a3cc-0915-77c7-9fb880c3a16a@gmail.com> <20170921223305.B72A8878E716@rock.dv.isc.org> <CAKD1Yr13ijKCB_71_2vMyGurc3-kSraLJycGxZwf121tjp8u1Q@mail.gmail.com> <20170922070719.74AA687A424E@rock.dv.isc.org> <20170922114847.GV45648@Space.Net> <369B3917-D9F3-41D4-A7BD-DAE134310004@employees.org> <20170922122146.GY45648@Space.Net> <20170922212502.E0CFF87B00BA@rock.dv.isc.org> <CAKD1Yr0VdmS0APz-G5VmxMNY1y9Kj+g0VP4Jx0_MXLkqkVyE8Q@mail.gmail.com>
In-Reply-To: <CAKD1Yr0VdmS0APz-G5VmxMNY1y9Kj+g0VP4Jx0_MXLkqkVyE8Q@mail.gmail.com>
Accept-Language: pl-PL, en-US
Content-Language: pl-PL
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [126.182.101.113]
X-TM-AS-Product-Ver: SMEX-12.0.0.1727-8.100.1062-23350.005
X-TM-AS-Result: No--28.150000-0.000000-31
X-TM-AS-MatchedID: 150567-700274-702131-700401-861142-700755-106660-706561-7 00057-700075-106640-702190-704421-390218-709850-106541-701461-702796-709584 -704156-702801-848947-701629-705450-702216-703130-704572-703747-701738-7060 65-709908-703303-188198-700245-701618-121195-863299-712133-707997-710207-70 1848-105700-863828-703267-704989-139704-113220-708196-111604-188119-700362- 705718-700345-701827-700264-702497-704425-700732-701012-701306-852490-70045 0-702638-700758-700537-709859-708075-863174-701594-702791-703707-188038-111 605-700074-303242-700079-111610-188057-188093-148004-148036-148046-148133-2 0020-42003
X-TM-AS-User-Approved-Sender: Yes
X-TM-AS-User-Blocked-Sender: No
Content-Type: multipart/alternative; boundary="_000_4bf16a40ffd44e9498babf7094b1e526orangecom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Junkmail-Premium-Raw: score=8/50, refid=2.7.2:2017.9.25.81516:17:8.907, ip=, rules=__HAS_FROM, FROM_NAME_PHRASE, __TO_MALFORMED_2, __TO_NAME, __TO_NAME_DIFF_FROM_ACC, __HAS_CC_HDR, __MULTIPLE_RCPTS_CC_X2, __CC_NAME, __CC_NAME_DIFF_FROM_ACC, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __SUBJ_ALPHA_END, __HAS_MSGID, __SANE_MSGID, __MSGID_32HEX, __REFERENCES, __IN_REP_TO, WEBMAIL_XOIP, __HAS_XOIP, __CT, __CTYPE_MULTIPART_ALT, __CTYPE_HAS_BOUNDARY, __CTYPE_MULTIPART, __MIME_VERSION, WEBMAIL_X_IP_HDR, __MIME_TEXT_P2, __MIME_TEXT_H2, __ANY_URI, __URI_NO_WWW, ECARD_KNOWN_DOMAINS, __SUBJ_ALPHA_NEGATE, __C230066_P5, SUPERLONG_LINE, __MULTIPLE_URI_TEXT, __URI_IN_BODY, __URI_NOT_IMG, __HTML_FONT_BLUE, __STYLE_RATWARE_NEG, __STYLE_TAG, __HAS_HTML, __HTML_TAG_DIV, BODY_SIZE_10000_PLUS, BODYTEXTP_SIZE_3000_LESS, BODYTEXTH_SIZE_3000_MORE, __MIME_TEXT_H1, __MIME_TEXT_P1, __MIME_HTML, __TAG_EXISTS_HTML, __RATWARE_SIGNATURE_3_N1, __URI_NS, [TRUNCATED]
X-Junkmail-Status: score=10/50, host=mailin.tpsa.pl
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0C0202.59C8C6DA.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32, mode=multiengine
X-Junkmail-IWF: false
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A0C0202.59C8C6DA.0056, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2012-12-31 09:39:00, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 4ce1e9b52a1573593ed55bf8889b4520
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Ijox1D4O9STjQa7nh1mHDBcI-bg>
Subject: Re: [v6ops] 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: Mon, 25 Sep 2017 09:06:11 -0000

Hi,
True ! 464xlat enabled IPv6 transition for mobile networks. Thank you ! In IPv6-only network you can expect up to 60% native IPv6
Cheers,
TK


From: Lorenzo Colitti [mailto:lorenzo@google.com]
Sent: Monday, September 25, 2017 3:55 AM
To: Mark Andrews
Cc: Gert Doering; v6ops@ietf.org WG
Subject: Re: [v6ops] reclassify 464XLAT as standard instead of info

On Sat, Sep 23, 2017 at 6:25 AM, Mark Andrews <marka@isc.org<mailto:marka@isc.org>> wrote:
Stop exaggerating.  Google went and added CLAT to the Android.  They
can just as easily add DS-Lite to Android and we would have billions
of machines that support DS-Lite.  Just because NAT64 and 464XLAT are
sexy doesn't mean that it is good technology.

We added 464xlat to Android because there were credible deployment plans in place for 464xlat on real networks that Android devices connect to. In hindsight, we were right, as 464xlat went from credible plan to successful deployment with an installed base in the tens of millions.

I personally think that if we had not done this, we wouldn't have IPv6-only mobile networks today and we'd all still be lamenting the chicken and egg problem for IPv6-only networks. Getting rid of IPv4 in the network is a great step forward, and as Apple has shown, once that's happened, host OSes can start removing IPv4 access from applications, too. (And make no mistake: without 464xlat, those networks would *not* have gone IPv6-only, and it would have been much harder, or even impossible, for Apple to say that apps must operate in IPv6-only environments, because there would have been no such environments.)

DS-Lite has no such credible deployment plans in place. Wifi networks are going to provide IPv4 for many years. Mobile networks were never going to deploy DS-Lite because the encapsulation would have broken their billing platforms. And so, here we are.

We'll all get to IPv6-only eventually, and some time after that, we'll get rid of IPv4. At that time, you can salt the earth over 464xlat if you want. But until then, I wouldn't be too eager to bash 464xlat as a technology. It was the right thing to do at the time.

v2.23.0 | Report a Bug | By Email