Hi, all, Here is a view of where we are, in my understanding, in view of the two parallel discussions on v6ops and NAT66 mailing lists:
1. - Some consider that some form of NAT66 is useful for some real customer needs. - Clear descriptions of which scenarios benefit from which type of NAT66 are however still missing. (At this stage, this seems to only be scenarios where baring all incoming connectivity is found desirable, but more precisions are lacking.) - If, once documented, such scenarios are convincing, documenting in IETF NAT66 characteristics that fit them will make sense. 2 - Some contributors advocate that "NAT66" should only designate *stateless NAT66*. - Making clear that "NAT66" may also designate *stateful NAT66* would eliminate ambiguity and misunderstanding we have seen in current discussions. 3. - 6to4-PMT is a proposal to add stateless NAT66's to 6to4 relays (without tool available for customers to know that their 6to4 addresses are now translated). - So far, there seems to be no common understanding that this breaks a legitimate use of 6to4 that exist today (6to4 addresses used for incoming connectivity). - Unless this understanding would be proved to be wrong, it should justify that IETF doesn't endorse 6to4-PMT. - This is despite the recognized improvement 6to4-PMT can bring for other uses of 6to4, because: . These uses have known limitations, but they won't get worse with 6to4 relays kept unchanged . The Hippocrates principle for disease treatments still holds: PRIMUM NON NOCERE (en.wikipedia.org/wiki/Hippocratic_Oath) Regards, RD > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
