idnits 2.17.1 draft-ietf-dhc-agent-options-05.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-26) 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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 current Internet-Drafts. ** 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 9 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 296 has weird spacing: '...s. This inclu...' == Line 416 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 (November 13, 1998) is 9296 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: 11 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Grop Michael Patrick 2 Motorola ISG 3 November 13, 1998 5 DHCP Relay Agent Information Option 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress." 20 Please check the "1id-abstracts.txt" listing contained in the 21 Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), 22 nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net 23 (US East Coast), or ftp.isi.edu (US West Coast). 25 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 26 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 27 document are to be interpreted as described in RFC 2119 [4]. 29 Abstract 31 Newer high-speed public Internet access technologies call for a 32 high-speed modem to have a LAN attachment to one or more customer 33 premise hosts. It is advantageous to use the Dynamic Host 34 Configuration Protocol as defined in RFC 2131 [1] to assign customer 35 premise host IP addresses in this environment. However, a number of 36 security and scaling problems arise with such "public" DHCP use. 37 This document describes a new DHCP option to address these issues. 38 This option extends the set of DHCP options as defined in RFC 2132 39 [2]. 41 The new option is called the Relay Agent Information option and is 42 inserted by the DHCP relay agent when forwarding client-originated 43 DHCP packets to a DHCP server. Servers recognizing the Relay Agent 44 Information option may use the information to implement IP address or 45 other parameter assignment policies. The DHCP Server echoes the 46 option back verbatim to the relay agent in server-to-client replies, 47 and the relay agent strips the option before forwarding the reply to 49 November 13, 1998 51 the client. 53 The "Relay Agent Information" option is organized as a single DHCP 54 option that contains one or more "sub-options" that convey 55 information known by the relay agent. The initial sub-options are 56 defined for a relay agent that is co-located in a public circuit 57 access unit. These include a "circuit ID" for the incoming circuit, 58 a "remote ID" which provides a trusted identifier for the remote 59 high-speed modem, and the "subnet mask" of the logical IP subnet from 60 which the relay agent received the client DHCP packet. 62 Table of Contents 64 1 Introduction........................................... 3 65 1.1 High-Speed Circuit Switched Data Networks.............. 3 66 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4 67 2.0 Relay Agent Information Option......................... 6 68 2.1 Agent Operation........................................ 7 69 2.1.1 Reforwarded DHCP requests............................ 8 70 2.2 Server Operation....................................... 8 71 3.0 Relay Agent Information Suboptions..................... 9 72 3.1 Agent Circuit ID....................................... 9 73 3.2 Agent Remote ID........................................ 10 74 3.3 Agent Subnet Mask...................................... 11 75 4.0 Issues Resolved........................................ 11 76 5.0 Security Considerations................................ 12 77 6.0 IANA Considerations.................................... 13 78 7.0 References............................................. 13 79 8.0 Glossary............................................... 13 80 9.0 Author's Address....................................... 14 82 Revision History 84 Rev Date Description 85 --- -------- ----------- 86 -05 11/13/98 Update per IESG review. 87 - MUST/SHOULD wording changes. 88 - Add "IANA considerations section" 90 November 13, 1998 92 1 Introduction 94 1.1 High-Speed Circuit Switched Data Networks 96 Public Access to the Internet is usually via a circuit switched data 97 network. Today, this is primarily implemented with dial-up modems 98 connecting to a Remote Access Server. But higher speed circuit 99 access networks also include ISDN, ATM, Frame Relay, and Cable Data 100 Networks. All of these networks can be characterized as a "star" 101 topology where multiple users connect to a "circuit access unit" via 102 switched or permanent circuits. 104 With dial-up modems, only a single host PC attempts to connect to the 105 central point. The PPP protocol is widely used to assign IP 106 addresses to be used by the single host PC. 108 The newer high-speed circuit technologies, however, frequently 109 provide a LAN interface (especially Ethernet) to one or more host 110 PCs. It is desirable to support centralized assignment of the IP 111 addresses of host computers connecting on such circuits via DHCP. 112 The DHCP server can be, but usually is not, co-implemented with the 113 centralized circuit concentration access device. The DHCP server is 114 often connected as a separate server on the "Central LAN" to which 115 the central access device (or devices) attach. 117 A common physical model for high-speed Internet circuit access is 118 shown in Figure 1, below. 120 November 13, 1998 122 +---------------+ | 123 Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A 124 LAN | | Access | Lan |- Host B 125 | | Unit 1 | |- Host C 126 |-----| |-- | 127 | |(relay agent) |... 128 +---------+ | +---------------+ 129 | DHCP |--| 130 | Server | | 131 +---------+ | 132 | 133 | +---------------+ 134 +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D 135 | Other | | | Access | Lan 136 | Servers |--|-----| Unit 2 | 137 | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E 138 | DNS) | | |(relay agent) |... Lan 139 | | +---------------+ 140 +---------+ 141 Figure 1: DHCP High Speed Circuit Access Model 143 Note that in this model, the "modem" connects to a LAN at the user 144 site, rather than to a single host. Multiple hosts are implemented at 145 this site. Although it is certainly possible to implement a full IP 146 router at the user site, this requires a relatively expensive piece 147 of equipment (compared to typical modem costs). Furthermore, a 148 router requires an IP address not only for every host, but for the 149 router itself. Finally, a user-side router requires a dedicated 150 Logical IP Subnet (LIS) for each user. While this model is 151 appropriate for relatively small corporate networking environments, 152 it is not appropriate for large, public accessed networks. In this 153 scenario, it is advantageous to implement an IP networking model that 154 does not allocate an IP address for the modem (or other networking 155 equipment device at the user site), and especially not an entire LIS 156 for the user side LAN. 158 1.2 DHCP Relay Agent in the Circuit Access Unit 160 It is desirable to use DHCP to assign the IP addresses for public 161 high-speed circuit access. A number of circuit access units (e.g. 162 RAS's, cable modem termination systems, ADSL access units, etc) 163 connect to a LAN (or local internet) to which is attached a DHCP 164 server. 166 November 13, 1998 168 For scaling and security reasons, it is advantageous to implement a 169 "router hop" at the circuit access unit, much like high-capacity 170 RAS's do today. The circuit access equipment acts as both a router 171 to the circuits and as the DHCP relay agent. 173 The advantages of co-locating the DHCP relay agent with the circuit 174 access equipment are: 176 DHCP broadcast replies can be routed to only the proper circuit, 177 avoiding, say, the replication of the DCHP reply broadcast onto 178 thousands of access circuits; 180 The same mechanism used to identify the remote connection of the 181 circuit (e.g. a user ID requested by a Remote Access Server acting as 182 the circuit access equipment) may be used as a host identifier by 183 DHCP, and used for parameter assignment. This includes centralized 184 assignment of IP addresses to hosts. This provides a secure remote 185 ID from a trusted source -- the relay agent. 187 A number of issues arise when forwarding DHCP requests from hosts 188 connecting publicly accessed high-speed circuits with LAN connections 189 at the host. Many of these are security issues arising from DHCP 190 client requests from untrusted sources. How does the relay agent 191 know to which circuit to forward replies? How does the system 192 prevent DHCP IP exhaustion attacks? This is when an attacker 193 requests all available IP addresses from a DHCP server by sending 194 requests with fabricated client MAC addresses. How can an IP address 195 or LIS be permanently assigned to a particular user or modem? How 196 does one prevent "spoofing" of client identifer fields used to assign 197 IP addresses? How does one prevent denial of service by "spoofing" 198 other client's MAC addresses? 200 All of these issues may be addressed by having the circuit access 201 equipment, which is a trusted component, add information to DHCP 202 client requests that it forwards to the DHCP server. 204 November 13, 1998 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 239 sub-options need not appear in sub-option code order. 241 The initial assignment of DHCP Relay Agent Sub-options is as follows: 243 DHCP Agent Sub-Option Descrption 244 Sub-option Code 245 --------------- ---------------------- 246 1 Agent Circuit ID Sub-option 247 2 Agent Remote ID Sub-option 248 3 Agent Subnet Mask Sub-option 250 November 13, 1998 252 New sub-option codes MUST be assigned by IANA according to the policy 253 described in the "IANA Considerations" section of this document. 255 2.1 Agent Operation 257 Overall adding of the DHCP relay agent option SHOULD be configurable, 258 and SHOULD be disabled by default. Relay agents SHOULD have separate 259 configurables for each sub-option to control whether it is added to 260 client-to-server packets. 262 A DHCP relay agent adding a Relay Agent Information field SHALL add 263 it as the last DHCP agent option in the DHCP options field of any 264 recognized DHCP packet forwarded from a client to a server. Such 265 additions shall be made for only those packets recognized as DHCP; 266 BOOTP-only packets shall not be affected. 268 Relay agents receiving a DHCP packet with giaddr set to zero 269 (indicating that they are the first-hop router) but with a Relay 270 Agent Information option already present in the packet SHALL discard 271 the packet and increment an error count. 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 The agent SHALL NOT add an "Option Overload" option to the packet or 287 use the "file" or "sname" fields for adding Relay Agent Information 288 option. It SHALL NOT parse or remove Relay Agent Information options 289 that may appear in the sname or file fields of a server-to-client 290 packet forwarded through the agent. 292 The operation of relay agents for specific sub-options is specified 293 with that sub-option. 295 Relay agents are NOT required to monitor or modify client-originated 296 DHCP packets addressed to a server unicast address. This includes 297 the DHCP-REQUEST sent when entering the RENEWING state. 299 November 13, 1998 301 2.1.1 Reforwarded DHCP requests 303 A DHCP relay agent may receive a client DHCP packet forwarded from a 304 BOOTP/DHCP relay agent closer to the client. Such a packet will have 305 giaddr as non-zero, and may or may not already have a DHCP Relay 306 Agent option in it. 308 Relay agents configured to add a Relay Agent option which receive a 309 client DHCP packet with a nonzero giaddr SHALL discard the packet if 310 the giaddr spoofs a giaddr address implemented by the local agent 311 itself. 313 Otherwise, the relay agent SHALL forward any received DHCP packet 314 with a valid non-zero giaddr WITHOUT adding any relay agent options. 315 Per RFC 2131, it shall also NOT modify the giaddr value. 317 2.2 Server Operation 319 DHCP servers unaware of the Relay Agent Information option will 320 ignore the option upon receive and will not echo it back on 321 responses. This is the specified server behavior for unknown 322 options. 324 DHCP servers claiming to support the Relay Agent Information option 325 SHALL echo the entire contents of the Relay Agent Information option 326 in all replies. Servers SHOULD copy the Relay Agent Information 327 option as the last DHCP option in the response. Servers SHALL NOT 328 place the echoed Relay Agent Information option in the overloaded 329 sname or file fields. If a server is unable to copy a full Relay 330 Agent Information field into a response, it SHALL send the response 331 without the Relay Information Field, and SHOULD increment an error 332 counter for the situation. 334 The operation of DHCP servers for specific sub-options is specified 335 with that sub-option. 337 Note that DHCP relay agents are not required to monitor unicast DHCP 338 messages sent directly between the client and server (i.e, those that 339 aren't sent via a relay agent). However, some relay agents MAY chose 340 to do such monitoring and add relay agent options. Consequently, 341 servers SHOULD be prepared to handle relay agent options in unicast 342 messages, but MUST NOT expect them to always be there. 344 November 13, 1998 346 3.0 Relay Agent Information Sub-options 348 3.1 Agent Circuit ID Sub-option 350 This sub-option MAY be added by DHCP relay agents which terminate 351 switched or permanent circuits. It encodes an agent-local identifier 352 of the circuit from which a DHCP client-to-server packet was 353 received. It is intended for use by agents in relaying DHCP 354 responses back to the proper circuit. Possible uses of this field 355 include 356 - Router interface number 357 - Switching Hub port number 358 - Remote Access Server port number 359 - Frame Relay DLCI 360 - ATM virtual circuit number 361 - Cable Data virtual circuit number 363 Servers MAY use the Circuit ID for IP and other parameter assignment 364 policies. The Circuit ID SHOULD be considered an opaque value, with 365 policies based on exact string match only; that is, the Circuit ID 366 SHOULD NOT be internally parsed by the server. 368 The DHCP server SHOULD report the Agent Circuit ID value of current 369 leases in statistical reports (including its MIB) and in logs. Since 370 the Circuit ID is local only to a particular relay agent, a circuit 371 ID should be qualified with the giaddr value that identifies the 372 relay agent. 374 SubOpt Len Circuit ID 375 +------+------+------+------+------+------+------+------+-- 376 | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... 377 +------+------+------+------+------+------+------+------+-- 379 November 13, 1998 381 3.2 Agent Remote ID Sub-option 383 This sub-option MAY be added by DHCP relay agents which terminate 384 switched or permanent circuits and have mechanisms to identify the 385 remote host end of the circuit. The Remote ID field may be used to 386 encode, for instance: 387 -- a "caller ID" telephone number for dial-up connection 388 -- a "user name" prompted for by a Remote Access Server 389 -- a remote caller ATM address 390 -- a "modem ID" of a cable data modem 391 -- the remote IP address of a point-to-point link 392 -- a remote X.25 address for X.25 connections 394 The remote ID MUST be globally unique. 396 DHCP servers MAY use this option to select parameters specific to 397 particular users, hosts, or subscriber modems. The option SHOULD be 398 considered an opaque value, with policies based on exact string match 399 only; that is, the option SHOULD NOT be internally parsed by the 400 server. 402 The relay agent MAY use this field in addition to or instead of the 403 Agent Circuit ID field to select the circuit on which to forward the 404 DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this 405 value in any reports or MIBs associated with a particular client. 407 SubOpt Len Agent Remote ID 408 +------+------+------+------+------+------+------+------+-- 409 | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... 410 +------+------+------+------+------+------+------+------+-- 412 November 13, 1998 414 3.3 Agent Subnet Mask Sub-option 416 This sub-option MAY be added by DHCP relay agents to identify the 417 subnet mask of the Logical IP Subnet (LIS) from which the client DHCP 418 packet was received. The LIS of the client is defined as the subnet 419 formed by the giaddr ANDed with the Agent Subnet Mask. 421 Servers MAY use this mask field to automatically create scopes of 422 assignable IP addresses. Use of this field avoids the need to have 423 identical configuration of the logical IP subnets on which clients 424 reside in both the relaying routers and the DHCP server. In this 425 case, the router configuration defines the LISs, and the DHCP servers 426 automatically discover the LISs from the relay agent options of 427 forwarded client DHCP requests. 429 SubOpt Len Agent Subnet Mask 430 +------+------+------+------+------+------+ 431 | 3 | 4 | m1 | m2 | m3 | m4 | 432 +------+------+------+------+------+------+ 434 4.0 Issues Resolved 436 Broadcast Forwarding 438 The circuit access equipment forwards the normally broadcasted 439 DHCP response only on the circuit indicated in the Agent Circuit 440 ID. 442 DHCP Address Exhaustion 444 In general, the DHCP server may be extended to maintain a database 445 with the "triplet" of 447 (client IP address, client MAC address, client remote ID) 449 The DHCP server SHOULD implement policies that restrict the number 450 of IP addresses to be assigned to a single remote ID. 452 November 13, 1998 454 Static Assignment 456 The DHCP server may use the remote ID to select the IP address to 457 be assigned. It may permit static assignment of IP addresses to 458 particular remote IDs, and disallow an address request from an 459 unauthorized remote ID. 461 IP Spoofing 463 The circuit access device may associate the IP address assigned by 464 a DHCP server in a forwarded DHCP Ack packet with the circuit to 465 which it was forwarded. The circuit access device MAY prevent 466 forwarding of IP packets with source IP addresses -other than- 467 those it has associated with the receiving circuit. This prevents 468 simple IP spoofing attacks on the Central LAN, and IP spoofing of 469 other hosts. 471 Client Identifer Spoofing 473 By using the agent-supplied Agent Remote ID option, the untrusted 474 and as-yet unstandardized client identifer field need not be used 475 by the DHCP server. 477 MAC Address Spoofing 479 By associating a MAC address with an Agent Remote ID, the DHCP 480 server can prevent offering an IP address to an attacker spoofing 481 the same MAC address on a different remote ID. 483 5.0 Security Considerations 485 DHCP as currently defined provides no authentication or security 486 mechanisms. Potential exposures to attack are discussed in section 7 487 of the DHCP protocol specification in RFC 2131 [1]. 489 This document introduces mechanisms to address several security 490 attacks on the operation of IP address assignment, including IP 491 spoofing, Client ID spoofing, MAC address spoofing, and DHCP server 492 address exhaustion. It relies on an implied trusted relationship 493 between the DHCP Relay Agent and the DHCP server, with an assumed 494 untrusted DHCP client. It introduces a new identifer, the "Remote 495 ID", that is also assumed to be trusted. The Remote ID is provided by 496 the access network or modem and not by client premise equipment. 497 Cryptographic or other techniques to authenticate the remote ID are 498 certainly possible and encouraged, but are beyond the scope of this 499 document. 501 November 13, 1998 503 Note that any future mechanisms for authenticating DHCP client to 504 server communications must take care to omit the DHCP Relay Agent 505 option from server authentication calculations. This was the 506 principal reason for organizing the DHCP Relay Agent Option as a 507 single option with sub-options, and for requiring the relay agent to 508 remove the option before forwarding to the client. 510 6.0 IANA Considerations 512 IANA is required to maintain a new number space of "DHCP Relay Agent 513 Sub-options", with the initial sub-options as described in this 514 document. 516 IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF 517 Consensus" policy as described in RFC 2434 [3]. Future proposed 518 sub-options MUST be referenced symbolically in the internet-drafts 519 that describe them, and shall be assigned numeric codes by IANA when 520 and if the draft is approved by IESG for Proposed Standard RFC 521 status. 523 7.0 References 525 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, 526 Bucknell University, March 1997. 528 [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor 529 Extension" RFC 2132. 531 [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an 532 IANA Considerations Section in RFCs", RFC 2434. 534 [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement 535 Levels", RFC 2119. 537 8.0 Glossary 539 IANA Internet Assigned Numbers Authority 540 LIS Logical IP Subnet 541 MAC Message Authentication Code 542 RAS Remote Access Server 544 November 13, 1998 546 9.0 Author's Address 548 Michael Patrick 549 Motorola Information Systems Group 550 20 Cabot Blvd., MS M4-30 551 Mansfield, MA 02048 553 Phone: (508) 261-5707 554 Email: mpatrick@dma.isg.mot.com