idnits 2.17.1 draft-cheshire-dnsext-special-names-03.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 3 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 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 -- The draft header indicates that this document updates RFC1918, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC2606, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC1918, updated by this document, for RFC5378 checks: 1995-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sep 19, 2012) is 4235 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 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 5735 (Obsoleted by RFC 6890) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Cheshire 3 Internet-Draft M. Krochmal 4 Updates: 1918, 2606 Apple Inc. 5 (if approved) Sep 19, 2012 6 Intended status: Standards Track 7 Expires: March 23, 2013 9 Special-Use Domain Names 10 draft-cheshire-dnsext-special-names-03 12 Abstract 14 This document describes what it means to say that a Domain Name (DNS 15 name) is reserved for special use, when reserving such a name is 16 appropriate, and the procedure for doing so. It establishes an IANA 17 registry for such domain names, and seeds it with entries for some of 18 the already-established special domain names. 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 working 27 documents as Internet-Drafts. The list of current Internet-Drafts is 28 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 23, 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 1. Introduction 54 Certain individual IP addresses and IP address ranges are treated 55 specially by network implementations, and consequently are not 56 suitable for use as unicast addresses. For example, IPv4 addresses 57 224.0.0.0 to 239.255.255.255 are multicast addresses [RFC5735], with 58 224.0.0.1 being the "all hosts" multicast address [RFC1112] 59 [RFC5771]. Another example is 127.0.0.1, the IPv4 "local host" 60 address [RFC5735]. 62 Analogous to Special-Use IPv4 Addresses [RFC5735], The Domain Name 63 System (DNS) [RFC1034][RFC1035] has its own concept of reserved 64 names, such as "example.com.", "example.net.", and "example.org.", or 65 any name falling under the top level pseudo-domain "invalid." 66 [RFC2606]. However, "Reserved Top Level DNS Names" [RFC2606] does not 67 state whether implementations are expected to treat such names 68 differently, and if so, in what way. 70 This document specifies under what circumstances special treatment is 71 appropriate, and in what ways. 73 2. Terminology 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in "Key words for use in 78 RFCs to Indicate Requirement Levels" [RFC2119]. 80 3. Applicability 82 When IP multicast was created [RFC1112], implementations had to be 83 updated to understand what an IP multicast address means and what to 84 do with it. Adding IP multicast to a networking stack entailed more 85 than merely adding the right routing table entries for those 86 addresses. Moreover, supporting IP multicast entails some level of 87 commonality that is consistent across all conformant hosts, 88 independent of what networks those hosts may be connected to. While 89 it is possible to build a private isolated network using whatever 90 valid unicast IP addresses and routing topology you choose 91 (regardless of whether those unicast IP addresses are already in use 92 by other hosts on the public Internet) the IPv4 multicast address 93 224.0.0.1 is always the "all hosts" multicast address, and that's not 94 a local decision. 96 Similarly, if a domain name has special properties that affect the 97 way hardware and software implementations handle the name, which 98 apply universally regardless of what network the implementation may 99 be connected to, then that may be a candidate for having the IETF 100 declare the name to be a Special-Use Domain Name and specify what 101 special treatment implementations should give to that name. On the 102 other hand, if declaring a given name to be special would result in 103 no change to any implementations, then that suggests that the name 104 may not be special in any material way, and it may be more 105 appropriate to use the existing DNS mechanisms [RFC1034] to provide 106 the desired delegation, data, or lack-of-data, for the name in 107 question. Where the desired behaviour can be achieved via the 108 existing domain name registration processes, that process should be 109 used. Reservation of a Special-Use Domain Name is not a mechanism for 110 circumventing normal domain name registration processes. 112 As an example, suppose there were to be an IETF document specifying 113 that a particular name (or set of names) is guaranteed to produce an 114 NXDOMAIN ("Name Error" [RFC1035]) result. Such a document falls 115 within the responsibilites of the IETF. The IETF is responsible for 116 protocol rules. The IETF defines name character set, length limits, 117 syntax, the fact that in DNS "A" is equivalent to "a", etc. 118 [RFC1034][RFC1035]. Portions of the namespace created by those rules 119 are given to ICANN to manage, but due to existing DNS protocol rules 120 ICANN is not free to allocate "COM" and "com" to two different name 121 servers. The IETF has responsibility for specifying how the DNS 122 protocol works, and ICANN is responsible for allocating the names 123 made possible by that DNS protocol. Now, suppose a developer were to 124 use this special "guaranteed nonexistent" name, "knowing" that it's 125 guaranteed to return NXDOMAIN, and suppose also that the user's DNS 126 server does not return NXDOMAIN for this name. The developer's 127 software then fails. Who do the user and/or developer complain to? 128 ICANN? The IETF? The DNS server operator? If the developer can't 129 depend on the special "guaranteed nonexistent" name to always return 130 NXDOMAIN then the special name is worthless, because it can't be 131 relied on to do what it is supposed to. For this special "guaranteed 132 nonexistent" name to have any use, it has to be defined to return 133 NXDOMAIN, BY PROTOCOL, for all installations, not just by ICANN 134 allocation on the public Internet. ICANN has no jurisdiction over how 135 users choose to configure their own private DNS servers on their own 136 private networks, but developers need a protocol specification that 137 states that returning answers for the special "guaranteed 138 nonexistent" name is a protocol violation on *all* networks, not just 139 the public Internet. Hence definition of such a special name would be 140 a higher-level protocol rule, above ICANN's management of allocable 141 names on the public Internet. 143 4. Procedure 145 If it is determined that special handling of a name is required in 146 order to implement some desired new functionality, then an IETF 147 "Standards Action" or "IESG Approval" specification [RFC5226] MUST be 148 published describing the new functionality, and: 150 o The specification needs to state how implementations determine 151 that the special handling is required for any given name. This is 152 typically done by stating that any fully-qualified domain names 153 ending in a certain suffix (i.e. falling within a specified parent 154 pseudo-domain) will receive the special behaviour. In effect this 155 carves off a sub-tree of the DNS namespace in which the modified 156 name treatment rules apply, analogous to how IP multicast 157 [RFC1112] or IP link-local addresses [RFC3927] [RFC4862] carve off 158 chunks of the IP address space in which their respective modified 159 address treatment rules apply. 161 o The specification needs to state, in each of the seven categories 162 below, what special treatment, if any, is to be applied. If the 163 answer in all seven categories is "none", then possibly no special 164 treatment is required and requesting reservation of a Special-Use 165 Domain Name may not be appropriate. 167 5. Domain Name Reservation Considerations 169 An IETF "Standards Action" or "IESG Approval" document specifying 170 some new naming behaviour, which requires a Special-Use Domain Name 171 be reserved to implement this desired new behaviour, needs to contain 172 a subsection of the "IANA Considerations" section entitled "Domain 173 Name Reservation Considerations" giving answers in the seven 174 categories listed below. In the case of algorithmically generated DNS 175 names, the specifying document needs to clearly identify the set of 176 names generated by the algorithm which would require the proposed 177 special treatment. 179 1. Users: 181 Are human users expected to recognize these names as special and 182 use them differently? In what way? 184 2. Application Software: 186 Are writers of application software expected to make their 187 software recognize these names as special and treat them 188 differently? In what way? (e.g. if a human users enters such a 189 name, should the application software reject it with an error 190 message?) 192 3. Name Resolution APIs and libraries: 194 Are writers of name resolution APIs and libraries expected to make 195 their software recognize these names as special and treat them 196 differently? If so, how? 198 4. Caching DNS Servers: 200 Are developers of caching DNS name servers expected to make their 201 implementations recognize these names as special and treat them 202 differently? If so, how? 204 5. Authoritative DNS Servers: 206 Are developers of authoritative DNS name servers expected to make 207 their implementations recognize these names as special and treat 208 them differently? If so, how? 210 6. DNS Server Operators: 212 Does this reserved Special-Use Domain Name have any potential 213 impact on DNS server operators? If they try to configure their 214 authoritative DNS server as authoritative for this reserved name, 215 will compliant name server software reject it as invalid? Do DNS 216 server operators need to know about that and understand why? Even 217 if the name server software doesn't prevent them from using this 218 reserved name, are there other ways that it may not work as 219 expected, which the DNS server operator should be aware of? 221 7. DNS Registries/Registrars: 223 How should DNS Registries/Registrars treat requests to register 224 this reserved domain name? Should such requests be denied? Should 225 such requests be allowed, but only to a specially-designated 226 entity? (For example, the name "www.example.org" is reserved for 227 documentation examples and is not available for registration; 228 however, the name is in fact registered; and there is even a web 229 site at that name, which states circularly that the name is 230 reserved for use in documentation and cannot be registered!) 232 6. Initial Registry 234 The initial IANA "Special-Use Domain Names" registry shall contain 235 entries for the private-address [RFC1918] reverse-mapping domains and 236 for the exising Reserved Top Level DNS Names [RFC2606]. 238 6.1. Domain Name Reservation Considerations for Private Addresses 240 The private-address [RFC1918] reverse-mapping domains listed below, 241 and any names falling within those domains, are Special-Use Domain 242 Names: 244 10.in-addr.arpa. 21.172.in-addr.arpa. 26.172.in-addr.arpa. 245 16.172.in-addr.arpa. 22.172.in-addr.arpa. 27.172.in-addr.arpa. 246 17.172.in-addr.arpa. 30.172.in-addr.arpa. 28.172.in-addr.arpa. 247 18.172.in-addr.arpa. 23.172.in-addr.arpa. 29.172.in-addr.arpa. 248 19.172.in-addr.arpa. 24.172.in-addr.arpa. 31.172.in-addr.arpa. 249 20.172.in-addr.arpa. 25.172.in-addr.arpa. 168.192.in-addr.arpa. 251 These domains, and any names falling within these domains, are 252 special in the following ways: 254 1. Users are free to use these names as they would any other reverse- 255 mapping names. However, since there is no central authority 256 responsible for use of private addresses, users SHOULD be aware 257 that these names are likely to yield different results on 258 different networks. 260 2. Application software SHOULD NOT recognize these names as special, 261 and SHOULD use these names as they would other reverse-mapping 262 names. 264 3. Name resolution APIs and libraries SHOULD NOT recognize these 265 names as special and SHOULD NOT treat them differently. Name 266 resolution APIs SHOULD send queries for these names to their 267 configured caching DNS server(s). 269 4. Caching DNS servers SHOULD recognize these names as special and 270 SHOULD NOT, by default, attempt to look up NS records for them, or 271 otherwise query authoritative DNS servers in an attempt to resolve 272 these names. Instead, caching DNS servers SHOULD by default 273 generate immediate (positive or negative) responses for all such 274 queries. This is to avoid unnecessary load on the root name 275 servers and other name servers. Caching DNS servers SHOULD offer a 276 configuration option (disabled by default) to enable upstream 277 resolving of such names, for use in private networks where 278 private-address reverse-mapping names are known to be handled by 279 an authoritative DNS server in said private network. 281 5. Authoritative DNS servers SHOULD recognize these names as special 282 and SHOULD by default generate immediate negative responses for 283 all such queries, unless explicitly configured by the 284 administrator to give positive answers for private-address 285 reverse-mapping names. 287 6. DNS server operators SHOULD, if they are using private addresses, 288 configure their authoritative DNS servers to act as authoritative 289 for these names. 291 7. DNS Registries/Registrars MUST NOT grant requests to register any 292 of these names in the normal way to any person or entity. These 293 names are reserved for use in private networks, and fall outside 294 the set of names available for allocation by registries/ 295 registrars. Attempting to allocate one of these names as if it 296 were a normal DNS domain name will probably not work as desired, 297 for reasons 4, 5 and 6 above. 299 6.2. Domain Name Reservation Considerations for "test." 301 The domain "test.", and any names falling within ".test.", are 302 special in the following ways: 304 1. Users are free to use these test names as they would any other 305 domain names. However, since there is no central authority 306 responsible for use of test names, users SHOULD be aware that 307 these names are likely to yield different results on different 308 networks. 310 2. Application software SHOULD NOT recognize test names as special, 311 and SHOULD use test names as they would other domain names. 313 3. Name resolution APIs and libraries SHOULD NOT recognize test names 314 as special and SHOULD NOT treat them differently. Name resolution 315 APIs SHOULD send queries for test names to their configured 316 caching DNS server(s). 318 4. Caching DNS servers SHOULD recognize test names as special and 319 SHOULD NOT, by default, attempt to look up NS records for them, or 320 otherwise query authoritative DNS servers in an attempt to resolve 321 test names. Instead, caching DNS servers SHOULD by default 322 generate immediate negative responses for all such queries. This 323 is to avoid unnecessary load on the root name servers and other 324 name servers. Caching DNS servers SHOULD offer a configuration 325 option (disabled by default) to enable upstream resolving of test 326 names, for use in networks where test names are known to be 327 handled by an authoritative DNS server in said private network. 329 5. Authoritative DNS servers SHOULD recognize test names as special 330 and SHOULD by default generate immediate negative responses for 331 all such queries, unless explicitly configured by the 332 administrator to give positive answers for test names. 334 6. DNS server operators SHOULD, if they are using test names, 335 configure their authoritative DNS servers to act as authoritative 336 for test names. 338 7. DNS Registries/Registrars MUST NOT grant requests to register test 339 names in the normal way to any person or entity. Test names are 340 reserved for use in private networks, and fall outside the set of 341 names available for allocation by registries/registrars. 342 Attempting to allocate a test name as if it were a normal DNS 343 domain name will probably not work as desired, for reasons 4, 5 344 and 6 above. 346 6.3. Domain Name Reservation Considerations for "localhost." 348 The domain "localhost.", and any names falling within ".localhost.", 349 are special in the following ways: 351 1. Users are free to use localhost names as they would any other 352 domain names. Users may assume that IPv4 and IPv6 address queries 353 for localhost names will always resolve to the respective IP 354 loopback address. 356 2. Application software MAY recognize localhost names as special, or 357 MAY pass them to name resolution APIs as they would for other 358 domain names. 360 3. Name resolution APIs and libraries SHOULD recognize localhost 361 names as special and SHOULD always return the IP loopback address 362 for address queries and negative responses for all other query 363 types. Name resolution APIs SHOULD NOT send queries for localhost 364 names to their configured caching DNS server(s). 366 4. Caching DNS servers SHOULD recognize localhost names as special 367 and SHOULD NOT attempt to look up NS records for them, or 368 otherwise query authoritative DNS servers in an attempt to resolve 369 localhost names. Instead, caching DNS servers SHOULD, for all such 370 address queries generate an immediate positive response giving the 371 IP loopback address, and for all other query types generate an 372 immediate negative response. This is to avoid unnecessary load on 373 the root name servers and other name servers. 375 5. Authoritative DNS servers SHOULD recognize localhost names as 376 special and handle them as described above for caching DNS 377 servers. 379 6. DNS server operators SHOULD be aware that the effective RDATA for 380 localhost names is defined by protocol specification, and cannot 381 be modified by local configuration. 383 7. DNS Registries/Registrars MUST NOT grant requests to register 384 localhost names in the normal way to any person or entity. 385 Localhost names are defined by protocol specification, and fall 386 outside the set of names available for allocation by registries/ 387 registrars. Attempting to allocate a localhost name as if it were 388 a normal DNS domain name will probably not work as desired, for 389 reasons 2, 3, 4, and 5 above. 391 6.4. Domain Name Reservation Considerations for "invalid." 393 The domain "invalid.", and any names falling within ".invalid.", are 394 special in the ways listed below. In the text below, the term 395 "invalid" is used in quotes to signify such names, as opposed to 396 names that may be invalid for other reasons (e.g. being too long). 398 1. Users are free to use "invalid" names as they would any other 399 domain names. Users MAY assume that queries for "invalid" names 400 will always return NXDOMAIN responses. 402 2. Application software MAY recognize "invalid" names as special, or 403 MAY pass them to name resolution APIs as they would for other 404 domain names. 406 3. Name resolution APIs and libraries SHOULD recognize "invalid" 407 names as special and SHOULD always return immediate negative 408 responses. Name resolution APIs SHOULD NOT send queries for 409 "invalid" names to their configured caching DNS server(s). 411 4. Caching DNS servers SHOULD recognize "invalid" names as special 412 and SHOULD NOT attempt to look up NS records for them, or 413 otherwise query authoritative DNS servers in an attempt to resolve 414 "invalid" names. Instead, caching DNS servers SHOULD generate 415 immediate NXDOMAIN responses for all such queries. This is to 416 avoid unnecessary load on the root name servers and other name 417 servers. 419 5. Authoritative DNS servers SHOULD recognize "invalid" names as 420 special and handle them as described above for caching DNS 421 servers. 423 6. DNS server operators SHOULD be aware that the effective RDATA for 424 "invalid" names is defined by protocol specification to be 425 nonexistent, and cannot be modified by local configuration. 427 7. DNS Registries/Registrars MUST NOT grant requests to register 428 "invalid" names in the normal way to any person or entity. These 429 "invalid" names are defined by protocol specification to be 430 nonexistent, and fall outside the set of names available for 431 allocation by registries/registrars. Attempting to allocate a 432 "invalid" name as if it were a normal DNS domain name will 433 probably not work as desired, for reasons 2, 3, 4, and 5 above. 435 6.5. Domain Name Reservation Considerations for Example Domains 437 The domains "example.", "example.com.", "example.net.", 438 "example.org.", and any names falling within those domains, are 439 special in the following ways: 441 1. Users SHOULD understand that example names are reserved for use in 442 documentation. 444 2. Application software SHOULD NOT recognize example names as 445 special, and SHOULD use example names as they would other domain 446 names. 448 3. Name resolution APIs and libraries SHOULD NOT recognize example 449 names as special and SHOULD NOT treat them differently. Name 450 resolution APIs SHOULD send queries for example names to their 451 configured caching DNS server(s). 453 4. Caching DNS servers SHOULD NOT recognize example names as special 454 and SHOULD resolve them normally. 456 5. Authoritative DNS servers SHOULD NOT recognize example names as 457 special. 459 6. DNS server operators SHOULD be aware that example names are 460 reserved for use in documentation. 462 7. DNS Registries/Registrars MUST NOT grant requests to register 463 example names in the normal way to any person or entity. All 464 example names are registered in perpetuity to IANA: 466 Domain Name: EXAMPLE.COM 467 Registrar: RESERVED-INTERNET ASSIGNED NUMBERS AUTHORITY 468 Whois Server: whois.iana.org 469 Referral URL: http://res-dom.iana.org 470 Name Server: A.IANA-SERVERS.NET 471 Name Server: B.IANA-SERVERS.NET 472 Status: clientDeleteProhibited 473 Status: clientTransferProhibited 474 Status: clientUpdateProhibited 475 Updated Date: 26-mar-2004 476 Creation Date: 14-aug-1995 477 Expiration Date: 13-aug-2011 479 IANA currently maintains a web server providing a web page 480 explaining the purpose of example domains. 482 7. Security Considerations 484 This document outlines the circumstances in which reserving a domain 485 name for special-use is appropriate, and the procedure for having 486 that Special-Use Domain Name recorded by IANA. Any document 487 requesting such a Special-Use Domain Name needs to contain an 488 appropriate "Security Considerations" section which describes any 489 security issues relevant to that special use. 491 8. IANA Considerations 493 IANA needs to create a new registry of Special-Use Domain Names, 494 initially populated with the private-address reverse-mapping domains 495 and the Reserved Top Level DNS Names outlined above in Section 6. 497 When IANA receives a request to record a new "Special-Use Domain 498 Name" it should verify, in consultation with the IESG, that the IETF 499 "Standards Action" or "IESG Approval" document [RFC5226] includes the 500 required "Domain Name Reservation Considerations" section stating how 501 the special meaning of this name affects the behaviour of hardware, 502 software, and humans in the seven categories. If IANA and the IESG 503 determine that special handling of this "Special-Use Domain Name" is 504 appropriate, IANA should record the Special-Use Domain Name, and a 505 reference to the specification that documents, it in the registry. 507 9. References 509 9.1. Normative References 511 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 512 Requirement Levels", BCP 14, RFC 2119, March 1997. 514 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 515 STD 13, RFC 1034, November 1987. 517 [RFC1035] Mockapetris, P., "Domain names - implementation and 518 specification", STD 13, RFC 1035, November 1987. 520 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 521 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 522 May 2008. 524 9.2. Informative References 526 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 527 RFC 1112, August 1989. 529 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 530 E. Lear, "Address Allocation for Private Internets", 531 BCP 5, RFC 1918, February 1996. 533 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 534 Names", BCP 32, RFC 2606, June 1999. 536 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 537 Configuration of IPv4 Link-Local Addresses", RFC 3927, 538 May 2005. 540 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 541 Address Autoconfiguration", RFC 4862, September 2007. 543 [RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", 544 BCP 153, RFC 5735, January 2010. 546 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 547 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 548 March 2010. 550 Authors' Addresses 552 Stuart Cheshire 553 Apple Inc. 554 1 Infinite Loop 555 Cupertino, California 95014 556 USA 558 Phone: +1 408 974 3207 559 Email: cheshire@apple.com 561 Marc Krochmal 562 Apple Inc. 563 1 Infinite Loop 564 Cupertino, California 95014 565 USA 567 Phone: +1 408 974 4368 568 Email: marc@apple.com