RE: ingress filteing problem

["Christian Huitema" <huitema@windows.microsoft.com>]

> By "NAT" I trust we mean reversible NAT... this WG is not about to
> suggest traditional NAT for IPv6, I don't think. Solutions that
rewrite
> the locator(s) and then set them back to their original value before
> final processing at the destination will not break IPSEC and will not
> require any transport checksums to be recalculated.

What you describe here is "rewrite at both ends", which supposes that
both ends are somehow upgraded. My contention is that the solution to
ingress filtering should be "single site", i.e., not force any special
processing on the other end, which may well be running a non-updated
IPv6 network. Single site solutions allow sites to multi-home at will;
multi-site solutions create a zero-day issue.

Think of the following case: vanilla IPv6 host A sends a TCP/SYN to
address B:X of host B, multi-homed to providers X and Y. Host B sends a
SYN-ACK back to A, from source B:X. The internal routing is such that
the packet is sent through exit Y, and fails ingress filtering at Y.

Clearly, in my example, if A retries a TCP connection using address B:Y,
the connection will eventually succeed. However, the trial and error has
a cost. And some dumb applications do not even retry all addresses. In
this example, B is "punished" because its site is multi-homed.
 
> Of course, how the source knows which rewrite will be accepted by
> the relevant ingress filters is a little piece of magic TBD.

With the same amount of magic, you probably can devise a single site
solution.

-- Christian Huitema