[Jool-list] EAM vs 6052

[Alberto Leiva]

> (assuming you're compliant
> with RFC6052 section 3.1 - I haven't checked that).

I'm not, actually. But there's a somewhat important reason for that:
If we ban 64::192.168, then users can fall into trouble following
tutorials (the same thing can be said about 192.0.2 and the rest of
the sample prefixes).

It's the kind of thing that makes me hit my head against the wall.

> Even if the operator has
> configured 64:ff9b::/96 as the pool6, you still cannot translate a
> packet which contain 64:ff9b::192.168.1.2

> I will then null route in order to make it happy.

I'm convinced I need a v6-pool6791 now.

Thanks. I will bounce this at the IETF along with other topics I need
to wrap my head around.

On Tue, Aug 25, 2015 at 12:32 AM, Tore Anderson <tore at fud.no> wrote:
> * Alberto Leiva <ydahhrk at gmail.com>
>
>> > 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?
>
> The way I see it, since such a requirement isn't stated anywhere,
> cannot be considered a MUST. On the other hand there is no MUST NOT
> either, so I believe both requiring and not requiring pool6 to
> beconfigured would be compliant with the specs.
>
>> 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.
>
> You could also argue the same thing about RFC1918 addresses and the use
> of the 64:ff9b::/96 well known RFC6052 prefix: Even if the operator has
> configured 64:ff9b::/96 as the pool6, you still cannot translate a
> packet which contain 64:ff9b::192.168.1.2 (assuming you're compliant
> with RFC6052 section 3.1 - I haven't checked that).
>
> Personally, I think that is fine. Translate what you can, drop what you
> can not. But if you take the position that if you cannot ensure you can
> translate *all* packets, then you refuse to translate *any* packets,
> you would need to consider forbidding pool6=64:ff9b::/96 too...
>
> That said, I have no real issue with you making pool6 mandatory, it
> doesn't hurt any of my use cases, and if it does in the future I can
> easily enough give it some bogus prefix I will then null route in order
> to make it happy.
>
> Anyway, you asked for my opinion and you got it - but don't feel
> obligated to actually listen to me. :-)
>
> Tore
>