idnits 2.17.1 draft-mouton-mif-dhcpv6-drlo-02.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 (September 19, 2012) is 4208 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFC 4861' is mentioned on line 520, but not defined == Missing Reference: 'CEA' is mentioned on line 633, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-17) exists of draft-ietf-dmm-requirements-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Petrescu 3 Internet-Draft CEA, LIST 4 Intended status: Experimental K. Pentikousis 5 Expires: March 23, 2013 Huawei Technologies 6 C. Janneteau 7 CEA, LIST 8 M. Mouton 9 University of Luxembourg 10 September 19, 2012 12 Default Router List Option for DHCPv6 (DRLO) 13 draft-mouton-mif-dhcpv6-drlo-02.txt 15 Abstract 17 This document specifies an experimental DHCPv6 default route option 18 which provisions static routing information to client nodes. The 19 option facilitates central configuration of a multi-access client 20 node's default router list with the IPv6 address, MAC address, and 21 lifetime of the route, which is preferred in certain multi-access 22 network environments. In addition, the DHCP option defined in this 23 document can provide operational simplicity in network coverage 24 extension scenarios using inexpensive (and limited resource) 25 consumer-grade equipment. Finally, the proposed DHCP option has been 26 implemented and tested in practice; its experimental use points to 27 benefits with respect to reduced signaling and energy consumption 28 compared to existing default route configuration mechanisms. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 23, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Applicability and Use Cases . . . . . . . . . . . . . . . . . 4 66 3.1. Large Mobile Network Use Case . . . . . . . . . . . . . . 4 67 3.2. Mi-Fi Coverage Extension Use Case . . . . . . . . . . . . 5 68 3.3. M2M Constrained Device Use Case . . . . . . . . . . . . . 6 69 4. Pertinence to the MIF Working Group . . . . . . . . . . . . . 8 70 5. Topologies and Message Exchange Diagrams . . . . . . . . . . . 8 71 5.1. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 8 72 5.2. Message Exchange . . . . . . . . . . . . . . . . . . . . . 9 73 6. DHCPv6 Default router list option . . . . . . . . . . . . . . 10 74 6.1. Option format . . . . . . . . . . . . . . . . . . . . . . 10 75 6.1.1. Client side . . . . . . . . . . . . . . . . . . . . . 10 76 6.1.2. Server side . . . . . . . . . . . . . . . . . . . . . 11 77 6.2. Optimization . . . . . . . . . . . . . . . . . . . . . . . 12 78 6.3. Default router lifetime management . . . . . . . . . . . . 13 79 7. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. ChangeLog . . . . . . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The Neighbor Discovery protocol [RFC4861] is currently considered as 92 the best way for providing a default route information to a client in 93 IPv6 networks. Hence it was not considered necessary for DHCPv6 94 [RFC3315] to have this feature. But, recently, certain deployment 95 scenarios express a need not to use the neighbor discovery 96 autoconfiguration mechanism. 98 For example, a distinct trend is shaping up towards centralization in 99 network configuration and management. In this trend, contrary to 100 Stateless Address Autoconfiguration (SLAAC) [RFC4862], which requires 101 provisioning and distributing configuration information at each 102 router, certain configuration information can be centralized in a 103 server and then distributed when needed through DHCPv6. This means 104 that, for instance, all subnet configurations can be managed via a 105 single configuration database containing all IP prefix information, 106 DNS server addresses, timers, and others - in an on demand manner. 107 As we will see below, in practice, there are several scenarios where 108 the administrator of a large, complex network architecture including 109 numerous routers and access points may prefer a more centralized, 110 stateful autoconfiguration solution which capitalizes on the 111 widespread deployment of DHCPv6 to facilitate operation and 112 management for multiaccess networks. Ease of deployment, operation 113 and management are key design consideration for future mobile 114 networks (e.g., see [Penti2011] and the references therein). 116 This draft specifies an experimental DHCPv6 option which can be used 117 to populate the ND Neighbor Cache as pointed to by the ND Default 118 Router List (this data is colloquially named "a default router list" 119 in the remainder of this document). This option is similar to the 120 DHCPv4 option router [RFC2132]. Contrary to DHCPv4, however, this 121 option also provides router lifetime (thus enabling mechanisms such 122 as automatic renumbering) and optionally the default router's link- 123 layer address. Lifetime and link-layer address are necessary for a 124 coherent implementation of DHCP and ND data structures. They are 125 particularly useful in the context of mobile networks and pertinent 126 to multihoming nodes for managing several default routers in order to 127 address service continuity issues. 129 Using DHCPv6 to provide a default route to a client was previously 130 advocated in [I-D.droms-dhc-dhcpv6-default-router]. Additionally, 131 [I-D.ietf-mif-dhcpv6-route-option] presents a method to distribute 132 routes, in a generic manner, to DHCP Clients. The route-option draft 133 describes a capability to communicate a default route as a particular 134 case of a route (use destination prefix "::" with prefix length 0, 135 and address of the default router). But (1) this draft needs a means 136 to communicate the MAC address of the default router, and (2) avoids 137 to communicate multiple default routers to the same Client. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in RFC 2119 [RFC2119]. 145 This document uses also the terminology defined in [RFC3315], 146 [RFC3963] and [RFC4862]. 148 3. Applicability and Use Cases 150 This section describes use cases relevant to the experimental DHCP 151 option proposed in this document and explains how its deployment can 152 improve network management. We explore three use cases, although we 153 expect that the solution has other applications as well. First, we 154 discuss the use of the proposed option in a large mobile network 155 where the administrator/operator prefers to have centralized control 156 of the default routes used by different nodes. Second, we consider 157 the Mi-Fi coverage extension case where the need is to control the 158 devices connecting to the mobile network in an ad-hoc manner over 159 consumer-grade equipment. Finally, we look into M2M constrained 160 router devices where configuration message exchanges need to be as 161 few as possible, in the interest of energy and other network resource 162 consumption. Scenarios like these have been long described in the 163 research literature; see, for example [Sollner2008] and the 164 references therein. 166 3.1. Large Mobile Network Use Case 168 There is no doubt that most users today access the Internet over a 169 wireless network. This trend is expected to continue unabated for 170 the foreseeable future. The current generation of mobile networks 171 features a largely hierarchical structure, in part due the origins of 172 the technologies used in wireless telecommunication networks 173 [Penti2011]. Another part has to do with the strong push for 174 centralized control for technical and business reasons. While it is 175 expected that more distribution, for example, in mobility management 176 is to be expected [I-D.ietf-dmm-requirements], other trends point to 177 the need for more centralized network control loops [Cori2012]. 179 The experimental DHCPv6 option specified in this document is 180 applicable to both cases. In a network where more centralization is 181 preferred, multi-mode nodes can receive different default route 182 configuration (including route lifetime) with the aid of a 183 centralized database and DHCPv6, as described in Section Section 5.1. 184 This may prove particularly useful for enabling the network to select 185 the best default route for multihomed nodes depending on monitoring 186 information collected from various network elements. In addition, 187 the network can use the option specified in this document to steer 188 traffic from newly attached nodes to a different default router due 189 to network maintenance operations. On the other hand, an IP network 190 adopting control/data plane separation for certain mechanisms can 191 benefit from the use of this option in some subnets depending on 192 several factors. For instance, we expect that this can ease the 193 incremental deployment of the aforementioned mechanisms by 194 maintaining a tightly controlled centralized view of the network. 196 3.2. Mi-Fi Coverage Extension Use Case 198 This use case relates to residential access and, in particular, to 199 wireless network extension scenarios, including those involving 200 personal portable devices connected to cellular or other wide-area 201 networks. Devices like these, popularly referred to as "Mi-Fi", 202 enable a user to take advantage of her cellular subscription, for 203 example, and connect other devices to the Internet. Mi-Fi devices 204 can be standalone, i.e. provide no other functionality than acting as 205 interconnection points, are typically small in size (hence mobile), 206 and tend to be inexpensive. 208 Mi-Fi devices have gained in popularity in recent years as they allow 209 other Wi-Fi-only devices to be connected to the Internet via a 210 cellular network in the absence of Wi-Fi coverage. For example, a 211 Mi-Fi device can connect up to five other devices over its Wi-Fi 212 interface to a cellular network. Typical users carry Mi-Fi devices 213 around and often use them to connect very different sets of Wi-Fi 214 devices even within the same day. For instance, a mobile network 215 subscriber can use the Mi-Fi device to enable Internet connectivity 216 to the user's pad and laptop at home, connect a pod to a streaming 217 Internet radio service while the user is in the car to work, and 218 offer ad-hoc Internet connectivity to friends and colleagues at an 219 IETF meeting. It may be often desirable to configure different 220 default routes through the mobile network. Note that, in practice, 221 said device could be dedicated to the role of providing tethered 222 access or it can be a typical multiaccess smartphone extending 223 network coverage to neighboring nodes. 225 From the network perspective, the operation of all connected nodes 226 should be still managed efficiently although connectivity is 227 maintained through a low-end consumer device. This includes the 228 default routes as well as IP address lease times. In this use case, 229 the Mi-Fi device does not play the role of a router, but it can act 230 as a DHCP relay or a server. In the former case, the Mi-Fi DHCP 231 relay agent forwards the request as per usual, indicating its DUID, 232 and the default router assignment occurs at the network side 233 explicitly as each Wi-Fi device connects to the Mi-Fi-based local 234 wireless network. Alternatively, the Mi-Fi device makes the default 235 router assignment locally, based on the configuration information it 236 has received using the proposed option. In either case, the network 237 can configure, on demand, different default routes depending on the 238 Mi-Fi location and point of attachment to the mobile network. 239 Moreover, the network can provide different route lifetimes depending 240 on the operational context. Note that the often battery-powered 241 Mi-Fi device should not broadcast connectivity information in order 242 to keep power consumption low and reduce information leakage. In 243 short, from the device perspective, power consumption is reduced and 244 the Wi-Fi devices do not need any updates, while, from the network 245 perspective, the advantages of centralized management are 246 significant. 248 3.3. M2M Constrained Device Use Case 250 For a constrained M2M Gateway it is advantageous to use solely the 251 DHCPv6 protocol to configure a default route, an address and a 252 delegated prefix, instead of using both protocols ND and DHCPv6. 254 Machine-to-Machine communication (M2M) has recently been employed in 255 large-scale deployments in various markets such as cellular 256 telecommunications, home networking, smart energy management, eHealth 257 and vehicular communications. A machine device is typically a highly 258 constrained computing and communicating platform: for example an 259 8-bit processor with a GSM module powered by a button cell. Other, 260 more powerful machine devices, include more than a single means of 261 communication. Without going into detail, it is acknowledged that 262 whereas many different classes of machine devices exist, their key 263 characteristics are generally the following: simplicity, small 264 dimensions, low cost, and unattended operation for extended periods 265 of time. 267 An M2M Gateway is a machine-class device which has two or more 268 interfaces. One of the interfaces has long range wireless data 269 capability (e.g., LTE-M). This Gateway is in charge of obtaining 270 Internet connectivity and offering Internet connectivity to other 271 machine-class devices. Since it ought to run unattended for extended 272 periods of time, it must be easily auto-configurable. In other 273 words, the most important IP parameters must be configured 274 automatically. 276 A basic IPv6 configuration includes IPv6 prefix and a default route 277 to global Internet. Devices with limited CPU and memory capacity can 278 benefit from the sole presence of a default route in their routing 279 tables: it is sufficient to store the default route only in order to 280 be able to reach any other node in the Internet. In this sense, the 281 default route is a very strong candidate for implementation in small 282 devices as it is possible to avoid storing other routes, while still 283 maintaining connectivity to every other device in the Internet. 284 Using a default route instead of a large number of specific routes 285 helps keeping routing table sizes extremely compact, which is 286 essential in the case of machine-class devices. 288 For these reason, it is important to have a suitable mechanism for 289 assigning default routes to end nodes: M2M Device and M2M Gateway. A 290 Gateway can be considered as an emph(almost)-end node: it is situated 291 one or a few IP hops away from the end. 293 In addition to the IPv6 prefix (for its own interface(s)) and the 294 default route to the global Internet, the M2M Gateway needs to be 295 configured with an additional IPv6 prefix, call it P. This prefix P 296 is to be used by the devices 'behind' the M2M Gateway - each such 297 device needs to auto-configure an address for itself. This prefix P 298 is the delegated prefix. 300 The currently defined mechanisms to automatically configure the 301 triplet [IPv6 address, default route, delegated prefix] to a node, 302 such as as the M2M Gateway in our example, are two: Neighbor 303 Discovery and DHCPv6 Prefix Delegation. Hence, two full protocol 304 implementations are needed for an M2M Gateway because, on the one 305 hand, Neighbor Discovery (ND) cannot delegate prefixes and, on the 306 other, DHCPv6 cannot configure default routes. Some implementers 307 find that using two different protocols for obtaining the 308 aforementioned triplet is an unnecessary burden for machine-class 309 devices: the needs in terms of memory size are almost two times as 310 much, the number and size of exchanged messages are almost doubled, 311 and so on. In short, for a constrained M2M Gateway implementation it 312 is advantageous to use solely the DHCPv6 protocol to configure a 313 default route, an address and a delegated prefix, instead of using 314 both ND and DHCPv6. 316 It would thus be advantageous to define options for the DHCPv6 317 protocol which can be used to assign the missing parameter from the 318 triplet (i.e. a default route) to an M2M Gateway, instead of using 319 both ND and DHCPv6 to achieve the same task. 321 Experiments with an actual implementation, which uses the DHCPv6 322 default route proposed in this draft, have shown a reduction in 323 message counts from 6 to 4 (when comparing the combined use of DHCPv6 324 and ND, versus solely DHCPv6 with the option proposed herein, to make 325 the same configuration). 327 4. Pertinence to the MIF Working Group 329 The Multiple Interfaces WG (MIF) is treating of hosts which have the 330 ability to attach to multiple networks simultaneously. The WG is 331 chartered to produce, among other products, extensions to DHCPv6 to 332 "provision client nodes with small amount of static routing 333 information". 335 The mechanism described in this draft, can be used to communicate 336 several static default routes (triplets of the form gw-mac-lifetime) 337 to a single host which can have several interfaces. 339 The distinction among the default routes (once installed on a client) 340 can be realized according to various criteria: (1) use a form of 341 Preferences, new extensions similar to RFC 4191, (2) use the Lifetime 342 communicated by the mechanism of this draft to distinguish among 343 default routes according to new rules, (3) use a random function to 344 pick a default route, (4) use a new interface name in the ORO and in 345 the Ack to specify which default route uses which interface, (5) use 346 a new field containing a source address which the client must use for 347 a particular default route, and more. 349 5. Topologies and Message Exchange Diagrams 351 5.1. Topologies 353 This section describes two simple topologies which abstract the use 354 cases described above: one involving a server and a client and 355 another implying in addition a relay. 357 Client/Server topology: 359 +------+ +------+ 360 |DHCPv6|--------|DHCPv6| 361 |server| link |client| 362 +------+ +------+ 364 Figure 1: Simple Client-Server topology 366 In this topology, a client with no IPv6 configuration needs to obtain 367 an Internet access and does not intend to use SLAAC. It asks the 368 DHCPv6 Server the three necessary settings: an IPv6 address, a 369 default router address and a DNS server in a solicit message. The 370 DHCPv6 Server receives this Solicit message and sends back the 371 parameters necessary fo IPv6 configuration. 373 Client/Relay/Server topology: 375 +------+ +------+ +------+ 376 |DHCPv6|--....--|DHCPv6|--------|DHCPv6| 377 |server|ethernet|relay |ethernet|client| 378 +------+ +------+ +------+ 380 Figure 2: Simple Client-Relay-Server topology 382 Again, a client with no IPv6 configuration tries to obtain an 383 Internet access and doesn't want to use SLAAC. It asks the DHCPv6 384 server the same way as in previous figure but the DHCPv6 server is 385 not on the same link. The DHCPv6 relay takes client DHCPv6 message 386 and delivers it to the server. The server knows that the message is 387 relayed and send its responses back to the relay. 389 5.2. Message Exchange 391 There are two main message exchange scenarios corresponding to the 392 use or not of a relay. The message exchange when the client is not 393 on the same link with the server is the following: 395 +------+ +------+ 396 |DHCPv6| |DHCPv6| 397 |client| |server| 398 +------+ +------+ 399 | | 400 | DHCPv6 Solicit | 401 |------------------------->| 402 | | 403 | DHCPv6 Advertise | 404 |<-------------------------| 405 | | 406 | DHCPv6 Request | 407 |------------------------->| 408 | | 409 | DHCPv6 Reply | 410 |<-------------------------| 411 | | 413 Figure 3: Client-Server message exchange 415 A normal exchange between a new Client and a DHCPv6 Server consists 416 of four messages: Solicit, Advertise, Request, and Reply. In a 417 Solicit/Request packet a Client lists wanted options in the Option 418 Request Option (ORO). This option is composed of a list of option 419 codes. The DHCPv6 Server answers those packets with Advertise/Reply 420 packets containing values for the options asked by the Client. 422 The message exchange when using a relay, because the client and the 423 server are not on the same link is illustrated in Figure 4. 425 +------+ +------+ +------+ 426 |DHCPv6| |DHCPv6| |DHCPv6| 427 |client| |relay | |server| 428 +------+ +------+ +------+ 429 | | | 430 | DHCPv6 Solicit | DHCPv6 Relay-forw | 431 |------------------------->|===========================>| 432 | | | 433 | DHCPv6 Advertise | DHCPv6 Relay-reply | 434 |<-------------------------|<===========================| 435 | | | 436 | DHCPv6 Request | DHCPv6 Relay-forw | 437 |------------------------->|===========================>| 438 | | | 439 | DHCPv6 Reply | DHCPv6 Relay-reply | 440 |<-------------------------|<===========================| 441 | | | 443 Figure 4: Client-Relay-Server message exchange 445 The relay receives the message from the client and forwards it to the 446 server in a Relay-forw message. The server replies to the relay with 447 an advertise/reply message encapsulated in a Relay-reply message. 448 The content of this message is extracted by the relay and sent to the 449 client. 451 6. DHCPv6 Default router list option 453 6.1. Option format 455 6.1.1. Client side 457 In its DHCPv6 requests, the client sends a list of required options 458 in the option request option (ORO). The format of this option is the 459 following: 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | OPTION_ORO | option-len | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | requested-option-code | | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | ... | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 Figure 5: DHCPv6 option request option field 473 The proposed option (to fill in the field requested-option-code in 474 the diagram above) is named in this draft OPTION_DEFAULT_ROUTER_LIST. 475 It is possible to concatenate this value with several other existing 476 requested-option-code's. 478 The value of this code of this option is TBD (to be defined) and/or 479 TBA (to be assigned). 481 6.1.2. Server side 483 The default router list option is illustrated below: 485 0 1 2 3 486 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 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | OPTION_DEFAULT_ROUTER_LIST | option-len | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 | router_address | 492 | | 493 | | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | router_lifetime | lla_len | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 497 . router_link_layer_address(opt) . 498 . ... . 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 Figure 6: DHCPv6 default router list option field 503 As this option contains a list, the pattern containing 504 router_address, router_lifetime, lla_len and optionnaly 505 router_link_layer_address can be repeated. 507 option-code 508 OPTION_DEFAULT_ROUTER_LIST (TBA) 510 option-len 511 length of the default router list option in bytes. It has a 512 value of minimum 23 (decimal representation). 514 router_address 515 default router IPv6 address (16 bytes) 517 router_lifetime 518 16-bit unsigned integer. Router lifetime in units of 519 seconds. Limit value is 9000, while the value 0 SHOULD NOT 520 appear, as explained in section 6 of [RFC 4861]. 522 lla_len 523 8-bit unsigned integer. The size of the link layer address 524 of the router in bytes. Equals to 0 if no link layer address 525 is given. 527 router_link_layer_address 528 link layer address of the router. Its length is not known in 529 advance and need to be inquired in lla_len field. This field 530 is optional. 532 This option contains an optional variable length field 533 router_link_layer_address. Router_address and router_lifetime 534 field's size are fixed. 536 There are two alternative possibilities of using router information 537 in the list: 539 o Not using router_link_layer_address: DHCPv6 server communicates 540 router_address and router_lifetime with lla_len equals to 0. 541 Default router's information is finished at the end of lla_len. 543 o Using router_link_layer_address: DHCPv6 server communicates 544 router_address and router_lifetime with lla_len equals to k, where 545 k is the size of the link-layer address. After the field lla_len 546 the default router's information is finished after reading k more 547 bytes. 549 6.2. Optimization 551 An optimization is possible: removing lla_len field for the last 552 element of a default router list when that is not necessary. Prima 553 facie, one may consider that removing one byte may not be worth the 554 effort of the implementation complexity. This is why this draft 555 proposes to apply this optimization in only one simple but fairly 556 frequent case: if the last element (i.e. the triplet address-MAC- 557 lifetime) of a list (i.e., if there are more than one elements) has 558 no link-layer address. As a matter of fact it has the advantage of 559 removing 8 zero bits. This case occurs each time a network 560 administrator does not want to use the router_link_layer_address. 561 This case is frequent enough to justify an optimization. Moreover 562 this optimization has been implemented and does not require a huge 563 amount of intellectual effort (around 10 extra lines of code). 565 6.3. Default router lifetime management 567 This draft proposes to use default router lifetime in the same manner 568 as [RFC4861]. This has the following consequences. 570 When a default router lifetime is equal to 0 it MUST be deleted from 571 the Default Router list, Neighbor cache and other related Forwarding 572 Information Bases. 574 Following [RFC4861] Section 6, this document proposes to limit the 575 lifetime to 9000 (decimal) seconds. 577 7. Open issues 579 In addition to the default router address, lifetime and link-layer 580 address, the neighbor discovery mechanism also provides MTU, hop 581 limit, reachable time, retransmission timer, and textual name of the 582 interface. This information can be defined in other DHCPv6 options 583 extending this draft, if needed. 585 The DHCP and Neighbor Discovery protocols manage router lifetime 586 differently. DHCPv6 [RFC3315] specifies lifetimes typically in a 587 4-byte field. On the other hand, the Neighbor Discovery protocol 588 defines a 2-byte field for lifetime. In addition, it defines a 589 lifetime limit equaling 9000 making the use of 4-byte fields 590 unnecessary. Because of this, this draft proposes adopts the ND 591 approach and includes a 2-byte field for router lifetime. 593 The simultaneous use of DHCP and Router Advertisement mechanisms to 594 communicate default routes is out of the scope of this specification. 596 8. Security Considerations 598 Security considerations referring to DHCPv6 are described in 599 [RFC3315] and other more recent Internet Drafts. The new option 600 described here should not add new threats. However, it is worth 601 mentioning that the high importance of a default route (it must work 602 when everything else fails) represents also a high risk when 603 successful attacks - if at all - happen. 605 9. IANA Considerations 607 The proper working of this extension to DHCPv6 to support default 608 routers rely on using a unique number for OPTION_DEFAULT_ROUTER_LIST. 610 In this sense, and when agreed to take on this path, IANA will be 611 demanded to assign an option code to OPTION_DEFAULT_ROUTER_LIST, if 612 deemed necessary. 614 Currently, the local prototype implementation uses the number 66 615 (decimal) for this field. 617 10. Acknowledgements 619 The authors would like to acknowledge the useful technical 620 contribution of Mathias Boc, Sofian Imadali and Arnaud Kaiser. 622 Authors appreciate the particularly stimulating discussion about 623 default route and DHCPv6 in the email lists of DHC, MIF and 6MAN 624 Working Groups. 626 Recently, Tomasz Mrugalski offered insight about default routes 627 potentially used by draft-dec-dhcpv6-route-option-02. Mikael 628 Abrahamsson suggested communicating a source address when discussing 629 default route and DHCPv6. 631 This work has been performed in the framework of the ICT project ICT- 632 5-258512 EXALTED, which is partly funded by the European Union. The 633 organisations on the source list [CEA] would like to acknowledge the 634 contributions of their colleagues to the project, although the views 635 expressed in this contribution are those of the authors and do not 636 necessarily represent the project. 638 11. References 640 11.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 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 646 Extensions", RFC 2132, March 1997. 648 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 649 and M. Carney, "Dynamic Host Configuration Protocol for 650 IPv6 (DHCPv6)", RFC 3315, July 2003. 652 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 653 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 654 RFC 3963, January 2005. 656 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 657 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 658 September 2007. 660 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 661 Address Autoconfiguration", RFC 4862, September 2007. 663 11.2. Informative References 665 [Cori2012] 666 Corici, M I., Hasse, P., Kappler, C., Pentikousis, K., 667 Roth, R., and M. Schramm, "Cost-controlled monitoring 668 information collection in heterogeneous mobile network 669 infrastructures", Proceedings of the IEEE International 670 Conference on Communications Workshops 671 (Telecommunications: From Research to Standards), Ottawa, 672 Canada , June 2012. 674 [I-D.droms-dhc-dhcpv6-default-router] 675 Droms, R. and T. Narten, "Default Router and Prefix 676 Advertisement Options for DHCPv6", 677 draft-droms-dhc-dhcpv6-default-router-00 (work in 678 progress), March 2009. 680 [I-D.ietf-dmm-requirements] 681 Chan, A., "Requirements for Distributed Mobility 682 Management", draft-ietf-dmm-requirements-02 (work in 683 progress), September 2012. 685 [I-D.ietf-mif-dhcpv6-route-option] 686 Dec, W., Mrugalski, T., Sun, T., Sarikaya, B., and A. 687 Matsumoto, "DHCPv6 Route Options", 688 draft-ietf-mif-dhcpv6-route-option-05 (work in progress), 689 August 2012. 691 [Penti2011] 692 Pentikousis, K., "Design considerations for mobility 693 management in future infrastructure networks", ITU Telecom 694 World 2011 Technical Symposium, Geneva, Switzerland , 695 October 2011. 697 [Sollner2008] 698 Sollner, M., Gorg, C., Pentikousis, K., Cabero-Lopez, J 699 M., Ponce de Leon, M., and P. Bertin, "Mobility scenarios 700 for the Future Internet: The 4WARD approach", Proceedings 701 of the 11th International Symposium on Wireless Personal 702 Multimedia Communications (WPMC), Saariselk, Finland , 703 September 2008. 705 Appendix A. ChangeLog 707 The changes are listed in reverse chronological order, most recent 708 changes appearing at the top of the list. 710 From draft-mouton-mif-dhcpv6-drlo-01.txt to 711 draft-mouton-mif-dhcpv6-drlo-02.txt: 713 o New author entry. 715 o Extended and detailed the use cases where this DHCPv6 option may 716 be used to communicate a default route. 718 o Explained that this is experimental, an implementation exists and 719 a gain in number of messages exchanged has been demonstrated. 721 o Rephrased completely the abstract. 723 From draft-mouton-mif-dhcpv6-drlo-00.txt to 724 draft-mouton-mif-dhcpv6-drlo-01.txt: 726 o Date change, author ordering and affiliation. 728 Authors' Addresses 730 Alexandru Petrescu 731 CEA, LIST 732 Communicating Systems Laboratory, Point Courrier 173 733 Gif-sur-Yvette, F-91191 734 France 736 Phone: +33(0)169089223 737 Email: alexandru.petrescu@cea.fr 738 Kostas Pentikousis 739 Huawei Technologies 740 Carnotstr. 4 741 Berlin, D-10585 742 Germany 744 Phone: 745 Email: k.pentikousis@huawei.com 747 Christophe Janneteau 748 CEA, LIST 749 Communicating Systems Laboratory, Point Courrier 173 750 Gif-sur-Yvette, F-91191 751 France 753 Phone: +33(0)169089182 754 Email: christophe.janneteau@cea.fr 756 Maximilien Mouton 757 University of Luxembourg 758 Interdisciplinary Center for Security, Reliability and Trust 759 Luxembourg, 760 Luxembourg 762 Phone: 763 Email: maximilien.mouton@uni.lu