RFC 5949
Fast Handovers for Proxy Mobile IPv6
Fast Handovers for Proxy Mobile IPv6 🦋
This RFC is a Standards Track document from the Internet Engineering Task Force (IETF), published in September 2010 with ISSN 2070-1721. It's RFC 5949, and it was written by H. Yokota (KDDI Lab), K. Chowdhury, R. Koodli (Cisco Systems), B. Patil (Nokia), and F. Xia (Huawei USA). Its title block doesn't list any RFCs that it obsoletes or updates. 🎀
Abstract
okay so Mobile IPv6 (MIPv6; RFC 3775) gives a mobile node IP mobility when it hops from one access router to another, and fast handovers for Mobile IPv6 (FMIPv6) exist to make that hop smoother in terms of latency and packet loss ✨ MIPv6 (and FMIPv6 too) needs the mobile node to take part in the mobility signaling, but Proxy Mobile IPv6 (PMIPv6; RFC 5213) gives IP mobility to nodes that have MIPv6 functionality and to nodes that don't, without that involvement. Still, the basic handover latency and packet loss of PMIPv6 are considered no different from MIPv6's 🙈
When you want fast handovers in that kind of environment, FMIPv6 needs a few changes to work with network-based mobility management. This document says how to use FMIPv6 (RFC 5568) when PMIPv6 is the mobility management protocol 💅 It also adds the extensions FMIPv6 needs for the case where the mobile node has no IP mobility functionality at all, which means it isn't involved in MIPv6 or FMIPv6 operations. bestie, that's the whole point 🫶
Status of This Memo
This is an Internet Standards Track document. 🌈
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, and it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check Section 2 of RFC 5741 ✨
For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5949 🍓
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the date of publication. Please read these documents carefully, because they explain your rights and restrictions for this document. Code components extracted from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🔥
This document may contain material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. The people controlling the copyright in some of that material may not have given the IETF Trust the right to allow modifications outside the IETF Standards Process. Without an adequate license from those people, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. The exceptions are formatting it for publication as an RFC and translating it into languages other than English 🌸
Table of Contents
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Terminology .....................................................4
4. Proxy-Based FMIPv6 Protocol Overview ............................5
4.1. Protocol Operation .........................................7
4.2. Inter-AR Tunneling Operation ..............................14
4.3. IPv4 Support Considerations ...............................16
5. PMIPv6-Related Fast Handover Issues ............................16
5.1. Manageability Considerations ..............................16
5.2. Expedited Packet Transmission .............................17
6. Message Formats ................................................18
6.1. Mobility Header ...........................................18
6.1.1. Handover Initiate (HI) .............................18
6.1.2. Handover Acknowledge (HAck) ........................20
6.2. Mobility Options ..........................................22
6.2.1. Context Request Option .............................22
6.2.2. Local Mobility Anchor Address (LMAA) Option ........23
6.2.3. Mobile Node Link-Local Address Interface
Identifier (MN LLA-IID) Option .....................24
6.2.4. Home Network Prefix Option .........................25
6.2.5. Link-Local Address Option ..........................25
6.2.6. GRE Key Option .....................................25
6.2.7. IPv4 Address Option ................................25
6.2.8. Vendor-Specific Mobility Option ....................25
7. Security Considerations ........................................26
8. IANA Considerations ............................................26
9. Acknowledgments ................................................28
10. References ....................................................28
10.1. Normative References .....................................28
10.2. Informative References ...................................29
Appendix A. Applicable Use Cases ..................................30
A.1. PMIPv6 Handoff Indication .................................30
A.2. Local Routing .............................................311. Introduction ✨
Proxy Mobile IPv6 (PMIPv6) [RFC5213] gives IP mobility to a mobile node that doesn't support Mobile IPv6 (MIPv6) [RFC3775] mobile node functionality. A proxy agent in the network does the mobility management signaling for the mobile node. This model gives transparent mobility to nodes inside a PMIPv6 domain 🦋 Still, the basic handover latency and packet loss of PMIPv6 are considered no different from Mobile IPv6's 🙈
Fast handovers for Mobile IPv6 (FMIPv6) [RFC5568] describes a protocol that cuts the handover latency for Mobile IPv6. It does this by letting a mobile node send packets as soon as it detects a new subnet link, and by delivering packets to the mobile node as soon as the new access router detects its attachment 💖 This document extends FMIPv6 for PMIPv6 operation. The goal is to minimize handover delay and packet loss, and also to transfer network-resident context for a PMIPv6 handover 🧚 [RFC5568] is normative for this document, except where this document specifies new or revised functions and messages.
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 [RFC2119].
3. Terminology 🎀
This document reuses terminology from [RFC5213], [RFC5568], and [RFC3775]. It also adds the following terms and abbreviations 🌈
Access Network (AN): A network made of link-layer access devices, like access points or base stations, that give access to a Mobile Access Gateway (MAG) connected to it.
Previous Access Network (P-AN): The access network the Mobile Node (MN) is attached to before handover.
New Access Network (N-AN): The access network the Mobile Node (MN) is attached to after handover.
Previous Mobile Access Gateway (PMAG): The MAG that manages mobility-related signaling for the mobile node before handover. In this document, the MAG and the Access Router are co-located 👑
New Mobile Access Gateway (NMAG): The MAG that manages mobility-related signaling for the mobile node after handover. In this document, the MAG and the Access Router (AR) are co-located 👑
Local Mobility Anchor (LMA): The topological anchor point for the mobile node's home network prefix(es), and the entity that manages the mobile node's binding state. This specification doesn't change any capability or functionality defined in [RFC5213] 🫶
Handover indication: A generic signaling message, sent from the P-AN to the PMAG, that indicates a mobile node's handover. This signaling depends on the access technology, but it's assumed that a Handover indication can carry the information needed to identify the mobile node and to help the PMAG work out the NMAG (and the new access point or base station) the mobile node is moving to. The details of this message are outside the scope of this document 🔥
4. Proxy-Based FMIPv6 Protocol Overview ✨
okay so this spec is all about fast handover protocols for Proxy Mobile IPv6 (PMIPv6) [RFC5213], which is a network-based mobility management protocol 🦋 The two main players are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The LMA is the topological anchor point for the mobile node's home network prefix(es), so it's basically the home base 🏠 The MAG acts as an access router (AR) for the mobile node and handles the mobility management procedures on its behalf. It's also the one that notices when the mobile node moves on or off the access link, and it starts the binding registrations with the mobile node's local mobility anchor. Now here's the glow-up 💅 If the MAGs can hear about the mobile node detaching and/or attaching in a timely way, say through lower-layer signaling (e.g., lower-layer signaling), the handover can get optimized. That handover involves setting up a connection on the new link and signaling between the mobility agents, and the improvement is measured against the baseline PMIPv6 spec. Iconic 🙌
To make the handover even smoother, this document defines a bidirectional tunnel between the Previous MAG (PMAG) and the New MAG (NMAG) so that packets meant for the mobile node can be tunneled between them 🎀 To let the NMAG send the Proxy Binding Update (PBU), the Handover Initiate (HI) and Handover Acknowledge (HAck) messages from [RFC5568] get extended for context transfer. That means things like the mobile node's Network Access Identifier (NAI), Home Network Prefix (HNP), and IPv4 Home Address get passed along from the PMAG. There are also two new flags, P and F, defined for the HI and HAck messages. The P flag tells them apart from the ones in [RFC5568], and the F flag requests packet forwarding 🧚
In this document, the Previous Access Router (PAR) and New Access Router (NAR) are treated as interchangeable with the PMAG and NMAG, respectively 💜 The reference network is shown in Figure 1. The access networks in the figure (i.e., P-AN and N-AN) are made up of Access Points (APs) from [RFC5568], which people often call base stations in cellular networks 📡
Here's the vibe check ✨ A mobile node isn't directly involved in IP mobility protocol operations at all, so it's also not directly involved in fast handover procedures. That's why the messages involving the mobile node in [RFC5568] aren't used when PMIPv6 is in play. Specifically, the Router Solicitation for Proxy Advertisement (RtSolPr), the Proxy Router Advertisement (PrRtAdv), the Fast Binding Update (FBU), the Fast Binding Acknowledgment (FBack), and the Unsolicited Neighbor Advertisement (UNA) messages don't apply in the PMIPv6 context 🙈 Now, a MAG that gets an RtSolPr or FBU message from a mobile node SHOULD act like it doesn't implement FMIPv6 as defined in [RFC5568] at all, and just keep operating under this spec inside the network. Or, alternatively, it can start serving that particular mobile node the way [RFC5568] describes 🔥
+----------+
| LMA |
| |
+----------+
/ \
/ \
/ \
+........../..+ +..\..........+
. +-------+-+ .______. +-+-------+ .
. | PMAG |()_______)| NMAG | .
. | (PAR) | . . | (NAR) | .
. +----+----+ . . +----+----+ .
. | . . | .
. ___|___ . . ___|___ .
. / \ . . / \ .
. ( P-AN ) . . ( N-AN ) .
. \_______/ . . \_______/ .
. | . . | .
. +----+ . . +----+ .
. | MN | ----------> | MN | .
. +----+ . . +----+ .
+.............+ +.............+
Figure 1: Reference Network for Fast Handover4.1. Protocol Operation 🦋
okay so FMIPv6 [RFC5568] has two modes ✨ In the predictive mode, the bidirectional tunnel between the PMAG (PAR) and the NMAG (NAR) gets set up before the mobile node attaches to the NMAG. In the reactive mode, that tunnel setup happens after the mobile node has already attached to the NMAG 💅 Packet loss during a handover is a real problem, especially when the mobile node is detached from both links, so the downlink packets for the mobile node need buffering either at the PMAG or the NMAG. Where it happens depends on when the packet forwarding takes place 📦 Which means it is REQUIRED that all MAGs have the capability and enough resources to buffer packets for the mobile nodes they accommodate 🫶 The buffer size to prepare and the rate at which buffered packets get drained are covered in Section 5.4 of [RFC5568]. Also, the protocol operation in this document is transparent to the local mobility anchor (LMA), so there is no new functional requirement or change on the LMA. No drama there 💖
Unlike MIPv6, the mobile node in a PMIPv6 domain isn't involved with IP mobility signaling. So for predictive fast handover to actually work well, it is REQUIRED that the mobile node can report lower-layer information to the AN at a short enough interval, and that the AN can send the Handover indication to the PMAG at an appropriate timing ⏰ Here's the whole sequence of events for predictive fast handover, shown in Figure 2 🌈
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) |--Report-->| | | | |
| | | | | |
| | Handover | | |
(b) | |------indication------>| | |
| | | | | |
| | | | | |
(c) | | | |----HI---->| |
| | | | | |
| | | | | |
(d) | | | |<---HAck---| |
| | | | | |
| | | | | |
| | | |HI/HAck(optional) |
(e) | | | |<- - - - ->| |
| | | #=|<===================|
(f) | | | #====DL data=>| |
| Handover | Handover | | |
(g) |<-command--|<------command---------| | | | MN-AN connection | AN-MAG connection | |
(h) |<---establishment---->|<----establishment----->| |
| | | (substitute for UNA) | |
| | | | | |
(i) |<==================DL data=====================| |
| | | | | |
(j) |===================UL data====================>|=# |
| | | #=|<============# |
| | | #=====================>|
/ | | | | | | \
|(k) | | | | |--PBU-->| |
| | | | | | | |
|(l) | | | | |<--PBA--| |
| |<==================DL data=====================|<=======| |
| | | | | | | |
\ |===================UL data====================>|=======>| /
UL Uplink
DL Downlink
PBA Proxy Binding Acknowledgment
Figure 2: Predictive Fast Handover for PMIPv6 (Initiated by PMAG)Here's the detailed breakdown, step by step 🍓
(a) The mobile node notices a handover is coming up and reports its identifier (MN ID) plus the New Access Point Identifier (New AP ID) [RFC5568] of the spot it's most likely to move to 📣 The MN ID could be the NAI, a link-layer address, or any other suitable identifier, but the MAG SHOULD be able to map any access-specific identifier to the NAI as the MN ID. Sometimes the previous access network (P-AN) figures out the New AP ID for the mobile node instead. This step is access technology specific, and the details are outside the scope of this document 🤷♀️
(b) The previous access network, where the mobile node is currently attached, tells the previous mobile access gateway (PMAG) about the handover, using the MN ID and New AP ID. The detailed definition and specification of this message are outside the scope of this document 📬
(c) The previous MAG works out the new mobile access gateway (NMAG) from the New AP ID. It's a similar process to building an [AP ID, AR-Info] tuple in [RFC5568] ✨ Then the previous MAG sends the Handover Initiate (HI) message to the new MAG. The HI message MUST have the P flag set and MUST include the MN ID, the HNP(s), and the address of the local mobility anchor currently serving the mobile node 🎀 If there is a valid (non-zero) MN Link-layer Identifier (MN LL-ID), that info MUST also be included too. With some link layers, the MN Link-local Address Interface Identifier (MN LLA-IID) can be included as well (see Section 6.2.3) 🧚
(d) The new MAG sends the Handover Acknowledge (HAck) message back to the previous MAG, with the P flag set 💌
(e) If it's preferred that buffering or forwarding happens later than step (c), the new MAG MAY optionally ask the previous MAG to buffer or forward packets at a later and appropriate time. It does that by setting the U flag [RFC5568] or the F flag in the HI message, respectively 🕰️
(f) If the F flag was set in the previous step, a bidirectional tunnel gets established between the previous MAG and the new MAG. Packets destined for the mobile node get forwarded from the previous MAG to the new MAG over that tunnel 🚇 After decapsulation, those packets MAY be buffered at the new MAG. And if the connection between the new access network and the new MAG is already up, those packets MAY be forwarded towards the new access network. The new access network then becomes responsible for them, like buffering or delivering depending on the state of the mobile node's attachment. That part is access technology specific 💜
Okay so, this is where the predictive handover gets really satisfying 💅✨
(g) 🦋 Once the network side says "we're ready," the mobile node gets the signal to hop over to the new access network. How that actually happens depends on the access technology, and that's outside the scope of this document, so we're leaving it alone 🙈
(h) 🌸 The mobile node sets up its physical-layer connection with the new access network (think radio channel assignment), and that kicks off the link-layer connection between the new access network and the new MAG, if it isn't already up. An IP-layer connection setup can happen right now (like the PPP IPv6 Control Protocol) or later (like stateful or stateless address autoconfiguration). This step can stand in for the Unsolicited Neighbor Advertisement (UNA) in [RFC5568], which is giving efficiency 🫶
Now the vibe check: if the new MAG gets a valid new MN LL-ID through the new access network, and a valid old MN LL-ID from the previous MAG back at step (c), those IDs SHOULD be compared to figure out whether the same interface is being used before and after the handover. If the connection between the mobile node and the new MAG is PPP and it's the same interface, the new MAG SHOULD confirm that the same interface identifier is used for the mobile node's link-local address. That identifier was passed along from the previous MAG through the MN LLA-IID option at step (c), and it gets sent to the mobile node during the Configure-Request/Ack exchange. Iconic ✨
(i) 🎀 The new MAG starts forwarding packets meant for the mobile node through the new access network.
(j) 💖 Uplink packets from the mobile node go to the new MAG over the new access network, and the new MAG passes them along to the previous MAG. The previous MAG then sends them to the local mobility anchor that's currently serving the mobile node. Main character energy 👑
(k) 🧚 The new MAG sends the Proxy Binding Update (PBU) to the local mobility anchor, whose address was given in step (c). Heads up: steps (k) and (l) aren't really part of the fast handover procedure. They're just shown here for reference 💜
(l) 🌈 The local mobility anchor sends back the Proxy Binding Acknowledgment (PBA) to the new MAG. From this point on, packets to and from the mobile node go through the new MAG instead of the previous MAG. Finally, it's done 😭🔥
Okay, now the tea. According to Section 4 of [RFC5568], the previous MAG sets up a binding between the Previous Care-of Address (PCoA) and the New Care-of Address (NCoA) so it can forward the mobile node's packets to the new MAG. The new MAG also creates a proxy neighbor cache entry to receive those packets for the NCoA before the mobile node shows up. In PMIPv6, though, the only address the mobile node uses is its Mobile Node's Home Address (MN-HoA). So the PMAG forwards the mobile node's packets to the NMAG instead of the NCoA. The NMAG then just decapsulates those packets and delivers them to the mobile node. 🍓
FMIPv4 [RFC4988] describes forwarding for when the mobile node uses its home address as its on-link address instead of its care-of address. PMIPv6 is kind of similar to that, since the address(es) the mobile node uses are based on its HNP(s). Here's the bonus part: the NMAG can grab the link-layer address (MN LL-ID) and the HNP(s) from the HI message (plus the interface identifier of the mobile node's link-local address, MN LLA-ID, if it's available). With that, it can create a neighbor cache entry for the link-local address and routes for the whole HNP(s) before the mobile node even does Neighbor Discovery. Galaxy brain 🧠✨
For uplink packets from the mobile node after the handover in step (j), the NMAG forwards them to the PMAG through the tunnel from step (f). The PMAG decapsulates them and sends them on to the local mobility anchor 🦋
The timing of context transfer and packet forwarding might not line up, so a new flag 'F' and new Option Code values for it are defined in the HI and HAck messages to request forwarding. To request buffering, the 'U' flag was already defined in [RFC5568]. If the PMAG gets an HI message with the 'F' flag set, it starts forwarding packets for the mobile node. An HI message with the 'U' flag set MAY be sent earlier if buffering needs to start at a different time than forwarding. When packet forwarding is complete, the PMAG MAY send an HI message with the 'F' flag set and the Option Code value set to 2. That message lets the ARs on both ends tear down the forwarding tunnel at the same time 🎀
Here are the IP addresses in the headers of those user packets, bestie 👀
In step (f),
Inner source address: IP address of the correspondent node
Inner destination address: HNP or Mobile Node's IPv4 Home Address
(IPv4-MN-HoA)
Outer source address: IP address of the PMAG
Outer destination address: IP address of the NMAG
In step (i),
Source address: IP address of the correspondent node
Destination address: HNP or IPv4-MN-HoA
In step (j),
- from the mobile node to the NMAG,
Source address: HNP or IPv4-MN-HoA
Destination address: IP address of the correspondent node
- from the NMAG to the PMAG,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the correspondent node
Outer source address: IP address of the NMAG
Outer destination address: IP address of the PMAG
- from the PMAG to the LMA,
Inner source address: HNP or IPv4-MN-HoA
Inner destination address: IP address of the correspondent node
Outer source address: IP address of the PMAG
Outer destination address: IP address of the LMANow the reactive handover, which is a whole different energy 🫠 In reactive handover for PMIPv6, the mobile node doesn't send either the FBU or the UNA. So it makes more sense for the NMAG to send the HI message to the PMAG after the mobile node has moved onto the new link. The NMAG does need to know the PMAG's info ahead of time, though. That info could come from the mobile node sending the AP-ID on the old link, or from lower-layer procedures between the P-AN and N-AN. The exact method isn't specified in this document 🤷♀️ Figure 3 shows the reactive fast handover procedures for PMIPv6, where the NMAG kicks off the bidirectional tunnel setup.
PMAG NMAG
MN P-AN N-AN (PAR) (NAR) LMA
| | | | | |
(a) ~~~ | | | | |
~~~ | | | | |
| MN-AN connection | AN-MAG connection | |
(b) |<--establishment-->|<-------establishment------>| |
| | |(substitute for UNA and FBU)| |
| | | | | |
| | | | | |
(c) | | | |<-----HI-------| |
| | | | | |
| | | | | |
(d) | | | |-----HAck----->| |
| | | | | |
| | | | | |
(e) | | | #=|<=======================|
| | | #================>|=# |
|<====================DL data======================# |
| | | | | |
(f) |=====================UL data===================>|=# |
| | | #=|<================# |
| | | #=========================>|
| | | | | |
/ | | | | | | \
|(g) | | | | |--PBU-->| |
| | | | | | | |
|(h) | | | | |<--PBA--| |
| |<====================DL data====================|<=======| |
| | | | | | | |
\ |=====================UL data===================>|=======>| /
Figure 3: Reactive Fast Handover for PMIPv6 (Initiated by NMAG)Here's the step-by-step, in order 💅
(a) 🌸 The mobile node moves from the previous access network to the new access network.
(b) 💖 The mobile node connects (say, over a radio channel) to the new access network. That triggers the connection between the new access network and the new MAG. The MN ID gets passed to the new MAG here so it can be used in the later steps. The AP-ID on the old link (Old AP ID), which the mobile node or the new access network provides, is also sent to the new MAG so it can figure out which previous MAG to talk to on the new link. This can count as a substitute for the UNA and FBU ✨
(c) 🧚 The new MAG sends the HI message to the previous MAG. The HI message MUST have the 'P' flag set and MUST include the MN ID. It MAY also include the Context Request option, asking the previous MAG for more context info on the mobile node 🎀
(d) 🦋 The previous MAG sends the HAck message back to the new MAG with the 'P' flag set. The HAck message MUST include the HNP(s) and/or IPv4-MN-HoA that match the MN ID in the HI message. It SHOULD include the MN LL-ID, but only if it's valid (non-zero). It also has to include the local mobility anchor address that's currently serving the mobile node. Any context the new MAG asked for MUST be included too. If that requested context isn't available for some reason, the previous MAG MUST return the HAck message with the Code value 131. And if the 'F' flag was set in the HI message at step (c) but forwarding still can't be done for some reason, the previous MAG MUST return the HAck message with the Code value 132 😭
(e) 🌈 If the 'F' flag in the HI message is set at step (c), a bidirectional tunnel gets set up between the previous MAG and the new MAG. Packets for the mobile node are forwarded from the previous MAG to the new MAG over that tunnel. After decapsulation, they're delivered to the mobile node through the new access network 🍓
(f) 💜 Uplink packets from the mobile node go to the new MAG over the new access network, and the new MAG forwards them to the previous MAG. The previous MAG then sends them to the local mobility anchor that's currently serving the mobile node.
Steps (g)-(h) are the same as steps (k)-(l) in the predictive fast handover procedures 🔁
Last but not least: in step (c), the NMAG needs the IP address of the PMAG so it can send the HI message to the PMAG. That info might come from the N-AN or from some database the NMAG can access. 🫶
4.2. Inter-AR Tunneling Operation ✨
okay so when the PMAG (PAR) or NMAG (NAR) gets an HI message with the 'F' flag set, it's time to get the mobile node's packets moving between the two MAGs 🦋 It sends back an HAck with the same sequence number, and that's the handshake. Both MAGs SHOULD support these encapsulation modes for the user packets, which are the same ones defined for the tunnel between the local mobility anchor and the MAG 💖
- IPv4-or-IPv6-over-IPv6 [RFC5844]
- IPv4-or-IPv6-over-IPv4 [RFC5844]
- IPv4-or-IPv6-over-IPv4-UDP [RFC5844]
- TLV-header UDP tunneling [RFC5845]
- Generic Routing Encapsulation (GRE) tunneling with or without GRE key(s) [RFC5845]
The PMAG and the NMAG MUST use the same tunneling mechanism for the data traffic tunneled between them. The encapsulation mode SHOULD be configurable, and it's RECOMMENDED that you go with one of these three scenarios 🎀
- As the default, the inter-MAG tunnel uses the same encapsulation mechanism as the PMIPv6 tunnel between the local mobility anchor and the MAGs. The PMAG and NMAG just automatically start using the same mechanism, no special configuration on the MAGs and no dynamic tunneling negotiation between them. Very low maintenance, very iconic 💅
- Configuration on the MAGs can override the default from scenario #1. The PMAG and NMAG MUST be configured with the same mechanism, and this is most likely going to be uniform across the whole PMIPv6 domain. If the packets on the PMIPv6 tunnel can't be uniquely mapped onto the configured inter-MAG tunnel, this scenario isn't applicable, and scenario #3 below SHOULD directly be applied 🙈
- An implicit or explicit tunnel negotiation mechanism between the MAGs can override the default from scenario #1. The negotiation mechanism itself is outside the scope of this document, so that's a different story 🌈
The necessary information MUST be transferred in the HI/HAck messages so the MAGs can figure out whether a mobile node's packets should be forwarded right away or later. That info includes the HNP(s) (or IPv4-MN-HoA) and/or GRE key(s) 🧚 When GRE tunneling uses GRE keys, the NMAG picks the GRE key for the downlink packets and the PMAG picks the GRE key for the uplink packets, for each mobility session. They swap these keys using the GRE Key option from [RFC5845]. For example, in the reactive mode from Figure 3, the DL GRE key rides along in the HI message and the UL GRE key comes back in the HAck message ✨
For downlink packets, the PMAG redirects the mobile node's packets from the local mobility anchor toward the NMAG. If the mobile node is ready to receive them, or the N-AN can handle them no matter what state the mobile node is in, the NMAG SHOULD send them straight on to the N-AN. Otherwise it SHOULD buffer them until the mobile node is ready 🫶 For uplink packets, the NMAG SHOULD reverse-tunnel them from the mobile node toward the PMAG, and then the PMAG sends them along to the local mobility anchor 🚀
When the PMAG or NMAG gets an HI message with the 'U' flag set, it gets ready to buffer the mobile node's packets and sends back an HAck with the same sequence number. This MUST be followed by another HI message with the 'F' flag set at an appropriate time, which is what actually forwards the buffered packets 💜
If the MAG that got the HI message runs into something erroneous (say, not enough buffer space), it SHOULD immediately send an HAck with the cause of the error and cancel all tunneling operations. Oof, big sad but very responsible 😭
4.3. IPv4 Support Considerations
Okay, IPv4 support in PMIPv6 has its own motivations and usage scenarios, and those are described in [RFC5844] 🌸 This feature covers two things:
- IPv4 Home Address Mobility Support, and
- IPv4 Transport Support.
For IPv4 Home Address Mobility Support, the mobile node gets the IPv4 Home Address (IPv4-MN-HoA). When a handover happens, the PMAG has to pass the IPv4-MN-HoA over to the NMAG, because that address is the inner destination address of the downlink packets. The IPv4 Address option from Section 6.2.7 is used for this 🍓 For IPv4 Transport Support, the NMAG needs to know the IPv4 address of the local mobility anchor (IPv4-LMAA) so it can send PMIPv6 signaling messages to the local mobility anchor across the IPv4 transport network. So there's a new option called the LMA Address (LMAA) option, defined in Section 6.2.2, that carries IPv4-LMAA from the PMAG to the NMAG 🎀
5. PMIPv6-Related Fast Handover Issues
5.1. Manageability Considerations
This specification doesn't require any extra IP-level functionality on the local mobility anchor or on the mobile node in the PMIPv6 domain 💖 A typical interface the mobile node could have is one on the cellular network, where the network controls how the mobile node moves around. Different interface types could be involved, like different generations (3G and 3.9G) or different radio access systems. This specification supports a mobile node in single radio mode, where only one interface is active at any given time. The assigned IP address stays the same whether or not the physical interface changes, and the mobile node can tell which interface to use if there are several of them ✨
5.2. Expedited Packet Transmission
The protocol in this document lets the NMAG get parameters that would otherwise only be available by talking to the local mobility anchor. For example, the HNP(s) and/or IPv4-MN-HoA of a mobile node are made available to the NMAG through context transfer. That lets the NMAG do some helpful stuff early 🧚 The NMAG SHOULD send a Router Advertisement (RA) with prefix information to the mobile node as soon as it detects the link attachment (for example, by receiving a Router Solicitation message). An RA like this is recommended in situations where the mobile node uses a new radio interface when attaching to the NMAG. Since the mobile node doesn't know anything about the new interface yet, it can't send packets right away without first getting an RA with HNP(s) 🫶
In reactive fast handover, the NMAG finds out the HNP(s) assigned to the mobile node on the previous link at step (d) in Figure 3. To cut down on communication disruption time, the NMAG SHOULD expect the mobile node to keep using the same HNP and to send uplink packets before that step, if the mobile node asks it to. But if the HAck from the PMAG returns a different HNP, or the later PMIPv6 binding registration for the HNP fails for some reason, then the NMAG MUST withdraw the advertised HNP by sending another RA with a zero prefix lifetime for that HNP. This is the same operation described in Section 6.12 of [RFC5213] 🚨
The protocol in this document works whether or not link-layer addresses are used between a mobile node and its MAG. A mobile node should be able to keep sending uplink packets even when it changes links. When link-layer addresses are used, the mobile node performs Neighbor Unreachability Detection (NUD) [RFC4861] after attaching to a new link, probing whether its default router is reachable. The new router should respond to the NUD probe by giving its link-layer address in the solicited Neighbor Advertisement, which is common in the PMIPv6 domain. Implementations should let the mobile node keep sending uplink packets while it's doing NUD 💅
6. Message Formats
This document defines new Mobility Header messages for the extended HI and HAck, plus new mobility options for carrying context information 🌈
6.1. Mobility Header
6.1.1. Handover Initiate (HI)
This section defines extensions to the HI message in [RFC5568]. The format of the Message Data field in the Mobility Header looks like this 🦋
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
+-------------------------------+
| Sequence # |
+-+-+-+-+-------+---------------+-------------------------------+
|S|U|P|F|Resv'd | Code | |
+-+-+-+-+-------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)IP Fields:
- Source Address: The IP address of the PMAG or NMAG
- Destination Address: The IP address of the peer MAG
Message Data:
- Sequence #: Same as [RFC5568].
- 'S' flag: Defined in [RFC5568], and MUST be set to zero in this specification.
- 'U' flag: Buffer flag. Same as [RFC5568].
- 'P' flag: Proxy flag. Used to tell the message apart from the one defined in [RFC5568]. It MUST be set in all new message formats defined in this document when using this protocol extension.
- 'F' flag: Forwarding flag. Used to request forwarding of the packets for the mobile node.
- Reserved: Same as [RFC5568].
- Code: [RFC5568] defines this field and its values, 0 and 1. In this specification, with the 'P' flag set, this field can be set to zero by default, or to the following values:
- 2: Indicate the completion of forwarding
- 3: All available context transferred
Code value 3 is set when the transfer of all necessary context information is completed with this message. This Code value gets used both when the context information is fragmented into several pieces and the last fragment is in this message, and when the whole information is transferred in one piece 💜
Mobility options:
This field contains one or more mobility options, whose encoding and formats are defined in [RFC3775] ✨
Required option
To uniquely identify the target mobile node, the mobile node identifier MUST be contained in the Mobile Node Identifier option 🎀
The transferred context MUST be for one mobile node per message. On top of that, the NMAG can request necessary mobility options via the Context Request option defined in this document 🧚
Context Request Option
This option MAY be present to request context information, typically sent by the NMAG to the PMAG in the NMAG-initiated fast handover 🫶
6.1.2. Handover Acknowledge (HAck) ✨
okay bestie, the HAck is basically the reply to an HI, and it's [RFC5568] with some new stuff added on top 💅 this section defines those extensions. The Message Data field in the Mobility Header looks like this:
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
+-------------------------------+
| Sequence # |
+-+-+-+---------+---------------+-------------------------------+
|U|P|F|Reserved | Code | |
+-+-+-+---------+---------------+ |
| |
. .
. Mobility options .
. .
| |
+---------------------------------------------------------------+
(Note: P=1)IP Fields 🌸
- Source Address: copied from the destination address of the Handover Initiate message this one is responding to. It's giving mirror 🪞
- Destination Address: copied from the source address of that same Handover Initiate message. Ping-pong, but make it cute 🏓
Message Data 🎀
The Sequence # and Reserved fields work exactly the same way they do in [RFC5568], so no surprises there ✨
- U flag: same as defined in Section 6.1.1.
- P flag: same as defined in Section 6.1.1. This is the one that tells everyone "hey, I'm not the old [RFC5568] message, I'm the new glow-up 🦋" and it MUST be set in all new message formats defined in this document when using this protocol extension.
- F flag: same as defined in Section 6.1.1.
Code 🔥
Code values 0 through 4 and 128 through 130 are defined in [RFC5568]. When the P flag is set, Code 0 means what this spec says it means, 128 through 130 get reused, and 5, 6, 131, and 132 are brand new 😭
0: Handover Accepted or Successful
5: Context Transfer Accepted or Successful
6: All available Context Transferred
128: Handover Not Accepted, reason unspecified
129: Administratively prohibited
130: Insufficient resources
131: Requested Context Not Available
132: Forwarding Not AvailableMobility options 🧚
This field holds one or more mobility options, and their encoding and formats are defined in [RFC3775]. The mobility option that uniquely identifies the target mobile node MUST be copied over from the matching HI message. Also, the transferred context MUST be for one mobile node per message, no sharing the spotlight 👑
Required option(s) 💜
All the context information asked for by the Context Request option in the HI message SHOULD show up in the HAck message. The other cases are below ⬇️
Now the spicy part. In PMAG-initiated fast handover, the PMAG sends the HI to the NMAG with the context info, and if the NMAG successfully receives it, the NMAG replies with a HAck carrying Code 5 ✨
In NMAG-initiated fast handover, the NMAG sends the HI to the PMAG with or without the Context Request option, and the PMAG replies with a HAck holding the requested or default context info (if there is any) 🍓 If ALL the available context info gets transferred, the PMAG sets the Code to 6. If there's still more context available, the PMAG sets the Code to 5, and the NMAG MAY send new HI message(s) to grab the rest. And if none of the requested context is available at all? The PMAG sends a HAck with Code 131 and no context info, which is a whole mood 😭
6.2. Mobility Options
6.2.1. Context Request Option
Okay, this option rides along in the HI message to ask for context info about the mobile node 🌈 If there's a default set of context info that's always defined and always enough, you don't need this option at all. It really shines when you want extra stuff or dynamically chosen stuff.
It's typically used for the reactive (NMAG-initiated) fast handover mode, where the NMAG goes "hey PMAG, give me the context 💅" When this option is in the HI message, ALL the requested context info SHOULD be included in the HAck message, inside the matching mobility option(s) (for example the HNP, LMAA, or MN LL-ID mobility options) ✨
The default context info to request is the Home Network Prefix option. If the Mobile Node link layer is available and being used, the Mobile Node Link-layer Identifier option MUST also be requested 🫶
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
+---------------+---------------+---------------+---------------+
| Option-Type | Option-Length | Reserved |
+---------------+---------------+-------------------------------+
| Req-type-1 | Req-length-1 | Req-type-2 | Req-length-2 |
+---------------------------------------------------------------+
| Req-type-3 | Req-length-3 | Req-option-3 |
+---------------------------------------------------------------+
| ... |- Option-Type:
40 - Option-Length: the length in octets of this option, not counting the Option Type and Option Length fields.
- Reserved: this field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 🙈
- Req-type-n: the type value for the nth requested option.
- Req-length-n: the length of the nth requested option, not counting the Req-type-n and Req-length-n fields.
- Req-option-n: the optional data that uniquely identifies the requested context for the nth requested option.
If there are only Req-type-n and Req-length-n fields, then Req-length-n is set to zero. If you need extra info beyond Req-type-n to pin down the requested context, that info goes right after Req-length-n. For example, when the requested contexts start with the HNP option (type=22), the MN Link-layer ID option (type=25), and the Vendor-Specific option (type=19), the format looks like this 🧚
| ... |
+---------------+---------------+---------------+---------------+
|Option-Type=CRO| Option-Length | Reserved |
+---------------+---------------+---------------+---------------+
| Req-type-n=22 | Req-length-n=0| Req-type-n=25 | Req-length-n=0|
+---------------+---------------+-------------------------------+
| Req-type-n=19 | Req-length-n=5| Vendor-ID |
+-------------------------------+---------------+---------------+
| Vendor-ID | Sub-Type | |
+-----------------------------------------------+ |
| ... |Note: CRO = Context Request Option
The first two options can uniquely identify their contexts (the HNP and MN Link-layer ID) just by their Req-type, so Req-length is set to zero. The Vendor-Specific option, though, needs its Vendor-ID and Sub-Type to figure out which context is wanted, so those follow, and Req-length is set to 5 🎀 The exact values for Vendor-ID and Sub-Type follow [RFC5094].
6.2.2. Local Mobility Anchor Address (LMAA) Option
This option carries the Local Mobility Anchor IPv6 Address (LMAA), or its IPv4 Address (IPv4-LMAA), that the mobile node is currently registered with 🦋 The full scoop on the LMAA lives in [RFC5213].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Option-Code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Mobility Anchor Address ... |- Option-Type:
41 - Option-Length:
18or6 - Option-Code:
0: Reserved1: IPv6 address of the local mobility anchor (LMAA)2: IPv4 address of the local mobility anchor (IPv4-LMAA)
- Reserved: this field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 🌸
- Local Mobility Anchor Address: if the Option-Code is 1, the LMA IPv6 address (LMAA) goes here. If the Option-Code is 2, the LMA IPv4 address (IPv4-LMA) goes here.
6.2.3. Mobile Node Link-Local Address Interface Identifier (MN LLA-IID) Option
This option carries the interface identifier of the mobile node's IPv6 Link-local Address that's used in the P-AN. In deployments where the interface identifier is assigned by the network or already known to the network, this option transfers that identifier from the PMAG to the NMAG 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option-Type | Option-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Interface Identifier +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Option-Type:
42 - Option-Length:
10 - Reserved: this field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. 💀
- Interface Identifier: the Interface Identifier value used for the mobile node's IPv6 Link-local address in the P-AN.
6.2.4. Home Network Prefix Option
This option, as defined in [RFC5213], transfers the home network prefix that's assigned to the mobile node in the P-AN. Simple and iconic 👑
6.2.5. Link-Local Address Option
This option, as defined in [RFC5213], transfers the link-local address of the PMAG 💖
6.2.6. GRE Key Option
This option carries the GRE Key for the mobile node's data flow over the bidirectional tunnel between the PMAG and NMAG 🌈 Its message format follows the GRE Key option defined in [RFC5845]. The GRE Key value uniquely identifies each flow, and the sender of this option expects to receive packets of that flow from the peer AR with this value ✨
6.2.7. IPv4 Address Option
As described in Section 4.3, if the mobile node runs in IPv4-only mode or dual-stack mode, it needs an IPv4 home address (IPv4-MN-HoA) 🦋 This option transfers that IPv4 home address if it was assigned on the previous link. Its format follows the IPv4 Home Address Request option defined in [RFC5844].
6.2.8. Vendor-Specific Mobility Option 🎀
okay so this option is basically the catch-all bag 🛍️ it carries any other info this document defines. The format and values follow the Vendor-Specific Mobility option from [RFC5094], so you already know how it works if you've seen that one 💅
7. Security Considerations 🔐
bestie, this part is SERIOUS 😭 but it's also important, so let's go.
Security issues here follow the ones for PMIPv6 [RFC5213] and FMIPv6 [RFC5568]. In PMIPv6, the MAG and the local mobility anchor are assumed to share security associations. In FMIPv6, the access routers (aka the PMAG and NMAG in this document) are assumed to share security associations 🤝
The Handover Initiate (HI) and Handover Acknowledge (HAck) messages exchanged between the PMAG and NMAG MUST be protected using end-to-end security association(s) offering integrity and data origin authentication. The PMAG and the NMAG MUST implement IPsec [RFC4301] for protecting the HI and HAck messages. IPsec Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection SHOULD be used for protecting the signaling messages. Confidentiality protection SHOULD be used if sensitive context related to the mobile node is transferred. 🔒✨
Heads up: the two MUSTs above are not optional. HI and HAck protection with IPsec is a hard requirement, so don't skip it 🙅♀️
IPsec ESP [RFC4303] in tunnel mode SHOULD be used to protect the mobile node's packets at the time of forwarding if the link between the PMAG and NMAG exposes the mobile node's packets to more threats than if they had followed their normal routed path. So if that link is a bit sketchy, tunnel mode is the move 🚇🛡️
8. IANA Considerations 📚
This document defines new flags and status codes in the HI and HAck messages, plus three new mobility options. The Type values for those options come from the same numbering space as the other mobility options defined in [RFC3775]. The flags and status codes come from the matching numbering space defined in [RFC5568], and they've been made as new tables in the IANA registry (marked with asterisks). New values can be allocated by Standards Action or IESG approval [RFC5226]. 🗂️
The new mobility options:
Mobility Options
Value Description Reference
----- ------------------------------------- -------------
40 Context Request Option Section 6.2.1
41 Local Mobility Anchor Address Option Section 6.2.2
42 Mobile Node Link-local Address
Interface Identifier Option Section 6.2.3The new Handover Initiate flags:
Handover Initiate Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ----------------------------------- -------------
S 0x80 Assigned Address Configuration flag [RFC5568]
U 0x40 Buffer flag [RFC5568]
P 0x20 Proxy flag Section 6.1.1
F 0x10 Forwarding flag Section 6.1.1The new Handover Acknowledge flags:
Handover Acknowledge Flags (*)
Registration Procedures: Standards Action or IESG Approval
Flag Value Description Reference
---- ----- ------------------------------- -------------
U 0x80 Buffer flag Section 6.1.2
P 0x40 Proxy flag Section 6.1.2
F 0x20 Forwarding flag Section 6.1.2The new Handover Initiate status codes:
Handover Initiate Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- -------------------------------------- -------------
0 FBU with the PCoA as source IP address [RFC5568]
1 FBU whose source IP address is not PCoA [RFC5568]
2 Indicate the completion of forwarding Section 6.1.1
3 All available context transferred Section 6.1.1
4-255 UnassignedThe new Handover Acknowledge status codes:
Handover Acknowledge Status Codes (*)
Registration Procedures: Standards Action or IESG Approval
Code Description Reference
---- --------------------------------------- -------------
0 Handover Accepted or Successful
(when 'P' flag is set) Section 6.1.2
Handover Accepted with NCoA valid [RFC5568]
1 Handover Accepted, NCoA not valid [RFC5568]
2 Handover Accepted, NCoA assigned [RFC5568]
3 Handover Accepted, use PCoA [RFC5568]
4 Message sent unsolicited [RFC5568]
5 Context Transfer Accepted or Successful Section 6.1.2
6 All available Context Transferred Section 6.1.2
7-127 Unassigned
128 Handover Not Accepted, reason unspecified [RFC5568]
129 Administratively prohibited [RFC5568]
130 Insufficient resources [RFC5568]
131 Requested Context Not Available Section 6.1.2
132 Forwarding Not Available Section 6.1.2
133-255 Unassigned9. Acknowledgments 🫶
The authors want to give a super special shoutout to Vijay Devarapalli and Sri Gundavelli for their thorough reviews of this document. You two are literally the reason it's good 💖
The authors also want to thank Charlie Perkins, Desire Oulai, Ahmad Muhanna, Giaretta Gerardo, Domagoj Premec, Marco Liebsch, Fan Zhao, Julien Laganier, and Pierrick Seite for their passionate discussions on the MIPSHOP working group mailing list. The debate era was iconic 🔥
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.
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
- [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
- [RFC5094] Devarapalli, V., Patel, A., and K. Leung, "Mobile IPv6 Vendor Specific Option", RFC 5094, December 2007.
- [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
- [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
- [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 2009.
- [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", RFC 5844, May 2010.
- [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", RFC 5845, June 2010.
10.2. Informative References
- [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4988] Koodli, R. and C. Perkins, "Mobile IPv4 Fast Handovers", RFC 4988, October 2007.
Appendix A. Applicable Use Cases 🧠
A.1. PMIPv6 Handoff Indication
PMIPv6 [RFC5213] defines the Handoff Indicator option, and it also describes the types of handoff and the values that can be set for this option. This document proposes one approach for the NMAG to determine the handoff type when the mobile node's handoff is executed. 🏃♀️
According to [RFC5213], these handoff types are defined:
0) Reserved
1) Attachment over a new interface
2) Handoff between two different interfaces of the mobile node
3) Handoff between mobile access gateways for the same interface
4) Handoff state unknown
5) Handoff state not changed (Re-registration)Assuming there's a valid MN Link-layer Identifier (MN LL-ID), here's a solution you can consider. When the NMAG gets the MN LL-ID from the PMAG in the MN LL-ID option via the HI or HAck message, it compares that with the new MN LL-ID it got from the mobile node in the N-AN. If the two MN LL-IDs are the same, the handoff type falls into type 3 (defined above) and the Handoff Indicator value is set to 3. If they're different, the handoff is likely type 2 (defined above), since the HI/HAck exchange implies this is a handoff rather than a multihoming, so the Handoff Indicator value can be set to 2. If there's no HI/HAck exchange before the mobile node attaches in the N-AN, the NMAG may infer that this is a multi-homing case and set the Handoff Indicator value to 1. In the case of re-registration, the MAG the mobile node is attached to can tell that the handoff state hasn't changed, so the MAG can set the HI value to 5 without any extra info. If no handoff type can be assumed, or there's no valid MN LL-ID available, the NMAG may set the value to 4. 🧩
A.2. Local Routing
As described in Section 6.10.3 of [RFC5213], if the EnableMAGLocalRouting flag is set, then when two mobile nodes are attached to one MAG, the traffic between them may be locally routed. If one mobile node moves from this MAG (PMAG) to another MAG (NMAG), and the PMAG doesn't detect the mobile node's detachment, it'll keep forwarding packets locally forever 😱 This situation is more likely with reactive fast handover over Wireless Local Area Network (WLAN) access, which can't detect the mobile node's detachment in a timely manner. This specification can be applied to handle this case. When the mobile node attaches to the NMAG, the NMAG sends the HI message to the PMAG with the 'F' flag set. That makes the PMAG realize the mobile node has detached and establish the inter-MAG tunnel. The PMAG immediately stops the local routing and sends the mobile node's packets to the NMAG through that tunnel, and then they're delivered to the mobile node on the new link. 🦋
Authors' Addresses 💌
Hidetoshi Yokota
KDDI Lab
2-1-15 Ohara, Fujimino
Saitama 356-8502
Japan
EMail: yokota@kddilabs.jp
Kuntal Chowdhury
Cisco Systems
30 International Place
Tewksbury, MA 01876
USA
EMail: kchowdhu@cisco.com
Rajeev Koodli
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
USA
EMail: rkoodli@cisco.com
Basavaraj Patil
Nokia
6000 Connection Drive
Irving, TX 75039
USA
EMail: basavaraj.patil@nokia.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
EMail: xiayangsong@huawei.com📦 where this page comes from
- ietf: rfc5949 2010-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms