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

[Alberto Leiva]

> You do incur an extra EAMT lookup on each 6->4 translation though, but maybe that isn't a too big price to pay?

Do you think the EAMT is going to grow that much?
A lookup in a small table is just a lookup in a small table.
And I don't think people is planning to implement it as a linear search either.

> At least if the hairpinning heuristic can be configured on or off, in case that it actually does break something

OK, good idea.

> The heuristic might need to handle ICMP addresses differentl

OK so,

1. A writes packet e1::8 to p.9 (where e1 is "2001:db8:6" and p is
"64:ff9b::198.51.100")
2. T translates that into packet p.8 to e2::9 (Where e1 can be the same as e2)
3. R (router) has a problem and responds ICMP error <whatever address>
to p.8. This packet has an inner packet that goes from p.8 to e2::9.
(R can be anything between T and B, including B.)

T has to translate again, this time from IPv6 to IPv4.

- If R is B, <whatever address> will be translated using e2's EAM entry.
- If R is not B, <whatever address> will be translated as anything
from the RFC 6791 pool.
- Outer p.8 will be translated to IPv4 using the 6052 prefix.
- Inner p.8 will also be translated using the 6052 prefix.
- e2::9 will be translated using e2's EAM entry.

Assuming e1 = e2 and R = B, this will yield these addresses:

- Outer src: 198.51.100.9
- Outer dst: 198.51.100.8
- Inner src: 198.51.100.8
- Inner dst: 198.51.100.9

source address was translated using EAM? yes (more or less :/)
(I guess this condition should be something more in the lines of
"source address was NOT translated using the 6052 prefix?")
the destination address was translated using the 6052 prefix? yes
the resulting destination address is also part of the EAM? yes

OK, hairpin.

- Translate outer src address using the 6052 prefix (64:ff9b::198.51.100.9)
- Translate outer dst address normally (2001:db8:6::8)
- The inner src address needs to be e1::8, therefore translate
normally (2001:db8:6::8)
- The inner dst address needs to be p.9, therefore disable EAM
(64:ff9b::198.51.100.9)

Proposed hack so far:

    in the 6 -> 4 direction,
    if the source address was not translated using the 6052 prefix,
        the destination address was translated using the 6052 prefix,
        AND the resulting destination address 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
            -> The src address
            -> Inner dst address (if it exists)

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

OK, I'll try to have this ready on Monday. Don't trust my forecasts, though ;p

Alberto

On Tue, Apr 14, 2015 at 1:25 AM, Tore Anderson <tore at fud.no> wrote:
> 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