DHCP Relay Agent Stacking
draft-zheng-dhc-relay-agent-stacking-00

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

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 April 22, 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.

Abstract

According to RFC 3046, there is only one DHCP Option 82 allowed in a certain DHCP message. This document describes several cases that need more than one Relay Agent to add link information. Proposed method is to have different Relay Agents add multiple DHCP Option 82.

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

Table of Contents

1.  Introduction
2.  Multi-level Access Loop Identification Scenarios
3.  Stacking DHCP Option 82 Syntax
4.  Agent Operation
5.  Applicability
6.  Security Considerations
7.  IANA Consideration
8.  Informative References
§  Authors' Addresses

1.  Introduction

In a typical DSL access network, DHCP Relay Agent Option is used to carry the access loop identification, which identifies the access loop of the user and is useful for troubleshooting and policy management functions. In FTTC/FTTB scenarios of PON system, there are multiple subscribers behind an ONU and both OLT and ONU's slot/port information are needed to identify a use accurately. However, a DHCP Relay Agent does NOT add a "second" relay agent option, when it receives a DHCP packet with a Relay Agent Information option already present from a trusted circuit, according to chapter 2.1 of [RFC3046] (IETF, “DHCP Relay Agent Information Option,” January 2001.).

As described in[draft‑huang‑dhc‑relay‑ps‑00] (IETF, “Line identification in IPv6 Router Solicitation messages,” July  2009.), when a layer 3 switch is installed for a 20 floor building and a layer 2 switch is installed at each floor inside this building, there is a policy delivery problem if only one relay agent inserts access loop identification.

If we define a new sub-option, DHCP Relay Agents appending access loop identification to existing DHCP Option 82 will have to identify the information inserted by other Relay Agents previously, which is complicated. Another reason not to do so, is that some options can't be changed because of the signature. Define a new option x is also a bad choice because of incompatibility with legacy device.

What is proposed is to insert multiple DHCP Option 82 to a DHCP packet. Stacking DHCP Option 82 is much simpler and is able to void the problems mentioned above.

2.  Multi-level Access Loop Identification Scenarios

There are at least two cases where multi-level access loop identification is needed to be carried in DHCP packets.

A typical PON FTTB/FTTC network includes OLT, ONU and ODN, as depicted in figure 1. ONU can be Multi-Dwelling Unit (MDU) or Multi-Tenant Unit (MTU). In this case, ONU provides network access for multiple residential users or multiple business users via DSL or Ethernet typically. In order to locate a user precisely from a DHCP message via Option 82, ONU need add a user's access loop identification on which port the user is attached, while OLT need add PON port where the ONU is attached. Therefore, two DHCP Relay Agents reside in ONU and OLT respectively.

 +---------+
 |AAA      |
 |server   |       /---\                               +-------+
 +---------+     /-/   \\                              |       |----User
           \     |      |                            / |  MDU  |
          +------+      \    +-------+    +-----+  /   |       |----User
          |BRAS  |Layer 2\   |OLT    |    |ODN  |/     +-------+
          |/BNG  |network----|       |----|     |\
          +------+       |   +-------+    +-----+ \   +-------+
             |  |        |                         \  |       |----User
  +--------+ /   \\       |                          \|  MTU  |
  |DHCP    |/     \-------/                           |       |----User
  |server  |                                          +-------+
  +--------+

Another case is cascaded LAN system, which port information of multi-level LAN switches is needed to locate a user. There is more information of this case in[draft‑huang‑dhc‑relay‑ps‑00] (IETF, “Line identification in IPv6 Router Solicitation messages,” July  2009.). Figure 2 depicts an example of this case. Both curb switch and floor switch need add access loop identifier to DHCP Option 82. That means there are two levels of DHCP Relay Agents.

                /--------\
              /-/        \\
              |           \\      +--------+    +--------+
  +------+    |            \\     |        |    |        |----User
  |DHCP  |----| Aggregation \\----|curb    |----|floor   |
  |server|    | network      |    |switch  |    |switch  |
  +------+    |             //    |        |    |        |----User
              \\          /-/     +--------+    +--------+
               \-\       //
                 \-------/

3.  Stacking DHCP Option 82 Syntax

There is no change to the syntax specified in [RFC3046] (IETF, “DHCP Relay Agent Information Option,” January 2001.)(DHCP Relay Agent Information Option) in a Type-Length-Value format.

4.  Agent Operation

A trusted circuit of a DHCP Relay Agent is attached by a trusted downstream (closer to client) network element, which is between the current DHCP Relay Agent and the client. The current DHCP Relay Agent MAY add a DHCP relay agent option but not set the giaddr field. In the case of multi-level DHCP Relay Agent, the current DHCP Relay Agent can add a "second" relay agent option to a DHCP packet that has a DHCP relay agent option which was added by a trusted DHCP Relay Agent attached to the trusted circuit. The DHCP packet will further be forwarded per normal DHCP relay agent operations, setting the giaddr field as it deems appropriate.

A DHCP relay agent adding a Relay Agent Information field SHALL always add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet. When there are multiple DHCP Option 82 in a packet, the options should be arranged in the order of time sequence.

The Relay Agent Information option echoed by a server MUST be removed by either the relay agent or the trusted downstream network element which added it when forwarding a server-to-client response back to the client. If there are multiple DHCP Option 82 in a DHCP packet, Option 82 added previously will become the last option (but before 'End Option' 255, if present) in the DHCP options field after last option82 is striped.

5.  Applicability

Option 82 stacking is practicable in the scenario of multiple Relay Agents between DHCP client and DHCP server. Multiple Relay Agents are especially common in FTTB/FTTC with PON or multi-level switches based access network.

6.  Security Considerations

This document has no security effect on current mechanism in addressing security attacks.

7.  IANA Consideration

No requests to IANA.

8. Informative References

Authors' Addresses