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

[Alberto Leiva]

It seems the outer source IPv6 address switch (and I guess the inner
destination IPv6 address switch - it's a little fuzzy still) are the
only useful ones so far.
I take it the reason you want to make this possible for other fields
as well is in hopes they will someday find a use case?

Also,
Is all of this really necessary?
At first sight it doesn't sound too hard for the SIIT to tell whether
there's going to be hairpinning involved. Stateful NAT64 does
something similar;
"If the resulting destination address I translated using the RFC 6052
algorithm is in the EAM table... then there is hairpinning... and
therefore maybe I should just U-turn it right away instead of sending
it to my IPv4 gateway"?

It does sound like overhead given the extra lookup... but to me it
seems so transparent it's worth it...

I might be spewing nonsense. It will review this again tomorrow.

On Wed, Mar 25, 2015 at 2:10 AM, Tore Anderson <tore at fud.no> wrote:
> Hi,
>
> I've thought a bit about how to handle hairpinning through a SIIT/EAM
> gateway. Consider for example:
>
> Node A: 2001:db8:1::1
> Node B: 2001:db8:2::2
>
> EAM A in SIIT gateway: 2001:db8:1::1, 192.0.2.1
> EAM B in SIIT gateway: 2001:db8:2::2, 192.0.2.2
>
> Now, assume A wants to communicate with B. Assume also that A (and
> possibly B) is really an IPv4-only application running behind an
> SIIT-DC Edge Translator, making native IPv6-to-IPv6 communication
> impossible.
>
> The packet flow will look like this:
>
> 1. Initial TCP SYN from node A:
> SRC: 2001:db8:1::1
> DST: 64:ff9b::192.0.2.2
>
> 2. After initial translation by SIIT translator:
> SRC: 192.0.2.1
> DST: 192.0.2.2
>
> 3. Above packet will loop straight back into the SIIT translator, and
>    after the second translation pass:
> SRC: 2001:db8:1::1
> DST: 2001:db8:2::2
>
> 4. TCP SYN/ACK response from node B:
> SRC: 2001:db8:2::2
> DST: 2001:db8:1::1
>
> This SRC address is not what node A is expecting, so the three-way
> handshake will fail. One possible way to deal with this is to configure
> node A's Edge Translator with node with EAM B. That way, the
> communication will go direct between the two nodes, and the gateway
> won't be involved. However this might cause a provisioning problem, if
> there are a large amount of EAMs configured on the gateway, and the
> IPv4-only application might need to communicate with all of them.
>
> I believe it is possible to make hairpinning through the gateway work
> by avoiding to apply the EAM algorithm to certain address fields. In
> the above case, if you disable it for the IPv4 SRC field, the outcome
> should be the following:
>
> 1. Initial TCP SYN from node A:
> SRC: 2001:db8:1::1
> DST: 64:ff9b::192.0.2.2
>
> 2. After initial translation by SIIT translator:
> SRC: 192.0.2.1
> DST: 192.0.2.2
>
> 3. The above packet will loop straight back into the SIIT translator,
>    and after the second translation pass look like this:
> SRC: 64:ff9b::192.0.2.1 <-- EAM algorithm disabled; RFC6052 used
> DST: 2001:db8:2::2
>
> 4. TCP SYN/ACK response from node B:
> SRC: 2001:db8:2::2
> DST: 64:ff9b::192.0.2.1
>
> 5. After initial translation:
> SRC: 192.0.2.2
> DST: 192.0.2.1
>
> 6. After second translation:
> SRC: 64:ff9b::192.0.2.2 <-- EAM algorithm disabled; RFC6052 used
> DST: 2001:db8:1::1
>
> So what I'm proposing is to add to the siit-eam draft text that states
> something like this:
>
> An implementation SHOULD provide a mechanism to disable the EAM
> algorithm for any of the eight possible address fields
> ({IP,ICMP}v{4,6}.{SRC,DST}). By default, the EAM algorithm should be
> enabled for all address fields.
>
> This mechanism MAY be a global setting, or it MAY be set per-EAM, or
> both. A per-EAM setting would precedence over the global setting.
>
> Finally, an EAM would not be considered to overlap with another if it
> they are translating a different set of address fields. In other words,
> these EAMs would not be considered to overlap (they probably make no
> sense from an operational standpoint)
>
> IPv6          IPv4        Enabled address fields
> ------------------------------------------------
> 2001:db8::1   192.0.2.1   IPv6.SRC,IPv6.DST
> 2001:db8::1   192.0.2.2   IPv4.SRC,IPv4.DST
> 2001:db8::1   192.0.2.2   ICMPv6.SRC,ICMPv6.DST
>
> BTW: The reason for allowing a global setting is that I expect that a
> device in a certain role will want to apply the algorithm to the same
> address fields for every entry in the EAM Table. For example, a SIIT-DC
> Gateway would likely disable it for the IPv4.SRC field to facilitate
> hairpinning, and doing so does not harm regular traffic from IPv4
> clients on the internet which wouldn't match any EAM anyway. So having
> it as a global setting will reduce the size of the EAMT, as well as
> optimising away one useless EAMT lookup for each packet being
> translated from IPv4 to IPv6.
>
> What do you think?
>
> Tore
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list