[Jool-list] EAM vs 6052

[Alberto Leiva]

> which also can't guarantee a 6 to 4 translation.

I mean 4 to 6

On Mon, Aug 24, 2015 at 11:47 AM, Alberto Leiva <ydahhrk at gmail.com> wrote:
>> 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