idnits 2.17.1 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 67 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2012) is 4206 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 800 -- Looks like a reference, but probably isn't: '2' on line 806 == Missing Reference: 'M' is mentioned on line 816, but not defined == Unused Reference: 'RFC1112' is defined on line 983, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt 3 Internet-Draft HAW Hamburg 4 Intended status: Standards Track M. Waehlisch 5 Expires: April 23, 2013 link-lab & FU Berlin 6 R. Koodli 7 Cisco Systems 8 G. Fairhurst 9 University of Aberdeen 10 October 20, 2012 12 Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers 13 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07 15 Abstract 17 Fast handover protocols for MIPv6 and PMIPv6 define mobility 18 management procedures that support unicast communication at reduced 19 handover latency. Fast handover base operations do not affect 20 multicast communication, and hence do not accelerate handover 21 management for native multicast listeners. Many multicast 22 applications like IPTV or conferencing, though, are comprised of 23 delay-sensitive real-time traffic and will benefit from fast handover 24 execution. This document specifies extension of the Mobile IPv6 Fast 25 Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 26 (PFMIPv6) protocols to include multicast traffic management in fast 27 handover operations. This multicast support is provided first at the 28 control plane by a management of rapid context transfer between 29 access routers, second at the data plane by an optional fast traffic 30 forwarding that MAY include buffering. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 23, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Multicast Context Transfer between Access Routers . . . . 6 70 3.2. Protocol Operations Specific to FMIPv6 . . . . . . . . . . 8 71 3.3. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 10 72 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1. Protocol Operations Specific to FMIPv6 . . . . . . . . . . 13 74 4.1.1. Operations of the Mobile Node . . . . . . . . . . . . 13 75 4.1.2. Operations of the Previous Access Router . . . . . . . 14 76 4.1.3. Operations of the New Access Router . . . . . . . . . 15 77 4.2. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 15 78 4.2.1. Operations of the Mobile Node . . . . . . . . . . . . 15 79 4.2.2. Operations of the Previous MAG . . . . . . . . . . . . 15 80 4.2.3. Operations of the New MAG . . . . . . . . . . . . . . 16 81 4.2.4. IPv4 Support Considerations . . . . . . . . . . . . . 17 82 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 18 83 5.1. Multicast Indicator for Proxy Router Advertisement 84 (PrRtAdv) . . . . . . . . . . . . . . . . . . . . . . . . 18 85 5.2. Extensions to Existing Mobility Header Messages . . . . . 18 86 5.3. New Multicast Mobility Option . . . . . . . . . . . . . . 18 87 5.4. New Multicast Acknowledgement Option . . . . . . . . . . . 20 88 5.5. Length Considerations: Number of Records and Addresses . . 22 89 5.6. MLD (IGMP) Compatibility Aspects . . . . . . . . . . . . . 22 90 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 92 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 93 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 94 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 95 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 97 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 100 1. Introduction 102 Mobile IPv6 [RFC3775] defines a network layer mobility protocol 103 involving mobile nodes participation, while Proxy Mobile IPv6 104 [RFC5213] provides a mechanism without requiring mobility protocol 105 operations at a Mobile Node (MN). Both protocols introduce traffic 106 disruptions on handovers that may be intolerable in many application 107 scenarios. Mobile IPv6 Fast Handovers (FMIPv6) [RFC5568], and Fast 108 Handovers for Proxy Mobile IPv6 (PFMIPv6) [RFC5949] improve these 109 handover delays for unicast communication to the order of the maximum 110 delay needed for link switching and signaling between Access Routers 111 (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. 113 No dedicated treatment of seamless multicast data reception has been 114 proposed by any of the above protocols. MIPv6 only roughly defines 115 multicast for Mobile Nodes using a remote subscription approach or a 116 home subscription through bi-directional tunneling via the Home Agent 117 (HA). Multicast forwarding services have not been specified at all 118 in [RFC5213], but are subject to current specification [RFC6224]. It 119 is assumed throughout this document that mechanisms and protocol 120 operations are in place to transport multicast traffic to ARs. These 121 operations are referred to as 'JOIN/LEAVE' of an AR, while the 122 explicit techniques to manage multicast transmission are beyond the 123 scope of this document. 125 Mobile multicast protocols need to serve applications such as IPTV 126 with high-volume content streams to be distributed to potentially 127 large numbers of receivers, and therefore should preserve the 128 multicast nature of packet distribution and approximate optimal 129 routing [RFC5757]. It is undesirable to rely on home tunneling for 130 optimizing multicast. Unencapsulated, native multicast transmission 131 requires establishing forwarding state, which will not be transferred 132 between access routers by the unicast fast handover protocols. Thus 133 multicast traffic will not experience expedited handover performance, 134 but an MN - or its corresponding MAG in PMIPv6 - can perform remote 135 subscriptions in each visited network. 137 This document specifies extensions of FMIPv6 and PFMIPv6 for 138 including multicast traffic management in fast handover operations. 139 The solution common to both underlying protocols defines the per- 140 group transfer of multicast contexts between ARs or MAGs. The 141 protocol defines corresponding message extensions necessary for 142 carrying group context information independent of the particular 143 handover protocol. ARs or MAGs are then enabled to treat multicast 144 traffic according to fast unicast handovers and with similar 145 performance. No protocol changes are introduced that prevent a 146 multicast unaware node from performing fast handovers with multicast 147 aware ARs or MAGs. 149 This specification is applicable when a mobile node has joined and 150 maintains one or several multicast group subscriptions prior to 151 undergoing a fast handover. It does not introduce any requirements 152 on the multicast routing protocols in use, nor are the ARs or MAGs 153 assumed to be multicast routers. It assumes network conditions, 154 though, that allow native multicast reception in both, the previous 155 and new access network. Methods to bridge regions without native 156 multicast connectivity are beyond the scope of this document. 158 2. Terminology 160 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 161 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 162 document are to be interpreted as described in RFC 2119 [RFC2119]. 163 The use of the term, "silently ignore" is not defined in RFC 2119. 164 However, the term is used in this document and can be similarly 165 construed. 167 This document uses the terminology of [RFC5568], [RFC5949], 168 [RFC3775], and [RFC5213]. In addition, the following terms are 169 introduced: 171 3. Protocol Overview 173 The reference scenario for multicast fast handover is illustrated in 174 Figure 1. 176 *** *** *** *** 177 * ** ** ** * 178 * * 179 * Multicast Cloud * 180 * * 181 * ** ** ** * 182 *** *** *** *** 183 / \ 184 / \ 185 / \ 186 +........../..+ +..\..........+ 187 . +-------+-+ .______. +-+-------+ . 188 . | PAR |()_______)| NAR | . 189 . | (PMAG) | . . | (NMAG) | . 190 . +----+----+ . . +----+----+ . 191 . | . . | . 192 . ___|___ . . ___|___ . 193 . / \ . . / \ . 194 . ( P-AN ) . . ( N-AN ) . 195 . \_______/ . . \_______/ . 196 . | . . | . 197 . +----+ . . +----+ . 198 . | MN | ----------> | MN | . 199 . +----+ . . +----+ . 200 +.............+ +.............+ 202 Figure 1: Reference Network for Fast Handover 204 3.1. Multicast Context Transfer between Access Routers 206 In a fast handover scenario (cf. Figure 1), ARs/MAGs establish a 207 mutual binding and provide the capability to exchange context 208 information concerning the MN. This context transfer will be 209 triggered by detecting MN's forthcoming move to a new AR and assist 210 the MN to immediately resume communication on the new subnet link 211 using its previous IP address. In contrast to unicast, multicast 212 stream reception does not primarily depend on address and binding 213 cache management, but requires distribution trees to adapt so that 214 traffic follows the movement of the MN. This process may be 215 significantly slower than fast handover management [RFC5757]. 216 Multicast listeners at handover may take the twofold advantage of 217 including the multicast groups under subscription in context 218 transfer. First, the NAR can proactively join the desired groups as 219 soon as it gains knowledge of them. Second, multicast streams MAY be 220 included in traffic forwarding via the tunnel established from PAR to 221 NAR. 223 There are two modes of operation in FMIPv6 and in PFMIPv6. The 224 predictive mode allows for AR-binding and context transfer prior to 225 an MN handover, while in the reactive mode, these steps are executed 226 after detection that the MN has re-attached to NAR. Details of the 227 signaling schemes differ between FMIPv6 and PFMIPv6 and are outlined 228 in Section 3.2 and Section 3.3. 230 In a predictive fast handover, the access router (i.e., PAR (PMAG) in 231 Figure 1) learns about the impending movement of the MN and 232 simultaneously about the multicast group context as specified in 233 Section 3.2 and Section 3.3. Thereafter, PAR will initiate an AR- 234 binding and context transfer by transmitting a HI message to NAR 235 (NMAG). HI is extended by multicast group states carried in mobility 236 header options as defined in Section 5.3. On reception of the HI 237 message, NAR returns a multicast acknowledgement in its HACK answer 238 that indicates its ability to support each requested group (see 239 Section 5.4). NAR (NMAG) expresses its willingness to receive 240 multicast traffic from forwarding by PAR using standard MLD 241 signaling. There are several reasons to waive forwarding, e.g., the 242 group could already be under native subscription or capacity 243 constraints can hinder decapsulation of additional streams at the 244 NAR. On the previous network side, forwarding of multicast traffic 245 can be in conflict with capacity or policy constraints of PAR. 247 For the groups requested, PAR MAY add the tunnel interface to its 248 multicast forwarding database, so that multicast streams can be 249 forwarded in parallel to unicast traffic. NAR, taking the role of an 250 MLD proxy [RFC4605] with upstream router PAR, will submit an MLD 251 report on this upstream tunnel interface to request the desired 252 groups, but will terminate multicast forwarding [RFC3810] from PAR, 253 as soon as group traffic natively arrives. In addition, NAR 254 immediately joins all groups that are not already under subscription 255 using its native multicast upstream interface and loopback as 256 downstream. It starts to downstream multicast forwarding after the 257 MN has arrived. 259 In a reactive fast handover, PAR will learn about the movement of the 260 MN, after the latter has re-associated with the new access network. 261 Also from the new link, it will be informed about the multicast 262 context of the MN. As group membership information are present at 263 the new access network prior to context transfer, MLD join signaling 264 can proceed in parallel to HI/HACK exchange. Following the context 265 transfer, multicast data can be forwarded to the new access network 266 using the PAR-NAR tunnel of the fast handover protocol. Depending on 267 the specific network topology though, multicast traffic for some 268 groups may natively arrive before it is forwarded from PAR. 270 In both modes of operation, it is the responsibility of the PAR 271 (PMAG) to properly react on the departure of the MN in the context of 272 local group management. Depending on the multicast state management, 273 link type and MLD parameters deployed (cf., [RFC5757]), it is 274 requested to take appropriate actions to adjust multicast service to 275 requirements of the remaining nodes. 277 In this way, the MN will be able to participate in multicast group 278 communication with a handover performance comparable to that for 279 unicast, while network resource consumption is minimized. 281 3.2. Protocol Operations Specific to FMIPv6 283 ARs that provide multicast support in FMIPv6 will advertise this 284 general service by setting an indicator bit (M-bit) in its PrRtAdv 285 message as defined in Section 5.1. Additional details about the 286 multicast service support, e.g., flavors and groups, will be 287 exchanged within HI/HACK dialogs later at handovers. 289 An MN operating FMIPv6 will actively initiate the handover management 290 by submitting a fast binding update (FBU). The MN, which is aware of 291 the multicast groups it wishes to maintain, will attach mobility 292 options containing its group states (see Section 5.3) to the FBU, and 293 thereby inform ARs about its multicast context. ARs will use these 294 multicast context options for inter-AR context transfer. 296 In predictive mode, FBU is issued on the previous link and received 297 by PAR as displayed in Figure 2. PAR will extract the multicast 298 context options and append them to its HI message. From the HACK 299 message, PAR will redistribute the multicast acknowledgement by 300 adding the corresponding mobility options to its FBACK message. From 301 receiving FBACK, the MN will learn about a per group multicast 302 support in the new access network. If some groups or a multicast 303 flavour are not supported, it MAY decide on taking actions to 304 compensate the missing service. Note that the proactive multicast 305 context transfer may proceed successfully, even if the MN misses the 306 FBACK message on the previous link. 308 MN PAR NAR 309 | | | 310 |------RtSolPr------->| | 311 |<-----PrRtAdv--------| | 312 | | | 313 | | | 314 |---------FBU-------->|----------HI--------->| 315 | (Multicast MobOpt) | (Multicast MobOpt) | 316 | | | 317 | |<--------HAck---------| 318 | | (Multicast AckOpt) | 319 | | Join to 320 | | Multicast 321 | | Groups 322 | | | 323 | <-----FBack---|--FBack------> | 324 | (Multicast AckOpt) | (Multicast AckOpt) | 325 | | | 326 disconnect optional | 327 | packet ================>| 328 | forwarding | 329 | | | 330 connect | | 331 | | | 332 |------------UNA --------------------------->| 333 |<=================================== deliver packets 334 | | 336 Figure 2: Predictive Multicast Handover for FMIPv6 338 The call flow for reactive mode is visualized in Figure 3. After 339 attaching to the new access link and performing an unsolicited 340 neighbor advertisement (UNA), the MN issues an FBU which NAR forwards 341 to PAR without processing. At this time, the MN is able to re-join 342 all desired multicast groups without relying on AR assistance. 343 Nevertheless, multicast context options are exchanged in the HI/HACK 344 dialog to facilitate intermediate forwarding of requested streams. 345 Note that group traffic possibly already arrives from a MN's 346 subscription at the time NAR receives the HI message. Such streams 347 may be transparently excluded from forwarding by setting an 348 appropriate multicast acknowledge option. In any case, NAR MUST 349 ensure that not more than one stream of the same group is forwarded 350 to the MN. 352 MN PAR NAR 353 | | | 354 |------RtSolPr------->| | 355 |<-----PrRtAdv--------| | 356 | | | 357 disconnect | | 358 | | | 359 | | | 360 connect | | 361 |-------UNA-----------|--------------------->| 362 |-------FBU-----------|---------------------)| 363 | (Multicast MobOpt) |<-------FBU----------)| 364 | | | 365 Join to | | 366 Multicast | | 367 Groups | | 368 | |----------HI--------->| 369 | | (Multicast MobOpt) | 370 | |<-------HAck----------| 371 | | (Multicast AckOpt) | 372 | | | 373 | |(HI/HAck if necessary)| 374 | | | 375 | FBack, optional | 376 | packet forwarding ==========>| 377 | | | 378 |<=================================== deliver packets 379 | | 381 Figure 3: Reactive Multicast Handover for FMIPv6 383 3.3. Protocol Operations Specific to PFMIPv6 385 In a proxy mobile IPv6 environment, the MN remains agnostic of 386 network layer changes, and fast handover procedures are operated by 387 the access routers or MAGs. The handover initiation, or the re- 388 association respectively are managed by the access networks. 389 Consequently, access routers need to be aware of multicast membership 390 state at the mobile node. There are two ways to obtain record of 391 MN's multicast membership. First, MAGs MAY perform an explicit 392 tracking (cf., [RFC4605], [RFC6224]) or extract membership status 393 from forwarding states at node-specific point-to-point links. 394 Second, routers can perform general queries at handovers. Both 395 methods are equally applicable. However, a router that does not 396 operate explicit tracking MUST query its downstream links subsequent 397 to handovers. In either case, the PAR will become knowledgeable 398 about multicast group subscriptions of the MN. 400 In predictive mode, the PMAG (PAR) will learn about the upcoming 401 movement of the mobile node. Without explicit tracking, it will 402 immediately submit a general MLD query and learn about the multicast 403 groups under subscription. As displayed in Figure 4, it will 404 initiate binding and context transfer with the NMAG (NAR) by issuing 405 a HI message that is augmented by multicast contexts in the mobility 406 options defined in Section 5.3. NAR will extract multicast context 407 information and act as described in Section 3.1. 409 PMAG NMAG 410 MN P-AN N-AN (PAR) (NAR) 411 | | | | | 412 | Report | | | | 413 |---(MN ID,-->| | | | 414 | New AP ID) | | | | 415 | | HO Indication | | 416 | |--(MN ID, New AP ID)-->| | 417 | | | | | 418 | | | Optional: | 419 | | | MLD Query | 420 | | | | | 421 | | | |------HI---->| 422 | | | |(Multicast MobOpt) 423 | | | | | 424 | | | |<---HAck-----| 425 | | | |(Multicast AckOpt) 426 | | | | | 427 | | | | Join to 428 | | | | Multicast 429 | | | | Groups 430 | | | | | 431 | | | |HI/HAck(optional) 432 | | | |<- - - - - ->| 433 | | | | | 434 | | | optional packet | 435 | | | forwarding =======>| 436 disconnect | | | | 437 | | | | | 438 connect | | | | 439 | MN-AN connection | AN-MAG connection | 440 |<----establishment----->|<----establishment------->| 441 | | | (substitute for UNA) | 442 | | | | | 443 |<========================================== deliver packets 444 | | | | | 445 Figure 4: Predictive Multicast Handover for PFMIPv6 447 In reactive mode, the NMAG (NAR) will learn about MN's attachment to 448 the N-AN and establish connectivity by means of PMIPv6 protocol 449 operations. However, it will have no knowledge about multicast state 450 at the MN. Triggered by a MN attachment, the NMAG will send a 451 general MLD query and thereafter join the requested groups. In the 452 case of a reactive handover, the binding is initiated by NMAG, and 453 the HI/HACK message semantic is inverted (see [RFC5949]). For 454 multicast context transfer, the NMAG attaches to its HI message those 455 group identifiers it requests to be forwarded from PMAG. Using the 456 identical syntax in its multicast mobility option headers as defined 457 in Section 5.4, PMAG acknowledges those requested groups in its HACK 458 answer that it is willing to forward . The corresponding call flow 459 is displayed in Figure 5. 461 PMAG NMAG 462 MN P-AN N-AN (PAR) (NAR) 463 | | | | | 464 disconnect | | | | 465 | | | | | 466 connect | | | | 467 | | | | | 468 | MN-AN connection | AN-MAG connection | 469 |<---establishment---->|<----establishment------->| 470 | | |(substitute for UNA & FBU)| 471 | | | | | 472 | | | | MLD Query 473 | | | | | 474 | | | | Join to 475 | | | | Multicast 476 | | | | Groups 477 | | | | 478 | | | |<------HI----| 479 | | | |(Multicast MobOpt) 480 | | | | | 481 | | | |---HAck----->| 482 | | | |(Multicast AckOpt) 483 | | | | | 484 | | | | | 485 | | | |HI/HAck(optional) 486 | | | |<- - - - - ->| 487 | | | | | 488 | | | optional packet | 489 | | | forwarding =======>| 490 | | | | | 491 |<======================================== deliver packets 492 | | | | | 494 Figure 5: Reactive Multicast Handover for PFMIPv6 496 4. Protocol Details 498 4.1. Protocol Operations Specific to FMIPv6 500 4.1.1. Operations of the Mobile Node 502 A Mobile Node willing to manage multicast traffic within fast 503 handover operations will inform about its MLD listener state records 504 within handover signaling. 506 When sensing a handover in predictive mode, an MN will build a 507 Multicast Mobility Option as described in Section 5.3 that contains 508 the MLD (IGMP) multicast listener state and append it to the Fast 509 Binding Update (FBU) prior to signaling with PAR. It will receive 510 the Multicast Acknowledgement Option(s) as part of Fast Binding 511 Acknowledge (FBack) (see Section 5.4) and learn about unsupported or 512 prohibited groups at the NAR. The MN MAY take appropriate actions 513 like home tunneling to bridge missing multicast services in the new 514 access network. No multicast-specific operation is required by the 515 MN when re-attaching in the new network besides standard FMIPv6 516 signaling. 518 In reactive mode, the MN appends an identical Multicast Mobility 519 Option to FBU sent after its reconnect. In response, it will learn 520 about the Multicast Acknowledgement Option(s) from FBACK and expect 521 corresponding multicast data. Concurrently it joins all desired 522 multicast groups (channels) directly on its newly established access 523 link. 525 4.1.2. Operations of the Previous Access Router 527 A PAR will advertise its multicast support by setting the M-bit in 528 PrRtAdv. 530 In predictive mode, a PAR will receive the multicast listener state 531 of a MN prior to handover from the Multicast Mobility Option appended 532 to the FBU. It will forward these records to NAR within HI messages 533 and will expect Multicast Acknowledgement Option(s) in HACK, which 534 itself is returned to the MN as an appendix to FBACK. In performing 535 multicast context exchange, the AR is instructed to include the PAR- 536 to-NAR tunnel obtained from unicast handover management in its 537 multicast downstream interfaces and await MLD listener reports from 538 NAR. In response to receiving multicast subscriptions, PAR will 539 normally forward group data acting as a normal multicast router or 540 proxy. However, NAR MAY refuse to forward some or all of the 541 multicast streams. 543 In reactive mode, PAR will receive the FBU augmented by the Multicast 544 Mobility Option from the new network, but will continue with an 545 identical multicast record exchange in the HI/HACk dialog. As in the 546 predictive case, it will configure the PAR-to-NAR tunnel for 547 multicast downstream and forward data according to MLD reports 548 obtained from NAR, if capable of forwarding. 550 In both modes, PAR will interpret the first of the two events, the 551 departure of the MN or the reception of the Multicast Acknowledgement 552 Option(s) as a multicast LEAVE message of the MN and react according 553 to the signaling scheme deployed in the access network (i.e., MLD 554 querying, explicit tracking). 556 4.1.3. Operations of the New Access Router 558 NAR will advertise its multicast support by setting the M-bit in 559 PrRtAdv. 561 In predictive mode, a NAR will receive the multicast listener state 562 of an expected MN from the Multicast Mobility Option appended to the 563 HI message. It will extract the MLD/IGMP records from the message 564 and intersect the request subscription with its multicast service 565 offer. Further on it will adjoin the supported groups (channels) to 566 the MLD listener state using loopback as downstream interface. This 567 will lead to suitable regular subscriptions on its native multicast 568 upstream interface without additional forwarding. Concurrently, NAR 569 builds a Multicast Acknowledgement Option(s) (see Section 5.4) 570 listing those groups (channels) unsupported on the new access link 571 and returns them within HACK. As soon as the bidirectional tunnel 572 from PAR to NAR is operational, NAR joins the groups desired for 573 forwarding on the tunnel link. 575 In reactive mode, NAR will learn about the multicast listener state 576 of a new MN from the Multicast Mobility Option appended to HI at a 577 time, when the MN has already performed local subscriptions of the 578 multicast service. Thus NAR solely determines the intersection of 579 requested and supported groups (channels) and issues the join 580 requests for group forwarding on the PAR-NAR tunnel interface. 582 In both modes, NAR MUST send a LEAVE message to the tunnel 583 immediately after forwarding of a group (channel) becomes unneeded, 584 e.g., after native multicast traffic arrives or group membership of 585 the MN terminates. 587 4.2. Protocol Operations Specific to PFMIPv6 589 4.2.1. Operations of the Mobile Node 591 A Mobile Node willing to participate in multicast traffic will join, 592 maintain and leave groups as if located in the fixed Internet. It 593 will cooperate in handover indication as specified in [RFC5949] and 594 required by its access link-layer technology. No multicast-specific 595 mobility actions nor implementations are required at the MN in a 596 PMIPv6 domain. 598 4.2.2. Operations of the Previous MAG 600 A MAG receiving a handover indication for one of its MNs follows the 601 predictive fast handover mode as a PMAG. It MUST issue an MLD 602 General Query immediately on its corresponding link unless it 603 performs an explicit tracking on that link. After gaining knowledge 604 of the multicast subscriptions of the MN, the PMAG builds a Multicast 605 Mobility Option as described in Section 5.3 that contains the MLD 606 (IGMP) multicast listener state. If not empty, this Mobility Option 607 is appended to the regular fast handover HI messages, or - in the 608 case of unicast HI message being submitted prior to multicast state 609 detection - sent in an additional HI message to the NMAG. PMAG then 610 waits for receiving the Multicast Acknowledgement Option(s) with HACK 611 (see Section 5.4) and the creation of the bidirectional tunnel with 612 NMAG. Thereafter PMAG will add the tunnel to its downstream 613 interfaces in the multicast forwarding database. For those groups 614 (channels) reported in the Multicast Acknowledgement Option(s), i.e., 615 not supported in the new access network, PMAG normally takes 616 appropriate actions (e.g., forwarding, termination) in concordance 617 with the network policy. It SHOULD start forwarding traffic down the 618 tunnel interface for those groups it receives an MLD listener report 619 message from NMAG. However, it MAY deny forwarding service. After 620 the departure of the MN and on the reception of LEAVE messages for 621 groups/channels, PMAG MUST terminate forwarding of the specific 622 groups and update its multicast forwarding database. Correspondingly 623 it issues a group/channel LEAVE to its upstream link, if no more 624 listeners are present on its downstream links. 626 A MAG receiving a HI message with Multicast Mobility Option for a 627 currently attached node follows the reactive fast handover mode as a 628 PMAG. It will return Multicast Acknowledgement Option(s) (see 629 Section 5.4) within HACK listing those groups/channels unsupported at 630 NMAG. It will add the bidirectional tunnel with NMAG to its 631 downstream interfaces and will start forwarding multicast traffic for 632 those groups it receives an MLD listener report message from NMAG. 633 At the reception of LEAVE messages for groups (channels), PMAG MUST 634 terminate forwarding of the specific groups and update its multicast 635 forwarding database. According to its multicast forwarding states, 636 it MAY need to issue a group/channel LEAVE to its upstream link, if 637 no more listeners are present on its downstream links. 639 In both modes, PMAG will interpret the departure of the MN as a 640 multicast LEAVE message of the MN and react according to the 641 signaling scheme deployed in the access network (i.e., MLD querying, 642 explicit tracking). 644 4.2.3. Operations of the New MAG 646 A MAG receiving a HI message with Multicast Mobility Option for a 647 currently unattached node follows the predictive fast handover mode 648 as NMAG. It will decide on those multicast groups/channels it wants 649 forwarded from the PMAG and builds a Multicast Acknowledgement Option 650 (see Section 5.4) that enumerates only unwanted groups/channels. 651 This Mobility Option is appended to the regular fast handover HACK 652 messages, or - in the case of unicast HACK message being submitted 653 prior to multicast state acknowledgement - sent in an additional HACK 654 message to the PMAG. Immediately thereafter, NMAG SHOULD update its 655 MLD listener state by the new groups/channels obtained from the 656 Multicast Mobility Option. Until the MN re-attaches, NMAG uses its 657 loopback interface for downstream and does not forward traffic to the 658 potential link of the MN. NMAG SHOULD issue JOIN messages for those 659 newly adopted groups to its regular multicast upstream interface. As 660 soon as the bidirectional tunnel with PMAG is established, NMAG 661 additionally joins those groups/channels on the tunnel interface that 662 it wants to receive by forwarding from PMAG. NMAG MUST send a LEAVE 663 message to the tunnel immediately after forwarding of a group/channel 664 becomes unneeded, e.g., after native multicast traffic arrives or 665 group membership of the MN terminates. 667 A MAG experiencing a connection request for a MN without prior 668 reception of a corresponding Multicast Mobility Option is operating 669 in the reactive fast handover mode as NMAG. Following the re- 670 attachment, it immediately issues an MLD General Query to learn about 671 multicast subscriptions of the newly arrived MN. Using standard 672 multicast operations, NMAG joins the missing groups (channels) on its 673 regular multicast upstream interface. Concurrently, it selects 674 groups (channels) for forwarding from PMAG and builds a Multicast 675 Mobility Option as described in Section 5.3 that contains the MLD 676 (IGMP) multicast listener state. If not empty, this Mobility Option 677 is appended to the regular fast handover HI messages with the F flag 678 set, or - in the case of unicast HI message being submitted prior to 679 multicast state detection - sent in an additional HI message to the 680 PMAG. Upon reception of the Multicast Acknowledgement Option and 681 upcoming of the bidirectional tunnel, NMAG additionally joins those 682 groups/channels on the tunnel interface that it wants to receive by 683 forwarding from PMAG. When multicast streams arrive, the NMAG 684 forwards data to the appropriate downlink(s). NMAG MUST send a LEAVE 685 message to the tunnel immediately after forwarding of a group/channel 686 becomes unneeded, e.g., after native multicast traffic arrives or 687 group membership of the MN terminates. 689 4.2.4. IPv4 Support Considerations 691 An MN in a PMIPv6 domain may use an IPv4 address transparently for 692 communication as specified in [RFC5844]. For this purpose, LMAs can 693 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide 694 IPv4 support in access networks. Correspondingly, multicast 695 membership management will be performed by the MN using IGMP. For 696 multiprotocol multicast support on the network side, IGMPv3 router 697 functions are required at both MAGs (see Section 5.6 for 698 compatibility considerations with previous IGMP versions). Context 699 transfer between MAGs can transparently proceed in HI/HACK message 700 exchanges by encapsulating IGMP multicast state records within 701 Multicast Mobility Options (see Section 5.3 and Section 5.4 for 702 details on message formats. 704 It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access 705 network, and the use of GRE tunneling as specified in[RFC5845]. 706 Corresponding implications and operations are discussed in the PMIP 707 Multicast Base Deployment document, cf., [RFC6224]. 709 5. Message Formats 711 5.1. Multicast Indicator for Proxy Router Advertisement (PrRtAdv) 713 An FMIPv6 AR will indicate its multicast support by activating the 714 M-bit in its Proxy Router Advertisements (PrRtAdv). The message 715 extension has the following format. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Code | Checksum | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Subtype |M| Reserved | Identifier | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Options ... 724 +-+-+-+-+-+-+-+-+-+-+-+- 726 Figure 6: Multicast Indicator Bit for Proxy Router Advertisement 727 (PrRtAdv) Message 729 5.2. Extensions to Existing Mobility Header Messages 731 The fast handover protocols use a new IPv6 header type called 732 Mobility Header as defined in [RFC3775]. Mobility headers can carry 733 variable Mobility Options. 735 Multicast listener context of an MN is transferred in fast handover 736 operations from PAR/PMAG to NAR/NMAG within a new Multicast Mobility 737 Option, and acknowledged by a corresponding Acknowledgement Option. 738 Depending on the specific handover scenario and protocol in use, the 739 corresponding option is included within the mobility option list of 740 HI/HAck only (PFMIPv6), or of FBU/FBAck/HI/HAck (FMIPv6). 742 5.3. New Multicast Mobility Option 744 The Multicast Mobility Option contains the current listener state 745 record of the MN obtained from the MLD Report message, and has the 746 format displayed in Figure 7. 748 0 1 2 3 749 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 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Type | Length | Option-Code | Reserved | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | | 754 + + 755 | | 756 + MLD (IGMP) Report Payload + 757 ~ ~ 758 ~ ~ 759 | | 760 + + 761 | | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Figure 7: Mobility Header Multicast Option 766 Type: TBD 768 Length: 8-bit unsigned integer. The size of this option in 8 octets 769 including the Type, Option-Code, and Length fields. 771 Option-Code: 773 1: IGMPv3 Payload Type 775 2: MLDv2 Payload Type 777 3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode 779 4: MLDv2 Payload Type from MLDv1 Compatibility Mode 781 Reserved: MUST be set to zero by the sender and MUST be ignored by 782 the receiver. 784 MLD (IGMP) Report Payload: this field is composed of the MLD (IGMP) 785 Report message after stripping its ICMP header. Corresponding 786 message formats are defined for MLDv2 in [RFC3810], and for IGMPv3 in 787 [RFC3376]. 789 Figure 8 shows the Report Payload for MLDv2, while the payload format 790 for IGMPv3 is defined corresponding to the IGMPv3 payload format (see 791 Section 5.2. of [RFC3810], or Section 4.2 of [RFC3376]) for the 792 definition of Multicast Address Records). 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Reserved |No of Mcast Address Records (M)| 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | | . . 800 . Multicast Address Record [1] . 801 . . 802 | | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 | | 805 . . 806 . Multicast Address Record [2] . 807 . . 808 | | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 | . | 811 . . . 812 | . | 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | | 815 . . 816 . Multicast Address Record [M] . 817 . . 818 | | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 Figure 8: MLDv2 Report Payload 823 5.4. New Multicast Acknowledgement Option 825 The Multicast Acknowledgement Option reports the status of the 826 context transfer and contains the list of state records that could 827 not be successfully transferred to the next access network. It has 828 the format displayed in Figure 9. 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Type | Length | Option-Code | Status | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | | 836 + + 837 | | 838 + MLD (IGMP) Unsupported Report Payload + 839 ~ ~ 840 ~ ~ 841 | | 842 + + 843 | | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 Figure 9: Mobility Header Multicast Acknowledgement Option 848 Type: TBD 850 Length: 8-bit unsigned integer. The size of this option in 8 octets. 851 The length is 1 when the MLD (IGMP) Unsupported Report Payload field 852 contains no Mcast Address Record. 854 Option-Code: 0 856 Status: 858 1: Report Payload type unsupported 860 2: Requested group service unsupported 862 3: Requested group service administratively prohibited 864 Reserved: MUST be set to zero by the sender and MUST be ignored by 865 the receiver. 867 MLD (IGMP) Unsupported Report Payload: this field is syntactically 868 identical to the MLD (IGMP) Report Payload field described in 869 Section 5.3, but is only composed of those multicast address records 870 that are not supported or prohibited in the new access network. This 871 field MUST always contain the first header line (reserved field and 872 No of Mcast Address Records), but MUST NOT contain any Mcast Address 873 Records, if the status code equals 1. 875 Note that group subscriptions to specific sources may be rejected at 876 the destination network, and thus the composition of multicast 877 address records may differ from initial requests within an MLD (IGMP) 878 Report Payload option. 880 5.5. Length Considerations: Number of Records and Addresses 882 Mobility Header Messages exchanged in HI/HACK and FBU/FBACK dialogs 883 impose length restrictions on multicast context records. The maximal 884 payload length available in FBU/FBACK messages is the PATH-MTU - 40 885 octets (IPv6 Header) - 6 octets (Mobility Header) - 6 octets (FBU/ 886 FBACK Header). For example, on an Ethernet link with an MTU of 1500 887 octets, not more than 72 Multicast Address Records of minimal length 888 (without source states) may be exchanged in one message pair. In 889 typical handover scenarios, this number reduces further according to 890 unicast context and Binding Authorization data. A larger number of 891 MLD Report Payloads MAY be sent within multiple HI/HACK or FBU/FBACK 892 message pairs. In PFMIPv6, context information can be fragmented 893 over several HI/HACK messages. However, a single MLDv2 Report 894 Payload MUST NOT be fragmented. Hence, for a single Multicast 895 Address Record on an Ethernet link, the number of source addresses is 896 limited to 89. 898 5.6. MLD (IGMP) Compatibility Aspects 900 Access routers (MAGs) MUST support MLDv2 (IGMPv3). To enable 901 multicast service for MLDv1 (IGMPv2) listeners, the routers MUST 902 follow the interoperability rules defined in [RFC3810] ([RFC3376]) 903 and appropriately set the Multicast Address Compatibility Mode. When 904 the Multicast Address Compatibility Mode is MLDv1 (IGMPv2), a router 905 internally translates the following MLDv1 (IGMPv2) messages for that 906 multicast address to their MLDv2 (IGMPv2) equivalents and uses these 907 messages in the context transfer. The current state of Compatibility 908 Mode is translated into the code of the Multicast Mobility Option as 909 defined in Section 5.3. A NAR (nMAG) receiving a Multicast Mobility 910 Option during handover will switch to the minimum obtained from its 911 previous and newly learned value of MLD (IGMP) Compatibility Mode for 912 continued operation. 914 6. Security Considerations 916 Security vulnerabilities that exceed issues discussed in the base 917 protocols of this document ([RFC5568], [RFC5949], [RFC3810], 918 [RFC3376]) are identified as follows. 920 Multicast context transfer at predictive handovers implements group 921 states at remote access routers and may lead to group subscriptions 922 without further validation of the multicast service requests. 923 Thereby a NAR (nMAG) is requested to cooperate in potentially complex 924 multicast re-routing and may receive large volumes of traffic. 926 Malicious or inadvertent multicast context transfers may result in a 927 significant burden of route establishment and traffic management onto 928 the backbone infrastructure and the access router itself. Rapid re- 929 routing or traffic overload can be mitigated by a rate control at the 930 AR that restricts the frequency of traffic redirects and the total 931 number of subscriptions. In addition, the wireless access network 932 remains protected from multicast data injection until the requesting 933 MN attaches to the new location. 935 7. IANA Considerations 937 This document defines new flags and status codes in the HI and HAck 938 messages as well as two new mobility options. The Type values for 939 these mobility options are assigned from the same numbering space as 940 allocated for the other mobility options defined in [RFC3775]. Those 941 for the flags and status codes are assigned from the corresponding 942 numbering space defined in [RFC5568], or [RFC5949] and requested to 943 be created as new tables in the IANA registry (marked with 944 asterisks). New values for these registries can be allocated by 945 Standards Action or IESG approval [RFC5226]. 947 8. Acknowledgments 949 Protocol extensions to support multicast in Fast Mobile IPv6 have 950 been loosely discussed since several years. Repeated attempts have 951 been taken to define corresponding protocol extensions. The first 952 draft [fmcast-mip6] was presented by Suh, Kwon, Suh, and Park already 953 in 2004. 955 This work was stimulated by many fruitful discussions in the MobOpts 956 research group. We would like to thank all active members for 957 constructive thoughts and contributions on the subject of multicast 958 mobility. Comments, discussions and reviewing remarks have been 959 contributed by (in alphabetical order) Carlos J. Bernardos, Luis M. 960 Contreras, Dirk von Hugo, Marco Liebsch, Behcet Sarikaya, Stig Venaas 961 and Juan Carlos Zuniga. 963 9. References 965 9.1. Normative References 967 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 968 Requirement Levels", BCP 14, RFC 2119, March 1997. 970 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 971 in IPv6", RFC 3775, June 2004. 973 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 974 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 976 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, 977 July 2009. 979 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 980 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 981 September 2010. 983 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 984 RFC 1112, August 1989. 986 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 987 "Internet Group Management Protocol (IGMP) / Multicast 988 Listener Discovery (MLD)-Based Multicast Forwarding 989 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 991 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 992 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 994 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 995 Thyagarajan, "Internet Group Management Protocol, Version 996 3", RFC 3376, October 2002. 998 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 999 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1000 May 2008. 1002 9.2. Informative References 1004 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 1005 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 1006 and Brief Survey", RFC 5757, February 2010. 1008 [fmcast-mip6] 1009 Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast 1010 Protocol for Mobile IPv6 in the fast handovers 1011 environments", draft-suh-mipshop-fmcast-mip6-00 (work in 1012 progress), July 2004. 1014 [FMIPv6-Analysis] 1015 Schmidt, TC. and M. Waehlisch, "Predictive versus Reactive 1016 - Analysis of Handover Performance and Its Implications on 1017 IPv6 and Multicast Mobility", Telecommunication 1018 Systems Vol 33, No. 1-3, pp. 131-154, November 2005. 1020 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1021 Deployment for Multicast Listener Support in Proxy Mobile 1022 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1024 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1025 Mobile IPv6", RFC 5844, May 2010. 1027 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 1028 "Generic Routing Encapsulation (GRE) Key Option for Proxy 1029 Mobile IPv6", RFC 5845, June 2010. 1031 Appendix A. Change Log 1033 The following changes have been made from 1034 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-04. 1036 1. Following working group feedback, multicast traffic forwarding is 1037 now a two-sided option between PAR (PMAG) and NAR (NMAG): Either 1038 access router can decide on its contribution to the data plane. 1040 2. Several editorial improvements. 1042 The following changes have been made from 1043 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-03. 1045 1. References updated. 1047 The following changes have been made from 1048 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-02. 1050 1. Detailed operations on PFMIPv6 entities completed. 1052 2. Some editorial improvements & clarifications. 1054 3. References updated. 1056 The following changes have been made from 1057 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-01. 1059 1. First detailed operations on PFMIPv6 added. 1061 2. IPv4 support considerations for PFMIPv6 added. 1063 3. Section on length considerations for multicast context records 1064 corrected. 1066 4. Many editorial improvements & clarifications. 1068 5. References updated. 1070 The following changes have been made from 1071 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-00. 1073 1. Editorial improvements & clarifications. 1075 2. Section on length considerations for multicast context records 1076 added. 1078 3. Section on MLD/IGMP compatibility aspects added. 1080 4. Security section added. 1082 Authors' Addresses 1084 Thomas C. Schmidt 1085 HAW Hamburg 1086 Dept. Informatik 1087 Berliner Tor 7 1088 Hamburg, D-20099 1089 Germany 1091 Email: schmidt@informatik.haw-hamburg.de 1093 Matthias Waehlisch 1094 link-lab & FU Berlin 1095 Hoenower Str. 35 1096 Berlin D-10318 1097 Germany 1099 Email: mw@link-lab.net 1101 Rajeev Koodli 1102 Cisco Systems 1103 30 International Place 1104 Xuanwu District, 1105 Tewksbury MA 01876 1106 USA 1108 Email: rkoodli@cisco.com 1109 Godred Fairhurst 1110 University of Aberdeen 1111 School of Engineering 1112 Aberdeen AB24 3UE 1113 UK 1115 Email: gorry@erg.abdn.ac.uk