draft-ietf-dhc-mac-assign-04.txt   draft-ietf-dhc-mac-assign-05.txt 
Dynamic Host Configuration (DHC) B. Volz Dynamic Host Configuration (DHC) B. Volz
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track T. Mrugalski Intended status: Standards Track T. Mrugalski
Expires: September 6, 2020 ISC Expires: September 17, 2020 ISC
CJ. Bernardos CJ. Bernardos
UC3M UC3M
March 5, 2020 March 16, 2020
Link-Layer Addresses Assignment Mechanism for DHCPv6 Link-Layer Addresses Assignment Mechanism for DHCPv6
draft-ietf-dhc-mac-assign-04 draft-ietf-dhc-mac-assign-05
Abstract Abstract
In certain environments, e.g. large scale virtualization deployments, In certain environments, e.g. large scale virtualization deployments,
new devices are created in an automated manner. Such devices new devices are created in an automated manner. Such devices
typically have their link-layer (MAC) addresses randomized. With typically have their link-layer (MAC) addresses randomized. With
sufficient scale, the likelihood of collision is not acceptable. sufficient scale, the likelihood of collision is not acceptable.
Therefore an allocation mechanism is required. This draft proposes Therefore an allocation mechanism is required. This draft 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.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2020. This Internet-Draft will expire on September 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Deployment scenarios and mechanism overview . . . . . . . . . 4 4. Deployment scenarios and mechanism overview . . . . . . . . . 4
4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4 4.1. Proxy client mode scenario . . . . . . . . . . . . . . . 4
4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5 4.2. Direct client mode scenario . . . . . . . . . . . . . . . 5
4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5 4.3. Mechanism Overview . . . . . . . . . . . . . . . . . . . 5
5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 7 5. Design Assumptions . . . . . . . . . . . . . . . . . . . . . 7
6. Information Encoding . . . . . . . . . . . . . . . . . . . . 8 6. Information Encoding . . . . . . . . . . . . . . . . . . . . 8
7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 8 7. Requesting Addresses . . . . . . . . . . . . . . . . . . . . 8
8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 9 8. Renewing Addresses . . . . . . . . . . . . . . . . . . . . . 10
9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 10 9. Releasing Addresses . . . . . . . . . . . . . . . . . . . . . 10
10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 10 10. Option Definitions . . . . . . . . . . . . . . . . . . . . . 10
10.1. Identity Association for Link-Layer Addresses Option . . 10 10.1. Identity Association for Link-Layer Addresses Option . . 10
10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12 10.2. Link-Layer Addresses Option . . . . . . . . . . . . . . 12
11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14 11. Selecting Link-Layer Addresses for Assignment to an IA_LL . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 9, line 46 skipping to change at page 9, line 46
its T1 and T2 timers using the values specified in the IA_LL option. its T1 and T2 timers using the values specified in the IA_LL option.
The client MUST be able to handle a Reply message containing a The client MUST be able to handle a Reply message containing a
smaller number of addresses, or an address or addresses different smaller number of addresses, or an address or addresses different
than those requested. than those requested.
A client that has included a Rapid Commit option in the Solicit, may A client that has included a Rapid Commit option in the Solicit, may
receive a Reply in response to the Solicit and skip the Advertise and receive a Reply in response to the Solicit and skip the Advertise and
Request steps above (see Section 18.2.1 of [RFC8415]). Request 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 inform
its neighbors of the new link-layer address quickly.
8. Renewing Addresses 8. Renewing Addresses
Address renewals follow the normal DHCPv6 renewals processing Address renewals follow the normal DHCPv6 renewals processing
described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses, described in Section 18.2.4 of [RFC8415]. Once the T1 timer elapses,
the client starts sending Renew messages with the IA_LL option the client starts sending Renew messages with the IA_LL option
containing a LLADDR option for the address block being renewed. The containing a LLADDR option for the address block being renewed. The
server responds with a Reply message that contains the renewed server responds with a Reply message that contains the renewed
address block. The server SHOULD NOT alter the address block being address block. The server SHOULD NOT alter the address block being
renewed, unless its policy has changed. The server MUST NOT shrink renewed, unless its policy has changed. The server MUST NOT shrink
or expand the address block - once a block is assigned and has a non- or expand the address block - once a block is assigned and has a non-
skipping to change at page 16, line 27 skipping to change at page 16, line 27
16. References 16. References
16.1. Normative References 16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters, Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018, RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>. <https://www.rfc-editor.org/info/rfc8415>.
16.2. Informative References 16.2. Informative References
[I-D.ietf-dhc-slap-quadrant] [I-D.ietf-dhc-slap-quadrant]
Bernardos, C. and A. Mourad, "SLAP quadrant selection Bernardos, C. and A. Mourad, "SLAP quadrant selection
options for DHCPv6", draft-ietf-dhc-slap-quadrant-04 (work options for DHCPv6", draft-ietf-dhc-slap-quadrant-06 (work
in progress), February 2020. in progress), March 2020.
[IEEE-802-Tutorial] [IEEE-802-Tutorial]
Thaler, P., "Emerging IEEE 802 Work on MAC Addressing", Thaler, P., "Emerging IEEE 802 Work on MAC Addressing",
<https://datatracker.ietf.org/meeting/96/materials/slides- <https://datatracker.ietf.org/meeting/96/materials/slides-
96-edu-ieee802work-0/>. 96-edu-ieee802work-0/>.
[IEEE-802.11-02-109r0] [IEEE-802.11-02-109r0]
Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava, Edney, J., Haverinen, H., Honkanen, J-P., and P. Orava,
"Temporary MAC address for anonymity", "Temporary MAC address for anonymity",
<https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i- <https://mentor.ieee.org/802.11/dcn/02/11-02-0109-00-000i-
 End of changes. 8 change blocks. 
7 lines changed or deleted 16 lines changed or added

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