[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-kurapati-dhc-l2ra-extensions) 00 01

DHC Working Group                                               B. Joshi
Internet-Draft                                               P. Kurapati
Expires: August 29, 2009                                       M. Kamath
                                               Infosys Technologies Ltd.
                                                           S. De Cnodder
                                                          Alcatel-Lucent
                                                       February 25, 2009


                   Extensions to Layer 2 Relay Agent
                 draft-ietf-dhc-l2ra-extensions-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   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 August 29, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust 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.





Joshi, et al.            Expires August 29, 2009                [Page 1]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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 . . . . . . . . . . . . . . 14
     6.2.  Flooding of DHCPLEASEQUERY reply messages from Layer 3
           Relay Agent  . . . . . . . . . . . . . . . . . . . . . . . 16
       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





Joshi, et al.            Expires August 29, 2009                [Page 2]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


1.  Introduction

   DHCP Relay Agents eliminate the necessity of having a DHCP server on
   each physical network.  [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.




































Joshi, et al.            Expires August 29, 2009                [Page 3]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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 [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] 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  "Transparent Bridge"

   A device which does bridging based on MAC learning principles.
   Bridge learns the Source MAC of the incoming frames and updates a



Joshi, et al.            Expires August 29, 2009                [Page 4]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


   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, et al.            Expires August 29, 2009                [Page 5]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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 Agent
   [draft-ietf-dhc-l2ra] deployments

   o  Broadcasting DHCP requests on all interfaces

   A normal Layer 2 Relay Agent [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 Agent [draft-ietf-dhc-l2ra] may snoop DHCP messages
   and maintain the lease information.  This information is lost if the
   Layer 2 Relay Agent reboots.  [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.











Joshi, et al.            Expires August 29, 2009                [Page 6]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


                 +-------+
   +-----+       |       |
   |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





























Joshi, et al.            Expires August 29, 2009                [Page 7]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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.










































Joshi, et al.            Expires August 29, 2009                [Page 8]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


5.  Extension of DHCPLEASEQUERY for Layer 2 Relay Agent

5.1.  Protocol Extension Overview

   A Layer 2 Relay Agent [draft-ietf-dhc-l2ra] may need to maintain the
   information of outgoing interface, MAC Address, IP address and Lease
   information for each DHCP Client.  This information [MAC-IP-Interface
   Binding] is mostly used to prevent MAC/IP Spoofing 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
   [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 reboots, it can obtain the lease
   information by using DHCPLEASEQUERY message.  The DHCPLEASEQUERY
   message can be generated with data driven approach by using Query by
   IP address, MAC address or Client Identifier with all the fields
   populated as defined in [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

   For 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 a Layer 2 Relay Agent
   may verify if it has location/lease information for a given user
   connection as soon as the device comes up or 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 [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 [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.





Joshi, et al.            Expires August 29, 2009                [Page 9]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


   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 [RFC2131].  Additional details concerning different query
   types are same as defined in [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

   DHCP server prepares the reply to the DHCPLEASEQUERY message as
   desribed in [RFC4388] and [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.




Joshi, et al.            Expires August 29, 2009               [Page 10]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


5.2.5.  Handling DHCP Reply Message in Layer 2 Relay Agent

5.2.5.1.  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 can use this information 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.

5.2.5.2.  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
   [RFC4388].  For query by remote-id
   [draft-ietf-dhc-leasequery-by-remote-id] this caching MAY be avoided.

5.2.5.3.  Handling DHCPLEASEACTIVE Reply Message

   When Layer 2 Relay Agent receives a DHCPLEASEACTIVE message, it MUST
   update its location/lease information.

5.2.5.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.

5.2.5.5.  Handling No Response to the DHCPLEASEQUERY Message

   This has been discussed in detail in [RFC4388] and the same holds
   good for this document as well.







Joshi, et al.            Expires August 29, 2009               [Page 11]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


5.2.5.6.  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.



























Joshi, et al.            Expires August 29, 2009               [Page 12]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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 2131[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.  Consider the
   scenario where CPE is doing 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 IP frames to the
   L3RA by adding its own Ethernet header.  The intermediate L2 network
   would only know L2RA MAC address.  Hence all the messages from the
   L3RA needs to 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.







Joshi, et al.            Expires August 29, 2009               [Page 13]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


6.1.1.  Unicast-Address Sub-Option

6.1.1.1.  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 3

   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
      [RFC3232].

   o  "hwaddr" is the unicast hardware address.

6.1.1.2.  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.

6.1.1.3.  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



Joshi, et al.            Expires August 29, 2009               [Page 14]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


   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.

6.1.1.4.  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.

6.1.1.5.  Example Scenarios

   o  The trusted layer 2 DHCP relay agent and CPE acts as a 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.  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 CPE uses IPoA call type: In this case layer 2 DHCP relay agent
      adds unicast-address sub-option which contains the MAC address
      that the Layer 2 DHCP Relay Agent is using for upstream frames.



Joshi, et al.            Expires August 29, 2009               [Page 15]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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 4

   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 Relay Agent hardware address.

6.2.1.1.  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.




Joshi, et al.            Expires August 29, 2009               [Page 16]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


6.2.1.2.  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.

6.2.1.3.  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.






















Joshi, et al.            Expires August 29, 2009               [Page 17]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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.





































Joshi, et al.            Expires August 29, 2009               [Page 18]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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,
      RFC3118[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.



































Joshi, et al.            Expires August 29, 2009               [Page 19]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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.2 for more details.

   This document also needs IANA to provide a unique number for a new
   suboptions in Relay Agent Information option [Option 82] to carry the
   hardware address of the Relay Agent.  Please refer to section 6.1 for
   more details.









































Joshi, et al.            Expires August 29, 2009               [Page 20]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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-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.









Joshi, et al.            Expires August 29, 2009               [Page 21]


Internet-Draft      Extensions to Layer 2 Relay Agent      February 2009


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/


   Mukund Kamath
   Infosys Technologies Ltd.
   44 Electronics City, Hosur Road
   Bangalore  560 100
   India

   Email: mukund_kamath@infosys.com
   URI:   http://www.infosys.com/


   Stefaan De Cnodder
   Alcatel-Lucent
   Francis Wellesplein 1,
   B-2018 Antwerp
   Belgium

   Email: stefaan.de_cnodder@alcatel-lucent.be
   URI:   http://www.alcatel-lucent.com











Joshi, et al.            Expires August 29, 2009               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/