Not all tools are suitable for all cases. Renumbering of enterprise network is quite a different case than few laptops and one ipad behind lightweight nat66 box that happens to have frequently changing /64 on its uplink and doesn't like to do checksum recalculation.. Well, usually ND Proxy is used in that case (and hosts renumber always when /64 changes). And if the box is mobile phone, its uplink's /64 may change often (e.g. Daily).
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:) 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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/nat66 >
_______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
