idnits 2.17.1 draft-haberman-ipngwg-mcast-arch-01.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 7 longer pages, the longest (page 2) being 67 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 111 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (September 2000) is 8621 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) == Unused Reference: 'RFC 2460' is defined on line 265, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 271, but no explicit reference was found in the text ** 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: 10 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPNGWG Working Group B. Haberman 3 Internet Draft Nortel Networks 4 draft-haberman-ipngwg-mcast-arch-01.txt D. Thaler 5 March 2000 Microsoft 6 Expires September 2000 8 IP Version 6 Multicast Addressing Architecture 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026 [RFC 2026]. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. Internet- 18 Drafts are draft documents valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet- Drafts as reference material or to cite 21 them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This specification defines the multicast addressing architecture of the 32 IP Version 6 protocol. The updated multicast address architecture 33 presented in this document allows for unicast prefix-based allocation 34 of multicast addresses. It is an update of section 2.7 of the RFC 35 2373. 37 1. Introduction 39 This document specifies an update to the IPv6 multicast addressing 40 architecture [RFC 2373]. The current architecture does not contain any 41 built-in support for dynamic address allocation. This proposal 42 introduces encoded information in the multicast address to allow for 43 dynamic, network prefix-based allocation of IPv6 multicast addresses, 44 as well as allocation of single-source multicast addresses. 46 2. Multicast Address Format 48 An IPv6 multicast address is an identifier for a group of nodes. A 49 node may belong to any number of multicast groups. Multicast addresses 50 have the following generic format: 52 | 8 | 4 | 4 | 80 | 32 | 53 +--------+----+----+-----------------------------------+------------+ 54 |11111111|flgs|scop| (see below) | group ID | 55 +--------+----+----+-----------------------------------+------------+ 57 Haberman, Thaler 1 58 11111111 at the start of the address identifies the address as being a 59 multicast address. 61 +-+-+-+-+ 62 flgs is a set of 4 flags: |0|S|P|T| 63 +-+-+-+-+ 65 o The high-order flag is reserved, and must be initialized to 66 0. 67 o P = 0 indicates a multicast address that is not assigned 68 based on the network prefix. 69 o P = 1 indicates a multicast address that is assigned based 70 on the network prefix. 71 o T = 0 indicates a permanently assigned ("well-known") 72 multicast address, assigned by the global Internet numbering 73 authority. 74 o T = 1 indicates a non-permanently-assigned ("transient") 75 multicast address. 76 o S = 0 indicates a multicast address that is not a single- 77 source group address. 78 o S = 1 indicates a multicast address that is a single-source 79 group address. 81 scop is a 4-bit multicast scope value used to limit the scope of the 82 multicast group. The values are: 84 0 reserved 85 1 node-local scope 86 2 link-local scope 87 3 local scope 88 4 (unassigned) 89 5 site-local scope 90 6 allocation scope 91 7 (unassigned) 92 8 organization-local scope 93 9 (unassigned) 94 A (unassigned) 95 B (unassigned) 96 C (unassigned) 97 D (unassigned) 98 E global scope 99 F reserved 101 The format of the next 80 bits is dependent on the value of the flags, 102 and is discussed in Section 4 below. 104 group ID identifies the multicast group, either permanent or transient, 105 within the given scope. 107 The "meaning" of a permanently assigned multicast address is 108 independent of the scope value. For example, if the "NTP servers 109 group" is assigned a permanent multicast address with a group ID of 101 110 (hex), then: 112 FF01::101 means all NTP servers on the same node as the sender. 114 FF02::101 means all NTP servers on the same link as the sender. 116 FF05::101 means all NTP servers in the same site as the sender. 118 Haberman, Thaler 2 119 FF0E::101 means all NTP servers in the Internet. 121 Non-permanently-assigned multicast addresses are meaningful only within 122 a given scope. For example, a group identified by the non-permanent, 123 site-local multicast address FF15::101 at one site bears no 124 relationship to a group using the same address at a different site, or 125 to a non-permanent group using the same group ID with a different 126 scope, nor to a permanent group with the same group ID. 128 Multicast addresses must not be used as source addresses in IPv6 129 packets or appear in any routing header. 131 3. Pre-Defined Multicast Addresses 133 Since the meaning of a permanently assigned multicast address is 134 independent of the scope value, such addresses are valid over all scope 135 ranges. This is shown by an "x" in the scope field of the address that 136 means any legal scope value. 138 Note that multicast addresses that differ only in scope represent 139 different groups. Nodes must join each group individually. 141 The following well-known multicast addresses are pre-defined: 143 Reserved Multicast Addresses: FF0x:0:0:0:0:0:0:0 145 The above multicast addresses are reserved and shall never be assigned 146 to any multicast group. 148 All Nodes Addresses: FF0x:0:0:0:0:0:0:1 150 The above multicast addresses identify the group of all IPv6 nodes 151 within a given scope. The All-Nodes-Address for scopes larger than 152 scope 2 (link-local) SHOULD NOT be used or joined by nodes. 154 All Routers Addresses: FF0x:0:0:0:0:0:0:2 156 The above multicast addresses identify the group of all IPv6 routers 157 within a given scope. The All-Routers-Address for scopes other than 158 scope 1 (node-local), 2 (link-local), and 5 (site-local) SHOULD NOT be 159 used or joined by routers. 161 Solicited-Node Address: FF0x:0:0:0:0:1:FFXX:XXXX 163 The above multicast address is computed as a function of a node's 164 unicast and anycast addresses, and SHOULD NOT be used or joined for any 165 scope value other than scope 2 (link-local). The solicited-node 166 multicast address is formed by taking the low-order 24 bits of the 167 address (unicast or anycast) and appending those bits to the prefix 168 FF02:0:0:0:0:1:FF00::/104 resulting in a multicast address in the range 169 FF02:0:0:0:0:1:FF00:0000 to FF02:0:0:0:01:FFFF:FFFF. 171 For example, the solicited node multicast address corresponding to the 172 IPv6 address 4037::01:800:200E:8C6C is FF02::1:FF0E:8C6C. IPv6 173 addresses that differ only in the high-order bits, e.g. due to multiple 174 high-order prefixes associated with different aggregations, will map to 175 the same solicited-node address thereby reducing the number of 176 multicast addresses a node must join. 178 Haberman, Thaler 3 179 A node is required to compute and join the associated Solicited-Node 180 multicast addresses for every unicast and anycast address it is 181 assigned. 183 4. Assignment of New IPv6 Multicast Addresses 185 The current approach [RFC 2464] to map IPv6 multicast addresses into 186 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 187 multicast address and uses it to create a MAC address. Note that Token 188 Ring networks are handled differently. Token Ring support of IPv6 189 multicast is defined in [RFC 2470]. Group ID's less than or equal to 190 32 bits long will generate unique MAC addresses. 192 Due to this, the existing IPv6 multicast address architecture suggests 193 that the group identifier always be in the low order 32 bits as shown 194 in the following: 196 | 8 | 4 | 4 | 80 bits | 32 bits | 197 +--------+----+----+----------------------------+-------------------+ 198 |11111111|flgs|scop| reserved must be zero | group ID | 199 +--------+----+----+----------------------------+-------------------+ 201 This document updates the above by specifying a different address 202 format when P = 1. Any new IPv6 multicast addresses that are network 203 prefix-based will have the following format: 205 | 8 | 4 | 4 | 8 | plen |72 - plen | 32 | 206 +--------+----+----+-------+----------------+----------+------------+ 207 |11111111|flgs|scop| plen | network prefix | reserved | group ID | 208 +--------+----+----+-------+----------------+----------+------------+ 210 plen indicates the length of the network prefix portion of the address 211 when P = 1. This field is required in order to determine the number of 212 bits to include as part of the unicast prefix. 214 network prefix identifies the network prefix of the unicast subnet 215 owning the multicast address. If P = 1, this field contains the 216 unicast network prefix defined in [RFC 2374] and assigned to the domain 217 owning the multicast address. 219 The reserved field must be zero. 221 While this limits the number of unicast prefix-based IPv6 multicast 222 groups to 2^32 per prefix, this is unlikely to be a limitation in the 223 future. If it becomes necessary to exceed this limit in the future, 224 multicast will still work but the processing will be slightly slower. 226 With the network prefix-based architecture and the current unicast 227 address architecture [RFC 2374], the network prefix portion of the 228 multicast address will be at most 64 bits. This allows for the group 229 ID field to be at least 40 bits. 231 Additional IPv6 multicast addresses are defined and registered by the 232 IANA [RFC 2375]. 234 Haberman, Thaler 4 235 5. Open Issues 237 5.1 IPv4-compatible Multicast Addresses 239 Is ::224.1.2.24 considered a legal IPv6 multicast address? Is 240 ::FFFF:224.1.2.24 considered a legal IPv6 multicast address? 242 5.2 Scope-relative Offsets 244 Scope-relative offsets as described in RFC 2365 [RFC 2365] are defined 245 with language implying the offset is the same between IPv6 and IPv4. 246 IANA has assigned them from separate number spaces. Should these 247 offsets be the same for IPv4 and IPv6 so that every protocol that wants 248 a scope-relative offset only has to get one offset and not two? 250 6. Security Considerations 252 Using unicast network-prefix based multicast addresses can sometimes 253 aid in identifying the allocation domain of a given multicast address, 254 although no guarantee is provided. 256 Using single-source multicast addresses can sometimes aid in the 257 prevention of denial-of-service attacks by arbitrary sources, although 258 no guarantee is provided. 260 7. References 262 [RFC 2026] S. Bradner, "The Internet Standards Process -- Revision 3", 263 BCP 9, RFC 2026, October 1996. 265 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 266 (IPv6) Specification", RFC 2460, December 1998. 268 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 269 Architecture", RFC 2373, July 1998. 271 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 272 Requirement Levels", RFC 2119, BCP14, March 1999. 274 [RFC 2374] R. Hinden, M. O'Dell, and S. Deering, "An IPv6 275 Aggregatable Global Unicast Address Format", RFC 2374, 276 July 1998. 278 [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet 279 Networks", RFC 2464, December 1998. 281 [RFC 2470] M. Crawford, T. Narten, and S. Thomas, "Transmission of IPv6 282 Packets over Token Ring Networks", RFC 2470, December 1998. 284 [RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address 285 Assignments", RFC 2375, July 1998. 287 [RFC 2365] D. Meyer, "Administratively Scoped IP Multicast", 288 BCP 23, RFC 2365, July 1998. 290 Haberman, Thaler 5 291 Haberman, Thaler 6 292 Author's Address 294 Brian Haberman 295 Nortel Networks 296 4309 Emperor Blvd. 297 Suite 200 298 Durham, NC 27703 299 1-919-992-4439 300 Email : haberman@nortelnetworks.com 302 Dave Thaler 303 Microsoft Corporation 304 One Microsoft Way 305 Redmond, WA 48105-6399 306 1-425-703-8835 307 Email: dthaler@microsoft.com 309 Haberman, Thaler 7