idnits 2.17.1 draft-ietf-dhc-nextserver-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 408 lines 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (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) ** Obsolete normative reference: RFC 2489 (Obsoleted by RFC 2939) -- Possible downref: Non-RFC (?) normative reference: ref. 'RSIP-FRAME' -- Possible downref: Non-RFC (?) normative reference: ref. 'RSIP-PROTO' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-UC' -- Possible downref: Non-RFC (?) normative reference: ref. 'DHC-AUTH' ** Obsolete normative reference: RFC 2052 (Obsoleted by RFC 2782) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Jerome Privat 2 INTERNET-DRAFT BT 3 Date: March 2000 Michael Borella 4 Expires: August 2000 3Com Corp 6 DHCP Next Server Option 7 9 Status of This Memo 11 The document is an Internet-Draft and is in full conformance with all 12 of the provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Intenet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This proposal allows host configuration to be split between two 33 different address servers, potentially under different 34 administration. 35 This ability may be useful to satisfy specific regulatory, 36 operational or business model requirements, as well as to 37 provide support for secondary address servers. This draft 38 proposes two new DHCP options called the DHCP Next Server 39 DNS name option and the DHCP Next Server IP address option. 40 A DHCP server can use these options to redirect clients to a 41 secondary server. 43 1. Introduction 45 The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a 46 mechanism for the assignment of addressing and other parameters from 47 a server to a client. In order to extend DHCP's abilities, a 48 process for defining new DHCP options has been established [RFC2489]. 49 This document defines two new DHCP options for redirecting requests 50 to a secondary address server. This secondary server may or may not 51 be a DHCP server. In particular, we consider DHCP redirect to an 52 RSIP [RSIP-FRAME] server. 54 2. Terminology 56 - DHCP client 58 A DHCP client is an Internet host using DHCP to obtain configuration 59 parameters such as a network address. 61 - DHCP server 63 A DHCP server is an Internet host that returns configuration 64 parameters to DHCP clients. 66 - Realm Specific IP (RSIP) 68 A method through which a client from one addressing realm can 69 assume and utilize addressing and configuration parameters from a 70 second addressing realm [RSIP-FRAME]. 72 - RSIP Server 74 A router situated on the boundary between a private realm and a 75 public realm and owns one or more public IP addresses. An RSIP 76 server is responsible for public parameter management and 77 assignment to RSIP clients. 79 - RSIP Client 81 A host within the private realm that assumes publicly unique 82 parameter sets from an RSIP server through the use of RSIP. 84 3. Specification of Requirements 86 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 88 this documents are to be interpreted as described in [RFC2119]. 90 4. Architecture 92 Our proposed architecture is as follows. Client host configuration 93 information is split between two different address servers, 94 potentially under different administrative control. The primary 95 (most local) address server is always a DHCP server. The secondary 96 address server may or may not be DHCP. 98 The primary server manages IP addresses. More precisely, it allocates 99 an IP address, a network mask and a default router to clients. It 100 MAY also manage other parts of the configuration. The secondary 101 server manages the rest of the configuration. 103 Partition of the configuration information (other than IP address, 104 network mask and default router) between the two servers is a matter 105 of policy and agreement between administrators of the two servers. It 106 is out of the scope of this document. 108 5. Redirect to Secondary Server 110 We define two new DHCP options called the DHCP Next Server 111 DNS name option and the DHCP Next Server IP address option. 112 These options are used by a DHCP server to indicate to a 113 DHCP client respectively, the DNS name and the IP address of a 114 secondary server from where it can retrieve other parts of its 115 configuration. 117 The utility of these options is that they allow a client to discover 118 a secondary configuration server even if that server is not on the 119 same logical subnet as the client. For example, a client might use 120 a UDP broadcast on a particular port number to discover a 121 configuration server. However, these broadcasts, with the exception 122 of DHCP/BOOTP traffic, will be dropped by first-hop routers. By 123 allowing DHCP servers to provide a secondary server's address or 124 DNS name to a client, the client is able to contact that server 125 directly, using whatever protocol is necessary. 127 6. Next Server Options 129 These options are DHCP options [RFC2131, RFC2489]. Next Server 130 Options are returned in DHCPOFFER and DHCPACK by a DHCP server. 132 6.1. Next Server IP address option 134 The Next Server IP address Option specifies a list of IP 135 addresses for secondary servers (Multiple addresses of 136 secondary servers MAY be provided for robustness). 137 Secondary servers MUST be listed in order of preference, if 138 there is an order of preference. 140 The code for this option is TBD, and its length is N. 141 The Length value must include one for the 'Proto' byte and 142 include four for each Secondary Server address which follows; 143 it has has a minimum value of 5. 144 The Length minus one of the option MUST always be divisible 145 by 4. 147 The address of the Secondary Server is given in network byte order. 149 The "Proto field" p indicates the protocol to use to contact 150 the secondary server. 152 More than one Next Server IP address Option MAY be provided 153 to a client. However each of these options MUST contain different 154 protocol fields. 156 Code Len Proto Address 157 +-----+-----+-----+-----+-----+-----+-----+-----+ 158 | TBD | N | p | a1 | a2 | a3 | a4 | ... | 159 +-----+-----+-----+-----+-----+-----+-----+-----+ 161 6.2. Next Server DNS name option 163 This option specifies the DNS [RFC1035] name for 164 the secondary server. 165 The code for this option is TBD, and its length is N. 166 The Length value is equal to one plus the length of the 167 DNS name string. Thus the maximum length of the DNS name 168 string is 254 octets. 170 Code Len Proto DNS name of secondary server 171 +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 172 | TBD | N | p | s1 | s2 | s3 | s4 | s5 | ... | 173 +-----+-----+-----+-----+-----+-----+-----+-----+-----+ 175 The "Proto field" p indicates the protocol to use to contact 176 the secondary server. 177 More than one Next Server DNS name Option MAY be provided 178 to a client. However each of these options MUST contain 179 different protocol fields. 180 The reason for defining this option in addition to the 181 Next Server IP address option is that it allows implementation 182 of load-balancing by using an SRV [RFC2052] query. 184 c. Protocol field 186 Initial values for p, the protocol to use to contact the secondary 187 server, are defined below: 189 0 Reserved 190 1 DHCP 191 2 RSIP 193 New values for p MAY be registered with IANA. 195 Note on the scope of these options: 196 These options are meant to redirect the client in situations 197 where further configuration transactions may be necessary but 198 not to replace other options in general. Thus new values of p 199 should only be attributed for protocols used by clients to 200 retrieve part of their configuration. 202 If a client receives a Next Server Option with a protocol that it 203 does not support, the client MUST silently ignore the fact that 204 it has been referred to a secondary server. 206 7. DHCP Server as Secondary Server 208 In this section we use the term Next Server Option to mean 209 either Next Server IP address option or Next Server DNS 210 name option. 212 If a DHCP server is indicated by the protocol field of the 213 Next Server Option, a DHCP client SHOULD send a DHCPINFORM to 214 the server identified in the Next Server Option field to 215 retrieve the rest of its configuration via DHCP. A typical 216 double-phase DHCP configuration using the DHCP next server 217 option is: 219 - A DHCP client broadcasts a DHCPDISCOVER. It receives a 220 DHCPOFFER from the primary DHCP server containing (at least) 221 a proposed IP address, a network mask and a default router. 223 - Based on its local policy, the primary DHCP server 224 returns a Next Server Option or not. This decision, as well 225 as the address or DNS name returned in the Next Server 226 Option, MAY be based on some of the options in the client 227 request such as the 'client identifier' option or the 228 'user class' option [DHC-UC]. 230 - The DHCP client and the primary DHCP server finish their 231 DHCP exchange in the standard way. 233 - If a Next Server Option was present and it indicates 234 that the secondary server is a DHCP server, then the DHCP 235 client SHOULD send a DHCPINFORM to the server indicated 236 in the option. 238 Note that the two phases are independent of each other. 239 In this way, a failure of the second phase does not affect 240 the first one. 242 The 'siaddr' field is used by a DHCP server to tell a DHCP 243 client the IP address of the server to use in the next step 244 of the client bootstrap process [RFC2131]. The proposed 245 option differs from the 'siaddr' field in that the Next 246 Server Option is used by the DHCP client not to retrieve 247 a boot file, but other parts of its configuration. 249 8. RSIP Server as Secondary Server 251 In this section we use the term Next Server Option to mean 252 either Next Server IP address option or Next Server DNS 253 name option. 255 If an RSIP server is indicated in the Next Server Option, 256 the client SHOULD contact the RSIP server using the RSIP 257 protocol [RSIP-PROTO]. 258 The typical double phase redirect configuration with RSIP 259 is: 261 - A DHCP client broadcasts a DHCPDISCOVER. It receives 262 a DHCPOFFER from the primary DHCP server containing 263 (at least) a proposed IP address, a network mask and a 264 default router. 266 - Based on its local policy, the primary DHCP server 267 returns a Next Server Option or not. This decision, as 268 well as the address or domain name returned in the Next 269 Server Option, MAY be based on some of the options in 270 the client request such as the 'client identifier' option 271 or the 'user class' option [DHC-UC]. 273 - The client and the primary DHCP server finish their DHCP 274 exchange in the standard way. 276 - If the Next Server Option was present and it indicates 277 that the secondary server is an RSIP server, then the client 278 SHOULD send an RSIP REGISTER_REQUEST message to the server 279 indicated in the option. 281 - The RSIP protocol continues as defined in [RSIP-PROTO]. 283 Note that the two phases are independent of each other. 284 In this way, a failure of the second phase does not affect 285 the first one. 287 9. Security Considerations 289 The IP address of the secondary server may depend on some 290 options sent by the client such as the 'client identifier' 291 option or the 'user class' option [DHC-UC]. A client giving 292 false information in one of these options could have access 293 to some configuration information to which it is not entitled. 294 Authentication [DHC-AUTH] and policy at the DHCP server SHOULD 295 be used to prevent that happening. 297 10. Acknowledgements 299 Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their 300 review and comments. 301 Thanks to Mike Henry for his comments. 302 The introduction of the DHCP Next Server DNS name option was 303 suggested by the use of a similar option defined in the DHCP 304 option for SIP server draft by G. Nair and H. Schulzrinne. 306 11. References 308 [RFC2119] S. Bradner, "Key words for use in RFCs to indicate 309 requirement levels," RFC 2119, Mar. 1997. 311 [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", 312 RFC 2131, Mar. 1997. 314 [RFC2489] R. Droms, "Procedure for Defining New DHCP Options", 315 RFC 2489, Jan. 1999. 317 [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky and G. Montenegro, 318 "Realm Specific IP: Framework" Internet Draft 319 , Oct. 1999 (work in progress). 321 [RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi, 322 "Realm Specific IP: Protocol Specification," Internet Draft 323 , Jan. 2000 (work in progress). 325 [DHC-UC] G. Stump, R. Droms, Y. Gu, A. Demirtjis, B. Beser, and 326 J. Privat, "The User Class Option for DHCP", Internet Draft 327 , Feb. 2000 (work in progress). 329 [DHC-AUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", 330 (work in progress). 332 [RFC1035] P. V. Mockapetris, "Domain names - implementation and 333 specification", RFC1035, Nov. 1997. 335 [RFC2052] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying 336 the location of services (DNS SRV)", RFC2052, Oct. 1996. 338 12. Authors' Addresses 340 Jerome Privat 341 BT Advanced Communications Technology Centre 342 Adastral Park, Martlesham Heath, IP5 3RE 343 UK 344 +44 1473 606304 345 jerome.privat@bt.com 347 Michael Borella 348 3Com Corp. 349 1800 W. Central Rd. 350 Mount Prospect IL 60056 351 USA 352 (847) 342-6093 353 mike_borella@3com.com 355 13. Expiration 357 This document will expire on August 2000. 359 Copyright Statement 361 Copyright (c) The Internet Society (1999). All Rights Reserved. 362 This document and translations of it may be copied and furnished to 363 others, and derivative works that comment on or otherwise explain it 364 or assist in its implementation may be prepared, copied, published 365 and distributed, in whole or in part, without restriction of any 366 kind, provided that the above copyright notice and this paragraph are 367 included on all such copies and derivative works. However, this 368 document itself may not be modified in any way, such as by removing 369 the copyright notice or references to the Internet Society or other 370 Internet organizations, except as needed for the purpose of 371 developing Internet standards in which case the procedures for 372 copyrights defined in the Internet Standards process must be 373 followed, or as required to translate it into languages other than 374 English. 376 The limited permissions granted above are perpetual and will not be 377 revoked by the Internet Society or its successors or assigns. 379 This document and the information contained herein is provided on an 380 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 381 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 382 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 383 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 384 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.