RFC 5271
Mobile IPv6 Fast Handovers for 3G CDMA Networks
RFC 5271: Mobile IPv6 Fast Handovers for 3G CDMA Networks 🦋
okay bestie, the title block is giving a lot. It's from the Network Working Group, written by H. Yokota (KDDI Lab) and G. Dommety (Cisco Systems, Inc.), dated June 2008. It's Informational, which means it shares information and is not an Internet standard 💅. It doesn't say it obsoletes or updates anything.
Status of This Memo 🌸
okay so this memo gives information to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🫶.
Abstract ✨
Mobile IPv6 is built to keep your connection alive while you move from one network to another, and it's literally the reason your phone doesn't drop calls when you walk across town 😭. 3G CDMA networks adopted it so the mobile node (MN) can stay connected while it moves between access routers. The catch is that a handover needs more than the MN noticing it moved. It also has to get a new Care-of Address and register that address with Mobile IPv6 before traffic can be sent or received in the target network. During that gap, packets headed for the mobile node may get lost, and that's a big no for real-time stuff like Voice over IP (VoIP) or video telephony 💀. So this document lays out fast handover methods for 3G CDMA networks to cut down on latency and packet loss during handover 🧚.
Table of Contents 🎀
1. Introduction ....................................................2
2. Requirements Notation ...........................................3
3. Terminology .....................................................3
4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks ...4
5. Fast Handover Procedures ........................................6
5.1. Predictive Fast Handover ...................................7
5.2. Reactive Fast Handover ....................................12
5.3. Considerations on the Link Indications ....................15
6. Message Format .................................................15
6.1. Handover Assist Information Option ........................15
6.2. Mobile Node Identifier Option .............................16
6.3. New Flag Extension to FBU Message .........................17
6.4. New Flag Extension to PrRtAdv Message .....................17
7. Security Considerations ........................................18
8. IANA Considerations ............................................18
9. Acknowledgements ...............................................19
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................191. Introduction ✨
okay so Mobile IPv6 [2] lets mobile nodes (MNs) keep a persistent IP connection while they roam around the IPv6 network 🌈. 3G CDMA networks use it for host-based mobility management [12]. The problem is that during a handover, the mobile node (MN) has to switch its radio link, grab a new Care-of Address (CoA), and re-register with the home agent (HA). That can cause a communication disruption, which is not the vibe for real-time apps like VoIP and video telephony 🙈.
To shrink that disruption time (aka latency), a fast handover protocol for Mobile IPv6 [3] was proposed. RFC 4260 [7] goes further and describes how this Mobile IPv6 Fast Handover could be implemented on link layers that follow the IEEE 802.11 suite of specifications. BUT 3G CDMA and IEEE 802.11 networks are really different in radio access, in how network nodes and parameters are represented, and in how devices attach to the network 🍓. For example, the beacon scanning or New Access Router (NAR) discovery that RFC 4260 does with [Access Point Identifier, Access Router-info (AP-ID, AR-info)] tuples can not be directly applied to 3G CDMA networks. So this document specifies how Mobile IPv6 fast handovers can be applied in 3G CDMA networks 👑.
2. Requirements Notation ✨
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 💅
3. Terminology ✨
okay bestie, this document uses [3] for the Mobile IPv6 fast handover terminology 🧠. These are the terms that first show up here, and they're defined below:
Access Network Identifier (ANID): This is an identifier the Packet Data Serving Node (PDSN) uses to figure out whether the MN is being handed off from an access network that wasn't using this PDSN before. Anytime the MN crosses into a new region (defined by the ANID), it must re-register with that access network 🔥. The ANID is made up of the System ID (SID), Network ID (NID), and Packet Zone ID (PZID), and the operator administers these values. The SID is 2 octets, the NID is 2 octets, and the PZID is 1 octet. So the ANID takes up 5 octets in total [11] ✨.
Forward Pilot Channel: This is the part of the Forward Channel that carries the pilot. The Forward Channel is a bundle of physical layer channels sent from the 3G CDMA access network to the MN. There are also several sets of pilots (like the active set or neighbor set) that help decide when and where to handover 🦋.
Home Link Prefix (HLP): This is the prefix address assigned to the home link, which is where the MN should send the binding update message. It's also called the Home Network Prefix (HNP), and it's one of the bootstrap parameters for the MN 🌸.
International Mobile Subscriber Identity (IMSI): The IMSI is a string of decimal digits, up to 15 digits max, that identifies a unique mobile terminal or mobile subscriber internationally 🌍. It has three fields: the Mobile Country Code (MCC), the Mobile Network Code (MNC), and the Mobile Subscriber Identification Number (MSIN). Here's an example: "440701234567890", where "440" is the MCC, "70" is the MNC, and "1234567890" is the MSIN. The IMSI follows the ITU-T E.212 numbering standard [6]. In this spec, the IMSI is an ASCII string of not more than 15 decimal digits (ASCII values between 30 and 39 hexadecimal), one character per IMSI digit. So the example above gets encoded like this in hexadecimal 👀:
34 34 30 37 30 31 32 33 34 35 36 37 38 39 30Mobile Identity (MN ID): This is an identifier for the Mobile Node that the access network uses. The value (like an IMSI) is unique within the operator's network 🫶.
Packet Data Serving Node (PDSN): This entity routes MN originated or MN terminated packet data traffic. It sets up, maintains, and ends link-layer sessions to MNs. The PDSN is the access router in the visited access provider network 🚏.
Sector Address Identifier (SectorID): A typical cell splits its coverage area into several sectors. In 3G CDMA systems, each sector uses a different PN (Pseudo Noise) code offset and is linked to a SectorID. The SectorID is 128 bits long and can be represented in the IPv6 address format [8] 💜.
4. Network Reference Model for Mobile IPv6 over 3G CDMA Networks ✨
Okay bestie, let's look at the big picture 🗺️💜 Figure 1 is a simplified reference model of the Mobile IP enabled 3G CDMA networks. The home agent (HA) and the Authentication, Authorization, and Accounting (AAA) server of the mobile node (MN) live in the home IP network, and the MN roams within or between the access provider network(s). Usually the home IP network has no MNs hanging out in it 🙈 Instead, the MNs only connect to the access provider networks. Before the Mobile IPv6 registration, the MN sets up a 3G CDMA access technology specific link-layer connection with the access router (AR). When the MN moves from one AR to another, that link-layer connection gets re-established and a Mobile IPv6 handover happens. Those ARs can sit in the same access provider network or in different ones. The figure shows the MN moving from the Previous Access Router (PAR) to the New Access Router (NAR) through the radio access network (RAN) 🦋
Home IP Network
+........................+
. +--------+ +--------+ .
. | HA |--| AAA | .
. +--------+ +--------+ .
+../......\..............+
/ \
Access Provider Network(s)
+.............+ +.............+
. +---------+ . . +---------+ .
. | PAR | . . | NAR | .
. +---------+ . . +---------+ .
. |: . . :| .
. |:L2link L2link:| .
. |: . . :| .
. +----+:---+ . . +---:+----+ .
. | RAN | . . | RAN | .
. +----+:---+ . . +---:+----+ .
. |: . . :| .
. +----+ . . +----+ .
. | MN | ---------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+Figure 1: Reference Model for Mobile IP
In 3G CDMA networks, pilot channels sent out by base stations let the MN get a fast and accurate C/I (carrier to interference) estimate 📡✨ That estimate comes from measuring the strength of the Forward Pilot Channel, or the pilot associated with a sector of a base station (BS). The MN searches for pilots and keeps the ones with enough signal strength in the pilot sets. It then sends measurement results, which include the offsets of the PN code in use and the C/Is in the pilot sets, so the radio access network (RAN) gets an estimate of the sectors around it. There are a few triggers for the MN to send those estimates. For example, when the strength of a pilot in the pilot sets goes above the current pilot, the MN sends the estimates to the access network 💅 As long as the sector the MN is heading to belongs to the same access network, mobility inside that access network is handled by the access-specific interfaces [10], and the link-layer connection between the MN and AR can stay up without being re-established. The MN can keep searching for pilots without disrupting its data communication, and the network helps make the handover timely. But if the serving access network sees that the sector with the highest pilot strength belongs to a different AR, it tries to close the connection with the MN. The MN then tries to get a new traffic channel assigned in the new access network, and after that it sets up a new connection with the new AR. This can cause a noticeable communication disruption and seriously hurt the user experience 😭 To cut down on that service degradation, an IP-level fast handover approach as defined in RFC 5268 needs to be involved during the handover between ARs. If the air interface information can be used as a trigger for the handover between access routers, fast and smooth Mobile IPv6 handover can happen in 3G CDMA networks 🔥 Again, the MN can keep searching for pilots without disrupting the data communication, and the network helps make the handover timely.
To help the MN hand over to the new AR, lots of different information can be considered: the pilot sets, which include the candidates for the target sectors or BSs, the cell information where the MN is currently, the serving nodes in the radio access network, and the location of the MN, if that's available 🗺️ To figure out which access network the MN is moving to or from, the Access Network Identifiers (ANID) or the subnet information can be used [9][10]. In this document, that whole collection of info is called "handover assist information" 🎀 In 3G CDMA networks, the Link-Layer Address of the New Access Point (AP) defined in [3] might not be available. If that's the case, the Handover Assist Information option defined in this document SHOULD be used instead 💖
5. Fast Handover Procedures 🚀
There are two modes defined in [3] based on when the FBU (Fast Binding Update) gets sent. The first is called "predictive mode", where the MN sends the FBU and receives the FBAck (Fast Binding Acknowledgment) on the PAR's (Previous Access Router's) link. The second is called "reactive mode", where the MN sends the FBU from the NAR's (New Access Router's) link. In predictive mode, the time and place the MN hands off must be indicated well before it actually happens ⏰ In cellular systems the network controls the handovers, so predictive mode fits really well 👑 But if the network can't identify the new AR the MN is moving to in a timely way, reactive mode is the better choice 🌸
Section 2 of RFC 4907 [20] suggests architectural principles about link indication and how effective the optimization is. The link indication in this document relies on 3G CDMA networks, and the effectiveness of the optimization is credited to RFC 5268. So those principles are already taken care of by the related specifications referenced in this document 🫶
5.1. Predictive Fast Handover
Figure 2 shows the predictive mode of MIPv6 fast handover operation. When the MN finds a sector or a BS with a pilot signal that's strong enough, it kicks off a handover using this sequence 🦋
- (a) A router solicitation for proxy router advertisement goes out to the PAR. The handover assist information for the target 3G CDMA network gets attached to this message.
- (b) Using the handover assist information it received, the NAR is determined, and a proxy router advertisement (PrRtAdv) carrying the prefix of the NAR is sent back to the MN. The MN also checks that the R flag is not set in the PrRtAdv message, since that's how it knows the network supports the predictive fast handover mode (defined later) ✅
- (c) The MN creates an NCoA (new CoA) and sends the Fast Binding Update (FBU) with the NCoA to the PAR, which then sends the Handover Initiate (HI) to the NAR.
- (d) The NAR sends the Handover Acknowledge (HAck) back to the PAR, which then sends the FBU acknowledgment (FBAck) to the MN.
- (e) The PAR starts forwarding packets toward the NCoA, and the NAR captures and buffers them.
- (f) The link-layer connection associated with the PAR gets closed, and a new traffic channel is assigned in the new access network.
- (g) The MN attaches to the new access network. The attachment procedure is access technology specific, and the one for 3G CDMA networks (including the PPP transactions) is described later.
- (h) The MN sends the Unsolicited Neighbor Advertisement (UNA).
- (i) The NAR starts delivering packets to the MN.
- (j) The MN sends the Binding Update (BU) to the HA to update the Binding Cache Entry (BCE) with the NCoA, and the HA sends the Binding Acknowledgment (BA) back to the MN 💜
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | Hl | | |
(c) |------------->|-------------->| | |
| FBack | HAck | | |
(d) |<-------------|<--------------| | |
| |forward packets| | |
(e) | |==============>|(buffering) | |
| | | | |
(f) handover | | | |
| | | | |
+--------------------------------------------------------------+
(g) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(h) |----------------------------->| | |
| deliver packets | | |
(i) |<=============================| | |
| | BU/BA | | |
(j) |<------------------------------------------->| |
| | | | |Figure 2: MIPv6 Fast Handover Operation (Predictive Mode)
It's assumed the PAR can identify the NAR by using the handover assist information from the MN 🧚 To run predictive mode, the MN MUST send the FBU before the connection with the current access network is closed, no excuses 😤 If the MN doesn't manage to send the FBU before the handover, it SHOULD fall back to reactive mode 🔄 Even when the MN sends the FBU successfully, the PAR might get it late because of things like congestion. If the NAR gets the HI that was triggered by the delayed FBU after it already received the UNA ((c) comes after (h)), then the NAR SHOULD send the HAck with handover not accepted and behave as reactive mode 💀
In (a), the Router Solicitation for Proxy Advertisement (RtSolPr) is supposed to include the New Access Point and the MN Link-Layer Address (LLA) options (Option Code=1 and 2, respectively) according to [3]. In 3G CDMA networks, the New AP-LLA option MAY be replaced by the handover assist information option ✨ As for the MN-LLA option, if the LLA for the MN isn't available, 3G specific IDs such as IMSI[11] MAY be used. If that's the case, the MN ID option defined in Section 6.2 SHOULD be used instead of the MN-LLA option. That option can support other types of IDs, and its length doesn't have to be a multiple of 8 octets, which is a huge plus 🎀
In (b), the PrRtAdv MUST include options for the IP address of the NAR, which may be the link-local address, and the prefix for the MN 🫶 The PAR SHOULD be able to identify the NAR from the handover assist information the MN provided. Literally the whole handover hinges on that, so it's giving main character energy 👑
Okay so, Figure 3 shows the call flow for the initial attachment in the 3G CDMA network [12] 📡✨. Once the traffic channel is assigned, the MN first sets up a link-layer connection with the access router. The figure uses PPP as the link-layer protocol, so the example shows a PPP handshake 🎀. After that link is up, the MN registers with the HA by sending a Binding Update message 💌. Mobile IPv6 needs a few parameters to work: the home address (HoA), the Care-of Address (CoA), the home agent address (HA), and the home link prefix (HLP) 🧚. [12] calls getting these values "bootstrapping," and that info can show up during the link-layer setup phase, the mobility binding phase, or both [13] 💅.
MN PAR NAR HA AAA
/ | (serving PDSN) (target PDSN) | |
| | LCP | | | |
| (1) |<----------------------->| | |
| | CHAP/PAP | Access-Request/Accept |
| (2) |<----------------------->|<-------------|------->|
| | | +------+ | | |
| (3) | | | HA |<---------+ |
| | | +------+ | |
|+........................................+ | |
|. | | . | |
|. | IPv6CP(IF-ID) | . | |
|.(4)* |<---------|------------->| . | |
(g)< . +---------+ | | | . | |
|.(5)*| LL-addr |<-+ | | . | |
|. +---------+ | | . | |
|. | | . | |
|. | RA(prefix) | . | |
|.(6)* |<---------|--------------| . | |
|. +-----+ | | | . | |
|.(7)*| CoA |<-----+ | | . | |
|. +-----+ | | . | |
|+........................................+ | |
| | DHCPv6(HA) | | |
| (8) |<---------------+------->| | |
| +-----+ | | | | |
| (9) | HA |<-----------+ | | |
| +-----+ | | | |
| | | | | |
\ | | | | |
Figure 3: Attachment Procedure in 3G CDMA NetworkHere's the initial attachment procedure, step by step 👑:
(g) The link-layer connection establishment and the bootstrapping phase. 🌸
(g-1) The LCP (Link Control Protocol) configure-request/response messages get exchanged. 💫
(g-2) User authentication happens, like with Challenge Handshake Authentication Protocol (CHAP) or Password Authentication Protocol (PAP) 🔐.
(g-3) The static bootstrapping info is passed along from the AAA and stored in the NAR (target PDSN). The HoA and HLP can be dynamically assigned by the HA during the mobility binding phase. This step can be skipped in the handover case 🦋.
(g-4) Unique interface IDs get negotiated in IPv6 Control Protocol (IPv6CP) 🧚.
(g-5) The MN configures its link-local address based on the interface ID it got 🎀.
(g-6) The MN receives a router advertisement containing the prefix 📣.
(g-7) The MN configures its CoA based on that prefix 💖.
(g-8) DHCPv6 gets used to obtain the static bootstrap info (for example, the HA address). This step happens in the initial attachment and can be skipped once the MN has those parameters 🍓.
(g-9) The MN installs the bootstrap info for the later procedures (for example, the mobility binding) ✨.
Look, as the figure shows, setting up a link-layer connection takes a seriously long time, and almost all of those steps run every single time the MN attaches to a new access network 😭. So it's lowkey a big deal if packets headed to the MN get saved not only while the MN switches to the new radio channel, but also while it's setting up the link-layer connection 🫶.
There are a few ways to set up a unique IP address for the MN. If a globally unique prefix gets assigned per link, as [12] introduces, the MN can use any interface ID except the one belonging to the other peer (the AR the MN is attached to) to build a unique IP address 🌈. BUT, and this is the tea, the PAR can't give the MN a correct prefix for the new network in the PrRtAdv, because the NAR picks that prefix and sends it in the router advertisement 💀. So the MN makes a temporary NCoA using the prefix from the PAR, and the correct NCoA MUST be assigned by the NAR. That's why, in 3G CDMA network, the PAR MUST send the HI with the S flag set when it gets the FBU from the MN at step (c) in Figure 2 🔥.
The UNA is supposed to include the MN-LLA [3], but a point-to-point link-layer connection may already uniquely identify the MN 🙈. What the UNA mostly needs is the NCoA, so it can check whether there's a matching buffer. So in (h), the UNA function can be handled in a few different ways 👑:
- Since setting up the link-layer connection in (g) shows the MN side is ready for data, the NAR immediately checks whether there's a buffer holding packets destined for the NCoA (configured at steps (c) - (d)), and starts delivering them if there are any (substitution of UNA) 💅.
- The MN sends the UNA as defined in [3]. Instead of the MN-LLA in the LLA option, the MN ID MAY be included in the MN ID option (standard implementation of UNA) 🦋.
Here's the main perk of predictive fast handover mode: packets headed to the MN can be buffered at the NAR, so packet loss from handover is way lower than in normal MIPv6 operation 🎉. There's another benefit for bootstrapping too 🧚:
- Since the NCoA can be configured through the fast handover procedures, a router advertisement is not required.
So, the procedures (g-4) to (g-7) can be skipped from the standard MIPv6 operation in Figure 3 💖✨.
5.2. Reactive Fast Handover ✨
okay so, when the network does NOT do predictive fast handover 🙅♀️, we switch to reactive mode 💅. this doc defines a new flag in PrRtAdv so the MN can find out what the network can do 🎀 (see Section 6.4). to cut down on packet loss, the PAR (not the NAR) can buffer packets for the MN until it reconnects with the NAR 🦋. the NAR gets the PAR's info from the MN over the NAR's link and then picks up the buffered packets from the PAR 🫶. the PAR doesn't need the NAR's IP address or the NCoA here, it just waits for the NAR to reach out 🧚. BUT the PAR still needs to know when to start buffering, so it learns that timing from the MN through the FBU or from lower-layer signaling, like a heads-up that the connection with the MN was released 🌸. here's the play-by-play:
- (a) A router solicitation for proxy router advertisement MAY be sent to the PAR.
- (b) The proxy router advertisement MAY be sent to the MN. If the information on the NAR is not available by the PAR,
0::0MUST be used for the options related to the NAR (e.g., IP address of the NAR). - (c) The MN sends the FBU or the access network indicates the close of the connection with the MN by the lower-layer signaling. If the MN cannot formulate the NCoA,
0::0, MUST be used for the NCoA in the FBU. If the B flag is set in the FBU, the PAR SHOULD start buffering packets destined for the PCoA. - (d) The link-layer connection associated with the PAR is closed and a new traffic channel is assigned in the new access network.
- (e) The MN attaches to the new access network. This part is the same as described in Section 5.1 and illustrated in Figure 3.
- (f) The MN sends the UNA to the NAR.
- (g) The MN sends the Fast Binding Update (FBU) to the PAR via the NAR.
- (h) The NAR forwards the FBU from the MN to the PAR.
- (i) The PAR sends the Handover Initiate (HI) to the NAR with the Code set to 1.
- (j) The NAR sends the Handover Acknowledge (HAck) back to the PAR.
- (k) The PAR sends the FBAck to the NAR.
- (l) If the PAR is buffering packets destined for the PCoA, it starts forwarding them as well as newly arriving ones to the NAR.
- (m) The NAR delivers the packets to the MN.
- (n) The MN sends the BU to the HA to update the BCE with the NCoA and the HA sends back the BA to the MN.
MN PAR NAR HA AAA
| RtSolPr | | | |
(a) |------------->| | | |
| PrRtAdv | | | |
(b) |<-------------| | | |
| FBU | | | |
(c) |- - - - - - ->|(buffering) | | |
| | | | |
(d) handover | | | |
| | | | |
+--------------------------------------------------------------+
(e) | Attachment procedure |
+--------------------------------------------------------------+
| UNA | | |
(f) |----------------------------->| | |
| FBU | | |
(g) |----------------------------->| | |
| | FBU | | |
(h) | |<--------------| | |
| | HI | | |
(i) | |-------------->| | |
| | HAck | | |
(j) | |<--------------| | |
| | FBack | | |
(k) | |-------------->| | |
| |forward packets| | |
(l) | |==============>| | |
| deliver packets | | |
(m) |<=============================| | |
| | BU/BA | | |
(n) |<------------------------------------------->| |
| | | | |Figure 4: MIPv6 Fast Handover Operation (Reactive Mode)
to tell the PAR to buffer packets for the PCoA, step (c) uses a brand new B flag in the FBU 🍓. when the PAR gets an FBU with B set, it SHOULD buffer packets for the MN. the PAR MAY also start buffering for the MN based on a lower-layer signal during the handover 💜. since the PAR is holding the packets in this setup, the UNA (which the NAR gets and processes) can NOT be used to trigger forwarding from the PAR 🙈. instead, in Figure 4, the HAck from the NAR is the trigger that releases any buffered packets 🔥.
the handover indication from the 3G CDMA lower layer is pretty reliable thanks to periodic reports from the MN 📡, BUT there are situations where the target link isn't available after the handover (step (d)) and the MN ends up back at the PAR 😭, or the MN can't move to the target link for some reason after the connection closed 💀. if that happens, the attachment procedure happens on the previous link 🌈. the packets buffered at the PAR SHOULD be delivered to the MN once the connection is re-established 🫶.
5.3. Considerations on the Link Indications 🔍
this section checks whether the link indications this doc assumes meet the principles in Section 2 of RFC 4907[20] 🤓. that section lays out 11 architectural principles for link indications and how well the optimization works. this doc leans on the 3G CDMA network for link indications, which 3GPP2 specifies very precisely 💅. so principles (1) to (5), (7), (8), and (11) (that's "Model Validation", "Clear Definition", "Robustness", "Recovery from Invalid Indications", "Congestion Control", "Interoperability", "Race Condition", and "Transport of Link Indications") are covered by those specs ✨. principle (6), "Effectiveness", is about how well the optimization works, and this doc bases its effectiveness on RFC 5268, so that RFC handles it 🎀. principle (9), "Metric Consistency", is about mismatches between link and routing layer metrics. this spec doesn't change routing metrics and multi-homing isn't considered 🍓. last one, principle (10), "Layer Compression", is about an overhead reduction scheme and interoperability. this doc doesn't do overhead reduction, so this principle doesn't apply 🙃.
6. Message Format 💌
6.1. Handover Assist Information Option 🧚
if the lower-layer info for the new point of attachment isn't represented as a link-layer address, this option SHOULD be used 🌸. its main job is to carry the handover assist information from Section 4.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Option-Code | HAI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HAI-Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 29Typeis 29.Lengthis the size of this option in 8 octets, including the Type, Length, Option-Code, and HAI-Length (Handover Assist Information-Length) fields.Option-Codehas two values:1for the Access Network Identifier (AN ID), and2for the Sector ID.HAI-Lengthis the size of the HAI-Value field in octets.HAI-Valueis the value specified by the Option-Code.
if the folks receiving this message don't support this option, they SHOULD treat it as opaque and MUST NOT drop it 🫶. Option-Code tells you which kind of handover assist info it is, and right now two types are defined to help discover the NAR (see Section 3) ✨.
depending on how big the HAI-Value field is, you MUST use padding so the whole option is a multiple of 8 octets 📏. HAI-Length is what tells you how big the HAI-Value actually is, so it's not ambiguous 💖.
the handover assist info MAY replace the New Access Point Link-Layer Address in 3G CDMA networks 🌈.
6.2. Mobile Node Identifier Option 🪪
this option carries the Identifier of the MN, which isn't its link-layer address 💜.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Type | Length | Option-Code | MN ID-Length |
+---------------------------------------------------------------+
| MN ID ...
+-----------------------------Typeis 30.Lengthis the size of this option in 8 octets, including the Type, Length, and Option-Code fields.Option-Codehas two values:1for NAI [4], and2for IMSI (See Section 3).MN ID-Lengthis the length of the MN ID in octets.MN IDis the MN ID value.
the MN ID MAY replace the MN Link-Layer Address in 3G CDMA networks 🍓.
6.3. New Flag Extension to FBU Message 🚩
the MN MUST send the FBU to the PAR with the new (B) flag set in the previous network, telling the PAR to buffer packets destined for the PCoA 💅. everything else in the Binding Update message stays the same as defined in [2], plus the (M), (R), and (P) flags from [14], [15], and [16], respectively 🎀.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|L|K|M|R|P|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Bflag: If theBflag is set, the PAR SHOULD start buffering the packets destined for the MN as specified in Section 5.2 🌟.
6.4. New Flag Extension to PrRtAdv Message ✨
okay so this is the tiny flag that tells the MN which fast handover modes the network can actually do 🦋 there's a new flag called 'R' in the PrRtAdv message, and it's giving "here's what I support, bestie" 💅
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Subtype |R| Reserved | Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+-+-+-+-+-+-+-+-So the R flag works like this 🌸 If the 'R' flag is set, the network only supports the reactive handover mode. If it isn't set, the network supports both the predictive and reactive fast handover modes. Simple, but it's the difference between "I can only do reactive" and "I can do both" 🧚
7. Security Considerations 🔐
ngl this section is serious, but it's also kind of iconic 😭 The security considerations for Mobile IPv6 fast handover are described in [3]. When a 3G CDMA network is considered, it can be assumed that the PAR and the NAR have a trust relationship, and the links between them and the links between the ARs and the MN are secured. The MN gets authenticated every single time it attaches to the new link, so the AR can securely identify the MN 🫶 Depending on the operator's policy, though, SEcure Neighbor Discovery (SEND) [18] and the shared handover key defined in [17] can also be applied 🔥
8. IANA Considerations 📋
okay so this document defines two new IPv6 Neighbor Discovery options, and they were assigned from the same space as the IPv6 Neighbor Discovery Options defined in [19] 💜
- 29: Handover Assist Information Option (Section 6.1)
- 30: Mobile Node Identifier Option (Section 6.2)
It also creates two brand-new registries, one for the Option-Code field in the Handover Assist Information Option and one for the Option-Code field in the Mobile Node Identifier Option. The values for the Option-Code must be within the range 0-255. New values for both registries can be allocated by Standards Action or IESG approval [5] 🎀
The Option-Code values that IANA has assigned are below, so you can see exactly what's already taken ✨
Option-Code for Handover Assist Information Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 ANID Section 6.1
2 Sector ID Section 6.1
Option-Code for Mobile Node Identifier Option
Value Description Reference
----- ---------------------------- ----------
0 Reserved
1 NAI Section 6.2
2 IMSI Section 6.29. Acknowledgements 🌈
The authors would like to thank Kuntal Chowdhury, Ashutosh Dutta, Ved Kafle, and Vijay Devarapalli for giving feedback and support for this work 💖 The authors would also thank Sebastian Thalanany for 3GPP2 expert review 🙈
10. References 📚
10.1. Normative References
- [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [3] Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.
- [4] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
- [5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [6] ITU-T Recommendation, "The international identification plan for mobile terminals and mobile users", ITU-T E.212, May 2004.
10.2. Informative References
- [7] McCann, P., "Mobile IPv6 Fast Handovers for 802.11 Networks", RFC 4260, November 2005.
- [8] 3GPP2 TSG-C, "cdma2000 High Rate Packet Data Air Interface Specification", C.S0024-A v.2.0, July 2005.
- [9] 3GPP2 TSG-A, "3GPP2 Access Network Interfaces Interoperability Specification", A.S0001-A v.2.0, June 2001.
- [10] 3GPP2 TSG-A, "Interoperability Specification for High Rate Packet 1 2 Data (HRPD) Access Network Interfaces - Rev A.", A.S0007-A v.2.0, May 2003.
- [11] 3GPP2 TSG-A, "Interoperability Specification (IOS) for High Rate Packet Data (HRPD) Access Network Interfaces", 3GPP2 A.S0008-0 v3.0, May 2003.
- [12] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard: Simple IP and Mobile IP services", X.S0011-002-D v.1.0, February 2006.
- [13] Devarapalli, V., Patel, A., Keung, K., and K. Chowdhury, "Mobile IPv6 Bootstrapping for the Authentication Option Protocol", Work in Progress, September 2007.
- [14] Soliman, H., Castelluccia, C., El Malki, K., and L. Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 4140, August 2005.
- [15] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005.
- [16] Gundavell, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Work in Progress, February 2008.
- [17] Kempf, J., Ed. and R. Koodli, "Distributing a Symmetric FMIPv6 Handover Key using SEND", RFC 5269, June 2008.
- [18] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
- [19] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [20] Aboba, B., Ed., "Architectural Implications of Link Indications", RFC 4907, June 2007.
Authors' Addresses 🦋
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama, 356-8502
JP
Phone: +81 49 278 7894
Fax: +81 49 278 7510
EMail: yokota@kddilabs.jp
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134
US
Phone: +1 408 525 1404
EMail: gdommety@cisco.comFull Copyright Statement ©
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property 🔒
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available. Nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 🫶
📦 where this page comes from
- ietf: rfc5271 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms