idnits 2.17.1 draft-ietf-mif-dhcpv6-route-option-00.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 (January 10, 2011) is 4854 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: July 14, 2011 Gdansk University of Technology 6 T. Sun 7 China Mobile 8 B. Sarikaya 9 Huawei USA 10 January 10, 2011 12 DHCPv6 Route Option 13 draft-ietf-mif-dhcpv6-route-option-00 15 Abstract 17 This document describes DHCPv6 Route Options for provisioning IPv6 18 routes on nodes with DHCPv6 clients. This is expected to improve the 19 ability of an operator to configure and influence a node's 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 July 14, 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 . . . . . . . . . . . . . . . . 6 70 5. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 10.1. Normative References . . . . . . . . . . . . . . . . . . . 9 77 10.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 1. Introduction 82 The Neighbor Discovery (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 protocol 85 defined in [RFC4191] allow hosts to discover the preferences for 86 multiple default routers on a given link, as well as any specific 87 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 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 following scenario is used to illustrate the problem as found in 109 multi-homed residential access networks. It is duly noted that the 110 problem is not specific to IPv6, occurring also with IPv4, where it 111 is today solved by means of DHCPv4 classless route information option 112 [RFC3442], or alternative configuration mechanisms. 114 In multi-homed networks, a given user's node may be connected to more 115 than one gateways. Such connectivity may be realized by means of 116 dedicated physical or logical links that may also be shared with 117 other users nodes. In such multi-homed networks it is quite common 118 for the network operator to offer the delivery of a particular type 119 of IP service via a particular gateway, where the service can be 120 characterised by means of specific destination IP network prefixes. 121 Thus, from an IP routing perspective in order for the user node to 122 select the appropriate gateway for a given destination IP prefix, 123 recourse needs to be made to classic longest destination match IP 124 routing, with the node acquiring such prefixes into its routing 125 table. This is typically the remit of dynamic Internal Gateway 126 Protocols (IGPs), which however are rarely used by operators in 127 residential access networks. This is primarily due to operational 128 costs and a desire to contain the complexity of user nodes and IP 129 Edge devices to a minimum. While, IP Route configuration may be 130 achieved using the ICMPv6 extensions defined in [RFC4191], this 131 mechanism does not lend itself to other operational constraints such 132 as the desire to control the route information on a per node basis, 133 the ability to determine whether a given node is actually capable of 134 receiveing/processing such route information. A preferred mechanism, 135 and one that additionally also lends itself to centralized management 136 independent of the management of the gateways, is that of using the 137 DHCP protocol for conveying route information to the nodes. 139 3. DHCPv6 Based Solution 141 A DHCPv6 based solution allows an operator an on demand and node 142 specific means of configuring static routing information. Such a 143 solution also fits into network environments where the operator 144 prefers to manage RG configuration information from a centralized 145 DHCP server. [I-D.troan-multihoming-without-nat66] provides 146 additional background to the need for a DHCPv6 solution to the 147 problem. 149 In terms of the high level operation of the solution defined in this 150 draft, a DHCPv6 client interested in obtaining routing information 151 request the route option using the DHCPv6 Option Request Option (ORO) 152 sent to a server. A Server, when configured to do so, provides the 153 requested route information as part of a nested options structure 154 covering; the next-hop address; the destination prefix; the route 155 metric; any additional options applicable to the destination or next- 156 hop. The overall DHCPv6 design follow a similar approach to that 157 used in the design of the IA_NA, IA_TA and IA_PD options in [RFC3633] 159 4. DHCPv6 Route Option 161 A DHCPv6 client interested in obtaining routing information includes 162 the OPTION_IA_RT in its DHCPv6 Option Request Option (ORO) sent to a 163 server. A Server, when configured to do so, provides the requested 164 route information using the OPTION_IA_RT option. So as to allow the 165 route option to be both extensible, as well as conveying detailed 166 info for routes, use is made of a nested options structure. An IA_RT 167 conveys one or more OPTION_NEXT_HOP options that specify the IPv6 168 next hop addresses. Each OPTION_NEXT_HOP conveys in turn one or more 169 OPTION_RT_PREFIX options that represents the IPv6 destination 170 prefixes reachable via the given next hop. The Formats of the 171 OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX are defined in the 172 following sub-sections 173 The DHCPv6 Route Option format borrows from the principles of the 174 Route Information Option defined in [RFC4191]. One notable exception 175 with respect to [RFC4191] is however that a Route Lifetime element is 176 not defined. The information conveyed by the DHCPv6 Route Option is 177 considered valid until changed or refreshed by general events that 178 trigger DHCPv6 or route table state changes on a node, thus not 179 requiring a specific route lifetime. In the event that it is desired 180 for the client to request a refresh of the route information (and 181 other stateless DHCPv6 options), use of the generic DHCPv6 182 Information Refresh Time Option, as specified in [RFC4242] is 183 envisaged. 185 4.1. DHCPv6 Route Option Format 187 To separate routing information from other options conveyed in a 188 DHCPv6 message, the DHCPv6 Route Option is defined and is used to 189 convey to a client one or more IPv6 routes. Each IPv6 route consists 190 of an IPv6 next hop address, an IPv6 destination prefix (a.k.a. The 191 destination subnet), and a host preference value for the route. 192 Elements of such route (e.g. Next hops and prefixes associated with 193 them) are conveyed in IA_RT's options, rather than in the IA_RT 194 option itself. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | OPTION_IA_RT | option-len | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | | 201 . IA_RT options . 202 . . 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 1: IPv6 Routes Option Format 207 option-code: OPTION_IA_RT (TBD). 209 option-len: Length of the IA_RT options field. 211 IA_RT options: Options associated with this IA_RT. This includes, 212 but is not limited to, OPTION_NEXT_HOP options that specify 213 next hop addresses. 215 The Route option MUST NOT appear in the following DHCPv6 messages: 216 Solicit, Request, Renew, Rebind, Information-Request. The Route 217 Option MAY appear in ADVERTISE and REPLY messages. 219 Discussion: Traditionally, grouping options (IA_NA, IA_TA and IA_RD) 220 contain an identifier field (IAID) that must be unique among 221 identifiers generated by one client. It is used to differentiate 222 between several options of the same type (e.g. several IA_NA options) 223 that may be used simultaneously. However, it is assumed that client 224 will never use more than one IA_RT option therefore such an 225 identifier is not needed. 227 4.2. Next Hop Option Format 229 The Next Hop Option defines the IPv6 address of the next hop, usually 230 corresponding to a specific next-hop router. For each next hop 231 address there are one or more prefixes reachable via that next hop. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | OPTION_NEXT_HOP | option-len | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | | 238 | IPv6 Next Hop Address | 239 | (16 octets) | 240 | | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | | 243 | NEXT_HOP options | 244 . . 245 . . 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 Figure 2: IPv6 Route Option Format 250 option-code: OPTION_NEXT_HOP (TBD). 252 option-len: 16 + Length of NEXT_HOP options field. 254 IPv6 Next Hop Address: 16 octet long field that specified IPv6 255 address of the next hop. 257 NEXT_HOP options: Options associated with this Next Hop. This 258 includes, but is not limited to, OPTION_RT_PREFIX options 259 that specify prefixes available via specified next hop. 261 4.3. Route Prefix Option Format 263 The Route Prefix Option is used to convey information about a single 264 prefix that represents the destination network. The Route Prefix 265 Option is used as a sub-option in the previously defined Next Hop 266 Option. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | OPTION_RT_PREFIX | option-len | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Prefix-Length | Metric | | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 275 | Prefix | 276 | (16 octets) | 277 | | 278 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | | | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 281 . . 282 . RT_PREFIX options . 283 . . 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 Figure 3: Route Prefix Option Format 288 option-code: OPTION_RT_PREFIX (TBD). 290 option-len: 18 + length of RT_PREFIX options. 292 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 293 Prefix. The value ranges from 0 to 128. This field 294 represents the number of valid leading bits in the prefix. 296 Metric: Route Metric. 8-bit signed integer. The Route Metric 297 indicates whether to prefer the next hop associated with 298 this prefix over others, when multiple identical prefixes 299 (for different next hops) have been received. 301 Prefix: Fixed length 16 octet field containing an IPv6 prefix. 303 RT_PREFIX options: Options specific to this particular prefix. 305 5. DHCPv6 Server Behavior 307 When configured to do so s DHCPv6 server shall provide the Routes 308 Option in ADVERTISE and REPLY messages sent to a client that 309 requested the route option. Each Next Hop Option sent by the server 310 must convey at least one Route Prefix Option. 312 Servers SHOULD NOT send Route Option to clients that did not 313 explicitly requested it, using the ORO. 315 Servers MUST NOT send Route Option in messages other than ADVERTISE 316 or REPLY. 318 Servers MAY also include Status Code Option, defined in Section 22.13 319 of the [RFC3315] to indicate the status of the operation. 321 Servers MUST include the Status Code Option, if the requested routing 322 configuration was not successful and SHOULD use status codes as 323 defined in [RFC3315] and [RFC3633]. 325 Discussion: How should server indicate that there are no specific 326 routes for this particular client? The reasonable behavior is to 327 return empty IA_RT option, possibly with Status Code indicating 328 Success. Another approach could be to simply not return any IA_RT 329 option. 331 6. DHCPv6 Client Behavior 333 A DHCPv6 client compliant with this specification MUST request the 334 Route Option (option value TBD) in an Option Request Option (ORO) in 335 the following messages: Solicit, Request, Renew, Rebind, Information- 336 Request or Reconfigure. The messages are to be sent as and when 337 specified by [RFC3315]. 339 When processing a received Route Option a client MUST substitute a 340 received 0::0 value in the Next Hop Option with the source IPv6 341 address of the received DHCPv6 message. It MUST also associate a 342 received Link Local next hop addresses with the interface on which 343 the client received the DHCPv6 message containing the route option. 344 Such a substitution and/or association is useful in cases where the 345 DHCPv6 server operator does not directly know the IPv6 next-hop 346 address, other than knowing it is that of a DHCPv6 relay agent on the 347 client LAN segment. DHCPv6 Packets relayed to the client are sourced 348 by the relay using this relay's IPv6 address, which could be a link 349 local address. 351 The Client MAY refresh assigned route information periodically. The 352 generic DHCPv6 Information Refresh Time Option, as specified in 353 [RFC4242], can be used when it is desired for the client to 354 periodically refresh of route information. 356 The routes conveyed by the Route Option should be considered as 357 complimentary to any other static route learning and maintenance 358 mechanism used by, or on the client with one modification: The client 359 MUST flush DHCPv6 installed routes following a link flap event on the 360 DHCPv6 client interface over which the routes were installed. This 361 requirement is necessary to automate the flushing of routes for 362 clients that may move to a different network. 364 7. IANA Considerations 366 A DHCPv6 option number of TBD for the introduced Route Option. IANA 367 is requested to allocate three DHCPv6 option codes referencing this 368 document: OPTION_IA_RT, OPTION_NEXT_HOP and OPTION_RT_PREFIX. 370 8. Security Considerations 372 The overall security considerations discussed in [RFC3315] apply also 373 to this document. The Route option could be used by malicious 374 parties to misdirect traffic sent by the client either as part of a 375 denial of service or man-in-the-middle attack. An alternative denial 376 of service attack could also be realized by means of using the route 377 option to overflowing any known memory limitations of the client, or 378 to exceed the client's ability to handle the number of next hop 379 addresses. 381 Neither of the above considerations are new and specific to the 382 proposed route option. The mechanisms identified for securing DHCPv6 383 as well as reasonable checks performed by client implementations are 384 deemed sufficient in addressing these problems. 386 9. Contributors and .Acknowledgements 388 This document would not have been possible without the significant 389 support and contribution to its development provided by: Arifumi 390 Matsumoto, Hui Deng, Richard Johnson, Zhen Cao. 392 The authors would like to thank Alfred Hines, Ralph Droms, Ted Lemon, 393 Ole Troan, Dave Oran and Dave Ward for their comments and useful 394 suggestions. 396 10. References 398 10.1. Normative References 400 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 401 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 404 and M. Carney, "Dynamic Host Configuration Protocol for 405 IPv6 (DHCPv6)", RFC 3315, July 2003. 407 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 408 Host Configuration Protocol (DHCP) version 6", RFC 3633, 409 December 2003. 411 10.2. Informative References 413 [I-D.troan-multihoming-without-nat66] 414 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 415 Wing, "IPv6 Multihoming without Network Address 416 Translation", draft-troan-multihoming-without-nat66-01 417 (work in progress), July 2010. 419 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 420 Static Route Option for Dynamic Host Configuration 421 Protocol (DHCP) version 4", RFC 3442, December 2002. 423 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 424 More-Specific Routes", RFC 4191, November 2005. 426 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 427 Time Option for Dynamic Host Configuration Protocol for 428 IPv6 (DHCPv6)", RFC 4242, November 2005. 430 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 431 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 432 September 2007. 434 Authors' Addresses 436 Wojciech Dec (editor) 437 Cisco Systems 438 Haarlerbergweg 13-19 439 1101 CH Amsterdam 440 The Netherlands 442 Email: wdec@cisco.com 444 Tomasz Mrugalski 445 Gdansk University of Technology 446 Storczykowa 22B/12 447 Gdansk 80-177 448 Poland 450 Phone: +48 698 088 272 451 Email: tomasz.mrugalski@eti.pg.gda.pl 452 Tao Sun 453 China Mobile 454 Unit2, 28 Xuanwumenxi Ave 455 Beijing, Xuanwu District 100053 456 China 458 Phone: 459 Email: suntao@chinamobile.com 461 Behcet Sarikaya 462 Huawei USA 463 1700 Alma Dr. Suite 500 464 Plano, TX 75075 465 United States 467 Phone: +1 972-509-5599 468 Fax: 469 Email: sarikaya@ieee.org 470 URI: