Bug #5449
Updated by pespin about 2 years ago
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"), section
In current osmo-ggsn master, we seem to implement the pre-release 8 behavior:
<pre>
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.
</pre>
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".
