idnits 2.17.1 draft-jjmb-dhc-dhcpv6-redundancy-consider-01.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 12, 2010) is 5030 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-dhc-dhcpv6-opt-netboot-09 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dhc J. Brzozowski 3 Internet-Draft Comcast Cable Communications 4 Intended status: BCP J. Tremblay 5 Expires: January 13, 2011 Videotron Ltd. 6 J. Chen 7 Time Warner Cable 8 T. Mrugalski 9 Gdansk University of Technology 10 July 12, 2010 12 DHCPv6 Redundancy Deployment Considerations 13 draft-jjmb-dhc-dhcpv6-redundancy-consider-01 15 Abstract 17 This document documents some deployment considerations for those who 18 wishing to use DHCPv6 to support their deployment of IPv6. 19 Specifically, providing semi-redundant DHCPv6 services is discussed 20 in this document. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Scope and Assumptions . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Service provider model . . . . . . . . . . . . . . . . . . 4 59 2.2. Enterprise model . . . . . . . . . . . . . . . . . . . . . 4 60 3. Protocol requirements . . . . . . . . . . . . . . . . . . . . 5 61 3.1. DHCPv6 Servers . . . . . . . . . . . . . . . . . . . . . . 5 62 3.2. DHCPv6 Relays . . . . . . . . . . . . . . . . . . . . . . 5 63 3.3. DHCPv6 Clients . . . . . . . . . . . . . . . . . . . . . . 5 64 4. Deployment models . . . . . . . . . . . . . . . . . . . . . . 6 65 4.1. Split Prefixes . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Multiple Unique Prefixes . . . . . . . . . . . . . . . . . 8 67 4.3. Identical Prefixes . . . . . . . . . . . . . . . . . . . . 10 68 5. Challenges and Issues . . . . . . . . . . . . . . . . . . . . 12 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 72 9. Normative References . . . . . . . . . . . . . . . . . . . . . 14 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 To support the deployment of IPv6 redundancy and high availability 78 are required for many if not all components. This document provides 79 information specific to the proposed near term approach for deploying 80 semi-redundant DHCPv6 services in advance of DHCPv6 server 81 implementations that support a standards based failover or redundancy 82 protocol. 84 2. Scope and Assumptions 86 This document specifies an interim architecture to provide a semi- 87 redundant DHCPv6 solution before the availability of vendor or 88 standard based solutions. The proposed architecture may be used in 89 wide range of networks, two notable deployment models are discussed: 90 service provider and enterprise network environments. The described 91 architecture leverages only existing and implemented DHCPv6 92 standards. This document does not address a standards based solution 93 for DHCPv6 redundancy. In the absence of a standards based DHCPv6 94 redundancy protocol and implementation, some analogies are loosely 95 drawn with the DHCPv4 failover protocol for reference. Specific 96 discussions related to DHCPv4 failover and redundancy is out of scope 97 for this document. 99 Although DHCPv6 redundancy may be useful in a wide range of 100 scenarios, they may be generalized for illustration purposes in the 101 two aforementioned. The following assumptions were made with regards 102 to the existing DHCPv6 infrastructure, regardless of the model used: 104 1. At least two DHCPv6 servers are used to service to the same 105 clients, but the number of servers is not restricted. 107 2. Existing DHCPv6 servers will not directly communicate or interact 108 with one another in the assignment of IPv6 addresses and 109 configuration information to requesting clients. 111 3. DHCPv6 clients are instructed to run stateful DHCPv6 to request 112 at least one IPv6 address. Configuration information and other 113 options like a delegated IPv6 prefix may be also requested. 115 4. Clients requesting IPv6 addresses, prefixes, and or options care 116 of DHCPv6 must recognize and honor the DHCPv6 preference option. 117 Furthermore, the requesting clients must process DHCPv6 ADVERTISE 118 messages per [RFC3315] when the preference option is present. 120 5. DHCPv6 server failure does not imply failure of any other network 121 service or protocol, e.g. TFTP servers. Redundancy of any 122 additional services configured by means of DHCPv6 are outside of 123 scope of this document. For example, a single DHCPv6 server may 124 configure multiple TFTP servers, with preference for each TFTP 125 server, as specified in [I-D.ietf-dhc-dhcpv6-opt-netboot]. 127 2.1. Service provider model 129 The service provider model represents cases, where end-user devices 130 may be configured directly, without any intermediate devices (like 131 home routers used in service provider model). DHCPv6 clients include 132 cable modems, customer gateways or home routers, and end-user 133 devices. In some cases hosts may be configured directly using the 134 service provider DHCPv6 infrastructure or via intermediate router, 135 that is in turn being configured by the provider DHCPv6 136 infrastructure. The service provider DHCPv6 infrastructure may be 137 semi-redundant in either case. Cable modems, customer gateways or 138 home routers, and end-user devices are commonly referred to as CPE 139 (Customer Premises Equipment). The following additional assumptions 140 were made, besides the ones made in Section 2: 142 1. The service provider edge routers and access routers (CMTS for 143 cable or DSLAM/BRAS for DSL for example) are IPv6 enabled when 144 required. 146 2. CPE devices are instructed to perform stateful DHCPv6 to request 147 atleast one IPv6 address, delegated prefix, and or configuration 148 information. CPE devices may also be instructed to leverage 149 stateless DHCPv6 [RFC3736] to acquire configuration information 150 only. This assumes that IPv6 address and prefix information has 151 been acquired using other means. 153 3. The primary application of this BCP is for native IPv6 services. 154 Use and applicability to transition mechanisms is out of scope 155 for this document. 157 4. CPE devices must implement a stateful DHCPv6 client [RFC3315], 158 support for DHCPv6 prefix delegation [RFC3633] or stateless 159 DHCPv6 [RFC3736] may also be implemented. 161 2.2. Enterprise model 163 The enterprise model represents cases, where end-user devices are 164 most often configured directly, without any intermediate devices 165 (like home routers used in service provider model). However, 166 enterprise IPv6 environments quite often use or require that DHCPv6 167 relay agents are in place to support the use of DHCPv6 for the 168 acquisition of IPv6 addresses and or configuration information. The 169 assumptions here extend those that are defined in the beginning of 170 Section 2: 172 1. DHCPv6 clients are hosts and are considered end nodes. Examples 173 of such clients include computers, laptops, and possibily mobile 174 devices. 176 2. DHCPv6 clients generally do not require the assignment of an IPv6 177 prefix delegation and as such do not support DHCPv6 prefix 178 delegation [RFC3633]. 180 3. Protocol requirements 182 The following sections outline the requirements that must be 183 satisfied by DHCPv6 clients, relays, and servers to ensure the 184 desired behavior is provided using pre-existing DHCPv6 server 185 implementations as is. The objective is to provide a semi-redundant 186 DHCPv6 service to support the deployment of IPv6 where DHCPv6 is 187 required for the assignment of IPv6 addresses, prefixes, and or 188 configuration information. 190 3.1. DHCPv6 Servers 192 This interim architecture requires DHCPv6 servers that are RFC 3315 193 [RFC3315] compliant and support the necessary options required to 194 support this solution. Essential to the the use of the interim 195 architecture is support for stateful DHCPv6 and the DHCPv6 preference 196 option both which are specified in [RFC3315]. For deployment 197 scenarios where IPv6 prefix delegation is employed DHCPv6 servers 198 must support DHCPv6 prefix delegation as defined by [RFC3633]. 199 Further, where stateless DHCPv6 is used support for [RFC3736] is 200 required by DHCPv6 servers. 202 3.2. DHCPv6 Relays 204 There are no specific requirements regarding relays. However, it is 205 implied that DHCPv6 relay agents must be [RFC3315] compliant and must 206 support the ability to relay DHCPv6 messages to more than one 207 destination minimally. 209 3.3. DHCPv6 Clients 211 DHCPv6 clients are required to be compliant to [RFC3315] and support 212 the necessary options required to support this solution depending on 213 the mode of operations and desired behavior. Where prefix delegation 214 is required DHCPv6 clients will be required to support DHCPv6 prefix 215 delegation as defined in [RFC3633]. Clients used with this semi- 216 redundant DHCPv6 deployment model must support the acquistion of at 217 least one IPv6 address and configuration information using stateful 218 DHCPv6 as specified by [RFC3315]. The use of stateless DHCPv6 which 219 is also specified in [RFC3315] may also be supported. DHCPv6 client 220 must recognize and adhere to the processing of the advertised DHCPv6 221 preference options sent by the DHCPv6 servers. 223 4. Deployment models 225 At the time of this writing a standards-based DHCPv6 redundancy 226 protocol and implementations are not available. As a result DHCPv6 227 server implementations will be used as-is to provide best effort, 228 semi-redundant DHCPv6 services. Behavior of the DHCPv6 services will 229 in part be governed by the configuration used by each of the servers. 230 Additionally, various aspects of the DHCPv6 protocol [RFC3315] will 231 be leveraged to yield the desired behavior. No inter-server or 232 inter-process communications will be used to coordinate DHCPv6 events 233 and or activities. DHCP services for both IPv4 and IPv6 may operate 234 simultaneously on the same physical server(s) or may operate on 235 different ones. 237 4.1. Split Prefixes 239 In the split prefixes model, each DHCPv6 server is configured with a 240 unique, non-overlapping range derived from the /64 prefix deployed 241 for use within an IPv6 network. Distribution between two servers, 242 for example, would require that an allocated /64 be split in two /65 243 ranges. 2001:db8:1:0001:0000::/65 and 2001:db8:1:0001:8000::/65 would 244 be assigned to each DHCPv6 server for allocation to clients derived 245 from 2001:db8:1:0001::/64 prefix. 247 Each DHCP server allocates IPv6 addresses from the corresponding 248 ranges per device class. Each DHCPv6 server will be simultaneously 249 active and operational. Address allocation is governed largely 250 through the use of the DHCPv6 preference option, so server with 251 higher preference value is always prefered. Additional proprietary 252 mechanisms can be leveraged to further enforce the favoring of one 253 DHCP server over another. Example of such scenario is presented in 254 Figure 1. 256 It is important to note that over time, it is possible that bindings 257 may be disproportionally distributed amongst DHCPv6 servers and not 258 any one server will be authoritative for all bindings. Per 259 [RFC3315], a DHCPv6 ADVERTISE messages with a preference option of 260 255 is an indicator to a DHCPv6 client to immediately begin a client- 261 initiated message exchange by transmitting a REQUEST message. 262 Alternatively, a DHCPv6 ADVERTISE messages with a preference option 263 of any value lesser than 255 or is absent is an indicator to the 264 client that it must wait for subsequent ADVERTISE messages (for a 265 specified period of time) before proceeding. Additionally, in the 266 event of a DHCPv6 server failure it is desirable for a server other 267 than the server that originally responded to be able to rebind the 268 client. It is not critical, that the DHCPv6 server be able to rebind 269 the client in this scenario, however, this is generally desirable 270 behavior. Given the proposed architecture, the remaining active 271 DHCPv6 server will have a different range configured making it 272 technically incorrect for the same to rebind the client in its 273 current state. Ultimately, when rebinding fails the client will 274 acquire a new binding from the configured range unique to an active 275 server. Furthermore, shorter T1, T2, valid, and preferred lifetimes 276 can be used to reduce the possibility that a client or some other 277 element on the network will experience a disruption in service or 278 access to relevant binding data. The values used for T2, preferred 279 and valid lifetime can be adjusted or configured to minimize service 280 disruption. Ideally T2, preferred and valid lifetimes that are equal 281 or near equal can be used to trigger a DHCPv6 client to reacquire 282 IPv6 address, prefix, and or configuration information almost 283 immediately after rebinding fails. It is important to note that 284 shorter values will most certainly create additional load and 285 processing for the DHCPv6 server, which must be considered. 287 Using a split prefix configuration model dynamic updates to DNS can 288 be coordinated to ensure that the DNS is properly updated with 289 current binding information. Challenges arise with regards to the 290 update of PTR for IPv6 addresses since the DNS may need to be 291 overwritten in a failure condition. The use of a split prefixes 292 enables the differentiation of bindings and binding timing to 293 determine which represents the current state. This becomes 294 particularly important when DHCPv6 Leasequery [RFC5007] and/or DHCPv6 295 Bulk Leasequery [RFC5460] are leveraged to determine lease or binding 296 state. An additional benefit is that the use of separate ranges per 297 DHCPv6 server makes failure conditions more obvious and detectable. 299 (@todo - add more useful illustration) 300 +----------+ +-----------+ 301 | Client 1 +-\ +--+ Server 1 | 302 +----------+ \ | +-----------+ 303 \ | 304 \ | 305 \ | 306 +----------+ \ | +-----------+ 307 | Client 2 +--------------+--| Server 2 | 308 +----------+ / | +-----------+ 309 . / . 310 . / . 311 . / . 312 +----------+ / . +-----------+ 313 | Client N +-/ .--| n+1 Server| 314 +----------+ +-----------+ 316 Server 1 317 ======== 318 Prefix=2001:db8:abcd:0000::/64 319 Range=2001:db8:abcd:5678:0000:/65 320 Preference=255 322 Server 2 323 ======== 324 Prefix=2001:db8:abcd:0000::/64 325 Range=2001:db8:abcd:5678:8000:/65 326 Preference=0 328 Server n+1 329 ========== 330 Prefix, range, and preference would 331 vary based on range definition 333 Split prefixes approach. 335 Figure 1 337 4.2. Multiple Unique Prefixes 339 In multiple prefix model, each DHCPv6 server is configured with a 340 unique, non-overlapping range derived from multiple unique prefixes 341 deployed for use within an IPv6 network. Distribution between two 342 servers, for example, would require that a /64 range be configured 343 from an allocated from unique /64 prefixes. For example, the range 344 2001:db8:1:0001:0000::/64 would be assigned to a single DHCPv6 server 345 for allocation to clients derived from 2001:db8:1:0001::/64 prefix, 346 subsequently the 2001:db8:1:0001:1000::/64 from the prefix 2001:db8: 348 1:0001:1000::/64 could be used by a second DHCP server. This would 349 be repeated for each active DHCP server. Example of this scenario is 350 presented in Figure 2. 352 This approach uses a unique prefix and ultimately range per DHCPv6 353 server with corresponding prefixes configured for use in the network. 354 The corresponding network infrastructure must in turn be configured 355 to use multiple prefixes on the inteface(s) facing the DHCPv6 client. 356 The configuration is similar on all the servers, but a different 357 prefix and a different preference is used per DHCPv6 server. 359 This approach would drastically increase the rate of consumption of 360 IPv6 prefixes and would also yield operational and management 361 challenges related to the underlying network since a significantly 362 higher number of prefixes would need to be configured and routed. 363 This approach also does not provide a clean migration path to the 364 desired solution leveraging a standards-based DHCPv6 redundancy or 365 failover protocol, which of course has yet to be specified. 367 The use of multiple unique prefixes provides benefits similar to 368 those referred to in Section 4.1 related to dynamic updates to DNS. 369 The use of multiple unique prefixes enables the differentiation of 370 bindings and binding timing to determine which represents the current 371 state. This becomes particularly important when DHCPv6 Leasequery 372 [RFC5007] and/or DHCPv6 Bulk Leasequery [RFC5460] are leveraged to 373 determine lease or binding state. The use of separate prefixes and 374 ranges per DHCPv6 server makes failure conditions more obvious and 375 detectable. 377 +----------+ +-----------+ 378 | Client 1 +-\ +--+ Server 1 | 379 +----------+ \ | +-----------+ 380 \ | 381 \ | 382 \ | 383 +----------+ \ | +-----------+ 384 | Client 2 +--------------+--| Server 2 | 385 +----------+ / | +-----------+ 386 . / . 387 . / . 388 . / . 389 +----------+ / . +-----------+ 390 | Client N +-/ .--| n+1 Server| 391 +----------+ +-----------+ 393 Server 1 394 ======== 395 Prefix=2001:db8:abcd:0000::/64 396 Range=2001:db8:abcd:0000::/64 397 Preference=255 399 Server 2 400 ======== 401 Prefix=2001:db8:abcd:1000::/64 402 Range=2001:db8:abcd:1000::/64 403 Preference=0 405 Server 3 406 ======== 407 Prefix=2001:db8:abcd:2000::/64 408 Range=2001:db8:abcd:2000::/64 409 Preference=(>0 and <255) 411 Multiple unique prefix approach. 413 Figure 2 415 4.3. Identical Prefixes 417 In the identical prefix model, each DHCPv6 server is configured with 418 the same overlapping prefix and range deployed for use within an IPv6 419 network. Distribution between two or more servers, for example, 420 would require that the same /64 prefix and range be configured on all 421 DHCP servers. For example, the range 2001:db8:1:0001:0000::/64 would 422 be assigned to all DHCPv6 server for allocation to clients derived 423 from 2001:db8:1:0001::/64 prefix. This would be repeated for each 424 active DHCP server. Example of such scenario is presented in 425 Figure 3. 427 This approach uses the same prefix, length, and range definition 428 across multiple DHCPv6 servers. All other configuration remaining 429 the same the only other attribute of configuration option configured 430 differently per DHCPv6 server would be DHCPv6 preference. This 431 approach conceivably eases the migration of DHCPv6 services to fully 432 support a standards based redundancy or failover protocol. Similar 433 to the split prefix architecture described above this approach does 434 not place any additional addressing requirements on network 435 infrastructure. 437 The use of identical prefixes provides no benefit or advantage 438 related to dynamic DNS updates, support of DHCPv6 Leasequery 439 [RFC5007] or DHCPv6 Bulk Leasequery [RFC5460]. In this case all DHCP 440 servers will use the same prefix and range configurations making it 441 less obvious that a failure condition or event has occurred. 443 +----------+ +-----------+ 444 | Client 1 +-\ +--+ Server 1 | 445 +----------+ \ | +-----------+ 446 \ | 447 \ | 448 \ | 449 +----------+ \ | +-----------+ 450 | Client 2 +--------------+--| Server 2 | 451 +----------+ / | +-----------+ 452 . / . 453 . / . 454 . / . 455 +----------+ / . +-----------+ 456 | Client N +-/ .--| n+1 Server| 457 +----------+ +-----------+ 459 Server 1 460 ======== 461 Prefix=2001:db8:abcd:0000::/64 462 Range=2001:db8:abcd:0000::/64 463 Preference=255 465 Server 2 466 ======== 467 Prefix=2001:db8:abcd:0000::/64 468 Range=2001:db8:abcd:0000::/64 469 Preference=0 471 Server 3 472 ======== 473 Prefix=2001:db8:abcd:0000::/64 474 Range=2001:db8:abcd:0000::/64 475 Preference=(>0 and <255) 477 Identical prefix approach. 479 Figure 3 481 5. Challenges and Issues 483 The lack of interaction between DHCPv6 servers introduces a number of 484 challenges related to the operations of the same in a production 485 environment. The following areas of are particular concern. 487 o Interactions with DNS server(s) to support the dynamic update of 488 the same adress and prefix when one or more DHCPv6 servers have 489 become unavailable. This specifically becomes a challenge when or 490 if nodes that were initially granted a lease: 492 1. Attempt to renew or rebind the lease originally granted, or 494 2. Attempt to obtain a new lease 496 In either of the cases cited above, safeguards leveraged to 497 prevent the deliberate or inadvertent overwriting of DNS data will 498 likely prevent the responding DHCPv6 server from properly updating 499 DNS with the client's new information and or may result in stale 500 data in DNS. Possible solutions include the following: 502 * The ability to configure the override and or disabling of the 503 safeguards that prevent the over-writing of DNS data care of 504 RFC2136, specifically, related to [RFC4701] and [RFC4703]. 505 This behavior must specifically be supported by the DHCPv6 506 server. This will allow for the overwriting of existing RRs in 507 DNS that represent the former binding for the client. As a 508 result clients will not have multiple RRs in DNS for a client's 509 FQDN-to-IPv6 address mapping. Conversely, RR's for a client's 510 IPv6 address-to-FQDN mapping will not be actively overwritten 511 or deleted. Stale reverse zone data will be purged using well 512 known DNS constructs, including but not limited to leveraging 513 TTLs. Access control on the DNS server must be leveraged to 514 restrict which DHCP servers may update DNS. 516 o Interactions with DHCPv6 servers to facilitate the acquisition of 517 IPv6 lease data care of the DHCPv6 Leasequery [RFC5007] or DHCPv6 518 Bulk Leasequery [RFC5460] protocols when one or more DHCPv6 519 servers have become unavailable and have granted leases to DHCPv6 520 clients. If IPv6 lease data is required and the granting server 521 is unavailable it will not be possible to obtain any information 522 about leases granted until one of the following has taken place. 523 It is important to note that with DHCPv6 until such time that a 524 redundancy or failover protocol is available binding updates and 525 synchronization will not occur between DHCPv6 servers. 527 1. The granting DHCPv6 server becomes available with all lease 528 information restored 530 2. The client has renewed or rebound its lease against a 531 different DHCPv6 server 533 6. IANA Considerations 535 IANA is not requested to assign any numbers at this time. 537 7. Security Considerations 539 Security considerations specific to the operation of the DHCPv6 540 protocol are created through the use of this interim architecture for 541 DHCPv6 redundancy beyond what has been cited for Dynamic Host 542 Configuration Protocol for IPv6 (DHCPv6) [RFC3315]. There are 543 considerations related to DNS, specifically the dynamic updating of 544 DNS, when such models are employed. Potential opportunities are 545 created to overwrite valid DNS resource records when provisions have 546 been made accommodate some of the models cited in this document. In 547 some cases this is desirable to ensure that DNS remains up to date 548 when using one or more of these models, however, abuse of the same 549 could result in undesirable behavior. 551 8. Acknowledgements 553 Many thanks to Bernie Volz, Kim Kinnear, and Ralph Droms for their 554 input and review. 556 9. Normative References 558 [I-D.ietf-dhc-dhcpv6-opt-netboot] 559 Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 560 option for network boot", 561 draft-ietf-dhc-dhcpv6-opt-netboot-09 (work in progress), 562 June 2010. 564 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 565 and M. Carney, "Dynamic Host Configuration Protocol for 566 IPv6 (DHCPv6)", RFC 3315, July 2003. 568 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 569 Host Configuration Protocol (DHCP) version 6", RFC 3633, 570 December 2003. 572 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 573 (DHCP) Service for IPv6", RFC 3736, April 2004. 575 [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource 576 Record (RR) for Encoding Dynamic Host Configuration 577 Protocol (DHCP) Information (DHCID RR)", RFC 4701, 578 October 2006. 580 [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified 581 Domain Name (FQDN) Conflicts among Dynamic Host 582 Configuration Protocol (DHCP) Clients", RFC 4703, 583 October 2006. 585 [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, 586 "DHCPv6 Leasequery", RFC 5007, September 2007. 588 [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, 589 February 2009. 591 Authors' Addresses 593 John Jason Brzozowski 594 Comcast Cable Communications 595 1306 Goshen Parkway 596 West Chester, PA 19380 597 USA 599 Phone: +1-609-377-6594 600 Email: john_brzozowski@cable.comcast.com 602 Jean-Francois Tremblay 603 Videotron Ltd. 604 612 Saint-Jacques 605 Montreal, Quebec H3C 4M8i 606 Canada 608 Email: Jean-Francois.TremblayING@videotron.com 610 Jack Chen 611 Time Warner Cable 612 13820 Sunrise Valley Drive 613 Herndon, VA 20171 614 USA 616 Email: jack.chen@twcable.com 618 Tomasz Mrugalski 619 Gdansk University of Technology 620 Storczykowa 22B/12 621 Gdansk, 80-177 622 Poland 624 Phone: +48 698 088 272 625 Email: tomasz.mrugalski@eti.pg.gda.pl