draft-ietf-dhc-leasequery-04.txt   draft-ietf-dhc-leasequery-05.txt 
Dynamic Host Configuration Working Group Rich Woundy Dynamic Host Configuration Working Group Rich Woundy
INTERNET DRAFT Kim Kinnear INTERNET DRAFT Comcast Cable
Kim Kinnear
Cisco Systems Cisco Systems
October 2002 March 2003
Expires April 2003 Expires September 2003
DHCP Lease Query DHCP Lease Query
<draft-ietf-dhc-leasequery-04.txt> <draft-ietf-dhc-leasequery-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 36 skipping to change at page 1, line 38
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
Access concentrators that act as DHCP relay agents need to determine A DHCP server contains considerable authoritative information
the endpoint locations of IP addresses across public broadband access concerning the IP addresses it has leased to DHCP clients. Other
networks such as cable, DSL, and wireless networks. Because ARP processes and devices, many that already send and receive DHCP format
broadcasts are undesirable in public networks, many access packets, sometimes need to access this information. The leasequery
concentrator implementations "glean" location information from DHCP protocol is designed to give these processes and devices a
messages forwarded by its relay agent function. Unfortunately, the lightweight way to access information that may be critical to their
typical access concentrator loses its gleaned information when the operation.
access concentrator is rebooted or is replaced. This memo proposes
that when gleaned DHCP information is not available, the access
concentrator/relay agent obtains the location information directly
from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY
message.
1. Introduction 1. Introduction
In many broadband access networks, the access concentrator needs to A DHCP server contains considerable authoritative information con-
associate an IP address lease to the correct endpoint location, which cerning the IP addresses it has leased to DHCP clients. Other
includes knowledge of the host hardware address, the port or virtual processes and devices, many that already send and receive DHCP format
circuit that leads to the host, and/or the hardware address of the packets, sometimes need to access this information. The leasequery
intervening subscriber modem. This is particularly important when protocol is designed to give these processes and devices a light-
one or more IP subnets are shared among many ports, circuits, and weight way to access information that may be critical to their opera-
modems. Representative cable and DSL environments are depicted in tion.
Figures 1 and 2 below.
For example, access concentrators that act as DHCP relay agents some-
times derive information important to their operation by extracting
data out of the DHCP packets they forward, a process known as "glean-
ing". Unfortunately, the typical access concentrator loses its
gleaned information when the access concentrator is rebooted or is
replaced. This memo proposes that when gleaned DHCP information is
not available, the access concentrator/relay agent can obtain the
location information directly from the DHCP server(s) using the new
lightweight DHCPLEASEQUERY message.
To continue this example in more depth, in many broadband access net-
works, the access concentrator needs to associate an IP address lease
to the correct endpoint location, which includes knowledge of the
host hardware address, the port or virtual circuit that leads to the
host, and/or the hardware address of the intervening subscriber
modem. This is particularly important when one or more IP subnets
are shared among many ports, circuits, and modems. Representative
cable and DSL environments are depicted in Figures 1 and 2 below.
+--------+ +---------------+ +--------+ +---------------+
| DHCP | | DOCSIS CMTS | | DHCP | | DOCSIS CMTS |
| Server |-...-| or DVB INA |------------------- | Server |-...-| or DVB INA |-------------------
+--------+ | (Relay Agent) | | | +--------+ | (Relay Agent) | | |
+---------------+ +------+ +------+ +---------------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
skipping to change at page 3, line 4 skipping to change at page 3, line 18
+---------------+ | | +---------------+ | |
+------+ +------+ +------+ +------+
|Modem1| |Modem2| |Modem1| |Modem2|
+------+ +------+ +------+ +------+
| | | | | |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
|Host1| |Host2| |Host3| |Host1| |Host2| |Host3|
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
Figure 2: DSL Environment for DHCPLEASEQUERY Figure 2: DSL Environment for DHCPLEASEQUERY
Knowledge of this location information benefits the access concentra-
tor in several ways: Knowledge of this location information can benefit the access concen-
trator in several ways:
1. The access concentrator can forward traffic to the access net- 1. The access concentrator can forward traffic to the access net-
work using the correct access network port, down the correct work using the correct access network port, down the correct
virtual circuit, through the correct modem, to the correct virtual circuit, through the correct modem, to the correct
hardware address. hardware address.
2. The access concentrator can perform IP source address verifica- 2. The access concentrator can perform IP source address verifica-
tion of datagrams received from the access network. The verif- tion of datagrams received from the access network. The verif-
ication may be based on the datagram source hardware address, ication may be based on the datagram source hardware address,
the incoming access network port, the incoming virtual circuit, the incoming access network port, the incoming virtual circuit,
and/or the transmitting modem. and/or the transmitting modem.
3. The access concentrator can encrypt datagrams which can only be 3. The access concentrator can encrypt datagrams which can only be
decrypted by the correct modem, using mechanisms such as [BPI] decrypted by the correct modem, using mechanisms such as [BPI]
or [BPI+]. or [BPI+].
The premise of this document is that the access concentrator obtains The access concentrator in this example obtains the location informa-
this location information primarily from "gleaning" information from tion primarily from "gleaning" information from DHCP server responses
DHCP server responses sent through the relay agent. When location sent through the relay agent. When location information is not
information is not available from "gleaning", e.g. due to reboot, available from "gleaning", e.g. due to reboot, the access concentra-
the access concentrator can query the DHCP server(s) for location tor can query the DHCP server(s) for location information using the
information using the DHCPLEASEQUERY message. The DHCPLEASEQUERY DHCPLEASEQUERY message defined in this document.
mechanism is the focus of this document.
The DHCPLEASEQUERY message is a new DHCP message type transmitted The DHCPLEASEQUERY message is a new DHCP message type transmitted
from a DHCP relay agent to a DHCP server. The DHCPLEASEQUERY-aware from a DHCP relay agent to a DHCP server. A DHCPLEASEQUERY-aware
relay agent sends the DHCPLEASEQUERY message when it needs to know relay agent sends the DHCPLEASEQUERY message when it needs to know
the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server the location of an IP endpoint. The DHCPLEASEQUERY-aware DHCP server
replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN replies with a DHCPLEASEKNOWN, DHCPLEASEACTIVE or DHCPLEASEUNKNOWN
message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message message. The DHCPLEASEACTIVE response to a DHCPLEASEQUERY message
allows the relay agent to determine the IP endpoint location, and the allows the relay agent to determine the IP endpoint location, and the
remaining duration of the IP address lease. The DHCPLEASEKNOWN is remaining duration of the IP address lease. The DHCPLEASEKNOWN is
similar to a DHCPLEASEACTIVE message but indicates that there is no similar to a DHCPLEASEACTIVE message but indicates that there is no
currently active lease on the resultant IP address. The DHCPLEASEUN- currently active lease on the resultant IP address. The DHCPLEASEUN-
KNOWN message indicates that the DHCP server has no knowledge of the KNOWN message indicates that the DHCP server has no knowledge of the
information specified in the query (e.g., IP address, MAC address, or information specified in the query (e.g., IP address, MAC address, or
client-id option). client-id option).
The DHCPLEASEQUERY message does not presuppose a particular use for
the information it returns -- it is simply designed to return infor-
mation for which the DHCP server is an authoritative source to a
client which requests that information. It is designed to make it
straightforward for processes and devices which already interpret
DHCP packets to access information from the DHCP server.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC 2119]. document are to be interpreted as described in RFC 2119 [RFC 2119].
This document uses the following terms: This document uses the following terms:
o "access concentrator" o "access concentrator"
skipping to change at page 5, line 44 skipping to change at page 6, line 20
information is not lost in the event of a server failure which information is not lost in the event of a server failure which
requires restart of the server. requires restart of the server.
o "upstream" o "upstream"
Upstream is the direction from the broadband subscriber towards Upstream is the direction from the broadband subscriber towards
the access concentrator. the access concentrator.
3. Background 3. Background
The focus of this document is to enable access concentrators to send The focus of this document is to enable processes and devices which
DHCPLEASEQUERY messages to DHCP servers, to obtain location informa- wish to access information from the DHCP server in a lightweight and
tion of broadband access network devices. convenient manner. It is especially appropriate for processes and
devices which already interpret DHCP packets.
One important motivating example is that the DHCPLEASEQUERY message
allows access concentrators to send DHCPLEASEQUERY messages to DHCP
servers, to obtain location information of broadband access network
devices.
This document assumes that many access concentrators have an embedded This document assumes that many access concentrators have an embedded
DHCP relay agent functionality. Typical access concentrators include DHCP relay agent functionality. Typical access concentrators include
DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac- DOCSIS Cable Modem Termination Systems (CMTSs) [DOCSIS], DVB Interac-
tive Network Adapters (INAs) [EUROMODEM], and DSL Access tive Network Adapters (INAs) [EUROMODEM], and DSL Access Concentra-
Concentrators. tors.
The DHCPLEASEQUERY message is an optional extension to the DHCP pro- The DHCPLEASEQUERY message is an optional extension to the DHCP pro-
tocol [RFC 2131]. Unlike previous DHCP message types, the DHCP relay tocol [RFC 2131].
agent originates and sends the DHCPLEASEQUERY message to the DHCP
server, and processes the reply from the DHCP server.
In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message In a DHCP Failover environment [FAILOVER], the DHCPLEASEQUERY message
can be sent to the primary or secondary DHCP server. In order for the can be sent to the primary or secondary DHCP server. In order for the
secondary DHCP server to answer DHCPLEASEQUERY messages, the primary secondary DHCP server to answer DHCPLEASEQUERY messages, the primary
DHCP server must send "interesting options" (such as the relay- DHCP server must send "interesting options" (such as the relay-
agent-information option [RFC 3046]) in Failover BNDUPD messages to agent-information option [RFC 3046]) in Failover BNDUPD messages to
the secondary DHCP server, as recommended by section 7.1.1 of [FAIL- the secondary DHCP server, as recommended by section 7.1.1 of [FAIL-
OVER]. OVER].
The DHCPLEASEQUERY message is a query message only, and does not The DHCPLEASEQUERY message is a query message only, and does not
affect the state of the IP address or the binding information associ- affect the state of the IP address or the binding information associ-
ated with it. ated with it.
4. Design Goals 4. Design Goals
The core requirement of this document is to provide a lightweight The goal of this document is to provide a lightweight mechanism for
mechanism for access concentrator implementations to obtain location processes or devices to access information contained in the DHCP
information for broadband access network devices. The specifics of server. It is designed to allow processes and devices which already
the broadband environment that drove the approach of this document process and interpret DHCP messages to access this information in a
follow. rapid and lightweight manner.
Some of this information might be acquired in a different way, and
the following sections discuss some of these alternative approaches.
4.1. Broadcast ARP is Undesirable 4.1. Broadcast ARP is Undesirable
The access concentrator can transmit a broadcast ARP Request [RFC The access concentrator can transmit a broadcast ARP Request [RFC
826], and observe the origin and contents of the ARP Reply, to recon- 826], and observe the origin and contents of the ARP Reply, to recon-
struct the location information. struct the location information.
The ARP mechanism is undesirable for three reasons: The ARP mechanism is undesirable for three reasons:
1. the burden on the access concentrator to transmit over multiple 1. the burden on the access concentrator to transmit over multiple
skipping to change at page 8, line 7 skipping to change at page 8, line 34
DHCP server is a single point of failure. DHCP server is a single point of failure.
4.5. Minimal Additional Configuration is Required 4.5. Minimal Additional Configuration is Required
Access concentrators can usually query the same set of DHCP servers Access concentrators can usually query the same set of DHCP servers
used for forwarding by the relay agent, thus minimizing configuration used for forwarding by the relay agent, thus minimizing configuration
requirements. requirements.
5. Protocol Overview 5. Protocol Overview
In the following discussion of the DHCPLEASEQUERY message, the client
of the message is assumed to be an access concentrator. Note that
access concentrators are not the only allowed (or required) consumers
of the information provided by the DHCPLEASEQUERY message, but they
do give reader a concrete feel for how the message might be used.
The access concentrator initiates all DHCPLEASEQUERY message conver- The access concentrator initiates all DHCPLEASEQUERY message conver-
sations. This document assumes that the access concentrator gleans sations. This document assumes that the access concentrator gleans
location information in its DHCP relay agent function. However, the location information in its DHCP relay agent function. However, the
location information is usually unavailable after the reboot or location information is usually unavailable after the reboot or
replacement of the access concentrator. replacement of the access concentrator.
Suppose the access concentrator is a router, and further suppose that Suppose the access concentrator is a router, and further suppose that
the router receives an IP datagram to forward downstream to the pub- the router receives an IP datagram to forward downstream to the pub-
lic broadband access network. If the location information for the lic broadband access network. If the location information for the
downstream next hop is missing, the access concentrator sends one or downstream next hop is missing, the access concentrator sends one or
skipping to change at page 9, line 14 skipping to change at page 9, line 51
assigned that IP address. assigned that IP address.
The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE The DHCP server replies with a DHCPLEASEKNOWN or DHCPLEASEACTIVE
message if the IP address in the DHCPLEASEQUERY message message if the IP address in the DHCPLEASEQUERY message
corresponds to an IP address about which the server has defini- corresponds to an IP address about which the server has defini-
tive information (ie., it is authorized to lease this IP tive information (ie., it is authorized to lease this IP
address). The server replies with a DHCPLEASEUNKNOWN message if address). The server replies with a DHCPLEASEUNKNOWN message if
the server does not have definitive information concerning the the server does not have definitive information concerning the
address in the DHCPLEASEQUERY message. address in the DHCPLEASEQUERY message.
A server which implements the DHCPLEASEQUERY message MUST imple- A server which implements the DHCPLEASEQUERY message MUST
ment this capability. implement this capability.
o Query by MAC address: o Query by MAC address:
For this query, the requester supplies only a MAC address in the For this query, the requester supplies only a MAC address in the
DHCPLEASEQUERY message. The DHCP server will return any infor- DHCPLEASEQUERY message. The DHCP server will return any infor-
mation that it has on the IP address most recently accessed by a mation that it has on the IP address most recently accessed by a
client with that MAC address. In addition, it may supply addi- client with that MAC address. In addition, it may supply addi-
tion IP addresses which have been associated with that MAC tion IP addresses which have been associated with that MAC
address in different subnets. Information about these bindings address in different subnets. Information about these bindings
can then be found using the Query by IP Address, described can then be found using the Query by IP Address, described
skipping to change at page 12, line 8 skipping to change at page 12, line 30
TBD DHCPUNIMPLEMENTED TBD DHCPUNIMPLEMENTED
2. There is a new bit defined in the "flags" field of the DHCP 2. There is a new bit defined in the "flags" field of the DHCP
packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It packet (see Section 1, Figure 1 and Table 1 of [RFC 2131]). It
is called the R: RESERVATION flag. The revised Figure 2 from is called the R: RESERVATION flag. The revised Figure 2 from
[RFC 2131] is show here: [RFC 2131] is show here:
1 1 1 1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B| tbd MBZ | |B|R| MBZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B: BROADCAST flag B: BROADCAST flag
R: RESERVATION FLAG R: RESERVATION FLAG
MBZ: MUST BE ZERO (reserved for future use) MBZ: MUST BE ZERO (reserved for future use)
Revised Figure 2 from RFC2131: Revised Figure 2 from RFC2131:
Format of the 'flags' field Format of the 'flags' field
skipping to change at page 22, line 51 skipping to change at page 23, line 20
7. Security Considerations 7. Security Considerations
Access concentrators that use DHCP gleaning, refreshed with Access concentrators that use DHCP gleaning, refreshed with
DHCPLEASEQUERY messages, will maintain accurate location information. DHCPLEASEQUERY messages, will maintain accurate location information.
Location information accuracy ensures that the access concentrator Location information accuracy ensures that the access concentrator
can forward data traffic to the intended location in the broadband can forward data traffic to the intended location in the broadband
access network, can perform IP source address verification of access network, can perform IP source address verification of
datagrams from the access network, and can encrypt traffic which can datagrams from the access network, and can encrypt traffic which can
only be decrypted by the intended access modem (e.g. [BPI] and only be decrypted by the intended access modem (e.g. [BPI] and
[BPI+]). As a result, the access concentrator does not need to [BPI+]). As a result, the access concentrator does not need to
depend on ARP broadcasts across the access network, which is depend on ARP broadcasts across the access network, which is suscep-
susceptible to malicious hosts which masquerade as the intended IP tible to malicious hosts which masquerade as the intended IP end-
endpoints. Thus, the DHCPLEASEQUERY message allows an access concen- points. Thus, the DHCPLEASEQUERY message allows an access concentra-
trator to provide considerably enhanced security. tor to provide considerably enhanced security.
DHCP servers SHOULD prevent exposure of location information (partic- DHCP servers SHOULD prevent exposure of location information (partic-
ularly the mapping of hardware address to IP address lease, which can ularly the mapping of hardware address to IP address lease, which can
be an invasion of broadband subscriber privacy) by leveraging DHCP be an invasion of broadband subscriber privacy) by leveraging DHCP
authentication [RFC 3118]. With respect to authentication, the authentication [RFC 3118]. With respect to authentication, the
access concentrator acts as the "client". The use of "Authentication access concentrator acts as the "client". The use of "Authentication
Protocol 0" (using simple unencoded authentication token(s) between Protocol 0" (using simple unencoded authentication token(s) between
the access concentrator and the DHCP server) is straightforward. the access concentrator and the DHCP server) is straightforward.
Alternatively, use of IPsec would also be a way to ensure security Alternatively, use of IPsec would also be a way to ensure security
between the relay agent and the DHCP server. between the relay agent and the DHCP server.
skipping to change at page 25, line 20 skipping to change at page 25, line 34
for digital bi-directional communications via cable networks", for digital bi-directional communications via cable networks",
Version 1.0, May 1999. Version 1.0, May 1999.
[FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., [FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S.,
Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol", Rabil, G., Dooley, M., Kapur, A., "DHCP Failover Protocol",
draft-ietf-dhc-failover-10.txt, January 2002. draft-ietf-dhc-failover-10.txt, January 2002.
11. Author's information 11. Author's information
Rich Woundy Rich Woundy
AT&T Broadband Comcast Cable
27 Industrial Ave. 27 Industrial Ave.
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 244-4010 Phone: (978) 244-4010
EMail: rwoundy@broadband.att.com EMail: richard_woundy@cable.comcast.com
Kim Kinnear Kim Kinnear
Cisco Systems Cisco Systems
250 Apollo Drive 250 Apollo Drive
Chelmsford, MA 01824 Chelmsford, MA 01824
Phone: (978) 497-8000 Phone: (978) 497-8000
EMail: kkinnear@cisco.com EMail: kkinnear@cisco.com
12. Intellectual Property Statement 12. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any intel- The IETF takes no position regarding the validity or scope of any intel-
lectual property or other rights that might be claimed to pertain to lectual property or other rights that might be claimed to pertain to
the implementation or use of the technology described in this document 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 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 be available; neither does it represent that it has made any effort to
identify any such rights. Information on the IETF's procedures with identify any such rights. Information on the IETF's procedures with
skipping to change at page 26, line 17 skipping to change at page 26, line 28
the use of such proprietary rights by implementors or users of this the use of such proprietary rights by implementors or users of this
specification can be obtained from the IETF Secretariat. specification can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
which may cover technology that may be required to practice this stan- which may cover technology that may be required to practice this stan-
dard. Please address the information to the IETF Executive Director. dard. Please address the information to the IETF Executive Director.
13. Full Copyright Statement 13. Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to oth- This document and translations of it may be copied and furnished to oth-
ers, and derivative works that comment on or otherwise explain it or ers, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and dis- assist in its implementation may be prepared, copied, published and dis-
tributed, in whole or in part, without restriction of any kind, provided tributed, in whole or in part, without restriction of any kind, provided
that the above copyright notice and this paragraph are included on all that the above copyright notice and this paragraph are included on all
such copies and derivative works. However, this document itself may not such copies and derivative works. However, this document itself may not
be modified in any way, such as by removing the copyright notice or be modified in any way, such as by removing the copyright notice or
references to the Internet Society or other Internet organizations, references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/