idnits 2.17.1 draft-ietf-mboned-mcaddrdoc-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 : ---------------------------------------------------------------------------- == There are 6 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 17, 2012) is 4359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3513 (Obsoleted by RFC 4291) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Venaas 3 Internet-Draft R. Parekh 4 Intended status: Informational G. Van de Velde 5 Expires: November 18, 2012 cisco Systems 6 T. Chown 7 University of Southampton 8 M. Eubanks 9 Iformata Communications 10 May 17, 2012 12 Multicast Addresses for Documentation 13 draft-ietf-mboned-mcaddrdoc-04.txt 15 Abstract 17 This document discusses which multicast addresses should be used for 18 documentation purposes and reserves multicast addresses for such use. 19 Some multicast addresses are derived from AS numbers or unicast 20 addresses. This document also explains how these can be used for 21 documentation purposes. 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 November 18, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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. IPv4 multicast documentation addresses . . . . . . . . . . . . 4 59 2.1. Administratively scoped IPv4 multicast addresses . . . . . 4 60 2.2. GLOP multicast addresses . . . . . . . . . . . . . . . . . 4 61 2.3. Unicast prefix based IPv4 multicast addresses . . . . . . 5 62 3. IPv6 multicast documentation addresses . . . . . . . . . . . . 6 63 3.1. Unicast prefix based IPv6 multicast addresses . . . . . . 6 64 3.2. Embedded-RP IPv6 multicast addresses . . . . . . . . . . . 6 65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 68 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 71 1. Introduction 73 It is often useful in documentation, IETF documents, etc., to provide 74 examples containing IP multicast addresses. For documentation where 75 examples of general purpose multicast addresses are needed, one 76 should use multicast addresses that never will be assigned or in 77 actual use. There is a risk that addresses used in examples may 78 accidentally be used. It is then important that the same addresses 79 are not used by other multicast applications or services. It may 80 also be beneficial to filter out such addresses from multicast 81 signalling and multicast data sent to such addresses. 83 For unicast there are both IPv4 and IPv6 addresses reserved for this 84 purpose, see [RFC5737] and [RFC3849] respectively. This document 85 reserves multicast addresses for this purpose. 87 There are also some multicast addresses that are derived from AS 88 numbers or unicast addresses. For examples where such addresses are 89 desired, one should derive them from the AS numbers and unicast 90 addresses reserved for documentation purposes. This document also 91 discusses the use of these. 93 2. IPv4 multicast documentation addresses 95 For Any-Source Multicast (ASM), the IPv4 multicast addresses 96 allocated for documentation purposes are 233.252.0.0 - 233.252.0.255 97 (233.252.0.0/24). 99 For Source-Specific Multicast (SSM) it is less important which 100 multicast addresses are used, since a host/application joins a 101 channel identified by both source and group. Any source addresses 102 used in SSM examples should be unicast addresses reserved for 103 documentation purposes. There are three unicast address ranges 104 provided for documentation use in [RFC5737]. The ranges are 105 192.0.2.0/24, 198.51.100.0/24 and 203.0.113.0/24. 107 Sometimes one wants to give examples where a specific type of address 108 is desired. E.g. for text about multicast scoping, one might want 109 the examples to use addresses that are to be used for administrative 110 scoping. See below for guidance on how to construct specific types 111 of example addresses. 113 2.1. Administratively scoped IPv4 multicast addresses 115 Administratively scoped IPv4 multicast addresses [RFC2365] are 116 reserved for scoped multicast. They can be used within a site or an 117 organization. Apart from a small set of scope relative addresses, 118 these addresses are not assigned. The high order /24 in every scope 119 is reserved for relative assignments. A relative assignment is an 120 integer offset from the highest address in the scope and represents 121 an IPv4 address. For documentation purposes, the integer offset is 122 TBD1. This provides one multicast address per scope. 124 For example in the Local Scope 239.255.0.0/16, the multicast address 125 for documentation purposes is 239.255.255.255-TBD1. 127 2.2. GLOP multicast addresses 129 GLOP [RFC3180] is a method for deriving IPv4 multicast group 130 addresses from 16-bit AS numbers. For examples where GLOP addresses 131 are desired, the addresses should be derived from the AS numbers 132 reserved for documentation use. 134 The 16-bit AS numbers reserved for documentation use in [RFC5398] are 135 64496 - 64511. By use of [RFC3180], we then get 16 /24 multicast 136 prefixes for documentation use. The first one 233.251.240.0/24, and 137 the last 233.251.255.0/24. 139 2.3. Unicast prefix based IPv4 multicast addresses 141 IPv4 multicast addresses can be derived from IPv4 unicast prefixes, 142 see [RFC6034]. For examples where this type of addresses are 143 desired, the addresses should be derived from the unicast addresses 144 reserved for documentation purposes, see [RFC5737]. 146 There are three unicast address ranges provided for documentation use 147 in [RFC5737]. The ranges are 192.0.2.0/24, 198.51.100.0/24 and 148 203.0.113.0/24. Using [RFC6034] this leaves us with the unicast 149 prefix based IPv4 multicast addresses 234.192.0.2, 234.198.51.100 and 150 234.203.0.113. 152 3. IPv6 multicast documentation addresses 154 For Any-Source Multicast (ASM) the IPv6 multicast addresses allocated 155 for documentation purposes are TBD2. This is a /96 prefix so that it 156 can be used with group IDs according to the allocation guidelines in 157 [RFC3307]). Also note that for these addresses the transient flag, 158 the T-flag as defined in [RFC3513], is zero. This is because they 159 are permanently assigned. There can be no permanently assigned 160 addresses for documentation purposes with the transient flag set to 161 one, since the flag set to one means that they are not permanently 162 assigned. 164 For Source-Specific Multicast (SSM) it is less important which 165 multicast addresses are used, since a host/application joins a 166 channel identified by both source and group. Any source addresses 167 used in SSM examples should be unicast addresses reserved for 168 documentation purposes. The IPv6 unicast prefix reserved for 169 documentation purposes is 2001:DB8::/32, see [RFC3849]. 171 Sometimes one wants to give examples where a specific type of address 172 is desired. E.g. for text about multicast scoping, one might want 173 the examples to use addresses that are to be used for administrative 174 scoping. See below for guidance on how to construct specific types 175 of example addresses. 177 3.1. Unicast prefix based IPv6 multicast addresses 179 IPv6 multicast addresses can be derived from IPv6 unicast prefixes, 180 see [RFC3306]. For examples where this type of addresses is desired, 181 the addresses should be derived from the unicast addresses reserved 182 for documentation purposes. 184 The IPv6 unicast prefix reserved for documentation purposes is 2001: 185 DB8::/32, see [RFC3849]. This allows a wide range of different IPv6 186 multicast addresses. Using just the base /32 prefix, one gets the 187 IPv6 multicast prefixes FF3X:20:2001:DB8::/64, one for each available 188 scope X. One can also produce longer prefixes from this. Just as an 189 example, one can pick say a /64 prefix 2001:DB8:DEAD:BEEF::/64 which 190 gives the multicast prefixes FF3X:40:2001:DB8:DEAD:BEEF::/96, one for 191 each available scope X. 193 3.2. Embedded-RP IPv6 multicast addresses 195 There is a type of IPv6 multicast addresses called Embedded-RP 196 addresses where the IPv6 address of a Rendezvous-Point is embedded 197 inside the multicast address, see [RFC3956]. For examples where this 198 type of addresses is desired, the addresses should be derived from 199 the unicast addresses reserved for documentation purposes, see 201 [RFC3849]. 203 For documentation purposes, the RP address can be any address from 204 the range 2001:DB8::/32 that follows the constraints specified in 205 [RFC3956]. One example address could be 2001:DB8::1. The 206 embedded-RP multicast prefixes might then be FF7X:120:2001:DB8::/96. 207 Another example could be the RP address 2001:DB8:BEEF:FEED::7 which 208 gives the prefixes FF7X:740:2001:DB8:BEEF:FEED::/96. See also the 209 examples in [RFC3956]. 211 4. Security Considerations 213 The use of specific multicast addresses for documentation purposes 214 has no negative impact on security. 216 5. IANA Considerations 218 IANA is requested to add a reference to this document for the IPv4 219 MCAST-TEST-NET allocation, so that all the different documentation 220 multicast assignments reference this document. 222 IANA is requested to assign a scope relative IPv4 address for 223 documentation purposes. 225 This paragraph contains some further instructions for IANA in order 226 to clarify. It should be deleted before publishing. The string TBD1 227 in this document should be replaced by the assigned offset. Also the 228 string 255-TBD1 should be replaced by the value of 255 minus the 229 assigned offset. The next available offset seems currently to be 10. 230 Look in the registry for where it says "10-252 Reserved - To be 231 assigned by the IANA". If the value 10 is chosen, then we would like 232 to add "10 MCAST-TEST-NET-2 [RFCxxxx]" to the table. TBD1 would then 233 be 10. TBD1 is used in two places apart from the IANA 234 considerations. In one place it says just TBD1, that should be 235 replaced by "10". The other place it says "239.255.255.255-TBD1". 236 That should then be replaced by "239.255.255.245". In the unlikely 237 event that 10 is not available, please use the first available value 238 accordingly. MCAST-TEST-NET-2 is suggested here, since the existing 239 allocation is named MCAST-TEST-NET. 241 IANA is requested to assign "variable scope" IPv6 multicast addresses 242 for documentation purposes. This should be a /96 prefix. 244 This paragraph contains some further instructions for IANA in order 245 to clarify. It should be deleted before publishing. The word TBD2 246 in this text should be replaced with the assigned prefix. The prefix 247 should be of the form FF0X:.../96. In order to make this 248 documentation prefix easily recognizable, the authors would like to 249 request the prefix FF0X::DB8:0:0/96 if possible. This makes it 250 somewhat similar to the IPv6 unicast prefix 2001:DB8::/32. We 251 suggest they are denoted as "Documentation Addresses" with a 252 reference to this document. 254 6. Acknowledgments 256 The authors thank Roberta Maglione, Leonard Giuliano and Dave Thaler 257 for providing comments on this document. 259 7. Informative References 261 [RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, 262 RFC 2365, July 1998. 264 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 265 BCP 53, RFC 3180, September 2001. 267 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 268 Multicast Addresses", RFC 3306, August 2002. 270 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 271 Addresses", RFC 3307, August 2002. 273 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 274 (IPv6) Addressing Architecture", RFC 3513, April 2003. 276 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 277 Reserved for Documentation", RFC 3849, July 2004. 279 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 280 Point (RP) Address in an IPv6 Multicast Address", 281 RFC 3956, November 2004. 283 [RFC5398] Huston, G., "Autonomous System (AS) Number Reservation for 284 Documentation Use", RFC 5398, December 2008. 286 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 287 Reserved for Documentation", RFC 5737, January 2010. 289 [RFC6034] Thaler, D., "Unicast-Prefix-Based IPv4 Multicast 290 Addresses", RFC 6034, October 2010. 292 Authors' Addresses 294 Stig Venaas 295 cisco Systems 296 Tasman Drive 297 San Jose, CA 95134 298 USA 300 Email: stig@cisco.com 302 Rishabh Parekh 303 cisco Systems 304 Tasman Drive 305 San Jose, CA 95134 306 USA 308 Email: riparekh@cisco.com 310 Gunter Van de Velde 311 cisco Systems 312 De Kleetlaan 6a 313 Diegem 1831 314 Belgium 316 Phone: +32 476 476 022 317 Email: gvandeve@cisco.com 319 Tim Chown 320 University of Southampton 321 Highfield 322 Southampton, Hampshire SO17 1BJ 323 United Kingdom 325 Email: tjc@ecs.soton.ac.uk 326 Marshall Eubanks 327 Iformata Communications 328 130 W. Second Street 329 Dayton, Ohio 45402 330 US 332 Phone: +1 703 501 4376 333 Email: marshall.eubanks@iformata.com 334 URI: http://www.iformata.com/