Network Working Group W. Dec Internet-Draft R. Johnson Intended status: Informational Cisco Systems Expires: September 4, 2009 March 3, 2009 DHCPv6 Route Option draft-dec-dhcpv6-route-option-01 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 4, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document describes the DHCPv6 Route Option for provisioning static IPv6 routes on a DHCPv6 client..This improves the ability of an operator to configure and influence the client to pick an Dec & Johnson Expires September 4, 2009 [Page 1] Internet-Draft DHCPv6 Route Option March 2009 appropriate route to a destination when the client is multi-homed to routers and where other means of route configuration may be impractical. It is primarily envisaged for implementation on a DHCP client stack of a broadband Residential Gateway (RG) node. Requirements Language 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Route Option . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Appearance of the option in DHCP messages . . . . . . . . . 5 4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 6 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Dec & Johnson Expires September 4, 2009 [Page 2] Internet-Draft DHCPv6 Route Option March 2009 1. Introduction The Neighbor Discover protocol [RFC2461] provides a mechanism allowing hosts to discover one or more default router. Extensions to the protocol defined in [RFC4191]allow the discovery by a host of the preferences for multiple default routers as well as more specific routes, which allows network administrators to better handle multi- homed host topologies. This mechanism falls short in a few network and operational scenarios that are in existence today and where a DHCP approach is seen to be preferable. This document describes the DHCPv6 Route Option for provisioning static IPv6 routes by a DHCPv6 client. It is primarily envisaged for implementation on a DHCP client stack of a broadband Residential Gateway (RG) node. 2. Motivation The first motivational scenario is when the network administrator needs to dynamically provision static routes from a centrally managed repository and on only a subset of hosts or nodes that are connected to a multi-access network segment (e.g. a shared VLAN). This need is often driven by operational necessities, such as moving a small group of users or performing maintenance on service routers on this network segment while using a centrally managed configuration repository. A second scenario is when administrative boundaries between network operational groups inhibit or prevent the modification of the configuration of routers that are attached to the end host or end- node network segment. This is today often found to be the case in Layer 3 wholesale set-ups, or where an operator has multiple operational groups whose collaboration is some way inhibited. Both of these scenarios apply to residential broadband triple-play architectures of today, where the host or end-node is otherwise known as a Residential Gateway (RG) The RG may be connected via a shared VLAN to more than one Network Access Servers (NASes), each of which is intended for the delivery of a particular type of service that is distinguished by means of IP addresses. It sometimes is also the case that the RG is connected by means of two or more links, each link to a different NAS and where the NASes belong to different operators or administrative domains. The basic dynamic provisioning of RGs is often administered centrally and effected by means of DHCP and no IGPs are used for affecting the RGs routing decisions. The figures below depict two scenarios with one or more RG connected to different NASes acting as gateways to services S1 and S2.. Dec & Johnson Expires September 4, 2009 [Page 3] Internet-Draft DHCPv6 Route Option March 2009 +---NAS-S1 ---------NAS-S1 | / RG1----+ RG | \ RG2----+ ---------NAS-S2 | +---NAS-S2 Figure 1 Figure 2 RGs with a shared multi-access Multi homed RG segment In the context of these scenarios and today's IPv4 deployments, the problem of selecting a NAS in terms of routing from the RG is solved by the provisioning of one or more specific static routes on the RG. Each route points to the desired IP service subnet and the corresponding NAS as the next hop. Dynamic IGP routing protocols are deemed to incur an substantial overhead in terms of equipment costs and operational challenges to the operator, without providing a clear benefit given that the route to a service generally is trivial and only has one valid next hop. Hence, in order to assist the automated provisioning of such more specific routes on the RGs use is made of a DHCPv4 mechanism for disseminating classless route information as defined in[RFC3442]. In the context of an IPv6 deployment and where the [RFC4191] mechanism may not be put into action due to operational challenges described, the scenarios call for an analogous dynamic host configuration method by which route configuration can be effected on the RGs without direct manipulation of the NAS routers attached to the RG's network segment. This translates into a DHCPv6 route option equivalent to the one defined for DHCPv4. The adoption of such a DHCPv6 extension by an operator already using the DHCPv4 equivalent has the added benefit of integrating more efficiently in existing operational practices. 3. Route Option The server sends the Route Option to a client to covey one or more IPv6 routes. Each IPv6 route consists of an IPv6 prefix of a declared bit length and a next hop IPv6 address for the prefix. Multiple routes can be present in a single option. The complete option is octet aligned by padding with 0s to the last octet boundary. Dec & Johnson Expires September 4, 2009 [Page 4] Internet-Draft DHCPv6 Route Option March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Length | Prefix (variable length) | +-+-+-+-+-+-+-+-+ . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Next Hop Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ROUTE (TBD). option-len 17 + Length of the Prefix field in full octets (includes any padding). Prefix Length 8-bit unsigned integer. The length in bits of the IP Prefix, which also represents the number of leading bits in the prefix. The value ranges from 0 to 128. Prefix Variable-length field containing the IP Prefix. IPv6 Next Hop Address The 128 bit IPv6 address of the next hop to be used when forwarding towards the IP Prefix. 3.1. Appearance of the option in DHCP messages The Route option MUST NOT appear in the following DHCP messages: Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. A single option can be used to covey multiple routes by means of successively inserting additional combinations of the prefix and next hop field. The example below illustrates how two routes, consisting of Prefix A and Prefix B with two different next hop addresses Next Hop 1 and Next Hop 2 respectively, can be conveyed within a single option. Dec & Johnson Expires September 4, 2009 [Page 5] Internet-Draft DHCPv6 Route Option March 2009 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ROUTE | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix A Length| Prefix A (variable length) | +-+-+-+-+-+-+-+-+ . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Next Hop Address 1 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Prefix B Length| Prefix B (variable length) | +-+-+-+-+-+-+-+-+ . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Next Hop Address 2 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4. DHCP Client Behavior A client compliant with this specification SHOULD request the Route option (option value TBD) in an Options Request Option (ORO) as described in [RFC3315] by including the Route options' code in the following messages: Solicit, Request, Renew, Rebind, Information- Request and Reconfigure. If more than one route option appears in a message, the client MUST process the contents of these options in the same way it would if the payload of each option were concatenated together and processed as a single option. The client is free to choose the order in which it processes individual route options according to its convenience. If the same prefix appears more than once either in a single route option or a series of route options, with different values for next- hop, the client SHOULD install separate routes in the routing table for that prefix, one for each distinct value of next-hop. When processing the Route option a client MUST substitute a 0::0 IP next hop address with the source IP address of the received DHCP message. This is useful in cases where the DHCP server operator Dec & Johnson Expires September 4, 2009 [Page 6] Internet-Draft DHCPv6 Route Option March 2009 would like the client to use as a next hop the source IP address of an intermediate DHCP relay agent, whose address is used in packets relayed to the client, without the need of identifying this address explicitly. DHCP clients that support the Route Option are expected to use the information in selecting the forwarding path, however the method by which the preferred path is selected is not part of this specification. In terms of all other behaviour, such as the behaviour upon the re- establishment of a link or the failure to communicate with a DHCP server, the client is assumed to follow [RFC3315]. 5. DHCP Server Behavior A server MAY send a client the Route Option if the server is configured to do so. The server SHOULD support sending the option as part of other DHCP options where such a possibility exists, for example when sending the route option as part of an IA_NA or IA_PD option set. 6. IANA Considerations IANA has assigned a DHCPv6 option number of TBD for the "Route Option" 7. Security Considerations The overall security considerations discussed in [RFC3315] apply also to this document. The Route option could be used by malicious parties to misdirect traffic sent by the client either as part of a denial of service or man-in-the-middle attack. An alternative denial of service attack could also be realized by means of using the route option to overflowing any known memory limitations of the client, or to exceed the client's ability to handle the number of next hop addresses. Neither of the above considerations are new and specific to the proposed route option. The mechanisms identified for securing DHCPv6 as well as reasonable checks performed by host implementations are deemed sufficient in addressing these problems. Dec & Johnson Expires September 4, 2009 [Page 7] Internet-Draft DHCPv6 Route Option March 2009 8. Acknowledgements The authors would like to thank Ralph Droms, Ted Lemon, Dave Oran and Dave Ward for their comments and useful suggestions. 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. 9.2. Informative References [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Authors' Addresses Wojciech Dec Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Email: wdec@cisco.com Dec & Johnson Expires September 4, 2009 [Page 8] Internet-Draft DHCPv6 Route Option March 2009 Richard Johnson Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Phone: Fax: Email: raj@cisco.com Dec & Johnson Expires September 4, 2009 [Page 9]