Network Working Group Baiju V. Patel INTERNET DRAFT Intel Corporation Munil Shah Microsoft Corporation March 1997 Multicast address allocation extensions options Status of this memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 1. Abstract This document describes host configuration options that may be used by multicast address allocation protocols[3]. The options include critical information such as the IP address (unicast or multicast) of the multicast address allocation server(s) and a list of multicast scopes supported by respective servers. These options are designed to work with the extensions to DHCP [1] servers to support multicast address allocation (described in a separate draft), however, their use may not be limited to the above protocol. 2 Requirements Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are: o "MUST" This word or the adjective "REQUIRED" means that the item is an absolute requirement of this specification. Patel & Shah [Page 1] o "MUST NOT" This phrase means that the item is an absolute prohibition of this specification. o "SHOULD" This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course. o "SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label. o "MAY" This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item. 3 Terminology This document uses the following terms: o "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. o "BOOTP relay agent" A BOOTP relay agent or relay agent is an Internet host or router that passes DHCP messages between DHCP clients and DHCP servers. DHCP is designed to use the same relay agent behavior as specified in the BOOTP protocol specification. o "binding" A binding is a collection of configuration parameters, including at least an IP address, associated with or "bound to" a DHCP client. Bindings are managed by DHCP servers. Patel & Shah [Page 2] 4 Multicast Scope List Option Any client attempting to request a multicast address must know the address to which the server is listening to (this address may be unicast or multicast address), and a list of multicast scopes supported by the multicast address servers. This option is specifically designed to provide the multicast address server address and the scope list that can specifically be used by the protocol described in [3], however, its use is not limited to the protocol described in [3]. The format of the multicast scope list option is: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code (1 byte) | length (1byte)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TTL (1 byte) | N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Scope list +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where IP address is the address of the MDHCP server, to its best knowledge, reachable from the client via unicast or multicast. packets. The IP address may be a unicast or multicast address and the multicast address server must process the packets addressed to this address. The TTL value is the maximum time to leave value to be used for the packets sent to the IP address specified in this option. The scope list a list of N tuples, where each tuple is of the form, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | scope ID(4 byte) | Scope len (1 bute) | Scope description | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where scope ID is a unique identifier to designate the scope, scope description is a string describing the scope (need not be null terminated) and scope len is the length of scope description. Scope id is numeric representation of the scope and is used by the client to indicate a multicast scope to the server. In order to keep the usage of scope id consistent in the MBONE, this draft SHOULD be coordinated with [3] reserve a scope id for each multicast range in [3]. The scope id with its MSB(most significant bit) of 1 should be used for administratively scoped multicast address range. And the scope id with its MSB of 0 should be used to represent other pre-defined internet scopes. The code for this option is 107. Example: The multicast address allocation servers are listening to multicast address 239.1.1.1. The maximum allowed value for the TTL for this address is 16. There are two scopes supported by the multicast Patel & Shah [Page 3] address allocation server: 1) Inside the abcd.com, 2) world. Then this option will be used as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code (1 byte) | 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 239.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |16| Inside abcd.com | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |5 |world | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Instead of specifying a multicast address, the option may also specify a unicast address of the multicast address server. In above example, if the address of the multicast address server (see [3]) was 10.1.1.1, the option will be used as: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | code (1 byte) | 30 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 10.1.1.1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 16 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 |16|"Inside abcd.com" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |5|"world" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 References [1] Droms, R., "Dynamic Host Configuration Protocol", RFC1541, October 1993 [2] Alexander, S., and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 1533, Lachman Technology, Inc., Bucknell University, October 1993. [3] Meyer, D., ``Administratively scoped IP Multicast'' [4] Patel, B., and Shah, M., ``Multicast address allocation extensions to the Dynamic Host Configuration Protocol'' Patel & Shah [Page 4] 5 Author's Address Baiju V. Patel Intel Corp. 2111 NE 25th Ave. Hillsboro, OR 97124 Phone: 503 264 2422 EMail: baiju@ibeam.intel.com Munil Shah Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone:206 703 3924 Email:munils@microsoft.com This document will expire on Sept, 1997 Patel & Shah [Page 5]