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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf