Re: [v6ops] GTP questions

Alexandre Petrescu <alexandre.petrescu@gmail.com> Mon, 13 November 2017 13:34 UTC

Return-Path: <alexandre.petrescu@gmail.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 B95581243F3 for <v6ops@ietfa.amsl.com>; Mon, 13 Nov 2017 05:34:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.632
X-Spam-Level:
X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 Usjc8mA4qg9C for <v6ops@ietfa.amsl.com>; Mon, 13 Nov 2017 05:34:26 -0800 (PST)
Received: from oxalide-smtp-out.extra.cea.fr (oxalide-smtp-out.extra.cea.fr [132.168.224.13]) (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 03EA2129562 for <v6ops@ietf.org>; Mon, 13 Nov 2017 05:34:23 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id vADDYILk172728; Mon, 13 Nov 2017 14:34:18 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 419562050D6; Mon, 13 Nov 2017 14:34:18 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 319AA205086; Mon, 13 Nov 2017 14:34:18 +0100 (CET)
Received: from [132.166.85.85] ([132.166.85.85]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id vADDYFvb013547; Mon, 13 Nov 2017 14:34:16 +0100
To: "Rajiv Asati (rajiva)" <rajiva@cisco.com>, Ca By <cb.list6@gmail.com>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
References: <LO1P123MB01168388285206BB7C26F029EA7A0@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> <alpine.DEB.2.20.1709291034390.18564@uplift.swm.pp.se> <40ec0857-30b1-8e7e-ec41-545d8f604d01@gmail.com> <CAD6AjGSfBH3GGLp2H07GrJ4KDwtFnD8aYkY5HDT9BCDJWGkeVg@mail.gmail.com> <05D2842E-AD51-450F-9124-6E3ABBA6D450@cisco.com>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <59fbcf3a-a8da-a468-04c4-2a64b2b45383@gmail.com>
Date: Mon, 13 Nov 2017 14:34:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <05D2842E-AD51-450F-9124-6E3ABBA6D450@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/O5mMuHNbxZFTj9Z2FNavUJ4BeHU>
Subject: Re: [v6ops] GTP questions
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, 13 Nov 2017 13:34:29 -0000


Le 13/11/2017 à 14:12, Rajiv Asati (rajiva) a écrit :
> Pls see inline,
> 
> 
> On Nov 12, 2017, at 10:05 AM, Ca By <cb.list6@gmail.com 
> <mailto:cb.list6@gmail.com>> wrote:
> 
>>
>> On Sun, Nov 12, 2017 at 4:11 AM Alexandre Petrescu 
>> <alexandre.petrescu@gmail.com <mailto:alexandre.petrescu@gmail.com>> 
>> wrote:
>>
>>     Hi Mikael,
>>
>>     Sorry for late reply.
>>
>>     Le 29/09/2017 à 10:44, Mikael Abrahamsson a écrit :
>>     > 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.
>>
>>     YEs, I can agree to read it that way, but it can be a little bit of a
>>     stretch.  GTP Rel15 Sept. 2017 clearly says only RFC768.  If it wanted
>>     to mean GTP/UDP/IPv6 it could have cited e.g. RFC6936.  Hence the
>>     doubt.
>>
>>     But yes, I agree with you that in largest part UDP works over IPv6 as
>>     over IPv4.
>>
>>     > There is a lot more text in TS 29.060 regarding this, but interested
>>     > parties can read it and form their own opinion.
>>
>>     I agree.
>>
>>     > 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.
>>
>>     I agree that real life in shipping products is a whole other question.
>>
>>     I had some discussion with some people, and here are some of my
>>     deductions.  If I am wrong, I carry the responsibility.
>>
>>     Operator1 in hexagon country: the IPv6 is carried in GTP/UDP/IPv4
>>     Operator2 in country voted out of EU: the IPv6 is carred in
>>     GTP/UDP/IPv4.
>>
>>     Among other cellular operators that offer IPv6 to smartphones, I
>>     wonder
>>     about the following:
>>
>>     Is T-Mobile USA carrying the smartphone's IPv6 inside
>>     GTP/UDP/IPv4?  Or
>>     inside GTP/UDP/IPv6?
>>
>>     Is Reliance JIO in India carrying the smartphone's IPv6 inside
>>     GTP/UDP/IPv4?  Or inside GTP/UDP/IPv6?
>>
> 
> Latter. Hopefully, more details will get discussed at the next v6 world 
> Congress in Paris.

That would be a first time a cellular network operator transports 
smartphone's IPv6 traffic into GTP-IPv6.  All the others transport 
smartphone's IPv6 traffic into GTP-IPv4.

GTP is a an UDP/IPv4 protocol and example packets look like this.  It 
comes from the smartphone and is captured on PGW:
 > INBOUND>>>>>  15:47:48:883 Eventid:142004(3)
 > GTPU Rx PDU, from [IPv4-address]:2152 to [IPv4-address-2]:2152 (129)
 > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF)
 > Sequence Number:: NA
 > GTP HEADER FOLLOWS:
 > [snip]
 > GTP HEADER ENDS.
 >            Payload protocol: IPv6
 > PROTOCOL PAYLOAD FOLLOWS:
 > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546:  [udp sum ok]
 > IPv6 Header Follows:
 > [snip]
 > PROTOCOL PAYLOAD ENDS.

A fictitious GTP as UDP/IPv6 packet would look like this, remark
the IPv6 addresses 'from' and 'to' in the second line below:
 > INBOUND>>>>>  15:47:48:883 Eventid:142004(3)
 > GTPU Rx PDU, from [IPv6-address]:2152 to [IPv6-address-2]:2152 (129)
 > TEID: 0x80072183, Message type: GTP_TPDU_MSG (0xFF)
 > Sequence Number:: NA
 > GTP HEADER FOLLOWS:
 > [snip]
 > GTP HEADER ENDS.
 >            Payload protocol: IPv6
 > PROTOCOL PAYLOAD FOLLOWS:
 > fe80::b9d9:c10a:2c2d:3c3b.546 > ff02::2.546:  [udp sum ok]
 > IPv6 Header Follows:
 > [snip]
 > PROTOCOL PAYLOAD ENDS.

Does such packet exist.  Why waiting the next v6 world Congress in Paris 
to see that.

> 
>>
>>     My gut feeling is that all do GTP/UDP/IPv4.
>>
>>
>> Your gut is correct, i do not know of any carrier using GTP with ipv6 
>> transport.
>>
>> That said, i believe the GTP transport network operations is 
>> orthogonal to the network that the UE / customer traffic experiences.
> 
> +1.
> 
> 
>>
>>     My intention with this discussion is twofold: find an operator
>>     that does
>>     GTP/UDP/IPv6 and second to deduce something for the IPv6-only
>>     terminology draft.
>>
> 
> How do either help out ?

Well, it would prove me wrong when I am saying there is no such thing as 
an IPv6-only core network in a cellular network.

Also, a well-defined term "IPv6-only" helps me when I approach parties 
proposing them "IPv6".  Sometimes they seem scared of the "IPv6" word, 
so I reassure them it is _not_ "IPv6-only", but it is "IPv6-only" 
together with "IPv4".  Or I may just say "IP".

Ther term "dual stack" is not well understood: some times it means IPv4 
side-by-side with IPv6 in the same computer, whereas other times it 
means a particular translation mechanism between IPv6 and IPv4 including 
some DNS features ("DS Lite", and others).

"IPv6-only" together with "IPv4" would mean something like it works ok 
for everyone without any translation, tunnelling or DNS combinations.

Then there is also this "native" term that would need to be clarified.

And also this level: encapsulated IPv6 in IPv4 does not mean "IPv6-only" 
and does not mean '"IPv6-only" together with IPv4.'

Just some thoughts.

Alex


> 
>>
>>     Alex
>>
>>     _______________________________________________
>>     v6ops mailing list
>>     v6ops@ietf.org <mailto:v6ops@ietf.org>
>>     https://www.ietf.org/mailman/listinfo/v6ops
>>
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops