| Internet-Draft | TEAP DHCPv6 TLV | June 2025 |
| Lear & Dekok | Expires 19 December 2025 | [Page] |
This document defines a new Tunneled Extensible Authentication Protocol (TEAP) Type-Length-Value (TLV) to encapsulate DHCPv6 (Dynamic Host Configuration Protocol Version 6) options within TEAP authentication exchanges. This enhancement enables exchange of network configuration parameters after the authentication phase.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://elear.github.io/teap-config-options/main/draft-lear-teap-config-options.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lear-teap-config-options/.¶
Discussion of this document takes place on the EMU WG Working Group mailing list (mailto:emu@ietf.org), which is archived at https://example.com/WG. Subscribe at https://www.ietf.org/mailman/listinfo/emu/.¶
Source for this draft and an issue tracker can be found at https://github.com/elear/draft-lear-teap-config-option.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 19 December 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
TEAP (Tunneled Extensible Authentication Protocol), defined in [RFC7170], supports the use of Type-Length-Value (TLV) structures to exchange additional data during the authentication process. DHCPv6 [RFC8415] is widely used for configuration of network parameters. This document introduces a new TLV to encapsulate DHCPv6 options within TEAP messages.¶
[RFC9445] specifies a way to communicate options to a radius client. This memo specifies a means to communicate options end-to-end between the authentication server and the peer.¶
Not all DHCP communications will necessarily make sense in this context. For instance, a AAA server may only wish to send non-topological options, such as a print server, or next hop configuration URL, and it might not send next-hop router or IP address binding information.¶
Because DHCPv6 is widely deployed, peers implementing this specifciation can expect to receive information via TEAP and DHCPv6. Thereefore, the possibility of a conflict arises. Clients are not in a good position to determine on their own which information is correct. Therefore, the following strategy is RECOMMENDED:¶
Peers receiving information only via DHCP will use that information.¶
Peers receiving DHCP information only via TEAP will use that information.¶
Peers receiving overlapping DHCPv6 options SHOULD select TEAP information since it is likely to be better authenticated and unchanged.¶
If conflicting information is received by the peer it SHOULD log the conflict as an error and MAY produce an exception.¶
Both the TEAP server and TEAP client MAY transmit this TLV during Phase 2, and it MAY be included in a Request Action frame. The Mandatory bit MUST not be set. If either side sends this TLV prior to Phase 2, an error TLV of 2002 (Unexpected TLVs Exchanged) be returned with a Result of Status=Failure. That is, the table in Section 4.3.1 of [I-D.ietf-emu-rfc7170bis] remains unchanged.¶
Thus this TLV MAY be used as follows:¶
| Request | Response | Success | Failure | TLV |
|---|---|---|---|---|
| 0+ | 0+ | 0+ | 0 | DHCPv6 options |
A TEAP peer or server receiving this TLV SHOULD NOT act on it until the other side has been sufficiently authenticated, but it is not an error to send this TLV in advance of such authentication. In this way, the TLV can be conveniently piggybacked as part of the authentication prior to a result or intermediate result being generated.¶
The new TEAP TLV for DHCPv6 options is structured as follows:¶
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|R| TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCPv6 fields...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
M
0 - Optional TLV
R
Reserved, set to zero (0)
TLV Type
TBD - DHCPv6 options
Length
>=2 octets
¶
The Value field encapsulates DHCPv6 options exactly as they appear in DHCPv6 messages. Multiple options can be included, concatenated sequentially, with no padding between them.¶
The format adheres to the standard DHCPv6 option encoding, ensuring compatibility with existing DHCPv6 implementations.¶
Encapsulating this option in the TLV would look as follows (in hexadecimal):¶
Type: 0xXXXX (assigned by IANA) Length: 0x0014 Value: 0x00170010FE8000000000000000000000000001¶
Where:¶
Encapsulating DHCPv6 options within TEAP messages inherits the security guarantees of the TEAP protocol. Further details on mitigation strategies are discussed in [RFC7170].¶
IANA is requested to assign a new TEAP TLV type value for the DHCPv6 Options TLV from the TEAP TLV Type registry defined in [RFC7170].¶
The authors hope to thank the members of the IETF EMU Working Group for their valuable input and contributions.¶
TODO acknowledge.¶