Original text:
it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing table to pick an outbound interface, and then send the IP packet on that interface <del> or pass it to a local application. </del>  In the other direction, when an endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for an IP loops, and matches the choices in IPsec IPSEC. Implementers need to ensure that they do not forward any link-local <del> 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. </del>  IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since IP proxying in HTTP conveys IP packets in HTTP Datagrams

Reviewer comments:
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

Revised text:
it will parse the packet's IP header, perform any local policy checks (e.g., source address validation), check their routing table to pick an outbound interface, and then send the IP packet on that interface  <ins> or pass it to a local application.  The endpoint can also choose to drop any received packets instead of forwarding them.  If a received IP packet fails any correctness or policy checks, that is a forwarding error, not a protocol violation as far as IP proxying is concerned; see error-signal. </ins> In the other direction, when an endpoint receives an IP packet, it checks to see if the packet matches the routes mapped for an IP loops, and matches the choices in IPsec IPSEC. Implementers need to ensure that they do not forward any link-local  <ins> traffic beyond the IP proxying interface that it was received on.  IP proxying endpoints also need to properly reply to packets destined to link-local multicast addresses. </ins> IPv6 requires that every link have an MTU of at least 1280 bytes IPv6.  Since IP proxying in HTTP conveys IP packets in HTTP Datagrams