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]