5 FACoA procedures for mobile IPv4
24.3043GPPMobility management based on Mobile IPv4Release 17Stage 3TSUser Equipment (UE) - foreign agent interface
5.1 FACoA initial attach and registration
5.1.1 General
The MIPv4 initial attach is performed by the UE to establish a MIPv4 connection with the node acting as the HA. The initial attach involves the following procedures:
– Discovery of the HA address. The UE needs to discover the IPv4 address of the node acting as the HA.
– Discovery of FACoA. The UE needs to discover the IPv4 care-of address provided by the FA.
– IPv4 home address assignment. The UE needs to be assigned an IPv4 address to be used as the home address in Mobile IPv4 FACoA mode. The HA is responsible of assigning the home address to the UE.
– Security association establishment. The UE needs to establish a security association with the node acting as the HA in order to secure the MIPv4 signalling. This procedure usually consists in a shared key verification and is performed via MIPv4 signalling.
5.1.2 UE procedures
5.1.2.1 Agent discovery
When the UE has attached to the non-3GPP access network, the UE may send a MIPv4 Agent Solicitation as specified in IETF RFC 5944 [2].
5.1.2.2 FACoA registration
Upon first receiving a MIPv4 Agent Advertisement message from a FA or detecting a reboot of the FA through inspection of the Agent Advertisement message sequence number, the UE shall select one care-of address included in the Mobility Agent Advertisement Extension and shall send an RRQ to the FA as specified in IETF RFC 5944 [2] with the care-of address included in the Care-of Address field of the RRQ message. The UE shall set the source address and Home Address field to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous binding) and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE shall also include the NAI extension as specified in IETF RFC 2794 [7].
As part of MIPv4 security, the UE shall include the Mobile-Home Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Home authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6]. If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Foreign authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
If the UE already knows the IP address of the HA (e.g. when the HA address is pre-configured) the UE shall include that IP address in the Home Agent field.
If the UE does not know the IP address of the HA, the UE shall include the unspecified address (i.e. 0.0.0.0) in the Home Agent field.
If the UE has established a mobility binding with a given PDN and connection to an additional PDN is desired, the UE shall include the APN of the desired PDN within a Service Selection extension as defined in IETF RFC 5446 [5] within an RRQ as described in IETF RFC 5944 [2].
If the UE is registered on a trusted non-3GPP access network and maintenance of its registered mobility binding is desired, the UE shall re-register before the expiration of the lifetime of the registration as specified in IETF RFC 5944 [2]. If the UE has established connectivity to multiple PDNs, the UE shall re-register all mobility bindings.
When the UE receives a Registration Reply (RRP) from the FA, the UE shall perform the validity checks and process the message as specified in IETF RFC 5944 [2] to include validation of the Mobile-Home Authentication extension and, if present, the Mobile-Foreign Authentication extension. After receiving a successful RRP, the UE shall store the HA address and the home address and may send data using the home address.
5.1.3 FA procedures
5.1.3.1 Agent advertisement
When the FA receives a MIPv4 Agent Solicitation, the FA shall send a MIPv4 Agent Advertisement to the UE as specified in IETF RFC 5944 [2]. The MIPv4 Agent Advertisement shall include only the Mobility Agent Advertisement Extension.
The FA shall send an unsolicited MIPv4Agent Advertisement when it receives a trigger that a new UE has attached to its link and it has not received a MIPv4 Agent Solicitation from the UE. In this case the FA shall set the destination address of the MIPv4Agent Advertisement shall be the "limited broadcast" address (i.e. 255.255.255.255).
For both solicited and unsolicited MIPv4Agent Advertisements, the FA shall set the following bits in the Mobility Agent Advertisement Extension: R (registration required), F (foreign agent) and T (reverse tunnelling) (see IETF RFC 5944 [2]). The FA shall include at least one care-of address in the Mobility Agent Advertisement Extension.
5.1.3.2 UE registration
When the FA receives an RRQ from the UE, the FA shall process it as specified in IETF RFC 5944 [2] and 3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if present.
If the RRQ is accepted by the network, the FA shall send an RRP to the UE as specified in IETF RFC 5944 [2]. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
5.2 FACoA handover
5.2.1 General
A MIPv4 handover occurs when the UE changes access between trusted non-3GPP accesses. A change in the local point of attachment will trigger a MIPv4 handover procedure. In this case, the UE has already an established binding at the HA, and the handover procedure will update the care-of address (FA IP address) of its binding.
5.2.2 UE procedures
The UE may detect a movement, based on the ICMP Lifetime field of the router advertisements: if the lifetime of an agent advertisement has expired, and the UE has not received another Agent Advertisement message from the same FA, then the UE can consider itself having moved.
Another method for the UE to discover that it has moved is based on the advertised prefix: a change in the advertised prefix can aid the UE in determining that it has moved and to register with the newly advertised prefix. This method is only used when all mobility agents use the prefix length extension in their agent advertisements.
NOTE: The UE can also detect the movement based on an indication from the layer 1 and layer 2.
Upon detecting movement, the UE shall register with the new FA as specified in IETF RFC 5944 [2] by sending an RRQ with the care-of address of the new FA included in the Care-of Address field of the message. The UE shall set the source address to the unspecified address (i.e. 0.0.0.0). The UE shall clear bits S (simultaneous binding) and D (decapsulation by mobile node), and set bit T (reverse tunnelling) to request reverse tunnelling. The UE shall also include the NAI extension as specified in IETF RFC 2794 [7].
As part of MIPv4 security, the UE shall include the Mobile-Home Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Home authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6]. If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The UE shall set the authenticator and SPI fields of the of the Mobile-Foreign authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
If the UE had maintained connectivity to multiple PDNs prior to the handover, the UE shall then update its mobility binding with each additional PDN using the procedure described in subclause 5.1.2.2.
The UE shall include its known home address and the IP address of the HA within the RRQ.
5.2.3 FA procedures
The FA shall respond to agent solicitations sent by the UE, by addressing these agent solicitations to the unicast layer 2 and layer 3 addresses.
When the FA receives a RRQ from the UE, the FA shall process it as specified in IETF RFC 5944 [2] and 3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if present.
The FA relays the RRQ to the HA IP address found in the registration message.
If the network accepts the RRQ, the FA shall send an RRP to the UE as specified in IETF RFC 5944 [2]. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
5.3 FACoA deregistration
5.3.1 General
MIPv4 deregistration is either due to a detach or a return home event.
When the UE returns home, it will need to deregister from the HA. This can occur when the UE returns to the 3GPP network. In this scenario, the UE will de-register from the PDN-GW acting as an HA.
5.3.2 UE procedures
5.3.2.1 Network-initiated deregistration
Network-initiated deregistration can occur due to an administrative reason or detecting the UE’s leaving the trusted non-3GPP access network. Network-initiated deregistration takes the form of registration revocation as defined in IETF RFC 3543 [9]. The FA or the HA can initiate registration revocation.
The UE can be informed that its mobility binding no longer exists through inspection of the Agent Advertisement sequence number as described in IETF RFC 5944 [2].
Upon determining that its mobility binding no longer exists with the FA and HA, the UE shall locally clear its mobility binding.
5.3.2.2 UE-initiated deregistration
The UE deregisters from its HA when it determines that it is back home or as part of a UE-initiated detach from the serving trusted non-3GPP access network. The UE can determine that it is back home through inspection of the H bit and advertised prefix within a received agent advertisement.
In the case of UE deregistration upon returning home, the UE sends an RRQ with the destination address set to the HA’s address, with a Lifetime field set to 0 to indicate deregistration, and with the care-of address set to the UE’s home IP address. The RRQ will be formatted and handled as specified in IETF RFC 5944 [2]. The UE shall include the Mobile-Home Authentication extension within the RRQ as specified in IETF RFC 5944 [2] and shall set the authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6].
In the case of UE deregistration as part of a UE-initiated detach from the serving trusted non-3GPP access network, the UE sends an RRQ with the Destination Address field set to the FA’s address, with a Lifetime field set to 0 to indicate deregistration, and with the Care-of Address field set to the FA care-of address previously registered with the HA. The RRQ will be formatted and handled as specified in IETF RFC 5944 [2]. The UE shall include the Mobile-Home Authentication extension within the RRQ as specified in IETF RFC 5944 [2] and shall set the authenticator and SPI fields of the of the authentication extension to the MN-HA key and associated MN-HA-SPI generated as described in 3GPP TS 33.402 [6]. If the non-3GPP access specific procedures require a security association between the UE and FA, the UE shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2] and shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
If the UE has established connectivity to multiple PDNs, the UE shall perform this deregistration process for each PDN. The UE shall include a Service Selection extension as defined in IETF RFC 5446 [5] denoting the APN of the PDN to be deregistered in the RRQ.
Once the deregistration request is accepted, the UE receives an RRP directly from the HA in the case of a "back home" deregistration or from the HA through the FA in the case of a deregistration as part of a UE initiated detach in the serving non-3GPP access network. The UE shall perform the validity checks on the Mobile-Home Authentication extension, and, if present, the Mobile-Foreign Authentication extension and processes the message as specified in IETF RFC 5944 [2].
5.3.3 FA procedures
5.3.3.1 Network-initiated deregistration
Network-initiated deregistration can occur due to an administrative reason or detecting the UE’s leaving the trusted non-3GPP access network. Network-initiated deregistration takes the form of registration revocation as defined in IETF RFC 3543 [9]. The FA or the HA can initiate registration revocation.
The FA can initiate deregistration by sending a Registration Revocation message, as defined in IETF RFC 3543 [9], to the address of the HA. The Source Address field will be the care-of address of the FA registered by the UE, and the Home Address field will be the home IP address of the UE whose registration is being revoked. The HA will respond with a Registration Revocation Acknowledge message as specified in IETF RFC 3543 [9].
The HA can initiate deregistration by sending a Registration Revocation message to the FA providing the care-of address for the UE. The FA shall process the Registration Revocation message as described in IETF RFC 3543 [9] and respond to the HA with a Registration Revocation Acknowledge message.
Following successful registration revocation, the FA may provide an indication to the UE that its mobility binding has been reset by appropriate setting of the Agent Advertisement sequence number as described in IETF RFC 5944 [2]. The FA may also initiate other actions to terminate the mobility session through other means that are beyond the scope of this document.
5.3.3.2 UE-initiated deregistration
When the FA receives an RRQ with a Lifetime field set to 0 from the UE, the FA shall process it as specified in IETF RFC 5944 [2] and 3GPP TS 29.279 [8]. The FA shall validate the Mobile-Foreign Authentication extension if present.
The FA shall relay the RRQ to the HA IP address found in the RRQ.
If the HA accepts the RRQ, the FA shall send an RRP to the UE as specified in IETF RFC 5944 [2]. If the non-3GPP access specific procedures require a security association between the UE and FA, the FA shall also include the Mobile-Foreign Authentication extension within the RRQ as specified in IETF RFC 5944 [2]. The FA shall set the authenticator and SPI fields of the Mobile-Foreign Authentication extension to the MN-FA key and associated MN-FA-SPI generated as described in 3GPP TS 33.402 [6].
In case of a return home event, the deregistration procedure occurs between the UE and the HA; as such, the FA is not involved.
Annex A (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
2008-01 |
Draft scope provided by the rapporteur |
0.0.0 |
|||||
|
2008-01 |
CT1-51 |
Updated to include agreed scope C1-080569 |
0.0.0 |
0.1.0 |
|||
|
2008-02 |
CT1-51bis |
Includes the following contribution agreed by CT1: C1-080782 |
0.1.0 |
0.2.0 |
|||
|
2008-04 |
CT1-52 |
Includes the following contribution agreed by CT1: C1-081405 |
0.2.0 |
0.3.0 |
|||
|
2008-04 |
Minor editorial corrections |
0.3.0 |
0.3.1 |
||||
|
2008-05 |
CT1-53 |
Includes the following contributions agreed by CT1: C1-082087, C1-082088, C1-082089, C1-082090 |
0.3.1 |
0.4.0 |
|||
|
2008-06 |
CT1-54 |
Includes the following contributions agreed by CT1: C1-082686, C1-082687 |
0.4.0 |
0.5.0 |
|||
|
2008-08 |
CT1-55 |
Includes the following contributions agreed by CT1: C1-082986, C1-083307 |
0.5.0 |
0.6.0 |
|||
|
2008-09 |
Version 1.0.0 created for presentation to TSG CT#41 for information |
0.6.0 |
1.0.0 |
||||
|
2008-10 |
CT1-55bis |
Includes the following contributions agreed by CT1: C1-083981, C1-083982 |
1.0.0 |
1.1.0 |
|||
|
2008-11 |
CT1-56 |
Includes the following contributions agreed by CT1: C1-084779, C1-085380 |
1.1.0 |
1.2.0 |
|||
|
2008-11 |
Minor editorial corrections incorporated |
1.2.0 |
1.2.1 |
||||
|
2008-11 |
Version 2.0.0 created for presentation to TSG CT#42 for approval |
1.2.1 |
2.0.0 |
||||
|
2008-12 |
CT-42 |
Version 8.0.0 created after approval in CT#42 |
2.0.0 |
8.0.0 |
|||
|
2009-12 |
CT-46 |
Upgrade to Rel-9 |
8.0.0 |
9.0.0 |
|||
|
2010-03 |
CT-47 |
CP-100107 |
0002 |
Update of reference for MIPv4 service selection |
9.0.0 |
9.1.0 |
|
|
2011-03 |
CT-51 |
CP-110163 |
0004 |
Reference update for MIPv4 |
9.1.0 |
9.2.0 |
|
|
2011-03 |
CT-51 |
Upgrade to Rel-10 |
9.2.0 |
10.0.0 |
|||
|
2012-09 |
CT-57 |
Upgrade to Rel-11 |
10.0.0 |
11.0.0 |
|||
|
2014-09 |
CT-65 |
Upgrade to Rel-12 |
11.0.0 |
12.0.0 |
|||
|
2015-12 |
CT-70 |
Upgrade to Rel-13 |
12.0.0 |
13.0.0 |
|||
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
2017-03 |
CT-75 |
Upgrade to Rel-14 |
14.0.0 |
||||
|
2018-06 |
SA-80 |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
|
2020-07 |
SA-88e |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
|
2022-03 |
CT-95e |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |