idnits 2.17.1 draft-sarikaya-dhc-6man-dhcpv6-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 (December 16, 2014) is 3418 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: 'I-D.ietf-mif-mpvd-dhcp-support' is defined on line 666, but no explicit reference was found in the text == Unused Reference: 'RFC3442' is defined on line 681, 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-05 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-07 == Outdated reference: A later version (-02) exists of draft-ietf-mif-mpvd-dhcp-support-00 == Outdated reference: A later version (-12) exists of draft-sarikaya-6man-sadr-overview-03 -- 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 (~~), 7 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 December 16, 2014 5 Expires: June 19, 2015 7 DHCPv6 Route Options for Source Address Dependent Routing 8 draft-sarikaya-dhc-6man-dhcpv6-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 June 19, 2015. 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 presented in 107 [I-D.sarikaya-6man-sadr-overview]. 109 The solution presented in this document is part of the network 110 configuration information. A consistent set of network configuration 111 is defined as Provisioning Domain (PvD) [I-D.ietf-mif-mpvd-arch]. 112 PvDs or so-called explicit PvDs may include information related to 113 more than one interfaces as is the case in this document. It is 114 important to note that the node has a trust relationship with the 115 PvD, in such a case, it is called trusted PvD. The trust is 116 established using authorization and authentication between the node 117 that is using the PvD configuration and the source that provided that 118 configuration. In this document, we assume that DHCP server can 119 provide trusted PvDs to the hosts. 121 2. DHCPv6 Based Solution 123 A DHCPv6 based solution allows an operator an on demand and node 124 specific means of configuring static routing information. Such a 125 solution also fits into network environments where the operator 126 prefers to manage Residential Gateway (RG) configuration information 127 from a centralized DHCP server. [RFC7157] provides additional 128 background to the need for a DHCPv6 solution to the problem. 130 In terms of the high level operation of the solution defined in this 131 draft, a DHCPv6 client interested in obtaining routing information 132 requests the route options using the DHCPv6 Option Request Option 133 (ORO) sent to a server. A Server, when configured to do so, provides 134 the requested route information as part of a nested options structure 135 covering; the next-hop address; the destination prefix; the route 136 metric; any additional options applicable to the destination or next- 137 hop. 139 2.1. Default route configuration 141 A non-trustworthy network may be available at the same time as a 142 trustworthy network, with the risk of bad consequences if the host 143 gets confused between the two. These are basically the two models 144 for hosts with multiple interfaces, both of which are valid, but 145 which are incompatible with each other. In the first model, an 146 interface is connected to something like a corporate network, over a 147 Virtual Private Network (VPN). This connection is trusted because it 148 has been authenticated. Routes obtained over such a connection can 149 probably be trusted, and indeed it may be important to use those 150 routes. This is because in the VPN case, you may also be connected 151 to a network that's offered you a default route, and you could be 152 attacked over that connection if you attempt to connect to resources 153 on the enterprise network over it. 155 On the other, non-trustworthy network scenario, none of the networks 156 to which the host is connected are meaningfully more or less 157 trustworthy. In this scenario, the untrustworthy network may hand 158 out routes to other hosts, e.g. those in the VPN going through some 159 malicious nodes. This will have bad consequences because the host's 160 traffic intended for the corporate VPN may be hijacked by the 161 intermediate nodes. 163 DHCPv6 options described in this document can be used to install the 164 routes. However, the use of such a technique makes sense only in the 165 former case above, i.e. trusted network. So the host MUST have an 166 authenticated connection to the network it connects so that DHCPv6 167 route options can be trusted before establishing routes. 169 Server MUST NOT define more than one default route. 171 2.2. Configuring on-link routes 173 Server may also configure on-link routes, i.e. routes that are 174 available directly over the link, not via routers. To specify on- 175 link routes, server MAY include RTPREFIX option directly in Advertise 176 and Reply messages. 178 2.3. Deleting obsolete route 180 There are two mechanisms that allow removing a route. Each defined 181 route has a route lifetime. If specific route is not refreshed and 182 its timer reaches 0, client MUST remove corresponding entry from 183 routing table. 185 In cases, where faster route removal is needed, server SHOULD return 186 RT_PREFIX option with route lifetime set to 0. Client that receives 187 RT_PREFIX with route lifetime set to 0 MUST remove specified route 188 immediately, even if its previous lifetime did not expire yet. 190 2.4. Applicability to routers 192 Contrary to Router Adverisement mechanism, defined in [RFC4861] that 193 explicitly limits configuration to hosts, routing configuration over 194 DHCPv6 defined in this document may be used by both hosts and 195 routers. (This limitation of RA mechanism was partially lifted by 196 W-1 requirement formulated in [RFC6204].) 198 One of the envisaged usages for this solution are residential 199 gateways (RG) or Customer Premises Equipment (CPE). Those devices 200 very often perform routing. It may be useful to configure routing on 201 such devices over DHCPv6. One example of such use may be a class of 202 premium users that are allowed to use dedicated router that is not 203 available to regular users. 205 2.5. Updating Routing Information 207 Network configuration occassionally changes, due to failure of 208 existing hardware, migration to newer equipment or many other 209 reasons. Therefore there a way to inform clients that routing 210 information have changed is required. 212 There are several ways to inform clients about new routing 213 information. Every client SHOULD periodically refresh its 214 configuration, according to Information Refresh Time Option, so 215 server may send updated information the next time client refreshes 216 its information. New routes may be configured at that time. As 217 every route has associated lifetime, client is required to remove its 218 routes when this timer expires. This method is particularly useful, 219 when migrating to new router is undergoing, but old router is still 220 available. 222 Server MAY also announce routes via soon to be removed router with 223 lifetimes set to 0. This will cause the client to remove its routes, 224 despite the fact that previously received lifetime may not yet 225 expire. 227 Aforementioned methods are useful, when there is no urgent need to 228 update routing information. Bound by timer set by value of 229 Information Refresh Time Option, clients may use outdated routing 230 information until next scheduled renewal. Depending on configured 231 value this delay may be not acceptable in some cases. In such 232 scenarios, administrators are advised to use RECONFIGURE mechanism, 233 defined in [RFC3315]. Server transmits RECONFIRGURE message to each 234 client, thus forcing it to immediately start renewal process. 236 See also Section 2.6 about limitations regarding dynamic routing. 238 2.6. Limitations 240 Defined mechanism is not intended to be used as a dynamic routing 241 protocol. It should be noted that proposed mechanism cannot 242 automatically detect routing changes. In networks that use dynamic 243 routing and also employ this mechanism, clients may attempt using 244 routes configured over DHCPv6 even though routers or specific routes 245 ceased to be available. This may cause black hole routing problem. 246 Therefore it is not recommended to use this mechanism in networks 247 that use dynamic routing protocols. This mechanism SHOULD NOT be 248 used in such networks, unless network operator can provide a way to 249 update DHCP server information in case of router availability 250 changes. 252 Discussion: It should be noted that DHCPv6 server is not able to 253 monitor health of existing routers. As there are currently more than 254 60 options defined for DHCPv6, it is infeasible to implement 255 mechanism that would monitor huge set of services and stop announcing 256 its availability in case of service outage. Therefore in case of 257 prolonged unavailability human interverntion is required to change 258 DHCPv6 server configuration. If that is considered a problem, 259 network administrators should consider using other alternatives, like 260 RA and ND mechanisms (see [RFC4861]). 262 3. DHCPv6 Route Options 264 A DHCPv6 client interested in obtaining routing information includes 265 the NEXT_HOP and RT_PREFIX options as part of its Option Request 266 Option (ORO) in messages directed to a server (as allowed by 267 [RFC3315], i.e. Solicit, Request, Renew, Rebind or Information- 268 request messages). A Server, when configured to do so, provides the 269 requested route information using zero, one or more NEXT_HOP options 270 in messages sent in response (Advertise, and Reply). So as to allow 271 the route options to be both extensible, as well as conveying 272 detailed info for routes, use is made of a nested options structure. 273 Server sends one or more NEXT_HOP options that specify the IPv6 next 274 hop addresses. Each NEXT_HOP option conveys in turn zero, one or 275 more RT_PREFIX options that represents the IPv6 destination prefixes 276 reachable via the given next hop. Server includes RT_PREFIX directly 277 in message to indicate that given prefix is available directly on- 278 link. Server MAY send a single NEXT_HOP without any RT_PREFIX 279 suboptions or with RT_PREFIX that contains ::/0 to indicate available 280 default route. The Formats of the NEXT_HOP and RT_PREFIX options are 281 defined in the following sub-sections. 283 The DHCPv6 Route Options format borrows from the principles of the 284 Route Information Option defined in [RFC4191]. 286 3.1. Route Prefix Option Format 288 The Route Prefix Option is used to convey information about a single 289 prefix that represents the destination network. The Route Prefix 290 Option is used as a sub-option in the previously defined Next Hop 291 Option. It may also be sent directly in message to indicate that 292 route is available directly on-link. 294 0 1 2 3 295 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 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | OPTION_RT_PREFIX | option-len | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | Route lifetime | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Prefix-Length | Metric | | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 303 | Prefix | 304 | (up to 16 octets) | 305 | | 306 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 1: Route Prefix Option Format 312 option-code: OPTION_RT_PREFIX (TBD2). 314 option-len: Length of the Route Prefix option including all its sub- 315 options. 317 Route lifetime 32-bit unsigned integer. Specifies lifetime of the 318 route information, expressed in seconds (relative to the 319 time the packet is sent). There are 2 special values 320 defined. 0 means that route is no longer valid and must be 321 removed by clients. A value of all one bits (0xffffffff) 322 represents infinity. means infinity. 324 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 325 Prefix. The value ranges from 0 to 128. This field 326 represents the number of valid leading bits in the prefix. 328 Resvd: Reserved field. Server MUST set this value to zero and 329 client MUST ignore its content. 331 Metric: Route Metric. 8-bit signed integer. The Route Metric 332 indicates whether to prefer the next hop associated with 333 this prefix over others, when multiple identical prefixes 334 (for different next hops) have been received. 336 Prefix: a variable size field that specifies Rule IPv6 prefix. 337 Length of the field is defined by prefix6-len field and is 338 rounded up to the nearest octet boundary (if case when 339 Prefix Length is not divisible by 8). In such case 340 additional padding bits must be zeroed. 342 Values for metric field have meaning based on the value, i.e. higher 343 value indicates higher preference. 345 3.2. Next Hop Option Format 347 Each IPv6 route consists of an IPv6 next hop address, an IPv6 348 destination prefix (a.k.a. the destination subnet), and a host 349 preference value for the route. Elements of such route (e.g. Next 350 hops and prefixes associated with them) are conveyed in NEXT_HOP 351 option that contains RT_PREFIX suboptions. 353 The Next Hop Option defines the IPv6 address of the next hop, usually 354 corresponding to a specific next-hop router. For each next hop 355 address there can be zero, one or more prefixes reachable via that 356 next hop. 358 0 1 2 3 359 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 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | OPTION_NEXT_HOP | option-len | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | | 364 | IPv6 Next Hop Address | 365 | (16 octets) | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | | 369 | NEXT_HOP sub-options | 370 . . 371 . . 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 Figure 2: IPv6 Next Hop Option Format 376 option-code: OPTION_NEXT_HOP (TBD1). 378 option-len: 16 + Length of NEXT_HOP options field. 380 IPv6 Next Hop Address: 16 octet long field that specified IPv6 381 address of the next hop. 383 NEXT_HOP options: Options associated with this Next Hop. This 384 includes, but is not limited to, zero, one or more 385 RT_PREFIX options that specify prefixes reachable through 386 the given next hop. 388 NEXT_HOP options: Options associated with this Next Hop. This 389 includes, but is not limited to, zero, one or more 390 SOURCE_AP and RT_PREFIX options that specify prefixes 391 reachable through the given next hop. 393 3.3. Source Address/Prefix Option Format 395 Each IPv6 route consists of an IPv6 next hop address, an IPv6 396 destination prefix (a.k.a. the destination subnet), and a host 397 preference value for the route. Elements of such route (e.g. Next 398 hops and prefixes associated with them) are conveyed in NEXT_HOP 399 option that contains RT_PREFIX suboptions. 401 The Source Address/Prefix Option defines the source IPv6 prefix/ 402 address that are assigned from the prefixes that belong to this next 403 hop. 405 0 1 2 3 406 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 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | OPTION_SOURCE_AP | option-len | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Prefix-Length | Reserved | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 412 | IPv6 Source Address/Prefix | 413 | (up to 16 octets) | 414 | | 415 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 3: IPv6 Source Address/Prefix Option Format 421 option-code: OPTION_SOURCE_AP (TBD1). 423 option-len: 16 + Length of SOURCE_AP options field. 425 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 426 Prefix. The value ranges from 0 to 128. This field 427 represents the number of valid leading bits in the prefix. 428 In case of source address this field is set to 132. 430 Resvd: Reserved field. Server MUST set this value to zero and 431 client MUST ignore its content. 433 IPv6 Source Address/Prefix: 16 octet long field that specified IPv6 434 source address or source prefix. 436 4. DHCPv6 Server Behavior 438 When configured to do so, a DHCPv6 server shall provide the NEXT_HOP 439 and RT_PREFIX Options in ADVERTISE and REPLY messages sent to a 440 client that requested the route option. Each Next Hop Option sent by 441 the server must convey at least one Route Prefix Option. 443 Server includes NEXT_HOP option with possible RT_PREFIX suboptions to 444 designate that specific routes are available via routers. Server 445 includes RT_PREFIX options in Next Hop sub-options directly in 446 Advertise and Reply messages to inform that specific routes are 447 available directly on-link. 449 If there is more than one route available via specific next hop, 450 server MUST send only one NEXT_HOP for that next hop, which contains 451 multiple RT_PREFIX options. Server MUST NOT send more than one 452 identical (i.e. with equal next hop address field) NEXT_HOP option. 454 When configured to do so, a DHCPv6 server shall send one or more 455 NEXT_HOP options that contain one or more source addresses Figure 3 456 included in the Next Hop sub-options field. Each Next Hop Address 457 may be associated with zero, one or more Source Prefix that represent 458 the source addresses that are assigned from the prefixes that belong 459 to this next hop. The Next Hop sub-options field MAY contain Route 460 Prefix options that represent the IPv6 destination prefixes reachable 461 via the given next hop as defined in Figure 2. When configured to do 462 so, a DHCPv6 server shall send NEXT_HOP option with Route Prefix 463 option and Source Prefix in the message in the Next Hop sub-options 464 field to indicate that given prefix is available directly on-link and 465 that any source addresses derived from the source prefix will not be 466 subject to ingress filtering on these routes supported by these next 467 hops. 469 When configured to do so, a DHCPv6 server shall send one or more 470 NEXT_HOP option that specify the IPv6 next hop addresses and source 471 address. Each Next Hop Address option may be associated with zero, 472 one or more Source Address that represent the source addresses that 473 are assigned from the prefixes that belong to this next hop. The 474 Next Hop sub-options field shall contain Source Address Figure 3 and 475 Route Prefix options Figure 1 that represent the IPv6 destination 476 prefixes reachable via the given next hop. DHCPv6 server shall 477 include Next Hop Address with Source Address and Route Prefix option 478 in Next Hop sub-options field in the message to indicate that given 479 prefix is available directly on-link and that the source address will 480 not be subject to ingress filtering. For the Source Address, Source 481 Address/Prefix option Figure 3 is used with prefix length set to 128. 483 Each Next Hop Address may be associated with zero, one or more Source 484 Prefix that represent the source addresses that are assigned from the 485 prefixes that belong to this next hop. The option MAY contain Route 486 Prefix options that represent the IPv6 destination prefixes reachable 487 via the given next hop. DHCP server shall include Next Hop Address 488 with Route Prefix option in Next Hop sub-option field defined in 489 Figure 2 in the message to indicate that given prefix is available 490 directly on-link. To indicate that any source addresses derived from 491 the source prefix will not be subject to ingress filtering on these 492 routes supported by these next hops DHCPv6 server shall send two 493 options, Next Hop option with Route Prefix option in Next Hop options 494 field and a Source Prefix option defined in Figure 3. 496 Servers SHOULD NOT send NEXT_HOP or RT_PREFIX to clients that did not 497 explicitly requested it, using the ORO. 499 Servers MUST NOT send NEXT_HOP or RT_PREFIX in messages other than 500 ADVERTISE or REPLY. 502 Servers MAY also include Status Code Option, defined in Section 22.13 503 of the [RFC3315] to indicate the status of the operation. 505 Servers MUST include the Status Code Option, if the requested routing 506 configuration was not successful and SHOULD use status codes as 507 defined in [RFC3315] and [RFC3633]. 509 The maximum number of routing information in one DHCPv6 message 510 depend on the maximum DHCPv6 message size defined in [RFC3315] 512 5. DHCPv6 Client Behavior 514 A DHCPv6 client compliant with this specification MUST request the 515 NEXT_HOP and RT_PREFIX Options in an Option Request Option (ORO) in 516 the following messages: Solicit, Request, Renew, Rebind, and 517 Information-Request. The messages are to be sent as and when 518 specified by [RFC3315]. 520 When processing a received Route Options a client MUST substitute a 521 received 0::0 value in the Next Hop Option with the source IPv6 522 address of the received DHCPv6 message. It MUST also associate a 523 received Link Local next hop addresses with the interface on which 524 the client received the DHCPv6 message containing the route option. 525 Such a substitution and/or association is useful in cases where the 526 DHCPv6 server operator does not directly know the IPv6 next-hop 527 address, other than knowing it is that of a DHCPv6 relay agent on the 528 client LAN segment. DHCPv6 Packets relayed to the client are sourced 529 by the relay using this relay's IPv6 address, which could be a link 530 local address. 532 The Client SHOULD refresh assigned route information periodically. 533 The generic DHCPv6 Information Refresh Time Option, as specified in 534 [RFC4242], can be used when it is desired for the client to 535 periodically refresh of route information. 537 The routes conveyed by the Route Option should be considered as 538 complimentary to any other static route learning and maintenance 539 mechanism used by, or on the client with one modification: The client 540 MUST flush DHCPv6 installed routes following a link flap event on the 541 DHCPv6 client interface over which the routes were installed. This 542 requirement is necessary to automate the flushing of routes for 543 clients that may move to a different network. 545 Client MUST confirm that routers announced over DHCPv6 are reachable, 546 using one of methods suitable for specific network type. The most 547 common mechanism is Neighbor Unreachability Detection (NUD), 548 specified in [RFC4861]. Client SHOULD use NUD to verify that 549 received routers are reachable before adjusting its routing tables. 550 Client MAY use other reachability verification mechanisms specific to 551 used network technology. To avoid potential long-lived routing black 552 holes, client MAY periodically confirm that router is still 553 reachable. 555 5.1. Conflict resolution 557 Information received via Route Options over DHCPv6 MUST be treated 558 equally to routing information obtained via other sources. In 559 particular, from the RA perspective, DHCPv6 provisioning should be 560 treated as if yet another RA was received. Preference field should 561 be taken into consideration during route information processing. In 562 particular, administrators are encouraged to read [RFC4191], 563 Section 4.1 for guidance. 565 To facilitate information merge between DHCPv6 and RA, DHCPv6 options 566 in this document convey the same information specified in 567 [I-D.sarikaya-6man-next-hop-ra]. 569 To facilitate information merge between DHCPv6 and RA, DHCPv6 option 570 RT_PREFIX conveys the same information specified in [RFC4191] albeit 571 on-wire format is slightly different. The differences are: 573 Metric field is an 8-bit field that conveys the route metric. 575 RIO uses 128-length prefix field, while DHCPv6 option uses variable 576 prefix length. That difference is used to minimize packet size as it 577 avoid transmitting zeroed octets. Despite slightly different 578 encoding, delivered information is exactly the same. 580 If prefix is available directly on-link, Route Prefix option is 581 conveyed directly in DHCPv6 message, not within Next Hop option. 582 That feature is considered a superset, compared to RIO. 584 In short, when DHCPv6 RT_PREFIX option is used alone this 585 specification works in compatibility mode with [RFC4191]. 587 6. IANA Considerations 589 IANA is kindly requested to allocate DHCPv6 option code TBD1 to the 590 OPTION_NEXT_HOP, TBD2 to OPTION_RT_PREFIX, TBD3 to OPTION_SOURCE_AP. 591 All values should be added to the DHCPv6 option code space defined in 592 Section 24.3 of [RFC3315]. 594 7. Security Considerations 596 The overall security considerations discussed in [RFC3315] apply also 597 to this document. The Route option could be used by malicious 598 parties to misdirect traffic sent by the client either as part of a 599 denial of service or man-in-the-middle attack. An alternative denial 600 of service attack could also be realized by means of using the route 601 option to overflowing any known memory limitations of the client, or 602 to exceed the client's ability to handle the number of next hop 603 addresses. 605 Neither of the above considerations are new and specific to the 606 proposed route option. The mechanisms identified for securing DHCPv6 607 as well as reasonable checks performed by client implementations are 608 deemed sufficient in addressing these problems. 610 It is essential that clients verify that announced routers are indeed 611 reachable, as specified in Section 5. Failing to do so may create 612 black hole routing problem. 614 This mechanism may introduce severe problems if deployed in networks 615 that use dynamic routing protocols. See Section 2.6 for details. 617 DHCPv6 becomes a complete provisioning protocol with this mechanism, 618 i.e. all necessary configuration parameters may be delivered using 619 DHCPv6 only. It was suggested that in some cases this may lead to 620 decision of disabling RA. While RA-less networks could offer lower 621 operational expenses and protection against rogue RAs, they would not 622 work with nodes that do not support this feature. Therefore such 623 decision is not recommended, unless all effects are carefully 624 analyzed. It is worth noting that disabling RA support in hosts 625 would solve rogue RA problem, it would in fact only change the issue 626 into rogue DHCPv6 problem. That is somewhat beneficial, however, as 627 rogue RA may affect all nodes immediately while rogue DHCPv6 server 628 will affect only new nodes, that boot up after rogue server manifests 629 itself. 631 Reader is also encouraged to read DHCPv6 security considerations 632 document [I-D.ietf-dhc-sedhcpv6]. 634 8. Acknowledgements 636 The author acknowledges the work done by his co-authors in MIF WG 637 draft entitled DHCPv6 Route Options. 639 9. References 641 9.1. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, March 1997. 646 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 647 and M. Carney, "Dynamic Host Configuration Protocol for 648 IPv6 (DHCPv6)", RFC 3315, July 2003. 650 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 651 Host Configuration Protocol (DHCP) version 6", RFC 3633, 652 December 2003. 654 9.2. Informative References 656 [I-D.ietf-dhc-sedhcpv6] 657 Jiang, S., Shen, S., Zhang, D., and T. Jinmei, "Secure 658 DHCPv6", draft-ietf-dhc-sedhcpv6-05 (work in progress), 659 December 2014. 661 [I-D.ietf-mif-mpvd-arch] 662 Anipko, D., "Multiple Provisioning Domain Architecture", 663 draft-ietf-mif-mpvd-arch-07 (work in progress), October 664 2014. 666 [I-D.ietf-mif-mpvd-dhcp-support] 667 Krishnan, S., Korhonen, J., and S. Bhandari, "Support for 668 multiple provisioning domains in DHCPv6", draft-ietf-mif- 669 mpvd-dhcp-support-00 (work in progress), August 2014. 671 [I-D.sarikaya-6man-next-hop-ra] 672 Sarikaya, B., "IPv6 RA Options for Next Hop Routes", 673 draft-sarikaya-6man-next-hop-ra-04 (work in progress), 674 December 2014. 676 [I-D.sarikaya-6man-sadr-overview] 677 Sarikaya, B., "Overview of Source Address Dependent 678 Routing", draft-sarikaya-6man-sadr-overview-03 (work in 679 progress), December 2014. 681 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 682 Static Route Option for Dynamic Host Configuration 683 Protocol (DHCP) version 4", RFC 3442, December 2002. 685 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 686 More-Specific Routes", RFC 4191, November 2005. 688 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 689 Time Option for Dynamic Host Configuration Protocol for 690 IPv6 (DHCPv6)", RFC 4242, November 2005. 692 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 693 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 694 September 2007. 696 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 697 Troan, "Basic Requirements for IPv6 Customer Edge 698 Routers", RFC 6204, April 2011. 700 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 701 Wing, "IPv6 Multihoming without Network Address 702 Translation", RFC 7157, March 2014. 704 Author's Address 706 Behcet Sarikaya 707 Huawei USA 708 5340 Legacy Dr. 709 Plano, TX 75024 710 United States 712 Phone: +1 972-509-5599 713 Email: sarikaya@ieee.org