RFC 7550

Issues and Recommendations with Multiple Stateful DHCPv6 Options

📅 published May 2015, from ietf

Issues and Recommendations with Multiple Stateful DHCPv6 Options 🎀

okay bestie, this is RFC 7550, and it's giving Standards Track 💅 (that means it's an official Internet standard, not just a suggestion). It came out in May 2015 from the IETF 🌸. The authors are O. Troan and B. Volz from Cisco Systems, Inc., plus M. Siodelski from ISC 🧚. It's listed as ISSN: 2070-1721 and it Updates RFC 3315 and RFC 3633, so it's basically here to patch up two older DHCPv6 specs 🫶.

Abstract ✨

okay so the DHCPv6 spec (that's RFC 3315, btw) only had two stateful options, IA_NA and IA_TA, and honestly it never planned for more to show up 😭. Then DHCPv6 Prefix Delegation added IA_PD, which is also stateful. Now people are using IA_NA and IA_PD together and things are getting messy 💀. This doc updates RFCs 3315 and 3633 to fix that mess 🔥.

Status of This Memo ✨

this one is an Internet Standards Track document 🎀.

it's a product of the Internet Engineering Task Force (IETF) and represents what the IETF community agreed on. it got public review and was approved by the Internet Engineering Steering Group (IESG) 👑. if you want more about Internet Standards, check out Section 2 of RFC 5741 🧚.

for the current status, any errata, or how to send feedback, go to http://www.rfc-editor.org/info/rfc7550 💜.

Copyright Notice 🌈

the copyright belongs to the IETF Trust and the document authors, and it's all reserved, okay 📜. this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date. please actually read those, they're your rights and restrictions lol 🙈.

if you pull Code Components out of this doc, they 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, same as the license says 🫶.

this doc might contain stuff from IETF Documents or Contributions published before November 10, 2008. some of the people who own the copyright on that older material may not have given the IETF Trust permission to let it get modified outside the IETF Standards Process. so without a proper license from those folks, this doc can't be modified outside the IETF Standards Process, and you can't make derivative works outside it either. the one exceptions are formatting it for publication as an RFC or translating it into languages other than English 💅.

Table of Contents 🌸

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   4
3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
4.  Handling of Multiple IA Option Types  . . . . . . . . . . . .   4
  4.1.  Placement of Status Codes in an Advertise Message . . . .   6
  4.2.  Advertise Message Processing by a Client  . . . . . . . .   8
  4.3.  T1/T2 Timers  . . . . . . . . . . . . . . . . . . . . . .   9
  4.4.  Renew and Rebind Messages . . . . . . . . . . . . . . . .  10
    4.4.1.  Renew Message . . . . . . . . . . . . . . . . . . . .  10
    4.4.2.  Rebind Message  . . . . . . . . . . . . . . . . . . .  11
    4.4.3.  Updates to Section 18.1.3 of RFC 3315 . . . . . . . .  11
    4.4.4.  Updates to Section 18.1.4 of RFC 3315 . . . . . . . .  13
    4.4.5.  Updates to Section 18.1.8 of RFC 3315 . . . . . . . .  14
    4.4.6.  Updates to Section 18.2.3 of RFC 3315 . . . . . . . .  16
    4.4.7.  Updates to Section 18.2.4 of RFC 3315 . . . . . . . .  18
    4.4.8.  Updates to RFC 3633 . . . . . . . . . . . . . . . . .  20
  4.5.  Confirm Message . . . . . . . . . . . . . . . . . . . . .  21
  4.6.  Decline Should Not Necessarily Trigger a Release  . . . .  22
  4.7.  Multiple Provisioning Domains . . . . . . . . . . . . . .  22
5.  Security Considerations . . . . . . . . . . . . . . . . . . .  22
6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  22
  6.1.  Normative References  . . . . . . . . . . . . . . . . . .  22
  6.2.  Informative References  . . . . . . . . . . . . . . . . .  23
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  24
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  24

1. Introduction ✨

so DHCPv6 ([RFC3315]) was written without anyone expecting more stateful DHCPv6 options to show up 🙈. then DHCPv6 Prefix Delegation ([RFC3633]) added a new stateful option for Prefix Delegation. the Customer Edge (CE) router model in [RFC7084] has shown that DHCPv6 has trouble supporting multiple stateful option types at once, especially IA_NA (non-temporary addresses) and IA_PD (delegated prefixes) 💖.

this document goes over a bunch of problems with IA_NA and IA_PD coexisting and then spells out changes to the DHCPv6 protocol to fix them 🔥.

the goal is to clarify the DHCPv6 spec and, where needed, change it so IA_NA and IA_PD option types can live together in a single DHCPv6 session 🦋.

also, IA_TA (temporary addresses) options can ride along with other IA option type requests, but they usually don't get renewed (there are no T1/T2 times) and they have their own life cycle separate from IA_NA and IA_PD. so the IA_TA option type is mostly out of scope here 💅.

the changes in this doc are meant to be folded into a new revision of the DHCPv6 protocol spec [DHCPv6] 🎀.

2. Conventions 🌷

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 📖.

3. Terminology 💜

on top of the terms defined in [RFC3315], [RFC3633], and [RFC7227], this doc also uses the following terms:

Identity Association (IA): throughout this doc, "IA" means the Identity Association that holds the addresses or prefixes given to a client, carried in the IA_NA or IA_PD options respectively 🧚.
IA option types: a general way of saying an IA_NA and/or IA_PD option 🌈.
Stateful options: options that need a dynamic binding state per client on the server 🔥.
Top-level options: DHCPv6 options that aren't wrapped inside other options, except the Relay Message option. options wrapped only by Relay Message options (and nothing else) still count as top-level, whether they show up in a relay agent message or a server message. see [RFC7227] 👑.

4. Handling of Multiple IA Option Types 🦋

okay so the DHCPv6 spec ([RFC3315]) assumed the only stateful options were for handing out addresses 😭. DHCPv6 Prefix Delegation ([RFC3633]) explains how to extend DHCPv6 for prefix delegation, but it doesn't clearly say how address assignment and prefix delegation are supposed to coexist 💀.

if a client asks for multiple IA option types but the server is only set up to give some of them, the client could react in a few different ways 🌸:

reset the state machine and keep sending Solicit messages,
make separate DHCP sessions for each IA option type and keep Soliciting for the unfulfilled IA options, or
keep using the single session and include the unfulfilled IA options in later messages to the server.

resetting the state machine and endlessly sending Solicit messages might mean the client never finishes DHCP, and it's generally not considered a good move 🙈. it can also cause a packet storm if the client doesn't rate limit its Solicit messages properly or if there are tons of clients on the network 😭. client implementors who go this route SHOULD implement the updates to RFC 3315 specified in [RFC7083] 🫶.

making a separate DHCP session (its own instance of the client state machine) for each IA option type is conceptually simple, but it causes a bunch of issues: clients need extra resources to create and keep up multiple state machine instances, there's more DHCP traffic, other configuration options get duplicated unnecessarily and might conflict, and each IA option type spec ends up with its own "version" of the DHCP protocol, which is a divergence waiting to happen 💅.

the single session and state machine lets the client use the best configuration it can get from one DHCP server during the configuration exchange. but the server might not be set up to deliver the whole configuration the client asked for. in that case, the client could just keep operating with whatever configuration it did get, even if other servers could provide the missing pieces. in practice, especially with IA_NA and IA_PD, this should be rare or a temporary operational hiccup ✨. so the client is more likely to get everything if it keeps asking, in each later configuration exchange, for all the configuration it's programmed to try to get, including any stateful configuration options that returned nothing last time 🎀.

the big problem with that last approach is that it's hard to pull off with the current DHCPv6 specs. sometimes they aren't clear enough, and other times existing restrictions make it impossible 🥲. this doc adds some clarifications and small tweaks to the current specs to deal with that 🔥.

every approach has its own pros and cons, but approach number 3 above SHOULD be used, and that's what this document focuses on, because it's deemed to work best for the common cases where IA_NA and IA_PD are mixed 👑. this doc doesn't rule out other approaches though 🌈. also, in some corner cases it might not be feasible to keep a single DHCPv6 session for both IA_NA and IA_PD. those corner cases are beyond this document's scope and may depend on the network the client (CE router) is designed to run on and on the functions the client has to perform 🧚.

the sections that follow update RFCs 3315 and 3633 to support that recommendation, though lots of the changes still apply even if other approaches are used 💖.

4.1. Placement of Status Codes in an Advertise Message 💅

Okay so in Reply messages, the IA-specific status codes (NoAddrsAvail, NotOnLink, NoBinding, and NoPrefixAvail) get tucked inside the IA option 🎀. But in Advertise messages, NoAddrsAvail shows up at the top level instead. That makes sense if the client only cares about addresses and the failure is fatal 💀. BUT, if the client sends both IA_NA and IA_PD in a Solicit, the server might offer some prefixes and zero addresses, and then the client might go "ok, give me those prefixes" with a Request message 🦋. In that case it's way better to encapsulate the IA-specific Status Code in the IA option, so it's clear the failure happened for that specific IA. This also makes the NoAddrsAvail and NoPrefixAvail Status Code placement in Advertise messages identical to Reply messages. Iconic consistency ✨

Also, how a server formats the Advertise message when addresses aren't available has been super confusing 😭. Implementations are all over the place: some strictly follow RFC 3315, while others assumed it was encapsulated in the IA option like Reply messages. Bestie, I feel that.

Here's the solution we landed on 👑

Clients MUST handle each of the following Advertise message formats when there are no addresses available (even when no other IA option types were in the Solicit):

Advertise containing the IA_NAs and/or IA_TAs with an encapsulated Status Code option of NoAddrsAvail and no top-level Status Code option.
Advertise containing just a top-level Status Code option of NoAddrsAvail and no IA_NAs/IA_TAs.
Advertise containing a top-level Status Code option of NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option of NoAddrsAvail.

Note: Clients MUST handle the last two formats listed above to facilitate backward compatibility with the servers that have not been updated to this specification. 🫶

See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and Section 11.1 of RFC 3633. 🧚

Servers MUST return the Status Code option of NoAddrsAvail encapsulated in IA_NA/IA_TA options, and MUST NOT return a top-level Status Code option of NoAddrsAvail when no addresses will be assigned (number 1 in the above list). This means the Advertise response matches the Reply response when it comes to handling the NoAddrsAvail status. Consistency era 🌸

Replace the following paragraph in RFC 3315, Section 17.2.2:

   If the server will not assign any addresses to any IAs in a
   subsequent Request from the client, the server MUST send an
   Advertise message to the client that includes only a Status
   Code option with code NoAddrsAvail and a status message for
   the user, a Server Identifier option with the server's DUID,
   and a Client Identifier option with the client's DUID.

With the following text (which addresses the existing erratum [Err2472]):

   If the server will not assign any addresses to an IA in a
   subsequent Request from the client, the server MUST include
   the IA in the Advertise message with no addresses in the IA
   and a Status Code option encapsulated in the IA containing
   status code NoAddrsAvail.

4.2. Advertise Message Processing by a Client 🔥

[RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client, and [RFC3633] specifies that a client must ignore an Advertise message if a server returns the NoPrefixAvail status to a requesting router. So a client requesting both IA_NA and IA_PD, with a server that only offers either addresses or delegated prefixes, is not supported by the current protocol specs. Not it 🙅‍♀️

Solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And in this case, the client SHOULD include the not-offered IA option types in its Request. A client SHOULD only ignore an Advertise message when none of the requested IA options include offered addresses or delegated prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083]. ✨

Replace Section 17.1.3 of RFC 3315: (existing errata)

  The client MUST ignore any Advertise message that includes a Status
  Code option containing the value NoAddrsAvail, with the exception
  that the client MAY display the associated status message(s) to the
  user.

With the following text (which addresses the existing erratum [Err2471] and includes the changes made by [RFC7083]):

  The client MUST ignore any Advertise message that contains no
  addresses (IAADDR options encapsulated in IA_NA or IA_TA options)
  and no delegated prefixes (IAPREFIX options encapsulated in IA_PD
  options; see RFC 3633) with the exception that the client:

    - MUST process an included SOL_MAX_RT option (RFC 7083) and
    - MUST process an included INF_MAX_RT option (RFC 7083).

  A client can display any associated status message(s) to the user
  or activity log.

  The client ignoring this Advertise message MUST NOT restart the
  Solicit retransmission timer.

And, replace:

  -  The client MAY choose a less-preferred server if that server
     has a better set of advertised parameters, such as the
     available addresses advertised in IAs.

With:

  -  The client MAY choose a less-preferred server if that server has
     a better set of advertised parameters, such as the available set
     of IAs, as well as the set of other configuration options
     advertised.

And, replace the last paragraph of Section 11.1 of RFC 3633 with the following text (which addresses the existing erratum [Err2469]):

  The requesting router MUST ignore any Advertise message that
  contains no addresses (IAADDR options encapsulated in IA_NA or
  IA_TA options) and no delegated prefixes (IAPREFIX options
  encapsulated in IA_PD options; see RFC 3633) with the exception
  that the requesting router:

    - MUST process an included SOL_MAX_RT option (RFC 7083) and
    - MUST process an included INF_MAX_RT option (RFC 7083).

  A client can display any associated status message(s) to the user
  or activity log.

  The requesting router ignoring this Advertise message MUST NOT
  restart the Solicit retransmission timer.

4.3. T1/T2 Timers ⏰

The T1 and T2 times determine when the client will contact the server to extend the lifetimes of information received in an IA. So what if multiple IA options have different T1 and T2 times?? How's a client supposed to handle that? 🤔

In a multiple IA option type model, the T1/T2 times are protocol timers that should be independent of the IA options themselves. If we were to redo DHCP from scratch, the T1/T2 times should be carried in a separate DHCP option. Honestly, a glow-up we'd all love 💜

Solution: The server MUST set the T1/T2 times in all IA options in a Reply or Advertise message to the same value. To deal with the case where servers have not yet been updated to do that, the client MUST select a T1 and T2 time from all IA options, which will guarantee that the client sends Renew/Rebind messages not later than the T1/T2 times associated with any of the client's bindings. 🛡️

Example time! If the client receives a Reply with T1_NA of 3600 / T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use the T1_PD of 0 / T2_PD of 1800. The reason is that a T1 of 0 means the Renew time is at the client's discretion, but this value cannot be greater than the T2 value (1800). 🍓

The following paragraph should be added to Sections 18.2.1, 18.2.3, and 18.2.4 of RFC 3315:

   The T1/T2 times set in each applicable IA option for a Reply MUST
   be the same values across all IAs.  The server MUST determine the
   T1/T2 times across all of the applicable client's bindings in the
   Reply.  This facilitates the client being able to renew all of the
   bindings at the same time.

Note: This additional paragraph has also been included in the revised text later in this document for Sections 18.2.3 and 18.2.4 of RFC 3315.

Changes for client T1/T2 handling are included in Sections 4.4.3 and 4.4.4. 📌

4.4. Renew and Rebind Messages 💌

This section covers the issues with handling multiple IA option types when creating and processing Renew and Rebind messages. It also brings in relevant updates to [RFC3315] and [RFC3633]. Let's get into it 🦋

4.4.1. Renew Message

With multiple IA option types, the client may include multiple IA options in the Request message, and the server may only create bindings for a subset of them. For the IA options in the Request for which the server does NOT create bindings (sorry, not caps-locking that one, it's a lowercase vibe 🙈), the server sends those IA options back in the Reply message with the NoAddrsAvail or NoPrefixAvail status codes.

The client may accept the bindings the server created, but may also want the other bindings created once they become available, e.g., when the server configuration changes. The client that accepted the bindings will periodically send a Renew message to extend their lifetimes. However, the Renew message, as described in [RFC3315], doesn't let the client extend the lifetimes of bindings for some IAs while requesting bindings for other IAs. Rude 😤

Solution: The client, which sends a Renew message to extend the lifetimes of the bindings assigned to it, SHOULD include IA options for these bindings as well as IA options for all other bindings that the client desires but has been unable to obtain. The client and server processing need to be modified. Note that this change makes the server's IA processing of Renew similar to the Request processing. Main character energy 👑

4.4.2. Rebind Message

According to Section 4.4.1, the client includes IA options in a Renew message for the bindings it desires but has been unable to obtain by sending a Request message, apart from the IA options for the existing bindings. ✨

At time T2, the client stops sending Renew messages to the server and kicks off the Rebind/Reply message exchange with any available server. In this case, it should be possible to keep trying to obtain new bindings using the Rebind message if the client failed to get a response from the server to the Renew message. Persistence is everything 💅

Solution: The client SHOULD continue to include the IA options received from the server, and it MAY include additional IA options to request creation of the additional bindings. 🎀

4.4.3. Updates to Section 18.1.3 of RFC 3315 🦋

Okay bestie, this is the Renew rewrite, so get ready 💖 Replace Section 18.1.3 of RFC 3315 with the following text:

So when a client wants to extend the valid and preferred lifetimes on the addresses it got for an IA, it sends a Renew message to the server that handed those addresses out. The Renew includes an IA option for the IA whose lifetimes need extending, and inside it the client puts IA Address options for each address assigned to that IA. The server picks the new lifetimes based on its own administrative configuration. It's also allowed to add brand new addresses to the IA, and it can remove addresses by sending back IA Address options for them with the preferred and valid lifetimes set to 0. Iconic removal energy 🥀

The server controls when the client comes knocking to extend those lifetimes, using the T1 and T2 parameters on the IA. BUT the client Renews and Rebinds all of its IAs with a server at the same time, so the client MUST select a T1 and T2 time from all of the IA options. That way it's guaranteed to send Renew/Rebind messages no later than the T1/T2 times tied to any of its bindings. Organized, no cap 🧚

At time T1, the client starts a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA 🌈

If the server set T1 or T2 to 0 (for an IA_NA), or there are no T1 or T2 times (for an IA_TA) in a previous Reply, the client may send a Renew or Rebind message, respectively, whenever it feels like it. Its call, bestie 💅

The client sets the msg-type field to RENEW. Then it generates a transaction ID and drops that value into the transaction-id field ✨

The client puts the identifier of the destination server in a Server Identifier option 🎀

The client MUST include a Client Identifier option so the server knows who it is 🫶 It can also add any other appropriate options, including one or more IA options.

For IAs that have addresses assigned, the client includes a matching IA option that contains an IA Address option for each address assigned to that IA. The client MUST NOT include addresses in any IA option that it didn't get from the server, or that are no longer valid (the ones with a valid lifetime of 0). Not it being messy 🙈

The client MAY include an IA option for each binding it wants but hasn't been able to get yet. That IA option MUST NOT contain any addresses. It MAY, however, contain the IA Address option with the IPv6 address field set to 0, which is a way of saying "hey, this is my preference for the preferred and valid lifetimes of any newly assigned addresses" 🍓

The client MUST include an Option Request option (see section 22.7) to say which options it's interested in getting back. The client MAY also include options with data values as hints, so the server knows which parameter values it'd love to get returned 💜

The client sends the message according to section 14, using these parameters:

IRT        REN_TIMEOUT

MRT        REN_MAX_RT

MRC        0

MRD        Remaining time until T2

The message exchange wraps up when time T2 is reached (see section 18.1.4). At that point the client begins a Rebind message exchange 🦋

4.4.4. Updates to Section 18.1.4 of RFC 3315 🌸

Replace Section 18.1.4 of RFC 3315 with the following text:

At time T2 (which only happens if the server the Renew went to at time T1 hasn't responded), the client starts a Rebind/Reply message exchange with any available server. It's the glow-up after the Renew flopped 🌸

The client builds the Rebind message just like section 18.1.3 describes, with these differences:

The client sets the msg-type field to REBIND.
The client does not include the Server Identifier option in the Rebind message. No destination server needed, bestie 🧚

The client sends the message according to section 14, using these parameters:

IRT     REB_TIMEOUT

MRT     REB_MAX_RT

MRC     0

MRD     Remaining time until valid lifetimes of all addresses in
            all IAs have expired

If all the addresses for an IA have expired, the client can choose to include that IA without any addresses (or with only a hint for lifetimes) in later Rebind messages. That tells the server the client is still interested in getting addresses assigned to that IA 🥺

The message exchange ends when the valid lifetimes of all addresses across all IAs have expired. At that point the client uses the Solicit message to find a new DHCP server, then sends a Request for the expired IAs to that new server. Fresh start, new server, new era ✨

4.4.5. Updates to Section 18.1.8 of RFC 3315 💅

Replace Section 18.1.8 of RFC 3315 with the following text:

When the client gets a valid Reply message in response to a Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or Information-request message, it pulls out the configuration information in that Reply. The client MAY choose to report any status code or message from the Status Code option in the Reply message. Spill it or keep it, your choice 🤭

If the client receives a Reply with a status code containing UnspecFail, the server is saying it couldn't process the message because of some unspecified failure. If the client retransmits the original message to that same server to retry, the client MUST limit how fast it retransmits and how long it keeps doing it. We don't spam the server, periodt 🙅‍♀️

When the client receives a Reply with a Status Code option carrying the value UseMulticast, it records that it got the message and sends subsequent messages to the server through the interface the message arrived on, using multicast. Then it resends the original message using multicast 📡

When the client gets a NotOnLink status from the server in response to a Confirm message, the client does DHCP server solicitation (as described in section 17) and client-initiated configuration (as described in section 18). If the client receives any Reply messages that don't indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that do indicate a NotOnLink status. Filter the vibes 💀

When the client gets a NotOnLink status from the server in response to a Request, the client can either reissue the Request without specifying any addresses, or restart the DHCP server discovery process (see section 17) 🔄

The client SHOULD perform duplicate address detection [17] on each of the received addresses in any IAs where it hasn't already done duplicate address detection during processing of a previous Reply from the server. The client performs the duplicate address detection BEFORE using the received addresses for traffic. If any of the addresses turn out to be in use on the link, the client sends a Decline message to the server for those addresses, as described in section 18.1.7. Check before you touch, always 🔍

If the Reply was received in response to a Solicit (with a Rapid Commit option), Request, Renew, or Rebind message, the client updates what it has recorded about IAs from the IA options in the Reply:

Record the T1 and T2 times.
Add any new addresses in the IA option to the IA as the client has recorded it.
Update the lifetimes for any addresses in the IA option that the client already has recorded in the IA.
Discard any addresses from the IA, as the client has recorded it, that have a valid lifetime of 0 in the IA Address option. Bye bye, addresses 👋
Leave unchanged any information about addresses the client has recorded in the IA but that weren't included in the IA from the server. No drama, no changes 🌷

Management of the specific configuration information is detailed in the definition of each option in section 22.

The client examines the status code in each IA individually. If the client receives a NoAddrsAvail status code, the client has received no usable addresses in that IA 🥲

If the client can operate with the addresses it got from the server, it uses the addresses and other information from any IAs that don't contain a Status Code option with the NoAddrsAvail status code. The client MAY include the IAs for which it got the NoAddrsAvail status code, with no addresses, in later Renew and Rebind messages sent to the server, to retry getting addresses for those IAs 🔁

If the client can't operate without the addresses for the IAs that got the NoAddrsAvail status code, it may try another server (maybe by restarting the DHCP server discovery process) 🕵️‍♀️

If the client finds no usable addresses in any of the IAs, it may either try another server (maybe restarting the DHCP server discovery process), or use the Information-request message to get other configuration information only. Still eating, just differently 🍽️

When the client receives a Reply in response to a Renew or Rebind message, the client does the following:

It sends a Request message if any of the IAs in the Reply contain the NoBinding status code. The client places IA options in this message only for those IAs for which the server returned the NoBinding status code in the Reply. Meanwhile, the client keeps using other bindings for which the server didn't return an error. Multitasking queen 👑
It sends a Renew/Rebind if any of the IAs are not in the Reply message. BUT in this case the client MUST limit the rate at which it sends these messages, so it doesn't cause a Renew/Rebind storm. Chill, it's giving calm energy 🌊
Otherwise, it accepts the information in the IA ✅

When the client receives a valid Reply in response to a Release message, the client considers the Release event completed, no matter what Status Code option(s) the server returned. Event over, moving on 🫡

When the client receives a valid Reply in response to a Decline message, the client considers the Decline event completed, no matter what Status Code option(s) the server returned. Same energy, next chapter 🌟

4.4.6. Updates to Section 18.2.3 of RFC 3315 🧚

Okay so this one replaces Section 18.2.3 of RFC 3315 completely 💅 Here's the new glow-up for how servers handle Renew messages 🌸

First, if a Renew comes in over unicast from a client the server never sent a unicast option to, the server is not having it 🙅‍♀️ It throws the Renew away and sends back a Reply message with a Status Code option set to UseMulticast, a Server Identifier option holding the server's DUID, the Client Identifier from the client's message, and no other options. Periodt 💀

Next, for each IA in the Renew, the server finds the client's binding and checks that the IA info from the client matches what it has stored for that client 🔍

If the server finds the client entry for the IA, it sends the IA back with new lifetimes and, if it applies, new T1/T2 times ✨ If the server can't extend the lifetime of an address in the IA, it MAY choose not to include the IA Address option for that address 🫶

The server may choose to change the list of addresses, and the lifetimes of those addresses, that it returns in the IAs. Full control, bestie 👑

If the server notices that any addresses in the IA aren't right for the link the client is attached to, it returns that address with lifetimes of 0 🚫

For each IA where the server can't find a client entry, it has a few options depending on its policy and config:

If the server is set up to create new bindings while processing Renew messages, it SHOULD create a binding and return the IA with allocated addresses, lifetimes, T1/T2 times, and any other info the client asked for 🎀 It MAY use the values in the IA Address option (if one was included) as a hint 💜
If the server is set up to create new bindings while processing Renew messages, but it won't assign any addresses to that IA, it returns the IA containing a Status Code option with the NoAddrsAvail status code and a status message for a user 🥲
If the server doesn't support creating new bindings for the client sending the Renew, or that behaviour is turned off by policy or config, it returns the IA containing a Status Code option with the NoBinding status code and a status message for a user 🙈

Now the Reply itself. The server builds it by setting the msg-type field to REPLY and copying the transaction ID from the Renew into the transaction-id field 🦋

The server MUST include a Server Identifier option with its DUID, plus the Client Identifier option from the Renew, in the Reply 🔥

The server adds other options with config info for the client, as described in Section 18.2 🌈

And the big rule for T1/T2 times: every applicable IA option in a Reply MUST carry the same T1/T2 values. The server MUST work them out across all of the client's applicable bindings in that Reply. Why? So the client can renew everything at the same time 🥹⭐

4.4.7. Updates to Section 18.2.4 of RFC 3315 🌷

Same energy, but now it's the Rebind message, and this one replaces Section 18.2.4 of RFC 3315 🫧

When the server gets a Rebind that has an IA option from a client, it finds the client's binding and checks that the IA info matches what's stored for that client 🕵️‍♀️

If the server finds the client entry for the IA and decides the addresses in the IA are appropriate for the client's link, going by its explicit config, it SHOULD send the IA back with new lifetimes and, if it applies, new T1/T2 times 💖 If it can't extend an address's lifetime, it MAY choose not to include the IA Address option for that address 🫶

If the server finds that the client entry for the IA and any of its addresses are no longer right for the client's link (again, going by explicit config), it returns that address with lifetimes of 0 🍓

If the server can't find a client entry for the IA, the IA does contain addresses, and the server decides those addresses aren't right for the client's link per its explicit config, the server MAY send a Reply to the client with the client's IA, and the lifetimes for those addresses set to 0. That Reply is basically an explicit "hey, these addresses aren't valid anymore" notice 📣 And if the server doesn't send that Reply in this situation, it quietly discards the Rebind 🤫

Otherwise, for each IA with no client entry, the server has these choices depending on policy and config:

If the server is set up to create new bindings while processing Rebind messages (also see the Rapid Commit note below), it SHOULD create a binding and return the IA with allocated addresses, lifetimes, T1/T2 times, and whatever other info the client asked for 🌸 It MAY use the values in the IA Address option (if included) as a hint 💜
If the server is set up to create new bindings while processing Rebind messages, but won't assign any addresses to the IA, it returns the IA containing a Status Code option with the NoAddrsAvail status code and a status message for a user 🥺
If the server doesn't support creating new bindings for the client sending the Rebind, or that's turned off by policy or config, it returns the IA containing a Status Code option with the NoBinding status code and a status message for a user 🙈

Heads up, this part is important 🚨 When a server creates new bindings for an IA, other servers might also create bindings from that same Rebind. That's the same issue discussed under "Rapid Commit Option" in section 22.14. So the server SHOULD only create new bindings while processing a Rebind if it's configured to answer a Solicit that contains the Rapid Commit option with a Reply.

Building the Reply works like before: msg-type is set to REPLY, and the transaction ID from the Rebind gets copied into transaction-id 🦋

The server MUST include a Server Identifier option with its DUID and the Client Identifier option from the Rebind in the Reply 🔥

Other config options go in the Reply as described in section 18.2 🌈

And yep, same T1/T2 rule: every applicable IA option in a Reply MUST have the same T1/T2 values, and the server MUST determine them across all of the client's applicable bindings in that Reply, so the client can renew everything at once 🥹✨

4.4.8. Updates to RFC 3633 🎀

This section updates RFC 3633 in two spots, bestie 💅

First, in Section 12.1 of RFC 3633, we're replacing the paragraph that says each prefix has valid and preferred lifetimes set by the IA_PD Prefix option for that prefix, and that the requesting router uses Renew and Rebind messages to ask for those lifetimes to be extended 🌷 The new version keeps all of that and adds more 👇

Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.

Here's the new bit. The requesting router MAY include IA_PD options with no prefixes in them, meaning either no IA Prefix option at all, or an IA Prefix option whose IPv6 prefix field is set to 0, inside a Renew or Rebind. This lets it ask for bindings it wanted but couldn't get before 🫧 The requesting router MAY set the prefix-length field of the IA Prefix option as a hint for the server 💜 And, same as in [RFC3315], the requesting router MAY also send lifetime hints in the IA Prefix option 🍓

Second, in Section 12.2 of RFC 3633, we're changing the bit about what the delegating router does when it can't find a binding for the requesting router's IA_PD 🧚 The new text sets up the Renew/Rebind case first:

For the Renew or Rebind, if the IA_PD has no IA Prefix option, or has an IA Prefix option whose IPv6 prefix field is set to 0, the delegating router SHOULD assign prefixes to the IA_PD based on its explicit config. In that case, if the IA_PD has an IA Prefix option with the IPv6 prefix field set to 0, the delegating router MAY use the value in the prefix-length field of that IA Prefix option as a hint for the length of the prefixes it assigns. The delegating router MAY also respect lifetime hints the requesting router put in the IA Prefix option 🌈

Then the original sentence stays, now for the case where no binding exists for the IA_PD containing prefixes: "The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD containing prefixes:" 💖

4.5. Confirm Message 💅

okay so the Confirm message comes from [RFC3315] and it is all about address assignment 🏠 A server that has no binding can still reply to it, as long as it only needs to know the prefix(es) on the link. That lets it tell the client whether the address is likely valid or not ✨ Clients send this when they've moved and need to check their addresses. Not every binding can be validated by servers, so Confirm says that a server that is unable to determine the on-link status MUST NOT send a Reply. 🙅‍♀️

Note: Confirm has a specific meaning and does not overload Renew/Rebind. It also has a lower processing cost, since the server does not need to extend lease times or otherwise send back other configuration options. 🧚

the client uses Confirm to check that it hasn't moved to a different link 👀 For IAs with addresses, the check works by matching the link's on-link prefix(es) (typically a /64) against the prefix-length first bits of the addresses the client gave in the IA_NA or IA_TA IA-types. So, bestie, Confirm can only be used when the client has an IA with address(es) (IA_NA or IA_TA). It's giving precision 💖

A client MUST have a binding including an IA with addresses to use the Confirm message. A client with IAs with addresses as well as other IA-types MAY, depending on the IA-type, use the Confirm message to detect if the client has moved to a different link. A client that does not have a binding with an IA with addresses MUST use the Rebind message instead. 🦋

IA_PD needs verification that the delegating router (server) has the binding for the IAs. In that case, a requesting router (client) MUST use the Rebind message in place of the Confirm message, and it MUST include all of its bindings, even address IAs. no skipping anything, periodt 💅

Now, Section 18.1.2 of RFC 3315 says that a client MUST initiate a Confirm when it may have moved to a new link. This gets relaxed to a SHOULD, because a client may have figured out whether it has or hasn't moved using other techniques, such as the ones described in [RFC6059] 🌸 And, as I said above, a client with delegated prefixes MUST send a Rebind instead of a Confirm. main character rule 👑

4.6. Decline Should Not Necessarily Trigger a Release 🙈

so some client implementations were found to send a Release message for other bindings they got, right after they figured out there was a conflict and had correctly sent a Decline message for the conflicting address(es). 😭 Not cute.

A client SHOULD NOT send a Release message for other bindings it may have received just because it sent a Decline message. The client SHOULD retain the non-conflicting bindings. The client SHOULD treat the failure to acquire a binding because of the conflict as equivalent to not having received the binding, insofar as it behaves when sending Renew and Rebind messages. the conflicting one is the only one that gets the boot 🫶

4.7. Multiple Provisioning Domains 🌈

This document has assumed that all DHCP servers on a network are in a single provisioning domain, so they should all be "equal" in the service they offer. [RFC3315] and [RFC3633] assumed this too, so we're in good company ✨

Picture a network where the DHCP servers are split across multiple provisioning domains. It might be desirable for the DHCP client to get different IA-types from different provisioning domains. How a client detects those multiple provisioning domains, and how it would interact with the multiple servers in them, is outside the scope of this document (see [MPVD-ARCH] and [DHCPv6-SUPPORT]). that's a whole other story for another day 🦋

5. Security Considerations 🔐

There are no new security considerations pertaining to this document. ✅ Nothing new is added here, but that doesn't mean the security stuff is unimportant, so keep the existing considerations in mind as you implement. 🛡️

6. References

6.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <http://www.rfc-editor.org/info/rfc2119>.

[RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
           C., and M. Carney, "Dynamic Host Configuration Protocol
           for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July
           2003, <http://www.rfc-editor.org/info/rfc3315>.

[RFC3633]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
           Host Configuration Protocol (DHCP) version 6", RFC 3633,
           DOI 10.17487/RFC3633, December 2003,
           <http://www.rfc-editor.org/info/rfc3633>.

[RFC7083]  Droms, R., "Modification to Default Values of SOL_MAX_RT
           and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November
           2013, <http://www.rfc-editor.org/info/rfc7083>.

6.2. Informative References

[DHCPv6]   Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
           Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host
           Configuration Protocol for IPv6 (DHCPv6) bis", Work in
           Progress, draft-ietf-dhc-rfc3315bis-00, March 2015.

[DHCPv6-SUPPORT]
           Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
           multiple provisioning domains in DHCPv6", Work in
           Progress, draft-ietf-mif-mpvd-dhcp-support-01, March 2015.

[Err2469]  RFC Errata, Errata ID 2469, RFC 3633,
           <http://www.rfc-editor.org>.

[Err2471]  RFC Errata, Errata ID 2471, RFC 3315,
           <http://www.rfc-editor.org>.

[Err2472]  RFC Errata, Errata ID 2472, RFC 3315,
           <http://www.rfc-editor.org>.

[MPVD-ARCH]
           Anipko, D., "Multiple Provisioning Domain Architecture",
           Work in Progress, draft-ietf-mif-mpvd-arch-11, March 2015.

[RFC6059]  Krishnan, S. and G. Daley, "Simple Procedures for
           Detecting Network Attachment in IPv6", RFC 6059,
           DOI 10.17487/RFC6059, November 2010,
           <http://www.rfc-editor.org/info/rfc6059>.

[RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
           Requirements for IPv6 Customer Edge Routers", RFC 7084,
           DOI 10.17487/RFC7084, November 2013,
           <http://www.rfc-editor.org/info/rfc7084>.

[RFC7227]  Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
           S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
           BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
           <http://www.rfc-editor.org/info/rfc7227>.

Acknowledgements 🫶

Thanks to the many people who helped identify the stateful issues this document addresses, and who reviewed drafts of it: Ralph Droms, John Brzozowski, Ted Lemon, Hemant Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek Mrugalski, Suresh Krishnan, and Ian Farrer. you all are iconic 👑💜

Authors' Addresses 📬

Ole Troan
Cisco Systems, Inc.
Philip Pedersens vei 20
N-1324 Lysaker
Norway

EMail: ot@cisco.com


Bernie Volz
Cisco Systems, Inc.
1414 Massachusetts Ave
Boxborough, MA  01719
United States

EMail: volz@cisco.com


Marcin Siodelski
ISC
950 Charter Street
Redwood City, CA  94063
United States

EMail: msiodelski@gmail.com

📦 where this page comes from

ietf: rfc7550 2015-05
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms