Change:
receiver of the capsule MUST follow the error handling procedure defined in HTTP-DGRAM. <del> Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in these ranges to its peer. </del> <ins> Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY update its local state regarding what its peer is willing to route (subject to local policy), such as by installing entries in a routing table. </ins> Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction,

Discussion:
From NAME
Link-local addresses are valid, why would they not be? This was the consensus of the editors and then of the WG. I agree with you about incentives, but this was deemed better than any alternative proposed at the time.
On the second point, OK, I figured as much. The first point is triggered by (S6): "Implementers need to ensure that they do not forward any link-local traffic onto a different interface than the one it was received on. IP proxies also need to properly reply to packets destined to link-local multicast addresses." I'm having a little trouble reasoning about this, but is it allowed for a proxy to send ADDRESS_ASSIGN containing a link-local address? Only if the MASQUE connection is on the same physical interface as the address? Or is a MASQUE connection a virtual interface? Similarly, are there conditions where a client could send an IP packet addressed to a link-local address? If so, would this be forwarded out the "internet end" of the proxy? I'm not convinced there's a problem here, but I'm confused.
Yes, why would it not be? No no no - these addresses are inside the tunnel. A MASQUE connection is a virtual interface, just like IPsec, WireGuard, OpenVPN, etc. "Virtual interface" is not a well-defined concept as far as RFCs go, but yeah it's an interface that isn't a physical cable or radio. Yes. So the use for this is the traditional scenario where both IP proxying endpoints have link-local addresses, then they can use them to communicate between one another. No, link-local traffic is by definition local to the link. Those packets cannot be forwarded onto another interface. They can only be destined to the peer.
After further high-bandwidth discussion, I believe the design covers all the bases. We agreed that the following two changes are best: (1) Both connect-IP endpoints need to reply to link-layer multicast, not just the proxy. (2) change the requirement about not forwarding link-local IPs over different interfaces (which opens up a useless what-is-an-interface discussion) with clearer language like "don't forward beyond that IP tunnel" or "beyond the HTTP stream", etc.
From NAME
This is IP networking, so there is no notion of "fear of being dropped".

Any IP link or router can drop any packet any time for any reason. I wrote PR to clarify this.
I get that there are no guarantees in IP networking. The PR is fine, but I'm not afraid that someone thinks this protocol is providing delivery guarantees. But there is a clear divide between using an IP address speculatively and sending one that the peer has given an indication will succeed. It's the meaning of the phrase "due to an improper address" in the initial issue. This is the point of having ADDRESSASSIGN and ROUTEADVERTISEMENT. Put another way, what does an implementation do when it receives ROUTE_ADVERTISEMENT? Are there any other equivalent events that trigger the same behavior (e.g. A 200 on a CONNECT-IP request to a literal IP?)
No, that's not how IP networks work. Let's take the example of DHCP: a client attaches to a new network and asks for an address. The DHCP server assigns an IP to the client. The client often sends from that address, but that assignment does not represent any assurances with regards to delivery, it represents unicity. On my home network I have DHCP but also machines with static addresses - when I get address X via DHCP, I have absolutely no assurance that sending with that source address is more likely to succeed than with this static address. Whether packets gets through is a matter of either (a) policy or (b) addressing architecture - both of which were decided out of scope during the WG consensus process for draft-ietf-masque-ip-proxy-reqs, see . All this to say, I understand what you're asking for - but it's squarely out of scope
"I have absolutely no assurance that sending with that source address is more likely to succeed than with this static address." "assurance" and "more likely" are weird things to have in the same sentence -- anything dealing with likelihood is by definition not assured. Your flattening of the distinction between addresses the sender picks out of the air and those in ADDRESSASSIGNED and ROUTEADVERTISEMENT makes me wonder what the point of those capsules are. ADDRESSASSIGNED at least means "I will try to deliver packets to you if they have this destination IP", but what does ROUTEADVERTISEMENT mean if not "you have a somewhat better chance of delivering these than a randomly picked destination IP?"

And whatever ROUTE_ADVERTISEMENT means, is a 200 on CONNECT to a literal IP equivalent, or do they carry different semantics?
These capsules exchange configuration data. The recipient is free to choose to apply said configuration, or ignore it. To answer your specific question: yes - if you are a split-tunnel VPN client, you'll install any routes from ROUTEADVERTISEMENT into your routing table. But in a separate scenario if you're just trying to get a point-to-point link, you're going to ignore a ROUTEADVERTISEMENT telling you the whole world is routable. Taking a few steps back: what change would you like to see in the draft that is not covered by ?
OK, after a higher-bandwidth discussion, where I went wrong is with this sentence in S4.7.3: "Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start routing IP packets in these ranges to its peer." This implies that an endpoint should not send before this, which is not the intent. NAME and I agreed that this sentence should be deleted or changed. I recommended some sort of alternative sentence(s) in this section that clearly stated the purpose of this capsule, perhaps something that ends with "for the use cases where clients require it"
NAME I wrote up a fix for that last point as . That's what we initially intended and avoid the unintended implication