Network Working Group W. Dec Internet-Draft R. Johnson Intended status: Standards Track Cisco Systems Expires: January 13, 2011 T. Mrugalski Gdansk University of Technology A. Matsumoto NTT PF Lab July 12, 2010 DHCPv6 Route Options draft-dec-dhcpv6-route-option-04 Abstract This document describes the DHCPv6 Route Options for provisioning IPv6 routes on a DHCPv6 client. This is expected to improve the ability of an operator to configure and influence a client's ability to pick an appropriate route to a destination when this client is multi-homed and where other means of route configuration may be impractical. The options are primarily envisaged for configuring a broadband Residential Gateway (RG) router, but are generic enough to be used by other types of DHCPv6 clients that have basic host routing capabilities. 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]. 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 January 13, 2011. Dec, et al. Expires January 13, 2011 [Page 1] Internet-Draft DHCPv6 Route Options July 2010 Copyright Notice Copyright (c) 2010 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. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3 3. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 5 3.1. Options Extensibility . . . . . . . . . . . . . . . . . . 5 3.2. Relation To Other Configuration Methods . . . . . . . . . 6 4. DHCPv6 Options Format . . . . . . . . . . . . . . . . . . . . 6 4.1. DHCPv6 Route Option Format . . . . . . . . . . . . . . . . 6 4.2. Next Hop Option Format . . . . . . . . . . . . . . . . . . 7 4.3. Route Prefix Option Format . . . . . . . . . . . . . . . . 8 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 10 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Dec, et al. Expires January 13, 2011 [Page 2] Internet-Draft DHCPv6 Route Options July 2010 1. Introduction The Neighbor Discovery protocol [RFC4861] provides a mechanism for hosts to discover one or more default routers on a directly connected network segment. Extensions to the protocol defined in [RFC4191] allow the discovery by such hosts of the preferences for multiple default routers as well as more specific routes advertised by these routers. This allows network administrators to better handle multi- homed host topologies and influence the route selection by the host. This mechanism however is sub optimal or impractical in multi-homing scenarios that are in existence today. These scenarios are broadly presented in detail in [I-D.troan-multihoming-without-nat66], with this document focusing on a specific aspect identified therein, namely the ability to dynamically provision select multi-homed devices with specific IPv6 routes. This draft defines the DHCPv6 Route Option for provisioning IPv6 routes on a DHCPv6 client. The proposed option is primarily envisaged for use by a class of IPv6 routers known as a broadband Residential Gateway (RG), found in Digital Subscriber Line (DSL), Cable, and Fibre To The Home (FTTH) environments. It is however generic enough to be used by other types of advanced DHCPv6 clients that are have basic IPv6 routing capabilities. It is assumed that such a client is capable of making basic IP routing decisions and maintaining a simple IPv6 routing table, in line with the capabilities of a host, as described in [RFC4191]. Throughout the document the words RG and client are used as a reference to the device with routing capabilities, hosting the DHCPv6 client software. 2. Problem overview The following exemplary scenario is used to illustrate the problem as found in residential broadband networks. It is duly noted that the problem is not specific to IPv6, occurring also with IPv4, where it is today solved by means of DHCPv4 or remote configuration mechanisms. In residential broadband networks, a given user's routed Residential Gateway (RG) may be connected to more than one Network Access Servers (NAS). Such connectivity may be realized by means of dedicated physical or logical links from the RG to each NAS (e.g. Using dedicated physical interfaces, or multiple PPP links, or Ethernet VLANs that may also be shared with the RGs of other users). In either case a given NAS is intended by the network operator for the delivery of a particular type of IP service, where the service can be Dec, et al. Expires January 13, 2011 [Page 3] Internet-Draft DHCPv6 Route Options July 2010 characterised by means of specific destination IP network prefixes. Thus, from an IP routing perspective in order for the RG to select the appropriate NAS router as the gateway for a given destination IP prefix, recourse needs to be made to classic longest destination match IP routing, with the RG learning the relevant prefixes. An issue however is the fact that common dynamic Internal Gateway Protocols (IGPs) are rarely used by operators for conveying dynamic route information to RGs. This is due to operational reasons and a desire to contain the complexity of RGs and IP Edge devices to a minimum. A preferred mechanism adopted for IPv4 is one of dynamically provisioning RGs when these connect to the network, which can be done using the DHCPv4 classless route information option [RFC3442]. Figure 1 illustrates the case of a single RG connected via two links to NAS Routers 1 and 2 respectively. NAS Router 1 is the intended gateway for a specific application served from ServerA (e.g. VoIP or NMS) whose IP subnet is otherwise not reachable via NAS Router2. The latter NAS is intended to provide connectivity to an Internet service, and could belong to a different operator as Router 1. Regular hosts, such as PCs or other end-user devices, are assumed to be connected to the Home LAN network fronted by the RG. These hosts are assumed to have the capacity to perform the correct source and destination address selection when accessing each of the services. ----Router1------ServerA / (Home)----RG-1 \ ----Router2------Internet Figure 1: Example use case. To obtain the desired routing behaviour RG-1 needs to have a more specific IP route towards the target service subnet accessible via Router1, leaving Router2 as the default gateway for all other destinations. To achieve this the ICMPv6 [RFC4191] mechanism does provide a solution, however it entails a number of limitations. Firstly, the operator has no assurance that the RG is actually capable of correctly interpreting the [RFC4191] route options, since the RG is unable to signal such capability, nor that each NAS in the network is capable of generating such messages. Secondly, the mechanism is applicable only in cases when the operator is willing to apply and maintain per subscriber/RG configuration directly on NAS Routers 1 and 2, which is often either administratively difficult or impossible in cases where the NASes are operated by a 3rd party. Thirdly, the mechanism presents an operational and troubleshooting challenge in cases where the IPv6 service is offered alongside IPv4, Dec, et al. Expires January 13, 2011 [Page 4] Internet-Draft DHCPv6 Route Options July 2010 given that the analogous IPv4 routing problem may be solved by means of the DHCPv4 option [RFC3442]. To complete the description of the above scenario it is useful to note that no new or novel IPv6 routing mechanisms are required by NAS Routers 1 and 2. E.g. NAS Router 1 and 2 may act as DHCPv6 Delegating Routers and have the home subnet delegated prefix route installed by means of DHCPv6 Prefix Delegation. 3. DHCPv6 Based Solution A DHCPv6 based solution is able to address the limitations of the described ICMPv6 method, by allowing an operator an on demand and RG specific means of configuring static routing information. Such a DHCPv6 based solution also fits into network environments where the operator prefers to manage RG configuration information from a centralized DHCP server as opposed to doing so on each NAS. Furthermore, a DHCPv6 based solution can easily co-exist operationally with the already defined IPv4 solution [RFC3442]. Client interested in obtaining routing information, includes OPTION_IA_RT in its Option Request Option (ORO). Server provides requested information using OPTION_IA_RT option. To convey complex routing information, several nested options are required. Routing information is conveyed in a single IA_RT option. It must convey one or more OPTION_NEXT_HOP options that specify next hop. Each OPTION_NEXT_HOP conveys one or more OPTION_RT_PREFIX options that represents prefixes reachable via specified next hop. Formats of OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX are defined in the following sections. Defined options follow similar approach previously used in IA_NA, IA_TA and IA_PD options definitions. Each IPv6 next hop is associated with a one or more prefixes that share the same next-hop address. This allows the Route Option to convey both numerous prefixes that map to a common next hop address, as well as multiple next hop addresses each with their own set of prefixes. 3.1. Options Extensibility In previous versions of this draft, informations about routes were aggregated in a single option. It was determined that such a format eliminates the ability to add extensions to the routing information provided. As such, a nested options approach was defined. Dec, et al. Expires January 13, 2011 [Page 5] Internet-Draft DHCPv6 Route Options July 2010 The Defined syntax should be treated as a minimal framework necessary to convey routing related information. There are many possible parameters that may be defined at a later date. Examples include the Maximum Transfer Unit (MTU) defined for each prefix and router preferences. 3.2. Relation To Other Configuration Methods In terms of all other behaviour, such as the behaviour upon the failure or re-establishment of a link, or the failure to communicate with a DHCP server, the client is assumed to follow standard DHCPv6 [RFC3315] behaviour. 4. DHCPv6 Options Format The Route Option format borrows from that of the Route Information Option defined in [RFC4191]. The Route Preference field allows a client to compare the learned prefix to other like prefixes, possibly learned via other means. Other, host local preference route mechanisms may also be used. One notable exception with respect to [RFC4191] is however that a Route Lifetime element is not defined. The information conveyed by the DHCPv6 Route Option is considered valid until changed or refreshed by events that trigger DHCPv6 state changes, thus not requiring a specific route lifetime. In the event that it is desired for the client to request a refresh of the route information (and other stateless DHCPv6 options), use of the generic DHCPv6 Information Refresh Time Option, as specified in [RFC4242] is envisaged. 4.1. DHCPv6 Route Option Format To separate routing information from other options conveyed in a DHCPv6 message, DHCPv6 Route Option is defined. Its format is presented in Figure 2. The DHCPv6 Route Option is used to convey to a client one or more IPv6 routes. Each IPv6 route consists of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. the destination subnet), and a host preference value for the route. Elements of such route (e.g. next hops and prefixes associated with them) are conveyed in IA_RT's options, rather than in the IA_RT option itself. Dec, et al. Expires January 13, 2011 [Page 6] Internet-Draft DHCPv6 Route Options July 2010 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_IA_RT | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . IA_RT options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: IPv6 Routes Option Format option-code: OPTION_IA_RT (TBD). option-len: Length of the IA_RT options field. IA_RT options: Options associated with this IA_RT. This includes, but is not limited to, OPTION_NEXT_HOP options that specify next hop addresses. The Route option MUST NOT appear in the following DHCPv6 messages: Solicit, Request, Renew, Rebind, Information-Request. The Route Option MAY appear in ADVERTISE and REPLY messages. Discussion: Traditionally, grouping options (IA_NA, IA_TA and IA_RD) contain an identifier field (IAID) that must be unique among identifiers generated by one client. It is used to differentiate between several options of the same type (e.g. several IA_NA options) that may be used simultaneously. However, it is assumed that client will never use more than one IA_RT option therefore such an identifier is not needed. 4.2. Next Hop Option Format The Next Hop Option defines IPv6 address of the next hop, usually representing a distinct router. This information is crucial element of routing information as it defines location of the router. With each Next Hop address there is associated one or more prefixes available via that next hop. Dec, et al. Expires January 13, 2011 [Page 7] Internet-Draft DHCPv6 Route Options July 2010 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_NEXT_HOP | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 Next Hop Address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | NEXT_HOP options | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: IPv6 Route Option Format option-code: OPTION_NEXT_HOP (TBD). option-len: 16 + Length of NEXT_HOP options field. IPv6 Next Hop Address: 16 octet long field that specified IPv6 address of the next hop. NEXT_HOP options: Options associated with this Next Hop. This includes, but is not limited to, OPTION_RT_PREFIX options that specify prefixes available via specified next hop. 4.3. Route Prefix Option Format Route Prefix Option is used to convey information about a single prefix that represents destination network, reachable via certain router. Route Prefix Option is used as a sub-option in the previously defined Next Hop Option. Dec, et al. Expires January 13, 2011 [Page 8] Internet-Draft DHCPv6 Route Options July 2010 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_RT_PREFIX | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix-Length | Reserved |Prf| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Prefix | | (16 octets) | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . RT_PREFIX options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Route Prefix Option Format option-code: OPTION_RT_PREFIX (TBD). option-len: 18 + length of RT_PREFIX options. Prefix Length: 8-bit unsigned integer. The length in bits of the IP Prefix. The value ranges from 0 to 128. This field represents the number of valid leading bits in the prefix. Reserved: This 6 bits wide field is currently not used and must be filled with zeros. Prf: Route Preference. 2-bit signed integer. The Route Preference indicates whether to prefer the next hop associated with this prefix over others, when multiple identical prefixes (for different next hops) have been received. The defined preference values are as follows: 01 High 00 Medium (default) 11 Low Prefix: Fixed length 16 octet field containing an IPv6 prefix. Dec, et al. Expires January 13, 2011 [Page 9] Internet-Draft DHCPv6 Route Options July 2010 RT_PREFIX options: Optional options, specific to this particular prefix. This document does not specify such options. 5. DHCPv6 Server Behavior If configured to do so, DHCPv6 servers provide Routes Option in ADVERTISE and REPLY messages to client that requested such option. During successful operation, server adds at least one Next Hop Option as suboptions within single Routes Option. Each Next Hop Option must convey at least one Route Prefix Option. Servers MUST NOT send Route Option to clients that did not explicitly requested it, using the ORO. Server MUST NOT send Route Option in messages other than ADVERTISE or REPLY. Server MAY also include Status Code Option, defined in Section 22.13 of the [RFC3315] to indicate status of the operation. Server MUST include Status Code Option, if routing configuration was not successful. It SHOULD use status codes defined in [RFC3315] and [RFC3633]. Discussion: How should server indicate that there are no specific routes for this particular client? The reasonable behavior is to return empty IA_RT option, possibly with Status Code indicating Success. Another approach could be to simply not return any IA_RT option. 6. DHCPv6 Client Behavior A DHCPv6 client compliant with this specification MUST request the Route Option (option value TBD) in an Option Request Option (ORO), as described in [RFC3315], by including the Route Option code in the following messages: Solicit, Request, Renew, Rebind, Information- Request or Reconfigure. When processing a received Route Option a client MUST substitute a 0::0 value of the Next Hop Option with the source IPv6 address of the received DHCPv6 message. It MUST also associate a Link Local next hop addresses with the interface on which the client received the DHCPv6 message containing the route option. Such a substitution and/or association is useful in cases where the DHCPv6 server operator does not directly know the IPv6 next-hop address, other than knowing it is that of a DHCPv6 relay agent on the client LAN segment. Dec, et al. Expires January 13, 2011 [Page 10] Internet-Draft DHCPv6 Route Options July 2010 DHCPv6 Packets relayed to the client are sourced by the relay using this relay's IPv6 address, which could be a link local address. Client SHOULD ask for updated route information every time it sends REQUEST, RENEW, REBIND, CONFIRM or INFORMATION-REQUEST messages, by including Route Option code in the ORO it the transmitted message. Client MAY refresh assigned route information periodically. The generic DHCPv6 Information Refresh Time Option, as specified in [RFC4242], can be used when it is desired for the client to periodically refresh of route information. The routes conveyed by the Route Option should be considered as complimentary to any other route learning mechanism used by or on the host. 7. IANA Considerations A DHCPv6 option number of TBD for the introduced Route Option. IANA is requested to allocate three DHCPv6 option codes referencing this document: OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX. 8. 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 client implementations are deemed sufficient in addressing these problems. 9. Acknowledgements The authors would like to thank Alfred Hines, Ralph Droms, Ted Lemon, Ole Troan, Dave Oran and Dave Ward for their comments and useful suggestions. Dec, et al. Expires January 13, 2011 [Page 11] Internet-Draft DHCPv6 Route Options July 2010 10. References 10.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. 10.2. Informative References [I-D.troan-multihoming-without-nat66] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Wing, "IPv6 Multihoming without Network Address Translation", draft-troan-multihoming-without-nat66-00 (work in progress), May 2010. [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. [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. Dec, et al. Expires January 13, 2011 [Page 12] Internet-Draft DHCPv6 Route Options July 2010 Authors' Addresses Wojciech Dec Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Email: wdec@cisco.com Richard Johnson Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA Email: raj@cisco.com Tomasz Mrugalski Gdansk University of Technology Storczykowa 22B/12 Gdansk 80-177 Poland Phone: +48 698 088 272 Email: tomasz.mrugalski@eti.pg.gda.pl Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo, 180-8585 Japan Phone: +81 422 59 3334 Email: arifumi@nttv6.net Dec, et al. Expires January 13, 2011 [Page 13]