idnits 2.17.1 draft-haberman-malloc-static-ipv6-alloc-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 2373 (ref. 'ADDARCH') (Obsoleted by RFC 3513) == Outdated reference: A later version (-07) exists of draft-ietf-malloc-madcap-04 == Outdated reference: A later version (-06) exists of draft-ietf-malloc-masc-01 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-masc (ref. 'MASC') Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Brian Haberman 2 April 1999 (IBM) 4 Static Allocation of Multicast Addresses in 5 the Internet Protocol Version 6 (IPv6) 7 9 Status of This Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents 17 as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months, and may be updated, replaced, or obsoleted by other documents 21 at any time. It is not appropriate to use Internet-Drafts as 22 reference material, or to cite them other than as a ``working draft'' 23 or ``work in progress.'' 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document defines a mechanism for statically allocating IPv6 34 multicast addresses by network prefixes. This approach will 35 integrate seamlessly with the Multicast Address Dynamic Client 36 Allocation Protocol (MADCAP). It will also remove the need to support 37 the Multicast Address Set Claim (MASC) Protocol for IPv6. 39 Contents 41 1. Keywords 1 43 2. Introduction 1 45 3. IPv6 Multicast Address Format 1 47 4. Static Allocation 1 48 4.1. Globally routable prefixes . . . . . . . . . . . . . . . 1 49 4.2. Site-local prefixes . . . . . . . . . . . . . . . . . . . 2 50 4.3. Link-local prefixes . . . . . . . . . . . . . . . . . . . 2 52 5. Security Considerations 2 54 6. References 3 56 7. Author's Address 3 58 8. Full Copyright Statement 3 60 1. Keywords 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 2. Introduction 68 One of the most common problems with IPv4 multicast is the limited 69 size of the multicast address range. This limited range size has led 70 to 71 several mechanisms for allocating IPv4 multicast addresses. With the 72 address architecture introduced for IPv6 [ADDARCH], the address range 73 constraint does 74 not hinder IPv6 multicast. Because of the increased address size, it 75 is feasible to allocate multicast addresses statically in IPv6. 77 This work describes the mechanism for the static allocation of IPv6 78 multicast addresses based on the IPv6 network prefix. It will work 79 seamlessly with the MADCAP [MADCAP] 80 protocol. Because this is a static allocation, it will eliminate the 81 need for running the MASC protocol [MASC]. 83 3. IPv6 Multicast Address Format 85 The IPv6 address architecture defines an IPv6 multicast address as 86 follows : 88 | 8 | 4 | 4 | 112 bits | 89 +--------+----+----+---------------------------------------------+ 90 |11111111|flgs|scop| group ID | 91 +--------+----+----+---------------------------------------------+ 93 The legal values for the flgs and scop field are defined in the IPv6 94 address architecture [ADDARCH]. 96 4. Static Allocation 98 4.1. Globally routable prefixes 100 The mechanism for allocating IPv6 multicast addresses will be to 101 imbed an IPv6 unciast network prefix 102 in the multicast address starting at bit 16. The resulting multicast 103 address will have the following format if 104 the network prefix was taken from an address format that must contain 105 an EUI-64 based interface identifier (Section 2.4 of [ADDARCH]). 107 | 8 | 4 | 4 | 64 bits | 48 bits | 108 +--------+----+----+---------------------------------------------+ 109 |11111111|flgs|scop| IPv6 unicast network prefix | group ID | 110 +--------+----+----+---------------------------------------------+ 112 This format will allow for 2^48 group IDs for each unique (scop, 113 prefix) pair. 115 4.2. Site-local prefixes 117 If a node attempting 118 to obtain an IPv6 multicast address does not have a globally routable 119 network prefix, it can use a site-local address prefix in the same 120 manner. In this case, the multicast address format will be : 122 | 8 | 4 | 4 | 10 bits |38 bits | 16 bits | 48 bits | 123 +--------+----+----+---------------------------------------------+ 124 |11111111|flgs|scop|1111111011 | 0 | subnet ID | group ID | 125 +--------+----+----+---------------------------------------------+ 127 With this format, the scop field of the address can be no greater 128 than site-local (5), defined in Section 2.7 of [ADDARCH]. 130 4.3. Link-local prefixes 132 If a node only 133 has a link-local address, section 2.5.8 of [ADDARCH], it can only use 134 a multicast address with a scop field no greater than link-local (2). 135 For this case, the multicast address format is as follows : 137 | 8 | 4 | 4 | 112 bits | 138 +--------+----+----+---------------------------------------------+ 139 |11111111|flgs|scop| group ID | 140 +--------+----+----+---------------------------------------------+ 142 5. Security Considerations 143 6. References 145 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 146 Requirement Levels", RFC 2119, BCP14, March 1997. 148 [ADDARCH] R. Hinden and S. Deering, "IP Version 6 Addressing 149 Architecture", RFC 2373, July 1998. 151 [MADCAP] B. Patel, M. Shah, and S. Hanna, "Multicast Address 152 Dynamic Client Allocation Protocol (MADCAP)", 153 draft-ietf-malloc-madcap-04.txt, February 1999. 155 [MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar, 156 P. Radoslavov, and D. Thaler, "The Multicast Address-Set 157 Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt, 158 August 1998. 160 7. Author's Address 162 Brian Haberman 163 IBM Corporation 164 800 Park Office Drive 165 Research Triangle Park, NC 27709 166 USA 167 +1-919-254-2673 168 haberman@raleigh.ibm.com 170 8. Full Copyright Statement 172 Copyright (C) The Internet Society (1999). All Rights Reserved. 174 This document and translations of it may be copied and furnished to 175 others, and derivative works that comment on or otherwise explain 176 it or assist in its implementation may be prepared, copied, published 177 and distributed, in whole or in part, without restriction of any 178 kind, provided that the above copyright notice and this paragraph are 179 included on all such copies and derivative works. 180 However, this document itself may not be modified in any way, such as 181 by removing the copyright notice or references to the Internet 182 Society or other Internet organizations, except as needed for the 183 purpose of developing Internet standards in which case the procedures 184 for copyrights defined in the Internet Standards process must 185 be followed, or as required to translate it into languages other than 186 English. 188 The limited permissions granted above are perpetual and will not be 189 revoked by the Internet Society or its successors or assigns. 191 This document and the information contained herein is provided on an 192 "AS IS" basis and THE INTERNET SOCIETY AND 193 THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS 194 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE 195 OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 196 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.