idnits 2.17.1 draft-dec-dhcpv6-route-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 8, 2010) is 5162 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4291' is defined on line 376, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Dec 3 Internet-Draft R. Johnson 4 Intended status: Informational Cisco Systems 5 Expires: September 9, 2010 March 8, 2010 7 DHCPv6 Route Option 8 draft-dec-dhcpv6-route-option-03 10 Abstract 12 This document describes the DHCPv6 Route Option for provisioning IPv6 13 routes on a DHCPv6 client. This is expected to improve the ability 14 of an operator to configure and influence a client's ability to pick 15 an appropriate route to a destination when this client is multi-homed 16 to routers and where other means of route configuration may be 17 impractical. The option is primarily envisaged for configuring a 18 broadband Residential Gateway (RG) router, but is generic enough to 19 be used by other types of DHCPv6 clients. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 9, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Route Option Format . . . . . . . . . . . . . . . . . . . . 5 71 3.2. Appearance of the route option in DHCP messages . . . . . . 6 72 4. DHCP Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 73 5. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . . 8 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The Neighbor Discovery protocol [RFC4861] provides a mechanism for 85 hosts to discover one or more default routers on a directly connected 86 network segment. Extensions to the protocol defined in [RFC4191] 87 allow the discovery by such hosts of the preferences for multiple 88 default routers as well as more specific routes advertised by these 89 routers. This allows network administrators to better handle multi- 90 homed host topologies and influence the route selection by the host. 91 The mechanism however falls short in a few broadband access network 92 and operational scenarios that are in existence today. 94 This document presents the operational scenarios for which a DHCP 95 based static route provisioning method would be preferred. It then 96 defines the DHCPv6 Route Option for provisioning static IPv6 routes 97 on a DHCPv6 client that supports such functionality. The proposed 98 option is primarily envisaged for implementation on a class of IPv6 99 router known as a broadband Residential Gateway (RG), found in DSL, 100 Cable and FTTH environments, but it is generic enough to be used by 101 other types of clients. 103 Throughout the document the word client is used to designate the 104 device hosting the DHCPv6 client and is intended to be 105 interchangeable with the term RG. It is assumed that such a client 106 is capable of making basic IP routing decisions and maintaining a 107 simple IPv6 routing table. 109 2. Problem overview 111 Two scenarios are used to illustrate the problem as found in 112 residential broadband access networks. (It is duly noted that the 113 problem is not specific to IPv6). In general, in such access 114 networks a given user's RG may be expected to use a gateway more than 115 one Network Access Servers (NAS) when connected by means of an 116 Ethernet VLAN that is shared with other users. Each NAS would 117 typically be intended by the operator for the delivery of a 118 particular type of service, made accessible to the user of the RG, 119 where the service can be characterised by means of IP network 120 addresses. Naturally, the RG can also be connected to each NAS by 121 means of two or more links (e.g. using dedicated PPP links). In such 122 networks today, in order for the RG to select the appropriate NAS for 123 a given destination IP address, recourse is made to static routing 124 (meaning that they are not expected to change), which are actually 125 dynamically provisioned upon an RG connecting to the network. IGPs 126 are not commonly used for conveying such route information to RGs due 127 to operational reasons and a desire by the operators to maintain RG 128 and IP Edge devices complexity to a minimum. 130 Figure 1 illustrates the case of two clients connected to a shared 131 Ethernet access VLAN. Both clients are assumed to have already 132 assigned IPv6 addresses of a global scope and obtain their Internet 133 connectivity via Router2 by means of a configured or discovered 134 default route/router. In addition to a global IP address Client1 may 135 be assigned with another IP address of a provider restricted scope 136 (ULA) for the purpose of communicating with specific services such as 137 that offered by Server A. Client 1, unlike Client 2, is intended to 138 access such a specific service, e.g. VoIP, hosted on ServerA by 139 means of Router1, with Server A being otherwise not reachable from 140 the Internet. 142 +---Router1------ServerA 143 | 144 Client1----+ 145 | 146 Client2----+ 147 | 148 +---Router2------Internet 150 Figure 1 152 The problem in the above scenario comes due to the fact that in order 153 to reach Server A, Client1 is required to possess a more specific 154 route for the address of A as reachable via Router1. An ICMPv6 based 155 mechanism for advertising more specific route information, as defined 156 in [RFC4191], disseminates this information via the shared link also 157 to Client2 which an operator often wants to avoid. Furthermore it's 158 is also desired to be able to manage per user route information from 159 a centralized repository instead of managing such information 160 directly on the NAS routers. The former requirement is driven by the 161 desire to provide to each client only the information required for 162 their intended role, which may be tied to a specific authorized 163 service subscription, as well as to allow the possibility to 164 introduce other service-routers into the scenario for load sharing of 165 other users. The requirement for centralized configuration 166 management is often due to commercial (e.g. Layer 3 wholesale) or 167 administrative boundaries which make router based configuration 168 difficult or impossible. 170 Figure 2 illustrates the case of a single client connected via two 171 logical or physical links to Router 1 and Router 2 respectively. 172 Router 1 is the intended gateway for a specific application on 173 ServerA (e.g. VoIP or NMS) that is otherwise not reachable via 174 Router2. 176 ----Router1------ServerA 177 / 178 Client1 179 \ 180 ----Router2------Internet 182 Figure 2 184 Once again, to obtain the desired routing behaviour there is a need 185 for Client1 to have a more specific IP route towards the target 186 application/server accessible via Router1, leaving Router2 as the 187 default gateway for other destinations. In this set-up the [RFC4191] 188 mechanism does indeed provide a solution, but one that is only 189 applicable in cases when the operator is willing to maintain the 190 necessary per user/RG configuration directly on Routers1 and 2. As 191 per the earlier scenario, this is often either impractical or not 192 possible, especially when operators are accustomed to resolving the 193 analogous IPv4 routing case by means of DHCPv4 using the classless 194 route information option [RFC3442]. 196 In terms of routing and route installation towards Client1 by Routers 197 1 and 2, neither scenario calls for any specific mechanisms other 198 than those commonly used in such access scenarios, e.g. Router 1 may 199 have a DHCP PD derived route towards the limited scope IP prefix 200 assigned to Client1, while Router2 may have a AAA derived route 201 corresponding to the Client1 global IP address prefix. 203 3. Solution 205 A solution using a DHCPv6 Route-Option can be seen to offer an 206 operator to directly configure static routing information on a per 207 client basis. The DHCPv6 solution fits also readily into a network 208 environment where the operator has no means of directly configuring 209 the first hop NAS routers and/or maintain per user configuration 210 therein, preferring to manage such information from a centralized 211 DHCP server. Furthermore, the solution can easily integrate 212 operationally alongside similar functionality that may already used 213 be for IPv4, namely DHCPv4[RFC3442]. 215 3.1. Route Option Format 217 A DHCPv6 server sends the Route Option to a DHCPv6 client to convey 218 one or more IPv6 routes. Each IPv6 route consists of a 128-bit next 219 hop IPv6 address for one or more IPv6 prefixes of a declared bit 220 length (a prefix). Multiple prefixes can be present in a single 221 option, when sharing the same next hop address. The complete option 222 is octet aligned by padding with 0s to the last octet boundary. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | OPTION_ROUTE | option-len | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | | 230 | IPv6 Next Hop Address | 231 | | 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Prefix Length | Prefix (variable length) | 235 +-+-+-+-+-+-+-+-+ . 236 . . 237 . . 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 option-code OPTION_ROUTE (TBD). 242 option-len 17 + Length of the Prefix field in full octets (includes 243 any padding). 245 IPv6 Next Hop Address 246 The 128 bit IPv6 address of the next hop to be 247 used when forwarding towards the IP Prefix(es). 249 Prefix Length 250 8-bit unsigned integer. The length in bits of 251 the directly following IP Prefix directly following, 252 which also represents the number of leading bits in the 253 prefix. The value ranges from 0 to 128. 255 Prefix 256 Variable-length field containing the IP Prefix. 258 3.2. Appearance of the route option in DHCP messages 260 The Route option MUST NOT appear in the following DHCP messages: 261 Solicit, Request, Renew, Rebind, Information-Request and Reconfigure. 263 A single option can be used to covey multiple routes for the same 264 next hop by means of successively inserting additional combinations 265 prefix-length and prefix fields. Separate options are to be used for 266 routes not sharing the same next-hop. 268 The example below illustrates how two routes, consisting of Prefix A 269 and Prefix B with the same next hop addresses Next Hop 1 and can be 270 conveyed by a single route-option. 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | OPTION_ROUTE | option-len | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | | 278 | IPv6 Next Hop Address 1 | 279 | | 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 |Prefix A Length| Prefix A (variable length) | 283 +-+-+-+-+-+-+-+-+ . 284 . . 285 . . 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 |Prefix B Length| Prefix B (variable length) | 288 +-+-+-+-+-+-+-+-+ . 289 . . 290 . . 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 4. DHCP Client Behavior 295 A DHCPv6 client compliant with this specification SHOULD request the 296 Route option (option value TBD) in an Options Request Option (ORO), 297 as described in [RFC3315], by including the Route options' code in 298 the following messages: Solicit, Request, Renew, Rebind, Information- 299 Request and Reconfigure. 301 If more than one route option appears in the same DHCPv6 message, the 302 client MUST process the options in the same way as if the information 303 was received in a single route option. If the same prefix appears 304 more than once but with different values for next- hop, the client 305 SHOULD install separate routes in the routing table for that prefix, 306 one for each distinct value of next-hop. 308 When processing the Route option a client MUST substitute a 0::0 IP 309 next hop address with the source IP address of the received DHCP 310 message. This is useful in cases where the DHCP server operator 311 would like the client to use as a next hop the source IP address of 312 an intermediate DHCP relay agent, whose address is used in packets 313 relayed to the client, without the need of identifying this address 314 explicitly. Given that next-hop address is likely to be an IPv6 315 Link-local address, the client MUST associate the route with the 316 interface on which the client received the DHCPv6 message containing 317 the route option. 319 In terms of all other behaviour, such as the behaviour upon the 320 failure or re-establishment of a link ,or the failure to communicate 321 with a DHCP server, the client is assumed to follow [RFC3315]. 323 5. DHCP Server Behavior 325 A server MAY send one of more Route Options to the client. The 326 server SHOULD support sending the option(s) as part of other DHCP 327 options where such a possibility exists, for example when sending the 328 route option(s) as part of an IA_NA or IA_PD option set. 330 6. IANA Considerations 332 A DHCPv6 option number of TBD for the "Route Option" is required to 333 be assigned by IANA. 335 7. Security Considerations 337 The overall security considerations discussed in [RFC3315] apply also 338 to this document. The Route option could be used by malicious 339 parties to misdirect traffic sent by the client either as part of a 340 denial of service or man-in-the-middle attack. An alternative denial 341 of service attack could also be realized by means of using the route 342 option to overflowing any known memory limitations of the client, or 343 to exceed the client's ability to handle the number of next hop 344 addresses. 346 Neither of the above considerations are new and specific to the 347 proposed route option. The mechanisms identified for securing DHCPv6 348 as well as reasonable checks performed by client implementations are 349 deemed sufficient in addressing these problems. 351 8. Acknowledgements 353 The authors would like to thank Alfred HInes, Ralph Droms, Ted Lemon, 354 Ole Troan, Dave Oran and Dave Ward for their comments and useful 355 suggestions. 357 9. References 358 9.1. Normative References 360 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 361 Requirement Levels", BCP 14, RFC 2119, March 1997. 363 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 364 and M. Carney, "Dynamic Host Configuration Protocol for 365 IPv6 (DHCPv6)", RFC 3315, July 2003. 367 9.2. Informative References 369 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 370 Static Route Option for Dynamic Host Configuration 371 Protocol (DHCP) version 4", RFC 3442, December 2002. 373 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 374 More-Specific Routes", RFC 4191, November 2005. 376 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 377 Architecture", RFC 4291, February 2006. 379 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 380 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 381 September 2007. 383 Authors' Addresses 385 Wojciech Dec 386 Cisco Systems 387 Haarlerbergweg 13-19 388 1101 CH Amsterdam 389 The Netherlands 391 Email: wdec@cisco.com 393 Richard Johnson 394 Cisco Systems 395 170 W. Tasman Dr. 396 San Jose, CA 95134 397 USA 399 Phone: 400 Fax: 401 Email: raj@cisco.com