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

[Tore Anderson]

* Alberto Leiva <ydahhrk at gmail.com>

> It seems the outer source IPv6 address switch (and I guess the inner
> destination IPv6 address switch - it's a little fuzzy still) are the
> only useful ones so far.
> I take it the reason you want to make this possible for other fields
> as well is in hopes they will someday find a use case?

Yes, the siit-eam draft is meant to describe a generic algorithm that
can be then used to build stuff like, but not limited to, siit-dc.

> Also,
> Is all of this really necessary?
> At first sight it doesn't sound too hard for the SIIT to tell whether
> there's going to be hairpinning involved. Stateful NAT64 does
> something similar;
> "If the resulting destination address I translated using the RFC 6052
> algorithm is in the EAM table... then there is hairpinning... and
> therefore maybe I should just U-turn it right away instead of sending
> it to my IPv4 gateway"?
> 
> It does sound like overhead given the extra lookup... but to me it
> seems so transparent it's worth it...

While such an optimisation would probably be possible, that doesn't
really solve the problem - you need to _disable the EAM algorithm for
specific header fields_ for bi-directional communication through the
hairpin to work.

That said, also note that the destination address being found in the
EAM table doesn't necessarily mean that there is hairpinning. Consider
for example an EAMT such as this one:

0.0.0.0/0 <-> 64:ff9b::/96

Here, every possible IPv4 destination is in the EAM table, but it
doesn't mean that every possible IPv4 destination is hairpinned.

(Yes, this example would be functionally identical to RFC6052, but
that's still a valid EAM.)

Tore