Draft: draft-ietf-masque-connect-ip

Commentary: From 
 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  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 . 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 " 
 I wrote up a fix for that last point as . That 's what we initially intended and avoid the unintended implication
Paragraph (version A):
When an endpoint receives an HTTP Datagram containing an IP packet,
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
or pass it to a local application.
Paragraph (version B):
When an endpoint receives an HTTP Datagram containing an IP packet,
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
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.
Paragraph (version A):
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.
Paragraph (version B):
Implementers need to ensure that they do not forward any link-local
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.