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]