idnits 2.17.1 draft-ietf-mif-dhcpv6-route-option-01.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 (March 14, 2011) is 4793 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: September 15, 2011 Gdansk University of Technology 6 T. Sun 7 China Mobile 8 B. Sarikaya 9 Huawei USA 10 March 14, 2011 12 DHCPv6 Route Option 13 draft-ietf-mif-dhcpv6-route-option-01 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 September 15, 2011. 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 Option . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 9 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The Neighbor Discovery (ND) ICMPv6 protocol [RFC4861] provides a 83 mechanism for hosts to discover one or more default routers on a 84 directly connected network segment. Extensions to the Router 85 Advertisement (RA) protocol defined in [RFC4191] allow hosts to 86 discover the preferences for multiple default routers on a given 87 link, as well as any specific routes advertised by these routers. 88 This allows network administrators to better handle multi-homed host 89 topologies and influence the route selection by the host. This ND 90 based mechanism however is sub optimal or impractical in some multi- 91 homing scenarios, where DHCPv6 [RFC3315]is seen to be more viable. 93 This draft defines the DHCPv6 Route Option 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 [RFC3633] 162 4. DHCPv6 Route Option 164 A DHCPv6 client interested in obtaining routing information includes 165 the OPTION_IA_RT as par of its DHCPv6 Option Request Option (ORO) in 166 messages directed to a server (as allowed by [RFC3315], ie Solicit, 167 Request, Renew, Rebind, Confirm or Information-request messages). A 168 Server, when configured to do so, provides the requested route 169 information using the OPTION_IA_RT option in messages sent in 170 response (Advertise, and Reply). So as to allow the route option to 171 be both extensible, as well as conveying detailed info for routes, 172 use is made of a nested options structure. An IA_RT conveys one or 173 more OPTION_NEXT_HOP options that specify the IPv6 next hop 174 addresses. Each OPTION_NEXT_HOP conveys in turn one or more 175 OPTION_RT_PREFIX options that represents the IPv6 destination 176 prefixes reachable via the given next hop. The Formats of the 177 OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX are defined in the 178 following sub-sections 180 The DHCPv6 Route Option format borrows from the principles of the 181 Route Information Option defined in [RFC4191]. One notable exception 182 with respect to [RFC4191] is however that a Route Lifetime element is 183 not defined. The information conveyed by the DHCPv6 Route Option is 184 considered valid until changed or refreshed by general events that 185 trigger DHCPv6 or route table state changes on a node, thus not 186 requiring a specific route lifetime. In the event that it is desired 187 for the client to request a refresh of the route information (and 188 other stateless DHCPv6 options), use of the generic DHCPv6 189 Information Refresh Time Option, as specified in [RFC4242] is 190 envisaged. 192 4.1. DHCPv6 Route Option Format 194 To separate routing information from other options conveyed in a 195 DHCPv6 message, the DHCPv6 Route Option is defined and is used to 196 convey to a client one or more IPv6 routes. Each IPv6 route consists 197 of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. the 198 destination subnet), and a host preference value for the route. 199 Elements of such route (e.g. Next hops and prefixes associated with 200 them) are conveyed in IA_RT's options, rather than in the IA_RT 201 option itself. 202 0 1 2 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | OPTION_IA_RT | option-len | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | | 208 . IA_RT options . 209 . . 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 1: IPv6 Routes Option Format 214 option-code: OPTION_IA_RT (TBD). 216 option-len: Length of the IA_RT options field. 218 IA_RT options: Options associated with this IA_RT. This includes, 219 but is not limited to, OPTION_NEXT_HOP options that specify 220 next hop addresses. 222 The Route option MUST NOT appear in the following DHCPv6 messages: 223 Solicit, Request, Renew, Rebind, Information-Request. The Route 224 Option MAY appear in ADVERTISE and REPLY messages. 226 Discussion: Traditionally, grouping options (IA_NA, IA_TA and IA_RD) 227 contain an identifier field (IAID) that must be unique among 228 identifiers generated by one client. It is used to differentiate 229 between several options of the same type (e.g. several IA_NA options) 230 that may be used simultaneously. However, it is assumed that client 231 will never use more than one IA_RT option therefore such an 232 identifier is not needed. 234 4.2. Next Hop Option Format 236 The Next Hop Option defines the IPv6 address of the next hop, usually 237 corresponding to a specific next-hop router. For each next hop 238 address there can be one or more prefixes reachable via that next 239 hop. 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | OPTION_NEXT_HOP | option-len | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | | 246 | IPv6 Next Hop Address | 247 | (16 octets) | 248 | | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | | 251 | NEXT_HOP options | 252 . . 253 . . 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 Figure 2: IPv6 Route Option Format 258 option-code: OPTION_NEXT_HOP (TBD). 260 option-len: 16 + Length of NEXT_HOP options field. 262 IPv6 Next Hop Address: 16 octet long field that specified IPv6 263 address of the next hop. 265 NEXT_HOP options: Options associated with this Next Hop. This 266 includes, but is not limited to, one or more 267 OPTION_RT_PREFIX options that specify prefixes reachable 268 through the given next hop. 270 4.3. Route Prefix Option Format 272 The Route Prefix Option is used to convey information about a single 273 prefix that represents the destination network. The Route Prefix 274 Option is used as a sub-option in the previously defined Next Hop 275 Option. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | OPTION_RT_PREFIX | option-len | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Prefix-Length | Metric | | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 283 | Prefix | 284 | (16 octets) | 285 | | 286 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 289 . . 290 . RT_PREFIX options . 291 . . 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Figure 3: Route Prefix Option Format 296 option-code: OPTION_RT_PREFIX (TBD). 298 option-len: 18 + length of RT_PREFIX options. 300 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 301 Prefix. The value ranges from 0 to 128. This field 302 represents the number of valid leading bits in the prefix. 304 Metric: Route Metric. 8-bit signed integer. The Route Metric 305 indicates whether to prefer the next hop associated with 306 this prefix over others, when multiple identical prefixes 307 (for different next hops) have been received. 309 Prefix: Fixed length 16 octet field containing an IPv6 prefix. 311 RT_PREFIX options: Options specific to this particular prefix. 313 5. DHCPv6 Server Behavior 315 When configured to do so s DHCPv6 server shall provide the Routes 316 Option in ADVERTISE and REPLY messages sent to a client that 317 requested the route option. Each Next Hop Option sent by the server 318 must convey at least one Route Prefix Option. 320 Servers SHOULD NOT send Route Option to clients that did not 321 explicitly requested it, using the ORO. 323 Servers MUST NOT send Route Option in messages other than ADVERTISE 324 or REPLY. 326 Servers MAY also include Status Code Option, defined in Section 22.13 327 of the [RFC3315] to indicate the status of the operation. 329 Servers MUST include the Status Code Option, if the requested routing 330 configuration was not successful and SHOULD use status codes as 331 defined in [RFC3315] and [RFC3633]. 333 The maximum number of routing information in one DHCPv6 message 334 depend on the maximum DHCPv6 message size defined in [RFC3315] 336 Discussion: How should server indicate that there are no specific 337 routes for this particular client? The reasonable behavior is to 338 return empty IA_RT option, possibly with Status Code indicating 339 Success. Another approach could be to simply not return any IA_RT 340 option. 342 6. DHCPv6 Client Behavior 344 A DHCPv6 client compliant with this specification MUST request the 345 Route Option (option value TBD) in an Option Request Option (ORO) in 346 the following messages: Solicit, Request, Renew, Rebind, Information- 347 Request or Reconfigure. The messages are to be sent as and when 348 specified by [RFC3315]. 350 When processing a received Route Option a client MUST substitute a 351 received 0::0 value in the Next Hop Option with the source IPv6 352 address of the received DHCPv6 message. It MUST also associate a 353 received Link Local next hop addresses with the interface on which 354 the client received the DHCPv6 message containing the route option. 355 Such a substitution and/or association is useful in cases where the 356 DHCPv6 server operator does not directly know the IPv6 next-hop 357 address, other than knowing it is that of a DHCPv6 relay agent on the 358 client LAN segment. DHCPv6 Packets relayed to the client are sourced 359 by the relay using this relay's IPv6 address, which could be a link 360 local address. 362 The Client MAY refresh assigned route information periodically. The 363 generic DHCPv6 Information Refresh Time Option, as specified in 364 [RFC4242], can be used when it is desired for the client to 365 periodically refresh of route information. 367 The routes conveyed by the Route Option should be considered as 368 complimentary to any other static route learning and maintenance 369 mechanism used by, or on the client with one modification: The client 370 MUST flush DHCPv6 installed routes following a link flap event on the 371 DHCPv6 client interface over which the routes were installed. This 372 requirement is necessary to automate the flushing of routes for 373 clients that may move to a different network. 375 7. IANA Considerations 377 A DHCPv6 option number of TBD for the introduced Route Option. IANA 378 is requested to allocate three DHCPv6 option codes referencing this 379 document: OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX. 381 8. Security Considerations 383 The overall security considerations discussed in [RFC3315] apply also 384 to this document. The Route option could be used by malicious 385 parties to misdirect traffic sent by the client either as part of a 386 denial of service or man-in-the-middle attack. An alternative denial 387 of service attack could also be realized by means of using the route 388 option to overflowing any known memory limitations of the client, or 389 to exceed the client's ability to handle the number of next hop 390 addresses. 392 Neither of the above considerations are new and specific to the 393 proposed route option. The mechanisms identified for securing DHCPv6 394 as well as reasonable checks performed by client implementations are 395 deemed sufficient in addressing these problems. 397 9. Contributors and .Acknowledgements 399 This document would not have been possible without the significant 400 contribution provided by: Arifumi Matsumoto, Hui Deng, Richard 401 Johnson, Zhen Cao. 403 The authors would also like to thank Alfred Hines, Ralph Droms, Ted 404 Lemon, Ole Troan, Dave Oran and Dave Ward for their comments and 405 useful suggestions. 407 10. References 409 10.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 415 and M. Carney, "Dynamic Host Configuration Protocol for 416 IPv6 (DHCPv6)", RFC 3315, July 2003. 418 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 419 Host Configuration Protocol (DHCP) version 6", RFC 3633, 420 December 2003. 422 10.2. Informative References 424 [I-D.troan-multihoming-without-nat66] 425 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 426 Wing, "IPv6 Multihoming without Network Address 427 Translation", draft-troan-multihoming-without-nat66-01 428 (work in progress), July 2010. 430 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 431 Static Route Option for Dynamic Host Configuration 432 Protocol (DHCP) version 4", RFC 3442, December 2002. 434 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 435 More-Specific Routes", RFC 4191, November 2005. 437 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 438 Time Option for Dynamic Host Configuration Protocol for 439 IPv6 (DHCPv6)", RFC 4242, November 2005. 441 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 442 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 443 September 2007. 445 Authors' Addresses 447 Wojciech Dec (editor) 448 Cisco Systems 449 Haarlerbergweg 13-19 450 1101 CH Amsterdam 451 The Netherlands 453 Email: wdec@cisco.com 455 Tomasz Mrugalski 456 Gdansk University of Technology 457 Storczykowa 22B/12 458 Gdansk 80-177 459 Poland 461 Phone: +48 698 088 272 462 Email: tomasz.mrugalski@eti.pg.gda.pl 464 Tao Sun 465 China Mobile 466 Unit2, 28 Xuanwumenxi Ave 467 Beijing, Xuanwu District 100053 468 China 470 Phone: 471 Email: suntao@chinamobile.com 473 Behcet Sarikaya 474 Huawei USA 475 1700 Alma Dr. Suite 500 476 Plano, TX 75075 477 United States 479 Phone: +1 972-509-5599 480 Fax: 481 Email: sarikaya@ieee.org 482 URI: