idnits 2.17.1 draft-ietf-malloc-ipv6-guide-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: ---------------------------------------------------------------------------- ** 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 (November 2000) is 8563 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) -- No information found for draft-ietf-ipngwg-mcast-arch - is the name correct? -- Possible downref: Normative reference to a draft: 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 (==), 4 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-00.txt 4 May 2000 5 Expires November 2000 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 With the current multicast address architecture and the proposed 33 multicast address architecture, a set of guidelines is needed for 34 multicast address allocation servers to use in assigning IPv6 35 multicast addresses. The purpose of these rules is to reduce the 36 possibility of address collision not only at layer 3, but also on 37 devices at layer 2. 39 1. Terminology 41 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 42 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 43 this document are to be interpreted as described in [RFC 2119]. 45 2. Introduction 47 Haberman 1 48 With the current multicast address architecture [RFC 2373] and the 49 multicast address architecture proposed in [NEW ARCH], a set of 50 guidelines is needed for multicast address allocation servers 51 [MALLOC] to use in assigning IPv6 multicast addresses. The purpose 52 of these rules is to reduce the possibility of address collision not 53 only at layer 3, but also on devices at layer 2. 55 These guidelines specify how the lowest 32 bits of the IPv6 56 multicast address are chosen and assigned. The guidelines specify 57 several mechanisms that can be used to determine the lowest 32 bits 58 of the multicast address. By having several mechanisms of varying 59 complexity, implementers and operators have the flexibility to 60 choose a mechanism that is appropriate for their application. 62 3. Assignment of New IPv6 Multicast Addresses 64 The current approach [RFC 2464] to map IPv6 multicast addresses into 65 IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 66 multicast address and uses it to create a MAC address. Group ID's 67 less than or equal to 32 bits long will generate unique MAC 68 addresses. 70 The goal of this document is to present several mechanisms 71 implementers and operators can use to select the group ID portion of 72 the address so that the possibility of collisions at the IP layer 73 and at the IEEE 802 layer is reduced. The following section 74 presents several different mechanism of varying complexity that can 75 be used to select an appropriate group ID. 77 4. Group ID Selection Guidelines 79 The following guidelines assume that the upper 96 bits of the IPv6 80 multicast address have been set up. For unicast network prefix- 81 based multicast addresses, the set up of those bits is done in the 82 following manner: 84 o An IPv6 multicast address prefix is initialized with the 85 appropriate flags and scope fields 86 o The IPv6 Network Prefix is inserted into the address and 87 the plen field is set. The Network Prefix is obtained 88 from the periodic Router Advertisements. 89 o The reserved field in the IPv6 multicast address is set 90 to zero 92 With the multicast address architecture in [RFC 2373], the set up of 93 those bits is done in the following manner: 95 o An IPv6 multicast address prefix is initialized with the 96 appropriate flags and scope fields 98 Haberman 2 99 o The reserved field in the IPv6 multicast address is set 100 to zero 102 The group ID portion of the address is set using either a pseudo- 103 random 32-bit number or a 32-bit number created using the guidelines 104 in [RFC 1750]. Possible approaches to creating a pseudo-random 105 number are to use an MD5 message-digest [RFC 1321] or portions of an 106 NTP [RFC 1305] timestamp. 108 The assignment of the group ID portion of the address SHOULD take 109 care to ensure that the generated multicast address does not share a 110 group ID with a permanently assigned IPv6 multicast address. The 111 permanently assigned multicast addresses are defined in [RFC 2375]. 113 Requests for more than one multicast address SHOULD be handled 114 atomically. One possible approach is to use the initial group ID, 115 created using the guidelines above, as the base address in a 116 contiguous block of multicast addresses. Another approach is to 117 create multiple group IDs and generate the appropriate multicast 118 addresses. 120 5. Multicast Address Lifetime 122 The lifetime of the assignment of unicast prefix-based multicast 123 addresses MUST be less than or equal to the Valid Lifetime field in 124 the Prefix Information option contained in the Neighbor Discovery 125 Router Advertisement message [RFC 2461]. 127 6. Security Considerations 129 This document does not have any direct impact on Internet 130 infrastructure security. 132 7. References 134 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 135 3", BCP 9, RFC 2026, October 1996. 137 [NEW ARCH] Haberman, B., Thaler, D., "IP Version 6 Multicast 138 Addressing Architecture", 139 draft-ietf-ipngwg-mcast-arch-00.txt, April 2000. 141 [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing 142 Architecture", RFC 2373, July 1998. 144 [MALLOC] Thaler, D., Handley, M., and Estrin, D., "The Internet 145 Multicast Address Allocation Architecture", 146 draft-ietf-malloc-arch-04.txt, January 2000. 148 Haberman 3 150 [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate 151 Requirement Levels", RFC 2119, BCP14, March 1999. 153 [RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 154 Networks", RFC 2464, December 1998. 156 [RFC 1305] Mills, D., "Network Time Protocol (Version 3) 157 Specification, Implementation", RFC 1305, March 1992. 159 [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 160 April 1992. 162 [RFC 1750] Eastlake, D., Crocker, S., Schiller, J., "Randomness 163 Recommendations for Security", RFC 1750, December 1994. 165 [RFC 2375] Hinden, R., Deering, S., "IPv6 Multicast Address 166 Assignments", RFC 2375, July 1998. 168 [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor 169 Discovery for IP Version 6 (IPv6)", RFC 2461, December 170 1998. 172 Haberman 4 173 Author's Address 175 Brian Haberman 176 Nortel Networks 177 4309 Emperor Blvd. 178 Suite 200 179 Durham, NC 27703 180 1-919-992-4439 181 Email : haberman@nortelnetworks.com 183 Haberman 5