One document matched: draft-ietf-malloc-ipv6-guide-00.txt

   MALLOC Working Group                                         B. Haberman
   Internet Draft                                           Nortel Networks
   draft-ietf-malloc-ipv6-guide-00.txt 
   May 2000 
   Expires November 2000 
 
 
                     Dynamic Allocation Guidelines  
                      for 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 current multicast address architecture and the proposed 
   multicast address architecture, 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 collision not only at layer 3, but also on 
   devices at layer 2.  
    
    
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 
    


  
Haberman                                                             1 
 
 

Internet Draft   IPv6 Multicast Address Architecture          May 2000 
    
   With the current multicast address architecture [RFC 2373] and the 
   multicast address architecture proposed in [NEW ARCH], a set of 
   guidelines is needed for multicast address allocation servers 
   [MALLOC] to use in assigning IPv6 multicast addresses.  The purpose 
   of these rules is to reduce the possibility of address collision not 
   only at layer 3, but also on devices at layer 2. 
    
   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. 
 
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 long will generate unique MAC 
   addresses.   
    
   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 IP layer 
   and 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.  For unicast network prefix-
   based multicast addresses, 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 
    
   With the multicast address architecture in [RFC 2373], 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 


  
Haberman                                                             2 
    
 

Internet Draft   IPv6 Multicast Address Architecture          May 2000 
    
           o  The reserved field in the IPv6 multicast address is set 
              to zero 
    
   The group ID portion of the address is set using either a pseudo-
   random 32-bit number or a 32-bit number created using the guidelines 
   in [RFC 1750].  Possible approaches to creating a pseudo-random 
   number are to use an MD5 message-digest [RFC 1321] or portions of an 
   NTP [RFC 1305] timestamp. 
    
   The assignment of the group ID portion of the address SHOULD take 
   care to ensure that the generated multicast address does not share a 
   group ID with a permanently assigned IPv6 multicast address.  The 
   permanently assigned multicast addresses are defined in [RFC 2375]. 
    
   Requests for more than one multicast address SHOULD be handled 
   atomically.  One possible approach is to use the initial group ID, 
   created using the guidelines above, as the base address in a 
   contiguous block of multicast addresses.  Another approach is to 
   create multiple group IDs and generate the appropriate multicast 
   addresses. 
    
                  
5. Multicast Address Lifetime 
    
   The lifetime of the assignment of unicast prefix-based multicast 
   addresses MUST be less than or equal to the Valid Lifetime field in 
   the Prefix Information option contained in the Neighbor Discovery 
   Router Advertisement message [RFC 2461]. 
    
    
6. Security Considerations 
    
   This document does not have any direct impact on Internet 
   infrastructure security. 
    
 
7. References 
    
   [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 
              3", BCP 9, RFC 2026, October 1996. 
    
   [NEW ARCH] Haberman, B., Thaler, D., "IP Version 6 Multicast 
              Addressing Architecture",  
              draft-ietf-ipngwg-mcast-arch-00.txt, April 2000. 
    
   [RFC 2373] Hinden, R., Deering, S., "IP Version 6 Addressing 
              Architecture", RFC 2373, July 1998. 
    
   [MALLOC]   Thaler, D., Handley, M., and Estrin, D., "The Internet 
              Multicast Address Allocation Architecture", 
              draft-ietf-malloc-arch-04.txt, January 2000. 

  
Haberman                                                             3 
    
 

Internet Draft   IPv6 Multicast Address Architecture          May 2000 
    
    
   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate     
              Requirement Levels", RFC 2119, BCP14, March 1999. 
    
   [RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 
              Networks", RFC 2464, December 1998. 
    
   [RFC 1305] Mills, D., "Network Time Protocol (Version 3) 
              Specification, Implementation", RFC 1305, March 1992. 
    
   [RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 
              April 1992. 
    
   [RFC 1750] Eastlake, D., Crocker, S., Schiller, J., "Randomness 
              Recommendations for Security", RFC 1750, December 1994. 
    
   [RFC 2375] Hinden, R., Deering, S., "IPv6 Multicast Address 
              Assignments", RFC 2375, July 1998. 
    
   [RFC 2461] Narten, T., Nordmark, E., Simpson, W., "Neighbor 
              Discovery for IP Version 6 (IPv6)", RFC 2461, December 
              1998.






























  
Haberman                                                             4 
    


 
Author's Address 
    
   Brian Haberman 
   Nortel Networks 
   4309 Emperor Blvd. 
   Suite 200 
   Durham, NC  27703 
   1-919-992-4439 
   Email : haberman@nortelnetworks.com 











































  
Haberman                                                             5