Ran,
On Wed, Nov 14, 2007 at 08:19:56AM -0500, RJ Atkinson wrote:
Given that the IESG ignored inputs from some number of
people noting that the RFC in question was actually deployed [1],
it seems doubtful that it would be worthwhile for any of the
operators who have deployed NAT+PT to travel to an IETF for
the purpose of commenting in person.
This paragraph is misleading in many ways: your reference [1] actually
points to a reference that indicates that a company that you are very
familiar with does not have a NAT-PT product, let alone that any
customers of that company might be able to deploy it. I would not call
such a reference supportive of the point that the RFC is actually
deployed as you claim.
Furthermore, you seem to know that the IESG ignored inputs when this
draft was up for Last Call. I was the shepherding AD at the time and
reality was very different:
I was very reluctant to take this draft on as I didn't look forward
for yet another inconclusive round of discussions on the merits of
NAT. In addition, personally I am not convinced that the Historic
status really has any value, especially if one considers the amount of
work to actually get it done as opposed to using the same energy for
other important work.
However, it was very clear that there was consensus within the working
group to request this status change as an alternative to moving it to
experimental as the process didn't seem to allow us to do that. I
talked to the chairs at multiple occasions and made it clear that in
my judegement, I expected that this status change might not be easily
accepted by the wider IETF community.
However, to my own surprise, after I issued the Last Call, it became
very clear from the comments received that there was no significant
opposition to making NAT-PT historic. Your statement that the IESG
just "ignored inputs from some number of people" seems thus not to
reflect what actually happened.
I do understand why quite a few operators have a somewhat cynical view
due to a believe that the IETF is not listening enough to them. While
there is definitely some truth there, there is very often also a
serious amount of misunderstanding due to incomplete information and
often misleading information spread by self-appointed spokes(wo)men
for the IETF. For example in this particular case, the working group
really wanted to move NAT-PT to experimental with the intention to
show that it is was not the preferred IETF solution but at the same
time not completely rule it's use out either (in fact even Historic
doesn't really say that one should not use it under any circumstance),
but as mentioned earlier we didn't find a way to actually do that with
our process rules. At the same time, there were already quite a few
voices within the IETF pushing for a new and improved NAT-PT. I
honestly cannot call that a situation where the IETF simply ignores
the needs of operators.
David Kessens
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.
---
More than one person in the operator community now refers
to the "IVTF" rather than IETF, because of the perception that the
large vendors and professional standards-goers dominate IETF processes
and IESG decisions and that network operators [2] are mostly ignored.
It seems a bit of hubris for one to insist that operators
must come to IETF given the history of IETF and IESG ignoring
many operator inputs for much of the past decade.[3]
The main bit of operator input that has been undertaken by IETF
has been NetConf (basically standardising an equivalent to the then
already deployed, albeit then proprietary, JunOS Script). That was
done because of the recommendation from the IAB Network Management
Workshop held in Reston earlier this decade (which itself was a bit
of IAB outreach, rather than IESG/IETF outreach). Rather than
demanding that operators come to IETF as if supplicants, particularly
given the history, some would prefer to see the IETF/IESG engage in
more outreach to the operational community -- not as a one-time thing
but as an ongoing obligation. IETF and IESG should go to the
operational community, rather than expecting or demanding that
they come to the IETF. [4] This burden of operator outreach ought
not be levied only on the O&M Area, but across the whole IESG.
IETF WG chairs should similarly be encouraged to actively reach out
to collect operational feedback.
Several operators have said that they have deployed this
IPv6::IPv4 NAT+PT technology. So the data seems to indicate at least
some operational folks view that RFC as "good enough", even if some
IETF folks view it as "imperfect". (The separate conclusions of
"good enough" and "imperfect" are not mutually exclusive, of course.
Sometimes "perfect" is the enemy of "good enough".)
Further, at the recent RIPE meeting in Amsterdam, there seemed
to be very broad operator feedback in the hallways that this NAT+PT
approach is the only viable transition strategy left available to
operators at this late date. Projections at the RIPE 55 meeting
were that the last ordinary IPv4 block will go from IANA to an RIR
circa November 2010. There was similar broad agreement that dual-stack
can't happen fast enough to be viable, given the short 3 year period
left and the lack of current economic incentives for most folks
to enable IPv6.[5,6]
In any event, Alain Durand (Comcast) has just posted
an I-D with some requirements in this area. He also made a public
presentation asking for NAT+PT at the last NANOG. (I believe his
NANOG presentation is available online in PDF; it was a "lightning
talk". Folks who have read down this far probably want to read that.)
There is an opportunity in all of this mess for some folks
to initiate work to develop a replacement RFC for NAT+PT. As near as
I can tell, operators aren't particularly worried whether that RFC
is on the standards-track or not, but they do want to have an open
specification for the function. Such an effort would likely benefit
from holding focused BOFs on the topic at the various operational
fora around the globe to present then-current thinking about how
to specify that and to solicit operational feedback.
Yours,
Ran
DISCLAIMER: I am never authorised to speak for my employer and
am not doing so in this note. Further, I personally am not the
decision-maker for what we do or don't implement or for when
we might implement something.
[1] Extreme has not shipped an implementation of this so far as I
am aware. It is the most-requested-of-us not-yet-implemented IPv6
feature that I know of. Since the IESG deprecation, several users
have told me that my employer should ignore the IESG action and
implement NAT+PT anyway -- according to that existing (and recently
deprecated) RFC.
[2] Although some use the term "network operators" narrowly to mean
Internet Service Providers. I *always* use a very broad definition
to include all sorts of network operators, including but not limited
to academic network operators, enterprise network operators,
content providers, Internet Exchange Points, and Internet Service
Providers. So please interpret this phrase very broadly.
[3] Some individual O&M Area Directors have tried to help inject
operational inputs to IETF/IESG activities. Different individuals
in that role have had different levels of effectiveness with that
over the past decade or so.
[4] Credit where due. Russ Housley and a few other IESG folks
have been attending some operationally oriented meetings on
their own. For example, Russ was at RIPE 55 in Amsterdam recently.
It would be nice to see the IESG regularly hold BOFs at APRICOT,
NANOG, RIPE, SANOG, and so forth around the globe to solicit
network operator inputs/feedback.
[5] In most organisations, budgets really are a zero sum game.
This means that spending money on X means reducing spending on
Y and Z. Budgets are tight everywhere, which means the money
needed to enable IPv6 right now within some enterprise/campus/network
just might not exist, given that many users already have enough
IPv4 address space and that IPv6 doesn't usually generate incremental
revenue to cover the incremental costs and there are other
business/academic needs unrelated to IPv6 or even networking.
[6] Folks might also want to go read the actual memoranda (dated
09 Jun 2003 & 29 Sep 2003) from US ASD/NII on IPv6 policy for
US DoD. The common summaries of those memoranda are usually
misleading at best and wrong at worst. It is worth doing a
web search and reading the actual memoranda in full as written.
Perhaps the least widely reported sentence there is:
"No implementation of IPv6 shall be permitted on networks
carrying operations traffic within DoD at this time."
I am told the US DREN has enabled IPv6, but that is a research
network and does not carry "operations traffic". I am also told
that, as of last week, DoD networks carrying "operations traffic"
are still prohibited from deploying IPv6 -- for myriad reasons,
including unresolved security concerns with IPv6.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf