[Jool-list] EAM vs 6052

[Alberto Leiva]

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

But where's the latter half of that specified?

My point is that this doesn't seem to me like the selling ropes
situation. We cannot expect the operator to mind intermediary nodes
with untranslatable addresses while configuring an EAM/SIIT. This
detail slipped past even the writers of the original SIIT/6052, which
is the reason why 6791 had to happen later.

If an operator casually chooses to use the EAMT but no 6052 prefix in
a situation where every IPv4 address is supposed to be translatable,
everything will *appear* to work. It's *our* fault if the translator
starts dropping traffic, not theirs. WE are the ones tying the rope to
their necks.

If 6052 is optional, I believe we NEED a fallback 4 to 6 translation option.

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

Well, in the case of v6-pool6791 I'm not technically forcing them
since it would default to its host address.

I do dislike the v6-pool6791 approach though, since it sounds somewhat
overcomplicated.

Although it also sounds like the most scalable solution, in case
future address translation algorithms appear, which also can't
guarantee a 6 to 4 translation.

On Sat, Aug 22, 2015 at 3:22 AM, Tore Anderson <tore at fud.no> wrote:
> 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