James,
My impression is that there is considerable pressure in IETF to NOT
publish a standard for NAT66 ... or even discuss the potential utility of this
technology in the hopes that somehow ignoring it will make it less likely for
it to be utilized.
>From my standpoint that is a vain hope.....for many of us down here in the
>trenches NAT is just too useful. There will be a demand for it and vendors
>will heed that call eventually. Hopefully sooner rather then later, as a lack
>of such solutions will help slow down the adoption of IPv6 itself to some
>degree, but that is a digression
It was my impression that IETF's mission is to set standards so that there is
at least some predictability in the way a given technology will
function....from vendor to vendor and implementation to implementation. That
improves the ability design and implement other technologies which interact
with those. Am I mistaken in that impression? Else what is the purpose of IETF?
Obviously, IETF doesn't have the ability to enforce adherence to those
standards....and I certainly know that even when those standards exist...the
degree to which individual vendors adhere to them in their solutions is often
quite loose at best. However, the very act of publishing those standards has
value....else what is the point of all the work people are doing here?
My point here is that it would be better for IETF to publish some standard for
NAT66 so that at least there can be better predictability about how particular
implementations of it will function for those technologies that will interact
with it. I would think that would be a far better outcome then not publishing a
standard at all.
As an aside, I made some specific criticisms in reference to RFC 4864. I
applaud the work and the effort that went into that document. However, I found
it weak in a couple areas when addressing the real utility NAT has for certain
functions. I'm not sure that there is any effective substitute for that
functionality in IPv6 without NAT...but I'd rather see the document recognize
that fact rather then attempt to gloss it over. Perhaps the authors may
consider revisiting it.
Finally, the statement that you quoted from me was a specific response to Keith
who suggested that it would be prudent for me (or basically any other Admin) to
eschew NAT in future because it breaks too many things. I was just attempting
to explain to him that it didn't make any sense for me (or any other admin) to
do so, if in my particular situation it solved more problems then it
caused...and the available substitutes weren't sufficient to my needs.
Christopher Engel
-----Original Message-----
From: james woodyatt [mailto:[email protected]]
Sent: Monday, November 02, 2009 6:55 PM
To: Chris Engel
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6
On Nov 2, 2009, at 15:25, Chris Engel wrote:
>
> [...] However, just because NAT isn't a very good tool for SOME
> situations doesn't mean we should take it out of the tool box when
> it's still a perfectly good tool for MANY situations (which it IS).
> [...]
I'm having trouble identifying your basic concern.
Are you under the mistaken impression that IETF has any power to stop you from
deploying IPv6/NAT in your networks? That concern should be easily dispatched
with just a moment of contemplation. The IETF does not have the keys to your
toolbox. Stop worrying about the Internet cops; they are not the jack-booted
authoritarians you might be imagining them to be.
Are you instead under the mistaken impression that IPv6/NAT equipment will not
be available to you unless IETF publishes a standards document for NAT66? That
would be a pretty strange concern coming from somebody who seems quite
satisfied already with the available IPv4/NAT equipment on the market, despite
the fact that there is no standards document for which their behavior is
expected to conform.
What is it, in particular, that you wish for the IETF to do, and why do you
believe the IETF should be the ones to do it? (I recommend reviewing the
archives of this list to see if your concerns have already been discussed
before attempting to supplement the discussion with additional argument.)
--
james woodyatt <[email protected]>
member of technical staff, communications engineering
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
