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