RFC 4067
Context Transfer Protocol (CXTP)
Context Transfer Protocol (CXTP) 🦋
- Stream: Network Working Group 💜
- RFC: 4067
- Category: Experimental 🧪
- Date: July 2005 🗓️
- Authors: J. Loughney, Ed., M. Nakhjiri, C. Perkins, R. Koodli 👯♀️
- Obsoletes / Updates: Nothing. This header doesn't list any RFCs it obsoletes or updates.
Status of This Memo 🌸
Okay bestie, first things first: this memo defines an Experimental Protocol for the Internet community. It is not an Internet standard of any kind, so don't go calling it one 🙅♀️. Discussion and suggestions for improvement are requested, so if you've got ideas, share them! Distribution of this memo is unlimited 💖.
Copyright Notice 🎀
Copyright (C) The Internet Society (2005).
Abstract ✨
So this doc presents the Context Transfer Protocol (CXTP), which enables authorized context transfers 🔐. Why is that a big deal? Context transfers give better support for node based mobility, so the apps running on mobile nodes can keep working with minimal disruption 📱💨. The key goals are to reduce latency and packet losses, and to avoid re-initiating signaling to and from the mobile node. Main character energy for your phone's apps, honestly 👑.
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Problem. . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Conventions Used in This Document. . . . . . . . . . . . 3
1.3. Abbreviations Used in the Document . . . . . . . . . . . 3
2. Protocol Overview. . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Context Transfer Scenarios . . . . . . . . . . . . . . . 4
2.2. Context Transfer Message Format. . . . . . . . . . . . . 5
2.3. Context Types. . . . . . . . . . . . . . . . . . . . . . 6
2.4. Context Data Block (CDB) . . . . . . . . . . . . . . . . 7
2.5. Messages . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Transport. . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Inter-Router Transport . . . . . . . . . . . . . . . . . 16
3.2. MN-AR Transport. . . . . . . . . . . . . . . . . . . . . 19
4. Error Codes and Constants. . . . . . . . . . . . . . . . . . . 20
5. Examples and Signaling Flows . . . . . . . . . . . . . . . . . 21
5.1. Network controlled, Initiated by pAR, Predictive . . . . 21
5.2. Network controlled, Initiated by nAR, Reactive . . . . . 21
5.3. Mobile controlled, Predictive New L2 up/Old L2 down. . . 22
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 22
6.1. Threats. . . . . . . . . . . . . . . . . . . . . . . . . 22
6.2. Access Router Considerations . . . . . . . . . . . . . . 23
6.3. Mobile Node Considerations . . . . . . . . . . . . . . . 24
7. Acknowledgements & Contributors. . . . . . . . . . . . . . . . 25
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
8.1. Normative References . . . . . . . . . . . . . . . . . . 25
8.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. Timing and Trigger Considerations . . . . . . . . . . 28
Appendix B. Multicast Listener Context Transfer . . . . . . . . . 281. Introduction ✨
This doc describes the Context Transfer Protocol, and it gives you three big things 🧁:
- Representation for feature contexts. 🗂️
- Messages to initiate and authorize context transfer, and to notify a mobile node of the status of the transfer. 📣
- Messages for transferring contexts before, during, and after handovers. 🔁
The proposed protocol is designed to work alongside other protocols to give you seamless mobility 🦋. It supports both IPv4 and IPv6, though support for IPv4 private addresses is for future study 🔮.
1.1. The Problem 💭
"Problem Description: Reasons For Performing Context Transfers between Nodes in an IP Access Network" [RFC3374] lists the main reasons why Context Transfer procedures might be useful in IP networks. Here's the tea ☕:
- The big one is to quickly re-establish context transfer-candidate services without making the mobile host redo every protocol flow for those services from scratch. An example of such a service is in Appendix B of this document 🙌.
- The other reason is to provide an interoperable solution that works with various Layer 2 radio access technologies 📡.
1.2. Conventions Used in This Document 📝
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 RFC 2119 [RFC2119]. Read those carefully, they're the rules 💅.
1.3. Abbreviations Used in the Document 🔤
Mobility Related Terminology [TERM] defines the basic mobility terminology. On top of what's in that doc, this one uses the following terms and abbreviations:
CXTP Context Transfer Protocol
DoS Denial-of-Service
FPT Feature Profile Types
PCTD Predictive Context Transfer Data2. Protocol Overview 🧚
Okay, this is the part where it all clicks. A context transfer can start in one of two ways: either the mobile node asks for it ("mobile controlled"), or the new or previous access router gets the ball rolling on its own ("network controlled") 🎀.
- The mobile node (MN) sends the CT Activate Request (CTAR) to its current access router (AR) right before a handover, when it's possible to start a predictive context transfer. No matter what, the MN always sends the CTAR message to the new AR (nAR) 📤. If the contexts are already there, the nAR checks the authorization token in the CTAR by computing its own using the parameters the previous access router (pAR) supplied, and then activates those contexts ✅. If the contexts aren't there, the nAR asks the pAR to supply them using the Context Transfer Request message, and in that request it passes along the authorization token from the CTAR 🙏.
- Either the nAR or the pAR can request or start (respectively) a context transfer, based on internal or network triggers. See Appendix A for those 🔔.
The Context Transfer protocol usually runs between a source node and a target node. Later on there might be multiple target nodes involved, and this protocol would work with those too. To keep things simple, though, we describe it assuming a single receiver, or target node 🎯.
Typically, the source node is an MN's pAR and the target node is an MN's nAR 🏠➡️🏡. A context transfer happens when an event, like a handover, takes place. We call that event a Context Transfer Trigger ⚡. In response to a trigger, the pAR may transfer the contexts, the nAR may request them, and the MN may send a message to the routers to transfer them 💌. A trigger has to be able to provide the info needed to identify the contexts (such as the MN's IP address). It also has to provide the IP addresses of the access routers, plus the authorization to transfer context. No info, no transfer, periodt 🫶.
Context transfer protocol messages use Feature Profile Types (FPTs), which describe how the data is organized for each particular feature context 🗃️. The FPTs are registered in a number space (with IANA Type Numbers), so a node can figure out, without any guessing, the type of context and the context parameters in the protocol messages 🔍. Contexts get transferred by laying out the right feature data inside Context Data Blocks, following the format in Section 2.3, along with whatever IP addresses are needed to tie the contexts to a particular MN 📦. The context transfer initiation messages carry parameters that identify the source and target nodes, the list of desired feature contexts, and the IP addresses used to identify the contexts. The messages that request the transfer of context data also carry an appropriate token to authorize the transfer 🔑.
Doing a context transfer before the MN attaches to the nAR can boost handover performance 🚀. For that to happen, certain conditions have to be met. For example, the pAR needs enough time and knowledge about the impending handover. That's doable with, for instance, Mobile IP fast handovers [LLMIP][FMIPv6]. Also, plenty of cellular networks have ways to detect handovers in advance 📶. But when advance knowledge of an impending handover isn't available, or a mechanism like fast handover fails, fetching the feature contexts after the MN attaches to the nAR is the only option left 😬. Doing the transfer after handover can still beat re-establishing every context from scratch, as shown in [FHCT] and [TEXT] 💪. And some contexts may simply need to be transferred during handover signaling. For example, any context that gets updated on a per-packet basis must clearly be transferred only after packet forwarding to the MN on its previous link has ended 📬.
2.1. Context Transfer Scenarios 🎬
The Previous Access Router transfers feature contexts under two general scenarios. Let's start with the first one 👀.
2.1.1. Scenario 1
The pAR gets a Context Transfer Activate Request (CTAR) message from the MN whose feature contexts are to be transferred, or it gets an internally generated trigger (for example, a link-layer trigger on the interface the MN is connected to) 🔔. The CTAR message, described in Section 2.5, gives the IP address of the nAR, the IP address of the MN on the pAR, the list of feature contexts to be transferred (by default, all contexts get transferred), and a token authorizing the transfer 🎟️. In response to a CT-Activate Request message or to the CT trigger, the pAR predictively transmits a Context Transfer Data (CTD) message that contains feature contexts 📨. This message, also described in Section 2.5, contains the MN's previous IP address. It also contains parameters for the nAR to compute an authorization token, which it uses to verify the MN's token that was in the CTAR message 🧾.
Here's a reminder, because it matters: the MN always sends a CTAR message to the nAR, even if it already sent one to the pAR. That's because the MN has no way to tell whether the context transfer actually happened reliably 🤷♀️. By always sending the CTAR to the nAR, the Context Transfer Request (see below) can be sent to the pAR if it's needed 🫶.
When a context transfer happens without the nAR asking for it, the nAR requires the MN to present its authorization token 🔐. Checking that locally at the nAR, once the MN attaches, improves performance and boosts security, since the contexts are likely to already be there ✨. Token verification happens at the router that has the contexts 💖.
2.1.2. Scenario 2 ✨
okay so in scenario 2, pAR gets a Context Transfer Request (CT-Req) message from nAR, which is explained in Section 2.5 💌 nAR makes that CT-Req either because it got a CTAR message, or because something triggered a context transfer. 🔥 In the CT-Req, nAR brings along the MN's previous IP address, the FPTs for the feature contexts it wants moved, the sequence number from the CTAR, and the authorization token from the CTAR. 🫶 When pAR gets a CT-Req, it sends back a Context Transfer Data (CTD) message with the MN's previous IP address and the feature contexts inside. ✨ Once nAR gets the matching CTD, it can send a CTD Reply (CTDR) to say how processing the contexts went 🎀 And nAR only installs the contexts after it has received them from pAR. 💅
2.2. Context Transfer Message Format 🦋
a CXTP message is made of a message-specific header plus one or more data blocks 🧚 You can bundle data blocks together for a more efficient transfer, which is so smart 🧠 On the inter-AR interface, SCTP is used, so fragmentation should not be a problem 🌸 On the MN-AR interface, though, the total packet size (counting the transport protocol and IP protocol headers too) SHOULD be less than the path MTU so you avoid packet fragmentation 🙈 Every message has a 3 bit version number field in the low order octet, sitting next to the 5 bit message type code 💜 This spec only covers Version 1 of the protocol, so the version number field MUST be set to 0x1 🍓 And if future revisions make binary incompatible changes, the version number MUST be incremented 👑
2.3. Context Types 🌈
okay context types are identified by the FPT code, which is a 16 bit unsigned integer ⭐ What each context type means is decided by its own specification document 📄 The context type numbers get listed in a registry that IANA maintains [IANA], and they're handled according to the message specs in this document 💖 How nAR instantiates each context depends on the messages in this document together with the spec for that particular context type 🫶 Here's the general shape of a CXTP message 👇
+----------------------+
| Message Header |
+----------------------+
| CXTP Data 1 |
+----------------------+
| CXTP Data 2 |
+----------------------+
| ... |every context type spec has to include these details 💅
- the number, size (in bits), and ordering of the data fields in the state variable vector that holds the context ✨
- the default values (if there are any) for each datum in that context state vector 🎀
- the procedures and requirements for creating a context at a new access router, based on the data sent from a previous access router and formatted using the ordering rules and field sizes in the spec 🔥
- if possible, the status codes for success or failure of the context transfer. for example, a QoS context transfer might have different status codes depending on which parts of the context data couldn't be instantiated at nAR 🦋
2.4. Context Data Block (CDB) 🌸
the Context Data Block (CDB) is used for both requests and responses 💜 When you're building a request, usually only the first 4 octets are needed (see CTAR below) 🧚 When the CDB is carrying the actual feature context, the context data is there, and sometimes the presence vector is there too ✨
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Feature Profile Type (FPT) | Length |P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Presence Vector (if P = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Feature Profile Type
16 bit integer, assigned by IANA,
indicating the type of data
included in the Data field.
Length Message length in units of 8 octet words.
'P' bit 0 = No presence vector.
1 = Presence vector present.
Reserved Reserved for future use. Set to
zero by the sender.
Data Context type-dependent data, whose
length is defined by the Length
Field. If the data is not 64 bit
aligned, the data field is
padded with zeros.so the FPT code tells you what kind of data is in the data field 🎀 Usually it's context data, but it could also be an error indication 🙈 The 'P' bit says whether the "presence vector" is being used 💅 When it is, the presence vector shows which data fields are present (and hold non-default values) 🫶 The bits in the presence vector line up with the data fields in the order the context type spec lists them, with one bit per data field no matter how big that field is 🦋 The Length field gives the size of the CDB in 8 octet words, and that count includes the first 4 octets starting from FPT 🌈
one more thing 👀 the length of the context data block is the sum of the lengths of every data field from the context type spec, plus 4 octets if the 'P' bit is set, minus the total size of all the context data that's already implied by default values 💖
2.5. Messages 💜
this section defines the CXTP messages 🧚 The MN that a context transfer operation is happening for is always identified by its previous IP access address 🌸 Only one context transfer operation per MN can be in progress at a time, so the CTDR message can say exactly which CTD message it's acknowledging just by including the MN's previous IP address 🔥 The 'V' flag tells you whether the IP addresses are IPv4 or IPv6 ✨
2.5.1. Context Transfer Activate Request (CTAR) Message 🎀
the MN always sends this message to nAR to ask for a context transfer 🫶 Even if the MN has no idea whether any contexts need transferring, it still sends the CTAR 💅 If the MN needs an acknowledgement for this message, it sets the 'A' flag to 1, and otherwise it doesn't expect one 🦋 The message can include a list of FPTs that need transferring 🌈
The MN can also send this message to pAR while it's still connected to pAR 👑 In that case the MN includes nAR's IP address, and otherwise, if the message goes to nAR, the pAR address gets sent instead 💖 The MN MUST set the sequence number to the same value it used for the message sent to both pAR and nAR, so pAR can tell whether to use a cached message 🍓
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ MN's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Previous (New) AR IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Requested Context Data Block (if present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1
Type CTAR = 0x1
'V' flag When set to '0', IPv6 addresses.
When set to '1', IPv4 addresses.
'A' bit If set, the MN requests an acknowledgement.
Reserved Set to zero by the sender, ignored by the
receiver.
Length Message length in units of octets.
MN's Previous IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
nAR / pAR IP Address Field contains either:
IPv4 [RFC791] Address, 4 octets, or
IPv6 [RFC3513] Address, 16 octets.
Sequence Number A value used to identify requests and
acknowledgements (see Section 3.2).
Authorization Token An unforgeable value calculated as
discussed below. This authorizes the
receiver of CTAR to perform context
transfer.
Context Block Variable length field defined in
Section 2.4.if no context types are specified, the MN is asking for all of its contexts 🌸
the Authorization Token gets calculated like this 🔐
First (32, HMAC_SHA1
(Key, (Previous IP address | Sequence Number | CDBs)))where Key is a shared secret between the MN and pAR 🗝️ and CDB is all the Context Data Blocks that specify which contexts to transfer and are included in the CTAR message, concatenated together 💜
2.5.2. Context Transfer Activate Acknowledge (CTAA) Message ✨
Okay bestie, this one's the receiver of CTAR replying to the MN to say "got it" 💌. It's informative, and sending it is optional, depending on whether the MN asked for an ack 🫶. It can also carry a list of FPTs that didn't transfer successfully, so the MN knows what didn't make it 😭.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ........ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the breakdown 💖:
Vers.: version number of CXTP protocol = 0x1 🌸Type: CTAA = 0x2 🦋'V' flag: when it's '0', that means IPv6 addresses. When it's '1', that means IPv4 addresses. 💅Reserved: the sender sets it to zero and the receiver just ignores it 🙈Length: the message length, in units of octets ✨MN's Previous IP Address: this field holds either:FPT: a 16 bit unsigned integer listing the Feature Profile Type that didn't transfer successfully 😬Status Code: one octet, holding the failure reason 💀........: more FPTs and status codes, as many as needed 🧚
2.5.3. Context Transfer Data (CTD) Message 🎀
So this is sent by the pAR to the nAR, and it carries the feature data (CXTP data) 📦. It handles both predictive and normal CT, which is so efficient 🔥. There's an acknowledgement flag, 'A', in this message that tells you whether the pAR wants a reply back 👑.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|A| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Elapsed Time (in milliseconds) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous Care-of Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^
| Algorithm | Key Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD
| Key | only
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V
~ First Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Context Data Block ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The field rundown 🧁:
Vers.: version number of CXTP protocol = 0x1 🌸Type: CTD = 0x3 (Context Transfer Data), or PCTD = 0x4 (Predictive Context Transfer Data) 🦋'V' flag: when it's '0', that means IPv6 addresses. When it's '1', that means IPv4 addresses. 💅'A' bit: when it's set, the pAR is asking for an acknowledgement 🙋♀️Length: the message length, in units of octets ✨Elapsed Time: the number of milliseconds since the first CTD message for this MN was sent ⏱️MN's Previous IP Address: this field holds either:Algorithm: the algorithm used to compute the MN Authorization Token. Right now only 1 algorithm is defined, HMAC_SHA1 = 1 🔐Key Length: the length of the key, in octets 🗝️Key: the shared key between the MN and the AR for CXTP 🫶Context Data Block: the Context Data Block (see Section 2.4) 📦
So when CTD gets sent predictively, the parameters that come with it (the algorithm, key length, and the key itself) let the nAR compute a token locally and check it against the token in the CTAR message. Iconic, right? 🧠 That material also gets sent if the pAR gets a CTD message with a null Authorization Token. That just means the CT-Req message was sent before the nAR got the CTAR message 🙈.
CTD MUST be protected by IPsec; see Section 6. This one's not optional, bestie 🔒💀
As we said before, the algorithm for the MN Authorization Token computation is HMAC_SHA1. The token authentication calculation is described in Section 2.5.1 🔐.
For predictive handover, the pAR SHOULD keep track of the CTAR sequence number and cache the CTD message 🗂️. It keeps doing that until a CTDR message for the MN's previous IP address comes back from the pAR, which means the context transfer worked, or until CT_MAX_HANDOVER_TIME runs out ⏳. The nAR MAY send a CT-Req message with the same sequence number if the predictive CTD message never arrived or the context got corrupted. In that case, the nAR sends a CT-Req message with a matching sequence number, and the pAR can resend the context 🔁✨.
2.5.4. Context Transfer Data Reply (CTDR) Message 💌
The nAR sends this one to the pAR, and which flag matters depends on the 'A' flag in CTD. It tells the pAR whether things worked or flopped 🥹.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V|S| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FPT (if present) | Status code | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The breakdown 🍓:
Vers.: version number of CXTP protocol = 0x1 🌸Type: CTDR = 0x5 (Context Transfer Data) 🦋'V' flag: when it's '0', that means IPv6 addresses. When it's '1', that means IPv4 addresses. 💅'S' bit: when it's set to one, every feature context sent in CTD or PCTD came through successfully 🎉Reserved: the sender sets it to zero and the receiver ignores it 🙈Length: the message length, in units of octets ✨MN's Previous IP Address: this field holds either:FPT: a 16 bit unsigned integer listing the Feature Profile Type being acknowledged 🧾Status Code: a context-specific return value. It's zero for success and nonzero when'S'isn't set to one 💀
2.5.5. Context Transfer Cancel (CTC) Message 🛑
If a context transfer can't be finished in a timely way, the nAR can send CTC to the pAR to cancel the ongoing CT process 🙅♀️. Honestly, sometimes you just have to let it go 💅.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the fields 🫧:
Vers.: version number of CXTP protocol = 0x1 🌸Type: CTC = 0x6 (Context Transfer Cancel) 🦋Length: the message length, in units of octets ✨'V' flag: when it's '0', that means IPv6 addresses. When it's '1', that means IPv4 addresses. 💅Reserved: the sender sets it to zero and the receiver ignores it 🙈MN's Previous IP Address: this field holds either:
2.5.6. Context Transfer Request (CT-Req) Message ✨
okay bestie, the CT-Req is sent by the nAR to the pAR 💌 to basically ask "hey, can we start the context transfer?" 🎀 It only goes out as a reply to a CTAR message, and every field after the Previous IP address of the MN is copied straight over from that CTAR, no edits 🫶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Vers.| Type |V| Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Mobile Node's Previous IP Address ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Authorization Token |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Next Requested Context Data Block (if present) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ........ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Here's the field breakdown 🧁
Vers.🌸 the CXTP protocol version number, which is0x1Type🦋CTREQ = 0x7(Context Transfer Request)Vflag 🎀 when it's'0', the addresses are IPv6. When it's'1', they're IPv4.Reserved🙈 the sender sets it to zero and the receiver just ignores itLength📏 the message length in units of octets- MN's Previous IP Address 🏠 this holds either an IPv4 [RFC791] address (4 octets) or an IPv6 [RFC3513] address (16 octets)
- Sequence Number 🔁 copied from the CTAR message, so the pAR can tell these requests apart from context it already sent earlier
- MN's Authorization Token 🔐 an unforgeable value worked out the way Section 2.5.1 describes. It's what authorizes the receiver of CTAR to do the context transfer. Copied from CTAR.
- Context Data Request Block 🧚 a request block for context data; see Section 2.4
The sequence number is how the pAR matches up a request with context it sent before 🧩 In predictive transfer, if the MN sends CTAR before handover, the pAR pushes context to the nAR using PCTD. If that CTD fails, the nAR sends a CT-Req with the same sequence number, so the pAR knows exactly which context to resend 🔄 The pAR deletes the context after CXTP_MAX_TRANSFER_TIME ⏳ The sequence number is not used in reactive transfer.
For predictive transfer, the pAR sends the keying material and other info needed to calculate the Authorization Token, all without ever having processed a CT-Req message 🗝️ For reactive transfer it's a little different 👀 If the nAR gets a context transfer trigger but hasn't received the CTAR message with the authorization token yet, the Authorization Token field in CT-Req is set to zero. The pAR reads that zero as a signal to include the keying material and other info needed to calculate the Authorization Token, and it packs that material into the CTD message just like it would for predictive transfer. This gives the nAR what it needs to calculate the authorization token when the MN sends CTAR 💜
3. Transport 🚚
3.1. Inter-Router Transport 🛣️
Okay so most of the access networks where CXTP would be useful aren't really out there yet, or if they are, nobody has measured them much 😬 That makes it hard to know whether congestion will be a problem for CXTP. Part of the research job, before CXTP can even be considered for standardization, is figuring out how big this issue actually is 📊 But here's the safety part: if a prototype CXTP deployment ends up running over the public Internet, we don't want it messing with real production applications 🙅♀️ so it makes sense to recommend a default transport that handles congestion nicely 🌈 Also, feature context has a definite lifetime, so the transport must allow flexible retransmission, which means stale contexts stuck behind congestion get dropped 🗑️ And since the amount of context data can be arbitrarily large, the transport should not be limited to a single packet or make you build a custom fragmentation protocol 🧩
So with all that in mind 💅 implementations of CXTP MUST support, and prototype deployments of CXTP SHOULD use, the Stream Control Transport Protocol (SCTP) [SCTP] as the transport protocol on the inter-router interface, especially if deployment over the public Internet is on the table 🌐 SCTP handles congestion control, fragmentation, and partial retransmission based on a programmable retransmission timer 🔥 It also has a bunch of fancy extras like multiple streams and multiple IP addresses for failover, but those aren't necessary for experimenting with CXTP or running a prototype, so the use of such SCTP features is not recommended at this time 🙃
The SCTP Payload Data Chunk carries the context transfer protocol messages 🎁 The User Data part of each SCTP message holds an appropriate context transfer protocol message defined in this document. The messages sent over SCTP are CTD (Section 2.5.3), CTDR (Section 2.5.4), CTC (Section 2.5.5), and CT-Req (Section 2.5.6). In general, each SCTP message can carry feature contexts belonging to any MN 💖 And if the SCTP checksum calculation fails, the nAR returns the BAD_CHECKSUM error code in a CTDR message 😭
A single stream is used for context transfer without in-sequence delivery of SCTP messages 🌊 Each message corresponds to a single MN's feature context collection. A single stream keeps things simple ✨ Using multiple streams to prevent head-of-line blocking is for future study. Unordered delivery means the receiver doesn't have to block for in-sequence delivery of messages that belong to different MNs 🦄 The Payload Protocol Identifier in the SCTP header is 'CXTP', and inter-router CXTP uses the Seamoby SCTP port [IANA] 🎀
Timeliness of the context transfer information SHOULD be handled by setting the SCTP maximum retransmission value to CT_MAX_TRANSFER_TIME, so it fits the maximum acceptable handover delay time ⏱️ The AR SHOULD be configured with CT_MAX_TRANSFER_TIME to match the particular wireless link technology and local wireless propagation conditions 📡 SCTP message bundling SHOULD be turned off to cut down on extra delay when sending messages 🏃♀️ Within CXTP, the nAR SHOULD estimate the retransmit timer from the moment it receives the first fragment of a CXTP message, and it should avoid processing any IP traffic from the MN until either context transfer is complete or the estimated retransmit timer expires 🫣 If both routers support PR-SCTP [PR-SCTP], then PR-SCTP SHOULD be used. PR-SCTP changes the lifetime parameter of the Send() operation (defined in Section 10.1 E in [SCTP]) so that it applies to retransmits as well as transmits. So with PR-SCTP, if the lifetime runs out and the data chunk hasn't been acknowledged, the transmitter stops retransmitting. In the base protocol, the data would keep being retransmitted until it's acknowledged or the connection times out 🔁
Here's the format of the Payload Data Chunk, taken from [SCTP] 📦
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 = 0 | Reserved|U|B|E| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Identifier S | Stream Sequence Number n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload Protocol Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ User Data (seq n of Stream S) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+And the field goodies 🍓
'U'bit 💫 the Unordered bit. It MUST be set to 1 (one).'B'bit 🌷 the Beginning fragment bit. See [SCTP].'E'bit 🌷 the Ending fragment bit. See [SCTP].TSN🔢 Transmission Sequence Number. See [SCTP].Stream Identifier S🎈 identifies the context transfer protocol stream.Stream Sequence Number n🙈 since the'U'bit is set to one, the receiver ignores this number. See [SCTP].Payload Protocol Identifier🆔 set to'CXTP'(see [IANA]).User Data📨 contains the context transfer protocol messages.
Heads up 🚨 If a CXTP deployment will never run over the public Internet, and it's known that congestion isn't a problem in the access network, alternative transport protocols MAY be appropriate vehicles for experimentation. One example is piggybacking CXTP messages on top of handover signaling for routing, like what FMIPv6 provides in ICMP [FMIPv6]. Implementations of CXTP MAY support ICMP for those purposes. If you do piggyback like that, an experimental message extension for the protocol CXTP is riding on MUST be designed. Direct deployment on top of a transport protocol for experimental purposes is also possible, but then the researcher MUST be careful to follow good Internet transport protocol engineering practices, including using retransmits with exponential backoff 🧠
3.2. MN-AR Transport 🦋
Okay bestie, the MN-AR interface MUST implement and SHOULD use ICMP to carry the CTAR and CTAA messages 💅. ICMP has zero retransmission support if signaling gets lost, so CXTP brings its own performance tricks for this link ✨. The MN and AR SHOULD keep the number of context data block identifiers in CTAR and CTAA messages small enough that the whole message fits in one packet. ICMP can't fragment above the IP level, so anything bigger is a no-go 🙈.
CXTP uses the Experimental Mobility ICMP type [IANA]. Here's the ICMP message format for CXTP messages 🧚:
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 | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message...
+-+-+-+-+-+-+-+-+-+-+-+- - - -IP Fields:
Source Address: An IP address assigned to the sending interface.Destination Address: An IP address assigned to the receiving interface.Hop Limit:255
ICMP Fields:
Type: Experimental Mobility Type (To be assigned by IANA, for IPv4 and IPv6, see [IANA])Code:0Checksum: The ICMP checksum.Sub-type: The Experimental Mobility ICMP subtype for CXTP, see [IANA].Reserved: Set to zero by the sender and ignored by the receiver.Message: The body of the CTAR or CTAA message.
CTAR messages that want a response but don't get one are retransmitted 🔁. The first retransmission happens after a CXTP_REQUEST_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). CTAR messages should be retransmitted until either a response (which might be an error) has been obtained, or until CXTP_RETRY_MAX seconds after the initial transmission.
MNs SHOULD generate the sequence number in the CTAR message randomly (also making sure that same sequence number hasn't been used in the last 7 seconds) 🎲. For predictive transfer, the MN MUST use the same sequence number in a CTAR message to the nAR as it used for the pAR. An AR MUST ignore the CTAR message if it has already received one with the same sequence number and MN IP address 🙅♀️.
Implementations MAY, for research purposes, try other transport protocols 🧪. Examples are defining a Mobile IPv6 Mobility Header [MIPv6] for use with the FMIPv6 Fast Binding Update [FMIPv6], so routing change and context transfer signaling can be bundled from the MN to the AR, or defining a UDP protocol instead of ICMP. If anyone does this, they should abide carefully by good Internet transport engineering practices, and it should be used for prototype and demonstration purposes only. Deployment on large scale networks should be avoided until the transport characteristics are well understood ⚠️.
4. Error Codes and Constants ✨
Here are the error codes and the constants you need to know, all in one spot 📋.
Error Code Section Value Meaning
------------------------------------------------------------
BAD_CHECKSUM 3.1 0x01 Error code if the
SCTP checksum fails.
Constant Section Default Value Meaning
--------------------------------------------------------------------
CT_REQUEST_RATE 6.3 10 requests/ Maximum number of
sec. CTAR messages before
AR institutes rate
limiting.
CT_MAX_TRANSFER_TIME 3.1 200 ms Maximum amount of time
pAR should wait before
aborting the transfer.
CT_REQUEST_RETRY 3.2 2 seconds Wait interval before
initial retransmit
on MN-AR interface.
CT_RETRY_MAX 3.2 15 seconds Give up retrying
on MN-AR interface.5. Examples and Signaling Flows 🎀
Time for the fun part, where we see how the messages actually flow 🌈.
5.1. Network Controlled, Initiated by pAR, Predictive 🔮
MN nAR pAR
| | |
T | | CT trigger
I | | |
M | |<------- CTD ----------|
E |------- CTAR -------->| |
: | | |
| | |-------- CTDR -------->|
V | | |
| | |5.2. Network Controlled, Initiated by nAR, Reactive ⚡
MN nAR pAR
| | |
T | CT trigger |
I | | |
M | |--------- CT-Req ----->|
E | | |
: | |<------- CTD ----------|
| | | |
V |------- CTAR -------->| |
| |----- CTDR (opt) ----->|
| | |5.3. Mobile Controlled, Predictive New L2 up/Old L2 down 📶
CTAR request to nAR 💌
MN nAR pAR
| | |
new L2 link up | |
| | |
CT trigger | |
| | |
T |------- CTAR -------->| |
I | |-------- CT-Req ------>|
M | | |
E | |<-------- CTD ---------|
: | | |
| | | |
V | | |
| | |Whether the nAR sends the MN a CTAR reject message if CT is not supported is for future study 🔭.
6. Security Considerations 🔥
Real talk, this part is seriously important 😭. Right now, the threats to IP handover in general and context transfer in particular are not widely understood, especially on the MN to AR link, and the mechanisms for countering them aren't well defined. Part of the experimental task in getting CXTP ready for a standards track will be to better characterize threats to context transfer and design specific mechanisms to counter them. This section gives some general guidelines about security, based on discussions among the Design Team and Working Group members 🧠.
6.1. Threats 🚨
The Context Transfer Protocol moves state between access routers. If the MNs aren't authenticated and authorized before they move around the network, masquerading attacks could shift state between ARs and cause network disruptions 👀.
DoS attacks can also be launched from MNs toward the access routers, by requesting multiple context transfers and then disappearing 💀. Finally, a rogue access router could flood mobile nodes with packets, attempt DoS attacks, and issue bogus context transfer requests to surrounding routers 😤.
Consistency and correctness in context transfer depend on interoperable feature context definitions and on how CXTP is used for a particular application. For some considerations about consistency and correctness that apply generally but are described in the context of AAA context transfer, please see [EAP] 📚.
6.2. Access Router Considerations 🛡️
The CXTP inter-router interface relies on IETF standardized security mechanisms to protect traffic between access routers, instead of creating application security mechanisms. IPsec [RFC2401] MUST be supported between access routers 🔐.
To avoid adding latency from setting up a secure channel between the context transfer peers (ARs), the two ARs SHOULD establish such a secure channel in advance ⏩. The two access routers need to engage in a key exchange mechanism such as IKE [RFC2409], establish IPSec SAs, and define the keys, algorithms, and IPSec protocols (such as ESP) in anticipation of any upcoming context transfer. This saves time during handovers that require secure transfer. Such SAs can be maintained and used for all upcoming context transfers between the two ARs. Security should be negotiated prior to the sending of context 🤝.
Access Routers MUST implement IPsec ESP [ESP] in transport mode with non-null encryption and authentication algorithms, to provide per-packet authentication, integrity protection and confidentiality. They MUST also implement the replay protection mechanisms of IPsec 🧱. In those scenarios where IP layer protection is needed, ESP in tunnel mode SHOULD be used. Non-null encryption should be used when using IPSec ESP. Strong security on the inter-router interface is required to protect against attacks by rogue routers, and to ensure confidentiality on the context transfer authorization key in predictive transfer 🔑.
The details of IKE key exchange and other details of the IPsec security associations between routers are to be determined as part of the research phase for finalizing the protocol for standardization. These details must be determined prior to standardization. Other working groups are currently working on general security for routing protocols, so ideally a possible solution for CXTP will be based on that work, to minimize the operational configuration of routers for different protocols 🛠️. Requirements for CXTP will be brought to the appropriate IETF routing protocol security working groups for consideration 💜.
6.3. Mobile Node Considerations 📱🔐
okay bestie, so the CTAR message needs the MN and the AR to both have a shared secret key so they can cook up the authorization token together 🤝. And this is the big rule: validating that token MUST happen before any context transfer or context installation for the MN 🚫. That way an attacker can't sneak in an unauthorized transfer, and that's giving main character security 💅. How the shared key gets set up is out of scope for this spec, so we're not getting into it today 🙈. If both the MN and the AR already know each other's certified public keys, Diffie-Hellman can be used to make a shared secret key [RFC2631] 🦋. If some kind of AAA protocol is already running for network entry, the shared key can come from that protocol instead [PerkCal04] ✨.
Now, if predictive context transfer is happening, the shared key used for the authorization token gets passed between ARs 😬. Sending confidential material like that is risky even when the transfer itself is confidential and authenticated, which is the case for inter-router CXTP 🫣. The more entities that know the key, the more likely it is to get compromised, so we have to be careful 🥺. To lower that risk, the nAR MUST discard the key immediately after using it to validate the authorization token 🗑️. The MN MUST establish a new key with the AR for future CXTP transactions 🔑. The MN and AR SHOULD be careful about using a key that was set up for other things to also authorize context transfer, because that's a bit of a vibe clash 🙃. Setting up a separate key just for context transfer authorization is RECOMMENDED, periodt 💖.
Replay protection on the MN-AR protocol comes from limiting how long context gets kept around ⏳. For predictive transfer, the pAR gets a CTAR message with a sequence number, transfers the context along with the authorization token key, and then drops the context and the authorization token key right when the transfer is done 🧹. For reactive transfer, the nAR gets the CTAR and asks for the context. That request includes the sequence number and the authorization token from the CTAR message, which lets the pAR check whether the transfer is authorized 🔍. Once the transfer has been completed, the pAR drops the context and the authorization token key 👋. The pAR and nAR also ignore any requests that contain the same MN IP address while an outstanding CTAR or CTD message is still unacknowledged and hasn't timed out 🙅♀️. After the key has been dropped, any replay attempt fails, because the authorization token won't validate anymore, so the attacker is literally cooked 💀. One more rule: the AR MUST NOT reuse the key for any MN, including the MN that originally had the key 🚷.
DoS attacks on the MN-AR interface can be limited if the AR rate limits how many CTAR messages it processes 🛑. The AR SHOULD limit the number of CTAR messages to the CT_REQUEST_RATE. If requests go over that rate, the AR SHOULD randomly drop messages until the rate settles down 🎲. The actual rate SHOULD be configured on the AR to match the maximum number of handovers that the access network is expected to support 📶.
7. Acknowledgements & Contributors 💜
this document is the result of a design team formed by the chairs of the SeaMoby working group 👯♀️. The team included John Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins 🌸.
Basavaraj Patil, Pekka Savola, and Antti Tuominen contributed to the Context Transfer Protocol review 🫶.
The working group chairs are Pat Calhoun and James Kempf, and their comments were super helpful in making this specification 👑.
The authors would also like to thank Julien Bournelle, Vijay Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf Motiwala, Phil Neumiller, Hesham Soliman, and Lucian Suciu for their help and suggestions with this document 🙌.
8. References 📚
8.1. Normative References
- [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
- [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
- [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
- [SCTP] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
- [PR-SCTP] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. Conrad, "Stream Control Transmission Protocol (SCTP) Partial Reliability Extension", RFC 3758, May 2004.
- [IANA] Kempf, J., "Instructions for Seamoby and Experimental Mobility Protocol IANA Allocations", RFC 4065, July 2005.
8.2. Informative References
- [FHCT] R. Koodli and C. E. Perkins, "Fast Handovers and Context Transfers", ACM Computing Communication Review, volume 31, number 5, October 2001.
- [TEXT] M. Nakhjiri, "A time efficient context transfer method with Selective reliability for seamless IP mobility", IEEE VTC-2003-Fall, VTC 2003 Proceedings, Vol.3, Oct. 2003.
- [FMIPv6] Koodli, R., Ed., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
- [LLMIP] K. El Malki et al., "Low Latency Handoffs in Mobile IPv4", Work in Progress.
- [RFC3374] Kempf, J., "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002.
- [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
- [TERM] Manner, J. and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004.
- [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
- [PerkCal04] Perkins, C. and P. Calhoun, "Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4", RFC 3957, March 2005.
- [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
- [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
- [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
- [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
- [RFC3095] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, July 2001.
- [BT] IEEE, "IEEE Standard for information technology - Telecommunication and information exchange between systems - LAN/MAN - Part 15.1: Wireless Medium Access Control (MAC) and Physical Layer (PHY) specifications for Wireless Personal Area Networks (WPANs)", IEEE Standard 802.15.1, 2002.
- [EAP] Aboba, B., Simon, D., Arkko, J., Eron, P., and H. Levokowetz, "Extensible Authentication Protocol (EAP) Key Management Framework", Work in Progress.
Appendix A. Timing and Trigger Considerations ⏰
basic Mobile IP handover signaling can cause disruptions to the services running on top of Mobile IP 😩. Those disruptions can add latencies that practically rule out certain types of services. Mobile IP latency and packet loss get optimized through several alternative procedures, like Fast Mobile IP [FMIPv6] and Low Latency Mobile IP [LLMIP] 🚀.
Feature re-establishment through context transfer should contribute zero (optimally) or minimal extra disruption of services in conjunction with handovers ✨. That means the timing of context transfer SHOULD be carefully aligned with basic Mobile IP handover events, and with optimized Mobile IP handover signaling mechanisms, as those protocols become available 🎯.
Furthermore, some of those optimized mobile IP handover mechanisms may provide more flexibility in choosing the timing and ordering for the transfer of various context information 🌈.
Appendix B. Multicast Listener Context Transfer ✨
okay so bestie, back in the day there were some credible proposals in the Seamoby Working Group (and elsewhere) to use context transfer to speed up handover 🚀. The stuff they wanted to move around was authentication, authorization, and accounting context, distributed firewall context, PPP context, and header compression context. But the Working Group wasn't chartered to write context profile definitions for specific applications, so none of those docs got accepted as Working Group items 😭. Right now, work on a context profile definition for RFC 3095 header compression context [RFC3095] is still going and isn't finished yet 🛠️. People also say several commercial wireless products use non-standard, non-interoperable context transfer protocols, but none of them is widely deployed yet 🙈.
So no cap, it's kind of hard to point to a solid example of context transfer being a commercially viable, widely deployable, interoperable win for wireless networks 💅. That's one reason CXTP is being proposed as an Experimental protocol and not Standards Track 🧪. Still, it's valuable to have a simple example of how handover could benefit from CXTP ✨. The example here is transferring IPv6 MLD state [RFC2710] 🎀. MLD state is a seriously good example because every IPv6 node has to run at least one MLD messaging sequence on the wireless link to make itself an MLD listener before it does router discovery [RFC2461] or duplicate address detection [RFC2462], or before it sends or receives any application-specific traffic (including Mobile IP handover signaling, if there is any) 💀. The node has to subscribe to the Solicited Node Multicast Address the second it comes up on the link 🧚. Any application-specific multicast addresses have to get re-established too 🌸. Context transfer can seriously speed up re-establishing multicast state, because the nAR can initialize MLD for a node that just finished handover with zero MLD signaling on the new wireless link 🫶.
Here's a rough estimate of how much handover time you could save 🍓. An MLD message is 24 octets, and you have to add headers on top, because there's no header compression on the new link 🔥. The IPv6 header is 40 octets, and a required Router Alert Hop-by-Hop option is 8 octets including padding 📦. So the total MLD message size is 72 octets per subscribed multicast address 🧮. RFC 2710 recommends that nodes send 2 to 3 MLD Report messages per address subscription, since the Report message is unacknowledged 📣. Assuming 2 MLD messages for a subscribed address, the MN would need to send 144 octets per address subscription 💜. If MLD messages go out for both the All Nodes Multicast address and the Solicited Node Multicast address for the node's link local address, that's a total of 288 octets when the node hands over to the new link 😩.
Heads up: some IPv6 implementations are optimized so they don't send an MLD message for the All Nodes Multicast Address, since the router can infer that at least one node is on the link (itself) when it comes up and always will be 🙈. For this calculation, though, we assume the IPv6 implementation is conformant and that the message is sent 💅.
The time MLD signaling takes depends on the per node available wireless link bandwidth 📶. Some representative numbers come from assuming bandwidths of 20 kbps or 100 kbps 🔢. At those 2 bit rates, skipping the pre-router discovery messages saves 115 msec. and 23 msec., respectively ⏱️. If any application-specific multicast addresses are subscribed, the time saved could be even more substantial 🌈.
Now, this example might seem a bit contrived 🤔. MLD isn't used in the 3G cellular protocols, and wireless local area network protocols usually have enough bandwidth if radio propagation conditions are optimal 📡. So sending one MLD message might not feel like a performance burden at all 🤷♀️. An example of a wireless protocol where MLD context transfer might be useful is IEEE 802.15.1 (Bluetooth)[BT] 🦋. IEEE 802.15.1 has two IP "profiles": one with PPP and one without 🎧. The profile without PPP would use MLD 🙌. The 802.15.1 protocol has a maximum bandwidth of about 800 kbps, shared between all nodes on the link, so a host on a moderately loaded 802.15.1 access point could experience the kind of bandwidth described in the previous paragraph 😭.
Also, 802.15.1 handover times usually run upwards of a second or more, because the host has to resynchronize its frequency hopping pattern with the access point 🐌. So anything the IP layer could do to ease further delay would be a win 👑.
The context-specific data field for MLD context transfer, included in the CXTP Context Data Block message for a single IPv6 multicast address, has this format 🗂️:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Subnet Prefix on nAR Wireless Interface +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Subscribed IPv6 Multicast Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Subnet Prefix on a nAR Wireless Interface field holds a subnet prefix that identifies the interface where multicast routing should be established 🛣️. The Subscribed IPv6 Multicast Address field holds the multicast address that multicast routing should be established for 💖.
The pAR sends one MLD context block per subscribed IPv6 multicast address 📬.
No changes are required in the MLD state machine 🙌.
When a CXTP Context Data Block for MLD comes in, the state machine takes these actions 🎬:
- If the router is in the No Listeners present state on the wireless interface where the Subnet Prefix field in the Context Data Block is advertised, it moves into the Listeners Present state for the Subscribed IPv6 Multicast Address field in the Context Data Block. This transition is exactly the same as if the router had received a Report message ✨.
- If the router is in the Listeners present state on that interface, it stays in that state but restarts the timer, as if it had received a Report message 🔄.
If more than one MLD router is on the link, a router that receives an MLD Context Data Block SHOULD send the block to the other routers on the link 🗣️. If wireless bandwidth isn't an issue, the router MAY instead send a proxy MLD Report message on the wireless interface that advertises the Subnet Prefix field from the Context Data Block 📣. Since MLD routers don't keep track of which nodes are listening to multicast addresses (only whether a particular multicast address is being listened to), proxying the subscription should cause no difficulty 💅🎀.
Authors' Addresses 🖊️
Rajeev Koodli
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
EMail: rajeev.koodli@nokia.com
John Loughney
Nokia
Itdmerenkatu 11-13
00180 Espoo
Finland
EMail: john.loughney@nokia.com
Madjid F. Nakhjiri
Motorola Labs
1301 East Algonquin Rd., Room 2240
Schaumburg, IL, 60196
USA
EMail: madjid.nakhjiri@motorola.com
Charles E. Perkins
Nokia Research Center
313 Fairchild Drive
Mountain View, California 94043
USA
EMail: charles.perkins@.nokia.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
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 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.
Acknowledgement 🫶
Funding for the RFC Editor function is currently provided by the Internet Society. 🌸
📦 where this page comes from
- ietf: rfc4067 2005-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms