are not modified by this document.  In case of aggregates the A-Label is treated as an S-Label and it is not modified as well. <del> To support outgoing DetNet MPLS over IP, an implementation MUST support the provisioning of IP/UDP header information in place of sets of F-Labels.  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet flows and therefore, when PRF is supported, multiple IP/UDP headers MAY be provisioned. When multiple IP/UDP headers are provisioned for a particular </del> <ins> 4. To support outgoing DetNet MPLS over UDP/IP, an implementation MUST support the provisioning of UDP/IP header information in addition or in place of sets of F-Label(s).  Note that multiple sets of F-Labels can be provisioned to support PRF on transmitted DetNet MPLS flows and therefore, when PRF is supported, multiple UDP/IP headers MAY be provisioned. [Note: PRF is an MPLS function.  It produces member flows.  Member flows have 1to1 mapping to UDP/IP headers.  So why are multiple headers provisioned?  Delete next sentence?] When multiple UDP/IP headers are provisioned for a particular </ins> outgoing DetNet IP flow, a copy of the outgoing packet, including the <del> pushed S-Label, MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. </del> <ins> pushed S-Label (and optional F-label(s)), MUST be made for each.  The headers for each outgoing packet MUST be based on the configuration information and as defined in RFC7510, with one exception.  The one exception is that the UDP Source Port value MUST be set to uniquely identify the DetNet (forwarding sub-layer) flow.  The packet MUST then be handed as a DetNet IP packet, per I-D.ietf-detnet-ip. [Note: What about IPv4 Type of Service and IPv6 Traffic Class Fields? Do we intend to set them?] </ins> To support receive processing an implementation MUST also support the <del> provisioning of received IP/UDP header information.  When S-Labels are taken from platform label space, all that is required is to provision that receiving IP/UDP encapsulated DetNet MPLS packets is permitted.  Once the IP/UDP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, IP/UDP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app- flows based on the combination of S-Label and incoming IP/UDP header. Normal receive processing, including PEOF can then take place. </del> <ins> provisioning of received UDP/IP header information. </ins> <del> 4. </del> <ins> [Note: Are the receiving nodes T-PE nodes?  Why?] When S-Labels are taken from platform label space, all that is required is to provision that receiving UDP/IP encapsulated DetNet MPLS packets is permitted.  Once the UDP/IP header is stripped, the S-label uniquely identifies the app-flow.  When S-Labels are not taken from platform label space, UDP/IP header information MUST be provisioned.  The provisioned information MUST then be used to identify incoming app-flows based on the combination of S-Label and incoming IP/UDP header.  Normal receive processing, including PEOF can then take place. 5. The following summarizes the set of information that is needed to identify individual and aggregated DetNet flows: IPv4 and IPv6 source address field. IPv4 and IPv6 source address prefix length, where a zero (0) value effectively means that the address field is ignored. IPv4 and IPv6 destination address field. IPv4 and IPv6 destination address prefix length, where a zero (0) effectively means that the address field is ignored. IPv4 protocol field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv6 next header field.  Only UDP is allowed, and the ability to ignore this field, e.g., via configuration of the value zero (0), is desirable. IPv4 Type of Service and IPv6 Traffic Class Fields. IPv4 Type of Service and IPv6 Traffic Class Field Bitmask, where a zero (0) effectively means that theses fields are ignored. UDP Source Port.  Exact and wildcard matching is required.  Port ranges can optionally be used. This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller or management plane. Information identifying a DetNet flow is ordered and implementations use the first match.  This can, for example, be used to provide a DetNet service for a specific UDP flow, with unique Source and Destination Port field values, while providing a different service for the aggregate of all other flows with that same UDP Destination Port value. It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific resources needed to provided the traffic treatment needed to meet each flow's service requirements.  This applies for aggregated and individual flows. 6. </ins> The security considerations of DetNet in general are discussed in I- D.ietf-detnet-architecture and I-D.ietf-detnet-security.  MPLS and IP


mpls and I-D.ietf-detnet-ip.  This draft does not have additional security considerations. <del> 5. </del> <ins> 7. </ins> This document makes no IANA requests.


This sequence of native DNS wire format records enables easier generation of the data structure on the server and easier verification of the data on client by means of existing DNS library <del> functions.  However this document describes the data structure in sufficient detail that implementers if they desire can write their own code to do this. </del> <ins> functions. </ins> Each RRset in the chain is composed of a sequence of wire format DNS resource records.  The format of the resource record is described in RFC1035, Section 3.2.1. <ins> The resource records that make up a RRset all have the same owner, type and class, but different RDATA as specified RFC2181, Section 5. </ins> Each RRset in the sequence is followed by its associated RRsig record <del> set.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </del> <ins> set.  This RRset has the same owner and class as the preceding RRset, but has type RRSIG.  The Type Covered field in the RDATA of the RRsigs identifies the type of the preceding RRset as described in RFC4034, Section 3.  The RRsig record wire format is described in RFC4034, Section 3.1.  The signature portion of the RDATA, as described in the same section, is the following: </ins> where RRSIG_RDATA is the wire format of the RRSIG RDATA fields with the Signer's Name field in canonical form and the signature field


1. <del> RFC5280 specifies several extended key purpose identifiers for X.509 certificates.  In addition, several extended key purpose identifiers were addedRFC7299 as public OIDs under the IANA PKIX Extended key purpose identifiers arc.  While usage of the any extended key usage value is bad practice for publicly trusted certificates, there is no public and general extended key purpose identifier explicitly assigned for Document Signing certificates.  The current practice is to use id-kp-emailProtection, id-kp-codeSigning or vendor defined Object IDs for general document signing purposes. </del> <ins> RFC5280 specifies several extended key usages for X.509 certificates. In addition, several extended key usage had been addedRFC7299 as public OID under the IANA repository.  While usage of any extended key usage is bad practice for publicly trusted certificates, there are no public and general extended key usage explicitly assigned for Document Signing certificates.  The current practice is to use id-kp- emailProtection, id-kp-codeSigning or vendor defined Object ID for general document signing purposes. </ins> In circumstances where code signing and S/MIME certificates are also widely used for document signing, the technical or policy changes


5. A DNS client that already knows the name of an Encrypted Resolver can <del> use DEER to discover details about all supported encrypted DNS </del> <ins> use DDR to discover details about all supported encrypted DNS </ins> protocols.  This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name


6. <del> Resolver deployments that support DEER are advised to consider the </del> <ins> Resolver deployments that support DDR are advised to consider the </ins> following points. 6.1.


6.1. <del> If a caching forwarder consults multiple resolvers, it may be possible for it to cache records for the "resolver.arpa" Special Use Domain Name (SUDN) for multiple resolvers.  This may result in clients sending queries intended to discover Designated Resolvers for resolver "foo" and receiving answers for resolvers "foo" and "bar". A client will successfully reject unintended connections because the authenticated discovery will fail or the resolver addresses do not match.  Clients that attempt unauthenticated connections to resolvers discovered through SVCB queries run the risk of connecting to the wrong server in this scenario. To prevent unnecessary traffic from clients to incorrect resolvers, DNS caching resolvers SHOULD NOT cache results for the "resolver.arpa" SUDN other than for Designated Resolvers under their control. </del> <ins> A DNS forwarder SHOULD NOT forward queries for "resolver.arpa" upstream.  This prevents a client from receiving an SVCB record that will fail to authenticate because the forwarder's IP address is not in the upstream resolver's Designated Resolver's TLS certificate SAN field.  A DNS forwarder which already acts as a completely blind forwarder MAY choose to forward these queries when the operator expects that this does not apply, either because the operator knows the upstream resolver does have the forwarder's IP address in its TLS certificate's SAN field or that the operator expects clients of the unencrypted resolver to use the SVCB information opportunistically. Operators who choose to forward queries for "resolver.arpa" upstream should note that client behavior is never guaranteed and use of DDR by a resolver does not communicate a requirement for clients to use the SVCB record when it cannot be authenticated. </ins> 6.2.


mechanism for DNS clients to use DNS records to discover a resolver's encrypted DNS configuration.  This mechanism can be used to move from unencrypted DNS to encrypted DNS when only the IP address of a <del> resolver is known.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities. </del> <ins> resolver is known.  This mechanism is designed to be limited to cases where unencrypted resolvers and their designated resolvers are operated by the same entity or cooperating entities.  It can also be used to discover support for encrypted DNS protocols when the name of an encrypted resolver is known. </ins> 1.


7. <del> Since client can receive DNS SVCB answers over unencrypted DNS, on- </del> <ins> Since clients can receive DNS SVCB answers over unencrypted DNS, on- </ins> path attackers can prevent successful discovery by dropping SVCB packets.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated


but be operated by an attacker that is trying to observe or modify user queries without the knowledge of the client or network. <del> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this documents, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </del> If the IP address of a Designated Resolver differs from that of an Unencrypted Resolver, clients applying Authenicated Discovery (authenticated) MUST validate that the IP address of the Unencrypted


to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. <ins> The constraints on validation of Designated Resolvers specified here apply specifically to the automatic discovery mechanisms defined in this document, which are referred to as Authenticated Discovery and Opportunistic Discovery.  Clients MAY use some other mechanism to validate and use Designated Resolvers discovered using the DNS SVCB record.  However, use of such an alternate mechanism needs to take into account the attack scenarios detailed here. </ins> 8. 8.1.


queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. <ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. </ins> While the IP address of the Unencrypted Resolver is often provisioned over insecure mechanisms, it can also be provisioned securely, such as via manual configuration, a VPN, or on a network with protections


Since clients can receive DNS SVCB answers over unencrypted DNS, on- path attackers can prevent successful discovery by dropping SVCB <del> queries or answers.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. </del> <ins> queries or answers, and thus prevent clients from switching to use encrypted DNS.  Clients should be aware that it might not be possible to distinguish between resolvers that do not have any Designated Resolver and such an active attack.  To limit the impact of discovery queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


Served DNS Zones" registry for 'resolver.arpa.' with the description "DNS Resolver Special-Use Domain", listing this document as the reference. <ins> 8.2. In accordance with Section 5 of RFC6761, the answers to the following questions are provided relative to this document: Are human users expected to recognize these names as special and use them differently?  In what way? No.  This name is used automatically by DNS stub resolvers running on client devices on behalf of users, and users will never see this name directly. Are writers of application software expected to make their software recognize these names as special and treat them differently?  In what way? No.  There is no use case where a non-DNS application (covered by the next question) would need to use this name. Are writers of name resolution APIs and libraries expected to make their software recognize these names as special and treat them differently?  If so, how? Yes. DNS client implementors are expected to use this name when querying for a resolver's properties instead of records for the name itself.  DNS servers are expected to respond to queries for this name with their own properties instead of checking the matching zone as it would for normal domain names. Are developers of caching domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? Yes. Caching domain name servers should not forward queries for this name to avoid causing validation failures due to IP address mismatch. Are developers of authoritative domain name servers expected to make their implementations recognize these names as special and treat them differently?  If so, how? No.  DDR is designed for use by recursive resolvers.  Theoretically, an authoritative server could choose to support this name if it wants to advertise support for encrypted DNS protocols over plain-text DNS, but that scenario is covered by other work in the IETF DNSOP working group. Does this reserved Special-Use Domain Name have any potential impact on DNS server operators?  If they try to configure their authoritative DNS server as authoritative for this reserved name, will compliant name server software reject it as invalid?  Do DNS server operators need to know about that and understand why?  Even if the name server software doesn't prevent them from using this reserved name, are there other ways that it may not work as expected, of which the DNS server operator should be aware? This name is locally served, and any resolver which supports this name should never forward the query.  DNS server operators should be aware that records for this name will be used by clients to modify the way they connect to their resolvers. How should DNS Registries/Registrars treat requests to register this reserved domain name?  Should such requests be denied? Should such requests be allowed, but only to a specially- designated entity? IANA should hold the registration for this name.  Non-IANA requests to register this name should always be denied by DNS Registries/ Registrars. </ins>


should be able to use those records while safely ignoring the third record. <del> To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of RFC8484 regarding the avoidance of DNS- based references that block the completion of the TLS handshake. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-


policy or user input.  Details of such policy are out of scope of this document.  Clients MUST NOT automatically use a Designated Resolver without some sort of validation, such as the two methods <del> defined in this document or a future mechanism. </del> <ins> defined in this document or a future mechanism.  Use without validation can allow an attacker to direct traffic to an Encrypted Resolver that is unrelated to the original Unencrypted DNS Resolver, as described in security. </ins> A client MUST NOT re-use a designation discovered using the IP address of one Unencrypted DNS Resolver in place of any other


address on multiple different networks, a Designated Resolver that has been discovered on one network SHOULD NOT be reused on any of the other networks without repeating the discovery process for each <del> network. However, if a given Unencrypted DNS Resolver designates a Designated Resolver that does not use a private or local IP address and can be verified using the mechanism described in verified, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in verified.  This is a tradeoff between performance (by having no delay in establishing an encrypted DNS connection on the new network) and functionality (if the Unencrypted DNS Resolver intends to designate different Designated Resolvers based on the network from which clients connect). </del> <ins> network, since the same IP address may be used for different servers on the different networks. </ins> 4.2.


possible. If these checks fail, the client MUST NOT automatically use the <del> discovered Designated Resolver.  Additionally, the client SHOULD </del> <ins> discovered Designated Resolver if this designation was only discovered via a "_dns.resolver.arpa." query (if the designation was advertised directly by the network as described in dnr-interaction, the server can still be used).  Additionally, the client SHOULD </ins> suppress any further queries for Designated Resolvers using this Unencrypted DNS Resolver for the length of time indicated by the SVCB record's Time to Live (TTL) in order to avoid excessive queries that


If the Designated Resolver and the Unencrypted DNS Resolver share an IP address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check <del> (opportunistic). </del> <ins> (opportunistic).  If the IP address is not shared, opportunistic use allows for attackers to redirect queries to an unrelated Encrypted Resolver, as described in security. </ins> <del> If resolving the name of a Designated Resolver from an SVCB record yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. </del> <ins> Connections to a Designated Resolver can use a different IP address than the IP address of the Unencrypted DNS Resolver, such as if the process of resolving the SVCB service yields additional addresses. Even when a different IP address is used for the connection, the TLS certificate checks described in this section still apply for the original IP address of the Unencrypted DNS Resolver. </ins> 4.3.


6.4. DNS resolvers that support DDR by responding to queries for <del> _dns.resolver.arpa SHOULD treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </del> <ins> _dns.resolver.arpa MUST treat resolver.arpa as a locally served zone per RFC6303.  In practice, this means that resolvers SHOULD respond to queries of any type other than SVCB for _dns.resolver.arpa with NODATA and queries of any type for any domain name under </ins> resolver.arpa with NODATA. 6.5.


Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the


client or network. If the IP address of a Designated Resolver differs from that of an Unencrypted DNS Resolver, clients applying Verified Discovery (verified) MUST validate that the IP address of the Unencrypted DNS Resolver is covered by the SubjectAlternativeName of the Designated


Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver <del> have the same IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </del> <ins> have the same IP address, which SHOULD be a private or local IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </ins> control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here


This key is automatically mandatory if present.  (See Section 7 of SVCB for the definition of "automatically mandatory".) <ins> Support for the "port" key can be unsafe if the client has implicit elevated access to some network service (e.g. a local service that is inaccessible to remote parties) and that service uses a TCP-based protocol other than TLS.  A hostile DNS server might be able to manipulate this service by causing the client to send a specially crafted TLS SNI or session ticket that can be misparsed as a command or exploit.  To avoid such attacks, clients SHOULD NOT support the "port" key unless one of the following conditions applies: The client is being used with a DNS server that it trusts not attempt this attack. The client is being used in a context where implicit elevated access cannot apply. The client restricts the set of allowed TCP port values to exclude any ports where a confusion attack is likely to be possible (e.g. the "bad ports" list from the "Port blocking" section of FETCH). </ins> 4.3. These SvcParamKeys from SVCB apply to the "dns" scheme without


defined for the DNS. Note that this document only clarifies requirements of name server <del> software implementations.  It does not change any requirements on data placed in DNS zones or registries. </del> <ins> software implementations.  It does not introduce or change any requirements on data placed in DNS zones or registries.  In other words, this document only makes requirements on "available glue records" (i.e., those given in a zone), but does not make requirements regarding their presence in a zone.  If some glue records are absent from a given zone, an authoritative name server may be unable to return a useful referral response for the corresponding domain.  The IETF may want to consider a separate update to the requirements for including glue in zone data, beyond those given in RFC1034 and RFC1035. </ins> 1.1.


5. This section defines the terms used for the systems that act as DNS <del> clients, DNS servers, or both. </del> <ins> clients, DNS servers, or both.  In the RFCs, DNS servers are sometimes called "name servers", "nameservers", or just "servers". There is no formal definition of DNS server, but the RFCs generally assume that it is an Internet server that listens for queries and sends responses using the DNS protocol defined in RFC1035 and its successors. </ins> For terminology specific to the public DNS root server system, see RSSAC026.  That document defines terms such as "root server", "root


of resolver (some of which are defined below), and understanding the use of the term depends on understanding the context. <ins> A related term is "resolve", which is not formally defined in RFC1034 or RFC1035.  An imputed definition might be "asking a question that consists of a domain name, class, and type, and receiving some sort of answer".  Similarly, an imputed definition of "resolution" might be "the answer received from resolving". </ins> A resolver that cannot perform all resolution itself.  Stub resolvers generally depend on a recursive resolver to undertake the actual resolution function.  Stub resolvers are discussed but


simplifications are available.  Instead of being configured with (or discovering) the service registration domain, the (proposed) special- use domain name (see RFC6761) "default.service.arpa" is used.  The <del> details of how SRP server(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </del> <ins> details of how SRP registrar(s) are discovered will be specific to the constrained network, and therefore we do not suggest a specific </ins> mechanism here. <del> SRP clients on constrained networks are expected to receive from the network a list of SRP servers with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP server addresses.  It is the responsibility of the SRP server supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </del> <ins> SRP requestors on constrained networks are expected to receive from the network a list of SRP registrars with which to register.  It is the responsibility of a Constrained-Node Network supporting SRP to provide one or more SRP registrar addresses.  It is the responsibility of the SRP registrar supporting a Constrained-Node Network to handle the updates appropriately.  In some network environments, updates may be accepted directly into a local "default.service.arpa" zone, which has only local visibility.  In other network environments, updates for names ending in "default.service.arpa" may be rewritten internally to names with broader visibility. </ins> 2.1.3.


An instruction is a Host Description Instruction if, for the appropriate hostname, it contains <ins> A and/or AAAA records that are not of of sufficient scope to be validly published in a DNS zone can be ignored by the SRP server, which could result in a host description effectively containing zero reachable addresses even when it contains one or more addresses. For example, if a link-scope address or IPv4 autoconfiguration address is provided by the SRP requestor, the SRP registrar could not publish this in a DNS zone.  However, in some situations, the SRP registrar may make the records available through a mechanism such as an advertising proxy only on the specific link from which the SRP update originated; in such a situation, locally-scoped records are still valid. </ins> 2.3.2. An SRP Update MUST include zero or more Service Discovery


Service Registration Protocol for DNS-Based Service Discovery <del> draft-ietf-dnssd-srp-13 </del> <ins> draft-ietf-dnssd-srp-14 </ins> Abstract


record MUST contain the same public key.  The update is signed using SIG(0), using the private key that corresponds to the public key in the KEY record.  The lifetimes of the records in the update is set <del> using the EDNS(0) Update Lease option I-D.sekar-dns-ul. </del> <ins> using the EDNS(0) Update Lease option I-D.ietf-dnssd-update-lease. </ins> The KEY record in Service Description updates MAY be omitted for brevity; if it is omitted, the SRP registrar MUST behave as if the


Because the DNS-SD registration protocol is automatic, and not managed by humans, some additional bookkeeping is required.  When an update is constructed by the SRP requestor, it MUST include an <del> EDNS(0) Update Lease Option I-D.sekar-dns-ul.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </del> <ins> EDNS(0) Update Lease Option I-D.ietf-dnssd-update-lease.  The Update Lease Option contains two lease times: the Lease Time and the Key Lease Time. </ins> These leases are promises, similar to RFC2131, from the SRP requestor that it will send a new update for the service registration before


There are two primary use cases for this protocol. <del> The primary one is to prevent on-path network devices from </del> <ins> The primary use case is to prevent on-path network devices from </ins> interfering with native DNS operations.  This interference includes, but is not limited to, spoofing DNS responses, blocking DNS requests, and tracking.  HTTP authentication and proxy friendliness are


A secondary use case is web applications that want to access DNS information.  Standardizing an HTTPS mechanism allows this to be done <del> in a way consistent with the cross-origin resource sharing CORS security model of the web and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </del> <ins> in a way consistent with the cross-origin resource sharing security model of the web CORS and also integrate the caching mechanisms of DNS with those of HTTP.  These applications may be interested in </ins> using a different media type than traditional clients. <del> [ This paragraph is to be removed when this document is published as an RFC ] Note that these use cases are different than those in a </del> <ins> [[ This paragraph is to be removed when this document is published as an RFC ]] Note that these use cases are different than those in a </ins> similar protocol described at I-D.ietf-dnsop-dns-wireformat-http. The use case for that protocol is proxying DNS queries over HTTP instead of over DNS itself.  The use cases in this document all


defined. The protocol must use a secure transport that meets the <del> requirements for modern https://. </del> <ins> requirements for modern HTTPS. </ins> 4.1.


5.1. The media type is "application/dns-udpwireformat".  The body is the <del> DNS on-the-wire format is defined in RFC1035.  The body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. </del> <ins> DNS on-the-wire format is defined in RFC1035. When using the GET method, the body MUST be encoded with base64url RFC4648.  Padding characters for base64url MUST NOT be included. When using the POST method, the body is not encoded. </ins> DNS API clients using the DNS wire format MAY have one or more EDNS(0) extensions RFC6891 in the request.


At the time this is published, the response types are works in progress.  The only known response type is "application/dns- <del> udpwireformat", but it is likely that at least one JSON-based </del> <ins> udpwireformat", but it is possible that at least one JSON-based </ins> response format will be defined in the future. The DNS response for "application/dns-udpwireformat" in dnswire MAY


7. <del> In order to satisfy the security requirements of DNS over HTTPS, this protocol MUST use HTTP/2 RFC7540 or its successors.  HTTP/2 enforces a modern TLS profile necessary for achieving the security requirements of this protocol. </del> This protocol MUST be used with https scheme URI RFC7230. <del> The messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression. For this additional reason, this protocol MUST use HTTP/2 RFC7540 or its successors. </del> <ins> This protocol MUST use HTTP/2 RFC7540 or its successors in order to satisfy the security requirements of DNS over HTTPS.  Further, the messages in classic UDP based DNS RFC1035 are inherently unordered and have low overhead.  A competitive HTTP transport needs to support reordering, priority, parallelism, and header compression, all of which are supported by HTTP/2 RFC7540 or its successors. </ins> 8.


9. <del> Running DNS over https:// relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS this protocol expects to use current best practices for secure </del> <ins> Running DNS over HTTPS relies on the security of the underlying HTTP connection.  By requiring at least RFC7540 levels of support for TLS, this protocol expects to use current best practices for secure </ins> transport. Session level encryption has well known weaknesses with respect to


1. <del> The Internet does not always provide end to end reachability for native DNS.  On-path network devices may spoof DNS responses, block DNS requests, or just redirect DNS queries to different DNS servers that give less-than-honest answers.  These are also sometimes delivered with poor performance or reduced feature sets. Over time, there have been many proposals for using HTTP and HTTPS as a substrate for DNS queries and responses.  To date, none of those proposals have made it beyond early discussion, partially due to disagreement about what the appropriate formatting should be and partially because they did not follow HTTP best practices. </del> This document defines a specific protocol for sending DNS RFC1035 queries and getting DNS responses over HTTP RFC7540 using https:// (and therefore TLS RFC5246 security for integrity and


3. <ins> [[ RFC Editor: Please remove this entire section before publication. ]] </ins> The protocol described here bases its design on the following protocol requirements:


In order to maximize interoperability, DNS API clients and DNS API servers MUST support the "application/dns-message" media type.  Other media types MAY be used as defined by HTTP Content Negotiation <del> (RFC7231 Section 3.4). </del> <ins> (RFC7231 Section 3.4).  Those media types MUST be flexible enough to express every DNS query that would normally be sent in DNS over UDP (including queries and responses that use DNS extensions, but not those that require multiple responses). </ins> 6.


are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other.  It is the choice of a client to either <del> perform full DNSSEC validation of answers or to treat answers from a DNS API server as DNSSEC-authenticated, and this choice may be affected by the response media type. </del> <ins> perform full DNSSEC validation of answers or to trust the DNS API server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.  As noted in http-response, different response media types will provide more or less information from a DNS response so this choice may be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect


security implications of HTTP caching for other protocols that use HTTP. <del> In the absence of information about the authenticity of responses, such as DNSSEC, a DNS API server can give a client invalid data in </del> <ins> In the absence of DNSSEC information about the authenticity of responses a DNS API server can give a client invalid data in </ins> responses.  A client MUST NOT use arbitrary DNS API servers. Instead, a client MUST only use DNS API servers specified using mechanisms such as explicit configuration.  This does not guarantee


configuration.  This does not guarantee protection against invalid data but reduces the risk. <del> A client can use DNS over HTTPS as one of multiple mechanisms to obtain DNS data.  If a client of this protocol encounters an HTTP error after sending a DNS query, and then falls back to a different DNS retrieval mechanism, doing so can weaken the privacy and authenticity expected by the user of the client. </del> 10. Local policy considerations and similar factors mean different DNS


This protocol MUST be used with the https scheme URI RFC7230. <ins> PrivacyConsiderations and Security discuss additional considerations for the integration with HTTP. </ins> 6.1. A DoH exchange can pass through a hierarchy of caches that include


7. The data payload for the application/dns-message media type is a <del> single message of the DNS on-the-wire format defined in section 4.2.1 </del> <ins> single message of the DNS on-the-wire format defined in Section 4.2.1 </ins> of RFC1035.  The format was originally for DNS over UDP.  Although RFC1035 says "Messages carried by UDP are restricted to 512 bytes", that was later updated by RFC6891.  This media type restricts the maximum size of the DNS message to 65535 bytes.  Note that the wire format used in this media type is different than the wire format used <del> in RFC7858 (which uses the format defined in section 4.2.2 of </del> <ins> in RFC7858 (which uses the format defined in Section 4.2.2 of </ins> RFC1035). DoH clients using this media type MAY have one or more EDNS options


9. <ins> RFC7626 discusses DNS Privacy Considerations in both "On the wire" (Section 2.4), and "In the server" (Section 2.5) contexts.  This is also a useful framing for DoH's privacy considerations. 9.1. DoH encrypts DNS traffic and requires authentication of the server. This mitigates both passive surveillance RFC7258 and active attacks that attempt to divert DNS traffic to rogue servers (RFC7626 Section 2.5.1).  DNS over TLS RFC7858 provides similar protections, while direct UDP and TCP based transports are vulnerable to this class of attack. Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. 9.2. A DoH implementation is built on IP, TCP, TLS, and HTTP.  Each layer contains one or more common features that can be used to correlate queries to the same identity.  DNS transports will generally carry the same privacy properties of the layers used to implement them. For example, the properties of IP, TCP, and TLS apply to DNS over TLS implementations. The privacy considerations of using the HTTPS layer in DoH are incremental to those of DNS over TLS.  DoH is not known to introduce new concerns beyond those associated with HTTPS. At the IP level, the client address provides obvious correlation information.  This can be mitigated by use of a NAT, proxy, VPN, or simple address rotation over time.  It may be aggravated by use of a DNS server that can correlate real-time addressing information with other personal identifiers, such as when a DNS server and DHCP server are operated by the same entity. TCP-based solutions may seek performance through the use of TCP Fast Open RFC7413.  The cookies used in TCP Fast Open allow servers to correlate TCP sessions together. TLS based implementations often achieve better handshake performance through the use of some form of session resumption mechanism such as session tickets RFC5077.  Session resumption creates trivial mechanisms for a server to correlate TLS connections together. HTTP's feature set can also be used for identification and tracking in a number of different ways.  For example, authentication request header fields explicitly identify profiles in use, and HTTP Cookies are designed as an explicit state tracking mechanism between the client and serving site and often are used as an authentication mechanism. Additionally, the User-Agent and Accept-Language request header fields often convey specific information about the client version or locale.  This facilitates content negotiation and operational work- arounds for implementation bugs.  Request header fields that control caching can expose state information about a subset of the client's history.  Mixing DoH requests with other HTTP requests on the same connection also provides an opportunity for richer data correlation. The DoH protocol design allows applications to fully leverage all the features of the HTTP ecosystem, including features not enumerated here.  Implementations of DoH clients and servers need to consider the benefit and privacy impact of these features, and their deployment context, when deciding whether or not to enable them. Implementations are advised to expose the minimal set of data needed to achieve the desired feature set. Determining whether or not a DoH implementation requires HTTP cookie RFC6265 support is particularly important because HTTP cookies are the primary state tracking mechanism in HTTP.  HTTP Cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case. 10. </ins> Running DNS over HTTPS relies on the security of the underlying HTTP transport.  This mitigates classic amplification attacks for UDP- based DNS.  Implementations utilizing HTTP/2 benefit from the TLS


This prohibition does not guarantee protection against invalid data, but it does reduce the risk. <del> 10. </del> <ins> 11. </ins> Local policy considerations and similar factors mean different DNS servers may provide different results to the same query: for instance


to support reordering, parallelism, priority, and header compression to acheive similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of <del> conveying the semantic requirements of DOH but would result in very </del> <ins> conveying the semantic requirements of DOH but may result in very </ins> poor performance for many uses cases. 8.


Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. <ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration


Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and <del> "user_cancelled", both of which indicate that the connection is not </del> <ins> "user_canceled", both of which indicate that the connection is not </ins> going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a


maintain backwards compatibility.  However, this document does provide additional guidance on authentication, authorization, and resumption for EAP-TLS regardless of the underlying TLS version used. <del> This document only describes differences compared to RFC5216.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </del> <ins> This document only describes differences compared to RFC5216.  When EAP-TLS is used with TLS 1.3, some references are updated as specified in updateref.  All message flow are example message flows specific to TLS 1.3 and do not apply to TLS 1.2.  Since EAP-TLS couples the TLS handshake state machine with the EAP state machine it is possible that new versions of TLS will cause incompatibilities that introduce failures or security issues if they are not carefully integrated into the EAP-TLS protocol.  Therefore, implementations MUST limit the maximum TLS version they use to 1.3, unless later versions are explicitly enabled by the administrator. </ins> This document specifies EAP-TLS 1.3 and does not specify how other TLS-based EAP methods use TLS 1.3.  The specification for how other


If the EAP-TLS peer authenticates successfully, the EAP-TLS server MUST send an EAP-Request packet with EAP-Type=EAP-TLS containing TLS records conforming to the version of TLS used.  The message <del> flow ends with the EAP-TLS server sending an EAP-Success message. </del> <ins> flow ends with a protected success indication from the EAP-TLS server, follwed by an EAP-Response packet of EAP-Type=EAP-TLS and no data from the EAP-TLS peer, follwed by EAP-Success from the server. </ins> If the EAP-TLS server authenticates successfully, the EAP-TLS peer MUST send an EAP-Response message with EAP-Type=EAP-TLS containing


When EAP-TLS is used with TLS version 1.3, the EAP-TLS peers and EAP- TLS servers MUST comply with the compliance requirements (mandatory- to-implement cipher suites, signature algorithms, key exchange <del> algorithms, extensions, etc.) for the TLS version used.  For TLS 1.3 the compliance requirements are defined in Section 9 of RFC8446.  In </del> <ins> algorithms, extensions, etc.) defined in Section 9 of RFC8446.  In </ins> EAP-TLS with TLS 1.3, only cipher suites with confidentiality SHALL be supported.


1.2. <del> A frequently emphasized advantage of XML is the availability of powerful tools to analyse, transform and selectively extract data from XML documents.  XPath is one of these tools. </del> <ins> This document picks up Stefan Goessner's popular JSONPath specification dated 2007-02-21 JSONPath-orig and provides a normative definition for it. inspired-by-xpath provides a brief synopsis with XML's XPath XPath, which was the inspiration that led to the definition of JSONPath. JSONPath was intended as a light-weight companion to JSON implementations on platforms such as PHP and JavaScript, so instead of defining its own expression language like XPath did, JSONPath delegated this to the expression language of the platform.  While the languages in which JSONPath is used do have significant commonalities, over time this caused non-portability of JSONPath expressions between the ensuing platform-specific dialects. The present specification intends to remove platform dependencies and server as a common JSONPath specification that can be used across platforms.  Obviously, this means that backwards compatibility could not always be achieved; a design principle of this specification is to go with a "consensus" between implementations even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language. </ins> <del> In 2007, the need for something solving the same class of problems for the emerging JSON community became apparent, specifically for: Finding data interactively and extracting them out of RFC8259 JSON values without special scripting. Specifying the relevant parts of the JSON data in a request by a client, so the server can reduce the amount of data in its response, minimizing bandwidth usage. So what does such a tool look like for JSON?  When defining a JSONPath, how should expressions look? The XPath expression looks like or in popular programming languages such as JavaScript, Python and PHP, with a variable x holding the argument.  Here we observe that such languages already have a fundamentally XPath-like feature built in. The JSONPath tool in question should: be naturally based on those language characteristics. cover only essential parts of XPath 1.0. be lightweight in code size and memory consumption. </del> <ins> 1.3. </ins> <del> be runtime efficient. </del> <ins> JSONPath expressions are applied to a JSON value, the </ins> <del> 1.3. </del> <ins> .  Within the JSONPath expression, the abstract name "$" is used to refer to the </ins> <del> JSONPath expressions always apply to a value in the same way as XPath expressions are used in combination with an XML document.  Since a value is anonymous, JSONPath uses the abstract name "$" to refer to the root node of the argument. </del> <ins> of the argument, i.e., to the argument as a whole. </ins> JSONPath expressions can use the or the <del> for paths input to a JSONPath processor.  [1] Where a JSONPath processor uses JSONPath expressions as output paths, these will always be converted to Output Paths which employ the more general .  [2] Bracket notation is more general than dot notation and can serve as a canonical form when a JSONPath processor uses JSONPath expressions as output paths. JSONPath allows the wildcard symbol "*" for member names and array indices.  It borrows the descendant operator ".." from E4X and the array slice syntax proposal "[start:end:step]" SLICE from ECMASCRIPT 4. JSONPath was originally designed to employ an </del> <ins> to build paths that are input to a JSONPath processor.  Bracket notation is more general than dot notation and can serve as a canonical form (for instance, when a JSONPath processor uses JSONPath expressions as output paths). </ins> <del> for computing expressions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform. </del> <ins> JSONPath allows the wildcard symbol "*" to select any member of an object or any element of an array (wildcard).  The descendant operator ".." selects the node and all its descendants (descendant- selector).  The array slice syntax "[start:end:step]" allows selecting a regular selection of an element from an array, giving a start position, an end position, and possibly a step value that moves the position from the start to the end (slice). </ins> <del> JSONPath can use expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in: </del> <ins> JSONPath employs an </ins> <del> The symbol "@" is used for the current node.  Filter expressions are supported via the syntax "?(<boolean expr>)" as in </del> <ins> for computing values and making decisions.  The present specification defines a simple expression language that is independent from any scripting language in use on the platform.  JSONPath can use such expression language expressions, written in parentheses: "(<expr>)", as an alternative to explicit names or indices as in [no-dot-length]: </ins> <del> Here is a complete overview and a side by side comparison of the JSONPath syntax elements with their XPath counterparts. </del> <ins> The symbol "@" is used for the current node, i.e., the node in the context of which the expression is evaluated. </ins> <del> XPath has a lot more to offer (location paths in unabbreviated syntax, operators and functions) than listed here.  Moreover there is a significant difference how the subscript operator works in Xpath and JSONPath: </del> <ins> Filter expressions are supported via the syntax "?(<boolean expr>)" as in </ins> <del> Square brackets in XPath expressions always operate on the resulting from the previous path fragment.  Indices always start at 1. With JSONPath, square brackets operate on the or addressed by the previous path fragment.  Array indices always start at 0. </del> <ins> tbl-overview provides a quick overview of the JSONPath syntax elements. </ins> 2.


3.5.7.2. <del> The "descendant-selector" is inspired by ECMAScript for XML (E4X). It selects the node and all its descendants. </del> <ins> The "descendant-selector" selects the node and all its descendants. </ins> 3.5.8.


isolating a single location within a document. Path is a query syntax that can also be used to pull multiple locations. <ins> [no-dot-length] We probably want to use an expression that does not use </ins>


The examples in tbl-example use the expression mechanism to obtain the number of elements in an array, to test for the presence of a member in a object, and to perform numeric comparisons of member <del> values with a constant. </del> <ins> values with a constant.  For further illustration, the table shows XPath expressions that would be used with a comparable XML document; see also xpath-overview. </ins> 3.


member name ""a"".  The result is again a list of one node: "[{"b":0},{"b":1},{"c":2}]". <del> Next, "[*]" selects from any input node -- either an array or an object -- all its elements or members.  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </del> <ins> Next, "[*]" selects from an input node of type array all its elements (if the input note were of type object, it would select all its member values, but not the member names).  The result is a list of three nodes: "{"b":0}", "{"b":1}", and "{"c":2}". </ins> Finally, ".b" selects from any input node of type object with a member name "b" and selects the node of the member value of the input


Regular expression tests can be applied to "string" values only. <del> The value of the first operand ("containable") of a "contain-expr" is compared to every single element of the RHS "container".  In case of a match a selection occurs.  Containment tests -- like comparisons -- are restricted to primitive values.  So even if a structured "containable" value is equal to a certain structured value in "container", no selection is done. The value of the second operand ("container") of a "contain-expr" needs to be resolved to an array.  Otherwise nothing is selected. </del> The following table lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).


to the member name from any JSON object in its input nodelist.  It selects no nodes from any other JSON value. <del> Note that the "dot-selector" follows the philosophy of JSON strings and is allowed to contain bit sequences that cannot encode Unicode characters (a single unpaired UTF-16 surrogate, for example).  The behaviour of an implementation is undefined for member names which do not encode Unicode characters. </del> 3.5.3. 3.5.3.1.


of their element or member values then.  Applied to other value types, it will select nothing. <del> : The zero number/empty string exceptions are no longer true. Booleans work the same everywhere. Negation operator "neg-op" allows to test of values. Applying negation operator twice "!!" gives us </del> <ins> DELETE-ME: (( We currently don't need this.  But we commit a version in case we do need it later.  The negation operator "neg-op" can be applied to any JSON value and returns "true" only when applied to "false" or "null": </ins> <del> of values. </del> <ins> Consequently, applying the negation operator twice "!!" returns "true" for all values except "false" or "null".  )) </ins> Some examples:


D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can <del> choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. </del> <ins> choose to submit specially crafted JSONPath queries or arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example via a naive recursive implementation of the descendant selector, stack overflow.  Implementations need to have appropriate resource management to mitigate these attacks. </ins> 5.2.


The semantics of regular expressions are as defined in I-D.draft- bormann-jsonpath-iregexp. <ins> The logical AND, OR, and NOT operators have the normal semantics of Boolean algebra and consequently obey these laws (where "P", "Q", and "R" are any expressions with syntax "logical-and-expr", "T" is any true expression, such as "1 == 1", and "F" is any false expression, such as "1 == 0"): </ins> 3.5.8.3. JSON document:


"index-wild-selector", "filter-selector", or "list-selector" acting on objects or arrays, or a "slice-selector" acting on arrays. <del> Note that there is no "bald" descendant selector "..". </del> <ins> Note that there is no "bald" descendant selector (".." on its own). </ins> 3.5.7.2. <del> The "descendant-selector" selects certain descendants of a node: </del> <ins> A "descendant-selector" selects certain descendants of a node: </ins> the "..<name>" form (and the "..[<index>]" form where "<index>" is a "quoted-member-name") selects those descendants that are member


the "..[*]" and "..*" forms select all the descendants. <del> The resultant nodelist is ordered as if: </del> <ins> An </ins> <del> nodes are visited before their children, and </del> <ins> of the descendants of a node is a sequence of all the descendants in which: </ins> <del> nodes of an array are visited in array order. </del> <ins> nodes of any array appear in array order, </ins> <del> Children of an object may be visited in any order, since JSON objects are unordered. </del> <ins> nodes appear immediately before all their descendants. </ins> <del> Implementations may visit descendants in any way providing the resultant nodelist could have been produced by visiting descendants as above. </del> <ins> This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. </ins> 3.5.7.3.


3.5.5.2.2. <del> The comparison operators "==", "<", and ">" are defined first and then these are used to define "!=", "<=", and ">=". </del> <ins> The comparison operators "==" and "<" are defined first and then these are used to define "!=", "<=", ">", and ">=". </ins> When a path resulting in an empty nodelist appears on either side of a comparison:


the comparison is between two paths each of which result in an empty nodelist. <del> a comparison using either of the operators "<" or ">" yields false. </del> <ins> a comparison using the operator "<" yields false. </ins> When any path on either side of a comparison results in a nodelist consisting of a single node, each such path is replaced by the value


for each of those names, the values associated with the name by the objects are equal. <del> a comparison using either of the operators "<" or ">" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </del> <ins> a comparison using the operator "<" yields true if and only if the comparison is between values of the same type which are both numbers or both strings and which satisfy the comparison: </ins> numbers expected to interoperate as per RFC7493 MUST compare using the normal mathematical ordering; numbers not expected to


first string compares less than the remainder of the second string. <del> Note that comparisons using either of the operators "<" or ">" yield false if either value being compared is an object, array, boolean, or "null". </del> <ins> Note that comparisons using the operator "<" yield false if either value being compared is an object, array, boolean, or "null". </ins> <del> "!=", "<=" and ">=" are defined in terms of the other comparison operators.  For any "a" and "b": </del> <ins> "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b": </ins> The comparison "a != b" yields true if and only if "a == b" yields false.


The comparison "a <= b" yields true if and only if "a < b" yields true or "a == b" yields true. <del> The comparison "a >= b" yields true if and only if "a > b" yields </del> <ins> The comparison "a > b" yields true if and only if "b < a" yields true. The comparison "a >= b" yields true if and only if "b < a" yields </ins> true or "a == b" yields true. 3.5.5.2.3.


3.8. <del> A Normalized Path is a JSONPath with restricted syntax that identifies a node by providing a query that results in exactly that node.  For example, the JSONPath expression "$.book[?(@.price<10)]" could select two values with Normalized Paths "$['book'][3]" and "$['book'][5]".  For a given JSON value, there is a one to one correspondence between the value's nodes and the Normalized Paths that identify these nodes.  Note that there is precisely one Normalized Path that identifies each node. A JSONPath implementation may output Normalized Paths instead of, or in addition to, the values identified by these paths. Since bracket notation is more general than dot notation, it is used to construct Normalized Paths.  Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear as strings (which are delimited with double quotes) in JSON texts. </del> <ins> A Normalized Path is a canonical representation of the identity of a node in a value.  Specifically, a Normalized Path is a JSONPath query with restricted syntax (defined below), e.g., "$['book'][3]", which when applied to the value results in a nodelist consisting of just the node identified by the Normalized Path.  Note that a Normalized Path represents the identity of a node .  There is precisely one Normalized Path identifying any particular node in a value. A canonical representation of a nodelist is as a JSON arrays of strings, where the strings are Normalized Paths. Normalized Paths provide a predictable format that simplifies testing and post-processing of nodelists, e.g., to remove duplicate nodes. Normalized Paths are used in this document as result paths in examples. Normalized Paths use the canonical bracket notation, rather than dot notation. Single quotes are used to delimit string member names.  This reduces the number of characters that need escaping when Normalized Paths appear in double quote delimited strings, e.g., in JSON texts. </ins> Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Normalized Paths are Singular Paths.  Not all Singular Paths are Normalized Paths: "$[-3]", for example, is a Singular Path, but not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del> <ins> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not. So the definition of "normal-hexchar" is designed for hex escaping of characters which are not straightforwardly-printable, for example <del> U+000B LINE TABULATION, but for which no standard JSON escape such as "n" is available. </del> <ins> U+000B LINE TABULATION, but for which no standard JSON escape, such as "n", is available. </ins> 3.8.1.


Security considerations for JSONPath can stem from <del> attack vectors on JSONPath implementations, and </del> <ins> attack vectors on JSONPath implementations, attack vectors on how JSONPath queries are formed, and </ins> the way JSONPath is used in security-relevant mechanisms.


4.2. <ins> JSONPath queries are often not static, but formed from variables that provide index values, member names, or values to compare with in a filter expression.  These variables need to be translated into the form they take in a JSONPath query, e.g., by escaping string delimiters, or by only allowing specific constructs such as ".name" to be formed when the given values allow that.  Failure to perform these translations correctly can lead to unexpected failures, which can lead to Availability, Confidentiality, and Integrity breaches, in particular if an adversary has control over the values (e.g., by entering them into a Web form).  The resulting class of attacks, (e.g., SQL injections), is consistently found among the top causes of application security vulnerabilities and requires particular attention. 4.3. </ins> Where JSONPath is used as a part of a security mechanism, attackers can attempt to provoke unexpected or unpredictable behavior, or take advantage of differences in behavior between JSONPath


filter-selectors enclosing the filter-selector that is directly enclosing the identifier). <del> An existence expression may test the result of a function expression (see fnex). </del> <ins> A test expression either tests the existence of a node designated by an embedded query (see extest) or tests the result of a function expression (see fnex).  In the latter case, if the function expression is of type "OptionalBoolean" or one of its subtypes, it tests whether the result is "true"; if the function expression is of type "OptionalNodes" or one of its subtypes, it tests whether the result is different from "Nothing". </ins> Parentheses MAY be used within "boolean-expr" for grouping.


alternatively be absent ("Nothing"). "OptionalNodes" is an abstraction of a "filter-path" (which <del> appears in an existence test or as a function argument). </del> <ins> appears in a test expression or as a function argument). </ins> The abstract instances above can be obtained from the concrete representations in tbl-typerep.


A function expression is correctly typed if all the following are true: <del> If it occurs as a "filter-path" in an existence test, the function </del> <ins> If it occurs as a "filter-path" in a test expression, the function </ins> is defined to have result type "OptionalNodes" or one of its subtypes, or to have result type "OptionalBoolean" or one of its subtypes.


Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Paths, </del> <ins> "null").  These can be obtained via literal values; Singular Queries, </ins> each of which selects at most one node the value of which is then used; and function expressions (see fnex) of type "ValueType" or "NodesType" (see type-conv).


2.5.5.2.1. <del> A path by itself in a Logical context is an existence test which yields true if the path selects at least one node and yields false if the path does not select any nodes. </del> <ins> A query by itself in a Logical context is an existence test which yields true if the query selects at least one node and yields false if the query does not select any nodes. </ins> Existence tests differ from comparisons in that: <del> they work with arbitrary relative or absolute paths (not just Singular Paths). </del> <ins> they work with arbitrary relative or absolute queries (not just Singular Queries). </ins> <del> they work with paths that select structured values. </del> <ins> they work with queries that select structured values. </ins> <del> To examine the value of a node selected by a path, an explicit </del> <ins> To examine the value of a node selected by a query, an explicit </ins> comparison is necessary.  For example, to test whether the node <del> selected by the path "@.foo" has the value "null", use "@.foo == </del> <ins> selected by the query "@.foo" has the value "null", use "@.foo == </ins> null" (see null-semantics) rather than the negated existence test "!@.foo" (which yields false if "@.foo" selects a node, regardless of the node's value).


a comparison using the operator "<" yields false. <del> When any path or function expression on either side of a comparison </del> <ins> When any query or function expression on either side of a comparison </ins> results in a nodelist consisting of a single node, that side is replaced by the value of its node and then:


implementation level only -- they do not influence the result of the evaluation.) <del> A function argument is a "filter-path" or a "comparable". </del> <ins> A function argument is a "filter-query" or a "comparable". </ins> According to filter-selector, a "function-expr" is valid as a <del> "filter-path" or a "comparable". </del> <ins> "filter-query" or a "comparable". </ins> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath


related to the JSON literals "true" and "false" and have no direct syntactical representation in JSONPath. <del> "NodesType" is an abstraction of a "filter-path" (which appears in a test expression or as a function argument).  Members of </del> <ins> "NodesType" is an abstraction of a "filter-query" (which appears in a test expression or as a function argument).  Members of </ins> "NodesType" have no direct syntactical representation in JSONPath. The abstract instances above can be obtained from the concrete


The argument is a literal primitive value and the defined type of the parameter is "ValueType". <del> The argument is a Singular Path or "filter-path" (which includes Singular Paths), or a function expression with </del> <ins> The argument is a Singular Query or "filter-query" (which includes Singular Queries), or a function expression with </ins> declared result type "NodesType" and the defined type of the parameter is "NodesType".  Where the declared type of the parameter is not "NodesType", a conversion applies.


filter expression: Its only argument is an instance of "ValueType" (possibly taken from <del> a singular path as in the example above).  The result also is an </del> <ins> a singular query as in the example above).  The result also is an </ins> instance of "ValueType": an unsigned integer or "Nothing". If the argument value is a string, the result is the number of


processing in the filter expression: Its only argument is an instance of "NodesType" (possibly taken from <del> a "filter-path" as in the example above).  The result is an instance </del> <ins> a "filter-query" as in the example above).  The result is an instance </ins> of "ValueType". If the argument contains a single node, the result is the value of


Certain characters are escaped, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Paths, but not all Singular Paths are Normalized Paths.  For example, "$[-3]" is a Singular Path, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3".  (The array length must be at least "3" if "$[-3]" is to identify a node.) </del> <ins> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.) </ins> Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not.


Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and <del> "null").  These can be obtained via literal values; Singular Queries, </del> <ins> "null").  These can be obtained via literal values; singular queries, </ins> each of which selects at most one node the value of which is then used; or function expressions (see fnex) of type "ValueType".


Existence tests differ from comparisons in that: they work with arbitrary relative or absolute queries (not just <del> Singular Queries). </del> <ins> singular queries). </ins> they work with queries that select structured values.


Certain characters are escaped in Normalized Paths, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a singular </del> <ins> Note: Normalized Paths are singular queries, but not all singular queries are Normalized Paths.  For example, "$[-3]" is a singular </ins> query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a


, as described in fnex. A JSONPath implementation MUST raise an error for any query which is <del> not well-formed and valid.  The well-formedness and the validity of </del> <ins> not well formed and valid.  The well-formedness and the validity of </ins> JSONPath queries are independent of the JSON value the query is applied to.  No further errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of


the result is "LogicalTrue"; if the function's declared result type is "NodesType", it tests whether the result is non-empty.  If the function's declared result type is "ValueType", its use in a test <del> expression is not well-typed. </del> <ins> expression is not well typed. </ins> Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, "true", "false", and


2.5.5.2.1. <del> A query by itself in a Logical context is an existence test which </del> <ins> A query by itself in a logical context is an existence test which </ins> yields true if the query selects at least one node and yields false if the query does not select any nodes.


implementation level only -- they do not influence the result of the evaluation.) <del> Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed, otherwise the JSONPath </del> <ins> Any function expressions in a query must be well formed (by conforming to the above ABNF) and well typed, otherwise the JSONPath </ins> implementation MUST raise an error (see synsem-overview).  To define <del> which function expressions are well-typed, a type system is first </del> <ins> which function expressions are well typed, a type system is first </ins> introduced. 2.6.1.


If the argument is "Nothing" or contains multiple nodes, the result is "Nothing". <del> Note: a Singular Query may be used anywhere where a ValueType is </del> <ins> Note: a singular query may be used anywhere where a ValueType is </ins> expected, so there is no need to use the "value" function extension <del> with a Singular Query. </del> <ins> with a singular query. </ins> 2.6.9.


one way; all other characters are unescaped. Note: Normalized Paths are Singular Queries, but not all Singular <del> Queries are Normalized Paths.  For example, "$[-3]" is a Singular Query, but is not a Normalized Path.  The Normalized Path equivalent </del> <ins> Queries are Normalized Paths.  For example, "$[-3]" is a singular query, but is not a Normalized Path.  The Normalized Path equivalent </ins> to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a node.)


example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as "%x2318". <ins> Functions are referred to using the function name followed by a pair of parentheses, as in "fname()". </ins> The terminology of RFC8259 applies except where clarified below.  The terms "Primitive" and "Structured" are used to group different kinds of values as in RFC8259; JSON Objects and Arrays are structured, all


2.3.2.2. <del> A "wildcard" selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </del> <ins> A wildcard selector selects the nodes of all children of an object or array.  The order in which the children of an object appear in the </ins> resultant nodelist is not stipulated, since JSON objects are unordered.  Children of an array appear in array order in the resultant nodelist. <del> The "wildcard" selector selects nothing from a primitive JSON value </del> <ins> The wildcard selector selects nothing from a primitive JSON value </ins> (that is, a number, a string, "true", "false", or "null"). 2.3.2.3.


Queries: <del> The examples in tbl-wild show the "wildcard" selector in use by a child segment: </del> <ins> The examples in tbl-wild show the wildcard selector in use by a child segment: </ins> The example above with the query "$.o[*, *]" shows that the wildcard selector may produce nodelists in distinct orders each time it


If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del> <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.


2.4.4. <del> The "length" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </del> <ins> The "length()" function extension provides a way to compute the length of a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "ValueType" (possibly taken from a singular query, as in the example above).  The result also is an


2.4.5. <del> The "count" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </del> <ins> The "count()" function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression: </ins> Its only argument is a nodelist.  The result is a value, an unsigned integer, that gives the number of nodes in the nodelist.  Note that


2.4.6. <del> The "match" function extension provides a way to check whether (the </del> <ins> The "match()" function extension provides a way to check whether (the </ins> entirety of, see search below) a given string matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.


2.4.7. <del> The "search" function extension provides a way to check whether a </del> <ins> The "search()" function extension provides a way to check whether a </ins> given string contains a substring that matches a given regular expression, which is in I-D.draft-ietf-jsonpath-iregexp form.


2.4.8. <del> The "value" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </del> <ins> The "value()" function extension provides a way to convert an instance of "NodesType" to a value and make that available for further processing in the filter expression: </ins> Its only argument is an instance of "NodesType" (possibly taken from a "filter-query", as in the example above).  The result is an


result is "Nothing". Note: a singular query may be used anywhere where a ValueType is <del> expected, so there is no need to use the "value" function extension </del> <ins> expected, so there is no need to use the "value()" function extension </ins> with a singular query. 2.4.9.


If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. <ins> Note that the ordering of Requested Addresses does not carry any semantics.  Similarly, the Request ID is only meant as a unique identifier, it does not convey any priority or importance. </ins> 4.7.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the


meet these requirements, it MUST abort the IP proxying request stream. <ins> Since setting the IP protocol to zero indicates all protocols are allowed, the requirements above make it possible for two routes to overlap when one has IP protocol set to zero and the other set to non-zero.  Endpoints MUST not send a ROUTE_ADVERTISEMENT capsule with routes that overlap in such a way.  Validating this requirement is OPTIONAL, but if an endpoint detects the violation, it MUST abort the IP proxying request stream. </ins> 5. The mechanism for proxying IP in HTTP defined in this document allows


of the destinations included in the scope, then the IP proxy can immediately fail the request. <ins> Note that IP protocol numbers represent both upper layers (as defined in IPv6, examples include TCP and UDP) and IPv6 extension headers (as defined in IPv6, examples include Fragment and Options headers).  IP proxies MAY reject requests to scope to protocol numbers that are used for extension headers.  Upon receiving packets, implementations that support scoping by IP protocol number MUST walk the chain of extensions to find the matching IP protocol number. </ins> 4.7. This document defines multiple new capsule types that allow endpoints


invoking packet included in the ICMP packet and only forward the ICMP packet to the client whose scoping matches the invoking packet. <ins> Since there are known risks with some IPv6 extension headers (e.g., ROUTING-HDR), implementers need to follow the latest guidance regarding handling of IPv6 extension headers. </ins> 11. 11.1.


ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. <ins> Note that the IP forwarding tunnels described in this document are not fully featured "interfaces" in the IPv6 addressing architecture sense IPv6-ADDR.  In particular, they do not necessarily have IPv6 link-local addresses.  Additionally, IPv6 stateless autoconfiguration or router advertisement messages are not used in such interfaces, and neither is neighbor discovery. </ins> 4.7.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the


Datagram.  This prevents infinite loops in the presence of routing loops, and matches the choices in IPsec IPSEC. <ins> Implementers need to ensure that they do not forward any link-local traffic onto a different interface than the one it was received on. IP proxies also need to properly reply to packets destined to link- local multicast addresses. </ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since IP proxying in HTTP conveys IP packets in HTTP Datagrams and those can in turn be sent in QUIC DATAGRAM frames which cannot be


4.2. <ins> This document defines multiple new capsule types that allow endpoints to exchange IP configuration information.  Both endpoints MAY send any number of these new capsules. </ins> 4.2.1. The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that


endpoint is allowed to send packets from any source address that falls within the prefix. <ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. </ins> 4.2.2. The ADDRESS_REQUEST capsule allows an endpoint to request assignment


Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in that prefix to its peer. <ins> If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </ins> 4.2.4. The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its


endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. <ins> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </ins> 5. IP packets are sent using HTTP Datagrams I-D.ietf-masque-h3-datagram.


tunnel. Along with a successful response, the proxy can send capsules to <del> assign addresses and routes to the client (capsules).  The client can also assign addresses and routes to the proxy for network-to-network routing. </del> <ins> assign addresses and advertise routes to the client (capsules).  The client can also assign addresses and advertise routes to the proxy for network-to-network routing. </ins> 4.1.


4.2.1. <del> The ADDRESS_ASSIGN capsule allows an endpoint to inform its peer that it has assigned an IP address to it.  It allows assigning a prefix which can contain multiple addresses.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del> <ins> The ADDRESS_ASSIGN capsule (see iana-types for the value of the capsule type) allows an endpoint to inform its peer that it has assigned an IP address or prefix to it.  The ADDRESS_ASSIGN capsule allows assigning a prefix which can contain multiple addresses.  Any of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. </ins> IP Version of this address assignment.  MUST be either 4 or 6.


The number of bits in the IP Address that are used to define the prefix that is being assigned.  This MUST be less than or equal to the length of the IP Address field, in bits.  If the prefix length <del> is equal to the length of the IP Address, the endpoint is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the endpoint is allowed to send packets from any source address that falls within the prefix. </del> <ins> is equal to the length of the IP Address, the receiver of this capsule is only allowed to send packets from a single source address.  If the prefix length is less than the length of the IP address, the receiver of this capsule is allowed to send packets from any source address that falls within the prefix. </ins> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple


4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del> <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.


4.2.3. <del> The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to its peer that it is willing to route traffic to a given prefix.  This indicates that the sender has an existing route to the prefix, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del> <ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is willing to route traffic to a set of IP address ranges.  This indicates that the sender has an existing route to each address range, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for one of these ranges in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route.  Any address which is in one of the address ranges can be used as the destination address on IP packets originated by the receiver of this capsule. </ins> <del> IP Version of this route advertisement.  MUST be either 4 or 6. </del> <ins> The ROUTE_ADVERTISEMENT capsule contains a sequence of IP Address Ranges. </ins> <del> IP address of the advertised route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. </del> <ins> IP Version of this range.  MUST be either 4 or 6. </ins> <del> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </del> <ins> Inclusive start and end IP address of the advertised range.  If the IP Version field has value 4, these fields SHALL have a length of 32 bits.  If the IP Version field has value 6, these fields SHALL have a length of 128 bits.  The Start IP Address MUST be strictly lesser than the End IP Address. </ins> The Internet Protocol Number for traffic that can be sent to this <del> prefix.  If the value is 0, all protocols are allowed. </del> <ins> range.  If the value is 0, all protocols are allowed. </ins> Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start <del> routing IP packets in that prefix to its peer. If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </del> <ins> routing IP packets in these ranges to its peer. </ins> <del> 4.2.4. </del> <ins> Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction, each ROUTE_ADVERTISEMENT capsule supersedes prior ones.  In other words, if a given address range was present in a prior capsule but the most recently received ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider that range withdrawn. </ins> <del> The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: </del> <ins> If multiple ranges using the same IP protocol were to overlap, some routing table implementations might reject them.  To prevent overlap, the ranges are ordered; this places the burden on the sender and makes verification by the receiver much simpler.  If an IP Address Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: </ins> <del> IP Version of this route withdrawal.  MUST be either 4 or 6. IP address of the withdrawn route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. The number of bits in the IP Address that are used to define the prefix of the withdrawn route.  This MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> IP Version of A MUST be lesser or equal than IP Version of B </ins> <del> The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. </del> <ins> If the IP Version of A and B are equal, the IP Protocol of A MUST be lesser or equal than IP Protocol of B. </ins> <del> Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop routing IP packets in that prefix to its peer.  Note that this capsule can be reordered with DATAGRAM frames, and therefore an endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. </del> <ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly lesser than the Start IP Address of B. </ins> <del> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </del> <ins> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not meet these requirements, it MUST abort the stream. </ins> 5.


or split-tunnel. In this case, the client does not specify any scope in its request. <del> The server assigns the client an IPv6 address prefix to the client (2001:db8::/64) and a full-tunnel route of all IPv6 addresses (::/0). The client can then send to any IPv6 host using a source address in its assigned prefix. </del> <ins> The server assigns the client an IPv4 address to the client (192.0.2.11) and a full-tunnel route of all IPv4 addresses (0.0.0.0/0).  The client can then send to any IPv4 host using a source address in its assigned prefix. </ins> A setup for a split-tunnel VPN (the case where the client can only access a specific set of private subnets) is quite similar.  In this <del> case, the advertised route is restricted to 2001:db8::/32, rather than ::/0. </del> <ins> case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. </ins> 6.2.