4.1.  CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined here are optional, and have default values if not included. specific host to which the client wants to proxy packets.  If the "target" variable is not specified, the client is requesting to communicate with any allowable host.  If the target is an IP <del> address, the request will only support a single IP version. </del>  The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If 6.  The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote <del> server through the proxy. </del>  The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to <del> target.example.com using ICMP (IP protocol 1), and receives a single local address and remote address it can use for transmitting packets. The following example shows a proxied UDP listen flow, where a client receives can receive UDP packets via the proxy, and can send to any UDP server through the proxy. </del>  7.

The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?
I continue to struggle with our difference in how we consider IP addressing and assumption on IP topology. I can't really determine which functionality is necessary to support the use cases. I think it would actually help if we actually detailed a couple of IP addressing examples for some use cases as an appendix to the draft. I am willing to help write such text. In this figure, are there any cases where we need to provide an proxy's external address to the client, rather than having the proxy act as a router of all addresses assigned to client's for packet arriving on its right side interface. The reason I ask, is in many tunnel protocols one can actually ping so to say the remote side of the tunnel, we haven't discussed if that should be possible. Also the discussion around the default route, in many cases that corresponds to all addresses except the subnet's IP range for a leaf network. I do think we would all be helped by actually drawing a couple of pictures and include subnet addresses in these to clarify the assumptions of the roles.
In QBONE today, the proxy's service address (aka "frontend address") acts as a normal reachable IP. If you wish to reach the proxy through the tunnel/flow, we provide a link-local address. In many cases, the proxy does not have a single external address that it can use as per your diagram, so it doesn't make sense to provide it. In general, I think modelling the proxy as having a single external address is detrimental. In the full tunnel mode, the proxy does not need to have any external address at all, as it may be making network routing advertisements on behalf of its clients. In the flow-based mode, it likely has more than 1 address onto which requests are mapped.
NAME I think you are confirming my point quite well. In flow-based mode, for a single flow the above picture represents terminology that is useful. However, I am not disagreeing with you on the VPN case where the model likely as you say you have a network, likely a IPv4 private address network, or an IPv6 subnet. Where the former will need a NAT device for external reachability. My point is that unless we actually draw up a couple of representing use cases when it comes to address usages we are going to miss things, or at least spend more time talking past each other about why a particular functionality is necessary. That is why I am advocating that we spend some time at least drawing these deployment cases.
I think that adding multiple diagrams to the document that show some example use cases would be helpful.
I support diagrams; my comment above was merely pointing out some issues with the initial proposed diagram and explaining some prior art in the space.
Adding details and diagrams to expand the examples section would help here.
I don't understand how the UDP Listen Flow Example works. Unless I'm missing something, for this example to work you would need a way to convey the client's UDP port number. Since we decided that this was out of scope, perhaps we should remove this example?
This example was more about saying we can do UDP listening on an address, but all ports. So, it's binding just the protocol and address. It is something that is begging for a port extension to scope down further, but it still shows how you can do protocol listening, without being a full IP tunnel. Essentially, saying "I only implement user space UDP and can handle that, I don't want anything else".
This is the first time I've ever heard of "UDP listening on all ports". I'm not saying it isn't useful, but perhaps our examples should be focused on use-cases that people have a clear use for?
So our draft had mechanism for the client to specify traffic selectors for what it actually considers to be individual IP flows. Think about how the rules to create IPv6 flow label works. MASQUE would need something that allows the client to indicate the necessary traffic selector that results in a IP flow, without having the local API interaction that for examples enables an stack to convert sockets into flows. I think this is the question we have here. And I don't think IP proto/next header is sufficient selector here.
RFC 6437 seems to say "Packet classifiers can use the triplet of Flow Label, Source Address, and Destination Address" which suggests to me that source address + destination address are the scopes within which flow label is evaluated. As a result, I don't see what changes we'd need here to support flow labels? It seems fine to pass them through unmodified here. If some extension wanted to add further traffic selectors that limit things by flow label, that would be possible without adding anything to the base draft.
NAME yes, for an on path device that does packet classification the flow label is scoped by the source and destination address. And that would be true in the case one only encapsulates whole IPv6 packets. However, as soon as the MASQUE endpoint becomes more flow aware one have to discuss a bit more on how this flow awareness is created. In endpoints the setting of IPv6 flow label is clearly created based on transport protocol flows. Also IPv6 flow labels could be a selector that would only work for IPv6. There is no IPv4 equivalent, and also what to do with zero flow label becomes interesting.
The protocol contains a mechanism that allows limiting the scope of the request, but doesn't explain why it would be desirable to do so. Can we add text explaining when a client would want to limit itself, and how a server can leverage this information?
Sure. I think the examples provide some insight here, but we should spell it out.
I still think that reasoning about this as a differ mode of operation helps. Depending on the use case, you either always or never want to limit the scope of your requests. There might be use case where both is used but I think the common mode of operation might be doing one or the other. In any case I agree that providing more reasoning is useful. Maybe this is part of an applicability section?
Yes, I think explaining a bit for what mechanism makes sense in which usages would help a lot.
Latest text LGTM

4.1. <ins> Unlike CONNECT-UDP requests, which require specifying a target host, CONNECT-IP requests can allow endpoints to send arbitrary IP packets to any host.  The client can choose to restrict a given request to a specific host or IP protocol by adding parameters to its request. When the server knows that a request is scoped to a target host or protocol, it can leverage this information to optimize its resource allocation; for example, the server can assign the same public IP address to two CONNECT-IP requests that are scoped to different hosts and/or different protocols. </ins> CONNECT-IP uses URI template variables (client-config) to determine the scope of the request for packet proxying.  All variables defined here are optional, and have default values if not included. specific host to which the client wants to proxy packets.  If the "target" variable is not specified, the client is requesting to communicate with any allowable host.  If the target is an IP  <ins> address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. </ins> The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If 6. <ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. 6.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote  <ins> server through the proxy.  Such VPN setups can be either full-tunnel or split-tunnel. In this case, the client does not specify any scope in its request. 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. 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 case, the advertised route is restricted to 2001:db8::/32, rather than ::/0. 6.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to  <ins> target.example.com using SCTP (IP protocol 132), and receives a single local address and remote address it can use for transmitting packets.  A similar approach could be used for any other IP protocol that isn't easily proxied with existing HTTP methods, such as ICMP, ESP, etc. In this case, the client specfies both a target hostname and an IP protocol number in the scope of its request, indicating that it only needs to communicate with a single host.  The proxy server is able to perform DNS resolution on behalf of the client and allocate a specific outbound socket for the client instead of allocating an entire IP address to the client.  In this regard, the request is similar to a traditional CONNECT proxy request. The server assigns a single IPv6 address to the client (2001:db8::1234:1234) and a route to a single IPv6 host (2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. 6.3. The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection establishement racing through a proxy, as defined in Happy Eyeballs RFC8305.  This example is a variant of the proxied flow, but highlights how IP-level proxying can enable new capabilities even for TCP and UDP. As with proxied flows, the client specfies both a target hostname and an IP protocol number in the scope of its request.  When the proxy server performs DNS resolution on behalf of the client, it can send the various remote address options to the client as separate routes. It can also ensure that the client has both IPv4 and IPv6 addresses assigned. The server assigns the client both an IPv4 address (192.0.2.3) and an IPv6 address (2001:db8::1234:1234) to the client, as well as an IPv4 route (198.51.100.2) and an IPv6 route (2001:db8::3456), which represent the resolved addresses of the target hostname, scoped to UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy. </ins> 7.


4.2.1. <del> The ADDRESS_ASSIGN capsule 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.  This capsule uses a Capsule Type of 0xfff100.  Its value uses the following format: </del>  IP Version of this address assignment.  MUST be either 4 or 6. 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>  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. Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule.  This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del>  IP Version of this route advertisement.  MUST be either 4 or 6. 4.2.4. <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>  IP Version of this route withdrawal.  MUST be either 4 or 6.

The current text in this draft needs to be updated to match the changes from URL I'll write up a PR once existing conflicting PRs are merged.
NAME is this unblocked now?

4.2.1.  <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. 4.2.2.  <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.  <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 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.  Any of these addresses can be used as the destination address on IP packets originated by the receiver of this capsule. </ins> IP Version of this route advertisement.  MUST be either 4 or 6. 4.2.4.  <ins> The ROUTE_WITHDRAWAL capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix. </ins> IP Version of this route withdrawal.  MUST be either 4 or 6.


address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client.  The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If

We should be clear that when a proxy resolves a hostname, it SHOULD give all results back as routes to the client (unless there is some policy to restrict it). Credit to NAME for proposing this
I agree
What is a client expected to do with this information? Say I ask for the proxy to connect to URL I get back a RA that includes the result of DNS lookups for URL (maybe multiple RAs that include all the answers from A/AAAA records?). Am I supposed to assume that this is the result of the DNS lookup? How do I distinguish that from other RAs that might just advertise where I might be able send packets via the tunnel? If the purpose of this is to provide name resolution, it is probably better to include an explicit signal. It's a bit of a rathole, but a new capsule type seems fairly obvious. That leads me to ask a whole bunch of questions about whether the proxy needs to supply a DNS service, ...
Nit: there is no port number. That's the status quo in this draft for hostname targets. The implicit signal here doesn't bother me, since it's unambiguous. I'm also fine with dropping support for DNS targets, although I think it might be useful in some scenarios.
Of course. I somehow got mislead by the first example: "URL{target}/{target_port}/"
Yeah, looks like that example had a copy paste error from CONNECT-UDP. I filed
The ability to specify a host to proxy to was important in our discussions for keeping parity with other proxying methods.
Indeed, that was bad copy-pasta from me, my apologies. It's been fixed in the editor's copy.
NAME thanks!
Thanks! ... wanted to raise the issue. URL". Section 4.1 says "route(s)", implying that the proxy might choose to advertise multiple routes to the target host, presumably because DNS resolution returned multiple A/AAAA records. I see the current text as an implicit "MAY return all the IP addresses", and I'm suggesting an upgrade to SHOULD.

address, the request will only support a single IP version.  If the target is a hostname, the server is expected to perform DNS resolution to determine which route(s) to advertise to the client. <ins> The server SHOULD send a ROUTE_ADVERTISEMENT capsule that includes routes for all usable resolved addresses for the requested hostname. </ins> The variable "ipproto" contains an IP protocol number, as defined in the "Assigned Internet Protocol Numbers" IANA registry.  If


be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the <del> End IP Address of A MUST be strictly lesser than the Start IP </del>  Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not or split-tunnel. In this case, the client does not specify any scope in its request. <del> 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. </del>  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

Edits collected while reading this draft. cc: NAME NAME
LGTM, thanks for this NAME !

be lesser or equal than IP Protocol of B. If the IP Version and IP Protocol of A and B are both equal, the  <ins> End IP Address of A MUST be strictly less than the Start IP </ins> Address of B. If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not or split-tunnel. In this case, the client does not specify any scope in its request.  <ins> The server assigns the client an IPv4 address (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


Clients are configured to use IP Proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables: <del> "target" and "ip_proto".  Examples are shown below: </del>  4.

Proposal for update to client configuration section. Would address . I would note that I think this proposal have some short comings that should be resolved before accepting. With the exception to the well known proposal here there is overlap with the corresponding example in connect-up and likely some separation with connect-UDP is desired. Connect-UDP did register the suffix as noted in text. However, should the URI paths under masque be managed somehow by IANA too?
I do not support defining a URI template for CONNECT-IP, especially if it requires port 443 endpoints to live in .well-known only.
NAME there's already a URI Template for where to put the target and protocol, I think the question is more about if there should be a well-known (which it doesn't currently).
Let's keep the discussion on issue folks
Specific regarding templates in general. How does one express the optionality of the variable and still be able to correctly parse the template. As currently formulated the template allows for either variables or both. How should the template be created to handle that?
As pointed by NAME is URL, there is currently no non-empty way to convey "any ipproto" or "any IP address of any address family". That can cause issues when using some path templates. It would be simple to define a non-empty way to convey "any". I propose using for this purpose. (I wouldn't use ipproto=0 to mean "any ipproto" because 0 means IPv6 Hop-by-Hop Options)
Yeah, using "" seems fine here
I didn't realise that the 0 for ipproto was actually broken. Will "" cause an type issue for ipproto? For target that is either an IP address literal or a hostname string. So what meaning does "" have for those types? As the target definition wasn't clear on what type definition that was used we need to start with agreeing on those types to verify that the "" is fine.
So I have now attempted to address this is PR . Please review.
There is no normative specification for the target IP address formats that can be used.
Agreed, this text could be formalized a bit more. In particular it should mention percent-encoding of colons in IPv6 addresses, and the fact that IPv6 scoped addressing zone identifiers are not supported. We could pull in some of the text from CONNECT-UDP.
So I have tried to clarify in PR the target specification to actually reference the URI spec and relevant syntax elements. I would note that IPv4 Literals has not that stringently defined, and points to the IPv4address syntax so I did that explicitly. I have assumed that we don't want the [ ] around the IPv6 address. I would note that Connect-UDP might be a bit louse on these aspects and could benefit from a similar change in Auth48 to include both a reference and the exact syntax element that are expected to be used.
Agreed. I filed URL to improve CONNECT-UDP, and once we have that there we can use that to inspire the text here
Align with CONNECT-UDP to use the well-known default template
CONNECT-IP currently doesn't have a concept of a "default URI template" the way CONNECT-UDP does. That concept was added to allow browsers to reuse their existing CONNECT configuration API when using HTTP/3. I think this concept might be useful in CONNECT-IP, but I'd rephrase this issue to say that we should investigate whether to add the concept of a default template or not. (If we decide to add it, I agree it should live under .well-known/masque to be consistent with CONNECT-UDP)
Are there any reasons to not add a default template?
I'm not opposed to adding it, I just want to make sure we don't add anything we don't have a use for.
I don't think the use cases are uniform enough that a default template makes sense right now. I would avoid adding it just on that reason alone. I also think it doesn't make sense in general because in CONNECT-IP you're connecting to the URL of the service endpoint itself, not some other destination in many of the the use cases.
After having started with text, I think the well known URI makes sense. However, it is fairly clear that requesting without target is one of the more likely use cases and maybe with a specific IP version. So these relations needs to be made clearer. But, I think not having some text on client configuration would be confusing, even if we just develop the well known.
We added a default template to CONNECT-UDP because existing Web browsers have a proxy API that doesn't currently support encoding a path. An example of such an API that can't easily be fixed is PAC files. Do we have a similar use-case for CONNECT-IP?
So my reason for thinking a well known also for connect IP is the following. We are considering using masque in mobile networks where we have first of all a multi-vendor situation for both MASQUE client and server, secondly the client will be thin one focused on establishing this connectivity and using it to provide network services. Although one could leave it up to 3GPP to define an HTTP API for its usage I think having one well defined one in the IETF specification have two advantages. First it reduces the barrier for using Connect-IP in a system, secondly it also ensures that we think through if there are aspects of its usage that impacts the part we absolutely need to specify for it to work at all. Looking at the client configuration and usage aspect here with the several types of usage we are considering for Connect-IP it is good to write consider the impact. Basic Client Configuration: Masque Server (Proxy) hostname or IP address and port for the service. Client usage cases and necessary information. Request IP tunnel for single borrowed address Request IP tunnel for IP flow to specific target: Target address or host name a) Request specific IP protocol: Additional specify IP proto Request tunnelling of IP prefix I want to ensure that it exist at least one defined way of achieving 1 and 2 with alternatives.
Thanks for clarifying. If I understand you correctly, in that scenario you'd still need a new mechanism to convey the hostname and port of the proxy right? Why can't that new mechanism carry a URI template instead? To get the use-cases 1,2,3 that you mentioned, you need a URI template, but you don't need a default URI template. I'm not proposing we remove the URI template, I'm asking whether we need a default URI template for cases when the hostname and port are known but the path is not.
So for the use case of the mobile network a default URI template would clearly be the simplest as hostname and ports for the proxy are things that there are good existing mechanism to configure a client with. But, not defining a default one would be the same as requiring the service to define their own API or template that works. I see that is problematic unless we actually provide example templates that actually works across the use case sets. The current template examples are not covering the breath of use case, nor if co-deployed with connect-UDP. I would propose that we hold of the question of the default a bit and first try to improve the client configuration section so that it discusses the requirements and also gives example for how to solve it with a template that covers the different use cases. I would note that for the use case I have in mind we will like to support all three of the cases above.
NAME can you elaborate on that? Apart from co-deployment with CONNECT-UDP, what specific use cases are not served by one of the templates that are currently in the draft?
I don't feel too strongly either way here. I wonder if the stronger reason to have a CONNECT-IP default template is specifically if it is not co-deployed with CONNECT-UDP, such that a browser would need to use CONNECT-IP instead of CONNECT-UDP. The rationale for having the default template in CONNECT-UDP is that there are browser use cases where it's not possible or convenient to add a full URI template. This assumes that general proxies would be supporting CONNECT-UDP, which is reasonable, but it's possible that some proxies would actually only do CONNECT-IP. So it may be useful to have the template for those. One of the use cases I have for CONNECT-IP is the ability to open up a UDP listener over the proxy — like how WebRTC can open a UDP socket that can receive traffic from peer-to-peer connections. That is a case where we'd use CONNECT-IP instead of CONNECT-UDP for browser traffic. In such a case, if the proxy was configured in the way that can't take a template, should CONNECT-IP indeed support a default template?
I think we need to figure out as a WG how to do UDP listening sockets over HTTP. I think an extension to CONNECT-UDP would make more sense, as non-Apple browsers don't have a UDP implementation nor an IP implementation. But maybe that's a topic in and of itself for 114? If we decide that CONNECT-IP is the way forward for UDP listening sockets, then adding a default template makes sense. If we decide on an extension to CONNECT-UDP, then we're back to not having a use-case for the default template. I'm going to think about this some more.
So to my understanding the only URI template that can work when both target and ipproto are optional is the query based one where the parameter is identified by a variable name in the template, e.g. "URL{target}&p={ipproto}". If one attempts for example to specify no target but ipproto in the following template "URL{target}/{ipproto}/" it doesn't work as the path becomes invalid. Also URL{?target,ip_proto} is dependent on both parameter being present as there are no Null values specified for target, there is the "0"=any for ipproto. So maybe let us start with having text for the template that actually makes it clear when they work and what limitations there are here. Because this is templates need more considerations than Connect-UDP. I think the question of a default is something we should discuss a bit more before making any decision on. I will see if I can update my PR to try to address the limitations on the template due to the optionality in the PR in the next few days and I can remove the well known part.
From my reading of RFC 9110, is a valid URI and is a valid path. That's a good point though, I think specifying something like "ipproto= means any" and "target= means any" would be a good idea. (I wouldn't do ipproto=0 because that means IPv6 Hop-by-Hop Options). I've filed to track this. I agree. Thanks, that would be great!
So PR has been updated to attempt to address the general need to consider this. I think this is a minimal general warning about the optionality. I do have one thing I am really uncertain about. I didn't discuss the "" usage for the value. If you construct a template are there any way to force the usage of rather than leaving it blank? I would appreciate some help in thinking about that issue. Or will you be forced to ensure that either work when writing the template and the template interpreter will be implementation dependent on what it does?
I think it's simpler to just omit the variable from the template if the configuration doesn't support scoping.
I didn't think about the case when the configuration does not support scoping. I was more thinking of the case when the client does not want to scope, is it omitting the variable freely, or can the template writer in some way force the client to inlace the "*" to indicate this. I don't understand this URI template well enough to answer the later is possible? And if not, then we can be clearer that as template writer you need to create a template where the variable can be omitted.
This is pretty straightforward: if the configuration wants to remove the ability to scope, all it needs to do is omit the variable. If the client wants to not scope even though the configuration supports it, the client can either omit the variable or send - so there's no requirement on the template since the client has both options.
So the main question if there should be a default template is not yet resolved.
Discussed offline. I'm OK with using a default template of where the two variables must be non-empty ( already means "any")
Oops, intended to make a PR.

Clients are configured to use IP Proxying over HTTP via an URI Template TEMPLATE.  The URI template MAY contain two variables:  <ins> "target" and "ipproto" (scope).  The optionality of the variables needs to be considered when defining the template so that either the variable is self-identifying or it works to exclude it in the syntax. Examples are shown below: The following requirements apply to the URI Template: The URI Template MUST be a level 3 template or lower. The URI Template MUST be in absolute form, and MUST include non- empty scheme, authority and path components. The path component of the URI Template MUST start with a slash "/". All template variables MUST be within the path or query components of the URI. The URI template MAY contain the two variables "target" and "ipproto" and MAY contain other variables. The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E inclusive (note that percent-encoding is allowed; see Section 2.1 of URI. The URI Template MUST NOT use Reserved Expansion ("+" operator), Fragment Expansion ("#" operator), Label Expansion with Dot- Prefix, Path Segment Expansion with Slash-Prefix, nor Path-Style Parameter Expansion with Semicolon-Prefix. Clients SHOULD validate the requirements above; however, clients MAY use a general-purpose URI Template implementation that lacks this specific validation.  If a client detects that any of the requirements above are not met by a URI Template, the client MUST reject its configuration and abort the request without sending it to the IP proxy. </ins> 4.


7.  CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used. <del> 7.1. </del>  The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0. <del> 7.2. </del>  The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to (2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host. <del> 7.3. </del>  The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy. <del> 8. </del>  There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks. <del> 9. </del>  <del> 9.1. </del>  This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> 9.2. </del>  This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

What is the behavior when an endpoint sends a packet for which it didn’t have an assigned source address or a valid destination route. Is this cause for dropping the packet silently, sending an error capsule, or closing the request stream with an error? Closing the stream too harshly may be problematic if the packet was valid in some previous routing table, but now is not.
I think that's a policy decision that is out of scope for this document. Some deployments will most likely implement BCP38 filtering, but that's not required of all uses of this protocol.
I agree it's a policy decision. In our implementation today we send and ICMP administratively prohibited and drop the packet. I would personally be comfortable with that being a SHOULD recommendation.
This was discussed in the room at IETF 113 and it sounded like ICMP seemed like the most liked option.
I think the decision to send ICMP or not is out of scope for this document. However, we can maybe still have an optional masque error capsule given the packet received doesn't fit the masque request. The question is, can the client do anything useful with this information? I guess the difference to ICMP is that you know this is a MASQUE issue and not something else.
I think that the issue of an IP packet not fitting in an HTTP Datagram is not specific to MASQUE - it's a very standard path MTU issue that can be communicated with ICMP Packet Too Big. I propose we add some text recommending to use ICMP when packets are dropped due to policy, path MTU, etc.
I think ICMP for dropping packets for policies and Packet Too Big etc is fine. However, I would note that we likely should consider recommendations regarding source address validation. But I can open another issue on that as I think this is one security function that should be recommended to be implemented especially for Proxies that intended to let the client reach general Internet.
Regarding source address validation, I propose we recommend deployments follow BCP 38 where applicable. Would that resolve this issue?
Actually I just saw you filed about source address validation, let's discuss BCP 38 there. Based on the discussion here, we can resolve this issue by writing a PR that recommends sending ICMP to signal packet loss due to policy, path MTU, etc.
Yes, lets start with that, as it is likely to resolve this aspect.
Not sure if this covers everything. We can use paceket-too-big and destination-unreachable but what if the source address is not allowed by the proxy?
We use Administratively Prohibited for that in our implementation.
you mean in the client or server? However, if the server receives a packet with a prohibited source IP address, shouldn't you eventually send an error somehow back to the client?
Interesting for client address errors. That could use type 12, Parameter Problem? But not sure.
I don't think that would be helpful for the client at all...
This issue got closed with merging PR however I don't think it's fully resolved yet. Should we re-open?
I think the broader issue of ICMP is resolved, NAME can you filed another issue for your more specific point? That way it'll have a cleaner history.

7. <ins> Since CONNECT-IP endpoints often forward IP packets onwards to other network interfaces, they need to handle errors in the forwarding process.  For example, forwarding can fail if the endpoint doesn't have a route for the destination address, or if it is configured to reject a destination prefix by policy, or if the MTU of the outgoing link is lower than the size of the packet to be forwarded.  In such scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP to signal the forwarding error to its peer. 8. </ins> CONNECT-IP enables many different use cases that can benefit from IP packet proxying and tunnelling.  These examples are provided to help illustrate some of the ways in which CONNECT-IP can be used.  <ins> 8.1. </ins> The following example shows a point-to-network VPN setup, where a client receives a set of local addresses, and can send to any remote case, the advertised route is restricted to 192.0.2.0/24, rather than 0.0.0.0/0.  <ins> 8.2. </ins> The following example shows an IP flow forwarding setup, where a client requests to establish a forwarding tunnel to (2001:db8::3456), scoped to SCTP.  The client can send and recieve SCTP IP packets to the remote host.  <ins> 8.3. </ins> The following example shows a setup where a client is proxying UDP packets through a CONNECT-IP proxy in order to control connection UDP.  The client can send and recieve UDP IP packets to the either of the server addresses to enable Happy Eyeballs through the proxy.  <ins> 9. </ins> There are significant risks in allowing arbitrary clients to establish a tunnel to arbitrary servers, as that could allow bad they SHOULD follow the guidance in BCP38 to help prevent denial of service attacks.  <ins> 10. </ins>  <ins> 10.1. </ins> This document will request IANA to register "connect-ip" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>.  <ins> 10.2. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:


ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses.  4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the

From ekr: S 4.2. Is the server required to send ADDRESS_ASSIGN? If not, what is the client supposed to use as it's source address? Also, what happens if you only get a v6 address but need to talk to a v4 endpoint, or vice versa.
For traditional proxy/VPN cases, I think this is required. It's possible the client could not get an address assign, and but a blank/bogus source IP that it expects a proxy to overwrite, but I don't think that's a good idea (and would also change the checksum values of higher-level protocols). Probably the best thing to say is that any peer that can send packets MUST first have received an ADDRESS_ASSIGN capsule.
I think we should keep the text on these capsules bidirectional. In the consumer VPN scenario, the client isn't going to send anything until it has received an ADDRESS_ASSIGN capsule. But in that same scenario, the same property isn't true of the server.
I agree that we should have the text be bidirectional—but I think just saying "an endpoint can only send packets after it receives an ADDRESS_ASSIGN capsule" meets that bill, right?
But in the consumer VPN scenario, the client isn't sending an ADDRESSASSIGN to the server. So if we apply your "an endpoint can only send packets after it receives an ADDRESSASSIGN capsule", then the server can't send any packets
How about we add some non-normative guidance text to resolve this? Like saying that in scenarios where addresses are not known before the request (e.g., the client doesn't know its address in the consumer VPN scenario) then the other endpoint would be well served to send ADDRESS_ASSIGN for things to work.
I think this would be easier to add text for if we had the high level usages named. Because clearly for the use cases where the masque proxy lends out an address to provide access from its point of presence it is clear that it does need to assign one. For the case of interconnecting networks it is instead fairly clear that some other level of configuration is necessary of both client and proxy to make this work in a secure fashion.
Since you used "clear" three times in your last comment, I think it's pretty clear to everyone when it makes sense to send ADDRESS_ASSIGN or not. Do we actually need to say anything in the draft?
Bad writing of me to use so much clear. I would argue that the text should make it clear that there are cases when it doesn't need to assign address. However, I would note that it actually becomes difficult for the server to judge this in the case of interconnecting networks. This due to that the defining behaviours for this usage comes first when the HTTP request has been accepted and the capsules with address assign request and route advertisements starts being sent. So I start to wonder if there isn't need for an parameter in the HTTP request if address is to be assigned, or does the equivalent of the address assigned capsule need to be moved to the HTTP request?
In practice, a CONNECT-IP server isn't going to be running in these multiple modes, and if it does, it'll know which mode it's in from the authentication that was carried in an HTTP header with the request. Do you have a use-case where the server could be confused here?
I think we have one case where it can become confusing. So an ATSSS enabled mobile (UE) uses MASQUE as part of its signalling for the traffic policies for flows. However a mobile is also often used to tether other devices. So it have both its own address and a local area network it like to tunnel over the same tunnel. So this confusion is something we can actually encounter when the UE has its own address and the tethered networks prefix. The existing solution when it comes to IPv6 has been the UE uses one or more of the addresses from the /64 for its own use, as well providing the LAN with addresses. However, that does create some issues, rather than having two /64s for IPv6. For IPv4 I think what one can assume here when it comes to address assignment is even more murky.
I wonder if we want something similar to SETTINGS to convey the types of CONNECT-IP a server is willing to participate in?
I really don't think the type of CONNECT-IP in use needs to be sent over the wire. The ATSSS server will know that it is an ATSSS server, and same for the client. I see Magnus' point that if the ATSSS server sends two prefixes to the client, the client doesn't know which /64 is for the UE and which one is for the tethered devices. However, since this problem is specific to ATSSS, I think that information can be conveyed in an ATSSS-specific extension capsule.
NAME I think I have to disagree here about that we should push this to usage specific extension. I think we need to for example as that is part of the request input that may make it easier to resolve the best way forward for the aspect of how and when servers need to send address_assign and how that impact the client.
I think this is a useful clarification that we can add to the document. However, I am not certain that it resolves all the aspects of the .

ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. <ins> In some deployments of CONNECT-IP, an endpoint needs to be assigned an address by its peer before it knows what source address to set on its own packets.  For example, in the Remote Access case (example- remote) the client cannot send IP packets until it knows what address to use.  In these deployments, endpoints need to send ADDRESS_ASSIGN capsules to allow their peers to send traffic. </ins> 4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the


establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated <del> users.  The HTTP Authorization header AUTH MAY be used to </del>  authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.

Fixing some ID nits validations errors include update references from drafts to RFCs for SEMANTICS and H3 Websockets draft.

establish a tunnel to arbitrary servers, as that could allow bad actors to send traffic and have it attributed to the proxy.  Proxies that support CONNECT-IP SHOULD restrict its use to authenticated  <ins> users.  The HTTP Authorization header SEMANTICS MAY be used to </ins> authenticate clients.  More complex authentication schemes are out of scope for this document but can be implemented using CONNECT-IP extensions.


of the URI. The URI template MAY contain the two variables "target" and <del> "ipproto" and MAY contain other variables. </del>  The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E reject its configuration and abort the request without sending it to the IP proxy.  4. This document defines the "connect-ip" HTTP Upgrade Token. "connect- 10.2.  This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:

Align with CONNECT-UDP to use the well-known default template
CONNECT-IP currently doesn't have a concept of a "default URI template" the way CONNECT-UDP does. That concept was added to allow browsers to reuse their existing CONNECT configuration API when using HTTP/3. I think this concept might be useful in CONNECT-IP, but I'd rephrase this issue to say that we should investigate whether to add the concept of a default template or not. (If we decide to add it, I agree it should live under .well-known/masque to be consistent with CONNECT-UDP)
Are there any reasons to not add a default template?
I'm not opposed to adding it, I just want to make sure we don't add anything we don't have a use for.
I don't think the use cases are uniform enough that a default template makes sense right now. I would avoid adding it just on that reason alone. I also think it doesn't make sense in general because in CONNECT-IP you're connecting to the URL of the service endpoint itself, not some other destination in many of the the use cases.
After having started with text, I think the well known URI makes sense. However, it is fairly clear that requesting without target is one of the more likely use cases and maybe with a specific IP version. So these relations needs to be made clearer. But, I think not having some text on client configuration would be confusing, even if we just develop the well known.
We added a default template to CONNECT-UDP because existing Web browsers have a proxy API that doesn't currently support encoding a path. An example of such an API that can't easily be fixed is PAC files. Do we have a similar use-case for CONNECT-IP?
So my reason for thinking a well known also for connect IP is the following. We are considering using masque in mobile networks where we have first of all a multi-vendor situation for both MASQUE client and server, secondly the client will be thin one focused on establishing this connectivity and using it to provide network services. Although one could leave it up to 3GPP to define an HTTP API for its usage I think having one well defined one in the IETF specification have two advantages. First it reduces the barrier for using Connect-IP in a system, secondly it also ensures that we think through if there are aspects of its usage that impacts the part we absolutely need to specify for it to work at all. Looking at the client configuration and usage aspect here with the several types of usage we are considering for Connect-IP it is good to write consider the impact. Basic Client Configuration: Masque Server (Proxy) hostname or IP address and port for the service. Client usage cases and necessary information. Request IP tunnel for single borrowed address Request IP tunnel for IP flow to specific target: Target address or host name a) Request specific IP protocol: Additional specify IP proto Request tunnelling of IP prefix I want to ensure that it exist at least one defined way of achieving 1 and 2 with alternatives.
Thanks for clarifying. If I understand you correctly, in that scenario you'd still need a new mechanism to convey the hostname and port of the proxy right? Why can't that new mechanism carry a URI template instead? To get the use-cases 1,2,3 that you mentioned, you need a URI template, but you don't need a default URI template. I'm not proposing we remove the URI template, I'm asking whether we need a default URI template for cases when the hostname and port are known but the path is not.
So for the use case of the mobile network a default URI template would clearly be the simplest as hostname and ports for the proxy are things that there are good existing mechanism to configure a client with. But, not defining a default one would be the same as requiring the service to define their own API or template that works. I see that is problematic unless we actually provide example templates that actually works across the use case sets. The current template examples are not covering the breath of use case, nor if co-deployed with connect-UDP. I would propose that we hold of the question of the default a bit and first try to improve the client configuration section so that it discusses the requirements and also gives example for how to solve it with a template that covers the different use cases. I would note that for the use case I have in mind we will like to support all three of the cases above.
NAME can you elaborate on that? Apart from co-deployment with CONNECT-UDP, what specific use cases are not served by one of the templates that are currently in the draft?
I don't feel too strongly either way here. I wonder if the stronger reason to have a CONNECT-IP default template is specifically if it is not co-deployed with CONNECT-UDP, such that a browser would need to use CONNECT-IP instead of CONNECT-UDP. The rationale for having the default template in CONNECT-UDP is that there are browser use cases where it's not possible or convenient to add a full URI template. This assumes that general proxies would be supporting CONNECT-UDP, which is reasonable, but it's possible that some proxies would actually only do CONNECT-IP. So it may be useful to have the template for those. One of the use cases I have for CONNECT-IP is the ability to open up a UDP listener over the proxy — like how WebRTC can open a UDP socket that can receive traffic from peer-to-peer connections. That is a case where we'd use CONNECT-IP instead of CONNECT-UDP for browser traffic. In such a case, if the proxy was configured in the way that can't take a template, should CONNECT-IP indeed support a default template?
I think we need to figure out as a WG how to do UDP listening sockets over HTTP. I think an extension to CONNECT-UDP would make more sense, as non-Apple browsers don't have a UDP implementation nor an IP implementation. But maybe that's a topic in and of itself for 114? If we decide that CONNECT-IP is the way forward for UDP listening sockets, then adding a default template makes sense. If we decide on an extension to CONNECT-UDP, then we're back to not having a use-case for the default template. I'm going to think about this some more.
So to my understanding the only URI template that can work when both target and ipproto are optional is the query based one where the parameter is identified by a variable name in the template, e.g. "URL{target}&p={ipproto}". If one attempts for example to specify no target but ipproto in the following template "URL{target}/{ipproto}/" it doesn't work as the path becomes invalid. Also URL{?target,ip_proto} is dependent on both parameter being present as there are no Null values specified for target, there is the "0"=any for ipproto. So maybe let us start with having text for the template that actually makes it clear when they work and what limitations there are here. Because this is templates need more considerations than Connect-UDP. I think the question of a default is something we should discuss a bit more before making any decision on. I will see if I can update my PR to try to address the limitations on the template due to the optionality in the PR in the next few days and I can remove the well known part.
From my reading of RFC 9110, is a valid URI and is a valid path. That's a good point though, I think specifying something like "ipproto= means any" and "target= means any" would be a good idea. (I wouldn't do ipproto=0 because that means IPv6 Hop-by-Hop Options). I've filed to track this. I agree. Thanks, that would be great!
So PR has been updated to attempt to address the general need to consider this. I think this is a minimal general warning about the optionality. I do have one thing I am really uncertain about. I didn't discuss the "" usage for the value. If you construct a template are there any way to force the usage of rather than leaving it blank? I would appreciate some help in thinking about that issue. Or will you be forced to ensure that either work when writing the template and the template interpreter will be implementation dependent on what it does?
I think it's simpler to just omit the variable from the template if the configuration doesn't support scoping.
I didn't think about the case when the configuration does not support scoping. I was more thinking of the case when the client does not want to scope, is it omitting the variable freely, or can the template writer in some way force the client to inlace the "*" to indicate this. I don't understand this URI template well enough to answer the later is possible? And if not, then we can be clearer that as template writer you need to create a template where the variable can be omitted.
This is pretty straightforward: if the configuration wants to remove the ability to scope, all it needs to do is omit the variable. If the client wants to not scope even though the configuration supports it, the client can either omit the variable or send - so there's no requirement on the template since the client has both options.
So the main question if there should be a default template is not yet resolved.
Discussed offline. I'm OK with using a default template of where the two variables must be non-empty ( already means "any")
Oops, intended to make a PR.

of the URI. The URI template MAY contain the two variables "target" and  <ins> "ipproto" and MAY contain other variables.  If the "target" or "ipproto" variables are included, their values MUST NOT be empty. Clients can instead use "*" to indicate wildcard or no-preference values, see scope. </ins> The URI Template MUST NOT contain any non-ASCII unicode characters and MUST only contain ASCII characters in the range 0x21-0x7E reject its configuration and abort the request without sending it to the IP proxy. <ins> As with CONNECT-UDP, some client configurations for CONNECT-IP proxies will only allow the user to configure the proxy host and proxy port.  Clients with such limitations MAY attempt to access IP proxying capabilities using the default template, which is defined as: "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ ip/{target}/{ipproto}/", where $PROXY_HOST and $PROXY_PORT are the configured host and port of the IP proxy, respectively.  IP proxy deployments SHOULD offer service at this location if they need to interoperate with such clients. </ins> 4. This document defines the "connect-ip" HTTP Upgrade Token. "connect- 10.2. <ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at <<https://www.iana.org/assignments/well-known-uris>>. IANA is requested to update the "Reference" field to include this document in addition to previous values from that field. 10.3. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry created by HTTP-DGRAM:


Datagrams with payloads of at least 1280 bytes).  This can be accomplished using various techniques: <del> if HTTP intermediaries are not in use, both CONNECT-IP endpoints can pad the QUIC INITIAL packets of the underlying QUIC connection that CONNECT-IP is running over. if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. </del>  CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out <del> of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. </del>  Endpoints MAY implement additional filtering policies on the IP packets they forward.

I think there are two option here, 1) close/deny the connect request, and 2) use streams instead. I think we should consider both option, especially given stream are just there to use.
Isn't this a dup of ? That's fixed with . I guess the text could be generalized to talk about more than just IPv6 MTU issues.
No, this aspect on what you do when the MTU required is not present is not resolved by that PR. I would note that closing gives the endpoints one experience that is likely easier to handle in implementation and do avoid the issue with reordering and the varying packet treatment that moving to stream would result.
I would suggest adding a sentence saying that if an endpoint realizes that the IPv6 tunnel MTU goes lower than 1280, then it MUST close the stream.
IETF 114: Note that if something happens and your MTU gets smaller, you may need to destroy that link. Potentially make this option a SHOULD do PMTUD, otherwise you could end up in a situation where you're not a compliant IPv6 tunnel. Proposal:
Even if PR was an improvement to the description of the IPv6 minimal link MTU issue the text still leaves an open issue in that it doesn't make clear which of the endpoints that are responsible for HTTP intermediaries or if is truly both which has another implication. So a Connect-IP endpoint will be aware of the HTTP datagram supported MTU and if its HTTP/3 connection can support sending at least 1280 bytes of IPv6 packets without fragmentation. However, if there is two or more HTTP intermediaries in between the client and the server then there are HTTP intermediaries that might have an HTTP/3 connection which has less than 1280 bytes MTU for HTTP datagram payloads in-between the client and server. Thus, arises the issue of how to detect this. PR states: if HTTP intermediaries are in use, CONNECT-IP endpoints can enter in an out of band agreement with the intermediaries to ensure that endpoints and intermediaries pad QUIC INITIAL packets. From my perspective the big question is how a client or a server knows that there are intermediaries, or the most important aspect, that there are no unknown HTTP intermediaries. To my understanding both the client and the server can potentially bring in HTTP intermediaries unknown to the other part. Thus resulting in a HTTP intermediary to intermediary connection where neither endpoint knows if the requirement is fulfilled. Thus my interpretation is that the only way to be sure that it works it to actually execute on the third bullet in the PR: CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response. Unless endpoints have an out of band means of guaranteeing that one of the two previous techniques is sufficient, they MUST use this method. I would also note that this only verifies from the acting endpoint towards its peer, not the reverse path. For that to be verified the peer need to send ICMP probes the other direction. Thus, my conclusion is that Connect-IP still don't ensure that the minimal MTU is fulfilled.
Isn't the quick-fix to require that the ICMP reply also be 1232 byte sized?
Normally I would say now, as you want to ensure that the reply makes it back that shouldn't be padded. Also if the response is anything else than echo reply you also should not pad. However, I think the implication is the same either way. Both masque client and server need to send ICMP or modify its ICMP processing. Given that I would think having each endpoint doing independent processing of its forward path might actually be simpler and enables using a standard off the shelf ICMP implementation and not have to modify it.
Our implementation has userspace ICMP request/response handling for echo request/response, it wasn't too hard to write. I don't propose modifying anything, but the structures were ~50 lines of code to set up. I agree we shouldn't be modifying responses we did not generate.
I think the existing text already is generic to "endpoint", not client or server: So this implies that both sides need to send the PING if they haven't guaranteed the MTU. This seems like this is already handled?
If both endpoints are required to send ping it would be resolved. However, that is not what is written in the draft currently. What is written is the there are various techniques, and if an endpoint choses something else than verifying its forward path using ping, it becomes unclear who is actually responsible for any HTTP intermediaries. Which results in an unclear requirement and very likely failure of the MTU verification resulting in an MTU black hole.
Well, it does say that endpoints MUST use this method unless the already have other coordination. I could see some clarification text to say that the guarantee for the other methods must include knowing there isn't an intermediary — which is actually pretty easy to guarantee in many cases.
That is what I intended when writing , but perhaps I wasn't clear. Can one of you propose a PR that would clarify this?
This PR is good but I don't this is fully addresses

Datagrams with payloads of at least 1280 bytes).  This can be accomplished using various techniques:  <ins> if both endpoints know for certain that HTTP intermediaries are not in use, the endpoints can pad the QUIC INITIAL packets of the underlying QUIC connection that CONNECT-IP is running over. (Assuming QUIC version 1 is in use, the overhead is 1 byte type, 20 bytes maximal connection ID length, 4 bytes maximal packet number length, 1 byte DATAGRAM frame type, 8 bytes maximal quarter stream ID, one byte for the zero context ID, and 16 bytes for the AEAD authentication tag, for a total of 51 bytes of overhead which corresponds to padding QUIC INITIAL packets to 1331 bytes or more.) </ins> CONNECT-IP endpoints can also send ICMPv6 echo requests with 1232 bytes of data to ascertain the link MTU and tear down the tunnel if they do not receive a response.  Unless endpoints have an out  <ins> of band means of guaranteeing that the previous techniques is sufficient, they MUST use this method. If an endpoint is using QUIC DATAGRAM frames to convey IPv6 packets, and it detects that the QUIC MTU is too low to allow sending 1280 bytes, it MUST abort the CONNECT-IP stream. </ins> Endpoints MAY implement additional filtering policies on the IP packets they forward.


11.3. This document will request IANA to add the following values to the <del> "HTTP Capsule Types" registry created by HTTP-DGRAM: </del>

There should be a reference providing an URL for the Assigned Internet Protocol Number registry in this document, not just the name, even if this is formally sufficient. The URL is: URL

11.3. This document will request IANA to add the following values to the  <ins> "HTTP Capsule Types" registry maintained at <<https://www.iana.org/assignments/http-capsule-protocol/http- capsule-protocol.xhtml>>. </ins>


The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses. <del> Note that an ADDRESS_ASSIGN capsule can also indicate that a previously assigned address is no longer assigned.  An ADDRESS_ASSIGN capsule can also be empty. </del>  In some deployments of IP proxying in HTTP, an endpoint needs to be assigned an address by its peer before it knows what source address

If an endpoint have received first ADDRESSASSIGN capsule with some address and then receives a subsequent ADDRESSASSIGN capsule the document does not explain the meaning of this. There are several cases: A) Just additional addresses are provided B) Some removal C) Some information are updated D) Combinations I think A) is straight forward and likely to occur. I think B) will happen when some connect-ip requests have been closed, and the need for an address does not any longer exist while a new request has come in. Can C) occur? I guess combinations are possible due to timing. I also think the intention here is to have the new capsule completely replace the old one, and that is also not explicit in the text. I think some clarification on this will be needed to ensure robust implementations.
Fixed by
realize that we need to remember this text from RFC 9000: "Packet and frame diagrams in this document use a custom format. The purpose of this format is to summarize, not define, protocol elements. Prose defines the complete semantics and details of structures." The issue is with at least the adderss assigned capsule: The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses.¶ Assigned Address { Request ID (i), IP Version (8), IP Address (32..128), IP Prefix Length (8), } Figure 4: Assigned Address Format Request ID: If this address assignment is in response to an Address Request (see Section 4.6.2), then this field SHALL contain the value of the corresponding field in the request. Otherwise, this field SHALL be zero.¶ IP Version: IP Version of this address assignment. MUST be either 4 or 6.¶ IP Address: Assigned IP address. 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.¶ IP Prefix Length: 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 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.¶ So the actual data format is missing for IP version and IP prefix, and only implicit for IP Address. I would guess they are both unsinged int, but that is not specified. Also the ones that use variable integer encoding from QUIC should be explicit about that. Same corrections needs to be applied to the other capsules.

The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses.  <ins> If an ADDRESS_ASSIGN capsule does not contain an address that was sent previously transmitted in another ADDRESS_ASSIGN capsule, that indicates that the address has been removed.  An ADDRESS_ASSIGN capsule can also be empty, that indicates that all addresses have been removed. </ins> In some deployments of IP proxying in HTTP, an endpoint needs to be assigned an address by its peer before it knows what source address


optionally indicate a preference for which address it would get assigned. <del> The ADDRESS_REQUEST capsule contains a sequence of zero or more </del>  Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that requested address, and that it can also assign some requested addresses but not others.  4.6.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the End IP Address of A MUST be strictly less than the Start IP Address of B. <del> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not </del>  meet these requirements, it MUST abort the IP proxying request stream.

"The ADDRESS_REQUEST capsule contains a sequence of zero or more Requested Addresses." In cases there are zero Requested Addresses what does this mean? It appears that this is an even less determined form than the all zero block , that at least indicates an address family support or preference as well as prefix length by including one or two all-zero address of the families the endpoint want assigned? Should this be explicitly stated?

optionally indicate a preference for which address it would get assigned.  <ins> The ADDRESS_REQUEST capsule contains a sequence of one or more </ins> Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that requested address, and that it can also assign some requested addresses but not others. <ins> If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream. </ins> 4.6.3. The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the End IP Address of A MUST be strictly less than the Start IP Address of B.  <ins> If an endpoint receives a ROUTE_ADVERTISEMENT capsule that does not </ins> meet these requirements, it MUST abort the IP proxying request stream.


"target" and "ipproto" variables MUST adhere to the format in target- format, using notation from ABNF.  Additionally: <del> if "target" contains an IPv6 literal, the colons (":") MUST be percent-encoded.  For example, if the target host is </del>  "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".

So the description of target says: The variable "target" contains a hostname or IP prefix of a specific host to which the client wants to proxy packets. If the "target" variable is not specified or its value is "", the client is requesting to communicate with any allowable host. "target" supports using DNS names, IPv6 literals and IPv4 literals. Further down the the ABNF is stating: target = IPv6prefix / IPv4prefix / reg-name / "" IPv6prefix = IPv6address ["%2F" 13DIGIT] IPv4prefix = IPv4address ["%2F" 12DIGIT] ipproto = 13DIGIT / "" Thus, the text is inconsistent where the first indicates hostnames and prefixes. Second indicates hostnames (as DNS names) and IPv4/6 Literals, but not prefixes. Then the ABNF indicates Prefixes and reg-name. So if it is only the prefix construct and hostnames then the text about literals directly needs to be addressed. If it is hostnames, IPvX literals, and IPprefix the ABNF and description need to be addressed.
I think you misread the ABNF? It allows hostnames and IP prefixes, that's what the is for. Also those brackets indicate optionality of the prefix.
I think the ABNF is fine. It's the text that once talks about IP prefixes and once about IP literals.
Ah! Thank you, will fix via PR

"target" and "ipproto" variables MUST adhere to the format in target- format, using notation from ABNF.  Additionally:  <ins> if "target" contains an IPv6 literal or prefix, the colons (":") MUST be percent-encoded.  For example, if the target host is </ins> "2001:db8::42", it will be encoded in the URI as "2001%3Adb8%3A%3A42".


protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an <del> HTTP server that acts as a proxy. </del>  1. 11.2.  This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at <<https://www.iana.org/assignments/well-known-uris>>. IANA is requested to update the "Reference" field to include this document in addition to previous values from that field. <del> 11.3. </del>  This document will request IANA to add the following values to the "HTTP Capsule Types" registry maintained at

See
LGTM, thanks. Might be worth mentioning that those are relative to .well-known explicitly in the registry def?
Have we checked with the expert NAME what the preferred way of documenting that multiple document specify different part of the sub-path after the initial prefix? I would feel that we need to be clearer that we want IANA to add this information to what is already existing. The use of just update can easily mean replace which would not be correct. I also wonder if this should be an additional entry line or just kept in the same entry is unclear to me. I could see that one actually split the current masque entry into two, one for masque/udp and one for masque/ip
So for clarity this is about this section: https://ietf-wg-URL
I imagine this should imitate what CONNECT-UDP published for its RFC?
NAME the issue I see her is the fact that UDP and IP tries to share the same well known suffix of "masque". So the question that arises here is how we are tracking the sub-identifiers and their references in this registry. So UDP created this registry, but does not specify a sub-registry, if it did that would be the registry we would add "ip" to. Instead it appears the current intention are adding both references into the same registry entry. And if we are doing that we need to be more careful in our instructions to IANA. A third way forward would be to register "masque/ip" as the well known suffix and get a separate entry into the table. URL I also think we haven't discussed this much, and I think we should rope in the expert into this discussion. I think we will have to move to email for that. But I want to check with the other authors first, I think we especially want NAME thoughts here about it. I am willing to drive the question towards the MASQUE WG, the IANA expert (Mark Nottingham) and I assume it is HTTPBIS WG that might have additional input into this.
The registry cannot and will not allow strings like -- the only registrable string is what's legal as a path segment. Managing the space "under" the registered path segment is up to the registrant. You could create a sub-registry, or you could just update the registering document when you need to expand it.
Thanks NAME thus I think this is an issue we need to take to the MASQUE WG to discuss how to bet handle and if there should be put in place some additional registries under the masque suffix.
Started discussion on the masque mailing list: URL WG, When doing a review of the connect-ip draft and its IANA consideration I realized that we will have to clarify a bit how to handle the well-known names URI suffix “masque”. So Connect-UDP (RFC 9298) registers the “masque” suffix. But the draft is also clear that it only uses the masque/udp path. Connect IP wants to use the masque/ip path. However, the suffix registry only allows registering a suffix for a single path element, i.e. “masque”. Thus, arise the question of the future management of this sub-space of “masque”. It is likely that some additional extended connect usages will be specified in the future for other protocols. Thus, others will likely follow in the track of what we do with Connect-IP. The main goal here as I see it is to ensure that we track what is in use to avoid collisions and that one can reverse look up this name space back to specification. For these purposes I see two routes that appear compatible with the existing registry. We update the URL entry for “masque” to list all currently known usages and specifications. We create a sub-registry for the masque space and in that add “udp” and “ip” as entries and update the existing well known uris registry to reference the changing spec and the new sub-registry. I think A) is clearly easier at this point. However, if we forsee that more than one or two more protocols will register additional sub-entries then I think we really should consider B). And doing B) now is simpler than doing it later when you have more RFCs that will not be aligned with this usage. Opinions? Cheers Magnus Westerlund

protocol is similar to UDP proxying in HTTP, but allows transmitting arbitrary IP packets.  More specifically, this document defines a protocol that allows an HTTP client to create an IP tunnel through an  <ins> HTTP server that acts as a proxy.  This document updates RFC 9298. </ins> 1. 11.2. <ins> This document requests that IANA create a new "MASQUE URI Suffixes" registry maintained at IANA_URL_TBD.  This new registry governs the path segment that immediately follows "masque" in paths that start with "/.well-known/masque/", see <<https://www.iana.org/assignments/ well-known-uris>> for the registration of "masque" in the "Well-Known URIs" registry.  This new registry contains three columns: The registration policy for this registry is Expert Review; see IANA- POLICY. There are initially two entries in this registry: 11.3. </ins> This document will request IANA to update the entry for the "masque" URI suffix in the "Well-Known URIs" registry maintained at <<https://www.iana.org/assignments/well-known-uris>>. IANA is requested to update the "Reference" field to include this document in addition to previous values from that field.  <ins> IANA is requested to replace the "Related Information" field with "For sub-suffix allocations, see registry at IANA_URL_TBD." where IANA_URL_TBD is the URL of the new registry described in iana-suffix. 11.4. </ins> This document will request IANA to add the following values to the "HTTP Capsule Types" registry maintained at


length it is requesting. Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign <del> an IP address to its peer, and then respond with an ADDRESS_ASSIGN capsule to inform the peer of the assignment.  Note that the receiver of the ADDRESS_REQUEST capsule is not required to assign the requested address, and that it can also assign some requested addresses but not others. </del>  If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream.

IIUC the recipient of an ADDRESSREQUEST has to respond one way or another, using ADDRESSASSIGN. Via , it is possible to reject a request and send a "null response" back. Per ADDRESSASSIGN Technically, the address was never given, so sending a "null address" just once and then never sending it again is probably a good move - it limits the commitment to remember full details and reduces capsule transfer size. Endpoints that try to send a complete list of addresses in every ADDRESSASSIGN, including the null ones, might find they could get aboused, because its a lot simpler to send a short request with a unique request ID, than to respond to it. Probably nothing needs to change in the protocol but adding some considerations for implementers might be nice.
That's fair, we should say that the all-zero addresses don't need to be repeated in future capsules
Preferences for SHOULD NOT be repeated vs MUST NOT be repeated?
If an endpoint sends a polite ADDRESS_REQUEST that is well formed but the receiver can't or won't action it, there's no feedback. Since capsules are sent reliably, we can depend on them making it to the peer, but not necessarily being procesed. If the request is blackholed, should it, for example, ever be retried? There's a difference between a proxy refusing to do something and it temporarily being unable to do it (possibly due to resource constraints or rate limiting).
I don't think we currently have support for an ADDRESS_REQUEST capsule not being replied-to. The current language is written with the expectation that every REQUEST gets a RESPONSE. SO I would expect that if the request cannot be satisfied (i.e., is rejected) you get the rejection response that NAME just committed. So I would expect a proxy that is being rate-limited to respond, just slowly.
NAME please see URL
Thanks! makes it clearer how to assertively respond, which is good. However, the text IP addresses to its peer, and then respond with an ADDRESSASSIGN capsule to inform the peer of the assignment. This SHOULD is a bit hairy. Maybe it would be clear to split these out and state that a receiver of an ADDRESSREQUEST MUST reply.
I agree, I think that this should be upgraded to MUST that was missed after request/response IDs were added.
Agreed. I'd be supportive of a MUST along the lines of: Though we need to wordsmith it better
Not sure if a MUST really helps here. I guess there is no way to force an endpoint to reply and we also can't specify until when the reply needs to come, so you always need to implement a logic to detect that you didn't get reply. To be honest that also a point where I'm not fully happy with . So far my assumption was rather that you can of course nicely ask for an address. But as soon as you get an address_assign you should assume that the list is complete and work with rather that than speculatively waiting for a potentially update that may or may not come. Sending a reject as specified in makes the situation less ambiguous but in the end it shouldn't really change much because it always better to start sending quickly with an address that you got assigned than to wait and hope for another address.
Why not? Peer could reset the stream, or time out the entire connection. That is what the point of a MUST is.
If you get a bunch of addresses assigned that you don't want to use and they're decide to not use the connect, I guess you should close it. however, if you use it, there is no point in closing it just because you didn't get a reply to your request. And again we don't send when a reply should or must be send. So there is no final deadline when you could close a stream.
The whole reason we added request IDs was to remove the requirement to timeout. This does not work if we allow the peers to simply not respond. The contract here needs to be that reach request gets a response, like HTTP. If a peer breaks that, you close the stream -- like HTTP.
I don't think it's the same. If you send two requests which each one IP address and you only get one reply, you can use the IP you got and everything is fine. In http if you don't get a reply, you connection simply broken. Yes, it would make things easier if you can guarantee that you always get a reply but I don't think there is a good way to enforce that; or even trying to enforce it, creates more limitation than it might help.
I think its easier to built a client if it knows whether to expect responses in the protocol or not. This will govern how it approaches cases where it does or does not get a timely response, for some measure of timely. These might be (and probably are) implementations choices that should be pointed out. There's lots of reasons a client might detect something was slow, when in fact it was serviced as fast as possible. Imagine I run a proxy that might, for reasons that are outside of its control, have delays servicing one address request out of a few. If clients are going to be "smart" and make opaque decisions, then it could adversely affect my operations.
I've been noodling a bunch of scenarios where I think the draft could use a bit more clarification, and maybe a rev of the wire format around Request IDs for / . They largely fall under the question of how does an endpoint NAK an address request? The draft says an endpoint receiving an capsule SHOULD respond with an capsule, so I suppose not responding is allowed, but figuring out how to respond with a NAK is worthwhile. For this, I'm going to use the term client to refer to the party requesting addresses/prefixes, and server to refer to the party assigning addresses/prefixes. 1) The client has received an (unsolicited?) address. The client then requests a different address. The server has chosen to not assign that address. A suggestion I've heard: server sends capsule with existing assignment and new request's Request ID. 2) The client sends a capsule requesting multiple addresses The server has chosen to only assign a subset of those addresses (or a different address). Using the suggestion from (1) involves replying with sufficiently many capsules so as to exhaust the Request IDs sent. Maybe this means sending back n capsules all with the same one assignment, or n/2 capsules with the same two assignments, etc? 3) The client sends a capsule requesting an IP version not supported by the server. This could be a request for addresses for IPv4 and IPv6 from a server that supports only one, or a simpler case of asking for an IPv4 address from an IPv6-only server. It feels odd to use the suggestion from (1) to respond to a request for an IPv4 address with an IPv6 address or vice versa. An alternative, which requires a wire format revision, is to include a list of NAK'd Request IDs in the capsule, which could be as simple as a varint count of IDs, followed by that many more varints. In the happy path, this is just one extra byte in the capsule.
Thanks for filing this NAME I agree that the draft isn't currently clear enough on how to respond to these scenarios. The three options I see are: do nothing write some text to explain how to use the existing capsule formats to indicate a rejected address request add a list of rejected request IDs to the ADDRESS_ASSIGN capsule Of these I think we really should avoid (1) because that could lead to interoperability issues, but I'm ok with either (2) or (3). I think I prefer (3) because changing the wire format now isn't too high of a cost and I think it'll make the protocol more explicit.
I agree we should do something here. Between (2) and (3), I'm not sure. We could fairly easily just say that if you include an with a non-zero Request ID but the assigned address is all zeros with a prefix length of 32 or 128, you're assigning an empty address, which is a rejection. Arguably, client must handle receiving such a capsule response anyway, and treat it as "no address assigned for that request". This is option (2), I think. If we do something like option (3), we'd have a field in the main ADDRESSASSIGN capsule for a list of rejected IDs, which would likely need to have a length in front, so we'd now have a field of at least a byte in all ADDRESSASSIGN capsules (even ones with no rejections) to handle the possibility of rejections. We either have a case where a lot of rejections leads to a somewhat bloated capsule, but the happy cases are nice and concise, or a case that optimizes for lots of rejections and always adds a byte to the happy cases. I personally prefer (2) there, since it only gets ugly if a ton of requests are being made anyhow. Thoughts NAME ?
I like your proposal NAME if we add text saying that 0.0.0.0/32 and ::/128 mean "your request was rejected" then we get the explicit property without changing the wire format. That works for me.
It's also good because it doesn't have two ways of saying the same thing, since we'll need to handle 0.0.0.0/32 and ::/128 anyhow. I can try to write that up.
I appreciate the added symmetry that comes from giving the zero addresses specific meaning in both requests and assignments, and no wire format changes + no ambiguity is a win. LGTM.
Thanks!

length it is requesting. Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign  <ins> one or more IP addresses to its peer, and then respond with an ADDRESS_ASSIGN capsule to inform the peer of the assignment.  For each Requested Address, the receiver of the ADDRESS_REQUEST capsule SHOULD respond with a Assigned Address with a matching Request ID. If the requested address was assigned, the IP Address and IP Prefix Length fields in the Assigned Address response SHALL be set to the assigned values.  If the requested address was not assigned, the IP Address SHALL be all-zero and the IP Prefix Length SHALL be the maximum length (0.0.0.0/32 or ::/128) to indicate that no address was assigned.  Note that other Assigned Address entries that do not correspond to any Request ID can also be contained in the same ADDRESS_ASSIGN response. </ins> If an endpoint receives an ADDRESS_REQUEST capsule that contains zero Requested Addresses, it MUST abort the IP proxying request stream.