#[repr(transparent)]pub struct Alpn(pub Vec<String>);
Expand description
draft-ietf-dnsop-svcb-https-03 SVCB and HTTPS RRs for DNS, February 2021
6.1. "alpn" and "no-default-alpn"
The "alpn" and "no-default-alpn" SvcParamKeys together indicate the
set of Application Layer Protocol Negotiation (ALPN) protocol
identifiers [ALPN] and associated transport protocols supported by
this service endpoint.
As with Alt-Svc [AltSvc], the ALPN protocol identifier is used to
identify the application protocol and associated suite of protocols
supported by the endpoint (the "protocol suite"). Clients filter the
set of ALPN identifiers to match the protocol suites they support,
and this informs the underlying transport protocol used (such as
QUIC-over-UDP or TLS-over-TCP).
ALPNs are identified by their registered "Identification Sequence"
("alpn-id"), which is a sequence of 1-255 octets.
alpn-id = 1*255OCTET
The presentation "value" SHALL be a comma-separated list
(Appendix A.1) of one or more "alpn-id"s.
The wire format value for "alpn" consists of at least one "alpn-id"
prefixed by its length as a single octet, and these length-value
pairs are concatenated to form the SvcParamValue. These pairs MUST
exactly fill the SvcParamValue; otherwise, the SvcParamValue is
malformed.
For "no-default-alpn", the presentation and wire format values MUST
be empty. When "no-default-alpn" is specified in an RR, "alpn" must
also be specified in order for the RR to be "self-consistent"
(Section 2.4.3).
Each scheme that uses this SvcParamKey defines a "default set" of
supported ALPNs, which SHOULD NOT be empty. To determine the set of
protocol suites supported by an endpoint (the "SVCB ALPN set"), the
client adds the default set to the list of "alpn-id"s unless the "no-
default-alpn" SvcParamKey is present. The presence of an ALPN
protocol in the SVCB ALPN set indicates that this service endpoint,
described by TargetName and the other parameters (e.g. "port") offers
service with the protocol suite associated with this ALPN protocol.
ALPN protocol names that do not uniquely identify a protocol suite
(e.g. an Identification Sequence that can be used with both TLS and
DTLS) are not compatible with this SvcParamKey and MUST NOT be
included in the SVCB ALPN set.
To establish a connection to the endpoint, clients MUST
1. Let SVCB-ALPN-Intersection be the set of protocols in the SVCB
ALPN set that the client supports.
2. Let Intersection-Transports be the set of transports (e.g. TLS,
DTLS, QUIC) implied by the protocols in SVCB-ALPN-Intersection.
3. For each transport in Intersection-Transports, construct a
ProtocolNameList containing the Identification Sequences of all
the client's supported ALPN protocols for that transport, without
regard to the SVCB ALPN set.
For example, if the SVCB ALPN set is ["http/1.1", "h3"], and the
client supports HTTP/1.1, HTTP/2, and HTTP/3, the client could
attempt to connect using TLS over TCP with a ProtocolNameList of
["http/1.1", "h2"], and could also attempt a connection using QUIC,
with a ProtocolNameList of ["h3"].
Once the client has constructed a ClientHello, protocol negotiation
in that handshake proceeds as specified in [ALPN], without regard to
the SVCB ALPN set.
With this procedure in place, an attacker who can modify DNS and
network traffic can prevent a successful transport connection, but
cannot otherwise interfere with ALPN protocol selection. This
procedure also ensures that each ProtocolNameList includes at least
one protocol from the SVCB ALPN set.
Clients SHOULD NOT attempt connection to a service endpoint whose
SVCB ALPN set does not contain any supported protocols. To ensure
consistency of behavior, clients MAY reject the entire SVCB RRSet and
fall back to basic connection establishment if all of the RRs
indicate "no-default-alpn", even if connection could have succeeded
using a non-default alpn.
For compatibility with clients that require default transports, zone
operators SHOULD ensure that at least one RR in each RRSet supports
the default transports.
Tuple Fields§
§0: Vec<String>
Trait Implementations§
Source§impl<'r> BinDecodable<'r> for Alpn
impl<'r> BinDecodable<'r> for Alpn
Source§fn read(decoder: &mut BinDecoder<'r>) -> ProtoResult<Self>
fn read(decoder: &mut BinDecoder<'r>) -> ProtoResult<Self>
This expects the decoder to be limited to only this field, i.e. the end of input for the decoder is the end of input for the fields
The wire format value for "alpn" consists of at least one "alpn-id"
prefixed by its length as a single octet, and these length-value
pairs are concatenated to form the SvcParamValue. These pairs MUST
exactly fill the SvcParamValue; otherwise, the SvcParamValue is
malformed.
Source§fn from_bytes(bytes: &'r [u8]) -> ProtoResult<Self>
fn from_bytes(bytes: &'r [u8]) -> ProtoResult<Self>
Returns the object in binary form
Source§impl BinEncodable for Alpn
impl BinEncodable for Alpn
Source§fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>
fn emit(&self, encoder: &mut BinEncoder<'_>) -> ProtoResult<()>
The wire format value for “alpn” consists of at least one “alpn-id” prefixed by its length as a single octet, and these length-value pairs are concatenated to form the SvcParamValue. These pairs MUST exactly fill the SvcParamValue; otherwise, the SvcParamValue is malformed.
impl Eq for Alpn
impl StructuralPartialEq for Alpn
Auto Trait Implementations§
impl Freeze for Alpn
impl RefUnwindSafe for Alpn
impl Send for Alpn
impl Sync for Alpn
impl Unpin for Alpn
impl UnwindSafe for Alpn
Blanket Implementations§
Source§impl<T> BorrowMut<T> for Twhere
T: ?Sized,
impl<T> BorrowMut<T> for Twhere
T: ?Sized,
Source§fn borrow_mut(&mut self) -> &mut T
fn borrow_mut(&mut self) -> &mut T
Mutably borrows from an owned value. Read more
Source§impl<T> CloneToUninit for Twhere
T: Clone,
impl<T> CloneToUninit for Twhere
T: Clone,
Source§unsafe fn clone_to_uninit(&self, dst: *mut T)
unsafe fn clone_to_uninit(&self, dst: *mut T)
🔬This is a nightly-only experimental API. (
clone_to_uninit
)