idnits 2.17.1 draft-ietf-softwire-multicast-prefix-option-04.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 (April 15, 2013) is 4028 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-18) exists of draft-ietf-softwire-dslite-multicast-04 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire WG M. Boucadair 3 Internet-Draft France Telecom 4 Intended status: Standards Track J. Qin 5 Expires: October 17, 2013 Cisco 6 T. Tsou 7 Huawei Technologies (USA) 8 X. Deng 9 APNIC 10 April 15, 2013 12 DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes 13 draft-ietf-softwire-multicast-prefix-option-04 15 Abstract 17 This document defines Dynamic Host Configuration Protocol version 6 18 (DHCPv6) Option for multicast transition solutions, aiming to convey 19 the IPv6 prefixes to be used to build unicast and multicast 20 IPv4-embedded IPv6 addresses. 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 October 17, 2013. 39 Copyright Notice 41 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 59 3. PREFIX64 DHCPv6 Option . . . . . . . . . . . . . . . . . . . 3 60 4. Configuration Guidelines (Server Side) . . . . . . . . . . . 4 61 5. DHCPv6 Client Behaviour . . . . . . . . . . . . . . . . . . . 5 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 64 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 65 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 67 9.2. Informative References . . . . . . . . . . . . . . . . . 6 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 70 1. Introduction 72 Several solutions (e.g., [I-D.ietf-softwire-dslite-multicast]) are 73 proposed for the delivery of multicast services in the context of 74 transition to IPv6. Even if these solutions may have different 75 applicable use cases, they all use specific IPv6 addresses to embed 76 IPv4 addresses, for both multicast group, and multicast source 77 addresses. 79 This document defines a DHCPv6 option [RFC3315] to convey the IPv6 80 prefixes to be used for constructing these IPv4-embedded IPv6 81 addresses. 83 This option can be in particular used in the context of DS-Lite 84 [RFC6333], Stateless A+P [RFC6346] and other IPv4-IPv6 transition 85 techniques. 87 1.1. Requirements Language 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 RFC 2119 [RFC2119]. 93 2. Terminology 95 This document makes use of the following terms: 97 o IPv4-embedded IPv6 address: is an IPv6 address which embeds a 32 98 bit-encoded IPv4 address [RFC6052]. An IPv4-embedded IPv6 address 99 can be a unicast or a multicast address. 100 o PREFIX64: is an IPv6 prefix used for synthesizing IPv4-embedded 101 IPv6 addresses. A PREFIX64 can be of unicast or multicast. 103 Note: "64" is used as an abbreviation for IPv6-IPv4 104 interconnection. 105 o ASM_PREFIX64: is a multicast PREFIX64 which belongs to the Any- 106 Source Multicast (ASM) range. 107 o SSM_PREFIX64: is a multicast PREFIX64 which belongs to the Source- 108 Specific Multicast (SSM, [RFC4607]) range. 109 o U_PREFIX64: is a unicast PREFIX64 for building the IPv4-embedded 110 IPv6 addresses of multicast sources in SSM mode. 112 3. PREFIX64 DHCPv6 Option 114 OPTION_PREFIX64 (Figure 1) conveys the IPv6 prefix(es) to be used 115 (e.g., by a mB4 [I-D.ietf-softwire-dslite-multicast]) to synthesize 116 IPv4-embbedded IPv6 addresses. 118 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 119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 120 | OPTION_PREFIX64 | option-length | 121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 122 | asm-length | | 123 +-+-+-+-+-+-+-+-+ : 124 : ASM_PREFIX64 (Variable) : 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | ssm-length | | 127 +-+-+-+-+-+-+-+-+ : 128 : SSM_PREFIX64 (Variable) : 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | unicast-length| | 131 +-+-+-+-+-+-+-+-+ : 132 : U_PREFIX64 (Variable) : 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 Figure 1: DHCPv6 Option Format for PREFIX64 137 The fields of the option shown in Figure 1 are as follows: 139 option-code: OPTION_PREFIX64 (see Section 8). 140 option-length: length of the PREFIX64 option. 141 asm-length: the prefix-length for the ASM IPv4-embedded prefix, as 142 an 8-bit unsigned integer (0 to 128). This field represents the 143 number of valid leading bits in the prefix. 145 ASM_PREFIX64: this field identifies the IPv6 multicast prefix to be 146 used to synthesize the IPv4-embedded IPv6 addresses of the 147 multicast groups in the ASM mode. It is a variable size field 148 with the length of the field defined by the asm-length field and 149 is rounded up to the nearest octet boundary. In such case any 150 additional padding bits must be zeroed. The conveyed multicast 151 IPv6 prefix MUST belong to the ASM range. This prefix is likely 152 to be a /96. 153 ssm-length: the prefix-length for the SSM IPv4-embedded prefix, as 154 an 8-bit unsigned integer (0 to 128). This field represents the 155 number of valid leading bits in the prefix. 156 SSM_PREFIX64: this field identifies the IPv6 multicast prefix to be 157 used to synthesize the IPv4-embedded IPv6 addresses of the 158 multicast groups in the SSM mode. It is a variable size field 159 with the length of the field defined by the ssm-length field and 160 is rounded up to the nearest octet boundary. In such case any 161 additional padding bits must be zeroed. The conveyed multicast 162 IPv6 prefix MUST belong to the SSM range. This prefix is likely 163 to be a /96. 164 unicast-length: the prefix-length for the IPv6 unicast prefix to be 165 used to synthesize the IPv4-embedded IPv6 addresses of the 166 multicast sources, as an 8-bit unsigned integer (0 to 128). This 167 field represents the number of valid leading bits in the prefix. 168 U_PREFIX64: this field identifies the IPv6 unicast prefix to be used 169 in SSM mode for constructing the IPv4-embedded IPv6 addresses 170 representing the IPv4 multicast sources in the IPv6 domain. 171 U_PREFIX64 may also be used to extract the IPv4 address from the 172 received multicast data flows. It is a variable size field with 173 the length of the field defined by the unicast-length field and is 174 rounded up to the nearest octet boundary. In such case any 175 additional padding bits must be zeroed. The address mapping MUST 176 follow the guidelines documented in [RFC6052]. 178 4. Configuration Guidelines (Server Side) 180 DHCP servers supporting OPTION_PREFIX64 should be configured with 181 U_PREFIX64 and at least one ASM_PREFIX64 or one SSM_PREFIX64. 183 When ASM_PREFIX64 and SSM_PREFIX64 are configured, the length of 184 these prefixes must be /96. 186 Both ASM_PREFIX64 and SSM_PREFIX64 may be configured and therefore be 187 returned to a requesting DHCP client; it is deployment-specific. In 188 particular, if both SSM and ASM modes are supported, ASM_PREFIX64 and 189 SSM_PREFIX64 prefixes must be configured. For SSM deployments, both 190 SSM_PREFIX64 and U_PREFIX64 should be configured. 192 5. DHCPv6 Client Behaviour 194 To retrieve the IPv6 prefixes that will be used to synthesize unicast 195 and multicast IPv4-embedded IPv6 addresses, the DHCPv6 client MUST 196 include OPTION_PREFIX64 in its OPTION_ORO. If the DHCPv6 client 197 receives more than one OPTION_PREFIX64 option from the DHCPv6 server: 199 o If all the enclosed IPv4-embedded IPv6 multicast prefixes have the 200 same scope, the first instance of the option MUST be used. 201 o If each enclosed IPv4-embedded IPv6 multicast prefix has a 202 distinct scope, the client MUST select the appropriate 203 IPv4-embedded IPv6 multicast prefix having a scope matching the 204 IPv4 multicast address used to synthesize an IPv4-embedded IPv6 205 multicast address. 207 If asm-length, ssm-length and unicast-length fields are all set to 0, 208 the DHCPv6 client MUST behave as if OPTION_PREFIX64 had not been 209 received in the response received from the DHCPv6 server. 211 If the asm-length field is non-null, the IPv6 prefix identified by 212 ASM_PREFIX64 is used to synthesize IPv4-embedded IPv6 multicast 213 addresses in the ASM range. This is achieved by concatenating the 214 ASM_PREFIX64 and the IPv4 multicast address; the Pv4 multicast 215 address is inserted in the last 32 bits of the IPv4-embedded IPv6 216 multicast address. 218 If the ssm-length field is non-null, the IPv6 prefix identified by 219 SSM_PREFIX64 is used to synthesize IPv4-embedded IPv6 multicast 220 addresses in the SSM range. This is achieved by concatenating the 221 SSM_PREFIX64 and the IPv4 multicast address; the Pv4 multicast 222 address is inserted in the last 32 bits of the IPv4-embedded IPv6 223 multicast address. 225 If the unicast-length field is non-null, the IPv6 prefix identified 226 by U_PREFIX64 field is used to synthesize IPv4-embedded IPv6 unicast 227 addresses as specified in [RFC6052]. 229 6. Security Considerations 231 The security considerations documented in [RFC3315] and [RFC6052] are 232 to be considered. 234 7. Acknowledgements 236 Particular thanks to C. Jacquenet, S. Venaas, B. Volz and T. 237 Taylor for their review. 239 8. IANA Considerations 241 Authors of this document requests IANA to assign a new DHCPv6 option: 243 Option Name Value 244 ----------------- ----- 245 OPTION_PREFIX64 TBA 247 9. References 249 9.1. Normative References 251 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 252 Requirement Levels", BCP 14, RFC 2119, March 1997. 254 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 255 and M. Carney, "Dynamic Host Configuration Protocol for 256 IPv6 (DHCPv6)", RFC 3315, July 2003. 258 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 259 IP", RFC 4607, August 2006. 261 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 262 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 263 October 2010. 265 9.2. Informative References 267 [I-D.ietf-softwire-dslite-multicast] 268 Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. 269 Wang, "Delivery of IPv4 Multicast Services to IPv4 Clients 270 over an IPv6 Multicast Network", draft-ietf-softwire- 271 dslite-multicast-04 (work in progress), October 2012. 273 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 274 Stack Lite Broadband Deployments Following IPv4 275 Exhaustion", RFC 6333, August 2011. 277 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 278 IPv4 Address Shortage", RFC 6346, August 2011. 280 Authors' Addresses 281 Mohamed Boucadair 282 France Telecom 283 Rennes 35000 284 France 286 Email: mohamed.boucadair@orange.com 288 Jacni Qin 289 Cisco 290 China 292 Email: jacni@jacni.com 294 Tina Tsou 295 Huawei Technologies (USA) 296 2330 Central Expressway 297 Santa Clara 298 USA 300 Phone: +1 408 330 4424 301 Email: tina.tsou.zouting@huawei.com 303 Xiaohong Deng 304 APNIC 305 Australia 307 Email: dxhbupt@gmail.com