One document matched: draft-itsumo-drcp-00.txt
Network Working Group Anthony McAuley
INTERNET-DRAFT Subir Das
Internet Engineering Task Force Telcordia Technologies
draft-itsumo-drcp-00.txt Shinichi Baba
Date: October 1999 Yasuro Shobatake
Expires: April 2000 Toshiba America Research Inc.
Dynamic Registration and Configuration Protocol (DRCP)
Status of this memo
This document is an Internet-Draft and is in full conformance with all
provisions of sections 10 of RFC 2026.
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".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts [DHC]. DHCP was,
however, designed for hosts on a fixed LAN, not for nodes roaming
among commercial wireless networks. Mobile IP [MIP], when combined
with some recent proposals [e.g., MIPA, MIPD, MIPN, HAW, CEL, TIA],
gives a powerful plug and play capability for roaming hosts, but the
additional functionality may not be needed or may be better provided
using some alternative mechanisms. This draft proposes an enhanced
version of DHCP for roaming users, called the Dynamic Registration
ITSUMO Group Expires April 2000 [Page 1]
Internet Draft DRCP October 1999
and Configuration Protocol (DRCP). DRCP borrows heavily from DHCP
and can revert to using DHCP protocol if only DHCP servers are
present in the network; but adds features critical to roaming users.
Most importantly, DRCP allows rapid configuration using several
modifications, including moving address consistency checking from the
critical path. Other new features allow: a) clients to know when to
get a new address independent of the access technology, b) efficient
use of scarce wireless bandwidth, c) nodes to be a relay agent or
server depending on a client's authorization, d) clients to be
routers, e) associating a priority with addresses, and f) identifying
users (e.g., by NAI [NAI]) rather than hardware address. DRCP also
adds options for QOS negotiation, service activation, and
authentication.
In some sense DRCP is to DHCP what DHCP is to BOOTP. DRCP directly
supports intra-domain registration and configuration, but must be
combined with other protocols to provide features such as continuous
connectivity (e.g., using Mobile IP or SIP [SIPM]), or inter-domain
authentication, authorization and accounting (e.g., using Radius
[RAD] or Diameter [DIA]).
Table of Contents
1 Introduction ...................................................3
1.1 Architecture ...............................................3
1.2 DHCP .......................................................4
1.3 Mobile IP ..................................................6
1.4 Requirements Terminology ...................................6
1.5 Overview ...................................................7
1.6 Terminology ................................................7
2 Protocol Summary ..............................................8
2.1 DRCP Overview - Components ................................8
2.2 DRCP Messages ............................................10
2.2.1 Local Subnet Messages ..............................10
2.2.2 Intradomain Messages ...............................12
2.3 Summary of Operation .....................................14
2.3.1 DRCP Client Operation ..............................14
2.3.2 DRCP Proxy Operation ...............................15
2.3.3 DRCP Server Operation ..............................15
2.4 DHCP Compatibility .......................................15
3 DRCP Format .................................................16
3.1 Common Header ...........................................17
3.2 Options .................................................17
4 Security Associations in DRCP ...............................18
ITSUMO Group Expires April 2000 [Page 2]
Internet Draft DRCP October 1999
5 Acknowledgements ............................................20
6 References ..................................................20
7 Authors' Address ............................................22
1. Introduction
Most future networks will use IP technology. To provide
heterogeneity and flexibility, devices will likely access this
IP-based network by directly sending IP packets. In such an
environment it is natural to consider using IP-based protocols for
user-network signaling, since it can be used across any wired or
wireless access network.
The functions needed to support users' roaming among IP-based
networks vary, depending on network, movement, and application
characteristics. Three common functions are Registration,
Configuration and Dynamic Address Binding. Registration allows
roaming users to rapidly and automatically register their presence
and their requirements with networks. Configuration allows networks
to automatically configure roaming users to the particular network
characteristics. Dynamic Binding allows corresponding nodes to
locate roaming users and to allow continuous communication as the
user moves among networks. This draft is concerned with the first
two functions; it has nothing to say about dynamic binding, except
that it should be an option independent of the registration and
configuration protocol.
1.1 Architecture
Figure 1 shows a high level functional architecture of a future IP-
based network, with a roaming node attaching to various wired or
wireless access networks. The access network may contain multiple
hubs or base stations with at least one subnet router with
connections to the rest of the network. We assume the mobile node
keeps the same IP address anywhere within an access network, since
micro mobility (e.g., among base stations) is handled at layer 2.
The mobile node must, however, get a new IP address every time it
moves to a new subnet (with some exceptions within a single domain if
a protocol such as HAWAII [HAW] or Cellular IP is used [CEL]). The
Regional Backbone connects all the subnet routers in a single
administrative domain and the global Internet interconnects all the
regional networks.
ITSUMO Group Expires April 2000 [Page 3]
Internet Draft DRCP October 1999
. <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> .
. . +-------------+ . .
. +---------------+ . | Public | . +---------------+ .
. | Registration | . | Verification| . | Registration | .
. | Agent | . | Agent | . | Agent | .
. +---------------+ . +-------------+ . +---------------+ .
. | . | . | .
. __|__ . __|__ . __|__ .
. / \ . / \ . / \ .
. / \ . / \ . / \ .
. / Regional\_________/ Global \_________/ Regional\ .
. \ Backbone/ . \ Internet/ . \ Backbone/ .
. ---\ /--- . \ / . ---\ /--- .
. | \_____/ | . \_____/ . | \_____/ | .
. | | . . | | .
. +---------+ +---------+ . . +---------+ +---------+ .
. | Subnet |...| Subnet | . . | Subnet |...| Subnet | .
. | Router | | Router | . . | Router | | Router | .
. +---------+ +---------+ . . +---------+ +---------+ .
. | | . . | | .
. __|__ __|__ . . __|__ __|__ .
. / \ / \ . . / \ / \ .
. / \ / \ . . / \ / \ .
. / Access \.../ Access \ . . / Access \.../ Access \ .
. \ Network / \ Network / . . \ Network / \ Network / .
. \ / \ / . . \ / \ / .
. \_____/ \_____/ . . \_____/ \_____/ .
. | | . . | | .
v v v v
+---------+ global macro
| Mobile | *******************> ************>
| Node | mobility mobility
+---------+
FIGURE 1: Functional Network Architecture for Supporting Universal
Mobile Operation
1.2 DHCP
The Dynamic Host Configuration Protocol (DHCP) provides a well tested
and widely deployed framework for passing configuration information
to hosts [DHC]. DHCP, however, was designed for hosts on a fixed
ITSUMO Group Expires April 2000 [Page 4]
Internet Draft DRCP October 1999
LAN, not for users roaming among commercial wireless networks. Table
1 shows that DHCP misses the requirements of some roaming users.
Table 1 Requirements for protocols supporting roaming users
------------------------------------------------------------
Requirements DHCP DRCP
----------------------------------------------------- ---- ----
Based on IP (work across all wired/wireless networks) Y Y
Requires no manual configuration when moving Y Y
Allows a single network server per domain Y Y
Allows any dynamic binding protocol (e.g., Mobile IP) Y Y
Allows nodes to go on and off without re-registration Y Y
Minimizes setup delay after a move N Y
Supports both hosts and routers N Y
Identifies users (e.g., NAI) not hosts or interfaces N Y
Minimizes signalling overhead across access network N Y
Requires AAA only when first active in a new domain N Y
Supports initial service activation N Y
Supports an inter-domain AAA protocol (e.g., Radius) N Y
Supports Quality of Service (QOS) negotiation N Y
Recent proposals provide some enhancements to DHCP for roaming users.
For example there are proposals to adding: authentication [DHCA],
LDAP database management [DHCL], and dynamic updating of DNS [DHCD].
Key problems remain, however, most importantly the long setup delay
after a move.
Rapid configuration (milliseconds rather than seconds) is necessary
for most roaming users. DHCP specification [DHC] says a client
SHOULD do an ARP check before an assigned address is used. This
checking results in long delay before communication can resume after
a move.
There are other reasons for which DHCP is not meeting the needs of
roaming users, including:
o No independent way to detect a move to a new subnet.
o Large message size (parts of which are not needed).
o Fixed role, requiring a DHCP node to be a server OR a relay agent.
o Forcing clients to be hosts.
o Not allowing the network to quickly change leased addresses
(before the lease runs out).
o Identifying hardware (e.g., by MAC address) rather than users
(e.g., by Network Access Identifier [NAI]).
The fixed role limits architectural choices. A wireless service
ITSUMO Group Expires April 2000 [Page 5]
Internet Draft DRCP October 1999
provider, for example, may want a subnet router (see Figure 1) to act
as a relay agent when a node first moves into its domain (forwarding
DHCP messages to a central server), but act as a server for
previously authorized nodes. Identifying users allows a user to use
any device and to specify the location of their Public Verification
Agent (see Figure 1).
DHCP also does not support some important options for commercial
wireless operation: such as QOS negotiation, and service activation.
Using QOS service specification users may request, for example, a
paging service that does not require nodes to be active as they move
in the doamin. In particular, QoS messages help the network to know
the requirements from the client side as well as client to know the
capabilities of the network. The network, for example, may use the
QoS service negotiation to set the policing mechanism.
1.3 Mobile IP
Mobile IP [MIP] is a simple and scalable solution to manage device
mobility throughout the global Internet. The Mobile IP Foreign Agent
supports host registration and configuration and the Home Agent
provides continuous connectivity by redirecting messages to the
roaming users' latest location. When combined with recent
enhancements, Mobile IP is the basis for a comprehensive roaming
solution. For example, there are proposals for Mobile IP
authentication, authorization and accounting [MIPA, TIA, MIPD], use
of Network Access Identifier [MIPN], and optimizations such as Hawaii
[HAW], and Cellular IP [CEL]. Although these proposal make large
improvements, they do not alter the fact that the Mobile IP service
has a large cost. Also using Foreign Agent adds additional
complexity to the network which may already be using DHCP.
Mobile IP provides networks transparency above the IP layer.
Although this transparency has a cost (e.g., triangular routing),
Mobile IP is ideal for many applications (particularly TCP
applications such as telnet or ftp). In many cases, however, this
transparency is not needed (e.g., for web browsing) or is better
provided by alternative mobility mechanism (viz., SIP for real-time
applications). Thus, while Mobile IP should be part of an overall
mobility solution, it is best used selectively and in pop-up mode
(i.e., using DHCP/DRCP to obtain addresses) instead of using a
Foreign Agent.
1.4 Requirements Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
ITSUMO Group Expires April 2000 [Page 6]
Internet Draft DRCP October 1999
"SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as decribied in RFC 2119 [REQ].
1.5 Overview
This draft proposes an enhanced version of DHCP for roaming users,
called the Dynamic Registration and Configuration Protocol (DRCP).
DRCP adds many new features including rapid client configuration and
efficient use of wireless bandwidth. Section 2 describes DRCP
operations while Section 3 presents the DRCP format. Finally,
security associations are discussed in Section 4.
1.6 Terminology
This document uses the following terms:
o AAA
Authentication, authorization and accounting
o "BOOTP"
The Bootstrap Protocol (BOOTP) [BOO1, BOO2].
o "DHCP"
The Dynamic Host Configuration Protocol (DHCP) used to configure
Internet hosts.
o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain
configuration parameters such as a network address.
o "DHCP relay agent"
A relay agent is an Internet host that passes DHCP messages
between DHCP clients and DHCP servers.
o "DHCP server"
A DHCP server is an Internet node that returns configuration
parameters to DHCP clients.
o "DRCP"
The Dynamic Registration and Configuration Protocol (DRCP) used to
configure nodes.
o "DRCP client"
A DRCP client is an Internet node (host or router) using DRCP to
register with the network and obtain configuration parameters such
ITSUMO Group Expires April 2000 [Page 7]
Internet Draft DRCP October 1999
as a network address.
o "DRCP proxy"
A DRCP-proxy is an Internet node that lies on the same subnet as
the client and can either act as a relay agent or a
virtual-server. It can forward DRCP messages between the
DRCP-client and a DRCP server or can pass configuration parameters
such as a network address directly to a DRCP client (from a pool
of addresses it got from a DRCP server).
o "DRCP server"
A DRCP server is an Internet node that owns a pool of IP
addresses. The server can lease addresses from this pool to other
DRCP nodes in its domain. Each domain running DRCP must have at
least one server, though there could be more in larger domains.
It performs verification of roaming nodes from other domains.
o "Virtual Server"
A DRCP-proxy is called a virtual server when it acts as a server
instead of a relay agent.
o "NAI"
Network Access Identifier of the form user@domain [NAI].
o "Public Verification Agent"
A Public Verification Agent (PVA) is an Internet node that
vouches for DRCP clients to DRCP servers. A client may have one
or multiple PVAs to support interdomain roaming.
o "Registration Agent"
A Registration Agent (RA) is an Internet node with a DRCP server
that provides a centralized service to DRCP proxies along with AAA
functionality.
2. Protocol Summary
The Dynamic Registration and Configuration Protocol (DRCP) uses many
of the features found in DHCP. We require a new protocol, however,
because DRCP's extended goals requires major enhancements to DHCP.
For example, DRCP supports users roaming among commercial service
providers.
2.1 DRCP Overview - Components
The Dynamic Registration and Configuration Protocol (DRCP) is based
on a client-proxy-server model. Figure 2 shows how the client,
ITSUMO Group Expires April 2000 [Page 8]
Internet Draft DRCP October 1999
proxy, and server could map onto the network architecture shown in
Figure 1.
DRCP-Clients DRCP-proxies DRCP-server
+-------------+ +---------------+ +--------------------+
| Mobile Node |<----->| Subnet Router |<----->| Registration Agent |
+-------------+ | +---------------+ | +--------------------+
: | |
: | |
+-------------+ | . |
| Mobile Node |<--- . |
+-------------+ . |
|
|
+-------------+ +---------------+ |
| Mobile Node |<----->| Subnet Router |<---
+-------------+ | +---------------+
: |
: |
+-------------+ |
| Mobile Node |<---
+-------------+
FIGURE 2 DRCP Client-Proxy-Server model
The DRCP client-proxy-server model is similar to the DHCP model of
client-relay-server. There are, however, differences that are
described below.
The DRCP-server is typically run at a single logical node called the
Registration Agent. The server is the only DRCP entity that owns a
pool of addresses. The server can lease addresses from this pool to
other DRCP nodes (DRCP-proxies and DRCP-clients) within its domain.
Each domain must have at least one server, though there could be
multiple servers in larger domains. While its central function is to
manage its address pool and hand out other configuration parameters
(like a DHCP server), the DRCP server may also interwork with AAA
protocol such as DIAMETER [DIA] to do the inter-domain AAA functions.
Figure 2 shows a single DRCP-proxy running on the subnet router at
each subnet. Although the proxy can be run on any node, not
necessarily a router, each subnet must have at least one DRCP proxy
or DRCP-server in order to support DRCP-clients on that subnet. The
proxies have a dual role. When a DRCP-client first moves into a new
domain, the proxy acts as a relay and forwards DRCP signaling packets
between the client and the central server. When the client has
ITSUMO Group Expires April 2000 [Page 9]
Internet Draft DRCP October 1999
registered and is moving among subnets in the same domain, the proxy
acts as a virtual server; so client's re-registration does not
involve the central server.
A DRCP-client is similar to a DHCP-client, except that it can lie on
a host or a router. A client can autoconfigure any interface that is
attached to a network that has a node with a DRCP-proxy or DRCP-
server.
2.2 DRCP Messages
DRCP is designed to be a superset of DHCP, like DHCP is a superset of
BOOTP. A DRCP implementation must support all DHCP messages defined
in the specification [DHC]. In addition, DRCP also defines its own
messages and have the same basic semantics as those used in DHCP.
For example, the DHCPOFFER [DHC] has the same basic functions (and
name) as DRCP_OFFER. New messages are needed in order to minimize
message size and also because their syntax is very different (see
Section 3). Section 2.4 discusses the interworking between DHCP and
DRCP.
Like DHCP, DRCP uses UDP as its transport protocol. There are two
types of DRCP signaling messages running on two different UDP ports:
a) All local subnet messages, between a client and a proxy or server
on the same subnet, are sent to the 'DRCP_CLIENT_PORT' port (number
To Be Determined (TBD)) and b) All intra-domain messages, between a
proxy and a server within a single domain, are sent to the
'DRCP_SERVER_PORT' port (number TBD).
2.2.1 Local Subnet Messages
Figure 3 shows a general architecture for DRCP operation on a local
subnet. In general a subnet requires only one proxy (as shown in
Figure 2); however, we show the more general with redundant proxies
and possibly DRCP servers.
ITSUMO Group Expires April 2000 [Page 10]
Internet Draft DRCP October 1999
+--------------+ +--------------+ +--------------+
| DRCP | | DRCP | ... | DRCP |
| Proxy/Server | | Proxy/Server | | Proxy/Server |
+--------------+ +--------------+ +--------------+
| | |
____|__________________|______________________|____
/ \
/ \
/ Local \
\ Subnet /
\ /
\___________________________________________________/
| | |
| | |
+---------+ +---------+ +---------+
| DRCP | | DRCP | ... | DRCP |
| Client | | Client | | Client |
+---------+ +---------+ +---------+
FIGURE 3 DRCP Node configuration on a Local Subnet
There are five messages from DRCP client:
o DRCP_DISCOVER:
Registration message sent by a DRCP-client on its local subnet
to request a new address and other configuration parameters. While
a DHCPDISCOVER message must be broadcast [DHC], a DRCP_DISCOVER
message may be broadcast or unicast depending whether the client
knows the address of a DRCP Proxy or Server (e.g., from a
DRCP_ADVERTISEMENT].
o DRCP_REQUEST:
Registration message sent by a DRCP-client on its local subnet
to request extending the lease on an address.
o DRCP_INFORM:
Registration message sent by a DRCP-client on its local subnet
to request new configuration parameters. This could be used,
for example, if the client already has an externally configured
network address.
o DRCP_DECLINE:
Registration message sent by a DRCP-client on its local subnet
to request a different address, either because the one assigned is
not acceptable (e.g., it is already in use by another client) or
because the client has moved to a new subnet.
ITSUMO Group Expires April 2000 [Page 11]
Internet Draft DRCP October 1999
o DRCP_RELEASE:
De-registration message sent by a DRCP-client on its local subnet
to relinquish a network address and cancel remaining lease.
These messages have the same basic semantics (though extended and
with different syntax) as the five used in DHCP [DHC], so we use the
same naming convention (e.g., DHCPDISCOVER is the equivalent of
DRCP_DISCOVER).
There are three messages from a DRCP proxy/server to a client on the
local subnet:
o DRCP_OFFER:
Configuration message sent back to client on the same subnet where
the DRCP proxy/server node received a DRCP_DISCOVER message.
o DRCP_ACK:
Configuration message broadcast by a Proxy/Server on its local
subnet in response to a DRCP_REQUEST.
o DRCP_ADVERTISEMENT:
Proxy/Server tells the network what addresses are available to use.
Can be broadcast (periodically) or unicast in response to a client
using an incorrect address, (e.g., client has moved to new subnet).
This message is a superset of the DHCPNAK message.
The first two are semantically similar to those use in DHCP (though
extended and with different syntax), so we use the same naming
convention. The DRCP_ADVERTISEMENT however has a new name (from
DHCPNAK) since its basic function is changed significantly.
2.2.2 Intradomain Messages
Figure 4 shows a general architecture for DRCP operation inside
a domain, In general a domain requires only one server (as shown in
Figure 2); however, we show the more general case that allows
redundancy. The addresses of the servers and proxy may be
preconfigured or may be discovered. One method, for example, would be
to use a well-known IP multicast group(s), which servers and
proxies could join independently.
ITSUMO Group Expires April 2000 [Page 12]
Internet Draft DRCP October 1999
+---------+ +---------+ +---------+
| DRCP | | DRCP | ... | DRCP |
| Server | | Server | | Server |
+---------+ +---------+ +---------+
| | |
____|__________________|______________________|____
/ \
/ \
/ Regional \
\ Backbone /
\ /
\___________________________________________________/
| | |
| | |
+---------+ +---------+ +---------+
| DRCP | | DRCP | ... | DRCP |
| Proxy | | Proxy | | Proxy |
+---------+ +---------+ +---------+
FIGURE 4 DRCP Node configuration within a single domain
There are two types of messages from a DRCP Proxy to a DRCP server
(or servers). The first type of messages are from the client being
forwarded to the server described in Section 2.2.1 (where the proxy
acts as a relay agent). The second class of messages are directly
from a proxy to a server (or servers) within its domain. Currently
only two messages of the second type are defined:
o DRCP_POOL_REQUEST
Proxy requests a range of addresses for its subnet, so it can
act as a virtual server.
o DRCP_STATUS_REQUEST
Request for a new DRCP_STATUS_UPDATE.
There are also two types of messages from a DRCP server to a DRCP
proxy (or proxies). The first type of messages are to a client that
should be forwarded by a proxy described in Section 2.2.1 (where the
proxy acts as a relay agent). The other messages are directly from a
server to a proxy (or proxies) within its domain. Currently only two
messages of the second type are defined:
o DRCP_POOL_RESPONSE
Response to a DRCP_POOL_RESPONSE.
ITSUMO Group Expires April 2000 [Page 13]
Internet Draft DRCP October 1999
o DRCP_STATUS_UPDATE
Status message giving information about users who have access to
the network.
The exact mechanisms used to send these intradomain messages are
still being researched. Clearly, however, the distribution of
information from server to proxies should be done efficiently
(possibly using IP multicast).
2.3 Summary of Operation
A DRCP client or proxy is initially assumed only to know which of its
interfaces is running as a DRCP-client or DRCP-proxy and
corresponding security associations. If there are multiple
interfaces, each interface may be configured in a different way. An
interface may be configured to run with a locally stored address or
as a DHCP-client. After boot-up, however, any interface configured
as a DRCP client or proxy listens to messages on DRCP_CLIENT_PORT.
During any message exchange the two sides may insert authentication
tokens (authentication token may be an option in options field [see
section 3.2]). If the required token does not match, the message
MUST be rejected.
2.3.1 DRCP Client Operation
A client first broadcasts a DRCP_DISCOVER message (similar to a DHCP
DISCOVER message) to the DRCP_CLIENT_PORT. If it gets no response
after DRCP_RETX_TIMEOUT, then it resends the DRCP_DISCOVER message.
This process repeats for up to DRCP_RETX_MAX retransmissions. If the
client receives a DRCP_ADVERTISEMENT message, then it will change to
a unicast state, so the next DRCP_DISCOVER message will be unicast to
the source address of the DRCP_ADVERTISEMENT. If the client receives
a DRCP_OFFER message, then it can immediately configure its interface
with that address. There is no requirement to do ARP checking before
using the address (as in DHCP).
After getting an address the client must periodically send out
DRCP_REQUEST messages to renew the lease. These message are
retransmitted until acknowledged by a DHCP_ACK message. If the
client detects a move to a new subnet (e.g., through receiving a
DRCP_ADVERTISEMENT message), then the client must send out a new
DRCP_DISCOVER message. If the DRCP_OFFER message indicated that the
client could keep the same address in the new subnet in the same
domain (e.g., using a mechanism such as HAWAII [HAW]), then it will
send a DRCP_REQUEST instead of a DRCP_DISCOVER.
ITSUMO Group Expires April 2000 [Page 14]
Internet Draft DRCP October 1999
2.3.2 DRCP Proxy Operation
A proxy is also initially assumed only to know which of its
interfaces is running as a DRCP-proxy and security associations, if
there are any. It broadcasts a DRCP_ADVERTISEMENT message to
DRCP_CLIENT_PORT to all DRCP proxy configured interfaces once per
DRCP_ADVERT_TIME. The proxy also listens for DRCP messages on either
the DRCP_CLIENT_PORT or the DRCP_SERVER_PORT.
If it hears any message from a DRCP client (on the DRCP_CLIENT_PORT),
then it will respond by either forwarding the message to a server (on
the DRCP_SERVER_PORT) or responding locally (on the
DRCP_CLIENT_PORT). If it hears any DRCP message from the server (on
the DRCP_SERVER_PORT) intended for a local client, it will forward
this message (on the DRCP_CLIENT_PORT).
If the proxy hears an DRCP_STATUS_UPDATE message (from a DRCP-server)
on the DRCP_SERVER_PORT, then it updates its local cache about what
clients have successfully registered with the server. If the proxy
hears from a client that thinks it is registered with a domain
server, but it does not have the information in its cache, then the
proxy can send a DRCP_STATUS_REQUEST message on the DRCP_SERVER_PORT.
If the proxy has no addresses (e.g., when first booted), runs out of
addresses, or the leases on the addresses it has are getting close to
expiring, then it can send a DRCP_POOL_REQUEST message to the
server(s) on the DRCP_SERVER_PORT. If it receives a
DRCP_POOL_RESPONSE message on the DRCP_SERVER_PORT, then it can
update its address pool.
2.3.3 DRCP Server Operation
The DRCP server is assumed to be configured with a pool of addresses.
It can either allocate these addresses directly to clients that
register or can give a range of addresses to proxies (that the
proxies can give to interfaces directly connected to subnets to which
it has a direct link).
2.4 DHCP Compatibility
DRCP is to DHCP what DHCP is to BOOTP [BOO1, BOO2, BODH]. Just as
DHCP allows interoperability of existing BOOTP clients with DHCP
servers, DRCP allows interoperability of DRCP clients with existing
DHCP servers (see Figure 3a). DHCP clients can also inter-operate
ITSUMO Group Expires April 2000 [Page 15]
Internet Draft DRCP October 1999
with DRCP servers (see Figure 3b), though policy may not allow a DHCP
client's access. In this case DRCP Servers/Proxy runs DHCP server
functionality as well.
+--------------+ +--------------+
| DHCP | | DRCP |
| Server/Relay | | Server/Proxy |
+--------------+ +--------------+
^ ^
__|__ __|__
/ \ / \
/ \ / \
/ Access \ / Access \
\ Network / \ Network /
\ / \ /
\_____/ \_____/
| |
v v
+---------+ +---------+
| DRCP | | DHCP |
| Client | | Client |
+---------+ +---------+
a) DRCP Client in DHCP Network. b) DHCP Client in DRCP Network.
FIGURE 5 DRCP-DHCP Interworking
The DRCP client may initially send out a DRCP_DISCOVER message that
can be understood only by a DRCP proxy/server. If after some time,
the node hears no DRCP messages on the subnet, then it can send DHCP
dicovery messages as well.
3. DRCP Format
All DRCP messages are sent in UDP/IP packets to a special DRCP port.
All messages are 32-bit aligned and have the general format shown
below (size shown in braces):
+---------------------------------------------------------------+
| Common Header (12) |
+---------------------------------------------------------------+
| Options (variable) |
+---------------------------------------------------------------+
FIGURE 6 DRCP Format
ITSUMO Group Expires April 2000 [Page 16]
Internet Draft DRCP October 1999
3.1 Common Header
The first part of all DRCP messages is the Common Header. Currently
it has the format shown below:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| op (1) | Flags(1) | Length(2) |
+---------------+---------------+---------------+---------------+
| id (8) | |
+---------------------------------------------------------------+
FIGURE 7 Common Header Format
The meaning (and size in bytes) of the fields in the common header
are:
Op 1 Message op code. For example, it is a DRCP_DISCOVER
message (the specific codes are TBD).
Flags 1 Flags to represent type of message.
Length 1 Length of of the message including all headers in 32-bit
words. Since all messages have a 3 word (12 byte) header
the minimum value is 3.
id 8 A unique id given to DRCP node by a Proxy or Server.
It SHOULD be unique within a domain. A value of 0 indicates
a NULL value (e.g., in a DRCP_DISCOVER message).
3.2 Options
All information, other than what is in the common header, must be
included as options. Some messages require certain options. For
example, an DRCP_OFFER must include an "IP Address Allocation"
option. Some messages may require at least an option of a certain
type, but not necessarily a specific option. For example, a
DRCP_DISCOVER message may require either an NAI or some equivalent
identifier. All options have a common 4 byte header shown below:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(1) | Type (2) | TBD(1) |
+---------------+---------------+---------------+---------------+
| .... |
FIGURE 8 Option Header
ITSUMO Group Expires April 2000 [Page 17]
Internet Draft DRCP October 1999
The meaning of the fields in the option header are:elds in the option
header are:
Length 1 Length of the option including this option headers in
32-bit words.
Type 2 Option type, such as IP address allocation (the specific
codes are TBD).
The figure below shows an example of the NAI option:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length(1) | Type (2) | TBD(1) |
+---------------+---------------+---------------+---------------+
| |
| |
NAI(128)
| |
+---------------------------------------------------------------+
FIGURE 9 NAI Option
The meaaning of the fields in the NAI option body are:
NAI 128 Network Access Identifier of the form user@domain
[NAI].
4. Security Association in DRCP
DRCP defines a set of messages that enable roaming users to rapidly
and automatically register to a new network with their requirements
and also allows networks to automatically configure roaming users.
Mobile nodes as well as DRCP proxies or Servers exchange several
messages for registration and configuration. Unlike conventional
cellular/ telephone networks where these types of messages are sent
over a secured signaling network, DRCP messages traverse through the
public IP network. Therefore, it is necessary to protect the data in
order to prevent security attacks on the mobile user as well as on
the visiting network [MIPS]. Figure 10 below describes different
security associations that are necessary for secured registration and
configuration.
ITSUMO Group Expires April 2000 [Page 18]
Internet Draft DRCP October 1999
|<--Visited Domain--> |<-- Home Domain -->
Client Proxy RA/Server PVA RA/Server Proxy Client
| | | | | | |
|<--------|---SA4---|-------->| | | |
| | |<--SA2-->| | | |
| | | |--|--| | | |
| | | | | | | | |
| | | | | | | | |
| |<--SA6-->| | | | | | |
| | | |--|--| | | |
|<--SA5-->| | Internet | | |
| | | | | |
| | |<-------SA1-------->| | |
|<----------------SA3------------------->| | |
|
FIGURE 10 Security Associations (SAs)
SA1 - between the Registration Agent (RA) or DRCP-server in the
visited domain and the Registration Agent in the home domain.
SA2 - between Registration Agent of the visited domain and Public
Verification Agent (PVA).
SA3 - between DRCP-Client and Registration Agent in home domain.
SA4 - between DRCP-client and Public Verification Agent.
SA5 - between DRCP-client and DRCP-proxy in the visited domain.
SA6 - between DRCP-client and DRCP-proxy in the visited domain.
SA1, SA2, SA3 and SA4 may not be required always. If the
Registration Agent of the visited domain determines that it will
contact the home domain's Registration Agent for verification it
requires SA1 and SA3. On the other hand if it contacts Public
Verification Agent it requires SA2 and SA4.
We assume that RAs and PVAs are capable of handling the AAA protocol.
In that case the visited domain may have a Service Level Agreement
with the home RA or nearest PVA. So it is expected that a secure
tunnel, e.g., IPsec will exist between two RAs or from RA to PVA. If
ITSUMO Group Expires April 2000 [Page 19]
Internet Draft DRCP October 1999
there exists multiple RAs in a single domain it may not be practical
to have security associations with every RA. There are still many
issues which need further discussions and research.
5. Acknowledgments
The authors wish to acknowledge the contributions of other members of
the ITSUMO (Internet Technologies Supporting Universal Mobile
Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta,
D. Famolari, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff)
and Toshiba America Research Incorporated (T. Kodama).
Some of the initial ideas of DRCP came out of a project on complete
autoconfiguration within a domain, funded by the U. S. Army
Research Laboratory (ARL) under the Advanced Telecommunications and
Information Distribution Research Program (ATIRP) Consortium.
6. References
[BOO] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951,
Stanford and SUN Microsystems, September 1985.
[BOO2] Wimer, W., "Clarifications and Extensions for the Bootstrap
Protocol", RFC 1542, Carnegie Mellon University, October 1993.
[BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534,
Bucknell University, October 1993.
[CEL] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet
draft, draft-valko-cellularip-00.txt, November 1998. Work in
progress.
[DHC] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for
Comments 2131, Mar 1997.
[DHCA] R. Droms, "Authentication for DHCP Messages", <draft-ietf-dhc-
authentication-11.txt>, June 1999.
[DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS,"
<draft-ietf-dhc-dhcp-dns-10.txt>, June 1999, Work in progress.
[DHCL] A. Bennett, B. Volz, A. Westerinen, " DHCP Schema for LDAP,"
<draft-ietf-dhc-schema-00.txt>, June 1999, Work in progress.
ITSUMO Group Expires April 2000 [Page 20]
Internet Draft DRCP October 1999
[DIA] P. Calhoun and A. Rubens, ``DIAMETER Base Protocol,'' Internet
draft, Work in Progress, Nov 1998.
[HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro-
mobility support using HAWAII",
<draft-ramjee-micro-mobility-hawaii-00.txt>, June 1999,
Work in progress.
[MIP] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 1996.
[MIP6] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet
Draft, Work in Progress, Nov 1998.
[MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication,
Authorization, and Accounting Requirements,"
<draft-ietf-mobileip-aaa-reqs-00.txt>, October 1999.
Work in progress.
[MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos,
"Requirements on Mobile IP from a Cellular Perspective,"
<draft-ietf-mobileip-cellular-requirements-01.txt>, June 1999.
Work in progress.
[MIPD] P. Calhoun and C.E. Perkins, ``DIAMETER Mobile IP Extensions,''
Internet draft, Work in Progress, Nov 1998.
[MIPS] B. PAtil, R. Narayanan and E. Qaddoura, "Security Requirements/
Implementaion Guidelines for Mobile IP using IP security"
Internet draft, Work in Progress, June,1999.
[MIPN] P. Calhoun and C.E. Perkins, ``Mobile IP Network Access
Identifier Extension," <draft-ietf-mobileip-mn-nai-05.txt>
October 1999. Work in progress.
[NAI] B. Aboba and M. A. Beadles, ``The network access identifier,''
Internet draft, Work in Progress, Nov 1998.
[RAD] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote
Authentication Dial in User Service (RADIUS),'' Request for
Comments 2138, Apr 1997.
[REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels," RFC-2119, March 1997.
[SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP:
Session Initiation Protocol," RFC 2543, March 1999
[SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using SIP",
ITSUMO Group Expires April 2000 [Page 21]
Internet Draft DRCP October 1999
Proc. of second ACM International Workshop on Wireless
Mobile Multimedia (WOWMOM'99), August, 1999, pp 76-82.
[TIA] Tom Hiller, et al. "3G Wireless Data Provider Architecture
Using Mobile IP and AAA," draft-hiller-3gwireless-00.txt
7. Authors' Addresses
Anthony J. McAuley
MCC 1C235B, Telcordia
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 4698
email: mcauley@research.telcordia.com
Subir Das
MCC 1D210R, Telcordia
445 South Street, Morristown, NJ 07960
Phone: +1 973 829 4959
email: subir@research.telcordia.com
Shinichi Baba
Toshiba America Research Inc.
P.O. Box 136 Convent Station, NJ 07961-0136
Phone: +1 973 829 4759
email: sbaba@tari.toshiba.com
Yasuro Shobatake
Toshiba America Research Inc.
P.O. Box 136 Convent Station, NJ 07961-0136
Phone: +1 973 829 3951
email: yasuro.shobatake@toshiba.com
ITSUMO Group Expires April 2000 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-24 01:27:15 |