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: I'll reiterate my suggestion from the meeting: it would be better to have IP-version-specific capsule types for each capsule. It saves a byte and also avoids problems with version mismatches.Thanks! I left 2 minor editorial questions, but feel free to merge as-is.