idnits 2.17.1 draft-ietf-mif-dhcpv6-route-option-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2011) is 4656 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Dec, Ed. 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track T. Mrugalski 5 Expires: January 27, 2012 ISC 6 T. Sun 7 China Mobile 8 B. Sarikaya 9 Huawei USA 10 July 26, 2011 12 DHCPv6 Route Options 13 draft-ietf-mif-dhcpv6-route-option-02 15 Abstract 17 This document describes DHCPv6 Route Options for provisioning IPv6 18 routes on DHCPv6 client nodes. This is expected to improve the 19 ability of an operator to configure and influence a nodes' ability to 20 pick an appropriate route to a destination when this node is multi- 21 homed and where other means of route configuration may be 22 impractical. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on January 27, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 4 66 4. DHCPv6 Route Options . . . . . . . . . . . . . . . . . . . . . 4 67 4.1. DHCPv6 Route Option Format . . . . . . . . . . . . . . . . 5 68 4.2. Next Hop Option Format . . . . . . . . . . . . . . . . . . 6 69 4.3. Route Prefix Option Format . . . . . . . . . . . . . . . . 7 70 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 8 71 6. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 8 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 9. Contributors and Acknowledgements . . . . . . . . . . . . . . 10 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 The Neighbor Discovery (ND) protocol [RFC4861] provides a mechanism 83 for hosts to discover one or more default routers on a directly 84 connected network segment. Extensions to the Router Advertisement 85 (RA) protocol defined in [RFC4191] allow hosts to discover the 86 preferences for multiple default routers on a given link, as well as 87 any specific routes advertised by these routers. This allows network 88 administrators to better handle multi-homed host topologies and 89 influence the route selection by the host. This ND based mechanism 90 however is sub optimal or impractical in some multi-homing scenarios, 91 where DHCPv6 [RFC3315]is seen to be more viable. 93 This draft defines the DHCPv6 Route Options for provisioning IPv6 94 routes on DHCPv6 clients. The proposed option is primarily envisaged 95 for use by DHCPv6 client nodes that are capable of making basic IP 96 routing decisions and maintaining an IPv6 routing table, broadly in 97 line with the capabilities of a generic host as described in 98 [RFC4191]. 100 Throughout the document the words node and client are used as a 101 reference to the device with such routing capabilities, hosting the 102 DHCPv6 client software. The route information is taken to be 103 equivalent to static routing, and limited in the number of required 104 routes to a handful. 106 2. Problem overview 108 The solution described in this document applies to multi-homed 109 scenarios including ones where the client is simultaneously connected 110 to multiple access network (e.g. WiFi and 3G). The following 111 scenario is used to illustrate the problem as found in typical multi- 112 homed residential access networks. It is duly noted that the problem 113 is not specific to IPv6, occurring also with IPv4, where it is today 114 solved by means of DHCPv4 classless route information option 115 [RFC3442], or alternative configuration mechanisms. 117 In multi-homed networks, a given user's node may be connected to more 118 than one gateways. Such connectivity may be realized by means of 119 dedicated physical or logical links that may also be shared with 120 other users nodes. In such multi-homed networks it is quite common 121 for the network operator to offer the delivery of a particular type 122 of IP service via a particular gateway, where the service can be 123 characterised by means of specific destination IP network prefixes. 124 Thus, from an IP routing perspective in order for the user node to 125 select the appropriate gateway for a given destination IP prefix, 126 recourse needs to be made to classic longest destination match IP 127 routing, with the node acquiring such prefixes into its routing 128 table. This is typically the remit of dynamic Internal Gateway 129 Protocols (IGPs), which however are rarely used by operators in 130 residential access networks. This is primarily due to operational 131 costs and a desire to contain the complexity of user nodes and IP 132 Edge devices to a minimum. While, IP Route configuration may be 133 achieved using the ICMPv6 extensions defined in [RFC4191], this 134 mechanism does not lend itself to other operational constraints such 135 as the desire to control the route information on a per node basis, 136 the ability to determine whether a given node is actually capable of 137 receiveing/processing such route information. A preferred mechanism, 138 and one that additionally also lends itself to centralized management 139 independent of the management of the gateways, is that of using the 140 DHCP protocol for conveying route information to the nodes. 142 3. DHCPv6 Based Solution 144 A DHCPv6 based solution allows an operator an on demand and node 145 specific means of configuring static routing information. Such a 146 solution also fits into network environments where the operator 147 prefers to manage RG configuration information from a centralized 148 DHCP server. [I-D.troan-multihoming-without-nat66] provides 149 additional background to the need for a DHCPv6 solution to the 150 problem. 152 In terms of the high level operation of the solution defined in this 153 draft, a DHCPv6 client interested in obtaining routing information 154 request the route option using the DHCPv6 Option Request Option (ORO) 155 sent to a server. A Server, when configured to do so, provides the 156 requested route information as part of a nested options structure 157 covering; the next-hop address; the destination prefix; the route 158 metric; any additional options applicable to the destination or next- 159 hop. The overall DHCPv6 design follow a similar approach to that 160 used in the design of the IA_NA, IA_TA and IA_PD options in 161 [RFC3633]. 163 4. DHCPv6 Route Options 165 A DHCPv6 client interested in obtaining routing information includes 166 the OPTION_IA_RT as par of its DHCPv6 Option Request Option (ORO) in 167 messages directed to a server (as allowed by [RFC3315], i.e. 168 Solicit, Request, Renew, Rebind, Confirm or Information-request 169 messages). A Server, when configured to do so, provides the 170 requested route information using the OPTION_IA_RT option in messages 171 sent in response (Advertise, and Reply). So as to allow the route 172 option to be both extensible, as well as conveying detailed info for 173 routes, use is made of a nested options structure. An IA_RT conveys 174 one or more OPTION_NEXT_HOP options that specify the IPv6 next hop 175 addresses. Each OPTION_NEXT_HOP conveys in turn one or more 176 OPTION_RT_PREFIX options that represents the IPv6 destination 177 prefixes reachable via the given next hop. The Formats of the 178 OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX are defined in the 179 following sub-sections 181 The DHCPv6 Route Option format borrows from the principles of the 182 Route Information Option defined in [RFC4191]. One notable exception 183 with respect to [RFC4191] is however that a Route Lifetime element is 184 not defined. The information conveyed by the DHCPv6 Route Option is 185 considered valid until changed or refreshed by general events that 186 trigger DHCPv6 or route table state changes on a node, thus not 187 requiring a specific route lifetime. In the event that it is desired 188 for the client to request a refresh of the route information (and 189 other stateless DHCPv6 options), use of the generic DHCPv6 190 Information Refresh Time Option, as specified in [RFC4242] is 191 envisaged. 193 4.1. DHCPv6 Route Option Format 195 To separate routing information from other options conveyed in a 196 DHCPv6 message, the DHCPv6 Route Option is defined and is used to 197 convey to a client one or more IPv6 routes. Each IPv6 route consists 198 of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. the 199 destination subnet), and a host preference value for the route. 200 Elements of such route (e.g. Next hops and prefixes associated with 201 them) are conveyed in IA_RT's options, rather than in the IA_RT 202 option itself. 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | OPTION_IA_RT | option-len | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | | 209 . IA_RT options . 210 . . 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 1: IPv6 Routes Option Format 215 option-code: OPTION_IA_RT (TBD). 217 option-len: Length of the IA_RT options field. 219 IA_RT options: Options associated with this IA_RT. This includes, 220 but is not limited to, OPTION_NEXT_HOP options that specify 221 next hop addresses. 223 The Route option MUST NOT appear in the following DHCPv6 messages: 224 Solicit, Request, Renew, Rebind, Information-Request. The Route 225 Option MAY appear in ADVERTISE and REPLY messages. 227 If there is more than one route available via specific next hop, 228 server MUST send only one OPTION_NEXT_HOP for that next hop, which 229 contains multiple OPTION_RT_PREFIX options. Server MUST NOT send 230 more than one identical (i.e. with equal next hop address field) 231 OPTION_NEXT_HOP option. 233 Discussion: Traditionally, grouping options (IA_NA, IA_TA and IA_RD) 234 contain an identifier field (IAID) that must be unique among 235 identifiers generated by one client. It is used to differentiate 236 between several options of the same type (e.g. several IA_NA options) 237 that may be used simultaneously. However, it is assumed that client 238 will never use more than one IA_RT option therefore such an 239 identifier is not needed. 241 4.2. Next Hop Option Format 243 The Next Hop Option defines the IPv6 address of the next hop, usually 244 corresponding to a specific next-hop router. For each next hop 245 address there can be one or more prefixes reachable via that next 246 hop. 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | OPTION_NEXT_HOP | option-len | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | IPv6 Next Hop Address | 254 | (16 octets) | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | | 258 | NEXT_HOP options | 259 . . 260 . . 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 Figure 2: IPv6 Route Option Format 265 option-code: OPTION_NEXT_HOP (TBD). 267 option-len: 16 + Length of NEXT_HOP options field. 269 IPv6 Next Hop Address: 16 octet long field that specified IPv6 270 address of the next hop. 272 NEXT_HOP options: Options associated with this Next Hop. This 273 includes, but is not limited to, one or more 274 OPTION_RT_PREFIX options that specify prefixes reachable 275 through the given next hop. 277 4.3. Route Prefix Option Format 279 The Route Prefix Option is used to convey information about a single 280 prefix that represents the destination network. The Route Prefix 281 Option is used as a sub-option in the previously defined Next Hop 282 Option. 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | OPTION_RT_PREFIX | option-len | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Prefix-Length | Metric | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 290 | Prefix | 291 | (16 octets) | 292 | | 293 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | | | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 296 . . 297 . RT_PREFIX options . 298 . . 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 3: Route Prefix Option Format 303 option-code: OPTION_RT_PREFIX (TBD). 305 option-len: 18 + length of RT_PREFIX options. 307 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 308 Prefix. The value ranges from 0 to 128. This field 309 represents the number of valid leading bits in the prefix. 311 Metric: Route Metric. 8-bit signed integer. The Route Metric 312 indicates whether to prefer the next hop associated with 313 this prefix over others, when multiple identical prefixes 314 (for different next hops) have been received. 316 Prefix: Fixed length 16 octet field containing an IPv6 prefix. 318 RT_PREFIX options: Options specific to this particular prefix. 320 5. DHCPv6 Server Behavior 322 When configured to do so s DHCPv6 server shall provide the Routes 323 Option in ADVERTISE and REPLY messages sent to a client that 324 requested the route option. Each Next Hop Option sent by the server 325 must convey at least one Route Prefix Option. 327 Servers SHOULD NOT send Route Option to clients that did not 328 explicitly requested it, using the ORO. 330 Servers MUST NOT send Route Option in messages other than ADVERTISE 331 or REPLY. 333 Servers MAY also include Status Code Option, defined in Section 22.13 334 of the [RFC3315] to indicate the status of the operation. 336 Servers MUST include the Status Code Option, if the requested routing 337 configuration was not successful and SHOULD use status codes as 338 defined in [RFC3315] and [RFC3633]. 340 The maximum number of routing information in one DHCPv6 message 341 depend on the maximum DHCPv6 message size defined in [RFC3315] 343 Discussion: How should server indicate that there are no specific 344 routes for this particular client? The reasonable behavior is to 345 return empty IA_RT option, possibly with Status Code indicating 346 Success. Another approach could be to simply not return any IA_RT 347 option. 349 6. DHCPv6 Client Behavior 351 A DHCPv6 client compliant with this specification MUST request the 352 Route Option (option value TBD) in an Option Request Option (ORO) in 353 the following messages: Solicit, Request, Renew, Rebind, Information- 354 Request or Reconfigure. The messages are to be sent as and when 355 specified by [RFC3315]. 357 When processing a received Route Option a client MUST substitute a 358 received 0::0 value in the Next Hop Option with the source IPv6 359 address of the received DHCPv6 message. It MUST also associate a 360 received Link Local next hop addresses with the interface on which 361 the client received the DHCPv6 message containing the route option. 362 Such a substitution and/or association is useful in cases where the 363 DHCPv6 server operator does not directly know the IPv6 next-hop 364 address, other than knowing it is that of a DHCPv6 relay agent on the 365 client LAN segment. DHCPv6 Packets relayed to the client are sourced 366 by the relay using this relay's IPv6 address, which could be a link 367 local address. 369 The Client MAY refresh assigned route information periodically. The 370 generic DHCPv6 Information Refresh Time Option, as specified in 371 [RFC4242], can be used when it is desired for the client to 372 periodically refresh of route information. 374 The routes conveyed by the Route Option should be considered as 375 complimentary to any other static route learning and maintenance 376 mechanism used by, or on the client with one modification: The client 377 MUST flush DHCPv6 installed routes following a link flap event on the 378 DHCPv6 client interface over which the routes were installed. This 379 requirement is necessary to automate the flushing of routes for 380 clients that may move to a different network. 382 Client MUST confirm that routers announced over DHCPv6 are reachable, 383 using one of methods suitable for specific network type. The most 384 common mechanism is Neighbor Unreachability Detection (NUD), 385 specified in [RFC4861]. Client SHOULD use NUD to verify that 386 received routers are reachable before adjusting its routing tables. 387 Client MAY use other reachibality verification mechanisms specific to 388 used network technology. To avoid potential long-lived routing black 389 holes, client MAY periodically confirm that router is still 390 reachable. 392 7. IANA Considerations 394 A DHCPv6 option number of TBD for the introduced Route Option. IANA 395 is requested to allocate three DHCPv6 option codes referencing this 396 document: OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX. 398 8. Security Considerations 400 The overall security considerations discussed in [RFC3315] apply also 401 to this document. The Route option could be used by malicious 402 parties to misdirect traffic sent by the client either as part of a 403 denial of service or man-in-the-middle attack. An alternative denial 404 of service attack could also be realized by means of using the route 405 option to overflowing any known memory limitations of the client, or 406 to exceed the client's ability to handle the number of next hop 407 addresses. 409 Neither of the above considerations are new and specific to the 410 proposed route option. The mechanisms identified for securing DHCPv6 411 as well as reasonable checks performed by client implementations are 412 deemed sufficient in addressing these problems. 414 It is essential that clients verify that announced routers are indeed 415 reachable, as specified in Section 6. Failing to do so may create 416 black hole routing problem. 418 9. Contributors and Acknowledgements 420 This document would not have been possible without the significant 421 contribution provided by: Arifumi Matsumoto, Hui Deng, Richard 422 Johnson, Zhen Cao. 424 The authors would also like to thank Alfred Hines, Ralph Droms, Ted 425 Lemon, Ole Troan, Dave Oran, Dave Ward and Joel Halpern for their 426 comments and useful suggestions. 428 10. References 430 10.1. Normative References 432 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 433 Requirement Levels", BCP 14, RFC 2119, March 1997. 435 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 436 and M. Carney, "Dynamic Host Configuration Protocol for 437 IPv6 (DHCPv6)", RFC 3315, July 2003. 439 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 440 Host Configuration Protocol (DHCP) version 6", RFC 3633, 441 December 2003. 443 10.2. Informative References 445 [I-D.troan-multihoming-without-nat66] 446 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 447 Wing, "IPv6 Multihoming without Network Address 448 Translation", draft-troan-multihoming-without-nat66-01 449 (work in progress), July 2010. 451 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 452 Static Route Option for Dynamic Host Configuration 453 Protocol (DHCP) version 4", RFC 3442, December 2002. 455 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 456 More-Specific Routes", RFC 4191, November 2005. 458 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 459 Time Option for Dynamic Host Configuration Protocol for 460 IPv6 (DHCPv6)", RFC 4242, November 2005. 462 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 463 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 464 September 2007. 466 Authors' Addresses 468 Wojciech Dec (editor) 469 Cisco Systems 470 Haarlerbergweg 13-19 471 1101 CH Amsterdam 472 The Netherlands 474 Email: wdec@cisco.com 476 Tomasz Mrugalski 477 Internet Systems Consortium, Inc. 478 950 Charter Street 479 Redwood City, CA 94063 480 USA 482 Phone: +1 650 423 1345 483 Email: tomasz.mrugalski@gmail.com 485 Tao Sun 486 China Mobile 487 Unit2, 28 Xuanwumenxi Ave 488 Beijing, Xuanwu District 100053 489 China 491 Phone: 492 Email: suntao@chinamobile.com 493 Behcet Sarikaya 494 Huawei USA 495 1700 Alma Dr. Suite 500 496 Plano, TX 75075 497 United States 499 Phone: +1 972-509-5599 500 Fax: 501 Email: sarikaya@ieee.org 502 URI: