idnits 2.17.1 draft-tsou-softwire-6rd-multicast-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 (September 4, 2012) is 4245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 264, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Tsou 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Informational T. Taylor 5 Expires: March 8, 2013 C. Zhou 6 Huawei Technologies 7 H. Ji 8 China Telecom 9 September 4, 2012 11 IPv6 Multicast Using Native IPv4 Capabilities in a 6rd Deployment 12 draft-tsou-softwire-6rd-multicast-02 14 Abstract 16 This document describes how IPv6 multicast can be extended across an 17 IPv4 network to an IPv6 host, using the native multicast capabilities 18 of the IPv4 network. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on March 8, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Description of the Solution . . . . . . . . . . . . . . . . . . 3 57 2.1. Assumed Architecture . . . . . . . . . . . . . . . . . . . 3 58 2.2. Components of the Proposed Solution . . . . . . . . . . . . 4 59 2.2.1. Address Mapping . . . . . . . . . . . . . . . . . . . . 4 60 2.2.2. Multicast Routing . . . . . . . . . . . . . . . . . . . 5 61 2.2.3. Translation From MLD To IGMP . . . . . . . . . . . . . 5 62 2.2.4. Interworking Between PIM With IPv4 and PIM with 63 IPv6 At the 6rd BR . . . . . . . . . . . . . . . . . . 5 64 2.2.5. Transport of Multicast Data Packets and Unicast 65 RTCP Feedback . . . . . . . . . . . . . . . . . . . . . 5 66 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 6 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 7 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 6rd ([RFC5569], [RFC5969]) provides a means to connect IPv6 hosts to 77 the IPv6 Internet across an IPv4 provider network. Unicast traffic 78 is carried through IPv6-in-IPv4 tunnels. It is possible to carry 79 multicast traffic from the IPv6 network through the IPv4 network in 80 the same way, but if multiple customers wish access to the same 81 multicast channels, the failure to use the native multicast 82 capabilities of the IPv4 network wastes resources in that network. 84 This document describes a solution using the native multicast 85 capabilities of the IPv4 network to acquire and forward multicast 86 traffic from the IPv6 Internet to an IPv6 host attached to the IPv4 87 network. Typically this solution will operate in combination with 88 6rd for unicast traffic. However, no IPv6-in-IPv4 tunneling is 89 required for signalling, only the ability to interwork between IPv4 90 and IPv6 at the 6rd Customer Equipment (6rd CE) and the 6rd Border 91 Relay (6rd BR). 93 1.1. Terminology 95 The term "address pair" is used to denote the combination of unicast 96 source address and multicast group address corresponding to a given 97 multicast stream at a given point along the path between the source 98 and receiver. 100 2. Description of the Solution 102 A number of problems have to be solved to allow an IPv6 host attached 103 to an IPv4 network to request and receive a multicast stream 104 originating in a neighbouring IPv6 network and passing through the 105 IPv4 network using the native multicast facilities of that network. 106 These problems are described in detail in the course of presenting 107 proposed solutions to them. 109 It is assumed that the IPv6 host wishing to receive a multicast 110 stream acquires the corresponding IPv6 address pair by means out of 111 scope of this document. See [ID.mboned-multrans-addr-acq]. 113 2.1. Assumed Architecture 115 This document assumes an architecture similar to that of 6rd 116 [RFC5569], [RFC5969], with additional capabilities for the 6rd 117 Customer Edge (CE) and the 6rd Border Relay (6rd BR). See Figure 1. 119 +----+ +----+ Access +--------+ +------+ 120 |IPv6| LAN | 6rd| Link |Provider| IPv4 |Border| IPv6 121 |Host|--------| CE |--------|IP Edge |-- network --|Relay |--- network 122 +----+ +----+ +--------+ +------+ 124 Figure 1: IPv6 Multicast Across an IPv4 Domain Using a Translator 125 Function 127 In addition to its 6rd responsibilities, the 6rd CE is responsible 128 for: 130 o mapping between the IPv6 address pair presented by the IPv6 Host 131 and an IPv4 address pair designating the same multicast stream in 132 the provider's IPv4 network; 134 o accepting MLD [RFC3810] on the IPv6 Host side and emitting IGMP 135 [RFC3376] toward the provider's IPv4 network; 137 o using the reverse mapping from IPv6 to IPv4 address pairs to 138 translate incoming IPv4 multicast streams to IPv6 before 139 forwarding them to the IPv6 Host. Alternatively, decapsulating 140 IPv6 multicast data packets from incoming IPv4 packets. 142 The Provider IP Edge has the normal function of interworking between 143 IGMP [RFC3376] and PIM [RFC4601] multicast signalling. 145 The Border Relay has the usual 6rd responsibilities. In addition, it 146 is responsible for: 148 o mapping between IPv4 address pairs received in PIM messages from 149 the IPv4 network and IPv6 address pairs denoting the same 150 multicast streams in the neighbouring IPv6 network; 152 o translating addresses in PIM between the IPv4 and IPv6 networks; 154 o using the reverse mapping from IPv6 to IPv4 address pairs to 155 translate and forward multicast data packets coming from the IPv6 156 network. Alternatively, using the reverse mapping to generate 157 encapsulating IPv4 headers for the IPv6 packets before forwarding 158 them as multicast IPv4 data. 160 2.2. Components of the Proposed Solution 162 2.2.1. Address Mapping 164 Both the 6rd CE and the 6rd BR need to map between IPv6 and IPv4 165 addresses, in both directions. The IPv6 address pairs do not have to 166 be the same at the two nodes, so long as the IPv6 address pair used 167 by the host designates the same multicast stream as the IPv6 address 168 pair generated at the 6rd BR or received from the source IPv6 169 network. 171 Because the source network uses IPv6, mapping between the addresses 172 used in that network and the IPv4 addresses used in the provider 173 network is in general a difficult problem. The most general solution 174 is to configure static mappings between the IPv6 and corresponding 175 IPv4 address pairs at the 6rd BR. Mapping at the 6rd CE can use 176 IPv4-embedded IPv6 addresses as defined in [RFC6052] for the unicast 177 source addresses, and [ID.mboned-64-mcast-addr-fmt] for the multicast 178 group addresses. This assumes that the IPv6 host has been provided 179 with such addresses in the first place. It also assumes that the 180 IPv4 network provider can configure suitable prefixes at the 6rd CE 181 for the purpose of such mapping. 183 With restrictions on the IPv6 addresses used for multicast source and 184 group addresses in the IPv6 network, it may be possible to use 185 algorithmic instead of static mapping at the 6rd BR. This generally 186 requires coordination between the IPv4 and IPv6 network operators. 188 2.2.2. Multicast Routing 190 For each IPv4 address to which an IPv6 source address is mapped, the 191 routing tables that PIM uses must result in a path that passes 192 through a multicast-enabled 6rd BR. At the routing level, this means 193 that the 6rd BR must advertise reachability to the mapped IPv4 source 194 addresses it knows about into the IPv4 domain. Its distance metrics 195 to those addresses must reflect the routing information it receives 196 on the IPv6 side for their IPv6 counterparts. 198 2.2.3. Translation From MLD To IGMP 200 See [ID.perreault-igmp-mld-translation]. 202 2.2.4. Interworking Between PIM With IPv4 and PIM with IPv6 At the 6rd 203 BR 205 See [ID.taylor-pim-v4v6-translation]. 207 2.2.5. Transport of Multicast Data Packets and Unicast RTCP Feedback 209 The documents cited in the previous two sections describe the process 210 of header translation for multicast data packets. The address 211 mapping aspect of that translation was discussed in Section 2.2.1. 212 If the 6rd BR and 6rd CE are configured to use encapsulation/ 213 decapsulation of multicast data packets instead, the encapsulating 214 IPv4 header uses the IPv4 address pair mapped from the original IPv6 215 address pair as source and destination. However, this requires that 216 the IPv6 host uses the same IPv6 addresses as the source IPv6 network 217 for each multicast stream it receives. That may force the 6rd CE to 218 use static rather than algorithmic mapping for address pairs for its 219 MLD/IGMP translation. 221 When the IPv6 Host sends unicast RTCP [RFC3550] feedback toward the 222 source, the packets are treated by the 6rd CE and 6rd BR like any 223 other unicast packets. That is, they are encapsulated at the 6rd CE, 224 transported across the IPv4 network as IPv6-in-IPv4, and decapsulated 225 at the 6rd BR before forwarding into the IPv6 network. 227 3. Acknowledgements 229 Awaiting comments. 231 4. IANA Considerations 233 This memo currently includes no request to IANA. 235 5. Security Considerations 237 To come. 239 6. References 241 6.1. Normative References 243 [ID.mboned-64-mcast-addr-fmt] 244 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 245 M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work 246 in progress)", August 2012. 248 [ID.perreault-igmp-mld-translation] 249 Perrault, S. and T. Tsou, "Internet Group Management 250 Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based 251 Multicast Translation ("IGMP/MLD Translation") (Work in 252 progress)", April 2012. 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, March 1997. 257 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 258 Thyagarajan, "Internet Group Management Protocol, Version 259 3", RFC 3376, October 2002. 261 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 262 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 264 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 265 Independent Multicast - Dense Mode (PIM-DM): Protocol 266 Specification (Revised)", RFC 3973, January 2005. 268 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 269 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 270 Protocol Specification (Revised)", RFC 4601, August 2006. 272 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 273 Infrastructures (6rd) -- Protocol Specification", 274 RFC 5969, August 2010. 276 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 277 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 278 October 2010. 280 6.2. Informative References 282 [ID.mboned-multrans-addr-acq] 283 Tsou, T., Clauberg, A., Boucadair, M., Venaas, S., and Q. 284 Sun, "Address Acquisition For Multicast Content When 285 Source and Receiver Support Differing IP Versions (Work in 286 progress)", March 2012. 288 [ID.taylor-pim-v4v6-translation] 289 Taylor, T. and C. Zhou, "Operation of a Dual-Stack 290 Multicast Router With Address Translation (Work in 291 progress)", July 2012. 293 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 294 Jacobson, "RTP: A Transport Protocol for Real-Time 295 Applications", STD 64, RFC 3550, July 2003. 297 [RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 298 Infrastructures (6rd)", RFC 5569, January 2010. 300 Authors' Addresses 302 Tina Tsou 303 Huawei Technologies (USA) 304 2330 Central Expressway 305 Santa Clara, CA 95050 306 USA 308 Phone: +1 408 330 4424 309 Email: Tina.Tsou.Zouting@huawei.com 310 URI: http://tinatsou.weebly.com/contact.html 312 Tom Taylor 313 Huawei Technologies 314 Ottawa, Ontario 315 Canada 317 Phone: 318 Email: tom.taylor.stds@gmail.com 320 Cathy Zhou 321 Huawei Technologies 322 Bantian, Longgang District 323 Shenzhen 518129 324 P.R. China 326 Phone: 327 Email: cathy.zhou@huawei.com 329 Hui Ji 330 China Telecom 331 NO19.North Street 332 Beijing, Chaoyangmen,Dongcheng District 333 P.R. China 335 Phone: 336 Email: jihui@chinatelecom.com.cn