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

[Alberto Leiva]

Well,

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?

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

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.

Alberto
PS. Do you have a sandbox implementation of the new column? I could
spend some time from my weekend.


On Mon, Apr 13, 2015 at 3:18 PM, Tore Anderson <tore at fud.no> wrote:
> * Michael Richardson
>
>> Tore Anderson <tore at fud.no> wrote:
>>     > Disregarding any specific hairpinning optimisations, T will
>>     > translate this packet twice in rapid succession. Keep in mind
>>     > that T has EAMs for both A (198.51.100.8,2001:db8:6::8) and B
>>     > (198.51.100.9,2001:db8:6::9):
>>
>>     > After 1st translation by T: src=198.51.100.8 dst=198.51.100.9
>>
>>     > 198.51.100.9 is then routed by the IPv4 network straight back
>>     > to T:
>>
>>     > After 2nd translation by T: src=2001:db8:6::8 dst=2001:db8:6::9
>>
>> SO, if the EAM for 100.8 was not there, then the outgoing connection
>> from A to B would have been subject to either a stateful NAT64
>> somewhere, or a stateless translation to 64:ff9b. and all would be
>> well as you say.
>
> If the 198.51.100.8,2001:db8:6::8 EAM didn't exist on T, the 1st
> translation by T would fail, because it would have no way of
> translating A's source address 2001:db8:6::8 to IPv4.
>
> I don't see how it would be end up handled by a Stateful NAT64 either.
> The destination address (64:ff9b::198.51.100.9) would be routed to the
> stateless translator T, regardless of T having the
> 198.51.100.8,2001:db8:6::8 EAM configured or not.
>
>> > the virtual interface, which gets translated by the local
>> > translator to src=2001:db8:6::8 dst=64:ff9b::198.51.100.9, which
>> > gets forwarded
>>
>> If the local translator would translate to
>>    src=64:ff9b:198.51.100.8 dst=64:ff9b::198.51.100.9
>>
>> then it would work better...
>
> No, we'd end up in the same place:
>
> Initial pkt received by T:  src=64:ff9b:198.51.100.8 dst=64:ff9b::198.51.100.9
> After 1st translation by T: src=198.51.100.8 dst=198.51.100.9
> After 2nd translation by T: src=2001:db8:6::8 dst=2001:db8:6::9
>
>> 1) but that would require the local translator to know it's IPv4,
>
> I'm not quite sure what you mean by this.
>
>> 2) if 198.51.100.9 is not an IPv4 behind a SIIT, then it might invoke
>> NAT64, if it goes through a device that does not have the 100.8 EAM.
>
> As above, I do not quite understand how and where NAT64 comes into the
> picture.
>
>>    If it goes through the SIIT, it can be statelessly translated to
>> IPv4.
>>
>> If somehow the local translator could translate the dst to
>> 2001:db8:6::9 itself, then it could go directly, no hairpining
>> required.
>
> True. However that's not really a scalable solution, because you would
> then need to ensure that every edge translator is provisioned with a
> full EAM table. In other words, A would need the EAMs for A,B,C,D,E; B
> would need the EAMs for A,B,C,D,E; and so on for C,D,E. If you add an
> F, you need to revisit the configuration on A,B,C,D,E and add the F EAM
> on each of them.
>
> Once you do that, however, traffic between any of the IPv4 applications
> running on those hosts will no longer need to be routed and hairpinned
> through T.
>
>> So is there someway to we can make the SIIT skip the EAM table in this
>> situation?
>
> Well, that is exactly what I am proposing. Basically a metod where you
> for this use case can configure T to skip the EAM algorithm whenever
> it's considering translating an IPv4 source address to IPv6.
>
>> What if we changed the ordering of the two lookups, then we would
>> know that it's being hairpinned before we lost the original source
>> IPv6.
>
> You mean to always to do RFC6052 before the EAM lookup? That would
> break inbound packets from the internet, since dst=198.51.100.8 would
> get translated to dst=64:ff8b::198.51.100.8 (and then loop straight
> back into T) rather than to dst=2001:db8:6::8.
>
> Tore
> _______________________________________________
> Jool-list mailing list
> Jool-list at nic.mx
> https://mail-lists.nic.mx/listas/listinfo/jool-list