Change:
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 <del> server through the proxy. </del> <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 <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> <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.

Discussion:
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