idnits 2.17.1 draft-ietf-seamoby-ctp-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 49 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2003) is 7488 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 791' is mentioned on line 605, but not defined == Missing Reference: 'RFC 2373' is mentioned on line 607, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Missing Reference: 'RFC2434' is mentioned on line 892, but not defined ** Obsolete undefined reference: RFC 2434 (Obsoleted by RFC 5226) == Unused Reference: 'CTHC' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 918, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2409 (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Seamoby WG J. Loughney (editor) 3 Internet Draft M. Nakhjiri 4 Category: Experimental C. Perkins 5 R. Koodli 6 Expires: May 25, 2004 October 25, 2003 8 Context Transfer Protocol 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Distribution of this memo is unlimited. 33 Copyright (C) The Internet Society 2003. All Rights Reserved. 35 Abstract 37 This document presents a context transfer protocol that enables 38 authorized context transfers. Context transfers allow better support 39 for node based mobility so that the applications running on mobile 40 nodes can operate with minimal disruption. Key objectives are to 41 reduce latency, packet losses and avoiding re-initiation of signaling 42 to and from the mobile node. 44 Table of Contents 46 1. Introduction 47 1.1 The Problem 48 1.2 Conventions Used in This Document 49 1.3 Abbreviations Used in the Document 50 2. Protocol Overview 51 2.1 Context Transfer Scenarios 52 2.2 Context Transfer Packet Formats 53 2.3 Context Types 54 2.4 Context Data Block 55 2.5 Messages 56 3. Transport, Reliability and Retransmission of Feature Data 57 4. Error Codes 58 5. Examples and Signaling Flows 59 5.1 Network controlled, Initiated by pAR 60 5.2 Network controlled, Initiated by nAR 61 5.3 Mobile controlled, Predictive New L2 up/old L2 down 62 6. Security Considerations 63 6.1 Threats 64 6.2 Security Details 65 6.3 IPsec Considerations 66 7. IANA Considerations 67 7.1 Context Profile Types Registry 68 7.2 UDP Port 69 8. Acknowledgements 70 9. References 71 9.1 Normative References 72 9.2 Non-Normative References 73 Appendix A. Timing and Trigger Considerations 74 Appendix B. Multicast Listener Context Transfer 75 Author's Addresses 77 1. Introduction 79 This document describes the Context Transfer Protocol overview, which 80 provides: 82 * Representation for feature contexts. 83 * Messages to initiate and authorize context transfer, and notify 84 a mobile node of the status of the transfer. 85 * Messages for transferring contexts prior to, during and after 86 handovers. 88 The proposed protocol is designed to work in conjunction with other 89 protocols in order to provide seamless mobility. The protocol 90 supports both IPv4 and IPv6, though support for IPv4 private 91 addresses is for future study. 93 The Problem 95 "Problem Description: Reasons For Performing Context Transfers 96 between Nodes in an IP Access Network" [RFC3374] defines the 97 following main reasons why Context Transfer procedures may be useful 98 in IP networks. 100 1) The primary motivation, as mentioned in the introduction, is the 101 need to quickly re-establish context transfer-candidate services 102 without requiring the mobile host to explicitly perform all 103 protocol flows for those services from scratch. An example of a 104 service is included in Appendix C. 106 2) An additional motivation is to provide an interoperable solution 107 that supports various Layer 2 radio access technologies. 109 1.1 Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 1.2 Abbreviations Used in the Document 117 Mobility Related Terminology [TERM] defines basic mobility 118 terminology. In addition to the material in that document, we use 119 the following terms and abbreviation in this document. 121 CTP Context Transfer Protocol 123 DoS Denial-of-Service 124 FPT Feature Profile Types 126 PCTD Predictive Context Transfer Data 128 2. Protocol Overview 130 This section provides a protocol overview. A context transfer can be 131 either started by a request from the mobile node ("mobile 132 controlled") or at the initiative of either the new or the previous 133 access router ("network controlled"). 135 * The mobile node sends the CT Activate Request to old AR whenever 136 possible to initiate predictive context transfer. In any case, the 137 MN always sends the CTAR message to new AR. If the contexts are 138 already present, nAR would verify the authorization token present 139 in CTAR with its own computation (using the parameters supplied by 140 pAR), and subsequently activate those contexts. If the contexts 141 are not present, nAR requests pAR to supply them using the Context 142 Transfer Request message, in which it supplies the authorization 143 token present in CTAR. 145 * Either nAR or pAR may request or start (respectively) context * 146 transfer based on internal or network triggers (see Appendix B). 148 The Context Transfer protocol typically operates between a source 149 node and a target node. In the future, there may be multiple target 150 nodes involved; the protocol described here would work with multiple 151 target nodes. For simplicity, we describe the protocol assuming a 152 single receiver or target node. 154 Typically, the source node is a MN's Previous Access Router (pAR) and 155 the target node is MN's New Access Router (nAR). Context Transfer 156 takes place when an event, such as a handover, takes place. We call 157 such an event a Context Transfer Trigger. In response to such a 158 trigger, the pAR may transfer the contexts; the nAR may request 159 contexts; and the MN may send a message to the routers to transfer 160 contexts. Such a trigger must be capable of providing the necessary 161 information, such as the MN's IP address with which the contexts are 162 associated, the IP addresses of the access routers, and authorization 163 to transfer context. 165 Context transfer protocol messages use Feature Profile Types that 166 identify the way that data is organized for the particular feature 167 contexts. The Feature Profile Types (FPTs) are registered in a number 168 space (with IANA Type Numbers) that allows a node to unambiguously 169 determine the type of context and the context parameters present in 170 the protocol messages. Contexts are transferred by laying out the 171 appropriate feature data within Context Data Blocks according to the 172 format in section 2.3, as well as any IP addresses necessary to 173 associate the contexts to a particular MN. The context transfer 174 initiation messages contain parameters that identify the source and 175 target nodes, the desired list of feature contexts and IP addresses 176 to identify the contexts. The messages that request transfer of 177 context data also contain an appropriate token to authorize the 178 context transfer. 180 Performing context transfer in advance of the MN attaching to nAR can 181 increase handover performance. For this to take place, certain 182 conditions must be met. For example, pAR must have sufficient time 183 and knowledge about the impending handover. This is feasible, for 184 instance, in Mobile IP fast handovers. Additionally, many cellular 185 networks have mechanisms to detect handovers in advance. However, 186 when the advance knowledge of impending handover is not available, or 187 if a mechanism such as fast handover fails, retrieving feature 188 contexts after the MN attaches to nAR is the only available means for 189 context transfer. Performing context transfer after handover might 190 still be better than having to re-establish all the contexts from 191 scratch. Finally, some contexts may simply need to be transferred 192 during handover signaling. For instance, any context that gets 193 updated on a per-packet basis must clearly be transferred only after 194 packet forwarding to the MN on its previous link is terminated. 196 The messages (CTD and CTDR) that perform the context transfer between 197 the access routers need to be authenticated, so that the access 198 routers can be certain that the data has not been tampered with 199 during delivery. 201 2.1 Context Transfer Scenarios 203 The Previous Access Router transfers feature contexts under two 204 general scenarios. 206 2.1.1 Scenario 1 208 The pAR may receive a Context Transfer Activate Request (CTAR) 209 message from the MN whose feature contexts are to be transferred, or 210 it receives an internally generated trigger (e.g., a link-layer 211 trigger on the interface to which the MN is connected). The CTAR 212 message, described in Section 2.5, provides the IP address of nAR, 213 the IP address of MN on pAR, the list of feature contexts to be 214 transferred (by default requesting all contexts to be transferred), 215 and a token authorizing the transfer. It also includes the MN's new 216 IP address (valid on nAR) whenever it is known. In response to a CT- 217 Activate Request message or to the CT trigger, pAR predictively 218 transmits a Context Transfer Data (CTD) message that contains feature 219 contexts. This message, described in Section 2.5, contains the MN's 220 previous IP address and its new IP address (if known). It also 221 contains parameters for nAR to compute an authorization token to 222 verify the MN's token present in CTAR message. Recall that the MN 223 always sends CTAR message to nAR regardless of whether it sent the 224 CTAR message to pAR. The reason for this is that there is no means 225 for the MN to ascertain that context transfer reliably took place. By 226 always sending the CTAR message to nAR, the Context Transfer Request 227 (see below) can be sent to pAR whenever necessary. 229 When context transfer takes place without the nAR requesting it, nAR 230 requires MN to present its authorization token. Doing this locally at 231 nAR when the MN attaches to it improves performance and increases 232 security, since the contexts are highly likely to be present already. 233 Token verification takes place at the router possessing the contexts. 235 2.1.2 Scenario 2 237 In the second scenario, pAR receives a Context Transfer Request (CT 238 Request), described in Section 2.5, message from nAR. The nAR itself 239 generates the CT Request message either as a result of receiving the 240 CTAR message or as a response to an internal trigger (that indicates 241 the MN's attachment). In the CT-Req message, nAR supplies the MN's 242 previous IP address, the feature contexts to be transferred, and a 243 token (generated by the MN) authorizing context transfer. In response 244 to CT Request message, pAR transmits a Context Transfer Data (CTD) 245 message that includes the MN's previous IP address and feature 246 contexts. When it receives a corresponding CTD message, nAR may 247 generate a CTD Reply message to report the status of processing the 248 received contexts. 250 When contexts are transferred reactively, the pAR verifies 251 authorization token before transmitting the contexts, and hence the 252 key the key is not needed in the CTD message. 254 2.2 Context Transfer Packet Format 256 The packet consists of a message specific header and one or more data 257 packets. Data packets may be bundled together in order to ensure a 258 more efficient transfer. The total packet size, including transport 259 protocol and IP protocol headers SHOULD be less than the path MTU, in 260 order to avoid packet fragmentation. 262 2.3 Context Types 264 Contexts are identified by context type of Feature Profile Type 265 (FPT), which is a 15-bit number. The meaning of each context type is 266 determined by a specification document and the context type numbers 267 are to be tabulated in a registry maintained by IANA, and handled 268 according to the message specifications in this document. The 269 instantiation of each context by nAR is determined by the messages in 270 this document along with the specification associated with the 271 particular context type. Each such context type specification 272 contains the following details: 274 +----------------------+ 275 | Message Header | 276 +----------------------+ 277 | CTP Data 1 | 278 +----------------------+ 279 | CTP Data 2 | 280 +----------------------+ 281 | ... | 283 - Number, size (in bits), and ordering of data fields in the 284 state variable vector which embodies the context. 285 - Default values (if any) for each individual datum of the 286 context state vector. 287 - Procedures and requirements for creating a context at a new 288 access router, given the data transferred from a previous 289 access router, and formatted according to the ordering rules 290 and date field sizes presented in the specification. 291 - If possible, status codes for success or failure related to the 292 context transfer. For instance, a QoS context transfer might 293 have different status codes depending on which elements of the 294 context data failed to be instantiated at nAR. 296 2.4 Context Data Block 298 The Context Data Block is used both for request and response 299 operation. When a particular feature request is constructed, only the 300 first 4 bytes are typically necessary (See CTAR below). When used for 301 the actual feature context itself, the context data is present, and 302 sometimes the presence vector is present. 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Cxt-Type | Length |P| Feature Profile Type (FTP) | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Presence Vector (if P = 1) | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | | 312 + data + 313 | | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 Cxt-Type Single octet, defined by IANA 317 Length message length in octets 319 'P' bit 0 = No presence vector 320 1 = Presence vector present. 322 FPT 16 bit integer, listing the feature profile 323 type contained in the data field. 325 data Context type-dependent data, whose length is 326 is defined by the Length Field. If the data 327 is not 64-bit aligned, the data field is padded 328 with zeros. 330 The Cxt-Type indicates the type of the feature context message itself 331 (such as QoS Context Request, QoS Context Transfer etc.), and Feature 332 Profile Type (FPT) identifies the way the particular feature context 333 is organized. The 'P' bit specifies whether or not the "presence 334 vector" is used. When the presence vector is in use, the Presence 335 Vector is interpreted to indicate whether particular data fields are 336 present (and containing non-default values). The ordering of the 337 bits in the presence vector is the same as the ordering of the data 338 fields according to the context type specification, one bit per data 339 field regardless of the size of the data field. 341 The Length field indicates the size of the CDB in 8 octets including 342 the first 4 bytes starting from Cxt-Type. 344 Notice that the length of the context data block is defined by the 345 sum of lengths of each data field specified by the context type 346 specification, plus 4 bytes if the 'P' bit is set, minus the 347 accumulated size of all the context data that is implicitly given 348 as a default value. 350 2.5 Messages 352 In this section, a list of the available context transfer message 353 types is given, along with a brief description of their functions. In 354 addition, the CTAR message also contains either the Previous Router's 355 IP address or the New Router's IP address. 357 The Mobile Node, for which context transfer protocol operations are 358 undertaken, is always identified by its previous IP access address. 359 At any one time, only one context transfer operation per MN may be in 360 progress so that the CTDR message unambiguously identifies which CTD 361 message is acknowledged simply by including the mobile node's 362 identifying previous IP address. 364 The 'V' flag indicates whether the MN's previous address is IPv4 365 only, IPv6 only or both addresses are present. See below. 367 2.5.1 Context Transfer Activate Request (CTAR) Message 369 This message is always sent by MN to nAR to request context transfer 370 activation. Even when the MN does not know whether or not contexts 371 are present, the MN sends CTAR message to gain access with nAR. If an 372 acknowledgement for this message is needed, the MN sets the A flag to 373 1, otherwise the MN does not expect an acknowledgement. This message 374 may include a list of FPT (feature profile types) that require 375 transfer. It may include flags to request reliable transfer. 377 The MN may also send this message to pAR while still connected to 378 pAR. In such a case, the MN includes the nAR's IP address and its new 379 IP address (if known) rather than previous IP address and pAR's IP 380 address. If the new IP address is not known, then its previous IP 381 address is used. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Type=CTAR | Length | V |A| Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Mobile Node's Previous (New) IP Address | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Previous (New) Router IP Address | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Replay | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | MN Authorization Token | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Requested Context Data Block (if present) | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Next Requested Context Data Block (if present) | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | ........ | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Type CTAR = 1 405 Length message length in octets 407 MN's IP Address Field contains either: 408 IPv4 Address as defined in [RFC 791]. 409 IPv6 Address as defined in [RFC 2373]. 411 nAR / pAR IP Address Field contains either: 413 IPv4 Address as defined in [RFC 791]. 414 IPv6 Address as defined in [RFC 2373]. 416 Reserved Reserved for future use. Must be set to zero 417 by the MN. 419 'V' flag When set to '00', indicate presence of IPv6 420 Previous (New) address only. 421 When set to '01' indicate presence of IPv4 422 Previous (New) Address only. 423 When set to '10' indicate presence of both 424 IPv6 and IPv4 Previous (New) addresses. 426 'A' bit The MN requests an acknowledgement. 428 Replay A value used to make sure that each use of the 429 CTAR message is uniquely identifiable. 431 Authorization Token An unforgeable value calculated as discussed 432 below. This authorizes the receiver of CTAR 433 to perform context transfer. 435 Context Block Variable length field defined in section 2.4. 437 If no context types are specified, then all contexts for the mobile 438 node are requested. When 'V' is 10, the IPv4 address MUST precede the 439 IPv6 address both for the MN and the access router. Since Context 440 Types clearly define the context including the IP version, context 441 enumeration need not be in any strict order, although it might be 442 natural to outline all the IPv4 contexts followed by IPv6 contexts. 444 The Authorization Token is calculated as: 446 First (32, HMAC_SHA1 (Key, (Previous IP address | Replay | Context 447 Types))) 449 where Key is the shared secret between the MN and pAR, and Context 450 Types includes all the desired contexts for which the transfer is 451 desired. In the default scenario, the MN implicitly (i.e., even 452 without the knowledge of contexts being present) or explicitly 453 requests transfer of all contexts. 455 2.5.2 Context Transfer Activate Acknowledge (CTAA) Message 457 This is an informative message sent by the receiver of CTAR to the MN 458 to acknowledge a CTAR message. Acknowledgement is optional, depending 459 on whether the MN requested it. This message may include a list of 460 FPT (feature profile types) that were not transferred successfully. 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Type=CTAA | Length | Reserved | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Mobile Node's Previous IP address | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | FPT (if present) | Status code | Reserved | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | ........ | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Type CTAR = 2 476 Length message length in octets 478 Reserved Reserved for future use. Must be set to zero 479 by the MN. 481 MN's Prev IP Address Field contains either: 482 IPv4 Address as defined in [RFC 791]. 483 IPv6 Address as defined in [RFC 2373]. 485 FPT 16 bit integer, listing the FTP that was not 486 Successfully transferred. 488 Status Code An octet, containing failure reason. 490 2.5.3 Context Transfer Data (CTD) Message 492 Sent by pAR to nAR, and includes feature data (CTP data). This 493 message should handle predictive as well as normal CT. A reliability 494 flag, R, included in this message indicates whether a reply is 495 required by nAR. 497 0 1 2 3 498 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 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | Type=(P)CTD | Length | V |A| Reserved | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Elapsed Time (in milliseconds) | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Mobile Node's Previous Care-of Address | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Mobile Node's New Care-of Address, when Type=PCTD | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 508 | Algorithm | Key Length | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD 510 | Key | only 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 512 | First Context Data Block | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Next Context Data Block | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 | ........ | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Type CTD = 3 (Context Transfer Data) 520 PCTD = 4 (Predictive Context Transfer Data) 522 'V' flag When set to '00', indicate presence of IPv6 523 Previous (New) address only. 524 When set to '01' indicate presence of IPv4 525 Previous (New) Address only. 526 When set to '10' indicate presence of both 527 IPv6 and IPv4 Previous (New) addresses. 529 'A' bit The MN requests an acknowledgement. 531 Length message length in octets 533 Reserved Reserved for future use. Must be set to zero 534 by the MN. 536 MN's Prev CoA Address Field contains either: 537 IPv4 Address as defined in [RFC 791], 538 IPv6 Address as defined in [RFC 2373]. 540 MN's New CoA Address Field contains either: 541 IPv4 Address as defined in [RFC 791], 542 IPv6 Address as defined in [RFC 2373]. 543 This is only applicable for the PCTD message. 545 Algorithm Algorithm for carrying out the computation 546 of the MN Authorization Token. Currently 547 only 1 algorithm is defined, HMAC_SHA1 = 1. 549 Key Length length of key, in octets. 551 When CTD is sent predictively, the supplied parameters including the 552 algorithm, key length and the key itself, allow nAR to compute a 553 token locally and verify against the token present in the CTAR 554 message. This message MUST be protected by IPsec ESP. 556 As described previously, the algorithm for carrying out the 557 computation of the MN Authorization Token is HMAC_SHA1. The input 558 data for computing the token are: 560 - the MN's Previous IP address, 561 - the FPT objects, 562 - the Replay field. 564 When support for transferring all contexts is requested, a default 565 FPT is used. The Authorization Token is obtained by truncating the 566 results of the HMAC_SHA1 computation to retain only the leading 32 567 bits. 569 2.5.4 Context Transfer Data Reply (CTDR) Message 571 This message is sent by nAR to pAR depending on the value of the 572 reliability flag in CTD. Indicates success or failure. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type=CTDR | Length | V |S| Reserved | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Mobile Node's Previous IP Address | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | FPT (if present) | Status code | Reserved | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | ....... | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Type CTDR = 5 (Context Transfer Data) 588 Length message length in octets 590 'V' flag When set to '00', indicate presence of IPv6 591 Previous address only. 592 When set to '01' indicate presence of IPv4 593 Previous Address only. 594 When set to '10' indicate presence of both 595 IPv6 and IPv4 Previous addresses. 597 'S' bit When set to one, this bit indicates that all 598 the feature contexts sent in CTD or PCTD were 599 received successfully. 601 Reserved Reserved for future use. Must be set to zero 602 by the MN. 604 MN's Prev IP Contains either: 605 Address Field IPv4 Address as defined in [RFC 791]. 607 IPv6 Address as defined in [RFC 2373]. 609 Status Code A context-specific return value, present 610 when 'S' is not set to one. 612 FPT 16 bit integer, listing the FPT that is being 613 acknowledged. 615 Status Code 0 = not successfully transfered 616 1 = successfully transfered 618 2.5.5 Context Transfer Cancel (CTC) Message 620 If transferring a context cannot be completed in a timely fashion, 621 then nAR may send CTC to pAR to cancel an ongoing CT process. 623 0 1 2 3 624 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 625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 | Type=CTC | Length | Reserved | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | Mobile Node's Previous Care-of Address | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 Type CTC = 6 (Context Transfer Data) 633 Length message length in octets 635 Reserved Reserved for future use. Must be set to zero 636 by the MN. 638 2.5.6 Context Transfer Request (CT Request) Message 640 Sent by nAR to pAR to request start of context transfer. This message 641 is sent as a response to CTAR message by the MN. The fields following 642 the Previous IP address of the MN are included verbatim from the CTAR 643 message. 645 0 1 2 3 646 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 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | Type=CTREQ | Length | V | Reserved | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Mobile Node's Previous IP Address | 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Replay | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | MN Authorization Token | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Requested Context Data Block (if present) | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Next Requested Context Data Block (if present) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | ........ | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 Type CTREQ = 7 665 Length message length in octets 667 'V' bits When set to '00', indicate presence of IPv6 668 Previous (New) address only. 669 When set to '01' indicate presence of IPv4 670 Previous (New) Address only. 671 When set to '10' indicate presence of both 672 IPv6 and IPv4 Previous (New) addresses. 674 Reserved Reserved for future use. Must be set to zero 675 by the MN. 677 Replay A value used to make sure that each use of the 678 CTAR message is uniquely identifiable. 679 Copied from CTAR. 681 Authorization Token An unforgeable value calculated as discussed 682 above. This authorizes the receiver of CTAR 683 to perform context transfer. Copied from 684 CTAR. 686 3. Transport, Reliability and Retransmission of Feature Data 688 CTP runs over UDP using port number . Some feature contexts may 689 specify a reliability factor, MAX_RETRY_INTERVAL, which is the length 690 of time that the pAR is allowed to perform retransmissions before 691 giving up on the context transfer for that feature context. The 692 longer the allowed retry interval, the more retransmissions will be 693 possible for that feature context. 695 For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD 696 retransmit an unacknowledged CTD message after waiting for 697 RETRANSMISSION_DELAY milliseconds. This time value is configurable 698 based on the type of network interface; slower network media 699 naturally will be configured with longer values for the 700 RETRANSMISSION_DELAY. Except for the value of the elapsed time field, 701 the payload of each retransmitted CTD packet is identical to the 702 payload of the initially transmitted CTD packet, in order to maintain 703 the ability of the mobile device to present a correctly calculated 704 authentication token. The number of retransmissions, each delayed by 705 RETRANSMISSION_DELAY, depends on the maximum value for 706 MAX_RETRY_INTERVAL as specified by any of the contexts. The value 707 of the Elapsed Time field is the number of milliseconds since the 708 transmission of the first CTD message 710 UDP provides an optional checksum, which SHOULD be checked. If the 711 checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with 712 the status value BAD_UDP_CHECKSUM, even if the 'A' bit is not set in 713 the CTD. 715 4. Error Codes 717 This section lists error codes used by UDP 719 BAD_UDP_CHECKSUM 0x01 721 5. Examples and Signaling Flows 723 5.1 Network controlled, Initiated by pAR 725 MN nAR pAR 726 | | | 727 T | | CT trigger 728 I | | | 729 M | |<------- CTD ----------| 730 E |--------CTAR--------->| | 731 : | | | 732 | | |-------- CTDR -------->| 733 V | | | 734 | | | 736 5.2 Network controlled, initiated by nAR 738 MN nAR pAR 739 | | | 740 T | CT trigger | 741 I | | | 742 M | |----- CT Request ----->| 743 E | | | 744 : | |<------- CTD ----------| 745 | | | | 746 V |--------CTAR--------->| | 747 | |----- CTDR (opt) ----->| 748 | | | 750 5.3 Mobile controlled, Predictive New L2 up/old L2 down 752 CTAR request to nAR 754 MN nAR pAR 755 | | | 756 new L2 link up | | 757 | | | 758 CT trigger | | 759 | | | 760 T |--------CTAR ------->| | 761 I | |---- CT Request ------>| 762 M | | | 763 E | |<-------- CTD ---------| 764 : | | | 765 | | | | 766 V | | | 767 | | | 769 In case CT cannot be supported, a CTAR reject (TBD) may be sent to 770 the MN by nAR. 772 6. Security Considerations 774 At this time, the threats to IP handover in general and context 775 transfer in particular are incompletely understood, particularly on 776 the MN to AR link, and mechanisms for countering them are not well 777 defined. Part of the experimental task in preparing CTP for eventual 778 standards track will be to better characterize threats to context 779 transfer and design specific mechanisms to counter them. This section 780 provides some general guidelines about security based on discussions 781 among the Design Team and Working Group members. 783 6.1. Threats. 785 The Context Transfer Protocol transfers state between access routers. 786 If the mobile nodes are not authenticated and authorized before 787 moving on the network, there is a potential for DoS attacks to shift 788 state between ARs, causing network disruptions. 790 Additionally, DoS attacks can be launched from mobile nodes towards 791 the access routers by requesting multiple context transfers and then 792 disappearing. Finally, a rogue access router could flood mobile 793 nodes with packets, attempting DoS attacks. 795 6.2. Security Details 797 CTP relies on IETF standardized security mechanisms for protecting 798 traffic between access routers, as opposed to creating application 799 security mechanisms. IPsec MUST be supported between access routers. 801 In order to avoid the introduction of additional latency to context 802 transfer due to the need for establishment of secure channel between 803 the context transfer peers (ARs), the two ARs SHOULD establish such 804 secure channel in advance. If IPSec is used, for example, the two 805 access routers need to engage in a key exchange mechanisms such as 806 IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and 807 IPSec protocols (such as ESP) in anticipation for any upcoming 808 context transfer. This will save time during handovers that require 809 secure transfer of mobile node's context(s). Such SAs can be 810 maintained and used for all upcoming context transfers between the 811 two ARs. Security SHOULD be negotiated prior to the sending of 812 context. 814 Furthermore, either one or both of the pAR and nAR need to be able to 815 authenticate the mobile and authorize mobile's credential before 816 authorizing the context transfer and release of context to the 817 mobile. In case the context transfer is request by the MN, a 818 mechanism MUST be provided so that requests are authenticated 819 (regardless of the security of context transfer itself) to prevent 820 the possibility of rogue MNs launching DoS attacks by sending large 821 number of CT requests as well as cause large number of context 822 transfers between ARs. Another important consideration is that the 823 mobile node should claim it's own context, and not some other 824 masquerader. One method to achieve this is to provide an 825 authentication cookie to be included with the context transfer 826 message sent from the pAR to the nAR and confirmed by the mobile node 827 at the nAR. 829 6.3. IPsec Considerations 831 Access Routers MUST implement IPsec ESP [ESP] in transport mode with 832 non-null encryption and authentication algorithms to provide per- 833 packet authentication, integrity protection and confidentiality, and 834 MUST implement the replay protection mechanisms of IPsec. In those 835 scenarios where IP layer protection is needed, ESP in tunnel mode 836 SHOULD be used. Non-null encryption should be used when using IPSec 837 ESP. 839 7. IANA Considerations 841 This section provides guidance to the Internet Assigned Numbers 842 Authority (IANA) regarding registration of values related to the 843 context transfer protocol, in accordance with BCP 26 [RFC2434]. 845 7.1 Context Profile Types Registry 847 This document authorized IANA to create a registry for Context 848 Profile Types, introduced in this document. For future Context 849 Profile Types, it is recommended that allocations be done on the 850 basis of Designated Expert. 852 The Context Profile Type introduced in this document requires IANA 853 Type Numbers for each set of feature contexts that make use of 854 Profile Types. 856 For registration requests where a Designated Expert should be 857 consulted, the responsible IESG area director should appoint the 858 Designated Expert. 860 7.2 UDP Port 862 CTP requires a UDP port assignment. 864 8. Acknowledgements & Contributors 866 This document is the result of a design team formed by the Working 867 Group chairs of the SeaMoby working group. The team included John 868 Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. 870 Contributors to the Context Transfer Protocol review are Basavaraj 871 Patil, Pekka Savola, and Antti Tuominen. 873 The working group chairs are Pat Calhoun and James Kempf, whose 874 comments have been very helpful during the creation of this 875 specification. 877 The authors would also like to thank Julien Bournelle, Vijay 878 Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf 879 Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their 880 help and suggestions with this document. 882 9. References 884 9.1 Normative References 886 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 887 BCP 9, RFC 2026, October 1996. 889 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- 890 ment Levels", BCP 14, RFC 2119, March 1997. 892 IP [RFC2434] T. Narten, H. Alvestrand, "Guidelines for 893 Writing an IANA Considerations Section in RFCs", BCP 26, 894 RFC 2434, October 1998. 896 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 897 RFC 2409, November 1998. 899 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- 900 load (ESP)", RFC 2406, November 1998. 902 9.2 Non-Normative References 904 [CTHC] R. Koodli et al., "Context Relocation for Seamless Header 905 Compression in IP Networks", Internet Draft, Internet 906 Engineering Task Force, Work in Progress. 908 [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet 909 Engineering Task Force. Work in Progress. 911 [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", 912 Internet Engineering Task Force. Work in Progress. 914 [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing 915 Context Transfers Between Nodes in an IP Access Network", RFC 916 3374, Internet Engineering Task Force, RFC 3374, May 2001. 918 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 919 Protocol", RFC 2401, November 1998. 921 [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet 922 Engineering Task Force, Work in Progress. 924 [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast 925 Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. 927 [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery 928 for IP Version 6 (IPv6)," RFC 2461, December, 1998. 930 [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfigura- 931 tion," RFC 2462, December, 1998. 933 Appendix A. Timing and Trigger Considerations 935 Basic Mobile IP handover signaling can introduce disruptions to the 936 services running on top of Mobile IP, which may introduce unwanted 937 latencies that practically prohibit its use for certain types of ser- 938 vices. Mobile IP latency and packet loss is being optimized through 939 several alternative procedures, such as Fast Mobile IP [FMIPv6] and 940 Low Latency Mobile IP [LLMIP]. 942 Feature re-establishment through context transfer should contribute 943 zero (optimally) or minimal extra disruption of services in conjunc- 944 tion to handovers. This means that the timing of context transfer 945 SHOULD be carefully aligned with basic Mobile IP handover events, and 946 with optimized Mobile IP handover signaling mechanisms, as those pro- 947 tocols become available. 949 Furthermore, some of those optimized mobile IP handover mechanisms 950 may provide more flexibility is choosing the timing and order for 951 transfer of various context information. 953 Appendix B. Multicast Listener Context Transfer 955 As an example of how context transfer can improve the performance of 956 IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. 957 MLD state is a particularly good example because every IPv6 node must 958 perform one MLD messaging sequence on the wireless link to establish 959 itself as an MLD listener prior to performing router discovery 960 [RFC2461] or duplicate address detection [RFC2462] or before 961 sending/receiving any application-specific traffic (including Mobile 962 IP handover signaling, if any). The node must subscribe to the Soli- 963 cited Node Multicast Address as soon as it comes up on the link. Any 964 application-specific multicast addresses must be re-established as 965 well. Context transfer can significantly speed up re-establishing 966 multicast state by allowing the nAR to initialize MLD for a node that 967 just completed handover; without any MLD signaling on the new wire- 968 less link. The same approach could be used for transferring multicast 969 context in IPv4. 971 An approximate qualitative estimate for the amount of savings in 972 handover time can be obtained as follows. MLD messages are 24 bytes, 973 to which the headers must be added, because there is no header 974 compression on the new link, with the IPv6 header being 40 bytes, and 975 a required Router Alert Hop-by-Hop option being 8 bytes including 976 padding. The total MLD message size is thus 72 bytes per subscribed 977 multicast address. RFC 2710 recommends that nodes send 2 to 3 MLD 978 Report messages per address subscription, since the Report message is 979 unacknowledged. Assuming 2 MLD messages sent for a subscribed 980 address, the mobile node would need to send 144 bytes per address 981 subscription, and must send at least 144 bytes on every handover, for 982 the link local Solicited Node Multicast address. The amount of time 983 required for MLD signaling will, of course, depend on the wireless 984 link bandwidth, but some representative numbers can be obtained by 985 assuming bandwidths of 20 kbps or 100 kbps. The former is approximate 986 for a narrowband 3G cellular link and the latter for a heavily util- 987 ized 802.11b WLAN link, both running Voice over IP (VoIP). With these 988 two bit rates, the savings from not having to perform the required 989 MLD signaling are 57 msec. and 11 msec., respectively. If any 990 application-specific multicast addresses are subscribed, the amount 991 of time saved could be substantially more. Considering most ATM-based 992 3G voice cellular protocols try to keep total voice handover delay 993 less than 40-80 msec., MLD signaling could have a substantial impact 994 on the performance of inter-subnet VoIP handover. 996 The context-specific data field for MLD context transfer included in 997 the CTP Context Data Block message for a single IPv6 multicast 998 address has the following format: 1000 0 1 2 3 1001 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 1002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1003 | | 1004 + Subnet Prefix on nAR Wireless Interface + 1005 | | 1006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1007 | | 1008 + + 1009 | | 1010 + Subscribed IPv6 Multicast Address + 1011 | | 1012 + + 1013 | | 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 The Subnet Prefix on nAR Wireless Interface field contains a subnet 1017 prefix that identifies the interface on which multicast routing 1018 should be established. The Subscribed IPv6 Multicast Address field 1019 contains the multicast address for which multicast routing should be 1020 established. 1022 The pAR sends one MLD context block per subscribed IPv6 multicast 1023 address. 1025 The MLD state machine requires no changes to implement context 1026 transfer. Upon receipt of a CTP Context Data Block for MLD, the state 1027 machine takes the following actions: 1029 - If the router is in the No Listeners present state on the wireless 1030 interface on which the Subnet Prefix field from the Context Data 1031 Block is advertised, it transitions into the Listeners Present 1032 state for the Subscribed IPv6 Multicast Address field in the Con- 1033 text Data Block. This transition is exactly the same as if the 1034 router had received a Report message. 1036 - If the router is in the Listeners present state on that interface, 1037 it remains in that state but restarts the timer, as if it had 1038 received a Report message. 1040 If more than one MLD router is on the link, a router receiving an MLD 1041 Context Data Block SHOULD send the block to the other routers on the 1042 link. The router MAY instead send a proxy MLD Report message on the 1043 wireless interface that advertises the Subnet Prefix field from the 1044 Context Data Block if wireless bandwidth is not an issue. Since MLD 1045 routers do not keep track of which nodes are listening to which mul- 1046 ticast addresses, only whether a particular multicast address is 1047 being listened to, proxying the subscription should cause no diffi- 1048 culty. 1050 Authors' Addresses 1052 Rajeev Koodli 1053 Nokia Research Center 1054 313 Fairchild Drive 1055 Mountain View, California 94043 1056 USA 1057 Rajeev.koodli@nokia.com 1059 John Loughney 1060 Nokia 1061 Itdmerenkatu 11-13 1062 00180 Espoo 1063 Finland 1064 john.loughney@nokia.com 1066 Madjid F. Nakhjiri 1067 Motorola Labs 1068 1031 East Algonquin Rd., Room 2240 1069 Schaumburg, IL, 60196 1070 USA 1071 madjid.nakhjiri@motorola.com 1073 Charles E. Perkins 1074 Nokia Research Center 1075 313 Fairchild Drive 1076 Mountain View, California 94043 1077 USA 1078 charliep@iprg.nokia.com 1080 Intellectual Property Considerations 1082 The IETF takes no position regarding the validity or scope of any 1083 intellectual property or other rights that might be claimed to per- 1084 tain to the implementation or use of the technology described in this 1085 document or the extent to which any license under such rights might 1086 or might not be available; neither does it represent that it has made 1087 any effort to identify any such rights. Information on the IETF's 1088 procedures with respect to rights in standards-track and standards- 1089 related documentation can be found in BCP-11. Copies of claims of 1090 rights made available for publication and any assurances of licenses 1091 to be made available, or the result of an attempt made to obtain a 1092 general license or permission for the use of such proprietary rights 1093 by implementers or users of this specification can be obtained from 1094 the IETF Secretariat. 1096 The IETF invites any interested party to bring to its attention any 1097 copyrights, patents or patent applications, or other proprietary 1098 rights which may cover technology that may be required to practice 1099 this standard. Please address the information to the IETF Executive 1100 Director.