From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4067.txt | 1851 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1851 insertions(+) create mode 100644 doc/rfc/rfc4067.txt (limited to 'doc/rfc/rfc4067.txt') diff --git a/doc/rfc/rfc4067.txt b/doc/rfc/rfc4067.txt new file mode 100644 index 0000000..73504ad --- /dev/null +++ b/doc/rfc/rfc4067.txt @@ -0,0 +1,1851 @@ + + + + + + +Network Working Group J. Loughney, Ed. +Request for Comments: 4067 M. Nakhjiri +Category: Experimental C. Perkins + R. Koodli + July 2005 + + + Context Transfer Protocol (CXTP) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + This document presents the Context Transfer Protocol (CXTP) that + enables authorized context transfers. Context transfers allow better + support for node based mobility so that the applications running on + mobile nodes can operate with minimal disruption. Key objectives are + to reduce latency and packet losses, and to avoid the re-initiation + of signaling to and from the mobile node. + +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 + + + +Loughney, et al. Experimental [Page 1] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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 . . . . . . . . . 28 + +1. Introduction + + This document describes the Context Transfer Protocol, which + provides: + + * Representation for feature contexts. + + * Messages to initiate and authorize context transfer, and notify + a mobile node of the status of the transfer. + + * Messages for transferring contexts prior to, during and after + handovers. + + The proposed protocol is designed to work in conjunction with other + protocols in order to provide seamless mobility. The protocol + 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] defines the + following main reasons why Context Transfer procedures may be useful + in IP networks. + + 1) As mentioned in the introduction, the primary motivation is to + quickly re-establish context transfer-candidate services without + requiring the mobile host to explicitly perform all protocol flows + for those services from scratch. An example of such a service is + included in Appendix B of this document. + + 2) An additional motivation is to provide an interoperable solution + that supports various Layer 2 radio access technologies. + + + + + + +Loughney, et al. Experimental [Page 2] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +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]. + +1.3. Abbreviations Used in the Document + + Mobility Related Terminology [TERM] defines basic mobility + terminology. In addition to the material in that document, we use + the following terms and abbreviations in this document. + + CXTP Context Transfer Protocol + + DoS Denial-of-Service + + FPT Feature Profile Types + + PCTD Predictive Context Transfer Data + +2. Protocol Overview + + This section provides a protocol overview. A context transfer can be + either started by a request from the mobile node ("mobile + controlled") or at the initiative of the new or the previous access + router ("network controlled"). + + * The mobile node (MN) sends the CT Activate Request (CTAR) to + its current access router (AR) immediately prior to handover + when it is possible to initiate a predictive context transfer. + In any case, the MN always sends the CTAR message to the new AR + (nAR). If the contexts are already present, nAR verifies the + authorization token present in CTAR with its own computation + using the parameters supplied by the previous access router + (pAR), and subsequently activates those contexts. If the + contexts are not present, nAR requests pAR to supply them using + the Context Transfer Request message, in which it supplies the + authorization token present in CTAR. + + * Either nAR or pAR may request or start (respectively) context + transfer based on internal or network triggers (see Appendix + A). + + The Context Transfer protocol typically operates between a source + node and a target node. In the future, there may be multiple target + nodes involved; the protocol described here would work with multiple + target nodes. For simplicity, we describe the protocol assuming a + single receiver or target node. + + + +Loughney, et al. Experimental [Page 3] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + Typically, the source node is an MN's pAR and the target node is an + MN's nAR. Context Transfer takes place when an event, such as a + handover, takes place. We call such an event a Context Transfer + Trigger. In response to such a trigger, the pAR may transfer the + contexts; the nAR may request contexts; and the MN may send a message + to the routers to transfer contexts. Such a trigger must be capable + of providing the necessary information (such as the MN's IP address) + by which the contexts are identified. In addition, the trigger must + be able to provide the IP addresses of the access routers, and the + authorization to transfer context. + + Context transfer protocol messages use Feature Profile Types (FPTs) + that identify the way that data is organized for the particular + feature contexts. The FPTs are registered in a number space (with + IANA Type Numbers) that allows a node to unambiguously determine the + type of context and the context parameters present in the protocol + messages. Contexts are transferred by laying out the appropriate + feature data within Context Data Blocks according to the format in + Section 2.3, as well as any IP addresses necessary to associate the + contexts to a particular MN. The context transfer initiation + messages contain parameters that identify the source and target + nodes, the desired list of feature contexts, and IP addresses to + identify the contexts. The messages that request the transfer of + context data also contain an appropriate token to authorize the + context transfer. + + Performing a context transfer in advance of the MN attaching to nAR + can increase handover performance. For this to take place, certain + conditions must be met. For example, pAR must have sufficient time + and knowledge of the impending handover. This is feasible, for + instance, in Mobile IP fast handovers [LLMIP][FMIPv6]. Additionally, + many cellular networks have mechanisms to detect handovers in + advance. However, when the advance knowledge of impending handover + is not available, or if a mechanism such as fast handover fails, + retrieving feature contexts after the MN attaches to nAR is the only + available means for context transfer. Performing context transfer + after handover might still be better than having to re-establish all + the contexts from scratch, as shown in [FHCT] and [TEXT]. Finally, + some contexts may simply need to be transferred during handover + signaling. For instance, 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 been terminated. + +2.1. Context Transfer Scenarios + + The Previous Access Router transfers feature contexts under two + general scenarios. + + + + +Loughney, et al. Experimental [Page 4] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +2.1.1. Scenario 1 + + The pAR receives a Context Transfer Activate Request (CTAR) message + from the MN whose feature contexts are to be transferred, or it + receives an internally generated trigger (e.g., a link-layer trigger + on the interface to which the MN is connected). The CTAR message, + described in Section 2.5, provides the IP address of nAR, the IP + address of MN on pAR, the list of feature contexts to be transferred + (by default requesting all contexts to be transferred), and a token + authorizing the transfer. In response to a CT-Activate Request + message or to the CT trigger, pAR predictively transmits a Context + Transfer Data (CTD) message that contains feature contexts. This + message, described in Section 2.5, contains the MN's previous IP + address. It also contains parameters for nAR to compute an + authorization token to verify the MN's token that is present in the + CTAR message. Recall that the MN always sends a CTAR message to nAR + regardless of whether it sent the CTAR message to pAR because there + is no means for the MN to ascertain that context transfer has + reliably taken place. By always sending the CTAR message to nAR, the + Context Transfer Request (see below) can be sent to pAR if necessary. + + When context transfer takes place without the nAR requesting it, nAR + requires MN to present its authorization token. Doing this locally + at nAR when the MN attaches to it improves performance and increases + security, since the contexts are likely to already be present. Token + verification takes place at the router possessing the contexts. + +2.1.2. Scenario 2 + + In the second scenario, pAR receives a Context Transfer Request (CT- + Req) message from nAR, as described in Section 2.5. The nAR itself + generates the CT-Req message as a result of receiving the CTAR + message, or alternatively, from receiving a context transfer trigger. + In the CT-Req message, nAR supplies the MN's previous IP address, the + FPTs for the feature contexts to be transferred, the sequence number + from the CTAR, and the authorization token from the CTAR. In + response to a CT-Req message, pAR transmits a Context Transfer Data + (CTD) message that includes the MN's previous IP address and feature + contexts. When it receives a corresponding CTD message, nAR may + generate a CTD Reply (CTDR) message to report the status of + processing the received contexts. The nAR installs the contexts once + it has received them from the pAR. + +2.2. Context Transfer Message Format + + A CXTP message consists of a message-specific header and one or more + data blocks. Data blocks may be bundled together to ensure a more + efficient transfer. On the inter-AR interface, SCTP is used so + + + +Loughney, et al. Experimental [Page 5] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + fragmentation should not be a problem. On the MN-AR interface, the + total packet size, including transport protocol and IP protocol + headers, SHOULD be less than the path MTU to avoid packet + fragmentation. Each message contains a 3 bit version number field in + the low order octet, along with the 5 bit message type code. This + specification only applies to Version 1 of the protocol, and the + therefore version number field MUST be set to 0x1. If future + revisions of the protocol make binary incompatible changes, the + version number MUST be incremented. + +2.3. Context Types + + Contexts are identified by the FPT code, which is a 16 bit unsigned + integer. The meaning of each context type is determined by a + specification document. The context type numbers are to be tabulated + in a registry maintained by IANA [IANA] and handled according to the + message specifications in this document. The instantiation of each + context by nAR is determined by the messages in this document along + with the specification associated with the particular context type. + The following diagram illustrates the general format for CXTP + messages: + + +----------------------+ + | Message Header | + +----------------------+ + | CXTP Data 1 | + +----------------------+ + | CXTP Data 2 | + +----------------------+ + | ... | + + Each context type specification contains the following details: + + - Number, size (in bits), and ordering of data fields in the + state variable vector that embodies the context. + + - Default values (if any) for each individual datum of the + context state vector. + + - Procedures and requirements for creating a context at a new + access router, given the data transferred from a previous + access router and formatted according to the ordering rules and + data field sizes presented in the specification. + + - If possible, status codes for success or failure related to the + context transfer. For instance, a QoS context transfer might + have different status codes depending on which elements of the + context data failed to be instantiated at nAR. + + + +Loughney, et al. Experimental [Page 6] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +2.4. Context Data Block (CDB) + + The Context Data Block (CDB) is used both for request and response + operations. When a request is constructed, only the first 4 octets + are typically necessary (See CTAR below). When used for transferring + the actual feature context itself, the context data is present, and + the presence vector is sometimes present. + + 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. + + The Feature Profile Type (FPT) code indicates the type of data in the + data field. Typically, this will be context data, but it could be an + error indication. The 'P' bit specifies whether the "presence + vector" is used. When the presence vector is in use, it is + interpreted to indicate whether particular data fields are present + (and contain non-default values). The ordering of the bits in the + presence vector is the same as the ordering of the data fields + according to the context type specification, one bit per data field + regardless of the size of the data field. The Length field indicates + the size of the CDB in 8 octet words, including the first 4 octets + starting from FPT. + + + +Loughney, et al. Experimental [Page 7] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + Notice that the length of the context data block is defined by the + sum of the lengths of each data field specified by the context type + specification, plus 4 octets if the 'P' bit is set, minus the + accumulated size of all the context data that is implicitly given as + a default value. + +2.5. Messages + + In this section, the CXTP messages are defined. The MN for which + context transfer protocol operations are undertaken is always + identified by its previous IP access address. Only one context + transfer operation per MN may be in progress at a time so that the + CTDR message unambiguously identifies which CTD message is + acknowledged simply by including the MN's identifying previous IP + address. The 'V' flag indicates whether the IP addresses are IPv4 or + IPv6. + +2.5.1. Context Transfer Activate Request (CTAR) Message + + This message is always sent by the MN to the nAR to request a context + transfer. Even when the MN does not know if contexts need to be + transferred, the MN sends the CTAR message. If an acknowledgement + for this message is needed, the MN sets the 'A' flag to 1; otherwise + the MN does not expect an acknowledgement. This message may include + a list of FPTs that require transfer. + + The MN may also send this message to pAR while still connected to + pAR. In this case, the MN includes the nAR's IP address; otherwise, + if the message is sent to nAR, the pAR address is sent. The MN MUST + set the sequence number to the same value as was set for the message + sent on both pAR and nAR so pAR can determine whether to use a cached + message. + + + + + + + + + + + + + + + + + + + +Loughney, et al. Experimental [Page 8] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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). + + + + + + + +Loughney, et al. Experimental [Page 9] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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, all contexts for the MN are + requested. + + The Authorization Token is calculated as: + + 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 a + concatenation of all the Context Data Blocks specifying the contexts + to be transferred that are included in the CTAR message. + +2.5.2. Context Transfer Activate Acknowledge (CTAA) Message + + This is an informative message sent by the receiver of CTAR to the MN + to acknowledge a CTAR message. Acknowledgement is optional, + depending on whether the MN requested it. This message may include a + list of FPTs that were not successfully transferred. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | ........ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vers. Version number of CXTP protocol = 0x1 + + Type CTAA = 0x2 + + 'V' flag When set to '0', IPv6 addresses. + When set to '1', IPv4 addresses. + + Reserved Set to zero by the sender and ignored by + the receiver. + + + +Loughney, et al. Experimental [Page 10] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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. + + FPT 16 bit unsigned integer, listing the Feature + Profile Type that was not successfully + transferred. + + Status Code An octet, containing failure reason. + + ........ more FPTs and status codes as necessary + +2.5.3. Context Transfer Data (CTD) Message + + Sent by pAR to nAR, and includes feature data (CXTP data). This + message handles both predictive and normal CT. An acknowledgement + flag, 'A', included in this message indicates whether a reply is + required by pAR. + + 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 ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ........ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vers. Version number of CXTP protocol = 0x1 + + Type CTD = 0x3 (Context Transfer Data) + PCTD = 0x4 (Predictive Context Transfer + Data) + + + + + +Loughney, et al. Experimental [Page 11] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 'V' flag When set to '0', IPv6 addresses. + When set to '1', IPv4 addresses. + + 'A' bit When set, the pAR requests an + acknowledgement. + + Length Message length in units of octets. + + Elapsed Time The number of milliseconds since the + transmission of the first CTD message for + this MN. + + MN's Previous IP Address Field contains either: + IPv4 [RFC791] Address, 4 octets, or + IPv6 [RFC3513] Address, 16 octets. + + Algorithm Algorithm for carrying out the computation + of the MN Authorization Token. Currently + only 1 algorithm is defined, HMAC_SHA1 = 1. + + Key Length Length of key, in octets. + + Key Shared key between MN and AR for CXTP. + + Context Data Block The Context Data Block (see Section 2.4). + + When CTD is sent predictively, the supplied parameters (including the + algorithm, key length, and the key itself) allow the nAR to compute a + token locally and verify it against the token present in the CTAR + message. This material is also sent if the pAR receives a CTD + message with a null Authorization Token, indicating that the CT-Req + message was sent before the nAR received the CTAR message. CTD MUST + be protected by IPsec; see Section 6. + + As described previously, the algorithm for carrying out the + computation of the MN Authorization Token is HMAC_SHA1. The token + authentication calculation algorithm 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 until a CTDR message for + the MN's previous IP address has been received from the pAR, + indicating that the context transfer was successful, or until + CT_MAX_HANDOVER_TIME expires. The nAR MAY send a CT-Req message + containing the same sequence number if the predictive CTD message + failed to arrive or the context was corrupted. In this case, the nAR + + + + + + +Loughney, et al. Experimental [Page 12] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + sends a CT-Req message with a matching sequence number and pAR can + resend the context. + +2.5.4. Context Transfer Data Reply (CTDR) Message + + This message is sent by nAR to pAR depending on the value of the 'A' + flag in CTD, indicating success or failure. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ........ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vers. Version number of CXTP protocol = 0x1 + + Type CTDR = 0x5 (Context Transfer Data) + + 'V' flag When set to '0', IPv6 addresses. + When set to '1', IPv4 addresses. + + 'S' bit When set to one, this bit indicates + that all feature contexts sent in CTD + or PCTD were received successfully. + + Reserved Set to zero by the sender and 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. + + FPT 16 bit unsigned integer, listing the Feature + Profile Type that is being acknowledged. + + Status Code A context-specific return value, + zero for success, nonzero when 'S' is + not set to one. + + + + + +Loughney, et al. Experimental [Page 13] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +2.5.5. Context Transfer Cancel (CTC) Message + + If transferring a context cannot be completed in a timely fashion, + then nAR may send CTC to pAR to cancel an ongoing CT process. + + 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 ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vers. Version number of CXTP protocol = 0x1 + + Type CTC = 0x6 (Context Transfer Cancel) + + Length Message length in units of octets. + + 'V' flag When set to '0', IPv6 addresses. + When set to '1', IPv4 addresses. + + Reserved Set to zero by the sender and ignored by + the receiver. + + MN's Previous IP Address Field contains either: + IPv4 [RFC791] Address, 4 octets, or + IPv6 [RFC3513] Address, 16 octets. + +2.5.6. Context Transfer Request (CT-Req) Message + + Sent by nAR to pAR to request the start of context transfer. This + message is sent as a response to a CTAR message. The fields + following the Previous IP address of the MN are included verbatim + from the CTAR message. + + + + + + + + + + + + + + + + +Loughney, et al. Experimental [Page 14] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ........ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Vers. Version number of CXTP protocol = 0x1 + + Type CTREQ = 0x7 (Context Transfer Request) + + 'V' flag When set to '0', IPv6 addresses. + When set to '1', IPv4 addresses. + + Reserved Set to zero by the sender and 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. + + Sequence Number Copied from the CTAR message, allows the + pAR to distinguish requests from previously + sent context. + + MN's Authorization Token + An unforgeable value calculated as + discussed in Section 2.5.1. This + authorizes the receiver of CTAR to + perform context transfer. Copied from + CTAR. + + Context Data Request Block + A request block for context data; see + Section 2.4. + + + + + +Loughney, et al. Experimental [Page 15] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + The sequence number is used by pAR to correlate a request for + previously transmitted context. In predictive transfer, if the MN + sends CTAR prior to handover, pAR pushes context to nAR using PCTD. + If the CTD fails, the nAR will send a CT-Req with the same sequence + number, enabling the pAR to determine 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 + information necessary to calculate the Authorization Token without + having processed a CT-Req message. For reactive transfer, if the nAR + receives a context transfer trigger but has not yet received the CTAR + message with the authorization token, the Authorization Token field + in CT-Req is set to zero. The pAR interprets this as an indication + to include the keying material and other information necessary to + calculate the Authorization Token, and includes this material into + the CTD message as if the message were being sent due to predictive + transfer. This provides nAR with the information it needs to + calculate the authorization token when the MN sends CTAR. + +3. Transport + +3.1. Inter-Router Transport + + Since most types of access networks in which CXTP might be useful are + not today deployed or, if they have been deployed, have not been + extensively measured, it is difficult to know whether congestion will + be a problem for CXTP. Part of the research task in preparing CXTP + for consideration as a possible candidate for standardization is to + quantify this issue. However, to avoid potential interference with + production applications should a prototype CXTP deployment involve + running over the public Internet, it seems prudent to recommend a + default transport protocol that accommodates congestion. In + addition, since the feature context information has a definite + lifetime, the transport protocol must accommodate flexible + retransmission, so stale contexts that are held up by congestion are + dropped. Finally, because the amount of context data can be + arbitrarily large, the transport protocol should not be limited to a + single packet or require implementing a custom fragmentation + protocol. + + These considerations argue that 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 contemplated. SCTP supports congestion control, + fragmentation, and partial retransmission based on a programmable + retransmission timer. SCTP also supports many advanced and complex + + + +Loughney, et al. Experimental [Page 16] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + features, such as multiple streams and multiple IP addresses for + failover that are not necessary for experimental implementation and + prototype deployment of CXTP. 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 contains an + appropriate context transfer protocol message defined in this + document. The messages sent using 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. 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 provides simplicity. + The use of multiple streams to prevent head-of-line blocking is for + future study. Unordered delivery allows the receiver to not block + for in-sequence delivery of messages that belong to different MNs. + The Payload Protocol Identifier in the SCTP header is 'CXTP'. + Inter-router CXTP uses the Seamoby SCTP port [IANA]. + + Timeliness of the context transfer information SHOULD be accommodated + by setting the SCTP maximum retransmission value to + CT_MAX_TRANSFER_TIME to accommodate the maximum acceptable handover + delay time. The AR SHOULD be configured with CT_MAX_TRANSFER_TIME to + accommodate the particular wireless link technology and local + wireless propagation conditions. SCTP message bundling SHOULD be + turned off to reduce an extra delay in sending messages. Within + CXTP, the nAR SHOULD estimate the retransmit timer from the receipt + of the first fragment of a CXTP message and 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 modifies 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; + that is, in PR-SCTP, if the lifetime expires and the data chunk has + not been acknowledged, the transmitter stops retransmitting, whereas + in the base protocol the data would be retransmitted until + acknowledged or the connection timed out. + + + + + + + + + + +Loughney, et al. Experimental [Page 17] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + The format of Payload Data Chunk taken from [SCTP] is shown in the + following diagram. + + 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) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + 'U' bit The Unordered bit. 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. + + If a CXTP deployment will never run over the public Internet, and it + is known that congestion is not a problem in the access network, + alternative transport protocols MAY be appropriate vehicles for + experimentation. For example, piggybacking CXTP messages on top of + handover signaling for routing, such as provided by FMIPv6 in ICMP + [FMIPv6]. Implementations of CXTP MAY support ICMP for such + purposes. If such piggybacking is used, an experimental message + extension for the protocol on which CXTP is piggybacking MUST be + designed. Direct deployment on top of a transport protocol for + experimental purposes is also possible. In this case, the researcher + + + +Loughney, et al. Experimental [Page 18] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + MUST be careful to accommodate good Internet transport protocol + engineering practices, including using retransmits with exponential + backoff. + +3.2. MN-AR Transport + + The MN-AR interface MUST implement and SHOULD use ICMP to transport + the CTAR and CTAA messages. Because ICMP contains no provisions for + retransmitting packets if signaling is lost, the CXTP protocol + incorporates provisions for improving transport performance on the + MN-AR interface. The MN and AR SHOULD limit the number of context + data block identifiers included in the CTAR and CTAA messages so that + the message will fit into a single packet, because ICMP has no + provision for fragmentation above the IP level. CXTP uses the + Experimental Mobility ICMP type [IANA]. The ICMP message format for + CXTP messages is as follows: + + 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 0 + + Checksum The ICMP checksum. + + + + + +Loughney, et al. Experimental [Page 19] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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 for which a response is requested but fail to elicit + a response are retransmitted. The initial retransmission occurs + 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 ensuring that the same sequence number has not been + used in the last 7 seconds), and, for predictive transfer, MUST + use the same sequence number in a CTAR message to the nAR as 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 the definition of a Mobile IPv6 Mobility + Header [MIPv6] for use with the FMIPv6 Fast Binding Update + [FMIPv6] to allow bundling of both routing change and context + transfer signaling from the MN to AR, or definition of a UDP + protocol instead of ICMP. If such implementations are done, they + should abide carefully by good Internet transport engineering + practices and 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 + + Error Code Section Value Meaning + ------------------------------------------------------------ + + BAD_CHECKSUM 3.1 0x01 Error code if the + SCTP checksum fails. + + + + + + + + + + +Loughney, et al. Experimental [Page 20] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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 + +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) ----->| + | | | + + + + +Loughney, et al. Experimental [Page 21] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +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 + + At this time, the threats to IP handover in general and context + transfer in particular are not widely understood, particularly on the + MN to AR link, and mechanisms for countering them are not well + defined. Part of the experimental task in preparing CXTP for + eventual standards track will be to better characterize threats to + context transfer and design specific mechanisms to counter them. + This section provides some general guidelines about security based on + discussions among the Design Team and Working Group members. + +6.1. Threats + + The Context Transfer Protocol transfers state between access routers. + If the MNs are not authenticated and authorized before moving on the + network, there is a potential for masquerading attacks to shift state + between ARs, causing network disruptions. + + Additionally, DoS attacks can be launched from MNs towards the access + routers by requesting multiple context transfers and then by + disappearing. Finally, a rogue access router could flood mobile + nodes with packets, attempt DoS attacks, and issue bogus context + transfer requests to surrounding routers. + + + + + + +Loughney, et al. Experimental [Page 22] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + Consistency and correctness in context transfer depend on + interoperable feature context definitions and how CXTP is utilized + for a particular application. For some considerations regarding + consistency and correctness that have general applicability but are + articulated 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 for protecting traffic between access routers, as opposed + to creating application security mechanisms. IPsec [RFC2401] MUST be + supported between access routers. + + To avoid the introduction of additional latency due to the need for + establishing 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 will save 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, and + MUST 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 + predicative 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 associated with 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. Ideally, a possible solution + for CXTP will be based on this 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. + + + + + + +Loughney, et al. Experimental [Page 23] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +6.3. Mobile Node Considerations + + The CTAR message requires the MN and AR to possess a shared secret + key to calculate the authorization token. Validation of this token + MUST precede context transfer or installation of context for the MN, + removing the risk that an attacker could cause an unauthorized + transfer. How the shared key is established is out of scope of this + specification. If both the MN and AR know certified public keys of + the other party, Diffie-Hellman can be used to generate a shared + secret key [RFC2631]. If an AAA protocol of some sort is run for + network entry, the shared key can be established using that protocol + [PerkCal04]. + + If predictive context transfer is used, the shared key for + calculating the authorization token is transferred between ARs. A + transfer of confidential material of this sort poses certain security + risks, even if the actual transfer itself is confidential and + authenticated, as is the case for inter-router CXTP. The more + entities know the key, the more likely a compromise may occur. To + mitigate this risk, 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 + exercise care in using a key established for other purposes for also + authorizing context transfer. The establishment of a separate key + for context transfer authorization is RECOMMENDED. + + Replay protection on the MN-AR protocol is provided by limiting the + time period in which context is maintained. For predictive transfer, + the pAR receives 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 immediately upon completion + of the transfer. For reactive transfer, the nAR receives the CTAR, + requests the context that includes the sequence number and + authorization token from the CTAR message that allows the pAR to + check whether the transfer is authorized. The pAR drops the context + and authorization token key after the transfer has been completed. + The pAR and nAR ignore any requests containing the same MN IP address + if an outstanding CTAR or CTD message is unacknowledged and has not + timed out. After the key has been dropped, any attempt at replay + will fail because the authorization token will fail to validate. The + AR MUST NOT reuse the key for any MN, including the MN that + originally possessed the key. + + DoS attacks on the MN-AR interface can be limited by having the AR + rate limit the number of CTAR messages it processes. The AR SHOULD + limit the number of CTAR messages to the CT_REQUEST_RATE. If the + request exceeds this rate, the AR SHOULD randomly drop messages until + the rate is established. The actual rate SHOULD be configured on the + + + +Loughney, et al. Experimental [Page 24] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + 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, whose + comments have been very helpful in the creation of 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. + + + +Loughney, et al. Experimental [Page 25] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + [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. + + + + +Loughney, et al. Experimental [Page 26] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + [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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney, et al. Experimental [Page 27] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +Appendix A. Timing and Trigger Considerations + + Basic Mobile IP handover signaling can introduce disruptions to the + services running on top of Mobile IP, which may introduce unwanted + latencies that practically prohibit its use for certain types of + services. Mobile IP latency and packet loss are optimized through + several alternative procedures, such as 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. This means that 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 + + In the past, credible proposals have been made in the Seamoby Working + Group and elsewhere for using context transfer to the speed of + handover of authentication, authorization, and accounting context, + distributed firewall context, PPP context, and header compression + context. Because the Working Group was not chartered to develop + context profile definitions for specific applications, none of the + documents submitted to Seamoby were accepted as Working Group items. + At this time, work to develop a context profile definition for RFC + 3095 header compression context [RFC3095] and to characterize the + performance gains obtainable by using header compression continues, + but is not yet complete. In addition, there are several commercial + wireless products that reportedly use non-standard, non-interoperable + context transfer protocols, though none is as yet widely deployed. + + As a consequence, it is difficult at this time to point to a solid + example of how context transfer could result in a commercially + viable, widely deployable, interoperable benefit for wireless + networks. This is one reason why CXTP is being proposed as an + Experimental protocol, rather than Standards Track. Nevertheless, it + seems valuable to have a simple example that shows how handover could + benefit from using CXTP. The example we consider here is + transferring IPv6 MLD state [RFC2710]. MLD state is a particularly + good example because every IPv6 node must perform at least one MLD + messaging sequence on the wireless link to establish itself as an MLD + listener prior to performing router discovery [RFC2461] or duplicate + address detection [RFC2462] or before sending/receiving any + + + +Loughney, et al. Experimental [Page 28] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + application-specific traffic (including Mobile IP handover signaling, + if any). The node must subscribe to the Solicited Node Multicast + Address as soon as it comes up on the link. Any application-specific + multicast addresses must be re-established as well. Context transfer + can significantly speed up re-establishing multicast state by + allowing the nAR to initialize MLD for a node that just completed + handover without any MLD signaling on the new wireless link. The + same approach could be used for transferring multicast context in + IPv4. + + An approximate quantitative estimate for the amount of savings in + handover time can be obtained as follows: MLD messages are 24 octets, + to which the headers must be added, because there is no header + compression on the new link, where the IPv6 header is 40 octets, and + a required Router Alert Hop-by-Hop option is 8 octets including + padding. 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 sent for a subscribed + address, the MN would need to send 144 octets per address + subscription. If MLD messages are sent for both the All Nodes + Multicast address and the Solicited Node Multicast address for the + node's link local address, a total of 288 octets are required when + the node hands over to the new link. Note that some implementations + of IPv6 are optimized by not sending 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. + However, for purposes of this calculation, we assume that the IPv6 + implementation is conformant and that the message is sent. The + amount of time required for MLD signaling will depend on the per node + available wireless link bandwidth, but some representative numbers + can be obtained by assuming bandwidths of 20 kbps or 100 kbps. With + these 2 bit rates, the savings from not having to perform the pre- + router discovery messages are 115 msec. and 23 msec., respectively. + If any application-specific multicast addresses are subscribed, the + amount of time saved could be more substantial. + + This example might seem a bit contrived as MLD is not used in the 3G + cellular protocols, and wireless local area network protocols + typically have enough bandwidth if radio propagation conditions are + optimal. Therefore, sending a single MLD message might not be viewed + as a performance burden. 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. + + + +Loughney, et al. Experimental [Page 29] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + In addition, 802.15.1 handover times are typically run upwards of a + second or more because the host must resynchronize its frequency + hopping pattern with the access point, so anything the IP layer could + do to alleviate further delay would be beneficial. + + The context-specific data field for MLD context transfer included in + the CXTP Context Data Block message for a single IPv6 multicast + address has the following 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 contains a subnet + prefix that identifies the interface on which multicast routing + should be established. The Subscribed IPv6 Multicast Address field + contains the multicast address for which multicast routing should be + established. + + The pAR sends one MLD context block per subscribed IPv6 multicast + address. + + No changes are required in the MLD state machine. + + Upon receipt of a CXTP Context Data Block for MLD, the state machine + takes the following actions: + + - If the router is in the No Listeners present state on the + wireless interface on which the Subnet Prefix field in the + Context Data Block is advertised, it transitions 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. + + + + + +Loughney, et al. Experimental [Page 30] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + + - If the router is in the Listeners present state on that + interface, it remains 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 receiving an MLD + Context Data Block SHOULD send the block to the other routers on the + link. If wireless bandwidth is not 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 do not 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Loughney, et al. Experimental [Page 31] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +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.com + + + + + + + + + + + + + + + +Loughney, et al. Experimental [Page 32] + +RFC 4067 Context Transfer Protocol (CXTP) July 2005 + + +Full 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. + + + + + + + +Loughney, et al. Experimental [Page 33] + -- cgit v1.2.3