WDIFF

draft-ietf-malloc-ipv6-guide-03.txt --> draft-ietf-malloc-ipv6-guide-04.txt-16322.txt

MALLOC Working Group B. Haberman
Internet Draft Nortel Networks
draft-ietf-malloc-ipv6-guide-03.txt
June
draft-ietf-malloc-ipv6-guide-04.txt
October 2001
Expires December 2001 April 2002

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 that must be implemented by any
entity responsible for allocating IPv6 multicast addresses. This
includes, but is not limited to, any documents or entities wishing
to assign permanent IPv6 multicast addresses, allocate dynamic IPv6
multicast addresses, and define permanent IPv6 multicast group
identifiers. 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 link-layer of media that utilizes IEEE 802 addressing. encode portions
of the IP layer address into the MAC layer address.

Table of Contents

Status of this Memo................................................1
Abstract...........................................................1
1. Terminology.....................................................2
2. Introduction....................................................2
3. Applicability...................................................2 Applicability...................................................3
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 October 2001

4.1 Permanent IPv6 Multicast Addresses...........................3
4.2 Permanent IPv6 Multicast Group Identifiers...................3
4.3 Dynamic IPv6 Multicast Addresses.............................4
4.3.1 Server Allocation............................................4
4.3.2 Host Allocation..............................................4
5. IANA Considerations.............................................5
6. Security Considerations.........................................5
7. Acknowledgements................................................5
8. References......................................................6
AuthorÆs Address...................................................6 Address...................................................7
Full Copyright Statement...........................................6 Statement...........................................7

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], [UNIMCAST], that is, the low-order 32 bits
of the IPv6 multicast address.

2. Introduction

This document specifies guidelines that MUST be implemented by any
entity responsible for allocating IPv6 multicast addresses. This
includes, but is not limited to, any documents or entities wishing
to assign permanent IPv6 multicast addresses, allocate dynamic IPv6
multicast addresses, and define permanent IPv6 multicast group
identifiers. 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 link-layer of media that utilizes IEEE 802 addressing. encode portions
of the IP layer address into the link-layer address.

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

These guidelines specify how

The current approach of several physical media [RFC 2464][RFC 2467]
is to map a portion of the low-order IPv6 multicast address into a link-layer
destination address. This is accomplished by taking the low order
32 bits (henceforth called the group ID) of the IPv6 multicast
address and including them in the link-layer destination address.
Group IDs less than or equal to 32 bits long will generate unique
link-layer addresses within a given multicast scope.

These guidelines specify how the group ID of the IPv6 multicast
address are chosen and assigned. The guidelines specify several

Haberman 2

Internet Draft IPv6 Multicast Address Guidelines October 2001

mechanisms that can be used to determine the group ID of the
multicast address. By
supporting several mechanisms, these guidelines can accommodate address, based on the
varying capabilities type of multicast address allocation schemes. being done.

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 96-bit multicast prefix as
defined in [NEW ARCH] [UNIMCAST] (i.e. FF3x::/96) 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 2.7 of RFC 2373 [RFC 2373] [ADDRARCH] 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.
- IANA can assign permanent multicast addresses to fulfill
requests via the protocol standardization process.

4. Assignment Group ID Selection Guidelines

The Group ID selection process allows for three types of New multicast
address assignments. These are permanent IPv6 Multicast Addresses multicast addresses,
dynamic IPv6 multicast addresses, and permanent IPv6 multicast group
IDs. The current approach [RFC 2464] following guidelines assume that the prefix of the
multicast address has been initialized according to map [ADDRARCH] or
[UNIMCAST].

4.1 Permanent IPv6 Multicast Addresses

Permanent multicast addresses, like those defined in [RFC 2375], are
allocated by IANA. These addresses into
IEEE 802 MAC addresses takes the low order 32 bits (the will be assigned with group ID) ID's
in the range of 0x00000001 to 0x3FFFFFFF on a First Come First
Served basis.

Multicast addresses assigned by IANA MUST have the IPv6 multicast address T bit set to 0
and uses it the P bit set to create a MAC address. 0.

4.2 Permanent IPv6 Multicast Group Identifiers

Permanent group IDs less than or equal to 32 bits long will generate unique
MAC addresses within allow for a given multicast scope.

The goal global identifier of this document is to present several mechanisms that can
be used to select a particular
service (e.g. Network Time Protocol (NTP) being assigned the group

Haberman 3

Internet Draft IPv6 Multicast Address Guidelines October 2001

ID portion 0x40404040). The use of the permanent group IDs differs from
permanent multicast address so addresses in that a permanent group ID offers a
global identifier for a service being offered by numerous servers.

As an example, consider the possibility NTP example group ID of collisions at the IP layer 0x40404040. An
NTP client would be able to access multiple servers and at multiple
scopes. That is, the IEEE
802 layer is reduced. The following section presents several
different mechanisms of varying complexity NTP client will know that can be used to
select an appropriate the group ID.

5. Group ID Selection Guidelines

The following guidelines assume that
0x40404040 identifies an NTP multicast stream regardless of the
upper 96 bits of the IPv6
multicast address have been initialized according to [RFC 2373] or
[NEW ARCH].

The T flag of each dynamically allocated multicast address MUST be
set to '1' [RFC 2373].

The address.

Permanent group ID portion of the address is set using either a pseudo-
random 32-bit number or IDs are allocated on a 32-bit number created using the guidelines First Come First Served basis
in [RFC 1750]. Possible approaches the range 0x40000000 to creating a pseudo-random
number include using 0x7FFFFFFF. These permanent group IDs
are meant to be used in IPv6 multicast addresses defined in
[UNIMCAST].

4.3 Dynamic IPv6 Multicast Addresses

Dynamic IPv6 multicast addresses can be allocated by an MD5 message-digest [RFC 1321] allocation
server or portions of by an NTP [RFC 1305] timestamp.

The high-order bit end-host. Regardless of the Group ID allocation mechanism,
all dynamically allocated IPv6 multicast addresses MUST be have the T
bit set to '1'. 1. This will distinguish the dynamically allocated
addresses from the permanently assigned multicast addresses defined
in [RFC 2375] at the MAC layer link-layer on any media that utilizes IEEE 802 addressing. maps the lower
portion of the IPv6 multicast address into a link-layer address. It
should be noted that the high-order bit of the Group ID will the
same value as the T flag.

As an example, the permanent IPv6 multicast address FF02::9 maps to
an Ethernet group address of 33-33-00-00-00-09. A request for multiple dynamically
allocated IPv6 multicast address of FF32::8000:9 would map to the
Ethernet group address 33-33-80-00-00-09.

4.3.1 Server Allocation

The allocation of IPv6 multicast addresses SHOULD be handled
atomically. One possible approach by a server is to defined in
[RFC 2730]. Address management is the responsibility of the
allocation protocol and outside the scope of this document.
Allocation servers MUST use the initial group ID,
created using group ID range 0x80000000 to
0xFFFFFFFF.

4.3.2 Host Allocation

Host-based allocation allows hosts to self-select IPv6 multicast
addresses. One example of host-based allocation is the Zeroconf
Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with
collision detection, claim notification, etc. are outside the scope
of this document and the responsibility of the guidelines above, protocol being used,
such as the base address in a [ZMAAPDOC].

Haberman 3 4

Internet Draft IPv6 Multicast Address Guidelines July 2000

contiguous block October 2001

The group ID portion of multicast addresses. Another approach the address is to
create multiple created using either a
pseudo-random 32-bit number or a 32-bit number created using the
guidelines in [RFC 1750]. The generated group IDs and generate ID MUST fall in the appropriate multicast
addresses.

Organizations wishing
range 0x80000000 to 0xFFFFFFFF. This can be accomplished by setting
the high-order bit of the generated number to reserve 1.

5. IANA Considerations

This document requests the creation of a new registry maintained by
IANA. This new registry will maintain permanent group ID value values.
The premise of this new registry is to allow for use permanent group IDs
to be used across multiple domains MUST direct their request to IANA.
Permanent utilizing the multicast address
architecture defined in [UNIMCAST]. The permanent group IDs MUST will
fall in the range 0x40000000 to 0x7FFFFFFF.

6. Security Considerations

This

In addition, this document does not have any known impact on Internet
infrastructure security.

7. IANA Considerations also defines rules for the allocation of
permanent IPv6 multicast addresses by IANA.

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 basis, see
Section 4.1.
- Permanent group ID's are allocated on a First Come First
Served basis in the range 0x40000000 to 0x7FFFFFFF 0x7FFFFFFF, see
Section 4.2.
- The range 0x80000000 to 0xFFFFFFFF is reserved for
Private Use

8. use by
dynamic multicast address allocation mechanisms, see
Section 4.3.

6. Security Considerations

The allocation mechanisms described in this document do not alter
the security properties of either the Any Source or Source Specific
multicast service models of IPv4 and IPv6.

The potential to allocate large blocks of addresses can lead to
Denial-of-Service attacks. A more in-depth discussion of the
security issues surrounding dynamic allocation of multicast
addresses can be found in [RFC 2908].

7. Acknowledgements

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

Haberman 5

Internet Draft IPv6 Multicast Address Guidelines October 2001

8. References

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

[NEW ARCH]

[UNIMCAST] Haberman, B., Thaler, D., "Unicast Prefix-based IPv6
Multicast Addresses", Work in Progress, January September 2001.

[RFC 2373]

[ADDRARCH] Hinden, R., Deering, S., "IP Version 6 Addressing
Architecture", RFC 2373, Work In Progress, July 1998. 2001.

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

[RFC 1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.

[RFC 1321] Rivest, R., "The MD5 Message-Digest Algorithm", 2467] Crawford, M., "Transmission of IPv6 over FDDI Networks",
RFC 1321,
April 1992. 2467, December 1998.

[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 2908] Thaler, D., Handley, M., and Estrin, D., "The Internet
Multicast Address Allocation Architecture", RFC 2908,
September 2000.

[ZMAAPDOC] Catrina, et al, "Zeroconf Multicast Address Allocation
Protocol (ZMAAP)", Work In Progress, June 2001.

Haberman 5 6

AuthorÆs Address

Brian Haberman
4309 Emperor Blvd.
Suite 200
Durham,
300 Perimeter Park
Morrisville, NC 27703
1-919-992-4439 27560
1-919-905-7484
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 6 7

----