idnits 2.17.1 draft-ietf-dhc-agent-options-10.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-04-19) 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 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 319 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 (May 15, 2000) is 8740 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 ING 5 May 15, 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 May 15, 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........................................... 3 67 1.1 High-Speed Circuit Switched Data Networks.............. 3 68 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 5 69 2.0 Relay Agent Information Option......................... 6 70 2.1 Agent Operation........................................ 7 71 2.1.1 Reforwarded DHCP requests............................ 8 72 2.2 Server Operation....................................... 8 73 3.0 Relay Agent Information Suboptions..................... 9 74 3.1 Agent Circuit ID....................................... 9 75 3.2 Agent Remote ID........................................ 10 76 4.0 Issues Resolved........................................ 11 77 5.0 Security Considerations................................ 12 78 6.0 IANA Considerations.................................... 12 79 7.0 Intellectual Property Notice........................... 13 80 8.0 References............................................. 13 81 9.0 Glossary............................................... 14 82 10.0 Author's Address...................................... 14 84 May 15, 2000 86 Revision History 88 Rev Date Description 89 --- -------- ----------- 90 -10 5/15/2000 Relay agent operation (section 2.1): 91 Define operation for both BOOTP and DHCP. 92 Allow an existing Relay Agent option 93 added by a trusted network element 94 between the client and Relay Agent. 96 -09 3/2/2000 Remove Subnet Mask suboption. It will be 97 considered as a separate draft. 99 -08 1/3/2000 Require that agents MUST NOT modify 100 DHCP packets that use IPSEC. 102 -07 8/24/99 Updated "Status of this memo" to conform to 103 current I-D requirements. 105 Revision -06 added section 7 Intellectual 106 Property Notices. 108 1 Introduction 110 1.1 High-Speed Circuit Switched Data Networks 112 Public Access to the Internet is usually via a circuit switched data 113 network. Today, this is primarily implemented with dial-up modems 114 connecting to a Remote Access Server. But higher speed circuit 115 access networks also include ISDN, ATM, Frame Relay, and Cable Data 116 Networks. All of these networks can be characterized as a "star" 117 topology where multiple users connect to a "circuit access unit" via 118 switched or permanent circuits. 120 With dial-up modems, only a single host PC attempts to connect to the 121 central point. The PPP protocol is widely used to assign IP 122 addresses to be used by the single host PC. 124 The newer high-speed circuit technologies, however, frequently 125 provide a LAN interface (especially Ethernet) to one or more host 126 PCs. It is desirable to support centralized assignment of the IP 127 addresses of host computers connecting on such circuits via DHCP. 128 The DHCP server can be, but usually is not, co-implemented with the 129 centralized circuit concentration access device. The DHCP server is 130 often connected as a separate server on the "Central LAN" to which 131 the central access device (or devices) attach. 133 May 15, 2000 135 A common physical model for high-speed Internet circuit access is 136 shown in Figure 1, below. 138 +---------------+ | 139 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A 140 LAN | | Access | Lan |- Host B 141 | | Unit 1 | |- Host C 142 |-----| |-- | 143 | |(relay agent) |... 144 +---------+ | +---------------+ 145 | DHCP |--| 146 | Server | | 147 +---------+ | 148 | 149 | +---------------+ 150 +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D 151 | Other | | | Access | Lan 152 | Servers |--|-----| Unit 2 | 153 | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E 154 | DNS) | | |(relay agent) |... Lan 155 | | +---------------+ 156 +---------+ 157 Figure 1: DHCP High Speed Circuit Access Model 159 Note that in this model, the "modem" connects to a LAN at the user 160 site, rather than to a single host. Multiple hosts are implemented at 161 this site. Although it is certainly possible to implement a full IP 162 router at the user site, this requires a relatively expensive piece 163 of equipment (compared to typical modem costs). Furthermore, a 164 router requires an IP address not only for every host, but for the 165 router itself. Finally, a user-side router requires a dedicated 166 Logical IP Subnet (LIS) for each user. While this model is 167 appropriate for relatively small corporate networking environments, 168 it is not appropriate for large, public accessed networks. In this 169 scenario, it is advantageous to implement an IP networking model that 170 does not allocate an IP address for the modem (or other networking 171 equipment device at the user site), and especially not an entire LIS 172 for the user side LAN. 174 Note that using this method to obtain IP addresses means that IP 175 addresses can only be obtained while communication to the central 176 site is available. Some host lan installations may use a local DHCP 177 server or other methods to obtain IP addresses for in-house use. 179 May 15, 2000 181 1.2 DHCP Relay Agent in the Circuit Access Unit 183 It is desirable to use DHCP to assign the IP addresses for public 184 high-speed circuit access. A number of circuit access units (e.g. 185 RAS's, cable modem termination systems, ADSL access units, etc) 186 connect to a LAN (or local internet) to which is attached a DHCP 187 server. 189 For scaling and security reasons, it is advantageous to implement a 190 "router hop" at the circuit access unit, much like high-capacity 191 RAS's do today. The circuit access equipment acts as both a router 192 to the circuits and as the DHCP relay agent. 194 The advantages of co-locating the DHCP relay agent with the circuit 195 access equipment are: 197 DHCP broadcast replies can be routed to only the proper circuit, 198 avoiding, say, the replication of the DCHP reply broadcast onto 199 thousands of access circuits; 201 The same mechanism used to identify the remote connection of the 202 circuit (e.g. a user ID requested by a Remote Access Server acting as 203 the circuit access equipment) may be used as a host identifier by 204 DHCP, and used for parameter assignment. This includes centralized 205 assignment of IP addresses to hosts. This provides a secure remote 206 ID from a trusted source -- the relay agent. 208 A number of issues arise when forwarding DHCP requests from hosts 209 connecting publicly accessed high-speed circuits with LAN connections 210 at the host. Many of these are security issues arising from DHCP 211 client requests from untrusted sources. How does the relay agent 212 know to which circuit to forward replies? How does the system 213 prevent DHCP IP exhaustion attacks? This is when an attacker 214 requests all available IP addresses from a DHCP server by sending 215 requests with fabricated client MAC addresses. How can an IP address 216 or LIS be permanently assigned to a particular user or modem? How 217 does one prevent "spoofing" of client identifer fields used to assign 218 IP addresses? How does one prevent denial of service by "spoofing" 219 other client's MAC addresses? 221 All of these issues may be addressed by having the circuit access 222 equipment, which is a trusted component, add information to DHCP 223 client requests that it forwards to the DHCP server. 225 May 15, 2000 227 2.0 Relay Agent Information Option 229 This document defines a new DHCP Option called the Relay Agent 230 Information Option. It is a "container" option for specific agent- 231 supplied sub-options. The format of the Relay Agent Information 232 option is: 234 Code Len Agent Information Field 235 +------+------+------+------+------+------+--...-+------+ 236 | 82 | N | i1 | i2 | i3 | i4 | | iN | 237 +------+------+------+------+------+------+--...-+------+ 239 The length N gives the total number of octets in the Agent 240 Information Field. The Agent Information field consists of a sequence 241 of SubOpt/Length/Value tuples for each sub-option, encoded in the 242 following manner: 244 SubOpt Len Sub-option Value 245 +------+------+------+------+------+------+--...-+------+ 246 | 1 | N | s1 | s2 | s3 | s4 | | sN | 247 +------+------+------+------+------+------+--...-+------+ 248 SubOpt Len Sub-option Value 249 +------+------+------+------+------+------+--...-+------+ 250 | 2 | N | i1 | i2 | i3 | i4 | | iN | 251 +------+------+------+------+------+------+--...-+------+ 253 No "pad" sub-option is defined, and the Information field shall NOT 254 be terminated with a 255 sub-option. The length N of the DHCP Agent 255 Information Option shall include all bytes of the sub-option 256 code/length/value tuples. Since at least one sub-option must be 257 defined, the minimum Relay Agent Information length is two (2). The 258 length N of the sub-options shall be the number of octets in only 259 that sub-option's value field. A sub-option length may be zero. The 260 sub-options need not appear in sub-option code order. 262 The initial assignment of DHCP Relay Agent Sub-options is as follows: 264 DHCP Agent Sub-Option Descrption 265 Sub-option Code 266 --------------- ---------------------- 267 1 Agent Circuit ID Sub-option 268 2 Agent Remote ID Sub-option 270 May 15, 2000 272 New sub-option codes MUST be assigned by IANA according to the policy 273 described in the "IANA Considerations" section of this document. 275 2.1 Agent Operation 277 Overall adding of the DHCP relay agent option SHOULD be configurable, 278 and SHOULD be disabled by default. Relay agents SHOULD have separate 279 configurables for each sub-option to control whether it is added to 280 client-to-server packets. 282 A DHCP relay agent adding a Relay Agent Information field SHALL add 283 it as the last DHCP agent option in the DHCP options field of any 284 recognized BOOTP or DHCP packet forwarded from a client to a server. 286 Relay agents receiving a DHCP packet from an untrusted source with 287 giaddr set to zero (indicating that they are the first-hop router) 288 but with a Relay Agent Information option already present in the 289 packet SHALL discard the packet and increment an error count. A 290 trusted network element (e.g. a bridge) between the relay agent and 291 the client MAY add a relay agent option but not set the giaddr field. 292 In this case, the relay agent does NOT add a "second" relay agent 293 option, but forwards the DHCP packet per normal DHCP relay agent 294 operations. 296 Relay agents MAY have a configurable for the maximum size of the DHCP 297 packet to be created after appending the Agent Information option. 298 Packets which, after appending the Relay Agent Information option, 299 would exceed this configured maximum size shall be forwarded WITHOUT 300 adding the Agent Information option. An error counter SHOULD be 301 incremented in this case. In the absence of this configurable, the 302 agent SHALL NOT increase a forwarded DHCP packet size to exceed the 303 MTU of the interface on which it is forwarded. 305 The Relay Agent Information option echoed by a server MUST be removed 306 by the agent when forwarding a server-to-client response back to the 307 client. 309 The agent SHALL NOT add an "Option Overload" option to the packet or 310 use the "file" or "sname" fields for adding Relay Agent Information 311 option. It SHALL NOT parse or remove Relay Agent Information options 312 that may appear in the sname or file fields of a server-to-client 313 packet forwarded through the agent. 315 The operation of relay agents for specific sub-options is specified 316 with that sub-option. 318 Relay agents are NOT required to monitor or modify client-originated 319 DHCP packets addressed to a server unicast address. This includes 321 May 15, 2000 323 the DHCP-REQUEST sent when entering the RENEWING state. 325 Relay agents MUST NOT modify DHCP packets that use the IPSEC 326 Authentication Header or IPSEC Encapsulating Security Payload [6]. 328 2.1.1 Reforwarded DHCP requests 330 A DHCP relay agent may receive a client DHCP packet forwarded from a 331 BOOTP/DHCP relay agent closer to the client. Such a packet will have 332 giaddr as non-zero, and may or may not already have a DHCP Relay 333 Agent option in it. 335 Relay agents configured to add a Relay Agent option which receive a 336 client DHCP packet with a nonzero giaddr SHALL discard the packet if 337 the giaddr spoofs a giaddr address implemented by the local agent 338 itself. 340 Otherwise, the relay agent SHALL forward any received DHCP packet 341 with a valid non-zero giaddr WITHOUT adding any relay agent options. 342 Per RFC 2131, it shall also NOT modify the giaddr value. 344 2.2 Server Operation 346 DHCP servers unaware of the Relay Agent Information option will 347 ignore the option upon receive and will not echo it back on 348 responses. This is the specified server behavior for unknown 349 options. 351 DHCP servers claiming to support the Relay Agent Information option 352 SHALL echo the entire contents of the Relay Agent Information option 353 in all replies. Servers SHOULD copy the Relay Agent Information 354 option as the last DHCP option in the response. Servers SHALL NOT 355 place the echoed Relay Agent Information option in the overloaded 356 sname or file fields. If a server is unable to copy a full Relay 357 Agent Information field into a response, it SHALL send the response 358 without the Relay Information Field, and SHOULD increment an error 359 counter for the situation. 361 The operation of DHCP servers for specific sub-options is specified 362 with that sub-option. 364 Note that DHCP relay agents are not required to monitor unicast DHCP 365 messages sent directly between the client and server (i.e, those that 366 aren't sent via a relay agent). However, some relay agents MAY chose 367 to do such monitoring and add relay agent options. Consequently, 368 servers SHOULD be prepared to handle relay agent options in unicast 369 messages, but MUST NOT expect them to always be there. 371 May 15, 2000 373 3.0 Relay Agent Information Sub-options 375 3.1 Agent Circuit ID Sub-option 377 This sub-option MAY be added by DHCP relay agents which terminate 378 switched or permanent circuits. It encodes an agent-local identifier 379 of the circuit from which a DHCP client-to-server packet was 380 received. It is intended for use by agents in relaying DHCP 381 responses back to the proper circuit. Possible uses of this field 382 include 383 - Router interface number 384 - Switching Hub port number 385 - Remote Access Server port number 386 - Frame Relay DLCI 387 - ATM virtual circuit number 388 - Cable Data virtual circuit number 390 Servers MAY use the Circuit ID for IP and other parameter assignment 391 policies. The Circuit ID SHOULD be considered an opaque value, with 392 policies based on exact string match only; that is, the Circuit ID 393 SHOULD NOT be internally parsed by the server. 395 The DHCP server SHOULD report the Agent Circuit ID value of current 396 leases in statistical reports (including its MIB) and in logs. Since 397 the Circuit ID is local only to a particular relay agent, a circuit 398 ID should be qualified with the giaddr value that identifies the 399 relay agent. 401 SubOpt Len Circuit ID 402 +------+------+------+------+------+------+------+------+-- 403 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 404 +------+------+------+------+------+------+------+------+-- 406 May 15, 2000 408 3.2 Agent Remote ID Sub-option 410 This sub-option MAY be added by DHCP relay agents which terminate 411 switched or permanent circuits and have mechanisms to identify the 412 remote host end of the circuit. The Remote ID field may be used to 413 encode, for instance: 414 -- a "caller ID" telephone number for dial-up connection 415 -- a "user name" prompted for by a Remote Access Server 416 -- a remote caller ATM address 417 -- a "modem ID" of a cable data modem 418 -- the remote IP address of a point-to-point link 419 -- a remote X.25 address for X.25 connections 421 The remote ID MUST be globally unique. 423 DHCP servers MAY use this option to select parameters specific to 424 particular users, hosts, or subscriber modems. The option SHOULD be 425 considered an opaque value, with policies based on exact string match 426 only; that is, the option SHOULD NOT be internally parsed by the 427 server. 429 The relay agent MAY use this field in addition to or instead of the 430 Agent Circuit ID field to select the circuit on which to forward the 431 DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this 432 value in any reports or MIBs associated with a particular client. 434 SubOpt Len Agent Remote ID 435 +------+------+------+------+------+------+------+------+-- 436 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 437 +------+------+------+------+------+------+------+------+-- 439 May 15, 2000 441 4.0 Issues Resolved 443 Broadcast Forwarding 445 The circuit access equipment forwards the normally broadcasted 446 DHCP response only on the circuit indicated in the Agent Circuit 447 ID. 449 DHCP Address Exhaustion 451 In general, the DHCP server may be extended to maintain a database 452 with the "triplet" of 454 (client IP address, client MAC address, client remote ID) 456 The DHCP server SHOULD implement policies that restrict the number 457 of IP addresses to be assigned to a single remote ID. 459 Static Assignment 461 The DHCP server may use the remote ID to select the IP address to 462 be assigned. It may permit static assignment of IP addresses to 463 particular remote IDs, and disallow an address request from an 464 unauthorized remote ID. 466 IP Spoofing 468 The circuit access device may associate the IP address assigned by 469 a DHCP server in a forwarded DHCP Ack packet with the circuit to 470 which it was forwarded. The circuit access device MAY prevent 471 forwarding of IP packets with source IP addresses -other than- 472 those it has associated with the receiving circuit. This prevents 473 simple IP spoofing attacks on the Central LAN, and IP spoofing of 474 other hosts. 476 Client Identifer Spoofing 478 By using the agent-supplied Agent Remote ID option, the untrusted 479 and as-yet unstandardized client identifer field need not be used 480 by the DHCP server. 482 May 15, 2000 484 MAC Address Spoofing 486 By associating a MAC address with an Agent Remote ID, the DHCP 487 server can prevent offering an IP address to an attacker spoofing 488 the same MAC address on a different remote ID. 490 5.0 Security Considerations 492 DHCP as currently defined provides no authentication or security 493 mechanisms. Potential exposures to attack are discussed in section 7 494 of the DHCP protocol specification in RFC 2131 [1]. 496 This document introduces mechanisms to address several security 497 attacks on the operation of IP address assignment, including IP 498 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 499 address exhaustion. It relies on an implied trusted relationship 500 between the DHCP Relay Agent and the DHCP server, with an assumed 501 untrusted DHCP client. It introduces a new identifer, the "Remote 502 ID", that is also assumed to be trusted. The Remote ID is provided by 503 the access network or modem and not by client premise equipment. 504 Cryptographic or other techniques to authenticate the remote ID are 505 certainly possible and encouraged, but are beyond the scope of this 506 document. 508 Note that any future mechanisms for authenticating DHCP client to 509 server communications must take care to omit the DHCP Relay Agent 510 option from server authentication calculations. This was the 511 principal reason for organizing the DHCP Relay Agent Option as a 512 single option with sub-options, and for requiring the relay agent to 513 remove the option before forwarding to the client. 515 While it is beyond the scope of this document to specify the general 516 forwarding algorithm of public data circuit access units, note that 517 automatic reforwarding of IP or ARP broadcast packets back downstream 518 exposes serious IP security risks. For example, if an upstream 519 broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back 520 downstream, any public host may easily spoof the desired DHCP server. 522 6.0 IANA Considerations 524 IANA is required to maintain a new number space of "DHCP Relay Agent 525 Sub-options", with the initial sub-options as described in this 526 document. 528 IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF 529 Consensus" policy as described in RFC 2434 [3]. Future proposed 530 sub-options MUST be referenced symbolically in the internet-drafts 531 that describe them, and shall be assigned numeric codes by IANA when 533 May 15, 2000 535 and if the draft is approved by IESG for Proposed Standard RFC 536 status. 538 7.0 Intellectual Property Notices 540 This section contains two notices as required by [5] for standards 541 track documents. 543 Per [5], section 10.4(A): 544 The IETF takes no position regarding the validity or scope of any 545 intellectual property or other rights that might be claimed to 546 pertain to the implementation or use of the technology described in 547 this document or the extent to which any license under such rights 548 might or might not be available; neither does it represent that it 549 has made any effort to identify any such rights. Information on the 550 IETF's procedures with respect to rights in standards-track and 551 standards-related documentation can be found in BCP-11. Copies of 552 claims of rights made available for publication and any assurances of 553 licenses to be made available, or the result of an attempt made to 554 obtain a general license or permission for the use of such 555 proprietary rights by implementors or users of this specification can 556 be obtained from the IETF Secretariat. 558 Per [5] section 10.4(D): 559 The IETF has been notified of intellectual property rights claimed in 560 regard to some or all of the specification contained in this 561 document. For more information consult the online list of claimed 562 rights. 564 8.0 References 566 May 15, 2000 568 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 569 Bucknell University, March 1997. 571 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 572 Extension" RFC 2132. 574 [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an 575 IANA Considerations Section in RFCs", RFC 2434. 577 [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement 578 Levels", RFC 2119. 580 [5] Bradner, S. "The Internet Standards Process -- Revision 3", 581 RFC 2026. 583 [6] Kent, S. and Atkinson, R. "Security Architecture for the 584 Internet Protocol", RFS 2401. 586 9.0 Glossary 588 IANA Internet Assigned Numbers Authority 589 LIS Logical IP Subnet 590 MAC Message Authentication Code 591 RAS Remote Access Server 593 10.0 Author's Address 595 Michael Patrick 596 Motorola Broadband Communications Sector 597 20 Cabot Blvd., MS M4-30 598 Mansfield, MA 02048 600 Phone: (508) 261-5707 601 Email: mpatrick@dma.isg.mot.com