Code change:
4.2.1. The ADDRESS_ASSIGN capsule (see iana-types for the value of the <del> 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 </del> <ins> capsule type) allows an endpoint to inform its peer of the list of IP addresses or prefixes it has assigned to it.  Every capsule contains the full list of IP prefixes currently assigned to the receiver.  Any </ins> of these addresses can be used as the source address on IP packets originated by the receiver of this capsule. <del> If an endpoint receives multiple ADDRESS_ASSIGN capsules, all of the assigned addresses or prefixes can be used.  For example, multiple ADDRESS_ASSIGN capsules are necessary to assign both IPv4 and IPv6 addresses. </del> <ins> The ADDRESS_ASSIGN capsule contains a sequence of zero or more Assigned Addresses. 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. </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 <del> to use.  In these deployments, endpoints need to send ADDRESS_ASSIGN capsules to allow their peers to send traffic. </del> <ins> to use.  In these deployments, the endpoint that is expecting an address assignment MUST send an ADDRESS_REQUEST capsule.  This isn't required if the endpoint does not need any address assignment, for example when it is configured out-of-band with static addresses. While ADDRESS_ASSIGN capsules are commonly sent in response to ADDRESS_REQUEST capsules, endpoints MAY send ADDRESS_ASSIGN capsules unprompted. </ins> 4.2.2. The ADDRESS_REQUEST capsule (see iana-types for the value of the <del> 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 </del> <ins> capsule type) allows an endpoint to request assignment of IP addresses from its peer.  The capsule allows the endpoint to </ins> optionally indicate a preference for which address it would get assigned. <ins> The ADDRESS_REQUEST capsule contains a sequence of Requested Addresses. If the IP Address is all-zero (0.0.0.0 or ::), this indicates that the sender is requesting an address of that address family but does not have a preference for a specific address.  In that scenario, the prefix length still indicates the sender's preference for the prefix length it is requesting. </ins> Upon receiving the ADDRESS_REQUEST capsule, an endpoint SHOULD assign an IP address to its peer, and then respond with an ADDRESS_ASSIGN <del> capsule to inform the peer of the assignment. </del> <ins> 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. </ins> 4.2.3.

Related discussion:
text: You're right this could be a potential solution to . Let's discuss them together tomorrow
Regarding IPv6, I think a standard request that would make sense is asking for any /64. I guess that works fine with this idea too?
Oh that's interesting, if the IP Address is or , the prefix length is a hint for the requested length. I like that.
IETF 114: Add an editorial sentence to "remember, what you ask for may not be what you get, especially with regards to address families". A request should be paired with a response, multiple requests can just say "you have the same ones you had before". Clarify that it's cumulative. Also solves unassign/removal of addresses.
So there appear to exist some downside with the timing of the interactions when one want to use Address-Request capsule. So the basic problem is simply that the proxy will assign an address prior to the Address-Request capsule has been received, thus preventing the proxy from processing the request in the right context. So lets assume that the client has already created one connect-IP request with a limited scope and been assigned IP-A. Then it want to make an additional request for another limited scope proxying and would like to get the same address assigned. Due to the separation between the HTTP request for the Connect-IP and the capsule Address-Request a server can actually process the whole HTTP request prior to receiving the Address-Request. Resulting potentially in that another IP address assignment (IP-B) be provided to the client, despite it asking for IP-A to be assigned also to the request. So does the HTTP request needs an indicator parameter to tell the proxy to wait for one or more "request" capsules from the client before processing the request?
Out of curiosity, in what scenario would the client "like to get the same address assigned"? It makes sense for the proxy to decide to reuse addresses to save its address pool when the scoping allows it, but why would the client care?
I could imagine this happening if the client was trying to resume some previous session that it lost due to an outage? Seems to be niche, but it's certainly possible.
So the most obvious use case for this is to request iproto= CMP in combination with for example UDP.