On Oct 31, 2010, at 6:19 AM, S.P.Zeidler wrote: > Hi, > > Thus wrote Fred Baker ([email protected]): > >> I do have a problem with one aspect of that, though, which is that you want >> the mechanism to be the same for stateful translators that will potentially >> come up up with a different TCP four-tuple per session AND apply to the >> stateless (configured but no dynamic state, with no port translation) >> version. With NAT66 as specified, you can do this once and know the values >> until you have a change of hardware or your company has a change of >> contract. > > Only if the packets pass the same algorithmic NAT. They may not.
Well, one going to the same upstream. If you have multiple DMZs using the same configuration, they will come up with the same result. > [...] > >> If that's not adequate - and no, I don't accept "it's not adequate" as an >> answer, I'd really like an explanation, because I don't see why not in the >> stateless case - then I find myself thinking in terms of ICMP or something >> akin to it. If I could send a datagram that would follow the same path to >> the same DMZ, perhaps as an anycast or multicast, and get zero or more >> responses saying "I would have changed your source address to []", would >> that be adequate? > > That would probably be necessary. > > regards, > spz > -- > [email protected] (S.P.Zeidler) _______________________________________________ nat66 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nat66
