RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

[<john.loughney@nokia.com>]

Iljitsch,

> Unless we take the rather radical approach of making the shim a TCP  
> option (hard to do with such limited option space available) the shim  
> negotiation and initial reachability verification packets need to get  
> through in the first place or the path won't be used, because as far  
> as the shim cal tell, it doesn't work.
> 
> It is of course possible that an enterprising firewall admin cooks up  
> a config that lets through shim and http packets, but not other  
> important protocols.
> 
> I guess the thing to do here is note the negative advice / lack of  
> positive advice from the affected upper layer/sessions and keep  
> looking for an alternative path.
> 
> > If you believe some firewalls today are causing non-transparency  
> > problems, the workaround seems to be to encapsulate in some general  
> > connectivity protocol (http, ipsec/esp, ssh, ...) end to end.
> 
> I disagree. If a firewall gets in the way, this can either be because  
> there is a valid reason, and then sneaking by is bad, or there is no  
> valid reason, so the firewall should be fixed. Adding additional  
> complexity and overhead to award people for laziness is very bad.

Detecting that there was a 'failure' due to a firewall is also quite 
difficult to determine anyhow.  The only way would be to compare
multiple address pairs and determine in one case it works but 
in another it doesn't work; and be sure that it wasn't just a transiant
failure.

John