idnits 2.17.1 draft-ietf-dhc-csr-07.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [3], [6,7], [4], [5], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document obsoletes draft-ietf-dhc-csr-06.txt, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == 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). -- No information found for rfcdraft-ietf-dhc-csr-06.txt - is the name correct? -- 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) ** Downref: Normative reference to an Historic RFC: RFC 1058 (ref. '5') ** Downref: Normative reference to an Historic RFC: RFC 1878 (ref. '9') Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Ted Lemon 2 Internet Draft Nominum, Inc. 3 Obsoletes: draft-ietf-dhc-csr-06.txt Stuart Cheshire 4 Apple Computer, Inc. 5 Bernie Volz 6 Ericsson 8 July, 2002 9 Expires January, 2003 11 The Classless Static Route Option for DHCPv4 12 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as 28 "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This document defines a new DHCP option which is passed from the 39 DHCP Server to the DHCP Client to configure a list of static routes 40 in the client. The network destinations in these routes are 41 classless - each routing table entry includes a subnet mask. 43 Introduction 45 This option supersedes the Static Route option (option 33) defined 46 in RFC2132 [2]. 48 The IP protocol [4] uses routers to transmit packets from hosts 49 connected to one IP subnet to hosts connected to a different IP 50 subnet. When an IP host (the source host) wishes to transmit a 51 packet to another IP host (the destination), it consults its 52 routing table to determine the IP address of the router that should 53 be used to forward the packet to the destination host. 55 The routing table on an IP host can be maintained in a variety of 57 ^L 58 ways - using a routing information protocol such as RIP [5], ICMP 59 router discovery [6,7] or using the DHCP Router option, defined in 60 RFC2132 [2]. 62 In a network that already provides DHCP service, using DHCP to 63 update the routing table on a DHCP client has several virtues. It 64 is efficient, since it makes use of messages that would have been 65 sent anyway. It is convenient - the DHCP server configuration 66 is already being maintained, so maintaining routing information, at 67 least on a relatively stable network, requires little extra work. 68 If DHCP service is already in use, no additional infrastructure 69 need be deployed. 71 The DHCP protocol as defined in RFC2131 [1] and the options defined 72 in RFC2132 [2] only provide a mechanism for installing a default 73 route or installing a table of classful routes. Classful routes 74 are routes whose subnet mask is implicit in the subnet number - see 75 section 3.2 of RFC791 [4] for details on classful routing. 77 Classful routing is no longer in common use, so the DHCP Static 78 Route option is no longer useful. Currently, classless routing, 79 described in [8] and [9], is the most commonly-deployed form of 80 routing on the Internet. In classless routing, IP addresses 81 consist of a network number (the combination of the network number 82 and subnet number described in [8]) and a host number. 84 In classful IP, the network number and host number are derived from 85 the IP address using a bitmask whose value is determined by the 86 first few bits of the IP address. In classless IP, the network 87 number and host number are derived from the IP address using a 88 seperate quantity, the subnet mask. In order to determine the 89 network to which a given route applies, an IP host must know both 90 the network number AND the subnet mask for that network. 92 The Static Routes option (option 33) does not provide a subnet mask 93 for each route - it is assumed that the subnet mask is implicit in 94 whatever network number is specified in each route entry. The 95 Classless Static Routes option does provide a subnet mask for each 96 entry, so that the subnet mask can be other than what would be 97 determined using the algorithm specified in RFC791 [4] and RFC950 98 [8]. 100 Definitions 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [3]. 106 This document also uses the following terms: 108 "DHCP client" 110 DHCP client or "client" is an Internet host using DHCP to 111 obtain configuration parameters such as a network address. 113 ^L 115 "DHCP server" 117 A DHCP server or "server" is an Internet host that returns 118 configuration parameters to DHCP clients. 120 "link" 122 Any set of all network attachment points that will recieve 123 a link-layer broadcast sent on any one of the attachment 124 points. This term is used in DHCP because in some cases 125 more than one IP subnet may be configured on a link. DHCP 126 uses a local-network (all-ones) broadcast, which is not 127 subnet-specific, and will therefore reach all nodes 128 connected to the link, regardless of the IP subnet or 129 subnets on which they are configured. 131 A "link" is sometimes referred to as a broadcast domain or 132 physical network segment. 134 Classless Route Option Format 136 The code for this option is TBD, and its minimum length is 5 bytes. 137 This option can contain one or more static routes, each of which 138 consists of a destination descriptor and the IP address of the 139 router that should be used to reach that destination. 141 Code Len Destination 1 Router 1 142 +-----+---+----+-----+----+----+----+----+----+ 143 | TBD | n | d1 | ... | dN | r1 | r2 | r3 | r4 | 144 +-----+---+----+-----+----+----+----+----+----+ 146 Destination 2 Router 2 147 +----+-----+----+----+----+----+----+ 148 | d1 | ... | dN | r1 | r2 | r3 | r4 | 149 +----+-----+----+----+----+----+----+ 151 In the above example, two static routes are specified. 153 Destination descriptors describe the IP subnet number and subnet 154 mask of a particular destination using a compact encoding. This 155 encoding consists of one octet describing the width of the subnet 156 mask, followed by all the significant octets of the subnet number. 158 The width of the subnet mask describes the number of one bits in 159 the mask, so for example a subnet with a subnet number of 160 10.0.127.0 and a netmask of 255.255.255.0 would have a subnet mask 161 width of 24. 163 The significant portion of the subnet number is simply all of the 164 octets of the subnet number where the corresponding octet in the 165 subnet mask is non-zero. The number of significant octets is the 166 width of the subnet mask divided by eight, rounding up, as shown 168 ^L 169 in the following table: 171 Width of subnet mask Number of significant octets 172 0 0 173 1- 8 1 174 9-16 2 175 17-24 3 176 25-32 4 178 The following table contains some examples of how various subnet 179 number/mask combinations can be encoded: 181 Subnet number Subnet mask Destination descriptor 182 0 0 0 183 10.0.0.0 255.0.0.0 8.10 184 10.0.0.0 255.255.255.0 24.10.0.0 185 10.17.0.0 255.255.0.0 16.10.17 186 10.27.129.0 255.255.255.0 24.10.27.129 187 10.229.0.128 255.255.255.128 25.10.229.0.128 188 10.198.122.47 255.255.255.255 32.10.198.122.47 190 Local Subnet Routes 192 In some cases more than one IP subnet may be configured on a link. 193 In such cases, a host whose IP address is in one IP subnet in the 194 link could communicate directly with a host whose IP address is in 195 a different IP subnet on the same link. In cases where a client is 196 being assigned an IP address on an IP subnet on such a link, 197 for each IP subnet in the link other than the IP subnet on which 198 the client has been assigned the DHCP server MAY be configured to 199 specify a router IP address of 0.0.0.0. 201 For example, consider the case where there are three IP subnets 202 configured on a link: 10.0.0/24, 192.168.0/24, 10.0.21/24. If the 203 client is assigned an IP address of 10.0.21.17, then the server 204 could include a route with a destination of 10.0.0/24 and a router 205 address of 0.0.0.0, and also a route with a destination of 206 192.168.0/24 and a router address of 0.0.0.0. 208 A DHCP client whose underlying TCP/IP stack does not provide this 209 capability MUST ignore routes in the Classless Static Routes option 210 whose router IP address is 0.0.0.0. Please note that the behavior 211 described here only applies to the Classless Static Routes option, 212 not to the Static Routes option nor the Router option. 214 DHCP Client Behavior 216 DHCP clients that do not support this option MUST ignore it if it 217 is received from a DHCP server. DHCP clients that support this 218 option MUST install the routes specified in the option, except as 219 specified in the Local Subnet Routes section. DHCP clients that 220 support this option MUST NOT install the routes specified in the 221 Static Routes option (option code 33) if both a Static Routes 222 option and the Classless Static Routes option are provided. 224 ^L 225 DHCP clients that support this option and that send a DHCP 226 Parameter Request List option MUST request both this option and the 227 Router option [2] in the DHCP Parameter Request List. 229 DHCP clients that support this option and send a parameter request 230 list MAY also request the Static Routes option, for compatibility 231 with older servers that don't support Classless Static Routes. 232 The Classless Static Routes option code MUST appear in the 233 parameter request list prior to both the Router option code and the 234 Static Routes option code, if present. 236 If the DHCP server returns both a Router option and a Classless 237 Static Routes option, the DHCP client MUST ignore the Router 238 option. 240 After deriving a subnet number and subnet mask from each 241 destination descriptor, the DHCP client MUST set any bits in the 242 subnet number that are zero in the subnet mask to zero. For 243 example, if the server sends a route with a destination of 244 129.210.177.132 (hexadecimal 81D4B184) and a subnet mask of 245 255.255.255.128 (hexadecimal FFFFFF80), the client will install a 246 route with a destination of 129.210.177.128 (hexadecimal 247 81D4B180). 249 Requirements to avoid sizing constraints 251 Because a full routing table can be quite large, the standard 576 252 octet maximum size for a DHCP message may be too short to contain 253 some legitimate Classless Static Route options. Because of this, 254 clients implementing the Classless Static Route option SHOULD send 255 a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP 256 stack is capable of reassembling fragmented IP datagrams. In this 257 case, the client SHOULD set the value of this option to at least 258 the MTU of the interface that the client is configuring. The 259 client MAY set the value of this option higher, up to the size of 260 the largest UDP packet it is prepared to accept. (Note that the 261 value specified in the Maximum DHCP Message Size option is the 262 total maximum packet size, including IP and UDP headers.) 264 DHCP servers sending this option MUST use the technique described 265 in [10] for sending options larger than 255 bytes when storing this 266 option in outgoing DHCP packets. DHCP clients supporting this 267 option MUST support the technique described in [10] when reading 268 this option from incoming DHCP packets. 270 DHCP Server administrator responsibilities 272 Many clients may not implement the Classless Static Routes option. 273 DHCP server administrators should therefore configure their DHCP 274 servers to send both a Router option and a Classless Static Routes 275 option, and should specify the default router(s) both in the 276 Router option and in the Classless Static Routes option. 278 DHCP Server Considerations 280 ^L 281 When a DHCP client requests the Classless Static Routes option and 282 also requests either or both of the Router option and the Static 283 Routes option, and the DHCP server is sending Classless Static 284 Routes options to that client, the server SHOULD NOT include the 285 Router or Static Routes options. 287 Security Considerations 289 Potential exposures to attack in the DHCP protocol are discussed in 290 section 7 of the DHCP protocol specification [1] and in 291 Authentication for DHCP Messages [5]. 293 The Classless Static Routes option can be used to misdirect network 294 traffic by providing incorrect IP addresses for routers. This can 295 be either a Denial of Service attack, where the router IP address 296 given is simply valid, or can be used to set up a man-in-the-middle 297 attack by providing the IP address of a potential snooper. This is 298 not a new problem - the existing Router and Static Routes options 299 defined in RFC2132 [2] exhibit the same vulnerability. 301 IANA Considerations 303 This DHCP option will require the allocation of an option code in 304 the list of DHCP option codes that the IANA maintains. 306 References 308 [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 309 Bucknell University, March 1997. 310 [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 311 Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell 312 University, March 1997. 313 [3] Bradner, S., "Key words for use in RFCs to indicate requirement 314 levels", RFC 2119, Harvard University, March 1997. 315 [4] Postel, J., "Internet Protocol", RFC 791, USC/Information 316 Sciences Institute, September 1981. 317 [5] Hedrick, C.L., "Routing Information Protocol", RFC 1058, 318 Rutgers University, June 1, 1988. 319 [6] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 320 Xerox PARC, September 1991. 321 [7] Postel, J., "Internet Control Message Protocol", RFC 792, 322 USC/Information Sciences Institute, September 1981. 323 [8] Mogul, J., Postel, J., "Internet Standard Subnetting 324 Procedure", RFC950, Stanford University, USC/Information 325 Sciences Institute, August 1985. 326 [9] Pummill, T., Manning, B., "Variable Length Subnet Table For 327 IPv4", RFC1878, Alantec, USC/Information Sciences Institute, 328 December, 1995. 329 [10] Lemon, T., Cheshire, S., "Encoding Long DHCP Options", 330 draft-ietf-dhc-concat-05.txt, Nominum, Inc., Apple Computer, 331 Inc., July, 2002. 333 ^L 335 Author Information 337 Ted Lemon 338 Nominum, Inc. 339 2385 Bay Road 340 Redwood City, CA 94063 341 email: Ted.Lemon@nominum.com 343 Stuart Cheshire 344 Apple Computer, Inc. 345 1 Infinite Loop 346 Cupertino 347 California 95014 348 USA 349 Phone: +1 408 974 3207 350 EMail: rfc@stuartcheshire.org 352 Bernie Volz 353 Ericsson 354 959 Concord Street 355 Framingham, MA, 01701 356 Phone: +1 508 875 3162 357 EMail: bernie.volz@ericsson.com 359 Expiration 361 This document will expire on December 31, 2002. 363 Full Copyright Statement 365 Copyright (C) The Internet Society (2000-2002). All Rights 366 Reserved. 368 This document and translations of it may be copied and furnished to 369 others, and derivative works that comment on or otherwise explain it 370 or assist in its implementation may be prepared, copied, published 371 and distributed, in whole or in part, without restriction of any 372 kind, provided that the above copyright notice and this paragraph are 373 included on all such copies and derivative works. However, this 374 document itself may not be modified in any way, such as by removing 375 the copyright notice or references to the Internet Society or other 376 Internet organizations, except as needed for the purpose of 377 developing Internet standards in which case the procedures for 378 copyrights defined in the Internet Standards process must be 379 followed, or as required to translate it into languages other than 380 English. 382 The limited permissions granted above are perpetual and will not be 383 revoked by the Internet Society or its successors or assigns. 385 ^L 386 This document and the information contained herein is provided on an 387 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 388 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 389 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 390 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 391 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.