draft-ietf-mboned-admin-ip-space-04.txt   draft-ietf-mboned-admin-ip-space-05.txt 
skipping to change at page 1, line 28 skipping to change at page 1, line 27
material or to cite them other than as ``work in progress.'' material or to cite them other than as ``work in progress.''
To learn the current status of any Internet-Draft, please check the To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast). ftp.isi.edu (US West Coast).
2. Abstract 2. Abstract
This document defines the ''administratively scoped IPv4 multicast This document defines the "administratively scoped IPv4 multicast
space'' to be the range 239.0.0.0 to 239.255.255.255. In addition, it space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it
describes a simple set of semantics for the implementation of describes a simple set of semantics for the implementation of
Administratively Scoped IP Multicast. Finally, it provides a mapping Administratively Scoped IP Multicast. Finally, it provides a mapping
between the IPv6 multicast address classes [RFC1884] and IPv4 between the IPv6 multicast address classes [RFC1884] and IPv4
multicast address classes. multicast address classes.
This memo is a product of the MBONE Deployment Working Group (MBONED) This memo is a product of the MBONE Deployment Working Group (MBONED)
in the Operations and Management Area of the Internet Engineering in the Operations and Management Area of the Internet Engineering
Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author. Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
3. Acknowledgments 3. Acknowledgments
skipping to change at page 6, line 28 skipping to change at page 6, line 28
assignments. A relative assignment is an integer offset from highest assignments. A relative assignment is an integer offset from highest
address in the scope and represents a 32-bit address (for IPv4). For address in the scope and represents a 32-bit address (for IPv4). For
example, in the Local Scope defined above, 239.255.255.0/24 is example, in the Local Scope defined above, 239.255.255.0/24 is
reserved for relative allocations. The de-facto relative assignment reserved for relative allocations. The de-facto relative assignment
"0", (i.e., 239.255.255.255 in the Local Scope) currently exists for "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for
SAP [SAP]. The next relative assignment, "1", corresponds to the SAP [SAP]. The next relative assignment, "1", corresponds to the
address 239.255.255.254 in the Local Scope. The rest of a scoped address 239.255.255.254 in the Local Scope. The rest of a scoped
region below the reserved /24 is available for dynamic assignment region below the reserved /24 is available for dynamic assignment
(presumably by an address allocation protocol). (presumably by an address allocation protocol).
In is important to note that a scope discovery protocol will have to In is important to note that a scope discovery protocol [MZAP] will
be developed to make practical use of scopes other that the Local have to be developed to make practical use of scopes other than the
Scope. In addition, since any use of any administratively scoped Local Scope. In addition, since any use of any administratively
region, including the Local Scope, requires dynamically assigned scoped region, including the Local Scope, requires dynamically
addressing, an Address Allocation Protocol (AAP) will need to be assigned addressing, an Address Allocation Protocol (AAP) will need
developed to make administrative scoping generally useful. to be developed to make administrative scoping generally useful.
10.1. Relative Assignment Guidelines 10.1. Relative Assignment Guidelines
Requests for relative assignments should be directed to the IANA. In Requests for relative assignments should be directed to the IANA. In
general, relative addresses will be used only for bootstrapping to general, relative addresses will be used only for bootstrapping to
dynamic address assignments from within the scope. As such, relative dynamic address assignments from within the scope. As such, relative
assignments should only be made to those services that cannot use a assignments should only be made to those services that cannot use a
dynamic address assignment protocol to find the address used by that dynamic address assignment protocol to find the address used by that
service within the desired scope, such as a dynamic address service within the desired scope, such as a dynamic address
assignment service itself. assignment service itself.
skipping to change at page 7, line 30 skipping to change at page 7, line 30
as an application feature and merely needs to be enabled (and as an application feature and merely needs to be enabled (and
appropriate cryptographic keys securely distributed). For many other appropriate cryptographic keys securely distributed). For many other
applications, the use of the IP Encapsulating Security Payload (ESP) applications, the use of the IP Encapsulating Security Payload (ESP)
[RFC-1825, RFC-1827] can provide IP-layer confidentiality though [RFC-1825, RFC-1827] can provide IP-layer confidentiality though
encryption. encryption.
Within the context of an administratively scoped IP multicast group, Within the context of an administratively scoped IP multicast group,
the use of manual key distribution might well be feasible. While the use of manual key distribution might well be feasible. While
dynamic key management for IP Security is a research area at the time dynamic key management for IP Security is a research area at the time
this note is written, it is expected that the IETF will be extending this note is written, it is expected that the IETF will be extending
the ISAKMP key management protocol [draft-ietf-ipsec-isakmp-*.txt, the ISAKMP key management protocol to support scalable multicast key
draft-ietf-ipsec-ipsec-doi-*.txt] to support scalable multicast key
distribution in the future. distribution in the future.
It is important to note that the "boundary router" described in this It is important to note that the "boundary router" described in this
note is not necessarily providing any kind of firewall capability. note is not necessarily providing any kind of firewall capability.
12. References 12. References
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP [ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP
Multicast", , presented at the 30th IETF, Toronto, Multicast", , presented at the 30th IETF, Toronto,
Canada, 25 July 1994. Canada, 25 July 1994.
[DVMRP] T. Pusateri, "Distance Vector Multicast Routing [DVMRP] T. Pusateri, "Distance Vector Multicast Routing
Protocol", draft-ietf-idmr-dvmrp-v3-03.txt, Protocol", draft-ietf-idmr-dvmrp-v3-05.txt,
September, 1996. October, 1997.
[MZAP] M. Handley, "Multicast-Scope Zone Announcement
Protocol (MZAP)", draft-ietf-mboned-mzap-00.txt,
December, 1997.
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast [PIMDM] Deering, S, et. al., "Protocol Independent Multicast
Version 2, Dense Mode Specification", Version 2, Dense Mode Specification",
draft-ietf-idmr-pim-dm-05.txt, April, 1997. draft-ietf-idmr-pim-dm-05.txt, May, 1997.
[PIMSM] Estrin, D, et. al., "Protocol Independent Multicast [PIMSM] Estrin, D, et. al., "Protocol Independent Multicast
Sparse Mode (PIM-SM): Protocol Specification", Sparse Mode (PIM-SM): Protocol Specification",
draft-ietf-idmr-pim-sm-specv2-00.txt, September draft-ietf-idmr-pim-sm-specv2-00.txt,
9,1997.
September,1997.
[RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October, [RFC1700] J. Reynolds, "ASSIGNED NUMBERS", RFC1700, October,
1994. 1994.
[RFC1884] R. Hinden. et. al., "IP Version 6 Addressing [RFC1884] R. Hinden. et. al., "IP Version 6 Addressing
Architecture", RFC1884, December 1995. Architecture", RFC1884, December 1995.
[SAP] Handley, Mark, "SAP: Session Announcement Protocol", [SAP] Handley, Mark, "SAP: Session Announcement Protocol",
draft-ietf-mmusic-sap-00.txt, November, 1996. draft-ietf-mmusic-sap-00.txt, November, 1996.
13. Author's Address 13. Author's Address
David Meyer David Meyer
Advanced Network Technology Center Cisco Systems
University of Oregon San Jose, CA
1225 Kincaid St. email: dmm@cisco.com
Eugene, OR 97403
phone: +1 541.346.1747
email: meyer@antc.uoregon.edu
 End of changes. 

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