Draft: draft-ietf-masque-connect-ip

Commentary: If one is using IPPROTO to select a particular protocol to be tunneled , one may still received ICMP in the context of this request . To my understanding there are two reasons for this . a ) ICMP generated by the Connect - IP peer endpoint b ) ICMP sent back by  beyond the Connect - IP that is directly related to forward traffic sent by this endpoint and which the tunnel endpoint maps back to the Connect - IP request . I think we could add a clarification of this in , or we could do it later . 
 Totally agree . I to address this as part of . 
 Based on the discussion in issue we recommend to use ICMP for error signal . ICMP works for MTU issue or destination unreachable , however , there is no appropriate message type if the IP header of the packet provided by the client contains an IP that was n't assigned to the client . So we need a different kind of error handling for this case ? 
 I think  works for this , I 'd send See . Would that work ? 
 I guess that could do it . Should we be more specific in the draft ? Also , we probably would need to be more explicit in the draft that you should request a scope for your CONNECT request that allows you to received ICMP messages . 
 Can you write a PR for this please ? 
 IETF 114 : Recommend including ICMP if providing routes to the peer , and clients should always be prepared to receive ICMP . Also add note that ICMP may have other source / destination addresses so as to not surprise endpoints . 
 Also look at RFC 4301 for some potentially helpful text . 
 Where is the ICMPv4 detail ?
Paragraph (version A):
Since CONNECT-IP endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint doesn't
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP to signal the
forwarding error to its peer.
Paragraph (version B):
Since CONNECT-IP endpoints often forward IP packets onwards to other
network interfaces, they need to handle errors in the forwarding
process.  For example, forwarding can fail if the endpoint doesn't
have a route for the destination address, or if it is configured to
reject a destination prefix by policy, or if the MTU of the outgoing
link is lower than the size of the packet to be forwarded.  In such
scenarios, CONNECT-IP endpoints SHOULD use ICMP ICMP ICMPV6 to signal
the forwarding error to its peer.
Paragraph (version B):
For invalid source addresses, send Destination Unreachable ICMPV6
with code 5, "Source address failed ingress/egress policy".
Paragraph (version B):
For unroutable destination addresses, send Destination Unreachable
ICMPV6 with a code 0, "No route to destination", or code 1,
"Communication with destination administratively prohibited".
Paragraph (version B):
For packets that cannot fit within the MTU of the outgoing link,
send Packet Too Big ICMPV6.
Paragraph (version B):
In order to receive these errors, endpoints need to be prepared to
receive ICMP packets.  If an endpoint sends ROUTE_ADVERTISEMENT
capsules, its routes SHOULD include an allowance for receiving ICMP
messages.  If an endpoint does not send ROUTE_ADVERTISEMENT capsules,
such as a client opening an IP flow through a proxy, it SHOULD
process proxied ICMP packets from its peer in order to receive these
errors.  Note that ICMP messages can originate from a source address
different from that of the CONNECT-IP peer.