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 |