[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/