Subject: [nat66] Necessity for NAT remains in IPv6

From: Chris Engel <[email-masked]>
Date: Mon, 2 Nov 2009 14:15:11 -0500

Hello,

Forgive me if I am entering late into the discussion here...but I was referred to the IETF mailing lists by individuals from a discussion that was occurring in the ARIN mailing lists.

The NAT66 list in IETF seemed to me to be the most relevant place to raise my concerns. Please forgive me if this is not the proper venue to raise such issues...as this is my first participation with IETF mailing lists.

First, by way of introduction...I'm a Network Manager in charge of operations at a small ASP. My responsibilities include management of both the corporate network infrastructure and the  infrastructure of the environment where the application services my company provides to it's clients is hosted. As such, I find NAT an EXTREMELY useful tool under IPv4 and would expect it to remain so under IPv6. In fact, were some sort of NAT solution not available under IPv6, my company would likely eschew any implementation of IPv6 to whatever degree would be possible.

I do NOT feel that RFC 4864 adequately addresses the utility of NAT.... nor adequately provides a acceptable substitutes for it.

That NAT proves problematic for some (mainly peer to peer) applications is undeniable. However for many of the people who make widespread use of NAT that is also largely irrelevant. In fact, I might even hazard that NAT's tendency to break such application are actually seen as a side benefit of NAT by many of the administrators who utilize it... and not a determent. I'm sure that my standard base FW rule of DENY ALL IN, which is pretty standard fare at corporate network boundaries, would prove similarly problematic to most such applications.

The very fact that NAT abstracts the private network from the public and makes it difficult for external traffic to address or reach an internal device without a 1:1 mapping IS part of the utility that NAT offers. This may indeed prove problematic for certain applications... but in a way similar to a right-handed golf club proving problematic to a left-handed user. The answer to this is simple, like golf-clubs, not ALL technologies are equally suited to all circumstances.... however with a variety of technologies available individuals are able to make a CHOICE of using those which ARE well suited to their particular circumstances (just as with golf clubs)... which is why NAT should continue to be useful in an IPv6 environment.

In section 2.2.  of RFC 4864 "Simple Security Due to Tasteful Filter Implementation" the authors contend that NAT's utility for Security is not particularly compelling because it incomplete and can be bypassed through techniques such as Trojans.... and that filtering via a FW offers a more robust solution. Respectfully, it's difficult for me to fathom that anyone well versed in security would find these arguments compelling.

Those of us who have worked in security are well aware that there is no one "magic bullet" to address all security issues. It is well known that they key to providing robust security is a MULTI-LAYERED DEFENSE that utilizes multiple controls over multiple layers to reduce the chances that a SINGLE point of failure will result in a breach. Even under such a design we realize that such security is not bullet-proof, just makes it require greater resources to breach. Thus claiming that NAT is not a useful security tool because their are methods that can circumvent it is like claiming that firewalls are not useful either simply because they can't prevent an intruder from physically breaking into your server room and walking out with a hard drive. NAT (like filtering done by a firewall) is simply one useful control among the many that are employed to protect an environment.

Furthermore, I don't believe that anyone seriously suggests that NAT in itself is an adequate substitute for firewalls entirely. The utility of NAT lies in CONJUNCTION with the use of firewalls to do filtering and statefull inspection. NAT acts as a partial insurance policy against firewall misconfigurations. Security controls are designed and implemented by human beings...as such they are prone to flaw both in design and in implementation. It is realization of this axiom that allows those charged with security to be effective in the execution of their duties. In the lab is perfectly fine to say that a well configured set of firewall rules renders much of NAT's security functionality superfluous... in the real world, we realize and try to account for the fact that individuals can (and eventually are bound to) make mistakes configuring such rules. NAT adds partial protection against this reality.

Let me illustrate with a simple hypothetical example of NAT's utility in this area. Let us assume that an administrator had intended to block all HTTP traffic INBOUND (save for some static servers) and allow all OUTBOUND. In practice, this is a very common rule. It is trivially easy on many firewalls for said administrator to mistakenly open up the firewall to all INBOUND and OUTBOUND HTTP traffic instead. In practice, this is actually one of the more common (and potentially dangerous) misconfigurations that we see in the field. In the NAT scenario, the private network is still largely protected against such a failure. Most devices inside the firewall would have private addresses and not be statically mapped to any external IP.....thus INBOUND HTTP requests would have no way of addressing or reaching them to initiate communications. The only machines exposed under such a scenario would be those few devices that had static 1:1 NAT mappings. However, the entire reason to provide a device with a static 1:1 mapping is that one would be expecting some sort of INBOUND connectivity to it.... thus those machines are highly likely to be hardened against such traffic (at least far more so then the ENTIRETY of the infrastructure behind the FW would be). Without NAT in such a scenario and with all devices behind the FW provided with a public address (as would generally be presumed in IPv6). EVERY SINGLE DEVICE becomes publicly exposed to HTTP traffic.... all from one very simple and common mistake. Thus every device capable of responding to HTTP would have to be hardened (at all times) to the same degree that servers expected to recieve external traffic are. I hope this example serves to illustrate SOME of the utility of NAT from a security perspective.

Another very important utility of NAT that I did not see addressed at all in RFC 4864 is to abstract the internal hardware that provides a given external service from the connection information provided externally for that service. As an Application Service Provider this is a pretty darn important consideration. Let me illustrate what I mean. If I am providing a particular service that external users connect to on IP x.x.23.46:80 and I want to substitute either permanently or temporarily the internal hardware that provides said service.... with a 1:1 NAT mapping on the firewall ALL I need do is bring that new internal hardware up in parallel on it's own internal IP's and then when I am ready cycle the active connections to that IP on the firewall and change the NAT mappings to it. This affords me great utility as I am allowed precise control over the exact timing which this operation occurs and it can be implemented with very little time and effort. All my internal applications still correctly identify the internal hardware distinctly.... yet the entire operation is obfuscated from external users....nothing need change about their connection information....and they may not even realize that a change in the internal hardware providing the service has occurred. Going even a step further I can provide a related service on x.x.23.46:25 and use entirely separate internal hardware to provide it, and I can replace the hardware that provides said services independant of those on port 80. Yet to the external user...everything looks like it is provided from the same physical address. NAT allows this to be done simply, efficiently and with minimal effort. Other solutions would either not be possible at all...or would be far less efficient to enact.

These two examples provide just a few of the practical benefits of NAT. Benefits that would transcend issues specific to IPv4. I could go on with others, but this post is already lengthy enough. I hope it has served to illustrate what I believe to be the continuing importance of NAT to administrators...even in an IPv6 environment. I thank you for your attention....and hope this choice of venue was the appropriate one for raising these issues.

Christopher Engel

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Nov 2009 14:35:01 -0500

I always find it amusing when a network administrator effectively says
"I want to be able to use NAT to cripple my network so that valuable
applications cannot run on it".  The fact is that NAT is not a useful
discriminator between valuable and harmful applications.  Whether NAT
breaks an application has nothing to do with the legitimacy or utility
of that application.

In my experience, NAT is detrimental to security because it makes it
much more difficult to trace security breaches.

In the example you cite where the NAT provides an "insurance policy"
backup to a misconfigured firewall, another way to look at what's
happening is that the NAT is masking the fact that the firewall is
misconfigured -- and perhaps, permitting breaches that would not be
permitted were the firewall properly configured.

I agree that that NAT can be useful to an ASP in managing the mapping
between external address and internal hardware.  I see this as a corner
case rather than an argument for the general utility of NAT.

And in general, if you are running a special-purpose network whose only
purpose is to provide a very small and well-identified, specific set of
services, NAT might work just fine for you.  But most networks aren't
like that.  The whole idea of IP is to allow a network to support a
broad range of services, and NATs are detrimental to that in almost
every way.

Keith

---

From: Chris Engel <[email-masked]>
Date: Mon, 2 Nov 2009 15:59:17 -0500

Keith,

Whether NAT is a useful discriminator or NOT is rather irrelevant (though I happen to find it a useful one).... the point is the Network Administrator and company security policy IS a useful security discriminator in determining what applications are valuable or not...and THEY can determine whether the benefits of NAT outweigh the costs. NO ONE is arguing that NAT is a useful tool for EVERY network. I'm glad that there will be more alternatives available under IPv6 for people to use. However, that does NOT mean that for many of the people who currently use it that NAT is not currently useful and would not be so in future regardless of the other options available. Just because person X in thier situation finds a particular tool more harmful then helpful is NOT a good arguement for denying the tools use to EVERYONE. Let the people who find the tool useful CHOOSE to use it (and live with the consequences of that choice) and those who don't, don't.

Furthermore, it's definitely NOT special-purpose networks that look to tightly limit the services that traverse the network boundary. That's a pretty significant goal in pretty much all corporate security. My company deals with ALOT of Fortune 1000 clients and almost every one which has had a security review as part of their vendor qualification process MANDATES NAT... not just in the ASP hosting environment...but even in the corporate networks of the vendors they deal with. Most of them even write it into their contracts as a specific contractual obligation of their vendor. If that is not enough, I simply refer you to PCI DSS v1.2.

On most corporate networks I've seen...the recommended security standard has become not just DENY ALL IN but DENY ALL OUT and then poke open holes AS REQUIRED.

You're other argument doesn't make much sense to me. Yes, NAT protecting the private network from exposure may indeed "mask" the fact that the FW rules have been misconfigured.... in that sense it is doing it's job as a compensating control. I'm pretty sure that almost any network admin is going to be happier discovering that flaw in a routine audit of their FW config rather then discovering it because of an ACTUAL breach....I'm almost certain the business owners who's assets are being protected would be. That's the whole point of compensating controls.

Note, when I'm speaking here...I'm really addressing the utility of NAT from the perspective of employing it at the edge of private networks....particularly corporate enterprise or non-profit organization networks. You might label these as "special-purpose" networks...but I really wouldn't. In these instances, the end users do NOT rightfully have the expectation to run any old application they may choose or want and have it work. They are specifically utilizing assets (including the computers they happen to be sitting at) that are NOT owned or controlled by them.... and they are doing so in the capacity as paid representatives of the organization whose assets they are utilizing. Under such circumstances it IS incumbent upon them to use only such applications that are provided and authorized for them by the (tightly controlled) company technology policy.... and if they DO have a need which is not currently being met...the appropriate thing for them to do is to bring it up with the organizations IT department and let the responsible managers there weigh the costs and benefits of various tools and come up with a solution.

That's pretty much how things are SUPPOSED to work in the corporate IT world. As has been pointed out to me by some-one.... the issue is far more problematic if your dealing with something like an ISP which is supposed to be providing general purpose connectivity to it's consumers. Under those circumstances, the use of NAT would be far more problematic.... but that is a very different scenario then the one I am describing.

Christopher Engel

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Monday, November 02, 2009 2:35 PM
To: Chris Engel
Cc: [email-masked]'
Subject: Re: [nat66] Necessity for NAT remains in IPv6

I always find it amusing when a network administrator effectively says "I want to be able to use NAT to cripple my network so that valuable applications cannot run on it".  The fact is that NAT is not a useful discriminator between valuable and harmful applications.  Whether NAT breaks an application has nothing to do with the legitimacy or utility of that application.

In my experience, NAT is detrimental to security because it makes it much more difficult to trace security breaches.

In the example you cite where the NAT provides an "insurance policy" backup to a misconfigured firewall, another way to look at what's happening is that the NAT is masking the fact that the firewall is misconfigured -- and perhaps, permitting breaches that would not be permitted were the firewall properly configured.

I agree that that NAT can be useful to an ASP in managing the mapping between external address and internal hardware.  I see this as a corner case rather than an argument for the general utility of NAT.

And in general, if you are running a special-purpose network whose only purpose is to provide a very small and well-identified, specific set of services, NAT might work just fine for you.  But most networks aren't like that.  The whole idea of IP is to allow a network to support a broad range of services, and NATs are detrimental to that in almost every way.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 02 Nov 2009 17:01:23 -0500

Chris Engel wrote:
> Keith,
>
> Whether NAT is a useful discriminator or NOT is rather irrelevant (though I happen to find it a useful one).... the point is the Network Administrator and company security policy IS a useful security discriminator in determining what applications are valuable or not...and THEY can determine whether the benefits of NAT outweigh the costs.
Actually, I disagree.  In my experience (at least for networks that
serve a significantly sized population of users) such people are usually
quite ignorant of both the diversity of needs of their users, and the
true impact of NAT on their networks in terms of the range of the
applications that NATs deny to users; and are therefore unable to make a
realistic estimate of the costs.  Of course, it's not unusual for a
network administrator to view applications as thorns in his side, and to
try to reduce the number of applications available to users.
>  NO ONE is arguing that NAT is a useful tool for EVERY network. I'm glad that there will be more alternatives available under IPv6 for people to use. However, that does NOT mean that for many of the people who currently use it that NAT is not currently useful and would not be so in future regardless of the other options available. Just because person X in thier situation finds a particular tool more harmful then helpful is NOT a good arguement for denying the tools use to EVERYONE. 
The same could be said of applications whose functions are impaired by
NAT.  e.g. Just because a network administrator thinks that such
applications are more harmful than helpful is NOT a good reason for
denying the use of those applications to EVERYONE on that network.

Perhaps unfortunately, nobody has figured out a way to prevent NATs from
being used in IPv6.  But the ONLY significant benefit of NAT in the IPv4
world is associated with their use to conserve precious address space,
and even that comes with significant pain.  The other benefits are
corner cases that apply only to very specific situations.
> Let the people who find the tool useful CHOOSE to use it (and live with the consequences of that choice) and those who don't, don't.
The problem is, the people who are choosing to install NATs are not the
ones dealing with the consequences of that choice. 
> Furthermore, it's definitely NOT special-purpose networks that look to tightly limit the services that traverse the network boundary. That's a pretty significant goal in pretty much all corporate security. My company deals with ALOT of Fortune 1000 clients and almost every one which has had a security review as part of their vendor qualification process MANDATES NAT... not just in the ASP hosting environment...but even in the corporate networks of the vendors they deal with. 
Most of those Fortune 1000 companies use Windows too...which doesn't say
much for their sense of security. 
> On most corporate networks I've seen...the recommended security standard has become not just DENY ALL IN but DENY ALL OUT and then poke open holes AS REQUIRED.
You certainly don't need NAT to do that.
> You're other argument doesn't make much sense to me. Yes, NAT protecting the private network from exposure may indeed "mask" the fact that the FW rules have been misconfigured.... in that sense it…
If you want a layered defense (which I agree is a good thing), it makes
far more sense to have multiple layers of firewall (as well as intrusion
detection and active probing) than to trust a NAT to "do the right
thing" when you have a configuration error.
> Note, when I'm speaking here...I'm really addressing the utility of NAT from the perspective of employing it at the edge of private networks....particularly corporate enterprise or non-profit organization networks. You might label these as "special-purpose" networks...but I really wouldn't.
Nor I.
>  In these instances, the end users do NOT rightfully have the expectation to run any old application they may choose or want and have it work. They are specifically utilizing assets (including the computers they happen to be sitting at) that are NOT owned or controlled by them.... and they are doing so in the capacity as paid representatives of the organization whose assets they are utilizing. 
I'm not talking about the "rights" of end users in such situations, but
rather, their ability to use the best applications available in order to
get their work done. 

Yes, a company can, if it wishes, dictate precisely which applications a
user may or may not use on the company's network or equipment; and yes,
the company can attempt to enforce those restrictions by placing
impediments in the network.  Of course, they do that at the peril of
harming their company's ability to compete in the marketplace.  But it's
their choice.

But given that it chooses to limit the apps that can be used on its
network, why in the world should it employ NAT to do that when there are
far better tools for the job?  Or to put it another way, why should it
cripple its networks a priori so that it becomes more difficult to
support new applications even when their utility becomes apparent?

Keith

---

From: Chris Engel <[email-masked]>
Date: Mon, 2 Nov 2009 18:25:53 -0500

Keith,

The idea that Network Administrators and Corporate IT are some-how less qualified to weigh the cost/benefits of choosing to use NAT vs specific applications then their end users are is a strange notion to say the least. As is the idea that they don't have to deal with the consequences of those decisions.

Most end-users on corporate networks have no grounding, qualification or knowledge to make informed technical decisions about the applications they use let alone about the costs and benefits of deploying technologies such as NAT. Most end users haven't even HEARD of NAT...if I mentioned the word to them they would assume I was talking about an insect (and mis-spelling it). By saying this I'm not denigrating those end users either.... They shouldn't HAVE to understand the implications of such technologies.... they have their own fields and specialties which they are experts in. That's what they get paid for.... what WE get paid for is understanding the implications of things like NAT and of the unseen costs associated with certain applications and technologies.

Even if the end users did understand those implications....they would be doing so through the lens of their own narrow self-interest. Jane really isn't going to be too concerned if her choice of technology interferes with what Joe is doing... as long as her needs are met.

As Network Admins in Corporate IT it's OUR job to make sure that corporate network is functioning smoothly as a WHOLE for EVERYONE. It's our job to make sure that our companies technology goals as a whole are being met and to balance those goals against the needs and desires and priorities of individual end users.... most of whom may not even be fully aware of those technology goals. At the end of the day, if we're not meeting those responsibilities well then WE'RE the ones that are going to be getting pink slips.... not the receptionist that wants to run lime-wire because she thinks "it's cool".

Whether or not to run NAT is a choice for individual administrators 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.
Even in cases where there is some application that might prove useful...usually work around can be found... and in those cases it's upto the Network Admins to make cost/benefit decisions about whether it makes more sense to find a work around for that Application...or find a work around for the benefits he perceives NAT provides. Furthermore, even if we choose NAT today...there is nothing to say that if in future priorities change we can't revisit that decision. Ultimately these are the type of choices that Network Admins are paid to make.... and trust me, if we end up making poor ones we DO get held accountable for them.

NAT is simply one type of tool which is available in our toolbox. Thanks to the work people are doing with IPv6... there ARE alot more options available in that toolbox. That's a good thing. 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). It's like saying that because we have all these fancy power tools available today...we should all throw out our hammers when the hammer still works perfectly well for many jobs.

Christopher Engel

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Monday, November 02, 2009 5:01 PM
To: Chris Engel
Cc: [email-masked]'
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Chris Engel wrote:
> Keith,
>
> Whether NAT is a useful discriminator or NOT is rather irrelevant
> (though I happen to find it a useful one).... the point is the Network Administrator and company security policy IS a useful security discriminator in determining what applications are valuable or not...and THEY can determine whether the benefits of NAT outweigh the costs.
Actually, I disagree.  In my experience (at least for networks that serve a significantly sized population of users) such people are usually quite ignorant of both the diversity of needs of their users, and the true impact of NAT on their networks in terms of the range of the applications that NATs deny to users; and are therefore unable to make a realistic estimate of the costs.  Of course, it's not unusual for a network administrator to view applications as thorns in his side, and to try to reduce the number of applications available to users.
>  NO ONE is arguing that NAT is a useful tool for EVERY network. I'm
> glad that there will be more alternatives available under IPv6 for people to use. However, that does NOT mean that for many of the people who currently use it that NAT is not currently useful and would not be so in future regardless of the other options available. Just because person X in thier situation finds a particular tool more harmful then helpful is NOT a good arguement for denying the tools use to EVERYONE.
The same could be said of applications whose functions are impaired by NAT.  e.g. Just because a network administrator thinks that such applications are more harmful than helpful is NOT a good reason for denying the use of those applications to EVERYONE on that network.

Perhaps unfortunately, nobody has figured out a way to prevent NATs from being used in IPv6.  But the ONLY significant benefit of NAT in the IPv4 world is associated with their use to conserve precious address space, and even that comes with significant pain.  The other benefits are corner cases that apply only to very specific situations.
> Let the people who find the tool useful CHOOSE to use it (and live
> with the consequences of that choice) and those who don't, don't.
The problem is, the people who are choosing to install NATs are not the ones dealing with the consequences of that choice.
> Furthermore, it's definitely NOT special-purpose networks that look to
> tightly limit the services that traverse the network boundary. That's a pretty significant goal in pretty much all corporate security. My company deals with ALOT of Fortune 1000 clients and almost every one which has had a security review as part of their vendor qualification process MANDATES NAT... not just in the ASP hosting environment...but even in the corporate networks of the vendors they deal with.
Most of those Fortune 1000 companies use Windows too...which doesn't say much for their sense of security.
> On most corporate networks I've seen...the recommended security
> standard has become not just DENY ALL IN but DENY ALL OUT and then poke open holes AS REQUIRED.
> You're other argument doesn't make much sense to me. Yes, NAT
> protecting the private network from exposure may indeed "mask" the fact that the FW rules have been misconfigured.... in that sense it is doing it's job as a compensating control. I'm pretty sure that almost any network admin is going to be happier discovering that flaw in a routine audit of their FW config rather then discovering it because of an ACTUAL breach....I'm almost certain the business owners who's assets are being protected would be. That's the whole point of compensating controls.
If you want a layered defense (which I agree is a good thing), it makes far more sense to have multiple layers of firewall (as well as intrusion detection and active probing) than to trust a NAT to "do the right thing" when you have a configuration error.
> Note, when I'm speaking here...I'm really addressing the utility of
> NAT from the perspective of employing it at the edge of private networks....particularly corporate enterprise or non-profit organization networks. You might label these as "special-purpose" networks...but I really wouldn't.
Nor I.
>  In these instances, the end users do NOT rightfully have the
> expectation to run any old application they may choose or want and have it work. They are specifically utilizing assets (including the computers they happen to be sitting at) that are NOT owned or controlled by them.... and they are doing so in the capacity as paid representatives of the organization whose assets they are utilizing.
I'm not talking about the "rights" of end users in such situations, but rather, their ability to use the best applications available in order to get their work done.

Yes, a company can, if it wishes, dictate precisely which applications a user may or may not use on the company's network or equipment; and yes, the company can attempt to enforce those restrictions by placing impediments in the network.  Of course, they do that at the peril of harming their company's ability to compete in the marketplace.  But it's their choice.

But given that it chooses to limit the apps that can be used on its network, why in the world should it employ NAT to do that when there are far better tools for the job?  Or to put it another way, why should it cripple its networks a priori so that it becomes more difficult to support new applications even when their utility becomes apparent?

Keith

---

From: james woodyatt <[email-masked]>
Date: Mon, 2 Nov 2009 15:54:40 -0800

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-masked]>
member of technical staff, communications engineering

---

From: Mark Andrews <[email-masked]>
Date: Tue, 03 Nov 2009 11:00:37 +1100

In message <F55FF9C4FDB76643AE0CEC06D0F5CEB3048557BFE1@Skyhawk>, Chris Engel wr
ites:
> Keith,
> 
> The idea that Network Administrators and Corporate IT are some-how less quali
> fied to weigh the cost/benefits of choosing to use NAT vs specific applicatio
> ns then their end users are is a strange notion to say the least. As is the i
> dea that they don't have to deal with the consequences of those decisions.

Chris, its not just the network that uses a NAT that pays for the
cost of the NAT.  Every network user pays for the cost of NAT in
higher products costs incured from needing to provide products that
will work in the presence of NAT even if that don't actually use a
NAT or not.

People are anti NAT because this is a unnecessary cost that pro NAT
people are imposing on everyone else.  It an added complication
that is not needed.

NAT44 was a necessary evil as we had effectively run out IPv4 addresses.

Mark

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

---

From: Roland Bless <[email-masked]>
Date: Tue, 03 Nov 2009 01:09:06 +0100

Hi Chris,

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. Even in cases where there is

Sounds that you mainly think of unwanted P2P apps.
The main problem is that NAT is an obstacle also for future transport
protocols (e.g., DCCP, SCTP, and subsequent ones) and that you are
stuck with whatever transport protocols the NAT supports. The only
possibility to let future apps run smoothly is usually to buy in
solutions like STUN/TURN that require additional components, making the
whole architecture more complex. So to let arbitrary apps run you need
NAT + STUN/TURN servers/relays and the control protocols (plus discovery
delay etc.). That's IMHO much more complexity and requires more
components in the e2e path that may fail or cause problems.

> some application that might prove useful...usually work around can be
> found... and in those cases it's upto the Network Admins to make
> cost/benefit decisions about whether it makes more sense to find a
> work around for that Application...or find a work around for the

it's a question whether you want to make such "work arounds" part of
the overall architecture. I don't.

> benefits he perceives NAT provides. Furthermore, even if we choose
> NAT today...there is nothing to say that if in future priorities
> change we can't revisit that decision. Ultimately these are the type

That's why we easily get rid off v4 NATs today... :-)

> of choices that Network Admins are paid to make.... and trust me, if
> we end up making poor ones we DO get held accountable for them.

I think that NAT may have advantages, but there are other ways
of achieving such goals. As Keith already said: NATs primary
purpose is to limit address consumption. Probably other desired side
effects are not covered too well in RFC4864 and several people
want to see an update of it. But the cost of
introducing NAT66 is the exclusion of future apps and protocols
or the permanent buy-in of NAT traversal work arounds.

> NAT is simply one type of tool which is available in our toolbox.
> Thanks to the work people are doing with IPv6... there ARE alot more
> options available in that toolbox. That's a good thing. 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). It's like saying that

If you consider the above costs, I don't think that its the right
tool, especially NOT for security as already documented many times.

> because we have all these fancy power tools available today...we
> should all throw out our hammers when the hammer still works
> perfectly well for many jobs.

...and perfectly breaks so many things. NAT66 may break less things
than NATv4, but it still may break future transports and apps.

Regards,
 Roland

---

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

John Payne wrote:
>
> On Nov 2, 2009, at 5:01 PM, Keith Moore wrote:
>
>> Chris Engel wrote:
>>> Keith,
>>>
>>> (though I happen to find it a useful one).... the point is the
>>> Network Administrator and company security policy IS a useful
>>> security discriminator in determining what applications are valuable
>>> or not...and THEY can determine whether the benefits of NAT outweigh
>>> the costs.
>> serve a significantly sized population of users) such people are
>> usually quite ignorant of both the diversity of needs of their users,
>> and the true impact of NAT on their networks in terms of the range of
>> the applications that NATs deny to users; and are therefore unable to
>> make a realistic estimate of the costs.
>
> And the business has made a business decision to act that way, and I
> strongly do not believe it's your job to decide that it's a dangerous
> tool and take it away from them.
Nobody's talking about taking anything away from anybody.  We don't have
any mechanism by which to do that.

But at the same time, just because a bunch of network administrators
have made decisions that are extremely detrimental to the ability of
networks (and not just their networks) to support applications, does not
mean that IETF should pretend that what they're doing is not a problem. 
IETF's job is to make sound technical recommendations, not to reinforce
other people's preconceptions.
>>> glad that there will be more alternatives available under IPv6 for
>>> people to use. However, that does NOT mean that for many of the
>>> people who currently use it that NAT is not currently useful and
>>> would not be so in future regardless of the other options available.
>>> Just because person X in thier situation finds a particular tool
>>> more harmful then helpful is NOT a good arguement for denying the
>>> tools use to EVERYONE.
> Actually, yes it is.  If the network administrator has decided that
> something shouldn't be on the network, there is _NO_ better reason for
You appear to be talking about authority.  I'm talking about wisdom. 
>>
>> Perhaps unfortunately, nobody has figured out a way to prevent NATs
>> from being used in IPv6.  But the ONLY significant benefit of NAT in
>> the IPv4 world is associated with their use to conserve precious
>> address space, and even that comes with significant pain.  The other
>> benefits are corner cases that apply only to very specific situations.
>
> Cite?
> I think it was Brian Carpenter who mentioned the use of NAT for
> enterprise multihoming (dozens of interconnects to the public
> Internet).  That is a HUGE benefit.... and one that I believe also has
> security implications - by "allowing" or "blessing" NAT at the
> enterprise exit points, the internal filters become much simpler,
> rather than having to track dozens or hundreds of prefixes in the
> internal network, one can use one prefix internally and NAT out the
> local Internet exit point, without having to size each and every one
> of those to support the entire enterprise.
Mumble.  This is a very complex topic.  IPv4 and IPv6 are different
enough in this respect that they need to be analyzed separately.   In
the IPv4 world, very few large organizations have enough IPv4 address
space to give a unique global address to each of their hosts.   So it's
easy for them to say "heck, we already have to use NAT because of
address scarcity, we've already bought into this approach and accepted
the collateral damage.  We might as well use it for this too." 

Also, I've never thought that having IPv6 networks advertise a separate
prefix for each exit point made good sense.  It might work well enough
for a network having only two or three exit points, all of which are
equally capable, but it doesn't scale.  My take is that the IPv6
designers were so intent on solving the routing scaling problem that,
probably without realizing it, they created several other problems for
other aspects of the network that were no easier to solve.  I haven't
followed recent work in the area of IPv6 multihoming, so I don't know
the current state of thinking there.  But I hope that they solve the
problem in a way that doesn't confuse applications.  Or at least, that
they give applications a good way to not be confused.
>> The problem is, the people who are choosing to install NATs are not
>> the ones dealing with the consequences of that choice.
>
> In the enterprise world, they absolutely are.   I really don't care
> what application of yours I break on my network.  Sorry.
So why should application developers, or your users, care if they
circumvent your network's security?  I mean, they have to get work done
in spite of your network administrators.

It bears repeating: the result of putting NATs into the network is that
applications need to be more complex in order to cope with the
enviroments in which they're expected to function.  They also tend to
need explicit infrastructure (e.g. servers in the network core to do
rendezvous or relay) which they might not otherwise need.  What this
means is that applications are more expensive and more fragile than they
would otherwise be, and this in turn limits the availability of
applications to users.  It also increases the expense of managing
networks, if for no other reason than the support costs.  Network admins
arguing for their "right" to install NATs are missing the point.  What
they're arguing for is the right to make their networks less flexible
and less able to support users' needs for reasons that have nothing to
do with policy.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 3 Nov 2009 10:58:17 -0500

Hi Chris,

On Nov 2, 2009, at 2:15 PM, Chris Engel wrote:
>
> Forgive me if I am entering late into the discussion here...but I  
> was referred to the IETF mailing lists by individuals from a  
> discussion that was occurring in the ARIN mailing lists.

It is never too late to state your opinion, especially when it agrees  
so closely with mine!  :-)

If this discussion occurred on a public ARIN mailing list, could you  
send me a pointer?  I'd be interested in what else was said about the  
need for NATs in IPv6.

> The NAT66 list in IETF seemed to me to be the most relevant place to  
> raise my concerns. Please forgive me if this is not the proper venue  
> to raise such issues...as this is my first participation with IETF  
> mailing lists.

This is a fine place to state your opinion about the need for NAT in  
IPv6, as that is the primary subject of this group.

However, I don't want there to be any confusion about the status of  
the NAT66 work...  At this point, the Transport and Internet Area  
Directors have rejected the NAT66 document, and have suggested that  
Fred Baker (my co-author) and I publish it as an independent  
submission.  So, unless something changes, it is highly unlikely that  
this work will be pursued in the IETF.  I am very disappointed about  
that, because I believe that an IETF NAT66 document could have made a  
positive difference in how NAT's are implemented for IPv6, but we've  
not been successful in convincing the Internet or Transport ADs, and  
their support is needed to present or propose any work in the IETF.

> First, by way of introduction...I'm a Network Manager in charge of  
> operations at a small ASP. My responsibilities include management of  
> both the corporate network infrastructure and the  infrastructure of  
> the environment where the application services my company provides  
> to it's clients is hosted. As such, I find NAT an EXTREMELY useful  
> tool under IPv4 and would expect it to remain so under IPv6. In  
> fact, were some sort of NAT solution not available under IPv6, my  
> company would likely eschew any implementation of IPv6 to whatever  
> degree would be possible.

As one of the authors of NAT66, I agree with much of what you are  
saying below.

Have you read the NAT66 draft that describes how to build an IPv6 NAT  
box using 1:1 address mapping and no port mapping?  Would the type of  
NAT described in that document meet your needs for an IPv6 NAT?  We're  
working on an update to allow NAT66 to work on networks with a prefix  
longer than /48, but the current version is here:

https://datatracker.ietf.org/drafts/draft-mrw-behave-nat66/

As an enterprise network administrator, you would be a great example  
of a "customer" for a NAT66 device, so we would be very interested in  
your feedback on how the device we've described would/wouldn't meet  
your needs.

> I do NOT feel that RFC 4864 adequately addresses the utility of  
> NAT.... nor adequately provides a acceptable substitutes for it.
[...]

I think that your analysis of the limitations of RFC 4864 is right  
on.  That document is a work product of the IPv6 Operations (v6ops)  
WG, so if you would like to propose an update to RFC 4864, you would  
probably do best to do that in the v6ops WG ([email-masked]).

Welcome to the IETF!  Please don't be put off by the responses you've  
received so far.  Not everyone in the IETF is as much of an  
architectural purist as Keith or James...  In fact, we have a lot of  
diversity of opinion in the IETF, with lots of lively debate, and that  
is one of our strengths.  While it may not always sound like it, we do  
want and need input from enterprise administrators to develop  
protocols that are useful in real-world environments.

Margaret

---

From: Chris Engel <[email-masked]>
Date: Tue, 3 Nov 2009 11:45:43 -0500

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-masked]]
Sent: Monday, November 02, 2009 6:55 PM
To: Chris Engel
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6

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

--

---

From: Keith Moore <[email-masked]>
Date: Tue, 03 Nov 2009 12:01:12 -0500

>           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 ign…
I haven't followed this much recently, but my impression has been for
several years (at least a decade) that IETF has a very strange attitude
about NAT. 

On one hand it's been reluctant to be honest about how much harm NATs
cause - and I really mean that, the documents published to date are
still glossing over a number of problems. 

On the other hand, it's been reluctant to develop any solution to the
NAT problem that would raise the bar for NATs much at all.   The
assumption seems to be that we can't fix NATs, even in IPv6, so the
problems that NATs cause have to be solved elsewhere in the network, or
in applications. 

In other words, there's no attempt to resolve the tussle or even to make
it explicit in the architecture.  

Failure to resolve this conflict is, in effect, a decision to prolong
the tussle indefinitely - to continue the arms race between users and
applications devleopers on one hand and network administrators and
vendors of network equipment on the other - and to make IPv6 almost as
dysfunctional as IPv4. 

To me this is the worst of the alternatives available.  Either NATs in
IPv6 should be discouraged in the strongest possible terms, or they
should be required to implement an explicit, standardized mechanism to
allow applications (with appropriate credentials) to explicitly maintain
bindings and/or punch holes in them.  (the PnP and NAT-PMP are tiny
steps in the right direction, but need to be generalized and to support
authentication so that hosts and apps can be issued credentials to allow
them to do what they need).

Personally I've become convinced that NATs between IPv4 and IPv6 are
absolutely necessary for transition, that applications need to have
explicit control of the bindings in such NATs in order to reasonably
deal with them, and that the transition will last for a decade at
least.   Given that necessity, I think the more prudent course is to
standardize an API for NATs in general. 

I don't like this conclusion, as NATs are still a huge mess even if you
make them explicitly visible to applications and allow applications to
maintain bindings.  I'd love to be convinced otherwise.  But from where
I sit now, and after having looked at this problem for about 15 years,
to me that currently looks like the best course of action.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Tue, 3 Nov 2009 13:38:54 -0500

> Failure to resolve this conflict is, in effect, a decision to prolong
the tussle indefinitely - 
> to continue the arms race between users and applications devleopers on
one hand and network
> administrators and vendors of network equipment on the other - and to
make IPv6 almost as

> To me this is the worst of the alternatives available.  

It has been said that compromise is when all parties walk away from the
table unsatisfied.  If that's the metric for success, then we're doing
great!

- Wes

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Keith Moore
Sent: Tuesday, November 03, 2009 12:01 PM
To: Chris Engel
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Chris Engel wrote:
> 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.
I haven't followed this much recently, but my impression has been for
several years (at least a decade) that IETF has a very strange attitude
about NAT. 

_______________________________________________
nat66 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nat66

---

From: Chris Engel <[email-masked]>
Date: Tue, 3 Nov 2009 16:57:30 -0500

Mark,

I would guess in the same manner that every application developer that creates an application imposes an additional cost on the Network Admin (and their companies) to make sure that application doesn't breach their network perimeter without authorization.... or every person who chooses to use a different version of web browser imposes the cost of supporting that choice on the web-site operator...and on every other person that visits that site.

That's part of the reality of the internet. We all impose certain costs on each other for the connectivity that we share. However, people are different and one man's "unnecessary" is another mans "essential".

Ultimately though, it's upto the individual application developers to determine if they want to sink the costs of working with NAT into their application or not..... and it's upto individual consumers to determine whether they want to carry that cost or not.

If the anti-NAT folks don't want to deal with the costs of supporting it (indirectly) the solution is simple... don't buy applications that are designed to work with NAT... you won't be carrying any of the costs for it.

If there really is a significant enough number of people out there that don't find NAT useful... you should be able to convince plenty of application developers not to build support into their products for it. I'm sure that they would be happy not to have to deal with that hassle anyways, if they can get away with it.

Christopher Engel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, November 02, 2009 7:01 PM
To: Chris Engel
Cc: 'Keith Moore'; [email-masked]'
Subject: Re: [nat66] Necessity for NAT remains in IPv6

Chris Engel writes:
> Keith,
>
> The idea that Network Administrators and Corporate IT are some-how
> less quali fied to weigh the cost/benefits of choosing to use NAT vs
> specific applicatio ns then their end users are is a strange notion to
> say the least. As is the i dea that they don't have to deal with the
> consequences of those decisions.

Chris, its not just the network that uses a NAT that pays for the cost of the NAT.  Every network user pays for the cost of NAT in higher products costs incured from needing to provide products that will work in the presence of NAT even if that don't actually use a NAT or not.

People are anti NAT because this is a unnecessary cost that pro NAT people are imposing on everyone else.  It an added complication that is not needed.

Mark

--

Mark Andrews, ISC

---

From: Roland Bless <[email-masked]>
Date: Wed, 04 Nov 2009 00:19:06 +0100

Hi Keith,

> them to do what they need).

There's already work and running code in the IETF to do that: NAT/FW
NSLP was developed within the NSIS WG for exactly this purpose,
http://tools.ietf.org/html/draft-ietf-nsis-nslp-natfw-20
However, this 2nd option comes at the extra cost of such signaling.

> standardize an API for NATs in general. 

Maybe you could take a look at the NATFW draft: it's probably exactly
what you meant.

> maintain bindings.  I'd love to be convinced otherwise.  But from where

Yep.

> to me that currently looks like the best course of action.

The thing is that if we standardize NAT for v6 it will probably
just get deployed widely, because it's there and network admins got used
to it, as underlined by Chris' mail. Maybe NAT offers some benefits
in some scenarios, and it would be nice if it is only used as an
exception. However, restricting NAT use to only some exceptions will
probably not work. So providing alternative solutions along the lines of
RFC  4864 would be better.

Regards,
 Roland

---

From: james woodyatt <[email-masked]>
Date: Tue, 3 Nov 2009 17:43:53 -0800

On Nov 3, 2009, at 08:45, Chris Engel wrote:
>
>          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.

I certainly do not share any hope that IETF can-- by declining the  
opportunity, or refusing to discuss options, for publishing a  
specification for NAT66-- can somehow discourage operators from  
deploying it.  That certainly didn't work with IPv4, as I believe I  
can declare with some personal authority.  I'm crazy, but not nearly  
crazy enough to believe IPv6 will be any different.

As an aside, if I gather correctly from your previous messages, then  
you would find NAT66 an unacceptable solution because it's a symmetric  
address translator, and the specific scenario you described as one of  
your principle reasons for wanting IPv6/NAT requires an asymmetric  
address/port translator.

So, again-- I'm not sure I understand your basic concern.

---

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

James,

       It is true that I wouldn't find the NAT66 draft in it's current state acceptable to meet my current needs. However, just because it doesn't fully meet my needs doesn't mean it wouldn't offer significant utility over IPv6 without NAT.

The draft as written does provide a measure of abstraction between the private and public address space of an organization. It therefore does provide significant utility in a number of areas which would otherwise be lacking or more difficult to achieve without it. As I understand it, it also makes a significant effort to address some of the concerns raised under NAT44 and the problems it causes for certain applications/protocols. That it is not entirely sufficient for my needs does not mean that it wouldn't be sufficient for others who's priorities were somewhat different.

In that regards, I would have hoped it would have been considered. It's unfortunate that IETF is declining to move it forward. I am grateful that it's authors will be moving it forward independently and hope that it will at least reach the notice of some of the equipment vendors looking to implement NAT solutions under IPv6. Again, the more choices and options, the better.... and I believe it is useful to at least suggest some standards about how those options might be implemented.

Christopher Engel

-----Original Message-----
From: james woodyatt [mailto:[email-masked]]
Sent: Tuesday, November 03, 2009 8:44 PM
To: Chris Engel
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6

> make it less likely for it to be utilized.

I certainly do not share any hope that IETF can-- by declining the opportunity, or refusing to discuss options, for publishing a specification for NAT66-- can somehow discourage operators from deploying it.  That certainly didn't work with IPv4, as I believe I can declare with some personal authority.  I'm crazy, but not nearly crazy enough to believe IPv6 will be any different.

As an aside, if I gather correctly from your previous messages, then you would find NAT66 an unacceptable solution because it's a symmetric address translator, and the specific scenario you described as one of your principle reasons for wanting IPv6/NAT requires an asymmetric address/port translator.

--

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 07 Nov 2009 12:36:47 +1300

Sigh, I've been keeping my fingers off the keyboard, but a few
points in this thread really need clarification. Apologies
for prolonging the off-topic thread, I will shut up after this.

On 2009-11-03 08:15, Chris Engel wrote:
...
> First, by way of introduction...I'm a Network Manager in
> charge of operations at a small ASP. 

Hi. I used to be in charge of network operations at a large
site (cern.ch), then I spent 10 years in industry, and
now I'm an academic but working with our university's
IT operations people on IPv6 deployment. I was also the
instigator of and a contributor to RFC4864. So...

...
> I do NOT feel that RFC 4864 adequately addresses the utility
> of NAT.... nor adequately provides a acceptable substitutes
> for it.

We worked as hard as we could to make the list complete.Can you
identify exactly which benefits of NAT are not mentioned in
section 2 of the document?

...
> 
> In section 2.2.  of RFC 4864 "Simple Security Due to Tasteful
> Filter Implementation" the authors contend that NAT's utility
> for Security is not particularly compelling because it
> incomplete and can be bypassed through techniques such as
> Trojans.... and that filtering via a FW offers a more robust
> solution. Respectfully, it's difficult for me to fathom that
> anyone well versed in security would find these arguments
> compelling.

Well, how about any large site manager who runs a firewall
but no NAT? This is a very common scenario, although I agree
that many sites run boxes that are simultaneously NATs
and firewalls.

On 2009-11-04 15:14, Roger Marquis wrote:
...
> Given that somewhere over 90% of devices connected to the IPv4 Internet are
> NAT'd, allegations of "NAT harm" would seem to be like those funded by
> insurance interest against single payer i.e., without basis but repeated
> often in the hope that someone will believe them. 

The problem here is that NATs (especially the $99 kind
misleadingly described as ADSL routers) lose session state
and abort user sessions when they run out of resource. Then
the user sees a glitch or a timeout, or occasionally an
aborted credit card or banking transaction. But there is no
logging and no diagnosis. So we simply have no data about
how many hours of user time and help desk time are wasted
on NAT-induced glitches. If every domestic user ran Wireshark
continuously, and every glitch was carefully analysed, we'd
have data. But that isn't going to happen.

That's not to mention the performance and complexity cost
for applications that have to work around NATs, which
is a constant tax on everybody.

So we know that there is a large dollar cost here, but
we have no reasonable way to measure it. As far as the
IT managers and ISPs who choose to put users behind
NATs are concerned, it's an externality that they have
no interest in pricing. The problem with NATs is basically
one of economics: the incentives to NAT act on one group
(IT managers) and the costs of NAT lie on another group (users).

On 2009-11-04 15:19, Roger Marquis wrote:
> Mark Andrews wrote:
> This is false.  NAT was implemented long, long before there were widespread
> concerns regarding the number of addresses.  

Absolutely not. The concern about the number of address dates
back to about 1991, and was formally documented in November 1992
(RFC1380, section 2.1.3):

   There is considerable uncertainty regarding the timeframe
   when we might exceed the limits of the IP address space.
   However, the issue is serious enough that it deserves our
   earliest attention.  It is very important that we develop
   solutions to this potential problem well before we are in
   danger of actually running out of addresses.

IPv6 is the result of that paragraph.

But NAT (at least for IP) was first documented in 1994
(RFC1631).

> A larger reason for NAT was
> that many of us were using non-routable addresses, 

You were only using them because they were defined in 1994
(RFC1597), 2 months before NAT.

> as there was (and still
> is) no business case for any of our internal addresses to be publically
> routable.

Actually that is a side issue. I agree that it's a very
reasonable business argument. But whether you use ambiguous
(RFC1597/RFC1918) addresses, IPv6 ULAs, or globally unique
addresses is completely orthogonal to whether they are routed
on the public Internet. There are many cases of organisations
with globally unique addresses used internally that are not
routed externally. (The same goes for DNS names, although there
is quite a bit of allergy in the IETF to two-faced DNS.)

   Brian

---

From: Eric Klein <[email-masked]>
Date: Mon, 9 Nov 2009 14:27:21 +0200

Hi Chris

As one of the co-authors of RFC 4864 I would be interested if you could
itemize that you mean by:

On Tue, Nov 3, 2009 at 18:45, Chris Engel <[email-masked]> wrote:

> James,
>
>
>
> 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
>
> I agree that there will be demand, and that vendors will feed this demand
(in many cases may cause it), but unless there is a specific need not
addressed with a better, more scalable solution then it is still not clear
what you want NAT for.

> 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.
>
>
> Including what functionality? Be specific.

> 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.
>
> If you can point to specific places you would like updates it may be
considered.

Eric

<http://www.google.com/search?q=%0D%0A%0D%0A%20%20%20%20Christopher%20Engel%0D%0A%0D%0A%20%20%20%20%20>

---

From: Chris Engel <[email-masked]>
Date: Mon, 9 Nov 2009 10:11:01 -0500

On Friday, November 06, 2009 6:37 PM,  Brian E Carpenter wrote:

"We worked as hard as we could to make the list complete.Can you identify exactly which benefits of NAT are not mentioned in section 2 of the document?"

On Mon 11/9/2009 7:27 AM, Eric Klein wrote:

"As one of the co-authors of RFC 4864 I would be interested if you could itemize that you mean by:"

Eric & Brian, I was under the impression that I had done just that with my origional post to the list. Let me provide the relavent excerpt. It contains 2 very specific examples (there are more areas, but these 2 really stand out).

1) NAT allows a firewall to "fail closed" rather then "fail open" when there is a miscofiguration of rules.

2) NAT serves to abstract internal hardware that provides services from the external advertisement of those services. Making it very easy and flexible to distribute and redistribute the provision of those services among your internal hardware.

---------------------------------------
Let me illustrate with a simple hypothetical example of NAT's utility in this area. Let us assume that an administrator had intended to block all HTTP traffic INBOUND (save for some static servers) and allow all OUTBOUND. In practice, this is a very common rule. It is trivially easy on many firewalls for said administrator to mistakenly open up the firewall to all INBOUND and OUTBOUND HTTP traffic instead. In practice, this is actually one of the more common (and potentially dangerous) misconfigurations that we see in the field. In the NAT scenario, the private network is still largely protected against such a failure. Most devices inside the firewall would have private addresses and not be statically mapped to any external IP.....thus INBOUND HTTP requests would have no way of addressing or reaching them to initiate communications. The only machines exposed under such a scenario would be those few devices that had static 1:1 NAT mappings. However, the entire reason to provid  e a device with a static 1:1 mapping is that one would be expecting some sort of INBOUND connectivity to it.... thus those machines are highly likely to be hardened against such traffic (at least far more so then the ENTIRETY of the infrastructure behind the FW would be). Without NAT in such a scenario and with all devices behind the FW provided with a public address (as would generally be presumed in IPv6). EVERY SINGLE DEVICE becomes publicly exposed to HTTP traffic.... all from one very simple and common mistake. Thus every device capable of responding to HTTP would have to be hardened (at all times) to the same degree that servers expected to recieve external traffic are. I hope this example serves to illustrate SOME of the utility of NAT from a security perspective.

Another very important utility of NAT that I did not see addressed at all in RFC 4864 is to abstract the internal hardware that provides a given external service from the connection information provided externally for that service. As an Application Service Provider this is a pretty darn important consideration. Let me illustrate what I mean. If I am providing a particular service that external users connect to on IP x.x.23.46:80 and I want to substitute either permanently or temporarily the internal hardware that provides said service.... with a 1:1 NAT mapping on the firewall ALL I need do is bring that new internal hardware up in parallel on it's own internal IP's and then when I am ready cycle the active connections to that IP on the firewall and change the NAT mappings to it. This affords me great utility as I am allowed precise control over the exact timing which this operation occurs and it can be implemented with very little time and effort. All my internal applicatio  ns still correctly identify the internal hardware distinctly.... yet the entire operation is obfuscated from external users....nothing need change about their connection information....and they may not even realize that a change in the internal hardware providing the service has occurred. Going even a step further I can provide a related service on x.x.23.46:25 and use entirely separate internal hardware to provide it, and I can replace the hardware that provides said services independant of those on port 80. Yet to the external user...everything looks like it is provided from the same physical address. NAT allows this to be done simply, efficiently and with minimal effort. Other solutions would either not be possible at all...or would be far less efficient to enact.

---------------------------------------

To this I might add a third...thougn not technical in nature still pretty darn important... It's listed as a REQUIREMENT in order to be compliant with PCI DSS v1.2

"PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address translation (NAT) technologies-for example, port address translation (PAT)."

It seems that the prime arguements against NAT are...

1) That it breaks certain applications/protocols.... but if the orginization that is deploying NAT has no need or desire to allow those particular applications/protocols to traverse thier network boundary anyways, I fail to see the harm being done there.

2) That when the device implimenting it runs out of resources it aborts user sessions.... but I fail to see how this is any different then any device in the chain of services running out of resources and breaking functionality of a user transaction. Certainly if my web or database server gets overloaded and can't respond to a user request quickly enough.... they will get a time-out error.

Christopher Engel

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 12:15:29 +1300

> Eric & Brian, I was under the impression that I had done just that with my origional post to the list. Let me provide the relavent excerpt. It contains 2 very specific examples (there are more area…

Thanks. There are too many words in my unread mail just before an
IETF to pick up everything...

> 1) NAT allows a firewall to "fail closed" rather then "fail open" when there is a miscofiguration of rules.

I know of nothing that stops firewalls being shipped with "default deny". In fact,
that's how my preferred personal firewall is, and I have no hesitation about
connecting to raw Internet as a result.

> 2) NAT serves to abstract internal hardware that provides services from the external advertisement of those services. Making it very easy and flexible to distribute and redistribute the provision o…

I though we covered that, though not in those words. Certainly topology hiding,
one of the areas we discuss at some length,is a big part of that (and is part
of the gap analysis, so we tend to agree that is a weaker area).

Also of course ULAs are specifically designed to "abstract internal hardware
that provides services from the external advertisement".

...

> Another very important utility of NAT that I did not see addressed at all in RFC 4864 is to abstract the internal hardware that provides a given external service from the connection information provided externally for that service. 
...
ULAs do that.

...

> "PCI-DSS v1.2 Requirement 1.3.8 - "Implement IP masquerading to prevent internal addresses from being translated and revealed on the Internet, using RFC 1918 address space. Use network address tran…

That's just another expression of topology hiding, see above.

> 1) That it breaks certain applications/protocols.... but if the orginization that is deploying NAT has no need or desire to allow those particular applications/protocols to traverse thier network b…

The harm is generic harm to innovation and applications architecture.
The prime example today is the grotesque things that VoIP protocol
designers have been forced to do.

> 2) That when the device implimenting it runs out of resources it aborts user sessions.... but I fail to see how this is any different then any device in the chain of services running out of resources 

...
Mainly because the problems are totally undiagnosable, especially for
the typical home user/help desk combination. And should we really be
pushing technology that we know to be unreliable? As an engineer, that's
actually a violation of my professional ethics.

Enough. Maybe we can get back to honing the NAT66 draft...

    Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 9 Nov 2009 16:03:48 -0800

On Nov 9, 2009, at 15:15, Brian E Carpenter wrote:
> I though we covered that, though not in those words. Certainly topology hiding, one of the areas we discuss at some length,is a big part of that (and is part of the gap analysis, so we tend to agree that is a weaker area).
> 
> Also of course ULAs are specifically designed to "abstract internal hardware that provides services from the external advertisement".

Actually, I think Mr. Engels wants port-translating IPv6/NAT, expressly for making *surjective* mappings from unique local port/addresses to public port/addresses.  He doesn't seem to want this for topology hiding purposes, so much as for achieving high service availability.

I don't think I see anything in RFC 4864 that specifically addresses the usage of port-translating NAT as a tactic for achieving high service availability, and that might be the source of Mr. Engels' agitation.

Of course, there are perfectly reasonable ways to achieve high service availability without using NAT to make surjective address/port mappings, but RFC 4864 doesn't mention any of them.

Perhaps, an update *is* in order.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Nov 2009 13:34:43 +1300

> Actually, I think Mr. Engels wants port-translating IPv6/NAT, expressly for making *surjective* mappings from unique local port/addresses to public port/addresses.  He doesn't seem to want this for…

Ah, you mean the utilisation of NAT covered by US Patent 5371852?

Yes, I agree that this is missing. My opinion is that since IPv6 offers
the ability to synthesise an effectively infinite number of virtual
addresses for virtual servers within an array of physical servers, we
don't need to play NAPT games to achieve this. Yes, this missing
from 4864.

> Perhaps, an update *is* in order.

Or an addendum. But now we are definitely off topic for this list.

   Brian.

---

From: james woodyatt <[email-masked]>
Date: Mon, 9 Nov 2009 17:14:27 -0800

> Ah, you mean the utilisation of NAT covered by US Patent 5371852?

Yes, the IBM cluster patent.  I see that IBM issued an IPR disclosure to IETF for that patent, but has only promised to grant RAND licenses for VRRP usage.  The more general application of the invention that Mr. Engel references appears not to be expressly declared.

  <http://www.ietf.org/ietf-ftp/IPR/ibm-rfc2338-rfc2787.txt>

Yes, we are well and truly off topic now.

ObTopic: the NAT66 draft doesn't help address either of the two concerns Mr. Engel raised, i.e. neither the high availability consideration, nor the issue with misconfigured NAT failure tending toward "closed" rather than "open" configurations.  A misconfigured NAT66 middlebox, being a symmetric NAT, is just as likely to fail "open" as "closed" from his perspective.  I'll leave it to the authors of the NAT66 draft to respond.

---

From: <[email-masked]>
Date: Tue, 10 Nov 2009 09:37:06 +0100

Dear Brian, all,

Please see inline.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Brian E Carpenter
Envoyé : mardi 10 novembre 2009 01:35
À : james woodyatt
Cc : NAT66 HappyFunBall; [email-masked]
Objet : Re: [nat66] Necessity for NAT remains in IPv6

Yes, I agree that this is missing. My opinion is that since IPv6 offers the ability to synthesise an effectively infinite number of virtual addresses for virtual servers within an array of physical servers, we don't need to play NAPT games to achieve this. Yes, this missing from 4864.

Med: We have identified a use case in which such NAPT66 functionality may be required to avoid introducing NAT64 devices in the core network (see http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04#section-6.6.3). Except the need to avoid stateful devices (which means: CAPEX/OPEX constraints, maintenance issues, constraint on session establishment and need to embed updated ALGs, routing optimisation, robustness, etc.) in the network and the forthcoming IPv4 address exhaustion, I don't have other arguments to justify that this would be a viable use case. 

Cheers,
Med 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Chris Engel <[email-masked]>
Date: Tue, 10 Nov 2009 11:58:28 -0500

Gentlemen,

Unless I am misunderstanding how ULA works I don't see how it addresses the 2nd issue I raised. It provides a private address space, but doesn't provide any means to relate that space to your public address space. I don't see any abstraction there.... just the possibility to maintain an  additional space.

Example: I have a service that I publicly advertise on Network A, Host 1 (public address space). I provide that service on an internal device on Network B, Host 1 (private address space) but I want to move that service  (either temporarily or permanently) to be provided on a different internal device Network B, Host 2 (private address space). I don't see how ULA helps with that. It allows me to have a private address space...but it doesn't provide any mapping of that space to the Public Address space... that's what NAT does.

In this scenario with NAT, I only need maintain 1 address scheme on my internal network (the private one). My external address scheme only exists virtually on my firewalls external interface. When I want to switch which internal device is providing that service all I need do is logon to my firewall, change the NAT mappings to it and then cycle the active connections for the device...presto done...simple and easy.

In the ULA scenario, I would need to maintain 2 separate address schemes on my private network... the ULA (private one) and the public one. I would have to manage those address schemes on the NIC of every single device that might need external access and I'd need to logon to those individual devices when I wanted to make changes. That REALLY is NOT an abstraction of the internal infrastructure... it's just an additional network placed on the internal infrastructure.

It doesn't compare with the utility provided by NAT. Where I have only one network/address space to manage on my internal infrastructure. I have one device make any changes I want on, they happen simply and easily and they allow me to completely abstract my internal infrastructure.... even going so far as the port level. (Which, btw, can provide ALOT of utility if services outgrow a particular device and I want to split the ones it provides to different machines without changing anything about the external service address).

As far as item #1 and firewalls being configured with a default rule of DENY ALL IN. That's pretty much standard configuration these days. However, I've already covered this and it doesn't address the issue I raised. Standard practice is to Deny ALL IN by default and then poke holes as needed. The issue comes in the "poking holes" process. This is where you see the most common mistakes... where the holes being poked are larger then necessary.

For a specific example: Imagine an admin wanted to create a rule to ALLOW HTTP OUT ALL... to let all internal devices go out and do web browsing. By mistake they configure it to ALLOW HTTP IN/OUT ALL... not hard to do on some firewall interfaces. Your default DENY ALL IN rule doesn't help.... it's just been overridden by accident. NAT, however, DOES help....as none of those internal devices are publicly addressable unless they've been given a static 1:1 mapping.

I really don't think you guys are thinking this through completely. Honestly, I think you are so intent on driving a stake in the heart of NAT that you don't recognize the VERY REAL utility NAT provides in some areas. That's a big part of the issue with RFC 4864.... it comes of as an advocacy piece rather as a straight informative piece.

Finally I don't believe you would have a very successful time convincing a security auditor that ULA covers the PCI-DSS v1.2 Requirement 1.3.8, when they say use "Use network address translation (NAT)" that is PRECISELY what they want you to do. I've dealt alot with those type of audits. You are going to have a VERY tough sell that ULA is an acceptable "compensating control" for that.

Bottom line is, that whether you like it or not you WILL be dealing with NAT in an IPv6 world. There will be too many people like me who demand it. Vendors will listen to those demands because there will be a market there for them. You can either try to exert some influence over the manner in which it is implemented, and possibly address some means of compensating for it.... or just try to pretend it's not going to happen and let the chips fall as they may.

Christopher Engel

-----Original Message-----
From: james woodyatt [mailto:[email-masked]]
Sent: Monday, November 09, 2009 8:14 PM
To: Brian E Carpenter; Chris Engel
Cc: NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6

--

---

From: Keith Moore <[email-masked]>
Date: Tue, 10 Nov 2009 12:20:21 -0500

> Example: I have a service that I publicly advertise on Network A, Host 1 (public address space). I provide that service on an internal device on Network B, Host 1 (private address space) but I want…
I don't think NAT causes many problems when used in this manner - to map
specific hosts with specific, well-known, services, to specific external
addresses.  The alternative would be to use a tunnel, which has its own
problems, and it's a case of choosing the lesser of two evils.  Which is
better depends on specific circumstances.

But that kind of NAT has almost nothing in common with the kind of NAT
> For a specific example: Imagine an admin wanted to create a rule to ALLOW HTTP OUT ALL... to let all internal devices go out and do web browsing. By mistake they configure it to ALLOW HTTP IN/OUT A…
You seem to be arguing that NAT is a way to solve the problem that
firewalls have poor configuration interfaces.   That strikes me as a bit
like using a cannon to try to swat a fly - you're doing so much
collateral damage in the process that the fly becomes irrelevant.

And the argument that NAT helps here is completely bogus, because while
there are indeed cases where a NAT "just happens" to do the right thing,
there are also numerous cases where it "just happens" to do the wrong
thing.  You want to call attention to the former cases while ignoring
the latter ones. 
> I really don't think you guys are thinking this through completely. Honestly, I think you are so intent on driving a stake in the heart of NAT that you don't recognize the VERY REAL utility NAT pro…
It's clear that you haven't thought this through completely.  Either
that or you're so intent on driving a stake into the Internet's ability
to evolve and support new applications that you don't recognize the VERY
REAL utility the Internet provides outside of existing transport
protocols and the few applications that you care about.  And you're so
committed to this view that the Internet should always stay the same as
it is now, that you react adversely to RFC 4864 or anything else that
tries to make the Internet more useful or more broadly applicable.
> Finally I don't believe you would have a very successful time convincing a security auditor that ULA covers the PCI-DSS v1.2 Requirement 1.3.8, when they say use "Use network address translation (N…
There's lots of ignorance in the world.     IETF's job is to explain how
to make the Internet work well, not to propagate ignorance or to give it
more credibility than it deserves.
> Bottom line is, that whether you like it or not you WILL be dealing with NAT in an IPv6 world. There will be too many people like me who demand it. 
Too many people who are bent on crippling the Internet. 

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 11 Nov 2009 06:39:12 +0900

On Nov 11, 2009, at 2:20 AM, Keith Moore wrote:

> Chris Engel wrote:
>>
>> Gentlemen,
>>
>> Unless I am misunderstanding how ULA works I don't see how it  
>> addresses the 2nd issue I raised. It provides a private address  
>> space, but doesn't provide any means to relate that space to your  
>> public address space. I don't see any abstraction there.... just  
>> the possibility to maintain an  additional space.
>>
>> Example: I have a service that I publicly advertise on Network A,  
>> Host 1 (public address space). I provide that service on an  
>> internal device on Network B, Host 1 (private address space) but I  
>> want to move that service  (either temporarily or permanently) to  
>> be provided on a different internal device Network B, Host 2  
>> (private address space). I don't see how ULA helps with that. It  
>> allows me to have a private address space...but it doesn't provide  
>> any mapping of that space to the Public Address space... that's  
>> what NAT does.
> I don't think NAT causes many problems when used in this manner - to  
> map specific hosts with specific, well-known, services, to specific  
> external addresses.  The alternative would be to use a tunnel, which  
> has its own problems, and it's a case of choosing the lesser of two  
> evils.  Which is better depends on specific circumstances.
>
> But that kind of NAT has almost nothing in common with the kind of  
> NAT you cite below:

That kind of NAT has, of course, everything in common with NAT66.
>> Finally I don't believe you would have a very successful time  
>> convincing a security auditor that ULA covers the PCI-DSS v1.2  
>> Requirement 1.3.8, when they say use "Use network address  
>> translation (NAT)" that is PRECISELY what they want you to do. I've  
>> dealt alot with those type of audits. You are going to have a VERY  
>> tough sell that ULA is an acceptable "compensating control" for that.

What PCI-DSS v1.2 requirement 1.3.8 actually says is:

"1.3.8 Implement IP masquerading to
prevent internal addresses from being
translated and revealed on the Internet,
using RFC 1918 address space. Use
network address translation (NAT)
technologies—for example, port address
translation (PAT). "

Obviously this would need to be updated to be met in IPv6 at all, as  
RFC 1918 is IPv4-only.  The simplest change would be to use ULAs (the  
IPv6 replacement for RFC 1918 address space) instead.  This section  
does not actually require port translation, although it is mentioned.   
So, I think you could meet this requirement for IPv6 by using ULAs for  
internal addressing and NAT66 to translate the RFC 1918 space to  
external addresses.

Chris, do you know if there is any plan to update the PCI requirements  
to cover IPv6?

Margaret

---

From: Chris Engel <[email-masked]>
Date: Tue, 10 Nov 2009 17:41:39 -0500

Margaret,

I'm actualy not really the best person to ask about that. I have no insight into the internal workings of PCI policy making. I mostly deal with it from a standpoint compliance issues. Meaning I know what the policy is.....but I don't know much about the sausage-making process of how that policy gets crafted.

Most of my actual experience comes from getting qualified as a vendor for clients that are regulated under Gramm-Leach-Bliley which involves a security review/audit for compliance with thier corporate vendor security standards. The issues dealt with are similar but not the same.

NAT has been listed as a requirement in pretty much all of those that I've dealt with.... I haven't encountered anything IPv6 specific in any of those yet.... though I'm sure it'll come along at some point. They are usualy pretty slow in adapting those policies to cover emerging technologies.

Last one I dealt with had as a listed requirement to "Not use Cell Phones for business purposes, for any discusions related to business purposes or for the transmission of any sensitive data". So that should give you a good picture of what they look like.

Christopher Engel

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]]
Sent: Tuesday, November 10, 2009 4:39 PM
To: Keith Moore
Cc: Chris Engel; NAT66 HappyFunBall
Subject: Re: [nat66] Necessity for NAT remains in IPv6

On Nov 11, 2009, at 2:20 AM, Keith Moore wrote:

>> public address space. I don't see any abstraction there.... just the
>> possibility to maintain an  additional space.
>>
>> Host 1 (public address space). I provide that service on an internal
>> device on Network B, Host 1 (private address space) but I want to
>> move that service  (either temporarily or permanently) to be provided
>> on a different internal device Network B, Host 2 (private address
>> space). I don't see how ULA helps with that. It allows me to have a
>> private address space...but it doesn't provide any mapping of that
>> space to the Public Address space... that's what NAT does.

>> Requirement 1.3.8, when they say use "Use network address translation
>> (NAT)" that is PRECISELY what they want you to do. I've dealt alot
>> with those type of audits. You are going to have a VERY tough sell
>> that ULA is an acceptable "compensating control" for that.

technologies-for example, port address
translation (PAT). "

Obviously this would need to be updated to be met in IPv6 at all, as RFC 1918 is IPv4-only.  The simplest change would be to use ULAs (the IPv6 replacement for RFC 1918 address space) instead.  This section does not actually require port translation, although it is mentioned. So, I think you could meet this requirement for IPv6 by using ULAs for internal addressing and NAT66 to translate the RFC 1918 space to external addresses.

Chris, do you know if there is any plan to update the PCI requirements to cover IPv6?

Margaret