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