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