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

Sat Apr 11 05:36:38 CDT 2015

* Michael Richardson

> Tore Anderson <tore at fud.no> wrote:
>     > The problem occurs when two IPv6 nodes handled by the same SIIT
>     > instance tries to communicate through it. The IPv6 nodes can
>     > very well be located in different data centres, this doesn't
>     > really matter, what matters is that the source address will be
>     > rewritten according to the EAM rather than RFC6052 mapping,
>     > which makes the response packet go directly rather than through
>     > SIIT. That in turn means that the response will appear to come
>     > from a different address than the initial packet was adressed
>     > to, so it is discarded.
> 
> I think I need to read your email with the example (which I think was
> in the tickets) again.  I'm sorry that I haven't located it again.

Hi Michael,

It was sent to the list, but considering the list was a bit buggy in
its first few days, maybe it got lost somehow. No worries, I'll just
quote it below, near the end of this message.

> I think that if we are having this problem is because we are skipping
> some step that would have occured when there were two DCs served by
> two different SIITs.

Well, even if you have two DCs with two separate SIIT installations,
you'd still run into the problem if two applications/nodes (of which at
least one is IPv4-only) *in the same DC* wants to communicate with each
other.

> Let me start again with the diagram at:
>     http://jool.mx/intro-nat64.html
> 
> I think that the problem occurs when A wants to talk to B, but the
> address that A has for B is 198.51.100.9 (because the application on
> A that wants to talk to B is not v6 able, or the signaling system
> didn't know that IPv6 was involved), rather than 2001:db8:4::9.
> 
> Am I correct?

Yes. Assume that on node A, there's an IPv4-only application served by
a host-based Edge Translator with an EAM 198.51.100.8,2001:db8:6::8. So
the IPv4-only application binds to a local (virtual) interface with the
address 198.51.100.8 assigned and a default IPv4 route; it has no
knowledge of IPv6 at all. Furthermore assume that the well-known RFC6052
prefix of 64:ff9b::/96 is used.

Now if the IPv4-only application on A wants to communicate with B, it
will send an IPv4 packet with src=198.51.100.8 dst=198.51.100.9 into
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
through the IPv6 network to T. So far so good.

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

This packet makes it to B just fine, which will respond to it with a
packet with reversed src/dst fields (i.e., src=2001:db8:6::9,
dst=2001:db8:6::8). Since the destination field does not fall within
64:ff9b::/96, the packet will not be routed to T, but directly to A.

However the edge translator on A will not be able to translate this
source address 2001:db8:6::9 to IPv4, because it has no EAM for it, and
it doesn't fall within 64:ff9b::/96. Therefore, bi-directional
communication will not work.

If T had *not* translated the IPv4 source address according to A's EAM
in the second translation step, but instead used RFC6052 mapping (i.e.
causing the IPv6 packet received by B to have
src=64:ff9b::198.51.100.8), then the return traffic from B to A would
also be hairpinned through T, and the addresses seen both by A and B in
both directions would be what they'd expect, and communication would
actually work just fine.

Original message that started this thread quoted below:
-------------------------------------------------------
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