IETF Logo Mail Archive

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

"Rajiv Asati (rajiva)" <rajiva@cisco.com> Thu, 28 September 2017 09:44 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 7F2E11345DE for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 02:44:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.519
X-Spam-Level:
X-Spam-Status: No, score=-14.519 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 tflTNjmnbLRW for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 02:44:07 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A338A1345DD for <v6ops@ietf.org>; Thu, 28 Sep 2017 02:44:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9525; q=dns/txt; s=iport; t=1506591847; x=1507801447; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=E34tWU+wCw1EEe7UBhh9aGQjaK8ShPEx2Bt2t8Agcyo=; b=UeAUTA98qewrixcx+CunEWTccp8MLSO9FnhWLaowgQXCkBCA8mLz3w+O auSc0GpqZnLZMvsrwocPKJIj/9EX8/J4nn6DGxsKDF/P8K/sU8G6l16oe NJrNoYn6IVcEMtuTj0pzLLHnJlUh6Z/KOmmr4Nd8uAoyaYc/hCCgSsUdG A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DfAQDNw8xZ/5hdJa1dGQEBAQEBAQEBAQEBBwEBAQEBg1xkbieDeJl9kmOGcQNcChgBBYUdAhqETFcBAgEBAQEBAmsohRkCAQMBASFLCxACAQgOMQMCAgIlCxQRAgQOBYlNZBCnHIIniwEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYMrggKBUYIVgn2EcimCfC+CMQWYT4hWApRdkwaVHwIRGQGBOAFXTz94FUkSAYU8gU52AYhPAQEB
X-IronPort-AV: E=Sophos;i="5.42,449,1500940800"; d="scan'208,217";a="9278814"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Sep 2017 09:44:06 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v8S9i63E021058 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Sep 2017 09:44:06 GMT
Received: from xch-aln-005.cisco.com (173.36.7.15) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 28 Sep 2017 04:44:05 -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.1320.000; Thu, 28 Sep 2017 04:44:05 -0500
From: "Rajiv Asati (rajiva)" <rajiva@cisco.com>
To: Erik Kline <ek@google.com>
CC: Mikael Abrahamsson <swmike@swm.pp.se>, IPv6 Ops WG <v6ops@ietf.org>
Thread-Topic: [v6ops] 464xlat case study (was reclassify 464XLAT as standard instead of info)
Thread-Index: AdM16ZBiVXxOrrPASdi8hSWu5DH/5gBUxEOAAA4804AAHACngAAFqZaAAAPsVoAAAeIOAAAGsJeA//+yUQuAAIJHAP//yXnCgABYXwD//7E2X4AAXHyAgAABzgCAAAN0AP//ts7a
Date: Thu, 28 Sep 2017 09:44:05 +0000
Message-ID: <F3AFCB39-00D0-4E3C-AC90-E06038AC5230@cisco.com>
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> <CAD6AjGQdMFgv4727wHm41HmEyo2Z-PCabPHPSRSVwOi_rey7OQ@mail.gmail.com> <CAKD1Yr03zsuSBqPegs6RNbBqnJizUOLZwH+rNDi1Ocg4k+mARQ@mail.gmail.com> <20170928030630.DD2D08867238@rock.dv.isc.org> <alpine.DEB.2.20.1709280753080.18564@uplift.swm.pp.se> <20170928074105.BCB99886E538@rock.dv.isc.org> <alpine.DEB.2.20.1709280955490.18564@uplift.swm.pp.se> <20170928081527.21D9F886EF0C@rock.dv.isc.org> <CAAedzxqRar=X6c6WJNOWtKA3S6Dx8nXcuwYYh8OyK3oncJYnsQ@mail.gmail.com> <alpine.DEB.2.20.1709281052430.18564@uplift.swm.pp.se>, <CAAedzxobp6ORODchDGqjbjfKuiZ1vO+q4k5so74MLqdpCzY84A@mail.gmail.com>
In-Reply-To: <CAAedzxobp6ORODchDGqjbjfKuiZ1vO+q4k5so74MLqdpCzY84A@mail.gmail.com>
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_F3AFCB3900D04E3CAC90E06038AC5230ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/5yEQ6k2JXvgY4lmo69HcbOkzvqE>
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: Thu, 28 Sep 2017 09:44:10 -0000

Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's been

I could double check CPE routers such as ISR819 with LTE WAN uplink support DHCPv6.

Separately, from PGW point of view, DHCPv6 within an APN seems to be supported -

https://www.cisco.com/c/en/us/td/docs/wireless/asr_5000/20/P-GW/b_20_PGW_Admin/b_19_PGW_Admin_chapter_010.html#task_309eb986-4510-425a-81ed-833018e70921

//
The system can be configured to use the Dynamic Host Control Protocol (DHCP) for IPv6 to enable the DHCP servers to pass the configuration parameters such as IPv6 network addresses to IPv6 nodes. DHCPv6 configuration is done within an APN.
//



I have been wondering about asking for an API to the modem to query
for the 3GPP release number of the network as a hint for expected
capabilities, but that kinda seems both excessive and like a layering

Given all the thing that get queried and fetched by apps, fetching the rel# being used (assuming available) would add a drop to the ocean. :)

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services


On Sep 28, 2017, at 11:06 AM, Erik Kline <ek@google.com<mailto:ek@google.com>> wrote:

On 28 September 2017 at 17:53, Mikael Abrahamsson <swmike@swm.pp.se<mailto:swmike@swm.pp.se>> wrote:
On Thu, 28 Sep 2017, Erik Kline wrote:

I can just feel all the "android and dhcpv6" screeds being written right
now...


Do any other mobile operating systems do DHCPv6 on the GTP tunnel? It's been
too many years since I last looked at GTP packet traces to remember if this
was done or not.

I've no idea.  Nor do I know what might happen to various networks if
DHCPv6 requests were to be made on the mobile interface (even if the O
bit /were/ observed to be set).  The stories of billing system crashes
and so on from the early days of v6 on mobile leave me somewhat
suspicious.

I have been wondering about asking for an API to the modem to query
for the 3GPP release number of the network as a hint for expected
capabilities, but that kinda seems both excessive and like a layering
violation.  ;-)
_______________________________________________
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