]>

martenseemann@gmail.com

Web and Internet Transport MASQUE masque connect-ip qlog This document defines qlog events for CONNECT-IP packet processing and representations for its capsules, including the DNS and PREF64 configuration extensions. It extends the HTTP event schema defined in the HTTP/3 qlog document. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Multiplexed Application Substrate over QUIC Encryption Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction CONNECT-IP () uses capsules to exchange address assignments, address requests, and routing information. defines additional capsules for DNS and PREF64 configuration. This document defines how these capsules and IP packet processing are represented in qlog (). Packet events record forwarding decisions for inputs from the peer and the local application, including rejected inputs and generated ICMP responses. Capsule representations use the HTTP events defined in .

Conventions and Definitions 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 when, and only when, they appear in all capitals, as shown here. The data types are defined using CDDL (). The uint8, uint16, uint32, uint64, hexstring, and RawInfo types are defined in . ECN is defined in .

Event Schemas The schemas defined in and extend the http namespace defined in . Implementations SHOULD include the URIs of the schemas they use, together with the HTTP event schema URI, in the trace's event_schemas field, as described in .

Draft Event Schema Identification Until this document is published as an RFC, implementations MUST NOT use the unversioned event schema URIs. Instead, they MUST append a hyphen and the two-digit draft number to each extension identifier. For draft 00, the URIs are urn:ietf:params:qlog:events:http#connect-ip-00 and urn:ietf:params:qlog:events:http#connect-ip-dns-00.

Capsule Encoding Capsule representations extend the $HTTPCapsule type socket defined in . These representations are used in the capsule field of http:capsule_created and http:capsule_parsed events. The event's stream_id identifies the CONNECT-IP request stream, allowing multiple sessions and application protocols to share a trace. Sequence fields preserve the order of entries in the capsule. Empty sequences are represented by empty arrays. Integer fields contain their numeric values without the variable-length integer encoding. In capsule representations, the optional raw field uses RawInfo. Its length includes the capsule's Type, Length, and Value fields; payload_length is the length of the Value field. Both exclude HTTP DATA frame headers.

CONNECT-IP Schema This schema defines capsule representations and packet processing events for . Its URI is urn:ietf:params:qlog:events:http#connect-ip.

Capsules

ADDRESS_ASSIGN ConnectIPAddressAssignCapsule represents the ADDRESS_ASSIGN capsule defined in . Each assigned address records its Request ID and IP prefix. Unsolicited assignments retain Request ID 0. Refused assignments retain the prefix 0.0.0.0/32 or ::/128, as specified in .

ADDRESS_REQUEST ConnectIPAddressRequestCapsule represents the ADDRESS_REQUEST capsule defined in . Each requested address records its Request ID and requested IP prefix, including an unspecified address when the sender has no preference for a particular address.

ROUTE_ADVERTISEMENT ConnectIPRouteAdvertisementCapsule represents the ROUTE_ADVERTISEMENT capsule defined in . Each range records its inclusive start and end addresses and its IP Protocol value. A protocol value of 0 retains its meaning of allowing all protocols.

Packet Processing The http:connect_ip_packet_processed event (Base importance) records an IP packet after processing, its forwarding decision, and any generated ICMP response. stream_id identifies the CONNECT-IP request stream. forwarded means handed to the application or accepted by HTTP for transmission. source identifies the input as coming from the application or peer. packet describes it before forwarding changes. icmp_response records a generated response and its destination. Capsule and packet events SHOULD be ordered to reflect the address and route state used for each decision. A local change can take effect when its capsule is created and queued.

IP Packets Header fields retain their wire values; unavailable fields are omitted. IPv6 extension headers appear in wire order. upper_layer_protocol identifies the protocol after them. For raw, length is the observed packet length, payload_length excludes IP and extension headers, and data may contain a prefix of the packet.

ICMP quoted_packet describes the packet quoted by an ICMP error. mtu is the advertised MTU for Packet Too Big or Fragmentation Needed. ICMP raw excludes the IP header; payload_length excludes the ICMP header.

DNS and PREF64 Capsule Schema This schema defines representations for the capsules in . Its URI is urn:ietf:params:qlog:events:http#connect-ip-dns.

DNS_ASSIGN ConnectIPDNSAssignCapsule represents the DNS_ASSIGN capsule defined in . Each configuration records its nameservers, internal domains, and search domains. Domain names retain the presentation format used in the capsule, including empty strings where permitted by . Each service parameter records its numeric SvcParamKey and its SvcParamValue wire bytes as a hexadecimal string. Parameters are listed in ascending key order.

PREF64 ConnectIPPREF64Capsule represents the PREF64 capsule defined in . The 96 address bits carried in the capsule are followed by 32 zero bits to form the IPv6 address.

Common Data Types These types are shared by both event schemas.

IPAddress An IP address can be represented as text, hexadecimal bytes, or a redacted value. Human-readable IPv4 and IPv6 addresses use dotted-decimal notation and , respectively.

IPPrefix An IP prefix is a textual address, a slash, and a decimal prefix length, for example 192.0.2.0/24 or 2001:db8::/64.

Security Considerations The security and privacy considerations in apply. Headers, configuration, and raw data can reveal network topology, user activity, and application data. Implementations should minimize capture and protect logs.

IANA Considerations This document requests two entries in the "qlog event schema URIs" registry defined in .

CONNECT-IP Schema

Event schema URI:

urn:ietf:params:qlog:events:http#connect-ip

Namespace:

http

Event Types:

connect_ip_packet_processed

Description:

Capsule representations and packet processing events for CONNECT-IP.

Reference:

of this document.

DNS and PREF64 Capsule Schema

Event schema URI:

urn:ietf:params:qlog:events:http#connect-ip-dns

Namespace:

http

Event Types:

None. This schema extends the capsule data types of existing events.

Description:

Capsule representations for the CONNECT-IP DNS and PREF64 extensions.

Reference:

of this document.

Normative References Akamai Meta Cloudflare qlog provides extensible structured logging for network protocols, allowing for easy sharing of data that benefits common debug and analysis methods and tooling. This document describes key concepts of qlog: formats, files, traces, events, and extension points. This definition includes the high-level log file schemas, and generic event schemas. Requirements and guidelines for creating protocol- specific event schemas are also presented. All schemas are defined independent of serialization format, allowing logs to be represented in various ways such as JSON, CSV, or protobuf. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Akamai Meta Cloudflare This document defines qlog event schemas containing concrete events for the core HTTP/3 protocol and selected extensions. It also defines an http namespace for the Capsule Protocol. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. Akamai Meta Cloudflare This document describes a qlog event schema containing concrete qlog event definitions and their metadata for the core QUIC protocol and selected extensions. Note to Readers Note to RFC editor: Please remove this section before publication. Feedback and discussion are welcome at https://github.com/quicwg/qlog (https://github.com/quicwg/qlog). Readers are advised to refer to the "editor's draft" at that URL for an up-to-date version of this document. This document describes how to proxy IP packets in HTTP. This protocol is similar to UDP proxying in HTTP but allows transmitting arbitrary IP packets. More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an HTTP server that acts as an IP proxy. This document updates RFC 9298. Google LLC Zscaler Proxying IP in HTTP allows building a VPN through HTTP load balancers. However, at the time of writing, that mechanism lacks a way to communicate network configuration details such as DNS information or IPv6 NAT64 prefixes (PREF64). In contrast, most existing VPN protocols provide mechanisms to exchange such configuration information. This document defines extensions that convey DNS and PREF64 configuration using HTTP capsules. This mechanism supports encrypted DNS transports and can be used to inform peers about network translation prefixes for IPv6/IPv4 synthesis. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text. While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users. This document defines a canonical textual representation format. It does not define a format for internal storage, such as within an application or database. It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format. [STANDARDS-TRACK] In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.