idnits 2.17.00 (12 Aug 2021) /tmp/idnits28359/draft-haberman-ipngwg-mcast-arch-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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first 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 == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 73 lines 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. ** There are 92 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC2460], [RFC2464], [RFC2470], [RFC2373], [RFC2374], [RFC2375]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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.) -- The document date (June 2000) is 8010 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 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2374 (Obsoleted by RFC 3587) ** Downref: Normative reference to an Informational RFC: RFC 2375 Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPNGWG Working Group B. Haberman 2 Internet Draft Nortel Networks 3 draft-haberman-ipngwg-mcast-arch-00.txt 4 December 1999 5 Expires June 2000 7 IP Version 6 Multicast Addressing Architecture 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026 [RFC 2026]. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet- Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This specification defines the multicast addressing architecture of the 31 IP Version 6 protocol [RFC 2460]. The updated multicast address 32 architecture presented in this document allows for prefix-based 33 allocation of multicast addresses. It is an update of section 2.7 of 34 the RFC 2373 [RFC 2373]. 36 1. 37 Terminology 39 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 40 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 41 document are to be interpreted as described in [RFC 2119]. 43 2. 44 Introduction 46 This document specifies an update to the IPv6 multicast addressing 47 architecture. The current architecture does not contain any built-in 48 support for dynamic address allocation. This proposal introduces 49 encoded information in the multicast address to allow for dynamic, 50 network prefix-based allocation of IPv6 multicast addresses. 52 3. 53 Multicast Address Format 55 Haberman 1 56 An IPv6 multicast address is an identifier for a group of nodes. A 57 node may belong to any number of multicast groups. Multicast addresses 58 have the following format: 60 | 8 | 4 | 4 | 8 | plen | 104 - plen | 61 +--------+----+----+--------+--------------------+--------------------+ 62 |11111111|flgs|scop| plen | network prefix | group ID | 63 +--------+ + 64 ---- ----+--------+--------------------+--------------------+ 66 11111111 at the start of the address identifies the address as being a 67 multicast address. 69 +-+-+-+-+ 70 flgs is a set of 4 flags: |0|0|P|T| 71 +-+-+-+-+ 73 o 74 The high-order 2 flags are reserved, and must be initialized to 75 0. 76 o 77 P = 0 indicates a multicast address that is not assigned based 78 on the network prefix. When P = 0, the plen field and the 79 network prefix portion of the address are a part of the group 80 ID. 81 o 82 P = 1 indicates a multicast address that is assigned based on 83 the network prefix. 84 o 85 T = 0 indicates a permanently assigned (_well-known_) multicast 86 address, assigned by the global Internet numbering authority. 87 o 88 T = 1 indicates a non-permanently-assigned (_transient_) 89 multicast address. 91 scop is a 4-bit multicast scope value used to limit the scope of the 92 multicast group. The values are: 94 0 reserved 95 1 node-local scope 96 2 link-local scope 97 3 (unassigned) 98 4 (unassigned) 99 5 site-local scope 100 6 (unassigned) 101 7 (unassigned) 102 8 organization-local scope 103 9 (unassigned) 104 A (unassigned) 105 B (unassigned) 106 C (unassigned) 107 D (unassigned) 108 E global scope 109 F reserved 111 plen indicates the length of the network prefix embedded in the address 112 when P = 1. When P = 0, this field is considered a part of the group 113 ID. 115 network prefix identifies the network prefix of the unicast subnet 116 owning the multicast address. If P = 0, this field is considered a 117 part of the group ID. If P = 1, this field contains the unicast 118 network prefix defined in [RFC 2374] and assigned to the domain owning 119 the multicast address. 121 Haberman 2 122 group ID identifies the multicast group, either permanent or transient, 123 within the given scope. 125 The _meaning_ of a permanently assigned multicast address is 126 independent of the scope value. For example, if the _NTP servers 127 group_ is assigned a permanent multicast address with a group ID of 101 128 (hex), then: 130 FF01::101 means all NTP servers on the same node as the sender. 132 FF02::101 means all NTP servers on the same link as the sender. 134 FF05::101 means all NTP servers in the same site as the sender. 136 FF0E::101 means all NTP servers in the Internet. 138 Non-permanently-assigned multicast addresses are meaningful only within 139 a given scope. For example, a group identified by the non-permanent, 140 site-local multicast address FF15::101 at one site bears no 141 relationship to a group using the same address at a different site, or 142 to a non-permanent group using the same group ID with a different 143 scope, nor to a permanent group with the same group ID. 145 Multicast addresses must not be used as source addresses in IPv6 146 packets or appear in any routing header. 148 4. 149 Pre-Defined Multicast Addresses 151 The following well-known multicast addresses are pre-defined: 153 Reserved Multicast Addresses: FF00:0:0:0:0:0:0:0 154 FF01:0:0:0:0:0:0:0 155 FF02:0:0:0:0:0:0:0 156 FF03:0:0:0:0:0:0:0 157 FF04:0:0:0:0:0:0:0 158 FF05:0:0:0:0:0:0:0 159 FF06:0:0:0:0:0:0:0 160 FF07:0:0:0:0:0:0:0 161 FF08:0:0:0:0:0:0:0 162 FF09:0:0:0:0:0:0:0 163 FF0A:0:0:0:0:0:0:0 164 FF0B:0:0:0:0:0:0:0 165 FF0C:0:0:0:0:0:0:0 166 FF0D:0:0:0:0:0:0:0 167 FF0E:0:0:0:0:0:0:0 168 FF0F:0:0:0:0:0:0:0 170 The above multicast addresses are reserved and shall never be assigned 171 to any multicast group. 173 All Nodes Addresses: FF01:0:0:0:0:0:0:1 174 FF02:0:0:0:0:0:0:1 176 The above multicast addresses identify the group of all IPv6 nodes, 177 within scope 1 (node-local) or 2 (link-local). 179 All Routers Addresses: FF01:0:0:0:0:0:0:2 180 FF02:0:0:0:0:0:0:2 182 Haberman 3 183 FF05:0:0:0:0:0:0:2 185 The above multicast addresses identify the group of all IPv6 routers, 186 within scope 1 (node-local), 2 (link-local), or 5 (site-local). 188 Solicited-Node Address: FF02:0:0:0:0:1:FFXX:XXXX 190 The above multicast address is computed as a function of a node's 191 unicast and anycast addresses. The solicited-node multicast address is 192 formed by taking the low-order 24 bits of the address (unicast or 193 anycast) and appending those bits to the prefix 194 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range 195 FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:01:FFFF:FFFF. 197 For example, the solicited node multicast address corresponding to the 198 IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C:6C. IPv6 199 addresses that differ only in the high-order bits, e.g. due to multiple 200 high-order prefixes associated with different aggregations, will map to 201 the same solicited-node address thereby reducing the number of 202 multicast addresses a node must join. 204 A node is required to compute and join the associated Solicited-Node 205 multicast addresses for every unicast and anycast address it is 206 assigned. 208 5. 209 Assignment of New IPv6 Multicast Addresses 211 The current approach [RFC 2464] to map IPv6 multicast addresses into 212 IEEE 802 MAC addresses takes that low order 32 bits of the IPv6 213 multicast address and uses it to create a MAC address. Note that Token 214 Ring networks are handled differently. This is defined in [RFC 2470]. 215 Group ID's less than or equal to 32 bits will generate unique MAC 216 addresses. 218 Due to this, new IPv6 multicast addresses that are not network prefix- 219 based should be assigned so that the group identifier is always in the 220 low order 32 bits as shown in the following: 222 | 8 | 4 | 4 | 80 bits | 32 bits | 223 +--------+----+----+------------------------------+-------------------+ 224 |11111111|flgs|scop| reserved must be zero | group ID | 225 +--------+----+----+------------------------------+-------------------+ 227 Any new IPv6 multicast addresses that are network prefix-based will 228 have the following format: 230 | 8 | 4 | 4 | 8 | plen bits | 72 _ plen | 32 bits | 231 +--------+----+----+--------+----------------+-----------+------------+ 232 |11111111|flgs|scop| plen | Network prefix | reserved | group ID | 233 +--------+----+----+--------+----------------+-----------+------------+ 235 While this limits the number of permanent IPv6 multicast groups to 2^32 236 this is unlikely to be a limitation in the future. If it becomes 237 necessary to exceed this limit in the future multicast will still work 238 but the processing will be slightly slower. 240 With the network prefix-based architecture and the current unicast 241 address architecture [RFC 2374], the network prefix portion of the 243 Haberman 4 244 multicast address will be at most 64 bits. This allows for the group 245 ID field to be 40 bits. 247 Additional IPv6 multicast addresses are defined and registered by the 248 IANA [RFC 2375]. 250 6. 251 Security Considerations 253 This document does not have any direct impact on Internet 254 infrastructure security. 256 7. 257 References 259 [RFC 2026] S. Bradner, _The Internet Standards Process -- Revision 3_, 260 BCP 9, RFC 2026, October 1996. 262 [RFC 2460] S. Deering and R. Hinden, _Internet Protocol, Version 6 263 (IPv6) Specification_, RFC 2460, December 1998. 265 [RFC 2373] R. Hinden and S. Deering, _IP Version 6 Addressing 266 Architecture_, RFC 2373, July 1998. 268 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 269 Requirement Levels", RFC 2119, BCP14, March 1999. 271 [RFC 2374] R. Hinden, M. O'Dell, and S. Deering, _An IPv6 272 Aggregatable Global Unicast Address Format_, RFC 2374, 273 July 1998. 275 [RFC 2464] M. Crawford, _Transmission of IPv6 Packets over Ethernet 276 Networks_, RFC 2464, December 1998. 278 [RFC 2470] M. Crawford, T. Narten, and S. Thomas, _Transmission of IPv6 279 Packets over Token Ring Networks_, RFC 2470, December 1998. 281 [RFC 2375] R. Hinden and S. Deering, _IPv6 Multicast Address 282 Assignments_, RFC 2375, July 1998. 284 Haberman 5 285 Author's Address 287 Brian Haberman 288 Nortel Networks 289 4309 Emperor Blvd. 290 Suite 200 291 Durham, NC 27703 292 1-919-992-4439 293 Email : haberman@nortelnetworks.com 295 Haberman 6