



ADD Working Group                                                 D. Liu
Internet-Draft                                          Jinan University
Intended status: Informational                                    Z. Yan
Expires: 22 September 2026                                         CNNIC
                                                                 J. Weng
                                                    Guangzhou University
                                                                 G. Geng
                                                                Y. Zhang
                                                        Jinan University
                                                           21 March 2026


        PPP IPCP Extensions for Encrypted DNS Server Negotiation
                 draft-liu-add-ppp-edns-negotiation-02

Abstract

   This document defines extensions to the Point-to-Point Protocol (PPP)
   Internet Protocol Control Protocol (IPCP) for negotiating encrypted
   DNS resolver configurations.  These extensions allow PPP peers to
   exchange information about encrypted DNS servers supporting protocols
   such as DNS over TLS (DoT), DNS over HTTPS (DoH), and DNS over QUIC
   (DoQ).  The design maintains backward compatibility with RFC 1877
   while addressing modern security requirements.

Status of This Memo

   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 22 September 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Liu, et al.             Expires 22 September 2026               [Page 1]

Internet-Draft              PPP Encrypted DNS                 March 2026


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Additional IPCP Configuration Options . . . . . . . . . . . .   3
     2.1.  Primary Encrypted DNS Server Option . . . . . . . . . . .   4
     2.2.  Secondary Encrypted DNS Server Option . . . . . . . . . .   5
     2.3.  DNS Encryption Parameters Option  . . . . . . . . . . . .   5
   3.  Negotiation Process . . . . . . . . . . . . . . . . . . . . .   6
     3.1.  Client Request Behavior . . . . . . . . . . . . . . . . .   6
     3.2.  Server Response Behavior  . . . . . . . . . . . . . . . .   7
     3.3.  Configuration Priority  . . . . . . . . . . . . . . . . .   7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     4.1.  Authentication  . . . . . . . . . . . . . . . . . . . . .   7
     4.2.  Privacy Protection  . . . . . . . . . . . . . . . . . . .   8
     4.3.  Downgrade Attacks . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Client Flexibility  . . . . . . . . . . . . . . . . . . .   8
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   6.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   9
   Future Considerations . . . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  Example Negotiations . . . . . . . . . . . . . . . .   9
     A.1.  Basic DoT Configuration . . . . . . . . . . . . . . . . .   9
     A.2.  DoH with Custom Path  . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   The Point-to-Point Protocol (PPP) [RFC1661] and its Ethernet
   adaptation, PPPoE ([RFC2516]) remain foundational technologies for
   authenticated network access, particularly in broadband and
   enterprise environments.

   PPP is widely used in scenarios such as:

   *  ISP broadband access (e.g., PPPoE for DSL/fiber authentication)




Liu, et al.             Expires 22 September 2026               [Page 2]

Internet-Draft              PPP Encrypted DNS                 March 2026


   *  Industrial control networks (serial PPP for SCADA/PLC
      communications)

   *  Cellular backhaul (PPP over GTP in 4G/5G user-plane data)

   *  Secure tunneling (PPP inside L2TP/IPsec or MPLS VPNs)

   Despite the rise of DHCP and IPv6 RA for configuration, PPP persists
   due to its fine-grained access control, negotiation flexibility, and
   compatibility with legacy systems.  However, traditional PPP IPCP
   extensions ([RFC1877]) only support plaintext DNS, exposing queries
   to surveillance and manipulation — a critical gap in an era where
   encrypted DNS (DoT [RFC7858], DoH [RFC8484], DoQ [RFC9250]) is
   essential for privacy and security.

   This document extends PPP IPCP to negotiate encrypted DNS resolvers,
   enabling:

   *  *Secure DNS by default*: Clients automatically adopt encrypted
      transports (e.g., DoT on port 853) without manual configuration.

   *  *Operator-managed trust*: ISPs can provide authenticated DNS
      resolvers (via ADNs and certificate fingerprints) to enable secure
      DNS by default.  Clients retain the flexibility to use other
      resolvers if configured accordingly.

   *  *Backward compatibility*: Coexists with RFC 1877 options, allowing
      fallback to plaintext DNS if needed.

   By integrating encrypted DNS negotiation into PPP, this specification
   bridges the gap between legacy access protocols and modern security
   requirements, ensuring confidentiality and integrity for DNS queries
   across diverse deployment scenarios — from home broadband to critical
   infrastructure.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174].

2.  Additional IPCP Configuration Options

   This document defines three new IPCP Configuration Options:






Liu, et al.             Expires 22 September 2026               [Page 3]

Internet-Draft              PPP Encrypted DNS                 March 2026


   +======+===========================+================================+
   | Type | Name                      | Description                    |
   +======+===========================+================================+
   | 133  | Primary Encrypted DNS     | Primary encrypted DNS server   |
   +------+---------------------------+--------------------------------+
   | 134  | Secondary Encrypted DNS   | Secondary encrypted DNS server |
   +------+---------------------------+--------------------------------+
   | 135  | DNS Encryption            | Additional encryption          |
   |      | Parameters                | parameters                     |
   +------+---------------------------+--------------------------------+

                                  Table 1

2.1.  Primary Encrypted DNS Server Option

   This option provides the primary encrypted DNS resolver
   configuration.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Protocol   |    Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          ADN Length           |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   ~                   Authentication Domain Name (ADN)            ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Port Number          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   ~                 Additional Parameters (Optional)              ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 1: Primary Encrypted DNS Option Format

   Fields:

   *  Type: 133

   *  Length: ≥ 6

   *  Protocol: 1=DoT, 2=DoH, 3=DoQ

   *  Reserved: MUST be 0

   *  ADN Length: Length of ADN field




Liu, et al.             Expires 22 September 2026               [Page 4]

Internet-Draft              PPP Encrypted DNS                 March 2026


   *  ADN: Resolver FQDN (RFC 1035 format)

   *  Port Number: Defaults to 853 (DoT/DoQ) or 443 (DoH) if 0

2.2.  Secondary Encrypted DNS Server Option

   This option provides a fallback encrypted DNS resolver configuration
   when the primary server is unavailable.  It follows the same
   structure as the Primary Encrypted DNS Server Option (Section 2.1)
   but uses a distinct type code.

   *  Type: 134

2.3.  DNS Encryption Parameters Option

   This option provides supplemental configuration parameters required
   for specific encrypted DNS protocols.  It enables negotiation of
   advanced settings that cannot be conveyed in the primary/secondary
   options alone.

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |Server Selector|  Param Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Param Length          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   ~                       Parameter Value                        ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 2: DNS Encryption Parameters Option Format

   Fields:

   *  Type: 135

   *  Length: ≥ 5

   *  Server Selector (1 octet):

   *  0x00 – Parameters apply to the Primary Encrypted DNS Server
      (Option 133)

   *  0x01 – Parameters apply to the Secondary Encrypted DNS Server
      (Option 134)

   *  Other values are reserved for future use



Liu, et al.             Expires 22 September 2026               [Page 5]

Internet-Draft              PPP Encrypted DNS                 March 2026


   *  Param Type (1 octet):

   *  0x01 – ALPN Protocols

   *  0x02 – DoH Path Template

   *  0x03–0xFF – Reserved

   *  Param Length: Length of Parameter Value

   *  Parameter Value: Protocol-specific data

   Defined Parameters:

   1.  *ALPN Protocols (Type 0x01)* – Value: comma-separated list of
       ALPN identifiers as defined in [RFC7301].  Example: “dot,h2” for
       DoT and HTTP/2.

   2.  *DoH Path Template (Type 0x02)* – Value: URI path for DoH
       requests (UTF-8).  Example: “/dns-query”.

   When multiple Option 135 instances are received for the same server
   (specified by the Server Selector) with the same Param Type, the
   client MUST use the parameter value from the last received Option 135
   in the IPCP negotiation.  This follows the standard negotiation
   behavior of IPCP (RFC 1332), ensuring determinism.  Parameter options
   are processed independently per server.  If a client receives an
   unrecognized Param Type or an invalid value, it SHOULD ignore that
   specific option and continue processing other valid options.

3.  Negotiation Process

   This section specifies the state machine and processing rules for
   encrypted DNS option negotiation.  The procedure follows standard
   IPCP negotiation defined in [RFC1332], with additional validation
   specific to encrypted DNS parameters.

3.1.  Client Request Behavior

   1.  The client MAY include Option 133 and/or 134 in Configure-Request

   2.  To request configuration:

   *  Set ADN Length = 0

   *  Set Port Number = 0

   *  Omit ADN field



Liu, et al.             Expires 22 September 2026               [Page 6]

Internet-Draft              PPP Encrypted DNS                 March 2026


   3.  The client MAY include Option 135 to request specific parameters

3.2.  Server Response Behavior

   1.  If server supports encrypted DNS:

   *  For valid requests: Respond with Configure-Ack

   *  For invalid/empty requests: Respond with Configure-Nak containing
      valid configuration

   2.  If server doesn't support encrypted DNS:

   *  Respond with Configure-Reject

   If the client includes a DNS Encryption Parameters Option (Option
   135) in a Configure-Request, the server responds in one of the
   following ways:

   *  If the server supports *all* of the requested parameters, it MUST
      include them unchanged in a Configure-Ack.

   *  If the server supports a *subset* of the requested parameters, or
      supports alternative values for them, it SHOULD respond with a
      Configure-Nak containing a valid DNS Encryption Parameters Option
      with the parameters (and values) it is willing to support.

   *  If the server does not support encrypted DNS negotiation at all,
      or does not recognize Option 135, it SHOULD respond with a
      Configure-Reject for this option.

3.3.  Configuration Priority

   When both Options 129 (RFC 1877) and 133 or 134 are present:

   1.  Clients SHOULD prefer encrypted DNS (Option 133/134)

   2.  Clients MAY fall back to plaintext DNS if encrypted connection
       fails

4.  Security Considerations

4.1.  Authentication

   *  Clients MUST validate the server's TLS certificate against the
      provided ADN





Liu, et al.             Expires 22 September 2026               [Page 7]

Internet-Draft              PPP Encrypted DNS                 March 2026


   *  Clients SHOULD perform standard TLS certificate validation by
      checking that the server's certificate is valid, chains to a
      trusted root, and matches the provided Authentication Domain Name
      (ADN)

4.2.  Privacy Protection

   *  While the options themselves may be transmitted in cleartext, they
      enable encrypted DNS transport

   *  Implementations SHOULD use PPP encryption (e.g., MPPE) when
      available

4.3.  Downgrade Attacks

   *  Active attackers may remove encrypted DNS options from IPCP
      negotiation

   *  Clients SHOULD maintain a history of successful encrypted DNS
      usage and warn when unexpectedly unavailable

4.4.  Client Flexibility

   The DNS resolver addresses negotiated via PPP IPCP are intended as
   configuration suggestions.  Implementations MAY allow users to
   manually override these settings or fall back to other resolvers, as
   PPP itself does not enforce DNS usage.  This flexibility ensures that
   end-user choice is not restricted by network-provided configuration.

5.  IANA Considerations

   This document has no IANA actions.

6.  Acknowledgments

   This work is supported by the National Key Research and Development
   Program of China (No. 2022YFB3103000).  The authors would like to
   thank Dan Wing from Cisco for his useful input.

7.  References

7.1.  Normative References

   [RFC1661]  IETF, "The Point-to-Point Protocol (PPP)", RFC 1661, July
              1994, <https://www.rfc-editor.org/rfc/rfc1661>.

   [RFC1332]  IETF, "PPP Internet Protocol Control Protocol", RFC 1332,
              May 1992, <https://www.rfc-editor.org/rfc/rfc1332>.



Liu, et al.             Expires 22 September 2026               [Page 8]

Internet-Draft              PPP Encrypted DNS                 March 2026


   [RFC2119]  IETF, "Key words for use in RFCs", RFC 2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC7301]  IETF, "Transport Layer Security (TLS) Application-Layer
              Protocol Negotiation Extension", RFC 7301, July 2014,
              <https://www.rfc-editor.org/rfc/rfc7301>.

   [RFC8174]  IETF, "Ambiguity of Uppercase", RFC 8174, May 2017,
              <https://www.rfc-editor.org/rfc/rfc8174>.

   [RFC7858]  IETF, "Specification for DNS over TLS", RFC 7858, May
              2016, <https://www.rfc-editor.org/rfc/rfc7858>.

   [RFC8484]  IETF, "DNS Queries over HTTPS", RFC 8484, October 2018,
              <https://www.rfc-editor.org/rfc/rfc8484>.

   [RFC9250]  IETF, "DNS over Dedicated QUIC", RFC 9250, May 2022,
              <https://www.rfc-editor.org/rfc/rfc9250>.

   [RFC2516]  IETF, "PPP over Ethernet", RFC 2516, February 1999,
              <https://www.rfc-editor.org/rfc/rfc2516>.

7.2.  Informative References

   [RFC1877]  IETF, "PPP IPCP Extensions for Name Server Addresses",
              RFC 1877, December 1995,
              <https://www.rfc-editor.org/rfc/rfc1877>.

   [RFC9460]  IETF, "Service Binding via DNS", RFC 9460, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9460>.

Future Considerations

   This document focuses on PPP IPCP.  Future work may explore analogous
   extensions for other configuration protocols, such as IPv6 Router
   Advertisements (RAs) or DHCP, to enable encrypted DNS negotiation in
   those contexts.

Appendix A.  Example Negotiations

A.1.  Basic DoT Configuration










Liu, et al.             Expires 22 September 2026               [Page 9]

Internet-Draft              PPP Encrypted DNS                 March 2026


   Client: Configure-Request
     Option 133:
       Type: 133, Length: 10, Protocol: 1 (DoT),
       ADN Len: 0, Port: 0

   Server: Configure-Nak
     Option 133:
       Type: 133, Length: 22, Protocol: 1 (DoT),
       ADN Len: 14, ADN: "dot.example.com",
       Port: 853

A.2.  DoH with Custom Path

   Client: Configure-Request
     Option 133:
       Type: 133, Length: 10, Protocol: 2 (DoH),
       ADN Len: 0, Port: 0
     Option 135:
       Type: 135, Length: 8,
       Param Type: 2 (DoH Path), Value: "/dns-query"

   Server: Configure-Ack
     Option 133:
       Type: 133, Length: 22, Protocol: 2 (DoH),
       ADN Len: 14, ADN: "doh.example.com",
       Port: 443
     Option 135:
       Type: 135, Length: 8,
       Param Type: 2 (DoH Path), Value: "/dns-query"

Authors' Addresses

   Dongjie Liu
   Jinan University
   Email: dongjieliu8917@gmail.com


   Zhiwei Yan
   CNNIC
   Email: yanzhiwei@cnnic.cn


   Jian Weng
   Guangzhou University
   Email: cryptjweng@gmail.com






Liu, et al.             Expires 22 September 2026              [Page 10]

Internet-Draft              PPP Encrypted DNS                 March 2026


   Guanggang Geng
   Jinan University
   Email: guanggang.geng@gmail.com


   Yinyan Zhang
   Jinan University
   Email: csyyzhang@gmail.com











































Liu, et al.             Expires 22 September 2026              [Page 11]
