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