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

[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.

I think that mayybe the fault lies here:

> 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...
1) but that would require the local translator to know it's IPv4,
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.
   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.

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

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.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [