DHC Working Group B. Joshi Internet-Draft P. Kurapati Expires:
December 16, 2008August 29, 2009 M. Kamath Infosys Technologies Ltd. S. De Cnodder Alcatel-Lucent June 14, 2008February 25, 2009 Extensions to Layer 2 Relay Agent draft-ietf-dhc-l2ra-extensions-00.txtdraft-ietf-dhc-l2ra-extensions-01.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 sheThis Internet-Draft is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed,submitted to IETF in accordancefull conformance with Section 6the provisions of BCP 78 and 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 December 16, 2008.August 29, 2009. Copyright Notice Copyright (C) The(c) 2009 IETF Trust (2008).and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 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 a transparent bridge in Layer 2 mode. These Access Concentrators also act as Layer 2 relay agents. Layer 2 Relay Agent functionality does not provide means to avoid flooding of DHCP messages and also needs to be extended to support DHCP LeaseQuery This draft discusses these issues and provides solutions for the same. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Enhancements in Layer 2 Relay Agent . . . . . . . . . . . . . 6 3.1. Reference Network . . . . . . . . . . . . . . . . . . . . 6 4. Uplink port . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent . . . . . 9 5.1. Protocol Extension Overview . . . . . . . . . . . . . . . 9 5.2. Protocol Extension Details . . . . . . . . . . . . . . . . 9 5.2.1. Generating DHCPLEASEQUERY Message . . . . . . . . . . 9 5.2.2. Handling DHCPLEASEQUERY Message in Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server . . . . 10 5.2.4. Handling DHCP Reply Message in Layer 3 Relay Agent . . 10 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent . . 11 5.3. DHCPLEASEQUERY using Management IP address of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 12 6. Prevention of flooding of DHCP replies from Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1. Flooding of DHCP reply messages from Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Unicast-Address Sub-Option . . . . . . . . . . . . . . 1314 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent . . . . . . . . . . . . . . . . . . . . . . . 1516 6.2.1. Relay Agent Hardware Address option . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 8. Security Consideration . . . . . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative Reference . . . . . . . . . . . . . . . . . . . 21 10.2. Informative Reference . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 231. Introduction DHCP Relay Agents eliminate the necessity of having a DHCP server on each physical network. RFC 3046 [RFC3046] defines a new option 'Relay Agent Information' which is added to DHCP messages by Relay Agents. DHCP servers may use this option for IP address and other parameter assignment policies. In case of Layer 2 Access Networks, Access Concentrators typically act as Layer 2 Relay Agents .[draft-ietf-dhc-l2ra]. This document proposes enhancements in Layer 2 Relay Agent [draft-ietf-dhc-l2ra] which addresses issues like flooding between Layer 3 Relay Agent and Layer 2 Relay Agent and retrieving lease information from server using DHCP leasequery mechanism. 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 .[RFC2119]. 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 "IPoA" IP over AAL5: One of the call types used in xDSL networks where CPE acts as a routing device and encapsulates IP frames directly inside ATM Adaptation Layer 5. 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 [RFC951] and RFC1542.[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 "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. 3. Enhancements in Layer 2 Relay Agent This section looks at various enhancements possible in Layer 2 Relay Agents. Following issues are seen in a typical Layer 2 Relay AgentAgent [draft-ietf-dhc-l2ra] deployments o Broadcasting DHCP requests on all interfaces A normal Layer 2 Relay AgentAgent [draft-ietf-dhc-l2ra] would broadcast a DHCP request message to all its interfaces except on which the message was received. Because of this, a DHCP request message is received by those devices which would not be interested in it. Configuring an uplink port that leads to a Layer 3 Relay Agent or DHCP server can solve this issue. Some of the existing implementations [Mostly in xDSL Access Concentrators] already supports this. o Recovering Lease Information from Server A Layer 2 Relay AgentAgent [draft-ietf-dhc-l2ra] may snoop DHCP messages and maintain the lease information. This information is lost if the Layer 2 Relay Agent reboots. RFC 4388 suggests[RFC4388] suggested Leasequery mechanism to get the lease information from the server. This document extends the same for Layer 2 Relay Agent. o Layer 3 Relay Agent broadcasting DHCP replies Layer 3 Relay Agents generally broadcast DHCP replies towards Layer 2 Relay Agents. This will be received by those devices which would not be interested in it. In general, broadcasts should be avoided in Layer 2 networks. A new sub-option in Relay Agent Information option can be used to solve this issue. To avoid broadcasts in case of replies to Leasequery, a new option is defined. 3.1. Reference Network Following network configuration is used as a reference network to explain the various issues and solutions in Layer 2 Networks. This network configuration is a typical Ethernet Aggregated Access Network. +-------+ +-----+ | | |Host1|-------| | +-----+ |Access | |Concen-|-----...... +-----+ |trator | . |Host2|-------| #1 | . +------+ +-----+ | | . | | +-------+ ----| | +--------+ Trusted Layer 2 | | | DHCP | DHCP Relay Agents |IPEdge|--.....---| Server | +-------+ | | +--------+ +-----+ | | .----| | |Host3|-------| | . | | +-----+ |Access | . +------+ |Concen-|-----...... Layer 3 +-----+ |trator | Relay Agent |Host4|-------| #2 | +-----+ | | +-------+ Figure 1 4. Uplink port A Layer 2 Relay Agent broadcasts the DHCP request messages [Messages which are broadcast by Clients] to all the interfaces within the same broadcast domain except the interface on which it was received. This leads to flooding of DHCP messages which is unnecessary. Hence there is a need to identify an "Uplink Port", through which the DHCP request messages could be relayed towards the DHCP server. The uplink port SHOULD be a configurable parameter. 5. Extension of DHCPLEASEQUERY for Layer 2 Relay Agent 5.1. Protocol Extension Overview A Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may wantneed to maintain the information of outgoing interface, MAC Address, IP address and Lease information for each DHCP Client. This information [MAC-IP-Interface Binding] could beis mostly used to prevent MAC/IP Spoofing attacks.attacks by installing anti-spoofing filters. It could also be used for bridging frames. Maintain this information makes a Layer 2 Relay Agent vulnerable to the same issue [location/lease information lost when Layer 2 Relay Agent gets rebooted] which has been addressed in RFC 4388 [RFC4388] for Layer 3 networks. This document extends mechanism proposed in [RFC4388] to address this issue for layer 2 networks. When a Layer 2 Relay Agent 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,reboots, it can query DHCP server toobtain the lease/locationlease information by using DHCPLEASEQUERY message. A Layer 2 Relay Agent can generate aThe DHCPLEASEQUERY [Querymessage can be generated with data driven approach by using Query by IP address, MAC address, client identifier ]address or Client Identifier with all the fields properlypopulated as defined in RFC 4388 .[RFC4388] or with a new non-data driven approach by using Query by remote-id as defined in [draft-ietf-dhc-leasequery-by-remote-id] 5.2. Protocol Extension Details 5.2.1. Generating DHCPLEASEQUERY Message When aFor data driven lease query approach, when a packet is received from a host, Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may verify if it has location/lease information for the source IP address or source MAC address of data packet received. Similarly whena Layer 2 Relay Agent receives a data packet from the uplink port, itmay verify if it has location/lease information for a given user connection as soon as the destination IP addressdevice comes up or destination MAC address of the data packet.a specific connection comes up. A Layer 2 Relay Agent would typically generate DHCPLEASEQUERY message if the location/lease information is not available for the corresponding IP address or MAC address or connection 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 ,[RFC2131], 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 [RFC4388] mandates that an Access Concentrator [in Layer 3 mode] 'MUST' set the "giaddr" field, this document suggest that a Layer 2 Relay Agent acting as Transparent Bridge must not set the "giaddr" field. 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 options of interest are likely to be 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 .[RFC2131]. Additional details concerning different query types are same as defined in RFC 4388 .[RFC4388]. 5.2.2. 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 similar to the other DHCP messages. 5.2.3. Handling DHCPLEASEQUERY Message in DHCP Server While generating aDHCP server prepares the reply for a DHCPLEASEQUERY message, if the message type is DHCPLEASEUNASSIGNED or DHCPLEASEUNKNOWN, it MUST echo back the Relay Agent Information received in the DHCPLEASEQUERY message. If the message type is DHCPLEASEACTIVE, DHCP server preparesto the DHCPLEASEQUERY message as describeddesribed in RFC 4388[RFC4388] and ignores the Relay Agent Information option received in the DHCPLEASEQUERY message. This document does not propose any other changes to RFC 4388  for handling DHCPLEASEQUERY message in DHCP server.[draft-ietf-dhc-leasequery-by-remote-id]. 5.2.4. 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 must have a way to identify if it had generated the leasequery message or it had relayed it for a Layer 2 Relay Agent. When the DHCP Reply message is received, a Layer 3 Relay Agent may use 'giaddr' or 'state information' to identify the outgoing interface. 5.2.5. Handling DHCP Reply Message in Layer 2 Relay Agent 184.108.40.206. Handling DHCPLEASEUNASSIGNED Reply Message When a DHCPLEASEUNASSIGNED message is received by a Layer 2 Relay Agent, it 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. Layer 2 Relay Agent SHOULD cachecan use this information for later use.to discard the relevant data streams matching this reply. For data driven query approach as defined in [RFC4388] Relay Agent MAY decide to cache this entry to avoid sending a similar query to the server again. If a query by remote-id [draft-ietf-dhc-leasequery-by-remote-id] is used caching MAY be avoided. 220.127.116.11. Handling DHCPLEASEUNKNOWN Reply Message When a DHCPLEASEUNKNOWN message is received by Layer 2 Relay Agent, it SHOULD cache this information for data driven approach but only for a short lifetime, approximately for 5 minutes as suggested in RFC 4388 .[RFC4388]. For query by remote-id [draft-ietf-dhc-leasequery-by-remote-id] this caching MAY be avoided. 18.104.22.168. Handling DHCPLEASEACTIVE Reply Message When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST update its location/lease information. 22.214.171.124. 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. 126.96.36.199. Handling No Response to the DHCPLEASEQUERY Message This has been discussed in detail in RFC 4388 [RFC4388] and the same holds good for this document as well. 188.8.131.52. Handling DHCPLEASEQUERY messages not belonging to Layer 2 Relay Agent o Since Layer 3 Relay Agent can broadcast the reply of DHCPLEASEQUERY message, it will be processed by all the Layer 2 Relay Agents connected to the same LAN. Using either Transaction Id or Relay Agent Information Option, a Layer 2 Relay Agent should be able to correctly identify if the DHCPLEASEQUERY response is meant for itself. Responses which do not belong to an Access Concentrator MUST be silently discarded. o In a typical bridged network, multiple Layer 2 Relay Agents may share the same LAN. As a DHCPLEASEQUERY message generated by a Layer 2 Relay Agent is broadcast, it will be received by other Layer 2 Relay Agents also. Layer 2 Relay Agents MUST silently discard any DHCPLEASEQUERY message received from the uplink port. 5.3. DHCPLEASEQUERY using Management IP address of Layer 2 Relay Agent Though rare, but if a Layer 2 Relay Agent 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. 6. Prevention of flooding of DHCP replies from Layer 3 Relay Agent Figure 1 shows an example where each access concentrator adds the relay agent information option containing the port information of the host sending the DHCP messages. IP edge router relays these DHCP messages to the server. RFC 21312131[RFC2131] defines the meaning of the broadcast flag in the flags field: it indicates whether the client wishes to receive the DHCPOFFER and DHCPACK message as a broadcast or a unicast from the DHCP server or the DHCP relay agent. In the scenario of Figure 1, this means that the IP edge router will broadcast the DHCPOFFER and DHCPACK messages to all access concentrators if the broadcast flag is set. Whether or not broadcast is used between the Layer 3 Relay Agent and the trusted Layer 2 Relay Agents depends on the behavior of the DHCP clients. However broadcasts in the aggregation network are to be avoided. So it is preferred to always use unicast from the Layer 3 DHCP relay agent to the trusted layer 2 DHCP relay agent. Between the trusted layer 2 DHCP relay agent and the host, broadcast flag has to be honored. Even though the DHCP clients are not setting the broadcast flag, it is still possible that the DHCPOFFER and DHCPACK messages from the DHCP server are sent to all access concentrators. This is whenConsider the access concentrator implements a MAC concentration or MAC translation function. When such a MAC operationscenario where CPE is performed, the access concentrator replacesdoing IPoA (IP over AAL5). IPoAAL5 L2 CPE----------L2RA--------L3RA-------Server Figure 2 In this case, there will not be any Ethernet for CPE and hence it would populate chaddr with 0s. L2RA bridges the source MAC address of all upstreamIP frames to the L3RA by another MAC address, for instance withadding its own Ethernet header. The intermediate L2 network would only know L2RA MAC address. In this case, the MAC addresses of the hosts will remain unknown in the network between the trusted layer 2 DHCP relay agent and the Layer 3 DHCP relay agent.Hence all unicastthe messages sent byfrom the Layer 3 DHCP relay agent using this MAC address will be floodedL3RA needs to all access concentrators.be broadcasted in the L2 network 6.1. Flooding of DHCP reply messages from Layer 3 Relay Agent To overcome these two previously mentioned problems, a new sub-option 'unicast-address' is defined for the Relay Agent Information option. With this sub-option, the Layer 3 Relay Agent will always unicast the messages towards the trusted Layer 2 Relay Agent with a hardware address that is known in the network. 6.1.1. Unicast-Address Sub-Option 184.108.40.206. Unicast-Address Sub-Option Definition The unicast-address sub-option of the relay-agent-information option MAY be used by any trusted layer 2 DHCP relay agent such that the Layer 3 relay agent unicasts the messages from the DHCP server with a hardware address known in the network. The hardware address in the unicast-address sub-option MUST be an address that can be used to send unicast packets towards the client. The format of the option is as follows: SubOpt Len [Hardware address details] +------+------+----------+-------------+ | X | Len | htype(1) | hwaddr | +------+------+----------+-------------+ Figure 23 o 'X' is the sub-option code which needs to be allocated by IANA. o 'Len' represents the length of the 'value' which includes both htype and hwaddr fields o "htype" represents Hardware type. See the 'ARP parameters' maintained in the database referenced by Assigned numbers RFC 3232 .[RFC3232]. o "hwaddr" is the unicast hardware address. 220.127.116.11. Layer 3 Relay Agent Behavior When Layer 3 DHCP Relay Agent receives a DHCP packet with unicast- address sub-option added, it SHOULD unicast that message towards the layer 2 DHCP relay agent with destination address set to the value contained in the hwaddr field of the sub-option. A Layer 3 relay agent that supports this option SHOULD ignore the broadcast flag if this sub-option is present in the DHCP message. In the absence of this sub-option a Layer 3 relay agent SHOULD behave as earlier and forward the message as per the broadcast bit set in the message. 18.104.22.168. Layer 2 Relay Agent Behavior The Layer 2 Relay Agent may add this sub-option only in the case when the intermediate network elements do MAC learning ensuring that when the Layer 3 relay agent unicasts the messages to this hardware address, the messages will arrive at the same layer 2 DHCP relay agent. The Layer 2 DHCP relay agent SHOULD still be able to receive broadcast messages from the Layer 3 DHCP relay agent in order to remain compatible with relay agents that do not support the unicast- address sub-option. Layer 2 DHCP relay agent MUST always process the broadcast flag as described in [RFC2131]. This means that it is possible that the layer 2 DHCP relay agents receive a unicast message from the Layer 3 DHCP relay agent, and that it has to forward it as a broadcast. It is also possible that the unicast message stays unicast and that only the destination MAC address has to be changed to the content of the chaddr field. If the layer 2 DHCP relay agent performs a MAC address concentration function, it SHOULD add the unicast-address sub-option to all upstream DHCP messages in order to avoid flooding of unknown destination MAC addresses. On the other hand, if the layer 2 DHCP relay agent acts as a bridge, it MAY add the unicast-address sub- option only to the DHCPDISCOVER and DHCPREQUEST messages as these are the only messages which may result in a downstream broadcast. 22.214.171.124. DHCP Server Behavior Although rather unlikely, it is also possible that no Layer 3 DHCP relay agent is configured in the network and that the DHCP server has layer 2 connectivity with the trusted layer 2 DHCP relay agent. In this case the DHCP server, supporting the unicast address option, SHOULD act as a Layer 3 DHCP relay agent would do. So if the DHCP server receives DHCP messages with giaddr set to zero and a valid unicast-address sub-option, the DHCP server SHOULD ignore the broadcast flag and unicast the DHCP messages to the hardware address in the unicast-address sub-option. The DHCP Server SHOULD also include this sub-option in the option 82 of its reply. 126.96.36.199. Example Scenarios o The trusted layer 2 DHCP relay agent and CPE acts as a bridge.bridge : In such a case, the layer 2 DHCP relay agent puts the MAC address in the chaddr field of DHCP messages in the unicast-address sub-option.sub- option. The Layer 3 DHCP relay agent will then send the DHCPOFFER and DHCPACK messages from the DHCP server as unicast to the layer 2 DHCP relay agent, which converts the message to broadcast if the broadcast flag is set. o The Layer 2 Relay Agent does MAC translation/concentration function.CPE uses IPoA call type: In this case layer 2 DHCP relay agent adds unicast- addressunicast-address sub-option which contains the MAC address that the Layer 2 DHCP Relay Agent is using for upstream frames. 6.2. Flooding of DHCPLEASEQUERY reply messages from Layer 3 Relay Agent The above suboption would not work for reply message for a LEASEQUERY request because the reply message type other than LEASEACTIVE for a LEASEQUERY message will not have Relay Agent Information option. This can be resolved by creating a new option which is echoed back by the DHCP server in DHCP reply messages for a LEASEQUERY message. This document need the definition of following new option for DHCP packet beyond those defined by [RFC2131] and [RFC2132]. See also Section 9, IANA Considerations. 6.2.1. Relay Agent Hardware Address option "relay-agent-hwaddr" option allows a Layer 3 Relay agent to unicast a DHCP reply for a DHCPLEASEQUERY message to the Layer 2 Relay Agent which had generated the DHCPLEASEQUERY message. The code for this option need to be allocated by IANA. code [Hardware address details] +------+------+------------+------------+ | X | len | htype (1) | hwaddr | +------+------+------------+------------+ Figure 34 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. o "hwaddr" is Relay Agent hardware address. 188.8.131.52. Layer 2 Relay Agent Behavior Layer 2 Relay agents which has the capability to receive a unicast reply for DHCPLEASEQUERY message SHOULD add option "relay-agent- hwaddr" in DHCPLEASEQUERY message. Option "relay-agent-hwaddr" SHOULD be populated based on the interface on which this request is sent out. 184.108.40.206. Layer 3 Relay Agent Behavior While forwarding a reply for Lease Query request, a Layer 3 Relay Agent MUST look for "relay-agent-hwaddr" option [code 'X'] in the DHCP reply and if it finds this option, it SHOULD extract the hardware address and use it to unicast the reply to the Layer 2 Relay Agent. DHCP reply message with message type 'DHCPLEASEACTIVE' can have Relay Agent Information option which may have 'unicast-address' sub-option. In such a case, both 'relay-agent-hwaddr' option and 'unicast- address' sub-option MAY be present. A Layer 3 Relay Agent conforming to this document MUST always prefer hardware address extracted from 'unicast-address' sub-option of Relay Agent Information option over 'relay-agent-hwaddr' option. 220.127.116.11. DHCP server Behavior DHCP servers conforming to this document MUST echo the entire contents of the "relay-agent-hwaddr" option [code 'X'] in the reply for a DHCPLEASEQUERY request. DHCP servers SHALL NOT place the echoed "relay-agent-hwaddr" option in the overloaded sname or file fields. If a server is unable to copy a full "relay-agent-hwaddr" option into a response, it SHALL send the response without the "relay-agent-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. 7. Acknowledgments Stig Venaas, Wojciech Dec, Richard Pruss and Andre Kostur provided good feedback on this memo. A detailed discussion with Ted Lemon, Andre Kostur on how a Layer 3 Relay Agent can unicast the various DHCP replies to a Layer 2 Relay Agent was very helpful. The authors would like to acknowledge Ludwig Pauwels and Paul Reynders for their feedback on 'unicast-address' sub-option. Thanks to Patrick Mensch who contributed for the initial version of the document which had defined 'unicast-address' sub-option. Description of authentication for DHCPLEASEQUERY messages in security section are taken from RFC 4388. 8. Security Consideration o Layer 3 Relay Agent that relays the DHCP message are essentially DHCP clients for the purposes of the DHCP messages relayed by Layer 2 Relay Agent. Layer 3 Relay Agent MUST relay a DHCP message only when it comes from a trusted circuit. Thus, RFC3118RFC3118[RFC3118] is an appropriate mechanism for DHCP messages relayed by Layer 2 Relay Agent. o This document suggest new option which MAY be added by Layer 2 Relay Agents in DHCP message. If a server finds this new option included in a received message, the server MUST compute any hash function as if the option were NOT included in the message without changing the order of options. Whenever the server sends back this option to a relay agent, the server MUST not include this option in the computation of any hash function over the message. 9. IANA Considerations This document needs IANA to provide a unique number for the new option to carry Hardware address of a Relay Agent. Please refer to section 6.16.2 for more details. This document also needs IANA to provide a unique number for the followinga new suboptions in Relay Agent Information option [Option 82]: o To82] to carry the hardware address of athe Relay Agent. Please refer to section 6.26.1 for more details. 10. References 10.1. Normative Reference [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001. [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001. [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration Protocol (DHCP) Leasequery", RFC 4388, February 2006. [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. [draft-ietf-dhc-l2ra] Joshi, B. and P. Kurapati, "Layer 2 Relay Agent Information", draft draft-ietf-dhc-l2ra-01.txt, May 2008.draft-ietf-dhc-l2ra-03.txt, January 2009. [draft-ietf-dhc-leasequery-by-remote-id] Kurapati, P., Joshi, B., and R. Desetti, "DHCPv4 Leasequery by relay agent remote ID", draft draft-ietf-dhc-leasequery-by-remote-id-01.txt, January 2009. 10.2. Informative Reference [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, September 1985. [RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993. [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. Authors' Addresses Bharat Joshi Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: firstname.lastname@example.org URI: http://www.infosys.com/ Pavan Kurapati Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: email@example.com URI: http://www.infosys.com/ Mukund Kamath Infosys Technologies Ltd. 44 Electronics City, Hosur Road Bangalore 560 100 India Email: firstname.lastname@example.org URI: http://www.infosys.com/ Stefaan De Cnodder Alcatel-Lucent Francis Wellesplein 1, B-2018 Antwerp Belgium Email: email@example.com URI: http://www.alcatel-lucent.com 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 firstname.lastname@example.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, THE IETF TRUST 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 IETF Trust (2008). 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.