Internet Engineering Task Force C. Perkins INTERNET DRAFT B. Patel IBM Research 13 February 1996 Preference for Broadcast Datagram Support with Mobile IP draft-perkins-mobileip-bcastpref-00.txt Status of This Memo This document is a submission to the Mobile-IP Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mobile-ip@smallworks.com mailing list. Distribution of this memo is unlimited. 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). Abstract This document specifies a new extension to the Registration Request used by mobile nodes with the mobile-IP protocol. The new extension allows the mobile node to select the particular IP broadcasts which the home agent should forward to the mobile node when it attaches to the Internet at a care-of address not on its home network. Perkins, Patel Expires 13 August 1996 [Page i] Internet Draft Mobile-IP Broadcast Preference 13 February 1996 1. Introduction Mobile-IP [1] allows mobile nodes to move from one point of attachment within the Internet to another, and defines mechanisms by which a home agent on the mobile node's home network can send datagrams to the mobile node. Since the mobile node's IP address makes it seem to other routers as if the mobile node is on the same network as the home agent (i.e., as if the mobile node is on its "home network"), datagrams from other networks destined to the mobile node will be transmitted onto the mobile node's home network, where they can be received by the home agent and encapsulated for delivery to the mobile node's care-of address. The mobile node's care-of address can be an address assigned to one of the mobile node's network interfaces, or it can be an address advertised by a mobility agent near the current whereabouts of the mobile node. Such a mobility agent is called a foreign agent. Assuming that the mobile node is not currently attached to its home network, datagrams destined for the mobile node's home address will be sent to it by the home agent at its care-of address. The mobile node is unlikely to wish to receive all the broadcast packets which it would normally receive on its home network. For instance, when the mobile node is not attached to its home network, it would not have any use for handling ARP packets [2]. However, there are many cases when the mobile node would find certain IP broadcast datagrams useful. The mobile-IP specification specifies the relevant details about how the transmission of broadcast datagrams to the mobile node must occur. However, it is assumed to be a matter for the network administration in charge of the mobile node's home network to configure the mobile node's home agent so that the desired datagrams are transmitted from the home agent to the mobile node. This document specifies an extension to the mobile-IP Registration Request message to allow the mobile node to specify which broadcast datagrams it wishes to receive while it is away from its home network. The mobile node uses this extension during its registration process at its current point of attachment. 2. Broadcast Preference Extension The Broadcast Preference extension allows a mobile node to specify at the time it registers its current care-of address which IP broadcast datagrams it wants to receive from its home network (via its home agent). The Broadcast Preference extension may be included several times within a single registration request. Each preference Perkins, Patel Expires 13 August 1996 [Page 1] Internet Draft Mobile-IP Broadcast Preference 13 February 1996 selects a particular kind of broadcast that the mobile node wants to receive. If the mobile node wishes to receive several kinds of broadcast datagrams, it includes several preference extensions. Each Preference Extension specifies conditions on the protocol number and the port number, which must both be satisfied by a broadcast datagram before the home agent should forward the broadcast to the mobile node. DISCUSSION: What other constraints should be considered? 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |C|P|A|X| rsvd | Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 40 Length 6 C If the 'C' ('Clean') flag is set, the home agent is instructed to eliminate any retained specifications for broadcast datagrams which the mobile node had included in any previous Broadcast Preference extensions. P If the 'P' ('Permanent') flag is set, the home agent is instructed to keep the following broadcast datagrams specification active until the mobile node registers again using the 'C' flag. A If the 'A' ('Additional') flag is set, the home agent is instructed to include this preference for receiving broadcasts along with other preferences previously specified by the mobile node. X If the 'X' ('Exclude') flag is set, the home agent is instructed to exclude this preference for receiving broadcasts from other preferences previously specified by the mobile node. rsvd 0 Protocol Broadcasts selected by this Broadcast Preference extension must have the specified Protocol in the protocol field of the IP header of the IP broadcast Perkins, Patel Expires 13 August 1996 [Page 2] Internet Draft Mobile-IP Broadcast Preference 13 February 1996 datagram. If the Protocol field of the Broadcast Preference extension is zero, then no restriction is being placed on that field in the IP header. Port Broadcasts selected by this Broadcast Preference extension must have the specified Port in the appropriate field in the upper-level protocol header which follows the IP IP header of the IP broadcast datagram. If the Port field of the Broadcast Preference extension is zero, then no restriction is being placed on that field in the upper level protocol header. All extensions to the mobile-IP registration request have a type field and a length field, as shown above. If the Port field is nonzero, then the Protocol field must also be nonzero. Also, when the Port field is nonzero, the special value Protocol = 255 is taken to mean both the TCP and UDP protocols. This special value is reserved otherwise, and used in this way will make the common case more convenient where the same port number is used for TCP and for UDP for the same application. Note that the Port field is included for convenience, and technically represents a layering violation. If the mobile node wishes to clear ALL of its Preferences, it sends a Broadcast Preference Extension with the 'C' bit set, and both the Port and the Protocol fields set to all zero. 3. Home Agent Considerations If the home agent cannot satisfy the request, it MUST reject the Registration Request by issuing a Registration Reply using the newly defined status code: 144 Broadcast Preference Not Supported When a mobile node is attached to its home network, a home agent MUST not forward broadcasts to the mobile node. When a mobile node includes the 'P' flag in the Broadcast Preference extension to a registration request, the home agent MUST keep track of the requested Broadcast Preference(s) for the mobile node until the mobile node clears the information with a new Broadcast Preference extension containing the 'C' flag. In this way, the mobile node may be relieved of the requirement to send in the same list of Broadcast Preference extensions every time it registers at a new care-of address. Perkins, Patel Expires 13 August 1996 [Page 3] Internet Draft Mobile-IP Broadcast Preference 13 February 1996 Extensions with both the 'C' bit and the 'X' bit set are interpreted with a special meaning. When such a message is received by the home agent, the home agent begins sending ALL broadcast datagrams to the mobile node except the ones which are specified by the Protocol and Port fields. Subsequent extensions without the 'C' bit set may exclude further broadcasts by not including the 'C' bit. If the home agent does not implement the protocol specified in the Protocol field of the Broadcast Preference extension, it can still approve the mobile node's request as long as the mobile node did not specify the Port field also. When the Port field is zero, the home agent sends ALL broadcasts with the specified Protocol (or excludes ALL such broadcasts if the 'X' bit is set) to the mobile node. When there is a nonzero Port specified, and the home agent does not implement the requested Protocol, the home agent MUST reject the Registration Request with status code 144. 4. OPEN ISSUES - Should the Broadcast Preference Extension provide any means to request that non-IP broadcast packets be forwarded to the mobile node? - Should the home agent be able to report status on each Broadcast Preference Extension individually, instead of accepting Registration Request only if each Extension is acceptable? An alternative would be to have another Extension to Reply messages, enabling the home agent to tell the mobile node exactly which Broadcast Preference Extension was unacceptable to the home agent. Perkins, Patel Expires 13 August 1996 [Page 4] Internet Draft Mobile-IP Broadcast Preference 13 February 1996 References [1] IPv4 Mobility Support. ietf-draft-mobileip-protocol-15.txt - work in progress, February 1996. [2] David C. Plummer. An Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware. RFC 826, November 1982. Authors' Addresses Questions about this memo can also be directed to: Charles Perkins Room H3-D34 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-7350 Fax: +1-914-784-6205 E-mail: perk@watson.ibm.com Baiju Patel Room H3-D36 T. J. Watson Research Center IBM Corporation 30 Saw Mill River Rd. Hawthorne, NY 10532 Work: +1-914-784-6786 Fax: +1-914-784-6205 E-mail: baiju@watson.ibm.com Perkins, Patel Expires 13 August 1996 [Page 5]