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

[Tore Anderson]

* Alberto Leiva <ydahhrk at gmail.com>

> It was a lazy weekend. I managed to implement the fields, but only as
> a global setting. I also postponed the heuristic approach.
> 
> https://github.com/NICMx/NAT64/tree/eam-disable-fields
> 
> I tested the fields are disabled correctly, but did not actually
> attempt hairpinning.

It works very well! :-)

I'm using --eam-enabled-fields 222 (0b11011110) in order to disable
IPv4.SRC and ICMPv4.DST.

There is very minor issue I noticed though. If --pool6791 is empty or
contains a locally-assigned address, then ICMPv6 errors won't be
hairpinned correctly.

What happens is that an ICMPv6 error comes in, like so:

[ 6772.180757] Catching IPv6 packet: 2001:420:1100:5::1->2a02:c0::46:42:b92f:2a02
[ 6772.180762] Translating the Packet.
[ 6772.180778] Address 2001:420:1100:5::1 lacks the NAT64 prefix and an EAMT entry.
[ 6772.180785] Result: 185.47.41.3->185.47.42.2
[ 6772.180788] Translating the inner packet (6->4)...
[ 6772.180794] Result: 185.47.42.2->185.47.42.10
[ 6772.180798] Sending skb via device 'eth0'
[ 6772.180824] Success.

Fine so far. This new packet gets sent to the IPv4 default gateway (due
to the lack of "native hairpinning" in Jool), where it makes a U-turn
and comes right back to the Jool node:

[ 6772.180935] Catching IPv4 packet: 185.47.41.3->185.47.42.2
[ 6772.180938] Translating the Packet.
[ 6772.180944] Address 185.47.41.3 lacks an EAMT entry and is blacklisted.
[ 6772.180946] Returning the packet to the kernel.

Since 185.47.41.3 is the local address of the Jool node (and thus the
default contents of --pool6791), this packet is dropped.

If I set --pool6791 to contain some arbitrary address that's not
present on any local interface, it works just fine.

Maybe the "is it blacklisted?" check could only consider *destination*
addresses, or is there some purpose in making it look at source
addresses as well?

> (Would you rather I made eight separate flags, one for each field? It
> sounds messier... especially while uploading EAMT entries :p)

A bit field is fine for me. I'm honestly more interested in the
functionality than the exact way it is configured. :-)

> Something's bugging me (even though it's all theoretical because,
> again, I haven't tested hairpinning):
> 
> I think you should really justify the distinction between outer (IP)
> addresses and inner (ICMP) addresses. From my point of view, outer.src
> is spiritually equivalent to inner.dst and outer.dst is spiritually
> equivalent to inner.src in all circumstances. I feel nobody will ever
> want to allow a SIIT to translate outer.dst but not inner.src, for
> example.

You are probably right.

> The distinction is actually going to be hazardous when an operator
> disables outer.src, forgets to disable inner.dst, and see hairpinning
> seemingly work. I feel people expects ICMP errors to "just work" (and
> some people doesn't even care about them enough).
> 
> I feel there should be only four fields: IPv4.SRC, IPv4.DST, IPv6.SRC
> and IPv6.DST. The ICMP fields should be inferred from them and not be
> otherwise configurable.

Mhm. I think I should focus on the IPv4.SRC/ICMPv6.DST since none of us
have come up with a use case for any of the others...

I'll try to post some suggested text later this week.

Tore