idnits 2.17.1 draft-ietf-ipngwg-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. ** There are 4 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (February 2001) is 8464 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 124, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 130, but no explicit reference was found in the text == Unused Reference: 'RFC 2464' is defined on line 137, but no explicit reference was found in the text == Unused Reference: 'RFC 2470' is defined on line 140, but no explicit reference was found in the text == Unused Reference: 'RFC 2375' is defined on line 144, but no explicit reference was found in the text == Unused Reference: 'RFC 2365' is defined on line 149, 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 3 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-ietf-ipngwg-uni-based-mcast-00.txt D. Thaler 4 August 2000 Microsoft 5 Expires February 2001 7 Unicast-Prefix-based IPv6 Multicast Addresses 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 RFC2026 [RFC 2026]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. Internet-Drafts are draft documents valid for a maximum of 18 six months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts as 20 reference material or to cite 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 an extension to the multicast addressing 31 architecture of the IP Version 6 protocol. The extension presented 32 in this document allows for unicast-prefix-based allocation of 33 multicast addresses. 35 1. Introduction 37 This document specifies an extension to the multicast portion of the 38 IPv6 addressing architecture [RFC 2373]. The current architecture 39 does not contain any built-in support for dynamic address 40 allocation. This proposal introduces encoded information in the 41 multicast address to allow for dynamic, network prefix-based 42 allocation of IPv6 multicast addresses, as well as allocation of 43 source-specific multicast addresses. 45 2. Multicast Address Format 47 Section 2.7.2 of RFC 2373 defines the following operational format 48 of IPv6 multicast addresses: 50 Haberman, Thaler 1 51 | 8 | 4 | 4 | 80 | 32 | 52 +--------+----+----+--------------------------------+------------+ 53 |11111111|flgs|scop| reserved must be zero | group ID | 54 +--------+----+----+--------------------------------+------------+ 56 This document introduces a new format that incorporates unicast 57 prefix information in the multicast address. The following 58 illustrates the new format: 60 | 8 | 4 | 4 | 8 | plen |72 - plen | 32 | 61 +--------+----+----+------+----------------+----------+----------+ 62 |11111111|flgs|scop| plen | network prefix | reserved | group ID | 63 +--------+----+----+------+----------------+----------+----------+ 65 +-+-+-+-+ 66 flgs is a set of 4 flags: |0|0|P|T| 67 +-+-+-+-+ 69 o P = 0 indicates a multicast address that is not assigned 70 based on the network prefix. 71 o P = 1 indicates a multicast address that is assigned 72 based on the network prefix. 73 o The setting of the T bit is defined in Section 2.7 of RFC 74 2373 76 plen indicates the length of the network prefix portion of the 77 address when P = 1. This field is required in order to determine 78 the number of bits to include as part of the unicast prefix. 80 network prefix identifies the network prefix of the unicast subnet 81 owning the multicast address. If P = 1, this field contains the 82 unicast network prefix defined in [RFC 2374] and assigned to the 83 domain owning the multicast address. 85 The reserved field MUST be zero. 87 While this limits the number of unicast prefix-based IPv6 multicast 88 groups to 2^32 per prefix, this is unlikely to be a limitation in 89 the future. If it becomes necessary to exceed this limit in the 90 future, multicast will still work but the processing will be 91 slightly slower. 93 With the network prefix-based architecture and the current unicast 94 address architecture [RFC 2374], the network prefix portion of the 95 multicast address will be at most 64 bits. This allows for the 96 group ID field to be at least 40 bits. 98 Haberman, Thaler 2 99 3. Source-Specific Multicast Addresses 101 The network prefix-based IPv6 multicast address format supports 102 Source-specific multicast addresses, as defined by [IANA]. This is 103 accomplished by: 105 o Setting P = 1 106 o Setting plen = 0 107 o Setting network prefix = 0 109 4. Security Considerations 111 Using unicast network-prefix based multicast addresses can sometimes 112 aid in identifying the allocation domain of a given multicast 113 address, although no guarantee is provided. 115 Using source-specific multicast addresses can sometimes aid in the 116 prevention of denial-of-service attacks by arbitrary sources, 117 although no guarantee is provided. 119 5. References 121 [RFC 2026] S. Bradner, "The Internet Standards Process -- 122 Revision 3", BCP 9, RFC 2026, October 1996. 124 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 125 (IPv6) Specification", RFC 2460, December 1998. 127 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 128 Architecture", RFC 2373, July 1998. 130 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 131 Requirement Levels", RFC 2119, BCP14, March 1999. 133 [RFC 2374] R. Hinden, M. O'Dell, and S. Deering, "An IPv6 134 Aggregatable Global Unicast Address Format", RFC 2374, 135 July 1998. 137 [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet 138 Networks", RFC 2464, December 1998. 140 [RFC 2470] M. Crawford, T. Narten, and S. Thomas, "Transmission of 141 IPv6 Packets over Token Ring Networks", RFC 2470, 142 December 1998. 144 [RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address 145 Assignments", RFC 2375, July 1998. 147 Haberman, Thaler 3 149 [RFC 2365] D. Meyer, "Administratively Scoped IP Multicast", 150 BCP 23, RFC 2365, July 1998. 152 [IANA] D. Cheriton, "Single-source IP Multicast Address Range", 153 http://www.isi.edu/in-notes/iana/assignments/single- 154 source-multicast, October 1998. 156 Haberman, Thaler 4 157 Author's Address 159 Brian Haberman 160 Nortel Networks 161 4309 Emperor Blvd. 162 Suite 200 163 Durham, NC 27703 164 1-919-992-4439 165 Email : haberman@nortelnetworks.com 167 Dave Thaler 168 Microsoft Corporation 169 One Microsoft Way 170 Redmond, WA 48105-6399 171 1-425-703-8835 172 Email: dthaler@microsoft.com 174 Haberman, Thaler 5