draft-ietf-taps-arch-17.txt   draft-ietf-taps-arch-18.txt 
TAPS Working Group T. Pauly, Ed. TAPS Working Group T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track B. Trammell, Ed. Intended status: Standards Track B. Trammell, Ed.
Expires: 30 September 2023 Google Switzerland GmbH Expires: 1 December 2023 Google Switzerland GmbH
A. Brunstrom A. Brunstrom
Karlstad University Karlstad University
G. Fairhurst G. Fairhurst
University of Aberdeen University of Aberdeen
C. Perkins C. Perkins
University of Glasgow University of Glasgow
29 March 2023 30 May 2023
An Architecture for Transport Services An Architecture for Transport Services
draft-ietf-taps-arch-17 draft-ietf-taps-arch-18
Abstract Abstract
This document describes an architecture for exposing transport This document describes an architecture for exposing transport
protocol features to applications for network communication, a protocol features to applications for network communication, a
Transport Services system. The Transport Services Application Transport Services system. The Transport Services Application
Programming Interface (API) is based on an asynchronous, event-driven Programming Interface (API) is based on an asynchronous, event-driven
interaction pattern. This API uses messages for representing data interaction pattern. This API uses messages for representing data
transfer to applications, and describes how implementations can use transfer to applications, and describes how implementations can use
multiple IP addresses, multiple protocols, and multiple paths, and multiple IP addresses, multiple protocols, and multiple paths, and
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 30 September 2023. This Internet-Draft will expire on 1 December 2023.
Copyright Notice Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the Copyright (c) 2023 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 30 skipping to change at page 2, line 30
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specification of Requirements . . . . . . . . . . . . . . 5 1.3. Specification of Requirements . . . . . . . . . . . . . . 5
1.4. Glossary of Key Terms . . . . . . . . . . . . . . . . . . 5 1.4. Glossary of Key Terms . . . . . . . . . . . . . . . . . . 5
2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. API Model . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 9 2.1. Event-Driven API . . . . . . . . . . . . . . . . . . . . 9
2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 10 2.2. Data Transfer Using Messages . . . . . . . . . . . . . . 10
2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 11 2.3. Flexible Implementation . . . . . . . . . . . . . . . . . 11
2.4. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 12
3. API and Implementation Requirements . . . . . . . . . . . . . 12 3. API and Implementation Requirements . . . . . . . . . . . . . 12
3.1. Provide Common APIs for Common Features . . . . . . . . . 13 3.1. Provide Common APIs for Common Features . . . . . . . . . 13
3.2. Allow Access to Specialized Features . . . . . . . . . . 14 3.2. Allow Access to Specialized Features . . . . . . . . . . 14
3.3. Select Between Equivalent Protocol Stacks . . . . . . . . 15 3.3. Select Between Equivalent Protocol Stacks . . . . . . . . 15
3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 16 3.4. Maintain Interoperability . . . . . . . . . . . . . . . . 16
4. Transport Services Architecture and Concepts . . . . . . . . 16 4. Transport Services Architecture and Concepts . . . . . . . . 16
4.1. Transport Services API Concepts . . . . . . . . . . . . . 18 4.1. Transport Services API Concepts . . . . . . . . . . . . . 18
4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 19 4.1.1. Endpoint Objects . . . . . . . . . . . . . . . . . . 20
4.1.2. Connections and Related Objects . . . . . . . . . . . 20 4.1.2. Connections and Related Objects . . . . . . . . . . . 20
4.1.3. Pre-Establishment . . . . . . . . . . . . . . . . . . 21 4.1.3. Pre-establishment . . . . . . . . . . . . . . . . . . 21
4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 22 4.1.4. Establishment Actions . . . . . . . . . . . . . . . . 22
4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 23 4.1.5. Data Transfer Objects and Actions . . . . . . . . . . 23
4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 24 4.1.6. Event Handling . . . . . . . . . . . . . . . . . . . 24
4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 24 4.1.7. Termination Actions . . . . . . . . . . . . . . . . . 25
4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 25 4.1.8. Connection Groups . . . . . . . . . . . . . . . . . . 25
4.2. Transport Services Implementation . . . . . . . . . . . . 25 4.2. Transport Services Implementation . . . . . . . . . . . . 26
4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 27 4.2.1. Candidate Gathering . . . . . . . . . . . . . . . . . 27
4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 27 4.2.2. Candidate Racing . . . . . . . . . . . . . . . . . . 27
4.2.3. Separating Connection Contexts . . . . . . . . . . . 28 4.2.3. Separating Connection Contexts . . . . . . . . . . . 28
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. Security and Privacy Considerations . . . . . . . . . . . . . 28 6. Security and Privacy Considerations . . . . . . . . . . . . . 29
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
8.1. Normative References . . . . . . . . . . . . . . . . . . 30 8.1. Normative References . . . . . . . . . . . . . . . . . . 30
8.2. Informative References . . . . . . . . . . . . . . . . . 30 8.2. Informative References . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
Many application programming interfaces (APIs) to perform transport Many application programming interfaces (APIs) to perform transport
networking have been deployed, perhaps the most widely known and networking have been deployed, perhaps the most widely known and
imitated being the BSD Socket [POSIX] interface (Socket API). The imitated being the BSD Socket [POSIX] interface (Socket API). The
naming of objects and functions across these APIs is not consistent, naming of objects and functions across these APIs is not consistent
and varies depending on the protocol being used. For example, and varies depending on the protocol being used. For example,
sending and receiving streams of data is conceptually the same for sending and receiving streams of data is conceptually the same for
both an unencrypted Transmission Control Protocol (TCP) stream and both an unencrypted Transmission Control Protocol (TCP) stream and
operating on an encrypted Transport Layer Security (TLS) [RFC8446] operating on an encrypted Transport Layer Security (TLS) [RFC8446]
stream over TCP, but applications cannot use the same socket send() stream over TCP, but applications cannot use the same socket send()
and recv() calls on top of both kinds of connections. Similarly, and recv() calls on top of both kinds of connections. Similarly,
terminology for the implementation of transport protocols varies terminology for the implementation of transport protocols varies
based on the context of the protocols themselves: terms such as based on the context of the protocols themselves: terms such as
"flow", "stream", "message", and "connection" can take on many "flow", "stream", "message", and "connection" can take on many
different meanings. This variety can lead to confusion when trying different meanings. This variety can lead to confusion when trying
skipping to change at page 5, line 51 skipping to change at page 5, line 51
* Candidate Protocol Stack: One Protocol Stack that can be used by * Candidate Protocol Stack: One Protocol Stack that can be used by
an application for a Connection during racing. an application for a Connection during racing.
* Client: The peer responsible for initiating a Connection. * Client: The peer responsible for initiating a Connection.
* Clone: A Connection that was created from another Connection, and * Clone: A Connection that was created from another Connection, and
forms a part of a Connection Group. forms a part of a Connection Group.
* Connection: Shared state of two or more endpoints that persists * Connection: Shared state of two or more endpoints that persists
across Messages that are transmitted and received between these across Messages that are transmitted and received between these
Endpoints [RFC8303]. Endpoints [RFC8303]. When this document (and other Transport
Services documents) use the capitalized "Connection" term, it
refers to a Connection Object that is being offered by the
Transport Services system, as opposed to more generic uses of the
word "connection".
* Connection Group: A set of Connections that shares properties and * Connection Group: A set of Connections that shares properties and
caches. caches.
* Connection Property: A Transport Property that controls per- * Connection Property: A Transport Property that controls per-
Connection behavior of a Transport Services implementation. Connection behavior of a Transport Services implementation.
* Endpoint: An identifier for one side of a Connection (local or * Endpoint: An identifier for one side of a Connection (local or
remote), such as a hostnames or URL. remote), such as a hostnames or URL.
* Equivalent Protocol Stacks: Protocol stacks that can be safely * Equivalent Protocol Stacks: Protocol Stacks that can be safely
swapped or raced in parallel during establishment of a Connection. swapped or raced in parallel during establishment of a Connection.
* Event: A primitive that is invoked by an endpoint [RFC8303]. * Event: A primitive that is invoked by an endpoint [RFC8303].
* Framer: A data translation layer that can be added to a Connection * Framer: A data translation layer that can be added to a Connection
to define how application-layer Messages are transmitted over a to define how application-layer Messages are transmitted over a
Protocol Stack. Protocol Stack.
* Local Endpoint: A representation of the application's identifier * Local Endpoint: A representation of the application's identifier
for itself that it uses for a Connection. for itself that it uses for a Connection.
skipping to change at page 6, line 44 skipping to change at page 6, line 47
protocol by a primitive [RFC8303]. protocol by a primitive [RFC8303].
* Path: A representation of an available set of properties that a * Path: A representation of an available set of properties that a
Local Endpoint can use to communicate with a Remote Endpoint. Local Endpoint can use to communicate with a Remote Endpoint.
* Peer: An endpoint application party to a Connection. * Peer: An endpoint application party to a Connection.
* Preconnection: an object that represents a Connection that has not * Preconnection: an object that represents a Connection that has not
yet been established. yet been established.
* Preference: A preference to prohibit, avoid, ignore prefer or * Preference: A preference to prohibit, avoid, ignore, prefer, or
require a specific Transport Feature. require a specific Transport Feature.
* Primitive: A function call that is used to locally communicate * Primitive: A function call that is used to locally communicate
between an application and an endpoint, which is related to one or between an application and an endpoint, which is related to one or
more Transport Features [RFC8303]. more Transport Features [RFC8303].
* Protocol Instance: A single instance of one protocol, including * Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive any state necessary to establish connectivity or send and receive
Messages. Messages.
skipping to change at page 7, line 50 skipping to change at page 8, line 5
* Transport Feature: A specific end-to-end feature that the * Transport Feature: A specific end-to-end feature that the
transport layer provides to an application. transport layer provides to an application.
* Transport Property: A property that expresses requirements, * Transport Property: A property that expresses requirements,
prohibitions and preferences [RFC8095]. prohibitions and preferences [RFC8095].
* Transport Service: A set of transport features, without an * Transport Service: A set of transport features, without an
association to any given framing protocol, that provides a association to any given framing protocol, that provides a
complete service to an application. complete service to an application.
* Transport Service System: The Transport Service implementation and * Transport Services System: The Transport Services implementation
the Transport Services API and the Transport Services API
2. API Model 2. API Model
The traditional model of using sockets for networking can be The traditional model of using sockets for networking can be
represented as follows: represented as follows:
* Applications create connections and transfer data using the Socket * Applications create connections and transfer data using the Socket
API. API.
* The Socket API provides the interface to the implementations of * The Socket API provides the interface to the implementations of
skipping to change at page 9, line 35 skipping to change at page 9, line 35
interface for an application to create Connections and transfer data. interface for an application to create Connections and transfer data.
It combines interfaces for multiple interaction patterns into a It combines interfaces for multiple interaction patterns into a
unified whole. By combining name resolution with connection unified whole. By combining name resolution with connection
establishment and data transfer in a single API, it allows for more establishment and data transfer in a single API, it allows for more
flexible implementations to provide path and transport protocol flexible implementations to provide path and transport protocol
agility on the application's behalf. agility on the application's behalf.
The Transport Services implementation [I-D.ietf-taps-impl] implements The Transport Services implementation [I-D.ietf-taps-impl] implements
the transport layer protocols and other functions needed to send and the transport layer protocols and other functions needed to send and
receive data. It is responsible for mapping the API to a specific receive data. It is responsible for mapping the API to a specific
available transport protocol stack and managing the available network available transport Protocol Stack and managing the available network
interfaces and paths. interfaces and paths.
There are key differences between the Transport Services architecture There are key differences between the Transport Services architecture
and the architecture of the Socket API: the API of the Transport and the architecture of the Socket API: the API of the Transport
Services architecture is asynchronous and event-driven; it uses Services architecture is asynchronous and event-driven; it uses
messages for representing data transfer to applications; and it messages for representing data transfer to applications; and it
describes how implementations can use multiple IP addresses, multiple describes how implementations can use multiple IP addresses, multiple
protocols, multiple paths, and provide multiple application streams. protocols, multiple paths, and provide multiple application streams.
2.1. Event-Driven API 2.1. Event-Driven API
skipping to change at page 10, line 48 skipping to change at page 10, line 48
most applications need to interpret structure within this byte- most applications need to interpret structure within this byte-
stream. For example, HTTP/1.1 uses character delimiters to segment stream. For example, HTTP/1.1 uses character delimiters to segment
messages over a byte-stream [RFC9112]; TLS record headers carry a messages over a byte-stream [RFC9112]; TLS record headers carry a
version, content type, and length [RFC8446]; and HTTP/2 uses frames version, content type, and length [RFC8446]; and HTTP/2 uses frames
to segment its headers and bodies [RFC9113]. to segment its headers and bodies [RFC9113].
The Transport Services API represents data as messages, so that it The Transport Services API represents data as messages, so that it
more closely matches the way applications use the network. A more closely matches the way applications use the network. A
message-based abstraction provides many benefits, such as: message-based abstraction provides many benefits, such as:
* providing additional information to the protocol stack; * providing additional information to the Protocol Stack;
* the ability to associate deadlines with messages, for applications * the ability to associate deadlines with messages, for applications
that care about timing; that care about timing;
* the ability to control reliability, which messages to retransmit * the ability to control reliability, which messages to retransmit
when there is packet loss, and how best to make use of the data when there is packet loss, and how best to make use of the data
that arrived; that arrived;
* the ability to automatically assign messages and connections to * the ability to automatically assign messages and connections to
underlying transport connections to utilize multi-streaming and underlying transport connections to utilize multi-streaming and
pooled connections. pooled connections.
Allowing applications to interact with messages is backwards- Allowing applications to interact with messages is backwards-
compatible with existing protocols and APIs because it does not compatible with existing protocols and APIs because it does not
change the wire format of any protocol. Instead, it provides the change the wire format of any protocol. Instead, it provides the
protocol stack with additional information to allow it to make better Protocol Stack with additional information to allow it to make better
use of modern transport services, while simplifying the application's use of modern transport services, while simplifying the application's
role in parsing data. For protocols that natively use a streaming role in parsing data. For protocols that natively use a streaming
abstraction, framers (Section 4.1.5) bridge the gap between the two abstraction, framers (Section 4.1.5) bridge the gap between the two
abstractions. abstractions.
2.3. Flexible Implementation 2.3. Flexible Implementation
The Socket API for protocols like TCP is generally limited to The Socket API for protocols like TCP is generally limited to
connecting to a single address over a single interface. It also connecting to a single address over a single interface. It also
presents a single stream to the application. Software layers built presents a single stream to the application. Software layers built
skipping to change at page 12, line 19 skipping to change at page 12, line 19
over whether this information is used for a specific establishment, over whether this information is used for a specific establishment,
in order to allow tradeoffs between efficiency and linkability. in order to allow tradeoffs between efficiency and linkability.
Flexibility after connection establishment is also important. Flexibility after connection establishment is also important.
Transport protocols that can migrate between multiple network-layer Transport protocols that can migrate between multiple network-layer
interfaces need to be able to process and react to interface changes. interfaces need to be able to process and react to interface changes.
Protocols that support multiple application-layer streams need to Protocols that support multiple application-layer streams need to
support initiating and receiving new streams using existing support initiating and receiving new streams using existing
connections. connections.
2.4. Coexistence
Note that while the Transport Service architecture is designed as an
enhanced replacement for the Socket API, it need not replace it
entirely on a system or platform; indeed, incremental deployability
[RFC8170] requires coexistence. The architecture is therefore
designed such that it can run alongside (or, indeed, on top of) an
existing Socket API implementation; only applications built to the
Transport Services API are managed by the system's Transport Services
implementation.
3. API and Implementation Requirements 3. API and Implementation Requirements
A goal of the Transport Services architecture is to redefine the A goal of the Transport Services architecture is to redefine the
interface between applications and transports in a way that allows interface between applications and transports in a way that allows
the transport layer to evolve and improve without fundamentally the transport layer to evolve and improve without fundamentally
changing the contract with the application. This requires a careful changing the contract with the application. This requires a careful
consideration of how to expose the capabilities of protocols. This consideration of how to expose the capabilities of protocols. This
architecture also encompasses system policies that can influence and architecture also encompasses system policies that can influence and
inform how transport protocols use a network path or interface. inform how transport protocols use a network path or interface.
skipping to change at page 13, line 21 skipping to change at page 13, line 26
transport protocols [RFC8923]. If that minimal set is updated or transport protocols [RFC8923]. If that minimal set is updated or
expanded in the future, the Transport Services API ought to be expanded in the future, the Transport Services API ought to be
extended to match. extended to match.
An application can specify constraints and preferences for the An application can specify constraints and preferences for the
protocols, features, and network interfaces it will use via protocols, features, and network interfaces it will use via
Properties. Properties are used by an application to declare its Properties. Properties are used by an application to declare its
preferences for how the transport service should operate at each preferences for how the transport service should operate at each
stage in the lifetime of a connection. Transport Properties are stage in the lifetime of a connection. Transport Properties are
subdivided into Selection Properties, which specify which paths and subdivided into Selection Properties, which specify which paths and
protocol stacks can be used and are preferred by the application; Protocol Stacks can be used and are preferred by the application;
Connection Properties, which inform decisions made during connection Connection Properties, which inform decisions made during connection
establishment and fine-tune the established connection; and Message establishment and fine-tune the established connection; and Message
Properties, set on individual Messages. Properties, set on individual Messages.
It is RECOMMENDED that the Transport Services API offers properties It is RECOMMENDED that the Transport Services API offers properties
that are common to multiple transport protocols. This enables a that are common to multiple transport protocols. This enables a
Transport Services implementation to appropriately select between Transport Services implementation to appropriately select between
protocols that offer equivalent features. Similarly, it is protocols that offer equivalent features. Similarly, it is
RECOMMENDED that the Properties offered by the Transport Services API RECOMMENDED that the Properties offered by the Transport Services API
are applicable to a variety of network layer interfaces and paths, are applicable to a variety of network layer interfaces and paths,
skipping to change at page 14, line 16 skipping to change at page 14, line 23
There are applications that will need to control fine-grained details There are applications that will need to control fine-grained details
of transport protocols to optimize their behavior and ensure of transport protocols to optimize their behavior and ensure
compatibility with remote systems. It is therefore RECOMMENDED that compatibility with remote systems. It is therefore RECOMMENDED that
the Transport Services API and the Transport Services implementation the Transport Services API and the Transport Services implementation
permit more specialized protocol features to be used. permit more specialized protocol features to be used.
A specialized feature could be needed by an application only when A specialized feature could be needed by an application only when
using a specific protocol, and not when using others. For example, using a specific protocol, and not when using others. For example,
if an application is using TCP, it could require control over the if an application is using TCP, it could require control over the
User Timeout Option for TCP; these options would not take effect for User Timeout Option for TCP [RFC5482]; these options would not take
other transport protocols. In such cases, the API ought to expose effect for other transport protocols. In such cases, the API ought
the features in such a way that they take effect when a particular to expose the features in such a way that they take effect when a
protocol is selected, but do not imply that only that protocol could particular protocol is selected, but do not imply that only that
be used. For example, if the API allows an application to specify a protocol could be used. For example, if the API allows an
preference to use the User Timeout Option, communication would not application to specify a preference to use the User Timeout Option,
fail when a protocol such as QUIC is selected. communication would not fail when a protocol such as QUIC is
selected.
Other specialized features, however, can also be strictly required by Other specialized features, however, can also be strictly required by
an application and thus further constrain the set of protocols that an application and thus further constrain the set of protocols that
can be used. For example, if an application requires support for can be used. For example, if an application requires support for
automatic handover or failover for a connection, only protocol stacks automatic handover or failover for a connection, only Protocol Stacks
that provide this feature are eligible to be used, e.g., protocol that provide this feature are eligible to be used, e.g., Protocol
stacks that include a multipath protocol or a protocol that supports Stacks that include a multipath protocol or a protocol that supports
connection migration. A Transport Services API needs to allow connection migration. A Transport Services API needs to allow
applications to define such requirements and constrain the options applications to define such requirements and constrain the options
available to a Transport Services implementation. Since such options available to a Transport Services implementation. Since such options
are not part of the core/common features, it will generally be simple are not part of the core/common features, it will generally be simple
for an application to modify its set of constraints and change the for an application to modify its set of constraints and change the
set of allowable protocol features without changing the core set of allowable protocol features without changing the core
implementation. implementation.
To control these specialized features, the application can declare To control these specialized features, the application can declare
its preference – whether the presence of a specific feature is its preference – whether the presence of a specific feature is
prohibited, should be avoided, can be ignored, is preferred, or is prohibited, should be avoided, can be ignored, is preferred, or is
required in the Pre-Establishment phase. An implementation of a required in the pre-establishment phase. An implementation of a
Transport Services API would honor this preference and allow the Transport Services API would honor this preference and allow the
application to query the availability of each specialized feature application to query the availability of each specialized feature
after a successful establishment. after a successful establishment.
3.3. Select Between Equivalent Protocol Stacks 3.3. Select Between Equivalent Protocol Stacks
A Transport Services implementation can attempt and select between A Transport Services implementation can attempt and select between
multiple Protocol Stacks based on the Selection and Connection multiple Protocol Stacks based on the Selection and Connection
Properties communicated by the application, along with any security Properties communicated by the application, along with any security
parameters. The implementation can only attempt to use multiple parameters. The implementation can only attempt to use multiple
skipping to change at page 16, line 16 skipping to change at page 16, line 16
It is important to note that neither the Transport Services API It is important to note that neither the Transport Services API
[I-D.ietf-taps-interface] nor the guidelines for the Transport [I-D.ietf-taps-interface] nor the guidelines for the Transport
Service implementation [I-D.ietf-taps-impl] define new protocols or Service implementation [I-D.ietf-taps-impl] define new protocols or
protocol capabilities that affect what is communicated across the protocol capabilities that affect what is communicated across the
network. A Transport Services system MUST NOT require that a peer on network. A Transport Services system MUST NOT require that a peer on
the other side of a connection uses the same API or implementation. the other side of a connection uses the same API or implementation.
A Transport Services implementation acting as a connection initiator A Transport Services implementation acting as a connection initiator
is able to communicate with any existing endpoint that implements the is able to communicate with any existing endpoint that implements the
transport protocol(s) and all the required properties selected. transport protocol(s) and all the required properties selected.
Similarly, a Transport Services implementation acting as a listener Similarly, a Transport Services implementation acting as a Listener
can receive connections for any protocol that is supported from an can receive connections for any protocol that is supported from an
existing initiator that implements the protocol, independent of existing initiator that implements the protocol, independent of
whether the initiator uses the Transport Services architecture or whether the initiator uses the Transport Services architecture or
not. not.
A Transport Services system makes decisions that select protocols and A Transport Services system makes decisions that select protocols and
interfaces. In normal use, a given version of a Transport Services interfaces. In normal use, a given version of a Transport Services
system SHOULD result in consistent protocol and interface selection system SHOULD result in consistent protocol and interface selection
decisions for the same network conditions given the same set of decisions for the same network conditions given the same set of
Properties. This is intended to provide predictable outcomes to the Properties. This is intended to provide predictable outcomes to the
skipping to change at page 17, line 41 skipping to change at page 17, line 41
| | Protocol | | | | Protocol | |
+-------------+ Stack(s) +----------------------+ +-------------+ Stack(s) +----------------------+
+-------+--------+ +-------+--------+
V V
Network Layer Interface Network Layer Interface
Figure 3: Concepts and Relationships in the Transport Services Figure 3: Concepts and Relationships in the Transport Services
Architecture Architecture
The Transport Services Implementation includes the Cached State and The Transport Services Implementation includes the Cached State and
System Policy. The System Policy provides input from an operating System Policy.
system or other global preferences that can constrain or influence
how an implementation will gather Candidate Paths and Protocol Stacks The System Policy provides input from an operating system or other
and race the candidates when establishing a Connection. The Cached global preferences that can constrain or influence how an
State is the state and history that the implementation keeps for each implementation will gather Candidate Paths and Protocol Stacks and
set of associated endpoints that have previously been used. race the candidates when establishing a Connection. As the details
of System Policy configuration and enforcement are largely platform-
and implementation- dependent, and do not affect application-level
interoperability, the Transport Services API
[I-D.ietf-taps-interface] does not specify an interface for reading
or writing System Policy.
The Cached State is the state and history that the implementation
keeps for each set of associated endpoints that have previously been
used.
4.1. Transport Services API Concepts 4.1. Transport Services API Concepts
Fundamentally, a Transport Services API needs to provide connection Fundamentally, a Transport Services API needs to provide connection
objects (Section 4.1.2) that allow applications to establish objects (Section 4.1.2) that allow applications to establish
communication, and then send and receive data. These could be communication, and then send and receive data. These could be
exposed as handles or referenced objects, depending on the chosen exposed as handles or referenced objects, depending on the chosen
programming language. programming language.
Beyond the connection objects, there are several high-level groups of Beyond the connection objects, there are several high-level groups of
actions that any Transport Services API needs to provide: actions that any Transport Services API needs to provide:
* Pre-Establishment (Section 4.1.3) encompasses the properties that * Pre-establishment (Section 4.1.3) encompasses the properties that
an application can pass to describe its intent, requirements, an application can pass to describe its intent, requirements,
prohibitions, and preferences for its networking operations. prohibitions, and preferences for its networking operations.
These properties apply to multiple transport protocols, unless These properties apply to multiple transport protocols, unless
otherwise specified. Properties specified during Pre- otherwise specified. Properties specified during pre-
Establishment can have a large impact on the rest of the establishment can have a large impact on the rest of the
interface: they modify how establishment occurs, they influence interface: they modify how establishment occurs, they influence
the expectations around data transfer, and they determine the set the expectations around data transfer, and they determine the set
of events that will be supported. of events that will be supported.
* Establishment (Section 4.1.4) focuses on the actions that an * Establishment (Section 4.1.4) focuses on the actions that an
application takes on the connection objects to prepare for data application takes on the connection objects to prepare for data
transfer. transfer.
* Data Transfer (Section 4.1.5) consists of how an application * Data Transfer (Section 4.1.5) consists of how an application
represents the data to be sent and received, the functions represents the data to be sent and received, the functions
skipping to change at page 18, line 48 skipping to change at page 19, line 9
to interact with the underlying transport by querying state or to interact with the underlying transport by querying state or
updating maintenance options. updating maintenance options.
* Termination (Section 4.1.7) focuses on the methods by which data * Termination (Section 4.1.7) focuses on the methods by which data
transmission is stopped, and connection state is torn down. transmission is stopped, and connection state is torn down.
The diagram below provides a high-level view of the actions and The diagram below provides a high-level view of the actions and
events during the lifetime of a Connection object. Note that some events during the lifetime of a Connection object. Note that some
actions are alternatives (e.g., whether to initiate a connection or actions are alternatives (e.g., whether to initiate a connection or
to listen for incoming connections), while others are optional (e.g., to listen for incoming connections), while others are optional (e.g.,
setting Connection and Message Properties in Pre-Establishment) or setting Connection and Message Properties in pre-establishment) or
have been omitted for brevity and simplicity. have been omitted for brevity and simplicity.
Pre-Establishment : Established : Termination Pre-establishment : Established : Termination
----------------- : ----------- : ----------- ----------------- : ----------- : -----------
: : : :
+-- Local Endpoint : Message : +-- Local Endpoint : Message :
+-- Remote Endpoint : Receive() | : +-- Remote Endpoint : Receive() | :
+-- Transport Properties : Send() | : +-- Transport Properties : Send() | :
+-- Security Parameters : | : +-- Security Parameters : | :
| : | : | : | :
| InitiateWithSend() | Close() : | InitiateWithSend() | Close() :
| +---------------+ Initiate() +-----+------+ Abort() : | +---------------+ Initiate() +-----+------+ Abort() :
+---+ Preconnection |------------->| Connection |-----------> Closed +---+ Preconnection |------------->| Connection |-----------> Closed
skipping to change at page 19, line 28 skipping to change at page 19, line 35
| : | v : | : | v :
v : | Connection : v : | Connection :
+----------+ : | Ready : +----------+ : | Ready :
| Listener |----------------------+ : | Listener |----------------------+ :
+----------+ Connection Received : +----------+ Connection Received :
: : : :
Figure 4: The lifetime of a Connection object Figure 4: The lifetime of a Connection object
In this diagram, the lifetime of a Connection object is broken into In this diagram, the lifetime of a Connection object is broken into
three phases: Pre-Establishment, the Established state, and three phases: pre-establishment, the Established state, and
Termination. Termination.
Pre-Establishment is based around a Preconnection object, that Pre-establishment is based around a Preconnection object, that
contains various sub-objects that describe the properties and contains various sub-objects that describe the properties and
parameters of desired Connections (Local and Remote Endpoints, parameters of desired Connections (Local and Remote Endpoints,
Transport Properties, and Security Parameters). A Preconnection can Transport Properties, and Security Parameters). A Preconnection can
be used to start listening for inbound connections, in which case a be used to start listening for inbound connections, in which case a
Listener object is created, or can be used to establish a new Listener object is created, or can be used to establish a new
connection directly using Initiate() (for outbound connections) or connection directly using Initiate (for outbound connections) or
Rendezvous() (for peer-to-peer connections). Rendezvous (for peer-to-peer connections).
Once a Connection is in the Established state, an application can Once a Connection is in the Established state, an application can
send and receive Message objects, and receive state updates. send and receive Message objects, and receive state updates.
Closing or aborting a connection, either locally or from the peer, Closing or aborting a connection, either locally or from the peer,
can terminate a connection. can terminate a connection.
4.1.1. Endpoint Objects 4.1.1. Endpoint Objects
* Endpoint: An endpoint represents an identifier for one side of a * Endpoint: An endpoint represents an identifier for one side of a
skipping to change at page 21, line 27 skipping to change at page 21, line 33
- Message Properties (Section 4.1.5): Message Properties can be - Message Properties (Section 4.1.5): Message Properties can be
specified as defaults on a Preconnection or a Connection, and specified as defaults on a Preconnection or a Connection, and
can also be specified during data transfer to affect specific can also be specified during data transfer to affect specific
Messages. Messages.
* Listener: A Listener object accepts incoming transport protocol * Listener: A Listener object accepts incoming transport protocol
connections from Remote Endpoints and generates corresponding connections from Remote Endpoints and generates corresponding
Connection objects. It is created from a Preconnection object Connection objects. It is created from a Preconnection object
that specifies the type of incoming Connections it will accept. that specifies the type of incoming Connections it will accept.
4.1.3. Pre-Establishment 4.1.3. Pre-establishment
* Selection Properties: The Selection Properties consist of the * Selection Properties: The Selection Properties consist of the
properties that an application can set to influence the selection properties that an application can set to influence the selection
of paths between the Local and Remote Endpoints, to influence the of paths between the Local and Remote Endpoints, to influence the
selection of transport protocols, or to configure the behavior of selection of transport protocols, or to configure the behavior of
generic transport protocol features. These properties can take generic transport protocol features. These properties can take
the form of requirements, prohibitions, or preferences. Examples the form of requirements, prohibitions, or preferences. Examples
of properties that influence path selection include the interface of properties that influence path selection include the interface
type (such as a Wi-Fi connection, or a Cellular LTE connection), type (such as a Wi-Fi connection, or a Cellular LTE connection),
requirements around the largest Message that can be sent, or requirements around the largest Message that can be sent, or
skipping to change at page 22, line 29 skipping to change at page 22, line 36
* Initiate: The primary action that an application can take to * Initiate: The primary action that an application can take to
create a Connection to a Remote Endpoint, and prepare any required create a Connection to a Remote Endpoint, and prepare any required
local or remote state to enable the transmission of Messages. For local or remote state to enable the transmission of Messages. For
some protocols, this will initiate a client-to-server style some protocols, this will initiate a client-to-server style
handshake; for other protocols, this will just establish local handshake; for other protocols, this will just establish local
state (e.g., with connectionless protocols such as UDP). The state (e.g., with connectionless protocols such as UDP). The
process of identifying options for connecting, such as resolution process of identifying options for connecting, such as resolution
of the Remote Endpoint, occurs in response to the Initiate call. of the Remote Endpoint, occurs in response to the Initiate call.
* Listen: Enables a listener to accept incoming connections. The * Listen: Enables a Listener to accept incoming connections. The
Listener will then create Connection objects as incoming Listener will then create Connection objects as incoming
connections are accepted (Section 4.1.6). Listeners by default connections are accepted (Section 4.1.6). Listeners by default
register with multiple paths, protocols, and Local Endpoints, register with multiple paths, protocols, and Local Endpoints,
unless constrained by Selection Properties and/or the specified unless constrained by Selection Properties and/or the specified
Local Endpoint(s). Connections can be accepted on any of the Local Endpoint(s). Connections can be accepted on any of the
available paths or endpoints. available paths or endpoints.
* Rendezvous: The action of establishing a peer-to-peer connection * Rendezvous: The action of establishing a peer-to-peer connection
with a Remote Endpoint. It simultaneously attempts to initiate a with a Remote Endpoint. It simultaneously attempts to initiate a
connection to a Remote Endpoint while listening for an incoming connection to a Remote Endpoint while listening for an incoming
skipping to change at page 23, line 4 skipping to change at page 23, line 11
occurs in response to the Rendezvous call. As with Listeners, the occurs in response to the Rendezvous call. As with Listeners, the
set of local paths and endpoints is constrained by Selection set of local paths and endpoints is constrained by Selection
Properties. If successful, the Rendezvous call returns a Properties. If successful, the Rendezvous call returns a
Connection object to represent the established peer-to-peer Connection object to represent the established peer-to-peer
connection. The processes by which connections are initiated connection. The processes by which connections are initiated
during a Rendezvous action will depend on the set of Local and during a Rendezvous action will depend on the set of Local and
Remote Endpoints configured on the Preconnection. For example, if Remote Endpoints configured on the Preconnection. For example, if
the Local and Remote Endpoints are TCP host candidates, then a TCP the Local and Remote Endpoints are TCP host candidates, then a TCP
simultaneous open [RFC9293] will be performed. However, if the simultaneous open [RFC9293] will be performed. However, if the
set of Local Endpoints includes server reflexive candidates, such set of Local Endpoints includes server reflexive candidates, such
as those provided by STUN, a Rendezvous action will race as those provided by STUN (Session Traversal Utilities for NAT)
candidates in the style of the ICE algorithm [RFC8445] to perform [RFC5389], a Rendezvous action will race candidates in the style
NAT binding discovery and initiate a peer-to-peer connection. of the ICE (Interactive Connection Establishment) algorithm
[RFC8445] to perform NAT binding discovery and initiate a peer-to-
peer connection.
4.1.5. Data Transfer Objects and Actions 4.1.5. Data Transfer Objects and Actions
* Message: A Message object is a unit of data that can be * Message: A Message object is a unit of data that can be
represented as bytes that can be transferred between two endpoints represented as bytes that can be transferred between two endpoints
over a transport connection. The bytes within a Message are over a transport connection. The bytes within a Message are
assumed to be ordered. If an application does not care about the assumed to be ordered. If an application does not care about the
order in which a peer receives two distinct spans of bytes, those order in which a peer receives two distinct spans of bytes, those
spans of bytes are considered independent Messages. Messages are spans of bytes are considered independent Messages. Messages are
sent in the payload of IP packet. One packet can carry one or sent in the payload of IP packet. One packet can carry one or
skipping to change at page 23, line 30 skipping to change at page 23, line 39
about Message transmission. They can be specified directly on about Message transmission. They can be specified directly on
individual Messages, or can be set on a Preconnection or individual Messages, or can be set on a Preconnection or
Connection as defaults. These properties might only apply to how Connection as defaults. These properties might only apply to how
a Message is sent (such as how the transport will treat a Message is sent (such as how the transport will treat
prioritization and reliability), but can also include properties prioritization and reliability), but can also include properties
that specific protocols encode and communicate to the Remote that specific protocols encode and communicate to the Remote
Endpoint. When receiving Messages, Message Properties can contain Endpoint. When receiving Messages, Message Properties can contain
information about the received Message, such as metadata generated information about the received Message, such as metadata generated
at the receiver and information signalled by the Remote Endpoint. at the receiver and information signalled by the Remote Endpoint.
For example, a Message can be marked with a Message Property For example, a Message can be marked with a Message Property
indicating that it is the final message on a connection. indicating that it is the final Message on a Connection.
* Send: The action to transmit a Message over a Connection to the * Send: The action to transmit a Message over a Connection to the
Remote Endpoint. The interface to Send can accept Message Remote Endpoint. The interface to Send can accept Message
Properties specific to how the Message content is to be sent. The Properties specific to how the Message content is to be sent. The
status of the Send operation is delivered back to the sending status of the Send operation is delivered back to the sending
application in an Event (Section 4.1.6). application in an event (Section 4.1.6).
* Receive: An action that indicates that the application is ready to * Receive: An action that indicates that the application is ready to
asynchronously accept a Message over a Connection from a Remote asynchronously accept a Message over a Connection from a Remote
Endpoint, while the Message content itself will be delivered in an Endpoint, while the Message content itself will be delivered in an
Event (Section 4.1.6). The interface to Receive can include event (Section 4.1.6). The interface to Receive can include
Message Properties specific to the Message that is to be delivered Message Properties specific to the Message that is to be delivered
to the application. to the application.
* Framer: A Framer is a data translation layer that can be added to * Framer: A Framer is a data translation layer that can be added to
a Connection. Framers allow extending a Connection's protocol a Connection. Framers allow extending a Connection's Protocol
stack to define how to encapsulate or encode outbound Messages, Stack to define how to encapsulate or encode outbound Messages,
and how to decapsulate or decode inbound data into Messages. In and how to decapsulate or decode inbound data into Messages. In
this way, message boundaries can be preserved when using a this way, message boundaries can be preserved when using a
Connection object, even with a protocol that otherwise presents Connection object, even with a protocol that otherwise presents
unstructured streams, such as TCP. This is designed based on the unstructured streams, such as TCP. This is designed based on the
fact that many of the current application protocols evolved over fact that many of the current application protocols evolved over
TCP, which does not provide message boundary preservation, and TCP, which does not provide message boundary preservation, and
since many of these protocols require message boundaries to since many of these protocols require message boundaries to
function, each application layer protocol has defined its own function, each application layer protocol has defined its own
framing. For example, when an HTTP application sends and receives framing. For example, when an HTTP application sends and receives
HTTP messages over a byte-stream transport, it must parse the HTTP messages over a byte-stream transport, it must parse the
skipping to change at page 26, line 10 skipping to change at page 26, line 20
4.2. Transport Services Implementation 4.2. Transport Services Implementation
This section defines the key concepts of the Transport Services This section defines the key concepts of the Transport Services
architecture. architecture.
* Transport Service implementation: This consists of all objects and * Transport Service implementation: This consists of all objects and
protocol instances used internally to a system or library to protocol instances used internally to a system or library to
implement the functionality needed to provide a transport service implement the functionality needed to provide a transport service
across a network, as required by the abstract interface. across a network, as required by the abstract interface.
* Transport Service system: This consists of the Transport Service * Transport Services system: This consists of the Transport Service
implementation and the Transport Services API. implementation and the Transport Services API.
* Path: Represents an available set of properties that a Local * Path: Represents an available set of properties that a Local
Endpoint can use to communicate with a Remote Endpoint, such as Endpoint can use to communicate with a Remote Endpoint, such as
routes, addresses, and physical and virtual network interfaces. routes, addresses, and physical and virtual network interfaces.
* Protocol Instance: A single instance of one protocol, including * Protocol Instance: A single instance of one protocol, including
any state necessary to establish connectivity or send and receive any state necessary to establish connectivity or send and receive
Messages. Messages.
skipping to change at page 29, line 33 skipping to change at page 29, line 42
appropriately. In cases where applications use an interface to appropriately. In cases where applications use an interface to
provide sensitive keying material, e.g., access to private keys or provide sensitive keying material, e.g., access to private keys or
copies of pre-shared keys (PSKs), key use needs to be validated and copies of pre-shared keys (PSKs), key use needs to be validated and
scoped to the intended protocols and roles. For example, if an scoped to the intended protocols and roles. For example, if an
application provides a certificate to only be used as client application provides a certificate to only be used as client
authentication for outbound TLS and QUIC connections, the Transport authentication for outbound TLS and QUIC connections, the Transport
Services system MUST NOT use this automatically in other contexts Services system MUST NOT use this automatically in other contexts
(such as server authentication for inbound connections, or in other (such as server authentication for inbound connections, or in other
another security protocol handshake that is not equivalent to TLS). another security protocol handshake that is not equivalent to TLS).
A Transport Services system must not automatically fall back from A Transport Services system MUST NOT automatically fall back from
secure protocols to insecure protocols, or to weaker versions of secure protocols to insecure protocols, or to weaker versions of
secure protocols (see Section 3.3). For example, if an application secure protocols (see Section 3.3). For example, if an application
requests a specific version of TLS, but the desired version of TLS is requests a specific version of TLS, but the desired version of TLS is
not available, its connection will fail. As described in not available, its connection will fail. As described in
Section 3.3, the Transport Services API can allow applications to Section 3.3, the Transport Services API can allow applications to
specify minimum versions that are allowed to be used by the Transport specify minimum versions that are allowed to be used by the Transport
Services system. Services system.
7. Acknowledgements 7. Acknowledgements
skipping to change at page 30, line 45 skipping to change at page 31, line 6
M. Welzl, "Implementing Interfaces to Transport Services", M. Welzl, "Implementing Interfaces to Transport Services",
Work in Progress, Internet-Draft, draft-ietf-taps-impl-15, Work in Progress, Internet-Draft, draft-ietf-taps-impl-15,
9 March 2023, <https://datatracker.ietf.org/doc/html/ 9 March 2023, <https://datatracker.ietf.org/doc/html/
draft-ietf-taps-impl-15>. draft-ietf-taps-impl-15>.
[I-D.ietf-taps-interface] [I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G., Trammell, B., Welzl, M., Enghardt, R., Fairhurst, G.,
Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly, Kühlewind, M., Perkins, C., Tiesel, P. S., and T. Pauly,
"An Abstract Application Layer Interface to Transport "An Abstract Application Layer Interface to Transport
Services", Work in Progress, Internet-Draft, draft-ietf- Services", Work in Progress, Internet-Draft, draft-ietf-
taps-interface-19, 9 March 2023, taps-interface-20, 29 March 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-taps- <https://datatracker.ietf.org/doc/html/draft-ietf-taps-
interface-19>. interface-20>.
[POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology [POSIX] "IEEE Std. 1003.1-2008 Standard for Information Technology
-- Portable Operating System Interface (POSIX). Open -- Portable Operating System Interface (POSIX). Open
group Technical Standard: Base Specifications, Issue 7", group Technical Standard: Base Specifications, Issue 7",
2008. 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
DOI 10.17487/RFC5389, October 2008,
<https://www.rfc-editor.org/rfc/rfc5389>.
[RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option",
RFC 5482, DOI 10.17487/RFC5482, March 2009,
<https://www.rfc-editor.org/rfc/rfc5482>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <https://www.rfc-editor.org/rfc/rfc6265>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/rfc/rfc8095>. <https://www.rfc-editor.org/rfc/rfc8095>.
[RFC8170] Thaler, D., Ed., "Planning for Protocol Adoption and
Subsequent Transitions", RFC 8170, DOI 10.17487/RFC8170,
May 2017, <https://www.rfc-editor.org/rfc/rfc8170>.
[RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of [RFC8303] Welzl, M., Tuexen, M., and N. Khademi, "On the Usage of
Transport Features Provided by IETF Transport Protocols", Transport Features Provided by IETF Transport Protocols",
RFC 8303, DOI 10.17487/RFC8303, February 2018, RFC 8303, DOI 10.17487/RFC8303, February 2018,
<https://www.rfc-editor.org/rfc/rfc8303>. <https://www.rfc-editor.org/rfc/rfc8303>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2: [RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305, Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017, DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/rfc/rfc8305>. <https://www.rfc-editor.org/rfc/rfc8305>.
 End of changes. 45 change blocks. 
61 lines changed or deleted 102 lines changed or added

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