One document matched: draft-zheng-dhc-relay-agent-stacking-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>
<?rfc strict="yes" ?>
<rfc category="std" docName="draft-zheng-dhc-relay-agent-stacking-00"
ipr="pre5378Trust200902">
<front>
<title abbrev="Option 82 stacking">DHCP Relay Agent Stacking</title>
<author fullname="Ruobin Zheng" initials="R." surname="Zheng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86-755-28972352</phone>
<email>robin@huawei.com</email>
<uri></uri>
</address>
</author>
<author fullname="Hongyu Li" initials="H." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86-755-28973567</phone>
<facsimile></facsimile>
<email>lihy@huawei.com</email>
<uri></uri>
</address>
</author>
<author fullname="Zhongjian Zhang" initials="Z." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<city>Shenzhen</city>
<region></region>
<code></code>
<country>China</country>
</postal>
<phone>+86-755-28978503</phone>
<facsimile></facsimile>
<email>zhangzhongjian@huawei.com</email>
<uri></uri>
</address>
</author>
<date month="October" year="2009" />
<area>Internet Area</area>
<!-- Using the acronym to keep idnits happy
<workgroup>Source Address Validation Improvements</workgroup>
-->
<workgroup>Dynamic Host Configuration WG</workgroup>
<keyword>option 82</keyword>
<keyword>stacking</keyword>
<keyword>Relay Agent Option</keyword>
<keyword>DHCP</keyword>
<abstract>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section anchor="Intro" title="Introduction">
<t>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 <xref
target="RFC3046"></xref>.</t>
<t>As described in<xref target="draft-huang-dhc-relay-ps-00"></xref>,
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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section anchor="Design"
title="Multi-level Access Loop Identification Scenarios">
<t>There are at least two cases where multi-level access loop
identification is needed to be carried in DHCP packets.</t>
<t>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.</t>
<t><figure anchor="PON" title="FTTB/FTTC network with PON">
<artwork><![CDATA[
+---------+
|AAA |
|server | /---\ +-------+
+---------+ /-/ \\ | |----User
\ | | / | MDU |
+------+ \ +-------+ +-----+ / | |----User
|BRAS |Layer 2\ |OLT | |ODN |/ +-------+
|/BNG |network----| |----| |\
+------+ | +-------+ +-----+ \ +-------+
| | | \ | |----User
+--------+ / \\ | \| MTU |
|DHCP |/ \-------/ | |----User
|server | +-------+
+--------+
]]></artwork>
</figure></t>
<t>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<xref
target="draft-huang-dhc-relay-ps-00"></xref>. 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.</t>
<t><figure anchor="LAN" title="Cascaded LAN access system">
<artwork><![CDATA[
/--------\
/-/ \\
| \\ +--------+ +--------+
+------+ | \\ | | | |----User
|DHCP |----| Aggregation \\----|curb |----|floor |
|server| | network | |switch | |switch |
+------+ | // | | | |----User
\\ /-/ +--------+ +--------+
\-\ //
\-------/
]]></artwork>
</figure></t>
</section>
<section anchor="specification" title="Stacking DHCP Option 82 Syntax">
<t>There is no change to the syntax specified in <xref
target="RFC3046"></xref>(DHCP Relay Agent Information Option) in a
Type-Length-Value format.</t>
</section>
<section title="Agent Operation">
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Applicability">
<t>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.</t>
</section>
<section title="Security Considerations">
<t>This document has no security effect on current mechanism in
addressing security attacks.</t>
</section>
<section title="IANA Consideration">
<t>No requests to IANA.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!---->
<reference anchor="draft-huang-dhc-relay-ps-00"
target="http://tools.ietf.org/id/draft-krishnan-6man-rs-mark-03.txt">
<front>
<title>Line identification in IPv6 Router Solicitation
messages</title>
<author>
<organization>IETF</organization>
</author>
<date month="July " year="2009" />
</front>
<format type="txt" />
</reference>
<reference anchor="RFC3046"
target="http://tools.ietf.org/rfc/rfc3046.txt">
<front>
<title>DHCP Relay Agent Information Option</title>
<author>
<organization>IETF</organization>
</author>
<date month="January" year="2001" />
</front>
<format type="txt" />
</reference>
<reference anchor="RFC2119"
target="http://tools.ietf.org/rfc/rfc2119.txt">
<front>
<title></title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 17:05:22 |