Internet DRAFT - draft-ietf-malloc-static-ipv6-alloc
draft-ietf-malloc-static-ipv6-alloc
INTERNET DRAFT Brian Haberman
April 1999 (IBM)
Static Allocation of Multicast Addresses in
the Internet Protocol Version 6 (IPv6)
<draft-ietf-malloc-static-ipv6-alloc-00.txt>
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of 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 not appropriate to use Internet-Drafts as
reference material, or to cite them other than as a ``working draft''
or ``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 defines a mechanism for statically allocating IPv6
multicast addresses by network prefixes. This approach will
integrate seamlessly with the Multicast Address Dynamic Client
Allocation Protocol (MADCAP). It will also remove the need to support
the Multicast Address Set Claim (MASC) Protocol for IPv6.
Haberman Expires October 1999 [Page i]
Internet Draft Static Allocation of IPv6 Multicast Addresses April 1999
Contents
1. Keywords 1
2. Introduction 1
3. IPv6 Multicast Address Format 1
4. Static Allocation 1
4.1. Globally routable prefixes . . . . . . . . . . . . . . . 1
4.2. Site-local prefixes . . . . . . . . . . . . . . . . . . . 2
4.3. Link-local prefixes . . . . . . . . . . . . . . . . . . . 2
5. Security Considerations 2
6. References 3
7. Author's Address 3
8. Full Copyright Statement 3
Haberman Expires October 1999 [Page ii]
Internet Draft Static Allocation of IPv6 Multicast Addresses April 1999
1. Keywords
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 [RFC2119].
2. Introduction
One of the most common problems with IPv4 multicast is the limited
size of the multicast address range. This limited range size has led
to
several mechanisms for allocating IPv4 multicast addresses. With the
address architecture introduced for IPv6 [ADDARCH], the address range
constraint does
not hinder IPv6 multicast. Because of the increased address size, it
is feasible to allocate multicast addresses statically in IPv6.
This work describes the mechanism for the static allocation of IPv6
multicast addresses based on the IPv6 network prefix. It will work
seamlessly with the MADCAP [MADCAP]
protocol. Because this is a static allocation, it will eliminate the
need for running the MASC protocol [MASC].
3. IPv6 Multicast Address Format
The IPv6 address architecture defines an IPv6 multicast address as
follows :
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
The legal values for the flgs and scop field are defined in the IPv6
address architecture [ADDARCH].
4. Static Allocation
4.1. Globally routable prefixes
The mechanism for allocating IPv6 multicast addresses will be to
imbed an IPv6 unciast network prefix
in the multicast address starting at bit 16. The resulting multicast
address will have the following format if
Haberman Expires October 1999 [Page 1]
Internet Draft Static Allocation of IPv6 Multicast Addresses April 1999
the network prefix was taken from an address format that must contain
an EUI-64 based interface identifier (Section 2.4 of [ADDARCH]).
| 8 | 4 | 4 | 64 bits | 48 bits |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| IPv6 unicast network prefix | group ID |
+--------+----+----+---------------------------------------------+
This format will allow for 2^48 group IDs for each unique (scop,
prefix) pair.
4.2. Site-local prefixes
If a node attempting
to obtain an IPv6 multicast address does not have a globally routable
network prefix, it can use a site-local address prefix in the same
manner. In this case, the multicast address format will be :
| 8 | 4 | 4 | 10 bits |38 bits | 16 bits | 48 bits |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop|1111111011 | 0 | subnet ID | group ID |
+--------+----+----+---------------------------------------------+
With this format, the scop field of the address can be no greater
than site-local (5), defined in Section 2.7 of [ADDARCH].
4.3. Link-local prefixes
If a node only
has a link-local address, section 2.5.8 of [ADDARCH], it can only use
a multicast address with a scop field no greater than link-local (2).
For this case, the multicast address format is as follows :
| 8 | 4 | 4 | 112 bits |
+--------+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
5. Security Considerations
Haberman Expires October 1999 [Page 2]
Internet Draft Static Allocation of IPv6 Multicast Addresses April 1999
6. References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP14, March 1997.
[ADDARCH] R. Hinden and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[MADCAP] B. Patel, M. Shah, and S. Hanna, "Multicast Address
Dynamic Client Allocation Protocol (MADCAP)",
draft-ietf-malloc-madcap-04.txt, February 1999.
[MASC] D. Estrin, R. Govindan, M. Handley, S. Kumar,
P. Radoslavov, and D. Thaler, "The Multicast Address-Set
Claim (MASC) Protocol", draft-ietf-malloc-masc-01.txt,
August 1998.
7. Author's Address
Brian Haberman
IBM Corporation
800 Park Office Drive
Research Triangle Park, NC 27709
USA
+1-919-254-2673
haberman@raleigh.ibm.com
8. Full Copyright Statement
Copyright (C) The Internet Society (1999). All Rights Reserved.
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 or 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
Haberman Expires October 1999 [Page 3]
Internet Draft Static Allocation of IPv6 Multicast Addresses April 1999
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 Expires October 1999 [Page 4]
