idnits 2.17.1 draft-ietf-dhc-agent-options-11.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: ---------------------------------------------------------------------------- ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 12 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 13 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 10 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([2], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 298 has weird spacing: '...s. This inclu...' -- 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.) -- The document date (July 13, 2000) is 8660 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) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '6' Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT 3 DHC Working Grop Michael Patrick 4 Motorola BCS 5 July 13, 2000 7 DHCP Relay Agent Information Option 9 Status of this Memo 11 This document is an Internet Draft and is in full conformance of 12 section 10 of RFC2026. Internet Drafts are working documents of the 13 Internet Engineering Task Force (IETF), its Areas, and its Working 14 Groups. Note that other groups may also distribute working documents 15 as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shado Directories can be accessed at 27 http://ww.ietf.org/shadow.html 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [4]. 33 Abstract 35 Newer high-speed public Internet access technologies call for a 36 high-speed modem to have a LAN attachment to one or more customer 37 premise hosts. It is advantageous to use the Dynamic Host 38 Configuration Protocol as defined in RFC 2131 [1] to assign customer 39 premise host IP addresses in this environment. However, a number of 40 security and scaling problems arise with such "public" DHCP use. 41 This document describes a new DHCP option to address these issues. 42 This option extends the set of DHCP options as defined in RFC 2132 43 [2]. 45 July 13, 2000 47 The new option is called the Relay Agent Information option and is 48 inserted by the DHCP relay agent when forwarding client-originated 49 DHCP packets to a DHCP server. Servers recognizing the Relay Agent 50 Information option may use the information to implement IP address or 51 other parameter assignment policies. The DHCP Server echoes the 52 option back verbatim to the relay agent in server-to-client replies, 53 and the relay agent strips the option before forwarding the reply to 54 the client. 56 The "Relay Agent Information" option is organized as a single DHCP 57 option that contains one or more "sub-options" that convey 58 information known by the relay agent. The initial sub-options are 59 defined for a relay agent that is co-located in a public circuit 60 access unit. These include a "circuit ID" for the incoming circuit, 61 and a "remote ID" which provides a trusted identifier for the remote 62 high-speed modem. 64 Table of Contents 66 1 Introduction........................................... 2 67 1.1 High-Speed Circuit Switched Data Networks.............. 2 68 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 69 2.0 Relay Agent Information Option......................... 5 70 2.1 Agent Operation........................................ 6 71 2.1.1 Reforwarded DHCP requests............................ 7 72 2.2 Server Operation....................................... 7 73 3.0 Relay Agent Information Suboptions..................... 8 74 3.1 Agent Circuit ID....................................... 8 75 3.2 Agent Remote ID........................................ 9 76 4.0 Issues Resolved........................................ 10 77 5.0 Security Considerations................................ 11 78 6.0 IANA Considerations.................................... 11 79 7.0 Intellectual Property Notice........................... 12 80 8.0 References............................................. 12 81 9.0 Glossary............................................... 13 82 10.0 Author's Address...................................... 13 84 1 Introduction 86 1.1 High-Speed Circuit Switched Data Networks 88 Public Access to the Internet is usually via a circuit switched data 89 network. Today, this is primarily implemented with dial-up modems 90 connecting to a Remote Access Server. But higher speed circuit 91 access networks also include ISDN, ATM, Frame Relay, and Cable Data 92 Networks. All of these networks can be characterized as a "star" 94 July 13, 2000 96 topology where multiple users connect to a "circuit access unit" via 97 switched or permanent circuits. 99 With dial-up modems, only a single host PC attempts to connect to the 100 central point. The PPP protocol is widely used to assign IP 101 addresses to be used by the single host PC. 103 The newer high-speed circuit technologies, however, frequently 104 provide a LAN interface (especially Ethernet) to one or more host 105 PCs. It is desirable to support centralized assignment of the IP 106 addresses of host computers connecting on such circuits via DHCP. 107 The DHCP server can be, but usually is not, co-implemented with the 108 centralized circuit concentration access device. The DHCP server is 109 often connected as a separate server on the "Central LAN" to which 110 the central access device (or devices) attach. 112 A common physical model for high-speed Internet circuit access is 113 shown in Figure 1, below. 115 +---------------+ | 116 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A 117 LAN | | Access | Lan |- Host B 118 | | Unit 1 | |- Host C 119 |-----| |-- | 120 | |(relay agent) |... 121 +---------+ | +---------------+ 122 | DHCP |--| 123 | Server | | 124 +---------+ | 125 | 126 | +---------------+ 127 +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D 128 | Other | | | Access | Lan 129 | Servers |--|-----| Unit 2 | 130 | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E 131 | DNS) | | |(relay agent) |... Lan 132 | | +---------------+ 133 +---------+ 134 Figure 1: DHCP High Speed Circuit Access Model 136 Note that in this model, the "modem" connects to a LAN at the user 137 site, rather than to a single host. Multiple hosts are implemented at 138 this site. Although it is certainly possible to implement a full IP 139 router at the user site, this requires a relatively expensive piece 141 July 13, 2000 143 of equipment (compared to typical modem costs). Furthermore, a 144 router requires an IP address not only for every host, but for the 145 router itself. Finally, a user-side router requires a dedicated 146 Logical IP Subnet (LIS) for each user. While this model is 147 appropriate for relatively small corporate networking environments, 148 it is not appropriate for large, public accessed networks. In this 149 scenario, it is advantageous to implement an IP networking model that 150 does not allocate an IP address for the modem (or other networking 151 equipment device at the user site), and especially not an entire LIS 152 for the user side LAN. 154 Note that using this method to obtain IP addresses means that IP 155 addresses can only be obtained while communication to the central 156 site is available. Some host lan installations may use a local DHCP 157 server or other methods to obtain IP addresses for in-house use. 159 1.2 DHCP Relay Agent in the Circuit Access Unit 161 It is desirable to use DHCP to assign the IP addresses for public 162 high-speed circuit access. A number of circuit access units (e.g. 163 RAS's, cable modem termination systems, ADSL access units, etc) 164 connect to a LAN (or local internet) to which is attached a DHCP 165 server. 167 For scaling and security reasons, it is advantageous to implement a 168 "router hop" at the circuit access unit, much like high-capacity 169 RAS's do today. The circuit access equipment acts as both a router 170 to the circuits and as the DHCP relay agent. 172 The advantages of co-locating the DHCP relay agent with the circuit 173 access equipment are: 175 DHCP broadcast replies can be routed to only the proper circuit, 176 avoiding, say, the replication of the DCHP reply broadcast onto 177 thousands of access circuits; 179 The same mechanism used to identify the remote connection of the 180 circuit (e.g. a user ID requested by a Remote Access Server acting as 181 the circuit access equipment) may be used as a host identifier by 182 DHCP, and used for parameter assignment. This includes centralized 183 assignment of IP addresses to hosts. This provides a secure remote 184 ID from a trusted source -- the relay agent. 186 A number of issues arise when forwarding DHCP requests from hosts 187 connecting publicly accessed high-speed circuits with LAN connections 188 at the host. Many of these are security issues arising from DHCP 189 client requests from untrusted sources. How does the relay agent 190 know to which circuit to forward replies? How does the system 192 July 13, 2000 194 prevent DHCP IP exhaustion attacks? This is when an attacker 195 requests all available IP addresses from a DHCP server by sending 196 requests with fabricated client MAC addresses. How can an IP address 197 or LIS be permanently assigned to a particular user or modem? How 198 does one prevent "spoofing" of client identifer fields used to assign 199 IP addresses? How does one prevent denial of service by "spoofing" 200 other client's MAC addresses? 202 All of these issues may be addressed by having the circuit access 203 equipment, which is a trusted component, add information to DHCP 204 client requests that it forwards to the DHCP server. 206 2.0 Relay Agent Information Option 208 This document defines a new DHCP Option called the Relay Agent 209 Information Option. It is a "container" option for specific agent- 210 supplied sub-options. The format of the Relay Agent Information 211 option is: 213 Code Len Agent Information Field 214 +------+------+------+------+------+------+--...-+------+ 215 | 82 | N | i1 | i2 | i3 | i4 | | iN | 216 +------+------+------+------+------+------+--...-+------+ 218 The length N gives the total number of octets in the Agent 219 Information Field. The Agent Information field consists of a sequence 220 of SubOpt/Length/Value tuples for each sub-option, encoded in the 221 following manner: 223 SubOpt Len Sub-option Value 224 +------+------+------+------+------+------+--...-+------+ 225 | 1 | N | s1 | s2 | s3 | s4 | | sN | 226 +------+------+------+------+------+------+--...-+------+ 227 SubOpt Len Sub-option Value 228 +------+------+------+------+------+------+--...-+------+ 229 | 2 | N | i1 | i2 | i3 | i4 | | iN | 230 +------+------+------+------+------+------+--...-+------+ 232 No "pad" sub-option is defined, and the Information field shall NOT 233 be terminated with a 255 sub-option. The length N of the DHCP Agent 234 Information Option shall include all bytes of the sub-option 235 code/length/value tuples. Since at least one sub-option must be 236 defined, the minimum Relay Agent Information length is two (2). The 237 length N of the sub-options shall be the number of octets in only 238 that sub-option's value field. A sub-option length may be zero. The 240 July 13, 2000 242 sub-options need not appear in sub-option code order. 244 The initial assignment of DHCP Relay Agent Sub-options is as follows: 246 DHCP Agent Sub-Option Descrption 247 Sub-option Code 248 --------------- ---------------------- 249 1 Agent Circuit ID Sub-option 250 2 Agent Remote ID Sub-option 252 2.1 Agent Operation 254 Overall adding of the DHCP relay agent option SHOULD be configurable, 255 and SHOULD be disabled by default. Relay agents SHOULD have separate 256 configurables for each sub-option to control whether it is added to 257 client-to-server packets. 259 A DHCP relay agent adding a Relay Agent Information field SHALL add 260 it as the last DHCP agent option in the DHCP options field of any 261 recognized BOOTP or DHCP packet forwarded from a client to a server. 263 Relay agents receiving a DHCP packet from an untrusted source with 264 giaddr set to zero (indicating that they are the first-hop router) 265 but with a Relay Agent Information option already present in the 266 packet SHALL discard the packet and increment an error count. A 267 trusted network element (e.g. a bridge) between the relay agent and 268 the client MAY add a relay agent option but not set the giaddr field. 269 In this case, the relay agent does NOT add a "second" relay agent 270 option, but forwards the DHCP packet per normal DHCP relay agent 271 operations. 273 Relay agents MAY have a configurable for the maximum size of the DHCP 274 packet to be created after appending the Agent Information option. 275 Packets which, after appending the Relay Agent Information option, 276 would exceed this configured maximum size shall be forwarded WITHOUT 277 adding the Agent Information option. An error counter SHOULD be 278 incremented in this case. In the absence of this configurable, the 279 agent SHALL NOT increase a forwarded DHCP packet size to exceed the 280 MTU of the interface on which it is forwarded. 282 The Relay Agent Information option echoed by a server MUST be removed 283 by the agent when forwarding a server-to-client response back to the 284 client. 286 July 13, 2000 288 The agent SHALL NOT add an "Option Overload" option to the packet or 289 use the "file" or "sname" fields for adding Relay Agent Information 290 option. It SHALL NOT parse or remove Relay Agent Information options 291 that may appear in the sname or file fields of a server-to-client 292 packet forwarded through the agent. 294 The operation of relay agents for specific sub-options is specified 295 with that sub-option. 297 Relay agents are NOT required to monitor or modify client-originated 298 DHCP packets addressed to a server unicast address. This includes 299 the DHCP-REQUEST sent when entering the RENEWING state. 301 Relay agents MUST NOT modify DHCP packets that use the IPSEC 302 Authentication Header or IPSEC Encapsulating Security Payload [6]. 304 2.1.1 Reforwarded DHCP requests 306 A DHCP relay agent may receive a client DHCP packet forwarded from a 307 BOOTP/DHCP relay agent closer to the client. Such a packet will have 308 giaddr as non-zero, and may or may not already have a DHCP Relay 309 Agent option in it. 311 Relay agents configured to add a Relay Agent option which receive a 312 client DHCP packet with a nonzero giaddr SHALL discard the packet if 313 the giaddr spoofs a giaddr address implemented by the local agent 314 itself. 316 Otherwise, the relay agent SHALL forward any received DHCP packet 317 with a valid non-zero giaddr WITHOUT adding any relay agent options. 318 Per RFC 2131, it shall also NOT modify the giaddr value. 320 2.2 Server Operation 322 DHCP servers unaware of the Relay Agent Information option will 323 ignore the option upon receive and will not echo it back on 324 responses. This is the specified server behavior for unknown 325 options. 327 DHCP servers claiming to support the Relay Agent Information option 328 SHALL echo the entire contents of the Relay Agent Information option 329 in all replies. Servers SHOULD copy the Relay Agent Information 330 option as the last DHCP option in the response. Servers SHALL NOT 331 place the echoed Relay Agent Information option in the overloaded 332 sname or file fields. If a server is unable to copy a full Relay 333 Agent Information field into a response, it SHALL send the response 334 without the Relay Information Field, and SHOULD increment an error 336 July 13, 2000 338 counter for the situation. 340 The operation of DHCP servers for specific sub-options is specified 341 with that sub-option. 343 Note that DHCP relay agents are not required to monitor unicast DHCP 344 messages sent directly between the client and server (i.e, those that 345 aren't sent via a relay agent). However, some relay agents MAY chose 346 to do such monitoring and add relay agent options. Consequently, 347 servers SHOULD be prepared to handle relay agent options in unicast 348 messages, but MUST NOT expect them to always be there. 350 3.0 Relay Agent Information Sub-options 352 3.1 Agent Circuit ID Sub-option 354 This sub-option MAY be added by DHCP relay agents which terminate 355 switched or permanent circuits. It encodes an agent-local identifier 356 of the circuit from which a DHCP client-to-server packet was 357 received. It is intended for use by agents in relaying DHCP 358 responses back to the proper circuit. Possible uses of this field 359 include 360 - Router interface number 361 - Switching Hub port number 362 - Remote Access Server port number 363 - Frame Relay DLCI 364 - ATM virtual circuit number 365 - Cable Data virtual circuit number 367 Servers MAY use the Circuit ID for IP and other parameter assignment 368 policies. The Circuit ID SHOULD be considered an opaque value, with 369 policies based on exact string match only; that is, the Circuit ID 370 SHOULD NOT be internally parsed by the server. 372 The DHCP server SHOULD report the Agent Circuit ID value of current 373 leases in statistical reports (including its MIB) and in logs. Since 374 the Circuit ID is local only to a particular relay agent, a circuit 375 ID should be qualified with the giaddr value that identifies the 376 relay agent. 378 SubOpt Len Circuit ID 379 +------+------+------+------+------+------+------+------+-- 380 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 381 +------+------+------+------+------+------+------+------+-- 383 July 13, 2000 385 3.2 Agent Remote ID Sub-option 387 This sub-option MAY be added by DHCP relay agents which terminate 388 switched or permanent circuits and have mechanisms to identify the 389 remote host end of the circuit. The Remote ID field may be used to 390 encode, for instance: 391 -- a "caller ID" telephone number for dial-up connection 392 -- a "user name" prompted for by a Remote Access Server 393 -- a remote caller ATM address 394 -- a "modem ID" of a cable data modem 395 -- the remote IP address of a point-to-point link 396 -- a remote X.25 address for X.25 connections 398 The remote ID MUST be globally unique. 400 DHCP servers MAY use this option to select parameters specific to 401 particular users, hosts, or subscriber modems. The option SHOULD be 402 considered an opaque value, with policies based on exact string match 403 only; that is, the option SHOULD NOT be internally parsed by the 404 server. 406 The relay agent MAY use this field in addition to or instead of the 407 Agent Circuit ID field to select the circuit on which to forward the 408 DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this 409 value in any reports or MIBs associated with a particular client. 411 SubOpt Len Agent Remote ID 412 +------+------+------+------+------+------+------+------+-- 413 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 414 +------+------+------+------+------+------+------+------+-- 416 July 13, 2000 418 4.0 Issues Resolved 420 The DHCP relay agent option resolves several issues in an environment 421 in which untrusted hosts access the intervet via a circuit based 422 public network. This resolution assumes that all DHCP protocol 423 traffic by the public hosts traverse the DHCP relay agent and that 424 the IP network between the DHCP relay agent and the DHCP server is 425 uncompromised. 427 Broadcast Forwarding 429 The circuit access equipment forwards the normally broadcasted 430 DHCP response only on the circuit indicated in the Agent Circuit 431 ID. 433 DHCP Address Exhaustion 435 In general, the DHCP server may be extended to maintain a database 436 with the "triplet" of 438 (client IP address, client MAC address, client remote ID) 440 The DHCP server SHOULD implement policies that restrict the number 441 of IP addresses to be assigned to a single remote ID. 443 Static Assignment 445 The DHCP server may use the remote ID to select the IP address to 446 be assigned. It may permit static assignment of IP addresses to 447 particular remote IDs, and disallow an address request from an 448 unauthorized remote ID. 450 IP Spoofing 452 The circuit access device may associate the IP address assigned by 453 a DHCP server in a forwarded DHCP Ack packet with the circuit to 454 which it was forwarded. The circuit access device MAY prevent 455 forwarding of IP packets with source IP addresses -other than- 456 those it has associated with the receiving circuit. This prevents 457 simple IP spoofing attacks on the Central LAN, and IP spoofing of 458 other hosts. 460 July 13, 2000 462 Client Identifer Spoofing 464 By using the agent-supplied Agent Remote ID option, the untrusted 465 and as-yet unstandardized client identifer field need not be used 466 by the DHCP server. 468 MAC Address Spoofing 470 By associating a MAC address with an Agent Remote ID, the DHCP 471 server can prevent offering an IP address to an attacker spoofing 472 the same MAC address on a different remote ID. 474 5.0 Security Considerations 476 DHCP as currently defined provides no authentication or security 477 mechanisms. Potential exposures to attack are discussed in section 7 478 of the DHCP protocol specification in RFC 2131 [1]. 480 This document introduces mechanisms to address several security 481 attacks on the operation of IP address assignment, including IP 482 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 483 address exhaustion. It relies on an implied trusted relationship 484 between the DHCP Relay Agent and the DHCP server, with an assumed 485 untrusted DHCP client. It introduces a new identifer, the "Remote 486 ID", that is also assumed to be trusted. The Remote ID is provided by 487 the access network or modem and not by client premise equipment. 488 Cryptographic or other techniques to authenticate the remote ID are 489 certainly possible and encouraged, but are beyond the scope of this 490 document. 492 Note that any future mechanisms for authenticating DHCP client to 493 server communications must take care to omit the DHCP Relay Agent 494 option from server authentication calculations. This was the 495 principal reason for organizing the DHCP Relay Agent Option as a 496 single option with sub-options, and for requiring the relay agent to 497 remove the option before forwarding to the client. 499 While it is beyond the scope of this document to specify the general 500 forwarding algorithm of public data circuit access units, note that 501 automatic reforwarding of IP or ARP broadcast packets back downstream 502 exposes serious IP security risks. For example, if an upstream 503 broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back 504 downstream, any public host may easily spoof the desired DHCP server. 506 6.0 IANA Considerations 508 IANA is required to maintain a new number space of "DHCP Relay Agent 509 Sub-options", with the initial sub-options as described in this 511 July 13, 2000 513 document. 515 IANA assigns future DHCP Relay Agent Sub-options with a "IETF 516 Consensus" policy as described in RFC 2434 [3]. Future proposed 517 sub-options are to be referenced symbolically in the internet-drafts 518 that describe them, and shall be assigned numeric codes by IANA when 519 and if the draft is approved by IESG for Proposed Standard RFC 520 status. 522 7.0 Intellectual Property Notices 524 This section contains two notices as required by [5] for standards 525 track documents. 527 The IETF takes no position regarding the validity or scope of any 528 intellectual property or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; neither does it represent that it 532 has made any effort to identify any such rights. Information on the 533 IETF's procedures with respect to rights in standards-track and 534 standards-related documentation can be found in BCP-11. Copies of 535 claims of rights made available for publication and any assurances of 536 licenses to be made available, or the result of an attempt made to 537 obtain a general license or permission for the use of such 538 proprietary rights by implementors or users of this specification can 539 be obtained from the IETF Secretariat. 541 The IETF has been notified of intellectual property rights claimed in 542 regard to some or all of the specification contained in this 543 document. For more information consult the online list of claimed 544 rights. 546 8.0 References 548 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 549 Bucknell University, March 1997. 551 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 552 Extension" RFC 2132. 554 [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an 555 IANA Considerations Section in RFCs", RFC 2434. 557 July 13, 2000 559 [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement 560 Levels", RFC 2119. 562 [5] Bradner, S. "The Internet Standards Process -- Revision 3", 563 RFC 2026. 565 [6] Kent, S. and Atkinson, R. "Security Architecture for the 566 Internet Protocol", RFS 2401. 568 9.0 Glossary 570 IANA Internet Assigned Numbers Authority 571 LIS Logical IP Subnet 572 MAC Message Authentication Code 573 RAS Remote Access Server 575 10.0 Author's Address 577 Michael Patrick 578 Motorola Broadband Communications Sector 579 20 Cabot Blvd., MS M4-30 580 Mansfield, MA 02048 582 Phone: (508) 261-5707 583 Email: michael.patrick@motorola.com