* Alberto Leiva <[email protected]> > > 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 _______________________________________________ Jool-list mailing list [email protected] https://mail-lists.nic.mx/listas/listinfo/jool-list
