In your previous mail you wrote:
> But IP-layer interception has some fairly significant limitations
> for this application. ...
There's a technical problem with IP intercepting that I've not seen
mentioned, including in the draft. Any intercepting based on TCP or UDP
port numbers or that makes any assumptions about TCP or UDP port numbers
will have problems, because of IPv4 fragmentation. It seems plausible
that intercepting done by/for the server(s) would want to redirect all
traffic for a given IP address, and so not be affected by port numbers.
(Thus, it may make sense for the draft to not mention the issue.)
=> the first fragment has 8 bytes or more of payload, then the port numbers.
And other fragments share the same ID then it is possible to apply
the same action on all the fragments if they follow the same path at
the interception point.
This can be hairy if fragments are not in the usual order, for instance
if someone sends the last one first (this is not as stupid as it seems
because the last fragment provides the whole length of the packet).
However, "transparent" HTTP proxy and email filtering and rewriting schemes
such as AOL's that need to intercept only traffic to a particular port
cannot do the right thing if the client has a private FDDI or 802.5 network
(e.g. behind a NAT box) or has an ordinary 802.3 network but follows the
widespread, bogus advice to use a small PPP MTU.
=> but fragmentation is not the best way to fight against "transparent"
Yes, I realize IPv6 doesn't have fragmentation
=> IPv6 has fragmentation, but only from end to end (no fragmentation
en route). Packet IDs are used by IPv6 only with fragmentation (they
are in fragmentation headers) too...
but most if not all of the distant-from-server IP interception
schemes sound unlikely to work with IPv6 for other reasons.
=> I'd like that this is true (another reason to switch to IPv6 :-)
but the only thing which is broken by interception is authentication
(IPSec is mandatory to implement, not (yet) to use with IPv6).
Encryption isn't really "transparent" proxies friendly too (:-).