RFC 7031

DHCPv6 Failover Requirements

📅 published September 2013, from ietf

RFC 7031: DHCPv6 Failover Requirements 🎀

  • Title: DHCPv6 Failover Requirements (RFC 7031) 💅
  • Authors: T. Mrugalski (ISC) and K. Kinnear (Cisco) 🧚
  • Category: Informational 🌸
  • Date: September 2013 📅
  • ISSN: 2070-1721
  • Published by: the Internet Engineering Task Force (IETF) ✨
  • Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates 🦋

Abstract ✨

okay so DHCPv6 (from RFC 3315) lets multiple servers run on the same network, which is iconic, but it never says how they'd share info about which clients are active and what leases they hold 🫠. Some sites want several servers so that if one goes down, another can step in and keep things running 🔥. For that to actually be reliable, the primary and secondary servers have to keep a consistent database of lease info 💖. RFC 3315 allows for redundancy and failover, but doesn't define any of it 😭.

This document lays out the requirements for DHCPv6 failover, lists the related problems, and talks about what work is planned in scope 🎀. It does not define a DHCPv6 failover protocol, so don't go looking for one here 🙈.

Status of This Memo 🌈

This is not an Internet Standards Track specification. It's published for informational purposes only 💜.

This document is a product of the IETF, and it reflects the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious about that 🧐.

For the current status, any errata, and how to send feedback, go to:

http://www.rfc-editor.org/info/rfc7031

Copyright (c) 2013 IETF Trust and the people listed as the document's authors. All rights reserved 💅.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document 📜. Code components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🍓.

Table of Contents 📖

1. Introduction ....................................................3
2. Definitions .....................................................3
3. Scope of Work ...................................................5
   3.1. Alternatives to Failover ...................................5
        3.1.1. Short-Lived Addresses ...............................5
        3.1.2. Redundant Servers ...................................6
        3.1.3. Distributed Databases ...............................6
        3.1.4. Load Balancing ......................................7
4. Failover Scenarios ..............................................7
   4.1. Hot Standby Model ..........................................7
   4.2. Geographically Distributed Failover ........................7
   4.3. Load Balancing .............................................8
   4.4. 1-to-1, m-to-1, and m-to-n Models ..........................8
   4.5. Split Prefixes .............................................8
   4.6. Long-Lived Connections .....................................8
   4.7. Partial Server Communication Loss ..........................9
5. Principles of DHCPv6 Failover ...................................9
   5.1. Failure Modes ..............................................9
        5.1.1. Server Failure .....................................10
        5.1.2. Network Partition ..................................10
   5.2. Synchronization Mechanisms ................................11
        5.2.1. Lockstep ...........................................11
        5.2.2. Lazy Updates .......................................12
6. DHCPv4 and DHCPv6 Failover Comparison ..........................12
7. DHCPv6 Failover Requirements ...................................13
   7.1. Features out of Scope .....................................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. References ....................................................16
   10.1. Normative References .....................................16
   10.2. Informative References ...................................16

1. Introduction ✨

okay so the DHCPv6 protocol, defined in [RFC3315], lets multiple servers run on a single network 🌸. The problem is that it doesn't explain how those servers can share the same address and prefix delegation pools, or how a client can smoothly extend its existing leases when the original server is down 😩. [RFC3315] gives room for these capabilities but doesn't document how the servers should cooperate and communicate to make them happen 💅. Lots of sites want several servers so they have redundancy when one fails, and for that to be reliable, the primary and secondary servers must keep a consistent database of lease information 🔥.

This document goes over failover implementation scenarios, failure modes, and synchronization approaches, so you have the background for the list of requirements a DHCPv6 failover protocol needs 🧚. It then sets out a minimum set of requirements that failover must provide to be useful, while leaving room for extra features to be specified as extensions 💖. Again, this document does not define a DHCPv6 failover protocol 🙈.

The failover model these requirements apply to will start as a pairwise "hot standby" model (see Section 4.1). In that setup, a primary server handles normal operation and switches over to a backup secondary server when something fails 🦋. A secondary server may optionally provide failover service for multiple primary servers 🍓. The requirements won't block a future load-balancing extension with a symmetric failover relationship, though ⭐.

The DHCPv6 failover concept borrows heavily from its DHCPv4 counterpart [DHCPV4-FAILOVER]. That one never finished the standardization process, but it has several successful, operationally proven vendor-specific implementations 👑. For the commonalities and differences, see Section 6 💜.

2. Definitions 📖

This section defines the terms that matter for DHCPv6 failover 🎀.

Definitions from [RFC3315] are included by reference 🫶. In particular, "client" means any device (for example, an end-user host, CPE (Customer Premises Equipment), or other router) that implements the client functionality of the DHCPv6 protocol 💅. A "server" is a DHCPv6 server, unless it's explicitly noted otherwise 🧚. A "relay" is a DHCPv6 relay 🌈.

  • Binding (or client binding): a group of server data records holding the info the server has about the addresses in an IA (Identity Association, see Section 10 of [RFC3315]), or about configuration info explicitly assigned to the client. Config info handed to a client through a policy (like the info given to every client on the same link) doesn't need a binding 🦋.
  • DNS Update: the ability to update a DNS server's name database using the on-the-wire protocol defined in [RFC2136]. Clients and servers can negotiate the scope of those updates, as defined in [RFC4704] 🍓.
  • Failover: one partner's ability to keep offering services that another partner was providing, with minimal or no impact on clients 🔥.
  • FQDN: a fully qualified domain name. A FQDN is generally a host name with at least one domain label under the top-level domain. For example, "dhcp.example.org" is a fully qualified domain name 💖.
  • High Availability: a desired property of DHCPv6 servers, meaning they keep providing services even after unwanted events like server crashes, link failures, or network partitions 😭.
  • Load Balancing: the ability of two or more servers to each process some portion of the client request traffic in a conflict-free way 🌸.
  • Lease: an IPv6 address, an IPv6 prefix, or some other resource that a server assigned ("leased") to a specific client. A lease may include extra info, like an associated fully qualified domain name (FQDN) and/or info about associated DNS updates. A client gets a lease for a specified period of time (the valid lifetime) ⭐.
  • Partner: for the purposes of this document, a "partner" is a failover server, usually the other failover server in a failover relationship 🧚.
  • Stable Storage: each DHCP server is required to keep its lease database in some form of storage (known as "stable storage") that stays consistent through reboots, crashes, and power failures 🫶.
  • Partner Failure: a power outage, unexpected shutdown, crash, or other type of failure that leaves a partner unable to keep operating 💀.

3. Scope of Work 🦋

To fit into the IETF process effectively and efficiently, the standardization effort for DHCPv6 failover is expected to happen in a series of documents, each one more specific than the last 🎀.

  • Requirements document: this document, which specifies the requirements for DHCPv6 failover 📜.
  • Design document: a later document is expected to cover the design of the DHCPv6 failover protocol 🧠.
  • Protocol document: if there's enough interest, a later document is expected to cover the protocol details needed to implement the DHCPv6 failover protocol itself 🔥.

The point of splitting it up like this is, in part, to make the DHCPv6 failover protocol easier to validate, review, and approve, by presenting it in bite-sized pieces to the wider community 💅.

Additional documents describing extensions may also be defined 🌈.

DHCPv6 failover requirements are presented in Section 7 ✨.

3.1. Alternatives to Failover 💜

There are lots of scenarios where a failover capability would be useful. But honestly, there are often much simpler approaches that meet the required goals 🙈. This section documents examples where failover isn't really needed 💖.

3.1.1. Short-Lived Addresses ✨

Okay so there are times when IPv6 addresses only stick around for a hot minute, but you still need to be super sure they'll get served 🥺. The big example is PXE (Preboot eXecution Environment) [RFC5970]. It's how a device grabs its config super early when it's booting up over the network 🖥️.

The PXE BIOS grabs an address so it can load the OS image and keep booting 🚀. That address and any other config params get used during boot and then tossed. So if there's no DHCPv6 service around at that moment, the device just can't boot. Literally stuck 💀.

Here's the thing: instead of setting up failover, it's way better to use the much simpler preference mechanism from [RFC3315] 💅. Picture two or more servers with different preference values, like 10 and 20. Both of them answer the client's request, and the client should go with the one that has the bigger preference value 👑. If the most preferred server goes down, the next one keeps answering the clients' queries 🫶. It's super easy to set up, but there's no lease stability. If a server fails, the clients' addresses and prefixes are gonna change 🦋.

3.1.2. Redundant Servers 🎀

Sometimes people want failover because they need high availability, which just means still providing services even when a server dies 💪. If you don't have any extra requirements, you can usually hit that goal by running two or more independent servers on the same link 🌸.

There are a bunch of well-documented approaches that show how this kind of setup works. They're covered in detail in [RFC6853] 📚. Each one is way easier to deploy and maintain than full failover, so honestly, iconic behavior 💖.

3.1.3. Distributed Databases 🗄️

Some servers let you store their lease database in external databases 🧠. Another alternative to failover is to set up two servers so they both connect to the same distributed database 🤝.

Okay but you really need to understand how inconsistencies get resolved in those database backends, and how those conflict resolutions affect DHCPv6 server operation 🤔.

It's also essential to only use a database that gives you equivalent reliability and failover capability 🔒. Otherwise, you've just moved the single point of failure somewhere else (into the database instead of the DHCPv6 server) 😬. That setup doesn't actually improve redundancy, it just makes deployment way more complicated 🙃.

Here's a big misconception: people assume that conflict resolution after recovering from a network partition isn't necessary. Not me... 🙈 Let's walk through an example with a very small pool that only has one address. There are two servers, and each one is connected to a co-located database node (aka running on the same hardware). Then a network partition happens. Each server is still operating, but it's lost its connection to its partner. Two clients request an address, one from each server. Each server checks its database and sees that only one address is free, so it hands that address to the client. Unfortunately, each server gave the same address to a different client 😭. Making it more realistic (millions of addresses instead of one) just lowered the chance of this failing, but it didn't get rid of the underlying issue 💔.

Any solution that involves a distributed database implementation of DHCPv6 failover has to take the security requirements into account. See Section 8 for more info 🔐.

3.1.4. Load Balancing ⚖️

Sometimes the reason you want more than one server is that you assume they'll share the client traffic 🍓. Admins who want that kind of capability are advised to deploy a load-balancing mechanism, which is defined in [LOAD-BALANCING] 💜.

4. Failover Scenarios 🧚

The following sections walk through a few deployment scenarios and use cases that might be linked to things people commonly call "failover" 👀. These scenarios may or may not be in scope for the DHCPv6 failover protocol that this document's requirements apply to. They're listed here so everyone has a common starting point for the discussion ✨.

4.1. Hot Standby Model 🔥

The simplest case is two partners connected to the same network 🌐. Only one of the partners ("primary") provides services to clients. If it fails, the second partner ("secondary") keeps handling the services the first partner used to handle 🫡. Since both servers are on the same network, a partner that can't talk to its partner, while still getting requests from clients, can assume with high probability that its partner is down and the network is working fine 🧐. That assumption may affect how it operates 💅.

4.2. Geographically Distributed Failover 🌍

Servers can be physically located in separate places 🗺️. A common example is a service provider that has at least a regional high-performance network between geographically distributed data centers 🏢. In that setup, one server lives in one data center, and its failover partner lives in another, far-away data center ✈️. Here, when one partner finds it can't communicate with the other, that doesn't necessarily mean the other partner is down 🤷‍♀️.

4.3. Load Balancing ⚖️

Wanting more than one server on a network can also come from wanting incoming traffic to be handled by several servers 📦. That means each server carries less load when all of them are up and running 💪. Although this capability doesn't, strictly speaking, require failover, failover definitely makes that kind of architecture more straightforward 🫶.

Also, in a load-balancing situation that includes failover, each individual server has to be able to handle the full load that both servers normally handle together. Otherwise, there isn't a true increase in availability 😤.

4.4. 1-to-1, m-to-1, and m-to-n Models 🧩

A failover relationship for a specific network is set up with two failover partners 👯. Those partners talk to each other and back up all pools. This is sometimes called the 1-to-1 model, and it's considered relatively simple 🍼. In bigger networks, one server might be part of several failover relationships, meaning it provides failover for several address or prefix pools, each served by separate partners 🌈. That scenario can be called m-to-1 🫠. The most complex one, m-to-n, assumes that each partner takes part in multiple failover relationships 🤯.

4.5. Split Prefixes 🍰

Because the IPv6 address space is so massive, you can provide semi-redundant service by splitting the available pool of addressees into two or more non-overlapping pools, with each server handling its own smaller pool 🎂. Several versions of this scenario are discussed in [RFC6853] 📖.

4.6. Long-Lived Connections 🔗

Certain nodes may keep long-lived connections going 💫. Since the IPv6 address space is large, there are techniques (like the ones in [RFC6853]) that use the easy availability of IPv6 addresses to give you increased DHCPv6 availability 🙌. But these approaches don't generally give you stable IPv6 addresses for DHCPv6 clients if the server they're talking to becomes unavailable 😬.

The obvious benefit of stable addresses is that you can update DNS infrequently 📝. DNS can be updated every time an IPv6 address changes, but that introduces delays, and (depending on the DNS configuration) old entries might get cached for prolonged periods of time 🕰️.

The other perk of having a stable address is that lots of monitoring solutions give you stats on a per-IP basis. So when IPs keep changing, measuring the characteristics of a given box gets harder 📉.

4.7. Partial Server Communication Loss 📡

There's a scenario where the DHCPv6 server is configured to serve clients on one network adapter, and talk to a partner server (server-to-server traffic) on a different network adapter 🔌. In this case, if the server loses connectivity on the adapter it uses to talk to clients because of an adapter (hardware) failure, there's no signal sent to the partner about the loss of service in the DHCPv6 failover protocol 🫥. Since the servers can still talk to each other, the partner stays totally unaware that clients are losing service 😶.

5. Principles of DHCPv6 Failover 🧠

This section covers important issues that will affect any DHCPv6 failover protocol 📌. It's not meant to define implementation details, it's about high-level concepts and issues that matter for DHCPv6 failover 🎯. These issues form the basis for later documents that will deal with solutions to them 🧱.

The general failover concept assumes there are backup servers that can provide service if a primary server fails 🛟. In theory, there could be more than one backup server that could take on the role if needed 🤔. However, having more than two servers introduces a really hard problem: synchronizing between partners 😵‍💫. With just a pair of cooperating servers, the notification and processes can only end up in one of two states: fully successful (got a response from a partner) or total failure (no response, failure event occurred) ✅❌. If more than two partners were in a relationship, there would be intermediate, inconsistent states where some partners had updated their state and some hadn't 🌀. That would seriously complicate the protocol design and give very little advantage in return 🙅‍♀️. So, an approach assuming a pair of cooperating servers was chosen 👯‍♀️.

5.1. Failure Modes 💥

This section documents failure modes 📝. This requirements document doesn't make any claims about whether those two failures are distinguishable by a server 🤐.

5.1.1. Server Failure 🖥️💀

Servers can become unresponsive because of a software crash, a hardware failure, a power outage, or any number of other reasons 🔋. The failover partner will detect this kind of event because it stops getting responses from the down partner 📵. In this failure mode, the assumption is that the server is the only equipment that's offline, and all other network equipment is operating normally 🟢. Especially, communication between other nodes isn't interrupted 💬.

When you're working under the assumption that this is the only type of failure that can happen, the server can safely assume that its partner being unreachable means the partner is down. That means other nodes (clients, in particular) can't reach it either, and no services are being provided 🫥.

It should be noted that recovery after the failed server is brought back online is super straightforward 🙌. It just needs to download current information from the lease database of the healthy partner, and there's no conflict resolution required ✨.

This is by far the most common failure mode between two failover partners 🏆.

When the two servers are physically close to each other, possibly in the same room, the probability that a failure to communicate between failover partners is due to server failure goes up 🚨.

5.1.2. Network Partition 🦋

Okay so another way a partner can become unreachable is if the network connecting the two servers breaks 💀. This can happen when any kind of network gear fails: a router, a switch, physical cables, or optic fibers. When that happens, the network splits into two or more disjoint sections (called partitions) that can't talk to each other. That's a "network partition" 🧩. If failover partners end up in different partitions, they won't be able to communicate with each other. BUT each partner might still be able to serve the clients that happen to be in the same partition, so it's not all doom 🌸.

Now, if you're taking this failure mode seriously (and you should 💅), a server can't assume that partner unreachability automatically means its partner is down. Nope. The partner may keep running and keep serving a subset of the clients. The only assumption that's actually valid is that the partner also detected the network partition and is following the procedures written for that exact situation 🫶.

Also, recovering after a partitioned network is rejoined is way more complicated than recovering from a server failure 😭. Both servers may have kept serving clients, so they now have two separate lease databases. They need to agree on the state of each lease (or follow some other algorithm to bring their lease databases back into agreement). It's messy, but it makes sense once you see it 🍓.

This failure mode is more likely (still rare though 🙈) when the two servers are physically far apart with multiple network elements between them. That's exactly the case in geographically distributed failover (see Section 4.2).

5.2. Synchronization Mechanisms 🔥

Partners must exchange information about changes made to the lease database. There are at least two types of synchronization methods that may be used (see Sections 5.2.1 and 5.2.2). These concepts are related to distributed databases, so a bit of familiarity with distributed database tech helps you understand this topic better 🧠.

5.2.1. Lockstep ✨

When a server gets a REQUEST message from a client, it checks its lease database and assigns the requested addresses and/or prefixes. To make sure its partner keeps a consistent database, it then sends info about a new or just-updated lease to the partner and waits for the partner's response. Once that response comes back, the REPLY message gets sent to the client.

This approach has the benefit of a completely consistent lease database between partners at all times 👑. The catch is there's typically a significant performance penalty, because each response to a client is delayed by the total sum of the delays from two transmissions between partners plus the processing by the second partner. That second partner is expected to update its own copy of the lease database in permanent storage, so this delay isn't negligible, even on fast networks 😩.

Thanks to fast SSD (solid state disk) and battery-backed RAM (random access memory) disk tech, this write performance penalty can be limited to some degree ⚡.

5.2.2. Lazy Updates 💤

Another approach is to send the REPLY message to the client before finishing the update to the partner. The server sends the REPLY right after assigning the addresses and/or prefixes, then starts the partner update at a later time, depending on the algorithm chosen. Another variation is to start transmitting to the partner but not wait for its response before sending the REPLY to the client.

This approach barely affects server response times, so it's way better from a performance perspective 🚀. However, it makes the lease databases only loosely synchronized between partners. That makes synchronization more complex (especially the re-integration after a network partition event), because there may be cases where one client has been given a lease on an address or prefix that the partner doesn't know about. For example, that happens if the server crashes after sending the REPLY to the client but before sending update information to its partner 😵.

6. DHCPv4 and DHCPv6 Failover Comparison 🎀

There are significant similarities between existing DHCPv4 failover and the envisaged DHCPv6 failover, bestie 👯. Both serve IP addresses to clients, both need to maintain consistent databases among partners, both need to perform consistent DNS updates, both must be able to take over bindings offered by a failed partner, and both must be able to resume operation after the partner is recovered. DNS conflict resolution works on the same principles in both DHCPv4 and DHCPv6.

Nevertheless, there are big differences 👀. IPv6 introduced prefix delegation [RFC3633], which is a crucial element of the DHCPv6 protocol. IPv6 also introduced deprecated addresses with separate preferred and valid lifetimes, both configured via DHCPv6. The negative response (NACK) from DHCPv4 got replaced by the ability in DHCPv6 to send a corrected response in a REPLY message, which is different from a REQUEST.

The typical huge address space also changes the game 🌌. There are close to 2^64 addresses on the /64 prefixes expected to be available on most networks, so managing address assignment can be very different from DHCPv4 failover. In DHCPv4, it wasn't possible to use a hash or calculated technique to divide the much smaller address space. That means a lot of the protocol that deals with pool balancing and rebalancing might not be necessary and can be done mathematically 🧮. Also, because there's a much lower degree of contention for IP addresses, the DHCPv6 failover protocol doesn't need to be tuned for rapid reclamation of IPv6 addresses after the loss of a failover peer's database.

However, DHCPv6 prefix delegation is similar to IPv4 addressing in terms of the number of available leases. So techniques for pool balancing and rebalancing, plus faster reclamation of prefixes allocated by a failed peer, will be needed 🫠.

7. DHCPv6 Failover Requirements 🌈

This section summarizes the requirements for DHCPv6 failover 📋.

Certain capabilities may be useful in some scenarios but not all of them. Those extra features will be considered optional parts of failover and will be defined in separate documents. So this document can be considered an attempt to define requirements for the DHCPv6 failover "core" protocol 💖.

The core of the DHCPv6 failover protocol is expected to provide the following properties:

  1. The number of supported partners must be exactly two, i.e., there are at most two servers that are aware of a specific lease.
  2. For each prefix or address pool, a server must not participate in more than one failover relationship.
  3. The defined protocol must support the m-to-1 model (i.e., one server may form more than one relationship), but an implementation may choose to implement only the 1-to-1 model (i.e., everything from one server is backed on another).
  4. One partner must be able to continue serving leases offered by the other partner. This property is also sometimes called "lease stability". The failure of either failover partner should have minimal or no impact on client connectivity. In particular, it must not force the client to change addresses and/or change prefixes delegated to it. Lease stability aims to avoid disturbing long-lived connections 🦋.
  5. Prefix delegation must be supported.
  6. Use of the failover protocol must not introduce significant performance impact on server response times. Therefore, synchronization between partners must be done using some form of lazy updates (see Section 5.2.2) ⚡.
  7. The pair of failover servers must be able to recover from a server down failure (see Section 5.1.1).
  8. The pair of failover servers must be able to recover from a network partition event (see Section 5.1.2).
  9. The design must allow secure communication between the failover partners 🔐.
  10. The definition of extensions to this core protocol should be allowed, when possible.

Depending on the specific nature of the failure, the recovery procedures mentioned in points 7 and 8 may require manual intervention 🛠️.

High availability is a property of the protocol that lets clients keep receiving DHCPv6 services even when individual DHCPv6 servers fail 🙌. In particular, the server that takes over service from its failed partner will keep serving the same addresses and/or prefixes. This property is also called "lease stability".

Progress on a standardized, interoperable DHCPv4 failover protocol has stalled, but vendor-specific DHCPv4 failover protocols have been deployed that meet these requirements to a large extent 🥲. So it would be appropriate to take into account the likely coexistence of DHCPv4 and DHCPv6 failover solutions. In particular, features that are common to both IPv4 and IPv6 implementations, such as the DNS Update mechanism, should be taken into consideration to ensure compatible operation 🍭.

7.1. Features out of Scope 🙅

The following features are explicitly out of scope 🚫.

  1. Load Balancing: This capability is considered an extension and may be defined in a separate document. It must not be part of the core protocol but rather defined as an extension. The primary reason is the desire to limit the complexity of the core protocol. See [LOAD-BALANCING].
  2. Configuration synchronization: Two failover partners are expected to maintain the same configuration. Mismatched configuration between partners is a frequent problem in failover solutions. Unfortunately, that's an open-ended problem, since different servers have very different configuration data models 😤.
  3. m-to-n model (see Section 4.4).
  4. Servers participating in multiple failover relationships for any given prefix or address pool.

8. Security Considerations 🔐

Security is serious business, bestie, so pay attention here 👀.

The design must provide a mechanism whereby each peer in a failover relationship can identify the other peer, authenticate that identification, and validate that the identified peer is the one with which communication is intended. This mechanism should also optionally provide support for confidentiality.

The protocol specification, when it is written, should provide operational guidelines for authentication mechanisms that require access to network servers that could be unreachable. For example: what to do if a partner is reachable but the remote Certificate Authority is unreachable due to a network partition event 🚨.

The security considerations for the design itself will be discussed in the design document 📝.

9. Acknowledgements 💖

okay so this doc leaned SUPER hard on [DHCPV4-FAILOVER] 🙌 its concepts, definitions and other bits are everywhere in here, so huge thanks to Bernie Volz and Shawn Routhier 🫶 for reviewing it again and again and making substantial contributions. ✨

The authors also thanked Qin Wu, Jean-Francois Tremblay, Frank Sweetser, Jiang Sheng, Yu Fu, Greg Rabil, Vithalprasad Gaitonde, Krzysztof Nowicki, Steinar Haug, Elwyn Davies, Ted Lemon, Benoit Claise, Stephen Farrell, Michal Hoeft, and Krzysztof Gierlowski for their comments and feedback. that's a whole squad 🧚🌈

this work was partially supported by the Department of Computer Communications (a division of Gdansk University of Technology) and the National Centre for Research and Development (Poland) under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045 / 09-00 (Future Internet Engineering Project). funding really said "let's make the internet better" and i respect it 🇵🇱🎀

10. References 📚

10.1. Normative References

These are the must-read ones, the stuff the spec is built on 👑

  • [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. the OG DHCPv6 spec 💜
  • [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. prefix delegation, iconic 🌸
  • [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006. the client FQDN option, very cute 🦋

10.2. Informative References

These are the extra reading that's super useful but not load-bearing 🧚

  • [DHCPV4-FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover Protocol", Work in Progress, March 2003. the DHCPv4 failover draft that this whole doc is basically modeled on 🙈
  • [LOAD-BALANCING] Kostur, A., "DHC Load Balancing Algorithm for DHCPv6", Work in Progress, December 2012. load balancing vibes 🍓
  • [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. DNS updates, the classic 🌈
  • [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010. network boot options 💅
  • [RFC6853] Brzozowski, J., Tremblay, J., Chen, J., and T. Mrugalski, "DHCPv6 Redundancy Deployment Considerations", BCP 180, RFC 6853, February 2013. this one is literally about redundancy so it's basically the sequel energy ⭐

Authors' Addresses 🦋

meet the people behind it 💖

Tomek Mrugalski
Internet Systems Consortium, Inc.
950 Charter Street
Redwood City, CA  94063
USA

Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com


Kim Kinnear
Cisco Systems, Inc.
1414 Massachusetts Ave.
Boxborough, Massachusetts  01719
USA

Phone: +1 (978) 936-0000
EMail: kkinnear@cisco.com
📦 where this page comes from