Iljitsch, On Thu, Nov 15, 2007 at 10:37:03AM +0100, Iljitsch van Beijnum wrote: > On 15 nov 2007, at 8:27, David Kessens wrote: > > >PS as my personal opinion on NAT-PT, as long as we define it as > > middlebox as opposed to a protocol that has strong interoperation > > needs, I am not convinced that it actually even needs to be > > standardized by IETF as it is perfectly possible to implement > > NAT-PT without a stable IETF specification and to make it work > > across the Internet. > > We did that with NAT, and I think we lived to regret it. I am not part of that 'we'. I don't believe we would have been able to produce a standard that was not already overtaken by innovation in the marketplace before we got it out. On the other hand, now that NAT has evolved into a more stable product, it seems useful to find commonalities like BEHAVE has been doing. > In fact, I was thinking about adding text to my modified NAT-PT draft > to mandate some specific NAT behavior rather than letting the vendors > figure it out in order to make it easier for applications to work > around the problems that the NAT part in NAT-PT creates. But sometimes we first need to try things out in the real world before we actually know what behavior works best. I agree that it can be useful to document some NAT behavior, but I don't believe it is necessary that NAT itself is standardized in order to achieve interoperability (in fact, I am not sure whether this is the right word, it is more about better application expections for certain behavior to achieve easier and more predictable NAT traversal). > I also believe we are moving towards a consensus that a NAT-PT like > solution that purely exists in a middlebox is probably not workable > for exactly the reasons that RFC 4966 explains so changes on either > the IPv6 or IPv4 host that communicates through the NAT-PT translator > are required. In that case, I am not sure whether we should still call it NAT-PT. What we are really developing then are NAT-PT control protocols or perhaps something completely new that deserves a new name. I have no issue with that, although I would like to note that we don't have a strong trackrecord when it comes to protocols that control middleboxes. In addition, I don't have a lot of hope to solve all issues with NAT behavior as they are inherent to the process of address translation itself. For the record, I believe that most people on this list are really tired of any discussion that involves NATs in any form or shape. My opinion is now known and I don't intend to send any more mail on this topic. David Kessens --- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf