Project

General

Profile

Actions

Bug #5449

open

osmo-ggsn: Accept IPv4v6 EUA pdp creation in APv4/v6-only APNs by answering with changed PDP Type

Added by pespin about 2 years ago. Updated 11 months ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
openggsn
Target version:
-
Start date:
02/09/2022
Due date:
% Done:

0%

Spec Reference:

Description

Scenario: We configure an "internet" APN to be of type IPv4, so it only serves IPv4 addresses. MS sends Create PDP Context Request using EUA with PDP Type IPv4v6.

Related specs:
  • 3GPP TS 24.008 version 15.8.0 Release 15, section 6.1.3.1(.1)
  • ETSI TS 129 060 V16.0.0 (GTPv1C), section 7.3.2 ("New PDP type due to network preference")
  • 3GPP TS 23.060 version 16.0.0 Release 16, section 9.2.1

In current osmo-ggsn master, we seem to implement the pre-release 8 behavior:

The MS, in a pre release 8 network not supporting IPv4/v6, could encounter other network reactions
[...]
NOTE: Some networks can respond with ACTIVATE PDP CONTEXT REJECT with SM cause #28 "unknown
PDP address or PDP type". In that instance, the MS can attempt to establish dual-stack connectivity by
performing two PDP context activation request procedures to activate an IPv4 PDP context and an IPv6
PDP context, both to the same APN.

This can be seen/reproduced in TTCN3 GGSN_Tests.TC_pdp46_act_deact_apn4

That means we reject it, and the MS then tries again trying to create separate pdp contexts, sending one Create PDP Context Request with PDPType=IPv4 and another one with PDPType=IPv6.
That means each MS may end up doing 3 CreatePDPContextRequest+Response ping pongs before properly establishing the PDP context.

The specs mentioned above seems to document a better way to do so, where the first Create PDP Context Request with PDPType=IPv4v6 is answered accepting the request by changing the PDPType to "IPv4" or "IPv6" (based on the APN type configured), and setting cause to "New PDP type due to network preference".

Actions #1

Updated by pespin about 2 years ago

  • Description updated (diff)
Actions #2

Updated by pespin about 2 years ago

  • Description updated (diff)
Actions #3

Updated by laforge over 1 year ago

  • Priority changed from Normal to Low
Actions #4

Updated by pespin 11 months ago

This is btw already implemented in open5gs SMF GTPv1C implementation I did some time ago, see smf_gn_build_create_pdp_context_response() there (OGS_GTP1_CAUSE_NEW_PDP_TYPE_DUE_TO_NETWORK_PREFERENCE):
https://github.com/open5gs/open5gs/blob/main/src/smf/gn-build.c#L154

Actions #5

Updated by pespin 11 months ago

TTCN3 test GGSN_Tests.TC_pdp46_act_deact_apn4 actually supports both methods (rejecting and jumping to IPv4 orIPv6 only, or the network allocating a new address type with cause=""New PDP type due to network preference").

In The GGSN_Tests run against open5gs-smfd+upfd (ttcn3-ggsn-tests-ogs), this method can be seen in action:
https://jenkins.osmocom.org/jenkins/view/TTCN3/job/ttcn3-ggsn-test-ogs/415/artifact/logs/ggsn-tester/GGSN_Tests.TC_pdp46_act_deact_apn4.pcap.gz

Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)