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

[Alberto Leiva]

> But I'll keep them as a MAY (so an compliant implemention would not have to implement both). Sounds OK?

> 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).

OK


On Sun, Apr 19, 2015 at 4:19 PM, Alberto Leiva <ydahhrk at gmail.com> wrote:
> 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