Internet DRAFT - draft-decnodder-dhc-rai-unicast

draft-decnodder-dhc-rai-unicast






DHC Working Group                                          S. De Cnodder
Internet-Draft                                                   Alcatel
Expires: February 18, 2007                                   P. Kurapati
                                               Infosys Technologies Ltd.
                                                         August 17, 2006


                       Unicast Address Sub-Option
                 draft-decnodder-dhc-rai-unicast-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 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 February 18, 2007.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   In some network topologies, it is preferred to have a trusted network
   element between the DHCP client and the L3 relay agent that adds the
   DHCP relay-agent-information option but does not set the giaddr
   field.  They operate in Layer 2 mode and hence act as trusted Layer 2
   relay agents.  The replies from the server are broadcasted by the L3
   relay agents to these L2 relay agents which must be avoided.  This
   document defines a new sub-option for the relay-agent-information



De Cnodder & Kurapati   Expires February 18, 2007               [Page 1]

Internet-Draft         Unicast Address Sub-Option            August 2006


   option.  With this sub-option, the L3 relay agent will always unicast
   the messages towards the trusted layer 2 DHCP relay agent with a
   hardware address that is known in the network.  The new sub-option is
   called the "unicast-address" sub-option.


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Unicast-Address Sub-Option . . . . . . . . . . . . . . . . . .  7
     3.1.  Unicast-Address Sub-Option Definition  . . . . . . . . . .  7
     3.2.  L3  Relay Agent Behavior . . . . . . . . . . . . . . . . .  7
     3.3.  L2 Relay Agent Behavior  . . . . . . . . . . . . . . . . .  7
     3.4.  DHCP Server Behavior . . . . . . . . . . . . . . . . . . .  8
     3.5.  Example Scenarios  . . . . . . . . . . . . . . . . . . . .  8
   4.  Security Consideration . . . . . . . . . . . . . . . . . . . . 10
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   6.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     7.1.  Normative Reference  . . . . . . . . . . . . . . . . . . . 13
     7.2.  Informative Reference  . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
   Intellectual Property and Copyright Statements . . . . . . . . . . 15



























De Cnodder & Kurapati   Expires February 18, 2007               [Page 2]

Internet-Draft         Unicast Address Sub-Option            August 2006


1.  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  "trusted layer 2 DHCP relay agent"

   A network element that is residing between the DHCP client and the L3
   DHCP relay agent.  This network element inserts the relay-agent-
   information option as a L3 DHCP relay agent would do.  The L3 DHCP
   relay agent trusts this option, and does not replace or remove it
   while transferring the DHCP message towards the server or towards the
   client.

   o  "DHCP client"

   A DHCP client is an Internet host using DHCP to obtain configuration
   parameters such as a network address.

   o  "L3 DHCP 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
   client.

   o  "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 client towards the edge



De Cnodder & Kurapati   Expires February 18, 2007               [Page 3]

Internet-Draft         Unicast Address Sub-Option            August 2006


   network.


















































De Cnodder & Kurapati   Expires February 18, 2007               [Page 4]

Internet-Draft         Unicast Address Sub-Option            August 2006


2.  Introduction

   In some network topologies, it is preferred to have a trusted network
   element between the DHCP client and the L3 DHCP relay agent that adds
   the DHCP relay-agent-information option (RFC 3046) [2] but does not
   set the giaddr field.  An example of such an environment is described
   in TR101 [3] where an access node such as a DSLAM adds the relay-
   agent-information option which can uniquely identify the DSL line.
   Multiple access nodes can be connected via an Ethernet based
   aggregation network to an IP edge router that is acting as the L3
   relay agent.  Such network elements adding the DHCP relay-agent-
   information option are called "layer 2 DHCP relay agents" in
   TR101[3].

   Figure 1 shows an example where each access node adds the relay agent
   information option containing the port information of the host
   sending the DHCP messages and the IP edge router relays the DHCP
   messages.


                 +-------+
   +-----+       |       |
   |Host1|-------|       |
   +-----+       |Access |
                 |Node1  |-----......
   +-----+       |       |           .
   |Host2|-------|       |            .     +------+
   +-----+       |       |             .    |      |
                 +-------+              ----|      |          +--------+
                 Trusted layer 2            |      |          |  DHCP  |
                 DHCP relay agents          |IPedge|--.....---| Server |
                 +-------+                  |      |          +--------+
   +-----+       |       |             .----|      |
   |Host3|-------|       |            .     |      |
   +-----+       |Access |           .      +------+
                 |Node2  |-----......         L3
   +-----+       |       |                    Relay Agent
   |Host4|-------|       |
   +-----+       |       |
                 +-------+

   Figure 1

   RFC 2131[4] 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



De Cnodder & Kurapati   Expires February 18, 2007               [Page 5]

Internet-Draft         Unicast Address Sub-Option            August 2006


   DHCPACK messages to all access nodes if the broadcast flag is set.

   Whether or not broadcast is used between the L3 relay agent and the
   trusted layer 2 DHCP 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 L3 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 nodes.  This is when the access
   node implements a MAC concentration or MAC translation function.
   When such a MAC operation is performed, the access node replaces the
   source MAC address of all upstream frames by another MAC address, for
   instance with its own 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 L3 DHCP relay agent.  Hence, all
   unicast messages sent by the L3 DHCP relay agent using this MAC
   address will be flooded to all access nodes.

   To overcome these two previously mentioned problems, this document
   defines a new sub-option 'unicast-address' for the relay-agent-
   information option.  With this sub-option, the L3 DHCP relay agent
   will always unicast the messages towards the trusted layer 2 DHCP
   relay agent with a hardware address that is known in the network.
























De Cnodder & Kurapati   Expires February 18, 2007               [Page 6]

Internet-Draft         Unicast Address Sub-Option            August 2006


3.  Unicast-Address Sub-Option

3.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 L3
   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 2

   o 'X' is the sub-option code which needs to be allocated by IANA.

   o 'Len' represents the lenth 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[5].

   o"hwaddr" is the unicast hardware address.

3.2.  L3  Relay Agent Behavior

   When L3 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 L3 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 L3 relay agent SHOULD behave as earlier and forward the
   message as per the broadcast bit set in the message.

3.3.  L2 Relay Agent Behavior

   The layer 2 DHCP relay agent may add this sub-option only in the case
   when the intermediate network elements does MAC learning ensuring
   that when the L3 relay agent unicasts the messages to this hardware
   address, the messages will arrive at the same layer 2 DHCP relay



De Cnodder & Kurapati   Expires February 18, 2007               [Page 7]

Internet-Draft         Unicast Address Sub-Option            August 2006


   agent.  The layer 2 DHCP relay agent SHOULD still be able to receive
   broadcast messages from the L3 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 L3 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.

   Any host connected to a L2 relay agent can add an option 82 with this
   new sub-option and send to L2 Relay Agent.  To prevent this all
   downstream ports on the L2 DHCP relay agent SHOULD be treated as non
   trusted entities and any packet arriving on this interface with
   Option 82 added SHOULD be silently discarded.  In case L2 relay agent
   is further downstream of Access node, it SHOULD be ensured that
   access node does not act as L2 relay agent for that line.

3.4.  DHCP Server Behavior

   Although rather unlikely, it is also possible that no L3 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 L3 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.  Server SHOULD also
   include this sub-option in the option 82 of its reply.

3.5.  Example Scenarios

   In a first example, the trusted layer 2 DHCP relay agent 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



De Cnodder & Kurapati   Expires February 18, 2007               [Page 8]

Internet-Draft         Unicast Address Sub-Option            August 2006


   sub-option.  The L3 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.

   In the second case L2 DHCP relay agent does MAC translation/
   concentration function.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.










































De Cnodder & Kurapati   Expires February 18, 2007               [Page 9]

Internet-Draft         Unicast Address Sub-Option            August 2006


4.  Security Consideration

   o  The unicast-address sub-option only applies to a network where
      there is a trusted layer 2 DHCP relay agent.  No new security
      issues with respect to such a network architecture are introduced
      by the unicast-address sub-option.













































De Cnodder & Kurapati   Expires February 18, 2007              [Page 10]

Internet-Draft         Unicast Address Sub-Option            August 2006


5.  IANA Considerations

   IANA is requested to assign a value from the DHCP Relay Agent Sub-
   options space defined in [RFC3046] for the unicast-address sub-option
   defined in Section 3.














































De Cnodder & Kurapati   Expires February 18, 2007              [Page 11]

Internet-Draft         Unicast Address Sub-Option            August 2006


6.  Acknowledgments

   The authors would like the acknowledge Ludwig Pauwels and Paul
   Reynders for their comments on this document.  Thanks to Patrick
   Mensch who contributed for the initial version of this draft.  Thanks
   to Ted Lemon, Andre Kostur and Bharat Joshi for suggesting
   improvements for this new option.












































De Cnodder & Kurapati   Expires February 18, 2007              [Page 12]

Internet-Draft         Unicast Address Sub-Option            August 2006


7.  References

7.1.  Normative Reference

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
        January 2001.

   [3]  Cohen, A. and E. Shrum, "Migration to Ethernet Based DSL
        Aggregation", Tecnical Report 101, DSL Forum, April 2006.

   [4]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

   [5]  Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.

7.2.  Informative Reference

   [6]  Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
        Extensions", RFC 2132, March 1997.





























De Cnodder & Kurapati   Expires February 18, 2007              [Page 13]

Internet-Draft         Unicast Address Sub-Option            August 2006


Authors' Addresses

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

   Email: stefaan.de_cnodder@alcatel.be
   URI:   http://www.alcatel.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/































De Cnodder & Kurapati   Expires February 18, 2007              [Page 14]

Internet-Draft         Unicast Address Sub-Option            August 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.




De Cnodder & Kurapati   Expires February 18, 2007              [Page 15]