[Jool-list] RFC: Limiting EAM algorithm to specific header fields

[Tore Anderson]

* Michael Richardson

> Tore Anderson <tore at fud.no> wrote:
>     > Disregarding any specific hairpinning optimisations, T will
>     > translate this packet twice in rapid succession. Keep in mind
>     > that T has EAMs for both A (198.51.100.8,2001:db8:6::8) and B
>     > (198.51.100.9,2001:db8:6::9):
> 
>     > After 1st translation by T: src=198.51.100.8 dst=198.51.100.9
> 
>     > 198.51.100.9 is then routed by the IPv4 network straight back
>     > to T:
> 
>     > After 2nd translation by T: src=2001:db8:6::8 dst=2001:db8:6::9
> 
> SO, if the EAM for 100.8 was not there, then the outgoing connection
> from A to B would have been subject to either a stateful NAT64
> somewhere, or a stateless translation to 64:ff9b. and all would be
> well as you say.

If the 198.51.100.8,2001:db8:6::8 EAM didn't exist on T, the 1st
translation by T would fail, because it would have no way of
translating A's source address 2001:db8:6::8 to IPv4.

I don't see how it would be end up handled by a Stateful NAT64 either.
The destination address (64:ff9b::198.51.100.9) would be routed to the
stateless translator T, regardless of T having the
198.51.100.8,2001:db8:6::8 EAM configured or not.
 
> > the virtual interface, which gets translated by the local
> > translator to src=2001:db8:6::8 dst=64:ff9b::198.51.100.9, which
> > gets forwarded
> 
> If the local translator would translate to
>    src=64:ff9b:198.51.100.8 dst=64:ff9b::198.51.100.9
> 
> then it would work better...

No, we'd end up in the same place:

Initial pkt received by T:  src=64:ff9b:198.51.100.8 dst=64:ff9b::198.51.100.9
After 1st translation by T: src=198.51.100.8 dst=198.51.100.9
After 2nd translation by T: src=2001:db8:6::8 dst=2001:db8:6::9

> 1) but that would require the local translator to know it's IPv4,

I'm not quite sure what you mean by this.

> 2) if 198.51.100.9 is not an IPv4 behind a SIIT, then it might invoke
> NAT64, if it goes through a device that does not have the 100.8 EAM.

As above, I do not quite understand how and where NAT64 comes into the
picture.

>    If it goes through the SIIT, it can be statelessly translated to
> IPv4.
> 
> If somehow the local translator could translate the dst to
> 2001:db8:6::9 itself, then it could go directly, no hairpining
> required.

True. However that's not really a scalable solution, because you would
then need to ensure that every edge translator is provisioned with a
full EAM table. In other words, A would need the EAMs for A,B,C,D,E; B
would need the EAMs for A,B,C,D,E; and so on for C,D,E. If you add an
F, you need to revisit the configuration on A,B,C,D,E and add the F EAM
on each of them.

Once you do that, however, traffic between any of the IPv4 applications
running on those hosts will no longer need to be routed and hairpinned
through T.

> So is there someway to we can make the SIIT skip the EAM table in this
> situation?

Well, that is exactly what I am proposing. Basically a metod where you
for this use case can configure T to skip the EAM algorithm whenever
it's considering translating an IPv4 source address to IPv6.

> What if we changed the ordering of the two lookups, then we would
> know that it's being hairpinned before we lost the original source
> IPv6.

You mean to always to do RFC6052 before the EAM lookup? That would
break inbound packets from the internet, since dst=198.51.100.8 would
get translated to dst=64:ff8b::198.51.100.8 (and then loop straight
back into T) rather than to dst=2001:db8:6::8.

Tore