idnits 2.17.1 draft-ietf-malloc-ipv6-guide-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: ---------------------------------------------------------------------------- ** 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 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 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 (January 2001) is 8501 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'NEW ARCH' ** Obsolete normative reference: RFC 2373 (Obsoleted by RFC 3513) == Outdated reference: A later version (-05) exists of draft-ietf-malloc-arch-04 ** Downref: Normative reference to an Historic draft: draft-ietf-malloc-arch (ref. 'MALLOC') ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2375 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) Summary: 12 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MALLOC Working Group B. Haberman 2 Internet Draft Nortel Networks 3 draft-ietf-malloc-ipv6-guide-01.txt 4 July 2000 5 Expires January 2001 7 Dynamic Allocation Guidelines 8 for 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 21 as reference material or to cite them other than as "work in 22 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 This document specifies guidelines to be used when allocating IPv6 33 multicast addresses. The purpose of these guidelines is to reduce 34 the probability of IPv6 multicast address collision, not only at the 35 IPv6 layer, but also at the MAC layer of media that utilizes IEEE 36 802 addressing. 38 1. Terminology 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 42 this document are to be interpreted as described in [RFC 2119]. 44 2. Introduction 46 This document specifies guidelines to be used when allocating IPv6 47 multicast addresses. The purpose of these guidelines is to reduce 49 Haberman 1 50 the probability of IPv6 multicast address collision, not only at the 51 IPv6 layer, but also at the MAC layer of media that utilizes IEEE 52 802 addressing. 54 With the current IPv6 multicast address architecture [RFC 2373] and 55 the proposed extension to that architecture specified in [NEW ARCH], 56 a set of guidelines is needed for multicast address allocation 57 servers [MALLOC] to use in assigning IPv6 multicast addresses. 59 These guidelines specify how the lowest 32 bits of the IPv6 60 multicast address are chosen and assigned. The guidelines specify 61 several mechanisms that can be used to determine the lowest 32 bits 62 of the multicast address. By supporting several mechanisms, these 63 guidelines can accommodate the varying capabilities of multicast 64 address allocation servers. 66 3. Assignment of New IPv6 Multicast Addresses 68 The current approach [RFC 2464] to map IPv6 multicast addresses into 69 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 70 multicast address and uses it to create a MAC address. Group IDs 71 less than or equal to 32 bits long will generate unique MAC 72 addresses within a given multicast scope. 74 The goal of this document is to present several mechanisms 75 implementers and operators can use to select the group ID portion of 76 the address so that the possibility of collisions at the IP layer 77 and at the IEEE 802 layer is reduced. The following section 78 presents several different mechanisms of varying complexity that can 79 be used to select an appropriate group ID. 81 4. Group ID Selection Guidelines 83 The following guidelines assume that the upper 96 bits of the IPv6 84 multicast address have been initialized according to [RFC 2373] and 85 [NEW ARCH]. 87 The T flag of each dynamically allocated multicast address MUST be 88 set to '1'. Permanent addresses MUST NOT be allocated using the 89 multicast address allocation architecture. 91 The group ID portion of the address is set using either a pseudo- 92 random 32-bit number or a 32-bit number created using the guidelines 93 in [RFC 1750]. Possible approaches to creating a pseudo-random 94 number include using an MD5 message-digest [RFC 1321] or portions of 95 an NTP [RFC 1305] timestamp. 97 The high-order bit of the Group ID MUST be set to '1'. This will 98 distinguish the dynamically allocated addresses from the permanently 100 Haberman 2 101 assigned multicast addresses defined in [RFC 2375] at the MAC layer 102 on any media that utilizes IEEE 802 addressing. 104 A request for multiple multicast addresses SHOULD be handled 105 atomically. One possible approach is to use the initial group ID, 106 created using the guidelines above, as the base address in a 107 contiguous block of multicast addresses. Another approach is to 108 create multiple group IDs and generate the appropriate multicast 109 addresses. 111 5. Multicast Address Lifetime 113 The lifetime of the assignment of unicast prefix-based multicast 114 addresses MUST be less than or equal to the Valid Lifetime field in 115 the Prefix Information option contained in the Neighbor Discovery 116 Router Advertisement message [RFC 2461]. 118 6. Security Considerations 120 This document does not have any known impact on Internet 121 infrastructure security. 123 7. Acknowledgements 125 The author would like to thank Dave Thaler and Steve Deering for 126 their thorough review of this document. 128 8. References 130 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 131 3", BCP 9, RFC 2026, October 1996. 133 [NEW ARCH] Haberman, B., Thaler, D., "Unicast Prefix-based IPv6 134 Multicast Addresses", Work in Progress, July 2000. 136 [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing 137 Architecture", RFC 2373, July 1998. 139 [MALLOC] Thaler, D., Handley, M., and Estrin, D., "The Internet 140 Multicast Address Allocation Architecture", 141 draft-ietf-malloc-arch-04.txt, January 2000. 143 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 144 Requirement Levels", RFC 2119, BCP14, March 1999. 146 [RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 147 Networks", RFC 2464, December 1998. 149 Haberman 3 151 [RFC 1305] Mills, D., "Network Time Protocol (Version 3) 152 Specification, Implementation", RFC 1305, March 1992. 154 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 155 April 1992. 157 [RFC 1750] Eastlake, D., Crocker, S., Schiller, J., "Randomness 158 Recommendations for Security", RFC 1750, December 1994. 160 [RFC 2375] Hinden, R., Deering, S., "IPv6 Multicast Address 161 Assignments", RFC 2375, July 1998. 163 [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor 164 Discovery for IP Version 6 (IPv6)", RFC 2461, December 165 1998. 167 Haberman 4 168 Author's Address 170 Brian Haberman 171 Nortel Networks 172 4309 Emperor Blvd. 173 Suite 200 174 Durham, NC 27703 175 1-919-992-4439 176 Email : haberman@nortelnetworks.com 178 Haberman 5