One document matched: draft-petrescu-relay-route-pd-problem-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-petrescu-relay-route-pd-problem-00.txt"
ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic ipr values:
trust200902, noModificationTrust200902,
noDerivativesTrust200902, or pre5378Trust200902 you can add the
attributes updates="NNNN" and obsoletes="NNNN" they will
automatically be output with "(if approved)" -->
<front>
<title abbrev="DHCPv6 Route Problem at Relay during PD">Route Problem at
Relay during DHCPv6 Prefix Delegation</title>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Leaf Y. Yeh" initials="L." surname="Yeh">
<organization>Freelancer Technologies</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>P. R. China</country>
</postal>
<email>leaf.yeh.sdo@gmail.com</email>
</address>
</author>
<author fullname="Alexandru Petrescu" initials="A." surname="Petrescu">
<organization>CEA</organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country>France</country>
</postal>
<phone></phone>
<email>
Alexandru.Petrescu@cea.fr
</email>
</address>
</author>
<date />
<!-- Meta-data Declarations -->
<area>Internet</area>
<workgroup>Network Working Group</workgroup>
<!-- WG name at the upperleft corner of the doc, IETF is fine for
individual submissions. If this element is not present, the
default is "Network Working Group", which is used by the RFC
Editor as a nod to the history of the IETF. -->
<keyword>DHCPv6 Prefix Delegation, Relay, Route, route
installment</keyword>
<!-- Keywords will be incorporated into HTML output files in a
meta tag but they have no effect on text or nroff output. If
you submit your draft to the RFC Editor, the keywords will be
used for the search engine. -->
<abstract>
<t>
The operation of a prefix delegation procedure with the DHCPv6
protocol may need route setup and maintenance at the
Delegating Router, Requesting Router and on the entity on
which the Relay agent is implemented. This document describes
the problem of routing during DHCPv6 prefix delegation, and is
illustrated by ADSL-type and cellular-type of topologies which
may use Relays; we refer to section 14 of RFC 3633 which
mentions the need of 'a protocol or other out of band
communication to add routing information for delegated
prefixes'. Based on this problem, a number of requirements
from the service providers are described.
</t>
<t>
A small set of documented solutions are separately mentioned
(snooping, route injection, etc.), together with their pros
and cons according to a particular judgment.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The operation of a prefix delegation procedure with the DHCPv6
protocol may need route setup and maintenance at the
Delegating Router, Requesting Router and on the entity on
which the Relay agent is implemented. This document describes
the problem of routing during DHCPv6 prefix delegation, and is
illustrated by ADSL-type and cellular-type of topologies which
may use Relays; we refer to section 14 of RFC 3633 which
mentions the need of 'a protocol or other out of band
communication to add routing information for delegated
prefixes'. Based on this problem, a number of requirements
from the service providers are described.
</t>
<t>
A small set of documented solutions are separately mentioned
(snooping, route injection, etc.), together with their pros
and cons according to a particular judgment.
</t>
</section>
<section title="Terminology">
<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>
<t>
PE router stands for 'Provider Edge' router. It is a router
in the provider's network, situated at its edge. It is
connected directly to the CE router ('Customer's Edge') which
is situated within the customer's network, at its edge.
</t>
</section>
<section title="Problem and the Related Topologies">
<section title="Problem">
<t>
This is a problem mentioned in the context of the
specification of the Relay Agent behaviour, in DHCPv6 Prefix
Delegation <xref target="RFC3633"/>. If the network
topology in which running Prefix Delegation is run involves
a Relay Agent, then the delegating router may need a
protocol or other out-of-band communication to add routing
information for delegated prefixes into any router through
which the requesting router may forward traffic. That
protocol or out-of-band communication are left unspecified.
</t>
<t>
A more detailed interpretation of that problem is described
next.
</t>
<t>
Intuitively, the Prefix Delegation operation consists in a
request and a delegation phase (more precisely, a prefix
allocation is performed by the software in the Server, and
messages such as Solicit/Advertise/Request/Reply are used,
see <xref target="RFC3315"/>). In the request phase, the
Requesting Router requests an IPv6 prefix (not just an IPv6
address). In the delegation phase, the Delegating Router
allocates (reserves) a prefix for use by the Requesting
Router; this prefix is then sent by the Delegating Router to
the Requesting Router.
</t>
<t>
Allocating a prefix is an operation different than
allocating simply an address. In IPv6, one of the
differences relates to the way in which the routing is set
up with respect to the allocated parameter. The routing for
the allocated address is pre-set ((1) the address is part of
a prefix, and the routing is pre-set for that prefix and (2)
the address is allocated by the Server and may be resolved
on-link); whereas the routing for a prefix can not be
pre-set ((1) it is next to impossible to pre-aggregate
several /64 allocated prefixes into a single pre-set /64
prefix and (2) the IP address of the next-hop is not known
at the Server during the prefix allocation phase, being
pre-configured on the Client, and not relayed in the
messages sent by the Relay; yet this address is needed for
route setup). The concepts of numbered and unnumbered
interface may also play a distinctive role.
</t>
<t>
An alternative explanation: in the case of allocating an
address, the routing is pre-set for one particular prefix,
during network setup operation. Due to the imposed length
of the Interface ID on the widely used Ethernet-type of
links, that pre-set prefix has length 64. That particular
prefix covers the entire set of addresses which may be
dynamically allocated by DHCP. On the contrary, dynamically
allocating a prefix does not benefit of this pre-setting of
routing, because of that 64 limit. One can not pre-set a
prefix of length 64 which covers other prefixes of same
length /64. There is thus a need to dynamically set a route
for the allocated prefix (because it is not possible to
pre-set routes for allocated prefixes).
</t>
</section>
<section title="Relay vs. non-Relay Topologies">
<t>
In practice, some topologies may accommodate easily the
deployment of Prefix Delegation, yet other topologies may
pose problems with respect to PD. A topology where the
Requesting Router is a neighbor to the Delegating Router,
and the Requesting Router's default route is the Delegating
Router, may easily accommodate the Prefix Delegation
operation (in this case too, the delegating router needs the
operation of route set-up for network reachability). This
topology is pictured below.
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
/----------\
| Internet |
\----------/
|
+------------+
| Delegating |
| Router |
+------------+
|
+------------+
|Requestting |
| Router |
+------------+
| +--------+
\------------| Host PC|
+--------+
]]>
</artwork>
</figure>
</t>
<t>
On another hand, a topology where the Requesting Router is
not an immediate IP neighbor to the Delegating Router,
and/or RR's default route is not the DR, the operation of
allocating a prefix must necessarily involve an operation of
route set up. This topology is illustrated below.
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
/----------\
| Internet |
\----------/
|
| +------------+
...--------| Delegating |
| | Router |
| +------------+
|
+------------+
| DHCP Relay |
+------------+
|
+------------+
| Requesting |
| Router |
+------------+
| +--------+
\------------| Host PC|
+--------+
]]>
</artwork>
</figure>
</t>
<t>
The operation of Prefix Delegation in the topology
illustrated above needs to provoke the setting up of a route
at the DHCP Relay during the Prefix Delegation operation.
Otherwise, the DHCP Relay will not be able to forward
packets addressed to Host PC (which is configured with an
address in the range of the allocated prefix).
</t>
<t>
This problem statement if related exclusively to the
operation of the Relay Agent and the computer (Router or
Host) on which this Agent runs. These entities are direct
neighbors (in the sense of the Neighbor Discovery protocol)
with the interface on which the Requesting Router emits the
DHCPv6 Request message. On another hand, a similar problem,
is considered in a more generic manner: upon delegation, use
a routing protocol to maintain routing state at Delegating
Routers, at other intermediary routers (for routers not
necessarily direct neighbors to the RR), and at the
Requesting Router; this is described in section 2.3.4 of
<xref target="I-D.stenberg-pd-route-maintenance"/>.
</t>
</section>
<section title='Relay Topologies for Large-scale Deployments'>
<t>
The Figure 1 in <xref target="RFC3633"/> illustrates a
network architecture in which prefix delegation could be
used. That architecture is relating directly to the use of
DSL deployments.
</t>
<t>
The following topologies pertinent for large-scale
deployments are considered. A topology for home
deployments, and a topology of mobile hotspots (tethering
smartphone) are pictured.
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
+------+------+ DHCPv6 Server
| DHCPv6 |
| Server |
| |
+------+------+
|
_________|_________
/ \
| ISP Core Network |
\___________________/
| Network-facing interface
|
+------+------+
| Provider |
| Edge | DHCPv6 Relay Agent, DHCPv6 Requestor
| Router |
+------+------+
| Customer-facing interface
_________|_________
/ \
| Access Network |
\___________________/
|
|
+------+------+
| Customer | DHCPv6 Client
| Edge | DHCPv6-PD Requesting Router
| Router |
+------+------+
|
_________|_________
/ \
| Customer Network |
\___________________/
]]>
</artwork>
</figure>
<figure align="center">
<artwork align="center">
<![CDATA[
+-------------+
___________________|Correspondent|
| | Node |
| +-------------+
/--------\ (peer node, RFC6275)
|Internet|
\--------/
|
/--------\ +------------+
|Cellular|_____________| DHCP Server|
|Network | +------------+
\--------/ Delegating Router
|
+--------+
| Access |
| Router |
| DHCP |
| Relay |
+--------+
|
cellular radio link
|
+-----------+
| Tethering | Requesting
| Smartphone| Router
+-----------+
| +-----------+
|-- wifi ---| 'tethered'|
| PC |
+-----------+
]]>
</artwork>
</figure>
</t>
<t>
In the above figure, the cellular network is considered to be
similar to an ISP network.
</t>
</section>
</section>
<section title="Issues and Requirements">
<t>
As a reminder, the main requirement from service providers is the
following:
</t>
<t>
<list style="symbols">
<t>
Need for deterministic and dynamic means to drive route
aggregates and associated route announcement actions to
be undertaken by PE routers while ensuring a consistency
with prefix assignment states. In particular:
<list style="symbols">
<t>
Optimizing the size of routing and forwarding tables
must be supported. As such, route aggregation must
be supported by these routers.
</t>
<t>
Failures to deliver incoming packets to a customer
serviced behind a given PE router must be
avoided. Dedicated routing actions must be achieved
to ensure incoming traffic will be forwarded to the
appropriate customer's device. Nevertheless,
triggers to drive the level of route aggregation and
required route announcement actions must be
supported.
</t>
<t>
Prefix assignments and routing actions must be
correlated otherwise delivery of connectivity
service will fail.
</t>
</list>
</t>
</list>
</t>
<t>
These requirements can be fulfilled by a variety of
solutions that have their limits. For instance:
</t>
<t>
<list style="symbols">
<t>
Current practices rely on static configuration. This
practice is prone to errors.
</t>
<t>
The level of route aggregation cannot be driven by PE
routers without any hint(s) from an entity that has the
visibility on aggregation policies and the status of
prefixes, etc.
</t>
<t>
Relying on proprietary means to trigger the injection of
routing entries may lead to undesired behavior: increase
the size of routing table and forwarding table due to
injecting very specific routes, etc.
</t>
</list>
</t>
<t>
Note:
</t>
<t>
<list style="symbols">
<t>
Prefix assignment policies can be configured to DHCP
servers including topological aware considerations
(e.g., regional-based assignment, per-service
assignment, etc.). Refer to Section 4 of <xref
target="I-D.lemon-dhc-topo-conf"/>.
</t>
<t>
Status of active (prefix) states is maintained by DHCP
servers.
</t>
<t>
The use of DHCP for this purpose does not require an
additional interface to pass the state maintained by the
DHCP server to a routing controller which will then
undertake appropriate actions.
</t>
</list>
</t>
<t>
Finally, it is worth mentioning that other standards
development organizations consider the use of DHCPv6 Prefix
Delegation in particular contexts:
<list style="symbols">
<t>
at the Broadband Forum ('BBF'), a technical report titled
"IPv6 in the context of TR-101", dated November 2010,
<xref target="bf"/>, lists a number of requirements
derived from the problem that "hosts receiving IPv6
addresses from the RR are not known to the BNG, i.e. the
BNG is not aware of what addresses/prefixes are assigned
to hosts attached to the RG acting as RR."
</t>
<t>
at 3GPP, the specification <xref target="3gpp-ref"/>
describes the use of DHCPv6 prefix delegation using S2c.
It is for a "User Equipment acting as a Mobile Router".
</t>
</list>
</t>
</section>
<section title="Potential Solutions, Solution Space">
<t></t>
<section title="DHCPv6 message snooping for PD-prefix">
<t>
The Provider Edge (PE) router acting as relay snoops every
reply message from the server with valid lease. Per the
parameters, such as valid-lifetime and preferred-lifetime,
shown the IA_PD option, PE router knows the lease of each
delegated prefix. Then the PE can add and withdraw the
associated route per the lease of each delegated prefix.
</t>
<t>
Pros: no new messages and options defined, no additional
function on the relay.
</t>
<t>
Cons: but PE router need to snoop each DHCPv6-PD message,
then take action for routing per the lease of each delegated
prefix.
</t>
<t>
In the real deployed network, PE router always need to
handle each protocol message in the control plane including
DHCPv6 message. That makes snooping sounds not a problem for
PE router. Almost every implementation of PE router today in
the Telecom's network adopts the method of snooping to get
the lease of each delegated prefix.
</t>
</section>
<section title="ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix">
<t>
<xref target="I-D.ietf-dhc-dhcpv6-agentopt-delegate"/>.
</t>
<t>
The relay use OPTION_ORO to request the assigned address or
the delegated prefixes for the client from the server. But
the draft has not mentioned in which DHCPv6 message the
OPTION_ORO will always be employed.
</t>
<t>
Pros: no new messages, just define a new RAAN option
(OPTION_AGENT_NOTIFY) to convey OPTION_IAADDR and
OPTION_IAPREFIX, sounds it can de-couple with the DHCPv6-PD
mechanism.
</t>
<t>
Cons: sounds only for the route @ relay (or PE
router) co-related with the delegated prefix, have no route
aggregation.
</t>
<t>
Due to PE router need to interpret and handle each protocol
message in the control plane, it can get the assigned
address or the delegated prefixes directly from the DHCPv6
message. That makes RAAN option unnecessary.
</t>
</section>
<section title="draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for
prefix pool of PD">
<t>
<xref target="I-D.ietf-dhc-dhcpv6-prefix-pool-opt"/>.
</t>
<t>
PE router acting as relay use OPTION_ORO in the
relay-forward of DHCPv6-PD message to request the
information about the prefix pool (and its status). After the
PE got the OPTION_PREFIX_POOL in the Relay-reply message, it
can add the aggregation route per the status (or lease) of
the prefix pool. The aggregation route can dramatically
reduce the size of the routing table in the ISP network.
</t>
<t>
Pros: no new messages, just define a new option
(OPTION_PREFIX_POOL) to convey the information about prefix
pools.
</t>
<t>
Cons: lightweight but piggyback on the UDP-based DHCPv6
message.
</t>
<t>
This draft hasn't achieve Consensus yet, but may need to
simplify the mechanism to gain more support.
</t>
</section>
<section title="draft-joshi-dhc-dhcpv6-aggr-route-opt for
aggregation route of PD">
<t>
<xref target="I-D.joshi-dhc-dhcpv6-aggr-route-opt"/>
</t>
<t>
PE router acting as relay tries to employ new messages
exchange between relay and server, including new function of
information-request, renew and reply, reconfigure. That make
the communication between the relay and server to be the
communication between hosts.
</t>
<t>
Pros: de-coupled from the DHCPv6-PD mechanism, communication
between hosts could employ the reliable TCP.
</t>
<t>
Cons: introduce new functionality defined for the relay and
server, define new messages and option (OPTION_AGGR_ROUTE),
have problem of synchronization for the status of
aggregation route or for the leases of delegated prefixes.
</t>
<t>
This draft may be incomplete work, maybe further discussion
may be needed.
</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to acknowledge Mikael Abrahamsson</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633"
?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315"
?>
</references>
<references title="Informative References">
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.lemon-dhc-topo-conf'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-agentopt-delegate'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-prefix-pool-opt'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.joshi-dhc-dhcpv6-aggr-route-opt'?>
<?rfc
include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.stenberg-pd-route-maintenance'?>
<reference anchor="bf" >
<front>
<title>
Broadband Forum, Technical Report, TR-177, "IPv6 in the
Context of TR-101, Issue: 1, Issue date: November 2010",
document freely available at the URL
http://www.broadband-forum.org/technical/download/TR-177.pdf
accessed on October 4th, 2013.
</title>
<author/>
<date/>
</front>
</reference>
<reference anchor="3gpp-ref" >
<front>
<title>
3GPP TS 23.402 V12.2.0 (2013-09), Technical Specification,
3rd Generation Partnership Project; Technical
Specification Group Services and System Aspects;
Architecture enhancements for non-3GPP accesses (Release
12),
http://www.3gpp.org/ftp/Specs/archive/23_series/23.402/23402-c20.zip
accessed on October 7th, 2013
</title>
<author/>
<date/>
</front>
</reference>
</references>
<section anchor="changelog" title="ChangeLog">
<t>The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.</t>
<t>From draft-relay-route-pd-problem-00.txt to
draft-authors-relay-route-pd-problem-00.txt: <list style="symbols">
<t>first version.</t>
</list></t>
</section>
<section title="Software">
<t>
Prototype implementations.
</t>
</section>
<section title="draft-stenberg-pd-route-maintenance-00">
<t></t>
</section>
<section title="Snooping only">
<t>not sure.</t>
</section>
<section title="ICMP Redirect">
<t>
One possible solution to inform an entity in the network
about a better route to a destination is to use the message
ICMPv6 Redirect, as specified in <xref target="RFC4861"/>.
This message is used by Routers to inform hosts about better
routes.
</t>
<t>
Some DHCPv6 Prefix Delegation deployments consider that the
DHCPv6 Relay functionality is co-located within a Router.
In this case, it is not possible to use the ICMP Redirect
message.
</t>
<t>
However, in other possible deployments, the DHCPv6 Relay
functionality is co-located in a Host; in this case the use
of ICMPv6 Redirect may be possible. An example topology of
this use of DHCP Relay on a Host is depicted in the
following figure:
</t>
<t>
<figure align="center">
<artwork align="center">
<![CDATA[
________ ----------
| |DHCPServer|
... ----------
|
---------- ---------
| Host | | Access |
| DHCPRelay| | Router |
---------- ---------
| |
----+--------------+
|
---------- ----
|Requesting| | PC |
| Router | | |
---------- ----
| |
----+------------+--
]]>
</artwork>
</figure>
</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 14:38:39 |