idnits 2.17.1 draft-tsao-mboned-v4v6mcast-dynamic-conversion-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 10 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC6144]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 29, 2014) is 3589 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) == Missing Reference: 'ADDRARCH' is mentioned on line 173, but not defined ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational RFC: RFC 6144 == Outdated reference: A later version (-06) exists of draft-ietf-mboned-64-multicast-address-format-05 Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 mboned WG C. Xie 3 Internet-Draft Q. Sun 4 Intended status: Standards Track China Telecom 5 Expires: December 31, 2014 C. Wang 6 W. Meng 7 ZTE Corporation 8 B. Khasnabish 9 ZTE USA,Inc 10 June 29, 2014 12 IPv4-IPv6 Multicast Address Conversion 13 draft-tsao-mboned-v4v6mcast-dynamic-conversion-02 15 Abstract 17 This draft describes a mechanism for stateless conversion of IPv4 18 multicast address to IPv6 multicast address and vice versa,using 19 different rules. These rules can be used in both IPv4-IPv6 20 translation or encapsulation. This solution can be used in any 21 scenarios describe in [RFC6144]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 31, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Convention and Terminology . . . . . . . . . . . . . . . . . . 4 59 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. IPv4/IPv6 Multicast Address Conversion . . . . . . . . . . . . 6 61 4.1. Rule Design . . . . . . . . . . . . . . . . . . . . . . . 6 62 4.2. IPv4 Multicast Address Suffix-embedded IPv6 Multicast 63 Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.3. Full IPv4 Multicast Address-embedded IPv6 Multicast 65 Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 5.1. From IPv4 Multicast System to IPv6 Multicast System . . . 9 68 5.2. From IPv6 Multicast System to IPv6 Multicast System . . . 9 69 6. Backwards compatibility . . . . . . . . . . . . . . . . . . . 10 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 76 1. Introduction 78 This draft describes a mechanism for stateless translation between 79 IPv4 multicast address and IPv6 multicast address using different 80 rules. These rules can be used in both IPv4-IPv6 translation or 81 encapsulation.This solution can be used in any scenarios describe in 82 [RFC6144]. 84 The approach described in this draft is fully compatible with 85 [I-D.ietf-mboned-64-multicast-address-format]. 87 2. Convention and Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 Rule_IPv6_M_Prefix/Length: 95 Define an IPv6 Prefix assigned by a Service Provider for a IPv4/ 96 IPv6 Multicast Address Conversion rule. 98 Rule_IPv4_M_Prefix/Length: 100 Define an IPv4 Prefix assigned by a Service Provider for a IPv4/ 101 IPv6 Multicast Address Conversion rule. 103 Rule_IPv4_Offset: 105 Define an offset where IPv4 Multicast Address should embedded in 106 the IPv6 Multicast Address. 108 Rule_IPv4_Type: 110 Defined whether an IPv4 Multicast Address Suffix or a full IPv4 111 Multicast Address is embedded in the IPv6 Multicast Address. Value 0 112 is default and means IPv4 Multicast Address Suffix is embedded in the 113 IPv6 Multicast Address. Value 1 means a full IPv4 Multicast Address 114 is embedded in the IPv6 Multicast Address. 116 3. Architecture 118 All of the scenarios that are describe in [RFC6144] can be easily 119 illustrate using the diagram show in Figure 1 below: 121 ====> 122 -------- 123 // \\ ----------- 124 / \ // \\ 125 / +----+ \ 126 | |CONV| | 127 | IPv4 + + IPv6 | 128 | Multicast + + Multicast | CONV Rule: IPv4/IPv6 129 | System |Rule| System | Translation 130 \ +--- + / 131 \ / \\ // 132 \\ // ----------- 133 -------- 134 <==== 136 Figure 1: IPv4-IPv6 Address Conversion 138 As shown in this diagram(Fig.1), there is a conversion node between 139 an IPv4 Multicast System and IPv6 Multicast System. Every conversion 140 node must be provisioned with at least one rule defined in the 141 document used for IPv4/IPv6 Multicast Address Conversion. There are 142 also two arrows: an arrow from IPv4 Multicast system to IPv6 143 Multicast System means IPv4 Multicast system initiates the multicast 144 flow. Another arrow from IPv6 Multicast system to IPv4 Multicast 145 System means IPv6 Multicast system initiates the multicast flow. And 146 this also means that the algorithmic described in this document 147 support both IPv4-initiated communication and IPv6-initiated 148 communication. 150 4. IPv4/IPv6 Multicast Address Conversion 152 This section specifies the rule(s) for IPv4/IPv6 multicast address 153 conversion. 155 4.1. Rule Design 157 Every CONV node must be provisioned with at least one rule. When 158 there are several rules for IPv4/IPv6 Conversion assigned for a CONV 159 node, this node should choose the rule which is longest match prefix 160 for the destination IP address in multicast flow. 162 Each rule includes the following: 164 Rule_IPv6_M_Prefix (including prefix length) 166 Rule_IPv4_M_Prefix (including prefix length, optional) 168 Rule_IPv4_Offset (optional) 170 Rule_IPv4_Type (optional) 172 Rule_IPv6_M_Prefix/Length is according to section 2.7 of 173 [ADDRARCH][RFC3513],or based on [RFC3306].This parameter is 174 mandatory. 176 Rule_IPv4_M_Prefix/Length is in IPv4 multicast group address scope. 177 By default, this parameter is empty, which means match any IPv4 group 178 address in the destination address field in the receiving packet. 179 This parameter is optional. 181 Rule_IPv4_Offset defines the offset where IPv4 multicast address is 182 embedded in the IPv6 multicast address. By default, the value is 183 96,which means embedded the IPv4 multicast address in the last 32 184 bits of the IPv6 multicast address. This parameter is optional. 186 Rule_IPv4_Type defines two kinds of IPv6 Multicast Address format: 187 one format is IPv4 Multicast Address Suffix is embedded in the IPv6 188 Multicast Address, and corresponding Rule_IPv4_Type value is 0; 189 another format is Full IPv4 Multicast Address is embedded in the IPv6 190 Multicast Address, and corresponding Rule_IPv4_Type value is 1.By 191 default, Rule_IPv4_Type value is 0. This parameter is optional. 193 When Rule_IPv6_M_Prefix is SSM mode, the corresponding 194 Rule_IPv4_M_Prefix in the same rule should be SSM mode. When 195 Rule_IPv6_M_Prefix is ASM mode, the corresponding Rule_IPv4_M_Prefix 196 in the same rule should be ASM mode. 198 If Rule_IPv6_M_Prefix is ASM mode but the corresponding 199 Rule_IPv4_M_Prefix is SSM mode, the CONV node should process this 200 rule as invalid. Also, if Rule_IPv6_M_Prefix is SSM mode but the 201 corresponding Rule_IPv4_M_Prefix is ASM mode, the CONV node should 202 process this rule as invalid. 204 4.2. IPv4 Multicast Address Suffix-embedded IPv6 Multicast Address 206 When Rule_IPv4_Type value is 0, the concentrated IPv6 Multicast 207 Address format is as follow: 209 | n bits | o bits | m-n-o bits | 128-m bits | 210 +----------------------+-----------+-------------+-----------------------+ 211 | Rule_IPv6_M_Prefix | 0x00 |IPv4_M_Suffix| 0x00 | 212 +----------------------+-----------+-------------+-----------------------+ 213 |<------------------- IPv6 Multicast Address -------------------- --->| 215 Figure 2: IPv6 Multicast Address Format for Rule_IPv4_Type=0 217 The IPv6 Multicast Address is created by combining the 218 Rule_IPv6_M_Prefix and IPv4_M_Suffix and all zeros. Where the 219 IPv4_M_Suffix is embedded is dependent with the 220 Rule_IPv4_Offset(m).From the above format, with the 221 Rule_IPv4_Offset(m), can induce the embedded position of the 222 IPv4_M_Suffix. Then can concentrate the IPv6 Multicast Address as 223 above. The IPv4_M_Suffix illustrates as follow: 225 | r bits | p bits | 226 +--------------------+---------------------+ 227 |Rule_IPv4_M_Prefix | IPv4_M_Suffix | 228 +--------------------+---------------------+ 229 | 32 bits IPv4 Destination Address | 231 Figure 3 233 If Rule_IPv4_Offset value is 0, puts the IPv4_M_Suffix in the last 234 (32-r) bits in the 128-bits IPv6 Multicast Address. 236 4.3. Full IPv4 Multicast Address-embedded IPv6 Multicast Address 238 When Rule_IPv4_Type value is 1, the concentrated IPv6 Multicast 239 Address format is as follow: 241 | n bits | o bits | 32 bits | 128-m bits | 242 +----------------------+-----------+---------------+-----------------------+ 243 | Rule_IPv6_M_Prefix | 0x00 |Full IPv4 M Add| 0x00 | 244 +----------------------+-----------+---------------+-----------------------+ 245 |<------------------- IPv6 Multicast Address -------------------------->| 247 Figure 4: IPv6 Multicast Address Format for Rule_IPv4_Type=1 249 The IPv6 Multicast Address is created by combining the 250 Rule_IPv6_M_Prefix and Full IPv4 Destination Address and all zeros. 251 Where the Full IPv4 Destination Address is embedded is dependent with 252 the Rule_IPv4_Offset(m).From the above format, with the 253 Rule_IPv4_Offset(m), can induce the embedded position of the Full 254 IPv4 Destination Address. Then can concentrate the IPv6 Multicast 255 Address as above. The Full IPv4 Destination Address is the 256 destination IPv4 address in the multicast flow. 258 5. Forwarding 260 5.1. From IPv4 Multicast System to IPv6 Multicast System 262 When a CONV node receives IPv4 multicast flow from IPv4 Multicast 263 System, the CONV node should check whether there is a 264 Rule_IPv4_M_Prefix longest match with the destination IPv4 multicast 265 address. If there is no such rule which has a longest match prefix, 266 the CONV node should drop these IPv4 multicast flow. If there is a 267 rule which has a longest match prefix with the destination IPv4 268 multicast address, then do the IPv4-IPv6 conversion according to this 269 rule. And then derive the IPv6 multicast address. The CONV node 270 then checks the IPv6 multicast routing table ,finds the outgoing 271 interface and forwards the IPv6 multicast flow into the IPv6 272 Multicast System. 274 5.2. From IPv6 Multicast System to IPv6 Multicast System 276 When a CONV node receives IPv6 multicast flow from IPv6 Multicast 277 System, the CONV node should check whether there is a 278 Rule_IPv6_M_Prefix longest match with the destination IPv6 multicast 279 address. If there is no such rule which has a longest match prefix, 280 the CONV node should drop these IPv6 multicast flow. If there is a 281 rule which has a longest match prefix with the destination IPv6 282 multicast address, then do the IPv4-IPv6 conversion according to this 283 rule. If the Rule_IPv4_Type value is 0, then derives the 284 IPv4_M_Suffix from the destination IPv6 address at the 285 Rule_IPv4_Offset, concentrates the Rule_IPv4_M_Prefix with the 286 IPv4_M_Suffix as the destination IPv4 multicast address. If the 287 Rule_IPv4_Type value is 1, then derives the destination IPv4 address 288 from the destination IPv6 address at the Rule_IPv4_Offset. The CONV 289 node then checks the IPv4 multicast routing table , finds the 290 outgoing interface and forwards the IPv4 multicast flow into the IPv4 291 Multicast System. 293 6. Backwards compatibility 295 This solution is fully compatible with the multicast address format 296 in the "draft-ietf-mboned-64-multicast-address-format". 298 7. Security Considerations 300 To be added later on as-needed basis. 302 8. References 304 8.1. Normative References 306 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 307 Requirement Levels", BCP 14, RFC 2119, March 1997. 309 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 310 Multicast Addresses", RFC 3306, August 2002. 312 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 313 (IPv6) Addressing Architecture", RFC 3513, April 2003. 315 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 316 IPv4/IPv6 Translation", RFC 6144, April 2011. 318 8.2. Informative References 320 [I-D.ietf-mboned-64-multicast-address-format] 321 Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and 322 M. Xu, "IPv6 Multicast Address With Embedded IPv4 323 Multicast Address", 324 draft-ietf-mboned-64-multicast-address-format-05 (work in 325 progress), April 2013. 327 Authors' Addresses 329 Chongfeng Xie 330 China Telecom 331 Room 502, No.118, Xizhimennei Street 332 Beijing 333 China 335 Email: xiechf01@gmail.com,xiechf@ctbri.com.cn 337 Qiong Sun 338 China Telecom 339 Beijing 340 China 342 Email: bingxuere@gmail.com,sunqiong@ctbri.com.cn 344 Cui Wang 345 ZTE Corporation 346 No.50 Software Avenue, Yuhuatai District 347 Nanjing 348 China 350 Email: wang.cui1@zte.com.cn 352 Wei Meng 353 ZTE Corporation 354 No.50 Software Avenue, Yuhuatai District 355 Nanjing 356 China 358 Email: meng.wei2@zte.com.cn,vally.meng@gmail.com 360 Bhumip Khasnabish 361 ZTE USA,Inc 362 55 Madison Avenue, Suite 160 363 Morristown, NJ 07960 364 USA 366 Email: bhumip.khasnabish@zteusa.com,vumip1@gmail.com