idnits 2.17.1 draft-sarikaya-dhc-dhcpv6-raoptions-sadr-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 (June 20, 2014) is 3597 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) == Unused Reference: 'RFC3442' is defined on line 669, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-21) exists of draft-ietf-dhc-sedhcpv6-03 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-01 == Outdated reference: A later version (-04) exists of draft-sarikaya-6man-next-hop-ra-02 -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 6204 (Obsoleted by RFC 7084) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track June 20, 2014 5 Expires: December 22, 2014 7 DHCPv6 Route Options for Source Address Dependent Routing 8 draft-sarikaya-dhc-dhcpv6-raoptions-sadr-00 10 Abstract 12 This document describes DHCPv6 Route Options for provisioning IPv6 13 routes on DHCPv6 client nodes for source address dependent routing. 14 Using these options, an operator can configure multi-homed nodes 15 where other means of route configuration may be impractical. 17 Requirements Language 19 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 20 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 21 document are to be interpreted as described in RFC 2119 [RFC2119]. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 22, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Default route configuration . . . . . . . . . . . . . . . 3 60 2.2. Configuring on-link routes . . . . . . . . . . . . . . . 4 61 2.3. Deleting obsolete route . . . . . . . . . . . . . . . . . 4 62 2.4. Applicability to routers . . . . . . . . . . . . . . . . 5 63 2.5. Updating Routing Information . . . . . . . . . . . . . . 5 64 2.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. DHCPv6 Route Options . . . . . . . . . . . . . . . . . . . . 6 66 3.1. Route Prefix Option Format . . . . . . . . . . . . . . . 7 67 3.2. Next Hop Option Format . . . . . . . . . . . . . . . . . 8 68 3.3. Source Address/Prefix Option Format . . . . . . . . . . . 9 69 4. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . 10 70 5. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . 11 71 5.1. Conflict resolution . . . . . . . . . . . . . . . . . . . 12 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 74 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 75 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 77 9.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 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 provides 88 network administrators with a new set of tools to handle multi-homed 89 host topologies and influence the route selection by the host. This 90 ND based mechanism however is sub optimal or impractical in some 91 multi-homing scenarios, e.g. source address dependent routing. Both 92 Router Advertisement options [I-D.sarikaya-6man-next-hop-ra] and 93 DHCPv6 can be used. In networks that deployed DHCPv6, the use of 94 DHCPv6 [RFC3315] is seen to be more viable. 96 DHCPv6 Route Options defined in this document can be used to 97 configure fixed and mobile nodes in multi-homed scenarios with route 98 information and next hop address. Different scenarios exist such as 99 the node is simultaneously connected to multiple access network of 100 e.g. WiFi and 3G. The node may also be connected to more than one 101 gateway. Such connectivity may be realized by means of dedicated 102 physical or logical links that may also be shared with other users 103 nodes such as in residential access networks. 105 A document defining topologies and in general providing an overview 106 of the issue of source address dependent routing is TBD. 108 The solution presented in this document is part of the network 109 configuration information. A consistent set of network configuration 110 is defined as Provisioning Domain (PvD) [I-D.ietf-mif-mpvd-arch]. 111 PvDs or so-called explicit PvDs may include information related to 112 more than one interfaces as is the case in this document. It is 113 important to note that the node has a trust relationship with the 114 PvD, in such a case, it is called trusted PvD. The trust is 115 established using authorization and authentication between the node 116 that is using the PvD configuration and the source that provided that 117 configuration. In this document, we assume that DHCP server can 118 provide trusted PvDs to the hosts. 120 2. DHCPv6 Based Solution 122 A DHCPv6 based solution allows an operator an on demand and node 123 specific means of configuring static routing information. Such a 124 solution also fits into network environments where the operator 125 prefers to manage Residential Gateway (RG) configuration information 126 from a centralized DHCP server. [RFC7157] provides additional 127 background to the need for a DHCPv6 solution to the problem. 129 In terms of the high level operation of the solution defined in this 130 draft, a DHCPv6 client interested in obtaining routing information 131 requests the route options using the DHCPv6 Option Request Option 132 (ORO) sent to a server. A Server, when configured to do so, provides 133 the requested route information as part of a nested options structure 134 covering; the next-hop address; the destination prefix; the route 135 metric; any additional options applicable to the destination or next- 136 hop. 138 2.1. Default route configuration 140 A non-trustworthy network may be available at the same time as a 141 trustworthy network, with the risk of bad consequences if the host 142 gets confused between the two. These are basically the two models 143 for hosts with multiple interfaces, both of which are valid, but 144 which are incompatible with each other. In the first model, an 145 interface is connected to something like a corporate network, over a 146 Virtual Private Network (VPN). This connection is trusted because it 147 has been authenticated. Routes obtained over such a connection can 148 probably be trusted, and indeed it may be important to use those 149 routes. This is because in the VPN case, you may also be connected 150 to a network that's offered you a default route, and you could be 151 attacked over that connection if you attempt to connect to resources 152 on the enterprise network over it. 154 On the other, non-trustworthy network scenario, none of the networks 155 to which the host is connected are meaningfully more or less 156 trustworthy. In this scenario, the untrustworthy network may hand 157 out routes to other hosts, e.g. those in the VPN going through some 158 malicious nodes. This will have bad consequences because the host's 159 traffic intended for the corporate VPN may be hijacked by the 160 intermediate nodes. 162 DHCPv6 options described in this document can be used to install the 163 routes. However, the use of such a technique makes sense only in the 164 former case above, i.e. trusted network. So the host MUST have an 165 authenticated connection to the network it connects so that DHCPv6 166 route options can be trusted before establishing routes. 168 Server MUST NOT define more than one default route. 170 2.2. Configuring on-link routes 172 Server may also configure on-link routes, i.e. routes that are 173 available directly over the link, not via routers. To specify on- 174 link routes, server MAY include RTPREFIX option directly in Advertise 175 and Reply messages. 177 2.3. Deleting obsolete route 179 There are two mechanisms that allow removing a route. Each defined 180 route has a route lifetime. If specific route is not refreshed and 181 its timer reaches 0, client MUST remove corresponding entry from 182 routing table. 184 In cases, where faster route removal is needed, server SHOULD return 185 RT_PREFIX option with route lifetime set to 0. Client that receives 186 RT_PREFIX with route lifetime set to 0 MUST remove specified route 187 immediately, even if its previous lifetime did not expire yet. 189 2.4. Applicability to routers 191 Contrary to Router Adverisement mechanism, defined in [RFC4861] that 192 explicitly limits configuration to hosts, routing configuration over 193 DHCPv6 defined in this document may be used by both hosts and 194 routers. (This limitation of RA mechanism was partially lifted by 195 W-1 requirement formulated in [RFC6204].) 197 One of the envisaged usages for this solution are residential 198 gateways (RG) or Customer Premises Equipment (CPE). Those devices 199 very often perform routing. It may be useful to configure routing on 200 such devices over DHCPv6. One example of such use may be a class of 201 premium users that are allowed to use dedicated router that is not 202 available to regular users. 204 2.5. Updating Routing Information 206 Network configuration occassionally changes, due to failure of 207 existing hardware, migration to newer equipment or many other 208 reasons. Therefore there a way to inform clients that routing 209 information have changed is required. 211 There are several ways to inform clients about new routing 212 information. Every client SHOULD periodically refresh its 213 configuration, according to Information Refresh Time Option, so 214 server may send updated information the next time client refreshes 215 its information. New routes may be configured at that time. As 216 every route has associated lifetime, client is required to remove its 217 routes when this timer expires. This method is particularly useful, 218 when migrating to new router is undergoing, but old router is still 219 available. 221 Server MAY also announce routes via soon to be removed router with 222 lifetimes set to 0. This will cause the client to remove its routes, 223 despite the fact that previously received lifetime may not yet 224 expire. 226 Aforementioned methods are useful, when there is no urgent need to 227 update routing information. Bound by timer set by value of 228 Information Refresh Time Option, clients may use outdated routing 229 information until next scheduled renewal. Depending on configured 230 value this delay may be not acceptable in some cases. In such 231 scenarios, administrators are advised to use RECONFIGURE mechanism, 232 defined in [RFC3315]. Server transmits RECONFIRGURE message to each 233 client, thus forcing it to immediately start renewal process. 235 See also Section 2.6 about limitations regarding dynamic routing. 237 2.6. Limitations 239 Defined mechanism is not intended to be used as a dynamic routing 240 protocol. It should be noted that proposed mechanism cannot 241 automatically detect routing changes. In networks that use dynamic 242 routing and also employ this mechanism, clients may attempt using 243 routes configured over DHCPv6 even though routers or specific routes 244 ceased to be available. This may cause black hole routing problem. 245 Therefore it is not recommended to use this mechanism in networks 246 that use dynamic routing protocols. This mechanism SHOULD NOT be 247 used in such networks, unless network operator can provide a way to 248 update DHCP server information in case of router availability 249 changes. 251 Discussion: It should be noted that DHCPv6 server is not able to 252 monitor health of existing routers. As there are currently more than 253 60 options defined for DHCPv6, it is infeasible to implement 254 mechanism that would monitor huge set of services and stop announcing 255 its availability in case of service outage. Therefore in case of 256 prolonged unavailability human interverntion is required to change 257 DHCPv6 server configuration. If that is considered a problem, 258 network administrators should consider using other alternatives, like 259 RA and ND mechanisms (see [RFC4861]). 261 3. DHCPv6 Route Options 263 A DHCPv6 client interested in obtaining routing information includes 264 the NEXT_HOP and RT_PREFIX options as part of its Option Request 265 Option (ORO) in messages directed to a server (as allowed by 266 [RFC3315], i.e. Solicit, Request, Renew, Rebind or Information- 267 request messages). A Server, when configured to do so, provides the 268 requested route information using zero, one or more NEXT_HOP options 269 in messages sent in response (Advertise, and Reply). So as to allow 270 the route options to be both extensible, as well as conveying 271 detailed info for routes, use is made of a nested options structure. 272 Server sends one or more NEXT_HOP options that specify the IPv6 next 273 hop addresses. Each NEXT_HOP option conveys in turn zero, one or 274 more RT_PREFIX options that represents the IPv6 destination prefixes 275 reachable via the given next hop. Server includes RT_PREFIX directly 276 in message to indicate that given prefix is available directly on- 277 link. Server MAY send a single NEXT_HOP without any RT_PREFIX 278 suboptions or with RT_PREFIX that contains ::/0 to indicate available 279 default route. The Formats of the NEXT_HOP and RT_PREFIX options are 280 defined in the following sub-sections. 282 The DHCPv6 Route Options format borrows from the principles of the 283 Route Information Option defined in [RFC4191]. 285 3.1. Route Prefix Option Format 287 The Route Prefix Option is used to convey information about a single 288 prefix that represents the destination network. The Route Prefix 289 Option is used as a sub-option in the previously defined Next Hop 290 Option. It may also be sent directly in message to indicate that 291 route is available directly on-link. 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | OPTION_RT_PREFIX | option-len | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | Route lifetime | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Prefix-Length | Metric | | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 302 | Prefix | 303 | (up to 16 octets) | 304 | | 305 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 1: Route Prefix Option Format 311 option-code: OPTION_RT_PREFIX (TBD2). 313 option-len: Length of the Route Prefix option including all its sub- 314 options. 316 Route lifetime 32-bit unsigned integer. Specifies lifetime of the 317 route information, expressed in seconds (relative to the 318 time the packet is sent). There are 2 special values 319 defined. 0 means that route is no longer valid and must be 320 removed by clients. A value of all one bits (0xffffffff) 321 represents infinity. means infinity. 323 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 324 Prefix. The value ranges from 0 to 128. This field 325 represents the number of valid leading bits in the prefix. 327 Resvd: Reserved field. Server MUST set this value to zero and 328 client MUST ignore its content. 330 Metric: Route Metric. 8-bit signed integer. The Route Metric 331 indicates whether to prefer the next hop associated with 332 this prefix over others, when multiple identical prefixes 333 (for different next hops) have been received. 335 Prefix: a variable size field that specifies Rule IPv6 prefix. 336 Length of the field is defined by prefix6-len field and is 337 rounded up to the nearest octet boundary (if case when 338 Prefix Length is not divisible by 8). In such case 339 additional padding bits must be zeroed. 341 Values for metric field have meaning based on the value, i.e. higher 342 value indicates higher preference. 344 3.2. Next Hop Option Format 346 Each IPv6 route consists of an IPv6 next hop address, an IPv6 347 destination prefix (a.k.a. the destination subnet), and a host 348 preference value for the route. Elements of such route (e.g. Next 349 hops and prefixes associated with them) are conveyed in NEXT_HOP 350 option that contains RT_PREFIX suboptions. 352 The Next Hop Option defines the IPv6 address of the next hop, usually 353 corresponding to a specific next-hop router. For each next hop 354 address there can be zero, one or more prefixes reachable via that 355 next hop. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | OPTION_NEXT_HOP | option-len | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | | 363 | IPv6 Next Hop Address | 364 | (16 octets) | 365 | | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | | 368 | NEXT_HOP sub-options | 369 . . 370 . . 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 Figure 2: IPv6 Next Hop Option Format 375 option-code: OPTION_NEXT_HOP (TBD1). 377 option-len: 16 + Length of NEXT_HOP options field. 379 IPv6 Next Hop Address: 16 octet long field that specified IPv6 380 address of the next hop. 382 NEXT_HOP options: Options associated with this Next Hop. This 383 includes, but is not limited to, zero, one or more 384 RT_PREFIX options that specify prefixes reachable through 385 the given next hop. 387 NEXT_HOP options: Options associated with this Next Hop. This 388 includes, but is not limited to, zero, one or more 389 SOURCE_AP and RT_PREFIX options that specify prefixes 390 reachable through the given next hop. 392 3.3. Source Address/Prefix Option Format 394 Each IPv6 route consists of an IPv6 next hop address, an IPv6 395 destination prefix (a.k.a. the destination subnet), and a host 396 preference value for the route. Elements of such route (e.g. Next 397 hops and prefixes associated with them) are conveyed in NEXT_HOP 398 option that contains RT_PREFIX suboptions. 400 The Source Address/Prefix Option defines the source IPv6 prefix/ 401 address that are assigned from the prefixes that belong to this next 402 hop. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | OPTION_SOURCE_AP | option-len | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Prefix-Length | Reserved | | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 411 | IPv6 Source Address/Prefix | 412 | (up to 16 octets) | 413 | | 414 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 3: IPv6 Source Address/Prefix Option Format 420 option-code: OPTION_SOURCE_AP (TBD1). 422 option-len: 16 + Length of SOURCE_AP options field. 424 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 425 Prefix. The value ranges from 0 to 128. This field 426 represents the number of valid leading bits in the prefix. 427 In case of source address this field is set to 132. 429 Resvd: Reserved field. Server MUST set this value to zero and 430 client MUST ignore its content. 432 IPv6 Source Address/Prefix: 16 octet long field that specified IPv6 433 source address or source prefix. 435 4. DHCPv6 Server Behavior 437 When configured to do so, a DHCPv6 server shall provide the NEXT_HOP 438 and RT_PREFIX Options in ADVERTISE and REPLY messages sent to a 439 client that requested the route option. Each Next Hop Option sent by 440 the server must convey at least one Route Prefix Option. 442 Server includes NEXT_HOP option with possible RT_PREFIX suboptions to 443 designate that specific routes are available via routers. Server 444 includes RT_PREFIX options in Next Hop sub-options directly in 445 Advertise and Reply messages to inform that specific routes are 446 available directly on-link. 448 If there is more than one route available via specific next hop, 449 server MUST send only one NEXT_HOP for that next hop, which contains 450 multiple RT_PREFIX options. Server MUST NOT send more than one 451 identical (i.e. with equal next hop address field) NEXT_HOP option. 453 When configured to do so, a DHCPv6 server shall send one or more 454 NEXT_HOP options that contain one or more source addresses Figure 3 455 included in the Next Hop sub-options field. Each Next Hop Address 456 may be associated with zero, one or more Source Prefix that represent 457 the source addresses that are assigned from the prefixes that belong 458 to this next hop. The Next Hop sub-options field MAY contain Route 459 Prefix options that represent the IPv6 destination prefixes reachable 460 via the given next hop as defined in Figure 2. When configured to do 461 so, a DHCPv6 server shall send NEXT_HOP option with Route Prefix 462 option and Source Prefix in the message in the Next Hop sub-options 463 field to indicate that given prefix is available directly on-link and 464 that any source addresses derived from the source prefix will not be 465 subject to ingress filtering on these routes supported by these next 466 hops. 468 When configured to do so, a DHCPv6 server shall send one or more 469 NEXT_HOP option that specify the IPv6 next hop addresses and source 470 address. Each Next Hop Address option may be associated with zero, 471 one or more Source Address that represent the source addresses that 472 are assigned from the prefixes that belong to this next hop. The 473 Next Hop sub-options field shall contain Source Address Figure 3 and 474 Route Prefix options Figure 1 that represent the IPv6 destination 475 prefixes reachable via the given next hop. DHCPv6 server shall 476 include Next Hop Address with Source Address and Route Prefix option 477 in Next Hop sub-options field in the message to indicate that given 478 prefix is available directly on-link and that the source address will 479 not be subject to ingress filtering. For the Source Address, Source 480 Address/Prefix option Figure 3 is used with prefix length set to 128. 482 Each Next Hop Address may be associated with zero, one or more Source 483 Prefix that represent the source addresses that are assigned from the 484 prefixes that belong to this next hop. The option MAY contain Route 485 Prefix options that represent the IPv6 destination prefixes reachable 486 via the given next hop. DHCP server shall include Next Hop Address 487 with Route Prefix option in Next Hop sub-option field defined in 488 Figure 2 in the message to indicate that given prefix is available 489 directly on-link. To indicate that any source addresses derived from 490 the source prefix will not be subject to ingress filtering on these 491 routes supported by these next hops DHCPv6 server shall send two 492 options, Next Hop option with Route Prefix option in Next Hop options 493 field and a Source Prefix option defined in Figure 3. 495 Servers SHOULD NOT send NEXT_HOP or RT_PREFIX to clients that did not 496 explicitly requested it, using the ORO. 498 Servers MUST NOT send NEXT_HOP or RT_PREFIX in messages other than 499 ADVERTISE or REPLY. 501 Servers MAY also include Status Code Option, defined in Section 22.13 502 of the [RFC3315] to indicate the status of the operation. 504 Servers MUST include the Status Code Option, if the requested routing 505 configuration was not successful and SHOULD use status codes as 506 defined in [RFC3315] and [RFC3633]. 508 The maximum number of routing information in one DHCPv6 message 509 depend on the maximum DHCPv6 message size defined in [RFC3315] 511 5. DHCPv6 Client Behavior 513 A DHCPv6 client compliant with this specification MUST request the 514 NEXT_HOP and RT_PREFIX Options in an Option Request Option (ORO) in 515 the following messages: Solicit, Request, Renew, Rebind, and 516 Information-Request. The messages are to be sent as and when 517 specified by [RFC3315]. 519 When processing a received Route Options a client MUST substitute a 520 received 0::0 value in the Next Hop Option with the source IPv6 521 address of the received DHCPv6 message. It MUST also associate a 522 received Link Local next hop addresses with the interface on which 523 the client received the DHCPv6 message containing the route option. 524 Such a substitution and/or association is useful in cases where the 525 DHCPv6 server operator does not directly know the IPv6 next-hop 526 address, other than knowing it is that of a DHCPv6 relay agent on the 527 client LAN segment. DHCPv6 Packets relayed to the client are sourced 528 by the relay using this relay's IPv6 address, which could be a link 529 local address. 531 The Client SHOULD refresh assigned route information periodically. 532 The generic DHCPv6 Information Refresh Time Option, as specified in 533 [RFC4242], can be used when it is desired for the client to 534 periodically refresh of route information. 536 The routes conveyed by the Route Option should be considered as 537 complimentary to any other static route learning and maintenance 538 mechanism used by, or on the client with one modification: The client 539 MUST flush DHCPv6 installed routes following a link flap event on the 540 DHCPv6 client interface over which the routes were installed. This 541 requirement is necessary to automate the flushing of routes for 542 clients that may move to a different network. 544 Client MUST confirm that routers announced over DHCPv6 are reachable, 545 using one of methods suitable for specific network type. The most 546 common mechanism is Neighbor Unreachability Detection (NUD), 547 specified in [RFC4861]. Client SHOULD use NUD to verify that 548 received routers are reachable before adjusting its routing tables. 549 Client MAY use other reachability verification mechanisms specific to 550 used network technology. To avoid potential long-lived routing black 551 holes, client MAY periodically confirm that router is still 552 reachable. 554 5.1. Conflict resolution 556 Information received via Route Options over DHCPv6 MUST be treated 557 equally to routing information obtained via other sources. In 558 particular, from the RA perspective, DHCPv6 provisioning should be 559 treated as if yet another RA was received. Preference field should 560 be taken into consideration during route information processing. In 561 particular, administrators are encouraged to read [RFC4191], 562 Section 4.1 for guidance. 564 To facilitate information merge between DHCPv6 and RA, DHCPv6 options 565 in this document convey the same information specified in 566 [I-D.sarikaya-6man-next-hop-ra]. 568 To facilitate information merge between DHCPv6 and RA, DHCPv6 option 569 RT_PREFIX conveys the same information specified in [RFC4191] albeit 570 on-wire format is slightly different. The differences are: 572 Metric field is an 8-bit field that conveys the route metric. 574 RIO uses 128-length prefix field, while DHCPv6 option uses variable 575 prefix length. That difference is used to minimize packet size as it 576 avoid transmitting zeroed octets. Despite slightly different 577 encoding, delivered information is exactly the same. 579 If prefix is available directly on-link, Route Prefix option is 580 conveyed directly in DHCPv6 message, not within Next Hop option. 581 That feature is considered a superset, compared to RIO. 583 In short, when DHCPv6 RT_PREFIX option is used alone this 584 specification works in compatibility mode with [RFC4191]. 586 6. IANA Considerations 588 IANA is kindly requested to allocate DHCPv6 option code TBD1 to the 589 OPTION_NEXT_HOP, TBD2 to OPTION_RT_PREFIX, TBD3 to OPTION_SOURCE_AP. 590 All values should be added to the DHCPv6 option code space defined in 591 Section 24.3 of [RFC3315]. 593 7. Security Considerations 595 The overall security considerations discussed in [RFC3315] apply also 596 to this document. The Route option could be used by malicious 597 parties to misdirect traffic sent by the client either as part of a 598 denial of service or man-in-the-middle attack. An alternative denial 599 of service attack could also be realized by means of using the route 600 option to overflowing any known memory limitations of the client, or 601 to exceed the client's ability to handle the number of next hop 602 addresses. 604 Neither of the above considerations are new and specific to the 605 proposed route option. The mechanisms identified for securing DHCPv6 606 as well as reasonable checks performed by client implementations are 607 deemed sufficient in addressing these problems. 609 It is essential that clients verify that announced routers are indeed 610 reachable, as specified in Section 5. Failing to do so may create 611 black hole routing problem. 613 This mechanism may introduce severe problems if deployed in networks 614 that use dynamic routing protocols. See Section 2.6 for details. 616 DHCPv6 becomes a complete provisioning protocol with this mechanism, 617 i.e. all necessary configuration parameters may be delivered using 618 DHCPv6 only. It was suggested that in some cases this may lead to 619 decision of disabling RA. While RA-less networks could offer lower 620 operational expenses and protection against rogue RAs, they would not 621 work with nodes that do not support this feature. Therefore such 622 decision is not recommended, unless all effects are carefully 623 analyzed. It is worth noting that disabling RA support in hosts 624 would solve rogue RA problem, it would in fact only change the issue 625 into rogue DHCPv6 problem. That is somewhat beneficial, however, as 626 rogue RA may affect all nodes immediately while rogue DHCPv6 server 627 will affect only new nodes, that boot up after rogue server manifests 628 itself. 630 Reader is also encouraged to read DHCPv6 security considerations 631 document [I-D.ietf-dhc-sedhcpv6]. 633 8. Acknowledgements 635 The author acknowledges the work done by his co-authors in MIF WG 636 draft entitled DHCPv6 Route Options. 638 9. References 640 9.1. Normative References 642 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 643 Requirement Levels", BCP 14, RFC 2119, March 1997. 645 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 646 and M. Carney, "Dynamic Host Configuration Protocol for 647 IPv6 (DHCPv6)", RFC 3315, July 2003. 649 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 650 Host Configuration Protocol (DHCP) version 6", RFC 3633, 651 December 2003. 653 9.2. Informative References 655 [I-D.ietf-dhc-sedhcpv6] 656 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 657 DHCPv6 with Public Key", draft-ietf-dhc-sedhcpv6-03 (work 658 in progress), June 2014. 660 [I-D.ietf-mif-mpvd-arch] 661 Anipko, D., "Multiple Provisioning Domain Architecture", 662 draft-ietf-mif-mpvd-arch-01 (work in progress), May 2014. 664 [I-D.sarikaya-6man-next-hop-ra] 665 Sarikaya, B., "IPv6 RA Options for Next Hop Routes", 666 draft-sarikaya-6man-next-hop-ra-02 (work in progress), 667 June 2014. 669 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 670 Static Route Option for Dynamic Host Configuration 671 Protocol (DHCP) version 4", RFC 3442, December 2002. 673 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 674 More-Specific Routes", RFC 4191, November 2005. 676 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 677 Time Option for Dynamic Host Configuration Protocol for 678 IPv6 (DHCPv6)", RFC 4242, November 2005. 680 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 681 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 682 September 2007. 684 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 685 Troan, "Basic Requirements for IPv6 Customer Edge 686 Routers", RFC 6204, April 2011. 688 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 689 Wing, "IPv6 Multihoming without Network Address 690 Translation", RFC 7157, March 2014. 692 Author's Address 694 Behcet Sarikaya 695 Huawei USA 696 5340 Legacy Dr. 697 Plano, TX 75024 698 United States 700 Phone: +1 972-509-5599 701 Email: sarikaya@ieee.org