An IFOM capable UE shall perform HA IFOM capability discovery, i.e. an IFOM capable UE shall discover whether the HA supports IFOM or not. The HA IFOM capability can be performed using the following methods:

• as part of attach procedure for 3GPP access based on protocol configuration options;
• as part of a IKEv2 tunnel setup procedure with the HA; or
• using the information received from ANDSF.

The IFOM capable UE shall support HA IFOM capability discovery performed through IKEv2 tunnel setup procedure. The HA IFOM capability discovery performed within IKEv2 tunnel setup procedure with the HA is described in subclause 5.1.2.2. If the IFOM capable UE supports IPv6 Home Network Prefix assignment via PCO, the IFOM capable UE shall support HA IFOM capability discovery via PCO. The IFOM capable UE may use inter system routing policies (see TS 24.302 and TS 24.312) to perform the HA IFOM capability discovery for a specific APN. If the IFOM capable UE uses inter system routing policies to perform HA IFOM capability discovery, the UE may skip performing the HA IFOM capability discovery via PCO or the HA IFOM capability discovery via IKEv2.

The UE shall support the IKEv2 protocol (see RFC 5996) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in RFC 5996 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 RFC 4739 and the UE shall follow the WLAN UE procedure described in TS 33.234. The UE shall support IPsec ESP (see RFC 4303) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in RFC 4877. The UE shall support multiple authentication exchanges in the IKEv2 protocol as specified in RFC 4739 in order to support authentication with an external AAA server. The UE shall support the redirect mechanism as defined in RFC 5685. The UE shall initiate the security association establishment procedure by sending the IKE_SA_INIT request message defined in RFC 5996 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 RFC 5685. 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 TS 23.003. 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 RFC 4187. 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 HA may trigger the UE to perform the HA reallocation procedure. If the UE receives as part of the IKE_AUTH response message a REDIRECT payload containing the IP address of a target HA as specified in subclause 5.1.3.1, the UE shall initiate a new IKEv2 security association with the target HA. The UE shall terminate the IKEv2 security association with the initial HA by sending an IKEv2 Informational message with a DELETE payload as specified in RFC 5996. During the IKEv2 exchange, the UE shall request the allocation of an IPv6 home prefix through the Configuration Payload in the IKE_AUTH request message. 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 payload of the IKE_AUTH request message as described in RFC 5026. In addition the UE may include the INTERNAL_IP6_DNS attribute in the CFG_REQUEST as described in RFC 5996 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 payload to request the IPv4 address of the DNS server. During the IKEv2 exchange, if the UE receives an IKE_AUTH response message containing a Notify Payload with a Private Notify Message Type MAX_CONNECTION_REACHED as specified in TS 24.302, the UE shall close the related IKEv2 security association states. As long as none of existing IKEv2 security association is released, the UE shall not attempt to establish any additional IKEv2 security association. 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 RFC 4877. If the UE knows the IPv6 Home Network Prefix of a PDN connection for which the security association is to be setup, the UE shall insert a PDN Identifier notify payload, as defined in annex B, in the IKE_AUTH request message. The PDN Identifier notify payload shall contain the IPv6 Home Network Prefix of the PDN connection for which the security association is being set up. If the UE does not know the IPv6 Home Network Prefix of the PDN connection for which the security association is to be set up, the UE shall not include the PDN Identifier notify payload in the IKE_AUTH request message. If an IFOM capable UE performs HA IFOM capability discovery via IKEv2 procedure, the IFOM capable UE shall include the IFOM Capability notify payload (as specified in the Annex B.2) in the IKE_SA_INIT request message to perform HA IFOM capability discovery. If the IFOM capable UE receives in the IKE_SA_INIT response message the IFOM Capability notify payload, the IFOM capable UE shall behave as an IFOM capable UE configured for IFOM as the received payload indicates that the HA supports IFOM. If the IFOM capable UE does not receive in the IKE_SA_INIT response message the IFOM Capability notify payload, the IFOM capable UE shall behave as a UE which is not IFOM capable as the received payload indicates that the HA does not support IFOM.

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 connection 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 connection 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 TS 24.301, 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. If the IFOM capable UE performs the Home Network Prefix assignment via Protocol Configuration Option, the IFOM capable UE shall perform in the PDN CONNECTIVITY REQUEST message both Home Network Prefix assignment and the IFOM capability discovery.

After establishing the security association and obtaining the IPv6 Home Address, the UE shall send a Binding Update message as specified in RFC 6275 and RFC 5555 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. 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. The Alternate Care-of Address option shall not be included if a BID mobility option is added in the same Binding Update message. If IPv4 Care-of Address is used for initial binding registration, the UE shall send the Binding Update as follows (see RFC 5555):

• 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 IPv4 Care-of Address option shall not be included if a BID mobility option is added in the same Binding Update message.
• 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 RFC 5555.

If the UE is an IFOM capable UE configured for IFOM, the UE extends the Binding Update with the following options:

1. The UE shall set the O (Overwrite) flag to "1";
2. The UE shall include a BID identifier mobility option in the Binding Update as specified in RFC 5648;
   • The UE shall set the BID-PRI field to assign the priority to the BID as indicated in RFC 6089; and
3. The UE may create one or more routing rules with the HA. For each routing rule that the UE wants to register with the HA, the UE shall include a FID mobility option containing one traffic selector as specified in RFC 6089.
   • The FID field shall be set to an arbitrary value;
   • The FID-PRI field shall be set to the assigned priority of the FID as indicated in RFC 6089;
   • A Binding Reference suboption shall be included as defined in RFC 6089. As indicated in RFC 6089 the value assigned to the BID is the same included in the BID mobility option included in the Binding Update; and
   • Traffic selector suboption shall be set as specified in RFC 6089 and RFC 6088. The parameters described in the traffic selector suboption represent the routing filter that corresponds to the routing rule that the UE wants to register with the HA.

According to RFC 6089, traffic selector suboption contains parameters identifying downlink traffic, hence routing rules registered with the HA bind either a Care-of Address or a Home Address to the downlink traffic. The same bound IP address shall be used by the IFOM capable UE configured for IFOM to route the corresponding uplink traffic (i.e. asymmetrical routing is not allowed in this version of the specification). When the UE receives the Binding Acknowledgement from the HA, it shall validate it based on the rules described in RFC 6275 and RFC 5555. 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 RFC 6275. If the Binding Acknowledgement contains a value from 129 to 133 as specified in RFC 6275 or a value from 140 to 143 as specified in RFC 3963, 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. If the Binding Acknowledgment contains a BID mobility option, the UE shall process it as specified in RFC 5648. If the Binding Acknowledgment contains one or more flow mobility options, the UE shall process it as specified in RFC 6089. If the status field of the BID mobility option is set to zero, the IFOM capable UE configured for IFOM applies to every examined BID option the status code contained in the status field of the Binding Acknowledgement message as indicated in RFC 5648. If the value of the status field assigned to a BID mobility option is equal to 4 ("MCOA NOTCOMPLETE"), 164 ("MCOA MALFORMED"), 165 ("MCOA NON-MCOA") or 167 ("MCOA UNKOWN COA"), the IFOM capable UE configured for IFOM performs the operations described in RFC 5648. When processing a FID mobility option, if the value of the status field of the FID mobility option is 129 ("Flow binding rejected"), 130 ("Flow identification mobility option malformed"), 131 ("BID not found") or 132 ("FID not found"), the IFOM capable UE configured for IFOM performs the operations described in RFC 6089. 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 RFC 6275; IPv4 traffic shall be encapsulated in IPv6 packets as described in RFC 5555. 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 RFC 5555. Otherwise the UE shall send IPv6 and IPv4 packets encapsulated in IPv4 as specified in RFC 5555. Once the DSMIPv6 tunnel is established, the UE may build a DHCPv4 or DHCPv6 message as described in RFC 4039 or RFC 3736 respectively and send it via the DSMIPv6 tunnel as described in RFC 6275 in order to retrieve additional parameters, e.g. Vendor-specific options. The UE may also request additional IPv6 prefix(es) with length of /64 or shorter by using DHCPv6 Prefix Delegation as defined in RFC 6276.

The HA shall support the IKEv2 protocol (see RFC 5996) for negotiating the IPsec security association to secure DSMIPv6 signalling and shall support EAP over IKEv2 as described in RFC 5996 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 RFC 4739 and the HA shall follow the PDG procedure defined in TS 33.234. The HA shall support IPsec ESP (see RFC 4303) in order to provide authentication of Binding Update and Binding Acknowledgement messages as specified in RFC 4877. The HA shall support multiple authentication exchanges in the IKEv2 protocol as specified in RFC 4739 in order to support authentication with an external AAA server. The HA shall complete the IKE_SA_INIT exchange as specified in RFC 5996. 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 RFC 5026. If the UE included the INTERNAL_IP6_DNS or the INTERNAL_IP4_DNS in the CFG_REQUEST payload, the HA shall include the same attribute in the CFG_REPLY payload including zero or more DNS server addresses as specified in RFC 5996. If the HA needs to reject a IKEv2 security association establishment due to the network policies or capabilities to indicate that no more IKEv2 security association establishment request with any APN can be accepted for the UE, the HA shall include in the IKE_AUTH response message containing the IDr payload a Notify Payload with a Private Notify Message Type MAX_CONNECTION_REACHED as specified in TS 24.302. If the UE included a PDN Identifier notify payload within the IKE_AUTH request message, the HA may apply the following procedure:

1. Process the PDN Identifier notify payload according to RFC 5996; and
2. Use the IPv6 prefix contained in the payload to identify the PDN connection for which the security association is being set up and
   • if the HA is able to identify the PDN connection for which the security association is being set up, the HA shall insert the previously assigned IPv6 Home Network Prefix in the MIP6_HOME_PREFIX attribute in the CFG_REPLY payload; or
   • if the HA is not able to identify the PDN connection for which the security association is being set up, the HA shall ignore the content of the received PDN Identifier notify payload and allocate an IPv6 Home Network Prefix as described below.

When allocating an IPv6 Home Network Prefix, the HA shall apply one of the following procedures:

• If the IKEv2 message is received over an existing PDN connection, the assigned IPv6 network prefix of the PDN connection shall be sent to the UE as IPv6 Home Network Prefix in the MIP6_HOME_PREFIX attribute; or,
• If the IKEv2 message is not received over an existing PDN connection, and the UE has an existing PDN connection which has no IPSec security association established, the assigned IPv6 network prefix of the PDN connection shall be sent to the UE as IPv6 Home Network Prefix in the MIP6_HOME_PREFIX attribute; or,
• If the IKEv2 message is not received over an existing PDN connection, and the UE does not have an existing PDN connection which has no IPSec security association established, a new IPv6 network prefix shall be allocated and sent to the UE as IPv6 Home Network Prefix in the MIP6_HOME_PREFIX attribute.

An IFOM capable Home Agent shall implement the IFOM Capability notify payload. If the UE included the IFOM Capability notify payload within the IKE_SA_INIT request message, the HA shall perform the following procedures:

• process the IFOM Capability notify payload according to RFC 5996;
• if the HA is IFOM capable, the HA includes the IFOM Capability notify payload in the IKE_SA_INIT response message; and
• if the HA is not IFOM capable, the HA ignores the IFOM Capability notify payload received from the UE and in the IKE_SA_INIT response message will not include the IFOM Capability notify payload.

If the 3GPP AAA server triggers the HA to perform a HA reallocation procedure as specified in TS 33.402, the HA learns the IP address of the target HA as specified in TS 29.273. The HA shall provide to the UE the target HA IP address in the REDIRECT payload during IKE_AUTH exchange as specified in TS 33.402. The encoding of the REDIRECT payload in the IKE_AUTH response message is specified in RFC 5685. 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.

When the HA receives a Binding Update message from the UE, it shall validate it as described in RFC 6275 and in RFC 5555. If the Alternate Care-of Address option is present, the HA shall verify the correctness of the Alternate Care-of Address option. If the Care-of Address specified in the Alternate Care-of Address option and in the Source Address field of the IPv6 header of the Binding Update packet are different, the HA shall reject the request by returning a Binding Acknowledgement with status code 128. If the HA accepts the Binding Update message, it shall create a new entry in its binding cache for UE, marking it as a home registration. The lifetime of this binding cache entry is set based on operator's policies. The HA shall not perform a Duplicate Address Detection on the IPv6 Home Address of the UE because of the uniqueness of the IPv6 prefix assigned by the HA to the UE. Then the HA shall send a Binding Acknowledgement with R bit set to "1" as specified in RFC 6275 and RFC 3963. The HA may include the Binding Refresh Advice mobility option following rules defined in RFC 6275 to indicate the remaining time until the UE should send a new home binding update. If the Binding Update contains an IPv4 Home Address option with the 0.0.0.0 IPv4 address, the HA shall assign an IPv4 Home Address to the UE, including an IPv4 Address Acknowledgement option in the Binding Acknowledgement message, as specified in RFC 5555. If no IPv4 addresses are available at the HA, the HA shall send a Binding Acknowledgement with status code 132 in the IPv4 address acknowledgement option. If in the received Binding Update the IPv4 Care-of Address in the IPv4 Care-of Address option is not the same as the IPv4 address in the Source Address in the outer IPv4 header then a NAT was in the path. This information shall be included in the Binding Acknowledgement within a NAT Detection option with the F flag set and the Binding Acknowledgement shall be encapsulated based on the vanilla UDP encapsulation specified in RFC 5555. If a NAT was not detected, the HA shall send the Binding Acknowledgement without any UDP encapsulation; the message shall be encapsulated in an IPv4 header if the Care-of Address is IPv4 or in an IPv6 header if the Care-of Address is IPv6 as specified in RFC 5555. If the Binding Update contains a BID mobility option, the HA shall process it as specified in RFC 5648. If one or more FID mobility options are included in the received Binding Update, the HA shall process it as specified in RFC 6089 and RFC 6088. If binding update is accepted and IP flow mobility is supported, the HA shall insert the BID mobility option into the Binding Acknowledgement message as specified in RFC 5648. In addition, if the received Binding Update contains FID mobility option, the HA shall create the flow bindings accordingly and insert the FID mobility option into the Binding Acknowledgement message as specified in RFC 6089. If the binding update is accepted for both IPv4 and IPv6 home addresses, the HA creates two bindings, one for each home address as specified in RFC 5555. The HA shall link the IPv4 home address binding to the IPv6 home address binding. When the binding cache entry is created for the UE, the HA shall tunnel all packets destined to the IPv6 Home Address, the home network prefix and all packets destined to the IPv4 Home Address (if present) to the UE's Care-of Address. If a NAT was detected, packets shall be encapsulated in UDP and IPv4 based on vanilla UDP encapsulation specified in RFC 5555. If the Care-of Address is an IPv6 address, IPv4 and IPv6 packets shall be encapsulated in an IPv6 header as specified in RFC 6275 and in RFC 5555; otherwise, if the Care-of Address is an IPv4 address, IPv4 and IPv6 packets shall be encapsulated in an IPv4 header as specified in RFC 6275 and in RFC 5555. If the HA has multiple binding cache entries with flow bindings (see TS 23.261), the HA shall route all packets destined to the IPv6 Home Address, the home network prefix, the IPv6 prefix(es) assigned through DHCP prefix delegation (if present) and all packets destined to the IPv4 Home Address (if present) as described in RFC 6089. After the DSMIPv6 tunnel is established, if DHCPv6 Prefix Delegation request is received, the HA may assign additional IPv6 prefix(es) with length of /64 or shorter to the UE as defined in RFC 6276. Once the DHCPv6 Prefix Delegation procedure has been completed, the HA shall add the assigned delegated prefix(es) into the binding cache entry as defined in RFC 6276. When the delegated prefix(es) is included in the binding cache entry for UE, the HA shall tunnel all the packets destined to the delegated prefix(es) to the UE's Care-of Address.

When the HA receives a Binding Update and detects an unrecognized Mobility Header, the HA shall send a Binding Error message with status value 2 "Unrecognized MH Type value" as specified in RFC 6275. The HA shall include the Home address that was contained in the Home Address destination option. If NAT was not detected, the HA shall send the Binding Error without any UDP encapsulation; the message shall be encapsulated in an IPv4 header if the Care-of Address is IPv4 or in an IPv6 header if the Care-of Address is IPv6 in the same manner as the Binding Acknowledgement encapsulation specified in RFC 5555. If NAT was detected, the HA shall send the Binding Error encapsulated in UDP and IPv4 based on vanilla UDP encapsulation specified in RFC 5555.