idnits 2.17.1 draft-ietf-seamoby-ctp-08.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 24 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 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 52 instances of too long lines in the document, the longest one being 7 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 (January 21, 2004) is 7400 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 791' is mentioned on line 614, but not defined == Missing Reference: 'RFC 2373' is mentioned on line 615, but not defined ** Obsolete undefined reference: RFC 2373 (Obsoleted by RFC 3513) == Unused Reference: 'CTHC' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC2401' is defined on line 928, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** 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 (~~), 7 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Seamoby WG J. Loughney (editor) 2 Internet Draft M. Nakhjiri 3 Category: Experimental C. Perkins 4 R. Koodli 5 Expires: July 21, 2004 January 21, 2004 7 Context Transfer Protocol 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [RFC2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Distribution of this memo is unlimited. 32 Copyright (C) The Internet Society 2004. All Rights Reserved. 34 Abstract 36 This document presents a context transfer protocol that enables 37 authorized context transfers. Context transfers allow better support 38 for node based mobility so that the applications running on mobile 39 nodes can operate with minimal disruption. Key objectives are to 40 reduce latency, packet losses and avoiding re-initiation of signaling 41 to and from the mobile node. 43 Table of Contents 45 1. Introduction 46 1.1 The Problem 47 1.2 Conventions Used in This Document 48 1.3 Abbreviations Used in the Document 49 2. Protocol Overview 50 2.1 Context Transfer Scenarios 51 2.2 Context Transfer Packet Formats 52 2.3 Context Types 53 2.4 Context Data Block 54 2.5 Messages 55 3. Transport, Reliability and Retransmission of Feature Data 56 4. Open Issues 57 4.1 Failure Handling 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 7. IANA Considerations 64 8. Acknowledgements 65 9. References 66 9.1 Normative References 67 9.2 Non-Normative References 68 Appendix A. Timing and Trigger Considerations 69 Appendix B. Multicast Listener Context Transfer 70 Author's Addresses 72 1. Introduction 74 This document describes the Context Transfer Protocol overview, which 75 provides: 77 * Representation for feature contexts. 78 * Messages to initiate and authorize context transfer, and notify 79 a mobile node of the status of the transfer. 80 * Messages for transferring contexts prior to, during and after 81 handovers. 83 The proposed protocol is designed to work in conjunction with other 84 protocols in order to provide seamless mobility. The protocol 85 supports both IPv4 and IPv6, though support for IPv4 private 86 addresses is for future study. 88 The Problem 90 "Problem Description: Reasons For Performing Context Transfers 91 between Nodes in an IP Access Network" [RFC3374] defines the 92 following main reasons why Context Transfer procedures may be useful 93 in IP networks. 95 1) The primary motivation, as mentioned in the introduction, is the 96 need to quickly re-establish context transfer-candidate services 97 without requiring the mobile host to explicitly perform all 98 protocol flows for those services from scratch. An example of a 99 service is included in Appendix C. 101 2) An additional motivation is to provide an interoperable solution 102 that supports various Layer 2 radio access technologies. 104 1.1 Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 1.2 Abbreviations Used in the Document 112 Mobility Related Terminology [TERM] defines basic mobility 113 terminology. In addition to the material in that document, we use 114 the following terms and abbreviation in this document. 116 CTP Context Transfer Protocol 118 DoS Denial-of-Service 119 FPT Feature Profile Types 121 PCTD Predictive Context Transfer Data 123 2. Protocol Overview 125 This section provides a protocol overview. A context transfer can be 126 either started by a request from the mobile node ("mobile 127 controlled") or at the initiative of either the new or the previous 128 access router ("network controlled"). 130 * The mobile node sends the CT Activate Request to old AR whenever 131 possible to initiate predictive context transfer. In any case, the 132 MN always sends the CTAR message to new AR. If the contexts are 133 already present, nAR would verify the authorization token present 134 in CTAR with its own computation (using the parameters supplied by 135 pAR), and subsequently activate those contexts. If the contexts 136 are not present, nAR requests pAR to supply them using the Context 137 Transfer Request message, in which it supplies the authorization 138 token present in CTAR. 140 * Either nAR or pAR may request or start (respectively) context * 141 transfer based on internal or network triggers (see Appendix B). 143 The Context Transfer protocol typically operates between a source 144 node and a target node. In the future, there may be multiple target 145 nodes involved; the protocol described here would work with multiple 146 target nodes. For simplicity, we describe the protocol assuming a 147 single receiver or target node. 149 Typically, the source node is a MN's Previous Access Router (pAR) and 150 the target node is MN's New Access Router (nAR). Context Transfer 151 takes place when an event, such as a handover, takes place. We call 152 such an event a Context Transfer Trigger. In response to such a 153 trigger, the pAR may transfer the contexts; the nAR may request 154 contexts; and the MN may send a message to the routers to transfer 155 contexts. Such a trigger must be capable of providing the necessary 156 information, such as the MN's IP address with which the contexts are 157 associated, the IP addresses of the access routers, and authorization 158 to transfer context. 160 Context transfer protocol messages use Feature Profile Types that 161 identify the way that data is organized for the particular feature 162 contexts. The Feature Profile Types (FPTs) are registered in a number 163 space (with IANA Type Numbers) that allows a node to unambiguously 164 determine the type of context and the context parameters present in 165 the protocol messages. Contexts are transferred by laying out the 166 appropriate feature data within Context Data Blocks according to the 167 format in section 2.3, as well as any IP addresses necessary to 168 associate the contexts to a particular MN. The context transfer 169 initiation messages contain parameters that identify the source and 170 target nodes, the desired list of feature contexts and IP addresses 171 to identify the contexts. The messages that request transfer of 172 context data also contain an appropriate token to authorize the 173 context transfer. 175 Performing context transfer in advance of the MN attaching to nAR can 176 increase handover performance. For this to take place, certain 177 conditions must be met. For example, pAR must have sufficient time 178 and knowledge about the impending handover. This is feasible, for 179 instance, in Mobile IP fast handovers. Additionally, many cellular 180 networks have mechanisms to detect handovers in advance. However, 181 when the advance knowledge of impending handover is not available, or 182 if a mechanism such as fast handover fails, retrieving feature 183 contexts after the MN attaches to nAR is the only available means for 184 context transfer. Performing context transfer after handover might 185 still be better than having to re-establish all the contexts from 186 scratch. Finally, some contexts may simply need to be transferred 187 during handover signaling. For instance, any context that gets 188 updated on a per-packet basis must clearly be transferred only after 189 packet forwarding to the MN on its previous link is terminated. 191 The messages (CTD and CTDR) that perform the context transfer between 192 the access routers need to be authenticated, so that the access 193 routers can be certain that the data has not been tampered with 194 during delivery. 196 2.1 Context Transfer Scenarios 198 The Previous Access Router transfers feature contexts under two 199 general scenarios. 201 2.1.1 Scenario 1 203 The pAR may receive a Context Transfer Activate Request (CTAR) 204 message from the MN whose feature contexts are to be transferred, or 205 it receives an internally generated trigger (e.g., a link-layer 206 trigger on the interface to which the MN is connected). The CTAR 207 message, described in Section 2.5, provides the IP address of nAR, 208 the IP address of MN on pAR, the list of feature contexts to be 209 transferred (by default requesting all contexts to be transferred), 210 and a token authorizing the transfer. It also includes the MN's new 211 IP address (valid on nAR) whenever it is known. In response to a CT- 212 Activate Request message or to the CT trigger, pAR predictively 213 transmits a Context Transfer Data (CTD) message that contains feature 214 contexts. This message, described in Section 2.5, contains the MN's 215 previous IP address and its new IP address (if known). It also 216 contains parameters for nAR to compute an authorization token to 217 verify the MN's token present in CTAR message. Recall that the MN 218 always sends CTAR message to nAR regardless of whether it sent the 219 CTAR message to pAR. The reason for this is that there is no means 220 for the MN to ascertain that context transfer reliably took place. By 221 always sending the CTAR message to nAR, the Context Transfer Request 222 (see below) can be sent to pAR whenever necessary. 224 When context transfer takes place without the nAR requesting it, nAR 225 requires MN to present its authorization token. Doing this locally at 226 nAR when the MN attaches to it improves performance and increases 227 security, since the contexts are highly likely to be present already. 228 Token verification takes place at the router possessing the contexts. 230 2.1.2 Scenario 2 232 In the second scenario, pAR receives a Context Transfer Request (CT 233 Request), described in Section 2.5, message from nAR. The nAR itself 234 generates the CT Request message either as a result of receiving the 235 CTAR message or as a response to an internal trigger (that indicates 236 the MN's attachment). In the CT- Req message, nAR supplies the MN's 237 previous IP address, the feature contexts to be transferred, and a 238 token (generated by the MN) authorizing context transfer. In response 239 to CT Request message, pAR transmits a Context Transfer Data (CTD) 240 message that includes the MN's previous IP address and feature 241 contexts. When it receives a corresponding CTD message, nAR may 242 generate a CTD Reply message to report the status of processing the 243 received contexts. 245 When contexts are transferred reactively, the pAR verifies 246 authorization token before transmitting the contexts, and hence the 247 key the key is not needed in the CTD message. 249 2.2 Context Transfer Packet Format 251 The packet consists of a message specific header and one or more data 252 packets. Data packets may be bundled together in order to ensure a 253 more efficient transfer. The total packet size, including transport 254 protocol and IP protocol headers SHOULD be less than the path MTU, in 255 order to avoid packet fragmentation. 257 2.3 Context Types 259 Contexts are identified by context type of Feature Profile Type 260 (FPT), which is a 15-bit number. The meaning of each context type is 261 determined by a specification document and the context type numbers 262 are to be tabulated in a registry maintained by IANA, and handled 263 according to the message specifications in this document. The 264 instantiation of each context by nAR is determined by the messages in 265 this document along with the specification associated with the 266 particular context type. Each such context type specification 267 contains the following details: 269 +----------------------+ 270 | Message Header | 271 +----------------------+ 272 | CTP Data 1 | 273 +----------------------+ 274 | CTP Data 2 | 275 +----------------------+ 276 | ... | 278 - Number, size (in bits), and ordering of data fields in the 279 state variable vector which embodies the context. 280 - Default values (if any) for each individual datum of the 281 context state vector. 282 - Procedures and requirements for creating a context at a new 283 access router, given the data transferred from a previous 284 access router, and formatted according to the ordering rules 285 and date field sizes presented in the specification. 286 - If possible, status codes for success or failure related to the 287 context transfer. For instance, a QoS context transfer might 288 have different status codes depending on which elements of the 289 context data failed to be instantiated at nAR. 291 2.4 Context Data Block 293 The Context Data Block is used both for request and response 294 operation. When a particular feature request is constructed, only the 295 first 4 bytes are typically necessary (See CTAR below). When used for 296 the actual feature context itself, the context data is present, and 297 sometimes the presence vector is present. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Cxt-Type | Length |P| Feature Profile Type (FTP) | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Presence Vector (if P = 1) | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 + data + 308 | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Cxt-Type Single octet, defined by IANA 312 Length message length in units of 8 313 octet words 315 'P' bit 0 = No presence vector 316 1 = Presence vector present. 318 FPT 16 bit integer, listing the feature profile 319 type contained in the data field. 321 data Context type-dependent data, whose length 322 is defined by the Length Field. If the data 323 is not 64-bit aligned, the data field is 324 padded with zeros. 326 The Cxt-Type indicates the type of the feature context message itself 327 (such as QoS Context Request, QoS Context Transfer etc.), and Feature 328 Profile Type (FPT) identifies the way the particular feature context 329 is organized. The 'P' bit specifies whether or not the "presence 330 vector" is used. When the presence vector is in use, the Presence 331 Vector is interpreted to indicate whether particular data fields are 332 present (and containing non-default values). The ordering of the 333 bits in the presence vector is the same as the ordering of the data 334 fields according to the context type specification, one bit per data 335 field regardless of the size of the data field. 337 The Length field indicates the size of the CDB in 8 octets including 338 the first 4 bytes starting from Cxt-Type. 340 Cxt-Type = 0 is reserved for a general error message. The data field 341 contains error codes information, and is defined by in specific 342 context types. 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 units of 8 406 octet words 408 MN's IP Address Field contains either: 409 IPv4 Address as defined in [RFC 791]. 410 IPv6 Address as defined in [RFC 2373]. 412 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))), where Key is the shared secret between the MN and pAR, 448 and Context Types includes all the desired contexts for which the 449 transfer is desired. In the default scenario, the MN implicitly 450 (i.e., even without the knowledge of contexts being present) or 451 explicitly requests transfer of all contexts. 453 2.5.2 Context Transfer Activate Acknowledge (CTAA) Message 454 This is an informative message sent by the receiver of CTAR to the MN 455 to acknowledge a CTAR message. Acknowledgement is optional, depending 456 on whether the MN requested it. This message may include a list of 457 FPT (feature profile types) that were not transferred successfully. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | Type=CTAA | Length | V | Reserved | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Mobile Node's Previous IP address | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | FPT (if present) | Status code | Reserved | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | ........ | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Type CTAR = 2 473 Length message length in units of 8 474 octet words 476 Reserved Reserved for future use. Must be set to 477 zero by the sender of CTAA Message, i.e. 478 pAR or nAR. 480 'V' flag When set to '00', indicate presence of IPv6 481 Previous (New) address only. 482 When set to '01' indicate presence of IPv4 483 Previous (New) Address only. 484 When set to '10' indicate presence of both 485 IPv6 and IPv4 Previous (New) addresses. 487 MN's Prev IP Address Field contains either: 488 IPv4 Address as defined in [RFC 791]. 489 IPv6 Address as defined in [RFC 2373]. 491 FPT 16 bit integer, listing the FTP that was not 492 Successfully transferred. 494 Status Code An octet, containing failure reason. 496 2.5.3 Context Transfer Data (CTD) Message 498 Sent by pAR to nAR, and includes feature data (CTP data). This 499 message should handle predictive as well as normal CT. An 500 acknowledgement flag, A, included in this message indicates whether a 501 reply is required by pAR. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type=(P)CTD | Length | V |A| Reserved | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Elapsed Time (in milliseconds) | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Mobile Node's Previous Care-of Address | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | Mobile Node's New Care-of Address, when Type=PCTD | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 514 | Algorithm | Key Length | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PCTD 516 | Key | only 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ V 518 | First Context Data Block | 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 | Next Context Data Block | 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | ........ | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Type CTD = 3 (Context Transfer Data) 526 PCTD = 4 (Predictive Context Transfer Data) 528 'V' flag When set to '00', indicate presence of IPv6 529 Previous (New) address only. 530 When set to '01' indicate presence of IPv4 531 Previous (New) Address only. 532 When set to '10' indicate presence of both 533 IPv6 and IPv4 Previous (New) addresses. 535 'A' bit The MN requests an acknowledgement. 537 Length message length in units of 8 538 octet words 540 Reserved Reserved for future use. Must be set to 541 zero by the pAR. 543 Elapsed Time The number of milliseconds since the 544 transmission of the first CTD message. 546 MN's Prev CoA Address Field contains either: 547 IPv4 Address as defined in [RFC 791], 548 IPv6 Address as defined in [RFC 2373]. 550 MN's New CoA Address Field contains either: 552 IPv4 Address as defined in [RFC 791], 553 IPv6 Address as defined in [RFC 2373]. 554 This is only applicable for the PCTD 555 message. 557 Algorithm Algorithm for carrying out the computation 558 of the MN Authorization Token. Currently 559 only 1 algorithm is defined, HMAC_SHA1 = 1. 561 Key Length Length of key, in octets. 563 When CTD is sent predictively, the supplied parameters including the 564 algorithm, key length and the key itself, allow nAR to compute a 565 token locally and verify against the token present in the CTAR 566 message. This message MUST be protected by IPsec. 568 As described previously, the algorithm for carrying out the 569 computation of the MN Authorization Token is HMAC_SHA1. The input 570 data for computing the token are: the MN's Previous IP address, the 571 FPT objects and the Replay field. When support for transferring all 572 contexts is requested, a default FPT is used. The Authorization Token 573 is obtained by truncating the results of the HMAC_SHA1 computation to 574 retain only the leading 32 bits. 576 2.5.4 Context Transfer Data Reply (CTDR) Message 578 This message is sent by nAR to pAR depending on the value of the 579 reliability flag in CTD. Indicates success or failure. 581 0 1 2 3 582 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 583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 584 | Type=CTDR | Length | V |S| Reserved | 585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 | Mobile Node's Previous IP Address | 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | FPT (if present) | Status code | Reserved | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | ....... | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Type CTDR = 5 (Context Transfer Data) 595 Length Message length in units of 8 596 octet words 598 'V' flag When set to '00', indicate presence of IPv6 599 Previous address only. 601 When set to '01' indicate presence of IPv4 602 Previous Address only. 603 When set to '10' indicate presence of both 604 IPv6 and IPv4 Previous addresses. 606 'S' bit When set to one, this bit indicates that all 607 the feature contexts sent in CTD or PCTD were 608 received successfully. 610 Reserved Reserved for future use. Must be set to zero 611 by the nAR. 613 MN's Prev IP Address Field contains either: 614 IPv4 Address as defined in [RFC 791]. 615 IPv6 Address as defined in [RFC 2373]. 617 Status Code A context-specific return value, present 618 when 'S' is not set to one. 620 FPT 16 bit integer, listing the FTP that is being 621 acknowledged. 623 Status Code 0 = not successfully transfered 624 1 = successfully transfered 626 2.5.5 Context Transfer Cancel (CTC) Message 628 If transferring a context cannot be completed in a timely fashion, 629 then nAR may send CTC to pAR to cancel an ongoing CT process. 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Type=CTC | Length | Reserved | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Mobile Node's Previous Care-of Address | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 Type CTC = 6 (Context Transfer Data) 641 Length Message length in units of 8 642 octet words 644 Reserved Reserved for future use. Must be set to zero 645 by the nAR. 647 2.5.6 Context Transfer Request (CT Request) Message 648 Sent by nAR to pAR to request start of context transfer. This message 649 is sent as a response to CTAR message by the MN. The fields following 650 the Previous IP address of the MN are included verbatim from the CTAR 651 message. 653 0 1 2 3 654 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 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | Type=CTREQ | Length | V | Reserved | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | Mobile Node's Previous IP Address | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | Replay | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | MN Authorization Token | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | Requested Context Data Block (if present) | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Next Requested Context Data Block (if present) | 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 | ........ | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 Type CTREQ = 7 673 Length Message length in units of 8 674 octet words 676 'V' bits When set to '00', indicate presence of IPv6 677 Previous (New) address only. 678 When set to '01' indicate presence of IPv4 679 Previous (New) Address only. 680 When set to '10' indicate presence of both 681 IPv6 and IPv4 Previous (New) addresses. 683 Reserved Reserved for future use. Must be set to zero 684 by the nAR. 686 Replay A value used to make sure that each use of the 687 CTAR message is uniquely identifiable. 688 Copied from CTAR. 690 Authorization Token An unforgeable value calculated as discussed 691 above. This authorizes the receiver of CTAR 692 to perform context transfer. Copied from 693 CTAR. 695 3. Transport, Reliability and Retransmission of Feature Data 697 CTP runs over UDP using port number . Some feature contexts may 698 specify a reliability factor, MAX_RETRY_INTERVAL, which is the length 699 of time that the pAR is allowed to perform retransmissions before 700 giving up on the context transfer for that feature context. The 701 longer the allowed retry interval, the more retransmissions will be 702 possible for that feature context. 704 For feature contexts that specify MAX_RETRY_INTERVAL, pAR SHOULD 705 retransmit an unacknowledged CTD message after waiting for 706 RETRANSMISSION_DELAY milliseconds. This time value is configurable 707 based on the type of network interface; slower network media 708 naturally will be configured with longer values for the 709 RETRANSMISSION_DELAY. Except for the value of the elapsed time field, 710 the payload of each retransmitted CTD packet is identical to the 711 payload of the initially transmitted CTD packet, in order to maintain 712 the ability of the mobile device to present a correctly calculated 713 authentication token. The number of retransmissions, each delayed by 714 RETRANSMISSION_DELAY, depends on the maximum value for 715 MAX_RETRY_INTERVAL as specified by any of the contexts. The value 716 of the Elapsed Time field is the number of milliseconds since the 717 transmission of the first CTD message 719 UDP provides an optional checksum, which SHOULD be checked. If the 720 checksum is incorrect, nAR SHOULD return a CTDR packet to pAR with 721 the status value BAD_UDP_CHECKSUM, even if the 'A' bit is not set in 722 the CTD. 724 4. Error Codes 726 This section lists error codes used by UDP 728 BAD_UDP_CHECKSUM 0x01 730 5. Examples and Signaling Flows 732 5.1 Network controlled, Initiated by pAR 734 MN nAR pAR 735 | | | 736 T | | CT trigger 737 I | | | 738 M | |<------- CTD ----------| 739 E |--------CTAR--------->| | 740 : | | | 741 | | |-------- CTDR -------->| 742 V | | | 743 | | | 745 5.2 Network controlled, initiated by nAR 747 in 6 748 MN nAR pAR 749 | | | 750 T | CT trigger | 751 I | | | 752 M | |----- CT Request ----->| 753 E | | | 754 : | |<------- CTD ----------| 755 | | | | 756 V |--------CTAR--------->| | 757 | |----- CTDR (opt) ----->| 758 | | | 760 5.3 Mobile controlled, Predictive New L2 up/old L2 down 762 CTAR request to nAR 764 MN nAR pAR 765 | | | 766 new L2 link up | | 767 | | | 768 CT trigger | | 769 | | | 770 T |--------CTAR ------->| | 771 I | |---- CT Request ------>| 772 M | | | 773 E | |<-------- CTD ---------| 774 : | | | 775 | | | | 776 V | | | 777 | | | 779 In case CT cannot be supported, a CTAR reject (TBD) may be sent to 780 the MN by nAR. 782 6. Security Considerations 784 At this time, the threats to IP handover in general and context 785 transfer in particular are incompletely understood, particularly on 786 the MN to AR link, and mechanisms for countering them are not well 787 defined. Part of the experimental task in preparing CTP for eventual 788 standards track will be to better characterize threats to context 789 transfer and design specific mechanisms to counter them. This section 790 provides some general guidelines about security based on discussions 791 among the Design Team and Working Group members. 793 6.1. Threats. 795 The Context Transfer Protocol transfers state between access routers. 796 If the mobile nodes are not authenticated and authorized before 797 moving on the network, there is a potential for DoS attacks to shift 798 state between ARs, causing network disruptions. 800 Additionally, DoS attacks can be launched from mobile nodes towards 801 the access routers by requesting multiple context transfers and then 802 disappearing. Additionally, a rogue access router could flood mobile 803 nodes with packets, attempting DoS attacks. 805 6.2. Security Details 807 CTP relies on IETF standardized security mechanisms for protecting 808 traffic between access routers, as opposed to creating application 809 security mechanisms. IPsec MUST be supported between access routers. 811 In order to avoid the introduction of additional latency to context 812 transfer due to the need for establishment of secure channel between 813 the context transfer peers (ARs), the two ARs SHOULD establish such 814 secure channel in advance. If IPSec is used, for example, the two 815 access routers need to engage in a key exchange mechanisms such as 816 IKE [RFC2409], establish IPSec SAs, defining the keys, algorithms and 817 IPSec protocols (such as ESP) in anticipation for any upcoming 818 context transfer. This will save time during handovers that require 819 secure transfer of mobile node's context(s). Such SAs can be 820 maintained and used for all upcoming context transfers between the 821 two ARs. Security should be negotiated prior to the sending of 822 context. 824 Furthermore, either one or both of the pAR and nAR need to be able to 825 authenticate the mobile and authorize mobile's credential before 826 authorizing the context transfer and release of context to the 827 mobile. In case the context transfer is request by the MN, a 828 mechanism MUST be provided so that requests are authenticated 829 (regardless of the security of context transfer itself) to prevent 830 the possibility of rogue MNs launching DoS attacks by sending large 831 number of CT requests as well as cause large number of context 832 transfers between ARs. Another important consideration is that the 833 mobile node should claim it's own context, and not some other 834 masquerader. One method to achieve this is to provide an 835 authentication cookie to be included with the context transfer 836 message sent from the pAR to the nAR and confirmed by the mobile node 837 at the nAR. 839 6.3. IPsec Considerations 841 Access Routers MUST implement IPsec ESP [ESP] in transport mode with 842 non-null encryption and authentication algorithms to provide per- 843 packet authentication, integrity protection and confidentiality, and 844 MUST implement the replay protection mechanisms of IPsec. In those 845 scenarios where IP layer protection is needed, ESP in tunnel mode 846 SHOULD be used. Non-null encryption should be used when using IPSec 847 ESP. 849 7. IANA Considerations 851 This section provides guidance to the Internet Assigned Numbers 852 Authority (IANA) regarding registration of values related to the 853 context transfer protocol, in accordance with BCP 26 [RFC2434]. 855 7.1 Context Profile Types Registry 857 This document authorized IANA to create a registry for Context 858 Profile Types, introduced in this document. For future Context 859 Profile Types, it is recommended that allocations be done on the 860 basis of Designated Expert. 862 The Context Profile Type introduced in this document requires IANA 863 Type Numbers for each set of feature contexts that make use of 864 Profile Types. 866 For registration requests where a Designated Expert should be 867 consulted, the responsible IESG area director should appoint the 868 Designated Expert. 870 7.2 UDP Port 872 CTP requires a UDP port assignment. 874 8. Acknowledgements & Contributors 876 This document is the result of a design team formed by the Working 877 Group chairs of the SeaMoby working group. The team included John 878 Loughney, Madjid Nakhjiri, Rajeev Koodli and Charles Perkins. 880 Contributors to the Context Transfer Protocol review are Basavaraj 881 Patil, Pekka Savola, and Antti Tuominen. 883 The working group chairs are Pat Calhoun and James Kempf, whose 884 comments have been very helpful during the creation of this 885 specification. 887 The authors would also like to thank Julien Bournelle, Vijay 888 Devarapalli, Dan Forsberg, Xiaoming Fu, Michael Georgiades, Yusuf 889 Motiwala, Phil Neumiller, Hesham Soliman and Lucian Suciu for their 890 help and suggestions with this document. 892 9. References 894 9.1 Normative References 896 [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", 897 BCP 9, RFC 2026, October 1996. 899 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Require- 900 ment Levels", BCP 14, RFC 2119, March 1997. 902 [RFC2434] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 903 Considerations Section in RFCs", BCP 26, RFC 2434, October 904 1998. 906 [RFC2409] D. Harkins, D. Carrel, "The Internet Key Exchange (IKE)", 907 RFC 2409, November 1998. 909 [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Pay- 910 load (ESP)", RFC 2406, November 1998. 912 9.2 Non-Normative References 914 [CTHC] R. Koodli et al., "Context Relocation for Seamless Header 915 Compression in IP Networks", Internet Draft, Internet 916 Engineering Task Force, Work in Progress. 918 [FMIPv6] R. Koodli (Ed), "Fast Handovers for Mobile IPv6", Internet 919 Engineering Task Force. Work in Progress. 921 [LLMIP] K. El Malki et. al, "Low Latency Handoffs in Mobile IPv4", 922 Internet Engineering Task Force. Work in Progress. 924 [RFC3374] J. Kempf et al., "Problem Description: Reasons For Performing 925 Context Transfers Between Nodes in an IP Access Network", RFC 926 3374, Internet Engineering Task Force, RFC 3374, May 2001. 928 [RFC2401] S. Kent, R. Atkinson, "Security Architecture for the Internet 929 Protocol", RFC 2401, November 1998. 931 [TERM] J. Manner, M. Kojo, "Mobility Related Terminology", Internet 932 Engineering Task Force, Work in Progress. 934 [RFC2710] Deering, S., Fenner, W., and Haberman, B., " Multicast 935 Listener Discovery (MLD) for IPv6," RFC 2710, October, 1999. 937 [RFC2461] Narten, T., Nordmark, E., and Simpson. W., "Neighbor Discovery 938 for IP Version 6 (IPv6)," RFC 2461, December, 1998. 940 [RFC2462] Thompson, S., and Narten, T., "IPv6 Address Autoconfiguration," 941 RFC 2462, December, 1998. 943 Appendix A. Timing and Trigger Considerations 945 Basic Mobile IP handover signaling can introduce disruptions to the 946 services running on top of Mobile IP, which may introduce unwanted 947 latencies that practically prohibit its use for certain types of ser- 948 vices. Mobile IP latency and packet loss is being optimized through 949 several alternative procedures, such as Fast Mobile IP [FMIPv6] and 950 Low Latency Mobile IP [LLMIP]. 952 Feature re-establishment through context transfer should contribute 953 zero (optimally) or minimal extra disruption of services in conjunc- 954 tion to handovers. This means that the timing of context transfer 955 SHOULD be carefully aligned with basic Mobile IP handover events, and 956 with optimized Mobile IP handover signaling mechanisms, as those pro- 957 tocols become available. 959 Furthermore, some of those optimized mobile IP handover mechanisms 960 may provide more flexibility is choosing the timing and order for 961 transfer of various context information. 963 Appendix B. Multicast Listener Context Transfer 965 As an example of how context transfer can improve the performance of 966 IP layer handover, we consider transferring IPv6 MLD state [RFC2710]. 967 MLD state is a particularly good example because every IPv6 node must 968 perform two MLD messaging sequences on the wireless link to establish 969 itself as an MLD listener prior to performing router discovery 970 [RFC2461] or duplicate address detection [RFC2462] or before 971 sending/receiving any application-specific traffic (including Mobile 972 IP handover signaling, if any). The node must subscribe to the Soli- 973 cited Node Multicast Address as soon as it comes up on the link. Any 974 application-specific multicast addresses must be re-established as 975 well. Context transfer can significantly speed up re-establishing 976 multicast state by allowing the nAR to initialize MLD for a node that 977 just completed handover; without any MLD signaling on the new wire- 978 less link. The same approach could be used for transferring multicast 979 context in IPv4. 981 An approximate qualitative estimate for the amount of savings in 982 handover time can be obtained as follows. MLD messages are 24 bytes, 983 to which the headers must be added, because there is no header 984 compression on the new link, with IPv6 header being 40 bytes, and a 985 required Router Alert Hop-by-Hop option being 8 bytes including pad- 986 ding. The total MLD message size is 72 bytes per subscribed multicast 987 address. RFC 2710 recommends that nodes send 2 to 3 MLD Report mes- 988 sages per address subscription, since the Report message is unack- 989 nowledged. Assuming 2 MLD messages sent for a subscribed address, the 990 mobile node would need to send 144 bytes per address subscription. If 991 MLD messages are sent for both the All Nodes Multicast Address and 992 the Solicited Node Multicast address for the node's link local 993 address, a total of 288 bytes are required when the node hands over 994 to the new link. Note that some implementations of IPv6 optimize by 995 not sending an MLD message for the All Nodes Multicast Address, since 996 the router can infer that at least one node is on the link (itself) 997 when it comes up and always will be, but for purposes of this calcu- 998 lation, we assume that the IPv6 implementation is conformant and that 999 the message is sent. The amount of time required for MLD signaling 1000 will, of course, depend on the wireless link bandwidth, but some 1001 representative numbers can be obtained by assuming bandwidths of 20 1002 kbps or 100 kbps. The former is approximate for a narrowband 3G cel- 1003 lular links and the latter for a heavily utilized 802.11b WLAN link, 1004 both running Voice over IP (VoIP). With these two bit rates, the sav- 1005 ings from not having to perform the pre-router discovery messages are 1006 115 msec. and 23 msec., respectively. If any application-specific 1007 multicast addresses are subscribed, the amount of time saved could be 1008 substantially more. Considering most ATM-based 3G voice cellular pro- 1009 tocols try to keep total voice handover delay less than 40- 80 msec., 1010 MLD signaling could have a large impact on the performance of inter- 1011 subnet VoIP handover. 1013 The context-specific data field for MLD context transfer included in 1014 the CTP Context Data Block message for a single IPv6 multicast 1015 address has the following format: 1017 0 1 2 3 1018 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 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | | 1021 + Subnet Prefix on nAR Wireless Interface + 1022 | | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | | 1025 + + 1026 | | 1027 + Subscribed IPv6 Multicast Address + 1028 | | 1029 + + 1030 | | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 The Subnet Prefix on nAR Wireless Interface field contains a subnet 1034 prefix that identifies the interface on which multicast routing 1035 should be established. The Subscribed IPv6 Multicast Address field 1036 contains the multicast address for which multicast routing should be 1037 established. 1039 The pAR sends one MLD context block per subscribed IPv6 multicast 1040 address. 1042 No changes are required in the MLD state machine. 1044 Upon receipt of a CTP Context Data Block for MLD, the state machine 1045 takes the following actions: 1047 - If the router is in the No Listeners present state on the wireless 1048 interface on which the Subnet Prefix field from the Context Data 1049 Block is advertised, it transitions into the Listeners Present 1050 state for the Subscribed IPv6 Multicast Address field in the Con- 1051 text Data Block. This transition is exactly the same as if the 1052 router had received a Report message. 1054 - If the router is in the Listeners present state on that interface, 1055 it remains in that state but restarts the timer, as if it had 1056 received a Report message. 1058 If more than one MLD router is on the link, a router receiving an MLD 1059 Context Data Block SHOULD send the block to the other routers on the 1060 link. The router MAY instead send a proxy MLD Report message on the 1061 wireless interface that advertises the Subnet Prefix field from the 1062 Context Data Block if wireless bandwidth is not an issue. Since MLD 1063 routers do not keep track of which nodes are listening to munticast 1064 addresses, only whether a particular multicast address is being 1065 listened to, proxying the subscription should cause no difficulty. 1067 Authors' Addresses 1069 Rajeev Koodli 1070 Nokia Research Center 1071 313 Fairchild Drive 1072 Mountain View, California 94043 1073 USA 1074 Rajeev.koodli@nokia.com 1076 John Loughney 1077 Nokia 1078 Itdmerenkatu 11-13 1079 00180 Espoo 1080 Finland 1081 john.loughney@nokia.com 1083 Madjid F. Nakhjiri 1084 Motorola Labs 1085 1031 East Algonquin Rd., Room 2240 1086 Schaumburg, IL, 60196 1087 USA 1088 madjid.nakhjiri@motorola.com 1090 Charles E. Perkins 1091 Nokia Research Center 1092 313 Fairchild Drive 1093 Mountain View, California 94043 1094 USA 1095 charliep@iprg.nokia.com 1097 Intellectual Property Considerations 1099 The IETF takes no position regarding the validity or scope of any 1100 intellectual property or other rights that might be claimed to per- 1101 tain to the implementation or use of the technology described in this 1102 document or the extent to which any license under such rights might 1103 or might not be available; neither does it represent that it has made 1104 any effort to identify any such rights. Information on the IETF's 1105 procedures with respect to rights in standards-track and standards- 1106 related documentation can be found in BCP-11. Copies of claims of 1107 rights made available for publication and any assurances of licenses 1108 to be made available, or the result of an attempt made to obtain a 1109 general license or permission for the use of such proprietary rights 1110 by implementers or users of this specification can be obtained from 1111 the IETF Secretariat. 1113 The IETF invites any interested party to bring to its attention any 1114 copyrights, patents or patent applications, or other proprietary 1115 rights which may cover technology that may be required to practice 1116 this standard. Please address the information to the IETF Executive 1117 Director.