| 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
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.
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 (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.
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.
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.
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 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).
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.
/----------\
| 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|
+--------+
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].
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.
+------+------+ 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 |
\___________________/
+-------------+
___________________|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.
As a reminder, the main requirement from service providers is the following:
These requirements can be fulfilled by a variety of solutions that have their limits. For instance:
Note:
Finally, it is worth mentioning that other standards development organizations consider the use of DHCPv6 Prefix Delegation in particular contexts:
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.
[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 in the control plane, it can get the assigned address or the delegated prefixes directly from the DHCPv6 message. That makes RAAN option unnecessary.
[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.
[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.
The authors would like to acknowledge Mikael Abrahamsson
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4861] | Narten, T., Nordmark, E., Simpson, W. and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. |
| [RFC3633] | Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. |
| [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. |
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:
Prototype implementations.
not sure.
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 | | |
---------- ----
| |
----+------------+--