One document matched: draft-ietf-ipngwg-uni-based-mcast-01.txt
Differences from draft-ietf-ipngwg-uni-based-mcast-00.txt
IPNGWG Working Group B. Haberman
Internet Draft Nortel Networks
draft-ietf-ipngwg-uni-based-mcast-01.txt D. Thaler
January 2001 Microsoft
Expires July 2001
Unicast-Prefix-based 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 specification defines an extension to the multicast addressing
architecture of the IP Version 6 protocol. The extension presented
in this document allows for unicast-prefix-based allocation of
multicast addresses.
1. Introduction
This document specifies an extension to the multicast portion of the
IPv6 addressing architecture [RFC 2373]. The current architecture
does not contain any built-in support for dynamic address
allocation. This proposal introduces encoded information in the
multicast address to allow for dynamic, network prefix-based
allocation of IPv6 multicast addresses, as well as allocation of
source-specific multicast addresses.
2. Multicast Address Format
Section 2.7.2 of RFC 2373 defines the following operational format
of IPv6 multicast addresses:
Haberman, Thaler 1
Internet Draft Unicast Prefix-based IPv6 Multicast August 2000
| 8 | 4 | 4 | 80 | 32 |
+--------+----+----+--------------------------------+------------+
|11111111|flgs|scop| reserved must be zero | group ID |
+--------+----+----+--------------------------------+------------+
This document introduces a new format that incorporates unicast
prefix information in the multicast address. The following
illustrates the new format:
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+--------+----------------+----------+
|11111111|flgs|scop|reserved| plen | network prefix | group ID |
+--------+----+----+--------+--------+----------------+----------+
+-+-+-+-+
flgs is a set of 4 flags: |0|0|P|T|
+-+-+-+-+
o P = 0 indicates a multicast address that is not assigned
based on the network prefix.
o P = 1 indicates a multicast address that is assigned
based on the network prefix.
o The setting of the T bit is defined in Section 2.7 of RFC
2373
The reserved field MUST be zero.
plen indicates the actual length of the network prefix portion of
the address when P = 1. This field is required in order to
determine the number of bits to include as part of the unicast
prefix.
network prefix identifies the network prefix of the unicast subnet
owning the multicast address. If P = 1, this field contains the
unicast network prefix defined in [RFC 2374] and assigned to the
domain owning, or allocating, the multicast address.
With the network prefix-based architecture and the current unicast
address architecture [RFC 2374], the network prefix portion of the
multicast address will be at most 64 bits.
The scope of the unicast-prefix based multicast address must not
exceed the scope of the unicast prefix embedded in the multicast
address.
3. Source-Specific Multicast Addresses
Haberman, Thaler 2
Internet Draft Unicast Prefix-based IPv6 Multicast August 2000
The network prefix-based IPv6 multicast address format supports
Source-specific multicast addresses, as defined by [IANA]. This is
accomplished by:
o Setting P = 1
o Setting plen = 0
o Setting network prefix = 0
4. Security Considerations
Using unicast network-prefix based multicast addresses can sometimes
aid in identifying the allocation domain of a given multicast
address, although no guarantee is provided.
Using source-specific multicast addresses can sometimes aid in the
prevention of denial-of-service attacks by arbitrary sources,
although no guarantee is provided.
5. IANA Considerations
Well-known, fixed-scope and variable-scope multicast addresses with
the prefix FF2x (unicast-prefix based, permanent) may be created and
used as follows.
Group IDs are defined and registered by the IANA. Such well-known
group IDs may be used to create unicast-prefix based multicast
addresses by any domain or network by embedding their local unicast
prefix. Hence, given an IANA-assigned group ID, and a unicast
network prefix, an application could derive and join that network's
group used for the well-known purpose associated with the group ID.
6. References
[RFC 2026] S. Bradner, "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
[RFC 2460] S. Deering and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC 2373] R. Hinden and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP14, March 1999.
[RFC 2374] R. Hinden, M. OĘDell, and S. Deering, "An IPv6
Aggregatable Global Unicast Address Format", RFC 2374,
Haberman, Thaler 3
Internet Draft Unicast Prefix-based IPv6 Multicast August 2000
July 1998.
[RFC 2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[RFC 2470] M. Crawford, T. Narten, and S. Thomas, "Transmission of
IPv6 Packets over Token Ring Networks", RFC 2470,
December 1998.
[RFC 2375] R. Hinden and S. Deering, "IPv6 Multicast Address
Assignments", RFC 2375, July 1998.
[RFC 2365] D. Meyer, "Administratively Scoped IP Multicast",
BCP 23, RFC 2365, July 1998.
[IANA] D. Cheriton, "Single-source IP Multicast Address Range",
http://www.isi.edu/in-notes/iana/assignments/single-
source-multicast, October 1998.
Haberman, Thaler 4
AuthorĘs Address
Brian Haberman
Nortel Networks
4309 Emperor Blvd.
Suite 200
Durham, NC 27703
1-919-992-4439
Email : haberman@nortelnetworks.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 48105-6399
1-425-703-8835
Email: dthaler@microsoft.com
Haberman, Thaler 5
| PAFTECH AB 2003-2026 | 2026-04-23 10:44:55 |