idnits 2.17.00 (12 Aug 2021) /tmp/idnits17533/draft-haberman-malloc-ipv6-prefix-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 4 longer pages, the longest (page 2) being 70 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 65 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** The abstract seems to contain references ([RFC1321], [RFC2119], [NEWARCH], [RFC2464], [RFC1305], [RFC1750]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (August 2000) is 7949 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) == Outdated reference: A later version (-01) exists of draft-haberman-ipngwg-mcast-arch-00 -- Possible downref: Normative reference to a draft: ref. 'NEW ARCH' ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1750 (Obsoleted by RFC 4086) Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MALLOC Working Group B. Haberman 3 Internet Draft Nortel Networks 4 draft-haberman-malloc-ipv6-prefix-00.txt 5 February 2000 6 Expires August 2000 8 Dynamic Allocation Guidelines for 9 Network Prefix-based IPv6 Multicast Addresses 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026 [RFC 2026]. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. Internet- 19 Drafts are draft documents valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet- Drafts as reference material or to cite 22 them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 With the multicast address architecture proposed in [NEW ARCH], a set 33 of guidelines is needed for multicast address allocation servers to use 34 in assigning IPv6 multicast addresses. The purpose of these rules is 35 to reduce the possibility of address collisions on layer 2 devices. 37 1. 38 Terminology 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in [RFC 2119]. 44 2. 45 Introduction 47 With the multicast address architecture proposed in [NEW ARCH], a set 48 of guidelines is needed for multicast address allocation servers to use 49 in assigning IPv6 multicast addresses. The purpose of these rules is 50 to reduce the possibility of address collisions on layer 2 devices. 52 These guidelines specify how the lowest 32 bits of the IPv6 multicast 53 address are chosen and assigned. The guidelines specify several 54 mechanisms that can be used to determine the lowest 32 bits of the 55 multicast address. By having several mechanisms of varying complexity, 56 implementers and operators have the flexibility to choose a mechanism 57 that is appropriate for their application. 59 Haberman 1 60 3. 61 Assignment of New IPv6 Multicast Addresses 63 The current approach [RFC 2464] to map IPv6 multicast addresses into 64 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 65 multicast address and uses it to create a MAC address. Group ID's less 66 than or equal to 32 bits will generate unique MAC addresses. 68 Due to this, new IPv6 multicast addresses that are network prefix-based 69 have the following format: 71 | 8 | 4 | 4 | 8 | plen bits | 72 _ plen | 32 bits | 72 +--------+----+ + 73 ---- --------+----------------+-----------+------------+ 74 |11111111|flgs|scop| plen | Network prefix | reserved | group ID | 75 +--------+----+----+--------+----------------+-----------+------------+ 77 The goal of this document is to present several mechanisms implementers 78 and operators can use to select the group ID portion of the address so 79 that the possibility of collisions at the IEEE 802 layer is reduced. 80 The following section presents several different mechanism of varying 81 complexity that can be used to select an appropriate group ID. 83 4. 84 Group ID Selection Guidelines 86 The following guidelines assume that the upper 96 bits of the IPv6 87 multicast address have been set up. The set up of those bits is done 88 in the following manner: 90 o An IPv6 multicast address prefix is initialized with the 91 appropriate flags and scope fields 92 o The IPv6 Network Prefix is inserted into the address and the 93 plen field is set. The Network Prefix is obtained from the 94 periodic Router Advertisements. 95 o The reserved field in the IPv6 multicast address is set to 96 zero 98 The group ID portion of the address is set using one of the following 99 mechanisms. 101 4.1 Network Time Protocol (NTP) Rule 103 The Network Time Protocol [RFC 1305] defines a 64-bit network 104 timestamp. The entity creating the IPv6 multicast address sets the 105 group ID portion of the IPv6 multicast address to the upper 32 bits of 106 the NTP timestamp. In order for a collision to occur at the IEEE 802 107 layer, two IPv6 multicast address allocations would have to occur at 108 the same second. 110 4.2 Network Time Protocol and IPv6 Unicast Address 112 This mechanism adds some complexity to the NTP approach defined above. 113 The entity creating the IPv6 multicast address once again obtains an 114 NTP timestamp. It then logically OR's the upper 32 bits of the NTP 115 timestamp with the lowest 32 bits of its IPv6 link-local address and 116 places that value in the group ID portion of the IPv6 multicast 118 Haberman 2 119 address. This approach addresses the scenario where two allocating 120 entities allocate addresses in the same second. 122 4.3 MD5 Digest 124 In this approach, the group ID is created using the MD5 Message-Digest 125 [RFC 1321]. The 64-bit IPv6 Network Prefix is appended with either the 126 64-bit NTP timestamp or a 64-bit value created using the guidelines in 127 [RFC 1750]. The corresponding 128-bit value is then fed into MD5. The 128 group ID portion of the IPv6 multicast address is set to the lowest 32 129 bits of the resulting MD5 digest value. 131 5. 132 Security Considerations 134 This document does not have any direct impact on Internet 135 infrastructure security. 137 6. 138 References 140 [RFC 2026] S. Bradner, _The Internet Standards Process -- Revision 3_, 141 BCP 9, RFC 2026, October 1996. 143 [NEW ARCH] B. Haberman, _IP Version 6 Multicast Addressing 144 Architecture_, draft-haberman-ipngwg-mcast-arch-00.txt, 145 December 1999. 147 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 148 Requirement Levels", RFC 2119, BCP14, March 1999. 150 [RFC 2464] M. Crawford, _Transmission of IPv6 Packets over Ethernet 151 Networks_, RFC 2464, December 1998. 153 [RFC 1305] D. Mills, _Network Time Protocol (Version 3) Specification, 154 Implementation_, RFC 1305, March 1992. 156 [RFC 1321] R. Rivest, _The MD5 Message-Digest Algorithm_, RFC 1321, 157 April 1992. 159 [RFC 1750] D. Eastlake, S. Crocker, J. Schiller, _Randomness 160 Recommendations for Security_, RFC 1750, December 1994. 162 Haberman 3 163 Author's Address 165 Brian Haberman 166 Nortel Networks 167 4309 Emperor Blvd. 168 Suite 200 169 Durham, NC 27703 170 1-919-992-4439 171 Email : haberman@nortelnetworks.com 173 Haberman 4