idnits 2.17.1 draft-ietf-mif-dhcpv6-route-option-05.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 (August 24, 2012) is 4256 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) == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-05 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-secure-dhcpv6-06 == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 -- 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 (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Dec 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track T. Mrugalski 5 Expires: February 25, 2013 ISC 6 T. Sun 7 China Mobile 8 B. Sarikaya 9 Huawei USA 10 A. Matsumoto 11 NTT NT Lab 12 August 24, 2012 14 DHCPv6 Route Options 15 draft-ietf-mif-dhcpv6-route-option-05 17 Abstract 19 This document describes DHCPv6 Route Options for provisioning IPv6 20 routes on DHCPv6 client nodes. This is expected to improve the 21 ability of an operator to configure and influence a nodes' ability to 22 pick an appropriate route to a destination when this node is multi- 23 homed and where other means of route configuration may be 24 impractical. 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 30 document are to be interpreted as described in RFC 2119 [RFC2119]. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 25, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Problem overview . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 4. DHCPv6 Based Solution . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Default route configuration . . . . . . . . . . . . . . . 8 71 4.2. Configuring on-link routes . . . . . . . . . . . . . . . . 9 72 4.3. Deleting obsolete route . . . . . . . . . . . . . . . . . 9 73 4.4. Applicability to routers . . . . . . . . . . . . . . . . . 9 74 4.5. Updating Routing Information . . . . . . . . . . . . . . . 9 75 4.6. Limitations . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. DHCPv6 Route Options . . . . . . . . . . . . . . . . . . . . . 11 77 5.1. Next Hop Option Format . . . . . . . . . . . . . . . . . . 11 78 5.2. Route Prefix Option Format . . . . . . . . . . . . . . . . 12 79 6. DHCPv6 Server Behavior . . . . . . . . . . . . . . . . . . . . 14 80 7. DHCPv6 Client Behavior . . . . . . . . . . . . . . . . . . . . 15 81 7.1. Conflict resolution . . . . . . . . . . . . . . . . . . . 16 82 8. Raised concerns . . . . . . . . . . . . . . . . . . . . . . . 16 83 8.1. Vendor-specific option . . . . . . . . . . . . . . . . . . 16 84 8.2. Unicast RA . . . . . . . . . . . . . . . . . . . . . . . . 17 85 8.3. DHCPv6 requires client to use one server . . . . . . . . . 17 86 8.4. Use VLANs . . . . . . . . . . . . . . . . . . . . . . . . 18 87 8.5. Lack of link-layer address information . . . . . . . . . . 18 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 90 11. Contributors and Acknowledgements . . . . . . . . . . . . . . 19 91 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 92 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 93 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 96 1. Introduction 98 The Neighbor Discovery (ND) protocol [RFC4861] provides a mechanism 99 for hosts to discover one or more default routers on a directly 100 connected network segment. Extensions to the Router Advertisement 101 (RA) protocol defined in [RFC4191] allow hosts to discover the 102 preferences for multiple default routers on a given link, as well as 103 any specific routes advertised by these routers. This allows network 104 administrators to better handle multi-homed host topologies and 105 influence the route selection by the host. This ND based mechanism 106 however is sub optimal or impractical in some multi-homing scenarios, 107 where DHCPv6 [RFC3315] is seen to be more viable. 109 This draft defines the DHCPv6 Route Options for provisioning IPv6 110 routes on DHCPv6 clients. The proposed option is primarily envisaged 111 for use by DHCPv6 client nodes that are capable of making basic IP 112 routing decisions and maintaining an IPv6 routing table, broadly in 113 line with the capabilities of a generic host as described in 114 [RFC4191]. 116 Throughout the document the words node and client are used as a 117 reference to the device with such routing capabilities, hosting the 118 DHCPv6 client software. The route information is taken to be 119 equivalent to static routing, and limited in the number of required 120 routes to a handful. 122 2. Problem overview 124 The solution described in this document applies to multi-homed 125 scenarios including ones where the client is simultaneously connected 126 to multiple access network (e.g. WiFi and 3G). The following 127 scenario is used to illustrate the problem as found in typical multi- 128 homed residential access networks. It is duly noted that the problem 129 is not specific to IPv6, occurring also with IPv4, where it is today 130 solved by means of DHCPv4 classless route information option 131 [RFC3442], or alternative configuration mechanisms. 133 In multi-homed networks, a given user's node may be connected to more 134 than one gateway. Such connectivity may be realized by means of 135 dedicated physical or logical links that may also be shared with 136 other users nodes. In such multi-homed networks it is quite common 137 for the network operator to offer the delivery of a particular type 138 of IP service via a particular gateway, where the service can be 139 characterised by means of specific destination IP network prefixes. 140 Thus, from an IP routing perspective in order for the user node to 141 select the appropriate gateway for a given destination IP prefix, 142 recourse needs to be made to classic longest destination match IP 143 routing, with the node acquiring such prefixes into its routing 144 table. This is typically the remit of dynamic Internal Gateway 145 Protocols (IGPs), which however are rarely used by operators in 146 residential access networks. This is primarily due to operational 147 costs and a desire to contain the complexity of user nodes and IP 148 Edge devices to a minimum. While, IP Route configuration may be 149 achieved using the ICMPv6 extensions defined in [RFC4191], this 150 mechanism does not lend itself to other operational constraints such 151 as the desire to control the route information on a per node basis, 152 the ability to determine whether a given node is actually capable of 153 receiveing/processing such route information. A preferred mechanism, 154 and one that additionally also lends itself to centralized management 155 independent of the management of the gateways, is that of using the 156 DHCP protocol for conveying route information to the nodes. 158 3. Motivation 160 The following section enumerates use cases, both in existing networks 161 and as well as in evisaged future deployments. Usage scenarios are 162 specified here in no particular order. As those use cases are 163 descibed by various network operators, their scenario partially 164 overlaps. 166 Use case 1: In Broadband network environment where the CPE is multi- 167 homed to two upstream edge routers and each router provides 168 connectivity for different types of services for example internet 169 access and Video on Demand (restricted inside a walled garden) and 170 the Service Provide would like to avoid routing on the CPE, there is 171 a need to provision static route entries on RGs/CPEs. Service 172 Provider requires a centralized control/management point for storing 173 the customer's related innformation (IPv6 prefix, IPv6 routes and 174 other provisioned information) and DHCPv6 is a good place for that. 175 Using RA's would require to manually provision the edge router and 176 this operation is not always possible, for example when router is 177 operated by 3rd party. Broadband Forum document WT-124 issue 3 178 [BBF-WT-124] calls for this draft to solve the problem. 180 Use case 2: Operators want (approximate) feature parity so that they 181 can have (approximate) alignment between their operational procedures 182 for v4 and v6, especially in a dual stack network. Having similar 183 mechanisms for both protocols is desired due to lower operational 184 expenses (OPEX). 186 Use case 3: In cellular networks, it is efficient for the network to 187 configure routing information in central DHCPv6 server to do unified 188 routing policy information. The gateways (GGSN in cellular network) 189 only need to perform DHCPv6 relay. The Option code sent by clients 190 can be used as an indication that host is MIF capable, so that 191 network need not to do such configuration to host without MIF 192 capabilities. 194 Use case 4: In cellular network, DHCPv6 is used for IPv6 parameter 195 configuration and RA is used for SLAAC of handset. This behavior was 196 introduced in 3GPP Release 8 (or earlier). The network gateway in 197 cellular network (e.g., GGSN) can naturally support DHCPv6 extension 198 since the gateway acts as a DHCPv6 relay. However, it is very hard 199 to update those gateways to use RA announcing the route information. 200 The handsets with MIF feature need to visit subscribed/operator 201 provided service. Some traffic is routed to the operator's network 202 through 3G interface instead of to Internet through WiFi. DHCPv6 203 will be used to configure these specific routes. This use case is 204 described in [THREEGPP-23.853]. 206 Use case 5: WiFi networks. Some WiFi hotspots provide local services 207 ("walled garden"). The route configuration on hosts or RGs is needed 208 to direct some traffic to local network, while other traffic to the 209 Internet. While this can be achieved using Route Information Option 210 (RIO) in RA for all nodes that support [RFC4191], it does not allow 211 doing so on a per-host basis. 213 Use case 6: VPN network. When a user connects to enterprise VPN 214 network, the routing of VPN traffic need to be configured. Due to 215 the large number of such VPN networks, we cannot assume all the VPN 216 network only use RA. DHCPv6 provides another choice which may be 217 preferred by the VPN network. This situation is described in 218 [RFC4191], Section 5.2. Hosts that do not support RFC4191 will not 219 operate properly. 221 Use case 7: Walled garden. Figure 1 illustrates the case of two 222 clients connected to a shared link. Both clients are assumed to have 223 IPv6 addresses from a global scope and obtain their Internet 224 connectivity via Router2 by means of a configured or a discovered 225 default route. Client 1 however, unlike Client 2, is intended to run 226 a specific application, e.g. VoIP, that is meant to access ServerA 227 by means of Router1 with Server A being otherwise not reachable from 228 the Internet. In addition to the global IP address Client1 may be 229 assigned with another IP address of a more restricted scope for the 230 purpose of communicating with Server A. 232 +---Router1------ServerA 233 | 234 Client1----+ 235 | 236 Client2----+ 237 | 238 +---Router2------Internet 240 Figure 1: Walled garden scenario 242 The problem in the above scenario comes down to the fact that in 243 order to reach Server A, Client1 requires to use a more specific 244 route whose next-hop address is Router1. An ICMPv6 based mechanism 245 for disseminating more specific route information, as defined in 246 [RFC4191], disseminates this information via the shared link also to 247 Client2. Often the operator wants to avoid this redundant 248 dissemination to passing to Client2. In addition many operators 249 prefer to be able to manage specific client route information from a 250 centralized repository instead of managing directly such 251 configuration on a router, as is required with the ICMPv6 based 252 scheme. The former requirement is driven by the desire to provide to 253 each client only the information required for their intended role 254 which may be tied to a specific service, as well as to allow the 255 possibility to introduce other routers into the scenario for purposes 256 of load sharing. The requirement for more centralized configuration 257 management is often due to administrative boundaries within an 258 operator's organization as well as an existing operational practice 259 that are in place for IPv4, all of which make router based 260 configuration difficult. 262 Use case 8: Multihoming problem. A multihomed IPv6 host or gateway 263 needs to solve at least 3 problems to operate properly when more than 264 one link is operational: 266 1. Source address selection 268 2. Next-hop selection 270 3. DNS server selection 272 Problems one and three are solved by [I-D.ietf-6man-addr-select-opt] 273 and [I-D.ietf-mif-dns-server-selection], respectively. It should be 274 noted that both mechanisms use DHCPv6 as well. This draft attempts 275 to solve problem two. Below is a brief explanation of the problem. 276 See draft [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] for 277 detailed problem analysis, background information and additional 278 discussion regarding the need for a DHCPv6 solution to route 279 information problem and IPv6 multihoming in general (with focus on 280 aforementioned 3 problems). 282 In multihoming environment, server can restrict assignment of 283 additional prefixes only to hosts that support more advanced next-hop 284 and address selection requirements. (See Section 5.2 of 285 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat]). Obviously this 286 MUST be done on a per-host basis. Information about node capability 287 is obtained via Option Request Option (ORO) in Solicit message, so 288 support for Route Options is also used as means to report node 289 capabilities to a network. 291 Use case 9: In static networks (i.e. networks that have static 292 routers that are not changing over time), such as some enterprise 293 networks, it may be possible to stop using RA mechanism and deliver 294 all configuration parameters to hosts using DHCPv6 only. This 295 approach solves the rogue RA problem (i.e. a node that is not an 296 approved router starts announcing RA in a network may hijack traffic 297 from other hosts). This approach may be appealing in some cases, but 298 not in all. For example if there is security association shared 299 between clients and a DHCPv6 server, it may be useful to trust DHCP 300 and disable RA mechanism. 302 Use case 10: It also has been proposed that route information option 303 may be used as tie breaker in networks that deploy both DHCPv6 route 304 option and RA. DHCPv6 server could announce routing information 305 along with RA. Legitimate router is also announced over DHCPv6. 306 Host that receives conflicting information over RA may use additional 307 information received from DHCPv6 as a tie breaker. This proposal 308 [nanog-beijnum] was not investigated further. 310 Use case 11: Separated networks. In networks that do not have any 311 routers, two DHCPv6 clients get a global address from DHCPv6 server. 312 They cannot ping each other due to the fact that they do not know 313 prefix that is available on-link. While it is tempting to suggest 314 that separated networks should use link-local addressing, other 315 factors should be taken into consideration. A stateful DHCPv6 may be 316 used as a node monitoring tool, thus having avantage over link-local 317 address usage. The also may be sensor networks that have outside 318 connectivity only sporadically, e.g. uplink is established 319 periodically to gather readings, but most of the time router is 320 powered down for power reasons. Route Option in DHCPv6 could be used 321 to configure on-link routes, while router could announce itself using 322 short-lived RA. 324 Those requirements and use cases can be summarized as following: 326 1. In view of the DHCPv6 requirements in several fields, vendor- 327 specific options lead to several segmented definitions. An IETF 328 defined general option is a better choice. 330 2. Per user/host configuration makes DHCPv6 be used for the on- 331 demand configuration. 333 3. As there is no well-defined central management system for prefix 334 delegation and routing options va RA, it seems that DHCPv6 is the 335 only available solution. It is better to have a generic option 336 then a bunch of competing vendor options. 338 4. While this work was initially started with multihoming in mind, 339 it is useful for single interface devices as well. 341 In a sense this route configuration mechanism makes DHCPv6 complete. 342 Without it, this protocol cannot fully provision all configuration 343 parameters to a host on its own. 345 4. DHCPv6 Based Solution 347 A DHCPv6 based solution allows an operator an on demand and node 348 specific means of configuring static routing information. Such a 349 solution also fits into network environments where the operator 350 prefers to manage Residential Gateway (RG) configuration information 351 from a centralized DHCP server. 352 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] provides additional 353 background to the need for a DHCPv6 solution to the problem. 355 In terms of the high level operation of the solution defined in this 356 draft, a DHCPv6 client interested in obtaining routing information 357 request the route options using the DHCPv6 Option Request Option 358 (ORO) sent to a server. A Server, when configured to do so, provides 359 the requested route information as part of a nested options structure 360 covering; the next-hop address; the destination prefix; the route 361 metric; any additional options applicable to the destination or next- 362 hop. 364 4.1. Default route configuration 366 Defined mechanism may be used to configure default route. Default 367 route is configured using RT_PREFIX option that specifies ::/0 route, 368 included as suboption in NEXT_HOP. 370 Server MUST NOT define more than one default route. 372 4.2. Configuring on-link routes 374 Server may also configure on-link routes, i.e. routes that are 375 available directly over the link, not via routers. To specify on- 376 link routes, server MAY include RTPREFIX option directly in Advertise 377 and Reply messages. 379 4.3. Deleting obsolete route 381 There are two mechanisms that allow removing a route. Each defined 382 route has a route lifetime. If specific route is not refreshed and 383 its timer reaches 0, client MUST remove corresponding entry from 384 routing table. 386 In cases, where faster route removal is needed, server SHOULD return 387 RT_PREFIX option with route lifetime set to 0. Client that receives 388 RT_PREFIX with route lifetime set to 0 MUST remove specified route 389 immediately, even if its previous lifetime did not expire yet. 391 4.4. Applicability to routers 393 Contrary to Router Adverisement mechanism, defined in [RFC4861] that 394 explicitly limits configuration to hosts, routing configuration over 395 DHCPv6 defined in this document may be used by both hosts and 396 routers. (This limitation of RA mechanism was partially lifted by 397 W-1 requirement formulated in [RFC6204].) 399 One of the envisaged usages for this solution are residential 400 gateways (RG) or Customer Premises Equipment (CPE). Those devices 401 very often perform routing. It may be useful to configure routing on 402 such devices over DHCPv6. One example of such use may be a class of 403 premium users that are allowed to use dedicated router that is not 404 available to regular users. 406 4.5. Updating Routing Information 408 Network configuration occassionally changes, due to failure of 409 existing hardware, migration to newer equipment or many other 410 reasons. Therefore there a way to inform clients that routing 411 information have changed is required. 413 There are several ways to inform clients about new routing 414 information. Every client SHOULD periodically refresh its 415 configuration, according to Information Refresh Time Option, so 416 server may send updated information the next time client refreshes 417 its information. New routes may be configured at that time. As 418 every route has associated lifetime, client is required to remove its 419 routes when this timer expires. This method is particularly useful, 420 when migrating to new router is undergoing, but old router is still 421 available. 423 Server MAY also announce routes via soon to be removed router with 424 lifetimes set to 0. This will cause the client to remove its routes, 425 despite the fact that previously received lifetime may not yet 426 expire. 428 Aforementioned methods are useful, when there is no urgent need to 429 update routing information. Bound by timer set by value of 430 Information Refresh Time Option, clients may use outdated routing 431 information until next scheduled renewal. Depending on configured 432 value this delay may be not acceptable in some cases. In such 433 scenarios, administrators are advised to use RECONFIGURE mechanism, 434 defined in [RFC3315]. Server transmits RECONFIRGURE message to each 435 client, thus forcing it to immediately start renewal process. 437 See also Section 4.6 about limitations regarding dynamic routing. 439 4.6. Limitations 441 Defined mechanism is not intended to be used as a dynamic routing 442 protocol. It should be noted that proposed mechanism cannot 443 automatically detect routing changes. In networks that use dynamic 444 routing and also employ this mechanism, clients may attempt using 445 routes configured over DHCPv6 even though routers or specific routes 446 ceased to be available. This may cause black hole routing problem. 447 Therefore it is not recommended to use this mechanism in networks 448 that use dynamic routing protocols. This mechanism SHOULD NOT be 449 used in such networks, unless network operator can provide a way to 450 update DHCP server information in case of router availability 451 changes. 453 Discussion: It should be noted that DHCPv6 server is not able to 454 monitor health of existing routers. As there are currently more than 455 60 options defined for DHCPv6, it is infeasible to implement 456 mechanism that would monitor huge set of services and stop announcing 457 its availability in case of service outage. Therefore in case of 458 prolonged unavailability human interverntion is required to change 459 DHCPv6 server configuration. If that is considered a problem, 460 network administrators should consider using other alternatives, like 461 RA and ND mechanisms (see [RFC4861]). 463 User is also encouraged to read Section 8. 465 5. DHCPv6 Route Options 467 A DHCPv6 client interested in obtaining routing information includes 468 the NEXT_HOP and RT_PREFIX options as part of its Option Request 469 Option (ORO) in messages directed to a server (as allowed by 470 [RFC3315], i.e. Solicit, Request, Renew, Rebind or Information- 471 request messages). A Server, when configured to do so, provides the 472 requested route information using zero, one or more NEXT_HOP options 473 in messages sent in response (Advertise, and Reply). So as to allow 474 the route options to be both extensible, as well as conveying 475 detailed info for routes, use is made of a nested options structure. 476 Server sends one or more NEXT_HOP options that specify the IPv6 next 477 hop addresses. Each NEXT_HOP option conveys in turn zero, one or 478 more RT_PREFIX options that represents the IPv6 destination prefixes 479 reachable via the given next hop. Server includes RT_PREFIX directly 480 in message to indicate that given prefix is available directly on- 481 link. The Formats of the NEXT_HOP and RT_PREFIX options are defined 482 in the following sub-sections. 484 The DHCPv6 Route Options format borrows from the principles of the 485 Route Information Option defined in [RFC4191]. 487 5.1. Next Hop Option Format 489 Each IPv6 route consists of an IPv6 next hop address, an IPv6 490 destination prefix (a.k.a. the destination subnet), and a host 491 preference value for the route. Elements of such route (e.g. Next 492 hops and prefixes associated with them) are conveyed in NEXT_HOP 493 option that contains RT_PREFIX suboptions. 495 The Next Hop Option defines the IPv6 address of the next hop, usually 496 corresponding to a specific next-hop router. For each next hop 497 address there can be zero, one or more prefixes reachable via that 498 next hop. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | OPTION_NEXT_HOP | option-len | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 | IPv6 Next Hop Address | 507 | (16 octets) | 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | | 511 | NEXT_HOP options | 512 . . 513 . . 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 2: IPv6 Next Hop Option Format 518 option-code: OPTION_NEXT_HOP (TBD1). 520 option-len: 16 + Length of NEXT_HOP options field. 522 IPv6 Next Hop Address: 16 octet long field that specified IPv6 523 address of the next hop. 525 NEXT_HOP options: Options associated with this Next Hop. This 526 includes, but is not limited to, zero, one or more 527 RT_PREFIX options that specify prefixes reachable through 528 the given next hop. 530 5.2. Route Prefix Option Format 532 The Route Prefix Option is used to convey information about a single 533 prefix that represents the destination network. The Route Prefix 534 Option is used as a sub-option in the previously defined Next Hop 535 Option. It may also be sent directly in message to indicate that 536 route is available directly on-link. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | OPTION_RT_PREFIX | option-len | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | Route lifetime | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Prefix-Length |Resvd|Prf|Resvd| | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 547 | Prefix | 548 | (up to 16 octets) | 549 | | 550 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 553 . . 554 . RT_PREFIX sub-options . 555 . . 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 Figure 3: Route Prefix Option Format 560 option-code: OPTION_RT_PREFIX (TBD2). 562 option-len: Length of the Route Prefix option including all its sub- 563 options. 565 Route lifetime 32-bit unsigned integer. Specifies lifetime of the 566 route information, expressed in seconds (relative to the 567 time the packet is sent). There are 2 special values 568 defined. 0 means that route is no longer valid and must be 569 removed by clients. A value of all one bits (0xffffffff) 570 represents infinity. means infinity. 572 Prefix Length: 8-bit unsigned integer. The length in bits of the IP 573 Prefix. The value ranges from 0 to 128. This field 574 represents the number of valid leading bits in the prefix. 576 Resvd: Reserved field. Server MUST set this value to zero and 577 client MUST ignore its content. 579 Prf(Route Preference): 2-bit signed integer. The Route Preference 580 indicates whether to prefer the router associated with this 581 prefix over others, when multiple identical prefixes (for 582 different routers) have been received. If the Reserved 583 (10) value is received, the Route Information Option MUST 584 be ignored. 586 Metric: Route Metric. 8-bit signed integer. The Route Metric 587 indicates whether to prefer the next hop associated with 588 this prefix over others, when multiple identical prefixes 589 (for different next hops) have been received. 591 Prefix: a variable size field that specifies Rule IPv6 prefix. 592 Length of the field is defined by prefix6-len field and is 593 rounded up to the nearest octet boundary (if case when 594 prefix6-len is not divisible by 8). In such case 595 additional padding bits must be zeroed. 597 RT_PREFIX options: Options specific to this particular prefix. 599 Values for preference field have meaning identical to Route 600 Information Option, defined in [RFC4191], Section 2.1: 602 01 High 604 00 Medium (default) 606 11 Low 608 10 Reserved - MUST NOT be sent 610 6. DHCPv6 Server Behavior 612 When configured to do so, a DHCPv6 server shall provide the Next Hop 613 and Route Prefix Options in ADVERTISE and REPLY messages sent to a 614 client that requested the route option. Each Next Hop Option sent by 615 the server must convey at least one Route Prefix Option. 617 Server includes NEXT_HOP option with possible RT_PREFIX suboptions to 618 designate that specific routes are available via routers. Server 619 includes RT_PREFIX options directly in Advertise and Reply messages 620 to inform that specific routes are available directly on-link. 622 If there is more than one route available via specific next hop, 623 server MUST send only one NEXT_HOP for that next hop, which contains 624 multiple RT_PREFIX options. Server MUST NOT send more than one 625 identical (i.e. with equal next hop address field) NEXT_HOP option. 627 Servers SHOULD NOT send Route Option to clients that did not 628 explicitly requested it, using the ORO. 630 Servers MUST NOT send Route Option in messages other than ADVERTISE 631 or REPLY. 633 Servers MAY also include Status Code Option, defined in Section 22.13 634 of the [RFC3315] to indicate the status of the operation. 636 Servers MUST include the Status Code Option, if the requested routing 637 configuration was not successful and SHOULD use status codes as 638 defined in [RFC3315] and [RFC3633]. 640 The maximum number of routing information in one DHCPv6 message 641 depend on the maximum DHCPv6 message size defined in [RFC3315] 643 7. DHCPv6 Client Behavior 645 A DHCPv6 client compliant with this specification MUST request the 646 NEXT_HOP and RT_PREFIX Options in an Option Request Option (ORO) in 647 the following messages: Solicit, Request, Renew, Rebind, and 648 Information-Request. The messages are to be sent as and when 649 specified by [RFC3315]. 651 When processing a received Route Options a client MUST substitute a 652 received 0::0 value in the Next Hop Option with the source IPv6 653 address of the received DHCPv6 message. It MUST also associate a 654 received Link Local next hop addresses with the interface on which 655 the client received the DHCPv6 message containing the route option. 656 Such a substitution and/or association is useful in cases where the 657 DHCPv6 server operator does not directly know the IPv6 next-hop 658 address, other than knowing it is that of a DHCPv6 relay agent on the 659 client LAN segment. DHCPv6 Packets relayed to the client are sourced 660 by the relay using this relay's IPv6 address, which could be a link 661 local address. 663 The Client SHOULD refresh assigned route information periodically. 664 The generic DHCPv6 Information Refresh Time Option, as specified in 665 [RFC4242], can be used when it is desired for the client to 666 periodically refresh of route information. 668 The routes conveyed by the Route Option should be considered as 669 complimentary to any other static route learning and maintenance 670 mechanism used by, or on the client with one modification: The client 671 MUST flush DHCPv6 installed routes following a link flap event on the 672 DHCPv6 client interface over which the routes were installed. This 673 requirement is necessary to automate the flushing of routes for 674 clients that may move to a different network. 676 Client MUST confirm that routers announced over DHCPv6 are reachable, 677 using one of methods suitable for specific network type. The most 678 common mechanism is Neighbor Unreachability Detection (NUD), 679 specified in [RFC4861]. Client SHOULD use NUD to verify that 680 received routers are reachable before adjusting its routing tables. 681 Client MAY use other reachibality verification mechanisms specific to 682 used network technology. To avoid potential long-lived routing black 683 holes, client MAY periodically confirm that router is still 684 reachable. 686 7.1. Conflict resolution 688 Information received via Route Options over DHCPv6 MUST be treated 689 equally to routing information obtained via other sources. In 690 particular, from the RA perspective, DHCPv6 provisioning should be 691 treated as if yet another RA was received. Preference field should 692 be taken into consideration during route information processing. In 693 particular, administrators are encouraged to read [RFC4191], Section 694 4.1 for guidance. 696 To facilitate information merge between DHCPv6 and RA, DHCPv6 option 697 conveys the same information as RIO, specified in [RFC4191], albeit 698 on-wire format is slightly different. The differences are: 700 Metric field (available in previous version of this draft) has been 701 replaced with 2-bit preference field that is in line with RIO 702 information. 704 RIO uses 128-length prefix field, while DHCPv6 option uses variable 705 prefix length. That difference is used to minimize packet size as it 706 avoid transmitting zeroed octets. Despite slightly different 707 encoding, delivered information is exactly the same. 709 If prefix is available directly on-link, Route Prefix option is 710 conveyed directly in DHCPv6 message, not withing Next Hop option. 711 That feature is considered a superset, compared to RIO. 713 8. Raised concerns 715 Opponents of this option proposed several alternative approaches. 716 This section attempts to address raised issues. 718 8.1. Vendor-specific option 720 Claim: During discussion about route configuration, some opponents 721 say that routing information should be defined as vendor specific 722 option. 724 Response: There are many ISPs, cellular and BBF network operators, 725 CPE vendors, hardware vendors, DHCP implementors that want to 726 implement and deploy this mechanism. Using vendor-specific option 727 would severly limit interoperability and would make adoption and 728 deployment much more complicated. 730 This solution is not a technology-specific requirement, it is 731 requested by wide variety of companies, so it is not a vendor 732 specific. 734 8.2. Unicast RA 736 Claim: Some proponents insist that instead of using DHCPv6 solution, 737 RA should be used instead. Some propose to send unicast RA with RIO 738 option on a per-host basis. 740 Response: While this approach technically does not violate existing 741 specs, it uses RA in a stateful way, thus the benefit of RA being 742 stateless is lost. Furthermore, it would require deploying 743 additional mechanism, like RADIUS to deliver necessary information 744 about hosts to routers. Authors consider deploying such stateful RA 745 server with RADIUS support more complicated to deploy than the 746 solution it tries to avoid (DHCPv6). 748 As there is no well-defined central management system for prefix 749 delegation and routing options va RA, it seems that DHCPv6 is the 750 only available solution. It is better to have a generic option than 751 a bunch of competing vendor options. 753 Another concern raised is that RIO is not menadatory nor optional in 754 3GPP system and there is currently not support in 29.061 RADIUS or 755 Diameter profile, so use of that alternative is somewhat limited in 756 some cases. 758 8.3. DHCPv6 requires client to use one server 760 Claim: DHCPv6 has less rich semantics as client has to pick one out 761 of all available server. 763 Response: While that is how currently most clients are implemented, 764 there is nothing in [RFC3315] that mandates that. It is true that 765 DHCPv6 was not designed with several provisioning domains. On the 766 contrary, section 17.1.3 states that "Upon receipt of one or more 767 valid Advertise messages, the client selects one or more Advertise 768 messages based upon the following criteria.". This means that DHCPv6 769 client can obtain parameters from all available DHCPv6 servers, not 770 just selected one. As such, DHCPv6 may work with overlapping 771 provisioning domains. Authors acknowledge that this possibility is 772 currently rather theoretical, as most known implementations do not 773 take advantage of that possibility. 775 8.4. Use VLANs 777 Claim: There was a proposal to use VLANs as a solution to lack of 778 per-host capability in RA mechanism. 780 Response: Deploying VLANs complicates network topology much more than 781 adding a single DHCPv6 option. Furthermore in many cases it is not 782 possible to deploy VLANs in any reasonable way, e.g. in multihost 783 environment. Also, low cost devices (e.g. CPE) often do not offer 784 VLAN capabilities, but they are very much capable of supporting 785 DHCPv6. Another objection of estetic nature. Using layer 2 786 mechanisms to work around limitations in layer 3 is not elegant. 788 8.5. Lack of link-layer address information 790 Claim: This mechanism does not allow conveying link-layer (typically 791 MAC address) information. It may be beneficial in some cases. 793 Response: Authors believe that such information does not belong here 794 and should be obtained using Neighbor Discovery protocol [RFC4861]. 795 If proponents of adding MAC address to route options still believe 796 that existence of such option is justified, the recommended path 797 forward is to write a separate draft that defines a separate option. 798 Such option would likely be a sub-option placed within NEXT_HOP 799 option. It is recommended to include justification section in such 800 draft that would answer the question why ND is not sufficient. 802 9. IANA Considerations 804 IANA is kindly requested to allocate DHCPv6 option code TBD1 to the 805 OPTION_NEXT_HOP and TBD2 to OPTION_RT_PREFIX. Both values should be 806 added to the DHCPv6 option code space defined in Section 24.3 of 807 [RFC3315]. 809 10. Security Considerations 811 The overall security considerations discussed in [RFC3315] apply also 812 to this document. The Route option could be used by malicious 813 parties to misdirect traffic sent by the client either as part of a 814 denial of service or man-in-the-middle attack. An alternative denial 815 of service attack could also be realized by means of using the route 816 option to overflowing any known memory limitations of the client, or 817 to exceed the client's ability to handle the number of next hop 818 addresses. 820 Neither of the above considerations are new and specific to the 821 proposed route option. The mechanisms identified for securing DHCPv6 822 as well as reasonable checks performed by client implementations are 823 deemed sufficient in addressing these problems. 825 It is essential that clients verify that announced routers are indeed 826 reachable, as specified in Section 7. Failing to do so may create 827 black hole routing problem. 829 This mechanism may introduce severe problems if deployed in networks 830 that use dynamic routing protocols. See Section 4.6 for details. 832 DHCPv6 becomes a complete provisioning protocol with this mechanism, 833 i.e. all necessary configuration parameters may be delivered using 834 DHCPv6 only. It was suggested that in some cases this may lead to 835 decision of disabling RA. While RA-less networks could offer lower 836 operational expenses and protection against rogue RAs, they would not 837 work with nodes that do not support this feature. Therefore such 838 decision is not recommended, unless all effects are carefully 839 analyzed. It is worth noting that disabling RA support in hosts 840 would solve rogue RA problem, it would in fact only change the issue 841 into rogue DHCPv6 problem. That is somewhat beneficial, however, as 842 rogue RA may affect all nodes immediately while rogue DHCPv6 server 843 will affect only new nodes, that boot up after rogue server manifests 844 itself. 846 Reader is also encouraged to read DHCPv6 security considerations 847 document [I-D.ietf-dhc-secure-dhcpv6]. 849 11. Contributors and Acknowledgements 851 This document would not have been possible without the significant 852 contribution provided by: Hui Deng, Richard Johnson, and Zhen Cao. 854 The authors would also like to thank Alfred Hines, Ralph Droms, Ted 855 Lemon, Ole Troan, Dave Oran, Dave Ward, Joel Halpern, Marcin 856 Siodelski, Alexandru Petrescu, Roberta Maglione, Tim Chown, Brian 857 Carpenter, Dave Thaler, Lorenzo Colitti and Leo Bicknell for their 858 comments and useful suggestions. 860 This work has been partially supported by Department of Computer 861 Communications (a division of Gdansk University of Technology) and 862 the Polish Ministry of Science and Higher Education under the 863 European Regional Development Fund, Grant No. POIG.01.01.02-00-045/ 864 09-00 (Future Internet Engineering Project). 866 12. References 867 12.1. Normative References 869 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 870 Requirement Levels", BCP 14, RFC 2119, March 1997. 872 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 873 and M. Carney, "Dynamic Host Configuration Protocol for 874 IPv6 (DHCPv6)", RFC 3315, July 2003. 876 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 877 Host Configuration Protocol (DHCP) version 6", RFC 3633, 878 December 2003. 880 12.2. Informative References 882 [BBF-WT-124] 883 Broadband Forum, "BBF WT-124 issue 3", BBF WT-124i3, 2011. 885 [I-D.ietf-6man-addr-select-opt] 886 Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 887 Address Selection Policy using DHCPv6", 888 draft-ietf-6man-addr-select-opt-05 (work in progress), 889 August 2012. 891 [I-D.ietf-dhc-secure-dhcpv6] 892 Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", 893 draft-ietf-dhc-secure-dhcpv6-06 (work in progress), 894 March 2012. 896 [I-D.ietf-mif-dns-server-selection] 897 Savolainen, T., Kato, J., and T. Lemon, "Improved 898 Recursive DNS Server Selection for Multi-Interfaced 899 Nodes", draft-ietf-mif-dns-server-selection-12 (work in 900 progress), August 2012. 902 [I-D.ietf-v6ops-ipv6-multihoming-without-ipv6nat] 903 Matsushima, S., Okimoto, T., Troan, O., Miles, D., and D. 904 Wing, "IPv6 Multihoming without Network Address 905 Translation", 906 draft-ietf-v6ops-ipv6-multihoming-without-ipv6nat-04 (work 907 in progress), February 2012. 909 [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless 910 Static Route Option for Dynamic Host Configuration 911 Protocol (DHCP) version 4", RFC 3442, December 2002. 913 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 914 More-Specific Routes", RFC 4191, November 2005. 916 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 917 Time Option for Dynamic Host Configuration Protocol for 918 IPv6 (DHCPv6)", RFC 4242, November 2005. 920 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 921 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 922 September 2007. 924 [RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. 925 Troan, "Basic Requirements for IPv6 Customer Edge 926 Routers", RFC 6204, April 2011. 928 [THREEGPP-23.853] 929 Stojanovski, S., "3GPP TR 23.853: Operator Policies for IP 930 Interface Selection (OPIIS)", 3GPP TR 23.853, August 2011, 931 . 933 [nanog-beijnum] 934 van Beijnum, I., "", , June 2011, . 937 Authors' Addresses 939 Wojciech Dec 940 Cisco Systems 941 Haarlerbergweg 13-19 942 1101 CH Amsterdam 943 The Netherlands 945 Email: wdec@cisco.com 947 Tomasz Mrugalski 948 Internet Systems Consortium, Inc. 949 950 Charter Street 950 Redwood City, CA 94063 951 USA 953 Phone: +1 650 423 1345 954 Email: tomasz.mrugalski@gmail.com 955 Tao Sun 956 China Mobile 957 Unit2, 28 Xuanwumenxi Ave 958 Beijing, Xuanwu District 100053 959 China 961 Email: suntao@chinamobile.com 963 Behcet Sarikaya 964 Huawei USA 965 1700 Alma Dr. Suite 500 966 Plano, TX 75075 967 United States 969 Phone: +1 972-509-5599 970 Email: sarikaya@ieee.org 972 Arifumi Matsumoto 973 NTT NT Lab 974 Midori-Cho 3-9-11 975 Musashino-shi, Tokyo 180-8585 976 Japan 978 Phone: +81 422 59 3334 979 Email: arifumi@nttv6.net