15 Mobility management based on DSMIPv6 (Dual-Stack Mobile IPv6)

36.523-13GPPEvolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Packet Core (EPC)Part 1: Protocol conformance specificationRelease 17TSUser Equipment (UE) conformance specification

15.1 Discovery of the Home Agent via DNS

15.1.1 Test Purpose (TP)

(1)

with { UE has acquired an IP address and UE is configured with a DNS server address and UE is configured with the HA-APN Network Identifier }

ensure that {

when { UE is configured to discover IP address of Home Agent via DNS }

then { UE transmits a DNS Query with QNAME set to FQDN of the Home Agent }

}

15.1.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.1.2.1.1 and 5.1.2.1.2.

[TS 24.303, clause 5.1.2.1.1]

The first procedure the UE needs to perform for DSMIPv6 initial attach is the discovery of the node acting as the HA.

The UE can discover the IP addresses of the HA in one of the four following ways:

– via DNS;

– via attach procedure for 3GPP access or trusted non-3GPP access (if supported) based on protocol configuration options;

– via IKEv2 during tunnel setup to ePDG for untrusted non-3GPP accesses;

– via DHCPv6.

If the UE does not obtain the IP addresses of the HA via PCO during the 3GPP or trusted non-3GPP (if supported) attach or via IKEv2 signalling, it shall follow either the procedures described in subclause 5.1.2.1.5 or the procedures described in subclause 5.1.2.1.2. The UE may be configured to perform both procedures in parallel or one of the two procedures only in case the other failed.

[TS 24.303, clause 5.1.2.1.2]

A UE performing Home Agent discovery based on DNS shall support the implementation of standard DNS mechanisms.

The UE shall perform DNS Lookup by Home Agent Name as specified in IETF RFC 5026 [10].The QNAME shall be set to the requested HA-APN. The HA-APN shall be constructed as specified in 3GPP TS 23.003 [17]. If a HA has both an IPv4 and an IPv6 address, the corresponding DNS record should be configured with both ‘AAAA’ and ‘A’ records. Accordingly the UE should perform one DNS lookup procedure to retrieve both ‘AAAA’ and ‘A’ records. The DNS server replies with one ‘AAAA’ and one ‘A’ record.

15.1.3 Test description

15.1.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

– The UE is configured to discover the Home Agent address via DNS.

– The UE is configured with a DNS server address.

– The UE is configured with the HA-APN Network Identifier.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IP address.

15.1.3.2 Test procedure sequence

Table 15.1.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The UE transmits a DNS Query message with QNAME set to FQDN of the Home Agent (derived from HA-APN Network Identifier and PLMN information).

–>

DNS Query

1

P

2

The SS transmits a DNS Response message with the IPv6 and IPv4 addresses of the Home Agent.

<–

DNS Response

15.1.3.3 Specific message contents

Table 15.1.3.3-1: Message DNS Query (step 1, Table 15.1.3.2-1)

Field

Value/remark

Comment

Condition

QR=

‘0’

query

OPCODE=

‘0000’

QUERY

QNAME=

Fully Qualified Domain Name of the Home Agent

Derived from HA-APN Network Identifier and PLMN information as per TS 23.003 clause 21.2

QTYPE=

A

This is the query for the IPv4 address

QCLASS=

IN

QNAME=

Fully Qualified Domain Name of the Home Agent

Derived from HA-APN Network Identifier and PLMN information as per TS 23.003 clause 21.2

QTYPE=

AAAA

This is the query for the IPv6 address

QCLASS=

IN

Table 15.1.3.3-2: Message DNS Response (step 2, Table 15.1.3.2-1)

Information Element

Value/remark

Comment

Condition

QR=

‘1’

response

OPCODE=

‘0000’

QUERY

QNAME=

Same as received in DNS Query

QTYPE=

A

QCLASS=

IN

QNAME=

Same as received in DNS Query

QTYPE=

AAAA

QCLASS=

IN

RR {

NAME

Same as received in DNS Query

TYPE

A

CLASS

IN

RDATA

IPv4 address of HA

}

RR {

NAME

Same as received in DNS Query

TYPE

AAAA

CLASS

IN

RDATA

IPv6 address of HA

}

15.2 Discovery of the Home Agent via DHCP

15.2.1 Test Purpose (TP)

(1)

with { UE has acquired an IP address and UE is configured with the HA-APN Network Identifier }

ensure that {

when { UE is configured to discover IP address of Home Agent via DHCP }

then { UE transmits a DHCP Information-Request with Home Network Identifier Option containing the FQDN of the Home Agent}

}

15.2.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.1.2.1.1 and 5.1.2.1.5.

[TS 24.303, clause 5.1.2.1.1]

The first procedure the UE needs to perform for DSMIPv6 initial attach is the discovery of the node acting as the HA.

The UE can discover the IP addresses of the HA in one of the four following ways:

– via DNS;

– via attach procedure for 3GPP access or trusted non-3GPP access (if supported) based on protocol configuration options;

– via IKEv2 during tunnel setup to ePDG for untrusted non-3GPP accesses;

– via DHCPv6.

If the UE does not obtain the IP addresses of the HA via PCO during the 3GPP or trusted non-3GPP (if supported) attach or via IKEv2 signalling, it shall follow either the procedures described in subclause 5.1.2.1.5 or the procedures described in subclause 5.1.2.1.2. The UE may be configured to perform both procedures in parallel or one of the two procedures only in case the other failed.

[TS 24.303, clause 5.1.2.1.5]

The HA address discovery via DHCPv6 is possible in the following cases:

– in 3GPP access, or

– in trusted non-3GPP access, when a DHCPv6 relay exists in the trusted non-3GPP access and the PDN GW is the DHCPv6 server, or

– in trusted non-3GPP access, when the DHCPv6 server is in the trusted non-3GPP access and it has the HA addressee information from static configuration, or received via STa reference point as specified in 3GPP TS 29.273 [20].

A UE performing HA discovery based on DHCPv6 shall support the implementation of stateless DHCPv6 as specified in IETF RFC 3736 [13] and the DHCPv6 options as specified in draft-ietf-mip6-hiopt [12].

In order to discover the address of the HA the UE shall send an Information-Request message including the Home Network Identifier Option.

In order to connect to a HA for a specific target PDN, the UE shall set the id-type to 1 and include the desired HA-APN in the Home Network Identifier field.

The HA information is provided to the UE within a Home Network Information Option as described in draft-ietf-mip6-hiopt [12]. This option shall include either the available HA addresses (both the IPv6 address and the IPv4 address of the HA, if available) or the HA FQDN. In the latter case the UE shall perform a DNS Lookup by Home Agent Name as specified in IETF RFC 5026 [10]. The QNAME shall be set to the received HA FQDN.

If a HA has both an IPv4 and an IPv6 address, the corresponding DNS record should be configured with both ‘AAAA’ and ‘A’ records. Accordingly the UE should perform one DNS lookup procedure to retrieve both ‘AAAA’ and ‘A’ records. The DNS server replies with one ‘AAAA’ and one ‘A’ record.

15.2.3 Test description

15.2.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

– The UE is configured to discover the address of the Home Agent via DHCPv6.

– The UE is configured with the HA-APN Network Identifier.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv6 address.

15.2.3.2 Test procedure sequence

Table 15.2.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE transmit a DHCP Information-Request including a Home Network Information Option?

–>

DHCP Information-Request

1

P

2

The SS transmits a DHCP Reply message including a Home Network Information Option.

<–

DHCP Reply message

15.2.3.3 Specific message contents

Table 15.2.3.3-1: DHCP Information-Request (step 1, Table 15.2.3.2-1)

Field

Value/remark

Comment

Condition

msg-type

‘00001011’B

Information-Request

Transaction- id

Set by UE

option-code

‘0000000000000001’B

Option Client ID

DUID

Set by UE

option-code

‘0000000000000110’B

Option ORO

Requested-option-code-1

FFS

Home Network Identifier Option

Id-type

‘00000001’B

Target network identity present

Sub-opt-code

‘00000001’B

Home network identifier

Home Network Parameter

Fully Qualified Domain Name

Derived from HA-APN Network Identifier and PLMN information as per TS 23.003 clause 21.2

Table 15.2.3.3-2: DHCP Reply message (step 2, Table 15.2.3.2-2)

Field

Value/remark

Comment

Condition

msg-type

‘00000111’B

Reply

Transaction- id

Set as the same value of Transaction-id in step 1

option-code

‘0000000000000001’B

Option Client ID

DUID

Set as the DUID of the client received in step 1

option-code

‘0000000000000010’B

Option Server ID

DUID

Set by SS

Home Network Identifier Option

FFS

Home Network Identifier Option

Id-type

‘00000001’B

Target network identity present

Sub-opt-code

‘00000001’B

Home network identifier

Home Network Parameter

Fully Qualified Domain Name

Derived from HA-APN Network Identifier and PLMN information as per TS 23.003 clause 21.2

Sub-opt-code

‘00000011’B

IPv6 address

Home Network Parameter

IPv6 address of the Home Agent

Sub-opt-code

‘00000100’B

IPv4 address (optional value)

Home Network Parameter

IPv4 address of the Home Agent

15.3 Void

15.4 Security association establishment with Home Agent reallocation procedure

15.4.1 Test Purpose (TP)

(1)

with { UE has acquired an IP address }

ensure that {

when { UE has acquired the IP address of the Home Agent }

then { UE transmits an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment }

}

(2)

with { UE has transmitted an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment }

ensure that {

when { UE receives an IKE_SA_INIT response message }

then { UE transmits an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX to receive the prefix to use for Home Address configuration }

}

(3)

with { UE has transmitted an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX to receive the prefix to use for Home Address configuration }

ensure that {

when { UE receives an IKE_AUTH Response message including an EAP-Request/AKA Challenge }

then { UE transmits an IKE_AUTH Request message containing the correct EAP-Response/AKA-Challenge }

}

(4)

with { UE has transmitted an IKE_AUTH Request message containing an EAP-Response/AKA-Challenge }

ensure that {

when { UE receives an IKE_AUTH Response message including EAP-Success }

then { UE transmits an IKE_AUTH Request message with Authentication payload }

}

(5)

with { UE has transmitted an IKE_AUTH Request message with Authentication payload }

ensure that {

when { UE receives an IKE_AUTH Response message with Notify payload with a REDIRECT attribute containing the HOME AGENT address to connect to }

then { UE transmits an IKE_SA_INIT message addressed to the Home Agent whose address was received in the Notify Payload to initiate security association establishment }

}

15.4.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.1.2.2 and 5.1.3.1.

[TS 24.303, clause 5.1.2.2]

The UE shall support the IKEv2 protocol (see IETF RFC 4306 [14]) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in IETF RFC 4306 [14] to perform authentication with an AAA server. In a case an additional authentication and authorization of the IPSec security association is needed with an external AAA server, then the additional authentication steps during the IKEv2 exchange shall be supported as specified in IETF RFC 4739 [23] and described in 3GPP TS 33.234 [24].

The UE shall support IPsec ESP (see IETF RFC 4303 [11]) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4]. The UE shall support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [23] in order to support authentication with an external AAA server. The UE shall support the redirect mechanism as defined in draft-ietf-ipsecme-ikev2-redirect [30].

The UE shall initiate the security association establishment procedure by sending the IKE_SA_INIT request message defined in IETF RFC 4306 [14] to the HA. The UE shall indicate support for the HA reallocation by including a REDIRECT_SUPPORTED payload in the IKE_SA_INIT request as specified in draft-ietf-ipsecme-ikev2-redirect [30]. On receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message including the MN-NAI in the IDi payload and the Access Point Name (APN) of the target PDN the UE wants to connect to in the IDr payload. The APN shall be formatted as defined in 3GPP TS 23.003 [17]. The username part of the MN-NAI included in "IDi" payload may be an IMSI, pseudonym or re-authentication ID. The UE shall include in the IDi payload the same MN-NAI it includes in the EAP-Response/Identity within the EAP-AKA exchange.

In the very first EAP-Response/Identity within the IKEv2 exchange the UE shall include a NAI whose username is derived from IMSI. In subsequent exchanges the UE should use pseudonyms and re-authentication identities provided by the 3GPP AAA server as specified in IETF RFC 4187 [26].

NOTE: Fast re‑authentication mechanism is optional, and therefore is an implementation option in the UE and operator configuration issue (i.e. it also depends on whether the AAA server sent a re-authentication ID during previous EAP authentication) whether to use it during security association establishment.

EAP-AKA over IKEv2 shall be used to authenticate UE in the IKE_AUTH exchange, while public key signature based authentication with certificates shall be used to authenticate the HA.

During the IKEv2 exchange, the UE shall request the allocation of an IPv6 home prefix through the Configuration Payload in the IKE_AUTH. Since in EPS a unique IPv6 prefix is assigned to the UE, the UE shall include a MIP6_HOME_PREFIX attribute in the CFG_REQUEST message as described in IETF RFC 5026 [10]. In addition the UE may include the INTERNAL_IP6_DNS attribute in the CFG_REQUEST as described in IETF RFC 4306 [14] to request the DNS server IPv6 address of the PLMN it is connecting to via DSMIPv6. In the same way the UE may include the INTERNAL_IP4_DNS attribute in the CFG_REQUEST to request the IPv4 address of the DNS server.

The UE shall then auto-configure a Home Address from the IPv6 prefix received from the HA and shall run a CREATE_CHILD_SA exchange to create the security association for the new Home Address. In the CREATE_CHILD_SA exchange the UE shall include the Home Address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate the IPsec security association for protecting the Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4].

[TS 24.303, clause 5.1.3.1]

The HA shall support the IKEv2 protocol (see IETF RFC 4306 [14]) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in IETF RFC 4306 [14] to perform UE authentication with an AAA server. If an additional authentication and authorization of the IPSec security association were needed with an external AAA server, then the additional authentication steps during the IKEv2 exchange shall be supported as specified in IETF RFC 4739 [23] and defined in 3GPP TS 33.234 [24]. The HA shall support IPsec ESP (see IETF RFC 4303 [11]) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4]. The HA shall support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [23] in order to support authentication with an external AAA server.

The HA shall complete the IKE_SA_INIT exchange as specified in IETF RFC 4306 [14]. The HA shall include in the IDr the same value included by the UE in the IDr payload of the request.

Upon successful authorization and authentication, the HA shall accept the security association establishment request by sending the IKE_AUTH response message with the CFG_REPLY payload including the IPv6 Home Network Prefix allocated to the UE in the MIP6_HOME_PREFIX attribute. This prefix information shall include the prefix length as specified in IETF RFC 5026 [10]. If the UE included the INTERNAL_IP6_DNS or the INTERNAL_IP4_DNS in the CFG_REQUEST, the HA shall include the same attribute in the CFG_REPLY including zero or more DNS server addresses as specified in IETF RFC 4306 [14]

If the 3GPP AAA server triggers the HA to perform a HA reallocation procedure as specified in 3GPP TS 33.402 [18], the HA learns the IP address of the target HA as specified in 3GPP TS 29.273 [20]. The HA shall provide to the UE the target HA IP address in the REDIRECT payload during IKE_AUTH exchange as specified in 3GPP TS 33.402 [18]. The encoding of the REDIRECT payload in the IKE_AUTH response message is specified in draft-ietf-ipsecme-ikev2-redirect [30]. The HA shall not assign an IPv6 prefix to the UE in the IKE_AUTH exchange. The HA shall remove the states of the IKEv2 security association with the UE after receiving an IKEv2 Informational message with a DELETE payload from the UE.

15.4.3 Test description

15.4.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IP address.

– The UE has discovered the IP address of the Home Agent (either via DNS, DHCPv6, IKEv2 signalling or during Attach Procedure via PCO).

15.4.3.2 Test procedure sequence

Table 15.4.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE transmit an IKE_SA_INIT message addressed to the Home Agent?

–>

IKE_SA_INIT

1

P

2

The SS transmits an IKE_SA_INIT message.

<–

IKE_SA_INIT

3

Check: Does the UE transmit an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX, a MN-NAI derived from UE IMSI in the IDi field and an APN in the IDr field?

–>

IKE_AUTH Request

2

P

4

The SS transmits an IKE_AUTH Response message including an EAP-Request/AKA-Challenge.

<–

IKE_AUTH Response

5

Check: Does the UE transmit an IKE_AUTH Request message including the EAP-Response/AKA-Challenge?

–>

IKE_AUTH Request

3

P

6

The SS transmits an IKE_AUTH Response message including EAP-Success.

<–

IKE_AUTH Response

7

Check: Does the UE transmit an IKE_AUTH Request message with Authentication payload?

–>

IKE_AUTH Request

4

P

8

The SS transmits an IKE_AUTH Response message with Notify payload containing REDIRECT attribute with the Home Agent to be used

<–

IKE_AUTH Response

9

Check: Does the UE transmit an IKE_SA_INIT message addressed to the Home Agent whose address was provided in the REDIRECT Notify payload?

–>

IKE_SA_INIT

5

P

15.4.3.3 Specific message contents

Table 15.4.3.3-1: Message IKE_SA_INIT (step 1, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Set by the UE

Responder’s IKE_SA SPI

0

First message in IKE_SA_INIT exchange

Next Payload

‘00100001’B

SA

Exchange Type

‘00100010’B

IKE_SA_INIT

Security Association Payload

Next Payload

’00100010’B

KE

More proposal

‘00000010’B

Proposal #

‘00000001’B

First cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00000011’B

3DES in CBC mode (ENCR_3DES)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000010’B

PRF_HMAC_SHA1 (HMAC‑SHA1)

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000010’B

HMAC-SHA1-96 (AUTH_HMAC_SHA1_96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Last proposal

‘00000000’B

Proposal #

‘00000010’B

Second cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00001011’B

AES with 128-bit keys in CBC mode (ENCR_AES_CBC)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000100’B

PRF_AES128_XCBC_ AES-XCBC-PRF-128

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000101’B

AES-XCBC-MAC-96 (AUTH_ AES-XCBC -96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Key Exchange Payload

Next Payload

‘00101000’B

Nonce

DH Group #

‘0000000000000010’B

DH group 2

Key Exchange data

Set by the UE

Nonce Payload

Next Payload

‘00101001’B

Notify (REDIRECT_SUPPORTED)

Nonce data

Random number set by the UE

REDIRECT_SUPPORTED Notify Payload

Next Payload

‘00000000’B

No Next Payload

Protocol ID

‘00000000’B

Notification is not specific to a particular security association

SPI size

‘00000000’B

SPI field not present

Notify Message Type

‘0100000000010110’B

REDIRECT_SUPPORTED

Table 15.4.3.3-2: Message IKE_SA_INIT (step 2, Table 15.4.3.2-1)

Information Element

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE in IKE_SA_INIT as Step 1

Responder’s IKE_SA SPI

Set by the SS

Next Payload

‘00100001’B

SA

Exchange Type

‘00100010’B

IKE_SA_INIT

Security Association Payload

Next Payload

’00100010’B

KE

Proposal

One of the 2 proposals included in IKE_SA_INIT at Step 1

Key Exchange Payload

Next payload

‘00 101000’B

Nonce

DH Group #

‘0000000000000010’B

DH group 2

Key Exchange data

Set by the SS

Nonce Payload

Next t payload

‘00000000’B

No Next Payload

Nonce data

Set by the SS

Table 15.4.3.3-3: Message IKE_AUTH Request (step 3, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100011’B

IDi

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Identification – Initiator Payload

Next Payload

‘00101111’B

CP

ID Type

00000010B

ID

Set to MN-NAI

Configuration Payload

Next Payload

‘00100001’B

SA

CFG Type

‘00000001’B

Request

Configuration Attribute

‘00010000’B

MIP6_HOME_PREFIX attribute

Length

‘0000000000000000’B

Security Association Payload

Next Payload

‘00101100’B

TSi

Proposals

Any set of allowed values

Traffic Selector – Initiator Payload

Next Payload

‘00101100’B

TSr

Traffic selector data

Any allowed set of values

Traffic Selector – Responder Payload

Next Payload

‘00100100’B

IDr

Traffic selector data

Any allowed set of values

Identification – Responder Payload

Next Payload

‘00000000’B

No Next Payload

ID Type

‘00000010’B

ID

APN

Padding

Set by the UE

Fields from Encrypted payload

Pad Length

Set by the UE

Fields from Encrypted payload

Integrity checksum data

Set by the UE

Fields from Encrypted payload

Table 15.4.3.3-4: Message IKE_AUTH Response (step 4, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100100’B

IDr

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Identification – Responder Payload

Next Payload

‘00100101’B

CERT

ID Type

‘00000010’B

ID

APN

Certificate Payload

Next Payload

‘00110000’B

EAP

Cert encoding

’00000100’B

X.509 certificate – signature

Certificate data

Set by the SS

DER encoded X.509 certificate

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000001’B

Request

Type

‘00010111’B

AKA

Subtype

AKA-Challenge

Attribute type

’00000001’B

AT_RAND

AT_RAND

An arbitrarily selected 128 bits value

Attribute Type

‘00000010’B

AT_AUTN

AT_AUTN

See TS 24.301 [28] subclause 9.9.3.2

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.4.3.3-5: Message IKE_AUTH Request (step 5, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00110000’B

EAP

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000010’B

Response

Type

‘00010111’B

AKA

Subtype

AKA-Challenge

Attribute type

’00000011’B

AT_RES

AT_RES

See TS 24.301 [28] subclause 9.9.3.4

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.4.3.3-6: Message IKE_AUTH Response (step 6, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00110000’B

EAP

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000011’B

Success

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.4.3.3-7: Message IKE_AUTH Request (step 7, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’

IKE_AUTH

Encrypted Payload

Next Payload

‘00100111’B

AUTH

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Auth Method

’00000010’B

Shared Key Integrity code

Auth Data

derived from the MSK obtained from AKA exchange

RFC 4306 defines the function to derive this key (section 2.15)

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.4.3.3-8: Message IKE_AUTH Response (step 8, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100111’B

AUTH

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Authentication Payload

Next Payload

‘00101001’B

Notify

Auth Method

’00000010’B

Shared Key Integrity code

Auth Data

derived from the MSK obtained from AKA exchange

RFC 4306 defines the function to derive this key (section 2.15)

Notify Payload

Next Payload

‘00100001’B

SA

Protocol ID

‘00000000’B

Notification is not specific to a particular security association

SPI Size

‘00000000’B

SPI field not present

Notify Message Type Length

‘0100000000010111’B

REDIRECT

GW Ident Type

‘00000101’B

New Responder GW Identity

IPv6 address of the HA to relocate

GW Ident Type

‘00000001’B

New Responder GW Identity

IPv4 address of the HA to relocate

Optional

Security Association Payload

Next Payload

‘00101101’

TSi

Proposal

One of the 2 proposals included in IKE_AUTH Request at Step 3

Traffic Selector – Initiator Payload

Next Payload

‘00101100’B

TSr

Traffic Selector data

Any allowed set of values

Traffic Selector – Responder Payload

Next Payload

‘00000000’B

No Next Payload

Traffic Selector data

Any allowed set of values

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.4.3.3-910: Message IKE_SA_INIT (step 109, Table 15.4.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Set by the UE

Responder’s IKE_SA SPI

0

First message in IKE_SA_INIT exchange

Next Payload

‘00100001’B

SA

Exchange Type

‘00100010’B

IKE_SA_INIT

Security Association Payload

Next Payload

’00100010’B

KE

More proposal

‘00000010’B

Proposal #

‘00000001’B

First cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00000011’B

3DES in CBC mode (ENCR_3DES)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000010’B

PRF_HMAC_SHA1 (HMAC‑SHA1)

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000010’B

HMAC-SHA1-96 (AUTH_HMAC_SHA1_96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Last proposal

‘00000000’B

Proposal #

‘00000010’B

Second cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00001011’B

AES with 128-bit keys in CBC mode (ENCR_AES_CBC)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000100’B

PRF_AES128_XCBC_ AES-XCBC-PRF-128

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000101’B

AES-XCBC-MAC-96 (AUTH_ AES-XCBC -96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Key Exchange Payload

Next Payload

‘00101000’B

Nonce

DH Group #

‘0000000000000010’B

DH group 2

Key Exchange data

Set by the UE

Nonce Payload

Next Payload

‘00101001’B

Notify (REDIRECT_SUPPORTED)

Nonce data

Random number set by the UE

REDIRECT_SUPPORTED Notify Payload

Next Payload

‘00101001’B

Notify (REDIRECT_FROM)

Protocol ID

‘00000000’B

Notification is not specific to a particular security association

SPI size

‘00000000’B

SPI field not present

Notify Message Type

‘0100000000010110’B

REDIRECT_SUPPORTED

Notify Payload

Next Payload

‘00000000’B

No next payload

Protocol ID

‘00000000’B

Notification is not specific to a particular security association

SPI Size

‘00000000’B

SPI field not present

Notify Message Type

‘0100000000011000’B

REDIRECT_From

GW Ident Type

Any allowed value (IPv6 or IPv4 or HA FQDN)

Set depending on how the UE has discovered the HA in the preamble

New Responder GW Identity

Depends on GW Ident type

15.5 Security association establishment without Home Agent reallocation procedure

15.5.1 Test Purpose (TP)

(1)

with { UE has acquired an IP address }

ensure that {

when { UE has acquired the IP address of the Home Agent }

then { UE transmits an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment }

}

(2)

with { UE has transmitted an IKE_SA_INIT message addressed to the Home Agent to initiate security association establishment }

ensure that {

when { UE receives an IKE_SA_INIT response message }

then { UE transmits an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX to receive the prefix to use for Home Address configuration }

}

(3)

with { UE has transmitted an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX to receive the prefix to use for Home Address configuration }

ensure that {

when { UE receives an IKE_AUTH Response message including an EAP-Request/AKA Challenge }

then { UE transmits an IKE_AUTH Request message containing the correct EAP-Response/AKA-Challenge }

}

(4)

with { UE has transmitted an IKE_AUTH Request message containing an EAP-Response/AKA-Challenge }

ensure that {

when { UE receives an IKE_AUTH Response message including EAP-Success }

then { UE transmits an IKE_AUTH Request message with Authentication payload }

}

(5)

with { UE has transmitted an IKE_AUTH Request message with Authentication payload }

ensure that {

when { UE receives an IKE_AUTH Response message with configuration payload MIP6_HOME_PREFIX containing the Home Network Prefix HNP associated to the UE }

then { UE transmits a CREATE_CHILD_SA Request message including traffic selectors fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU)/Binding Acknowledgments (BA) messages }

}

15.5.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clause 5.1.2.2.

[TS 24.303, clause 5.1.2.2]

The UE shall support the IKEv2 protocol (see IETF RFC 4306 [14]) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in IETF RFC 4306 [14] to perform authentication with an AAA server. In a case an additional authentication and authorization of the IPSec security association is needed with an external AAA server, then the additional authentication steps during the IKEv2 exchange shall be supported as specified in IETF RFC 4739 [23] and described in 3GPP TS 33.234 [24].

The UE shall support IPsec ESP (see IETF RFC 4303 [11]) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4]. The UE shall support multiple authentication exchanges in the IKEv2 protocol as specified in IETF RFC 4739 [23] in order to support authentication with an external AAA server. The UE shall support the redirect mechanism as defined in draft-ietf-ipsecme-ikev2-redirect [30].

The UE shall initiate the security association establishment procedure by sending the IKE_SA_INIT request message defined in IETF RFC 4306 [14] to the HA. The UE shall indicate support for the HA reallocation by including a REDIRECT_SUPPORTED payload in the IKE_SA_INIT request as specified in draft-ietf-ipsecme-ikev2-redirect [30]. On receipt of an IKE_SA_INIT response, the UE shall send an IKE_AUTH request message including the MN-NAI in the IDi payload and the Access Point Name (APN) of the target PDN the UE wants to connect to in the IDr payload. The APN shall be formatted as defined in 3GPP TS 23.003 [17]. The username part of the MN-NAI included in "IDi" payload may be an IMSI, pseudonym or re-authentication ID. The UE shall include in the IDi payload the same MN-NAI it includes in the EAP-Response/Identity within the EAP-AKA exchange.

In the very first EAP-Response/Identity within the IKEv2 exchange the UE shall include a NAI whose username is derived from IMSI. In subsequent exchanges the UE should use pseudonyms and re-authentication identities provided by the 3GPP AAA server as specified in IETF RFC 4187 [26].

NOTE: Fast re‑authentication mechanism is optional, and therefore is an implementation option in the UE and operator configuration issue (i.e. it also depends on whether the AAA server sent a re-authentication ID during previous EAP authentication) whether to use it during security association establishment.

EAP-AKA over IKEv2 shall be used to authenticate UE in the IKE_AUTH exchange, while public key signature based authentication with certificates shall be used to authenticate the HA.

During the IKEv2 exchange, the UE shall request the allocation of an IPv6 home prefix through the Configuration Payload in the IKE_AUTH. Since in EPS a unique IPv6 prefix is assigned to the UE, the UE shall include a MIP6_HOME_PREFIX attribute in the CFG_REQUEST message as described in IETF RFC 5026 [10]. In addition the UE may include the INTERNAL_IP6_DNS attribute in the CFG_REQUEST as described in IETF RFC 4306 [14] to request the DNS server IPv6 address of the PLMN it is connecting to via DSMIPv6. In the same way the UE may include the INTERNAL_IP4_DNS attribute in the CFG_REQUEST to request the IPv4 address of the DNS server.

The UE shall then auto-configure a Home Address from the IPv6 prefix received from the HA and shall run a CREATE_CHILD_SA exchange to create the security association for the new Home Address. In the CREATE_CHILD_SA exchange the UE shall include the Home Address and the appropriate selectors in the TSi (Traffic Selector-initiator) payload to negotiate the IPsec security association for protecting the Binding Update and Binding Acknowledgement messages as specified in IETF RFC 4877 [4].

15.5.3 Test description

15.5.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IP address.

– The UE has discovered the IP address of the Home Agent (either via DNS, DHCPv6, IKEv2 signalling or during Attach Procedure via PCO).

15.5.3.2 Test procedure sequence

Table 15.5.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE transmit an IKE_SA_INIT message addressed to the Home Agent?

–>

IKE_SA_INIT

1

P

2

The SS transmits an IKE_SA_INIT message.

<–

IKE_SA_INIT

3

Check: Does the UE transmit an IKE_AUTH Request message containing the configuration payload MIP6_HOME_PREFIX, a MN-NAI derived from UE IMSI in the IDi field and an APN in the IDr field?

–>

IKE_AUTH Request

2

P

4

The SS transmits an IKE_AUTH Response message including an EAP-Request/AKA-Challenge.

<–

IKE_AUTH Response

5

Check: Does the UE transmit an IKE_AUTH Request message including the EAP-Response/AKA-Challenge?

–>

IKE_AUTH Request

3

P

6

The SS transmits an IKE_AUTH Response message including EAP-Success.

<–

IKE_AUTH Response

7

Check: Does the UE transmit an IKE_AUTH Request message with Authentication payload?

–>

IKE_AUTH Request

4

P

8

The SS transmits an IKE_AUTH Response message with configuration payload MIP6_HOME_PREFIX containing the Home Network Prefix HNP associated to the UE.

<–

IKE_AUTH Response

9

Check: Does the UE transmit a CREATE_CHILD_SA Request message including traffic selectors’ fields (TSi and TSr) that contain the parameters identifying the Binding Update (BU) / Binding Acknowledgments (BA) messages?

–>

CREATE_CHILD_SA Request

5

P

10

The SS transmits a CREATE_CHILD_SA Response message.

<–

CREATE_CHILD_SA Response

15.5.3.3 Specific message contents

Table 15.5.3.3-1: Message IKE_SA_INIT (step 1, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Set by the UE

Responder’s IKE_SA SPI

0

First message in IKE_SA_INIT exchange

Next Payload

‘00100001’B

SA

Exchange Type

‘00100010’B

IKE_SA_INIT

Security Association Payload

Next Payload

’00100010’B

KE

More proposal

‘00000010’B

Proposal #

‘00000001’B

First cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00000011’B

3DES in CBC mode (ENCR_3DES)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000010’B

PRF_HMAC_SHA1 (HMAC‑SHA1)

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000010’B

HMAC-SHA1-96 (AUTH_HMAC_SHA1_96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Last proposal

‘00000000’B

Proposal #

‘00000010’B

Second cryptographic suite (section 6.5 of TS 33.234)

Protocol ID

‘00000001’B

IKE

SPI size

‘00000000’B

Number of transforms

‘00000010’B

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00001011’B

AES with 128-bit keys in CBC mode (ENCR_AES_CBC)

More transform

‘00000011’B

This is the transform for prf

Transform type

‘00000010’B

PRF

Transform ID

‘00000100’B

PRF_AES128_XCBC_ AES-XCBC-PRF-128

More transform

‘00000011’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000101’B

AES-XCBC-MAC-96 (AUTH_ AES-XCBC -96)

Last transform

‘00000000’B

This is the transform for DH

Transform type

‘00000100’B

DH

Transform ID

‘00000010’B

Diffie-Hellman group 2 (1024-bit MODP)

Key Exchange Payload

Next Payload

‘00101000’B

Nonce

DH Group #

‘0000000000000010’B

DH group 2

Key Exchange data

Set by the UE

Nonce Payload

Next Payload

‘00101001’B

Notify (REDIRECT_SUPPORTED)

Nonce data

Random number set by the UE

REDIRECT_SUPPORTED Notify Payload

Next Payload

‘00000000’B

No Next Payload

Protocol ID

‘00000000’B

Notification is not specific to a particular security association

SPI size

‘00000000’B

SPI field not present

Notify Message Type

‘0100000000010110’B

REDIRECT_SUPPORTED

Table 15.5.3.3-2: Message IKE_SA_INIT (step 2, Table 15.5.3.2-1)

Information Element

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE in IKE_SA_INIT as Step 1

Responder’s IKE_SA SPI

Set by the SS

Next Payload

‘00100001’B

SA

Exchange Type

‘00100010’B

IKE_SA_INIT

Security Association Payload

Next Payload

’00100010’B

KE

Proposal

One of the 2 proposals included in IKE_SA_INIT at Step 1

Key Exchange Payload

Next payload

‘00 101000’B

Nonce

DH Group #

‘0000000000000010’B

DH group 2

Key Exchange data

Set by the SS

Nonce Payload

Next t payload

‘00000000’B

No Next Payload

Nonce data

Set by the SS

Table 15.5.3.3-3: Message IKE_AUTH Request (step 3, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100011’B

IDi

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Identification – Initiator Payload

Next Payload

‘00101111’B

CP

ID Type

00000010B

ID

Set to MN-NAI

Configuration Payload

Next Payload

‘00100001’B

SA

CFG Type

‘00000001’B

Request

Configuration Attribute

‘00010000’B

MIP6_HOME_PREFIX attribute

Length

‘0000000000000000’B

Security Association Payload

Next Payload

‘00101100’B

TSi

Proposals

Any set of allowed values

Traffic Selector – Initiator Payload

Next Payload

‘00101100’B

TSr

Traffic selector data

Any allowed set of values

Traffic Selector – Responder Payload

Next Payload

‘00100100’B

IDr

Traffic selector data

Any allowed set of values

Identification – Responder Payload

Next Payload

‘00000000’B

No Next Payload

ID Type

‘00000010’B

ID

APN

Padding

Set by the UE

Fields from Encrypted payload

Pad Length

Set by the UE

Fields from Encrypted payload

Integrity checksum data

Set by the UE

Fields from Encrypted payload

Table 15.5.3.3-4: Message IKE_AUTH Response (step 4, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100100’B

IDr

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Identification – Responder Payload

Next Payload

‘00100101’B

CERT

ID Type

‘00000010’B

ID

APN

Certificate Payload

Next Payload

‘00110000’B

EAP

Cert encoding

’00000100’B

X.509 certificate – signature

Certificate data

Set by the SS

DER encoded X.509 certificate

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000001’B

Request

Type

‘00010111’B

AKA

Subtype

AKA-Challenge

Attribute type

’00000001’B

AT_RAND

AT_RAND

An arbitrarily selected 128 bits value

Attribute Type

‘00000010’B

AT_AUTN

AT_AUTN

See TS 24.301 [28] subclause 9.9.3.2

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.5.3.3-5: Message IKE_AUTH Request (step 5, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00110000’B

EAP

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000010’B

Response

Type

‘00010111’B

AKA

Subtype

AKA-Challenge

Attribute type

’00000011’B

AT_RES

AT_RES

See TS 24.301 [28] subclause 9.9.3.4

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.5.3.3-6: Message IKE_AUTH Response (step 6, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00110000’B

EAP

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Extensible Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Code

‘00000011’B

Success

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.5.3.3-7: Message IKE_AUTH Request (step 7, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’

IKE_AUTH

Encrypted Payload

Next Payload

‘00100111’B

AUTH

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Authentication Payload

Next Payload

‘00000000’B

No Next Payload

Auth Method

’00000010’B

Shared Key Integrity code

Auth Data

derived from the MSK obtained from AKA exchange

RFC 4306 defines the function to derive this key (section 2.15)

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.5.3.3-8: Message IKE_AUTH Response (step 8, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00100011’B

IKE_AUTH

Encrypted Payload

Next Payload

‘00100111’B

AUTH

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Authentication Payload

Next Payload

‘00101111’B

CP

Auth Method

’00000010’B

Shared Key Integrity code

Auth Data

derived from the MSK obtained from AKA exchange

RFC 4306 defines the function to derive this key (section 2.15)

Configuration Payload

Next Payload

‘00100001’B

SA

CFG Type

‘00000010’B

Reply

Configuration Attribute

‘00010000’B

MIP6_HOME_PREFIX attribute

Length

‘0000000000010101’B

Prefix lifetime

Any allowed value

Home Prefix

IPv6 prefix – 16 bytes

Prefix length

‘10000000’B

Prefix length must be 64

Security Association Payload

Next Payload

‘00101101’

TSi

Proposal

One of the 2 proposals included in IKE_AUTH Request at Step 3

Traffic Selector – Initiator Payload

Next Payload

‘00101100’B

TSr

Traffic Selector data

Any allowed set of values

Traffic Selector – Responder Payload

Next Payload

‘00000000’B

No Next Payload

Traffic Selector data

Any allowed set of values

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

Table 15.5.3.3-9: Message CREATE_CHILD_SA Request (step 9, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00 100100’B

CREATE_CHILD_SA

Encrypted Payload

Next Payload

‘00100001’B

SA

Initialization Vector

Random value set by the UE

Encrypted IKE Payloads

Security Association Payload

Next Payload

‘00101000’B

Ni

More proposal

‘00000010’B

Proposal #

‘00000001’B

First cryptographic suite (section 6.6 of TS 33.234)

Protocol ID

‘00000011’B

ESP

SPI size

‘00000100’B

# of transforms

‘00000010’B

SPI

Set by the UE

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00000011’B

3DES in CBC mode (ENCR_3DES)

Last transform

‘00000000’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform attribute ID

‘00000010’B

HMAC-SHA1-96 (AUTH_HMAC_SHA1_96)

Last proposal

‘00000000’B

Proposal #

‘00000010’B

Second cryptographic suite (section 6.6 of TS 33.234)

Protocol ID

‘00000011’B

ESP

SPI size

‘00000100’B

# of transforms

‘00000010’B

SPI

Set by the UE

More transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform ID

‘00001011’B

AES with 128-bit keys in CBC mode (ENCR_AES_CBC)

Last transform

‘00000000’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform ID

‘00000101’B

AES-XCBC-MAC-96 (AUTH_ AES-XCBC -96)

Nonce Payload

Next Payload

‘00101100’B

TSi

Nonce data

Random number set by the UE

Traffic Selector – Initiator Payload

Next Payload

‘00101101’B

TSr

Traffic Selector data

Any set of values containing the traffic selector of the CREATE_CHILD_SA Response at Step 10

Traffic Selector – Responder Payload

Next Payload

‘00101001’B

Notify (Use transport mode)

Traffic Selector data

Any set of values containing the traffic selector of the CREATE_CHILD_SA Response at Step 10

Use transport mode Notify Payload

Next payload

‘00101001’B

Notify (Use transport mode)

Protocol ID

‘00000011’B

ESP

SPI size

‘00000100’B

Notify Message Type

‘1000000000000111’B

Use transport mode

SPI

Same as that set by the UE in SA proposal #1

Use transport mode Notify Payload

Next payload

‘00000000’B

No Next Payload

Protocol ID

‘00000011’B

ESP

SPI size

‘00000100’B

Notify Message Type

‘1000000000000111’B

Use transport mode

SPI

Same as that set by the UE in SA proposal #1

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.5.3.3-10: Message CREATE_CHILD_SA Response (step 10, Table 15.5.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 1

Responder’s IKE_SA SPI

Same as that set by the SS at Step 2

Next Payload

‘00101110’B

E

Exchange Type

‘00 100100’B

CREATE_CHILD_SA

Encrypted Payload

Next Payload

‘00100001’

SA

Initialization Vector

Set by the SS

Encrypted IKE Payloads

Security Association Payload

Next Payload

‘00101000’B

Nr

Last proposal

‘00000000’B

Proposal #

One of the 2 proposals included in the CREATE_CHILD_SA Request at Step 9

Protocol ID

‘00000011’B

ESP

SPI size

‘00000100’B

SPI

Set by the SS

First transform

‘00000011’B

This is the transform for confidentiality

Transform type

‘00000001’B

Encryption

Transform attribute type

The corresponding value of the chosen proposal

Last transform

‘00000000’B

This is the transform for integrity

Transform type

‘00000011’B

Integrity

Transform attribute type

The corresponding value of the chosen proposal

Nonce Payload

Next Payload

‘00101100’B

TSi

Nonce data

Set by the SS

Traffic Selector – Initiator Payload

Next Payload

‘00101101’B

TSr

Number of traffic selectors

‘00000010’B

TS type

‘00001000’B

IPv6 range

IP protocol

‘10000111B

Mobility header

Start port

‘0000010100000000’B

BU

End port

‘0000010100000000’B

BU

Starting-address

HoA address derived from HNP

Ending address

HoA address derived from HNP

TS type

‘00001000’B

IPv6 range

IP protocol

‘10000111B

Mobility header

Start port

‘0000011000000000’B

BA

End port

‘0000011000000000’B

BA

Starting-address

HoA address derived from HNP

Ending address

HoA address derived from HNP

Traffic Selector – Responder Payload

Next Payload

‘00101001’B

Notify (Use transport mode)

Number of traffic selectors

‘00000010’B

Ts type

‘00001000’B

IPv6 range

IP protocol

‘10000111B

Mobility header

Start port

‘0000010100000000’B

BU

End port

‘0000010100000000’B

BU

Starting-address

HA address

Ending address

HA address

TS type

‘00001000’B

IPv6 range

IP protocol

‘10000111’B

Mobility header

Start port

‘0000011000000000’B

BA

End port

‘0000011000000000’B

BA

Starting-address

HA address

Ending address

HA address

Use transport mode Notify Payload

Next Payload

‘00000000’B

Protocol ID

‘00000011’B

ESP

SPI size

Set by the SS

Notify Message Type

‘1000000000000111’B

Use transport mode

SPI

Same as that set by the SS in the accepted SA proposal

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

15.6 Registration of a new IPv6 CoA (Binding Update/Acknowledgment procedure in IPv6 network)

15.6.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address }

ensure that {

when { UE receives a Router Advertisement containing an IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble and different from the prefixes contained in the UE’s Prefix list }

then { UE transmits a Binding Update message in order to register it Home Address and Care-of-Address at the Home Agent }

}

15.6.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.1.2.3, 5.1.2.4, and 5.2.2.3.

[TS 24.303, clause 5.1.2.3]

The DSMIPv6 Home Link Detection Function is used by the UE to detect if an access interface is on the home link for a PDN from a DSMIPv6 perspective. The Home Link Detection function shall be performed before sending DSMIPv6 Binding Update via the same access interface.

To perform the Home Link Detection procedure, the UE shall compare the assigned Home Network Prefix for a PDN with the IPv6 prefix or prefixes included in the Prefix Information Option in the Router Advertisements received on the local link. The Home Network Prefix can be assigned in a 3GPP access via PCO, as specified in 3GPP TS 24.301 [15], or via IKEv2 as specified in subclause 5.1.2.2. If there is a match between the Home Network Prefix and one of the local prefixes, the UE is attached on the home link over the respective access interface and shall not send a Binding Update to the HA unless the UE currently has a valid DSMIPv6 Binding Update list entry. If the UE has a valid DSMIPv6 Binding Update list entry, the UE shall proceed to perform the action specified in subclause 5.2.2.4. If there is not any match, the UE shall proceed as specified in subclause 5.1.2.4.

NOTE: The UE does not need to run IKEv2 for home link detection if the Home Network prefix is dynamically received in a PCO Information Element.

[TS 24.303, clause 5.1.2.4]

After establishing the security association and obtaining the IPv6 Home Address, the UE shall send a Binding Update message as specified in IETF RFC 3775 [6] and IETF RFC 5555 [2] in order to register its Home Address and Care-of Address at the HA, if it detects it is in the foreign network.

If both IPv4 and IPv6 Care-of Address are received at the foreign network, the UE shall first attempt to use the IPv6 Care-of Address for its binding registration. The UE shall not register both IPv4 and IPv6 Care-of Address to it’s HA.

If IPv6 Care-of Address is used for initial binding registration, the UE shall send the Binding Update message to the IPv6 address of the HA. In this Binding Update message the H (home registration) and A (acknowledge) bits shall be set. If the UE needs an IPv4 Home Address, the UE shall include the 0.0.0.0 address in the IPv4 Home Address option to request a dynamic IPv4 Home Address.

When IPv6 Care-of Address is used for initial binding registration, the Alternate Care-of Address option shall be used by the UE to carry the Care-of Address inside a Mobility Header which is protected by ESP. If this option is present, the address included in this option is the same address present in the source address of the IPv6 packet.

If IPv4 Care-of Address is used for initial binding registration, the UE shall send the Binding Update as follows (see IETF RFC 5555 [2]):

– The IPv6 packet, with the IPv6 Home Address as the Source Address field of the IPv6 header, shall be encapsulated in UDP.

– The UE shall include the IPv4 Care-of Address as the Source Address field of the IPv4 header and the HA IPv4 address as the Destination Address field of the IPv4 header.

– The UE shall include the IPv4 Care-of Address option containing the IPv4 Care-of Address.

– The UE shall set the H (home registration) and A (acknowledge) flags.

– The UE shall set the F (UDP encapsulation required) flag to 0.

– The UE shall set the R (Mobile Router Flag) flag to 1.

– If the UE needs an IPv4 Home Address, the UE shall include an IPv4 Home Address option with the 0.0.0.0 address in the Binding Update message, as defined in IETF RFC 5555 [2].

When the UE receives the Binding Acknowledgement from the HA, it shall validate it based on the rules described in IETF RFC 3775 [6] and IETF RFC 5555 [2]. If the Binding Acknowledgement contains the successful status code 0 ("Binding Update Accepted"), the UE shall create an entry for the registered Home Address in its Binding Update List and may start sending packets containing its IPv6 Home Address or other IPv6 addresses auto-configured from the assigned home network prefix.

If the Binding Acknowledgement contains a value of 128, the UE may re-send the BU as specified in IETF RFC 3775 [6]. If the Binding Acknowledgement contains a value from 129 to 133 as specified in IETF RFC 3775 [6] or a value from 140 to 143 as specified in IETF RFC 3963 [29], the UE shall not send the BU to the HA and should discover another HA.

If the Binding Acknowledgment contains an IPv4 Address Acknowledgement option with status code value from 0 to 127 (indicating success), the UE shall create two entries in its Binding Update List, one for the IPv6 Home Address and another for the IPv4 Home Address. If the Binding Acknowledgement contains an IPv4 Address Acknowledgment option with status code indicating error (i.e. 128 or higher), the UE shall create an entry only for the IPv6 HoA in its binding update list. Moreover, if the status code is 129 ("Administratively prohibited") or 132 ("Dynamic IPv4 home address assignment not available"), the UE shall not re-send the Binding Update and it shall use only the IPv6 HoA. If the Binding Acknowledgement contains an IPv4 Address Acknowledgement option with status 128 ("Failure, reason unspecified"), 130 ("Incorrect IPv4 home address"), 131 ("Invalid IPv4 address") or 133 ("Prefix allocation unauthorized") it shall re-send the Binding Update including the 0.0.0.0 address in the IPv4 Home Address option. If the Binding Acknowledgement does not contain an IPv4 Address Acknowledgment option, the UE shall create an entry only for the IPv6 HoA in its binding update list.

NOTE: The value to be used to identify the IPv4 address acknowledgement option in the mobility header is 30;

The UE may then send data traffic either with the IPv6 Home Address or with the IPv4 Home Address. If the UE is located on an IP6-enabled link, it shall send IPv6 packets as described in IETF RFC 3775 [6]; IPv4 traffic shall be encapsulated in IPv6 packets as described in IETF RFC 5555 [2]. If the UE is located on an IPv4-only link and the Binding Acknowledgement contains the NAT detection option with the F flag set, the UE shall send IPv6 and IPv4 packets following the vanilla UDP encapsulation rules specified in IETF RFC 5555 [2]. Otherwise the UE shall send IPv6 and IPv4 packets encapsulated in IPv4 as specified in IETF RFC 5555 [2].

Once the DSMIPv6 tunnel is established, the UE may build a DHCPv4 or DHCPv6 message as described in IETF RFC 4039 [26] or IETF RFC 3736 [13] respectively and send it via the DSMIPv6 tunnel as described in IETF RFC 3775 [6] in order to retrieve additional parameters, e.g. Vendor-specific options.

[TS 24.303, clause 5.2.2.3]

If the access network supports IPv6, as soon as the UE has received via a Router Advertisement at least an IPv6 prefix which is not present in its Prefix List, the UE shall perform the Home Link detection as specified in subclause 5.1.2.3.

If the UE detects it is not attached to the home link, the UE shall send a Binding Update to the HA including the newly configured IP address as the Care-of Address in the Source IP address of the packet and optionally in the Alternate Care-of Address Option [6]. The UE build the Binding Update message as specified in IETF RFC 3775 [6].

If the UE has been assigned also an IPv4 Home Address and wants to update also the binding for it, the UE shall include the IPv4 Home Address option including the assigned IPv4 Home Address in the same Binding Update message.

If the UE has been assigned also an IPv4 Home Address and wants to release it, the UE shall not include any IPv4 Home Address option in the same Binding Update.

If the UE does not have an IPv4 Home Address but wants to configure one, the UE shall include the IPv4 Home Address option with the 0.0.0.0 address as specified in subclause 5.1.2.4.

If the access network supports only IPv4, as soon as the UE has configured an IPv4 Care-of Address which is different from the previous Care-of Address, the UE shall send a Binding Update tunnelled in UDP as specified in draft-ietf-mext-nemo-v4traversal [2]. The UE shall set the F flag to "0". The UE shall set the R flag to "1".

Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the Binding Update message.

15.6.3 Test description

15.6.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

– The UE’s Prefix List has been cleared.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv6 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5 with the following exception: the IPv6 home prefix assigned to the UE by the SS shall be the same as the prefix used during IP address acquisition by the UE.

15.6.3.2 Test procedure sequence

Table 15.6.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS broadcasts a Router Advertisement with a Prefix Information Option containing an IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble.

2

Check: Does the UE transmit a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP destination Address field of the IP header?

–>

Binding Update

1

P

3

The SS transmits a Binding Acknowledgement accepting the Binding Update.

<–

Binding Acknowledgement

15.6.3.3 Specific message contents

Table 15.6.3.3-1: Router Advertisement (step 1, Table 15.6.3.2-1)

Derivation path: 36.508, Table 4.7C.2-1

Field

Value/remark

Comment

Condition

Prefix

IPv6 prefix different from the Home Network Prefix assigned to the UE during the preamble

15.7 Registration of a new IPv4 CoA (Binding Update/Acknowledgment procedure in IPv4 network)

15.7.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address }

ensure that {

when { UE is connected to a network supporting IPv4 only}

then { UE transmits a Binding Update message in order to register its Home Address and Care-of-Address at the Home Agent }

}

15.7.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.1.2.3, 5.1.2.4, and 5.2.2.3.

[TS 24.303, clause 5.1.2.3]

The DSMIPv6 Home Link Detection Function is used by the UE to detect if an access interface is on the home link for a PDN from a DSMIPv6 perspective. The Home Link Detection function shall be performed before sending DSMIPv6 Binding Update via the same access interface.

To perform the Home Link Detection procedure, the UE shall compare the assigned Home Network Prefix for a PDN with the IPv6 prefix or prefixes included in the Prefix Information Option in the Router Advertisements received on the local link. The Home Network Prefix can be assigned in a 3GPP access via PCO, as specified in 3GPP TS 24.301 [15], or via IKEv2 as specified in subclause 5.1.2.2. If there is a match between the Home Network Prefix and one of the local prefixes, the UE is attached on the home link over the respective access interface and shall not send a Binding Update to the HA unless the UE currently has a valid DSMIPv6 Binding Update list entry. If the UE has a valid DSMIPv6 Binding Update list entry, the UE shall proceed to perform the action specified in subclause 5.2.2.4. If there is not any match, the UE shall proceed as specified in subclause 5.1.2.4.

NOTE: The UE does not need to run IKEv2 for home link detection if the Home Network prefix is dynamically received in a PCO Information Element.

[TS 24.303, clause 5.1.2.4]

After establishing the security association and obtaining the IPv6 Home Address, the UE shall send a Binding Update message as specified in IETF RFC 3775 [6] and IETF RFC 5555 [2] in order to register its Home Address and Care-of Address at the HA, if it detects it is in the foreign network.

If both IPv4 and IPv6 Care-of Address are received at the foreign network, the UE shall first attempt to use the IPv6 Care-of Address for its binding registration. The UE shall not register both IPv4 and IPv6 Care-of Address to it’s HA.

If IPv6 Care-of Address is used for initial binding registration, the UE shall send the Binding Update message to the IPv6 address of the HA. In this Binding Update message the H (home registration) and A (acknowledge) bits shall be set. If the UE needs an IPv4 Home Address, the UE shall include the 0.0.0.0 address in the IPv4 Home Address option to request a dynamic IPv4 Home Address.

When IPv6 Care-of Address is used for initial binding registration, the Alternate Care-of Address option shall be used by the UE to carry the Care-of Address inside a Mobility Header which is protected by ESP. If this option is present, the address included in this option is the same address present in the source address of the IPv6 packet.

If IPv4 Care-of Address is used for initial binding registration, the UE shall send the Binding Update as follows (see IETF RFC 5555 [2]):

– The IPv6 packet, with the IPv6 Home Address as the Source Address field of the IPv6 header, shall be encapsulated in UDP.

– The UE shall include the IPv4 Care-of Address as the Source Address field of the IPv4 header and the HA IPv4 address as the Destination Address field of the IPv4 header.

– The UE shall include the IPv4 Care-of Address option containing the IPv4 Care-of Address.

– The UE shall set the H (home registration) and A (acknowledge) flags.

– The UE shall set the F (UDP encapsulation required) flag to 0.

– The UE shall set the R (Mobile Router Flag) flag to 1.

– If the UE needs an IPv4 Home Address, the UE shall include an IPv4 Home Address option with the 0.0.0.0 address in the Binding Update message, as defined in IETF RFC 5555 [2].

When the UE receives the Binding Acknowledgement from the HA, it shall validate it based on the rules described in IETF RFC 3775 [6] and IETF RFC 5555 [2]. If the Binding Acknowledgement contains the successful status code 0 ("Binding Update Accepted"), the UE shall create an entry for the registered Home Address in its Binding Update List and may start sending packets containing its IPv6 Home Address or other IPv6 addresses auto-configured from the assigned home network prefix.

If the Binding Acknowledgement contains a value of 128, the UE may re-send the BU as specified in IETF RFC 3775 [6]. If the Binding Acknowledgement contains a value from 129 to 133 as specified in IETF RFC 3775 [6] or a value from 140 to 143 as specified in IETF RFC 3963 [29], the UE shall not send the BU to the HA and should discover another HA.

If the Binding Acknowledgment contains an IPv4 Address Acknowledgement option with status code value from 0 to 127 (indicating success), the UE shall create two entries in its Binding Update List, one for the IPv6 Home Address and another for the IPv4 Home Address. If the Binding Acknowledgement contains an IPv4 Address Acknowledgment option with status code indicating error (i.e. 128 or higher), the UE shall create an entry only for the IPv6 HoA in its binding update list. Moreover, if the status code is 129 ("Administratively prohibited") or 132 ("Dynamic IPv4 home address assignment not available"), the UE shall not re-send the Binding Update and it shall use only the IPv6 HoA. If the Binding Acknowledgement contains an IPv4 Address Acknowledgement option with status 128 ("Failure, reason unspecified"), 130 ("Incorrect IPv4 home address"), 131 ("Invalid IPv4 address") or 133 ("Prefix allocation unauthorized") it shall re-send the Binding Update including the 0.0.0.0 address in the IPv4 Home Address option. If the Binding Acknowledgement does not contain an IPv4 Address Acknowledgment option, the UE shall create an entry only for the IPv6 HoA in its binding update list.

NOTE: The value to be used to identify the IPv4 address acknowledgement option in the mobility header is 30;

The UE may then send data traffic either with the IPv6 Home Address or with the IPv4 Home Address. If the UE is located on an IP6-enabled link, it shall send IPv6 packets as described in IETF RFC 3775 [6]; IPv4 traffic shall be encapsulated in IPv6 packets as described in IETF RFC 5555 [2]. If the UE is located on an IPv4-only link and the Binding Acknowledgement contains the NAT detection option with the F flag set, the UE shall send IPv6 and IPv4 packets following the vanilla UDP encapsulation rules specified in IETF RFC 5555 [2]. Otherwise the UE shall send IPv6 and IPv4 packets encapsulated in IPv4 as specified in IETF RFC 5555 [2].

Once the DSMIPv6 tunnel is established, the UE may build a DHCPv4 or DHCPv6 message as described in IETF RFC 4039 [26] or IETF RFC 3736 [13] respectively and send it via the DSMIPv6 tunnel as described in IETF RFC 3775 [6] in order to retrieve additional parameters, e.g. Vendor-specific options.

[TS 24.303, clause 5.2.2.3]

If the access network supports IPv6, as soon as the UE has received via a Router Advertisement at least an IPv6 prefix which is not present in its Prefix List, the UE shall perform the Home Link detection as specified in subclause 5.1.2.3.

If the UE detects it is not attached to the home link, the UE shall send a Binding Update to the HA including the newly configured IP address as the Care-of Address in the Source IP address of the packet and optionally in the Alternate Care-of Address Option [6]. The UE build the Binding Update message as specified in IETF RFC 3775 [6].

If the UE has been assigned also an IPv4 Home Address and wants to update also the binding for it, the UE shall include the IPv4 Home Address option including the assigned IPv4 Home Address in the same Binding Update message.

If the UE has been assigned also an IPv4 Home Address and wants to release it, the UE shall not include any IPv4 Home Address option in the same Binding Update.

If the UE does not have an IPv4 Home Address but wants to configure one, the UE shall include the IPv4 Home Address option with the 0.0.0.0 address as specified in subclause 5.1.2.4.

If the access network supports only IPv4, as soon as the UE has configured an IPv4 Care-of Address which is different from the previous Care-of Address, the UE shall send a Binding Update tunnelled in UDP as specified in draft-ietf-mext-nemo-v4traversal [2]. The UE shall set the F flag to "0". The UE shall set the R flag to "1".

Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the Binding Update message.

15.7.3 Test description

15.7.3.1 Pre-test conditions

System Simulator:

– Cell 1.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5.

15.7.3.2 Test procedure sequence

Table 15.7.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

Check: Does the UE transmit a Binding Update with its IPv4 CoA in the IP Source Address field of the IP Header and the Binding Update encapsulated in an UDP header?

–>

Binding Update

1

P

2

The SS transmits a Binding Acknowledgement accepting the Binding Update.

<–

Binding Acknowledgement

15.7.3.3 Specific message contents

None.

15.8 Re-registration of IPv6 CoA

15.8.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address and registered its IPv6 Home Address and IPv6 Care-of-Address at the Home Agent }

ensure that {

when { registration of its Care-of-Address is about the expire }

then { UE initiates the re-registration procedure to extend lifetime of the registration of its Care-of-Address }

}

15.8.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clause 5.3.2.

[TS 24.303, clause 5.3.2]

As specified in IETF RFC 3775 [6], if the UE wants to extend the validity of an existing binding at the HA, the UE shall send a new Binding Update to the HA before the expiration of the lifetime indicated in the received Binding Acknowledgement, even if it is not changing its primary Care-of Address. This Binding Update is usually referred as periodic Binding Update.

The UE shall follow the rules described in IETF RC 3775 [6], IETF RFC 5555 [2] and in subclause 5.1.2.4 to send a periodic Binding Update and handle the associated Binding Acknowledgement. As the UE has not performed any handover, the UE shall confirm the already registered Care of Address and shall indicate the desired lifetime value. In a periodic Binding Update the UE may request an IPv4 Home Address.

15.8.3 Test description

15.8.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

– The UE’s Prefix List has been cleared.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv6 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5 with the following exception: the IPv6 home prefix assigned to the UE by the SS shall be the same as the prefix used during IP address acquisition by the UE.

15.8.3.2 Test procedure sequence

Table 15.8.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1-3

Steps 1 to 3 of test case 15.6 are performed on Cell 1.

NOTE: The UE transmits an initial Binding Update to register its IPv6 Home Address and IPv6 Care-of-Address at the Home Agent. The SS accepts the Binding Update by transmitting a Binding Acknowledgement with a Lifetime set to 10 min.

4

Check: Does the UE transmit a Binding Update with its IPv6 CoA in the IP Source Address field of the IP Header and the IPv6 Home Agent address in the IP Destination Address field of the IP header within 10 min of Step 3?

–>

Binding Update

1

P

5

The SS transmits a Binding Acknowledgement accepting the Binding Update.

<–

Binding Acknowledgement

15.8.3.3 Specific message contents

None.

15.9 Re-registration of IPv4 CoA

15.9.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address and registered its IPv6 Home Address and IPv4 Care-of-Address at the Home Agent }

ensure that {

when { registration of its Care-of-Address is about the expire }

then { UE initiates the re-registration procedure to extend lifetime of the registration of its Care-of-Address }

}

15.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clause 5.3.2.

[TS 24.303, clause 5.3.2]

As specified in IETF RFC 3775 [6], if the UE wants to extend the validity of an existing binding at the HA, the UE shall send a new Binding Update to the HA before the expiration of the lifetime indicated in the received Binding Acknowledgement, even if it is not changing its primary Care-of Address. This Binding Update is usually referred as periodic Binding Update.

The UE shall follow the rules described in IETF RC 3775 [6], IETF RFC 5555 [2] and in subclause 5.1.2.4 to send a periodic Binding Update and handle the associated Binding Acknowledgement. As the UE has not performed any handover, the UE shall confirm the already registered Care of Address and shall indicate the desired lifetime value. In a periodic Binding Update the UE may request an IPv4 Home Address.

15.9.3 Test description

15.9.3.1 Pre-test conditions

System Simulator:

– Cell 1.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5.

15.9.3.2 Test procedure sequence

Table 15.9.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1-2

Steps 1 to 2 of test case 15.7 are performed on Cell 1.

NOTE: The UE transmits an initial Binding Update to register its IPv6 Home Address and IPv4 Care-of-Address at the Home Agent. The SS accepts the Binding Update by transmitting a Binding Acknowledgement with a Lifetime set to 10 min.

3

Check: Does the UE transmit a Binding Update with its IPv4 CoA in the IP Source Address field of the IP Header and the IPv4 Home Agent address in the IP destination Address field of the IP header within 10 min of Step 2?

–>

Binding Update

1

P

4

The SS transmits a Binding Acknowledgement accepting the Binding Update.

<–

Binding Acknowledgement

15.9.3.3 Specific message contents

None.

15.10 Return to home link

15.10.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address and registered its IPv6 Home Address and IPv6 Care-of-Address at the Home Agent }

ensure that {

when { UE detects it is attached to the home link }

then { UE transmits a Binding Update message with the lifetime field set to “0” }

}

15.10.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clause 5.2.2.4.

[TS 24.303, clause 5.2.2.4]

If the access network supports IPv6, as soon as the UE has received via a Router Advertisement message at least an IPv6 prefix which is not present in its Prefix List, the UE shall perform the Home Link detection as specified in subclause 5.1.2.3 to detect if the UE is attaching to the home link. If the UE detects it is attached to the home link and there is a valid DSMIPv6 Binding Update list entry at the UE, the UE shall send a Binding Update with the Lifetime field set to "0" in order to remove the binding at the HA, as specified in IETF RFC 3775 [6]. If an IPv4 home address was assigned to the UE, as an optimization the UE may not include the IPv4 home address option as the binding for the IPv4 home address will be removed by the HA. Independent of an IPv6 or IPv4 access network the UE shall set the Key Management Capability (K) bit in the de-registration Binding Update message. The UE may preserve the IKEv2 session in order to avoid re-establishing the session when the next handover occurs. If there is not a safe assumption that the UE will remain in the home link (e.g. switching off the non-3GPP radio interface in case of a dual radio terminal), the UE should preserve the IKEv2 session.

15.10.3 Test description

15.10.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv6 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5 with the following exception: the IPv6 home prefix assigned to the UE by the SS shall be the same as the prefix used during IP address acquisition by the UE.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv6 address) at the Home Agent, by executing the steps in test case 15.6.

15.10.3.2 Test procedure sequence

Table 15.10.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS broadcasts a Router Advertisement with a Prefix Information Option containing an IPv6 prefix matching the Home Network Prefix assigned to the UE during the preamble.

2

Check: Does the UE transmit a Binding Update message with the lifetime field set to “0”?

–>

Binding Update

1

P

3

The SS transmits a Binding Acknowledgement accepting the Binding Update with the lifetime field set to “0”.

<–

Binding Acknowledgement

15.10.3.3 Specific message contents

Table 15.10.3.3-1: Router Advertisement (step 1, Table 15.10.3.2-1)

Derivation path: 36.508 table 4.7C.2-1

Field

Value/remark

Comment

Condition

Prefix

IPv6 prefix equal to Home Network Prefix assigned to the UE during preamble

Table 15.10.3.3-2: Binding Update (step 2, Table 15.10.3.2-1)

Derivation path: 36.508 table 4.7C.2-2

Information Element

Value/remark

Comment

Condition

Lifetime

‘0000000000000000’B

Table 15.10.3.3-3: Binding Acknowledgement (step 3, Table 15.10.3.2-1)

Derivation path: 36.508 table 4.7C.2-3

Information Element

Value/remark

Comment

Condition

Lifetime

‘0000000000000000’B

15.11 Dual-Stack Mobile IPv6 detach in IPv6 network

15.11.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address and registered its IPv6 Home Address and IPv6 Care-of-Address at the Home Agent }

ensure that {

when { UE receives a Binding Revocation Indication message from the HA }

then { UE transmits a Binding Revocation Acknowledgement message with the status field set to ‘Success’ }

}

(2)

with { UE has received a Binding Revocation Indication message from the HA }

ensure that {

when { UE has transmitted a Binding Revocation Acknowledgement message with the status field set to ‘Success’ }

then { UE transmits an IKEv2 INFORMATIONAL message containing a DELETE payload to remove the Ipsec security association associated with the DSMIPv6 registration }

}

15.11.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.4.2.1 and 5.4.2.2.

[TS 24.303, clauses 5.4.2.1]

Upon receiving a Binding Revocation Indication (BRI) message according to draft-ietf-mext-binding-revocation [19] from the HA, the UE first shall perform the required validity checks on the BRI according to draft-ietf-mext-binding-revocation [19].

The UE shall send a Binding Revocation Acknowledgement (BRA) as specified in draft-ietf-mext-binding-revocation [19]. In this message the UE shall set the status field to ‘Success’ to reflect that it has received the BRI message. The BRA message may be tunnelled in UDP or IPv4 as specified in subclause 5.1.2.4 for Binding Update messages.

The UE then shall remove the entry identified in the BRI as deregistered from its binding update list and shall use the procedures defined in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration as described in subclause 5.4.2.2.

[TS 24.303, clause 5.4.2.2]

To detach from a specific PDN to which it is connected through a DSMIPv6 session, the UE shall send a Binding Update with the Lifetime field set to 0 as specified in IETF RFC 3775 [6].

The UE shall use the procedures defined in the IKEv2 protocol in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration. The UE shall close the security associations associated with the DSMIPv6 registration and instruct the HA to do the same by sending the INFORMATIONAL request message including a DELETE payload. The Protocol ID in the DELETE payload shall be set to "1" (IKE) to indicate that all IPsec ESP security associations that were negotiated within the IKEv2 exchange shall be deleted.

15.11.3 Test description

15.11.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv6 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5 with the following exception: the IPv6 home prefix assigned to the UE by the SS shall be the same as the prefix used during IP address acquisition by the UE.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv6 address) at the Home Agent, by executing the steps in test case 15.6.

15.11.3.2 Test procedure sequence

Table 15.11.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits a Binding Revocation Indication message to the UE.

<–

Binding Revocation Indication

2

Check: Does the UE transmit a Binding Revocation Acknowledgement message with the status field set to ‘Success’?

–>

Binding Revocation Acknowledgement

1

P

3

Check: Does the UE transmit an IKEv2 INFORMATIONAL message containing a DELETE payload?

–>

IKEv2 INFORMATIONAL

2

P

4

The SS transmits an IKEv2 INFORMATIONAL message containing a DELETE payload back to the UE.

<–

IKEv2 INFORMATIONAL

15.11.3.3 Specific message contents

Table 15.11.3.3-1: IKEv2 INFORMATIONAL (step 3, Table 15.11.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

The one identifying the UE in the SA set up during the preamble

Responder’s IKE_SA SPI

The one identifying the HA in the SA set up during the preamble

Next Payload

‘00101110’B

E

Exchange Type

‘00100101’B

INFORMATIONAL

Encrypted Payload

Next Payload

‘00101010’B

DELETE

Delete Payload

Next Payload

‘00000000’B

No Next Payload

Protocol ID

‘00000001’B

IKE SA

Padding

Set by the UE

Fields from Encryption payload

Pad Length

Set by the UE

Fields from Encryption payload

Integrity checksum data

Set by the UE

Fields from Encryption payload

Table 15.11.3.3-2: IKEv2 INFORMATIONAL (step 4, Table 15.11.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 3

Responder’s IKE_SA SPI

Same as that set by the SS at Step 3

Next Payload

‘00101110’B

E

Exchange Type

‘00100101’B

INFORMATIONAL

Encrypted Payload

Next Payload

‘00101010’B

DELETE

Delete Payload

Next Payload

‘00000000’B

No Next Payload

Protocol ID

‘00000001’B

IKE SA

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload

15.12 Dual-Stack Mobile IPv6 detach in IPv4 network

15.12.1 Test Purpose (TP)

(1)

with { UE has established a security association with the Home Agent and received the IPv6 Home Address and registered its IPv6 Home Address and IPv4 Care-of-Address at the Home Agent }

ensure that {

when { UE receives a Binding Revocation Indication message from the HA with the A flag set }

then { UE transmits a Binding Revocation Acknowledgement message with the status field set to ‘Success’ }

}

(2)

with { UE has received a Binding Revocation Indication message from the HA with the A flag set }

ensure that {

when { UE has transmitted a Binding Revocation Acknowledgement message with the status field set to ‘Success’ }

then { UE transmits an IKEv2 INFORMATIONAL message containing a DELETE payload to remove the Ipsec security association associated with the DSMIPv6 registration }

}

15.12.2 Conformance requirements

References: The conformance requirements covered in the present TC are specified in: TS 24.303, clauses 5.4.2.1 and 5.4.2.2.

[TS 24.303, clauses 5.4.2.1]

Upon receiving a Binding Revocation Indication (BRI) message according to draft-ietf-mext-binding-revocation [19] from the HA, the UE first shall perform the required validity checks on the BRI according to draft-ietf-mext-binding-revocation [19].

If the A (Acknowledge) flag is set in the BRI message, the UE shall send a Binding Revocation Acknowledgement (BRA) as specified in draft-ietf-mext-binding-revocation [19]. In this message the UE shall set the status field to ‘Success’ to reflect that it has received the BRI message. The BRA message may be tunnelled in UDP or IPv4 as specified in subclause 5.1.2.4 for Binding Update messages.

The UE then shall remove the entry identified in the BRI as deregistered from its binding update list and shall use the procedures defined in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration as described in subclause 5.4.2.2.

[TS 24.303, clause 5.4.2.2]

The UE shall use the procedures defined in the IKEv2 protocol in IETF RFC 4306 [14] to remove the IPsec security associations associated with the DSMIPv6 registration. The UE shall close the security associations associated with the DSMIPv6 registration and instruct the HA to do the same by sending the INFORMATIONAL request message including a DELETE payload. The Protocol ID in the DELETE payload shall be set to "1" (IKE) to indicate that all IPsec ESP security associations that were negotiated within the IKEv2 exchange shall be deleted.

15.12.3 Test description

15.12.3.1 Pre-test conditions

System Simulator:

– Cell 1.

UE:

None.

Preamble:

– The UE is in state Registered, Idle Mode (state 2) on Cell 1 according to [18].

– The UE has acquired an IPv4 address.

– The UE has established a security association with the Home Agent and obtained an IPv6 Home Address, by executing the steps in test case 15.5.

– The UE has registered its IPv6 Home Address and its Care-of-Address (acquired IPv4 address) at the Home Agent, by executing the steps in test case 15.7.

15.12.3.2 Test procedure sequence

Table 15.12.3.2-1: Main behaviour

St

Procedure

Message Sequence

TP

Verdict

U – S

Message

1

The SS transmits a Binding Revocation Indication message with the A flag set to the UE.

<–

Binding Revocation Indication

2

Check: Does the UE transmit a Binding Revocation Acknowledgement message with the status field set to ‘Success’?

–>

Binding Revocation Acknowledgement

1

P

3

Check: Does the UE transmit an IKEv2 INFORMATIONAL message containing a DELETE payload?

–>

IKEv2 INFORMATIONAL

2

P

4

The SS transmits an IKEv2 INFORMATIONAL message containing a DELETE payload back to the UE.

<–

IKEv2 INFORMATIONAL

15.12.3.3 Specific message contents

Table 15.12.3.3-1: IKE_INFORMATIONAL (step 3, Table 15.12.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

The one identifying UE in the SA set up during the preamble

Responder’s IKE_SA SPI

The one identifying the HA in the SA set up during the preamble

Next Payload

‘00101110’B

E

Exchange Type

‘00100101’B

INFORMATIONAL

Encrypted Payload

Next Payload

‘00101010’B

DELETE

Delete Payload

Next Payload

‘00000000’B

No next payload

Protocol ID

‘00000001’B

IKE SA

Padding

Set by UE

Fields from Encryption payload

Pad Length

Set by UE

Fields from Encryption payload

Integrity checksum data

Set by UE

Fields from Encryption payload

Table 15.12.3.3-2: IKE_INFORMATIONAL (step 4, Table 15.12.3.2-1)

Field

Value/remark

Comment

Condition

IKE Header

Initiator’s IKE_SA SPI

Same as that set by the UE at Step 3

Responder’s IKE_SA SPI

Same as that set by the SS at Step 3

Next Payload

‘00101110’B

E

Exchange Type

‘00100101’B

INFORMATIONAL

Encrypted Payload

Next Payload

‘00101010’B

DELETE

Delete Payload

Next Payload

‘00000000’B

No next payload

Protocol ID

‘00000001’B

IKE SA

Padding

Set by the SS

Fields from Encryption payload

Pad Length

Set by the SS

Fields from Encryption payload

Integrity checksum data

Set by the SS

Fields from Encryption payload