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

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