PPP IPCP Extensions for Encrypted DNS Server Negotiation

Introduction The Point-to-Point Protocol (PPP) includes the Internet Protocol Control Protocol (IPCP), which is used to configure IPv4 parameters for a PPP peer. RFC 1877 defines an IPCP extension for communicating DNS name server addresses, but those addresses identify plaintext DNS resolvers and do not provide information needed to configure encrypted DNS transports. This document defines two IPCP Configuration Options for encrypted DNS: one for a primary resolver and one for a secondary resolver. Each option is a complete resolver configuration and contains an Authentication Domain Name (ADN), an explicit address list, and Service Parameters (SvcParams). The SvcParams use the encoding specified by RFC 9460 so that existing Service Binding parameter definitions can be reused without defining a new parameter registry. The design supports DNS over TLS (DoT) , DNS over HTTPS (DoH) , and DNS over QUIC (DoQ) . It does not define a new encrypted-DNS transport protocol or a new representation for ALPN, port, or DoH path parameters. The encrypted DNS options coexist with RFC 1877. When both encrypted DNS and plaintext DNS configuration are available, the encrypted DNS configuration takes precedence. If the encrypted DNS service cannot be used, the client MAY fall back to plaintext DNS configuration obtained through RFC 1877, subject to local policy and the requirements of RFC 1877.

Conventions and Terminology The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 . ADN means Authentication Domain Name, encoded as a DNS wire-format domain name and used for TLS server identity validation. Resolver Configuration means one complete Option 133 or Option 134 option containing an ADN, an address list, and SvcParams.

Protocol Model This document defines exactly two encrypted DNS IPCP Configuration Options:

Option 133: Primary Encrypted DNS Server.
Option 134: Secondary Encrypted DNS Server.

Option 133 is the Primary Encrypted DNS Server Option, and Option 134 is the Secondary Encrypted DNS Server Option. IANA is requested to assign these values from the PPP IPCP Configuration Option Types registry. Each Option 133 or Option 134 independently contains all information required to configure one encrypted DNS resolver. There is no independent configuration option for encryption parameters. A client MUST NOT treat multiple instances of the same Option 133 or Option 134 as an ordered list or apply a "last received wins" rule. Duplicate instances are invalid. Processing of malformed or duplicate Configuration Options follows the general IPCP rules in RFC 1661 . The primary and secondary roles do not define an IPCP renegotiation procedure. Selection and failover between the two successfully negotiated resolver configurations are local client policy.

Option Format Both Option 133 and Option 134 use the same option format. The only difference is the Configuration Option Type.

Encrypted DNS Configuration Option Format The fields are:

Type: One of the two IANA-assigned IPCP Configuration Option Types.
Length: The total length of the Configuration Option, including Type and Length.
ADN Length: One octet indicating the length of the ADN field in octets.
ADN: The DNS wire-format Authentication Domain Name.
Address List Length: One octet indicating the length of the Address List field in octets.
Address List: A sequence of address-family identifiers and IP addresses.
SvcParams Length: One octet indicating the length of the SvcParams field in octets.
SvcParams: Service Parameters encoded using the wire format defined by RFC 9460.

The complete option, including all nested fields, MUST fit within the PPP MRU. This document does not define fragmentation of an individual Configuration Option. An implementation MUST NOT silently truncate an option.

Primary Encrypted DNS Server Option (133) Option 133 identifies the primary encrypted DNS resolver configuration. An Option 133 MUST contain an ADN field, an Address List field, and a SvcParams field, each preceded by its corresponding length field. A client may use an empty Address List as a discovery probe as described in .

Secondary Encrypted DNS Server Option (134) Option 134 identifies the secondary encrypted DNS resolver configuration. Option 134 has exactly the same field structure and validation requirements as Option 133. The distinction between primary and secondary is determined by the Configuration Option Type, not by a field inside the option.

Length Fields ADN Length, Address List Length, and SvcParams Length are each one octet. The outer PPP Configuration Option Length field is also one octet, as defined by IPCP. Consequently, the complete option cannot exceed 255 octets. A receiver MUST verify that every inner length is no greater than the number of octets remaining in the outer Configuration Option. A receiver MUST reject or otherwise process as malformed any option whose inner lengths cause parsing to extend beyond the outer option boundary. This document does not define larger inner length fields. Any future extension requiring subfields larger than 255 octets would require a revision or a new option format.

ADN Encoding The ADN is encoded using the DNS wire-format domain-name representation defined by RFC 1034 and RFC 1035 . The ADN MUST terminate with the root label. It MUST contain at least one non-root label and MUST NOT contain DNS compression pointers. The encoded ADN, including the terminating root label, MUST NOT exceed 255 octets. A client that uses an ADN of zero length is making a configuration request or probe and is not presenting a resolver identity. A server response that supplies a usable resolver configuration SHOULD contain a valid non-empty ADN.

Address List The Address List consists of zero or more address entries. Each entry begins with a one-octet address-family identifier (AF), followed by the address associated with that AF. Address-Family Values

AF	Address	Length
1	IPv4	4 octets
2	IPv6	16 octets

Address List Length counts both the one-octet AF field and the address octets for every entry. For example, an IPv4 entry consumes 5 octets and an IPv6 entry consumes 17 octets. IPv4 and IPv6 entries MAY be mixed in one list. Address-family values other than 1 and 2 are not defined by this document. A receiver MUST treat an entry with an unsupported AF as invalid rather than guessing its length. Address List Length equal to zero MAY be used in a client Configure-Request as a discovery probe. Such a probe MAY contain non-zero SvcParams. A Configure-Ack containing no resolver addresses is NOT RECOMMENDED unless another trusted resolver discovery or bootstrap mechanism is available.

SvcParams The SvcParams field reuses the SvcParam wire format defined by RFC 9460 . This document does not define a new SvcParam encoding or registry. SvcParam keys MUST appear in strictly increasing numerical order. Duplicate keys are invalid. Processing of individual SvcParams, including handling of unknown optional parameters, follows the rules of RFC 9460. The alpn, port, and dohpath parameters, when applicable, use their RFC 9460 definitions. The ALPN identifiers are defined by RFC 7301 , and the DoH path template follows RFC 9461 . The ipv4hint and ipv6hint parameters MUST NOT be included in a resolver configuration defined by this document, because the resolver IP addresses are explicitly carried in the Address List. SvcParams Length equal to zero means that the SvcParams field contains zero octets. It does not denote a separate encoding of an empty SvcParam set. When SvcParams Length is zero, the local default encrypted DNS transport is DoT. If a resolver configuration contains a required encrypted-DNS transport parameter that an implementation cannot understand or safely apply, that resolver configuration MUST NOT be activated. If a port SvcParam is present, its value MUST NOT be zero. The default ports for the encrypted DNS transports are used only when the corresponding protocol specification defines such a default and the port parameter is absent.

Wire-Format Validation A receiver MUST perform the following validation before activating a resolver configuration:

The outer Configuration Option Length is consistent with the number of octets received.
All inner length fields remain within the outer option boundary.
The ADN satisfies the DNS wire-format requirements in .
The Address List contains complete AF/address entries and uses only AF values defined by this document.
SvcParam keys are strictly increasing and contain no duplicates.
Any port SvcParam has a non-zero value.
The encrypted DNS transport indicated by the configuration is supported by the implementation.
TLS identity validation can be performed using the ADN as specified in .

IPCP Negotiation The negotiation follows the Configure-Request, Configure-Ack, Configure-Nak, and Configure-Reject procedures defined by RFC 1661 .

Client Configure-Request A client MAY include Option 133 and/or Option 134 in a Configure-Request. To probe for encrypted DNS configuration without supplying a resolver address, the client may use an empty Address List. The client MAY include non-zero SvcParams in such a request to indicate requested transport capabilities or parameters. A client MUST NOT assume that an empty Address List in a Configure-Ack constitutes a usable resolver configuration unless an independent trusted discovery or bootstrap mechanism exists.

Server Response For a recognizable option whose value is unacceptable but for which an acceptable replacement can be constructed, the peer may use Configure-Nak as specified by RFC 1661. A Configure-Nak MUST NOT contain a malformed Option 133 or Option 134. If an option is unrecognized or cannot be negotiated, Configure-Reject is used according to RFC 1661. If an option is malformed and no valid replacement can be represented, the implementation follows the general malformed packet processing rules rather than constructing an invalid Configure-Nak.

Duplicate Options A Configure-Request containing more than one Option 133 instance or more than one Option 134 instance is invalid. An implementation MUST NOT apply a "last received wins" rule to duplicate resolver options.

Primary and Secondary Resolver Selection Option 133 identifies the primary resolver and Option 134 identifies the secondary resolver. Both may be negotiated independently. Failover from the primary resolver to the secondary resolver is local client policy. A client MAY try the secondary resolver after connectivity-level failures of the primary resolver, subject to local policy. Such failover does not require IPCP renegotiation. Authentication failure of the primary resolver MUST NOT automatically trigger failover to the secondary resolver merely to bypass authentication failure. A client MAY use the secondary resolver when independently configured or trusted according to local policy. This document defines exactly two encrypted DNS resolver configurations. Negotiation and selection of more than two encrypted DNS resolvers are outside the scope of this document.

Coexistence with RFC 1877 When an encrypted DNS resolver configuration is successfully negotiated, the client SHOULD prefer the encrypted DNS service for DNS resolution. If the client cannot establish or use the negotiated encrypted DNS service, the client MAY use plaintext DNS configuration obtained through RFC 1877 , subject to local policy and the requirements of RFC 1877. The IPCP Configuration Options defined in this document do not negotiate an operating mode. The presence of an encrypted DNS configuration does not prohibit the use of RFC 1877 plaintext DNS when the encrypted DNS service is unavailable. Failure of the encrypted DNS service does not require IPCP renegotiation.

Encrypted DNS Transport Use The protocol identifier and SvcParams determine which encrypted DNS transport is used. Implementations supporting DoT use RFC 7858 . Implementations supporting DoH use RFC 8484 together with RFC 9461 when the DoH path is specified. Implementations supporting DoQ use RFC 9250 . When SvcParams Length is zero, DoT is the local default. A deployment requiring another transport SHOULD provide the necessary SvcParams explicitly.

Transport Mappings This document reuses existing protocol-specific parameter definitions rather than defining new ALPN, path, or port TLVs.

DoT uses the transport defined by RFC 7858 and the corresponding TLS service parameters.
DoH uses RFC 8484 and the dohpath parameter defined by RFC 9461 when a non-default path is required.
DoQ uses RFC 9250 and its applicable ALPN identifier.

ALPN values are encoded using the SvcParam representation specified by RFC 9460 and are not encoded as comma-separated strings or as a new IPCP-specific TLV.

TLS Authentication The IP addresses in the Address List are network locators. They are not TLS identities. When establishing an encrypted DNS connection, the client MUST validate the server identity using the ADN and the applicable TLS certificate identity rules in RFC 9525 . An implementation MUST NOT treat possession of an IP address from an IPCP option as sufficient evidence of the resolver's TLS identity. If certificate validation against the ADN fails, the corresponding resolver configuration MUST NOT be treated as an authenticated encrypted DNS resolver.

Security Considerations The IPCP Configuration Options defined in this document provide encrypted DNS resolver configuration. Receipt of an IPCP option does not by itself authenticate the DNS service or prove that the option was supplied by a trusted network operator. When establishing an encrypted DNS connection, the client MUST authenticate the resolver according to the applicable encrypted DNS transport specification. In particular, the Address List identifies network locations and the ADN identifies the DNS service for purposes of TLS server identity validation. An IP address received in an IPCP option MUST NOT be treated as sufficient evidence of the resolver's identity. The IPCP options defined by this document do not provide cryptographic protection for the configuration itself. Deployments that require protection of PPP control traffic should use an appropriate PPP security mechanism when available. When the encrypted DNS service cannot be established or used, the behavior defined in this document permits the client to use plaintext DNS configuration obtained through RFC 1877 . Such fallback does not provide the confidentiality and integrity properties of encrypted DNS. PPP does not require applications to use the resolver configuration negotiated by this protocol. Implementations may apply local resolver-selection policy, provided that such policy is consistent with the requirements of this document.

IANA Considerations IANA is requested to assign the following values from the "PPP IPCP Configuration Option Types" registry:

133 — Primary Encrypted DNS Server.
134 — Secondary Encrypted DNS Server.

The allocation is subject to the policy defined by RFC 3818 . This document does not create a new SvcParam registry or a new address-family registry. The AF values 1 and 2 used in this document are local field values corresponding to IPv4 and IPv6. Additional AF values would require a revision of this document.

Implementation Considerations Implementations should validate all nested lengths before attempting to parse an ADN, Address List, or SvcParams field. In particular, an implementation should not use an inner length to read beyond the enclosing PPP Configuration Option. Implementations should preserve the distinction between a missing SvcParams field, a zero-length SvcParams field, and an SvcParams field containing encoded parameters. Under the format defined here, a zero-length SvcParams field selects the local DoT default. Implementations should reject duplicate SvcParam keys and should not silently reinterpret an unsupported address-family value. Implementations should keep resolver selection and failover decisions separate from IPCP option parsing. In particular, authentication failure should not be converted into an automatic secondary-resolver bypass.