From owner-malloc@catarina.usc.edu Tue Feb 1 12:06:27 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25424 for ; Tue, 1 Feb 2000 12:06:25 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id IAA23573 for malloc-list; Tue, 1 Feb 2000 08:38:46 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id IAA23569 for ; Tue, 1 Feb 2000 08:38:42 -0800 (PST) Received: from eastmail2.East.Sun.COM ([129.148.1.241]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA28767; Tue, 1 Feb 2000 08:38:29 -0800 (PST) Received: from sunlabs.East.Sun.COM (sunlabs.East.Sun.COM [129.148.75.250]) by eastmail2.East.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6) with ESMTP id LAA24269; Tue, 1 Feb 2000 11:38:25 -0500 (EST) Received: from sun.com (dhcp75-155 [129.148.75.155]) by sunlabs.East.Sun.COM (8.9.1b+Sun/8.9.1) with ESMTP id LAA02273; Tue, 1 Feb 2000 11:38:26 -0500 (EST) Message-ID: <38970B83.D1287ED0@sun.com> Date: Tue, 01 Feb 2000 11:36:19 -0500 From: Steve Hanna Organization: Sun Microsystems, Inc. X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-secretariat@ietf.org CC: Vern Paxson , Scott Bradner , Thomas Narten , Dave Thaler , malloc Subject: Updating malloc milestones Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-malloc@catarina.usc.edu Precedence: bulk Content-Transfer-Encoding: 7bit Please update the milestones for the malloc Working Group to the following: Done Report on simulation and implementation efforts with existing protocol proposals. Address any problems in the specifications that were found. Done Meet at Orlando IETF. Review and finalize the host-server protocol. Done Submit the host-server protocol to the IESG for consideration as a Proposed Standard. Done Repost the updated architecture document as a WG Internet-Draft Done Repost the MADCAP scope-nesting option document as a WG Internet-Draft Done Review and finalize the inter-domain protocol Done Submit the abstract API document to the IESG for consideration as Informational. Done Submit the inter-domain protocol to the IESG for consideration as Experimental Done Submit the MADCAP scope-nesting option document to the IESG for consideration as Proposed Standard Done Submit the architecture document to the IESG for consideration as Informational Mar 00 Review and finalize the intra-domain protocol Apr 00 Submit the intra-domain protocol to the IESG for consideration as a Proposed Standard. Apr 00 Submit the MIB for the host-server and intra-domain protocols to the IESG for consideration as a Proposed Standard. Thanks, Steve Hanna malloc co-chair From owner-malloc@catarina.usc.edu Wed Feb 9 14:26:47 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18777 for ; Wed, 9 Feb 2000 14:26:44 -0500 (EST) Received: (from majordomo@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA01215 for malloc-list; Wed, 9 Feb 2000 11:03:24 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordomo set sender to owner-malloc@catarina.usc.edu using -f Received: (from pavlin@localhost) by catarina.usc.edu (8.9.3/8.9.3) id LAA01204 for malloc@catarina.usc.edu; Wed, 9 Feb 2000 11:03:18 -0800 (PST) Received: from smtprich.nortel.com (smtprich.nortel.com [192.135.215.8]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id KAA01024 for ; Wed, 9 Feb 2000 10:47:14 -0800 (PST) Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprich.nortel.com; Wed, 9 Feb 2000 12:46:41 -0600 Received: from zrtpd003.us.nortel.com ([47.140.224.137]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 1TWF5KA6; Wed, 9 Feb 2000 12:45:55 -0600 Received: from nortelnetworks.com (CLEMSON [132.245.252.117]) by zrtpd003.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id DJLA2GRR; Wed, 9 Feb 2000 13:45:55 -0500 Message-ID: <38A1B57F.C079A9F3@nortelnetworks.com> Date: Wed, 09 Feb 2000 13:44:16 -0500 From: "Brian Haberman" Organization: Nortel Networks X-Mailer: Mozilla 4.51 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: MALLOC Mailing List Subject: Multicast address allocation for IPv6 Content-Type: multipart/mixed; boundary="------------160D635E302EA6FAD5431EB6" X-Orig: Sender: owner-malloc@catarina.usc.edu Precedence: bulk This is a multi-part message in MIME format. --------------160D635E302EA6FAD5431EB6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, The following ID was just submitted to the editor for posting as an individual submission. Please direct comments, questions, or suggestions to the mailing list or to me. Brian -- Brian Haberman Advanced Network Research Nortel Networks haberman@nortelnetworks.com --------------160D635E302EA6FAD5431EB6 Content-Type: text/plain; charset=us-ascii; name="mcast-assign.txt" Content-Disposition: inline; filename="mcast-assign.txt" Content-Transfer-Encoding: 7bit MALLOC Working Group B. Haberman Internet Draft Nortel Networks draft-haberman-malloc-ipv6-prefix-00.txt February 2000 Expires August 2000 Dynamic Allocation Guidelines for Network Prefix-based IPv6 Multicast Addresses Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC 2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet- Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract With the multicast address architecture proposed in [NEW ARCH], a set of guidelines is needed for multicast address allocation servers to use in assigning IPv6 multicast addresses. The purpose of these rules is to reduce the possibility of address collisions on layer 2 devices. 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119]. 2. Introduction With the multicast address architecture proposed in [NEW ARCH], a set of guidelines is needed for multicast address allocation servers to use in assigning IPv6 multicast addresses. The purpose of these rules is to reduce the possibility of address collisions on layer 2 devices. These guidelines specify how the lowest 32 bits of the IPv6 multicast address are chosen and assigned. The guidelines specify several mechanisms that can be used to determine the lowest 32 bits of the multicast address. By having several mechanisms of varying complexity, implementers and operators have the flexibility to choose a mechanism that is appropriate for their application. Haberman 1 Internet Draft IPv6 Multicast Address Architecture December 1999 3. Assignment of New IPv6 Multicast Addresses The current approach [RFC 2464] to map IPv6 multicast addresses into IEEE 802 MAC addresses takes the low order 32 bits of the IPv6 multicast address and uses it to create a MAC address. Group ID's less than or equal to 32 bits will generate unique MAC addresses. Due to this, new IPv6 multicast addresses that are network prefix-based have the following format: | 8 | 4 | 4 | 8 | plen bits | 72 _ plen | 32 bits | +--------+----+ + ---- --------+----------------+-----------+------------+ |11111111|flgs|scop| plen | Network prefix | reserved | group ID | +--------+----+----+--------+----------------+-----------+------------+ The goal of this document is to present several mechanisms implementers and operators can use to select the group ID portion of the address so that the possibility of collisions at the IEEE 802 layer is reduced. The following section presents several different mechanism of varying complexity that can be used to select an appropriate group ID. 4. Group ID Selection Guidelines The following guidelines assume that the upper 96 bits of the IPv6 multicast address have been set up. The set up of those bits is done in the following manner: o An IPv6 multicast address prefix is initialized with the appropriate flags and scope fields o The IPv6 Network Prefix is inserted into the address and the plen field is set. The Network Prefix is obtained from the periodic Router Advertisements. o The reserved field in the IPv6 multicast address is set to zero The group ID portion of the address is set using one of the following mechanisms. 4.1 Network Time Protocol (NTP) Rule The Network Time Protocol [RFC 1305] defines a 64-bit network timestamp. The entity creating the IPv6 multicast address sets the group ID portion of the IPv6 multicast address to the upper 32 bits of the NTP timestamp. In order for a collision to occur at the IEEE 802 layer, two IPv6 multicast address allocations would have to occur at the same second. 4.2 Network Time Protocol and IPv6 Unicast Address This mechanism adds some complexity to the NTP approach defined above. The entity creating the IPv6 multicast address once again obtains an NTP timestamp. It then logically OR's the upper 32 bits of the NTP timestamp with the lowest 32 bits of its IPv6 link-local address and places that value in the group ID portion of the IPv6 multicast Haberman 2 Internet Draft IPv6 Multicast Address Architecture December 1999 address. This approach addresses the scenario where two allocating entities allocate addresses in the same second. 4.3 MD5 Digest In this approach, the group ID is created using the MD5 Message-Digest [RFC 1321]. The 64-bit IPv6 Network Prefix is appended with either the 64-bit NTP timestamp or a 64-bit value created using the guidelines in [RFC 1750]. The corresponding 128-bit value is then fed into MD5. The group ID portion of the IPv6 multicast address is set to the lowest 32 bits of the resulting MD5 digest value. 5. Security Considerations This document does not have any direct impact on Internet infrastructure security. 6. References [RFC 2026] S. Bradner, _The Internet Standards Process -- Revision 3_, BCP 9, RFC 2026, October 1996. [NEW ARCH] B. Haberman, _IP Version 6 Multicast Addressing Architecture_, draft-haberman-ipngwg-mcast-arch-00.txt, December 1999. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP14, March 1999. [RFC 2464] M. Crawford, _Transmission of IPv6 Packets over Ethernet Networks_, RFC 2464, December 1998. [RFC 1305] D. Mills, _Network Time Protocol (Version 3) Specification, Implementation_, RFC 1305, March 1992. [RFC 1321] R. Rivest, _The MD5 Message-Digest Algorithm_, RFC 1321, April 1992. [RFC 1750] D. Eastlake, S. Crocker, J. Schiller, _Randomness Recommendations for Security_, RFC 1750, December 1994. Haberman 3 Author's Address Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 1-919-992-4439 Email : haberman@nortelnetworks.com Haberman 4 --------------160D635E302EA6FAD5431EB6-- From owner-malloc@catarina.usc.edu Mon Feb 28 10:14:24 2000 Received: from catarina.usc.edu (catarina.usc.edu [128.125.51.47]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11047 for ; Mon, 28 Feb 2000 10:14:23 -0500 (EST) Received: (from majordom@localhost) by catarina.usc.edu (8.9.3/8.9.3) id OAA71770 for malloc-list; Tue, 22 Feb 2000 14:22:59 -0800 (PST) X-Authentication-Warning: catarina.usc.edu: majordom set sender to owner-malloc@catarina.usc.edu using -f Received: from rumi.usc.edu (rumi.usc.edu [128.125.51.41]) by catarina.usc.edu (8.9.3/8.9.3) with ESMTP id OAA71765 for ; Tue, 22 Feb 2000 14:22:58 -0800 (PST) Received: from rumi (localhost [127.0.0.1]) by rumi.usc.edu (8.9.3/8.9.3) with ESMTP id OAA77994 for ; Tue, 22 Feb 2000 14:23:10 -0800 (PST) Message-Id: <200002222223.OAA77994@rumi.usc.edu> To: malloc@catarina.usc.edu Subject: RFC Editor: RFC 2770 on GLOP Addressing in 233/8 Date: Tue, 22 Feb 2000 14:23:10 -0800 From: Pavlin Ivanov Radoslavov Sender: owner-malloc@catarina.usc.edu Precedence: bulk FYI. Pavlin ------- Forwarded Message Message-Id: <200002222043.MAA17261@boreas.isi.edu> To: IETF-Announce: ; Subject: RFC 2770 on GLOP Addressing in 233/8 Cc: rfc-ed@ISI.EDU, mboned@network-services.uoregon.edu Date: Tue, 22 Feb 2000 12:43:04 -0800 From: RFC Editor Sender: owner-mboned@network-services.uoregon.edu Precedence: bulk X-Archive: ftp://ns.uoregon.edu/mailing-lists/mboned.archive X-HTTP: http://ns.uoregon.edu/~dmm/MBONED X-Subscribe: majordomo@ns.uoregon.edu X-Unsubscribe: majordomo@ns.uoregon.edu - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2770 Title: GLOP Addressing in 233/8 Author(s): D. Meyer, P. Lothberg Status: Experimental Date: February 2000 Mailbox: dmm@cisco.com, roll@sprint.net Pages: 5 Characters: 8988 Updates/Obsoletes/See Also: None I-D Tag: draft-ietf-mboned-glop-addressing-02.txt URL: ftp://ftp.isi.edu/in-notes/rfc2770.txt This describes an experimental policy for use of the class D address space using 233/8 as the experimental statically assigned subset of the class D address space. This new experimental allocation is in addition to those described on [IANA] (e.g. [RFC2365]). This document is a product of the MBONE Deployment Working Group of the IETF. This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <000222123954.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc2770 - --OtherAccess Content-Type: Message/External-body; name="rfc2770.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <000222123954.RFC@RFC-EDITOR.ORG> - --OtherAccess-- - --NextPart-- ------- End of Forwarded Message