Subject: NAT+PT for IPv6 Transition & Operator Feedback generally

From: RJ Atkinson <[email-masked]>
Date: Wed, 14 Nov 2007 08:19:56 -0500

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.

	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 recentFrom [email-masked] Wed Nov 14 08:52:33 2007
From: RJ Atkinson <[email-masked]>
To: [email-masked]
Date: Wed, 14 Nov 2007 08:19:56 -0500
Subject: NAT+PT for IPv6 Transition & Operator Feedback generally

	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.

	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 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Nov 2007 15:14:27 +0100

On 14 nov 2007, at 14:19, RJ Atkinson wrote:

> specification for the function.

Please note that Brian Carpenter recently wrote a draft with a new  
take on NAT+PT:

http://www.ietf.org/internet-drafts/draft-carpenter-shanti-01.txt

Alain Durand's draft suggests an IPv4(public)-IPv6-IPv4(private)  
mechanism:

http://www.ietf.org/internet-drafts/draft-durand-v6ops-natv4v6v4-00.txt

And I wrote a draft proposing several modifications/additions to  
existing NAT-PT:

http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-00.txt

There was a lively discussion on this topic on the v6ops list that  
immediately stopped when I posted my draft... Margaret Wasserman  
brought up:

"Exactly what types of operational problems exist that we need to  
solve?  Why aren't the existing v4/v6 transition mechanisms sufficient  
to resolve those problems?  Where are the gaps that needs to be filled?"

It would be good to have answers to those questions from the  
operational community along with the signal that NAT±PT is required.
_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Nov 2007 16:58:04 +0200

Ran,

> the purpose of commenting in person.

There's also e-mail. And some of us in the IETF and the management
thereof do travel to operator meetings. But yes, understanding
what is needed, what the real problems are, and willing
customer participation are all necessary for the success of any
standardization effort.

> operators at this late date.  

I believe we need to look at NAT+PT and get an
improved spec published. More generally, we need
to look again at the current situation on whether
we have all the transition tools that we need. Input
from the IAB has been given; the IESG has asked time
to be allocated for discussion of this topic in meetings;
a number of different proposals are being made and are being
discussed.

I recognize that some set of people believe NAT+PT is the
only viable strategy. I hope we get the spec done, but
I'm not sure the emphasis of NAT+PT as something that
will make or break transition is completely correct.
My personal opinion is more like that it is one tool for
a particular type of situations. A tool with its own
set of problems. Necessary, but not overemphasizing
its role would also be bad, IMHO.

Should we move the technical part of this discussion to
v6ops mailing list?

Jari

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 14 Nov 2007 07:20:47 -0800

> From: RJ Atkinson [mailto:[email-masked]] 

> 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.

Did the mountain come even for Muhammad?

It seems to me that there is an unhelpful attitude in the IETF that it is the maypole around which the rest of the Internet must dance. If we want to be influential we have to accept the fact that there are other stakeholders involved and we must have a strategy for influencing them if our work is to be deployed.

> 	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.

I think that's off the mark. There are some large vendors but the individuals who attend are not necessarily able to influence their employer and there are many significant stakeholders that are not present. Some people attend the IETF to win battles they have already lost at home.

Case in point: NAT PT, it can hardly escape notice that many vociferous NAT-PT opponents are employed by a company that makes a NAT-PT product. Presumably the marketting side of the company put the feature in because they talk to their customers at the operators.

> 	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]

We have to go and talk to the operators, and much more.

More importantly we have to listen to them. If an operator turns up at IETF there is no real opportunity for them to even put their case. The meeting is simply not structured in a way to facilitate that.

I would suggest that the best way to lead deployment of IPv6 would be to hold a workshop and invite the IAB, the ADs of the affected areas, the operators, the vendors and whatever other stakeholders exist or might be able to evangelize. At the end of the workshop issue a press release endorsed by the likes of Vint Cerf, Tim Berners-Lee and co to the effect that it is believed that significant progress has been made on a deployment plan.

> 	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 

I agree in principle, but not that the IESG can do this. Clearly it is not going to happen if the job is given to the IESG given its current workload. Either this has to be done by the IAB or some new board.

Giving the job to the IAB is most attractive in my view, talking and listening to outside parties would greatly enhance the influence of the IAB inside the IETF.

---

From: Lucy Lynch <[email-masked]>
Date: Wed, 14 Nov 2007 07:53:43 -0800 (PST)

On Wed, 14 Nov 2007, Iljitsch van Beijnum wrote:

> Please note that Brian Carpenter recently wrote a draft with a new take on 
> NAT+PT:
>
> Alain Durand's draft suggests an IPv4(public)-IPv6-IPv4(private) mechanism:
>
> And I wrote a draft proposing several modifications/additions to existing 
> NAT-PT:
>
> immediately stopped when I posted my draft... Margaret Wasserman brought up:
>
> "Exactly what types of operational problems exist that we need to solve?  Why 
> aren't the existing v4/v6 transition mechanisms sufficient to resolve those 
> problems?  Where are the gaps that needs to be filled?"

There are several collection efforts going on - you might take a look at:

http://www.civil-tongue.net/clusterf

http://www.ipv6-to-standard.org/

http://ipv6.internet2.edu/

most of these are well advertised in the (Ran defined) Ops community.

- Lucy

> It would be good to have answers to those questions from the operational 
> community along with the signal that NAT±PT is required.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 14 Nov 2007 17:13:12 +0100

> http://www.ipv6-to-standard.org/

Don't bother. The first one is just a big stack of loose associations  
with "IPv6" that don't make sense half the time, the second is a big  
searchable list of something, not sure what.

But as long as we're talking about stuff that's missing from IPv6:  
with IPv4, I can get a modem and do dial-up. PPP takes care of my IP  
address, DNS, etc. If I'm going to do dial-up for IPv6, how am I  
supposed to handle this stuff? PPP sure doesn't help me there. Same  
thing for broadband. Do I get addresses through stateless autoconfig  
or DHCPv6? And/or an entire prefix through DHCPv6? Who puts my  
address in the reverse DNS?

---

From: Francis Dupont <[email-masked]>
Date: Wed, 14 Nov 2007 17:20:58 +0100

In your previous mail you wrote:

http://www.nanog.org/mtg-0710/presentations/Durand-lightning.pdf

[email-masked]

---

From: David Kessens <[email-masked]>
Date: Wed, 14 Nov 2007 23:27:33 -0800

Ran,

> 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.
---

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Nov 2007 10:37:03 +0100

>   NAT-PT without a stable IETF specification and to make it work

We did that with NAT, and I think we lived to regret it.

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.

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.

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 15 Nov 2007 07:47:51 -0600

Just echoing Ran's credit where due -

>> their own.  For example, Russ was at RIPE 55 in Amsterdam recently.

I haven't been to a NANOG in the past year, but Harald, Bill Fenner, and 
David Kessens (from IESG) were all consistent attendees 2-3 years ago. 
Several IAB types were also attending, but Ran's point was specifically 
about IESG.

>> network operator inputs/feedback.

Dave Meyer did a lot of outreach work specifically on SHIM6 and IPv6 
deployment when he was on IAB. I know he/Geoff did a SHIM6 BOF at NANOG, and 
I'm remembering that he did APRICOT pretty clearly (I assume RIPE happened, 
just that I wasn't awake when it did).

Speaking as a member of the audience, the SHIM6 BOF at NANOG 
(http://www.nanog.org/mtg-0510/iab.html) seemed very informative in both 
directions.

So - yes, more IESG/IAB-sponsored BOFs at NOGs on this and similar topics 
would probably be productive.

Thanks,

Spencer

---

From: Eliot Lear <[email-masked]>
Date: Thu, 15 Nov 2007 15:36:41 +0100

I preface this message by remembering that the IETF is an organization
of Individuals not Vendors.

RJ Atkinson wrote:
> of IAB outreach, rather than IESG/IETF outreach).

A bunch of people from many vendors reached out to the operator
community, and that community consisted of several NANOGs, RIPE, LISA
(!!), and others.  We did not standardize JunOS Script, but what is
largely speaking a series of transports and mechanisms above those
transports.  A model has been deferred.  The effort was co-led by Andy
Bierman and Simon Leinen.  It was a broad attempt to provide an
alternative to SNMP because configuration capabilities in SNMP have
never been adopted.  Bert went deliberately slowly so that we could try
to work out what problems we really needed to address.  The IAB workshop
was part of that process, but I wasn't there nor was I in Bert's head so
I can't say what effect it had.  My recollection is that, Ran, you
played a major positive role in this effort.  Lots of heavy lifting.

It is not a done deal.  NETCONF's uptake remains limited.  There are a
lot of reasons for this.  Perhaps things will improve, but perhaps we
may need to revisit some of our decisions.  We may not have gotten it right.

All of this having been said, there was limited actual input from the
operators, and what input we did receive (and I stood on the stage at
NANOG to take input) was not well understood, and in some cases took to
mean more than the operators intended.  This happened in part because I
and others muddled the questions to them at the time, but in part
because operators (and perhaps even now) really did not care at the
protocol level how we sent and received configuration information, so
long as we had a way, and that way interoperated with tools like RANCID.

What this tells me is that our engagement with operators either has to
be deep and ongoing, or that it has to be well structured through clear
questions that are well timed, with appropriate background given so that
implications of the answers are well understood.  In order to do the
former, it means that not only do vendors need to go to NOGs, LISA, etc,
but that operators need to get re-engaged in IETF.  (It is a self
fulfilling prophecy to simply call the IETF the IVTF and write it off. 
You don't fix things that way.)  For the latter we need to work more
closely with the leadership of customer organizations and user groups to
take input.  Even so, it's often difficult to take input from disparate
groups and make everyone happy.

Case and point: the calendaring standard of which I am now most acutely
aware has small device vendors screaming at us due to its complexity,
and yet valid usage cases that demand much of that complexity.  We have
to balance those use cases, with considerations such as whether Moore's
Law (such as it is) will help mobile devices, or whether power
limitations will keep footprints small.  But user groups like members of
Calconnect generally don't want to get to the nitty gritty of how to
handle DST transitions in recurring events (although some individuals do
go to that detail).

Regards,

Eliot

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 Nov 2007 07:44:20 -0500

On  15 Nov 2007, at 04:37, Iljitsch van Beijnum wrote:
> 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.
>
> the IPv6 or IPv4 host that communicates through the NAT-PT  
> translator are required.

I agree that specifying the behaviour in reasonable detail is useful,
both so that users have a clear basis for evaluating and comparing
different implementations, and also so that application protocol
folks can have a more predictable behaviour.

NAT-like devices simply are not going to go away.  Having a clear
and reasonably detailed specification for the behaviour of such
a device gives application protocol designers a better chance of
designing an application protocol that will work through whichever
devices get deployed.

If I look on the shelves at the big box geek store in Silly Valley,
there are bunches of different consumer gateway boxes at consumer
price points.

I can't easily find any consumer "gateway" box on the shelves there
that does not include IPv4 NAT or NAPT today.  Operationally, the
behaviours do seem to differ somewhat.  To the extent the behaviours
are similar or identical, then the application protocol designers
work is made easier.

Yours,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 15 Nov 2007 07:38:11 -0500

> such a reference supportive of the point that the RFC is actually

It is unfortunate that you mistook the financial-interest disclaimer [1]
as something else.

I've heard from end users in North America, Asia/Pacific, and also
Europe who say they are using this operationally today.  My relationship
with our customers (who are most usually also customers of other
suppliers) imposes NDA constraints upon me -- as it does on most other
folks in my situation at other firms.  I'm not inclined to provide
free advertising for my employer's competitors by naming the products
these folks say they are using.  One imagines a web search likely
will find them.

So while I can, and have, asked those operational folks to participate
directly, I can't provide a list without their consent.  The broad
reaction to my suggestion that they participate directly was usually
of the form "waste of time; IETF won't listen; please ignore them and
implement this anyway".

> draft was up for Last Call.

"some number" is an indefinite number.  I know there were some
objections.  You haven't denied that.

> accepted by the wider IETF community.

That statement is in fact part of the problem here.  The WG is not
the entire universe of affected Internet stakeholders -- and the
operational community is particularly impacted and also largely
absent from the IETF and its WGs.

Folks appear not to have done much outreach to operational folks
(who generally aren't in the IETF for myriad reasons, including
the perception that it is a waste of their time) to find out whether
or not the technology was in use or not -- and what issues (if any)
those operational folks might have been solving (or issues that
they might have had with the RFC).

Your statement merely tends to confirm the perceptions of those
who refer to the IETF as the IVTF, which is sad to me.  I really
was hoping for better.  I would prefer that a way be found to bridge
this gap in perception, as that would be best for the future of
the Internet.

> reflect what actually happened.

See comments above, which equally apply here.

> honestly cannot call that a situation where the IETF simply ignores

Another process option for the IESG would have been to form a WG or
even a BOF on updating/enhancing/replacing the RFC -- instead of
moving it to historic.  Undertaking that process option would seem
more consistent with your acknowledgement above that there were
"quite a few voices ... puhsing for a new and improved NAT-PT".

Moving it to Historic was not the only process option available
to the IESG, as you seemed to be claiming earlier.

>   NAT-PT without a stable IETF specification and to make it work

I share the idea that in the abstract the IETF does not need to
standardise such a thing -- mainly because I am in part an economist.
Useful technology tends to deploy itself regardless of standards.

In this case, what some operational folks say they need, which
I believe I said in my earlier note, is an open specification
so that it will be interoperable.  Interoperation with the rest
of the deployed Internet is clearly needed.  As I've noted all
along, those folks have advocated implementing the existing RFC
regardless of its IETF status.

If folks want to come up with an improved open specification,
I think that would be great -- and I suspect that at least some
operational folks would find that useful.  I-Ds of the past few days
seem to indicate that some effort on this topic is likely to happen,
either with or without the IETF.

Yours,

Ran
[email-masked]

---

From: Marc Manthey <[email-masked]>
Date: Thu, 15 Nov 2007 17:32:32 +0100

> http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat- 

just "cached"  ? or is it  pre expired ;) ?

http://216.239.59.104/search?q=cache:vYqujmV-6qcJ:www.ietf.org/ 
internet-drafts/draft-van-beijnum-modified-nat-pt-00.txt+draft-van- 
beijnum-modified-nat-pt-00.txt&hl=de&ct=clnk&cd=1&gl=de&client=firefox-a

cheers

Marc

"One must act on what has not yet happened."
--Lao Tzu
web: http://www.let.de
http://piratenpartei-koeln.de

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Nov 2007 17:54:40 +0100

> just "cached"  ? or is it  pre expired ;) ?

This should work better:

http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-01.txt

---

From: David Kessens <[email-masked]>
Date: Thu, 15 Nov 2007 11:26:19 -0800

Iljitsch,

> 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.

> 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).

> the IPv6 or IPv4 host that communicates through the NAT-PT translator  

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
---

---

From: Sam Hartman <[email-masked]>
Date: Thu, 15 Nov 2007 16:47:07 -0500

>>>>> "David" == David Kessens <[email-masked]> writes:

    David> Iljitsch,

    David> On Thu, Nov 15, 2007 at 10:37:03AM +0100, Iljitsch van
    David> Beijnum 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.
    >> 

    David> I am not part of that 'we'. I don't believe we would have
    David> been able to produce a standard that was not already
    David> overtaken by innovation in the marketplace before we got it
    David> out.

I think that if we had overcome the "Nat is evil" crowd sufficiently
we would have been able to do so.  Pointing out things like address
dependent mapping is harmful or examining the interactions between NAT
and locally destined traffic (something behave still does not do)
would have helped the Internet.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2007 15:53:04 +1300

Ran,

On 2007-11-15 02:19, RJ Atkinson wrote:
...
> operators at this late date.  

Please can you explain this in some detail, because to me it's
just words. What services do these operators believe will work
reliably through NAT-PT and how will they handle the residual problems
of NAT-PT (which are detailed in RFC 4966)?

There's no doubt that NAT-PT will work in well-defined scenarios for
which any necessary ALGs are in place. The concern is about how it
works in the general case or for unknown future applications.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 09:29:26 +0100

> of NAT-PT (which are detailed in RFC 4966)?

Maybe this is a good opportunity to point to the latest revision of my  
draft:

http://www.ietf.org/internet-drafts/draft-van-beijnum-modified-nat-pt-02.txt

The two main parts are ditching the DNS ALG, IPv6 hosts must do  
regular A record lookups and create a to-be-translated IPv6 address  
from that themselves and a way for IPv6-only hosts to receive incoming  
sessions from the IPv4-only world. There's also a way to do IPv4-IPv6- 
IPv4 translation with only a single layer of IPv4 NAT.

> works in the general case or for unknown future applications.

I don't think we need to solve the unknown future applications case.  
If something like 95% of the users have the same experience behind  
(some kind of) NAT-PT as they would with their current typical setup  
(which would probably be IPv4 NAT) that's good enough. NAT-PT comes  
with full IPv6 so the other 5% can be done over IPv6. And if that  
doesn't work, those users could get real IPv4 connectivity through  
softwires or regular IPv4.

What we do need to solve are things in NAT-PT that negatively impact  
IPv6 in general.