idnits 2.17.1 draft-ietf-ipngwg-uni-based-mcast-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: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** 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 2 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 (July 2001) is 8321 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 136, but no explicit reference was found in the text == Unused Reference: 'RFC 2119' is defined on line 142, but no explicit reference was found in the text == Unused Reference: 'RFC 2464' is defined on line 151, but no explicit reference was found in the text == Unused Reference: 'RFC 2470' is defined on line 154, but no explicit reference was found in the text == Unused Reference: 'RFC 2375' is defined on line 158, but no explicit reference was found in the text == Unused Reference: 'RFC 2365' is defined on line 161, 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 (~~), 10 warnings (==), 3 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-ietf-ipngwg-uni-based-mcast-01.txt D. Thaler 5 January 2001 Microsoft 6 Expires July 2001 8 Unicast-Prefix-based IPv6 Multicast Addresses 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [RFC 2026]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. Internet-Drafts are draft documents valid for a maximum of 19 six months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts as 21 reference material or to cite 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 an extension to the multicast addressing 32 architecture of the IP Version 6 protocol. The extension presented 33 in this document allows for unicast-prefix-based allocation of 34 multicast addresses. 36 1. Introduction 38 This document specifies an extension to the multicast portion of the 39 IPv6 addressing architecture [RFC 2373]. The current architecture 40 does not contain any built-in support for dynamic address 41 allocation. This proposal introduces encoded information in the 42 multicast address to allow for dynamic, network prefix-based 43 allocation of IPv6 multicast addresses, as well as allocation of 44 source-specific multicast addresses. 46 2. Multicast Address Format 48 Section 2.7.2 of RFC 2373 defines the following operational format 49 of IPv6 multicast addresses: 51 Haberman, Thaler 1 52 | 8 | 4 | 4 | 80 | 32 | 53 +--------+----+----+--------------------------------+------------+ 54 |11111111|flgs|scop| reserved must be zero | group ID | 55 +--------+----+----+--------------------------------+------------+ 57 This document introduces a new format that incorporates unicast 58 prefix information in the multicast address. The following 59 illustrates the new format: 61 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 62 +--------+----+----+--------+--------+----------------+----------+ 63 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 64 +--------+----+----+--------+--------+----------------+----------+ 66 +-+-+-+-+ 67 flgs is a set of 4 flags: |0|0|P|T| 68 +-+-+-+-+ 70 o P = 0 indicates a multicast address that is not assigned 71 based on the network prefix. 72 o P = 1 indicates a multicast address that is assigned 73 based on the network prefix. 74 o The setting of the T bit is defined in Section 2.7 of RFC 75 2373 77 The reserved field MUST be zero. 79 plen indicates the actual length of the network prefix portion of 80 the address when P = 1. This field is required in order to 81 determine the number of bits to include as part of the unicast 82 prefix. 84 network prefix identifies the network prefix of the unicast subnet 85 owning the multicast address. If P = 1, this field contains the 86 unicast network prefix defined in [RFC 2374] and assigned to the 87 domain owning, or allocating, the multicast address. 89 With the network prefix-based architecture and the current unicast 90 address architecture [RFC 2374], the network prefix portion of the 91 multicast address will be at most 64 bits. 93 The scope of the unicast-prefix based multicast address must not 94 exceed the scope of the unicast prefix embedded in the multicast 95 address. 97 3. Source-Specific Multicast Addresses 99 Haberman, Thaler 2 100 The network prefix-based IPv6 multicast address format supports 101 Source-specific multicast addresses, as defined by [IANA]. This is 102 accomplished by: 104 o Setting P = 1 105 o Setting plen = 0 106 o Setting network prefix = 0 108 4. Security Considerations 110 Using unicast network-prefix based multicast addresses can sometimes 111 aid in identifying the allocation domain of a given multicast 112 address, although no guarantee is provided. 114 Using source-specific multicast addresses can sometimes aid in the 115 prevention of denial-of-service attacks by arbitrary sources, 116 although no guarantee is provided. 118 5. IANA Considerations 120 Well-known, fixed-scope and variable-scope multicast addresses with 121 the prefix FF2x (unicast-prefix based, permanent) may be created and 122 used as follows. 124 Group IDs are defined and registered by the IANA. Such well-known 125 group IDs may be used to create unicast-prefix based multicast 126 addresses by any domain or network by embedding their local unicast 127 prefix. Hence, given an IANA-assigned group ID, and a unicast 128 network prefix, an application could derive and join that network's 129 group used for the well-known purpose associated with the group ID. 131 6. References 133 [RFC 2026] S. Bradner, "The Internet Standards Process -- 134 Revision 3", BCP 9, RFC 2026, October 1996. 136 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 137 (IPv6) Specification", RFC 2460, December 1998. 139 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 140 Architecture", RFC 2373, July 1998. 142 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 143 Requirement Levels", RFC 2119, BCP14, March 1999. 145 [RFC 2374] R. Hinden, M. O�Dell, and S. Deering, "An IPv6 146 Aggregatable Global Unicast Address Format", RFC 2374, 148 Haberman, Thaler 3 149 July 1998. 151 [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet 152 Networks", RFC 2464, December 1998. 154 [RFC 2470] M. Crawford, T. Narten, and S. Thomas, "Transmission of 155 IPv6 Packets over Token Ring Networks", RFC 2470, 156 December 1998. 158 [RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address 159 Assignments", RFC 2375, July 1998. 161 [RFC 2365] D. Meyer, "Administratively Scoped IP Multicast", 162 BCP 23, RFC 2365, July 1998. 164 [IANA] D. Cheriton, "Single-source IP Multicast Address Range", 165 http://www.isi.edu/in-notes/iana/assignments/single- 166 source-multicast, October 1998. 168 Haberman, Thaler 4 169 Author�s Address 171 Brian Haberman 172 Nortel Networks 173 4309 Emperor Blvd. 174 Suite 200 175 Durham, NC 27703 176 1-919-992-4439 177 Email : haberman@nortelnetworks.com 179 Dave Thaler 180 Microsoft Corporation 181 One Microsoft Way 182 Redmond, WA 48105-6399 183 1-425-703-8835 184 Email: dthaler@microsoft.com 186 Haberman, Thaler 5