idnits 2.17.1 draft-haberman-malloc-ipv6-prefix-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: ---------------------------------------------------------------------------- ** 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 3) being 68 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 57 instances of too long lines in the document, the longest one being 8 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 (September 2000) is 8625 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 1750' is defined on line 146, but no explicit reference was found in the text -- 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) Summary: 11 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-01.txt 5 March 2000 6 Expires September 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 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 multicast 35 addresses. The purpose of these rules is to reduce the possibility of 36 address collision not only at layer 3, but also on devices at layer 2. 38 1. 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. Introduction 46 With the current multicast address architecture [RFC 2373] and the 47 multicast address architecture proposed in [NEW ARCH], a set of 48 guidelines is needed for multicast address allocation servers [MALLOC] 49 to use in assigning IPv6 multicast addresses. The purpose of these 50 rules is to reduce the possibility of address collision not only at 51 layer 3, but also on devices at layer 2. 53 These guidelines specify how the lowest 32 bits of the IPv6 multicast 54 address are chosen and assigned. The guidelines specify several 55 mechanisms that can be used to determine the lowest 32 bits of the 57 Haberman 1 58 multicast address. By having several mechanisms of varying complexity, 59 implementers and operators have the flexibility to choose a mechanism 60 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 less 67 than or equal to 32 bits long will generate unique MAC addresses. 69 The goal of this document is to present several mechanisms implementers 70 and operators can use to select the group ID portion of the address so 71 that the possibility of collisions at the IP layer and at the IEEE 802 72 layer is reduced. The following section presents several different 73 mechanism of varying complexity that can be used to select an 74 appropriate group ID. 76 4. Group ID Selection Guidelines 78 The following guidelines assume that the upper 96 bits of the IPv6 79 multicast address have been set up. For unicast network prefix-based 80 multicast addresses, the set up of those bits is done in the following 81 manner: 83 o An IPv6 multicast address prefix is initialized with the 84 appropriate flags and scope fields 85 o The IPv6 Network Prefix is inserted into the address and the 86 plen field is set. The Network Prefix is obtained from the 87 periodic Router Advertisements. 88 o The reserved field in the IPv6 multicast address is set to 89 zero 91 With the multicast address architecture in [RFC 2373], the set up of 92 those bits is done in the following manner: 94 o An IPv6 multicast address prefix is initialized with the 95 appropriate flags and scope fields 96 o The reserved field in the IPv6 multicast address is set to 97 zero 99 The group ID portion of the address is set using either a pseudo-random 100 32-bit number or a 32-bit number created using the guidelines in [RFC 101 1750]. Possible approaches to creating a pseudo-random number are to 102 use an MD5 message-digest [RFC 1321] or portions of an NTP [RFC 1305] 103 timestamp. 105 Requests for more than one multicast address SHOULD be handled 106 atomically. One possible approach is to use the initial group ID, 107 created using the guidelines above, as the base address in a contiguous 108 block of multicast addresses. Another approach is to create multiple 109 group IDs and generate the appropriate multicast addresses. 111 5. Security Considerations 113 This document does not have any direct impact on Internet 114 infrastructure security. 116 Haberman 2 117 6. References 119 [RFC 2026] S. Bradner, "The Internet Standards Process -- Revision 3", 120 BCP 9, RFC 2026, October 1996. 122 [NEW ARCH] B. Haberman, "IP Version 6 Multicast Addressing 123 Architecture", draft haberman 124 - -ipngwg-mcast-arch-00.txt, 125 December 1999. 127 [RFC 2373] R. Hinden, S. Deering, "IP Version 6 Addressing 128 Architecture", RFC 2373, July 1998. 130 [MALLOC] D. Thaler, M. Handley, and D. Estrin, "The Internet 131 Multicast Address Allocation Architecture", 132 draft-ietf-malloc-arch-04.txt, January 2000. 134 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate 135 Requirement Levels", RFC 2119, BCP14, March 1999. 137 [RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet 138 Networks", RFC 2464, December 1998. 140 [RFC 1305] D. Mills, "Network Time Protocol (Version 3) Specification, 141 Implementation", RFC 1305, March 1992. 143 [RFC 1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321, 144 April 1992. 146 [RFC 1750] D. Eastlake, S. Crocker, J. Schiller, "Randomness 147 Recommendations for Security", RFC 1750, December 1994. 149 Haberman 3 150 Author's Address 152 Brian Haberman 153 Nortel Networks 154 4309 Emperor Blvd. 155 Suite 200 156 Durham, NC 27703 157 1-919-992-4439 158 Email : haberman@nortelnetworks.com 160 Haberman 4