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

Versions: 00 01

dhc                                                             T. Lemon
Internet-Draft                                             Nominum, Inc.
Intended status: Standards Track                                 H. Deng
Expires: January 12, 2012                                       L. Huang
                                                            China Mobile
                                                           July 11, 2011


                  Relay Agent Encapsulation for DHCPv4
              draft-ietf-dhc-dhcpv4-relay-encapsulation-01

Abstract

   This document describes a general mechanism whereby DHCP relay agents
   can encapsulate DHCP packets that they are forwarding in the
   direction of DHCP servers, and decapsulate packets that they are
   forwarding toward DHCP clients, so that more than one relay agent can
   insert relay agent suboptions into the forwarding chain.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on January 12, 2012.

Copyright Notice

   Copyright (c) 2011 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of



Lemon, et al.           Expires January 12, 2012                [Page 1]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
     1.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Protocol Summary . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  RELAYFORWARD Message . . . . . . . . . . . . . . . . . . .  6
     2.2.  RELAYREPLY Message . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Layer Two Address suboption  . . . . . . . . . . . . . . .  6
   3.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  The fixed-length header  . . . . . . . . . . . . . . . . .  8
     3.2.  Relay Segment  . . . . . . . . . . . . . . . . . . . . . .  9
     3.3.  Encapsulation Segment  . . . . . . . . . . . . . . . . . .  9
   4.  DHCP Relay Agent Behavior  . . . . . . . . . . . . . . . . . .  9
     4.1.  Packet processing  . . . . . . . . . . . . . . . . . . . . 10
       4.1.1.  Packets traveling toward DHCP servers  . . . . . . . . 11
       4.1.2.  Packets traveling toward DHCP clients  . . . . . . . . 11
       4.1.3.  Anti-spoofing  . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Constructing RELAYFORWARD messages . . . . . . . . . . . . 11
       4.2.1.  Initializing the fixed-length header . . . . . . . . . 11
       4.2.2.  Initializing the relay segment . . . . . . . . . . . . 12
       4.2.3.  Fixed header settings for RELAYFORWARD messages  . . . 12
       4.2.4.  Fixed header settings for BOOTREQUEST messages . . . . 13
       4.2.5.  Initializing the encapsulation segment . . . . . . . . 13
     4.3.  Decapsulating RELAYREPLY messages  . . . . . . . . . . . . 13
       4.3.1.  Processing relay agent suboptions  . . . . . . . . . . 13
       4.3.2.  Constructing the decapsulated message  . . . . . . . . 14
     4.4.  Retransmitting modified messages . . . . . . . . . . . . . 14
       4.4.1.  Layer two relay agents . . . . . . . . . . . . . . . . 14
         4.4.1.1.  Constructing the headers . . . . . . . . . . . . . 14
         4.4.1.2.  Forwarding the modified packet . . . . . . . . . . 15
       4.4.2.  Layer three relay agents . . . . . . . . . . . . . . . 15
         4.4.2.1.  Transmitting a decapsulated RELAYREPLY message . . 15
         4.4.2.2.  Transmitting a decapsulated BOOTREPLY message  . . 16
         4.4.2.3.  Transmitting other messages  . . . . . . . . . . . 16
   5.  DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  Receiving RELAYFORWARD messages  . . . . . . . . . . . . . 16
       5.1.1.  Decapsulation  . . . . . . . . . . . . . . . . . . . . 16
       5.1.2.  Processing of decapsulated suboptions  . . . . . . . . 16
       5.1.3.  Address allocation . . . . . . . . . . . . . . . . . . 17
         5.1.3.1.  Default link selection algorithm . . . . . . . . . 17
         5.1.3.2.  Other link selection algorithms  . . . . . . . . . 18
     5.2.  Responding to RELAYFORWARD messages  . . . . . . . . . . . 18
       5.2.1.  Constructing a RELAYREPLY encapsulation  . . . . . . . 18



Lemon, et al.           Expires January 12, 2012                [Page 2]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


         5.2.1.1.  Constructing the relay segments  . . . . . . . . . 19
         5.2.1.2.  Constructing the fixed-length header . . . . . . . 19
       5.2.2.  Transmission of RELAYREPLY messages  . . . . . . . . . 19
     5.3.  Responding to messages other than RELAYFORWARD . . . . . . 20
   6.  DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 20
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22








































Lemon, et al.           Expires January 12, 2012                [Page 3]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


1.  Introduction

   In some networking environments, it is useful to be able to configure
   relay agents in a hierarchy, so that information from a relay agent
   close to the client can be combined with information from one or more
   relay agents closer to the server, particularly in cases where the
   relay agents may be in separate administrative domains.

   The current Relay Agent Information Option (RAIO) specification
   [RFC3046] specifies that when a relay agent receives a packet
   containing an RAIO, it must not add an RAIO.  This prevents chaining
   of RAIOs, and hence prohibits the hierarchical use case.

   DHCP version 6 [RFC3315] provides a much cleaner technique for
   providing RAIO suboptions to the DHCP server.  Rather than appending
   an information option to the DHCP client's message, the relay agent
   encapsulates the DHCP client message in a new DHCP message which it
   sends to the DHCP server along with any options it chooses to add to
   provide information to the DHCP server.

   This document specifies a mechanism for providing the same
   functionality in DHCPv4.

1.1.  Requirements Language

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

1.2.  Terminology

   The following terms and acronyms are used in this document:

   BOOTREPLY message     Any DHCP or BOOTP message in which the 'op'
                         field is set to BOOTREPLY.

   BOOTREQUEST message   Any DHCP or BOOTP message in which the 'op'
                         field is set to BOOTREQUEST.

   DHCP                  Dynamic Host Configuration Protocol Version 4
                         [RFC2131]

   decapsulate           the act of de-encapsulating DHCP packets being
                         relayed from DHCP servers or relay agents in
                         the direction of DHCP clients, according to
                         this specification.





Lemon, et al.           Expires January 12, 2012                [Page 4]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   encapsulate           the act of encapsulating DHCP packets that are
                         being relayed from DHCP clients or relay agents
                         toward DHCP servers, according to the method
                         described in this specification.

   encapsulating relay agent  a relay agent that implements this
                         specification and is configured to encapsulate.

   L2RA                  Layer 2 Relay Agent--a relay agent that doesn't
                         have an IP address reachable by the DHCP
                         server.

   L3RA                  Layer 3 Relay Agent--a relay agent that has an
                         IP address reachable by the DHCP server.

   option buffer         the portion of the DHCP packet following the
                         magic cookie in the 'vend' field of the DHCP
                         Packet.

   RAIO                  Relay Agent Information Option [RFC3046].  Also
                         commonly referred to as "Option 82."

   RAIO suboption        a DHCP suboption that has been defined for
                         encapsulation in the Relay Agent Information
                         Option

   relay message         a RELAYFORWARD or RELAYREPLY message.

   RELAYFORWARD message  Any DHCP or BOOTP message in which the 'op'
                         field is set to RELAYFORWARD.

   RELAYREPLY message    Any DHCP or BOOTP message in which the 'op'
                         field is set to RELAYREPLY.

   silently discard      in many places in this specification, the
                         implementation is required to silently discard
                         erroneous messages.  What is meant by 'silently
                         discard' is that the implementation MUST NOT
                         send any ICMP message indicating that the
                         delivery was in error.  It may be desirable for
                         the implementation to keep a count of messages
                         that have been discarded, either by message
                         type or by reason for discarding, or some
                         combination.  Nothing in this specification
                         should be construed to forbid such data
                         collection.





Lemon, et al.           Expires January 12, 2012                [Page 5]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


2.  Protocol Summary

   This document specifies two new BOOTP message types: the RELAYFORWARD
   message, and the RELAYREPLY message.  These messages are analogous to
   the Relay Forward and Relay Reply messages in DHCPv6 [RFC3315].

   Although this specification is generally aimed at DHCP
   implementations, it is not specifically restricted to DHCP, and is
   applicable to BOOTP in cases where the BOOTP server is a DHCP server
   that implements this specification, or the less likely case that the
   BOOTP server only supports the BOOTP protocol, but still implements
   this specification.

   In general, when the term "DHCP" appears in this specification, the
   reader should not read this as intending to exclude BOOTP.

2.1.  RELAYFORWARD Message

   Conforming relay agents encapsulate messages being sent toward DHCP
   servers in RELAYFORWARD messages.

2.2.  RELAYREPLY Message

   A conforming DHCP server encapsulates any message being sent toward a
   DHCP client in a RELAYREPLY message, if the message being responded
   to was encapsulated.

   A conforming relay agent, when it receives a RELAYREPLY message,
   decapsulates the message contained in the RELAYREPLY message and
   sends it to the next relay or to the client.

2.3.  Layer Two Address suboption

   In cases where the closest relay agent to the client is an L2RA, but
   where there is an L3RA on the path to the client, the DHCP server
   will encode the link layer address that would normally go in the
   chaddr field of the DHCP packet into a Layer Two Address suboption.

         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         | SUBOPT_L2AS |    length     |     htype     |    chaddr ...
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Layer Two Address suboption has four fields:






Lemon, et al.           Expires January 12, 2012                [Page 6]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   SUBOPT_L2AS  One octet: the suboption code for the Layer Two Address
      suboption (TBD).

   length  One octet: the length of the Layer Two Address suboption.

   htype  One octet: the type of the Layer Two Address suboption--
      corresponds to the 'htype' field in a non-relay DHCP or BOOTP
      message.

   chaddr  One or more octets: the layer two address of the client, from
      the 'chaddr' field of the DHCP or BOOTP message.


3.  Encoding

   RELAYFORWARD and RELAYREPLY messages are distinguished through the
   use of the 'op' field of the DHCP packet.

   In non-relay DHCP packets, the 'op' field either contains
   BOOTREQUEST, for any DHCP message from the client to the server, or
   BOOTREPLY, for any DHCP message from the server to the client.

   This document defines two additional codes, RELAYFORWARD and
   RELAYREPLY.  Conforming DHCP servers and DHCP relay agents MUST
   support these two new values for the 'op' field.  DHCP clients should
   never see either value.

                          +------+--------------+
                          | code | meaning      |
                          +------+--------------+
                          | 1    | BOOTREQUEST  |
                          | 2    | BOOTREPLY    |
                          | 3    | RELAYFORWARD |
                          | 4    | RELAYREPLY   |
                          +------+--------------+

                         Values for the 'op' field

   RELAYFORWARD and RELAYREPLY messages share only the 'op' field in
   common with other DHCP and BOOTP messages.  The remainder of the
   message consists of a series of fixed-length fields followed by two
   variable-length fields: the relay segment, and the encapsulated
   message.








Lemon, et al.           Expires January 12, 2012                [Page 7]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   +-----+-----+-----+-----+
   |  op |  ep |   padlen  |
   +-----+-----+-----+-----+
   |   rslen   |   caplen  |
   +-----+-----+-----+-----+
   |        aiaddr         |
   +-----+-----+-----+-----+
   .                       .
   .     relay segment     .
   .                       .
   +-----------------------+
   .                       .
   .  encapsulated message .
   .                       .
   +-----------------------+

3.1.  The fixed-length header

   The fixed-length header of the relay message contains a series of
   fields that perform two purposes: to provide enough information that
   the DHCP server can reconstruct the original packet sent by the DHCP
   client, and to establish the lengths of the two variable-length
   segments.

   To satisfy the first of these requirements, two fields in the fixed-
   length header report the amount of padding stripped from the client
   message, if any, and whether or not an end option was stripped from
   the client message.  Except for a relay message that immediately
   encapsulates a message from a DHCP client, these fields are always
   zero.  Using these two fields, the DHCP server can reconstruct the
   client packet exactly, and this allows the DHCP server to validate
   any signature [RFC3118] that may be present.

   The fixed-length header consists of five fields:

   op The BOOTP 'op' field, which, for a relay message, MUST contain the
      RELAYFORWARD or RELAYREPLY code.

   ep If an End option was present in the option buffer prior to
      encapsulation, this field is set to 1; otherwise, it is set to 0.
      This field is a single byte.

   padlen  The length of any padding that was removed from the option
      buffer prior to encapsulation: two bytes in network byte order.







Lemon, et al.           Expires January 12, 2012                [Page 8]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   rslen  The length of the relay segment: two byte in network byte
      order.

   caplen  The length of the encapsulation segment: two byte in network
      byte order.

   aiaddr  Relay agent IP address.

3.2.  Relay Segment

   The relay segment contains any RAIO suboptions that the encapsulating
   agent (the relay agent or the DHCP server) wishes to send.  End and
   Pad options MUST NOT appear in the relay segment.

3.3.  Encapsulation Segment

   The encapsulation segment contains the entire DHCP message being
   encapsulated, with four exceptions:

   o  The encapsulating agent MUST omit the IP and UDP headers, as well
      as any layer two header, from the encapsulated message.

   o  The encapsulating agent MUST omit any options following the first
      End option in the option buffer.  These options are assumed to be
      garbage, and are not covered by any signature [RFC3118].

   o  The encapsulating MUST omit any Pad options present either at the
      end of the option buffer, or prior to the first End option, that
      are followed only by other Pad options or a single End option.
      The encapsulating agent MUST record number of Pad options that
      were omitted in the 'padlen' field of the message header.

   o  The encapsulating agent MUST omit the End option, if present.  The
      encapsulating agent MUST set the 'ep' field in the message header
      to 1 if an End option was present in the option buffer, and to
      zero if no End option was present.

   These exceptions apply only to the option buffer.  The encapsulating
   agent MUST NOT modify the contents of the 'file' and 'sname' fields.
   The encapsulating agent MUST NOT count End or Pad options that appear
   in these fields.


4.  DHCP Relay Agent Behavior

   DHCP Relay agents implementing this specification MUST have a
   configuration parameter controlling relay encapsulation.  By default,
   relay encapsulation MUST be disabled.



Lemon, et al.           Expires January 12, 2012                [Page 9]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   Relay agents with encapsulation disabled MUST NOT encapsulate.  Relay
   agents with encapsulation disabled MUST NOT decapsulate.

   In any case where a relay agent implementing this specification does
   not encapsulate or decapsulate, it MUST behave exactly as a relay
   agent that does not implement this specification at all.

   DHCP relay agents that are configured with encapsulation enabled, but
   which have no agent-specific options to send to the DHCP server, MUST
   encapsulate.  Relay agents that are configured with encapsulation
   enabled MUST decapsulate.

   Layer two relay agents MUST silently discard any messages that
   contains an IPsec authentication header [RFC4302].  This is because
   they cannot modify such messages, but also cannot detect that a
   message from the DHCP server is in response such messages, since the
   response message might not contain an IPsec authentication header.

   If a relay message would exceed the MTU of the outgoing interface, it
   MUST be discarded, and an error condition SHOULD be logged.

4.1.  Packet processing

   Relay agents implementing this specification may receive packets
   directed toward DHCP servers with a source port of 67 (BOOTPS).
   Therefore, the source port cannot be used to determine whether the
   packet is traveling toward a DHCP server or toward a DHCP client.

   In order to determine whether a message is traveling toward a DHCP
   client or toward a DHCP server, the relay agent must check the 'op'
   field of the DHCP message.  If the 'op' field is set to BOOTREQUEST
   or RELAYFORWARD, the message is traveling toward a DHCP server.  If
   the 'op' field is set to BOOTREPLY or RELAYREPLY, the message is
   traveling toward a DHCP client.  At the time of the writing of this
   specification, no other value is meaningful in the 'op' field.

   Relay agents implementing this specification MUST NOT encapsulate or
   decapsulate messages with other values in the 'op' field.  It is
   assumed that if meanings are defined for additional values, the
   document that specifies the meaning of those values will update this
   document; in the absence of such an update, the behavior specified
   here will remain in effect.

   Relay agents implementing this specification MAY differentiate
   between DHCP and BOOTP messages.  Under normal circumstances, BOOTP
   and DHCP messages are forwarded to the same server, which should be
   able to successfully decapsulate both DHCP and BOOTP messages.
   However, some relay agents may send BOOTP and DHCP packets to



Lemon, et al.           Expires January 12, 2012               [Page 10]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   different servers; this document should not be construed to require
   that such a relay agent should encapsulate all messages regardless of
   protocol.

4.1.1.  Packets traveling toward DHCP servers

   Any DHCP or BOOTP packet with an 'op' value of BOOTREQUEST or
   RELAYFORWARD is traveling toward a DHCP server.  When a DHCP relay
   agent that is configured to encapsulate receives such a packet, the
   relay agent MUST encapsulate that packet into a RELAYFORWARD message
   and send it to the address or addresses with which it is configured
   to forward messages intended for DHCP servers.

4.1.2.  Packets traveling toward DHCP clients

   Any DHCP or BOOTP packet with an 'op' value of BOOTREPLY or
   RELAYREPLY is traveling toward a DHCP client.  When a DHCP relay
   agent that is configured to encapsulate recieves a RELAYREPLY message
   that is traveling toward a DHCP or BOOTP client, the relay agent MUST
   decapsulate that message and forward the decapsulated message toward
   the client.

4.1.3.  Anti-spoofing

   Because this specification allows for chaining of relay agent-
   supplied information, it is now possible for a relay agent outside of
   the trusted portion of a network to communicate relay agent
   information to the DHCP server without preventing the legitimate
   relay from communicating return path information to the DHCP server,
   as is the case with RFC3046.

   In order to prevent this sort of spoofing, relay agents implementing
   this specification MUST be configurable to discard all RELAYFORWARD
   messages that they receive.  Administrators relying on a trusted
   network architecture to control the flow of information to the DHCP
   server SHOULD configure relay agents on the edge of their networks to
   discard RELAYFORWARD messages.

4.2.  Constructing RELAYFORWARD messages

4.2.1.  Initializing the fixed-length header

   The relay agent constructs the RELAYFORWARD message by constructing
   the fixed-length header as specified in the earlier section titled
   'Encoding'.  The relay agent MUST set the 'op' field to a value of
   RELAYFORWARD.

   If the relay agent is not a layer two relay agent



Lemon, et al.           Expires January 12, 2012               [Page 11]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   [I-D.ietf-dhc-l2ra], it MUST store one of its own IP addresses in the
   'aiaddr' field.  This address MUST be a valid IP address that is
   reachable by the next hop relay(s) or DHCP server(s) to which the
   relay agent is configured to forward.

   DHCP servers normally use the relay agent IP address to determine on
   what link the DHCP client's IP address should be allocated.  In some
   cases, the value stored in the 'aiaddr' field will not be a valid IP
   address on the link on which the source message was received.  In
   this case, the relay agent MUST include a link selection suboption
   [RFC3527] that identifies that link in the relay segment.

   If the relay agent is a layer two relay agent, it MAY include a link
   selection suboption in the relay segment.

   If the message being encapsulated is a BOOTREQUEST, L2RAs MUST store
   a value of zero in the 'aiaddr' field.  Otherwise, the L2RA MUST copy
   the value of the 'aiaddr' field in the RELAYFORWARD message being
   encapsulated into the 'aiaddr' field of the RELAYFORWARD message that
   it generates.

   The 'rslen' field depends on the length of the relay segment.  The
   'caplen', 'padlen' and 'ep' values in the fixed header are
   initialized differently depending on whether the message being
   encapsulated is a BOOTREQUEST or a RELAYFORWARD message.

4.2.2.  Initializing the relay segment

   Following the fixed header, the relay agent MUST append any RAIO
   suboptions it wishes to send to the DHCP server; this is the 'relay
   segment'.  It MUST store the length of the relay segment in the
   'rslen' field of the fixed header.

   The relay agent SHOULD include a Relay Agent ID suboption
   [I-D.ietf-dhc-relay-id-suboption] in the relay segment to identify
   itself to the DHCP server.

4.2.3.  Fixed header settings for RELAYFORWARD messages

   If the message being encapsulated is a RELAYFORWARD message, the
   relay agent MUST initialize the 'caplen' field of the fixed header to
   the length of the source message, excluding any layer 2, IP and UDP
   headers.  It MUST append the contents of the message, again excluding
   any layer 2, IP or UDP headers, to the new message.  It MUST
   initialize the 'ep' and 'padlen' fields in the fixed header of the
   new message to zero.





Lemon, et al.           Expires January 12, 2012               [Page 12]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


4.2.4.  Fixed header settings for BOOTREQUEST messages

   If the message being encapsulated is a BOOTREQUEST message, the relay
   agent determines the length of the encapsulation segment by scanning
   forward across the option buffer of the source message, beginning
   with the first option in the option buffer, until an End option is
   reached, or the end of the buffer is reached.  The difference between
   the offset of this location in the message and the offset of the
   first location following the UDP header of the message is the length
   of the message to be relayed.

   If an End option terminated the scan, the relay agent MUST set the
   value of the 'ep' field in the fixed header to one.  Otherwise, the
   relay agent MUST set the value of the 'ep' field to zero.

   The relay agent MUST count all of the Pad options that follow the
   last option in the option buffer that is neither a Pad nor an End
   option.  The relay agent MUST store this count in the 'padlen' field
   of the fixed header.

   The relay agent MUST store the difference between the value stored in
   'padlen' and the length of the message to be relayed in the 'caplen'
   field of the fixed header.

4.2.5.  Initializing the encapsulation segment

   The relay agent MUST copy the portion of the message being
   encapsulated that immediately follows the UDP header into the
   RELAYFORWARD message being generated.  The length of the data being
   copied is the value that was stored in 'caplen'.

4.3.  Decapsulating RELAYREPLY messages

   To decapsulate a RELAYREPLY message, the relay agent creates a
   decapsulated message, processes any RAIO suboptions it recognizes in
   the relay segment, and forwards the decapsulated message to its
   destination.

4.3.1.  Processing relay agent suboptions

   The suboptions parsed from the relay segment are processed by the
   relay agent as specified in the Relay Agent Information Option
   specification [RFC3046], as well as in any documents that define
   suboptions to the Relay Agent Information Option.  A current list of
   DHCP Relay Agent suboptions and the documents that define them can be
   located in the IANA protocol registry for Bootp and DHCP parameters,
   in the section titled "DHCP Relay Agent Sub-Option Codes."




Lemon, et al.           Expires January 12, 2012               [Page 13]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


4.3.2.  Constructing the decapsulated message

   To construct a decapsulated message, the relay agent copies the
   portion of the RELAYREPLY message following the relay segment, with a
   length specified in the 'caplen' field of the fixed-length header,
   into the new message.

4.4.  Retransmitting modified messages

   If the relay agent did not modify the message either by encapsulating
   or decapsulating it, it retransmits the message according to existing
   practice.

   Otherwise, how the modified message is transmitted to its next
   destination depends on two factors.  First, is the relay agent that
   modified the message a layer two [I-D.ietf-dhc-l2ra] relay agent or a
   layer three [RFC1542] relay agent?  Second, is the modified message a
   BOOTREPLY message, a RELAYREPLY message, or some other message?

4.4.1.  Layer two relay agents

   There are two special aspects to the handling of relayed packets in
   Layer Two Relay Agents (L2RAs).  The first is the construction of the
   layer two, IP and UDP headers on the packet.  The second is how the
   L2RA makes the forwarding decision.

4.4.1.1.  Constructing the headers

   The L2RA constructs the headers on the relayed packet by copying and,
   as necessary, modifying the headers from the original packet.

   If there is a layer two header, the L2RA MUST copy this header in
   accordance with the needs of the particular layer two implementation
   it is using.  If the header contains a packet length field, the L2RA
   MUST adjust the value in the packet length field.  If the header
   contains a non-secure integrity check such as a CRC or checksum that
   covers the entire packet, the L2RA MUST recompute this value.

   L2RA encapsulation in cases where the layer two contains a secure
   integrity check must either construct a new integrity signature, or
   else remove the integrity signature.  If neither of these is
   possible, the L2RA MUST silently discard the packet.

   The L2RA MUST copy the IP header without modification except length
   and checksum field which should be recomputed.  If the IP header
   contains any sort of secure integrity check on the packet, the L2RA
   MUST silently discard the packet.




Lemon, et al.           Expires January 12, 2012               [Page 14]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   The L2RA MUST copy the UDP header and adjust the 'Length' field
   [RFC0768].  If the contents of the 'Checksum' field are not zero, the
   L2RA MUST compute a new checksum according to the algorithm specified
   in User Datagram Protocol. [RFC0768]

4.4.1.2.  Forwarding the modified packet

   Ordinarily when a layer two device forwards a packet, it simply
   copies that packet from the interface on which it was received and
   transmits it, unchanged, on one or more interfaces other than that
   interface.  The mechanism used to choose which interfaces it forwards
   the packet to is beyond the scope of this document.

   Once a DHCP packet has been modified by the L2RA either as an
   encapsulation or a decapsulation, the L2RA must forward it either
   toward the DHCP server or the DHCP client.  The implementation has
   two options: transmit the packet as it would transmit any other
   packet, or use its configuration and/or information in the relay
   header to direct the packet out a particular interface.

   The details of ordinary packet forwarding in devices that implement
   L2RA is beyond the scope of this document.

   When processing a RELAYREPLY message, the L2RA MAY use information in
   the relay segment of the RELAYREPLY to determine on which network
   interface the RELAYREPLY should be forwarded.

   When processing any other message, the L2RA MAY use configuration
   information to direct the packet out a specific port or ports that
   have been marked as reaching DHCP servers.  The L2RA MUST NOT forward
   any packet on the interface on which it was received, even if that
   interface is so marked.

4.4.2.  Layer three relay agents

4.4.2.1.  Transmitting a decapsulated RELAYREPLY message

   When the decapsulated message is itself a RELAYREPLY message, the
   relay agent MUST forward the decapsulated message to the IP address
   specified in the 'aiaddr' field of the fixed-length header.

   If the relay segment of the packet that was decapsulated contains a
   Link Layer Address suboption, the relay agent MUST transmit the
   packet to that link layer address without attempting to use Address
   Resolution Protocol (ARP) to translate the address contained in
   'aiaddr' to a layer two address.





Lemon, et al.           Expires January 12, 2012               [Page 15]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


4.4.2.2.  Transmitting a decapsulated BOOTREPLY message

   When transmitting a decapsulated BOOTREPLY message, the relay agent
   transmits the message as specified in Bootstrap Protocol, Section 4
   [RFC0951].

4.4.2.3.  Transmitting other messages

   When transmitting RELAYFORWARD and BOOTREQUEST messages, the relay
   agent simply sends the message to the IP address or addresses
   configured as DHCP servers for that relay agent.


5.  DHCP Server Behavior

   A DHCP server which receives a RELAYREPLY message MUST silently
   discard that message.

5.1.  Receiving RELAYFORWARD messages

   DHCP servers that implement this specification MUST decapsulate
   RELAYFORWARD messages.

5.1.1.  Decapsulation

   By design, this specification supports multiple layers of
   encapsulation.  The DHCP server implementation therefore MUST
   decapsulate each layer and retain the information in that layer,
   organized so that the ordering of the encapsulation is available both
   during packet processing, and when constructing the reply.

   Aside from the necessity of handling an RAIO differently than an
   encapsulation when constructing a RELAYREPLY message, DHCP servers
   MUST NOT, by default, treat relay suboptions received in an RAIO any
   differently than relay suboptions received in an encapsulation.

   It is not the goal of this specification to define a particular
   implementation strategy or data structure for representing the
   encapsulation, so long as the ability to process the options and
   suboptions as required below is preserved.  Implementations MAY
   provide means for addressing the contents of relay segments and of
   the inner encapsulation segment in any convenient form, as long as it
   conforms generally to the requirements of this document.

5.1.2.  Processing of decapsulated suboptions

   This section specifies requirements for the processing of
   decapsulated relay suboptions in the default case, where no custom



Lemon, et al.           Expires January 12, 2012               [Page 16]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   processing has been specified.  This should not be construed to
   forbid implementations for providing mechanisms for customizing the
   processing of these suboptions.

   This document does not specify special handling for DHCP options.
   Only the inner encapsulation--the encapsulation of the original
   message sent from the client, which is done by the first
   encapsulating relay--can ever contain DHCP Options; hence, whatever
   normal mechanisms a DHCP server provides for processing these options
   should suffice.

   Some relay agent suboptions, such as the Relay Agent Subnet Selection
   suboption [RFC3527], are intended to be processed by DHCP servers.
   Others, like the Circuit ID and Remote ID [RFC3046] suboptions, were
   not intended to be processed by the DHCP server, but are often used
   by the DHCP server for identification purposes.

   In cases where more than one relay agent sends the same suboption,
   the DHCP server must either factor all such suboptions into its
   processing, or choose one such suboption and use that exclusively for
   processing.

   By default, DHCP servers MUST use the outermost suboption (the one
   added by the relay agent closest to the DHCP server) for every
   suboption that was sent by more than one relay agent.

5.1.3.  Address allocation

   During normal processing, DHCP servers use a variety of data to
   determine where the DHCP client is in the network topology.  These
   data are provided by relay agents.  In the absence of any relay-
   agent-provided topology data, the DHCP server assumes that the client
   is connected to the link on which the message was received.

   One datum used by DHCP servers in locating the client is the value of
   the 'giaddr' field of the BOOTP header.  This specification
   eliminates the use of giaddr; hence, it cannot be used in the address
   allocation decision.

   The functionality provided by giaddr is replaced in this
   specification by the 'aiaddr' field in the fixed-length relay header.

5.1.3.1.  Default link selection algorithm

   DHCP servers MUST implement a default algorithm for determining the
   link to which the client is attached.  This algorithm is to first
   search the client message for a subnet selection option [RFC3011].




Lemon, et al.           Expires January 12, 2012               [Page 17]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   The server next searches for link-identifying data in each
   RELAYFORWARD encapsulation, starting from the inner most and ending
   at the outermost, until a RELAYFORWARD is found that identifies the
   client's location.

   A RELAYFORWARD encapsulation contains link-identifying data if the
   value of the 'aiaddr' field of the fixed-length header is not zero,
   or if the relay segment contains a Link Selection suboption
   [RFC3527].

   If a Link Selection suboption is present in the innermost
   RELAYFORWARD message containing link-identifying data, the DHCP
   server MUST use the contents of that option to identify the link to
   which the client is connected.

   Otherwise, if a Subnet Selection option was found in the client
   message, the DHCP server MUST use the contents of that option to
   identify the link to which the client is connected.

   Otherwise, the DHCP server MUST use the contents of the 'aiaddr'
   field in the RELAYFORWARD encapsulation that was identified as being
   the innermost RELAYFORWARD containing link-identifying data.

5.1.3.2.  Other link selection algorithms

   DHCP servers implementing this specification MAY implement link
   selection algorithms other than the one described in the preceding
   section.  DHCP servers MUST NOT use any link selection algorithm
   other than the one described in the preceding section unless
   specially configured to do so.

5.2.  Responding to RELAYFORWARD messages

   Once the DHCP server has processed the encapsulated message from the
   DHCP client and constructed a response to the DHCP client, it
   constructs a RELAYREPLY message and sends it toward the client.

5.2.1.  Constructing a RELAYREPLY encapsulation

   The server MUST encapsulate any response to a client message
   contained in one or more RELAYFORWARD encapsulations in a set of
   corresponding RELAYREPLY encapsulations.  Each RELAYREPLY is nested
   in the same way that the corresponding RELAYFORWARD was nested, so
   that the innermost RELAYREPLY corresponds to the innermost
   RELAYFORWARD, and the outermost RELAYREPLY corresponds to the
   outermost RELAYFORWARD.





Lemon, et al.           Expires January 12, 2012               [Page 18]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


5.2.1.1.  Constructing the relay segments

   The server MUST copy every suboption that appeared in the relay
   segment of the RELAYFORWARD encapsulation into corresponding outgoing
   RELAYREPLY encapsulation's relay segment.  The server SHOULD NOT
   preserve the order of options from the incoming relay segment to the
   outgoing relay segment.

   If the message encapsulated by a particular RELAYREPLY encapsulation
   is not a RELAYREPLY, or if the message encapsulated by that
   RELAYREPLY is a RELAYREPLY, but the 'aiaddr' field of the fixed-
   length header of the inner RELAYREPLY has a value of zero, the DHCP
   server MUST include a Layer Two Address suboption in the relay
   segment.  The DHCP server MUST set the 'htype' field of the Layer Two
   Address suboption to the value of 'htype' in the client message.  The
   DHCP server MUST set the 'chaddr' field in the Layer Two Address
   suboption to the value of the 'chaddr' field in the client message.

5.2.1.2.  Constructing the fixed-length header

   The server MUST set the values of 'ep' and 'padlen' in the fixed-
   length header to zero.  The server MUST set the value of 'caplen' to
   the length of the message encapsulated in the RELAYREPLY
   encapsulation being constructed.  The server MUST set the value of
   'rslen' to the length of the relay segment of the RELAYREPLY
   encapsulation being constructed.

   If the message encapsulated in the RELAYREPLY being constructed is a
   RELAYREPLY, and the 'aiaddr' field of the RELAYFORWARD encapsulation
   corresponding to the inner RELAYREPLY is not zero, the DHCP server
   MUST copy the value from that 'aiaddr' field to the 'aiaddr' field of
   the RELAYREPLY being constructed.

   Otherwise, if the BROADCAST bit in the 'flags' field of the inner
   message is set to 1, or 'ciaddr' is zero and 'yiaddr' is also zero,
   the DHCP server MUST set the value of 'aiaddr' to 255.255.255.255.
   If 'ciaddr' is not zero, the DHCP server must copy that value to
   'aiaddr'.  If 'ciaddr' is zero and 'yiaddr' is not, the DHCP server
   MUST copy the value of 'yiaddr' to 'aiaddr'.

5.2.2.  Transmission of RELAYREPLY messages

   If the value of 'aiaddr' in the outermost RELAYFORWARD encapsulation
   to which the RELAYREPLY is a response is nonzero, the DHCP server
   MUST transmit the RELAYREPLY to that IP address.

   Otherwise, if 'ciaddr' and 'yiaddr' are both zero, or the BROADCAST
   bit in the 'flags' field is set to 1, or the DHCP server



Lemon, et al.           Expires January 12, 2012               [Page 19]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   implementation is not able to perform the ARP-cache preloading trick
   described in Bootstrap Protocol, Section 4 [RFC0951], the DHCP server
   MUST broadcast the RELAYREPLY message to the 255.255.255.255
   broadcast address.

   Otherwise, the DHCP server MUST use the value of 'ciaddr', if
   nonzero, or 'yiaddr', otherwise, as the destination address for the
   message, and MUST preload its ARP cache (or otherwise arrange to
   transmit the message without using ARP) to the layer two address
   provided by the client in 'htype' and 'chaddr' and 'hlen'.

5.3.  Responding to messages other than RELAYFORWARD

   When a DHCP server constructs a response to a DHCP client message
   that did not arrive encapsulated in a RELAYFORWARD message, the DHCP
   server MUST NOT encapsulate the response in a RELAYREPLY message.
   DHCP server implementors should be careful that their servers do not
   respond to an incoming packet with RAIO from a non-conforming relay
   agent with a RELAYREPLY message.


6.  DHCP Client Behavior

   A DHCP client that receives either a RELAYFORWARD message or a
   RELAYREPLY message MUST silently discard that message.


7.  Security Considerations

   DHCP Relay Information Option [RFC3046] limits relay agent
   information to a single relay agent, and provides some minimal anti-
   spoofing.  By supporting relay agent chaining, it is now possible for
   a relay agent downstream of the trusted portion of a provider network
   to communicate relay agent information options to a DHCP server.

   This specification defines a much more robust spoofing rejection
   mechanism, by allowing the administrator to configure the relay to
   discard RELAYFORWARD messages originating from outside of the trusted
   portion of the network.  Administrators of networks that rely on this
   trusted/untrusted configuration are encouraged to configure edge
   relays to discard RELAYFORWARD messages.

   In networks where trusted relay agents may be separated from the DHCP
   server by transit networks that are not trusted, it is possible to
   modify the message in transit.  This possibility exists with normal
   DHCP relays as well.  Administrators of such networks should consider
   using relay agent authentication [RFC4030] to prevent modification of
   relay agent communications in transit.



Lemon, et al.           Expires January 12, 2012               [Page 20]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


8.  IANA Considerations

   We request that IANA assign one new suboption code from the registry
   of DHCP Agent Sub-Option Codes maintained in
   http://www.iana.org/assignments/bootp-dhcp-parameters.  This
   suboption code will be assigned to the Layer Two Address Suboption.


9.  References

9.1.  Normative References

   [I-D.ietf-dhc-relay-id-suboption]
              Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption",
              draft-ietf-dhc-relay-id-suboption-07 (work in progress),
              July 2009.

   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              August 1980.

   [RFC0951]  Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951,
              September 1985.

   [RFC1542]  Wimer, W., "Clarifications and Extensions for the
              Bootstrap Protocol", RFC 1542, October 1993.

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

   [RFC3011]  Waters, G., "The IPv4 Subnet Selection Option for DHCP",
              RFC 3011, November 2000.

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

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3527]  Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy,
              "Link Selection sub-option for the Relay Agent Information
              Option for DHCPv4", RFC 3527, April 2003.

   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Option", RFC 4030, March 2005.



Lemon, et al.           Expires January 12, 2012               [Page 21]


Internet-Draft    Relay Agent Encapsulation for DHCPv4         July 2011


   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.

9.2.  Informative References

   [I-D.ietf-dhc-l2ra]
              Joshi, B. and P. Kurapati, "Layer 2 Relay Agent
              Information", draft-ietf-dhc-l2ra-04 (work in progress),
              April 2009.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.


Authors' Addresses

   Ted Lemon
   Nominum, Inc.
   2000 Seaport Blvd
   Redwood City, CA  94063
   USA

   Phone: +1 650 381 6000
   Email: mellon@nominum.com


   Hui Deng
   China Mobile
   53A, Xibianmennei Ave.
   Beijing, Xuanwu District  100053
   China

   Email: denghui@chinamobile.com


   Lu Huang
   China Mobile
   53A, Xibianmennei Ave.
   Xunwu District, Beijing  100053
   China

   Email: huanglu@chinamobile.com








Lemon, et al.           Expires January 12, 2012               [Page 22]


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