RFC 8947
Link-Layer Address Assignment Mechanism for DHCPv6
RFC 8947: Link-Layer Address Assignment Mechanism for DHCPv6 💖
okay bestie, gather round because this one is so good 🎀 It's a Standards Track spec from the IETF, written by B. Volz (Cisco), T. Mrugalski (ISC), and CJ. Bernardos (UC3M). It was published in December 2020 and its ISSN is 2070-1721 🦋 Nothing in the title block says it obsoletes or updates any other RFC, so it's a fresh standalone vibe ✨
The whole point is giving automated devices their own link-layer (MAC) addresses through DHCPv6 🧚 It's built for situations where preassigned addresses from a manufacturer aren't an option or just aren't needed.
Abstract
okay so picture this 🌸 Large-scale virtualization and other automated setups keep spinning up brand new devices, and those devices need link-layer addresses too. If you just pick addresses at random, collisions get more and more likely as the number of devices grows, and that's not acceptable 😭 So an allocation mechanism is required. This document extends DHCPv6 so it can hand out link-layer addresses at scale, for situations where a manufacturer didn't preassign them or where that would be pointless 💅
Status of This Memo
This is an Internet Standards Track document 👑
It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🫶
You can find the current status, any errata, and how to give feedback at https://www.rfc-editor.org/info/rfc8947 🔥
Copyright Notice
Copyright (c) 2020 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 (https://trustee.ietf.org/license-info) as in effect on the date of publication. Please read those carefully, because they spell out your rights and restrictions 🍓 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes.
Table of Contents
1. Introduction
2. Requirements Language
3. Terminology
4. Deployment Scenarios
4.1. Scenario: Proxy Client Mode
4.2. Scenario: Direct Client Mode
5. Mechanism Overview
6. Design Assumptions
7. Information Encoding
8. Requesting Addresses
9. Renewing Addresses
10. Releasing Addresses
11. Option Definitions
11.1. Identity Association for Link-Layer Addresses Option
11.2. Link-Layer Addresses Option
12. Selecting Link-Layer Addresses for Assignment to an IA_LL
13. IANA Considerations
14. Security Considerations
15. Privacy Considerations
16. References
16.1. Normative References
16.2. Informative References
Appendix A. IEEE 802c Summary
Acknowledgments
Authors' Addresses1. Introduction ✨
So there are a bunch of deployment types that have to initialize a huge pile of devices 🧚 One big example is spinning up virtual machines (VMs) at massive scale. New VM instances usually get a link-layer address, but random assignment doesn't scale well because of collision risk (see Appendix A.1 of [RFC4429]) 💀 Another use case is Internet of Things (IoT) devices (see [RFC7228]). Those could strain the IEEE's available Organizationally Unique Identifier (OUI) global address space. Usually these devices don't need global link-layer uniqueness, but a link-layer assignment mechanism lets you avoid conflicts inside an administrative domain 🫶 So it's desirable to have some mechanism that can assign locally unique Media Access Control (MAC) addresses.
This document proposes a new mechanism that extends DHCPv6 operation to handle link-layer address assignments 🦋
Why DHCPv6? Because [RFC8415] can already allocate all sorts of resources (non-temporary addresses, temporary addresses, prefixes, and lots of options) and it already has the infrastructure to maintain those allocations. There are loads of server and client implementations, a big deployed relay infrastructure, and helpers like leasequery and failover. So it's a really good candidate for this job 👑
This design should work for any link-layer address type, but some details are specific to IEEE 802 48-bit MAC addresses [IEEEStd802]. Future documents may cover other link-layer address types 🌸
IEEE 802 originally set aside half of the 48-bit MAC address space for local use (where the Universal/Local (U/L) bit is set to 1). In 2017, IEEE published an amendment [IEEEStd802c] that splits this space into quadrants with different address rules. More details are in Appendix A 🌈
IEEE is also developing protocols and procedures for assigning locally unique addresses (IEEE 802.1CQ). This work might serve as an alternative assignment protocol. For more background, see [IEEE-P802.1CQ-Project] 💜
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. Terminology 📖
The DHCP terminology from [RFC8415] applies here. The definitions below either tweak those definitions for how this document uses them, or they define new terms used in here 🧚
address Unless specified otherwise, a link-layer (or MAC)
address, as specified in [IEEEStd802]. The address
is typically six octets long, but some network
architectures may use different lengths.
address block A number of consecutive link-layer addresses. An
address block is expressed as a first address plus a
number that designates the number of additional
(extra) addresses. A single address can be
represented by the address itself and zero extra
addresses.
client A node that is interested in obtaining link-layer
addresses. It implements the basic DHCP mechanisms
needed by a DHCP client, as described in [RFC8415],
and supports the new options specified in this
document (IA_LL and LLADDR). The client may or may
not support IPv6 address assignment and prefix
delegation, as specified in [RFC8415].
IA_LL Identity Association for Link-Layer Address, an
identity association (IA) used to request or assign
link-layer addresses. See Section 11.1 for details
on the IA_LL option.
LLADDR Link-layer address option that is used to request or
assign a block of link-layer addresses. See
Section 11.2 for details on the LLADDR option.
server A node that manages link-layer address allocation and
is able to respond to client queries. It implements
basic DHCP server functionality, as described in
[RFC8415], and supports the new options specified in
this document (IA_LL and LLADDR). The server may or
may not support IPv6 address assignment and prefix
delegation as specified in [RFC8415].4. Deployment Scenarios 🦋
This mechanism is built to be generic and usable in lots of deployments, but there are two scenarios it's really aiming at: (i) proxy client mode and (ii) direct client mode 💖
4.1. Scenario: Proxy Client Mode 🧚
This mode is for when an entity acts as a DHCP client asking available DHCP servers to assign one or more addresses (an address block). The client then hands those addresses out to the final end devices 🌸 Large-scale virtualization is one application of proxy client mode. In those environments this entity is often called a "hypervisor," and it's frequently required to spawn new VMs. The hypervisor needs to give new addresses to those machines. It doesn't use the addresses for itself. It uses them to create new VMs with the right addresses 💅 It's worth pointing out how cumulative this scenario is. Over time the hypervisor will probably use more and more addresses. Some obsolete VMs get deleted, and their addresses can potentially be reused by new VMs ♻️
4.2. Scenario: Direct Client Mode 👑
This mode can be used when an entity acts as a DHCP client asking available DHCP servers to assign one or more addresses (an address block) for its own use 🫶 This usage is related to IoT (see Section 1). On first boot, for each interface, the device uses a temporary address, as described in [IEEEStd802.11] and IEEE 802.1CQ [IEEE-P802.1CQ-Project], to send initial DHCP packets to available DHCP servers. In those packets the device asks for a single address for that network interface. Once the server assigns an address, the device drops its temporary address and uses the assigned (leased) one 🦋
Note that a client working like this, which doesn't have a globally unique link-layer address on any of its interfaces, MUST NOT use a link-layer-based DHCP Unique Identifier (DUID). For more details, see Section 11 of [RFC8415] 🙈
Also, a client working like this might run into trouble if the switch it's plugged into prohibits or restricts link-layer address changes. That can limit where this capability works, or the administrator may need to tweak the switch configuration(s) to allow an address change 🍓
We're only at part 1, so more is coming, bestie 💜
5. Mechanism Overview ✨
okay so in every scenario from Section 4, this protocol basically works the same way 💅. The device asking for an address (the DHCP client) sends a Solicit message with an IA_LL option to all the DHCP servers it can find. That IA_LL option MUST include an LLADDR option that specifies the link-layer-type and link-layer-len, and it may include a specific address or address block as a hint for the server 🎀. Each server answers with either a Reply message carrying committed address(es) (if Rapid Commit was requested and honored) or an Advertise message with offered address(es) 🦋. The client picks one server's response, as governed by [RFC8415]. If needed, the client sends a Request message, the target server assigns the address(es), and then it sends a Reply message. Once that Reply arrives, the client can start using those address(es) 🫶.
Normal DHCP mechanisms are in play here too 🌸. The client is expected to renew the addresses on a schedule set by the T1 and T2 timers, and to stop using an address once its valid lifetime expires. Renewals can be turned off by the server sending "infinity" as the T1 and T2 values (see Section 7.7 of [RFC8415]). An administrator can also make an address assignment permanent by using the "infinity" valid lifetime, as defined in Section 7.7 of [RFC8415] 👑.
The client can release addresses when it no longer needs them by sending a Release message (see Section 18.2.7 of [RFC8415]) 🧚.
Figure 9 in [RFC8415] shows a timeline diagram of the messages exchanged between a client and two servers over the typical life cycle of one or more leases 📈.
Confirm and Information-request messages are not used in link-layer address assignment 🙅♀️. Decline should technically never be needed 🙈, but see Section 12 for one situation where this message is needed.
Clients implementing this mechanism SHOULD use the Rapid Commit option, as specified in Sections 5.1 and 18.2.1 of [RFC8415], to get addresses with a two-message exchange when it's possible ⚡.
Devices supporting this proposal MAY support the reconfigure mechanism, as defined in Section 18.2.11 of [RFC8415] 💜. If both the server and the client support it, the reconfigure mechanism lets the administrator immediately tell clients that the configuration has changed, and it triggers retrieval of the relevant changes right away instead of waiting for the T1 timer to elapse. Since this mechanism requires implementation of the Reconfiguration Key Authentication Protocol (see Section 20.4 of [RFC8415]), small-footprint devices may choose not to support it 🔋.
6. Design Assumptions 🌈
One of the essential parts of this mechanism is how cumulative it is, especially in the hypervisor scenario 📦. The server-client relationship in the hypervisor scenario does not look like other DHCP transactions. In a typical environment there would be one server and a fairly small number of hypervisors, possibly even only one. Over time, though, the number of addresses the hypervisor(s) request will grow as more VMs get spawned 🚀.
Another crucial thing for efficient design is that a single client acting as a hypervisor will likely use thousands of addresses 😭. An approach like the one used for IPv6 address or prefix assignment (an IA container with all assigned addresses listed, with one option for each address) would not work well. So the mechanism should operate on address blocks rather than single values 🧱. A single address can be treated as an address block with just one address.
The DHCP mechanisms are reused to a large degree, including message and option formats, transmission mechanisms, relay infrastructure, and more 🔁. However, a device that only wants to support link-layer address assignment is not required to support full DHCP. In other words, the device may support only assignment of link-layer addresses and not IPv6 addresses or prefixes 🍓.
7. Information Encoding 🎀
A client MUST send an LLADDR option encapsulated in an IA_LL option to specify the link-layer-type and link-layer-len values. For link-layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client sets the link-layer-address field to:
- All zeroes if the client has no hint as to the starting address of the unicast address block. This address has the IEEE 802 individual/group bit set to 0 (individual).
- Any other value to request a specific block of address starting with the specified address.
Encoding information for other link-layer-types may be added in the future by publishing an RFC that specifies those values 🔮.
A client sets the extra-addresses field to either 0 for a single address or the size of the requested address block minus 1 💖.
A client MUST set the valid-lifetime field to 0 (this field MUST be ignored by the server) 🙈.
8. Requesting Addresses 💅
The addresses are assigned in blocks. The smallest block is a single address 🦋. To request an assignment, the client sends a Solicit message with an IA_LL option inside. The IA_LL option MUST contain an LLADDR option, as specified in Section 7.
When the server gets an IA_LL option, it inspects the contents and may offer an address or addresses for each LLADDR option, according to its policy 👀. The server MAY take into consideration the address block the client requested in the LLADDR option. However, the server MAY choose to ignore some or all parameters of the requested address block. In particular, the server may send a different starting address or a smaller number of addresses than requested. The server sends back an Advertise message with an IA_LL option containing an LLADDR option that specifies the addresses being offered. If the server can't provide any addresses, it MUST return the IA_LL option containing a Status Code option (see Section 21.13 of [RFC8415]) with the status set to NoAddrsAvail 💀.
Note that servers that don't support the IA_LL option will ignore it and won't return it in Advertise (and Reply) messages 🙃. Clients that send IA_LL options MUST treat this as if the server returned the NoAddrsAvail status for those IA_LL option(s).
The client waits for available servers to send Advertise responses and picks one server, as defined in Section 18.2.9 of [RFC8415]. Then the client sends a Request message that includes the IA_LL container option, with the LLADDR option copied from the Advertise message sent by the chosen server 🎯.
The client MUST process the address block(s) returned in the Advertise, not what it put in the Solicit message. It may consider the offered address block(s) when selecting which Advertise message to accept. The server may offer a smaller number of addresses, or different addresses from the ones requested. A client MUST NOT use resources returned in an Advertise message, except to select a server and to send the Request message to that server. Resources are only useable by a client when they're returned in a Reply message ⚠️.
When a Request message with the IA_LL container option comes in, the server assigns the requested addresses 📬. The server allocates a block of addresses according to its configured policy. The server MAY assign a different block, or a smaller block size, than requested in the Request message. Then the server generates and sends a Reply message back to the client.
When a client receives a Reply message, it parses the IA_LL container option and may start using all the provided addresses 🥳. It MUST restart its T1 and T2 timers using the values specified in the IA_LL option.
The client MUST use the address block(s) returned in the Reply message, which may be a smaller block(s) or may have different address(es) than requested 🫶.
A client that included a Rapid Commit option in the Solicit message may receive a Reply in response to the Solicit message and skip the Advertise and Request message steps above (see Section 18.2.1 of [RFC8415]) ⚡.
A client that changes its link-layer address on an interface SHOULD follow the recommendations in Section 7.2.6 of [RFC4861] to tell its neighbors about the new link-layer address quickly 📣.
9. Renewing Addresses 🔁
Address renewals follow the normal DHCP renewal processing described in Section 18.2.4 of [RFC8415] 💫. Once the T1 timer elapses, the client starts sending Renew messages with the IA_LL option containing an LLADDR option for the address block being renewed. The server responds with a Reply message that contains the renewed address block. The server MUST NOT shrink or expand the address block. Once a block is assigned and has a non-zero valid lifetime, its size, starting address, and ending address MUST NOT change 🔒.
If the requesting client needs more addresses (for example, in the hypervisor scenario, because addresses need to be assigned to new VMs), it MUST send an IA_LL option with a different Identity Association IDentifier (IAID) to create another "container" for more addresses 🧺.
If the client can't renew before the T2 timer elapses, it starts sending Rebind messages, as described in Section 18.2.5 of [RFC8415] 🥺.
10. Releasing Addresses 👋
The client may decide to release a leased address block. A client MUST release the block in its entirety. A client releases an address block by sending a Release message that includes an IA_LL option containing the LLADDR option for the address block to release. The Release transmission mechanism is described in Section 18.2.7 of [RFC8415] 📤.
Note that if the client is releasing the link-layer address it's using, it MUST stop using that address before sending the Release message (as per [RFC8415]) 🛑. To send the Release message, the client MUST use another address (such as the one originally used to initiate DHCPv6 to provide an allocated link-layer address) 💜.
11. Option Definitions 📝
This mechanism uses an approach similar to the existing mechanisms in DHCP ✨. There is one container option (the IA_LL option) that contains the actual address or addresses, represented by an LLADDR option. Each LLADDR option represents an address block, which is expressed as a first address with a number that specifies how many additional addresses are included 🌸.
11.1. Identity Association for Link-Layer Addresses Option 🎀
okay so the IA_LL option (the Identity Association for Link-Layer Addresses option) is the thing that carries an IA_LL, the parameters that go with it, and the address blocks tied to it. it's giving main character energy 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_LL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_LL-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: IA_LL Option Format 🦋
option-code:OPTION_IA_LL(138) 🌸option-len:12 + length of IA_LL-options fieldIAID: the unique identifier for this IA_LL. the IAID must be unique among the identifiers for all of this client's IA_LLs. the number space for IA_LL IAIDs is separate from the number space for other IA option types (i.e., IA_NA, IA_TA, and IA_PD). it's a 4-octet field containing an unsigned integer.T1: the time interval after which the client should contact the server that the addresses in the IA_LL came from, to extend the valid lifetime of the addresses assigned to the IA_LL. T1 is a time duration relative to the current time, in seconds. it's a 4-octet field containing an unsigned integer.T2: the time interval after which the client should contact any available server to extend the valid lifetime of the addresses assigned to the IA_LL. T2 is also a time duration relative to the current time, in seconds. another 4-octet unsigned integer field.IA_LL-options: options associated with this IA_LL. it's a variable-length field, 12 octets less than the value in theoption-lenfield. ✨
an IA_LL option may only appear in the options area of a DHCP message. a DHCP message can contain multiple IA_LL options (though each one must have a unique IAID) 🧚
the status of any operations involving this IA_LL is shown in a Status Code option (see Section 21.13 of [RFC8415]) inside the IA_LL-options field 📋
ngl, an IA_LL doesn't have its own "lifetime" or "lease length." once the valid lifetimes of all the addresses in an IA_LL have expired, the IA_LL can be considered expired. T1 and T2 are there so servers get explicit control over when a client checks back in about a specific IA_LL 🕰️
in a message a client sends to a server, the T1 and T2 fields MUST be set to 0. the server MUST ignore any values in those fields in messages it receives from a client. 🙅♀️
in a message a server sends to a client, the client MUST use the values in the T1 and T2 fields as its T1 and T2 times, unless those values are 0. the values are the number of seconds until T1 and T2. 💅
as per Section 7.7 of [RFC8415], the value 0xffffffff is taken to mean "infinity" and should be used carefully. ⚠️
the server picks T1 and T2 so the client can extend the lifetimes of any address block in the IA_LL before they expire, even if the server is unavailable for a short while. recommended values for T1 and T2 are .5 and .8 times the shortest valid lifetime of the address blocks in the IA that the server is willing to extend, respectively. if the "shortest" valid lifetime is 0xffffffff ("infinity"), the recommended T1 and T2 values are also 0xffffffff. if the time when the addresses in an IA_LL get renewed is left up to the client, the server sets T1 and T2 to 0. the client MUST follow the rules defined in Section 14.2 of [RFC8415]. 🎯
if a client gets an IA_LL where T1 is greater than T2, and both T1 and T2 are greater than 0, the client throws out the IA_LL option and processes the rest of the message as though the server had never included that invalid IA_LL option. 🗑️
the IA_LL-options field usually contains one or more LLADDR options (see Section 11.2). if a client doesn't include an LLADDR option in a Solicit or Request message, the server MUST treat this as a request for a single address, and that the client has no hint as to which address it would like. 🤷♀️
11.2. Link-Layer Addresses Option 💜
the Link-Layer Addresses option is used to specify an address block associated with an IA_LL. the option must be encapsulated in the IA_LL-options field of an IA_LL option. the LLaddr-options field holds the options that are specific to this address block. 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_LLADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer-type | link-layer-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. link-layer-address .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extra-addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. LLaddr-options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: LLADDR Option Format 🌈
option-code:OPTION_LLADDR(139) 🍓option-len:12 + link-layer-len field value + length of LLaddr-options field. assuming a link-layer-address length of 6 and no extra options, theoption-lenwould be 18. 🔢link-layer-type: the link-layer type MUST be a valid hardware type assigned by IANA, as described in [RFC5494], and registered in the "Hardware Types" registry athttps://www.iana.org/assignments/arp-parameters. it's a 2-octet field containing an unsigned integer. 🪪link-layer-len: specifies the length, in octets, of thelink-layer-addressfield (typically 6 for a link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)). this is so link layers with variable-length addresses can fit too. it's a 2-octet field containing an unsigned integer. 📏link-layer-address: specifies the address of the first link-layer address that's being requested or assigned, depending on the message. a client MAY send a special value to request any address. for link-layer types 1 and 6, see Section 7 for details on this field. it's a field oflink-layer-lenoctets containing an address. 🫶extra-addresses: specifies how many additional addresses follow the address given inlink-layer-address. for a single address, 0 is used. for example,link-layer-address02:04:06:08:0a andextra-addresses3 designate a block of four addresses, starting at 02:04:06:08:0a and ending at 02:04:06:08:0d (inclusive). it's a 4-octet field containing an unsigned integer. 🧮valid-lifetime: the valid lifetime for the address(es) in the option, in seconds. it's a 4-octet field containing an unsigned integer. ⏳LLaddr-options: any encapsulated options specific to this particular address block. right now there are no such options defined, but there may be in the future. 🔮
in a message a client sends to a server, the valid-lifetime field MUST be set to 0. the server MUST ignore any received value. 🙅♀️
in a message a server sends to a client, the client MUST use the value in the valid-lifetime field as the valid lifetime for the address block. the value is the number of seconds remaining in the lifetime. ⏰
as per Section 7.7 of [RFC8415], the valid lifetime of 0xffffffff is taken to mean "infinity" and should be used carefully. 💀
more than one LLADDR option can appear in an IA_LL option. 👯♀️
12. Selecting Link-Layer Addresses for Assignment to an IA_LL ✨
a server picks link-layer addresses to assign to an IA_LL according to the assignment policies set by the server administrator and the requirements of that address space. it's all about the rules, bestie 📜
link-layer addresses are typically specific to a link, so the server SHOULD follow the steps in Section 13.1 of [RFC8415] to figure out the client's link. 🗺️
for IEEE 802 MAC addresses (see [IEEEStd802] as amended by [IEEEStd802c]):
- server administrators SHOULD follow the IEEE 802 Specifications for the unicast address pools they make available for assignment (see Appendix A and [IEEEStd802c]). only address space reserved for local use, or address space with the authorization of the assignee, may be used. 🔐
- servers MUST NOT allow administrators to configure address pools that would cross the boundary of 2^(42) bits (for 48-bit MAC addresses). this avoids problems with changes in the first octet of the address and the special bits in it (see Appendix A). clients MUST reject assignments where the assigned block would cross this boundary (they MUST decline the allocation -- see Section 18.2.8 of [RFC8415]). 🚫
- a server MAY use options supplied by a relay agent or client to select the quadrant (see Appendix A) that addresses get assigned from. this MAY include options like those specified in [RFC8948]. 🧩
13. IANA Considerations 📝
okay so IANA is the registry keeper, and they've officially handed out two new option codes for us 🎀 Both live in the "Option Codes" subregistry of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry, which is maintained at http://www.iana.org/assignments/dhcpv6-parameters. Here's the paperwork:
Value: 138
Description: OPTION_IA_LL
Client ORO: No
Singleton Option: No
Reference: RFC 8947Value: 139
Description: OPTION_LLADDR
Client ORO: No
Singleton Option: No
Reference: RFC 894714. Security Considerations 💀
this section is serious, bestie, so pay attention 🫶 For the general DHCP security stuff, go read Section 22 of [RFC8415] and Section 23 of [RFC7227]. For IPv6 security, check out [RFC8200].
As discussed in Section 22 of [RFC8415]:
DHCP lacks end-to-end encryption between clients and servers; thus, hijacking, tampering, and eavesdropping attacks are all possible as a result.
In some network environments, it is possible to secure them, as discussed later in Section 22 of [RFC8415].
Now here's the messy part 😭 If not every party on a link uses this mechanism to get an address from the space the DHCP server handed out, the same link-layer address could end up being used by more than one device. And honestly, this would be possible on those networks even without DHCP in the picture, so it's not the mechanism's fault, it's the network being chaotic 💅
Server implementations SHOULD consider configuration options to limit the maximum number of addresses to allocate (both in a single request and in total) to a client. Just know that this doesn't stop a bad client actor from pretending to be many different clients and grabbing every available address 💀 So it's a helpful guardrail, not a full shield.
15. Privacy Considerations 🙈
the privacy section is giving "who's watching" energy 👀 For the general DHCP privacy stuff, see Section 23 of [RFC8415].
When a client asks a server directly for a link-layer address, the address it gets will most likely be used by that client to talk on the link. That means the address is exposed to anyone who can listen in on that communication. Peers on the link who can also listen in on the DHCP exchange could match the client's identity (based on the DUID being used) with the assigned address. Ngl that's a lot of exposure. If you want to minimize what gets revealed, the mechanisms described in [RFC7844] can help improve anonymity.
As discussed in Section 23 of [RFC8415], DHCP servers and hypervisors may need to consider the implications of assigning addresses sequentially. Though in general, this is only of link-local concern, unlike IPv6 address assignment and prefix delegation, since those may be used for communication over the Internet 🌐
16. References 📚
16.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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.16.2. Informative References
[IEEE-P802.1CQ-Project]
IEEE, "P802.1CQ - Standard for Local and Metropolitan Area
Networks: Multicast and Local Address Assignment",
<https://standards.ieee.org/project/802_1CQ.html>.
[IEEEStd802]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks: Overview and Architecture, IEEE Std 802", IEEE
STD 802-2014, DOI 10.1109/IEEESTD.2014.6847097,
<https://doi.org/10.1109/IEEESTD.2014.6847097>.
[IEEEStd802.11]
IEEE, "IEEE Standard for Information technology--
Telecommunications and information exchange between
systems Local and metropolitan area networks--Specific
requirements - Part 11: Wireless LAN Medium Access Control
(MAC) and Physical Layer (PHY) Specifications", IEEE Std
802.11, DOI 10.1109/IEEESTD.2016.7786995,
<https://doi.org/10.1109/IEEESTD.2016.7786995>.
[IEEEStd802c]
IEEE, "IEEE Standard for Local and Metropolitan Area
Networks:Overview and Architecture--Amendment 2: Local
Medium Access Control (MAC) Address Usage", IEEE Std 802c-
2017, DOI 10.1109/IEEESTD.2017.8016709,
<https://doi.org/10.1109/IEEESTD.2017.8016709>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<https://www.rfc-editor.org/info/rfc2464>.
[RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD)
for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006,
<https://www.rfc-editor.org/info/rfc4429>.
[RFC5494] Arkko, J. and C. Pignataro, "IANA Allocation Guidelines
for the Address Resolution Protocol (ARP)", RFC 5494,
DOI 10.17487/RFC5494, April 2009,
<https://www.rfc-editor.org/info/rfc5494>.
[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,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity
Profiles for DHCP Clients", RFC 7844,
DOI 10.17487/RFC7844, May 2016,
<https://www.rfc-editor.org/info/rfc7844>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8948] Bernardos, CJ. and A. Mourad, "Structured Local Address
Plan (SLAP) Quadrant Selection Option for DHCPv6",
RFC 8948, DOI 10.17487/RFC8948, December 2020,
<https://www.rfc-editor.org/info/rfc8948>.Appendix A. IEEE 802c Summary 🧚
this appendix is a quick summary of IEEE 802c [IEEEStd802c], and it's a whole vibe 🦋
The original IEEE 802 specs set aside half of the 48-bit MAC address space for local use. These addresses have the U/L bit set to 1, and they're locally administered with no imposed structure.
In 2017, the IEEE released the IEEE Std 802c specification, which defines a new optional "Structured Local Address Plan (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space". Under this plan there are four SLAP quadrants, and each one uses a different assignment policy 💜
The first octet's Z and Y bits define the quadrant for locally assigned addresses (the X-bit is 1). In IEEE representation, the bits look like this:
LSB MSB
M X Y Z - - - -
| | | |
| | | +------------ SLAP Z-bit
| | +--------------- SLAP Y-bit
| +------------------ X-bit (U/L) = 1 for locally assigned
+--------------------- M-bit (I/G) (unicast/group)
Figure 3: SLAP BitsThe SLAP quadrants are:
+==========+=======+=======+=======================+============+
| Quadrant | Y-bit | Z-bit | Local Identifier Type | Local |
| | | | | Identifier |
+==========+=======+=======+=======================+============+
| 01 | 0 | 1 | Extended Local | ELI |
+----------+-------+-------+-----------------------+------------+
| 11 | 1 | 1 | Standard Assigned | SAI |
+----------+-------+-------+-----------------------+------------+
| 00 | 0 | 0 | Administratively | AAI |
| | | | Assigned | |
+----------+-------+-------+-----------------------+------------+
| 10 | 1 | 0 | Reserved | Reserved |
+----------+-------+-------+-----------------------+------------+
Table 1: SLAP QuadrantsMAC addresses derived from an Extended Local Identifier (ELI) are based on an assigned Company ID (CID), which is 24 bits (including the M, X, Y, and Z bits) for 48-bit MAC addresses. That leaves 24 bits for the locally assigned address for each CID, for unicast (M-bit = 0) and also for multicast (M-bit = 1). The IEEE Registration Authority (RA) assigns the CID.
MAC addresses derived from a Standard Assigned Identifier (SAI) are assigned by a protocol specified in an IEEE 802 standard. For 48-bit MAC addresses, 44 bits are available. Multiple protocols for assigning SAIs may be specified in IEEE standards. Coexistence of multiple protocols may be supported by limiting the subspace each protocol can assign from.
MAC addresses derived from an Administratively Assigned Identifier (AAI) are assigned locally, and administrators manage the space as needed. Heads up, though: multicast IPv6 packets [RFC2464] use a destination address starting in 33-33, so AAI addresses in that range should not be assigned 🙈 For 48-bit MAC addresses, 44 bits are available.
The last quadrant is reserved for future use. It may also be used similarly to AAI space, but administrators should be aware that future specifications may define alternate uses that could be incompatible.
Acknowledgments 🫶
thank you to the DHC Working Group participants who reviewed this document and gave comments and support 💖 Special thanks to Ian Farrer for his thorough reviews and for shepherding this document through the IETF process 👑 Thanks also to the directorate reviewers Samita Chakrabarti, Roni Even, and Tianran Zhou, and to the IESG members Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry Leiba, Alvaro Retana, Éric Vyncke, and Robert Wilton for their suggestions. And thanks to Roger Marks, Robert Grow, and Antonio de la Oliva for their comments related to IEEE work and references 🌸
Authors' Addresses 🎀
Bernie Volz
Cisco Systems, Inc.
300 Beaver Brook Rd
Boxborough, MA 01719
United States of America
Email: volz@cisco.com
Tomek Mrugalski
Internet Systems Consortium, Inc.
PO Box 360
Newmarket, NH 03857
United States of America
Email: tomasz.mrugalski@gmail.com
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/📦 where this page comes from
- ietf: rfc8947 2020-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms