rfc8947xml2.original.xml   rfc8947.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc strict="yes" ?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"
<?rfc toc="yes"?> docName="draft-ietf-dhc-mac-assign-09" number="8947" updates=""
<?rfc tocdepth="4"?> obsoletes="" submissionType="IETF" consensus="true" xml:lang="en"
<?rfc symrefs="yes"?> tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc sortrefs="yes" ?> <!-- xml2rfc v2v3 conversion 3.0.0 -->
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-dhc-mac-assign-09">
<front> <front>
<title abbrev="DHCPv6 Link-Layer Address Assignment"> <title abbrev="DHCPv6 Link-Layer Address Assignment">
Link-Layer Addresses Assignment Mechanism for DHCPv6</title> Link-Layer Addresses Assignment Mechanism for DHCPv6</title>
<seriesInfo name="RFC" value="8947"/>
<author fullname="Bernie Volz" initials="B" surname="Volz"> <author fullname="Bernie Volz" initials="B" surname="Volz">
<organization abbrev="Cisco">Cisco Systems, Inc.</organization> <organization abbrev="Cisco">Cisco Systems, Inc.</organization>
<address> <address>
<postal> <postal>
<street>1414 Massachusetts Ave</street> <street>300 Beaver Brook Rd</street>
<city>Boxborough, MA 01719</city> <city>Boxborough</city>
<country>USA</country> <region>MA</region>
<code>01719</code>
<country>United States of America</country>
</postal> </postal>
<email>volz@cisco.com</email> <email>volz@cisco.com</email>
</address> </address>
</author> </author>
<author fullname="Tomek Mrugalski" initials="T." surname="Mrugalski">
<author fullname="Tomek Mrugalski" initials="T."
surname="Mrugalski">
<organization abbrev="ISC">Internet Systems Consortium, <organization abbrev="ISC">Internet Systems Consortium,
Inc.</organization> Inc.</organization>
<address> <address>
<postal> <postal>
<street>950 Charter Street</street> <street>PO Box 360</street>
<city>Redwood City</city> <city>Newmarket</city>
<region>CA</region> <region>NH</region>
<code>94063</code> <code>03857</code>
<country>USA</country> <country>United States of America</country>
</postal> </postal>
<email>tomasz.mrugalski@gmail.com</email> <email>tomasz.mrugalski@gmail.com</email>
</address> </address>
</author> </author>
<author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos"> <author fullname="Carlos J. Bernardos" initials="CJ." surname="Bernardos">
<organization abbrev="UC3M">Universidad Carlos III de <organization abbrev="UC3M">Universidad Carlos III de
Madrid</organization> Madrid</organization>
<address> <address>
<postal> <postal>
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes, Madrid</city>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
skipping to change at line 59 skipping to change at line 54
<street>Av. Universidad, 30</street> <street>Av. Universidad, 30</street>
<city>Leganes, Madrid</city> <city>Leganes, Madrid</city>
<code>28911</code> <code>28911</code>
<country>Spain</country> <country>Spain</country>
</postal> </postal>
<phone>+34 91624 6236</phone> <phone>+34 91624 6236</phone>
<email>cjbc@it.uc3m.es</email> <email>cjbc@it.uc3m.es</email>
<uri>http://www.it.uc3m.es/cjbc/</uri> <uri>http://www.it.uc3m.es/cjbc/</uri>
</address> </address>
</author> </author>
<date month="November" year="2020"/>
<date year="2020"/>
<area>Internet</area> <area>Internet</area>
<workgroup>Dynamic Host Configuration (DHC)</workgroup> <workgroup>Dynamic Host Configuration (DHC)</workgroup>
<keyword>DHCPv6</keyword> <keyword>DHCPv6</keyword>
<keyword>DHCP</keyword> <keyword>DHCP</keyword>
<keyword>Link-layer</keyword> <keyword>Link-layer</keyword>
<keyword>assignment</keyword> <keyword>assignment</keyword>
<!-- SECTION 0: Abstract -->
<abstract> <abstract>
<t>In certain environments, e.g., large scale virtualization <t>In certain environments, e.g., large-scale virtualization
deployments, new devices are created in an automated manner. Such deployments, new devices are created in an automated manner. Such
devices may have their link-layer addresses assigned in an automated devices may have their link-layer addresses assigned in an automated
fashion. With sufficient scale, the likelihood of a collision using fashion. With sufficient scale, the likelihood of a collision using
random assignment without duplication detection is not acceptable. random assignment without duplication detection is not
Therefore an allocation mechanism is required. This draft proposes acceptable.
Therefore, an allocation mechanism is required. This document proposes
an extension to DHCPv6 that allows a scalable approach to link-layer an extension to DHCPv6 that allows a scalable approach to link-layer
address assignments address assignments
where preassigned link-layer address assignments (such as by a where preassigned link-layer address assignments (such as by a
manufacturer) are not possible or unnecessary.</t> manufacturer) are not possible or are unnecessary.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="intro" title="Introduction"> <section anchor="intro">
<!-- 1, line 230--> <name>Introduction</name>
<t>There are several deployment types that deal with a large number <t>There are several deployment types that deal with a large number
of devices that need to be initialized. One of them is a scenario of devices that need to be initialized. One of them is a scenario
where virtual machines (VMs) are created on a massive scale. where virtual machines (VMs) are created on a massive scale.
Typically the new VM instances are assigned a link-layer address, Typically, the new VM instances are assigned a link-layer address,
but random assignment does not scale well due to the risk of but random assignment does not scale well due to the risk of a collision
a collision (see Appendix A.1 of <xref target="RFC4429"/>). Another (see <xref target="RFC4429" sectionFormat="of" section="A.1"/>). Another
use case is IoT (Internet of Things) devices (see use case is Internet of Things (IoT) devices (see
<xref target="RFC7228"/>). The huge number of such devices could <xref target="RFC7228"/>). The huge number of such devices could
strain the IEEE's available OUI (Organizationally Unique Identifier) strain the IEEE's available Organizationally Unique Identifier (OUI)
global address space. While there is typically no need to provide global address space. While there is typically no need to provide
global link-layer address uniqueness for such devices, a link-layer global link-layer address uniqueness for such devices, a link-layer
assignment mechanism allows for conflicts to be avoided assignment mechanism allows for conflicts to be avoided
inside an administrative domain. For those reasons, it is desired to inside an administrative domain. For those reasons, it is desired to
have some form of mechanism that would be able to assign locally have some form of mechanism that would be able to assign locally
unique MAC (media access control) addresses.</t> unique Media Access Control (MAC) addresses.</t>
<t>This document proposes a new mechanism that extends DHCPv6 <t>This document proposes a new mechanism that extends DHCPv6
operation to handle link-layer address assignments.</t> operation to handle link-layer address assignments.</t>
<t>Since DHCPv6 (<xref target="RFC8415"/>) is a protocol <t>Since DHCPv6 <xref target="RFC8415"/> is a protocol
that can allocate various types of resources (non-temporary that can allocate various types of resources (non-temporary
addresses, temporary addresses, prefixes, as well as many options) addresses, temporary addresses, prefixes, as well as many options)
and has the necessary infrastructure to maintain such allocations and has the necessary infrastructure to maintain such allocations
(numerous server and client implementations, large deployed (numerous server and client implementations, large deployed
relay infrastructure, and supportive solutions such as leasequery relay infrastructure, and supportive solutions such as leasequery
and failover), it is a good candidate to address the desired and failover), it is a good candidate to address the desired
functionality.</t> functionality.</t>
<t>While this document presents a design that should be usable for <t>While this document presents a design that should be usable for
any link-layer address type, some of the details are specific to any link-layer address type, some of the details are specific to
IEEE 802 48-bit MAC addresses <xref target="IEEEStd802"/>. Future IEEE 802 48-bit MAC addresses <xref target="IEEEStd802"/>. Future
documents may provide specifics for other link-layer address documents may provide specifics for other link-layer address
types.</t> types.</t>
<t>IEEE 802 originally set aside half of the 48-bit MAC address <t>IEEE 802 originally set aside half of the 48-bit MAC address
space for local use (where the U/L bit is set to 1). In 2017, space for local use (where the Universal/Local (U/L) bit is set to 1). In 2017,
IEEE published an amendment <xref target="IEEEStd802c"/> that IEEE published an amendment <xref target="IEEEStd802c"/> that
divides this space into quadrants with differentied address rules. divides this space into quadrants with differentiated address rules.
More details are in <xref target="IEEE802cSummary"/>.</t> More details are in <xref target="IEEE802cSummary"/>.</t>
<t>IEEE is also developing protocols and procedures for <t>IEEE is also developing protocols and procedures for
assignment of locally unique addresses (IEEE 802.1CQ). This work may assignment of locally unique addresses (IEEE 802.1CQ). This work may
serve as an alternative protocol for assignment. For additional serve as an alternative protocol for assignment. For additional
background, see <xref target="IEEE-P802.1CQ-Project"/>.</t> background, see <xref target="IEEE-P802.1CQ-Project"/>.</t>
</section> </section>
<section anchor="requirements">
<section anchor="requirements" title="Requirements"> <name>Requirements Language</name>
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <t>
NOT", The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
"OPTIONAL" in this document are to be interpreted as described in NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
BCP 14 <xref target="RFC2119"/> <xref target="RFC8174" /> when, and RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
only when, they appear in all capitals, as shown here.</t> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="terminology">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The DHCP terminology relevant to this specification from <t>The DHCP terminology relevant to this specification from
<xref target="RFC8415"/> applies here. The following definitions <xref target="RFC8415"/> applies here. The following definitions
either modify those definitions as to how they are used in this either modify those definitions as to how they are used in this
document or define new terminology used herein.</t> document or define new terminology used herein.</t>
<dl newline="false" spacing="normal" indent="16">
<t> <dt>address</dt>
<list hangIndent="14" style="hanging"> <dd>Unless specified otherwise, a link-layer (or MAC) address, as specif
<t hangText="address">Unless specified otherwise, an address ied in
means a link-layer (or MAC) address, as specified in
<xref target="IEEEStd802"/>. The <xref target="IEEEStd802"/>. The
address is typically six octets long, but some network address is typically six octets long, but some network
architectures may use different lengths.</t> architectures may use different lengths.</dd>
<dt>address block</dt>
<t hangText="address block">A number of consecutive link-layer <dd>A number of consecutive link-layer
addresses. An address block is expressed as a first address addresses. An address block is expressed as a first address
plus a number that designates the number of additional (extra) plus a number that designates the number of additional (extra)
addresses. A single address can be represented by the address addresses. A single address can be represented by the address
itself and zero extra addresses.</t> itself and zero extra addresses.</dd>
<dt>client</dt>
<t hangText="client">A node that is interested in obtaining <dd>A node that is interested in obtaining
link-layer addresses. It implements the basic DHCP mechanisms link-layer addresses. It implements the basic DHCP mechanisms
needed by a DHCP needed by a DHCP
client as described in <xref target="RFC8415"/> and client, as described in <xref target="RFC8415"/>, and
supports the new options (IA_LL and LLADDR, see below) specified supports the new options specified in this document (IA_LL and LLADDR)
in this document. The client may or may not support IPv6 . The client may or may not support IPv6
address assignment and prefix delegation as specified in address assignment and prefix delegation, as specified in
<xref target="RFC8415"/>.</t> <xref target="RFC8415"/>.</dd>
<dt>IA_LL</dt>
<t hangText="IA_LL">Identity Association for Link-Layer Address: <dd>Identity Association for Link-Layer Address,
an identity association (IA) used to request or assign an identity association (IA) used to request or assign
link-layer addresses. See <xref target="IA_LL"/> for details on link-layer addresses. See <xref target="IA_LL"/> for details on
the IA_LL option.</t> the IA_LL option.</dd>
<dt>LLADDR</dt>
<t hangText="LLADDR">Link-layer address option that is used to <dd>Link-layer address option that is used to
request or assign a block of link-layer addresses. See request or assign a block of link-layer addresses. See
<xref target="LLADDR"/> for details on the LLADDR option.</t> <xref target="LLADDR"/> for details on the LLADDR option.</dd>
<dt>server</dt>
<t hangText="server">A node that manages link-layer address allocation <dd>A node that manages link-layer address allocation
and is able to respond to client queries. It implements basic DHCP and is able to respond to client queries. It implements basic DHCP
server functionality as described in <xref target="RFC8415"/> and server functionality, as described in <xref target="RFC8415"/>, and
supports the new options supports the new options specified in this document
(IA_LL and LLADDR) specified in this document. The server may or (IA_LL and LLADDR). The server may or
may not support IPv6 address assignment and prefix delegation as may not support IPv6 address assignment and prefix delegation as
specified in <xref target="RFC8415"/>.</t> specified in <xref target="RFC8415"/>.</dd>
</dl>
</list>
</t>
</section> </section>
<section anchor="overview">
<section anchor="overview" title="Deployment scenarios and mechanism overvie <name>Deployment Scenarios</name>
w">
<t>This mechanism is designed to be generic and usable in many <t>This mechanism is designed to be generic and usable in many
deployments, but there are two scenarios it attempts to address in deployments, but there are two scenarios it attempts to address in
particular: (i) proxy client mode, and (ii) direct client mode.</t> particular: (i) proxy client mode and (ii) direct client mode.</t>
<section anchor="proxy">
<section anchor="proxy" title="Proxy client mode scenario"> <name>Scenario: Proxy Client Mode</name>
<t>This mode is used when an entity acts as a DHCP client and requests
available DHCP servers to assign one or more addresses (an address block
),
to be then assigned for use by the final end-devices. Large-scale
virtualization is one application scenario for proxy client mode. In suc
h
environments this entity is often called a hypervisor and is frequently
required to spawn new VMs. The hypervisor needs to assign new addresses
to
those machines. The hypervisor does not use those addresses for itself,
but
rather uses them to create new VMs with appropriate addresses. It is
worth pointing out the cumulative nature of this scenario. Over time, th
e
hypervisor is likely to increase its address usage. Some obsolete VMs
will be deleted and their addresses are potentially eligible for reuse f
or new VMs.</t>
<t>This mode is used when an entity acts as a DHCP client that
requests that available DHCP servers assign one or more
addresses (an address block) for the DHCP client to then
assign to the final end devices to use. Large-scale virtualization is one
application scenario for proxy client mode. In such
environments, this entity is often called a "hypervisor" and is
frequently required to spawn new VMs. The hypervisor needs to
assign new addresses to those machines. The hypervisor does
not use those addresses for itself, but rather it uses them to
create new VMs with appropriate addresses. It is worth
pointing out the cumulative nature of this scenario. Over
time, the hypervisor is likely to increase its address
use. Some obsolete VMs will be deleted; their addresses
are potentially eligible for reuse by new VMs.</t>
</section> </section>
<section anchor="direct">
<section anchor="direct" title="Direct client mode scenario"> <name>Scenario: Direct Client Mode</name>
<t>This mode can be used when an entity acts as a DHCP client that
<t>This mode can be used when an entity acts as a DHCP client and requests that available DHCP servers assign one or more addresses
requests available DHCP servers to assign one or more addresses (an address block) for its own use. This usage scenario is related to
(an address block) for its use. This usage scenario is related to IoT (see <xref target="intro"/>). Upon first
IoT, as described earlier (see <xref target="intro"/>). Upon first boot, for each interface, the device uses a temporary address, as
boot, for each interface the device uses a temporary address, as described in <xref target="IEEEStd802.11"/> and
described in <xref target="IEEEStd802.11"/> or to be described in
IEEE 802.1CQ <xref target="IEEE-P802.1CQ-Project"/>, to send IEEE 802.1CQ <xref target="IEEE-P802.1CQ-Project"/>, to send
initial DHCP packets to available DHCP servers wherein the device initial DHCP packets to available DHCP servers wherein the device
requests a single address for that network interface. Once the requests a single address for that network interface. Once the
server assigns an address, the device abandons its server assigns an address, the device abandons its
temporary address and uses the assigned (leased) address.</t> temporary address and uses the assigned (leased) address.</t>
<t>Note that a client that operates as above that does not have a <t>Note that a client that operates as above that does not have a
globally unique link-layer address on any of its interfaces MUST globally unique link-layer address on any of its interfaces <bcp14>MUST
NOT use a link-layer based DUID (DHCP Unique Identifier). For more NOT</bcp14> use a link-layer-based DHCP Unique Identifier (DUID). For mo
details, refer to Section 11 of <xref target="RFC8415"/>.</t> re
details, refer to <xref target="RFC8415" sectionFormat="of"
section="11"/>.</t>
<t>Also, a client that operates as above may run into issues if <t>Also, a client that operates as above may run into issues if
the switch it is connected to prohibits or restricts link-layer the switch it is connected to prohibits or restricts link-layer
address changes. This may limit where this capability can be used, address changes. This may limit where this capability can be used
or may require the administrator to adjust the configuration of or may require the administrator to adjust the configuration of
the switch(es) to allow a change in address.</t> the switch(es) to allow a change in address.</t>
</section> </section>
</section>
<section anchor="mechanism">
<name>Mechanism Overview</name>
<section anchor="mechanism" title="Mechanism Overview"> <t>In the scenarios described in <xref target="overview"/>, the protocol
operates in fundamentally the
same way.
<t>In all scenarios the protocol operates in fundamentally the The device requesting an address, acting as a DHCP
same way. The device requesting an address, acting as a DHCP client, will send a Solicit message with an IA_LL option to all
client, will send a Solicit message with a IA_LL option to all available DHCP servers. That IA_LL option <bcp14>MUST</bcp14> include an
available DHCP servers. That IA_LL option MUST include a LLADDR LLADDR
option specifying the link-layer-type and option specifying the link-layer-type and
link-layer-len and may include a specific address or address link-layer-len, and it may include a specific address or address
block as a hint for the server. Each available server responds block as a hint for the server. Each available server responds
with either a Reply message with committed address(es) (if Rapid with either a Reply message with committed address(es) (if Rapid
Commit was requested and honored) or an Advertise message with Commit was requested and honored) or an Advertise message with
offered address(es). The client selects a server's response as offered address(es). The client selects a server's response, as
governed by <xref target="RFC8415"/>. If necessary, the client governed by <xref target="RFC8415"/>. If necessary, the client
sends a Request message and the target server will then assign the sends a Request message; the target server will then assign the
address(es) and send a Reply message. Once a Reply is received, address(es) and send a Reply message. Once a Reply is received,
the client can start using those address(es).</t> the client can start using those address(es).</t>
<t>Normal DHCP mechanisms are in use. The client is expected to <t>Normal DHCP mechanisms are in use. The client is expected to
periodically renew the addresses as governed by T1 and T2 timers periodically renew the addresses as governed by T1 and T2 timers
and stop using the address once the valid lifetime expires. and to stop using the address once the valid lifetime expires.
Renewals can be administratively disabled by the server Renewals can be administratively disabled by the server
sending "infinity" as the T1 and T2 values (see Section 7.7 of sending "infinity" as the T1 and T2 values (see <xref target="RFC8415"
<xref target="RFC8415"/>). An administrator may make the address sectionFormat="of" section="7.7"/>). An administrator may make the
assignment permanent by specifying use of the "infinity" valid address assignment permanent by specifying use of the "infinity" valid
lifetime, as defined in Section 7.7 of lifetime, as defined in <xref target="RFC8415" sectionFormat="of"
<xref target="RFC8415"/>.</t> section="7.7"/>.</t>
<t>The client can release addresses when they are no longer <t>The client can release addresses when they are no longer
needed by sending a Release message (see Section 18.2.7 needed by sending a Release message (see <xref target="RFC8415"
of <xref target="RFC8415"/>).</t> sectionFormat="of" section="18.2.7"/>).</t>
<t>Figure 9 in <xref target="RFC8415"/> shows <t>Figure 9 in <xref target="RFC8415"/> shows
a timeline diagram of the messages exchanged between a client and a timeline diagram of the messages exchanged between a client and
two servers for the typical lifecycle of one or more leases.</t> two servers for the typical life cycle of one or more leases.</t>
<t>Confirm and Information-request messages are not used in
<t>Confirm and Information-Request messages are not used in
link-layer address assignment. Decline should technically link-layer address assignment. Decline should technically
never be needed, but see <xref target="selecting-addresses"/> for never be needed, but see <xref target="selecting-addresses"/> for
one situation where this message is needed.</t> one situation where this message is needed.</t>
<t>Clients implementing this mechanism <bcp14>SHOULD</bcp14> use the Rap
<t>Clients implementing this mechanism SHOULD use the Rapid Commit id Commit
option as specified in Section 5.1 and 18.2.1 of option, as specified in Sections <xref target="RFC8415" section="5.1"
<xref target="RFC8415"/> to obtain addresses with a 2-message sectionFormat="bare"/> and <xref target="RFC8415" section="18.2.1"
exchange when possible.</t> sectionFormat="bare"/> of <xref target="RFC8415"/>, to obtain addresses
with a two-message exchange when possible.</t>
<t>Devices supporting this proposal MAY support the reconfigure <t>Devices supporting this proposal <bcp14>MAY</bcp14> support the recon
mechanism, as defined in Section 18.2.11 of figure
<xref target="RFC8415"/>. If supported by both server and client, mechanism, as defined in <xref target="RFC8415" sectionFormat="of"
section="18.2.11"/>. If supported by both server and client,
the reconfigure mechanism allows the administrator to immediately the reconfigure mechanism allows the administrator to immediately
notify clients that the configuration has changed and triggers notify clients that the configuration has changed and triggers
retrieval of relevant changes immediately, rather than after the retrieval of relevant changes immediately, rather than after the
T1 timer elapses. Since this mechanism requires implementation of T1 timer elapses. Since this mechanism requires implementation of
Reconfigure Key Authentication Protocol (See Section 20.4 of Reconfiguration Key Authentication Protocol (see <xref target="RFC8415"
<xref target="RFC8415"/>), small-footprint devices may choose to sectionFormat="of" section="20.4"/>), small-footprint devices may
not support it.</t> choose not to support it.</t>
</section> </section>
</section> <section>
<name>Design Assumptions</name>
<section title="Design Assumptions">
<t>One of the essential aspects of this mechanism is its cumulative <t>One of the essential aspects of this mechanism is its cumulative
nature, especially in the hypervisor scenario. The server-client nature, especially in the hypervisor scenario. The server-client
relationship does not look like other DHCP transactions in the relationship does not look like other DHCP transactions in the
hypervisor scenario. In a typical environment, there would be one hypervisor scenario. In a typical environment, there would be one
server and a rather small number of hypervisors, possibly server and a rather small number of hypervisors, possibly
even only one. However, over time the number of addresses requested even only one. However, over time, the number of addresses requested
by the hypervisor(s) will increase as more VMs are spawned.</t> by the hypervisor(s) will increase as more VMs are spawned.</t>
<t>Another aspect crucial for efficient design is the observation <t>Another aspect crucial for efficient design is the observation
that a single client acting as hypervisor will likely use thousands that a single client acting as hypervisor will likely use thousands
of addresses. An approach similar to what is used for IPv6 of addresses. An approach similar to what is used for IPv6
address or prefix assignment (IA container with all assigned address or prefix assignment (IA container with all assigned
addresses listed, one option for each address) would not work well. addresses listed, one option for each address) would not work well.
Therefore the mechanism should operate on address blocks, rather Therefore, the mechanism should operate on address blocks rather
than single values. A single address can be treated as an address than single values. A single address can be treated as an address
block with just one address.</t> block with just one address.</t>
<t>The DHCP mechanisms are reused to a large degree, including message
<t>The DHCP mechanisms are reused to large degree, including message and option formats, transmission mechanisms, relay infrastructure,
and option formats, transmission mechanisms, relay infrastructure
and others. However, a device wishing to support only link-layer and others. However, a device wishing to support only link-layer
address assignment is not required to support full DHCP. In other address assignment is not required to support full DHCP. In other
words, the device may support only assignment of link-layer words, the device may support only assignment of link-layer
addresses, but not IPv6 addresses or prefixes.</t> addresses but not IPv6 addresses or prefixes.</t>
</section> </section>
<section anchor="Information-Encoding">
<section anchor="Information-Encoding" title="Information Encoding"> <name>Information Encoding</name>
<t>A client MUST send a LLADDR option encapsulated in an IA_LL <t>A client <bcp14>MUST</bcp14> send an LLADDR option encapsulated in an I
A_LL
option to specify the link-layer-type and link-layer-len values. For 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 link-layer-type 1 (Ethernet) and 6 (IEEE 802 Networks), a client
sets the link-layer-address field to: sets the link-layer-address field to:
</t>
<list hangIndent="4" style="hanging"> <ol spacing="normal" type="1">
<t hangText="1.">All zeroes if the client has <li>All zeroes if the client has
no hint as to the starting address of the unicast address block. no hint as to the starting address of the unicast address block.
This address has the IEEE 802 individual/group bit set to 0 This address has the IEEE 802 individual/group bit set to 0
(individual). (individual).
</t> </li>
<li>Any other value to request a specific block of
<t hangText="2.">Any other value to request a specific block of address starting with the specified address.
address starting with the specified address<!-- (this may be a </li>
unicast or multicast address).--> </ol>
</t>
</list>
</t>
<t>Encoding information for other link-layer-types may be added in <t>Encoding information for other link-layer-types may be added in
the future by publishing an RFC that specifies those values.</t> the future by publishing an RFC that specifies those values.</t>
<t>A client sets the extra-addresses field to either 0 for a single <t>A client sets the extra-addresses field to either 0 for a single
address or the size of the requested address block minus 1.</t> address or the size of the requested address block minus 1.</t>
<t>A client <bcp14>MUST</bcp14> set the valid-lifetime field to 0 (this fi
<t>A client MUST set the valid-lifetime field to 0 (this field eld
MUST be ignored by the server).</t> <bcp14>MUST</bcp14> be ignored by the server).</t>
</section> </section>
<section>
<section title="Requesting Addresses"> <name>Requesting Addresses</name>
<t>The addresses are assigned in blocks. The smallest block is a <t>The addresses are assigned in blocks. The smallest block is a
single address. To request an assignment, the client sends a Solicit single address. To request an assignment, the client sends a Solicit
message with an IA_LL option in the message. The IA_LL option MUST message with an IA_LL option inside. The IA_LL option <bcp14>MUST</bcp14>
contain a LLADDR option as specified in contain an LLADDR option, as specified in
<xref target="Information-Encoding"/>.</t> <xref target="Information-Encoding"/>.</t>
<t>The server, upon receiving an IA_LL option, inspects its content <t>The server, upon receiving an IA_LL option, inspects its content
and may offer an address or addresses for each LLADDR option and may offer an address or addresses for each LLADDR option
according to its policy. The server MAY take into consideration the according to its policy. The server <bcp14>MAY</bcp14> take into considera tion the
address block requested by the client in the LLADDR option. However, address block requested by the client in the LLADDR option. However,
the server MAY choose to ignore some or all parameters of the the server <bcp14>MAY</bcp14> choose to ignore some or all parameters of t
requested address block. In particular, the server may send a he
different starting address than requested, or a smaller number of requested address block. In particular, the server may send
either a
different starting address or a smaller number of
addresses than requested. The server sends back an Advertise addresses than requested. The server sends back an Advertise
message with an IA_LL option containing an LLADDR option that message with an IA_LL option containing an LLADDR option that
specifies the addresses being offered. If the server is unable to specifies the addresses being offered. If the server is unable to
provide any addresses it MUST return the IA_LL option containing a provide any addresses, it <bcp14>MUST</bcp14> return the IA_LL option cont
Status Code option (see Section 21.13 of <xref target="RFC8415"/>) aining a
with status set to NoAddrsAvail.</t> Status Code option (see <xref target="RFC8415" sectionFormat="of"
section="21.13"/>) with status set to NoAddrsAvail.</t>
<t>Note: Servers that do not support the IA_LL option will ignore <t>Note that servers that do not support the IA_LL option will ignore
the option and not return it in Advertise (and Reply) messages. the option and not return it in Advertise (and Reply) messages.
Clients that send IA_LL options MUST treat this as if the server Clients that send IA_LL options <bcp14>MUST</bcp14> treat this as if the s erver
returned the NoAddrsAvail status for these IA_LL option(s). returned the NoAddrsAvail status for these IA_LL option(s).
</t> </t>
<t>The client waits for available servers to send Advertise <t>The client waits for available servers to send Advertise
responses and picks one server as defined in Section 18.2.9 of responses and picks one server, as defined in <xref target="RFC8415"
<xref target="RFC8415"/>. The client then sends a Request sectionFormat="of" section="18.2.9"/>. The client then sends a Request
message that includes the IA_LL container option with the LLADDR message that includes the IA_LL container option with the LLADDR
option copied from the Advertise message sent by the chosen option copied from the Advertise message sent by the chosen
server.</t> server.</t>
<t>The client MUST process the address block(s) returned in the <t>The client <bcp14>MUST</bcp14> process the address block(s) returned in
Advertise, rather than what it included in the Solicit, and may the
consider the offered address block(s) in selecting the Advertise to Advertise, rather than what it included in the Solicit message, and may
consider the offered address block(s) in selecting the Advertise
message to
accept. The server may offer a smaller number of addresses or accept. The server may offer a smaller number of addresses or
different addresses from those requested. A client MUST NOT use different addresses from those requested. A client <bcp14>MUST NOT</bcp14> use
resources returned in an Advertise message except to select a server resources returned in an Advertise message except to select a server
and in sending the Request to that server; resources are only and in sending the Request message to that server; resources are only
useable by a client when returned in a Reply message.</t> useable by a client when returned in a Reply message.</t>
<t>Upon reception of a Request message with the IA_LL container option,
<t>Upon reception of a Request message with IA_LL container option,
the server assigns the requested addresses. The server allocates a the server assigns the requested addresses. The server allocates a
block of addresses according to its configured policy. The server block of addresses according to its configured policy. The server
MAY assign a different block or smaller block size than requested in <bcp14>MAY</bcp14> assign a different block or smaller block size than req uested in
the Request message. The server then generates and sends a Reply the Request message. The server then generates and sends a Reply
message back to the client.</t> message back to the client.</t>
<t>Upon receiving a Reply message, the client parses the IA_LL <t>Upon receiving a Reply message, the client parses the IA_LL
container option and may start using all provided addresses. It MUST container option and may start using all provided addresses. It <bcp14>MUS T</bcp14>
restart its T1 and T2 timers using the values specified in the IA_LL restart its T1 and T2 timers using the values specified in the IA_LL
option.</t> option.</t>
<t>The client <bcp14>MUST</bcp14> use the address block(s) returned in the
<t>The client MUST use the address block(s) returned in the Reply Reply
message, which may be smaller block(s) or with different address(es) message, which may be a smaller block(s) or may have a different address(e
s)
than requested.</t> than requested.</t>
<t>A client that has included a Rapid Commit option in the Solicit <t>A client that has included a Rapid Commit option in the Solicit
may receive a Reply in response to the Solicit and skip the message may receive a Reply in response to the Solicit message and skip th
Advertise and Request steps above (see Section 18.2.1 of e
<xref target="RFC8415"/>).</t> Advertise and Request message steps above (see <xref target="RFC8415"
sectionFormat="of" section="18.2.1"/>).</t>
<t>A client that changes its link-layer address on an interface <t>A client that changes its link-layer address on an interface
SHOULD follow the recommendations in Section 7.2.6 of <bcp14>SHOULD</bcp14> follow the recommendations in <xref
<xref target="RFC4861"/> to inform its neighbors of the new target="RFC4861" sectionFormat="of" section="7.2.6"/> to inform its
link-layer address quickly.</t> neighbors of the new link-layer address quickly.</t>
</section> </section>
<section>
<section title="Renewing Addresses"> <name>Renewing Addresses</name>
<t>Address renewals follow the normal DHCP renewals processing <t>Address renewals follow the normal DHCP renewals processing
described in Section 18.2.4 of <xref target="RFC8415"/>. Once the T1 described in <xref target="RFC8415" sectionFormat="of"
section="18.2.4"/>. Once the T1
timer elapses, the client starts sending Renew messages with the timer elapses, the client starts sending Renew messages with the
IA_LL option containing a LLADDR option for the address block being IA_LL option containing an LLADDR option for the address block being
renewed. The server responds with a Reply message that contains the renewed. The server responds with a Reply message that contains the
renewed address block. The server MUST NOT shrink or expand the renewed address block. The server <bcp14>MUST NOT</bcp14> shrink or expand the
address block. Once a block is assigned and has a non-zero valid address block. Once a block is assigned and has a non-zero valid
lifetime, its size, starting address, and ending address MUST NOT lifetime, its size, starting address, and ending address <bcp14>MUST NOT</ bcp14>
change.</t> change.</t>
<t>If the requesting client needs additional addresses (e.g., in
<t>If the requesting client needs additional addresses -- e.g., in
the hypervisor scenario because addresses need to be assigned to new the hypervisor scenario because addresses need to be assigned to new
VMs -- it MUST send an IA_LL option with a different IAID to create VMs), it <bcp14>MUST</bcp14> send an IA_LL option with a different
Identity Association IDentifier (IAID) to create
another "container" for more addresses.</t> another "container" for more addresses.</t>
<t>If the client is unable to renew before the T2 timer elapses, it
<t>If the client is unable to Renew before the T2 timer elapses, it starts sending Rebind messages, as described in
starts sending Rebind messages as described in Section 18.2.5 of <xref target="RFC8415" sectionFormat="of" section="18.2.5"/>.</t>
<xref target="RFC8415"/>.</t>
</section> </section>
<section>
<section title="Releasing Addresses"> <name>Releasing Addresses</name>
<t>The client may decide to release a leased address block. A client <t>The client may decide to release a leased address block. A client
MUST release the whole block in its entirety. A client releases an <bcp14>MUST</bcp14> release the block in its entirety. A client releases a n
address block by sending a Release message that includes an IA_LL address block by sending a Release message that includes an IA_LL
option containing the LLADDR option for the address block to option containing the LLADDR option for the address block to
release. The Release transmission mechanism is described in Section release. The Release transmission mechanism is described in <xref
18.2.7 of <xref target="RFC8415"/>.</t> target="RFC8415" sectionFormat="of" section="18.2.7"/>.</t>
<t>Note that if the client is releasing the link-layer address it is
<t>Note: If the client is releasing the link-layer address it is using, it <bcp14>MUST</bcp14> stop using this address before sending the
using, it MUST stop using this address before sending the
Release message (as per <xref target="RFC8415"/>). In order to send Release message (as per <xref target="RFC8415"/>). In order to send
the Release message, the client MUST use another address (such as the Release message, the client <bcp14>MUST</bcp14> use another address (s uch as
the one originally used to initiate DHCPv6 to provide an allocated the one originally used to initiate DHCPv6 to provide an allocated
link-layer address).</t> link-layer address).</t>
</section> </section>
<section anchor="option">
<section anchor="option" title="Option Definitions"> <name>Option Definitions</name>
<t>This mechanism uses an approach similar to the existing <t>This mechanism uses an approach similar to the existing
mechanisms in DHCP. There is one container option (the IA_LL option) mechanisms in DHCP. There is one container option (the IA_LL option)
that contains the actual address or addresses, represented by an that contains the actual address or addresses, represented by an
LLADDR option. Each LLADDR option represents an address block, which LLADDR option. Each LLADDR option represents an address block, which
is expressed as a first address with a number that specifies how is expressed as a first address with a number that specifies how
many additional addresses are included.</t> many additional addresses are included.</t>
<section anchor="IA_LL">
<section anchor="IA_LL" <name>Identity Association for Link-Layer Addresses Option</name>
title="Identity Association for Link-Layer Addresses Option"> <t>The Identity Association for Link-Layer Addresses option
(the IA_LL
<t>The Identity Association for Link-Layer Addresses option (IA_LL
option) is used to carry an IA_LL, the parameters option) is used to carry an IA_LL, the parameters
associated with the IA_LL, and the address blocks associated with associated with the IA_LL, and the address blocks associated with
the IA_LL.</t> the IA_LL.</t>
<t>The format of the IA_LL option is:</t>
<t>The format of the IA_LL option is:</t> <figure anchor="ia-ll-syntax">
<name>IA_LL Option Format</name>
<figure align="center" anchor="ia-ll-syntax" <artwork align="left"><![CDATA[
title="IA_LL Option Format">
<artwork align="left"><![CDATA[
0 1 2 3 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 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 | | OPTION_IA_LL | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) | | IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 (4 octets) | | T1 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 (4 octets) | | T2 (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. IA_LL-options . . IA_LL-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="16">
<t> <dt>option-code</dt>
<list hangIndent="16" style="hanging"> <dd>OPTION_IA_LL (138).</dd>
<t hangText="option-code">OPTION_IA_LL (tbd1).</t> <dt>option-len</dt>
<dd>12 + length of IA_LL-options field.</dd>
<t hangText="option-len">12 + length of IA_LL-options field.</t> <dt>IAID</dt>
<dd>The unique identifier for this IA_LL; the
<t hangText="IAID">The unique identifier for this IA_LL; the
IAID must be unique among the identifiers for IAID must be unique among the identifiers for
all of this client's IA_LLs. The number all of this client's IA_LLs. The number
space for IA_LL IAIDs is separate from the space for IA_LL IAIDs is separate from the
number space for other IA option types (i.e., number space for other IA option types (i.e.,
IA_NA, IA_TA, and IA_PD). A 4-octet field IA_NA, IA_TA, and IA_PD). A 4-octet field
containing an unsigned integer.</t> containing an unsigned integer.</dd>
<dt>T1</dt>
<t hangText="T1">The time interval after which the client <dd>The time interval after which the client
should contact the server from which the should contact the server from which the
addresses in the IA_LL were obtained to extend addresses in the IA_LL were obtained to extend
the valid lifetime of the addresses assigned to the valid lifetime of the addresses assigned to
the IA_LL; T1 is a time duration relative to the IA_LL; T1 is a time duration relative to
the current time expressed in units of seconds. the current time expressed in units of seconds.
A 4-octet field containing an unsigned integer. A 4-octet field containing an unsigned integer.
</t> </dd>
<dt>T2</dt>
<t hangText="T2">The time interval after which the client <dd>The time interval after which the client
should contact any available server to extend should contact any available server to extend
the valid lifetime of the addresses assigned to the valid lifetime of the addresses assigned to
the IA_LL; T2 is a time duration relative to the IA_LL; T2 is a time duration relative to
the current time expressed in units of seconds. the current time expressed in units of seconds.
A 4-octet field containing an unsigned integer. A 4-octet field containing an unsigned integer.
</t> </dd>
<dt>IA_LL-options</dt>
<t hangText="IA_LL-options">Options associated with this <dd>Options associated with this
IA_LL. A variable length field (12 octets less IA_LL. A variable-length field (12 octets less
than the value in the option-len field).</t> than the value in the option-len field).</dd>
</list> </dl>
</t>
<t>An IA_LL option may only appear in the options area of a DHCP <t>An IA_LL option may only appear in the options area of a DHCP
message. A DHCP message may contain multiple IA_LL options message. A DHCP message may contain multiple IA_LL options
(though each must have a unique IAID).</t> (though each must have a unique IAID).</t>
<t>The status of any operations involving this IA_LL is indicated <t>The status of any operations involving this IA_LL is indicated
in a Status Code option (see Section 21.13 of in a Status Code option (see <xref target="RFC8415" sectionFormat="of"
<xref target="RFC8415"/>) in the IA_LL-options field. section="21.13"/>) in the IA_LL-options field.</t>
</t>
<t>Note that an IA_LL has no explicit "lifetime" or "lease length" <t>Note that an IA_LL has no explicit "lifetime" or "lease length"
of its own. When the valid lifetimes of all of the addresses in an of its own. When the valid lifetimes of all of the addresses in an
IA_LL have expired, the IA_LL can be considered as having expired. IA_LL have expired, the IA_LL can be considered to be expired.
T1 and T2 are included to give servers explicit control over when T1 and T2 are included to give servers explicit control over when
a client recontacts the server about a specific IA_LL.</t> a client recontacts the server about a specific IA_LL.</t>
<t>In a message sent by a client to a server, the T1 and T2 fields <t>In a message sent by a client to a server, the T1 and T2 fields
MUST be set to 0. The server MUST ignore any values in these <bcp14>MUST</bcp14> be set to 0. The server <bcp14>MUST</bcp14> ignore any values in these
fields in messages received from a client.</t> fields in messages received from a client.</t>
<t>In a message sent by a server to a client, the client <bcp14>MUST</bc
<t>In a message sent by a server to a client, the client MUST use p14> use
the values in the T1 and T2 fields for the T1 and T2 times, unless the values in the T1 and T2 fields for the T1 and T2 times, unless
those values in those fields are 0. The values in the T1 and T2 those values in those fields are 0. The values in the T1 and T2
fields are the number of seconds until T1 and T2.</t> fields are the number of seconds until T1 and T2.</t>
<t>As per <xref target="RFC8415" sectionFormat="of" section="7.7"/>,
<t>As per Section 7.7 of <xref target="RFC8415"/>),
the value 0xffffffff is taken to mean "infinity" and should be the value 0xffffffff is taken to mean "infinity" and should be
used carefully.</t> used carefully.</t>
<t>The server selects the T1 and T2 times to allow the client to <t>The server selects the T1 and T2 times to allow the client to
extend the lifetimes of any address block in the IA_LL before the extend the lifetimes of any address block in the IA_LL before the
lifetimes expire, even if the server is unavailable for some short lifetimes expire, even if the server is unavailable for some short
period of time. Recommended values for T1 and T2 are .5 and .8 period of time. Recommended values for T1 and T2 are .5 and .8
times the shortest valid lifetime of the address blocks in the IA times the shortest valid lifetime of the address blocks in the IA
that the server is willing to extend, respectively. If the that the server is willing to extend, respectively. If the
"shortest" valid lifetime is 0xffffffff ("infinity"), the "shortest" valid lifetime is 0xffffffff ("infinity"), the
recommended T1 and T2 values are also 0xffffffff. If the time at recommended T1 and T2 values are also 0xffffffff. If the time at
which the addresses in an IA_LL are to be renewed is to be left to which the addresses in an IA_LL are to be renewed is to be left to
the discretion of the client, the server sets T1 and T2 to 0. The the discretion of the client, the server sets T1 and T2 to 0. The
skipping to change at line 594 skipping to change at line 527
<t>The server selects the T1 and T2 times to allow the client to <t>The server selects the T1 and T2 times to allow the client to
extend the lifetimes of any address block in the IA_LL before the extend the lifetimes of any address block in the IA_LL before the
lifetimes expire, even if the server is unavailable for some short lifetimes expire, even if the server is unavailable for some short
period of time. Recommended values for T1 and T2 are .5 and .8 period of time. Recommended values for T1 and T2 are .5 and .8
times the shortest valid lifetime of the address blocks in the IA times the shortest valid lifetime of the address blocks in the IA
that the server is willing to extend, respectively. If the that the server is willing to extend, respectively. If the
"shortest" valid lifetime is 0xffffffff ("infinity"), the "shortest" valid lifetime is 0xffffffff ("infinity"), the
recommended T1 and T2 values are also 0xffffffff. If the time at recommended T1 and T2 values are also 0xffffffff. If the time at
which the addresses in an IA_LL are to be renewed is to be left to which the addresses in an IA_LL are to be renewed is to be left to
the discretion of the client, the server sets T1 and T2 to 0. The the discretion of the client, the server sets T1 and T2 to 0. The
client MUST follow the rules defined in Section 14.2 in client <bcp14>MUST</bcp14> follow the rules defined in
<xref target="RFC8415"/>. <xref target="RFC8415" sectionFormat="of" section="14.2"/>.
</t> </t>
<t>If a client receives an IA_LL with T1 greater than T2, and both <t>If a client receives an IA_LL with T1 greater than T2, and both
T1 and T2 are greater than 0, the client discards the IA_LL option T1 and T2 are greater than 0, the client discards the IA_LL option
and processes the remainder of the message as though the server and processes the remainder of the message as though the server
had not included the invalid IA_LL option.</t> had not included the invalid IA_LL option.</t>
<t>The IA_LL-options field typically contains one or more LLADDR <t>The IA_LL-options field typically contains one or more LLADDR
options (see <xref target="LLADDR"/>). If a client does not include options (see <xref target="LLADDR"/>). If a client does not include
a LLADDR option in a Solicit or Request message, the server MUST an LLADDR option in a Solicit or Request message, the server <bcp14>MUST </bcp14>
treat this as a request for a single address and that the treat this as a request for a single address and that the
client has no hint as to the address it would like.</t> client has no hint as to the address it would like.</t>
</section> </section>
<section anchor="LLADDR">
<section anchor="LLADDR" title="Link-Layer Addresses Option"> <name>Link-Layer Addresses Option</name>
<t>The Link-Layer Addresses option is used to specify an address block
<t>The Link-Layer Addresses option is used to specify an address block
associated with an IA_LL. The option must be encapsulated in the associated with an IA_LL. The option must be encapsulated in the
IA_LL-options field of an IA_LL option. The LLaddr-options fields IA_LL-options field of an IA_LL option. The LLaddr-options field
encapsulates those options that are specific to this address block.</t> encapsulates those options that are specific to this address block.</t>
<t>The format of the Link-Layer Addresses option is:</t>
<t>The format of the Link-Layer Addresses option is:</t> <figure anchor="lladdr-syntax">
<name>LLADDR Option Format</name>
<figure align="center" anchor="lladdr-syntax"
title="LLADDR Option Format">
<artwork align="left"><![CDATA[ <artwork align="left"><![CDATA[
0 1 2 3 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 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 | | OPTION_LLADDR | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-layer-type | link-layer-len | | link-layer-type | link-layer-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. link-layer-address . . link-layer-address .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extra-addresses | | extra-addresses |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid-lifetime | | valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. LLaddr-options . . LLaddr-options .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork> ]]></artwork>
</figure> </figure>
<dl newline="false" spacing="normal" indent="21">
<t> <dt>option-code</dt>
<list hangIndent="16" style="hanging"> <dd>OPTION_LLADDR (139).</dd>
<t hangText="option-code">OPTION_LLADDR (tbd2).</t> <dt>option-len</dt>
<dd>12 + link-layer-len field value
<t hangText="option-len">12 + link-layer-len field value
+ length of LLaddr-options field. Assuming a + length of LLaddr-options field. Assuming a
link-layer-address length of 6 and no extra options, the link-layer-address length of 6 and no extra options, the
option-len would be 18.</t> option-len would be 18.</dd>
<dt>link-layer-type</dt>
<t hangText="link-layer-type">The link-layer type MUST be a
valid hardware type assigned by the IANA, as described in
<xref target="RFC5494"/> and in the "Hardware Types" table at
https://www.iana.org/assignments/arp-parameters.
A 2-octet field containing an unsigned integer.</t>
<t hangText="link-layer-len">Specifies the length, in octets, <dd>The link-layer type <bcp14>MUST</bcp14> be a
of the link-layer-address field (typically 6, for a valid hardware type assigned by IANA, as described in
<xref target="RFC5494"/>, and registered in the "Hardware Types" reg
istry at
<eref target="https://www.iana.org/assignments/arp-parameters" brack
ets="angle"/>.
A 2-octet field containing an unsigned integer.</dd>
<dt>link-layer-len</dt>
<dd>Specifies the length, in octets,
of the link-layer-address field (typically 6 for a
link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)). link-layer-type of 1 (Ethernet) and 6 (IEEE 802 Networks)).
This is to accommodate link-layers that may have This is to accommodate link layers that may have
variable-length addresses. A 2-octet field containing an variable-length addresses. A 2-octet field containing an
unsigned integer.</t> unsigned integer.</dd>
<dt>link-layer-address</dt>
<t hangText="link-layer-address">Specifies the address of <dd>Specifies the address of
the first link-layer address that is being requested or the first link-layer address that is being requested or
assigned depending on the message. A client MAY send a assigned depending on the message. A client <bcp14>MAY</bcp14> send
special value to request any address. For a link-layer a
type of 1 and 6, see special value to request any address.
For link-layer
types 1 and 6, see
<xref target="Information-Encoding"/> for details on this <xref target="Information-Encoding"/> for details on this
field. A link-layer-len length octet field containing an field. A link-layer-len length octet field containing an
address.</t> address.</dd>
<dt>extra-addresses</dt>
<t hangText="extra-addresses">Specifies the number of <dd>Specifies the number of
additional addresses that follow the address specified in additional addresses that follow the address specified in
link-layer-address. For a single address, 0 is used. link-layer-address. For a single address, 0 is used.
For example: link-layer-address: 02:04:06:08:0a and For example, link-layer-address 02:04:06:08:0a and
extra-addresses 3 designates a block of 4 addresses, extra-addresses 3 designate a block of four addresses,
starting from 02:04:06:08:0a and ending with starting from 02:04:06:08:0a and ending with
02:04:06:08:0d (inclusive). A 4-octet field containing an 02:04:06:08:0d (inclusive). A 4-octet field containing an
unsigned integer.</t> unsigned integer.</dd>
<dt>valid-lifetime</dt>
<t hangText="valid-lifetime">The valid lifetime for the <dd>The valid lifetime for the
address(es) in the option, expressed in units of seconds. address(es) in the option, expressed in units of seconds.
A 4-octet field containing an unsigned integer.</t> A 4-octet field containing an unsigned integer.</dd>
<dt>LLaddr-options</dt>
<t hangText="LLaddr-options">Any encapsulated options that <dd>Any encapsulated options that
are specific to this particular address block. Currently there are specific to this particular address block. Currently, there
are no such options defined, but there may be in the future. are no such options defined, but there may be in the future.
</t> </dd>
</list> </dl>
</t>
<t>In a message sent by a client to a server, the valid <t>In a message sent by a client to a server, the valid
lifetime field MUST be set to 0. The server MUST ignore any lifetime field <bcp14>MUST</bcp14> be set to 0. The server <bcp14>MUST< /bcp14> ignore any
received value.</t> received value.</t>
<t>In a message sent by a server to a client, the client <bcp14>MUST</bc
<t>In a message sent by a server to a client, the client MUST use p14> use
the value in the valid lifetime field for the valid lifetime for the value in the valid lifetime field for the valid lifetime for
the address block. The value in the valid lifetime field is the the address block. The value in the valid lifetime field is the
number of seconds remaining in the lifetime.</t> number of seconds remaining in the lifetime.</t>
<t>As per <xref target="RFC8415" sectionFormat="of" section="7.7"/>,
<t>As per Section 7.7 of <xref target="RFC8415"/>,
the valid lifetime of 0xffffffff is taken to mean "infinity" and the valid lifetime of 0xffffffff is taken to mean "infinity" and
should be used carefully.</t> should be used carefully.</t>
<t>More than one LLADDR option can appear in an IA_LL option.</t> <t>More than one LLADDR option can appear in an IA_LL option.</t>
</section> </section>
</section> </section>
<section anchor="selecting-addresses">
<section anchor="selecting-addresses" <name>Selecting Link-Layer Addresses for Assignment to an IA_LL</name>
title="Selecting Link-Layer Addresses for Assignment to an IA_LL">
<t>A server selects link-layer addresses to be assigned to an IA_LL <t>A server selects link-layer addresses to be assigned to an IA_LL
according to the assignment policies determined by the server according to the assignment policies determined by the server
administrator and the requirements of that address space.</t> administrator and the requirements of that address space.</t>
<t>Link-layer addresses are typically specific to a link and the <t>Link-layer addresses are typically specific to a link and the
server SHOULD follow the steps in Section 13.1 of server <bcp14>SHOULD</bcp14> follow the steps in <xref target="RFC8415"
<xref target="RFC8415"/> to determine the client's link.</t> sectionFormat="of" section="13.1"/> to determine the client's link.</t>
<t>For IEEE 802 MAC addresses (see <xref target="IEEEStd802"/> as
<t>For IEEE 802 MAC addresses (see <xref target="IEEEStd802"/> as amended amended by <xref target="IEEEStd802c"/>):</t>
by <xref target="IEEEStd802c"/>): <ol spacing="normal" type="1">
<list hangIndent="4" style="hanging"> <li>Server administrators <bcp14>SHOULD</bcp14> follow the IEEE 802
<t hangText="1.">Server administrators SHOULD follow the IEEE 802 Specifications with regard to the unicast address pools made
Specifications with regards to the unicast address pools made
available for assignment (see <xref target="IEEE802cSummary"/> and available for assignment (see <xref target="IEEE802cSummary"/> and
<xref target="IEEEStd802c"/>) -- only address space reserved for <xref target="IEEEStd802c"/>) -- only address space reserved for
local use or with the authorization of the assignee may be used. local use or with the authorization of the assignee may be used.
</t> </li>
<li>Servers <bcp14>MUST NOT</bcp14> allow administrators to
<t hangText="2.">Servers MUST NOT allow administrators to configure address pools that would cross the boundary of 2<sup>42</sup>
configure address pools that would cross the 2^42 bit boundary bits
(for 48-bit MAC addresses) to avoid issues with changes in the (for 48-bit MAC addresses) to avoid issues with changes in the
first octet of the address and the special bits therein (see first octet of the address and the special bits therein (see
<xref target="IEEE802cSummary"/>). Clients MUST reject assignments <xref target="IEEE802cSummary"/>). Clients <bcp14>MUST</bcp14> reject as
where the assigned block would cross this boundary (they MUST signments
decline the allocation - see Section 18.2.8 of where the assigned block would cross this boundary (they <bcp14>MUST</bc
<xref target="RFC8415"/>). p14>
</t> decline the allocation -- see <xref target="RFC8415" sectionFormat="of"
section="18.2.8"/>).
<t hangText="3.">A server MAY use options supplied by a </li>
<li>A server <bcp14>MAY</bcp14> use options supplied by a
relay agent or client to select the quadrant (see relay agent or client to select the quadrant (see
<xref target="IEEE802cSummary"/>) from which addresses are to be <xref target="IEEE802cSummary"/>) from which addresses are to be
assigned. This MAY include options, such as those specified in assigned. This <bcp14>MAY</bcp14> include options like those specified i
<xref target="I-D.ietf-dhc-slap-quadrant"/>.</t> n
</list> <xref target="RFC8948" format="default"/>.</li>
</t> </ol>
</section> </section>
<section anchor="iana">
<section anchor="iana" title="IANA Considerations"> <name>IANA Considerations</name>
<t>IANA has assigned the OPTION_IA_LL (138)
<t>IANA is requested to assign the OPTION_IA_LL (tbd1) option code from the "Option Codes" subregistry of the
option code from the DHCPv6 "Option Codes" registry maintained at "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained a
http://www.iana.org/assignments/dhcpv6-parameters and use the t
following data when adding the option to the registry:</t> <eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="an
gle"/>:</t>
<figure> <dl newline="false" spacing="compact" indent="14">
<artwork align="left"> <dt>Value:</dt>
<![CDATA[ <dd>138</dd>
Value: tbd1 <dt>Description:</dt>
Description: OPTION_IA_LL <dd>OPTION_IA_LL</dd>
Client ORO: No <dt>Client ORO:</dt>
Singleton Option: No <dd>No</dd>
Reference: this document <dt>Singleton Option:</dt>
]]> <dd>No</dd>
</artwork> <dt>Reference:</dt>
</figure> <dd>RFC 8947</dd>
</dl>
<t>IANA is requested to assign the OPTION_LLADDR (tbd2) <t>IANA has assigned the OPTION_LLADDR (139)
option code from the DHCPv6 "Option Codes" registry maintained at option code from the "Option Codes" subregistry of the
http://www.iana.org/assignments/dhcpv6-parameters and use the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry maintained a
following data when adding the option to the registry:</t> t
<eref target="http://www.iana.org/assignments/dhcpv6-parameters" brackets="an
<figure> gle"/>:</t>
<artwork align="left"> <dl newline="false" spacing="compact" indent="14">
<![CDATA[ <dt>Value:</dt>
Value: tbd2 <dd>139</dd>
Description: OPTION_LLADDR <dt>Description:</dt>
Client ORO: No <dd>OPTION_LLADDR</dd>
Singleton Option: No <dt>Client ORO:</dt>
Reference: this document <dd>No</dd>
]]> <dt>Singleton Option:</dt>
</artwork> <dd>No</dd>
</figure> <dt>Reference:</dt>
<dd>RFC 8947</dd>
</dl>
</section> </section>
<section anchor="security">
<section anchor="security" title="Security Considerations"> <name>Security Considerations</name>
<t>See <xref target="RFC8415" sectionFormat="of" section="22"/> and
<t>See Section 22 of <xref target="RFC8415"/> and Section 23 of <xref target="RFC7227" sectionFormat="of" section="23"/> for
<xref target="RFC7227"/> for
the DHCP security considerations. See <xref target="RFC8200"/> the DHCP security considerations. See <xref target="RFC8200"/>
for the IPv6 security considerations.</t> for the IPv6 security considerations.</t>
<t>As discussed in <xref target="RFC8415" sectionFormat="of" section="22"/
<t>As discussed in Section 22 of <xref target="RFC8415"/>, "DHCP >:</t> <blockquote><t>DHCP
lacks end-to-end encryption between clients and servers; thus, lacks end-to-end encryption between clients and servers; thus,
hijacking, tampering, and eavesdropping attacks are all possible as hijacking, tampering, and eavesdropping attacks are all possible as
a result." In some network environments, it is possible to secure a result.</t></blockquote> <t>In some network environments, it is possible
them as discussed later in that Section 22.</t> to secure
them, as discussed later in <xref target="RFC8415"
sectionFormat="of" section="22"/>.</t>
<t>If not all parties on a link use this mechanism to obtain an address fr
om the space assigned to the DHCP server, there is the possibility of the same l
ink-layer address being used by more than one device.
<t>There is a possibility of the same link-layer address being Note that this issue would exist on these networks
used by more than one device if not all parties on a link use
this mechanism to obtain an address from the space assigned to
the DHCP server. Note that this issue would exist on these networks
even if DHCP were not used to obtain the address.</t> even if DHCP were not used to obtain the address.</t>
<t>Server implementations <bcp14>SHOULD</bcp14> consider configuration opt
<t>Server implementations SHOULD consider configuration options to ions to
limit the maximum number of addresses to allocate (both in a single limit the maximum number of addresses to allocate (both in a single
request and in total) to a client. However, note that this does not request and in total) to a client. However, note that this does not
prevent a bad client actor from pretending to be many different prevent a bad client actor from pretending to be many different
clients and consuming all available addresses.</t> clients and consuming all available addresses.</t>
</section> </section>
<section anchor="privacy">
<section anchor="privacy" title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>See <xref target="RFC8415" sectionFormat="of" section="23"/> for the
<t>See Section 23 of <xref target="RFC8415"/> for the DHCP DHCP privacy considerations.</t>
privacy considerations.</t>
<t>For a client requesting a link-layer address directly from <t>For a client requesting a link-layer address directly from
a server, as the address assigned to a client will a server, as the address assigned to a client will
likely be used by the client to communicate on the link, the likely be used by the client to communicate on the link, the
address will be exposed to those able to listen in on this address will be exposed to those able to listen in on this
communication. For those peers on the link that are able to communication. For those peers on the link that are able to
listen in on the DHCP exchange, they would also be able to listen in on the DHCP exchange, they would also be able to
correlate the client's identity (based on the DUID used) with the correlate the client's identity (based on the DUID used) with the
assigned address. Additional mechanisms, such as the ones described assigned address. Additional mechanisms, such as the ones described
in <xref target="RFC7844"/> can also be used to improve in <xref target="RFC7844"/>, can also be used to improve
anonymity by minimizing what is exposed.</t> anonymity by minimizing what is exposed.</t>
<t>As discussed in <xref target="RFC8415" sectionFormat="of" section="23"/
<t>As discussed in Section 23 of <xref target="RFC8415"/>, DHCP >, DHCP
servers and hypervisors may need to consider the implications of servers and hypervisors may need to consider the implications of
assigning addresses sequentially. Though in general, this is only assigning addresses sequentially. Though in general, this is only
of link-local concern unlike for IPv6 address assignment and of link-local concern unlike for IPv6 address assignment and
prefix delegation as these may be used for communication over the prefix delegation, as these may be used for communication over the
Internet.</t> Internet.</t>
</section>
<section title="Acknowledgements">
<t>Thanks to the DHC Working Group participants that reviewed this
document, provided comments, and support. With special thanks to
Ian Farrer for his thorough reviews and shepherding of this
document through the IETF process. Thanks also to area reviewers
Samita Chakrabarti, Roni Even and Tianran Zhou, and IESG members
Martin Duke, Benjamin Kaduk, Murray Kucherawy, Warren Kumari, Barry
Leiba, Alvaro Retana, Eric Vyncke, and Robert Wilton for their
suggestions. And to Roger Marks, Bob Grow, and Antonio de la Oliva
for comments related to IEEE work and references.
</t>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
<name>References</name>
<?rfc include='reference.RFC.2119'?> <references>
<?rfc include='reference.RFC.4861'?> <name>Normative References</name>
<?rfc include='reference.RFC.8174'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include="reference.RFC.8415'?> FC.2119.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</references> FC.4861.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<references title="Informative References"> FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.2464'?> FC.8415.xml"/>
<?rfc include='reference.RFC.4429'?> </references>
<?rfc include='reference.RFC.5494'?> <references>
<?rfc include='reference.RFC.7227'?> <name>Informative References</name>
<?rfc include='reference.RFC.7228'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<?rfc include='reference.RFC.7844'?> FC.2464.xml"/>
<?rfc include='reference.RFC.8200'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.4429.xml"/>
<?rfc include='reference.I-D.ietf-dhc-slap-quadrant'?> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.5494.xml"/>
<reference anchor="IEEEStd802"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.7227.xml"/>
<title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
IEEE Standard for Local and Metropolitan Area Networks: Overview a FC.7228.xml"/>
nd Architecture, IEEE Std 802 <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</title> FC.7844.xml"/>
<author /> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date /> FC.8200.xml"/>
</front> <reference anchor="RFC8948" target="https://www.rfc-editor.org/info/rfc89
</reference> 48">
<front>
<reference anchor="IEEEStd802.11"> <title>Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6
<front> </title>
<title> <author initials='CJ' surname='Bernardos' fullname='Carlos J. Bernardos'>
IEEE Standard for Information technology - Telecommunications and <organization>Universidad Carlos III de Madrid</organization>
information exchange between systems Local and metropolitan area networks - Spec </author>
ific requirements - Part 11: Wireless LAN Medium Access Control (MAC) and Physic <author initials='A' surname='Mourad' fullname='Alain Mourad'>
al Layer (PHY) Specifications, IEEE Std 802.11 <organization>InterDigital Europe</organization>
</title> </author>
<author /> <date month='November' year='2020'/>
<date /> </front>
</front> <seriesInfo name="RFC" value="8948"/>
</reference> <seriesInfo name="DOI" value="10.17487/RFC8948"/>
</reference>
<reference anchor="IEEEStd802c">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networks: Overview a
nd Architecture, Amendment 2: Local Medium Access Control (MAC) Address Usage, I
EEE Std 802c-2017
</title>
<author />
<date />
</front>
</reference>
<reference anchor="IEEE-P802.1CQ-Project"
target="https://standards.ieee.org/project/802_1CQ.html">
<front>
<title>
P802.1CQ - Standard for Local and Metropolitan Area Networks: Multic
ast and Local Address Assignment
</title>
<author />
<date />
</front>
</reference>
<reference anchor="IEEEStd802">
<front>
<title>IEEE Standard for Local and Metropolitan Area Networks: Overv
iew
and Architecture, IEEE Std 802</title>
<author>
<organization>IEEE</organization>
</author>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2014.6847097"/>
<refcontent>IEEE STD 802-2014</refcontent>
</reference>
<reference anchor="IEEEStd802.11">
<front>
<title>
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
</title>
<author>
<organization>IEEE</organization>
</author>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2016.7786995"/>
<refcontent>IEEE Std 802.11</refcontent>
</reference>
<reference anchor="IEEEStd802c">
<front>
<title>
IEEE Standard for Local and Metropolitan Area Networks:Overview
and Architecture--Amendment 2: Local Medium Access Control (MAC)
Address Usage
</title>
<author>
<organization>IEEE</organization>
</author>
</front>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2017.8016709"/>
<refcontent>IEEE Std 802c-2017</refcontent>
</reference>
<reference anchor="IEEE-P802.1CQ-Project"
target="https://standards.ieee.org/project/802_1CQ.html">
<front>
<title>
P802.1CQ - Standard for Local and Metropolitan Area Networks:
Multicast and Local Address Assignment</title>
<author>
<organization>IEEE</organization>
</author>
</front>
</reference>
</references>
</references> </references>
<section anchor="IEEE802cSummary">
<section anchor="IEEE802cSummary" title="IEEE 802c Summary"> <name>IEEE 802c Summary</name>
<t>This appendix provides a brief summary of IEEE 802c <t>This appendix provides a brief summary of IEEE 802c
<xref target="IEEEStd802c"/>.</t> <xref target="IEEEStd802c"/>.</t>
<t>The original IEEE 802 specifications assigned half of the 48-bit <t>The original IEEE 802 specifications assigned half of the 48-bit
MAC address space to local use -- these addresses have the U/L bit MAC address space to local use -- these addresses have the U/L bit
set to 1 and are locally administered with no imposed structure.</t> set to 1 and are locally administered with no imposed structure.</t>
<t>In 2017, the IEEE issued the IEEE Std 802c specification, which
<t>In 2017, the IEEE issued the IEEE Std 802c specification which
defines a new optional "Structured Local Address Plan (SLAP) that defines a new optional "Structured Local Address Plan (SLAP) that
specifies different assignment approaches in four specified regions specifies different assignment approaches in four specified regions
of the local MAC address space." Under this plan, there are 4 SLAP of the local MAC address space". Under this plan, there are four SLAP
quadrants that use different assignment policies.</t> quadrants that use different assignment policies.</t>
<t>The first octet of the MAC address Z and Y bits define the <t>The first octet of the MAC address Z and Y bits define the
quadrant for locally assigned addresses (X-bit is 1). In IEEE quadrant for locally assigned addresses (X-bit is 1). In IEEE
representation, these bits are as follows:</t> representation, these bits are as follows:</t>
<t keepWithNext="true"/>
<figure align="center" anchor="SLAP-Bits" <figure anchor="SLAP-Bits">
title="SLAP Bits"> <name>SLAP Bits</name>
<preamble></preamble> <artwork align="left"><![CDATA[
<artwork align="left"><![CDATA[
LSB MSB LSB MSB
M X Y Z - - - - M X Y Z - - - -
| | | | | | | |
| | | +------------ SLAP Z-bit | | | +------------ SLAP Z-bit
| | +--------------- SLAP Y-bit | | +--------------- SLAP Y-bit
| +------------------ X-bit (U/L) = 1 for locally assigned | +------------------ X-bit (U/L) = 1 for locally assigned
+--------------------- M-bit (I/G) (unicast/group) +--------------------- M-bit (I/G) (unicast/group)
]]></artwork> ]]></artwork>
</figure>
<postamble></postamble> <t keepWithPrevious="true"/>
</figure>
<t>The SLAP quadrants are:</t> <t>The SLAP quadrants are:</t>
<table>
<texttable title="SLAP Quadrants"> <name>SLAP Quadrants</name>
<ttcol align='right'>Quadrant</ttcol> <thead>
<ttcol align='left'>Y-bit</ttcol> <tr>
<ttcol align='left'>Z-bit</ttcol> <th align="right">Quadrant</th>
<ttcol align='left'>Local Identifier Type</ttcol> <th align="left">Y-bit</th>
<ttcol align='left'>Local Identifier</ttcol> <th align="left">Z-bit</th>
<c>01</c><c>0</c><c>1</c><c>Extended Local</c><c>ELI</c> <th align="left">Local Identifier Type</th>
<c>11</c><c>1</c><c>1</c><c>Standard Assigned</c><c>SAI</c> <th align="left">Local Identifier</th>
<c>00</c><c>0</c><c>0</c><c>Administratively Assigned</c><c>AAI</c> </tr>
<c>10</c><c>1</c><c>0</c><c>Reserved</c><c>Reserved</c> </thead>
</texttable> <tbody>
<tr>
<t>Extended Local Identifier (ELI) derived MAC addresses are based <td align="right">01</td>
on an assigned Company ID (CID), which is 24-bits (including the M, <td align="left">0</td>
X, Y, and Z bits) for 48-bit MAC addresses. This leaves 24-bits for <td align="left">1</td>
<td align="left">Extended Local</td>
<td align="left">ELI</td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">1</td>
<td align="left">1</td>
<td align="left">Standard Assigned</td>
<td align="left">SAI</td>
</tr>
<tr>
<td align="right">00</td>
<td align="left">0</td>
<td align="left">0</td>
<td align="left">Administratively Assigned</td>
<td align="left">AAI</td>
</tr>
<tr>
<td align="right">10</td>
<td align="left">1</td>
<td align="left">0</td>
<td align="left">Reserved</td>
<td align="left">Reserved</td>
</tr>
</tbody>
</table>
<t>MAC 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. This leaves 24 bits for
the locally assigned address for each CID for unicast (M-bit = 0) the locally assigned address for each CID for unicast (M-bit = 0)
and also for multicast (M-bit = 1). The CID is assigned by the IEEE and also for multicast (M-bit = 1). The CID is assigned by the IEEE
RA.</t> Registration Authority (RA).</t>
<t>MAC addresses derived from a Standard Assigned Identifier (SAI) are
<t>Standard Assigned Identifier (SAI) derived MAC addresses are
assigned by a protocol specified in an IEEE 802 standard. For assigned by a protocol specified in an IEEE 802 standard. For
48-bit MAC addresses, 44 bits are available. Multiple protocols 48-bit MAC addresses, 44 bits are available. Multiple protocols
for assigning SAIs may be specified in IEEE standards. Coexistence for assigning SAIs may be specified in IEEE standards. Coexistence
of multiple protocols may be supported by limiting the subspace of multiple protocols may be supported by limiting the subspace
available for assignment by each protocol.</t> available for assignment by each protocol.</t>
<t>MAC addresses derived from an Administratively Assigned Identifier (AAI
<t>Administratively Assigned Identifier (AAI) derived MAC addresses )
are assigned locally. Administrators manage the space as needed. are assigned locally. Administrators manage the space as needed.
Note that multicast IPv6 packets (<xref target="RFC2464"/>) use a Note that multicast IPv6 packets <xref target="RFC2464"/> use a
destination address starting in 33-33, so AAI addresses in that destination address starting in 33-33, so AAI addresses in that
range should not be assigned. For 48-bit MAC addresses, 44 bits are range should not be assigned. For 48-bit MAC addresses, 44 bits are
available.</t> available.</t>
<t>The last quadrant is reserved for future use. While this quadrant <t>The last quadrant is reserved for future use. While this quadrant
may also be used similar to AAI space, administrators should be may also be used similar to AAI space, administrators should be
aware that future specifications may define alternate uses that aware that future specifications may define alternate uses that
could be incompatible.</t> could be incompatible.</t>
</section> </section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgments</name>
<t>Thanks to the DHC Working Group participants that reviewed this
document and provided comments and support. With special thanks to
<contact fullname="Ian Farrer"/> for his thorough reviews and shepherding
of this
document through the IETF process. Thanks also to directorate reviewers
<contact fullname="Samita Chakrabarti"/>, <contact fullname="Roni
Even"/>, and <contact fullname="Tianran Zhou"/> and IESG members
<contact fullname="Martin Duke"/>, <contact fullname="Benjamin Kaduk"/>,
<contact fullname="Murray Kucherawy"/>, <contact fullname="Warren
Kumari"/>, <contact fullname="Barry Leiba"/>, <contact fullname="Alvaro
Retana"/>, <contact fullname="Éric Vyncke"/>, and <contact
fullname="Robert Wilton"/> for their
suggestions. And thanks to <contact fullname="Roger Marks"/>, <contact
fullname="Robert Grow"/>, and <contact fullname="Antonio de la
Oliva"/>
for comments related to IEEE work and references.
</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 180 change blocks. 
603 lines changed or deleted 590 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/