idnits 2.17.1 draft-taylor-pim-v4v6-translation-02.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 17, 2012) is 4291 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) == Unused Reference: 'I-D.mboned-64-multicast-address-format' is defined on line 448, but no explicit reference was found in the text == Unused Reference: 'RFC6052' is defined on line 460, but no explicit reference was found in the text -- No information found for draft-mboned-64-multicast-address-format - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.mboned-64-multicast-address-format' ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Taylor 3 Internet-Draft C. Zhou 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 18, 2013 July 17, 2012 7 Operation of a Dual-Stack Multicast Router With Address Translation 8 draft-taylor-pim-v4v6-translation-02 10 Abstract 12 This document describes the procedures required for correct operation 13 of a multicast router in a mixed IPv4 and IPv6 environment, where 14 some or all of the multicast group and unicast source addresses can 15 be translated between IPv4 and IPv6, and where incoming multicast 16 data may need to be forwarded into both IPv4 and IPv6 distribution 17 trees. The router is assumed to support Protocol Independent 18 Multicast - Sparse Mode (PIM-SM, RFC 4601) in an environment 19 consisting of a mixture of IPv4 and IPv6 local hosts and PIM peers. 20 The work is easily generalized to other versions of PIM. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 18, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Model of Multicast Router Operation . . . . . . . . . . . . . 4 59 3. Principles of Operation . . . . . . . . . . . . . . . . . . . 7 60 4. Modifications To RFC 4601 . . . . . . . . . . . . . . . . . . 9 61 5. Processing of PIM Messages and Multicast Data Packets . . . . 9 62 5.1. Hello Messages . . . . . . . . . . . . . . . . . . . . . . 9 63 5.2. Register and Register Stop Messages . . . . . . . . . . . 10 64 5.3. Join/Prune Messages . . . . . . . . . . . . . . . . . . . 10 65 5.4. Assert Messages . . . . . . . . . . . . . . . . . . . . . 10 66 5.5. Multicast Data Packets . . . . . . . . . . . . . . . . . . 11 67 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. Normative References . . . . . . . . . . . . . . . . . . . 11 72 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 During the transition from IPv4 to IPv6, operators need to maintain 78 their services, including multicast services. Depending on how the 79 operator evolves its networks, the situation may arise where sources 80 and receivers support different IP versions, or where some part of 81 the network path between the source and receiver supports one IP 82 version, and a succeeding portion supports the other. 83 [ID.v4v6-multicast-ps] describes a number of potential use cases that 84 can occur. 86 If IPv4 sources needed to be received only by IPv4 receivers, IPv6 87 sources needed to be received only by IPv6 receivers, and the network 88 were dual stack, a multicast router could simply run parallel IPv4 89 and IPv6 PIM state machines with no interaction between them. In the 90 transitional circumstances described above, however, it is necessary 91 to be able to map between IPv4 and IPv6 source and group addresses. 92 Such a mapping introduces interactions between the two PIM state 93 machines within the multicast router. The situation becomes more 94 complicated if, for administrative reasons, no translation is 95 possible/permitted for some addresses. As will be seen below, the 96 changes to PIM operation under these circumstances will not be large, 97 but do require some care. 99 A number of authors have already worked on multicast translation. 100 One of the earliest works on the topic was [ID.venaas-v4v6mcastgw], 101 which was aimed at giving IPv6 receivers access to IPv4 sources. The 102 document defines a 1-1 mapping of IPv4 multicast group addresses onto 103 a subset of IPv6 addresses defined by a /96 IPv6 multicast prefix. 104 The multicast router is assumed to sit on the boundary between an 105 IPv4 and IPv6 network, and serves as a rendezvous point for all 106 groups within the /96 prefix so that it can keep track of all IPv6 107 sources and receive all of their data. It appears to the IPv4 108 network as an IPv4 multicast host. 110 Succeeding documents have built on the foundations established by 111 [ID.venaas-v4v6mcastgw], taking advantage of advances in translation 112 standardized by the IETF BEHAVE Working Group. Implementations of 113 the gateway concept have also appeared, with [Kiviniemi] as a notable 114 example. [Kiviniemi] is useful for its summary of related 115 developments up to 2009 and for its extensive discussion of the 116 challenges of translation of multicast data packets. 118 The present document assumes a more general mode of operation. PIM 119 messages are exchanged with IPv4 as well as IPv6 peers. The 120 multicast router is not necessarily the rendezvous point for 121 translated multicast groups. Instead, reliance is placed on the 122 underlying routing tables to ensure that reverse paths pass through 123 dual stack multicast routers like the one described in this document 124 when translation between IPv4 and IPv6 is required. 126 Also unlike previous work, the present document takes the details of 127 translation more or less for granted, with the expectation that they 128 are documented elsewhere. (References are given where available.) 129 Its focus is squarely on changes in behaviour required for correct 130 functioning of the multicast router in the assumed environment. 132 The discussion which follows is framed in terms of a model of 133 multicast router operation. Needless to say, this model is a 134 descriptive device, not a recommendation for implementation. 135 Following the main discussion, Section 5 summarizes the processing 136 required for each PIM message type. 138 This document assumes the use of Protocol Independent Multicast - 139 Sparse Mode (PIM-SM) [RFC4601]. Its recommendations can easily be 140 generalized to other flavours of PIM. 142 1.1. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 This document uses the following terms from Section 2.1 of [RFC4601]: 150 o Rendezvous Point (RP); 152 o Multicast Routing Information Base (MRIB); 154 o Tree Information Base (TIB); 156 o RPF Neighbour; 158 o upstream; 160 o downstream. 162 2. Model of Multicast Router Operation 164 Figure 1 provides a model of multicast operation in the absence of 165 address translation. This model consists of four main components: 166 the local host protocol interface, the PIM state machine, route 167 determination (including the MRIB), and the multicast data forwarder. 169 +------------+ 170 | Local host | 171 Local hosts <-------->| protocol | 172 | interface | 173 | (IGMP/MLD) | 174 +------------+ 175 | 176 | 177 +------------+ 178 Incoming messages* | PIM | Outgoing messages* 179 from peers -------->| state |--------> to peers 180 | machine | 181 +------------+ 182 / \ 183 / \ 184 Hello +---------------+ +------------+ 185 messages <----->| Route | | Multicast |<------- 186 | determination | | data | 187 Routing <----->| | | forwarding |--------> 188 protocols +---------------+ +------------+ 190 * PIM Join/Prune, Assert, Register, and Register Stop messages 192 Figure 1: Model of Multicast Router Operation In the Absence of 193 Address Translation 195 The local host protocol interface provides the router portion of the 196 host protocol: Internet Group Management Protocol (IGMP) [RFC3376] 197 for IPv4 or Multicast Listener Discovery (MLD) [RFC3810] for IPv6. 198 It passes listener state changes for individual groups and sources to 199 the PIM state machine. 201 Route determination is built on the Multicast Routing Information 202 Base (MRIB), as well as the secondary address information provided by 203 Hello messages received from neighbouring peers. Upon request from 204 the PIM state machine, it provides the address of the next hop 205 neighbour (RPF neighbour) toward a given rendezvous point (RP) or 206 source, and identifies the interface leading to that neighbour. It 207 also provides metrics in support of Assert processing. 209 Multicast data forwarding receives multicast data packets, passes the 210 source and destination (multicast group) addresses to the PIM state 211 machine, and is passed in return the identifiers of the interfaces 212 out of which they must be forwarded. 214 Finally, the PIM state machine executes the protocol procedures 215 described in [RFC4601] and thereby creates and maintains the Tree 216 Information Base (TIB). As well as the interactions with the the 217 other components described above, it exchanges Join/Prune, Assert, 218 Register, and Register Stop messages with its peers. 220 Figure 2 shows the changes to the model when address translation is 221 introduced. Three new components are added to the picture: address 222 mapping, routing version selection, and multicast data packet 223 processing. Very briefly, address mapping maps source, group, and 224 rendezvous point (RP) addresses between IPv4 and IPv6 in either 225 direction, or returns an indication that no mapping exists. Routing 226 version selection decides whether the next hop toward a rendezvous 227 point or source should be IPv4 or IPv6. Multicast data packet 228 processing accepts a packet of one version and outputs a packet of 229 the other version. This may be accomplished through translation or, 230 possibly, through encapsulation. Further details for all of these 231 components and the changes needed in the PIM state machine will 232 emerge from the discussion that follows. 234 +------------+ 235 | Local host | 236 Local hosts <-------->| protocol | 237 | interface | 238 | (IGMP/MLD) | 239 +------------+ 240 | 241 | 242 +----------------+ 243 | Address | 244 | mapping | 245 | +------------+ 246 Incoming messages* | | PIM | Outgoing messages* 247 from peers ---->| | state |--------> to peers 248 | | machine | 249 +---+------------+ 250 / \ 251 / \ 252 Hello +---------------+ +------------+ 253 messages <----->| Route | | Multicast |<------- 254 | determination | | data | 255 Routing <----->| (IPv4, IPv6) | | forwarding |--------> 256 protocols +---------------+ +------------+ 257 | | 258 | | 259 +---------------+ +------------+ 260 | Routing | | Multicast | 261 | version | | data packet| 262 | selection | | processing | 263 +---------------+ +------------+ 265 * PIM Join/Prune, Assert, Register, and Register Stop messages 267 Figure 2: Model of Multicast Router Operation When Address 268 Translation Is Possible 270 3. Principles of Operation 272 This section justifies the changes to the model shown in Figure 2 and 273 provides further details of its operation. 275 The basic consideration behind the proposed model is that downstream 276 listeners have to be served in the IP version they support, but it is 277 desirable to receive individual streams from upstream in only one 278 version to avoid unnecessary duplication. Address mapping is 279 unavoidable in this situation. It is actually required for three 280 reasons: 282 o internally to the PIM state machine, so state and state-modifying 283 events involving the same source, group, or RP can be collected 284 together regardless of the IP version used to represent its 285 address; 287 o externally, to send messages in the appropriate IP version to PIM 288 peers and local hosts; and 290 o to support multicast data packet processing when the packet must 291 be forwarded in a different IP version from that in which it was 292 received. 294 Address mapping can be done at various points in the process. The 295 representation in Figure 2 assumes the following: 297 o Source and group addresses in incoming Join/Prune, Assert, and, 298 depending on the role of the router, Register or Register Stop 299 messages are passed to the address mapper. The mapper returns 300 either a corresponding address in the other version or and 301 indication that no mapping is available. 303 o Similarly, source and group addresses in the messages received by 304 the local host protocol interface are mapped before the messages 305 are passed to the PIM state machine. 307 o The PIM state machine accepts the mapped addresses and indications 308 along with the original messages, and stores them in the state 309 information it maintains. 311 [To add: references pertaining to the "how" of address mapping.] 313 As a result, when a message arrives that updates downstream listener 314 state, the PIM state machine is able to relate that state change to 315 the state it already holds for the source or group concerned, even if 316 that earlier state was established by a request in the other IP 317 version. This is because it can match on the mapped counterpart to 318 the address in the earlier request. 320 Consider now the case that, as a result of downstream events, the PIM 321 state machine decides to send a Join/Prune message upstream. When 322 only one IP version was involved, that was the only IP version that 323 had to be considered when choosing the next hop toward the RP or 324 source. In the situation presented here, however, it is possible 325 that both IPv4 and IPv6 next-hop neighbours are available. A new 326 function, routing version selection, is needed to make the decision. 328 At this point, no general rule can be given for how routing version 329 selection makes its decision. The obvious initial step is to 330 determine whether the RP or source is reachable in both IP versions. 331 It is assumed for the sake of this discussion that separate IPv4 and 332 IPv6 MRIBs are maintained by the routing determination component. If 333 the target source or RP proves to be reachable by both IPv4 and IPv6, 334 the associated routing metrics can be made available to routing 335 version selection. However, it may well be that these metrics are 336 not comparable. Routing version selection may make use of 337 heuristics, but most likely will be based on local policy. That 338 could take the form of a simple table mapping from target address to 339 preferred next-hop address family. 341 Once the IP version of the outgoing Join/Prune message has been 342 determined, the PIM state machine can populate the source and group 343 addresses in the message with the same IP version. In the present 344 narrative, this does not require another call to address translation 345 because the necessary mappings have been retained as part of stored 346 state. Other implementations are obviously possible. 348 Assert logic becomes more complicated in the dual-stack scenario 349 assumed here. One open issue is how to compare metrics if this 350 router will acquire the multicast flow concerned using a different IP 351 version from the version used by its rival peer. As noted below, 352 Assert messages have to sent out in both versions, because they have 353 to be understood by downstream as well as upstream entities. 355 [That topic may need more detailed discussion. Also to do: add 356 references and detail the challenges of multicast data packet 357 processing.] 359 4. Modifications To RFC 4601 361 [This section should provide detailed changes needed to the 362 specifications in RFC 4601, starting with the state data maintained.] 364 5. Processing of PIM Messages and Multicast Data Packets 366 5.1. Hello Messages 368 Hello messages are not translated. Rather, the differences between 369 the IPv4 and IPv6 versions are as follows: 371 o In the packet header, the source address varies between the IPv4 372 primary address and the IPv6 link-local address on that interface. 373 The destination address is the IPv4 or IPv6 ALL_PIM_ROUTERS 374 multicast address as applicable. 376 o The Address List option varies between the list of secondary IPv4 377 addresses on that interface and the list of secondary IPv6 378 addresses on that interface 380 5.2. Register and Register Stop Messages 382 The Register and Register Stop messages are routed as unicast 383 messages. 385 Section 4.9.3 of [RFC4601] requires the header of the multicast data 386 packet encapsulated within a Register message to have the same 387 address family as the packet header of the Register message itself. 388 This may require translation of the enclosed packet header to match 389 the outer header. The procedures described in [RFC6145] MUST be 390 applied to the header as a whole. Translation of the source and 391 group addresses (the packet source and destination addresses) is done 392 as described in Section 2. 394 The Register Stop message takes its contents from the received 395 Register message, and needs no translation. 397 5.3. Join/Prune Messages 399 Join/Prune messages MUST be sent in the IP version indicated by the 400 MRIB when it identifies an RPF neighbour. 402 Care must be taken when switching from the Rendezvous Point Tree to 403 the shortest-path tree for a given source. The Prune for the 404 Rendezvous Point Tree MUST be sent in the IP version of the RPF 405 neighbour for that tree. This implies that in the (*,G) state 406 described in Section 4.1.3 of [RFC4601], the address family of the 407 last RPF neighbour used MUST be retained, and the address itself MUST 408 NOT be translated. 410 Multicast group addresses and all joined and pruned source addresses 411 contained in the message are translated as described in Section 3. 413 5.4. Assert Messages 415 Assert messages need to reach both upstream and downstream neighbours 416 on a LAN. Hence, if the subject router PIM has received Hello 417 messages in both IP versions on an interface to which an Assert is to 418 be forwarded, it MUST send the Assert message in both IP versions. 420 The multicast group address and source address contained in the 421 message are translated as described in Section 3. 423 5.5. Multicast Data Packets 425 This section applies to multicast data packets being forwarded 426 directly rather than being encapsulated in Register messages. The 427 procedures described in [RFC6145] MUST be applied to the header as a 428 whole. Translation of the source and group addresses (the packet 429 source and destination addresses) is done as described in Section 3. 431 6. Acknowledgements 433 Thanks to Simon Perrault for comments on the first version of this 434 document. 436 7. IANA Considerations 438 This memo includes no request to IANA. 440 8. Security Considerations 442 TBD 444 9. References 446 9.1. Normative References 448 [I-D.mboned-64-multicast-address-format] 449 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 450 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 451 in progress)", February 2012. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 457 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 458 Protocol Specification (Revised)", RFC 4601, August 2006. 460 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 461 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 462 October 2010. 464 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 465 Algorithm", RFC 6145, April 2011. 467 9.2. Informative References 469 [ID.v4v6-multicast-ps] 470 Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., 471 and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and 472 Use Cases (Work in Progress)", May 2012. 474 [ID.venaas-v4v6mcastgw] 475 Venaas, S., "An IPv4 - IPv6 multicast gateway (Expired 476 Internet Draft)", February 2003. 478 [Kiviniemi] 479 Kiviniemi, T., "Implementation of an IPv4 to IPv6 480 Multicast Translator (Master's Thesis)", October 2009. 482 Author's summary: 484 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 485 Thyagarajan, "Internet Group Management Protocol, Version 486 3", RFC 3376, October 2002. 488 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 489 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 491 Authors' Addresses 493 Tom Taylor 494 Huawei Technologies 495 Ottawa, 496 Canada 498 Phone: 499 Email: tom.taylor.stds@gmail.com 501 Cathy Zhou 502 Huawei Technologies 503 Bantian, Longgang District 504 Shenzhen 518129 505 P.R. China 507 Phone: 508 Email: cathy.zhou@huawei.com