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

[Tore Anderson]

* Alberto Leiva <ydahhrk at gmail.com>

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

My expectation is that an operator who decides to do an IPv6-only
network and provide access to the IPv4 internet through SIIT will have
1 EAM per IPv4-"connected" node.

So if you take a public cloud operator like Amazon EC2 as an example,
each «Elastic IP» they have would be represented by an EAM. The same
thing would apply for OpenStack's «Floating IP» concept. So if we're
talking about really large operators, the EAMT could grow to millions
of entries.

That doesn't necessarily mean "too large", though. Those operators must
necessarily have identical-sized tables of Elastic/Floating IP
addresses already today, so if they can scale those they ought to be
able to scale an EAMT with a similar number of entries too. Another
thing worth noting is that the IPv4 routing table carried by most core
routers on the internet contains ~525k routes, and that seems to work
fine too, so...

Just thought it prudent to point out, that's all.

> 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?")

I think so. Otherwise it won't work if R = <some random address that
gets translated using RFC6791>.

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

ACK. I could think of one case where this breaks though, and that's if
R happens to be numbered using an IPv4-translatable address. This is a
legitimate use case, especially if you're mixing "vanilla" SIIT with
EAMs.

Consider a packet from A to B (via T), that gets dropped by R somewhere
in the path between T and B.

1. A's initial packet:
----------------------
Outer src:  2001:db8:6::8
Outer dst:  64:ff9b::198.51.100.9

2. After hairpin by T:
----------------------
Outer src:  64:ff9b::198.51.100.8
Outer dst:  2001:db8:6::9

3. ICMPv6 error returned by R after dropping #2:
------------------------------------------------
Outer src:  64:ff9b::10.10.10.10
Outer dst:  64:ff9b::198.51.100.8
Inner src:  64:ff9b::198.51.100.8
Inner dst:  2001:db8:6::9

4. After XLAT #1 by T (note: no hairpin logic applied):
-------------------------------------------------------
Outer src:  10.10.10.10
Outer dst:  198.51.100.8
Inner src:  198.51.100.8
Inner dst:  198.51.100.9

5. After U-turn in IPv4 network and XLAT #2 by T:
-------------------------------------------------
Outer src:  64:ff9b::10.10.10.10
Outer dst:  2001:db8:6::8
Inner src:  2001:db8:6::8
Inner dst:  2001:db8:6::9 <-- doesn't match the addresses in packet #1,
                              so A can't match it up to an existing flow

Unless we can think of a clever way to make the heuristic support this
use case too, I think ignoring it is acceptable. I don't think it is
likely to be very common.

That said, I think that my original idea would actually work with this
use case too (you'd unconditionally disable the EAM algorithm when
translating ipv4.src and icmpv4.dst into their IPv6 counterparts). Also
you'd avoid any overhead from looking up in the EAM twice (actually if
the toggle is global and not per-EAM, you'll recude the EAMT lookups
required by one for IPv4->IPv6 or by two for ICMPv4->ICMPv6), on the
other hand hairpinned packets will be handled less efficiently.

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

:-) No rush!

Tore