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", , June 1999. [DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS," , June 1999, Work in progress. [DHCL] A. Bennett, B. Volz, A. Westerinen, " DHCP Schema for LDAP," , 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", , 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," , October 1999. Work in progress. [MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos, "Requirements on Mobile IP from a Cellular Perspective," , 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," 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]