IETF Logo Mail Archive

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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Fri, 22 September 2017 12:45 UTC

Return-Path: <rajiva@cisco.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 D28B3132F76 for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 05:45:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Level:
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hHpJ-bULnFeI for <v6ops@ietfa.amsl.com>; Fri, 22 Sep 2017 05:45:14 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 027BA132031 for <v6ops@ietf.org>; Fri, 22 Sep 2017 05:45:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9465; q=dns/txt; s=iport; t=1506084311; x=1507293911; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=8tJqrWmqvvN4qMcjvX1rEkQ4hegIruoC0cbDV+LcF0A=; b=TAOSju+1rp+ALvLB9eVXJ2d7Ikm2lWWsHRSxnGR1SU5VNi4njb7ST4QL Zle0DSrX5jOHkMGyFNxtFKzMoNX7IraGBRx039VlLUJ9S3r7+xpbek5Vc V0/Jo4T/m1qppNc+UhDN4liMRRo6ZrarSc7iVPkm1MP4l/z5uphtqXrIs c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYAQCoBMVZ/4YNJK1cGQEBAQEBAQEBAQEBBwEBAQEBgy0tZG4nnhGBUiKQaoU/ghIKGAEKhRgChCNBFgECAQEBAQEBAWsohRkCAQMBAWwLEAIBCD8HJwsUEQIEDgUZiTZkEKkBiwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMrggKBUYFkKwuCcoQ6hAOCMQWIKZhsAoZheox/DJJ3lRYCERkBgTgBJg4jQg0/eBVJEgGHCnaJVwEBAQ
X-IronPort-AV: E=Sophos;i="5.42,427,1500940800"; d="scan'208,217";a="296840126"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Sep 2017 12:45:10 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v8MCjAkg017695 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 22 Sep 2017 12:45:10 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 22 Sep 2017 07:45:10 -0500
Received: from xch-aln-005.cisco.com ([173.36.7.15]) by XCH-ALN-005.cisco.com ([173.36.7.15]) with mapi id 15.00.1263.000; Fri, 22 Sep 2017 07:45:10 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Gert Doering <gert@space.net>
CC: Ole Troan <otroan@employees.org>, "v6ops@ietf.org WG" <v6ops@ietf.org>
Thread-Topic: [v6ops] reclassify 464XLAT as standard instead of info
Thread-Index: AQHTMid0MFsx+pW27UqTI5O/FzE0AKK+QISAgACZFACAAHVGAIAAAUqAgADS0gD//8wEPIAA1YeA//+6It6AAKJbgIAACCSAgAABEwD//7K4HA==
Date: Fri, 22 Sep 2017 12:45:10 +0000
Message-ID: <E991C091-EDC5-4735-A52E-4C53324ADE39@cisco.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>
In-Reply-To: <20170922122146.GY45648@Space.Net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
Content-Type: multipart/alternative; boundary="_000_E991C091EDC54735A52E4C53324ADE39ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/PmgL5RNEMhKKru82wNt0SXEcgrM>
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: Fri, 22 Sep 2017 12:45:17 -0000

I don't think that there any iOS app that is not IPv6-only compatible (since the apple AppStore mandate more than a year* ago). Is there one ?

If Google playstore could mandate something similar (perhaps, there is one that I am not aware of), then almost all mobile UEs can happily live with v6-only without any Clat function.  Better battery life, likely.

Hence, There is no need for XLAT being a BCP at this time in that regard.

Of course, NAT64 inside the network would still be needed to accommodate the smaller  (% of traffic) v4-only internet connectivity. But that's an ongoing saga of another debate.



However, there is one exception - tethering :: if mobile UE is tethered and the other devices connecting to its W/LAN are stuck in legacy v4-only, then mobile ISPs might prefer to not leave them behind to ensure customer experience. What "technical" options do we have then? Well, really two == Let go of v6-only access (provide an IPv4-only APN if tethering is enabled resulting in a dual-stack UE) or stick with v6-only access, but turn on CLAT function !!

Cheers,
Rajiv


* https://developer.apple.com/support/ipv6/


On Sep 22, 2017, at 8:22 AM, Gert Doering <gert@space.net<mailto:gert@space.net>> wrote:

Hi,

On Fri, Sep 22, 2017 at 02:17:55PM +0200, Ole Troan wrote:
On 22 Sep 2017, at 13:48, Gert Doering <gert@space.net<mailto:gert@space.net>> wrote:
On Fri, Sep 22, 2017 at 05:07:19PM +1000, Mark Andrews wrote:
IPv6 applications need to add code to WORKAROUND breakages caused
by NAT64 the way they need add WORKAROUNDS for the NAT breakages
even if they are not using NAT64 or NAT respectively.  The cancer
that is NAT64 needs to be eradicated.

It will nicely go away if all endpoints are reachable over v6.

I think that?fs the concern. That it will not.
IPv6 applications will have code to accommodate for NAT64 forever.

Yeah, but you can't have the cake and eat it.  Either we go v6-only
everywhere, or we keep running IPv4 everywhere until everybody else
is done, or we introduce v4/v6 NATs, or we add a CLAT to every single
operating system out there.

What's it gonna be, boys?

(Oh, "or we give up, roll back existing v6 deployments, and live happy
with v4 nat forever".  FAR less work, and for Joe Average User, it won't
make a difference.  Facebook and Youtube will continue to work, and
their IoT devices will keep drilling holes into firewalls to ensure that
they can be exploited no matter what)

Gert Doering
       -- NetMaster
--
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
_______________________________________________
v6ops mailing list
v6ops@ietf.org<mailto:v6ops@ietf.org>
https://www.ietf.org/mailman/listinfo/v6ops

v2.23.0 | Report a Bug | By Email