idnits 2.17.1 draft-itsumo-drcp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 60 characters in excess of 72. ** The abstract seems to contain references ([RAD], [NAI], [DHC], [SIPM], [DIA], [MIP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 211 has weird spacing: '...meeting the n...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'BOO1' is mentioned on line 663, but not defined == Missing Reference: 'BODH' is mentioned on line 663, but not defined == Unused Reference: 'BOO' is defined on line 867, but no explicit reference was found in the text == Unused Reference: 'BOOD' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'MIP6' is defined on line 902, but no explicit reference was found in the text == Unused Reference: 'MIPC' is defined on line 910, but no explicit reference was found in the text == Unused Reference: 'SIP' is defined on line 936, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-valko-cellularip-00 -- Possible downref: Normative reference to a draft: ref. 'CEL' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCA' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCD' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHCL' -- Possible downref: Non-RFC (?) normative reference: ref. 'DIA' -- Possible downref: Non-RFC (?) normative reference: ref. 'HAW' ** Obsolete normative reference: RFC 2002 (ref. 'MIP') (Obsoleted by RFC 3220) -- Possible downref: Non-RFC (?) normative reference: ref. 'MIP6' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPA' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPC' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MIPN' -- Possible downref: Non-RFC (?) normative reference: ref. 'NAI' ** Obsolete normative reference: RFC 2138 (ref. 'RAD') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2543 (ref. 'SIP') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Possible downref: Non-RFC (?) normative reference: ref. 'SIPM' -- Possible downref: Normative reference to a draft: ref. 'TIA' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 17 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Anthony McAuley 2 INTERNET-DRAFT Subir Das 3 Internet Engineering Task Force Telcordia Technologies 4 draft-itsumo-drcp-00.txt Shinichi Baba 5 Date: October 1999 Yasuro Shobatake 6 Expires: April 2000 Toshiba America Research Inc. 8 Dynamic Registration and Configuration Protocol (DRCP) 10 Status of this memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of sections 10 of RFC 2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- 23 Drafts as reference material or to cite them other than as 24 "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The Dynamic Host Configuration Protocol (DHCP) provides a framework 35 for passing configuration information to hosts [DHC]. DHCP was, 36 however, designed for hosts on a fixed LAN, not for nodes roaming 37 among commercial wireless networks. Mobile IP [MIP], when combined 38 with some recent proposals [e.g., MIPA, MIPD, MIPN, HAW, CEL, TIA], 39 gives a powerful plug and play capability for roaming hosts, but the 40 additional functionality may not be needed or may be better provided 41 using some alternative mechanisms. This draft proposes an enhanced 42 version of DHCP for roaming users, called the Dynamic Registration 43 and Configuration Protocol (DRCP). DRCP borrows heavily from DHCP 44 and can revert to using DHCP protocol if only DHCP servers are 45 present in the network; but adds features critical to roaming users. 46 Most importantly, DRCP allows rapid configuration using several 47 modifications, including moving address consistency checking from the 48 critical path. Other new features allow: a) clients to know when to 49 get a new address independent of the access technology, b) efficient 50 use of scarce wireless bandwidth, c) nodes to be a relay agent or 51 server depending on a client's authorization, d) clients to be 52 routers, e) associating a priority with addresses, and f) identifying 53 users (e.g., by NAI [NAI]) rather than hardware address. DRCP also 54 adds options for QOS negotiation, service activation, and 55 authentication. 57 In some sense DRCP is to DHCP what DHCP is to BOOTP. DRCP directly 58 supports intra-domain registration and configuration, but must be 59 combined with other protocols to provide features such as continuous 60 connectivity (e.g., using Mobile IP or SIP [SIPM]), or inter-domain 61 authentication, authorization and accounting (e.g., using Radius 62 [RAD] or Diameter [DIA]). 64 Table of Contents 66 1 Introduction ...................................................3 67 1.1 Architecture ...............................................3 68 1.2 DHCP .......................................................4 69 1.3 Mobile IP ..................................................6 70 1.4 Requirements Terminology ...................................6 71 1.5 Overview ...................................................7 72 1.6 Terminology ................................................7 74 2 Protocol Summary ..............................................8 75 2.1 DRCP Overview - Components ................................8 76 2.2 DRCP Messages ............................................10 77 2.2.1 Local Subnet Messages ..............................10 78 2.2.2 Intradomain Messages ...............................12 79 2.3 Summary of Operation .....................................14 80 2.3.1 DRCP Client Operation ..............................14 81 2.3.2 DRCP Proxy Operation ...............................15 82 2.3.3 DRCP Server Operation ..............................15 83 2.4 DHCP Compatibility .......................................15 85 3 DRCP Format .................................................16 86 3.1 Common Header ...........................................17 87 3.2 Options .................................................17 89 4 Security Associations in DRCP ...............................18 90 5 Acknowledgements ............................................20 92 6 References ..................................................20 94 7 Authors' Address ............................................22 96 1. Introduction 98 Most future networks will use IP technology. To provide 99 heterogeneity and flexibility, devices will likely access this 100 IP-based network by directly sending IP packets. In such an 101 environment it is natural to consider using IP-based protocols for 102 user-network signaling, since it can be used across any wired or 103 wireless access network. 105 The functions needed to support users' roaming among IP-based 106 networks vary, depending on network, movement, and application 107 characteristics. Three common functions are Registration, 108 Configuration and Dynamic Address Binding. Registration allows 109 roaming users to rapidly and automatically register their presence 110 and their requirements with networks. Configuration allows networks 111 to automatically configure roaming users to the particular network 112 characteristics. Dynamic Binding allows corresponding nodes to 113 locate roaming users and to allow continuous communication as the 114 user moves among networks. This draft is concerned with the first 115 two functions; it has nothing to say about dynamic binding, except 116 that it should be an option independent of the registration and 117 configuration protocol. 119 1.1 Architecture 121 Figure 1 shows a high level functional architecture of a future IP- 122 based network, with a roaming node attaching to various wired or 123 wireless access networks. The access network may contain multiple 124 hubs or base stations with at least one subnet router with 125 connections to the rest of the network. We assume the mobile node 126 keeps the same IP address anywhere within an access network, since 127 micro mobility (e.g., among base stations) is handled at layer 2. 128 The mobile node must, however, get a new IP address every time it 129 moves to a new subnet (with some exceptions within a single domain if 130 a protocol such as HAWAII [HAW] or Cellular IP is used [CEL]). The 131 Regional Backbone connects all the subnet routers in a single 132 administrative domain and the global Internet interconnects all the 133 regional networks. 135 . <---- DOMAIN 1 ----> . . <---- DOMAIN 2 ----> . 136 . . +-------------+ . . 137 . +---------------+ . | Public | . +---------------+ . 138 . | Registration | . | Verification| . | Registration | . 139 . | Agent | . | Agent | . | Agent | . 140 . +---------------+ . +-------------+ . +---------------+ . 141 . | . | . | . 142 . __|__ . __|__ . __|__ . 143 . / \ . / \ . / \ . 144 . / \ . / \ . / \ . 145 . / Regional\_________/ Global \_________/ Regional\ . 146 . \ Backbone/ . \ Internet/ . \ Backbone/ . 147 . ---\ /--- . \ / . ---\ /--- . 148 . | \_____/ | . \_____/ . | \_____/ | . 149 . | | . . | | . 150 . +---------+ +---------+ . . +---------+ +---------+ . 151 . | Subnet |...| Subnet | . . | Subnet |...| Subnet | . 152 . | Router | | Router | . . | Router | | Router | . 153 . +---------+ +---------+ . . +---------+ +---------+ . 154 . | | . . | | . 155 . __|__ __|__ . . __|__ __|__ . 156 . / \ / \ . . / \ / \ . 157 . / \ / \ . . / \ / \ . 158 . / Access \.../ Access \ . . / Access \.../ Access \ . 159 . \ Network / \ Network / . . \ Network / \ Network / . 160 . \ / \ / . . \ / \ / . 161 . \_____/ \_____/ . . \_____/ \_____/ . 162 . | | . . | | . 163 v v v v 164 +---------+ global macro 165 | Mobile | *******************> ************> 166 | Node | mobility mobility 167 +---------+ 169 FIGURE 1: Functional Network Architecture for Supporting Universal 170 Mobile Operation 172 1.2 DHCP 174 The Dynamic Host Configuration Protocol (DHCP) provides a well tested 175 and widely deployed framework for passing configuration information 176 to hosts [DHC]. DHCP, however, was designed for hosts on a fixed 177 LAN, not for users roaming among commercial wireless networks. Table 178 1 shows that DHCP misses the requirements of some roaming users. 180 Table 1 Requirements for protocols supporting roaming users 181 ------------------------------------------------------------ 183 Requirements DHCP DRCP 184 ----------------------------------------------------- ---- ---- 185 Based on IP (work across all wired/wireless networks) Y Y 186 Requires no manual configuration when moving Y Y 187 Allows a single network server per domain Y Y 188 Allows any dynamic binding protocol (e.g., Mobile IP) Y Y 189 Allows nodes to go on and off without re-registration Y Y 190 Minimizes setup delay after a move N Y 191 Supports both hosts and routers N Y 192 Identifies users (e.g., NAI) not hosts or interfaces N Y 193 Minimizes signalling overhead across access network N Y 194 Requires AAA only when first active in a new domain N Y 195 Supports initial service activation N Y 196 Supports an inter-domain AAA protocol (e.g., Radius) N Y 197 Supports Quality of Service (QOS) negotiation N Y 199 Recent proposals provide some enhancements to DHCP for roaming users. 200 For example there are proposals to adding: authentication [DHCA], 201 LDAP database management [DHCL], and dynamic updating of DNS [DHCD]. 202 Key problems remain, however, most importantly the long setup delay 203 after a move. 205 Rapid configuration (milliseconds rather than seconds) is necessary 206 for most roaming users. DHCP specification [DHC] says a client 207 SHOULD do an ARP check before an assigned address is used. This 208 checking results in long delay before communication can resume after 209 a move. 211 There are other reasons for which DHCP is not meeting the needs of 212 roaming users, including: 213 o No independent way to detect a move to a new subnet. 214 o Large message size (parts of which are not needed). 215 o Fixed role, requiring a DHCP node to be a server OR a relay agent. 216 o Forcing clients to be hosts. 217 o Not allowing the network to quickly change leased addresses 218 (before the lease runs out). 219 o Identifying hardware (e.g., by MAC address) rather than users 220 (e.g., by Network Access Identifier [NAI]). 222 The fixed role limits architectural choices. A wireless service 223 provider, for example, may want a subnet router (see Figure 1) to act 224 as a relay agent when a node first moves into its domain (forwarding 225 DHCP messages to a central server), but act as a server for 226 previously authorized nodes. Identifying users allows a user to use 227 any device and to specify the location of their Public Verification 228 Agent (see Figure 1). 230 DHCP also does not support some important options for commercial 231 wireless operation: such as QOS negotiation, and service activation. 232 Using QOS service specification users may request, for example, a 233 paging service that does not require nodes to be active as they move 234 in the doamin. In particular, QoS messages help the network to know 235 the requirements from the client side as well as client to know the 236 capabilities of the network. The network, for example, may use the 237 QoS service negotiation to set the policing mechanism. 239 1.3 Mobile IP 241 Mobile IP [MIP] is a simple and scalable solution to manage device 242 mobility throughout the global Internet. The Mobile IP Foreign Agent 243 supports host registration and configuration and the Home Agent 244 provides continuous connectivity by redirecting messages to the 245 roaming users' latest location. When combined with recent 246 enhancements, Mobile IP is the basis for a comprehensive roaming 247 solution. For example, there are proposals for Mobile IP 248 authentication, authorization and accounting [MIPA, TIA, MIPD], use 249 of Network Access Identifier [MIPN], and optimizations such as Hawaii 250 [HAW], and Cellular IP [CEL]. Although these proposal make large 251 improvements, they do not alter the fact that the Mobile IP service 252 has a large cost. Also using Foreign Agent adds additional 253 complexity to the network which may already be using DHCP. 255 Mobile IP provides networks transparency above the IP layer. 256 Although this transparency has a cost (e.g., triangular routing), 257 Mobile IP is ideal for many applications (particularly TCP 258 applications such as telnet or ftp). In many cases, however, this 259 transparency is not needed (e.g., for web browsing) or is better 260 provided by alternative mobility mechanism (viz., SIP for real-time 261 applications). Thus, while Mobile IP should be part of an overall 262 mobility solution, it is best used selectively and in pop-up mode 263 (i.e., using DHCP/DRCP to obtain addresses) instead of using a 264 Foreign Agent. 266 1.4 Requirements Terminology 268 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 269 "SHOULD", "SHOULD NOT", RECOMMENDED", "MAY", and "OPTIONAL" in this 270 document are to be interpreted as decribied in RFC 2119 [REQ]. 272 1.5 Overview 274 This draft proposes an enhanced version of DHCP for roaming users, 275 called the Dynamic Registration and Configuration Protocol (DRCP). 276 DRCP adds many new features including rapid client configuration and 277 efficient use of wireless bandwidth. Section 2 describes DRCP 278 operations while Section 3 presents the DRCP format. Finally, 279 security associations are discussed in Section 4. 281 1.6 Terminology 283 This document uses the following terms: 285 o AAA 286 Authentication, authorization and accounting 288 o "BOOTP" 289 The Bootstrap Protocol (BOOTP) [BOO1, BOO2]. 291 o "DHCP" 292 The Dynamic Host Configuration Protocol (DHCP) used to configure 293 Internet hosts. 295 o "DHCP client" 296 A DHCP client is an Internet host using DHCP to obtain 297 configuration parameters such as a network address. 299 o "DHCP relay agent" 300 A relay agent is an Internet host that passes DHCP messages 301 between DHCP clients and DHCP servers. 303 o "DHCP server" 304 A DHCP server is an Internet node that returns configuration 305 parameters to DHCP clients. 307 o "DRCP" 308 The Dynamic Registration and Configuration Protocol (DRCP) used to 309 configure nodes. 311 o "DRCP client" 312 A DRCP client is an Internet node (host or router) using DRCP to 313 register with the network and obtain configuration parameters such 314 as a network address. 316 o "DRCP proxy" 317 A DRCP-proxy is an Internet node that lies on the same subnet as 318 the client and can either act as a relay agent or a 319 virtual-server. It can forward DRCP messages between the 320 DRCP-client and a DRCP server or can pass configuration parameters 321 such as a network address directly to a DRCP client (from a pool 322 of addresses it got from a DRCP server). 324 o "DRCP server" 325 A DRCP server is an Internet node that owns a pool of IP 326 addresses. The server can lease addresses from this pool to other 327 DRCP nodes in its domain. Each domain running DRCP must have at 328 least one server, though there could be more in larger domains. 329 It performs verification of roaming nodes from other domains. 331 o "Virtual Server" 332 A DRCP-proxy is called a virtual server when it acts as a server 333 instead of a relay agent. 335 o "NAI" 336 Network Access Identifier of the form user@domain [NAI]. 338 o "Public Verification Agent" 339 A Public Verification Agent (PVA) is an Internet node that 340 vouches for DRCP clients to DRCP servers. A client may have one 341 or multiple PVAs to support interdomain roaming. 343 o "Registration Agent" 344 A Registration Agent (RA) is an Internet node with a DRCP server 345 that provides a centralized service to DRCP proxies along with AAA 346 functionality. 348 2. Protocol Summary 350 The Dynamic Registration and Configuration Protocol (DRCP) uses many 351 of the features found in DHCP. We require a new protocol, however, 352 because DRCP's extended goals requires major enhancements to DHCP. 353 For example, DRCP supports users roaming among commercial service 354 providers. 356 2.1 DRCP Overview - Components 358 The Dynamic Registration and Configuration Protocol (DRCP) is based 359 on a client-proxy-server model. Figure 2 shows how the client, 360 proxy, and server could map onto the network architecture shown in 361 Figure 1. 363 DRCP-Clients DRCP-proxies DRCP-server 364 +-------------+ +---------------+ +--------------------+ 365 | Mobile Node |<----->| Subnet Router |<----->| Registration Agent | 366 +-------------+ | +---------------+ | +--------------------+ 367 : | | 368 : | | 369 +-------------+ | . | 370 | Mobile Node |<--- . | 371 +-------------+ . | 372 | 373 | 374 +-------------+ +---------------+ | 375 | Mobile Node |<----->| Subnet Router |<--- 376 +-------------+ | +---------------+ 377 : | 378 : | 379 +-------------+ | 380 | Mobile Node |<--- 381 +-------------+ 383 FIGURE 2 DRCP Client-Proxy-Server model 385 The DRCP client-proxy-server model is similar to the DHCP model of 386 client-relay-server. There are, however, differences that are 387 described below. 389 The DRCP-server is typically run at a single logical node called the 390 Registration Agent. The server is the only DRCP entity that owns a 391 pool of addresses. The server can lease addresses from this pool to 392 other DRCP nodes (DRCP-proxies and DRCP-clients) within its domain. 393 Each domain must have at least one server, though there could be 394 multiple servers in larger domains. While its central function is to 395 manage its address pool and hand out other configuration parameters 396 (like a DHCP server), the DRCP server may also interwork with AAA 397 protocol such as DIAMETER [DIA] to do the inter-domain AAA functions. 399 Figure 2 shows a single DRCP-proxy running on the subnet router at 400 each subnet. Although the proxy can be run on any node, not 401 necessarily a router, each subnet must have at least one DRCP proxy 402 or DRCP-server in order to support DRCP-clients on that subnet. The 403 proxies have a dual role. When a DRCP-client first moves into a new 404 domain, the proxy acts as a relay and forwards DRCP signaling packets 405 between the client and the central server. When the client has 406 registered and is moving among subnets in the same domain, the proxy 407 acts as a virtual server; so client's re-registration does not 408 involve the central server. 410 A DRCP-client is similar to a DHCP-client, except that it can lie on 411 a host or a router. A client can autoconfigure any interface that is 412 attached to a network that has a node with a DRCP-proxy or DRCP- 413 server. 415 2.2 DRCP Messages 417 DRCP is designed to be a superset of DHCP, like DHCP is a superset of 418 BOOTP. A DRCP implementation must support all DHCP messages defined 419 in the specification [DHC]. In addition, DRCP also defines its own 420 messages and have the same basic semantics as those used in DHCP. 421 For example, the DHCPOFFER [DHC] has the same basic functions (and 422 name) as DRCP_OFFER. New messages are needed in order to minimize 423 message size and also because their syntax is very different (see 424 Section 3). Section 2.4 discusses the interworking between DHCP and 425 DRCP. 427 Like DHCP, DRCP uses UDP as its transport protocol. There are two 428 types of DRCP signaling messages running on two different UDP ports: 429 a) All local subnet messages, between a client and a proxy or server 430 on the same subnet, are sent to the 'DRCP_CLIENT_PORT' port (number 431 To Be Determined (TBD)) and b) All intra-domain messages, between a 432 proxy and a server within a single domain, are sent to the 433 'DRCP_SERVER_PORT' port (number TBD). 435 2.2.1 Local Subnet Messages 437 Figure 3 shows a general architecture for DRCP operation on a local 438 subnet. In general a subnet requires only one proxy (as shown in 439 Figure 2); however, we show the more general with redundant proxies 440 and possibly DRCP servers. 442 +--------------+ +--------------+ +--------------+ 443 | DRCP | | DRCP | ... | DRCP | 444 | Proxy/Server | | Proxy/Server | | Proxy/Server | 445 +--------------+ +--------------+ +--------------+ 446 | | | 447 ____|__________________|______________________|____ 448 / \ 449 / \ 450 / Local \ 451 \ Subnet / 452 \ / 453 \___________________________________________________/ 454 | | | 455 | | | 456 +---------+ +---------+ +---------+ 457 | DRCP | | DRCP | ... | DRCP | 458 | Client | | Client | | Client | 459 +---------+ +---------+ +---------+ 461 FIGURE 3 DRCP Node configuration on a Local Subnet 463 There are five messages from DRCP client: 465 o DRCP_DISCOVER: 466 Registration message sent by a DRCP-client on its local subnet 467 to request a new address and other configuration parameters. While 468 a DHCPDISCOVER message must be broadcast [DHC], a DRCP_DISCOVER 469 message may be broadcast or unicast depending whether the client 470 knows the address of a DRCP Proxy or Server (e.g., from a 471 DRCP_ADVERTISEMENT]. 473 o DRCP_REQUEST: 474 Registration message sent by a DRCP-client on its local subnet 475 to request extending the lease on an address. 477 o DRCP_INFORM: 478 Registration message sent by a DRCP-client on its local subnet 479 to request new configuration parameters. This could be used, 480 for example, if the client already has an externally configured 481 network address. 483 o DRCP_DECLINE: 484 Registration message sent by a DRCP-client on its local subnet 485 to request a different address, either because the one assigned is 486 not acceptable (e.g., it is already in use by another client) or 487 because the client has moved to a new subnet. 489 o DRCP_RELEASE: 490 De-registration message sent by a DRCP-client on its local subnet 491 to relinquish a network address and cancel remaining lease. 493 These messages have the same basic semantics (though extended and 494 with different syntax) as the five used in DHCP [DHC], so we use the 495 same naming convention (e.g., DHCPDISCOVER is the equivalent of 496 DRCP_DISCOVER). 498 There are three messages from a DRCP proxy/server to a client on the 499 local subnet: 501 o DRCP_OFFER: 503 Configuration message sent back to client on the same subnet where 504 the DRCP proxy/server node received a DRCP_DISCOVER message. 506 o DRCP_ACK: 508 Configuration message broadcast by a Proxy/Server on its local 509 subnet in response to a DRCP_REQUEST. 511 o DRCP_ADVERTISEMENT: 513 Proxy/Server tells the network what addresses are available to use. 514 Can be broadcast (periodically) or unicast in response to a client 515 using an incorrect address, (e.g., client has moved to new subnet). 516 This message is a superset of the DHCPNAK message. 518 The first two are semantically similar to those use in DHCP (though 519 extended and with different syntax), so we use the same naming 520 convention. The DRCP_ADVERTISEMENT however has a new name (from 521 DHCPNAK) since its basic function is changed significantly. 523 2.2.2 Intradomain Messages 525 Figure 4 shows a general architecture for DRCP operation inside 526 a domain, In general a domain requires only one server (as shown in 527 Figure 2); however, we show the more general case that allows 528 redundancy. The addresses of the servers and proxy may be 529 preconfigured or may be discovered. One method, for example, would be 530 to use a well-known IP multicast group(s), which servers and 531 proxies could join independently. 533 +---------+ +---------+ +---------+ 534 | DRCP | | DRCP | ... | DRCP | 535 | Server | | Server | | Server | 536 +---------+ +---------+ +---------+ 537 | | | 538 ____|__________________|______________________|____ 539 / \ 540 / \ 541 / Regional \ 542 \ Backbone / 543 \ / 544 \___________________________________________________/ 545 | | | 546 | | | 547 +---------+ +---------+ +---------+ 548 | DRCP | | DRCP | ... | DRCP | 549 | Proxy | | Proxy | | Proxy | 550 +---------+ +---------+ +---------+ 552 FIGURE 4 DRCP Node configuration within a single domain 554 There are two types of messages from a DRCP Proxy to a DRCP server 555 (or servers). The first type of messages are from the client being 556 forwarded to the server described in Section 2.2.1 (where the proxy 557 acts as a relay agent). The second class of messages are directly 558 from a proxy to a server (or servers) within its domain. Currently 559 only two messages of the second type are defined: 561 o DRCP_POOL_REQUEST 562 Proxy requests a range of addresses for its subnet, so it can 563 act as a virtual server. 565 o DRCP_STATUS_REQUEST 566 Request for a new DRCP_STATUS_UPDATE. 568 There are also two types of messages from a DRCP server to a DRCP 569 proxy (or proxies). The first type of messages are to a client that 570 should be forwarded by a proxy described in Section 2.2.1 (where the 571 proxy acts as a relay agent). The other messages are directly from a 572 server to a proxy (or proxies) within its domain. Currently only two 573 messages of the second type are defined: 575 o DRCP_POOL_RESPONSE 576 Response to a DRCP_POOL_RESPONSE. 578 o DRCP_STATUS_UPDATE 579 Status message giving information about users who have access to 580 the network. 582 The exact mechanisms used to send these intradomain messages are 583 still being researched. Clearly, however, the distribution of 584 information from server to proxies should be done efficiently 585 (possibly using IP multicast). 587 2.3 Summary of Operation 589 A DRCP client or proxy is initially assumed only to know which of its 590 interfaces is running as a DRCP-client or DRCP-proxy and 591 corresponding security associations. If there are multiple 592 interfaces, each interface may be configured in a different way. An 593 interface may be configured to run with a locally stored address or 594 as a DHCP-client. After boot-up, however, any interface configured 595 as a DRCP client or proxy listens to messages on DRCP_CLIENT_PORT. 596 During any message exchange the two sides may insert authentication 597 tokens (authentication token may be an option in options field [see 598 section 3.2]). If the required token does not match, the message 599 MUST be rejected. 601 2.3.1 DRCP Client Operation 603 A client first broadcasts a DRCP_DISCOVER message (similar to a DHCP 604 DISCOVER message) to the DRCP_CLIENT_PORT. If it gets no response 605 after DRCP_RETX_TIMEOUT, then it resends the DRCP_DISCOVER message. 606 This process repeats for up to DRCP_RETX_MAX retransmissions. If the 607 client receives a DRCP_ADVERTISEMENT message, then it will change to 608 a unicast state, so the next DRCP_DISCOVER message will be unicast to 609 the source address of the DRCP_ADVERTISEMENT. If the client receives 610 a DRCP_OFFER message, then it can immediately configure its interface 611 with that address. There is no requirement to do ARP checking before 612 using the address (as in DHCP). 614 After getting an address the client must periodically send out 615 DRCP_REQUEST messages to renew the lease. These message are 616 retransmitted until acknowledged by a DHCP_ACK message. If the 617 client detects a move to a new subnet (e.g., through receiving a 618 DRCP_ADVERTISEMENT message), then the client must send out a new 619 DRCP_DISCOVER message. If the DRCP_OFFER message indicated that the 620 client could keep the same address in the new subnet in the same 621 domain (e.g., using a mechanism such as HAWAII [HAW]), then it will 622 send a DRCP_REQUEST instead of a DRCP_DISCOVER. 624 2.3.2 DRCP Proxy Operation 626 A proxy is also initially assumed only to know which of its 627 interfaces is running as a DRCP-proxy and security associations, if 628 there are any. It broadcasts a DRCP_ADVERTISEMENT message to 629 DRCP_CLIENT_PORT to all DRCP proxy configured interfaces once per 630 DRCP_ADVERT_TIME. The proxy also listens for DRCP messages on either 631 the DRCP_CLIENT_PORT or the DRCP_SERVER_PORT. 633 If it hears any message from a DRCP client (on the DRCP_CLIENT_PORT), 634 then it will respond by either forwarding the message to a server (on 635 the DRCP_SERVER_PORT) or responding locally (on the 636 DRCP_CLIENT_PORT). If it hears any DRCP message from the server (on 637 the DRCP_SERVER_PORT) intended for a local client, it will forward 638 this message (on the DRCP_CLIENT_PORT). 640 If the proxy hears an DRCP_STATUS_UPDATE message (from a DRCP-server) 641 on the DRCP_SERVER_PORT, then it updates its local cache about what 642 clients have successfully registered with the server. If the proxy 643 hears from a client that thinks it is registered with a domain 644 server, but it does not have the information in its cache, then the 645 proxy can send a DRCP_STATUS_REQUEST message on the DRCP_SERVER_PORT. 646 If the proxy has no addresses (e.g., when first booted), runs out of 647 addresses, or the leases on the addresses it has are getting close to 648 expiring, then it can send a DRCP_POOL_REQUEST message to the 649 server(s) on the DRCP_SERVER_PORT. If it receives a 650 DRCP_POOL_RESPONSE message on the DRCP_SERVER_PORT, then it can 651 update its address pool. 653 2.3.3 DRCP Server Operation 655 The DRCP server is assumed to be configured with a pool of addresses. 656 It can either allocate these addresses directly to clients that 657 register or can give a range of addresses to proxies (that the 658 proxies can give to interfaces directly connected to subnets to which 659 it has a direct link). 661 2.4 DHCP Compatibility 663 DRCP is to DHCP what DHCP is to BOOTP [BOO1, BOO2, BODH]. Just as 664 DHCP allows interoperability of existing BOOTP clients with DHCP 665 servers, DRCP allows interoperability of DRCP clients with existing 666 DHCP servers (see Figure 3a). DHCP clients can also inter-operate 667 with DRCP servers (see Figure 3b), though policy may not allow a DHCP 668 client's access. In this case DRCP Servers/Proxy runs DHCP server 669 functionality as well. 671 +--------------+ +--------------+ 672 | DHCP | | DRCP | 673 | Server/Relay | | Server/Proxy | 674 +--------------+ +--------------+ 675 ^ ^ 676 __|__ __|__ 677 / \ / \ 678 / \ / \ 679 / Access \ / Access \ 680 \ Network / \ Network / 681 \ / \ / 682 \_____/ \_____/ 683 | | 684 v v 685 +---------+ +---------+ 686 | DRCP | | DHCP | 687 | Client | | Client | 688 +---------+ +---------+ 690 a) DRCP Client in DHCP Network. b) DHCP Client in DRCP Network. 692 FIGURE 5 DRCP-DHCP Interworking 694 The DRCP client may initially send out a DRCP_DISCOVER message that 695 can be understood only by a DRCP proxy/server. If after some time, 696 the node hears no DRCP messages on the subnet, then it can send DHCP 697 dicovery messages as well. 699 3. DRCP Format 701 All DRCP messages are sent in UDP/IP packets to a special DRCP port. 702 All messages are 32-bit aligned and have the general format shown 703 below (size shown in braces): 705 +---------------------------------------------------------------+ 706 | Common Header (12) | 707 +---------------------------------------------------------------+ 708 | Options (variable) | 709 +---------------------------------------------------------------+ 711 FIGURE 6 DRCP Format 713 3.1 Common Header 715 The first part of all DRCP messages is the Common Header. Currently 716 it has the format shown below: 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | op (1) | Flags(1) | Length(2) | 722 +---------------+---------------+---------------+---------------+ 723 | id (8) | | 724 +---------------------------------------------------------------+ 726 FIGURE 7 Common Header Format 728 The meaning (and size in bytes) of the fields in the common header 729 are: 730 Op 1 Message op code. For example, it is a DRCP_DISCOVER 731 message (the specific codes are TBD). 733 Flags 1 Flags to represent type of message. 735 Length 1 Length of of the message including all headers in 32-bit 736 words. Since all messages have a 3 word (12 byte) header 737 the minimum value is 3. 739 id 8 A unique id given to DRCP node by a Proxy or Server. 740 It SHOULD be unique within a domain. A value of 0 indicates 741 a NULL value (e.g., in a DRCP_DISCOVER message). 743 3.2 Options 745 All information, other than what is in the common header, must be 746 included as options. Some messages require certain options. For 747 example, an DRCP_OFFER must include an "IP Address Allocation" 748 option. Some messages may require at least an option of a certain 749 type, but not necessarily a specific option. For example, a 750 DRCP_DISCOVER message may require either an NAI or some equivalent 751 identifier. All options have a common 4 byte header shown below: 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | length(1) | Type (2) | TBD(1) | 757 +---------------+---------------+---------------+---------------+ 758 | .... | 760 FIGURE 8 Option Header 761 The meaning of the fields in the option header are:elds in the option 762 header are: 764 Length 1 Length of the option including this option headers in 765 32-bit words. 767 Type 2 Option type, such as IP address allocation (the specific 768 codes are TBD). 770 The figure below shows an example of the NAI option: 772 0 1 2 3 773 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 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | length(1) | Type (2) | TBD(1) | 776 +---------------+---------------+---------------+---------------+ 777 | | 778 | | 779 NAI(128) 780 | | 781 +---------------------------------------------------------------+ 783 FIGURE 9 NAI Option 785 The meaaning of the fields in the NAI option body are: 787 NAI 128 Network Access Identifier of the form user@domain 788 [NAI]. 790 4. Security Association in DRCP 792 DRCP defines a set of messages that enable roaming users to rapidly 793 and automatically register to a new network with their requirements 794 and also allows networks to automatically configure roaming users. 795 Mobile nodes as well as DRCP proxies or Servers exchange several 796 messages for registration and configuration. Unlike conventional 797 cellular/ telephone networks where these types of messages are sent 798 over a secured signaling network, DRCP messages traverse through the 799 public IP network. Therefore, it is necessary to protect the data in 800 order to prevent security attacks on the mobile user as well as on 801 the visiting network [MIPS]. Figure 10 below describes different 802 security associations that are necessary for secured registration and 803 configuration. 805 |<--Visited Domain--> |<-- Home Domain --> 807 Client Proxy RA/Server PVA RA/Server Proxy Client 808 | | | | | | | 809 |<--------|---SA4---|-------->| | | | 810 | | |<--SA2-->| | | | 811 | | | |--|--| | | | 812 | | | | | | | | | 813 | | | | | | | | | 814 | |<--SA6-->| | | | | | | 815 | | | |--|--| | | | 816 |<--SA5-->| | Internet | | | 817 | | | | | | 818 | | |<-------SA1-------->| | | 819 |<----------------SA3------------------->| | | 820 | 822 FIGURE 10 Security Associations (SAs) 824 SA1 - between the Registration Agent (RA) or DRCP-server in the 825 visited domain and the Registration Agent in the home domain. 827 SA2 - between Registration Agent of the visited domain and Public 828 Verification Agent (PVA). 830 SA3 - between DRCP-Client and Registration Agent in home domain. 832 SA4 - between DRCP-client and Public Verification Agent. 834 SA5 - between DRCP-client and DRCP-proxy in the visited domain. 836 SA6 - between DRCP-client and DRCP-proxy in the visited domain. 838 SA1, SA2, SA3 and SA4 may not be required always. If the 839 Registration Agent of the visited domain determines that it will 840 contact the home domain's Registration Agent for verification it 841 requires SA1 and SA3. On the other hand if it contacts Public 842 Verification Agent it requires SA2 and SA4. 844 We assume that RAs and PVAs are capable of handling the AAA protocol. 845 In that case the visited domain may have a Service Level Agreement 846 with the home RA or nearest PVA. So it is expected that a secure 847 tunnel, e.g., IPsec will exist between two RAs or from RA to PVA. If 848 there exists multiple RAs in a single domain it may not be practical 849 to have security associations with every RA. There are still many 850 issues which need further discussions and research. 852 5. Acknowledgments 854 The authors wish to acknowledge the contributions of other members of 855 the ITSUMO (Internet Technologies Supporting Universal Mobile 856 Operation) team from Telcordia (P. Agrawal, J.C. Chen, A. Dutta, 857 D. Famolari, F. Vakil, P. Ramanathan, H. Sherry and R. Wolff) 858 and Toshiba America Research Incorporated (T. Kodama). 860 Some of the initial ideas of DRCP came out of a project on complete 861 autoconfiguration within a domain, funded by the U. S. Army 862 Research Laboratory (ARL) under the Advanced Telecommunications and 863 Information Distribution Research Program (ATIRP) Consortium. 865 6. References 867 [BOO] Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, 868 Stanford and SUN Microsystems, September 1985. 870 [BOO2] Wimer, W., "Clarifications and Extensions for the Bootstrap 871 Protocol", RFC 1542, Carnegie Mellon University, October 1993. 873 [BOOD] Droms, D., "Interoperation between DHCP and BOOTP", RFC 1534, 874 Bucknell University, October 1993. 876 [CEL] Valko, A., Campbell, A. and Gomez, J.: "Cellular IP", Internet 877 draft, draft-valko-cellularip-00.txt, November 1998. Work in 878 progress. 880 [DHC] R. Droms, `` Dynamic Host Configuration Protocol,'' Request for 881 Comments 2131, Mar 1997. 883 [DHCA] R. Droms, "Authentication for DHCP Messages", , June 1999. 886 [DHCD] Y. Rekhter, M. Stapp, "Interaction between DHCP and DNS," 887 , June 1999, Work in progress. 889 [DHCL] A. Bennett, B. Volz, A. Westerinen, " DHCP Schema for LDAP," 890 , June 1999, Work in progress. 892 [DIA] P. Calhoun and A. Rubens, ``DIAMETER Base Protocol,'' Internet 893 draft, Work in Progress, Nov 1998. 895 [HAW] R. Ramjee, T. La Porta, S. Thuel and K. Varadhan: "IP micro- 896 mobility support using HAWAII", 897 , June 1999, 898 Work in progress. 900 [MIP] Perkins, C., Editor: "IP Mobility Support", RFC 2002, October 1996. 902 [MIP6] D. Johnson and C. Perkins, ``Mobility Support in IPv6,'' Internet 903 Draft, Work in Progress, Nov 1998. 905 [MIPA] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 906 Authorization, and Accounting Requirements," 907 , October 1999. 908 Work in progress. 910 [MIPC] E. Gustafsson, A. Jonsson, E. Hubbard, J. Malmkvist, A. Roos, 911 "Requirements on Mobile IP from a Cellular Perspective," 912 , June 1999. 913 Work in progress. 915 [MIPD] P. Calhoun and C.E. Perkins, ``DIAMETER Mobile IP Extensions,'' 916 Internet draft, Work in Progress, Nov 1998. 918 [MIPS] B. PAtil, R. Narayanan and E. Qaddoura, "Security Requirements/ 919 Implementaion Guidelines for Mobile IP using IP security" 920 Internet draft, Work in Progress, June,1999. 922 [MIPN] P. Calhoun and C.E. Perkins, ``Mobile IP Network Access 923 Identifier Extension," 924 October 1999. Work in progress. 926 [NAI] B. Aboba and M. A. Beadles, ``The network access identifier,'' 927 Internet draft, Work in Progress, Nov 1998. 929 [RAD] C. Rigney, A. Rubens, W. Simpson, and S. Willens, ``Remote 930 Authentication Dial in User Service (RADIUS),'' Request for 931 Comments 2138, Apr 1997. 933 [REQ] Bradner, S., "Key words for use in RFCs to Indicate Requirement 934 Levels," RFC-2119, March 1997. 936 [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg, "SIP: 937 Session Initiation Protocol," RFC 2543, March 1999 939 [SIPM] E. Wedlund and H. Schulzrinne, "Mobility Support using SIP", 940 Proc. of second ACM International Workshop on Wireless 941 Mobile Multimedia (WOWMOM'99), August, 1999, pp 76-82. 943 [TIA] Tom Hiller, et al. "3G Wireless Data Provider Architecture 944 Using Mobile IP and AAA," draft-hiller-3gwireless-00.txt 946 7. Authors' Addresses 948 Anthony J. McAuley 949 MCC 1C235B, Telcordia 950 445 South Street, Morristown, NJ 07960 951 Phone: +1 973 829 4698 952 email: mcauley@research.telcordia.com 954 Subir Das 955 MCC 1D210R, Telcordia 956 445 South Street, Morristown, NJ 07960 957 Phone: +1 973 829 4959 958 email: subir@research.telcordia.com 960 Shinichi Baba 961 Toshiba America Research Inc. 962 P.O. Box 136 Convent Station, NJ 07961-0136 963 Phone: +1 973 829 4759 964 email: sbaba@tari.toshiba.com 966 Yasuro Shobatake 967 Toshiba America Research Inc. 968 P.O. Box 136 Convent Station, NJ 07961-0136 969 Phone: +1 973 829 3951 970 email: yasuro.shobatake@toshiba.com