idnits 2.17.1 draft-ietf-ipngwg-uni-based-mcast-02.txt: -(48): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3 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 3 longer pages, the longest (page 2) being 59 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 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 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 (December 2001) is 8169 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 153, 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. 'SSM ARCH' Summary: 9 errors (**), 0 flaws (~~), 4 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-02.txt D. Thaler 4 June 2001 Microsoft 5 Expires December 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. By delegating multicast addresses at the same 34 time as unicast prefixes, network operators will be able to identify 35 their multicast addresses without needing to run an inter-domain 36 allocation protocol. 38 Table of Contents 40 Status of this Memo................................................1 41 Abstract...........................................................1 42 1. Introduction....................................................2 43 2. Terminology.....................................................2 44 3. Multicast Address Format........................................2 45 4. Source-Specific Multicast Addresses.............................3 46 5. Security Considerations.........................................3 47 6. References......................................................3 48 Author�s Address...................................................5 50 Haberman, Thaler 1 51 1. Introduction 53 This document specifies an extension to the multicast portion of the 54 IPv6 addressing architecture [RFC 2373]. The current architecture 55 does not contain any built-in support for dynamic address 56 allocation. This proposal introduces encoded information in the 57 multicast address to allow for dynamic, unicast prefix-based 58 allocation of IPv6 multicast addresses, as well as allocation of 59 source-specific multicast addresses. 61 2. Terminology 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 65 this document are to be interpreted as described in [RFC 2119]. 67 3. Multicast Address Format 69 Section 2.7.2 of RFC 2373 defines the following operational format 70 of IPv6 multicast addresses: 72 | 8 | 4 | 4 | 80 | 32 | 73 +--------+----+----+--------------------------------+------------+ 74 |11111111|flgs|scop| reserved must be zero | group ID | 75 +--------+----+----+--------------------------------+------------+ 77 This document introduces a new format that incorporates unicast 78 prefix information in the multicast address. The following 79 illustrates the new format: 81 | 8 | 4 | 4 | 8 | 8 | 64 | 32 | 82 +--------+----+----+--------+--------+----------------+----------+ 83 |11111111|flgs|scop|reserved| plen | network prefix | group ID | 84 +--------+----+----+--------+--------+----------------+----------+ 86 +-+-+-+-+ 87 flgs is a set of 4 flags: |0|0|P|T| 88 +-+-+-+-+ 90 o P = 0 indicates a multicast address that is not assigned 91 based on the network prefix. 92 o P = 1 indicates a multicast address that is assigned 93 based on the network prefix. 94 o If P = 1, T MUST be set to 1, otherwise the setting of 95 the T bit is defined in Section 2.7 of RFC 2373. 97 The reserved field MUST be zero. 99 Haberman, Thaler 2 100 plen indicates the actual number of bits in the network prefix field 101 that identify the subnet when P = 1. 103 network prefix identifies the network prefix of the unicast subnet 104 owning the multicast address. If P = 1, this field contains the 105 unicast network prefix defined in [RFC 2374] and assigned to the 106 domain owning, or allocating, the multicast address. 108 With the network prefix-based architecture and the current unicast 109 address architecture [RFC 2374], the network prefix portion of the 110 multicast address will be at most 64 bits. 112 The scope of the unicast-prefix based multicast address MUST NOT 113 exceed the scope of the unicast prefix embedded in the multicast 114 address. 116 The lifetime of a unicast prefix-based multicast addresses MUST be 117 less than or equal to the Valid Lifetime field in the Prefix 118 Information option, corresponding to the unicast prefix being used, 119 contained in the Neighbor Discovery Router Advertisement message 120 [RFC 2461]. 122 4. Source-Specific Multicast Addresses 124 The unicast prefix-based IPv6 multicast address format supports 125 Source-specific multicast addresses, as defined by [SSM ARCH]. To 126 accomplish is, a node MUST: 128 o Set P = 1. 129 o Set plen = 0. 130 o Set network prefix = 0. 132 These settings indicate that the multicast address is being used in 133 source-specific multicast transmission. The source address field in 134 the IPv6 header identifies the owner of the multicast address. 136 5. Security Considerations 138 Using unicast network-prefix based multicast addresses can sometimes 139 aid in identifying the allocation domain of a given multicast 140 address, although no guarantee is provided. 142 Using source-specific multicast addresses can sometimes aid in the 143 prevention of denial-of-service attacks by arbitrary sources, 144 although no guarantee is provided. 146 6. References 148 Haberman, Thaler 3 150 [RFC 2026] S. Bradner, "The Internet Standards Process -- 151 Revision 3", BCP 9, RFC 2026, October 1996. 153 [RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6 154 (IPv6) Specification", RFC 2460, December 1998. 156 [RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing 157 Architecture", RFC 2373, July 1998. 159 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 160 Requirement Levels", RFC 2119, BCP14, March 1999. 162 [RFC 2374] R. Hinden, M. O�Dell, and S. Deering, "An IPv6 163 Aggregatable Global Unicast Address Format", RFC 2374, 164 July 1998. 166 [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor 167 Discovery for IP Version 6 (IPv6)", RFC 2461, December 168 1998. 170 [SSM ARCH] H. Holbrook and B. Cain, "Source-Specific Multicast 171 for IP", Work In Progress, March 2001. 173 Haberman, Thaler 4 174 Author�s Address 176 Brian Haberman 177 Nortel Networks 178 4309 Emperor Blvd. 179 Suite 200 180 Durham, NC 27703 181 1-919-992-4439 182 haberman@nortelnetworks.com 184 Dave Thaler 185 Microsoft Corporation 186 One Microsoft Way 187 Redmond, WA 48105-6399 188 1-425-703-8835 189 dthaler@microsoft.com 191 Haberman, Thaler 5