Subject: Re: [nat66] Necessity for NAT remains in IPv6

From: Roger Marquis <[email-masked]>
Date: Tue, 3 Nov 2009 18:19:47 -0800 (PST)

Mark Andrews wrote:
> NAT44 was a necessary evil as we had effectively run out IPv4 addresses.

This is false.  NAT was implemented long, long before there were widespread
concerns regarding the number of addresses.  A larger reason for NAT was
that many of us were using non-routable addresses, as there was (and still
is) no business case for any of our internal addresses to be publically
routable.

Roger

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Nov 2009 13:33:24 +1100

> is) no business case for any of our internal addresses to be publically

Well then you don't need NAT then.

If you need to get packets back to internal machines from external
machines then yes those addresses were routed.  You just routed
them in translated form.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roger Marquis <[email-masked]>
Date: Tue, 3 Nov 2009 19:01:52 -0800 (PST)

> Chris Engel wrote:
> to decide. In many cases, it DOESN'T harm their organizations
> environments at all.... because the applications they would be
> missing are NOT the "best applications to get work done" or meet the
> organizations technology goals.... or because NAT friendly
> alternatives exist for the ones that do.

One example that's often cited as being a NAT issue is SIP(/STUN/TURN).  The real
issue here, however, is SIP's embedding of a network layer address in the application
data.  This convoluted authentication mechanism, and ISO 7 layer model breakage, is
the problem, not NAT.  SIP is an old, old protocol onto which many kitchen sink-like
'features' have piggybacked.  Far less reengineering would be required to use modern
protocols like IAX in place of SIP than to get rid of NAT (which isn't even a
possibility anyhow).

Protocols like DCCP and SCTP which do not implement TCP-like statefulness are also
cited as NAT issues but their real issue is statefulness.  It doesn't matter whether
a firewall uses NAT or not, it still has to keep the state of these non-TCP streams
for security, and the use of NAT without firewalling is so rare (usually limited to
server load balancing) it can be considered a non-issue.  Any time you have an edge
device keeping a state table it is easy to implement NAT on top of that.  Since
letting these protocols through the firewall without statefulness is not an option,
and any time there is statefulness NAT can be implemented easily, there is no NAT
issue here.

Despite all the vague and unsubstantiated claims of 'NAT issues' we are still waiting
for an example that actually holds water.  Until then you are safe in assuming that
financial interests, not technical issues, are blocking the implementation of NAT in
IPv6.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Nov 2009 22:06:53 -0500

Roger Marquis wrote:
> This is false.  NAT was implemented long, long before there were
> widespread concerns regarding the number of addresses.  A larger
> reason for NAT was that many of us were using non-routable addresses,
> as there was (and still is) no business case for any of our internal
> addresses to be publically routable.
as long as you want to be stuck with only being able to use applications
and transport protocols from the late 20th century, you mean.

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Nov 2009 22:10:31 -0500

Roger Marquis wrote:
> One example that's often cited as being a NAT issue is
> SIP(/STUN/TURN).  The real issue here, however, is SIP's embedding of
> a network layer address in the application data.  This convoluted
> authentication mechanism, and ISO 7 layer model breakage, is
> the problem, not NAT.  
The Internet was not designed according to the ISO 7 layer model. 
There's absolutely nothing wrong with passing network layer addresses in
application messages in the Internet architecture.  And DNS is, as far
as the architecture is concerned, just another application.

Keith

---

From: Roger Marquis <[email-masked]>
Date: Tue, 3 Nov 2009 19:30:40 -0800 (PST)

> machines then yes those addresses were routed.  You just routed

That's an artifact of the (unforeseen at the time) transition from
application proxy-based firewalls to NAT-based firewalls.  Still had
nothing to do with concerns regarding addresses availability, which
wouldn't attain critical mass for several years.

Roger Marquis

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Nov 2009 15:32:47 +1100

> wouldn't attain critical mass for several years.

And hosts didn't support more than one address on a interface and
... 

The reasons for using NAT back then have basically gone away.  It
really is just inertia and familiarity that keeps people asking for
NAT despite all the harm its presense causes.

Mark

---

From: Steven Blake <[email-masked]>
Date: Tue, 03 Nov 2009 23:35:14 -0500

> as the architecture is concerned, just another application.

Unfortunately, this architecture does not scale in a network where hosts
are dynamically multihomed and/or mobile.

Regards,

// Steve

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Nov 2009 23:53:30 -0500

> are dynamically multihomed and/or mobile.
perhaps not, but NATs don't make it any easier.  nor does playing games
with DNS.

---

From: Steven Blake <[email-masked]>
Date: Wed, 04 Nov 2009 01:24:02 -0500

> perhaps not, but NATs don't make it any easier.  nor does playing games

Opinions differ on that.

Every proposal to add that one extra level of indirection into the
Internet architecture, whether it is deploying home agents, binding
applications more tightly to DNS, or adding indirection into the
routing, is going to make someone's life more difficult and some
application perform less well than it did in the perfect network where
every site was singly attached and every host was stationary.

Therein lies the deadlock.

Regards,

// Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Nov 2009 19:32:26 +1300

Please could you set a Subject field that tells us what
you are talking about?

Thanks

   Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Nov 2009 07:29:12 -0500

>> perhaps not, but NATs don't make it any easier.  nor does playing games
yes they do, but this might be due to a failure to do a complete
analysis.  it's very easy to solve one's immediate view of the problem
at the expense of others.  sadly, IETF's structure even seems to
encourage this.
> Therein lies the deadlock.
agreed.

Keith

---

From: Chris Engel <[email-masked]>
Date: Wed, 4 Nov 2009 12:24:49 -0500

Excuse me if I find the claims of this vast "harm" ringing a little hollow. Exactly who am I supposed to be "harming" by choosing to deploy NAT ???

- My end users and my company board have had zero complaints regarding it. In fact, we generally get quite high marks for satisfaction with the services we deliver from both those groups. So it can't be them.

- Application Developers who need to put in extra work to make their applications work with NAT??  Strange, I don't recall asking a single one of them to do that, EVER. Now if THEY choose to do that, I'm sure that they are not going to eat those costs but rather pass them along to me in the price of their product.... and if their product is worth running, I am certainly going to be willing to pay those costs.  They could also choose NOT to build support for NAT into their products.... and then all the burden and costs associated with making that product work with NAT will fall upon me... not them. Again if their application is worth running then I will gladly meet that cost and burden. Strangely in the over 9 years my company has been in existence and I have been tasked with the responsibility of providing IT services for it there has never once been a single instance of this occurring.

- Protocol Designers for whom NAT would provide a barrier to their Protocol working?? Again, I never asked anyone to design their Protocol to work with NAT. It's upto them to determine whether they WANT to deliver those services to NAT users.... no one is forcing them to do so.

- Other end user who don't use NAT and feel like they need to pay an additional cost because application designers build in NAT support for those who use it??  I've NEVER told any outside entity what applications they must and must not purchase. By all means, go out and purchase an application that DOESN'T support NAT and save yourself some money. Can't find one? Well then your real argument is with the DEVELOPERS.... convince them not to build in NAT support and to lower the cost of their apps.

- Outside application users who want to put packets across my network boundary but can't because I'm running NAT??? Sorry, but we've never advertised to ANYONE that we would automatically accept their packets regardless of the nature of them. Any promise of services or connectivity that we have made to anyone is VERY WELL DEFINED and doesn't include anything that NAT would break. Historically we've significantly exceeded those promises.... and the people with whom we have made them have expressed significant satisfaction with us in this area.

Again, please inform me specifically who is being harmed by our choosing to deploy NAT and how?
The only people I can see that would have a complaint are Developers who want to sell us applications that we don't want to buy and users who try to put packets across our networks that we don't want to receive.

Forgive the analogy, but this is a little bit like people complaining that golf-clubs are more expensive because some people are left-handed and some are right-handed and a manufacturer has to supply both models if they want to reach the widest possible market.

For those Application/Protocol developers who find it troublesome to design their products to work well with NAT the solution is simple.... DON'T.  No one on the pro-NAT side is holding a gun to your heads and telling you that you must. Now if you want your product to be attractive to NAT users...then obviously putting in that support is important. However, I fail to see how that is any different then any other requirement a "consumer" of your product might give you in order for them to "purchase" it. Is the complaint here that you must include features that are attractive to your "consumers" rather then just those which you find convenient to build?? Forgive me if that fails to garner much sympathy from me.

Christopher Engel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mark Andrews
Sent: Tuesday, November 03, 2009 11:33 PM
To: Roger Marquis
Cc: [email-masked]
Subject: [SPAM] - Re: [nat66] Necessity for NAT remains in IPv6 - Email has different SMTP TO: and MIME TO: fields in the email addresses

In message <[email-masked]>, Roger Marquis writes:
> >> widesprea
> d
> >> concerns regarding the number of addresses.  A larger reason for
> >> NAT was that many of us were using non-routable addresses, as there
> >> was (and still
> > machines then yes those addresses were routed.  You just routed them
> > in translated form.
>

And hosts didn't support more than one address on a interface and ...

The reasons for using NAT back then have basically gone away.  It really is just inertia and familiarity that keeps people asking for NAT despite all the harm its presense causes.

Mark
--

Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Nov 2009 12:38:28 -0500

> - My end users and my company board have had zero complaints regarding it. In fact, we generally get quite high marks for satisfaction with the services we deliver from both those groups. So it can…
Wrong.  End users and board members typically don't understand what NATs
are, nor their effects on the network's ability to support
applications.  If they want to run an app that doesn't work on your
network, they blame the app, even though the NATs in your network are
what is screwing up the app. 

Furthermore, end users and board members don't understand the degree to
which the widespread deployment of NATs is artificially raising the cost
of deploying new apps, and denying them useful new apps which might help
employees in their work and help their company's competitiveness.

Again, in IPv4, it's pretty much a moot point because address scarcity
trumps everything else.  But that's not the case for IPv6.
> - Application Developers who need to put in extra work to make their applications work with NAT??  Strange, I don't recall asking a single one of them to do that, EVER. 
Did you ask for internet telephony to work?  Multi-party conferencing? 
Network management?

What you fail to realize is that NAT affects every single application
currently used in the Internet.  Many of them can continue to mostly
work, with reduced reliability, logging the wrong IP addresses, and
various other operational anomalies that users might not understand (and
you might not understand either).  But lots of apps get changed in one
way or another to deal with NAT.
> Now if THEY choose to do that, I'm sure that they are not going to eat those costs but rather pass them along to me in the price of their product.... and if their product is worth running, I am certainly going to be willing to pay those costs.  
Since you're obviously in (deliberate) denial about those costs, it's
clear you aren't in a position to estimate them.
> They could also choose NOT to build support for NAT into their products.... 
and shrink their markets (at least in IPv4) to essentially zero.  Yeah,
that's a real successful business strategy.

Keith

---

From: Chris Engel <[email-masked]>
Date: Wed, 4 Nov 2009 14:00:45 -0500

--------------------------------------------------------------------------------------------
"Wrong.  End users and board members typically don't understand what NATs are, nor their effects on the network's ability to support applications.  If they want to run an app that doesn't work on your network, they blame the app, even though the NATs in your network are what is screwing up the app.

Furthermore, end users and board members don't understand the degree to which the widespread deployment of NATs is artificially raising the cost of deploying new apps, and denying them useful new apps which might help employees in their work and help their company's competitiveness.

Again, in IPv4, it's pretty much a moot point because address scarcity trumps everything else.  But that's not the case for IPv6."
--------------------------------------------------------------------------------------------

Correct, but what they DO understand is whether they are satisfied with the services delivered to them or not...... whether their NEEDS are being met......and whether the budget they pay for those services equals the VALUE provided by them.

At the end of the day.... is that not the proof of any given approach?

If you really believe that stuff you said about NAT, then you pretty much don't need to be afraid of NAT in IPv6. If what you say happens to be true then those of us who choose to deploy it will be placing ourselves and our companies at a competitive disadvantage....and we'll either "see the light" and adapt/convert.... or we'll go the way of the dinosaurs.

Might the reality just happen to be that for a large portion of the community NAT provides significantly more utility then any of these hypothetical new apps that it is supposedly retarding?

I mean you DO realize that even in the IPv4 world there are organizations that hold sufficient address space that they COULD assign every single device a Public Address and they STILL choose to utilize private address space and deploy NAT? That actually holds true for my company in one of it's environments.

Furthermore, you seem to have a very poor understanding of how corporate environments actually work. If the end user wants to run an app and it isn't working they don't "blame the app". What they do is goto corporate IT and say "I'd like to run X, it's not working. Can you fix it for me please." It's upto corporate IT to take it from there.

Furthermore, in corporate environments things don't normally even get to the stage where NAT is breaking an end user application. That's because end users don't generally go out and grab their own apps and start working with them on their own in such environments. If that's happening to a significant degree in a corporate environment... then it's got alot more serious problems than whether NAT is breaking anything.

The way things typically go down in a corporate environment is...

 1) End user has a need. They put a request through channels till it gets to Corporate IT. The request reads something like "We have business need X. Here are the requirements. Find us a solution."  In rare cases the end user might even suggest or indicate a preference for a particular application...but usually not.

2) Corporate IT takes the request, makes sure that they have all the requirements they need from the end user. They then start researching a solution. They check this solution against...

                   - Company Security and Technology policies.
                   - Legal/Regulatory/Licensing considerations.
                   - Technology Standards, Compatibility & Interoperability
                   - Resource Allocation
                   - Budget (depending on who's budget it is being billed against)

3) Corporate IT comes up with a suggested solution. They pass it back to the business owner of the request to see if it meets their requirements.

4) Corporate IT tests the solution so they fully understand how to implement and support it. Depending on what happens here we may go back to Step #2.

5) Corporate IT sets up a user acceptance test to ensure the solution is acceptable to the business owner.

6) Corporate IT comes up with an implementation plan and everyone involved signs off.

7) Solution is implemented and available to end users.

ANY application that has a significant impact on the organization is likely to go through such a process. If it's a fairly trivial app and a trivial need then those steps may be fairly informal/abbreviated but even still some sort of iteration of it occurs.

NOTE by the time #7 rolls around and an end user has an application in their hands it's generally very well understood whether NAT is likely to be breaking it.

Christopher Engel

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Wednesday, November 04, 2009 12:38 PM
To: Chris Engel
Cc: 'Mark Andrews'; [email-masked]
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Chris Engel wrote:

Wrong.  End users and board members typically don't understand what NATs are, nor their effects on the network's ability to support applications.  If they want to run an app that doesn't work on your network, they blame the app, even though the NATs in your network are what is screwing up the app.

Furthermore, end users and board members don't understand the degree to which the widespread deployment of NATs is artificially raising the cost of deploying new apps, and denying them useful new apps which might help employees in their work and help their company's competitiveness.

Again, in IPv4, it's pretty much a moot point because address scarcity trumps everything else.  But that's not the case for IPv6.

Did you ask for internet telephony to work?  Multi-party conferencing?  Network management?

What you fail to realize is that NAT affects every single application currently used in the Internet.  Many of them can continue to mostly work, with reduced reliability, logging the wrong IP addresses, and various other operational anomalies that users might not understand (and you might not understand either).  But lots of apps get changed in one way or another to deal with NAT.

Since you're obviously in (deliberate) denial about those costs, it's clear you aren't in a position to estimate them.

and shrink their markets (at least in IPv4) to essentially zero.  Yeah, that's a real successful business strategy.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 04 Nov 2009 14:39:32 -0500

no, they do not understand these things.  they only naively believe that
they understand these things.
> At the end of the day.... is that not the proof of any given approach?
no.
> If you really believe that stuff you said about NAT, then you pretty much don't need to be afraid of NAT in IPv6. If what you say happens to be true then those of us who choose to deploy it will be…
that's only true if few enough people deploy NAT in IPv6.  if NAT turns
out to be rare, application developers who don't worry about it won't
suffer much, and the nets that use NAT will be marginalized.  OTOH, if
NAT turns out to be common, applications developers will have to deal
with it, resulting in increased costs and a higher bar for new apps -
even for users of networks that don't use NAT. 
> Might the reality just happen to be that for a large portion of the community NAT provides significantly more utility then any of these hypothetical new apps that it is supposedly retarding?
no.  the utility for NAT in IPv6 is extremely marginal, and the effect
of imposing NAT is huge.
> I mean you DO realize that even in the IPv4 world there are organizations that hold sufficient address space that they COULD assign every single device a Public Address and they STILL choose to uti…
there are very few such organizations.  and the fact that a few of them
choose to use NAT even though it is of no benefit to them should not be
taken as evidence of wisdom on the part of those organizations.

I mean, it was once widely believed that cigarettes and large (by
today's standards) doses of X-rays were beneficial to one's health.  
Just because many people today believe NAT is a good thing doesn't make
it so.

Keith

---

From: Chris Engel <[email-masked]>
Date: Wed, 4 Nov 2009 15:49:11 -0500

Ok,

I must admit... you've got me rather flummoxed here Keith. Your claiming that neither Network Admins, Business Owners nor End Users understand their OWN needs, priorities and costs very well?? That none of these entities are capable of understanding whether they are truly satisfied with the services they receive and judging whether they get VALUE for their investment in them??

If that is the case, then who, would you venture, is in a better position to understand such things???

Who, would you propose, should be in the position to make DECISIONS for such entities about the course of technologies they should seek to pursue??

Are you further claiming that Darwin was wrong??? That the fittest will NOT prevail?

If the arguments against NAT are so compelling and NAT's utility under IPv6 so negligible then why would you be concerned that NAT will see significant adoption under IPv6?

Are you simply saying that the vast majority of people in a position to make such decisions are stupid (or "ill-informed" if you want to be more polite in phrasing) and will make dumb decisions. That in the free market-place of ideas...the bad ideas will win out?

Even if you are convinced that's the case... the question then becomes... "What should one do about it?"

I certainly don't see any lack of effort made here to convince people about the negatives of NAT... nor to provide them potential substitutes. That is what RFC4864 was all about, correct?

If after all that effort, there is still a risk that a significant number of individuals fail to be convinced (as I am) and would seek NAT under IPv6.  What would be the most prudent course of action?

If there is a significant risk that people will seek out and adopt NAT solutions under IPv6... wouldn't it make more sense to try to provide some guide-lines about HOW to implement it... in effect to try to "minimize the harm" that it will do?

I am not trying to pigeon hole you here...I'm just honestly having a tough time understanding your position outside of "NAT = BAD".

Christopher Engel

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Wednesday, November 04, 2009 2:40 PM
To: Chris Engel
Cc: 'Mark Andrews'; [email-masked]
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Chris Engel wrote:

no, they do not understand these things.  they only naively believe that they understand these things.

no.

that's only true if few enough people deploy NAT in IPv6.  if NAT turns out to be rare, application developers who don't worry about it won't suffer much, and the nets that use NAT will be marginalized.  OTOH, if NAT turns out to be common, applications developers will have to deal with it, resulting in increased costs and a higher bar for new apps - even for users of networks that don't use NAT.

no.  the utility for NAT in IPv6 is extremely marginal, and the effect of imposing NAT is huge.

there are very few such organizations.  and the fact that a few of them choose to use NAT even though it is of no benefit to them should not be taken as evidence of wisdom on the part of those organizations.

I mean, it was once widely believed that cigarettes and large (by today's standards) doses of X-rays were beneficial to one's health.   Just because many people today believe NAT is a good thing doesn't make it so.

Keith

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Nov 2009 09:04:00 +1100

In message <F55FF9C4FDB76643AE0CEC06D0F5CEB3048557BFED@Skyhawk>, Chris Engel wr
ites:
> ---------------------------------------------------------------------------=
> -----------------
> "Wrong.  End users and board members typically don't understand what NATs a=
> re, nor their effects on the network's ability to support applications.  If=
>  they want to run an app that doesn't work on your network, they blame the =
> app, even though the NATs in your network are what is screwing up the app.
> 
> Furthermore, end users and board members don't understand the degree to whi=
> ch the widespread deployment of NATs is artificially raising the cost of de=
> ploying new apps, and denying them useful new apps which might help employe=
> es in their work and help their company's competitiveness.
> 
> Again, in IPv4, it's pretty much a moot point because address scarcity trum=
> ps everything else.  But that's not the case for IPv6."
> ---------------------------------------------------------------------------=
> -----------------
> 
> Correct, but what they DO understand is whether they are satisfied with the=
>  services delivered to them or not...... whether their NEEDS are being met.=
> .....and whether the budget they pay for those services equals the VALUE pr=
> ovided by them.

You seem to confuse NEED with DESIRE or WANT.

With IPv4 people NEEDED NAT because there is not enough IP addresses
to give every machine one.

Mark

---

From: Keith Moore <[email-masked]>
Date: Thu, 05 Nov 2009 12:08:42 -0500

> I must admit... you've got me rather flummoxed here Keith. Your claiming that neither Network Admins, Business Owners nor End Users understand their OWN needs, priorities and costs very well?? That…
I think that most such people have a really difficult time understanding
things in sufficient detail to evaluate the true impact of a decision
like whether or not to use NAT in IPv6.

I also think that most people (not just admins and business owners and
end users) are very caught up in the past and the present and have a
difficult time adapting to changing conditions.   This is true in
general; understanding the implications of a change from IPv4 to mixed
IPv4-v6 to mostly IPv6 is just one example.  Of course, someone like a
CTO is supposed to be thinking of those things, but still, it's a rare
skill.
> Who, would you propose, should be in the position to make DECISIONS for such entities about the course of technologies they should seek to pursue??
Well, that's the problem.  It's very difficult for those decision makers
to have the technical depth and time required to understand how NATs
work, what the advantages and drawbacks are and how they affect their
networks' ability to support applications, and still have all of the
other kinds of knowledge and wisdom that they need to do their jobs. 
What they really need is to have good technical people advising them,
and to be able to trust those people.   But again, those technical
people need to have foresight.  Most network admins that I know are too
busy fighting fires to really have time to think much about the future
implications of technological changes.  And I think it's fairly natural
to resist change, even change that would benefit you, when you're
constantly fighting fires.
> Are you further claiming that Darwin was wrong??? That the fittest will NOT prevail?
In general, the fittest do not prevail.  Just look at politics.

Or to put it another way, being fittest to survive (e.g. be able to keep
a job) is not the same thing as being fittest to actually do that job. 
If you're in an environment where people resist change, telling people
that things need to change is not a career-enhancing move, even if
you're absolutely 100% right.   Even if the company will go bankrupt for
failure to heed your advice, you stand a better chance of getting
another job with another company if you don't piss off your co-workers
who want to maintain their states of denial.

Or one could argue that the fittest people for such jobs are those who
have both the technical insight to know what to do, as well as the
ability to manipulate other people into making them want something that
they would not otherwise want.  But it's rare for the same person to
have both sets of skills.
> Are you simply saying that the vast majority of people in a position to make such decisions are stupid (or "ill-informed" if you want to be more polite in phrasing) and will make dumb decisions. Th…
Bad ideas often do win out. 

I suspect that the Darwinian idea of survival of the fittest is probably
a bit misstated.  A new species, or a new brilliant idea, can be very
fragile.   Even if the species or idea is extremely well adapted to
thrive in the long run, in the short term it needs to enjoy very
favorable circumstances until it can attain critical mass.
> If after all that effort, there is still a risk that a significant number of individuals fail to be convinced (as I am) and would seek NAT under IPv6.  What would be the most prudent course of acti…
I wish I knew.  IETF pretty much constrains itself to just writing
RFCs.  But while RFCs can be quite influential, they're not usually read
by the people making the decisions.  Also, NATs have a lot of mindshare,
and most of the people who have invested in NATs in v4 can be expected
to resist the idea of doing without them in v6.
> If there is a significant risk that people will seek out and adopt NAT solutions under IPv6... wouldn't it make more sense to try to provide some guide-lines about HOW to implement it... in effect…
Well, that was the goal of my NAT-XC proposal... accept that, at the
very least, IPv4-v6 transition means that NATs are going to be with us
for awhile longer, and define a single interface that allows apps to
deal with NATs of many different stripes (v4-v6, v6-v4, v6-v6 and maybe
even v4-v4; stateless and stateful NATs, NATs with limited port ranges,
and so on), and also define reasonable behavior for those NATs.  And
really I think it makes sense to have the protocol deal with firewalls
also, so that you make explicit the tussle between firewalls and apps.
> I am not trying to pigeon hole you here...I'm just honestly having a tough time understanding your position outside of "NAT = BAD".
NAT = BAD is of course a simplification, an expression of the situation
with a precision of two or three significant digits.   But when you
start to explain the reasons why NATs are bad, and/or to delineate the
cases where NATs are justifiable and/or mostly harmless, people's eyes
tend to glaze over.   It's easier to stay in denial.

Keith