RFC 8168

DHCPv6 Prefix-Length Hint Issues

📅 published May 2017, from ietf

DHCPv6 Prefix-Length Hint Issues 🎀

okay bestie, this is RFC 8168 💖, a Standards Track doc from the IETF (ISSN 2070-1721). It was written by T. Li, C. Liu, and Y. Cui from Tsinghua University, and it's dated May 2017 🌸. The title block doesn't list any RFCs it obsoletes or updates ✨.

Abstract ✨

okay so DHCPv6 Prefix Delegation lets a client include a prefix-length hint in its IA_PD option to say what size prefix it'd prefer 💅. The catch is that the spec isn't clear on how the client and server should act in different situations involving that hint 🤔. This doc sums up the existing problems with the prefix-length hint and gives guidance on what the client and server could do in those situations 🦋.

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Info about the current status of this document, any errata, and how to send feedback on it can be found at http://www.rfc-editor.org/info/rfc8168 🔗.

Copyright (c) 2017 IETF Trust and the persons identified as the document 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 in effect on the date of publication of this document. Please read these documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License 🫶.

Table of Contents 🗂️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
3.  Problem Description and Proposed Solutions  . . . . . . . . .   3
  3.1.  Creation of Solicit Message . . . . . . . . . . . . . . .   3
  3.2.  Receipt of Solicit Message  . . . . . . . . . . . . . . .   4
  3.3.  Receipt of Advertise Message  . . . . . . . . . . . . . .   5
  3.4.  Creation of Renew/Rebind Message  . . . . . . . . . . . .   6
  3.5.  Receipt of Renew/Rebind Message . . . . . . . . . . . . .   6
  3.6.  General Recommendation  . . . . . . . . . . . . . . . . .   8
4.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
6.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

1. Introduction 🌸

okay so DHCPv6 Prefix Delegation [RFC3633] lets a client include a prefix-length hint in the message it sends to the server, basically saying "this is the prefix size I'd love" 💅. The client sends that hint as an IA_PD Prefix Option (IAPREFIX option), tucked inside an IA_PD option, with the "IPv6 prefix" field set to zero and the "prefix-length" field set to a non-zero value 🧚. Servers are totally free to ignore the hint depending on their policy 🙃.

BUT some clients can't function (or only work in a degraded state) if they get a prefix with a different length than they asked for 😭. Like, if the client asks for a /56 and the server gives it a /64, the client might not be able to split the prefix across all its interfaces, and that's giving major problems 💀. For other hints, like asking for an explicit address, it's less of a big deal, since it just helps a client that wants to keep using what it used last time 🌈. The point is the prefix-length hint directly affects what the client can actually do, so it should be given more consideration ✨.

[RFC3633] is unclear about how the client and server should act in different situations involving the prefix-length hint 🤷‍♀️. From the client side, it should be able to use the hint to signal its real-time need to the server, and it should be able to handle prefixes with lengths that differ from the hint 💖. This document gives guidance on what a client should do in different situations so it can operate properly. From the server side, the server is free to ignore the prefix-length hints depending on server policy. However, when the server has a policy for considering the hint, this document explains how the server should handle the hint in different situations 👑.

2. Requirements Language 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🎀.

3. Problem Description and Proposed Solutions 🔥

3.1. Creation of Solicit Message 💌

Problem:

okay so the Solicit message is how a client asks servers for prefixes and other configuration parameters 📨. The client might want a different prefix length because its configuration changed, or it might just want the same prefix again after a reboot 🔄. It might also prefer a prefix of a specific length in case the requested prefix isn't available 🤞. The server could decide whether to give the client its preferred prefix based on server policy, but the client should be able to signal its real-time need to the server 💅.

The server usually has a record of the prefix it gave the client during its most recent interaction 🗃️. The best way to make sure the client gets a completely new delegated prefix is to send a new IAID (Identity Association IDentifier) in the IA_PD (Identity Association for Prefix Delegation). BUT that would mean the client device needs persistent storage, because rebooting the device would make the client use the original IAID in the IA_PD 😩.

Solution:

When the client prefers a prefix of a specific length from the server, the client MUST send a Solicit message using the same IAID in the IA_PD, include the preferred prefix-length value in the "prefix-length" field of the IAPREFIX option, and set the "IPv6 prefix" field to zero. This tells the server that the client prefers a prefix of the specified length, regardless of what it received before 🎯.

When the client wants the same prefix back from the server, it MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix value in the "IPv6 prefix" field of the IAPREFIX option, and include the length of the prefix in the "prefix-length" field. This tells the server that the client wants the same prefix back 🫶.

When the client wants the same prefix back from the server and would also like to accept a prefix of a specified length in case the requested prefix isn't available, the client MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix in one IAPREFIX option, and include the prefix-length hint in another IAPREFIX option. There's no requirement about the order of the two IAPREFIX options 🦋.

3.2. Receipt of Solicit Message 📬

Problem:

[RFC3633] lets a client include a prefix-length hint in the Solicit message to signal its preference to the server. How the server should handle that hint is unclear 😵‍💫. The client might want a different prefix length because of configuration changes, or it might just want the same prefix again after a reboot. The server should interpret these cases differently 🧠.

Lots of servers are configured to only provide prefixes of specific lengths to the client. For example, if the client requested a /54 but the server can only provide /30, /48, and /56. So how should these servers decide which prefix to give the client based on the prefix-length hint? 🤔

Solution:

When a Solicit message arrives, if the client included only a prefix-length hint in the message, the server SHOULD first check its prefix pool for a prefix with a length matching the prefix-length hint value, regardless of the prefix record from previous interactions with the client. If the server doesn't have a prefix with a length matching the prefix-length hint value, then the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value 🌟.

If the client included a specific prefix value in the Solicit message, the server SHOULD check its prefix pool for a prefix matching the requested prefix value. If the requested prefix isn't available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD check its prefix pool for a prefix with a length matching the prefix-length hint value. If the server doesn't have a prefix with a length matching the prefix-length hint value, the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value 💅.

If the server won't assign any prefixes to any IA_PDs in a subsequent Request from the client, the server MUST send an Advertise message to the client, as described in Section 11.2 of [RFC3633] 📮.

more to come in part 2 🦋 (section 3.3 is up next and it's giving main character energy) 💜

3.3. Receipt of Advertise Message ✨

Problem:

okay so the server might not be able to honor the prefix-length hint 🥺 because of server policy or because its prefix pool is running on fumes 🫠. If the Advertise message comes back with a prefix length that's different from what the client asked for in its Solicit, the big question is whether the client should just take what it got or keep asking for the length it wants 🤔. Some clients literally can't function with a different length, but if they ignore Advertise and keep soliciting for their preferred length, they might get stuck in the DHCP process forever 💀. And should the client also ignore other config stuff like available addresses? 🧐

Solution:

If the client can actually use the prefixes in the Advertise messages even though they're not the hint length, it SHOULD choose the shortest prefix length that's closest to the hint 💅. It SHOULD keep requesting its preferred prefix in later DHCPv6 messages, as defined in Section 3.4 of this document 🎀.

If the client sent a Solicit with only IA_PDs and can't use the prefixes in the Advertise messages, it MUST ignore those Advertise messages and keep sending Solicit messages until it gets its preferred prefix 🙈. To avoid traffic congestion, it MUST send Solicit messages at defined intervals, as specified in [RFC7083] 🌸.

If the client also asked for other stateful config options, like IA_NAs, and can't use the prefixes in the Advertise messages, the client SHOULD accept those other stateful options and keep requesting the desired IA_PD prefix in later DHCPv6 messages, as specified in [RFC7550] 🫶.

3.4. Creation of Renew/Rebind Message 🌈

Problem:

servers might not be able to give a prefix that's equal to or shorter than the hint 😬. If the client decided to use the prefix the server gave even though it's longer than the hint, but still prefers the hint length from its Solicit, there should be some way for it to say so during Renew/Rebind 🫣. For example, if the client asked for a /60 and got a /64, it should be able to tell the server during Renew/Rebind that it still prefers a /60 🧚. That's so the server can check whether its pool has the client's preferred prefix right then. [RFC3633] isn't totally clear on whether the client is allowed to put a prefix-length hint in the Renew/Rebind message 🤷‍♀️.

Solution:

During Renew/Rebind, if the client prefers a prefix length that's different from the prefix it's currently using, the client SHOULD send the Renew/Rebind message with the same IA_PD and include two IAPREFIX options: one with the currently delegated prefix and one with the prefix-length hint 🦋. This extends the lifetime of the prefix the client is using now, gets the prefix it prefers, and lets it go through a graceful switchover ✨.

If the server can't provide the newly requested prefix but can extend the lifetime of the old one, the client SHOULD keep using the old prefix 💖.

3.5. Receipt of Renew/Rebind Message 💜

Problem:

the prefix the client prefers might show up in the server's prefix pool during Renew/Rebind, even though it wasn't available during Solicit 👀. That could be due to a server config change, or because some other client stopped using it 🔄.

The question is whether the server should remember the prefix-length hint the client sent in its Solicit and check it during Renew/Rebind to see if it can give the length the client wanted 🧠. That means the server would have to keep extra info about each client 😮‍💨. There's also the chance the client changed its mind about the length in the meantime, so the remembered hint might not match what it wants now 🙃.

Instead of making the server remember anything, the client could just include the prefix-length hint in the Renew/Rebind message 🎯. [RFC3633] is unclear about what the server should do if the client includes a hint there, and whether the server could hand out a different prefix in that case 🫠.

Solution:

When a Renew/Rebind arrives and the client's IA_PD includes both an IAPREFIX option with the delegated prefix value and an IAPREFIX option with a prefix-length hint value, the server SHOULD check whether it could extend the lifetime of the original delegated prefix, and whether it has any available prefix matching the prefix-length hint (or determine the closest possible one to the hint) within its limits 🔍.

If the server assigned the prefix included in the IA_PD to the client, the server SHOULD do one of the following, depending on its policy 💅:

  1. Extend the lifetime of the original delegated prefix.
  2. Extend the lifetime of the original delegated prefix and assign a new prefix of the requested length.
  3. Mark the original delegated prefix as invalid by giving it 0 lifetimes, and assign a new prefix of the requested length. This avoids the complexity of handling multiple delegated prefixes, but it may break all the existing connections of the client 💀.
  4. Assign the original delegated prefix with 0 preferred-lifetime, a specific non-zero valid-lifetime depending on actual requirements, and assign a new prefix of the requested length. This lets the client finish up existing connections with the original prefix and use the new prefix for new connections 🌸.
  5. Don't include the original delegated prefix in the Reply message, and assign a new prefix of the requested length. The original prefix stays valid until its lifetime expires, which avoids sudden renumbering on the client 🫶.

If the server doesn't know the client's bindings (for example, a different server receives the message during Rebind), the server SHOULD ignore the original delegated prefix and try to assign a new prefix of the requested length 🧭.

It's unnecessary for the server to remember the prefix-length hint the client requested during Solicit 🙅. The client's preference for the prefix length might have changed during that time, so the prefix-length hint in the Renew message is what the client wants at that moment 💯.

3.6. General Recommendation 🍓

the recommendation for these issues is that a client which wants (at least) to have a delegated prefix of a specific length should always include an IAPREFIX option with just the prefix-length hint, in addition to any IAPREFIX options it has already included for each IA_PD, in any Solicit, Request, Renew, and Rebind messages it sends 📬. A server is free to ignore the hint, but servers that do not choose to ignore it should attempt to assign a prefix of the hint length (or assign the next closest length that does not exceed the hint) if one is available 👑. Whether a server favors the hint or avoids a renumbering event is a matter of server policy 🫧.

4. Security Considerations 🔐

This document gives guidance on how clients and servers interact with regard to the DHCPv6 prefix-length hint. Security considerations in DHCP are described in Section 23 of [RFC3315]. Security considerations regarding DHCPv6 prefix delegation are described in Section 15 of [RFC3633] 🛡️.

5. IANA Considerations 🎀

This document does not require any IANA actions 🥰.

6. Normative References 📚

Acknowledgements 💖

Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, Marcin Siodelski, Ted Lemon, Roni Even, Benoit Claise, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan Hares, and Hilarie Orman for their review and comments 🫶✨.

Authors' Addresses 🧚

Tianxiang Li
Tsinghua University
Beijing  100084
China

Phone: +86-18301185866
Email: peter416733@gmail.com
Cong Liu
Tsinghua University
Beijing  100084
China

Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Yong Cui
Tsinghua University
Beijing  100084
China

Phone: +86-10-6260-3059
Email: yong.cui.thu@gmail.com
📦 where this page comes from