summaryrefslogtreecommitdiff
path: root/rfc/rfc3046.txt
diff options
context:
space:
mode:
authorKozlov Dmitry <xeb@mail.ru>2012-06-22 18:11:19 +0400
committerKozlov Dmitry <xeb@mail.ru>2012-06-22 18:11:19 +0400
commit4080b4e1ffdb1482ab26557eb46a8121d93ac584 (patch)
tree0732197c98f911a18c024f7b91ec1031de34e10b /rfc/rfc3046.txt
parentb57c6b9e838fa7fa39e81164912d518b43de3723 (diff)
downloadaccel-ppp-4080b4e1ffdb1482ab26557eb46a8121d93ac584.tar.gz
accel-ppp-4080b4e1ffdb1482ab26557eb46a8121d93ac584.zip
initial ipoe implementation
Diffstat (limited to 'rfc/rfc3046.txt')
-rw-r--r--rfc/rfc3046.txt787
1 files changed, 787 insertions, 0 deletions
diff --git a/rfc/rfc3046.txt b/rfc/rfc3046.txt
new file mode 100644
index 00000000..18d70144
--- /dev/null
+++ b/rfc/rfc3046.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group M. Patrick
+Request for Comments: 3046 Motorola BCS
+Category: Standards Track January 2001
+
+
+ DHCP Relay Agent Information Option
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+Abstract
+
+ Newer high-speed public Internet access technologies call for a
+ high-speed modem to have a local area network (LAN) attachment to one
+ or more customer premise hosts. It is advantageous to use the
+ Dynamic Host Configuration Protocol (DHCP) as defined in RFC 2131 to
+ assign customer premise host IP addresses in this environment.
+ However, a number of security and scaling problems arise with such
+ "public" DHCP use. This document describes a new DHCP option to
+ address these issues. This option extends the set of DHCP options as
+ defined in RFC 2132.
+
+ The new option is called the Relay Agent Information option and is
+ inserted by the DHCP relay agent when forwarding client-originated
+ DHCP packets to a DHCP server. Servers recognizing the Relay Agent
+ Information option may use the information to implement IP address or
+ other parameter assignment policies. The DHCP Server echoes the
+ option back verbatim to the relay agent in server-to-client replies,
+ and the relay agent strips the option before forwarding the reply to
+ the client.
+
+ The "Relay Agent Information" option is organized as a single DHCP
+ option that contains one or more "sub-options" that convey
+ information known by the relay agent. The initial sub-options are
+ defined for a relay agent that is co-located in a public circuit
+ access unit. These include a "circuit ID" for the incoming circuit,
+ and a "remote ID" which provides a trusted identifier for the remote
+ high-speed modem.
+
+
+
+
+Patrick Standards Track [Page 1]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+Table of Contents
+
+ 1 Introduction........................................... 2
+ 1.1 High-Speed Circuit Switched Data Networks.............. 2
+ 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 4
+ 2.0 Relay Agent Information Option......................... 5
+ 2.1 Agent Operation........................................ 6
+ 2.1.1 Reforwarded DHCP requests............................ 7
+ 2.2 Server Operation....................................... 7
+ 3.0 Relay Agent Information Suboptions..................... 8
+ 3.1 Agent Circuit ID....................................... 8
+ 3.2 Agent Remote ID........................................ 9
+ 4.0 Issues Resolved........................................ 9
+ 5.0 Security Considerations................................ 10
+ 6.0 IANA Considerations.................................... 11
+ 7.0 Intellectual Property Notice........................... 12
+ 8.0 References............................................. 12
+ 9.0 Glossary............................................... 13
+ 10.0 Author's Address...................................... 13
+ 11.0 Full Copyright Statement ............................. 14
+
+1 Introduction
+
+1.1 High-Speed Circuit Switched Data Networks
+
+ Public Access to the Internet is usually via a circuit switched data
+ network. Today, this is primarily implemented with dial-up modems
+ connecting to a Remote Access Server. But higher speed circuit
+ access networks also include ISDN, ATM, Frame Relay, and Cable Data
+ Networks. All of these networks can be characterized as a "star"
+ topology where multiple users connect to a "circuit access unit" via
+ switched or permanent circuits.
+
+ With dial-up modems, only a single host PC attempts to connect to the
+ central point. The PPP protocol is widely used to assign IP
+ addresses to be used by the single host PC.
+
+ The newer high-speed circuit technologies, however, frequently
+ provide a LAN interface (especially Ethernet) to one or more host
+ PCs. It is desirable to support centralized assignment of the IP
+ addresses of host computers connecting on such circuits via DHCP.
+ The DHCP server can be, but usually is not, co-implemented with the
+ centralized circuit concentration access device. The DHCP server is
+ often connected as a separate server on the "Central LAN" to which
+ the central access device (or devices) attach.
+
+
+
+
+
+
+Patrick Standards Track [Page 2]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+ A common physical model for high-speed Internet circuit access is
+ shown in Figure 1, below.
+
+ +---------------+ |
+ Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A
+ LAN | | Access | Lan |- Host B
+ | | Unit 1 | |- Host C
+ |-----| |-- |
+ | |(relay agent) |...
++---------+ | +---------------+
+| DHCP |--|
+| Server | |
++---------+ |
+ |
+ | +---------------+
++---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D
+| Other | | | Access | Lan
+| Servers |--|-----| Unit 2 |
+| (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E
+| DNS) | | |(relay agent) |... Lan
+| | +---------------+
++---------+
+
+ Figure 1: DHCP High Speed Circuit Access Model
+
+ Note that in this model, the "modem" connects to a LAN at the user
+ site, rather than to a single host. Multiple hosts are implemented
+ at this site. Although it is certainly possible to implement a full
+ IP router at the user site, this requires a relatively expensive
+ piece of equipment (compared to typical modem costs). Furthermore, a
+ router requires an IP address not only for every host, but for the
+ router itself. Finally, a user-side router requires a dedicated
+ Logical IP Subnet (LIS) for each user. While this model is
+ appropriate for relatively small corporate networking environments,
+ it is not appropriate for large, public accessed networks. In this
+ scenario, it is advantageous to implement an IP networking model that
+ does not allocate an IP address for the modem (or other networking
+ equipment device at the user site), and especially not an entire LIS
+ for the user side LAN.
+
+ Note that using this method to obtain IP addresses means that IP
+ addresses can only be obtained while communication to the central
+ site is available. Some host lan installations may use a local DHCP
+ server or other methods to obtain IP addresses for in-house use.
+
+
+
+
+
+
+
+Patrick Standards Track [Page 3]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+1.2 DHCP Relay Agent in the Circuit Access Unit
+
+ It is desirable to use DHCP to assign the IP addresses for public
+ high-speed circuit access. A number of circuit access units (e.g.,
+ RAS's, cable modem termination systems, ADSL access units, etc)
+ connect to a LAN (or local internet) to which is attached a DHCP
+ server.
+
+ For scaling and security reasons, it is advantageous to implement a
+ "router hop" at the circuit access unit, much like high-capacity
+ RAS's do today. The circuit access equipment acts as both a router
+ to the circuits and as the DHCP relay agent.
+
+ The advantages of co-locating the DHCP relay agent with the circuit
+ access equipment are:
+
+ DHCP broadcast replies can be routed to only the proper circuit,
+ avoiding, say, the replication of the DCHP reply broadcast onto
+ thousands of access circuits;
+
+ The same mechanism used to identify the remote connection of the
+ circuit (e.g., a user ID requested by a Remote Access Server acting
+ as the circuit access equipment) may be used as a host identifier by
+ DHCP, and used for parameter assignment. This includes centralized
+ assignment of IP addresses to hosts. This provides a secure remote
+ ID from a trusted source -- the relay agent.
+
+ A number of issues arise when forwarding DHCP requests from hosts
+ connecting publicly accessed high-speed circuits with LAN connections
+ at the host. Many of these are security issues arising from DHCP
+ client requests from untrusted sources. How does the relay agent
+ know to which circuit to forward replies? How does the system
+ prevent DHCP IP exhaustion attacks? This is when an attacker
+ requests all available IP addresses from a DHCP server by sending
+ requests with fabricated client MAC addresses. How can an IP address
+ or LIS be permanently assigned to a particular user or modem? How
+ does one prevent "spoofing" of client identifier fields used to
+ assign IP addresses? How does one prevent denial of service by
+ "spoofing" other client's MAC addresses?
+
+ All of these issues may be addressed by having the circuit access
+ equipment, which is a trusted component, add information to DHCP
+ client requests that it forwards to the DHCP server.
+
+
+
+
+
+
+
+
+Patrick Standards Track [Page 4]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+2.0 Relay Agent Information Option
+
+ This document defines a new DHCP Option called the Relay Agent
+ Information Option. It is a "container" option for specific agent-
+ supplied sub-options. The format of the Relay Agent Information
+ option is:
+
+ Code Len Agent Information Field
+ +------+------+------+------+------+------+--...-+------+
+ | 82 | N | i1 | i2 | i3 | i4 | | iN |
+ +------+------+------+------+------+------+--...-+------+
+
+ The length N gives the total number of octets in the Agent
+ Information Field. The Agent Information field consists of a
+ sequence of SubOpt/Length/Value tuples for each sub-option, encoded
+ in the following manner:
+
+ SubOpt Len Sub-option Value
+ +------+------+------+------+------+------+--...-+------+
+ | 1 | N | s1 | s2 | s3 | s4 | | sN |
+ +------+------+------+------+------+------+--...-+------+
+ SubOpt Len Sub-option Value
+ +------+------+------+------+------+------+--...-+------+
+ | 2 | N | i1 | i2 | i3 | i4 | | iN |
+ +------+------+------+------+------+------+--...-+------+
+
+ No "pad" sub-option is defined, and the Information field shall NOT
+ be terminated with a 255 sub-option. The length N of the DHCP Agent
+ Information Option shall include all bytes of the sub-option
+ code/length/value tuples. Since at least one sub-option must be
+ defined, the minimum Relay Agent Information length is two (2). The
+ length N of the sub-options shall be the number of octets in only
+ that sub-option's value field. A sub-option length may be zero. The
+ sub-options need not appear in sub-option code order.
+
+ The initial assignment of DHCP Relay Agent Sub-options is as follows:
+
+ DHCP Agent Sub-Option Description
+ Sub-option Code
+ --------------- ----------------------
+ 1 Agent Circuit ID Sub-option
+ 2 Agent Remote ID Sub-option
+
+
+
+
+
+
+
+
+
+Patrick Standards Track [Page 5]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+2.1 Agent Operation
+
+ Overall adding of the DHCP relay agent option SHOULD be configurable,
+ and SHOULD be disabled by default. Relay agents SHOULD have separate
+ configurables for each sub-option to control whether it is added to
+ client-to-server packets.
+
+ A DHCP relay agent adding a Relay Agent Information field SHALL add
+ it as the last option (but before 'End Option' 255, if present) in
+ the DHCP options field of any recognized BOOTP or DHCP packet
+ forwarded from a client to a server.
+
+ Relay agents receiving a DHCP packet from an untrusted circuit with
+ giaddr set to zero (indicating that they are the first-hop router)
+ but with a Relay Agent Information option already present in the
+ packet SHALL discard the packet and increment an error count. A
+ trusted circuit may contain a trusted downstream (closer to client)
+ network element (bridge) between the relay agent and the client that
+ MAY add a relay agent option but not set the giaddr field. In this
+ case, the relay agent does NOT add a "second" relay agent option, but
+ forwards the DHCP packet per normal DHCP relay agent operations,
+ setting the giaddr field as it deems appropriate.
+
+ The mechanisms for distinguishing between "trusted" and "untrusted"
+ circuits are specific to the type of circuit termination equipment,
+ and may involve local administration. For example, a Cable Modem
+ Termination System may consider upstream packets from most cable
+ modems as "untrusted", but an ATM switch terminating VCs switched
+ through a DSLAM may consider such VCs as "trusted" and accept a relay
+ agent option added by the DSLAM.
+
+ Relay agents MAY have a configurable for the maximum size of the DHCP
+ packet to be created after appending the Agent Information option.
+ Packets which, after appending the Relay Agent Information option,
+ would exceed this configured maximum size shall be forwarded WITHOUT
+ adding the Agent Information option. An error counter SHOULD be
+ incremented in this case. In the absence of this configurable, the
+ agent SHALL NOT increase a forwarded DHCP packet size to exceed the
+ MTU of the interface on which it is forwarded.
+
+ The Relay Agent Information option echoed by a server MUST be removed
+ by either the relay agent or the trusted downstream network element
+ which added it when forwarding a server-to-client response back to
+ the client.
+
+
+
+
+
+
+
+Patrick Standards Track [Page 6]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+ The agent SHALL NOT add an "Option Overload" option to the packet or
+ use the "file" or "sname" fields for adding Relay Agent Information
+ option. It SHALL NOT parse or remove Relay Agent Information options
+ that may appear in the sname or file fields of a server-to-client
+ packet forwarded through the agent.
+
+ The operation of relay agents for specific sub-options is specified
+ with that sub-option.
+
+ Relay agents are NOT required to monitor or modify client-originated
+ DHCP packets addressed to a server unicast address. This includes
+ the DHCP-REQUEST sent when entering the RENEWING state.
+
+ Relay agents MUST NOT modify DHCP packets that use the IPSEC
+ Authentication Header or IPSEC Encapsulating Security Payload [6].
+
+2.1.1 Reforwarded DHCP requests
+
+ A DHCP relay agent may receive a client DHCP packet forwarded from a
+ BOOTP/DHCP relay agent closer to the client. Such a packet will have
+ giaddr as non-zero, and may or may not already have a DHCP Relay
+ Agent option in it.
+
+ Relay agents configured to add a Relay Agent option which receive a
+ client DHCP packet with a nonzero giaddr SHALL discard the packet if
+ the giaddr spoofs a giaddr address implemented by the local agent
+ itself.
+
+ Otherwise, the relay agent SHALL forward any received DHCP packet
+ with a valid non-zero giaddr WITHOUT adding any relay agent options.
+ Per RFC 2131, it shall also NOT modify the giaddr value.
+
+2.2 Server Operation
+
+ DHCP servers unaware of the Relay Agent Information option will
+ ignore the option upon receive and will not echo it back on
+ responses. This is the specified server behavior for unknown
+ options.
+
+ DHCP servers claiming to support the Relay Agent Information option
+ SHALL echo the entire contents of the Relay Agent Information option
+ in all replies. Servers SHOULD copy the Relay Agent Information
+ option as the last DHCP option in the response. Servers SHALL NOT
+ place the echoed Relay Agent Information option in the overloaded
+ sname or file fields. If a server is unable to copy a full Relay
+ Agent Information field into a response, it SHALL send the response
+ without the Relay Information Field, and SHOULD increment an error
+ counter for the situation.
+
+
+
+Patrick Standards Track [Page 7]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+ The operation of DHCP servers for specific sub-options is specified
+ with that sub-option.
+
+ Note that DHCP relay agents are not required to monitor unicast DHCP
+ messages sent directly between the client and server (i.e., those
+ that aren't sent via a relay agent). However, some relay agents MAY
+ chose to do such monitoring and add relay agent options.
+ Consequently, servers SHOULD be prepared to handle relay agent
+ options in unicast messages, but MUST NOT expect them to always be
+ there.
+
+3.0 Relay Agent Information Sub-options
+
+3.1 Agent Circuit ID Sub-option
+
+ This sub-option MAY be added by DHCP relay agents which terminate
+ switched or permanent circuits. It encodes an agent-local identifier
+ of the circuit from which a DHCP client-to-server packet was
+ received. It is intended for use by agents in relaying DHCP
+ responses back to the proper circuit. Possible uses of this field
+ include:
+
+ - Router interface number
+ - Switching Hub port number
+ - Remote Access Server port number
+ - Frame Relay DLCI
+ - ATM virtual circuit number
+ - Cable Data virtual circuit number
+
+ Servers MAY use the Circuit ID for IP and other parameter assignment
+ policies. The Circuit ID SHOULD be considered an opaque value, with
+ policies based on exact string match only; that is, the Circuit ID
+ SHOULD NOT be internally parsed by the server.
+
+ The DHCP server SHOULD report the Agent Circuit ID value of current
+ leases in statistical reports (including its MIB) and in logs. Since
+ the Circuit ID is local only to a particular relay agent, a circuit
+ ID should be qualified with the giaddr value that identifies the
+ relay agent.
+
+ SubOpt Len Circuit ID
+ +------+------+------+------+------+------+------+------+--
+ | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ...
+ +------+------+------+------+------+------+------+------+--
+
+
+
+
+
+
+
+Patrick Standards Track [Page 8]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+3.2 Agent Remote ID Sub-option
+
+ This sub-option MAY be added by DHCP relay agents which terminate
+ switched or permanent circuits and have mechanisms to identify the
+ remote host end of the circuit. The Remote ID field may be used to
+ encode, for instance:
+
+ -- a "caller ID" telephone number for dial-up connection
+ -- a "user name" prompted for by a Remote Access Server
+ -- a remote caller ATM address
+ -- a "modem ID" of a cable data modem
+ -- the remote IP address of a point-to-point link
+ -- a remote X.25 address for X.25 connections
+
+ The remote ID MUST be globally unique.
+
+ DHCP servers MAY use this option to select parameters specific to
+ particular users, hosts, or subscriber modems. The option SHOULD be
+ considered an opaque value, with policies based on exact string match
+ only; that is, the option SHOULD NOT be internally parsed by the
+ server.
+
+ The relay agent MAY use this field in addition to or instead of the
+ Agent Circuit ID field to select the circuit on which to forward the
+ DHCP reply (e.g., Offer, Ack, or Nak). DHCP servers SHOULD report
+ this value in any reports or MIBs associated with a particular
+ client.
+
+ SubOpt Len Agent Remote ID
+ +------+------+------+------+------+------+------+------+--
+ | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ...
+ +------+------+------+------+------+------+------+------+--
+
+4.0 Issues Resolved
+
+ The DHCP relay agent option resolves several issues in an environment
+ in which untrusted hosts access the internet via a circuit based
+ public network. This resolution assumes that all DHCP protocol
+ traffic by the public hosts traverse the DHCP relay agent and that
+ the IP network between the DHCP relay agent and the DHCP server is
+ uncompromised.
+
+ Broadcast Forwarding
+
+ The circuit access equipment forwards the normally broadcasted
+ DHCP response only on the circuit indicated in the Agent Circuit
+ ID.
+
+
+
+
+Patrick Standards Track [Page 9]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+ DHCP Address Exhaustion
+
+ In general, the DHCP server may be extended to maintain a database
+ with the "triplet" of
+
+ (client IP address, client MAC address, client remote ID)
+
+ The DHCP server SHOULD implement policies that restrict the number
+ of IP addresses to be assigned to a single remote ID.
+
+ Static Assignment
+
+ The DHCP server may use the remote ID to select the IP address to
+ be assigned. It may permit static assignment of IP addresses to
+ particular remote IDs, and disallow an address request from an
+ unauthorized remote ID.
+
+ IP Spoofing
+
+ The circuit access device may associate the IP address assigned by
+ a DHCP server in a forwarded DHCP Ack packet with the circuit to
+ which it was forwarded. The circuit access device MAY prevent
+ forwarding of IP packets with source IP addresses -other than-
+ those it has associated with the receiving circuit. This prevents
+ simple IP spoofing attacks on the Central LAN, and IP spoofing of
+ other hosts.
+
+ Client Identifier Spoofing
+
+ By using the agent-supplied Agent Remote ID option, the untrusted
+ and as-yet unstandardized client identifier field need not be used
+ by the DHCP server.
+
+ MAC Address Spoofing
+
+ By associating a MAC address with an Agent Remote ID, the DHCP
+ server can prevent offering an IP address to an attacker spoofing
+ the same MAC address on a different remote ID.
+
+5.0 Security Considerations
+
+ DHCP as currently defined provides no authentication or security
+ mechanisms. Potential exposures to attack are discussed in section 7
+ of the DHCP protocol specification in RFC 2131 [1].
+
+ This document introduces mechanisms to address several security
+ attacks on the operation of IP address assignment, including IP
+ spoofing, Client ID spoofing, MAC address spoofing, and DHCP server
+
+
+
+Patrick Standards Track [Page 10]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+ address exhaustion. It relies on an implied trusted relationship
+ between the DHCP Relay Agent and the DHCP server, with an assumed
+ untrusted DHCP client. It introduces a new identifer, the "Remote
+ ID", that is also assumed to be trusted. The Remote ID is provided
+ by the access network or modem and not by client premise equipment.
+ Cryptographic or other techniques to authenticate the remote ID are
+ certainly possible and encouraged, but are beyond the scope of this
+ document.
+
+ This option is targeted towards environments in which the network
+ infrastructure -- the relay agent, the DHCP server, and the entire
+ network in which those two devices reside -- is trusted and secure.
+ As used in this document, the word "trusted" implies that
+ unauthorized DHCP traffic cannot enter the trusted network except
+ through secured and trusted relay agents and that all devices
+ internal to the network are secure and trusted. Potential deployers
+ of this option should give careful consideration to the potential
+ security vulnerabilities that are present in this model before
+ deploying this option in actual networks.
+
+ Note that any future mechanisms for authenticating DHCP client to
+ server communications must take care to omit the DHCP Relay Agent
+ option from server authentication calculations. This was the
+ principal reason for organizing the DHCP Relay Agent Option as a
+ single option with sub-options, and for requiring the relay agent to
+ remove the option before forwarding to the client.
+
+ While it is beyond the scope of this document to specify the general
+ forwarding algorithm of public data circuit access units, note that
+ automatic reforwarding of IP or ARP broadcast packets back downstream
+ exposes serious IP security risks. For example, if an upstream
+ broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back
+ downstream, any public host may easily spoof the desired DHCP server.
+
+6.0 IANA Considerations
+
+ IANA is required to maintain a new number space of "DHCP Relay Agent
+ Sub-options", located in the BOOTP-DHCP Parameters Registry. The
+ initial sub-options are described in section 2.0 of this document.
+
+ IANA assigns future DHCP Relay Agent Sub-options with a "IETF
+ Consensus" policy as described in RFC 2434 [3]. Future proposed
+ sub-options are to be referenced symbolically in the Internet-Drafts
+ that describe them, and shall be assigned numeric codes by IANA when
+ approved for publication as an RFC.
+
+
+
+
+
+
+Patrick Standards Track [Page 11]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+7.0 Intellectual Property Notices
+
+ This section contains two notices as required by [5] for standards
+ track documents.
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF has been notified of intellectual property rights claimed in
+ regard to some or all of the specification contained in this
+ document. For more information consult the online list of claimed
+ rights.
+
+8.0 References
+
+ [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+ March 1997.
+
+ [2] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+ Extension", RFC 2132, March 1997.
+
+ [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+ [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [5] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+ 9, RFC 2026, October 1996.
+
+ [6] Kent, S. and R. Atkinson, "Security Architecture for the
+ Internet Protocol", RFC 2401, November 1998.
+
+
+
+
+
+
+
+
+Patrick Standards Track [Page 12]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+9.0 Glossary
+
+ DSLAM Digital Subscriber Link Access Multiplexer
+ IANA Internet Assigned Numbers Authority
+ LIS Logical IP Subnet
+ MAC Message Authentication Code
+ RAS Remote Access Server
+
+10.0 Author's Address
+
+ Michael Patrick
+ Motorola Broadband Communications Sector
+ 20 Cabot Blvd., MS M4-30
+ Mansfield, MA 02048
+
+ Phone: (508) 261-5707
+ EMail: michael.patrick@motorola.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Patrick Standards Track [Page 13]
+
+RFC 3046 DHCP Relay Agent Information Option January 2001
+
+
+11.0 Full Copyright Statement
+
+ Copyright (C) The Internet Society (2001). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Patrick Standards Track [Page 14]
+