Hi, Teemu, Le 21 oct. 2010 à 18:35, <[email protected]> <[email protected]> a écrit :
> It would be better if NAT66 would not be used in such cases at all, but if > that ought to happen anyway, it would be better done as efficienly as > possible (at least for the entity spoiling party for others:) It is still time, IMHO, to avoid that it "happens anyway", at least for those that read IETF explanations. NAT66 does pollute IPv6 badly by the fact that hosts no longer know their global addresses (no e2e address preservation), which is incompatible with peer-to-peer in IPv6. It's better to work on alternative approaches that address the same problems without breaking e2e address preservation. Some don't like my repeating that there is such an approach with SAM (tools.ietf.org/html/draft-despres-softwire-sam-01). However, based on automatic tunneling rather than translation, it is designed to solve the renumbering and multihoming problems without sacrificing e2e address preservation. Regards, RD > > Btw wasn't it so that due stateless nature of NAT66 no keep-alives whatsoever > are needed? > > Best regards, > > Teemu > > ----- Original message ----- > > Margaret Wasserman wrote: > > > On Oct 19, 2010, at 9:31 AM, <[email protected]> wrote: > > > > Have you considered selection of ULA prefix(es) for internal network > > > > in such a manner that it/they can be translated to NAT uplink's /64 > > > > prefix in checksum neutral fashion? > > > > > > > This is an interesting idea, however it undermines the purpose of > > > NAT66... If the internal addresses are chosen to allow checksum > > > neutral translation to external addresses, then the internal addresses > > > will need to be changed whenever the site is renumbered by an ISP, or > > > when a site changes ISPs. > > > > Regardless of NAT I'd be interesting in seeing a working example where > > internal hosts renumber successfully for any reason, much less in > > response to external renumbering. How would, for example, a persistent > > (internal-internal) database connection be renumbered securely? > > > > Used to be the IEFT required a reproducible working implementation > > before > > considering this sort of RFC. Has that policy been discontinued? > > > > Roger Marquis > > _______________________________________________ > > nat66 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nat66 > > > > > _______________________________________________ > nat66 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nat66 _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
