Draft: draft-ietf-masque-connect-ip

Commentary: From 
 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 is n'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 can not 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 " do n't forward beyond that IP tunnel " or " beyond the HTTP stream " , etc . 
 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):
Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start
routing IP packets in these ranges to its peer.
Paragraph (version B):
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.