Internet DRAFT - draft-pashby-ipv6-mc-scoped-addr
draft-pashby-ipv6-mc-scoped-addr
MBONE Deployment R. Pashby
Internet-Draft Bowhead
Expires: October 14, 2006 April 12, 2006
IPv6 Multicast Scoped Address Assignment Guidance
draft-pashby-ipv6-mc-scoped-addr-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on October 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The purpose of this document is to define IPv6 Multicast Id ranges
that will not allow overlap between dynamically assigned global
scoped addresses and dynamically assigned non-global scoped
addresses, specifically dynamically assigned link-local scoped
addresses.
Pashby Expires October 14, 2006 [Page 1]
Internet-Draft IPv6 MCast Scoped Addr April 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Justification . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Multicast Group ID Assignment Guidelines . . . . . . . . . . . 5
5. Modifications to RFC3307 . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Pashby Expires October 14, 2006 [Page 2]
Internet-Draft IPv6 MCast Scoped Addr April 2006
1. Introduction
The purpose of this document is to define IPv6 Multicast Id ranges
that will not allow overlap between dynamically assigned global
scoped addresses and dynamically assigned non-global scoped
addresses, specifically dynamically assigned link-local scoped
addresses.
RFC3307 [1] defines IPv6 Multicast Group ID ranges for the following
Permanent Addresses, Permanent Identifiers and Dynamic Addresses.
However, there are certain multicast addresses that need to be
assigned for closed systems that should not collide with the Group
IDs used within the Internet.
This document further defines the Dynamic Addresses into two ranges
Dynamically Assigned Global (DAG) addresses and Dynamically Assigned
Non-Global (DANG) addresses. The DANG range is further broken down
to Dynamically Assigned Link-Local (DALL) addresses and the rest
reserved for future. Future uses might be for Site-Local Scoped and
Organization Scoped ranges. The DALL range may be used to simplify
the design of MLD Snooping layer 2 switches.
It is understood that there is the Scope field in the IPv6 address;
however the issue here is keeping unique ranges that are guaranteed
not to overlap at the link-layer. Link-layer uniqueness is critical
within organizations because most of the multicast will be controlled
via layer 2 switches.
Given the definitions in RFC3307 [1] the new ranges should be
assigned from the currently defined Dynamically Assigned Addresses,
since they are not Permanently Assigned Addresses (from the Internet
perspective).
- Dynamically Assigned Global (DAG) Addresses
- Dynamically Assigned Non-Global (DANG) Addresses
- Reserved Dynamically Assigned Non-Global Addresses
- Dynamically Assigned Link-Local (DALL) Addresses
The Solicited Node Multicast Addresses will fall into the last range.
RFC3171 [3] also defines the Local Network Control Block (LNCB)
address range for IPv4. A similar range should be defined to
possibly simplify the design of MLD Snooping layer 2 switches, as
defined by mldsnoop [4]. This mldsnoop [4] document also recommends
that the DANG and LNCB addresses be forwarded to all layer 2 ports on
a MLD snooping switch.
Pashby Expires October 14, 2006 [Page 3]
Internet-Draft IPv6 MCast Scoped Addr April 2006
2. Applicability
These guidelines are to be used in any environment in which IPv6
multicast addresses are delegated, assigned, or selected. They are
critical to be used where overlap of multiple multicast flows can
happen on layer 2 switches.
3. Justification
If a host is flooded with high amounts of multicast traffic that is
not destined to the host (but matches a layer 2 multicast group that
the host has joined), then the traffic could cause the host to fail
to perform its function.
All hosts are required to join multicast groups associated with their
assigned IPv6 addresses. Hosts may also join a multicast group based
on an MD5 hash of its hostname. These multicast addresses fall into
the multicast group id range 0xFF000000 - 0xFFFFFFFF. This could
mean that every host joins 3 different multicast groups, i.e. link
local address, global address and name queries.
There is a method for creating dynamic multicast groups, which
defines that, the multicast group id to be generated by a 32 bit
random number and then setting the highest bit. This makes the range
0x80000000 - 0xFFFFFFFF, which overlaps the range above. Every time
a new multicast group is created a new group address is created.
There is a small, but definitely non-zero, probability that one host
on the sub-network joining one of these dynamic multicast groups that
it would cause an unsuspecting host to be flooded with the multicast
traffic. One may argue that since the probability is small it should
not be of concern. However, in many systems even a small probability
is unacceptable, because it could have catastrophic consequences.
One of the benefits of IPv6 is to create large numbers of small
sensors that each has an IPv6 address. It is perceived that these
sensors would not have much processing power. Thus, if one of these
sensors happened to be flooded with multicast traffic that happened
to match its required multicast group, it could end up not performing
its required duties.
The proposed solution is to reduce the range of the dynamically
created multicast address to guarantee that there is no overlap with
the multicast group ids that a host is required to join. The easiest
way is to reduce the range from 0x80000000 - 0xFFFFFFFF to the range
of 0x80000000 - 0xBFFFFFFF. This is accomplished by setting the
highest 2 bits of the 32 bit random number to 0b10.
Pashby Expires October 14, 2006 [Page 4]
Internet-Draft IPv6 MCast Scoped Addr April 2006
The major drawback to this approach is it reduces the range but
increases the probability of a collision between two groups created
by this method. The original range allowed for 2,147,483,648 (2B
Range) possible multicast ids. The reduced range, produces
1,073,741,824 (1B Range) possible multicast ids. This reduction does
not significantly increase the probability of two groups colliding as
can be seen by the following tables.
Probability of Collisions
+------------------+----------+----------+
| Number of Groups | 2B Range | 1B Range |
+------------------+----------+----------+
| 100 | <0.001% | <0.001% |
| 1000 | 0.023% | 0.047% |
| 10000 | 2.3% | 4.5% |
+------------------+----------+----------+
Number of Groups with Probability of Collisions
+-------------+----------+----------+
| Probability | 2B Range | 1B Range |
+-------------+----------+----------+
| 0.01% | 650 | 456 |
| 0.1% | 2077 | 1465 |
| 1% | 6572 | 4647 |
+-------------+----------+----------+
Given that the probability of collisions is not significantly
increased and the possibility of collision with hosts' required
groups is decreased to zero, it is recommended that the dynamically
created multicast id range be decreased to 0x80000000 - 0xBFFFFFFF.
4. Multicast Group ID Assignment Guidelines
4.1. Permanent Assigned Addresses
The range specified for Permanent Assigned Addresses is 0x00000001 -
0x3FFFFFFF. This is the same as defined in RFC3307.
4.1.1. Local Network Control Block
The range specified for Local Network Control Block is 0x00000001 -
0x000000FF. There is a related document [snoop] that recommends that
this range be sent to every interface on a layer 2 switches that
supports MLD snooping mldsnoop [4].
Pashby Expires October 14, 2006 [Page 5]
Internet-Draft IPv6 MCast Scoped Addr April 2006
4.2. Permanent Assigned IDs
The range specified for Permanent Assigned Identifiers is 0x40000000
- 0x7FFFFFFF. This is the same as defined in RFC3307.
4.3. Dynamically Assigned Addresses
This range was previously defined in RFC3307 but called Dynamic IPv6
Multicast Addresses. It is broken down into the following ranges.
4.3.1. Dynamically Assigned Global Scoped Addresses
This range would be used for Scope field values 9 - E.
The range specified for Dynamically Assigned Global Scoped Addresses
0x80000000 - 0xBFFFFFFF. This range was selected to provide the
largest range of addresses for dynamic allocation.
4.3.2. Dynamically Assigned Non-Global Addresses
This range would be used for Scope field values 1 - 8.
The range specified for Dynamically Assigned Non-Global Scoped
Addresses 0xC0000000 - 0xFFFFFFFF.
4.3.2.1. Reserved Dynamically Assigned Non-Global Addresses
This range is reserved for future use. Possible future use would be
for Site-Local Scoped and Organization Scoped addresses. The range
is 0xC0000000 - 0xEFFFFFFF.
4.3.2.2. Dynamically Assigned Link-Local Addresses
The range for Dynamically Assigned Link-Local Scoped Addresses is
0xF0000000 - 0xFFFFFFFF. This range was chosen so that it would
include the Solicited Node Multicast Addresses 0xFF000000 -
0xFFFFFFFF. There is a related document [snoop] that recommends that
this range be sent to every interface on a layer 2 switches that
supports MLD snooping mldsnoop [4].
5. Modifications to RFC3307
5.1. Permanent IPv6 Multicast Addresses (section 4.1)
Add the definitions of the LCNB ranges as defined above.
Pashby Expires October 14, 2006 [Page 6]
Internet-Draft IPv6 MCast Scoped Addr April 2006
5.2. Dynamic IPv6 Multicast Addresses (section 4.3)
Add the definitions of the DAG and DANG ranges as defined above.
5.3. Server Allocation (section 4.3.1)
Change the range from 0x80000000 - 0xFFFFFFFF to 0x80000000 -
0xBFFFFFFF.
5.4. Host Allocation Section (section 4.3.2)
Replace the last sentence with: This can be accomplished by setting
the high-order two bits of the generated number to 10 (binary).
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 RFC2908 [2].
7. IANA Considerations
This document defines the new LNCB range that IANA needs to assure
that addresses assigned in this range are for Link-local Network
Control.
8. Acknowledgments
Brian Haberman, John Hopkins University
Karen O'Donoghue, US Department of Navy
9. Change Log
9.1. Changes from 00 to 01
1. Added Justification section
2. Converted to XML
Pashby Expires October 14, 2006 [Page 7]
Internet-Draft IPv6 MCast Scoped Addr April 2006
10. References
[1] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[2] Thaler, D., Handley, M., and D. Estrin, "The Internet Multicast
Address Allocation Architecture", RFC 2908, September 2000.
[3] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, "IANA
Guidelines for IPv4 Multicast Address Assignments", BCP 51,
RFC 3171, August 2001.
[4] Pashby, R., "Simplifying IPv6 MLD Snooping Switches",
draft-pashby-maga-simplify-mld-snooping-01.txt (work in
progress).
Pashby Expires October 14, 2006 [Page 8]
Internet-Draft IPv6 MCast Scoped Addr April 2006
Author's Address
Ronald Pashby
Bowhead Information Technology Services
Phone: +1 540 653 6070
Email: ronald.pashby.ctr@navy.mil
Pashby Expires October 14, 2006 [Page 9]
Internet-Draft IPv6 MCast Scoped Addr April 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Pashby Expires October 14, 2006 [Page 10]
