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