Re: [v6ops] DHCPv6-PD presence on OSs, and GTP question (was: 464xlat case study (was reclassify 464XLAT as standard instead of info))

Mikael Abrahamsson <swmike@swm.pp.se> Fri, 29 September 2017 08:45 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 3D8A6126BF0 for <v6ops@ietfa.amsl.com>; Fri, 29 Sep 2017 01:45:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 llTYIf5vf7c4 for <v6ops@ietfa.amsl.com>; Fri, 29 Sep 2017 01:45:03 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 829A9132941 for <v6ops@ietf.org>; Fri, 29 Sep 2017 01:45:03 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id CBE7AB1; Fri, 29 Sep 2017 10:44:59 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1506674699; bh=d0OTdqp4CFUbhjHSRK5Rs8+kRb5FSOWreIUpJgPBKsw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=t1IA5qYyIXj4lfHoi9Oo6rOfjXB+zTOH1HhjfXrEeIjSyT/fS6UdZDgs3mfU3AmFZ N7pfv9bH6a3sv79U8MyaMeZaaBcBaZ5h+fb1ZgBLVCk9ZcgamzjdVrIw9khjtYSImQ +LiSA1inMBikvcWDSsOpcckXWWlGShfKokrDSJPQ=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C83D1AF; Fri, 29 Sep 2017 10:44:59 +0200 (CEST)
Date: Fri, 29 Sep 2017 10:44:59 +0200
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: Alexandre Petrescu <alexandre.petrescu@gmail.com>
cc: v6ops@ietf.org
In-Reply-To: <ef940338-4167-dbae-0895-069602f76013@gmail.com>
Message-ID: <alpine.DEB.2.20.1709291034390.18564@uplift.swm.pp.se>
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> <ef940338-4167-dbae-0895-069602f76013@gmail.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/Ppu7C0EUaMNKDJFGaeaKU2Mo_zc>
Subject: Re: [v6ops] DHCPv6-PD presence on OSs, and GTP question (was: 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: Fri, 29 Sep 2017 08:45:09 -0000

On Fri, 29 Sep 2017, Alexandre Petrescu wrote:

> I would like to ask whether by 3GPP specs the GTP packets can optionally 
> be transported in IPv6 messages?
>
> 3GPP spec "GTP" Rel 15 of September 2017 says this:
>> UDP/IP is the only path protocol defined to transfer GTP messages in
>>  the version 1 of GTP. A User Datagram Protocol (UDP) compliant with
>>  IETF RFC 768 [13] shall be used.
>
> In practice, a packet capture on PGW shows an IPv6 DHCPv6-PD Solicit
> message, preceded by a GTP-U Header, which is itself preceded by a "GTPU
> Rx PDU" which is an IPv4 UDP packet.
>
> The UDPv4 port number that transports GTP packets is 2152, reserved at
> IANA and at that 3GPP spec.

It's an implementation detail whether this is carried over IPv4 or IPv6. 
UDP can be carried by both. If you read 29.060 it talks about GTP over 
both IPv4 and IPv6:

"If an IPv4/IPv6 capable SGSN received IPv4 GGSN addresses from the old 
SGSN, it shall include IPv4 addresses in the fields SGSN Address for 
Control Plane and SGSN Address for User Traffic and IPv6 addresses in the 
fields Alternative SGSN Address for Control Plane and Alternative SGSN 
Address for User Traffic. Otherwise, an IPv4/IPv6 capable SGSN shall use 
only SGSN IPv6 addresses if it has GGSN IPv6 addresses available. If the 
GGSN supports IPv6 below GTP, it shall store and use the IPv6 SGSN 
addresses for communication with the SGSN and ignore the IPv4 SGSN 
addresses. If the GGSN supports only IPv4 below GTP, it shall store and 
use the IPv4  SGSN addresses for communication with the  SGSN and ignore 
the IPv6 SGSN addresses. When active contexts are being redistributed due 
to load sharing, G-PDUs that are in transit across the Gn-interface are in 
an undetermined state and may be lost."

"below GTP" seems to indicate what protocol GTP is run over. There is a 
lot more text in TS 29.060 regarding this, but interested parties can read 
it and form their own opinion. To me it's clear that 3GPP has done the 
work to try to achieve so you can standards-based build a network with no 
IPv4 addresses used for infrastructure. If this works in real life in 
shipping products, that's a whole other question.

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