draft-ietf-mboned-ipv4-uni-based-mcast-00.txt   draft-ietf-mboned-ipv4-uni-based-mcast-01.txt 
Network Working Group Dave Thaler Network Working Group Dave Thaler
Internet-Draft Microsoft Internet-Draft Microsoft
Expires: December 2002 29 June 2002 Expires: July 2004 19 January 2004
Unicast-Prefix-based IPv4 Multicast Addresses Unicast-Prefix-based IPv4 Multicast Addresses
<draft-ietf-mboned-ipv4-uni-based-mcast-00.txt> <draft-ietf-mboned-ipv4-uni-based-mcast-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
in progress." in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
Draft Uni-Prefix-based IPv4 Multicast June 2002 Draft Uni-Prefix-based IPv4 Multicast January 2004
This specification defines an extension to the multicast This specification defines an extension to the multicast
addressing architecture of the IP Version 4 protocol. The addressing architecture of the IP Version 4 protocol. The
extension presented in this document allows for unicast-prefix- extension presented in this document allows for unicast-prefix-
based allocation of multicast addresses. By delegating multicast based allocation of multicast addresses. By delegating multicast
addresses at the same time as unicast prefixes, network operators addresses at the same time as unicast prefixes, network operators
will be able to identify their multicast addresses without needing will be able to identify their multicast addresses without needing
to run an inter-domain allocation protocol. to run an inter-domain allocation protocol.
1. Introduction 1. Introduction
skipping to change at page 3, line 5 skipping to change at page 3, line 5
More recently, a mechanism [V6UPBM] has been developed for IPv6 More recently, a mechanism [V6UPBM] has been developed for IPv6
which provides a multicast range to every IPv6 subnet, which is at which provides a multicast range to every IPv6 subnet, which is at
a much finer granularity than an AS. As a result, the latter a much finer granularity than an AS. As a result, the latter
three disadvantages above are avoided (and the first disadvantage three disadvantages above are avoided (and the first disadvantage
does not apply to IPv6 due to the extended size of the address does not apply to IPv6 due to the extended size of the address
space). space).
Two significant advantages of providing multicast space to every Two significant advantages of providing multicast space to every
Draft Uni-Prefix-based IPv4 Multicast June 2002 Draft Uni-Prefix-based IPv4 Multicast January 2004
subnet (rather than just to an entire AS) are that: subnet (rather than just to an entire AS) are that:
o multicast address allocation within the range need only be o multicast address allocation within the range need only be
coordinated within the subnet (e.g., via ZMAAP [ZMAAP]), and coordinated within the subnet, and hence can be done with
hence can be done with zero configuration. zero configuration.
o bidirectional shared tree routing protocols may easily locate o bidirectional shared tree routing protocols may easily locate
the direction to the root by doing a route lookup on a the direction to the root by doing a route lookup on a
unicast address derived from the multicast group address. unicast address derived from the multicast group address.
This draft specifies a mechanism similar to [V6UPBM], whereby a This draft specifies a mechanism similar to [V6UPBM], whereby a
range of IPv4 multicast address space is provided to most IPv4 range of IPv4 multicast address space is provided to most IPv4
subnets. A resulting advantage over GLOP is that the mechanisms subnets. A resulting advantage over GLOP is that the mechanisms
in IPv4 and IPv6 become more similar. in IPv4 and IPv6 become more similar.
2. Address Space 2. Address Space
IANA should assign a /8 for this Unicast-Based Multicast (UBM) (RFC-editor: replace TBD below with IANA-assigned value, and
mechanism (e.g., the 225/8 which was previously leased to MASC). delete this note.)
The remaining 24 bits will be used as follows:
A multicast address with the prefix TBD/8 indicates that the
address is a Unicast-Based Multicast (UBM) address. The
remaining 24 bits can be used as follows:
Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length | Bits: | 8 | Unicast Prefix Length | 24 - Unicast Prefix Length |
+-----+-----------------------+----------------------------+ +-----+-----------------------+----------------------------+
Value: | 225 | Unicast Prefix | Group ID | Value: | TBD | Unicast Prefix | Group ID |
+-----+-----------------------+----------------------------+ +-----+-----------------------+----------------------------+
For subnets with a /24 or shorter prefix, the unicast prefix of For subnets with a /24 or shorter prefix, the unicast prefix of
the subnet is appended to the common /8. Any remaining bits may the subnet is appended to the common /8. Any remaining bits may
be locally assigned by hosts within the link (e.g., using manual be locally assigned by hosts within the link (e.g., using manual
configuration, or ZMAAP). Individual subnets with a prefix length configuration). Individual subnets with a prefix length longer
longer than 24 do not receive any multicast address space from than 24 do not receive any multicast address space from this
this mechanism; in such cases, MADCAP may be used. mechanism; in such cases, MADCAP may be used.
Compared to GLOP, an AS will receive more address space via this Compared to GLOP, an AS will receive more address space via this
mechanism if it has more than a /16 for unicast space. An AS will mechanism if it has more than a /16 for unicast space. An AS will
receive less address space than it does from GLOP if it has less receive less address space than it does from GLOP if it has less
than a /16. than a /16.
The owner of a UBM address can be determined by taking the The owner of a UBM address can be determined by taking the
multicast address, shifting it left by 8 bits, and identifying the multicast address, shifting it left by 8 bits, and identifying the
owner of the address space covering the resulting unicast address. owner of the address space covering the resulting unicast address.
Draft Uni-Prefix-based IPv4 Multicast June 2002 Draft Uni-Prefix-based IPv4 Multicast January 2004
3. Security Considerations 3. IANA Considerations
IANA should assign a /8 in the IPv4 multicast address space for
this purpose.
4. Security Considerations
Since dynamic assignment does not cross domain boundaries, the Since dynamic assignment does not cross domain boundaries, the
same well known intra-domain security techniques can be applied as same well known intra-domain security techniques can be applied as
with GLOP. Furthermore, the approach described here may have the with GLOP. Furthermore, the approach described here may have the
effect of reduced exposure to denial of space attacks based on effect of reduced exposure to denial of space attacks based on
dynamic allocation, since the area of dynamic allocation is dynamic allocation, since the area of dynamic allocation is
reduced from an entire AS to only within individual subnets. reduced from an entire AS to only within individual subnets.
4. Author's Address 5. Author's Address
Dave Thaler Dave Thaler
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond, WA 98052-6399 Redmond, WA 98052-6399
Phone: +1 425 703 8835 Phone: +1 425 703 8835
EMail: dthaler@microsoft.com EMail: dthaler@microsoft.com
5. References 6. Informative References
[AS4B] [AS4B]
Vohra, Q., and E. Chen, "BGP support for four-octet AS number Vohra, Q. and E. Chen, "BGP support for four-octet AS number
space", draft-ietf-idr-as4bytes-05.txt, Work in progress, May space", draft-ietf-idr-as4bytes-07.txt, Work in progress,
2002. August 2003.
[GLOP] [GLOP]
Meyer, D., and P. Lothberg, "GLOP Addressing in 233/8", RFC Meyer, D. and P. Lothberg, "GLOP Addressing in 233/8", RFC
2770, February 2000. 2770, February 2000.
[MADCAP] [MADCAP]
Hanna, S, Patel, B., and M. Shah, "Multicast Address Dynamic Hanna, S, Patel, B. and M. Shah, "Multicast Address Dynamic
Client Allocation Protocol (MADCAP)", RFC 2730, December Client Allocation Protocol (MADCAP)", RFC 2730, December
1999. 1999.
[V6UPBM] [V6UPBM]
Haberman, B., and D. Thaler, "Unicast-Prefix-based IPv6 Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", draft-ietf-ipngwg-uni-based- Multicast Addresses", RFC 3306, August 2002.
mcast-03.txt, October 2001.
[ZMAAP]
Catrina, O., Thaler, D., Aboba, B., and E. Guttman, "Zeroconf
Multicast Address Allocation Protocol (ZMAAP)", draft-ietf-
zeroconf-zmaap-02.txt, October 2001.
Draft Uni-Prefix-based IPv4 Multicast June 2002 Draft Uni-Prefix-based IPv4 Multicast January 2004
6. Full Copyright Statement Copyright (C) The Internet Society 7. Full Copyright Statement Copyright (C) The Internet Society
(2002). All Rights Reserved. (2004). All Rights Reserved.
This document and translations of it may be copied and furnished This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise to others, and derivative works that comment on or otherwise
explain it or assist in its implmentation may be prepared, copied, explain it or assist in its implmentation may be prepared, copied,
published and distributed, in whole or in part, without published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed Internet Society or other Internet organizations, except as needed
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/