RFC 5270
Mobile IPv6 Fast Handovers over IEEE 802.16e Networks
me when you realise your entire life is an RFC 💅
Okay so this is part 1 of 4 of RFC 5270, and I am OBSESSED, bestie 🦋 Mobile IPv6 Fast Handovers over IEEE 802.16e Networks. Lowkey the most niche topic ever and I'm here for it 🌸
Network Working Group 🎀 H. Jang (SAMSUNG), J. Jee (ETRI), Y. Han (KUT), S. Park (SAMSUNG Electronics), J. Cha (ETRI). Dated June 2008. It's Informational 📚 so it's giving "here's a guide, not a rule," and it obsoletes nothing and updates nothing 🙈
The title block is pure main character energy ✨ Let's get into it 💖
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 🌈
Abstract 🔥
This document describes how a Mobile IPv6 Fast Handover can be implemented on link layers conforming to the IEEE 802.16e suite of specifications. The proposed scheme tries to achieve seamless handover by exploiting the link-layer handover indicators and thereby synchronizing the IEEE 802.16e handover procedures with the Mobile IPv6 fast handover procedures efficiently. 💜
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. IEEE 802.16e Handover Overview . . . . . . . . . . . . . . . . 4
4. Network Topology Acquisition and Network Selection . . . . . . 5
5. Interaction between FMIPv6 and IEEE 802.16e . . . . . . . . . 6
5.1. Access Router Discovery . . . . . . . . . . . . . . . . . 6
5.2. Handover Preparation . . . . . . . . . . . . . . . . . . . 7
5.3. Handover Execution . . . . . . . . . . . . . . . . . . . . 8
5.4. Handover Completion . . . . . . . . . . . . . . . . . . . 9
6. The Examples of Handover Scenario . . . . . . . . . . . . . . 10
6.1. Predictive Mode . . . . . . . . . . . . . . . . . . . . . 10
6.2. Reactive Mode . . . . . . . . . . . . . . . . . . . . . . 12
7. IEEE 802.21 Considerations . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10.1. Normative References . . . . . . . . . . . . . . . . . . . 15
10.2. Informative References . . . . . . . . . . . . . . . . . . 161. Introduction 🦋
1.1. (none)
Okay wait, I need to stop and be real with you 😭 The original doesn't have a subsection here, so I'm not inventing one. Let's keep going 💅
Mobile IPv6 Fast Handover protocol [RFC5268] was proposed to complement the Mobile IPv6 (MIPv6) [RFC3775] by reducing the handover latency for the real-time traffic. FMIPv6 assumes the support from the link-layer technology; however, the specific link-layer information available and its available timing differs according to the particular link-layer technology in use, as pointed out in [RFC4260], which provides an FMIPv6 solution for the IEEE 802.11 networks. So, this document is proposed to provide an informational guide to the developers about how to optimize the FMIPv6 handover procedures, specifically in the IEEE 802.16e networks [IEEE802.16][IEEE802.16e]. 🌸
The proposed scheme achieves seamless handover by exploiting the link-layer handover indicators and designing an efficient interleaving scheme of the 802.16e and the FMIPv6 handover procedures. The scheme targets a hard handover, which is the default handover type of IEEE 802.16e. For the other handover types, i.e., the Macro Diversity Handover (MDHO) and Fast Base Station Switching (FBSS), the base stations in the same diversity set are likely to belong to the same subnet for diversity, and FMIPv6 might not be needed. Regarding the MDHO and the FBSS deployment with FMIPv6, further discussion will be needed and is not in the scope of this document. 🫶
We begin with a summary of handover procedures of [IEEE802.16e] and then present the optimized complete FMIPv6 handover procedures by using the link-layer handover indicators. The examples of handover scenarios are described for both the predictive mode and reactive mode. ✨
2. Terminology 🎀
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document is to be interpreted as described in [RFC2119]. 👑
Most of terms used in this document are defined in MIPv6 [RFC3775] and FMIPv6 [RFC5268]. 💖
The following terms come from the IEEE 802.16e specification [IEEE802.16e]. 🍓
MOB_NBR-ADV
An IEEE 802.16e neighbor advertisement message sent
periodically by a base station.
MOB_MSHO-REQ
An IEEE 802.16e handover request message sent by a mobile node.
MOB_BSHO-RSP
An IEEE 802.16e handover response message sent by a base
station.
MOB_BSHO-REQ
An IEEE 802.16e handover request message sent by a base
station.
MOB_HO-IND
An IEEE 802.16e handover indication message sent by a mobile
node.
BSID
An IEEE 802.16e base station identifier.3. IEEE 802.16e Handover Overview 🌈
Compared with the handover in the WLAN (Wireless Local Area Network), the IEEE 802.16e handover mechanism consists of more steps since the 802.16e embraces the functionality for elaborate parameter adjustment and procedural flexibility. 💅
When a mobile node (MN) stays in a link, it listens to the Layer 2 neighbor advertisement messages, named MOB_NBR-ADV, from its serving base station (BS). A BS broadcasts them periodically to identify the network and announce the characteristics of neighbor BSs. Receiving this, the MN decodes this message to find out information about the parameters of neighbor BSs for its future handover. With the provided information in a MOB_NBR-ADV, the MN may minimize the handover latency by obtaining the channel number of neighbors and reducing the scanning time, or may select the better target BS based on the signal strength, Quality-of-Service (QoS) level, service price, etc. 🦋
The handover procedure is conceptually divided into two steps: "handover preparation" and "handover execution" [SH802.16e]. The handover preparation can be initiated by either an MN or a BS. 🔥
During this period, neighbors are compared by the metrics such as signal strength or QoS parameters, and a target BS is selected among them. If necessary, the MN may try to associate (initial ranging) with candidate BSs to expedite a future handover. Once the MN decides to handover, it notifies its intent by sending a MOB_MSHO-REQ message to the serving BS (s-BS). The BS then replies with a MOB_BSHO-RSP containing the recommended BSs to the MN after negotiating with candidates. Optionally, it may confirm handover to the target BS (t-BS) over backbone when the target is decided. Alternatively, the BS may trigger handover with a MOB_BSHO-REQ message. 🧚
After handover preparation, handover execution starts. The MN sends a MOB_HO-IND message to the serving BS as a final indication of its handover. Once it makes a new attachment, it conducts 802.16e ranging through which it can acquire physical parameters from the target BS, tuning its parameters to the target BS. After ranging with the target BS successfully, the MN negotiates basic capabilities such as maximum transmit power and modulator/demodulator type. It then performs authentication and key exchange procedures, and finally registers with the target BS. If the target BS has already learned some contexts such as authentication or capability parameters through backbone, it may omit the corresponding procedures. For the details of the 802.16 handover procedures, refer to Section 6.3.22 of [IEEE802.16e]. After completing registration, the target BS starts to serve the MN and communication via target BS is available. However, in case the MN moves to a different subnet, it should reconfigure a new IP address and reestablish an IP connection. To resume the active session of the previous link, the MN should also perform IP layer handover. 💖
4. Network Topology Acquisition and Network Selection 🌸
This section describes how discovery of adjacent networks and selection of target network work in the IEEE 802.16e for background information. 🍓
An MN can learn the network topology and acquire the link information in several ways. First of all, it can do that via L2 neighbor advertisements. A BS supporting mobile functionality shall broadcast a MOB_NBR-ADV message periodically that includes the network topology information (its maximum interval is 1 second). This message includes BSIDs and channel information of neighbor BSs, and it is used to facilitate the MN's synchronization with neighbor BSs. An MN can collect the necessary information of the neighbor BSs through this message for its future handover. 🫶
Another method for acquisition of network topology is scanning, which is the process to seek and monitor available BSs in order to find suitable handover targets. While a MOB_NBR-ADV message includes static information about neighbor BSs, scanning provides rather dynamic parameters such as link quality parameters. Since the MOB_NBR-ADV message delivers a list of neighbor BSIDs periodically and scanning provides a way to sort out some adequate BSs, it is recommended that when new BSs are found in the advertisement, the MN identifies them via scanning and resolves their BSIDs to the information of the subnet where the BS is connected. The association, an optional initial ranging procedure occurring during scanning, is one of the helpful methods to facilitate the impending handover. The MN is able to get ranging parameters and service availability information for the purpose of proper selection of the target BS and expediting a potential future handover to it. The detailed explanation of association is described in Section 6.3.22 of [IEEE802.16e]. 🦋
Besides the methods provided by 802.16e, the MN may rely on other schemes. For instance, the topology information may be provided through the MIIS (Media Independent Information Service) [IEEE802.21], which has been developed by the IEEE 802.21 working group. The MIIS is a framework by which the MN or network can obtain network information to facilitate network selection and handovers. ✨
After learning about neighbors, the MN may compare them to find a BS, which can serve better than the serving BS. The target BS may be determined by considering various criteria such as required QoS, cost, user preference, and policy. How to select the target BS is not in the scope of this document. 💜
Part 1 is a wrap 🎀 Part 2 will pick up at Section 5 (Interaction between FMIPv6 and IEEE 802.16e), so stay tuned, bestie 🫶💅
5. Interaction between FMIPv6 and IEEE 802.16e ✨
okay so this section is where the magic happens 🦋 we introduce a little set of primitives so the IEEE 802.16e and FMIPv6 procedures can interleave super efficiently. the next sections use them to walk through the handover steps, so hold onto these, bestie 💖
NEW_LINK_DETECTED(NLD) 🌸: a trigger from the link layer to the IP layer in the MN to report that a new link has been detected.LINK_HANDOVER_IMPEND(LHI) 🔥: a trigger from the link layer to the IP layer in the MN to report that a link-layer handover decision has been made and its execution is imminent.LINK_SWITCH(LSW) 💅: a control command from the IP layer to the link layer in the MN to force the MN to switch from an old BS to a new BS.LINK_UP(LUP) 👑: a trigger from the link layer to the IP layer in the MN to report that the MN has completed the link-layer connection establishment with a new BS.
5.1. Access Router Discovery
okay so once a new BS gets detected through reception of a MOB_NBR-ADV and scanning, the MN may try to learn the associated access router (AR) information as soon as possible 🧚 to make quick discovery happen in the IP layer, the link layer (802.16) fires a NEW_LINK_DETECTED primitive up to the IP layer (FMIPv6) the moment it detects a new BS ✨
when the IP layer gets that NEW_LINK_DETECTED from the link layer, it tries to learn the AR info by swapping an RtSolPr (Router Solicitation for Proxy Advertisement) and a PrRtAdv (Proxy Router Advertisement) with the PAR (Previous Access Router) 💌
according to [RFC5268], the MN may send an RtSolPr at any convenient time. however, this proposal recommends that, if feasible, the MN send it as soon as possible after receiving the NEW_LINK_DETECTED for quick router discovery, because detecting a new BS usually means the MN is moving, which may result in a handover 🏃♀️💨
sending RtSolPr messages may cause the signaling overhead problem mentioned in Section 2 of [RFC4907] 🙈 to rate-limit the retransmitted RtSolPr messages, FMIPv6 provides a back-off mechanism. it's also possible that attackers forge a MOB_NBR-ADV message that contains a bunch of bogus BSIDs, or send a flood of MOB_NBR-ADV messages where each one carries different BSIDs. this problem is mentioned in Section 8. scary but important 😭
5.2. Handover Preparation
when the MN decides to change links based on its policy, like a degrading signal strength or an increasing packet loss rate, it starts the handover by sending a MOB_MSHO-REQ to the BS and will receive a MOB_BSHO-RSP from the BS as a response. alternatively, the BS may start the handover by sending a MOB_BSHO-REQ to the MN 🦋
on receiving either a MOB_BSHO-RSP or a MOB_BSHO-REQ, the link layer triggers a LINK_HANDOVER_IMPEND so it can signal the IP layer about the arrival of MOB_BSHO-REQ/MOB_BSHO-RSP quickly ⚡ at this point, the target BS decided in the link layer gets delivered to the IP layer as a parameter of the primitive. the primitive reports that a link-layer handover decision has been made and its execution is imminent. it can be super helpful for FMIPv6 as a signal to start the handover preparation procedure, which means sending an FBU (Fast Binding Update) message to the PAR 💖
okay now for the tea ☕ to avoid erroneous results from unreliable and inconsistent link characteristics, like moving to an unpredicted network or staying put in the current network after sending an FBU, Section 2 of [RFC4907] advises combining signal strength data with other techniques rather than relying only on signal strength for the handover decision 🧠 for example, the LINK_HANDOVER_IMPEND may be sent after validating filtered signal strength measurements with other indications of link loss, such as a lack of beacon reception 📡
once the IP layer receives the LINK_HANDOVER_IMPEND, it checks whether the specified target network belongs to a different subnet, based on the info collected during the Access Router Discovery step. if the target turns out to be in the same subnet, the MN can keep using its current IP address after the handover, and there's no need to perform FMIPv6 🌈 otherwise, the IP layer formulates a prospective NCoA (New Care-of Address) with the information provided in the PrRtAdv message and sends an FBU message to the PAR 🎀
when the FBU message arrives at the PAR successfully, the PAR and the NAR (New Access Router) process it according to [RFC5268]. the PAR sets up a tunnel between the PCoA (Previous Care-of Address) and NCoA by exchanging HI (Handover Initiate) and HAck (Handover Acknowledge) messages with the NAR, and forwards the packets destined for the MN to the NCoA 🚇 the NAR confirms or re-assigns the NCoA in the HAck, and it's finally delivered to the MN through the FBack (Fast Binding Acknowledgment) in the case of predictive mode 🫶
after the MN sends a MOB_HO-IND to the serving BS, data packet transfer between the MN and the BS is no longer allowed 🚫 heads up: if a MOB_HO-IND goes out before an FBack arrives at the MN, it's highly probable that the MN will end up in reactive mode, because the serving BS releases all the MN's connections and resources after receiving a MOB_HO-IND 💀 so if possible, the MN should exchange FBU and FBack messages with the PAR before sending a MOB_HO-IND to the BS, so it can operate in predictive mode 💜
the order matters here, bestie. FBU/FBack first, then MOB_HO-IND, or you end up in reactive mode 😭
5.3. Handover Execution
if the MN receives an FBack message on the previous link, it runs in predictive mode after the handover. otherwise, it should run in reactive mode 🎀 so the MN can operate in predictive mode as far as possible after the handover, implementations may allow use of a LINK_SWITCH primitive. the LINK_SWITCH is a command that forces the MN to switch from an old BS to a new BS, and a similar concept was introduced for wireless LAN in [RFC5184] 🛰️ when it's applied, the MN's IP layer issues a LINK_SWITCH primitive to the link layer on receiving the FBack message on the previous link. until that happens, the link layer keeps the current (previous) link if feasible and postpones sending a MOB_HO-IND message while it waits for the FBack message ⏳
after switching links, the MN synchronizes with the target BS and performs the 802.16e network entry procedure 🌸 the MN exchanges the RNG-REQ/RSP, SBC-REQ/RSP, PKM-REQ/RSP, and REG-REQ/RSP messages with the target BS. some of these messages may be omitted if the (previously) serving BS transferred the context to the target BS over the backbone beforehand 🧚 when the network entry procedure is completed and the link layer is ready for data transmission, it informs the IP layer of the fact with a LINK_UP primitive 👑
Section 2 of [RFC4907] recommends that link indications should be designed with built-in damping 🛡️ the LINK_UP primitive defined in this document is generated by the link layer state machine based on the 802.16e link layer message exchanges, that is, the IEEE 802.16e network entry and the service flow creation procedures. so the LINK_UP is typically less sensitive to changes in transient link conditions. the link may experience an intermittent loss, but even then, the following FMIPv6 operation is only performed when the MN hands over to a link with a different subnet, and there's no signaling overhead as a result of an intermittent loss 🙌
5.4. Handover Completion
when the MN's IP layer receives a LINK_UP primitive from the link layer, it should check whether it has moved into the target network predicted by FMIPv6 🔍 if the target BS is within the same subnet, the MN does not perform the FMIPv6 operation.
- if the MN discovers itself in the predicted target network and receives an FBack message on the previous link, the MN's IP layer sends a UNA (Unsolicited Neighbor Advertisement) to the NAR (predictive mode) 💖
- if the MN has moved to the target network without receiving an FBack message on the previous link, the IP layer sends a UNA and also an FBU message immediately after sending the UNA message (reactive mode) 🌈 the NAR may provide a different IP address by using an RA (Router Advertisement) with a NAACK (Neighbor Advertisement Acknowledge) option, other than the NCoA formulated by the MN 🎀
- the MN may discover itself in an unpredicted network (erroneous movement) 😵 if this happens, the MN moves to a network that is not the target specified in the
LINK_HANDOVER_IMPENDprimitive. to recover from such an invalid indication, which is mentioned in Section 2 of [RFC4907], the MN should send a new FBU to the PAR according to Section 5.6 of [RFC5268], so the PAR can update the existing binding entry and redirect the packets to the new confirmed location 🦋
in both predictive and reactive modes, once the MN has moved into the new link, it uses the NCoA it formulated as the source address of the UNA, irrespective of NCoA availability. then it starts a Duplicate Address Detection (DAD) probe for the NCoA according to [RFC4862] 🔎 if the NAR provides the MN with a new NCoA, the MN MUST use the provided NCoA instead of the NCoA it formulated itself 💅
when the NAR receives a UNA message, it deletes its proxy neighbor cache entry if one exists, and forwards buffered packets to the MN after updating the neighbor cache properly 📬 detailed UNA processing rules are specified in Section 6.4 of [RFC5268] 🤓
6. The Examples of Handover Scenario 🎬
in this section, we show the recommended handover procedures over an 802.16e network for both predictive and reactive modes ✨ it's assumed that the MN hands over to a network that belongs to a different subnet.
in the following figures, the messages between the MN's Layer 2 (MN L2) and the BS are IEEE 802.16 messages. the messages between the MN's Layer 3 (MN L3) and the PAR, and the messages between the PAR and NAR, are FMIPv6 messages. the messages between the MN L2 and the MN L3 are the primitives introduced in this document 🌷
6.1. Predictive Mode ✨
Okay so predictive mode is basically the MN seeing the move coming and getting everything sorted before it hops over 🔮 It's giving planning, and Figure 3 shows the whole choreography 💅
- A BS broadcasts a MOB_NBR-ADV periodically 📡
- If the MN spots a new neighbor BS in that message, it may scan for it 👀
- When a new BS is found through the MOB_NBR-ADV and scanning, the MN's link layer tells the IP layer with a NEW_LINK_DETECTED primitive 🔔
- The MN tries to figure out the new BS's BSID by swapping RtSolPr and PrRtAdv messages with the PAR, so it knows which AR it's linked to 🧚
- The MN starts the handover by sending a MOB_MSHO-REQ to the BS and gets a MOB_BSHO-RSP back. Or the BS can make the first move and send a MOB_BSHO-REQ to the MN 🤝
- Once the MN gets either a MOB_BSHO-RSP or a MOB_BSHO-REQ from the BS, its link layer triggers a LINK_HANDOVER_IMPEND primitive up to the IP layer 🚨
- When the LINK_HANDOVER_IMPEND shows up, the MN's IP layer checks that the target it came with belongs to a different subnet, then sends an FBU to the PAR 🏃♀️ The PAR sets up a tunnel between the PCoA and the NCoA by trading HI and HAck messages with the NAR, and it forwards packets meant for the MN to the NCoA. During all this, the NAR may confirm the NCoA is available on the new link through the HAck 🎀
- The MN gets the FBack message before its handover and sends a MOB_HO-IND as the final "I'm leaving" notice 👋 The MN can optionally promote that MOB_HO-IND by using a LINK_SWITCH command from the IP layer. After that, it's operating in predictive mode on the new link 🦋
- The MN hands over to the target BS and runs the IEEE 802.16e network entry procedure 🌈
- Once network entry is done, the MN's link layer signals the IP layer with a LINK_UP ✨ The IP layer now knows it moved to a predicted target network and already got the FBack in the previous link. It sends an UNA to the NAR using the NCoA as the source IP address, and at the same time starts DAD for the NCoA 💜
- When the NAR gets the UNA from the MN, it delivers the buffered packets to the MN 📦🫶
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2.| |<---MOB_NBR-ADV --------| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |------------------FBU---------------->| | |
| | | |--------HI-------->|
| | | |<------HACK--------|
|<-----------------FBack---------------|--> | |
| | | Packets==============>|
8. |(LSW)>|-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
11. |<==================================================== Packets
| | | | |
Figure 3. Predictive Fast Handover in 802.16e6.2. Reactive Mode 🌸
Now reactive mode 😬 This is the "oops, no FBack before I left" version. Figure 4 shows how it plays out.
- ~ 7. These are the same as the predictive mode steps 🔁
- The MN doesn't get the FBack before handover, so it sends a MOB_HO-IND as the final indication of handover anyway. After that, it's operating in reactive mode on the new link 🫠
- The MN hands over to the target network and runs the 802.16e network entry procedure 💫
- Once network entry wraps up, the MN's link layer signals the IP layer with a LINK_UP. The IP layer sees it moved to the predicted target network without having received the FBack on the previous link. The MN sends an UNA to the NAR using NCoA as the source IP address and starts DAD for the NCoA. It also sends an FBU to the PAR in reactive mode 🙈
- When the NAR gets both the UNA and the FBU from the MN, it forwards the FBack to the PAR. The FBack and Packets go from the PAR and reach the MN (NCoA) through the NAR. The NAR may also supply a different IP address than the NCoA by sending an RA with a NAACK option to the MN 🌈
(MN L3 MN L2) s-BS PAR t-BS NAR
| | | | | |
1-2.| |<---MOB_NBR-ADV & Scan--| | | |
| |<-------Scanning------->| | | |
3. |<-NLD-| | | | |
4. |--------------(RtSolPr)-------------->| | |
|<--------------PrRtAdv----------------| | |
| | | | | |
5. | |------MOB_MSHO-REQ----->| | | |
| |<-----MOB_BSHO-RSP------| | | |
| | or | | | |
| |<-----MOB_BSHO-REQ------| | | |
6. |<-LHI-| | | | |
7. |--------FBU----X---> | | | |
8. | |-------MOB_HO-IND------>| | | |
disconnect| | | | |
connect | | | | |
9. | |<---------IEEE 802.16 network entry-------->| |
10. |<-LUP-| | | | |
|----------------------------UNA-------------------------->|
|----------------------------FBU--------------------------)|
11. | | | |<-------FBU-------)|
| | | |<-----HI/HAck----->|
| | | | (if necessary) |
| | | Packets & FBack=========>|
|<=========================================================|
| | | | | |
Figure 4. Reactive Fast Handover in 802.16e7. IEEE 802.21 Considerations 🧠
Okay this is a fun one, because there's been a ton of research in the IEEE 802.21 working group on generic services that make handovers between heterogeneous access links way smoother 🌍 The standard is called the Media Independent Handover (MIH) Service [IEEE802.21], and it proposes three kinds of services: Media Independent Event Service (MIES), Media Independent Command Service (MICS), and Media Independent Information Service (MIIS) 💜
MIES is how lower layers (physical and link) tell higher layers (network and above) about changes in physical and link-layer conditions 📣 MICS goes the other way, carrying commands from higher layers down to lower layers, and it gives users a way to manage the link behavior related to handovers and mobility 🎛️ MIIS gives the MN or network a framework for getting network information to help with network selection and handovers 🗺️
IEEE 802.21 was built to make roaming between heterogeneous networks nicer for users, but its results may also help optimize handover performance in a homogeneous network ✨ If MIH primitives are available for handover in an 802.16e network, the MN can use them instead of the primitives proposed in this document 🙌 Table 1 shows examples of how the proposed primitives map to the MIH primitives 👇
+-------------------------+-------------------------+
| Proposed primitives | MIH primitives |
+===================================================+
| NEW_LINK_DETECTED | LINK_DETECTED |
+---------------------------------------------------+
| LINK_HANDOVER_IMPEND | LINK_HANDOVER_IMMINENT |
+---------------------------------------------------+
| LINK_SWITCH | HANDOVER_COMMIT |
+---------------------------------------------------+
| LINK_UP | LINK_UP |
+---------------------------------------------------+
Table 1. The Proposed Primitives and MIH Primitives8. Security Considerations 🔐✨
okay bestie, security is the one section where we don't flex, we protect 🫶 so let's get into it.
The primitives in this document are only used for local indication inside the MN 💅, so no security mechanism is required to protect those primitives. BUT the FMIPv6 messages and IEEE 802.16e messages that can trigger those primitives absolutely need protection 🔒 no cap.
Security considerations of the FMIPv6 specification [RFC5268] apply to this document too 💜. Also, IEEE 802.16e has a security sub-layer that gives subscribers privacy and authentication over the broadband wireless network 🌸. It has two main component protocols: a privacy key management protocol (PKM) for key management and authentication, and an encapsulation protocol for encrypting data 🧚. From the 802.16e point of view, FMIPv6 messages are treated as data and get delivered securely using those protocols 🎀.
Here's the tea though 🍵: some IEEE 802.16e management messages are sent without authentication 😭. For example, there's no protection securing 802.16e broadcast messages. So an attacker could maliciously forge a MOB_NBR-ADV message so that it contains bogus BSIDs, or send a flood of MOB_NBR-ADV messages with different bogus BSIDs toward the MN 💀. The result? The MN could trigger a bunch of NEW_LINK_DETECTED primitives and send useless consecutive RtSolPr messages to the PAR, which ends up wasting air resources 🙈. So the MN SHOULD perform scanning when it detects new BSs in the received MOB_NBR-ADV messages, so the neighbor information it includes is assured ✨.
Bestie, this is the part where you stay alert 🚨. Broadcast management messages are unauthenticated, so don't just trust a MOB_NBR-ADV because it showed up.
It's also possible that attackers try a DoS (Denial-of-Service) attack by flooding MOB_BSHO-REQ messages to trigger LINK_HANDOVER_IMPEND primitives in the MN 😤. But IEEE 802.16e provides a message authentication scheme for management messages involved in handover, as well as network entry procedures, using a message authentication code (MAC) such as HMAC/CMAC (hashed/cipher MAC) 🔐. So those management messages are protected from attackers who want to trigger LINK_HANDOVER_IMPEND or LINK_UP primitives in the MN 👑. Iconic, honestly.
9. Acknowledgments 🙏💖
Huge thanks to the IETF Mobility Working Group members of KWISF (Korea Wireless Internet Standardization Forum) for all their hard work on this 🌈. We also want to thank Alper E. Yegin, Jinhyeock Choi, Rajeev Koodli, Jonne Soininen, Gabriel Montenegro, Singh Ajoy, Yoshihiro Ohba, Behcet Sarikaya, Vijay Devarapalli, and Ved Kafle, who all gave technical advice 🫶✨.
10. References 📚
10.1. Normative References 💜
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility
Support in IPv6", RFC 3775, June 2004.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6
Stateless Address Autoconfiguration", RFC 4862,
September 2007.
[RFC5268] Koodli, R., Ed., "Mobile IPv6 Fast Handovers",
RFC 5268, June 2008.
[IEEE802.16] "IEEE Standard for Local and Metropolitan Area
Networks, Part 16: Air Interface for Fixed Broadband
Wireless Access Systems", IEEE Std 802.16-2004,
October 2004.
[IEEE802.16e] "IEEE Standard for Local and Metropolitan Area
Networks, Amendment 2: Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operation
in Licensed Bands and Corrigendum 1", IEEE
Std 802.16e-2005 and IEEE Std 802.16-2004/Cor 1-2005,
February 2006.10.2. Informative References 🦋
[RFC4260] McCann, P., "Mobile IPv6 Fast Handovers for 802.11
Networks", RFC 4260, November 2005.
[RFC5184] Teraoka, F., Gogo, K., Mitsuya, K., Shibui, R., and K.
Mitani, "Unified Layer 2 (L2) Abstractions for Layer 3
(L3)-Driven Fast Handover", RFC 5184, May 2008.
[RFC4907] Aboba, B., "Architectural Implications of Link
Indications", RFC 4907, June 2007.
[IEEE802.21] "Draft IEEE Standard for Local and Metropolitan Area
Networks: Media Independent Handover Services", IEEE
Std P802.21 D9.0, February 2008.
[SH802.16e] Kim, K., Kim, C., and T. Kim, "A Seamless Handover
Mechanism for IEEE 802.16e Broadband Wireless Access",
International Conference on Computational Science vol.
2, pp.527-534, 2005.Authors' Addresses 🌷
Heejin Jang
SAMSUNG Advanced Institute of Technology
P.O. Box 111
Suwon 440-600
Korea
EMail: heejin.jang@gmail.com
Junghoon Jee
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea
EMail: jhjee@etri.re.kr
Youn-Hee Han
Korea University of Technology and Education
Gajeon-ri, Byeongcheon-myeon
Cheonan 330-708
Korea
EMail: yhhan@kut.ac.kr
Soohong Daniel Park
SAMSUNG Electronics
416 Maetan-3dong, Yeongtong-gu
Suwon 442-742
Korea
EMail: soohong.park@samsung.com
Jaesun Cha
Electronics and Telecommunications Research Institute
161 Gajeong-dong, Yuseong-gu
Daejon 305-350
Korea
EMail: jscha@etri.re.krFull 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: rfc5270 2008-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms