idnits 2.17.1 draft-ietf-dhc-dyn-subnet-conf-02.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-28) 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == Mismatching filename: the document gives the document name as 'draft-ietf-dhcp-dyn-subnet-conf-02', but the file name used is 'draft-ietf-dhc-dyn-subnet-conf-02' == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 abstract seems to contain references ([3], [1,2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (2 March 1998) is 9523 days in the past. Is this intentional? 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 section? '1' on line 630 looks like a reference -- Missing reference section? '2' on line 633 looks like a reference -- Missing reference section? '3' on line 636 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Taniguchi 3 INTERNET DRAFT NEC USA 4 T. Nishida 5 NEC USA 6 2 March 1998 8 Subnet Configuration Option Set for DHCP 9 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as ``work in progress.'' 23 To view the entire list of current Internet-Drafts, please check 24 the "1id-abstracts.txt" listing contained in the Internet-Drafts 25 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 26 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 27 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 28 (US West Coast). 30 Abstract 32 This subnet configuration option set provides subnet address 33 assignment capability to DHCP[1,2] to be applied to both virtual 34 subnet creation like as LIS[3], V-LAN and static subnet configuration 35 for new deployed network. This draft illustrates service models for 36 subnet configuration, protocol design concept, protocol behavior and 37 discussions. 39 1. Introduction 41 Subnetworks can be created dynamically owing to recent data link 42 layer technology especially switching and wireless network. Since, 44 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 46 using these technologies, we do not need a IP router function for 47 segmenting IP subnetwork, subnet domain can easily create/delete in 48 accordance with user's requirements. Such typical applications are 49 virtual LAN, VPN (virtual private network), CUG (Closed Users Group) 50 and ad-hoc networks. Users can overlay subnetworks freely on a 51 single physical network for creating intranet and extranet. Ubiquity 52 of Internet results in easily (re)configurable netwoking. in the 53 context of the current Internet, however, each subnet needs to be 54 officially registered to the administrative NIC. This hinders easy 55 Internet access. While several technologies have been proposed, 56 e.g., NAT, IP masquerade, etc. to address this issues., each has some 57 drawbacks, e.g., performance, scalability, etc. 59 Internet engineers have been attacking to improve the network layer 60 technology. One of such challenges is an invention of a function 61 which changes configuration of hosts, route and name space 62 dynamically. For example, DHCP assigns IP address. Dynamic routing 63 protocol like RIP detects link status change and gives the right 64 route information. Moreover, DNS are going to accept a dynamic 65 record update by linking a DHCP server. These technologies 66 contribute easier configuration for a host connection and host 67 movement. This proposal adds another dimension of dynamic internet 68 configuration in conjunction with virtual subnetworking technologies. 69 A new option set, called DSCP (Dynamic Subnet Configuration by DHCP), 70 which is an extension of DHCP, assigns subnet resources to a 71 dynamically created subnetwork. This draft proposes service models 72 for dynamic subnet resource configuration, to add new options in DHCP 73 message format. 75 2. Difference From Previous Draft 77 In the Section 3, one new service model are added. Section 6.6 78 proposes the new message type to make identical subnet name over 79 multiple clients. Section 6.7 describes that how DSCP provides wider 80 subnet address. Section 6.8 illustrates that how DSCP provides 81 multi-homed subnet address. Finally, section 7. includes several 82 discussion to make clear the current problems and possible solutions. 84 3. Service Model 86 There are four models to be considered; (1)administrator driven, 87 (2)leader driven, (3)DHCP server driven and (4)router driven model. 89 (1)An administrator driven model supports requirements of a network 90 administrator who needs a new subnet address. Then, an administrator 91 invokes a DSCP client function. The client negotiates with DSCP 92 servers, and normally gets a set of new subnet address according to 93 the administrator's request. Then the administrator may manually 95 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 97 change the subnet table and configure router's IP address 98 information. In this model, the server only provides an available IP 99 subnet address to the administrator and marks that address as 100 reserved. 102 (2)A leader driven model supports requirements of a leader of a 103 specific group who may not be a network administrator and needs a new 104 subnet address temporally for creating a new subnet. A leader 105 executes a DSCP client. The client negotiates with DSCP servers to 106 get a new IP subnet address. The DSCP servers create a new IP host 107 table to manage a leased subnet address space and prepare to accept 108 DHCP requests from a host who wants to join the newly created IP 109 subnet. After that, hosts of members belonging to the same group 110 join newly created IP subnet using DHCP. The server allocates an IP 111 address to those hosts. 113 (3)A DHCP server driven model supports requirements of a DHCP server 114 who needs a new IP subnet address. The DHCP server as DSCP client 115 requests a new IP subnet address and creates a new IP host address 116 list for a new IP subnet address. Then, the DHCP server leases an IP 117 address in new IP subnet address space. 119 Dial-up access of SOHO router with DHCP server function is an 120 application of model (3). A home or SOHO user who has home subnet 121 can access an ISP by dial-up. A DSCP server in the ISP can provide 122 subnet address to his/her subnet. Finally, all IP terminal, e.g. not 123 only PC but also FAX, phone, TV, refrigerator and microwave can 124 access the Internet. 126 (4)A router driven model supports requirements of router plug-and- 127 play. When a router is connected to existing network and started 128 without any administration information, the router can get an IP 129 interface address by DHCP and could get the new IP subnet address for 130 the other interface which have never been configured yet, and finally 131 those interface could get IP host address for un-configured 132 interfaces, if DSCP server and address space are available. 134 4. Design Concept 136 This proposal adopts an extension of DHCP rather than any invention 137 of new protocol. 139 Extending DHCP for DSCP has several advantages. First, DHCP has 140 already a temporary address leasing mechanism. DHCP server also has 141 already a temporary IP address management database. DHCP client has 142 already finite state machine to assign an unique IP resource in a 143 multiple DHCP server environment. Therefore, the cost of defining, 144 developing and deploying protocol would be minimized. Moreover, the 146 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 148 existing network has a relay agent mechanism which is capable of 149 supporting the DSCP function. 151 5. Term Definition 153 5.1. DSCP This option set is absolutely for extension of DHCP and is NOT 154 dedicated protocol. But only for terminology to discuss here, the 155 word DSCP is defined as DHCP extended with this option set. 157 5.2. Non-DSCP server/client and DSCP server/client 159 During DSCP server/client deployment, DHCP servers/clients both which 160 supports and which does not support DSCP would exist. To describe the 161 difference clearly, non-DSCP server/client and DSCP server/client 162 means DHCP server/client which does not support DSCP and which 163 supports, respectively. 165 5.3. subnet address expiration time 167 This is the expiration time of a subnet address leased by DSCP 168 servers. The subnet address expiration time must be later (longer) 169 than all host address expiration time within the subnet address 170 range. 172 5.4. subnet name 174 In this document, all subnets must have an unique name. The name is 175 used to identify itself. If DSCP server has enough address space, a 176 client with the same subnet name can get the same subnet address 177 again even after the expiration of leased time. 179 5.5. subnet address table 181 In case of a fixed length subnet mask, each entry of the subnet 182 address table has 6 fields: subnet address, subnet mask, broadcast 183 address, lease status, subnet address expiration time, and subnet 184 name. The lease status is one of the following: FREE, RESERVED or 185 OFFERED. 187 In case of a variable length subnet mask, although the format of the 188 subnet address table becomes more complex, its format is similar to 189 that of a fixed subnet mask fixed. 191 6. Protocol Description 193 6.1. Normal operation 195 In this section, to simplify the protocol description, exceptional 197 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 199 operations are not mentioned. In a network with multiple DSCP 200 servers, each server maintains a separate subnet address space. In 201 other words, multiple servers do not manage a specific subnet address 202 at the same time. 204 First, a client sends a DSCPDISCOVER message to servers. To transmit 205 the message, one or more relay agents may forward the message. Or 206 the client may use broadcast, multicast, or unicast. (Since the 207 transfer method is one of the interesting issues for this protocol 208 architecture, this issue is discussed later.) 210 A server searches an unused subnet address from its subnet address 211 table. If there are no unused subnet addresses, the server rejects 212 the request silently, i.e., without any responses. Otherwise, the 213 server returns a DSCPOFFER message to the client. If the client has 214 specified a subnet mask, the server may select a subnet address which 215 has the same subnet mask. If the server has already leased a subnet 216 address to a client which requested previously with an identical 217 subnet name, the DSCP server should not send any DSCPOFFER messages. 219 In receiving a DSCPOFFER message, the client may send a DSCPREQUEST 220 message immediately to the responding server, or it may wait to 221 receive another DSCPOFFER message for some amount of time, e.g., 222 several seconds, then it selects the best offer and sends a 223 DSCPREQUEST message to that particular server. 225 The server receiving a DSCPREQUEST message must immediately check 226 whether the requested subnet address is available or not. If it is 227 still available, the server must reserve it and return a DSCPACK 228 message to the requesting client. Otherwise, the server must return 229 a DSCPNACK message to the client. 231 The client which receives a DSCPACK message, can use the subnet 232 address. The client which receives a DSCPNACK message may send a 233 DSCPDISCOVER message again and repeat the whole operation. 235 6.2. Protocol architecture issues 237 6.2.1. Who manages new IP subnet address space? 239 As described in section 2, there are two cases in a context of IP 240 address management for a subnet number newly assigned; (1) A DSCP 241 client requests DSCP server to manage the leased IP subnet address 242 space as a leader driven model, (2) DSCP client undertakes management 243 of the leased IP subnet address space as an administrator driven 244 model and a DHCP server driven model. For a purpose of definition of 245 authority in IP address space in newly assigned subnet number, a new 246 option is needed. 248 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 250 This option is named "new subnet option." The option number is T.B.D. 251 The length of this option is 1. If the value of this option is 0, 252 the server does not manage the new IP address space. If it is 1, the 253 server manages the new address space. If it is another value, the 254 server must treat those messages as error messages. 256 6.2.2. First message from a client 258 Coping with any DSCP model mentioned in Section 2, a DSCP client is 259 assumed to be assigned to a host address in advance, which is 260 received via DHCP, manual configuration or other method. Therefore, 261 a DSCP client can unicast messages to a DSCP server if the client 262 knows the server's address. Otherwise it may send messages using 263 either broadcast, anycast or multicast. 265 The advantage of using unicast is to minimize the traffic. The 266 advantage of broadcast, multicast or anycast is that a client does 267 not need to know the server's address. And a relay agent supports 268 the forwarding of the DSCP message to a server. 270 6.2.3. Subnet mask negotiation 272 For simple implementation, a server maintains only a fixed length 273 subnet mask. 275 For efficiency of address space utilization, however, the variable 276 network mask should be adopted. In this case, a client may indicate 277 its preferable subnet mask length by including subnet mask option 278 into the DSCPDISCOVER message. A server may negotiate the subnet 279 mask length with the requesting client by changing the value of the 280 option. If the client accepts the offer, it sends DSCPREQUEST 281 message. Otherwise, the client selects another DSCPOFFER message 282 with different subnet mask length. 284 Accommodating both fixed and variable subnetwork, both DSCP server 285 and client interpret subnet mask option as "peer's will." A server 286 may change it, and a client may reject it. 288 6.2.4. Server consistency 290 DSCP uses a subnet name as identification of a particular subnet. If 291 new subnet address is requested, and if the subnet name has already 292 reserved by another request, the server rejects the request. 294 In multiple DSCP servers environment, a server need to know the other 295 server's status, e.g., whether a subnet name is reserved, whether a 296 subnet address has already leased. Otherwise, inconsistency among 297 servers may occur. 299 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 301 To avoid such inconsistency accessing multiple servers, the simplest 302 method is that the number of servers is limited by one for specified 303 subnet name space. This is not fault tolerant, however. Another 304 possible method is that servers strive for database synchronization 305 for all requests. This incurs servers' load. 307 This issue will be resolved by further study. 309 6.3. Architecture of subnet address table 311 6.3.1. Table format 313 Subnet address table must have at least the following entries. 315 1. Subnet address (base) 317 2. Subnet mask 319 3. Broadcast address 321 4. Leasing status (see below) 323 5. Subnet address expiration date 325 6. Subnet name (leasing currently or leased last time) 327 6.3.2. Status of subnet address on server 329 A subnet address in a subnet address table has three status. 331 IDLE 333 In idle status, no clients use the subnet address. 335 OFFERED 337 In offered status, DSCP server has received a DSCPDISCOVER message 338 and sent a DSCPOFFER message including the subnet address. If a DSCP 339 server receives DSCPDISCOVER message which has identical subnet name 340 with "offered" status subnet from another clients, the DSCP server 341 must returns same DSCPOFFER message. A DSCP server should not offer 342 the subnet address in "offered" status to another requisition. A DSCP 343 server must set timer, when it change the status of subnet address to 344 "offered." The server stops the timer and changes the status to 345 "reserved", when the server receives DSCPREQUEST message before the 346 timer expires. When the timer expires, the server changes the status 347 to "idle." In this status, subnet name field is specified. 349 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 351 RESERVED 353 In reserved status, the address has already been leased. In this 354 status, the address must have subnet name and expiration time. The 355 server must not lease this address to another requisition. Yet, the 356 server may extend the expiration time, if the original requisition 357 sends the DSCPREQUEST message. 359 6.4. DHCP server issue 361 A DHCP server which has leased IP subnet address from a DSCP server 362 must keep the following rules. 364 * When T1 timer expires for subnet address, the DHCP server should 365 extend its lease period as DSCP client. 367 * If the subnet address is expired, the DHCP server must not lease 368 any hosts address. 370 * DHCP server must not lease host address with lease time longer 371 than one of the subnet address. 373 * Before releasing a subnet address, the DHCP server must make sure 374 no host address in the subnet are used. 376 * If lease time of the subnet address is infinite and the DHCP 377 server would like to release the address, the server must stop 378 releasing new host addresses first, wait until all host addresses 379 becomes free, and then send DSCPRELEASE message to its DHCP server. 381 6.5. Subnet resource representation 383 In case that DSCP server acts as DHCP server, the DSCP server needs 384 information concerning about subnet resource, such as default router, 385 DNS server, mail server, etc. Therefore, when the DSCP server creates 386 a new subnet, the client must specify the subnet resource. There are 387 two methods to implement simply this issue. 389 The first one is that DSCP client specifies all resources in DHCP 390 existing option. On receiving DSCPREQUEST message, the DSCP server 391 remember the options in that message. After creating a new subnet, 392 DSCP servers set those information on DHCP server. 394 The second one is that newly created subnet shares another existing 395 subnet resource. For these sake, the newly option "subnet resource 396 inheritance" is defined. It includes a name of subnet whose resources 397 are shared by a new subnet. If the specified subnet name does not 398 exist, the DSCP server must treat that message as error. 400 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 402 6.6. Identical name 404 6.6.1. Server view 406 In the case that DHCP server received DHCPDISCOVER message which 407 contains same client identifier option and same giaddr field with a 408 client which had been served, the DHCP server may assume that the 409 request comes from same client. In the case of DSCP server with same 410 client identifier option and same subnet name, the server may assume 411 that the message is a request for same subnet address. But in the 412 case of DSCP server with different client identifier option and same 413 subnet name, can the server assume the message is a request for same 414 subnet address? 416 There are some idea. The fist one is that same subnet name indicates 417 same subnet. If so, how the server respond to the client for reserved 418 address? Basically, the server should inform the client that the 419 subnet address is reserved by other client with same subnet address. 420 To do it, does new message type require to be defined, which is 421 similar with DHCPINFORM but opposite direction message? 423 6.6.2. Client view 425 From the view point of clients which belong same subnet, they desires 426 to have identical subnet name to request subnet address. How can 427 they have it? That's problem. 429 If it is assumed that a client does not have any configuration 430 information, the client would not know the subnet name. In this 431 case, the client can generate subnet name automatically, based on 432 hardware address or another hardware identical information. In the 433 case that there are another clients which know the subnet name on the 434 same subnet, it looks good way to get the subnet name from the 435 clients. Therefore, does DSCP need client-client protocol? 437 6.6.3. An idea 439 To solve these two problems, a new DSCP message type called 440 DSCPSTATUS is proposed. Note that it is assumed that all DSCP 441 clients belong to same subnet and are trying to configure a local 442 port. The clients which leases a subnet address for remote subnet is 443 not assumed. A DSCPSTATUS message includes the subnet name option, 444 subnet address, subnet mask, server identifier option which is used 445 to get subnet address and precedence. The precedence is an integer 446 and indicates administrative precedence of the the subnet name in the 447 message. If the subnet name is configured by an administrator, the 448 value would be higher rather than one which is automatically 449 generated based on hardware address. Clients and servers can send a 451 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 453 DSCPSTATUS message, but only client can receive it. 455 When a client which does not have any configuration information boots 456 up, the client would send DSCPDISCOVER message. If a server detects 457 the subnet in the DSCPDISCOVER message is reserved by another client, 458 the server replies DSCPSTATUS message immediately. If the client 459 sends the DSCPDISCOVER message by broadcast or multicast, another 460 clients could receive it. The clients which receive the DSCPDISCOVER 461 message check the precedence in the DSCPDISCOVER message, and compare 462 it with the precedence of the subnet name which is stored in the 463 memory of the clients. If the precedence in the memory is higher 464 than one of received message, the clients replies DSCPSTATUS message. 466 A client which receives a DSCPSTATUS message compares the precedence 467 in the message with one of the client owns. If the precedence in the 468 message is higher than owned one, the client ignores all DSCPOFFER 469 messages and accepts subnet address and subnet mask in DSCPSTATUS 470 messages. Moreover, the client stores the subnet name and the 471 precedence decreasing by 1 to prepare new neighbor clients' 472 DSCPDISCOVER messages. 474 A client which has never been beaten by any DSCPSTATUS message from 475 other DSCP client is called an original subnet name holder. A client 476 which has accepted a DSCPSTATUS message is called a copied subnet 477 name holder. The reason why the client decreases the precedence 478 value by 1 is to accept the subnet name change of original subnet 479 name holder. In the case that the original subnet name holder 480 changed the subnet name, the precedence of original subnet name 481 holder must be higher 1 than copied subnet name holder. Therefore 482 all copied subnet name holder can accept new name. 484 In order to confirm the subnet name, an original subnet name holder 485 frequently send DSCPSTATUS messages by broadcast so slowly that those 486 message does not affect serious traffic damage to its subnet, for 487 example 30 minutes or 1 hour interval. 489 This idea provides the time continuously of subnet address and the 490 methods to change the subnet name gently. 492 6.7. Wider subnet address 494 In the case that a DHCP server which can work as DSCP client needs 495 more address space for future requests of its clients, the DHCP 496 server can try to borrow wider subnet address. In this case, the 497 DHCP server as DSCP client sends DSCPREQUEST message with wider 498 subnet address and modified base address to fit new subnet address. 500 The DSCP server which receives a DSCPREQUEST message with registered 502 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 504 subnet name and wider subnet mask inspects subnet address table. And 505 if the address space is free, the server replies DSCPACK message. 506 Otherwise, it replies DSCPNACK message. 508 6.8. Multi-homed subnet 510 In the case that a DHCP server which can work as DSCP client needs 511 more address space and failed to get wider subnet address space, it 512 can try to borrow multi-homed subnet address. To do it, it changes 513 the subnet name slightly and sends DSCPDISCOVER message. The 514 following procedure is identical with normal DSCP procedure to borrow 515 a subnet address of a new DSCP client. 517 The method how to change the subnet name slightly is not defined 518 here. To make clear the relation between multi-homed subnet space, 519 explicit naming rule is to be defined. 521 7. Discussion 523 7.1. DSCP message type option 525 DHCP has 8 message types. Basically, this option set is also assumed 526 to have same number of message types. There are three ways to present 527 DSCP message type. 529 The first one is to define dedicated DSCP message type option as DHCP 530 message type option. It allows coexistence of non-DSCP server/client. 531 When any non-DSCP server/client receives DSCP message, DHCP module of 532 non-DSCP server/client can ignore the message because there are no 533 DHCP message type. BOOTP module would also discard the message 534 because there are no hardware address information, actually all 0s. 536 The second one is to define DHCP message type option again to include 537 DSCP messages types by undefined message codes. this does not 538 increase the number of DHCP options, while some DHCP implementation 539 may need to be modified. 541 The third one is to define DSCP mode option. In this case, if a 542 server or client finds this option in a message, they assume that the 543 message is DSCP. Some DHCP implementations may be confused, if they 544 receives this message. 546 The first method is adopted in this document. 548 7.2. Leased IP subnet address representation 550 Originally, DHCP has two important fields to represent leased host 551 address, ciaddr field in common header and requested IP address 553 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 555 option. In same idea, DSCP could use same field and option to 556 represent leased IP subnet address. 558 Another idea is to define dedicated option for leased IP subnet 559 address representation. The merit of this method is less impact to 560 existing non-DSCP server/client. Especially, in the case of 561 DSCPREQUEST message with filled ciaddr field is sent by broadcast to 562 extend lease time, non-DSCP server might return DHCPNAK message, 563 because of subnet address range, actually reserved for subnet 564 address. But this possibility would be very low or zero, since 565 DSCPREQUEST message would be sent by unicast. Moreover, the server 566 would be identified by siaddr, so non-DSCP server would discard the 567 message immediately. 569 Since it is assumed that all non-DSCP server/client ignores all DSCP 570 messages, the former method is applied. 572 7.3. DSCPDECLINE message 574 DHCPDECLINE message is defined as client to server indicating network 575 address is already used. The DHCP client can detect duplicated host 576 addresses by ARP, if the host which use same address is alive. In the 577 case of DSCP, how the client could detect duplicated subnet 578 addresses? 580 Generally, it is not so easy. But there are some special cases to 581 detect it easily. The first case is that like a router, which works 582 as DSCP client, detects that multiple ports of itself uses same IP 583 subnet address. Another possibility is detection by dynamic routing 584 protocol. Some routing protocol can figure out the network topology 585 and could detect the duplicated subnet address. But it might be not 586 so easy to run dynamic routing protocol with dynamically assigned 587 subnet address. 589 Anyway, DSCPDECLINE message should be defined for same multiple port 590 address and future technique. 592 7.4. Name operation 594 Is the function to change the subnet name which has been registered 595 into DSCP server? To do it, should new option 'old subnet name' be 596 defined? 598 7.5. Option set format 600 Currently there are several options proposed by this document 601 including this section 'Discussion'. 603 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 605 Subnet name option 606 DSCP message type 607 New subnet option 608 Subnet resource inheritance option 609 Subnet name precedence option 611 Should these option be defined as separated option or as integrated 612 option like as encapsulated vender specific information? 614 8. Future Work 616 Our next step for this project is to specify protocol specification 617 based on this idea, of course with considering all feed-backs. 618 Therefore, all comments, questions and requests are welcome. 620 9. Security Considerations 622 Current DHCP does not have function for security. 624 DSCP security adopts the same security functionalities as DHCP. In 625 addition, some authentication and/or encryption mechanisms might be 626 necessary. The detail is further study. 628 Reference 630 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 631 1997. 633 [2] Alexander, S., Droms, R., "BOOTP Vendor Information Extensions", 634 RFC 2132, March 1997. 636 [3] Laubach, L., "Classical IP over ATM", RFC1577, January 1994. 638 Author's Address 640 Kunihiro Taniguchi 642 CCRL, 643 NEC USA Inc. 644 110 Rio Robles, 645 San Jose, CA 95134 647 Phone: (408) 943-3031 649 EMail: taniguti@ccrl.sj.nec.com 651 DRAFT Dynamic Subnet Configuration Protocol 2 March 1998 653 Takeshi Nishida 655 CCRL, 656 NEC USA Inc. 657 110 Rio Robles, 658 San Jose, CA 95134 660 Phone: (408) 943-3030 662 EMail: nishida@ccrl.sj.nec.com