Note : Les descriptions sont présentées dans la langue officielle dans laquelle elles ont été soumises.
CA 02274050 1999-06-04
WO 98/26530 PCT/US97/22006
System, Device, and Method For Routing DHCP Packets
in a Public ~ Data Network
Background
1. Field of the Invention
a The invention relates generally to communication systems and,
more particularly, to routing DHCP packets in a public data network.
2. Discussion of Related Art
In today's information age, there is an increasing need for high
speed communications that provides access to on-line services for an
ever-increasing number of communications consumers. To that end,
communications networks and technologies are evolving to meet
current and future demands. Specifically) new networks are being
deployed which reach a larger number of end users, and protocols are
being developed to utilize the added bandwidth of these networks
efficiently.
One protocol that is used pervasively in modern communications
networks including "the Internet" is the Internet Protocol (IP). IP
provides "connectionless" service in that each unit of 1P information
(referred to as a datagram) is routed from its source to its
destination according to an IP address in the datagram without
reference to any pre-established physical or virtual connection
between the source and the destination. IP is also considered to be
an unreliable protocol, since it does not guarantee that all datagrams
will be delivered to their destinations and does not guarantee that
datagrams will be delivered in the order in which they were sent.
Although IP is connectionless and unreliable) it provides a
flexible platform over which other higher-layer protocols can be
carried. One such protocol is the Transmission Control Protocol
1
CA 02274050 1999-06-04
WO 98/26530 PCTIUS97/22006
(TCP), which provides connection-oriented reliable service over the
IP protocol. TCP is the most common protocol used with IP, and
together they are often referred to as TCP/IP.
Each device that will use IP services must have a unique IP
address. In many cases, a device will be pre-assigned an IP address.
However, in some cases, it is impractical or undesirable to pre-
assign IP addresses. For example, if a particular location has a large
number of devices that use IP services, but only a small number will
be using IP services simultaneously, it would be a waste of IP
addresses to pre-assign a unique IP address to each device. Instead,
it is preferable to assign IP addresses as needed from a pool of IP
addresses. Dynamic assignment of IP addresses simplifies client
configuration and conserves IP addresses by assigning addresses only
to actively connected clients.
ZS One protocol for dynamically assigning IP addresses is the
Dynamic Host Configuration Protocol (DHCP) which is described in the
Internet Engineering Task Force (IETF) RFC 1541. DHCP allows a
client that wishes to use IP services to obtain an IP address from a
server that maintains a pool of IP addresses. DHCP works generally
as follows. When the client needs an IP address, it broadcasts a
DHCP-Discover packet into the network. One or more servers receive
the DHCP-Discover packet and respond with a DHCP-Offer packet
including an IP address for the client. Since the client may receive
multiple offers, the client accepts one of the offers and broadcasts a
DHCP-Request packet indicating which DHCP-Offer was accepted. The
server which made the offer then broadcasts a DHCP-Ack packet to
the client containing configuration parameters for the client.
In typical local-area networks (LANs), the client and the server
are on the same LAN segment, so the broadcast messages are handled
locally by the client and the server. However, when the client
2
CA 02274050 1999-06-04
WO 98126530 PCT/US97/22006
accesses the server over a wide-area network (WAN)) such as a
hybrid fiber-opticlcoaxial cable (HFC) network, the broadcast
messages must be routed by one or more intermediate relay agents.
One problem caused by the routing function is that the
broadcast messages must be transmitted on all network segments
supported by the relay agent, since the relay agent cannot determine
a unique destination for each message. Furthermore, all devices on
the network receive the broadcast messages and must process them,
even if the processing is only to determine that the messages can be
ignored. Thus, the broadcasting of DHCP messages) and in particular
the broadcasting of DHCP responses from the server to the client,
waste network bandwidth and waste processing resources in non-
participating devices.
Thus, a need remains for an apparatus and method for
intelligently routing DHCP packets.
Brief Description of the Drawing
In the Drawing,
FIG. 1 shows an exemplary TCP/IP network as is known in the
art;
FIG. 2 is a flow diagram of a method for routing DHCP packets;
and
FIG. 3 shows a system for routing DHCP packets.
Detailed Description
As discussed above, the need remains for an apparatus and
method for intelligently routing DHCP packets. This invention routes
DHCP response packets to only the network segment on which the
initiating client is located. The relay agent is able to determine the
3
CA 02274050 1999-06-04
WO 98126530 PCTILTS97/22006
destination network segment by inserting a source identifier into the
DHCP packets sent by the client and receiving the source identifier
back from the server in DHCP packets sent by the server.
FIG. 1 shows an exemplary TCP/IP network 100 as is known in
the art. In this example, client devices access on-line services such
as the Internet and a DHCP server by means of a wide-area network
(WAN). Each client interfaces with the WAN by means of a modem
which provides physical layer connectivity to a Headend Unit.
Headend Unit typically supports a number of modems over a number of
physical modem connections. Headend Unit terminates the physical
modem connections and relays IP datagrams between the clients and
the on-line services. Thus, one of the functions of the Headend Units
is to act as the relay agent for DHCP packets.
Where the Headend Unit supports a number of physical modem
connections) any broadcast messages sent by an on-line service must
be transmitted by the Headend Unit over all physical modem
connections. As discussed above, this broadcast transmission is
wasteful of WAN network resources. Aiso as discussed above, this
broadcast transmission is wasteful of client processing resources.
This problem is solved by including a source identifier in DHCP
messages that is then used by the relay agent to identify the
destination physical modem connection. Although this information
could be added by the client itself) the client is considered to be an
untrusted device which could insert false information to cause
network problems or obtain unauthorized services. A preferred
embodiment has the relay agent itself insert the source identifier
into DHCP packets sent by the client. The relay agent is considered to
be secure since it is typically within the control of the service
provider as opposed to the client which is typically within the
control of the end user.
a
CA 02274050 1999-06-04
WO 98/26530 PCT/US97/22006
The relay agent can insert any information that is has available
for identifying the physical modem connection, including (but not
limited to) a client identifier) a modem identifier, and a circuit
identifier. The source identifier is returned by the server in any
DHCP packets it sends. The relay agent uses the source identifier to
route DHCP responses to the correct physical modem connection.
FIG. 2 is a flow diagram of a method for intelligently routing
DHCP packets in a network having a client connected to a server by
means of a relay agent. The method begins with the client sending a
DHCP request packet. Upon receipt of the packet by the relay agent,
the relay agent inserts a source identifier into the packet and
forwards the modified packet to the server. Upon receipt of the
modified packet, the server formats a DHCP response packet including
the source identifier received in the request packet and forwards the
1 S response packet to the relay agent. Upon receipt of the response
packet, the relay agent uses the source identifier to determine which
one of a number of communications links is the destination for the
response packet. The relay agent then sends the response packet on
the destination communications link to the client.
FIG. 3 shows a system 300 for routing DHCP packets in
accordance with the present invention. The system 300 includes a
client 310 which generates a DHCP request packet. The DHCP request
packet is sent to a relay agent 320 over an interface 340. The relay
agent 320 inserts information into the DHCP request packet to form a
modified DHCP request packet. The modified DHCP request packet is
sent to a server 330 over an interface 350. In one embodiment, the
information is a source identifier.
The server 330 receives the modified DHCP request packet over
interface 350 and extracts the information from the packet. !n one
embodiment, the server uses the information locally in selecting an
5
CA 02274050 1999-06-04
WO 98/26530 PCTIUS97/22006
-- IP address and other information for the client. In another
embodiment, the server inserts the information into a DHCP response
packet which it sends to the relay agent 320 over interface 360.
The relay agent 320 receives the DHCP response packet
containing the information and extracts the information from the
packet. In one embodiment, the relay agent 320 uses the information
to determine a destination for the DHCP response packet. The relay
agent 320 sends the DHCP response packet to the client over
interface 370.
The relay agent 320 includes a client interface 321 for
receiving DHCP request packets from the client. The relay agent 320
also includes a relay agent DHCP processor 322 which receives DHCP
request packets from the client interface 321 over interface 324 and
inserts information into the DHCP request packets to form modified
1 S DHCP request packets. The relay agent DHCP processor 322 outputs
the modified DHCP request packets to a server interface 323 over
interface 325. The server interface 323 sends the modified DHCP
request packets to the server 330.
The server interface 323 also receives DHCP response packets
from the server which include the information inserted by the server
330. In one embodiment, the information in the DHCP response packet
is equal to the information in the modified DHCP request packet. The
relay agent DHCP processor 322 uses the information, for example, to
determine a destination for the DHCP response packets. The client
interface 321 sends the DHCP response packets to the destination
client.
The server 330 processes DHCP request packets containing
information inserted by the relay agent 320. The server 330 includes
a receiver 331 for receiving the DHCP request packets, a server DHCP
processor 332 for extracting the information and for processing the
s
CA 02274050 1999-06-04
WO 98!26530 PCT/US97/22006
DHCP request packet, and a transmitter 333 for sending a DHCP
response packet including the information inserted by the relay agent.
The operation of having the relay agent insert information into
DHCP packets is useful for solving other problems that arise when
using DHCP over a public data network. As discussed above, the relay
agent can insert any information it has available. Thus, the relay
agent can insert other types of information in addition to or in place
of a source identifier. The server and relay agent can then use the
inserted information to provide security and other services.
One service that the relay agent can provide is protection
against IP address spoofing. IP address spoofing occurs when a client
uses an unauthorized IP address. By spoofing an improper IP address,
the client either denies service to a legitimate user or attempts to
bypass address-based access controls within the network. The relay
agent protects against this attack by maintaining a list of the IP
addresses assigned by the DHCP server and only forwarding those IP
addresses that have been assigned by the DHCP server.
Another service that the relay agent can provide is to allow
multiple clients connected to the same modem to be assigned IP
addresses from the same Logical IP Subnet (LiS). It is desirable for
all clients attached to the same modem to have IP addresses from the
same LIS so that the clients will be able to use the Address
Resolution Protocol (ARP) to determine the MAC addresses of other
clients on the same LAN, enabling direct client-to-client
communication. If the clients are permitted to be assigned IP
addresses from different LISs) then communication between two
clients on the same LAN would require routing of ail information over
the WAN to the relay agent and back over the WAN to the destination
client. The relay agent solves this problem by remembering the LIS
for the first IP address assigned to a client supported by a particular
CA 02274050 1999-06-04
WO 98126530 PCTIUS9~I22006
modem, and then inserting that LIS into DHCP packets sent by other
clients supported by the same modem.
Yet another service that the relay agent can provide is to allow
multiple LISs to be supported in the network. In general, a number of
non-contiguous LISs may be assigned for allocation by the network.
The issue then becomes which LIS to use for determining the contents
of the "giaddr" which is a field that is included in packets sent to
servers for identifying the relay agent from which the packet was
generated. Normally, relay agents set the "giaddr" to the IP address
of the interface on which the client request was received. However,
in networks such as the network depicted in FIG. 1 above, the
interfaces on the relay agent over which client packets are received
do not have IP addresses (they are termination points for physical
connections and generally are not IP addressable). Since each
physical modem link may support multiple modems, and each modem
may support multiple clients having multiple LISs) there may be a
number of LISs all of which are associated with a single physical
modem link. One embodiment has the relay agent use a single LIS for
all "giaddr" settings. However, this is an unnecessary
oversimplification which is avoided by having the relay agent select
from among the number of LISs, for example, using a round-robin
technique for selecting an LIS.
One service that the server can provide is protection against IP
address exhaustion. IP address exhaustion can occur when a single
client requests multiple IP addresses until the pool of IP addresses
is exhausted. Such an attack can be used to maliciously deny service
to other users. The server protects against this attack by
maintaining a list of the clients (using the source identifier
information inserted by the relay agent) and denying an IP address to
any client that requests more than one IP address.
8
CA 02274050 1999-06-04
WO 98126530 PCT/US97I22006
Another service that the server can provide is the configuration
of subnets. The original IP version 4 specification called for
"classed" addresses, whereby the subnet mask of an IP address could
be determined by the address itself. For some time now, however, an
explicit subnet mask has been required for IP interface configuration,
Y
in order to implement "classless" IP subnetwork number assignment.
The DHCP protocol provides no mechanism for the DHCP relay agent to
provide the subnet mask of the interface from which it received the
original request from the client. The DHCP server, however, must
know what the subnet mask is in order to select the proper range of
host addresses for assigning the client an IP address. In the absence
of subnet mask information, the DHCP server must either use a mask
that can be implied from other addressing information or, more
commonly, rely on pre-configured information of the subnet structure
from which to assign addresses. However, pre-configuration of
subnet information can be tedious considering the huge number of
devices that may have different subnet masks. To solve this problem,
the relay agent inserts the subnet mask of the interface from which
it received the original request from the client, and the server uses
the subnet mask to choose an IP address from the pool of IP
addresses within the specified subnet.
In order to support the above-mentioned services, the relay
agent must insert information such as an Agent Circuit ID) an Agent
Remote ID, and an Agent Subnet Mask into DHCP packets. However,
the format of DHCP packets as specified in IETF RFC 1541 does not
include fields for inserting such information. Therefore, extensions
in the form of numbered DHCP options are necessary to the DHCP
specification to allow such information to be inserted. Each DHCP
option includes a code field to identify the option, a length field, and
a data field for carrying the option information. Code field numbers
9
CA 02274050 1999-06-04
WO 98!26530 PCTIUS97/22006
are assigned by a standards body within the IETF. Code field numbers
for an Agent Circuit ID option, an Agent Remote ID option, and an
Agent Subnet Mask option have been assigned the decimal values 82,
83, and 84, respectively. The following is a description of an
embodiment of the extended DHCP options. Specific option field
formats (including the assigned code field numbers) will be presented
to the IETF for adoption as a standard, although proprietary formats
may be used, and the invention is not limited to or by the formats of
the option fields.
An Agent Circuit ID MAY be added by DHCP relay agents which
terminate switched or permanent circuits. It encodes a agent-local
identifier of the circuit from which a DHCP discoverlrequest packet
was received. It is intended for use by agents in relaying DHCP
responses back to the proper circuit. Possible uses of this field
include:
- Router interface number
- Switching Hub port number
- Remote Access Server port number
- Frame Relay DLCI
- ATM virtual circuit number
- Cable Data virtual circuit number
DHCP relay agents SHALL NOT modify any existing Agent Circuit
ID which may be in a received DHCP DiscoverlRequest packet; such an
option may have been added by a circuit bridge.
DHCP servers supporting this option MUST return the option
value unchanged in all Offer and Ack responses. Servers MAY use the
information for IP and other parameter assignment policies.
An Agent Remote ID MAY be added by DHCP relay agents which
terminate switched or permanent circuits and have mechanisms to
CA 02274050 1999-06-04
WO 98/26530 PCT/I1S97122006
- identify the remote host end of the circuit. The Remote ID field may
be used to encode, for instance:
- a "caller ID" telephone number for dial-up connection
- a "user name" prompted for by a Remote Access Server
- a remote caller ATM address
- a "modem ID" of a cable data modem
- the remote IP address of a point-to-point link
- a remote X.25 address for X.25 connections
The format of the Agent Remote ID will depend on the type of
circuit connected to the relay agent. The only requirement is that the
remote iD be administered as globally unique.
DHCP servers supporting this option MUST return the option
value unchanged in all Offer and Ack responses. DHCP servers MAY
use this option to select parameters specific to particular users,
hosts, or subscriber modems. The relay agent MAY use this field in
addition to or instead of the Agent Circuit ID field to select the
circuit on which to forward the DHCP Offer/Ack reply.
DHCP relay agents SHALL NOT modify any existing Agent Remote
ID field in received broadcasted DHCP Discover/Ack packets; such a
field may have been added by a circuit bridge.
An Agent Subnet Mask MAY be added by DHCP relay agents which
terminate multiple Logical IP Subnets. It provides the server with
the subnet mask for the LIS on which the relay agent received the
request. (The giaddr field provides the agent's IP host address on that
LIS.)
DHCP servers supporting this option MAY copy the Agent Subnet
mask value into the Client Subnet Mask parameter returned to the
host, and SHOULD have a configurable option to do so. DHCP Servers
SHOULD NOT return the Agent Subnet Mask option in the response.
11
CA 02274050 1999-06-04
WO 98/26530 PCTIUS97l22006
The Agent Subnet Mask option is intended to avoid the duplicate
configuration in both the relay agent and the server of the agent's
circuit subnet masks. A DHCP relay agent terminating a public data
switched network may have thousands of such configured circuits and
masks.
DHCP relay agents SHALL remove any incoming Agent Subnet
Mask options on received broadcasted DHCP Discover/Request packets
from clients. This option is only appropriately added by the relay
agent implementing a LIS interface.
Although in the preferred embodiment information is added by
the relay agent into DHCP packets, this specification is not intended
to limit the scope of the invention to the DHCP protocol. This
invention applies equally to any application in which the relay agent
adds information to cfientlserver packets for use by the relay agent,
other relay agent(s), servers, and/or clients.
The present invention may be embodied in other specific forms
without departing from the spirit or essential characteristics. The
described embodiments are to be considered in all respects only as
illustrative and not restrictive.
What is claimed is:
12
