title: intercepting http proxy - disadvantages compared to a normal proxy
body: <p>I would like to know how "realistic" is to consider implementing an intercepting proxy(with cache support) for the <strong>purpose of web filtering</strong>. I would like to support also IPv6, authentication of clients and caching.</p>
  
  <p>Reading to the list of disadvantages from squid wiki <a href="http://wiki.squid-cache.org/SquidFaq/InterceptionProxy" rel="nofollow">http://wiki.squid-cache.org/SquidFaq/InterceptionProxy</a> that implements an intercepting proxy, it mentions some things to consider as disadvantages when using it(that I want to clarify):</p>
  
  <ol>
  <li>Requires IPv4 with NAT - proxy intercepting does not support IPv6, why ?</li>
  <li>it causes path-MTU (PMTUD) to possibly fail - why ?</li>
  <li>Proxy authentication does not work - client thinks it's talking directly to the originating server, in there a way to do authentication in this case ?</li>
  <li>Interception Caching only supports the HTTP protocol, not gopher, SSL, or FTP. You cannot setup a redirection-rule to the proxy server for other protocols other than HTTP since it will not know how to deal with it - This seems quite plausible as the way redirecting of traffic to proxy is done in this case is by a firewall changing the destination address of a packet from the originating server to the proxy's own address(Destination NAT). How would in this case, if i want to intercept other protocols besides http know where the connection was intended to go so I can relay it to that destination ?</li>
  </ol>