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

[Alberto Leiva]

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.

Also, configuring the fields is awkward. They are a single-byte
integer; each bit is a field:

1. IPv6.SRC
2. IPv6.DST
3. IPv4.SRC
4. IPv4.DST
5. ICMPv6.SRC
6. ICMPv6.DST
7. ICMPv4.SRC
8. ICMPv4.DST

I want to allow people to enter binary or hex numbers, but AFAIK this
is not possible yet.

    # Enable all IP fields, disable all ICMP fields (240 = 11110000)
    $ jool_siit --eam-enabled-fields 240

Sorry it's so stupid, but I wanted you to be able to try out your theory ASAP.

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

=============================================================================

Also

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.

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.

More progress later...
Alberto

On Fri, Apr 17, 2015 at 2:02 AM, Tore Anderson <tore at fud.no> wrote:
> * Alberto Leiva <ydahhrk at gmail.com>
>
>>     in the 6 -> 4 direction,
>>
>>     if packet is ICMP error
>>         tuple.src = outgoing (IPv4) packet's inner dst address
>>         tuple.dst = outgoing (IPv4) packet's inner src address
>>     else (ie. packet is TCP, UDP, ICMP info or unknown)
>>         tuple.src = outgoing (IPv4) packet's outer src address
>>         tuple.dst = outgoing (IPv4) packet's outer dst address
>>
>>     if tuple.src was not translated using the 6052 prefix,
>>         tuple.dst was translated using the 6052 prefix,
>>         AND tuple.dst is part of the EAM,
>>     then hairpin the packet manually.
>>         -> the outgoing IPv4 packet becomes the incoming packet.
>>         -> the packet is translated "recursively".
>>         -> In this 2nd translation, EAM is disabled for tuple.src.
>>
>> This is looking more and more like Stateful NAT64's solution.
>
> Hehe, indeed, it is getting a bit complicated, but I think it'll work.
>
> I think that in siit-eam I'll describe both the above heuristic, as
> well as the possiblity to let the let the operator configure the EAM
> algorithm as disabled for specific address fields. But I'll keep them
> as a MAY (so an compliant implemention would not have to implement
> both). Sounds OK?
>
>> The outer source address could be improved. Strictly speaking,
>> 2001:db8:6::9 = 64:ff9b::198.51.100.9, which is fine, but I don't know
>> if implementations can handle this when the error code is something
>> like port unreachable.
>> ("Why did somebody else answered port unreachable!?!?!?!?").
>> Guess it won't be a problem if we add "EAM is disabled for the outer
>> source address too" to the heuristic, not sure if it's worthwhile.
>
> I think it is worthwhile. It should be simple to handle: if hairpin is
> detected, disable the EAM algorithm for ipv4.src + icmpv4.dst (if
> applicable) for the second translation (instead of disabling it for
> tuple.src).
>
> Tore