idnits 2.17.1 draft-ietf-mboned-mcast-arpa-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 abstract seems to indicate that this document updates RFC5771, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2010) is 5065 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC1034' is defined on line 251, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC2908' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC3833' is defined on line 304, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-07) exists of draft-ietf-mboned-addrarch-06 -- Obsolete informational reference (is this intentional?): RFC 2672 (Obsoleted by RFC 6672) -- Obsolete informational reference (is this intentional?): RFC 2908 (Obsoleted by RFC 6308) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Koch 3 Internet-Draft DENIC eG 4 Intended status: BCP L. Vegoda 5 Expires: December 16, 2010 ICANN 6 June 14, 2010 8 Moving MCAST.NET into the ARPA infrastructure top level domain 9 draft-ietf-mboned-mcast-arpa-02 11 Abstract 13 This document proposes to migrate the MCAST.NET domain into the ARPA 14 top level domain that is dedicated to infrastructure support. It 15 also provides for a maintenance policy for the new MCAST.ARPA domain 16 and covers migration issues and caveats. This document updates RFC 17 5771 and forms part of BCP 51. 19 XXX reverse mapping 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 16, 2010. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3 69 3. The ARPA top level domain . . . . . . . . . . . . . . . 3 70 4. Current Use . . . . . . . . . . . . . . . . . . . . . . 3 71 5. Registration Policy . . . . . . . . . . . . . . . . . . 3 72 5.1. Names and Addresses eligible for Registration in 73 MCAST.ARPA . . . . . . . . . . . . . . . . . . . . . . 4 74 5.2. Subdomains of MCAST.ARPA . . . . . . . . . . . . . . . 4 75 5.3. Corresponding Reverse Mapping . . . . . . . . . . . . . 4 76 5.3.1. Reverse Mapping for 224/4 . . . . . . . . . . . . . . . 4 77 5.3.2. Reverse Mapping for FF0::/12 . . . . . . . . . . . . . 4 78 6. Migration Issues . . . . . . . . . . . . . . . . . . . 4 79 6.1. Migration Strategies . . . . . . . . . . . . . . . . . 5 80 6.1.1. Freeze . . . . . . . . . . . . . . . . . . . . . . . . 5 81 6.1.2. Phase Out . . . . . . . . . . . . . . . . . . . . . . . 5 82 6.1.3. Continue . . . . . . . . . . . . . . . . . . . . . . . 5 83 7. Security Considerations . . . . . . . . . . . . . . . . 5 84 8. IANA Considerations . . . . . . . . . . . . . . . . . . 6 85 9. Acknowledgements . . . . . . . . . . . . . . . . . . . 6 86 10. References . . . . . . . . . . . . . . . . . . . . . . 6 87 10.1. Normative References . . . . . . . . . . . . . . . . . 6 88 10.2. Informative References . . . . . . . . . . . . . . . . 7 89 Appendix A. Document Revision History . . . . . . . . . . . . . . . 7 90 A.1. Changes from -01 to -02 . . . . . . . . . . . . . . . . 7 91 A.2. Changes from -00 to -01 . . . . . . . . . . . . . . . . 7 92 A.3. Initial Document . . . . . . . . . . . . . . . . . . . 8 93 Authors' Addresses . . . . . . . . . . . . . . . . . . 8 95 1. Introduction 97 This document describes a maintenance policy and migration strategy 98 for the MCAST.NET (MCAST.ARPA) domain that contains names for a 99 subset of the multicast groups assigned by the IANA. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in BCP 14, [RFC2119]. 107 3. The ARPA top level domain 109 [RFC3172] designates the ARPA top level domain as "Address and 110 Routing Parameters Area" to be used for infrastructure applications. 112 The MCAST.NET second level domain fulfills the criteria set out in 113 section 2.1 of [RFC3172]. However, there is no standards track 114 document explicitly designating this domain to a multicast group name 115 to multicast group address mapping. 117 [RFC5771] defines the IPv4 multicast address assignment policy. 119 [RFC4291] defines the IPv6 multicast address assignment policy. 121 4. Current Use 123 Currently the zone MCAST.NET reflects the contents of parts the IANA 124 IPv4 multicast address registry. However, some names are missing 125 from the DNS zone and some names used differ from the description 126 that appears in the registry file. Entries in the IPv6 multicast 127 address registry are not reflected in the MCAST.NET zone. 129 With few exceptions, only multicast group addresses from 224.0.0/24 130 and 224.0.1/24 are listed in MCAST.NET. Addresses outside 224/8 do 131 not appear at all. 133 5. Registration Policy 135 Names within MCAST.ARPA will consist of one additional label and MUST 136 adhere to the hostname syntax requirements of [RFC1123]. These names 137 MUST own a single A RR, a single AAAA RR, or both. Addresses will be 138 in the IPv4 or IPv6 multicast address space. 140 5.1. Names and Addresses eligible for Registration in MCAST.ARPA 142 Only IANA multicast address registrations are eligible for being 143 listed in MCAST.ARPA. 145 For IPv4, only multicast groups from 224.0.0/24 (Local Network 146 Control Block) and 224.0.1/24 (Internetwork Control Block) will have 147 names assigned. 149 For IPv6, only multicast groups from FF01::/16 (Node-Local Scope 150 Multicast Addresses) and FF02::/16 (Link-Local Scope Multicast 151 Addresses) will have names assigned. 153 5.2. Subdomains of MCAST.ARPA 155 The namespace under MCAST.ARPA is considered flat, i.e., all direct 156 descendants of MCAST.ARPA are leaves in the DNS tree. Future 157 extensions might want to define subdomains that serve special 158 purposes. Any such designation needs IETF consensus [RFC5226]. 160 5.3. Corresponding Reverse Mapping 162 The DNS Reverse Mapping for those multicast groups that appear as 163 addresses in MCAST.ARPA MUST be kept consistent with the forward 164 namespace. 166 5.3.1. Reverse Mapping for 224/4 168 A single DNS PTR record will be entered at the corresponding owner 169 within the 224.IN-ADDR.ARPA domain that points to the multicast group 170 name within MCAST.ARPA. 172 The zones 225.IN-ADDR.ARPA through 239.IN-ADDR.ARPA will be delegated 173 but MUST remain empty (except necessary infrastructure RRs). The one 174 exception is 233.IN-ADDR.ARPA. A mechanism for the delegation of 175 reverse mapping for GLOP space [RFC3180] should be designed and 176 implemented. 178 5.3.2. Reverse Mapping for FF0::/12 180 [How to deal with IPv6 multicast reverse mapping is TBD.] 182 6. Migration Issues 184 The current content of the MCAST.NET zone MUST be brought in line 185 with the multicast address registry. 187 Since legacy systems may use MCAST.NET for quite some time, there 188 needs to be a mapping/forwarding solution to answer those queries in 189 a useful manner without discouraging migration. 191 RFCs mentioning MCAST.NET are [RFC3261] and [RFC3678]. 193 An updated multicast address architecture appears in 194 [I-D.ietf-mboned-addrarch]. 196 6.1. Migration Strategies 198 After the move, several options are available for the future handling 199 of MCAST.NET. 201 [[The working group needs to choose one of the options.]] 203 6.1.1. Freeze 205 The current MCAST.NET zone could be frozen, so that no additions, 206 deletions or changes to the content (apart from those necessary for 207 maintenance, e.g. SOA and NS RRs) would be performed. New 208 registrations would only be available in MCAST.ARPA, so this could be 209 an incentive for querying clients to alter their behavior as well. 211 6.1.2. Phase Out 213 MCAST.NET would only see deletions. Even after the last record will 214 have been deleted, the domain should be kept registered by the IANA 215 to prevent redelegation ... 217 6.1.3. Continue 219 MCAST.NET could be further operated in parallel, either by 220 operational habit or per DNAME RR, as described in [RFC2672]. 222 7. Security Considerations 224 The usual Security Considerations for the DNS [RFC3833]apply. 226 The MCAST.ARPA., MCAST.NET., and the Reverse mapping zones mentioned 227 in this document SHALL be DNSSEC signed by the IANA under direction 228 from the IAB. 230 There is no Security Problem associated with the migration itself. 231 XXX keeping MCAST.NET. 233 {This section needs more work.} 235 8. IANA Considerations 237 This document amends [RFC5771] to add a mandatory entry in the 238 MCAST.ARPA domain and a corresponding reverse mapping entry. The 239 officially registered multicast group name is made subject to DNS 240 hostname syntax rules. 242 9. Acknowledgements 244 The authors would like to thank David Conrad and Joe Abley for their 245 input. 247 10. References 249 10.1. Normative References 251 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 252 STD 13, RFC 1034, November 1987. 254 [RFC1035] Mockapetris, P., "Domain names - implementation and 255 specification", STD 13, RFC 1035, November 1987. 257 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 258 and Support", STD 3, RFC 1123, October 1989. 260 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 261 Requirement Levels", BCP 14, RFC 2119, March 1997. 263 [RFC3172] Huston, G., "Management Guidelines & Operational 264 Requirements for the Address and Routing Parameter Area 265 Domain ("arpa")", BCP 52, RFC 3172, September 2001. 267 [RFC3180] Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", 268 BCP 53, RFC 3180, September 2001. 270 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 271 Architecture", RFC 4291, February 2006. 273 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 274 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 275 May 2008. 277 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 278 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 279 March 2010. 281 10.2. Informative References 283 [I-D.ietf-mboned-addrarch] 284 Savola, P., "Overview of the Internet Multicast Addressing 285 Architecture", draft-ietf-mboned-addrarch-06 (work in 286 progress), August 2009. 288 [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", 289 RFC 2672, August 1999. 291 [RFC2908] Thaler, D., Handley, M., and D. Estrin, "The Internet 292 Multicast Address Allocation Architecture", RFC 2908, 293 September 2000. 295 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 296 A., Peterson, J., Sparks, R., Handley, M., and E. 297 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 298 June 2002. 300 [RFC3678] Thaler, D., Fenner, B., and B. Quinn, "Socket Interface 301 Extensions for Multicast Source Filters", RFC 3678, 302 January 2004. 304 [RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain 305 Name System (DNS)", RFC 3833, August 2004. 307 Appendix A. Document Revision History 309 This section is to be removed should the draft be published. 311 A.1. Changes from -01 to -02 313 Added text about v6 multicast. 315 Added text about GLOP space 317 Added terminology section and RFC 2119 language 319 A.2. Changes from -00 to -01 321 Added text about DNS reverse mapping. Eligibility for an MCAST.ARPA 322 name now restricted to 224.0.0/24 and 224.0.1/24. Stronger 323 requirement for MCAST.ARPA subdomains. 325 A.3. Initial Document 327 First draft, taking over with only little changes from 328 draft-koch-mboned-mcast-arpa-00.txt 330 Authors' Addresses 332 Peter Koch 333 DENIC eG 334 Kaiserstrasse 75-77 335 Frankfurt 60329 336 DE 338 Phone: +49 69 27235 0 339 Email: pk@DENIC.DE 341 Leo Vegoda 342 Internet Corporation for Assigned Names and Numbers 343 4676 Admiralty Way, Suite 330 344 Marina del Rey 90292 345 United States of America 347 Phone: +1-310-823-9358 348 Email: leo.vegoda@icann.org 349 URI: http://www.iana.org/