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

[Alberto Leiva]

> Probably we'd have to argue for a few months if it's an OSPFv2 (IPv4) or OSPFv3 (IPv6) TLV.

Guess I'm going to have to hit the books since I'm a lammer when it
comes to routing ;p

> 4. After XLAT #1 by T (note: no hairpin logic applied):

This is the problem.
The heuristic is attempting to detect the hairpin using the wrong
addresses. In the case of ICMP errors, the inner addresses are the
ones that count (they're the ones used to detect the original hairpin,
after all).

    in the 6 -> 4 direction,

    if packet is ICMP error
        tuple.src = outgoing (IPv4) packet's inner dst address
        tuple.dst = outgoing (IPv4) packet's inner src address
    else (ie. packet is TCP, UDP, ICMP info or unknown)
        tuple.src = outgoing (IPv4) packet's outer src address
        tuple.dst = outgoing (IPv4) packet's outer dst address

    if tuple.src was not translated using the 6052 prefix,
        tuple.dst was translated using the 6052 prefix,
        AND tuple.dst 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 tuple.src.

This is looking more and more like Stateful NAT64's solution.

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. Temporary XLAT by T:
-----------------------
Outer src:  10.10.10.10
Outer dst:  198.51.100.8
Inner src:  198.51.100.8 (tuple.dst)
Inner dst:  198.51.100.9 (tuple.src)

5. After second hairpin:
------------------------
Outer src:  64:ff9b::10.10.10.10
Outer dst:  2001:db8:6::8
Inner src:  2001:db8:6::8
Inner dst:  64:ff9b::198.51.100.9

Is it like magic or is it like magic?

******************************************

This is what happens when R = B:

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

4. Temporary XLAT by T:
-----------------------
Outer src:  198.51.100.9
Outer dst:  198.51.100.8
Inner src:  198.51.100.8 (tuple.dst)
Inner dst:  198.51.100.9 (tuple.src)

5. After second hairpin:
------------------------
Outer src:  2001:db8:6::9
Outer dst:  2001:db8:6::8
Inner src:  2001:db8:6::8
Inner dst:  64:ff9b::198.51.100.9

The outer source address could be improved. Strictly speaking,
2001:db8:6::9 = 64:ff9b::198.51.100.9, which is fine, but I don't know
if implementations can handle this when the error code is something
like port unreachable.
("Why did somebody else answered port unreachable!?!?!?!?").
Guess it won't be a problem if we add "EAM is disabled for the outer
source address too" to the heuristic, not sure if it's worthwhile.

******************************************

This is what happens when R != B and untranslatable:

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

4. Temporary XLAT by T:
-----------------------
Outer src:  <pool6791 address>
Outer dst:  198.51.100.8
Inner src:  198.51.100.8 (tuple.dst)
Inner dst:  198.51.100.9 (tuple.src)

5. After second hairpin:
------------------------
Outer src:  64:ff9b::<pool6791 address>
Outer dst:  2001:db8:6::8
Inner src:  2001:db8:6::8
Inner dst:  64:ff9b::198.51.100.9

I like this one too.

On Wed, Apr 15, 2015 at 11:04 AM, Michael Richardson <mcr at sandelman.ca> wrote:
>
> Tore Anderson <tore at fud.no> wrote:
>     > 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...
>
> And... we can use IPv4 routing (OSPF) to split the load across many devices I
> think, and we can probably also invent a way to distribute EAMT entries into
> OSPF.
> Probably we'd have to argue for a few months if it's an OSPFv2 (IPv4) or
> OSPFv3 (IPv6) TLV.
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        | network architect  [
> ]     mcr at sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [
>