[Jool-list] EAM vs 6052

Tore Anderson tore at fud.no
Sat Aug 22 03:22:55 CDT 2015


Hi Alberto,

* Alberto Leiva

> Should an SIIT implementation be able to choose to support EAM but
> not RFC 6052?

The implementation must (per 6145bis) *support* both, but that doesn't
necessarily mean that it requires both to be configured by the user.

> Admittedly, the introduction of the draft is saying no:
> 
>     The Explicit Address Mapping Table does not replace [RFC6052].

In a formal IETF sense. RFC6052 isn't deprecated or anything, EAM isn't
«RFC6052bis».

> I'm thinking I messed this up in Jool. Currently, if the packet
> addresses match, Jool translates using EAM even if there is no pool6
> prefix. Should we force Jool to stay disabled in these cases?
> 
> The problem with only EAM/translating is that doesn't guarantee every
> IPv4 address is translatable. So if an IPv4 router with an
> untranslatable address answers an error to IPv6, Jool drops the ICMP
> error (RFC 6791 style).
> 
> So I'm thinking I need to either force pool6 or create an IPv6
> pool6791. Am I going the right way?

IMHO no. Consider for example IVI, EAM {0/0, 2001:db8:ff00::/40}.
Or possibly a SIIT-DC BR that is only handling hairpinned traffic
(granted, this is a somewhat convoluted example, but you could do it as
an optimsation to reduce hairpin latency if it is a great distance
between the ER-nodes and the internet-connected BRs). In neither of
these use cases you need pool6 or a v6-pool6791, so why force the admin
to configure some bogus never to be used prefixes?

I'd say just drop the packet or return it to the kernel. If you prefer,
log a warning when you do (but make it a one-time-only message or at
least subject to heavy rate-limiting so that an external attacker can't
fill your /var/log filesystem by spamming you with non-translatable
packets).

Tore


More information about the Jool-list mailing list