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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 28 September 2017 12:50 UTC

Return-Path: <swmike@swm.pp.se>
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 933B713304E for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 05:50:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 2i6-vK3-W0dt for <v6ops@ietfa.amsl.com>; Thu, 28 Sep 2017 05:50:38 -0700 (PDT)
Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A186132811 for <v6ops@ietf.org>; Thu, 28 Sep 2017 05:50:38 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4CC8FB1; Thu, 28 Sep 2017 14:50:36 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506603036; bh=ju3RfT+HZkahX/4naVmICtln7Kb68hSvLbgjr0hhiU8=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=pVphlI62rnqTtoarmjDWswjrgYXUUeKE3xVvevi8qRV0k2G0i6JAtjc3rJGH7IG+D z51rHv13zGPjfp/02y/hI8XnE3tXHEL74BlyYin7WY6nGyoyLQbcr101EYy4UxOjfc tPpogEkXSHdIoKnTNcU0SVYJIKiw8byX7dvumbKo=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 34992AF; Thu, 28 Sep 2017 14:50:36 +0200 (CEST)
Date: Thu, 28 Sep 2017 14:50:36 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Ca By <cb.list6@gmail.com>
cc: IPv6 Ops WG <v6ops@ietf.org>
In-Reply-To: <CAD6AjGTeQ4RTXmzYKotKFMGO3z8E+5n3FXb9iKL03O3rSATwTQ@mail.gmail.com>
Message-ID: <alpine.DEB.2.20.1709281436090.18564@uplift.swm.pp.se>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@LO1P123MB0116.GBRP123.PROD.OUTLOOK.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> <F3AFCB39-00D0-4E3C-AC90-E06038AC5230@cisco.com> <CAD6AjGTeQ4RTXmzYKotKFMGO3z8E+5n3FXb9iKL03O3rSATwTQ@mail.gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: multipart/mixed; BOUNDARY="-137064504-14900332-1506603036=:18564"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/SUY7WZwwsRxXwfzHnsZ7f4kOC2E>
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 12:50:41 -0000

On Thu, 28 Sep 2017, Ca By wrote:

> I may be wrong here, but these instruction likely do not allow the client
> mobile to run dhcpv6

https://tools.ietf.org/html/rfc6653

There is also this gem that I found:

http://www.google.sr/patents/US9491036

Wonder if that's causing a problem in implementing DHCPv6-PD in SPGW.

Anyhow, TS 23.401 says:

"The UE uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in 
addition to the default prefix) from the PDN GW after completing stateless 
IPv6 address autoconfiguration procedures. The UE acts as a "Requesting 
Router" as described in RFC 3633 [21] and inserts one or more IA_PD 
option(s) into a DHCPv6 Solicit message sent from the UE to the PDN GW. 
The PDN GW acts as the DHCP server and fulfils the role of a "Delegating 
Router" according to RFC 3633 [21]. The UE optionally includes the 
RAPID_COMMIT option in the DHCPv6 Solicit message to trigger two-message 
DHCPv6 procedure instead of the four-message DHCPv6 procedure. The UE 
shall include OPTION_PD_EXCLUDE option code in an OPTION_ORO option to 
indicate support for prefix exclusion. In response to the DHCPv6 Solicit 
message, the UE receives a DHCPv6 Reply message with one or more IA_PD 
prefix(es) for every IA_PD option that it sent in the DHCPv6 Solicit 
message. The PDN GW delegates a prefix excluding the default prefix with 
help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow 
IETF RFC 6603 [70]."

Seems to me that in the standardization documents, it's perfectly fine for 
UE to request prefix using standard DHCPv6-PD, and this is the way it was 
intended to be done.

In 5.3.1.2.3 there is also talk about stateless DHCPv6:

"5.3.1.2.3	IPv6 parameter configuration via stateless DHCPv6
The UE may use stateless DHCPv6 for additional parameter configuration. 
The PDN GW acts as the DHCP server. When PLMN based parameter 
configuration is used, the PDN GW provides the requested parameters from 
locally provisioned database. When external PDN based parameter 
configuration is used, the PDN GW obtains the requested configuration 
parameters from the external PDN as described in the previous clauses. 
When the PDN GW acts as a DHCPv6 server towards the UE, the PDN GW may act 
as DHCPv6 client towards the external PDN to request the configuration 
parameters for the UE. If RADIUS or Diameter is used towards the external 
PDN as described in TS 29.061 [38], the requested configuration parameters 
can be fetched as part of these procedures."

There is also this overview text:

Both EPS network elements and UE may support the following mechanisms:
a.	IPv4 address allocation and IPv4 parameter configuration after the 
attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25];
b.	IPv6 parameter configuration via Stateless DHCPv6 according to 
RFC 3736 [20].
c.	Allocation of IPv6 prefixes using DHCPv6 according to 
RFC 3633 [21].

So it's pretty obvious that DHCPv6 is a thing in 3GPP networks, but it's 
optional to implement.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se