WDIFF

draft-ietf-malloc-ipv6-guide-01.txt --> draft-ietf-malloc-ipv6-guide-03.txt

MALLOC Working Group B. Haberman
Internet Draft Nortel Networks
draft-ietf-malloc-ipv6-guide-01.txt
July 2000
draft-ietf-malloc-ipv6-guide-03.txt
June 2001
Expires January December 2001

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

This document specifies guidelines to that must be used when implemented by any
entity responsible for allocating IPv6 multicast addresses. The
purpose of these guidelines is to reduce the probability of IPv6
multicast address collision, not only at the IPv6 layer, but also at
the MAC layer of media that utilizes IEEE 802 addressing.

Table of Contents

Status of this Memo................................................1
Abstract...........................................................1
1. Terminology.....................................................2
2. Introduction....................................................2
3. Applicability...................................................2
4. Assignment of New IPv6 Multicast Addresses......................3
5. Group ID Selection Guidelines...................................3
6. Multicast Address Lifetime...........Error! Bookmark not defined.
7. Security Considerations.........................................4
8. IANA Considerations.............................................4

Haberman 1

Internet Draft IPv6 Multicast Address Guidelines July 2000

9. Acknowledgements................................................4
10. References.....................................................4
AuthorÆs Address...................................................6
Full Copyright Statement...........................................6

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].

The term "group ID" throughout this document conforms to the
definition contained in section 2.7.2 of RFC 2373 [RFC 2373], that
is, the low-order 32 bits of the address.

2. Introduction

This document specifies guidelines to that MUST be used when implemented by any
entity responsible for allocating IPv6 multicast addresses. The
purpose of these guidelines is to reduce

Haberman 1

Internet Draft IPv6 Multicast Address Guidelines July 2000 the probability of IPv6
multicast address collision, not only at the IPv6 layer, but also at
the MAC layer of media that utilizes IEEE 802 addressing.

With the current IPv6 multicast address architecture [RFC 2373] and the
proposed extension to that the multicast address architecture specified
in [NEW ARCH], a set of guidelines is needed for multicast address allocation
servers [MALLOC] to use in entities assigning
any flavor of IPv6 multicast addresses.

These guidelines specify how the lowest low-order 32 bits (henceforth
called the group ID) of the IPv6 multicast address are chosen and
assigned. The guidelines specify several mechanisms that can be
used to determine the lowest 32 bits group ID of the multicast address. By
supporting several mechanisms, these guidelines can accommodate the
varying capabilities of multicast address allocation servers. schemes.

3. Applicability

These guidelines are designed to be used in any environment in which
IPv6 multicast addresses are delegated, assigned, or selected.
These guidelines are not limited to use by MADCAP [RFC 2730]
servers. The following is a non-exhaustive list of applications of
these guidelines:

- Source-specific multicast application servers can generate an
SSM group address by generating a 96 bit multicast prefix as
defined in [NEW ARCH] and concatenating that with a group ID
as defined in this document.

Haberman 2

Internet Draft IPv6 Multicast Address Guidelines July 2000

- A MADCAP server allocates IPv6 multicast addresses generated
in the same manner as the SSM server. This approach gives
network administrators centralized control over multicast
address delegation.
- A MADCAP server allocates IPv6 multicast addresses conforming
to section 2.7.2 of RFC 2373 [RFC 2373] with the group ID
being created using the rules defined in this document.
- Nodes supplying multicast services in a zeroconf environment
generate multicast addresses without the need of centralized
control.

4. 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 (the group ID) of
the IPv6 multicast address and uses it to create a MAC address.
Group IDs less than or equal to 32 bits long will generate unique
MAC addresses within a given multicast scope.

The goal of this document is to present several mechanisms
implementers and operators that can use
be used to select the group ID portion of the multicast 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 mechanisms of varying complexity that can be used to
select an appropriate group ID.

5. Group ID Selection Guidelines

The following guidelines assume that the upper 96 bits of the IPv6
multicast address have been initialized according to [RFC 2373] and or
[NEW ARCH].

The T flag of each dynamically allocated multicast address MUST be
set to '1'. Permanent addresses MUST NOT be allocated using the
multicast address allocation architecture. '1' [RFC 2373].

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 include using an MD5 message-digest [RFC 1321] or portions of
an NTP [RFC 1305] timestamp.

The high-order bit of the Group ID MUST be set to '1'. This will
distinguish the dynamically allocated addresses from the permanently

Haberman 2

Internet Draft IPv6 Multicast Address Guidelines July 2000
assigned multicast addresses defined in [RFC 2375] at the MAC layer
on any media that utilizes IEEE 802 addressing.

A request for multiple multicast addresses 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

Haberman 3

Internet Draft IPv6 Multicast Address Guidelines July 2000

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

Organizations wishing to reserve a permanent group ID value for use
across multiple domains MUST be less than or equal direct their request to the Valid Lifetime field in
the Prefix Information option contained IANA.
Permanent group IDs MUST fall in the Neighbor Discovery
Router Advertisement message [RFC 2461]. range 0x40000000 to 0x7FFFFFFF.

6. Security Considerations

This document does not have any known impact on Internet
infrastructure security.

7. IANA Considerations

Following the policies outlined in [RFC 2434]:

- Permanent multicast addresses, like those defined in [RFC
2375], are allocated with group ID's in the range of 1 to
0x3FFFFFFF on a First Come First Served basis
- Permanent group ID's are allocated on a First Come First
Served basis in the range 0x40000000 to 0x7FFFFFFF
- The range 0x80000000 to 0xFFFFFFFF is reserved for
Private Use

8. Acknowledgements

The author would like to thank Dave Thaler and Thaler, Steve Deering Deering, Allison
Mankin, and Thomas Narten for their thorough review of this
document.

9. References

[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.

[NEW ARCH] Haberman, B., Thaler, D., "Unicast Prefix-based IPv6
Multicast Addresses", Work in Progress, July 2000. January 2001.

[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.

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP14, March 1999.

[RFC 2730] Hanna, S., Patel, B., Shah, M., "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)", RFC 2730,

Haberman 4

Internet Draft IPv6 Multicast Address Guidelines July 2000

December 1999.

[RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.

Haberman 3

Internet Draft IPv6 Multicast Address Guidelines July 2000

[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 5

AuthorÆs Address

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

Full Copyright Statement

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice ore references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Haberman 5 6

----