4 General

24.3033GPPMobility management based on Dual-Stack Mobile IPv6Release 17Stage 3TS

4.1 Mobility management based on Dual-Stack Mobile IPv6

DSMIPv6 is specified in IETF RFC 6275 [27] and IETF RFC 5555 [2]. The purpose of the DSMIPv6 procedures is to establish, manage and tear down a mobility tunnel between the UE and the HA function. The mobility tunnel establishment is always initiated by the UE, while the mobility tunnel tear down can be initiated either by the UE or the network. Communication between the UE and a correspondent node shall use the bidirectional mode of operation. Route optimization mode of operation is not supported by EPC in this release.

In this specification, the IETF RFC 4877 [4] is used to secure DSMIPv6 signalling. For this purpose, the UE performs an IKEv2 exchange with the HA before establishing the mobility tunnel as described in subclause 5.1.2.2. The details of the security aspects are specified in 3GPP TS 33.402 [18].

The mobility tunnel procedures are performed by the UE for each PDN connection, meaning that if multiple PDNs are accessed by the UE, multiple instances of the procedures are needed. The multiple PDN connections behaviour is specified more in detail in subclause 4.3.

In this specification, the IETF RFC 3963 [29] is used for prefix preservation. For this purpose, the UE uses the implicit mode as stated in IETF RFC 3963 [29] to tell the HA that the home network prefix would be preserved during mobility. The support of this operation is limited to the sending and receiving of IPv6 packets containing IPv6 addresses auto-configured from the home network prefix, in addition to the IPv6 Home Address.

In this specification, the IETF RFC 5648 [31], IETF RFC 6089 [32] and IETF RFC 6088 [33] are used for IFOM. The general principles of IFOM are listed in 3GPP TS 23.261 [34]. For this purpose, the UE can decide if IFOM is to be applied to a PDN connection. The procedures used by the UE to determine which PDN connection IFOM is to be applied and how the IP flows are distributed are specified in 3GPP TS 24.302 [21].

4.2 Identities

The UE shall use Network Access Identifier (NAI) as identification towards the HA in the IKEv2 exchange. During this process, the IPsec security association between the UE and the HA is tied to the user identity, set to the NAI, and to an SPI uniquely identifying this security association. The NAI is structured according to 3GPP TS 23.003 [17]. The NAI can be either a root NAI, a fast re-authentication NAI or pseudonym identity as specified in 3GPP TS 23.003 [17].

The UE shall use the HA-APN to identify the desired HA in the DNS-based and DHCPv6-based HA discovery procedures. The HA-APN is constructed according to 3GPP TS 23.003 [17].

NOTE: The operator is responsible to configure the DNS system so that the same PDN GW can be discovered via HA-APN and APN. A possible way of configuring the mapping between HA-APN and APN is to create the HA-APN from the respective APN by using the same Network Identifier and by adding the prefix "ha-apn" to the Operator Identifier.

The Binding Update and Binding Acknowledgement shall not explicitly carry an NAI as the IPsec security association is tied to the user identity.

4.3 Multiple PDN connectivity

This specification supports multiple PDN connectivity. The UE can setup multiple PDN connections with a given APN or multiple APNs using multiple DSMIPv6 sessions. There is one DSMIPv6 session per each PDN connection.

NOTE: When a UE is associated to multiple PDN connections, it is possible for the UE to create a tunnel loop amongst the HAs by binding home addresses to each other. This results in the possibility of HA being flooded with packets. Packet flooding is not specific to DSMIPv6 and there exist current implementations to deal with the packet flooding issue. As for the formation of tunnel loop, the solution to solve it in this current specification (Release 9) is implementation specific until a standardized solution emerges.

The procedures described in clause 5 shall be interpreted as procedures which are executed for each PDN connection the UE established. This implies that:

– For the initial attachment of a PDN connection, the UE shall perform a Home Agent address discovery (subclause 5.1.2.1), a security association establishment via IKEv2, including the EAP-AKA authentication and the IPv6 Home Network Prefix assignment (subclause 5.1.2.2), and the initial binding registration (subclause 5.1.2.4).

– The handover procedure shall be performed for each PDN connection separately as described in subclause 5.2.2.

– The re-registration procedure shall be performed for each PDN connection separately as described in subclause 5.3.2.

– The detach procedure shall be performed for each PDN connection separately as described in subclause 5.4.2 or in subclause 5.4.3.

In addition to the above procedures, the following procedures described for an IFOM capable UE configured for IFOM shall be interpreted as procedures which are executed for each PDN connection that the UE has decided to apply the IFOM procedures. This implies that:

– The attach to additional access network procedure, as described in subclause 5.6.2, shall be performed by the UE separately for each PDN connection to which the access is to be the added.

– The inter-access flow mobility procedure, as described in subclause 5.7.2, shall be performed by the UE separately for each PDN connection when IP flows are to be moved amongest access networks.

– The removal of an access network procedure, as described in subclause 5.8.2, shall be performed by the UE separately for each PDN connection using the access network to be removed.