9.2.1 Static and Dynamic PDP Addresses

23.0603GPPGeneral Packet Radio Service (GPRS)Release 17Service descriptionStage 2TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

PDP addresses can be allocated to an MS in four different ways:

– the HPLMN operator assigns a PDP address permanently to the MS (static PDP address);

– the HPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic HPLMN PDP address);

– the VPLMN operator assigns a PDP address to the MS when a PDP context is activated (dynamic VPLMN PDP address); or

– the PDN operator or administrator assigns a permanent or dynamic PDP address to the MS (External PDN Address Allocation).

NOTE 1: A PDP address consists of an IPv4 address and/or IPv6 prefix as described in clause 14.5.

It is the HPLMN operator that defines in the subscription whether a dynamic HPLMN or VPLMN PDP address can be used. The HPLMN operator may assign a static PDP address in the PDP context subscription record. An MS implemented according to this version of the protocol does not support static PDP addresses, which are permanently configured in the MS and sent by the MS within the PDP context activation request. The handling of static addresses, which are sent by the MS, is retained in the SGSN in order to ensure backwards compatibility for MSs implemented according to earlier protocol releases.

For every IMSI, zero, one, or more dynamic PDP addresses per PDP type can be assigned. For every IMSI, zero, one, or more static PDP addresses per PDP type can be subscribed to.

When dynamic addressing from the HPLMN or the VPLMN is used, it is the responsibility of the GGSN or P‑GW to allocate and release the dynamic PDP address.

When External PDN Address Allocation is used, the following applies for GGSN:

– the PLMN may obtain a PDP address from the PDN and provide it to the MS during PDP context activation, or the MS may directly negotiate a PDP address with the PDN after the PDP context activation procedure is executed. If the PLMN provides the address during PDP context activation in case of External PDN Address Allocation, then it is the responsibility of the GGSN and PDN to allocate, renew and release the dynamic PDP address by means of protocols such as DHCP or RADIUS. If DHCPv4/v6 is used, the GGSN provides the function of a DHCPv4/v6 Client. If RADIUS is used, the GGSN provides the function of a RADIUS Client. If the MS negotiates a PDP address with the PDN after PDP context activation in case of External PDN Address Allocation, it is the responsibility of the MS and the PDN to allocate and release the PDP address by means of protocols such as DHCP or MIP. In case of DHCPv4, the GGSN provides the function of a DHCP Relay Agent as defined in RFC 2131 [47] and RFC 1542 [45]. In case of MIP, the GGSN provides the function of a Foreign Agent as defined in RFC 3344 [46].

External PDN Address Allocation (including DHCP functionality) in P‑GW is specified in TS 23.401 [89].

Only static PDP addressing is applicable in the network-requested PDP context activation case.

PDP types IPv4, IPv6 and IPv4v6 are supported. A PDP Context of PDP type IPv4v6 may be associated with one IPv6 prefix only or with both one IPv4 address and one IPv6 prefix. PDP types IPv4 and IPv6 are utilised in case the MS and/or the GGSN or P‑GW support IPv4 addressing only or IPv6 addressing only; or operator preferences dictate the use of a single IP version type only, or the subscription is limited to IPv4 only or IPv6 only. In addition, PDP types IPv4 and IPv6 are utilised for interworking with nodes of earlier releases.

The way that the MS sets the requested PDP type may be pre-configured in the device per APN. Unless otherwise configured (including when the MS does not send any APN), PDP types are set by the MS as follows:

– An MS, which supports Non-IP data and wants to use Non-IP data, shall request for PDP type Non-IP.

Otherwise:

– An MS, which is IPv6 and IPv4 capable, shall request for PDP type IPv4v6.

– An MS, which supports IPv4 addressing only, shall request for PDP type IPv4.

– An MS, which supports IPv6 addressing, shall request for PDP type IPv6.

– When the IP addressing capability of the MS is not known in the MS (as in the case when the MT and TE are separated and the capability of the TE is not known in the MT), the MS shall request for PDP type IPv4v6.

During the PDP Context Activation procedure the SGSN compares the requested PDP type to the PDP type in the subscription records for the given APN and sets the PDP type as follows:

– If the requested PDP type is allowed by subscription, the S4-SGSN sets the PDP type as requested.

– If the requested PDP type is allowed by subscription and if the requested PDP type is IPv4v6, the Gn/Gp SGSN sets the PDP type as requested if the GGSN supports PDP type IPv4v6. Otherwise, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is based on the result of the check.

NOTE 2: The check for PDP type IPv4v6 is implementation specific and configuration may be shared in roaming agreements.

NOTE 3: A Gn/Gp SGSN assumes coherent support for PDP type IPv4v6 across all SGSNs in a PLMN.

– If the requested PDP type is IPv4v6 and subscription data only allows PDP type IPv4 or only allows PDP type IPv6, the SGSN sets the PDP type according to the subscribed value. A reason cause shall be returned to the UE indicating that only the assigned PDP type is allowed. In this case the UE shall not request for another PDP context to the same APN for the other IP version during the existence of the PDP context.

– If the requested PDP type is IPv4 or IPv6, and either the requested PDP type or PDP type IPv4v6 are subscribed, the SGSN sets the PDP type as requested. Otherwise the PDP context activation request is rejected.

– If the requested PDP type is IPv4v6, and both IPv4 and IPv6 PDP types are allowed by subscription but not IPv4v6, the SGSN shall set the PDP type to IPv4 or IPv6 where the selection between IPv4 and IPv6 is implementation specific. The MS should then initiate another PDP Context Activation procedure to this APN in order to activate a second PDP context with the other single address PDP type which was not allocated by the network.

The GGSN / PDN GW may restrict the usage of PDP type IPv4v6 as follows:

– If the MS requests PDP type IPv4v6, but the operator preferences dictate the use of a single IP version only, the PDP type shall be changed to a single address PDP type (IPv4 or IPv6) and a reason cause shall be returned to the MS indicating that only the assigned PDP type is allowed. In this case, the MS shall not request another PDP context for the other PDP type during the existence of the PDP context.

– If the MS requests PDP type IPv4v6, but the operator uses single addressing per PDP context due to interworking with nodes of earlier releases, the PDP type shall be changed to a single address PDP type and a reason cause of "single address bearers only" shall be returned to the MS. In this case the MS should request another PDP context for the other PDP type to the same APN with a single address PDP type (IPv4 or IPv6) other than the one already activated.

NOTE 4: If the MT and TE are separated, the MS might not be able to use reason cause "single address bearers only" as a trigger for activating a second single-stack PDP context.

An MS of this release may request for PDP type IPv4v6 from a SGSN which does not support this PDP type. The SGSN treats a request for PDP type IPv4v6 as if it were a request for PDP type IPv4. To enable dual-stack connectivity for this case, the MS should request another PDP context for PDP type IPv6 to the same APN.

NOTE 5: If the MS requests PDP type IPv4v6, and the PDP context is rejected due to "unknown PDP type", the MS can attempt to establish dual-stack connectivity by performing two PDP context request procedures to activate an IPv4 PDP context and an IPv6 PDP context, both to the same APN.

The mechanism used to allocate an IPv4 address to an MS depends on the MS and the network capabilities. The MS may indicate to the network within the Protocol Configuration Options element that the MS wants to obtain the IPv4 address with DHCPv4 as defined in RFC 2131 [47]:

– the MS may indicate that it prefers to obtain an IPv4 address as part of the PDP context activation procedure. In such a case, the MS relies on the network to provide an IPv4 address to the MS as part of the PDP context activation procedure.

– the MS may indicate that it prefers to obtain the IPv4 address after the PDP Context Activation by DHCPv4. That is, the network does not provide the IPv4 address for the MS as part of the PDP context activation procedures but sets the PDP address as 0.0.0.0. After the PDP Context establishment procedure is completed, the MS initiates the IPv4 address allocation by using DHCPv4 (see details in TS 29.061 [27] and RFC 2131 [47]).

If the MS does not send such an indication of address allocation preference, the network selects the IPv4 address allocation method based on per APN configuration.

Both the network elements and MS may support:

a. IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 [47] and RFC 4039 [117];

b. IPv6 parameter configuration via Stateless DHCPv6 according to RFC 3736 [118].

9.2.1.1 Stateless IPv6 Address Autoconfiguration

IPv6 address configuration is somewhat different from the IPv4 address configuration procedure. The address of an IPv6 node is allocated by stateless autoconfiguration.

The GGSN informs the MS that it shall perform stateless address autoconfiguration by means of the Router Advertisements, as defined in RFC 4861 [98]. For this purpose, the GGSN shall automatically and periodically send Router Advertisement messages towards the MS after a PDP context of type IPv4v6 or IPv6 is activated.

In order to support the standard IPv6 stateless address autoconfiguration mechanism, as defined by the IETF, within the particular context of UMTS (point-to-point connections, radio resource efficiency, etc.), the GGSN shall assign a prefix that is unique within its scope to each PDP context applying IPv6 stateless address autoconfiguration. The size of the prefix is according to the maximum prefix length for a global IPv6 address. This avoids the necessity to perform duplicate address detection at the network level for every address built by the MS. The GGSN shall not use the prefix advertised to the MS to configure an address on any of its interfaces.

To ensure that the link-local address generated by the MS does not collide with the link-local address of the GGSN, the GGSN shall provide an interface identifier (see RFC 4862 [99]) to the MS and the MS shall use this interface identifier to configure its link-local address. For stateless address autoconfiguration however, the MS can choose any interface identifier to generate addresses other than link-local, without involving the network. However, the UE shall not use any identifiers defined in TS 23.003 [4] as the basis for generating the interface identifier. For privacy, the UE may change the interface identifier used to generate full IPv6 address as defined in TS 23.221 [80], without involving the network. In particular, the SGSN and the GGSN are not updated with the actual address used by the MS, as the prefix alone identifies the PDP context.

Figure 62 illustrates the IPv6 stateless autoconfiguration procedure The figure and its description show only the messages and actions specific to the IPv6 stateless address autoconfiguration procedure. For a complete description of the PDP Context Activation Procedure, refer to the corresponding clause.

Figure 62: IPv6 Stateless Address Autoconfiguration Procedure

NOTE 1: All steps in Figure 62 except step 2 are common for architecture variants using Gn/Gp based interaction with Gn/Gp-based interaction with a GGSN and using S4-based interaction with an S‑GW and a P‑GW. For a S4-based interaction with a S‑GW and P‑GW, procedure step (A) is defined in clause 9.2.2.1A.

1) The MS sends an Activate PDP Context Request message to the SGSN as defined in clause "PDP Context Activation Procedure". The MS shall leave PDP Address empty and set PDP Type to IPv6 or IPv4v6.

2) Upon reception of the Create PDP Context Request, the GGSN creates an IPv6 address composed of the prefix allocated to the PDP context and an interface identifier generated by the GGSN. This address is then returned in the PDP Address information element in the Create PDP Context Response message. The processing of the Create PDP Context Request and Create PDP Context Response, in both the SGSN and the GGSN, is otherwise as specified in clause "PDP Context Activation Procedure".

NOTE 2: Since the MS is considered to be alone on its link towards the GGSN, the interface identifier does not need to be unique across all PDP contexts on any APN.

3) The MS receives the IPv6 address produced by the GGSN in the Activate PDP Context Accept. The MS extracts the interface identifier from the address received and stores it. The MS shall use this interface identifier to build its link-local address and may also use it for building its full IPv6 address, as describe in step 5. The MS shall ignore the prefix contained in the address received in the Activate PDP Context Accept. The processing of the Activate PDP Context Accept is otherwise as specified in clause "PDP Context Activation Procedure".

4) The MS may send a Router Solicitation message to the GGSN to activate the sending of the Router Advertisement message.

5) The GGSN sends a Router Advertisement message. The Router Advertisement messages shall contain the same prefix as the one provided in step 2. A given prefix shall not be advertised on more than one PDP context on a given APN, or set of APNs, within the same addressing scope. The GGSN shall be configured to advertise only one prefix per PDP context.

After the MS has received the Router Advertisement message, it constructs its full IPv6 address by concatenating the interface identifier received in step 3, or a locally generated interface identifier, and the prefix received in the Router Advertisement. If the Router Advertisement contains more than one prefix option, the MS shall only consider the first one and silently discard the others.

NOTE 3: The MS can at any time change the interface identifier used to generate full IPv6 addresses, without involving the network, i.e. without updating the PDP context in the SGSN and the GGSN.

Because any prefix that the GGSN advertises in a PDP context is unique within the scope of the prefix (i.e. site-local or global), there is no need for the MS to perform Duplicate Address Detection for this IPv6 address. Therefore, the GGSN shall silently discard Neighbor Solicitation messages that the MS may send to perform Duplicate Address Detection. It is possible for the MS to perform Neighbor Unreachability Detection towards the GGSN, as defined in RFC 4861 [98]; therefore if the GGSN receives a Neighbor Solicitation as part of this procedure, the GGSN shall provide a Neighbor Advertisement as described in RFC 4862 [99].

9.2.1.2 IPv6 Prefix Delegation via DHCPv6

Optionally, a single network prefix shorter than the default /64 prefix may be assigned to a PDN connection. In this case, the /64 default prefix used for IPv6 stateless autoconfiguration will be allocated from this network prefix; the remaining address space from the network prefix can be delegated to the PDN connection using prefix delegation after the PDP context activation and IPv6 prefix allocation via IPv6 stateless address autoconfiguration as defined in clause 9.2.1.1. When PLMN based parameter configuration is used, the GGSN provides the requested IPv6 prefix from a locally provisioned pool. When external PDN based IPv6 prefix allocation is used, the GGSN obtains the prefix from the external PDN.

NOTE 1: Allocation of IPv6 prefixes with flexible prefix length can leverage e.g. local configuration on the GGSN or interaction with the AAA server.

The address space provided is maintained as an IPv6 address space pool available to the PDN connection for DHCPv6 IPv6 prefix requests with the exclusion of the IPv6 prefix that is allocated to the PDP context during PDP context activation as defined in clause 9.2.1.1. The total IPv6 address space available for the PDP connection (the /64 default prefix and the remaining IPv6 address space pool) shall be possible to aggregate into one IPv6 prefix that will represent all IPv6 addresses that the MS may use. If the MS had indicated that it supports prefix exclusion and the prefix to be delegated to the UE includes the /64 prefix that was allocated to the PDN Connection, the GGSN shall utilise the prefix exclusion feature as specified for DHCPv6 Prefix Delegation in RFC 6603 [113].

The MS uses DHCPv6 to request additional IPv6 prefixes (i.e. prefixes in addition to the default prefix) from the GGSN after completing stateless IPv6 address autoconfiguration procedures. The MS acts as a "Requesting Router" as described in RFC 3633 [105] and inserts one or more IA_PD option(s) into a DHCPv6 Solicit message sent from the MS to the GGSN. The GGSN acts as the DHCP server and fulfils the role of a "Delegating Router" according to RFC 3633 [105]. The MS 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 MS 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 MS 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 GGSN delegates a prefix excluding the default prefix with help of OPTION_PD_EXCLUDE. Prefix exclusion procedures shall follow RFC 6603 [113].