DHC Working Group                                               B. Joshi
Internet-Draft                                               P. Kurapati
Expires: January 8, 2010                       Infosys Technologies Ltd.
                                                            July 7, 2009


                        Relay Chaining in DHCPv4
            draft-kurapati-dhc-relay-chaining-dhcpv4-02.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 January 8, 2010.

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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.









Joshi & Kurapati         Expires January 8, 2010                [Page 1]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


Abstract

   DHCP Relay Agents eliminate the necessity of having a DHCP server on
   each physical network.  In certain network configurations, a DHCP
   server may be multiple subnets away from the DHCP client and multiple
   Relay Agents may be configured to relay DHCP messages to and from
   DHCP client.  Such configuration can be supported only when each
   Relay Agent adds certain Information to DHCP messages before relaying
   them.  This additional information helps in relaying the DHCP reply
   back to the DHCP client through the same path.  This mechanism is
   referred as Relay Chaining.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  New sub-options  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  peer-relay-agent-information Sub Option  . . . . . . . . .  6
     3.2.  peer-address Sub Option  . . . . . . . . . . . . . . . . .  6
   4.  Relay Chaining . . . . . . . . . . . . . . . . . . . . . . . .  7
     4.1.  Handling DHCP messages in Relay Agent  . . . . . . . . . .  7
       4.1.1.  Handling Broadcast DHCP messages . . . . . . . . . . .  8
       4.1.2.  Handling Unicast DHCP messages . . . . . . . . . . . .  9
   5.  DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 10
   6.  Special Scenarios  . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  Multiple Layer 2 Relay Agents between DHCP client and
           Layer 3 Relay Agent  . . . . . . . . . . . . . . . . . . . 11
     6.2.  One or multiple Layer 2 Relay Agents between two Layer
           3 Relay Agents . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Consideration . . . . . . . . . . . . . . . . . . . . 12
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 13
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     9.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 14
     9.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15















Joshi & Kurapati         Expires January 8, 2010                [Page 2]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


1.  Introduction

   In some network configurations, DHCP server and clients are separated
   by multiple Relay Agents.  One such case is the network configuration
   where Access Concentrators operate in Transparent Bridging mode as
   described in document [layer2-relay-agent].  In such configurations,
   there are situations where each of those relay agents need to add
   relay-agent-information to the DHCP messages received on its
   downstream interface.  Relay chaining support in DHCPv4 will help in
   solving following problems:

   o  In some deployments, Layer 3 Relay Agent uses unnumbered
      interfaces.  When these Layer 3 Relay Agents are used along with
      Layer 2 Relay agents as described in [layer2-relay-agent] , they
      need to maintain internal states to identify the outgoing
      interface.  Maintaining state information for each packet will not
      scale as number of DHCP clients increases.  With Relay Chaining,
      Layer 3 Relay Agent can add its own Relay Agent Information option
      that can be used to identify the outgoing interface for DHCP reply
      messages.

   o  When a network configuration supports multiple Layer 3 Relay
      Agents between DHCP Clients and DHCP server, a DHCP message need
      to be relayed through these Relay Agents to reach DHCP server or
      DHCP Clients.  This can not be supported with present mechanism.

   This document describes the enhancements to Relay Agent functionality
   when multiple Relay Agents are present between DHCP clients and
   servers.






















Joshi & Kurapati         Expires January 8, 2010                [Page 3]


Internet-Draft          Relay Chaining in DHCPv4               July 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 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  "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"




Joshi & Kurapati         Expires January 8, 2010                [Page 4]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


   Upstream is the direction from the DHCP Clients towards the edge
   network.

   o  "Unnumbered Interfaces"

   An interface with no IP address associated with it.  IP packets
   received on this interface will be processed like any other numbered
   IP interface.  It may use a local IP address of another interface
   while forwarding packets.










































Joshi & Kurapati         Expires January 8, 2010                [Page 5]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


3.  New sub-options

   The 'Relay Chaining in DHCPv4' requires the definition of following
   new sub-options in Relay Agent Information [Option 82] option for
   DHCP packet beyond those defined by RFC2131 [RFC2131] and RFC2132
   [RFC2132].  See also Section 7, IANA Considerations.

3.1.  peer-relay-agent-information Sub Option

   This sub-option is defined under Relay Agent Information option
   [Option 82].  A Relay Agent can use 'peer-relay-agent-information'
   sub-option to store the Relay Agent Information option added by the
   previous Relay Agent.  The value field of this sub-option contains
   the Relay Agent Information option present in the recevied DHCP
   message.  The new sub-option is as shown in the figure below:

      SubOpt    Len   Value
      +------+------+--------------------------+
      | X    | Len  | Option 82 of Previous RA |
      +------+------+--------------------------+
                   /                            \
                  /                              \
                 +------+-----+--------------------+
                 |  82  |  N  | i1 | i2 | ... | iN |
                 +------+-----+--------------------+
                 Code    Len   Relay Agent Information

                                 Figure 1

3.2.  peer-address Sub Option

   'peer-address' sub-option is used to store the previous Relay Agent's
   reachable IP address.  It SHOULD be typically populated with the same
   address as mentioned in the 'giaddr' field of the received message.
   If there are multiple Relay Agents involved, this sub-option helps in
   forwarding the reply back to the DHCP client through the same path.
   The 'peer-address' sub-option is as follows:

         SubOpt     Len         Sub-option Value
        +--------+--------+--------------------------------+
        |    X   |    4   | Previous RA's Address (giaddr) |
        +--------+--------+--------------------------------+

                                 Figure 2







Joshi & Kurapati         Expires January 8, 2010                [Page 6]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


4.  Relay Chaining

   Relay Chaining is defined as the mechanism where multiple Relay
   Agents are involved in relaying a DHCP message between DHCP clients
   and server.  Each Relay Agent adds Relay Agent Information option to
   the DHCP message as described below.  The option of using relay
   chaining mechanism MUST be configurable on Relay Agent in order to
   provide compatibility to the previous solutions.


                |
   +-----+      |
   |Host1|------+
   +-----+      |
                |
   +-----+      |
   |Host2|------+      +--------+
   +-----+      |      |        |        +--------+      +--------+
                +------|        |        |        |      |        |
                |      | Relay  |        | Relay  |      |  DHCP  |
                |      | Agent  |---..---| Agent  |--..--| Server |
                |      |  #1    |        |   #2   |      |        |
   +-----+      +------|        |        |        |      +--------+
   |Host3|------+      |        |        +--------+
   +-----+      |      +--------+
                |
   +-----+      |
   |Host4|------+
   +-----+      |
                |
                |

                                 Figure 3

   A typical network configuration where Relay Chaining is required is
   depicted in Figure 3.  In the above case, two Relay Agents are
   involved.  Relay Agent #1 does not know the DHCP server and so is
   configured to reach Relay Agent #2 for all DHCP messages.  Relay
   Agent #2 knows how to reach DHCP server and so relays a DHCP message
   directly to DHCP server.  DHCP server generates the reply messages
   and sends it to Relay Agent #2 which relays the same to Relay Agent
   #1.

4.1.  Handling DHCP messages in Relay Agent







Joshi & Kurapati         Expires January 8, 2010                [Page 7]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


4.1.1.  Handling Broadcast DHCP messages

   o  When a Relay Agent receives a DHCP request message which does not
      contain the Relay Agent Information option, it SHOULD add the
      Relay Agent Information option (Option 82 as described in RFC 3046
      [RFC3046]) and 'giaddr' field as it deems appropriate.  It should
      relay the DHCP message to the DHCP server or next Relay Agent.  If
      a Relay Agent is a Layer 2 relay agent, it MUST NOT populate the
      'giaddr' field in the DHCP message and should process it as per
      [layer2-relay-agent]

   o  When a Relay Agent receives a DHCP request message which contains
      a Relay Agent Information option, it SHOULD add the Relay Agent
      Information Option as it deems appropriate and also populate the
      'peer-relay-agent-information' sub-option as described in section
      3.1.

   o  If a DHCP message received by a Relay Agent has a non-zero
      'giaddr' field, it MUST add 'peer-address' sub-option in the Relay
      Agent Information option with the same IP address as described in
      section 3.2.

   o  When a Relay Agent receives the reply message from the server, it
      MAY verify the Relay Agent Information option and SHALL silently
      discard the packet if it had not added the Relay Agent Information
      option.  A Relay Agent MUST remove the Relay Agent Information
      option it had added and process the reply message as follows:

      *  A Relay Agent MUST look for 'peer-relay-agent-information' sub-
         option in the Relay Agent Information option it had added and
         if it finds this sub-option, it MUST extract the contents which
         is the Option 82 of the previous Relay Agent.  Before relaying
         this message, it MUST append the Relay Agent Information option
         of the previous Relay Agent as it is to the DHCP message.
         Relay Agent MAY use the Relay Agent Information it had added,
         to identify the outgoing interface.

      *  A Relay Agent MUST also look for 'peer-address' sub-option and
         if it finds this sub-option, it must extract the IP address
         from the sub-option.  It MUST set this IP address as 'giaddr'
         and relay the DHCP reply to this IP address.  If this sub-
         option is not available, it SHOULD broadcast the reply to the
         outgoing interface.








Joshi & Kurapati         Expires January 8, 2010                [Page 8]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


4.1.2.  Handling Unicast DHCP messages

   As DHCP Clients unicast RENEW, RELEASE and INFORM messages directly
   to the DHCP server, these messages are not intercepted by Relay
   Agents and so these messages does not have any Relay Agent
   Information options added to them.

   Some existing Relay Agent implementations maintain lease/location
   informations for each DHCP client.  These implementations intercepts
   unicast DHCP messages to keep the lease/location information updated.
   So these Relay Agent adds Relay Agent Information option to unicast
   DHCP messages as well.  Relay Agents and DHCP server process them
   similar to broadcast messages as described above in section 5.1.1.






































Joshi & Kurapati         Expires January 8, 2010                [Page 9]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


5.  DHCP Server Behavior

   DHCP server would still find only one single Relay Agent Information
   option [ Option 82 ] in the DHCP message which has been relayed by
   multiple relay agents.

   Some existing DHCP servers may use the Relay Agent Information option
   to apply the IP Address and other parameter assignment policies.
   These DHCP servers will have to employ recursive lookup algorithm to
   find the relevant Option 82 [the Option 82 which was added by the
   first Relay Agent].  Server MUST echo back the entire Option 82 as it
   is.







































Joshi & Kurapati         Expires January 8, 2010               [Page 10]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


6.  Special Scenarios

6.1.  Multiple Layer 2 Relay Agents between DHCP client and Layer 3
      Relay Agent

   There may be a network scenario when there are multiple Layer 2 Relay
   Agents configured between DHCP clients and Layer 3 Relay Agent.  In
   this case, as described above, each Layer 2 Relay Agent MUST add
   'Relay Agent Information' option and MUST not add 'peer-address' sub-
   option in it.  A Layer 2 Relay Agent can use this Relay Agent
   Information option while relaying the DHCP Reply message back to the
   DHCP client.

6.2.  One or multiple Layer 2 Relay Agents between two Layer 3 Relay
      Agents

   There is a very rare possibility of one or multiple Layer 2 Relay
   Agents being present between two Layer 3 Relay Agents.  In this case,
   all the DHCP messages exchanged between these two Layer 3 Relay
   Agents would be unicast messages.  Typically a Layer 2 Relay Agent
   should snoop these DHCP messages only if it maintains Lease/Location
   information as described in [layer2-relay-agent].  In such cases,
   Layer 2 Relay Agents SHOULD add Relay Agent Information option as
   described in section 4.1.1.



























Joshi & Kurapati         Expires January 8, 2010               [Page 11]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


7.  Security Consideration

   o  A Relay Agents relaying DHCP messages to another Relay Agent are
      essentially DHCP clients for the DHCP messages.  Thus, RFC3118
      [RFC3118] is an appropriate mechanism for these DHCP messages.

   o  To restrict the number of Relay Agents in Relay Chaining, as
      defined in RFC 1542 [RFC1542], a Relay Agent must silently discard
      the DHCP message whose 'hops' field exceeds the value 16.  A
      network manager can use configuration option to set this threshold
      to a smaller value.








































Joshi & Kurapati         Expires January 8, 2010               [Page 12]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


8.  IANA Considerations

   This document needs IANA to provide a unique number for the following
   new suboptions in Relay Agent Information option [Option 82]:

   o  To carry the peer relay agent information option.  Please refer to
      section 3.1 for more details.

   o  To carry the peer address.  Please refer to section 3.2 for more
      details.









































Joshi & Kurapati         Expires January 8, 2010               [Page 13]


Internet-Draft          Relay Chaining in DHCPv4               July 2009


9.  References

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

   [layer2-relay-agent]
              Joshi, B. and P. Kurapati, "Layer 2 Relay Agent",
              draft draft-ietf-dhc-l2ra-04.txt, February 2009.

9.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 & Kurapati         Expires January 8, 2010               [Page 14]


Internet-Draft          Relay Chaining in DHCPv4               July 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/































Joshi & Kurapati         Expires January 8, 2010               [Page 15]