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

[Tore Anderson]

Hi Alberto,

* Alberto Leiva <ydahhrk at gmail.com>

> I don't really have anything against implementing your solution. All
> that bothers me is that, while straightforward EAM will work out of
> the box, EAM+hairpinning will not.
> 
> That being the case, I'm wondering if supporting hairpinning via EAM
> is in fact worth the extra documentation it will require. Up till now,
> I haven't even needed to mention hairpinning in the site. It has
> worked all along, and some people don't even know it's a thing.
> 
> I guess you're tired of objecting to this approach, but I'll try to
> complicate the heuristic and see if it's worth your time:
> 
>     in the 6 -> 4 direction,
>     if the source address was translated using EAM,
>         the destination address was translated using the 6052 prefix,
>         AND the resulting destination address is also 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 the src address.
> 
> If I'm not missing something, this will happen (following the example
> you have been using):
> 
> Packet from A:
>     2001:db8:6::8    ->    64:ff9b::198.51.100.9
> 
> T's translated packet:
>     198.51.100.8     ->    198.51.100.9
> 
> source address was translated using EAM? yes
> the destination address was translated using the 6052 prefix? yes
> the resulting destination address is also part of the EAM? yes
>     -> Do not send packet yet; hairpin it.
> 
> T's new incoming packet (ie. same one):
>     198.51.100.8     ->    198.51.100.9
> 
> T's new translated packet (EAM disabled on src):
>     64:ff9b::198.51.100.8    ->    2001:db8::9
> 
> Is this not what we wanted?

Yes, on first glance I think this could work... You do incur an extra
EAMT lookup on each 6->4 translation though, but maybe that isn't a too
big price to pay?

> Me daydreaming:
> - It seems to me this does exactly what your solution does, except
> it's more "elitist"; your solution denies EAM translation for all
> certain addresses, this solution denies EAM translation only on the
> same certain address but in specific situations only. Because this
> heuristic is less aggressive, it seems to me if it breaks something,
> then yours breaks it as well.

Yep. At least if the hairpinning heuristic can be configured on or off,
in case that it actually does break something (which would probably a
different use case than SIIT-DC).

> - At the same time, I guess something that would require constant
> denial of EAMT translation for a certain field would work with your
> solution and not with this. But I can't think of any.

On the top of my head, me neither. I will think more about it and see
if I can come up with something.

> - Also yours allows different behaviours depending on EAM entry, but
> we agree this does not seem to be much better than
> all-entries-share-the-same-fields.

Yep. My SIIT-DC use case will have all entries share the same fields,
but I am hesistant to add siit-dc specific text to the siit-eam draft,
as it is supposed to be generic algorithm that should support other use
cases equally well. But I think that your solution qualifies as generic
enough.

> I do not have an enumeration of every possibility we have to cover,
> but this seems to handle your whole Internet EAM entry (0.0.0.0/0 <->
> 64:ff9b::/96) just fine. This is because A's IPv6 packet would not be
> translated in the first place, since its source address doesn't match
> the entry. If A sends 64:ff9b:: -> 64:ff9b::, then it would also
> behave like normal RFC 6052 translation.

Yep...

The heuristic might need to handle ICMP addresses differentl
> PS. Do you have a sandbox implementation of the new column? I could
> spend some time from my weekend.

No, this is all in my head so far. :-D

I need to spend some time thinking if addresses in ICMP errors need
special handling or not...

If you are able to cook up a quick patch, I'll be (as always) happy to
test it.

Tore