idnits 2.17.00 (12 Aug 2021) /tmp/idnits17522/draft-thaler-ipv4-uni-based-mcast-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (12 November 2001) is 7488 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 2770 (ref. 'GLOP') (Obsoleted by RFC 3180) == Outdated reference: draft-ietf-ipngwg-uni-based-mcast has been published as RFC 3306 -- Possible downref: Normative reference to a draft: ref. 'ZMAAP' Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Dave Thaler 2 Internet-Draft Microsoft 3 Expires: May 2002 12 November 2001 5 Unicast-Prefix-based IPv4 Multicast Addresses 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet- 21 Drafts as reference material or to cite them other than as "work 22 in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Copyright Notice 32 Copyright (C) The Internet Society (2001). All Rights Reserved. 34 Abstract 35 Draft Uni-Prefix-based IPv4 Multicast November 2001 37 This specification defines an extension to the multicast 38 addressing architecture of the IP Version 4 protocol. The 39 extension presented in this document allows for unicast-prefix- 40 based allocation of multicast addresses. By delegating multicast 41 addresses at the same time as unicast prefixes, network operators 42 will be able to identify their multicast addresses without needing 43 to run an inter-domain allocation protocol. 45 1. Introduction 47 RFC 2770 [GLOP] defined an experimental allocation mechanism in 48 233/8 whereby an Autonomous System (AS) number is embedded in the 49 middle 16 bits of an IPv4 multicast address, resulting in 256 50 multicast addresses per AS. Advantages of this mechanism include 51 the ability to get multicast address space without an inter-domain 52 multicast address allocation protocol, and the ease of determining 53 the AS of the owner of an address for debugging and auditing 54 purposes. 56 Some disadvantages of GLOP include: 58 o only 256 addresses are automatically available per AS, and 59 obtaining any more requires administrative effort. 61 o when an AS covers multiple sites or organizations, 62 administration of the multicast address space within an AS 63 must be handled by other mechanisms, such as manual 64 administrative effort or MADCAP [MADCAP]. 66 o during debugging, identifying the AS does not immediately 67 identify the owning organization, when an AS covers multiple 68 organizations. 70 More recently, a mechanism [V6UPBM] has been developed for IPv6 71 which provides a multicast range to every IPv6 subnet, which is at 72 a much finer granularity than an AS. As a result, the latter two 73 disadvantages above are avoided (and the first disadvantage does 74 not apply to IPv6 due to the extended size of the address space). 76 Two significant advantages of providing multicast space to every 77 subnet (rather than just to an entire AS) are that: 79 o multicast address allocation within the range need only be 80 coordinated within the subnet (e.g., via ZMAAP [ZMAAP]), and 82 Draft Uni-Prefix-based IPv4 Multicast November 2001 84 hence can be done with zero configuration. 86 o bidirectional shared tree routing protocols may easily locate 87 the direction to the root by doing a route lookup on a 88 unicast address derived from the multicast group address. 90 This draft specifies a mechanism similar to [V6UPBM], whereby a 91 range of IPv4 multicast address space is provided to most IPv4 92 subnets. A resulting advantage over GLOP is that the mechanisms 93 in IPv4 and IPv6 become more similar. 95 2. Address Space 97 IANA should assign a /8 for this mechanism (e.g., the 225/8 which 98 was previously leased to MASC). The remaining 24 bits will be 99 used as follows: 101 Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length | 102 +-----+-----------------------+----------------------------+ 103 Value: | 225 | Unicast Prefix | Group ID | 104 +-----+-----------------------+----------------------------+ 106 For subnets with a /24 or shorter prefix, the unicast prefix of 107 the subnet is appended to the common /8. Any remaining bits may 108 be locally assigned by hosts within the link (e.g., using manual 109 configuration, or ZMAAP). Individual subnets with a prefix length 110 longer than 24 do not receive any multicast address space from 111 this mechanism; in such cases, MADCAP may be used. 113 Compared to GLOP, an AS will receive more address space via this 114 mechanism if it has more than a /16 for unicast space. An AS will 115 receive less address space than it does from GLOP if it has less 116 than a /16. 118 3. Security Considerations 120 Since dynamic assignment does not cross domain boundaries, the 121 same well known intra-domain security techniques can be applied as 122 with GLOP. Furthermore, the approach described here may have the 123 effect of reduced exposure to denial of space attacks based on 124 dynamic allocation, since the area of dynamic allocation is 125 reduced from an entire AS to only within individual subnets. 127 Draft Uni-Prefix-based IPv4 Multicast November 2001 129 4. Author's Address 131 Dave Thaler 132 Microsoft Corporation 133 One Microsoft Way 134 Redmond, WA 98052-6399 135 Phone: +1 425 703 8835 136 EMail: dthaler@microsoft.com 138 5. References 140 [GLOP] 141 Meyer, D., and P. Lothberg, "GLOP Addressing in 233/8", RFC 142 2770, February 2000. 144 [MADCAP] 145 Hanna, S, Patel, B., and M. Shah, "Multicast Address Dynamic 146 Client Allocation Protocol (MADCAP)", RFC 2730, December 147 1999. 149 [V6UPBM] 150 Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 151 Multicast Addresses", draft-ietf-ipngwg-uni-based- 152 mcast-03.txt, October 2001. 154 [ZMAAP] 155 Catrina, O., Thaler, D., Aboba, B., and E. Guttman, "Zeroconf 156 Multicast Address Allocation Protocol (ZMAAP)", draft-ietf- 157 zeroconf-zmaap-02.txt, October 2001. 159 6. Full Copyright Statement 161 Copyright (C) The Internet Society (2001). All Rights Reserved. 163 This document and translations of it may be copied and furnished 164 to others, and derivative works that comment on or otherwise 165 explain it or assist in its implmentation may be prepared, copied, 166 published and distributed, in whole or in part, without 167 restriction of any kind, provided that the above copyright notice 168 and this paragraph are included on all such copies and derivative 169 works. However, this document itself may not be modified in any 170 way, such as by removing the copyright notice or references to the 171 Internet Society or other Internet organizations, except as needed 172 Draft Uni-Prefix-based IPv4 Multicast November 2001 174 for the purpose of developing Internet standards in which case the 175 procedures for copyrights defined in the Internet Standards 176 process must be followed, or as required to translate it into 177 languages other than English. 179 The limited permissions granted above are perpetual and will not 180 be revoked by the Internet Society or its successors or assigns. 182 This document and the information contained herein is provided on 183 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 184 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 185 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 186 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 187 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.