view Side-By-Side changes
IPNGWG Working Group B. Haberman Internet Draft Nortel Networksdraft-ietf-ipngwg-uni-based-mcast-01.txtdraft-ietf-ipngwg-uni-based-mcast-02.txt D. ThalerJanuaryJune 2001 Microsoft ExpiresJulyDecember 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. By delegating multicast addresses at the same time as unicast prefixes, network operators will be able to identify their multicast addresses without needing to run an inter-domain allocation protocol. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Introduction....................................................2 2. Terminology.....................................................2 3. Multicast Address Format........................................2 4. Source-Specific Multicast Addresses.............................3 5. Security Considerations.........................................3 6. References......................................................3 AuthorĘs Address...................................................5 Haberman, Thaler 1 Internet Draft Unicast Prefix-based IPv6 Multicast August 2000 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,networkunicast prefix-based allocation of IPv6 multicast addresses, as well as allocation of source-specific multicast addresses. 2. 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]. 3. 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. oTheIf P = 1, T MUST be set to 1, otherwise the setting of the T bit is defined in Section 2.7 of RFC23732373. The reserved field MUST be zero. Haberman, Thaler 2 Internet Draft Unicast Prefix-based IPv6 Multicast August 2000 plen indicates the actuallengthnumber of bits in the network prefixportion offield that identify theaddresssubnet 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 addressmust notMUST NOT exceed the scope of the unicast prefix embedded in the multicast address.3.The lifetime of a unicast prefix-based multicast addresses MUST be less than or equal to the Valid Lifetime field in the Prefix Information option, corresponding to the unicast prefix being used, contained in the Neighbor Discovery Router Advertisement message [RFC 2461]. 4. Source-Specific Multicast AddressesHaberman, Thaler 2 Internet Draft Unicast Prefix-based IPv6 Multicast August 2000Thenetworkunicast prefix-based IPv6 multicast address format supports Source-specific multicast addresses, as defined by[IANA]. This is accomplished by:[SSM ARCH]. To accomplish is, a node MUST: oSettingSet P =11. oSettingSet plen =00. oSettingSet network prefix =0 4.0. These settings indicate that the multicast address is being used in source-specific multicast transmission. The source address field in the IPv6 header identifies the owner of the multicast address. 5. 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 Haberman, Thaler 3 Internet Draft Unicast Prefix-based IPv6 Multicast August 2000 [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 2000July 1998. [RFC2464] M. Crawford, "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998. [RFC 2470] M. Crawford, T.2461] 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 ScopedT., Nordmark, E., Simpson, W., "Neighbor Discovery for IPMulticast", BCP 23,Version 6 (IPv6)", RFC2365, July2461, December 1998.[IANA] D. Cheriton, "Single-source IP[SSM ARCH] H. Holbrook and B. Cain, "Source-Specific MulticastAddress Range", http://www.isi.edu/in-notes/iana/assignments/single- source-multicast, October 1998.for IP", Work In Progress, March 2001. Haberman, Thaler 4 AuthorĘs Address Brian Haberman Nortel Networks 4309 Emperor Blvd. Suite 200 Durham, NC 27703 1-919-992-4439Email :haberman@nortelnetworks.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 48105-6399 1-425-703-8835Email:dthaler@microsoft.com Haberman, Thaler 5 ----