Internet DRAFT - draft-petrescu-relay-route-pd-problem
draft-petrescu-relay-route-pd-problem
Network Working Group M. Boucadair
Internet-Draft France Telecom
Intended status: Informational L. Yeh
Expires: April 24, 2014 Freelancer Technologies
A. Petrescu
CEA
October 21, 2013
Route Problem at Relay during DHCPv6 Prefix Delegation
draft-petrescu-relay-route-pd-problem-00.txt
Abstract
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.
A small set of documented solutions are separately mentioned
(snooping, route injection, etc.), together with their pros and cons
according to a particular judgment.
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 April 24, 2014.
Copyright Notice
Boucadair, et al. Expires April 24, 2014 [Page 1]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
Copyright (c) 2013 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Problem and the Related Topologies . . . . . . . . . . . . . . 3
3.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Relay vs. non-Relay Topologies . . . . . . . . . . . . . . 4
3.3. Relay Topologies for Large-scale Deployments . . . . . . . 6
4. Issues and Requirements . . . . . . . . . . . . . . . . . . . 8
5. Potential Solutions, Solution Space . . . . . . . . . . . . . 10
5.1. DHCPv6 message snooping for PD-prefix . . . . . . . . . . 10
5.2. ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix . . . . . 10
5.3. draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix
pool of PD . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. draft-joshi-dhc-dhcpv6-aggr-route-opt for aggregation
route of PD . . . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Software . . . . . . . . . . . . . . . . . . . . . . 13
Appendix C. draft-stenberg-pd-route-maintenance-00 . . . . . . . 13
Appendix D. Snooping only . . . . . . . . . . . . . . . . . . . . 13
Appendix E. ICMP Redirect . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Boucadair, et al. Expires April 24, 2014 [Page 2]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
1. Introduction
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.
A small set of documented solutions are separately mentioned
(snooping, route injection, etc.), together with their pros and cons
according to a particular judgment.
2. 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 [RFC2119].
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.
3. Problem and the Related Topologies
3.1. Problem
This is a problem mentioned in the context of the specification of
the Relay Agent behaviour, in DHCPv6 Prefix Delegation [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.
A more detailed interpretation of that problem is described next.
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
Boucadair, et al. Expires April 24, 2014 [Page 3]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
Solicit/Advertise/Request/Reply are used, see [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.
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.
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).
3.2. Relay vs. non-Relay Topologies
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.
Boucadair, et al. Expires April 24, 2014 [Page 4]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
/----------\
| Internet |
\----------/
|
+------------+
| Delegating |
| Router |
+------------+
|
+------------+
|Requestting |
| Router |
+------------+
| +--------+
\------------| Host PC|
+--------+
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.
/----------\
| Internet |
\----------/
|
| +------------+
...--------| Delegating |
| | Router |
| +------------+
|
+------------+
| DHCP Relay |
+------------+
|
+------------+
| Requesting |
| Router |
+------------+
| +--------+
\------------| Host PC|
+--------+
Boucadair, et al. Expires April 24, 2014 [Page 5]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
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).
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
[I-D.stenberg-pd-route-maintenance].
3.3. Relay Topologies for Large-scale Deployments
The Figure 1 in [RFC3633] illustrates a network architecture in which
prefix delegation could be used. That architecture is relating
directly to the use of DSL deployments.
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.
Boucadair, et al. Expires April 24, 2014 [Page 6]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
+------+------+ 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 |
\___________________/
Boucadair, et al. Expires April 24, 2014 [Page 7]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
+-------------+
___________________|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 |
+-----------+
In the above figure, the cellular network is considered to be similar
to an ISP network.
4. Issues and Requirements
As a reminder, the main requirement from service providers is the
following:
o 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:
* Optimizing the size of routing and forwarding tables must be
supported. As such, route aggregation must be supported by
Boucadair, et al. Expires April 24, 2014 [Page 8]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
these routers.
* 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.
* Prefix assignments and routing actions must be correlated
otherwise delivery of connectivity service will fail.
These requirements can be fulfilled by a variety of solutions that
have their limits. For instance:
o Current practices rely on static configuration. This practice is
prone to errors.
o 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.
o 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.
Note:
o 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
[I-D.lemon-dhc-topo-conf].
o Status of active (prefix) states is maintained by DHCP servers.
o 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.
Finally, it is worth mentioning that other standards development
organizations consider the use of DHCPv6 Prefix Delegation in
particular contexts:
o at the Broadband Forum ('BBF'), a technical report titled "IPv6 in
the context of TR-101", dated November 2010, [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
Boucadair, et al. Expires April 24, 2014 [Page 9]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
is not aware of what addresses/prefixes are assigned to hosts
attached to the RG acting as RR."
o at 3GPP, the specification [3gpp-ref] describes the use of DHCPv6
prefix delegation using S2c. It is for a "User Equipment acting
as a Mobile Router".
5. Potential Solutions, Solution Space
5.1. DHCPv6 message snooping for PD-prefix
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.
Pros: no new messages and options defined, no additional function on
the relay.
Cons: but PE router need to snoop each DHCPv6-PD message, then take
action for routing per the lease of each delegated prefix.
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.
5.2. ietf-dhc-dhcpv6-agentopt-delegate for PD-prefix
[I-D.ietf-dhc-dhcpv6-agentopt-delegate].
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.
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.
Cons: sounds only for the route @ relay (or PE router) co-related
with the delegated prefix, have no route aggregation.
Due to PE router need to interpret and handle each protocol message
Boucadair, et al. Expires April 24, 2014 [Page 10]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
in the control plane, it can get the assigned address or the
delegated prefixes directly from the DHCPv6 message. That makes RAAN
option unnecessary.
5.3. draft-ietf-dhc-dhcpv6-prefix-pool-opt-03 for prefix pool of PD
[I-D.ietf-dhc-dhcpv6-prefix-pool-opt].
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.
Pros: no new messages, just define a new option (OPTION_PREFIX_POOL)
to convey the information about prefix pools.
Cons: lightweight but piggyback on the UDP-based DHCPv6 message.
This draft hasn't achieve Consensus yet, but may need to simplify the
mechanism to gain more support.
5.4. draft-joshi-dhc-dhcpv6-aggr-route-opt for aggregation route of PD
[I-D.joshi-dhc-dhcpv6-aggr-route-opt]
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.
Pros: de-coupled from the DHCPv6-PD mechanism, communication between
hosts could employ the reliable TCP.
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.
This draft may be incomplete work, maybe further discussion may be
needed.
6. Security Considerations
Boucadair, et al. Expires April 24, 2014 [Page 11]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
7. IANA Considerations
8. Acknowledgements
The authors would like to acknowledge Mikael Abrahamsson
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
9.2. Informative References
[3gpp-ref]
"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".
[I-D.ietf-dhc-dhcpv6-agentopt-delegate]
Droms, R., Volz, B., and O. Troan, "DHCPv6 Relay Agent
Assignment Notification (RAAN) Option",
draft-ietf-dhc-dhcpv6-agentopt-delegate-04 (work in
progress), July 2009.
[I-D.ietf-dhc-dhcpv6-prefix-pool-opt]
leaf.yeh.sdo@gmail.com, l., Lemon, T., and M. Boucadair,
"Prefix Pool Option for DHCPv6 Relay Agent on the Provider
Edge Routers", draft-ietf-dhc-dhcpv6-prefix-pool-opt-03
(work in progress), April 2013.
Boucadair, et al. Expires April 24, 2014 [Page 12]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
[I-D.joshi-dhc-dhcpv6-aggr-route-opt]
Joshi, S., "Aggregate Route Option for Dynamic Host
Control Protocol version 6 (DHCPv6)",
draft-joshi-dhc-dhcpv6-aggr-route-opt-01 (work in
progress), September 2011.
[I-D.lemon-dhc-topo-conf]
Lemon, T., "Customizing DHCP Configuration on the Basis of
Network Topology", draft-lemon-dhc-topo-conf-01 (work in
progress), April 2013.
[I-D.stenberg-pd-route-maintenance]
Stenberg, M. and O. Troan, "IPv6 Prefix Delegation routing
state maintenance approaches",
draft-stenberg-pd-route-maintenance-00 (work in progress),
October 2006.
[bf] "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.".
Appendix A. ChangeLog
The changes are listed in reverse chronological order, most recent
changes appearing at the top of the list.
From draft-relay-route-pd-problem-00.txt to
draft-authors-relay-route-pd-problem-00.txt:
o first version.
Appendix B. Software
Prototype implementations.
Appendix C. draft-stenberg-pd-route-maintenance-00
Appendix D. Snooping only
not sure.
Boucadair, et al. Expires April 24, 2014 [Page 13]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
Appendix E. ICMP Redirect
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 [RFC4861]. This message is used by Routers to inform
hosts about better routes.
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.
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:
________ ----------
| |DHCPServer|
... ----------
|
---------- ---------
| Host | | Access |
| DHCPRelay| | Router |
---------- ---------
| |
----+--------------+
|
---------- ----
|Requesting| | PC |
| Router | | |
---------- ----
| |
----+------------+--
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange.com
Boucadair, et al. Expires April 24, 2014 [Page 14]
Internet-Draft DHCPv6 Route Problem at Relay during PD October 2013
Leaf Y. Yeh
Freelancer Technologies
P. R. China
Email: leaf.yeh.sdo@gmail.com
Alexandru Petrescu
CEA
France
Phone:
Email: Alexandru.Petrescu@cea.fr
Boucadair, et al. Expires April 24, 2014 [Page 15]
