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

[Tore Anderson]

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