DHC Working Group B. Joshi Internet-Draft P. Kurapati Expires: March 23, 2007 Infosys Technologies Ltd. September 19, 2006 Extension of DHCP Leasequery in Bridging/Switching networks draft-joshi-dhcp-lease-query-ext-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 23, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract As per industry trends, Access Networks have been migrating from traditional ATM based networks to Ethernet networks. In Ethernet based access networks, Access Concentrators are typically configured to act as traditional bridge. These Access Concentrators also act as relay agents and relay DHCP messages between hosts and DHCP servers. It also maintains and updates lease/location information while relaying the DHCP messages. Access Concentrators may use the lease/ location information for anti-spoofing, data forwarding etc. This Joshi & Kurapati Expires March 23, 2007 [Page 1] Internet-Draft Extension of DHCP Leasequery September 2006 lease/location information is lost if an Access Concentrator gets rebooted. RFC 4388 [5] has defined a new message type DHCPLEASEQUERY to address similar limitation in Routed Access Networks. This document initially gives an overview of the functioning of the Access Concentrator acting as a relay agent in a Layer 2 aggregation network. The limitation[as mentioned above] in a typical switched/ bridged[layer 2] is then discussed followed by the proposal to extend the DHCPLEASEQUERY message to address this limitation. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Typical layer 2 access network . . . . . . . . . . . . . . . . 6 3.1. Access Concentrator acting as Layer 2 DHCP relay agent . . 6 4. Protocol Extension Overview . . . . . . . . . . . . . . . . . 8 4.1. Lease/Location information in layer 2 Networks . . . . . . 8 4.2. Extension of DHCPLEASEQUERY in layer 2 Networks . . . . . 8 5. Protocol Extension Details . . . . . . . . . . . . . . . . . . 9 5.1. Definition required for extension of DHCPLEASEQUERY message . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Generating DHCPLEASEQUERY Message . . . . . . . . . . . . 9 5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent . . 11 5.4. Handling DHCPLEASEQUERY Message in DHCP Server . . . . . . 12 5.5. Handling DHCP Reply Message in Layer-3 Relay Agent . . . . 12 5.6. Handling DHCP Reply Message in Access Concentrator . . . . 13 5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message . . . . . . 13 5.6.2. Handling DHCPLEASEUNKNOWN Reply Message . . . . . . . 13 5.6.3. Handling DHCPLEASEACTIVE Reply Message . . . . . . . . 13 5.6.4. Handling multiple responses for DHCPLEASEQUERY Message . . . . . . . . . . . . . . . . . . . . . . . 13 5.6.5. Handling No Response to the DHCPLEASEQUERY Message . . 14 5.6.6. Handling DHCPLEASEQUERY messages not belonging to Access Concentrator . . . . . . . . . . . . . . . . . 14 6. Lease query using Management IP address of Access Concentrator . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 19 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Joshi & Kurapati Expires March 23, 2007 [Page 2] Internet-Draft Extension of DHCP Leasequery September 2006 1. Introduction Access networks are undergoing transformation from traditional ATM based networks to Ethernet based networks. Service providers have deployed Access Concentrators in both Routing and Bridging modes. In the Routing mode, Access Concentrator terminates the user connection and 'routes' the packets to the edge/core network. In the bridging mode, Access Concentrator does frame switching based on MAC address, VLANs etc. It also supports DHCP/PPPoE/IGMP snooping for better security and bandwidth management. In case of DHCP/PPPoE snooping, Access Concentrator acts as a Relay Agent. In both routing and bridging mode, Access Concentrator maintains lease/location information by extracting it from the DHCP replies received from the DHCP server. This information is typically maintained for anti-spoofing, data forwarding etc. This lease/ location information is lost when Access Concentrator gets rebooted. RFC 4388 [5] has defined a method to access information from the DHCP server in a lightweight and consistent manner. This is achieved by the use of a new message type "DHCPLEASEQUERY" that allows Relay Agents to query DHCP servers to obtain location information of DHCP clients. RFC 4388 [5] assumes that in a typical access environment, Access Concentrator acts as a Layer 3 DHCP Relay Agent. This document suggests extension to RFC 4388 [5] to make it suitable in a layer 2 access environment. Joshi & Kurapati Expires March 23, 2007 [Page 3] Internet-Draft Extension of DHCP Leasequery September 2006 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. This document uses the following terms: o "Access Concentrator" An Access Concentrator is a router or switch at the broadband access provider's edge of a public broadband access network. This document assumes that the Access Concentrator acts as a Transparent Bridge and includes the DHCP relay agent functionality. For example: In DSL environment, this is typically known as DSLAM.(Digital Subscriber Line Access Multiplexer) o "DHCP client" A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. o "Layer-3 Relay Agent" A Layer-3 Relay Agent is a third-party agent that transfers Bootstrap Protocol (BOOTP) and DHCP messages between clients and servers residing on different subnets, per [RFC951] and [RFC1542]. o "DHCP server" A DHCP server is an Internet host that returns configuration parameters to DHCP clients. o "downstream" Downstream is the direction from the edge network towards the DHCP Clients. o "lease/location information" Lease/Location information is information maintained by the Access Concentrator to either forward traffic to a broadband-accessible host or for anti-spoofing of MAC address/IP address or for both. This information includes knowledge of the host hardware address, host IP address, the port or virtual circuit that leads to the host, lease timeout for the associated IP address and/or the hardware address of the intervening subscriber modem. Joshi & Kurapati Expires March 23, 2007 [Page 4] Internet-Draft Extension of DHCP Leasequery September 2006 o "MAC address" In the context of a DHCP packet, a MAC address consists of the following fields: hardware type "htype", hardware length "hlen", and client hardware address "chaddr". o "Transparent Bridge" A device which does bridging based on MAC learning principles. Bridge learns the Source MAC of the incoming frames and updates a table with MAC/Interface information. While forwarding data packets, bridge looks at this table to find the outgoing interface. o "upstream" Upstream is the direction from the DHCP Clients towards the edge network. Joshi & Kurapati Expires March 23, 2007 [Page 5] Internet-Draft Extension of DHCP Leasequery September 2006 3. Typical layer 2 access network Figure 1 shows a typical access network where the Access Concentrator acts as a traditional Transparent Bridge. In a typical layer 2 access network, multiple hosts may be connected to each port. These hosts use DHCP to receive User/Host Specific configuration details. Access concentrator snoops DHCP requests and append relay agent information before bridging them to the upstream Layer-3 Relay Agent. A DHCP server may use the Relay Agent information to apply policies for allocation of specific configuration details like IP address etc. +-------------+ | DHCP Server | +--+----------+ | ---+---+-------- LAN | +------------+ | | |------------- user#1 +------+----------+ VLAN | Access |------------- user#1 | Layer-3 Relay |----------|Concentrator| : | Agent | | (Bridge) | : +-----------------+ | |------------- user#n +------------+ Figure 1 3.1. Access Concentrator acting as Layer 2 DHCP relay agent In access networks, Access Concentrator acting as Transparent Bridge can also act as a Layer 2 DHCP Relay Agent. In figure 1, Layer-3 Relay Agent can not correctly identify the end hosts so Access Concentrator needs to append Relay Agent Information [option 82] to each DHCP packet before forwarding it to Layer-3 Relay Agent. When a DHCP reply is received, Access concentrator uses the Relay Agent option [option 82] to identify the outgoing interface. Access Concentrator removes the Relay Agent option before forwarding DHCP reply to end hosts. In layer 2 mode, Access Concentrator does not set the "giaddr" field in the DHCP request before it forwards the request to DHCP server. When the Layer-3 Relay Agent receives a DHCP packet from the Access Concentrator with Relay Agent option already added, it should populate the giaddr field and relay that packet to the DHCP servers. This process is inline with RFC 3046 [3] which says that if the DHCP packet is from a trusted entity, Relay Agent MUST add the "giaddr" field before forwarding the DHCP request to DHCP server. Layer-3 Joshi & Kurapati Expires March 23, 2007 [Page 6] Internet-Draft Extension of DHCP Leasequery September 2006 Relay Agent SHOULD set the "giaddr" field with the IP address of the interface on which the DHCP request is received. When DHCP server reply to such a DHCP request, it sets the destination IP address in IP header to the "giaddr" value. When Layer-3 Relay Agent receives the DHCP reply, it identifies the outgoing interface based on the destination IP address in the DHCP reply. Layer-3 Relay Agent does not remove the DHCP Relay Agent option and forwards the DHCP reply to the Access Concentrator. Access Concentrator snoops the DHCP reply message, removes the Relay Agent option and identifies the outgoing interface based on the details in Relay Agent option [3]. Joshi & Kurapati Expires March 23, 2007 [Page 7] Internet-Draft Extension of DHCP Leasequery September 2006 4. Protocol Extension Overview 4.1. Lease/Location information in layer 2 Networks An Access Concentrator snoops all DHCP messages and maintains the information of outgoing interface, MAC Address, IP address and Lease information for each DHCP Client. This information [MAC-IP-Interface Binding] may be used to prevent MAC/IP Spoofing attacks and may also be used for bridging frames. 4.2. Extension of DHCPLEASEQUERY in layer 2 Networks Access Concentrator acting as Transparent Bridge typically maintains lease/location information for all DHCP clients. This makes it vulnerable to the same issue [location/lease information lost when Access Concentrator gets rebooted] which has been addressed in RFC 4388 [5] for Layer 3 networks. This document extends mechanism proposed in [5] to address this issue for layer 2 networks. When Access Concentrator needs to bridge a frame, it MAY refer to location/lease information to verify the IP address or MAC address. If the location/lease information is not available, Access Concentrator can query DHCP server to obtain the lease/location information using DHCPLEASEQUERY message. Access Concentrator can generate a DHCPLEASEQUERY [Query by IP address, MAC address or client identifier [9]] with all the fields properly populated as defined in RFC 4388 [5]. When Layer-3 Relay Agent receives a DHCPLEASEQUERY, before forwarding it to DHCP server, it MUST populate the "giaddr" field with the IP address of the interface on which the request has been received. Layer-3 Relay Agent should forward this DHCPLEASEQUERY to a particular DHCP server, if it knows which DHCP server might possess location/lease information for the given IP address or it should send it to all the DHCP servers configured in the Layer-3 Relay Agent. DHCP reply message for DHCPLEASEQUERY would have destination IP address as the IP address mentioned in "giaddr" field of DHCP request. DHCP server also appends Relay Agent option in the DHCP reply. When Layer-3 Relay Agent processes the DHCP reply, it identifies the outgoing interface based on the destination IP address of the DHCP reply message. Access Concentrator receives the DHCP reply and can retrieve the location/lease information from the reply message. Joshi & Kurapati Expires March 23, 2007 [Page 8] Internet-Draft Extension of DHCP Leasequery September 2006 5. Protocol Extension Details 5.1. Definition required for extension of DHCPLEASEQUERY message The extension of DHCP Leasequery to switched/bridged networks requires the definition of following new option for DHCP packet beyond those defined by [RFC2131] and [RFC2132]. See also Section 7, IANA Considerations. 1. There is a new option "access-concentrator-hwaddr": access-concentrator-hwaddr This option allows a Layer 3 Relay agent to unicast a DHCP reply for a DHCPLEASEQUERY message to the Access Concentrator which had generated the DHCPLEASEQUERY message. The code for this option need to be allocated by IANA. The length of this option is 18. code [Hardware address details] +------+------+------------+------------+ | X | len | htype (1) | hwaddr | +------+------+------------+------------+ In the above option: o 'X' need to be allocated by IANA. o "len" field contains the length of the "Hardware address details" and can be used to deduce length of "hwaddr" field. o "htype" represents Hardware type. See the 'ARP parameters' maintained in the database referenced by Assigned numbers RFC 3232[4]. o "hwaddr" is Access Concentrator hardware address. 5.2. Generating DHCPLEASEQUERY Message When a data packet is received from a host, Access Concentrator may verify if it has location/lease information for the source IP address or source MAC address of data packet received. Similarly when Access Concentrator receives a data packet from upstream interface, it may verify location/lease information for the destination IP address or destination MAC address of the data packet. An Access Concentrator would typically generate DHCPLEASEQUERY message if the location/lease information is not available for the corresponding IP address or MAC Joshi & Kurapati Expires March 23, 2007 [Page 9] Internet-Draft Extension of DHCP Leasequery September 2006 address assuming that it has lost the location/lease information during last reboot. The DHCPLEASEQUERY message uses the DHCP message format as described in RFC 2131 [2], and uses message number 10 in the DHCP Message Type option (option 53). The DHCPLEASEQUERY message has the following pertinent message contents: o "giaddr" field MUST NOT be set. Though RFC 4388 mandates that an Access Concentrator [in layer 3 mode] MUST set the "giaddr" field, this document suggest that an Access Concentrator acting as Transparent Bridge MUST not set the "giaddr" field. o Access concentrator which can receive a unicast reply for DHCPLEASEQUERY message SHOULD add option "access-concentrator- hwaddr" in DHCPLEASEQUERY message. Option "access-concentrator- hwaddr" SHOULD be populated based on the interface on which this request is sent out. o TTL value in IP header MUST be set to 255. This is to make sure that this packet is not forwarded beyond the Access Concentrator's LAN. o The Parameter Request List option (option 55) MUST include the Relay Agent Information option (option 82). o All the other options in Parameter Request List option (option 55) SHOULD be set as per the interest of the requester. The interesting options are likely to include the IP Address Lease Time option (option 51) and possibly the Vendor class identifier option (option 60). o Source IP address of the DHCPLEASEQUERY message MUST be set to 0.0.0.0. o Destination IP address of the DHCPLEASEQUERY message MUST be set to broadcast address 255.255.255.255. o Destination MAC address of the DHCPLEASEQUERY message MUST be set to FF:FF:FF:FF:FF:FF. o Source MAC address of the DHCPLEASEQUERY message MUST be set to the hardware address of the interface on which this request is sent out. All other fields in MAC header, IP header and DHCP header SHOULD be set as per RFC 2131 [2]. Additional details concerning different query types are same as defined in RFC 4388 [5]. Joshi & Kurapati Expires March 23, 2007 [Page 10] Internet-Draft Extension of DHCP Leasequery September 2006 5.3. Handling DHCPLEASEQUERY Message in Layer-3 Relay Agent A Layer-3 Relay Agent conforming to this document, MUST process the DHCP LEASEQUERY message received on its downstream interface. While processing a DHCPLEASEQUERY message, it MUST verify following: o If "giaddr" field is already set, "giaddr" field is not touched and the DHCP request is forwarded as per RFC 2131 [2]. o TTL value in IP header MUST be 255. If it is any other value, this packet MUST be silently discarded. After verifying the received DHCPLEASEQUERY request packet, Relay Agent should modify the DHCPLEASEQUERY request packet. The DHCPLEASEQUERY message has the following pertinent message contents: o "giaddr" field MUST be set to the primary IP address of the interface on which this DHCPLEASEQUERY request has been received. o No other fields in DHCP header needs to be changed. o Source IP address of IP header MAY be set to either the primary IP address of the interface on which this DHCPLEASEQUERY request has been received or to the IP address of the Interface on which this request will be sent out. o Destination IP address in IP header MUST be set to the IP address of the DHCP server. o Rest of the fields in IP header and DHCP header should be set as per RFC 2131 [2]. o As per RFC 3046 [3], Layer 3 Relay Agent SHALL add Relay Agent Information option to DHCP messages before forwarding them to the DHCP server. As explained in section 3, in layer 2 networks, layer 2 Relay Agent adds Relay Agent Information options to DHCP messages but does not populate "giaddr" before forwarding it to layer 3 Relay Agent. In case of DHCPLEASEQUERY message, layer 2 Relay Agent does not add Relay Agent Information option and so a Layer 3 Relay Agent may add Relay Agent Information assuming it as a normal DHCP message. A Layer 3 Relay Agent conforming to this document MUST NOT add Relay Agent Information option to the DHCPLEASEQUERY messages generated by a Layer 2 Relay Agent. In Layer-3 environment, RFC 4388 does not recommend how to set the "giaddr" field in DHCPLEASEQUERY message. While generating a DHCPLEASEQUERY message, a Layer-3 Relay Agent conforming to this document MUST always set the "giaddr" field to the primary IP address Joshi & Kurapati Expires March 23, 2007 [Page 11] Internet-Draft Extension of DHCP Leasequery September 2006 of the interface on which DHCPLEASEQUERY message will be sent. As described above, while receiving a DHCP reply, this helps Layer-3 Relay Agent to identify if it had generated a DHCPLEASEQUERY message or relayed it from an Access Concentrator. 5.4. Handling DHCPLEASEQUERY Message in DHCP Server DHCP servers conforming to this document MUST echo the entire contents of the "access-concentrator-hwaddr" option [code 'X'] in the reply for a DHCPLEASEQUERY request. DHCP servers SHALL NOT place the echoed "access-concentrator-hwaddr" option in the overloaded sname or file fields. If a server is unable to copy a full "access- concentrator-hwaddr" option into a response, it SHALL send the response without the "access-concentrator-hwaddr" option, and SHOULD increment an error counter for the situation. DHCP Server MUST NOT add or echo back this option in any other DHCP reply messages it generates. This document does not propose any other changes to RFC 4388 [5] for handling DHCPLEASEQUERY message in DHCP server. 5.5. Handling DHCP Reply Message in Layer-3 Relay Agent When Layer-3 Relay Agent receives a DHCP Reply message with message type as DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, or DHCPLEASEUNKNOWN, it first verifies the destination IP address. Following options are considered: o If the destination IP address of the DHCP reply packet is same as the primary IP address of the interface this reply has been received, it is assumed that this request was generated by the Layer-3 Relay Agent. It SHOULD NOT forward this DHCP Reply message. o If the destination IP address of the DHCP reply packet is same as the primary IP address of any of the outgoing interfaces except the one on which the reply was received, it is assumed that the request was generated by an Access Concentrator and so Layer-3 Relay Agent should forward this Reply message. Outgoing interface for the DHCP reply would be the one which has the same IP address as the destination IP address. Layer-3 Relay Agent will need to make following modification in DHCP reply before forwarding it to the Access Concentrator: o It MUST reset the "giaddr" field before forwarding the DHCP reply to Access Concentrator. Joshi & Kurapati Expires March 23, 2007 [Page 12] Internet-Draft Extension of DHCP Leasequery September 2006 o It SHOULD modify the source IP address of the DHCP reply to either 0.0.0.0 or to the IP address of the outgoing interface. o It SHOULD modify the destination IP address of the DHCP reply to 255.255.255.255. o It MUST look for "access-concentrator-hwaddr" option [code 'X'] in the DHCP reply and if it finds this option, it MUST extract the hardware address and use it to unicast the reply to the Access Concentrator. If it does not find this option, it SHOULD broadcast this reply over the outgoing interface identified as above. 5.6. Handling DHCP Reply Message in Access Concentrator 5.6.1. Handling DHCPLEASEUNASSIGNED Reply Message When a DHCPLEASEUNASSIGNED message is received by Access Concentrator, that means that there is no active lease for the IP address present in the DHCP server, but that a server does in fact manage that IP address. Access Concentrator SHOULD cache this information for later use. 5.6.2. Handling DHCPLEASEUNKNOWN Reply Message When a DHCPLEASEUNKNOWN message is received by Access Concentrator, it SHOULD cache this information but only for a short lifetime, approximately for 5 minutes as suggested in RFC 4388 [5]. 5.6.3. Handling DHCPLEASEACTIVE Reply Message When Access Concentrator receives a DHCPLEASEACTIVE message, it MUST update its location/lease information. 5.6.4. Handling multiple responses for DHCPLEASEQUERY Message A Layer 3 Relay Agent can forward a DHCPLEASEQUERY request to more than one DHCP server and so a Layer 2 Relay Agent may receive more than one reply for a DHCPLEASEQUERY message. A Layer 2 Relay Agent MUST be able to process multiple responses for a DHCPLEASEQUERY message. For example: o It should be able to ignore all other responses once it receives DHCPLEASEACTIVE response from one of the DHCP server. Joshi & Kurapati Expires March 23, 2007 [Page 13] Internet-Draft Extension of DHCP Leasequery September 2006 5.6.5. Handling No Response to the DHCPLEASEQUERY Message This has been discussed in detail in RFC 4388 [5] and the same holds good for this document as well. 5.6.6. Handling DHCPLEASEQUERY messages not belonging to Access Concentrator o Since Layer 3 Relay Agent can broadcast the reply of DHCPLEASEQUERY message, it will be processed by all the Access Concentrators connected to the same LAN. Using either Transaction Id or Relay Agent Information Option, an Access Concentrator should be able to correctly identify if the DHCPLEASEQUERY response is meant for itself. Responses which does not belong to an Access Concentrator MUST be silently discarded. o In a typical bridged network, multiple Access Concentrators may share the same LAN. As DHCPLEASEQUERY message generated by an Access Concentrator is broadcast, it will be received by other Access Concentrators also. Access Concentrators MUST silently discard any DHCPLEASEQUERY message received on its upstream interface. Joshi & Kurapati Expires March 23, 2007 [Page 14] Internet-Draft Extension of DHCP Leasequery September 2006 6. Lease query using Management IP address of Access Concentrator Though rare, but if an Access Concentrator allows the use of Management IP address for communication with DHCP server, it can generate DHCPLEASEQUERY message as described in RFC 4388 instead of using the extension of DHCPLEASEQUERY message described in this document. Joshi & Kurapati Expires March 23, 2007 [Page 15] Internet-Draft Extension of DHCP Leasequery September 2006 7. Security Consideration o Access Networks flood traffic to all the ports if the destination MAC is not present in MAC Learning table. The lease/location information obtained by snooping the DHCP messages and refreshed using DHCPLEASEQUERY mechanism, can be used to prevent this flooding. o If a Layer 2 Relay Agent, Layer 3 Relay Agent or DHCP server does not support the new option "access-concentrator-hwaddr", a Layer 3 Relay Agent would broadcast the response of the DHCPLEASEQUERY to the Access Concentrator. This response will be processed by all the Access Concentrators on the same LAN. This increases unnecessary cpu processing on the Access Concentrator on the same LAN. o DHCP servers SHOULD prevent exposure of location information (particularly the mapping of hardware address to IP address lease, which can be an invasion of broadband subscriber privacy) by employing the techniques detailed in RFC3118[6]. o Layer 3 Relay Agent that relays the DHCPLEASEQUERY message are essentially DHCP clients for the purposes of the DHCPLEASEQUERY messages generated by Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCPLEASEQUERY message only when it comes from a trusted circuit. Thus, RFC3118[6] is an appropriate mechanism for DHCPLEASEQUERY messages. o Since RFC3118[6] discusses the normal DHCP client interaction, consisting of a DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, and DHCPACK, it is necessary to transpose the operations described in RFC3118 [6] to the DHCPLEASEQUERY domain. The operations described in RFC3118 [6] for DHCPDISCOVER are performed for DHCPLEASEQUERY and the operations described for DHCPOFFER are performed for DHCPLEASEUNASSIGNED, DHCPLEASEACTIVE, and DHCPLEASEUNKNOWN messages. o All other security aspects are same as mentioned in "Security Consideration" section of RFC 4388 [5]. Joshi & Kurapati Expires March 23, 2007 [Page 16] Internet-Draft Extension of DHCP Leasequery September 2006 8. IANA Considerations This document needs IANA to provide a unique number for the new option to carry Hardware address of an Access Concentrator. Please refer to section 5.1 for more details. Joshi & Kurapati Expires March 23, 2007 [Page 17] Internet-Draft Extension of DHCP Leasequery September 2006 9. Acknowledgments Stig and Andre Kostur provided good feedback on this memo. A detailed discussion with Ted Lemon, Andre Kostur, Stefaan and David W. Hankinson on how a Layer 3 Relay Agent can unicast the DHCP reply to an Access Concentrator was very helpful. Description of authentication for DHCPLEASEQUERY messages in security section are taken from RFC 4388. Joshi & Kurapati Expires March 23, 2007 [Page 18] Internet-Draft Extension of DHCP Leasequery September 2006 10. References 10.1. Normative Reference [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [4] Reynolds, J., "IANA Assigned Numbers", RFC 3232, January 2002. [5] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006. [6] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. 10.2. Informative Reference [7] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [8] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. [9] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Joshi & Kurapati Expires March 23, 2007 [Page 19] Internet-Draft Extension of DHCP Leasequery September 2006 Authors' Addresses Bharat joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: bharat_joshi@infosys.com URI: http://www.infosys.com/ Pavan Kurapati Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: pavan_kurapati@infosys.com URI: http://www.infosys.com/ Joshi & Kurapati Expires March 23, 2007 [Page 20] Internet-Draft Extension of DHCP Leasequery September 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Joshi & Kurapati Expires March 23, 2007 [Page 21]