Subject: Re: [nat66] e2e New Version Notification

From: Roger Marquis <[email-masked]>
Date: Wed, 27 Oct 2010 20:42:16 -0700 (PDT)

Keith Moore wrote:
> I've been personally writing apps that had to deal with NAT brain-damage
> for 15 years. The opinions of your Berkeley professors and "IT security"
> colleagues don't mean jack.

And I appreciate those apps.  I especially appreciate the stateful NAT
implementations by Cisco and Juniper.  But what you're proposing,
deprecating NAT, is fundamentally different.

What apps are we talking about anyhow?  P2P or anything depending on SIP
or SCTP?  There's no business case for allowing those apps or protocols
to establish stateless inbound connections anywhere in my network.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 00:09:05 -0400

--On October 27, 2010 8:42:16 PM -0700 Roger Marquis <[email-masked]> 
wrote:

> And I appreciate those apps.

It's clear that you don't appreciate those apps, because you have no idea 
what they are.

> But what you're proposing, deprecating NAT, is fundamentally different.

I'm not proposing to deprecate NAT. NAT is and always was a violation of 
the core Internet standards.  NAT is and always was also fundamentally in 
violation of the Internet architecture.  NAT is and always was harmful to a 
wide range of applications and also quite often harmful to operation of 
networks.

NAT can't be deprecated because it was never approved.  It's never been 
acceptable as a general solution to anything.

And yet, we do find some legitimate corner cases for which we don't (yet) 
have a better solution than NAT. One such corner case is interoperation 
between v4/v6 during a transition to v6.  Another such corner case is 
giving v6 networks a global address prefix that is stable across changes to 
network providers or attachment points, until such time as the network 
routing system can be adapted to cope with anticipated scale.

So what I'm proposing is several things:

1. that (along with identifying cases where NATs are clearly not a good 
solution, such as substitutes for firewalls), we also identify those 
specific corner cases for which we don't yet have a better solution than NAT
2. that we keep looking for ways to address those corner cases without 
using NAT
3. that we define interface standards for NAT that allow applications 
(including those that need to do referrals) to deal with the worst pitfalls 
of NAT
4. that we be scrupulously honest about both NAT's limitations and the 
corner cases for which there are no better known solutions that appear to 
be deployable

> What apps are we talking about anyhow?  P2P or anything depending on SIP 
or SCTP?  There's no business case for allowing those apps or protocols to 
establish stateless inbound connections anywhere in my network.

I'm talking about apps that my employers and customers needed.  You've 
probably never heard of most of them, but they were important within their 
spheres, and it was important that those apps be able to function in the 
presence of NATs.

There's nothing special about P2P apps. The idea that all apps should 
communicate through some central server is myopic in the extreme.  That 
kind of thinking should have gone out the door with IBM dinosaur mainframes 
and SNA.

You're free to run (or prohibit) what you like on your own network, but 
your idea of what makes a good business case for your network has no 
bearing on whether IETF should endorse the use of NATs.  Especially since 
use of NATs to enforce security is poor practice.

Keith

---

From: Roger Marquis <[email-masked]>
Date: Wed, 27 Oct 2010 21:29:40 -0700 (PDT)

Keith Moore wrote:
> communicate through some central server is myopic in the extreme.  That kind

So you are talking about P2P then.  Please make the business case for my
company's allowing your P2P app to establish inbound connections without NAT?
Without those specifics your assertions have no identifiable logic.

> You're free to run (or prohibit) what you like on your own network, but your 
> idea of what makes a good business case for your network has no bearing on 
> whether IETF should endorse the use of NATs.  Especially since use of NATs to 
> enforce security is poor practice.

It's not my business case but the business case of just about every
non-ISP and non-carrier connected to the Internet.  t's t you're
asserting as "myopic" is standard practice in the real world.

Home and business users require NAT for 1) layer abstraction (no
different, fundamentally, from the abstraction of Ethernet's MAC layer),
2) flexibility (unlinking internal from external and multi-homed
topologies), and 3) security.  By not providing non-NAT alternatives for
any of these NAT features the case for a NATless IPv6 is like insurance
company's arguments against universal health care, baseless fear
mongering repeated again and again in hope of convincing those who dont
know any better.

IMO,
Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 00:43:27 -0400

On Oct 28, 2010, at 12:29 AM, Roger Marquis wrote:

> Keith Moore wrote:
>> There's nothing special about P2P apps. The idea that all apps should communicate through some central server is myopic in the extreme.  That kind
> 
> So you are talking about P2P then.  

I have no idea what you mean by P2P, and I suspect, neither do you.  But no, most of these apps wouldn't have been considered P2P apps.  They generally did have some form of central coordination, but having a central server participate in communications between nodes would have been totally unacceptable from both a performance and reliability perspective.

(hint: many of the apps I worked on were involved in large-scale and/or fault-tolerant distributed computing)

> Please make the business case for my company's allowing your P2P app to establish inbound connections without NAT?

I don't give a damn about your company or its network.   They are irrelevant to this discussion.  It's your choice whether you want to run any particular app or not.  

If you think there's something inherently wrong with P2P apps, you're deluded.  But hey, it's your business.  If you refuse to use tools that might be useful to you because you have some sort of uninformed prejudice against P2P, that's your choice and your business can suffer accordingly.   Survival of the fittest and all that.  It's still irrelevant to this discussion.

>> You're free to run (or prohibit) what you like on your own network, but your idea of what makes a good business case for your network has no bearing on whether IETF should endorse the use of NATs.  Especially since use of NATs to enforce security is poor practice.
> 
> It's not my business case but the business case of just about every non-ISP and non-carrier connected to the Internet.

There's a lot of bad advice going around masquerading as conventional wisdom.  I can't help that, but I'm not going to pretend that I suffer from the same delusions just for the sake of making delusional people feel better.

Keith

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 14:38:56 +0200

> to establish stateless inbound connections anywhere in my network.

The NAT66 (possibly) specified by IETF is likely end up going to be deployed also elsewhere than just in lets-restrict-everything corporate networks. Even if it would be just fine for apps to fail in your network, it would be good if said apps would work fine in those networks that deploy NAT66 for some other reasons than traffic restrictions. Maybe someone chooses to use NAT66 to translate uplink's /64 to ULA prefix in local LAN.

Hence base specification for NAT66 should be as application friendly as possible.

Best regards,

Teemu

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Oct 2010 14:57:15 +0200

Hi, teemu,

Le 28 oct. 2010 à 14:38, <[email-masked]> <[email-masked]> a écrit :
> Maybe someone chooses to use NAT66 to translate uplink's /64 to ULA prefix in local LAN.

Wouldn't advertising this /64 on the LAN make more sense?
BTW, that's what Free did in the first months when they only offered /64's.

Regards,
RD

---

From: <[email-masked]>
Date: Thu, 28 Oct 2010 15:22:55 +0200

Yes, or do ND proxy. But my point is that the NAT66 technology may very well escape out of the main deployment scenario..

Best regards,

Teemu

> -----Original Message-----
> From: ext Rémi Després [mailto:[email-masked]]
> Sent: 28. lokakuuta 2010 15:57
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: [nat66] e2e New Version Notification
> 
> Hi, teemu,
> 
>

---

From: Roger Marquis <[email-masked]>
Date: Thu, 28 Oct 2010 09:47:59 -0700 (PDT)

Keith Moore wrote:
>> Please make the business case for my company's allowing your P2P app to
>> establish inbound connections without NAT? Without those specifics your
>> assertions have no identifiable logic.
> 
> I don't give a damn about your company or its network. They are irrelevant
> to this discussion. It's your choice whether you want to run any particular
> app or not.

This paragraph appears to be self-contradictory.  How can you not care
what someone runs on their network on the one hand, and care whether they
use stateful NAT on the other?

> If you think there's something inherently wrong with P2P apps, you're
> deluded. But hey, it's your business.

I doubt anyone has a bias against generic P2P.  That's not the issue.
What's wrong is remote apps that expect to 1) initiate inbound
connections and 2) demand that they be allowed to initiate those inbound
connections to hosts unprotected by statefulness and to topologies
unabstracted by NAT.

Roger Marquis

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Oct 2010 10:39:45 -0700

On Oct 28, 2010, at 09:47, Roger Marquis wrote:
> 
> What's wrong is remote apps that [...] initiate those inbound connections to [...] topologies unabstracted by NAT.

Let's leave aside the parts of your argument I've excised with ellipses.  What precisely is wrong with applications that expect to initiate flows to destinations in topologies that have not been obfuscated away by a network address/port translator?

This question is relevant to the mailing list topic because I-D.mrw-nat66 doesn't provide any local topology obfuscation.  I think it would help to understand what you need that the NAT66 draft as currently composed assumes you're going to get from somewhere else.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Roger Marquis <[email-masked]>
Date: Thu, 28 Oct 2010 11:18:47 -0700 (PDT)

james woodyatt wrote:
> Let's leave aside the parts of your argument I've excised with ellipses.
> What precisely is wrong with applications that expect to initiate flows to
> destinations in topologies that have not been obfuscated away by a network
> address/port translator?

Same thing that would be wrong with applications expecting access to other
internal network details.  The opposite question would be what's wrong with
requiring applications to stick to the application layer?

An analogous situation would be if ATT required all phone numbers to be
keyed to GPS coordinates, forbidding forwarding.  What business is it of
ATT's, or of remote callers, where their destination is physically
located?

Perhaps a more common but also analogous situation is mail order
companies that require a physical address, email address, and phone
number before they'll process a credit card order.

End-users have good reason for not providing these details.  That's
basically what EU Privacy Directives are all about.  By using NAT end
users get the privacy they require, freedom from vendor lock-in, and are
able to maintain their internal hosts and topologies as they see fit, not
as their upstream ISP, application designers, or marketing data
aggregators see fit.

Roger Marquis

---

From: Chris Engel <[email-masked]>
Date: Thu, 28 Oct 2010 14:51:43 -0400

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of james woodyatt
> Sent: Thursday, October 28, 2010 1:40 PM
> To: Roger Marquis
> Cc: NAT66 HappyFunBall
> Subject: [SPAM] - Re: [nat66] e2e New Version Notification -
> Email has different SMTP TO: and MIME TO: fields in the email
> addresses
>
>
> > What's wrong is remote apps that [...] initiate those inbound
> > connections to [...] topologies unabstracted by NAT.
>
> Let's leave aside the parts of your argument I've excised
> with ellipses.  What precisely is wrong with applications
> that expect to initiate flows to destinations in topologies
> that have not been obfuscated away by a network address/port
> translator?
>
> This question is relevant to the mailing list topic because
> I-D.mrw-nat66 doesn't provide any local topology obfuscation.
>  I think it would help to understand what you need that the
> NAT66 draft as currently composed assumes you're going to get
> from somewhere else.
>
>
> --
>
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
>

James,

You seem to be changing the context of what Roger wrote, which seemed perfectly understandable and reasonable to me.

An application that originates at some arbitrary external location and seeks to cross the Enterprise Network Boundary and arrive at some arbitrary destination internal to the Enterprise without any intervention by the Enterprise Admin to explicitly allow for it has unreasonable expectations as far as the Enterprise (or at least most of them) is concerned.

That's exactly the type of scenario most Enterprises DON'T want to see work. In cases of INBOUND connections, Enterprises generally WANT them to fail unless the Enterprise has taken explicit measures to make them work. Furthermore, more often then not, when the Enterprise does want them to work, it's going to FORCE said apps to go through some well known, centrally managed point (i.e. some sort of Proxy/ALG) where it can be monitored/audited/controlled and perhaps some policies regarding how it is being used can be enforced.

In other words, NAT generally isn't breaking anything that the Enterprise doesn't want broken anyway.... and may actually be helping to break certain things that would be somewhat more difficult to break without it.

This is an area where Enterprises and Transit Providers seem to be entirely different animals with different priorities.

Let's look at something like VOIP. From the individual consumers point of view the idea that you can sit down at any internet connection anywhere in the world and have a free/low cost voice conversation with anyone at an internet connection anywhere else in the world is awesomely cool. However from the perspective of many Enterprises this is very problematic for business related calls. Enterprises may require specific things happen in relation to business calls (such as monitoring, auditing, recording) that are infinitely harder to achieve unless such calls are FORCED to go through a central service.

So for example, when customer calls up the company and says... "One of your Operators called me up at 2 AM and promised me X".  The response from IT isn't....

"OK we'll try to search through every single workstation in the company, including those which are out for repairs, and see If anyone was running Skype at 2 AM....and Oh god, I hope they were following policy and recording the call if they did....and Oh god, I hope someone didn't screw up and let a personal device plug into our network jacks."

The response is....

"We have a record of every call originating from our network. Searching the call log db we can see that a call was placed to this number at 5:02 PM from Operator #231 at workstation 211 in the Houston Branch. Here is the voice-recording of the content of that call. Shall I play it for you so that you can hear exactly what was said?"

Christopher Engel
Network Infrastructure Manager
SponsorDirect
[email-masked]
www.SponsorDirect.com
p(914) 729-7218
f (914) 729-7201

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Oct 2010 12:50:09 -0700

On Oct 28, 2010, at 11:18, Roger Marquis wrote:
> internal network details. [...]

I don't understand how this answers my question, because I don't know what's wrong with applications expecting to know A) what addresses the network presents to their peers for them, or B) what addresses the network presents to their peers for all their other peers.

> [...]

I hope I'm inferring correctly from the above paragraph that the reason you find RFC 4193 insufficient is that it places the burden for using privacy addresses on the application hosts and leaves the enterprise network operator without a central control point where the privacy addressing of an entire network can be applied regardless of whether hosts do or do not use RFC 4193.  Is that correct?

If so, then I-D.mrw-nat66 cannot help you; it offers no privacy addressing.  So, right now, it sounds like there isn't a publicly defined way to solve the problem you're here to discuss without using a stateful IPv6/NAT, which does well-understood harm to the Internet architecture and the Internet community beyond the domain of enterprises that use it.

So, if you want IETF to consider your problem, perhaps the most expedient way to get that to happen is to write up an Internet Draft of your own to compete with I-D.mrw-nat66.  If you decide to do that, then I hope you will answer my question above with more clarity, because it will help to refine your proposal so that it mitigates as much harm to the Internet as possible, c.f. Keith Moore's previous comments about self-address fixing.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 16:06:14 -0400

> use stateful NAT on the other?

First answer:   

This discussion is not about what you do on your network.  It's about what IETF should endorse.  What you do on your network is generally out of scope for the discussion, because nobody is proposing that IETF define any mechanism to forbid you from doing anything on your network.   And you don't need IETF's endorsement in order to do what you want with your network.  Do whatever you like, have a blast.  (Just don't complain to us if what you do doesn't work well.  You get to deal with the consequences of whatever choices you make.)

Second answer:  

I don't care what you do in the privacy of your home, but I do care if you and lots of other people dump your waste into the street and let it rot there. 

Occasional deployment of NATs does little harm, but widespread deployment of NATs is like widespread dumping of toxic waste.   I want people who actually have a legitimate need for NAT to be able to use NAT.   But because widespread use of NAT does harm, I don't want to encourage NAT, and I want to try to make sure that the vast majority of users have better ways to solve their problems than NAT.  I hope that if users are given better solutions, then they'll stop trying to use NAT where it makes no sense - like as a firewall.

The idea that NATs only affect the networks behind them is false.  When NATs are widespread, that affects the environment in which applications are expected to operate.   There isn't a separate market for apps that work behind NATs. 

If only a relative few networks use NAT, then when applications don't work on those networks, it's clear that it's the NAT's fault.    After all, the applications work just fine everywhere else.   

But when NATs are widespread, and they break applications, people blame the applications.  It's not the applications' fault that they don't work with NAT.  It's the fault of the network engineer who didn't design his network properly.  The application is operating according to specifications, the NAT is not.  But people often blame the applications because they take NATs as a given.  Partially this is because of poor planning in protocols like DHCP and PPP - they were only designed to support a single host, rather than a network.  Partially this is because CIDR resulted in somewhat shortsighted policies for address assignment to consumer customers of ISPs.  Partially this is because NAT vendors often failed to inform their customers about the harm that their products did (especially when they labeled them as "internet connection sharing" and the like).  Partially this is because most people don't have insight into what a particular application needs to do in order to operate well.  Some applications work just fine through NAT, others don't.  But this is generally because different kinds of applications quite naturally have different communications patterns - not because there's something wrong with the apps that don't work well through NAT.

Third answer:

On the other hand, when people carefully engineer and operate their networks for the sole purpose of running a limited number of well-understood applications, I don't have a problem with it at all if they happen to use NAT.  e.g. I don't have a problem with F5 boxes even though they use NAT techniques.   It's just another way of building a big server cluster.  If you can't build a single host big enough to handle your traffic, you'll get better results if you use that sort of NAT box to demux your traffic than you will if you try to use multiple IP addresses to spread the load around.  And it doesn't break anything when the clustering solution is carefully chosen to work well with the specific apps it is designed to support.  It's not this kind of very specifically tailored use of NATs that causes problems, it's trying to impose NATs on general purpose networks that need to support a wide variety of apps and users.

> I doubt anyone has a bias against generic P2P.  That's not the issue. What's wrong is remote apps that expect to 1) initiate inbound connections and 2) demand that they be allowed to initiate those inbound
> connections to hosts unprotected by statefulness and to topologies unabstracted by NAT.

There's nothing at all wrong with those apps.    Apps aren't supposed to have to know about network topology.   The app doesn't know that it's making an inbound connection to your network and it has no way of knowing.  (other than ICMP prohibited, which is almost never implemented and is also quite easily spoofed.)  That might be a major problem with the Internet architecture, but it's not a problem with the app.  Give the app a reliable way to know when it's circumventing a policy (along with a reasonable error message that the app can give to the user that tells him how to get the policy fixed if it's in error) and _then_ you can start expecting apps to be polite.  

The fact that a NAT is in the signal path is not an indication of policy because NATs are not designed as policy enforcement tools and are poorly suited as policy enforcement tools.  That doesn't stop you from trying to use NATs as policy enforcement tools any more than it stops you from using your forehead to nail something to a tree.  But just because you can try to do it doesn't mean it's a good idea.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2010 10:37:24 +1300

Roger,

On 2010-10-28 17:29, Roger Marquis wrote:
...
> topologies), and 3) security.  

For home users and the vast majority of business users, these three
arguments are well known to be spurious. I won't waste bits on that.

On the other hand, who's willing to refund me the $500NZ that I
unintentionally donated to a charity earlier this year, because
a NAT session timeout aborted a "secure" connection before the
ack for the credit card transaction came back over HTTPS, allegedly
a protocol that NATs handle impeccably?

OK, it was my own stupid fault for repeating the transaction before
checking my credit card account, and it was for a good cause,
but this is the basic reason why NATs are a bad thing for homes
and businesses. They break stuff.

     Brian

---

From: Scott Brim <[email-masked]>
Date: Thu, 28 Oct 2010 17:44:42 -0400

Brian: (1) I can't resist invoking the e2e argument and say you
shouldn't depend on intermediaries for reliability.  (2) It's a good
thing that this list is really about NAT66, not those stateful edge NATs.

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Oct 2010 14:45:18 -0700

On Oct 28, 2010, at 2:37 PM, Brian E Carpenter wrote:

> a NAT session timeout

You're aware that this doesn't apply to a stateless network prefix translator, right?

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 29 Oct 2010 11:15:21 +1300

> You're aware that this doesn't apply to a stateless network prefix translator, right?

Of course. But Roger's arguments were not about that, as far as I can see.

   Brian

---

From: Roger Marquis <[email-masked]>
Date: Thu, 28 Oct 2010 17:45:05 -0700 (PDT)

james woodyatt wrote:
> I don't understand how this answers my question, because I don't know
> what's wrong with applications expecting to know A) what addresses the
> network presents to their peers for them, or B) what addresses the network
> presents to their peers for all their other peers.

Your mal-understanding is most likely due to having responded to what you
paraphrased instead of what I originally wrote.  Did you understand the
analogy to ATT's demanding to know every phone user's GPS coordinates?

> I hope I'm inferring correctly from the above paragraph that the reason you
> find RFC 4193 insufficient is that it places the burden for using privacy

RFC 4193 replaces RFC 1918.  It has nothing directly to do with NAT.

> If so, then I-D.mrw-nat66 cannot help you; it offers no privacy addressing.
> So, right now, it sounds like there isn't a publicly defined way to solve
> the problem you're here to discuss without using a stateful IPv6/NAT, which
> does well-understood harm to the Internet architecture and the Internet
> community beyond the domain of enterprises that use it.

"well-understood harm to the Internet" is pure rhetoric and
intellectually dishonest.  NAT is part of the Internet whether we like it
or not.  It also does far more good than harm.  How else would it have
become so widespread, even within organizations not needing to use RFC
1918 addressing?  But we do understand that those writing P2P
applications, using a badly designed protocol like SIP, writing viruses
and trojans, or otherwise trying to access information that firewalls
block, NAT blocks, and plain old ACLs block, you are going to be "harmed"
just as was ATT when they lost the right to be a monopoly or deny number
portability.  That "harm" is intentional.

> So, if you want IETF to consider your problem, perhaps the most expedient
> way to get that to happen is to write up an Internet Draft of your own to
> compete with I-D.mrw-nat66.

This is a good point, but given the inability of the IETF to implement
IPv6 beyond a trivially small niche in over 10 years, their inability to
ratify IAX and other protocols, and the level of influence special
interests hold within the IETF (many of whom stand to profit from the
"harm" caused by forcing GUA on consumers) few consider the IETF capable
of much of anything these days.  The reasons why the IETF "can't do" are
illustrated in this very thread, particularly by the attempts at
rhetorical obfuscation like RFC 4193 and claims of "well-understood
harm".

Roger Marquis

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 28 Oct 2010 20:46:44 -0400

On Oct 28, 2010, at 3:50 PM, james woodyatt wrote:
>
> If so, then I-D.mrw-nat66 cannot help you; it offers no privacy  
> addressing.  So, right now, it sounds like there isn't a publicly  
> defined way to solve the problem you're here to discuss without  
> using a stateful IPv6/NAT, which does well-understood harm to the  
> Internet architecture and the Internet community beyond the domain  
> of enterprises that use it.

NAT66 doesn't interfere in any way with the use of IPv6 privacy  
addresses.

Margaret

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Oct 2010 18:16:11 -0700

On Oct 28, 2010, at 5:46 PM, Margaret Wasserman wrote:

> NAT66 doesn't interfere in any way with the use of IPv6 privacy addresses.

I'm pretty sure that much of this conversation isn't about what we wrote in that draft. I question how many have actually read it.

Guys - the difference between a network with NAT66 and a network without it is this:

Without NAT66
  - the transit core somehow knows the edge networks addresses.
    that could be PA or PI. If it is PI, the transit core has a route for the PI prefix
  - a device in the edge network is reachable from the transit core absent a firewall rule
  - a device in the edge network knows one or more global addresses for itself.
    These are the same addresses that the transit core knows.
  - the edge network addresses conform to RFC 4291, and may be assigned using SLAAC (ND 
    or SEND) or DHCPv6, and may be privacy addresses. In addition, there may be ULAs or 
    link-local addresses.

With NAT66
  - the transit core knows the PA prefix it uses for the edge network
  - a device in the edge network is reachable from the transit core absent a firewall rule
  - a device in the edge network knows one or more local addresses for itself.
    These are different than the addresses that the transit core knows.
  - the edge network addresses conform to RFC 4291, and may be assigned using SLAAC (ND 
    or SEND) or DHCPv6, and may be privacy addresses. If I were king, they would be ULAs,
    but that is not required. In addition, there may be other ULAs or link-local addresses.

As Keith points out, to maintain Dynamic DNS AAAA records, the device has to be able to determine its own external addresses. If a static DNS configuration is maintained and privacy addresses do not periodically change (which kind of calls for Dynamic DNS), the DNS service can be maintained centrally without the collusion of the addressed systems.

IMHO, which Keith disagrees with, any other system including a system that writes the HTML/etc file containing a referral can find the addresses of any system in the network in DNS. That's DNS's job. I'll accept that one may want to do that periodically rather than on every access.

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Oct 2010 18:25:39 -0700

On Oct 28, 2010, at 17:45, Roger Marquis wrote:
> Your mal-understanding is most likely due to having responded to what you paraphrased instead of what I originally wrote.

Technically, I didn't paraphrase.  I quoted while eliding extraneous text.  And I was responding to the quoted text.

The original text included the compound phrase "to hosts unprotected by statefulness and to topologies unabstracted by NAT."  I didn't have any questions about the former infinitive phrase; it was the latter phrase, the one I quoted, which read, "to topologies unabstracted by NAT," that I was asking about.

> Did you understand the analogy to ATT's demanding to know every phone user's GPS coordinates?

No, sorry.  I could make neither heads nor tails of your analogy.  I failed to see how it connects with the question I'm asking.

>> I hope I'm inferring correctly from the above paragraph that the reason you find RFC 4193 insufficient is that it places the burden for using privacy
> 

Ooops!  My mistake.  I meant Privacy Extensions for Stateless Address Autoconfiguration in IPv6 [RFC 4941], which you would presumably want to assign statefully as temporary addresses with Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC 3315].

Have I conveyed my question to you adequately now?

---

From: Christian Huitema <[email-masked]>
Date: Fri, 29 Oct 2010 01:29:05 +0000

> As Keith points out, to maintain Dynamic DNS AAAA records, the device has to be able to determine its own 
> external addresses. If a static DNS configuration is maintained and privacy addresses do not periodically 
> change (which kind of calls for Dynamic DNS), the DNS service can be maintained centrally 
> without the collusion of the addressed systems.

Another possibility is for the internal system to consider the "external" address provided by NAT-66 as a "virtual interface", similar to what would be obtained for example by a tunnel to the external gateway. That means the internal systems could learn the available address through some configuration function. Centralized DHCP servers come to mind, e.g. a DHCPv6 option providing the translation value.

-- Christian Huitema

---

From: james woodyatt <[email-masked]>
Date: Thu, 28 Oct 2010 18:30:49 -0700

> NAT66 doesn't interfere in any way with the use of IPv6 privacy addresses.

Of course not.  What it does not do, which I think Mr. Marquis finds lacking, is provide any privacy for interior hosts that are *not* using privacy addresses.

My understanding is that this isn't an oversight by the authors, and that we are not here to discuss whether privacy obfuscation is a feature that should be added to the draft.  Hopefully, Mr. Marquis and others with similar concerns will come to understand this and take the discussion where it will be more readily received.

See?  I'm trying to help.

---

From: Dave Thaler <[email-masked]>
Date: Fri, 29 Oct 2010 01:31:27 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Christian Huitema
> Sent: Thursday, October 28, 2010 6:29 PM
> To: Fred Baker; Margaret Wasserman
> Cc: Roger Marquis; NAT66 HappyFunBall
> > As Keith points out, to maintain Dynamic DNS AAAA records, the device
> > has to be able to determine its own external addresses. If a static
> > DNS configuration is maintained and privacy addresses do not
> > periodically change (which kind of calls for Dynamic DNS), the DNS service can
> be maintained centrally without the collusion of the addressed systems.
> 
> Another possibility is for the internal system to consider the "external" address
> provided by NAT-66 as a "virtual interface", similar to what would be obtained
> for example by a tunnel to the external gateway. That means the internal
> systems could learn the available address through some configuration function.

That's what SAF is.

> Centralized DHCP servers come to mind, e.g. a DHCPv6 option providing the
> translation value.

Yes, that's one valid SAF mechanism.

-Dave

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 21:44:36 -0400

> NAT66 doesn't interfere in any way with the use of IPv6 privacy addresses.

entirely correct.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 21:52:31 -0400

> Another possibility is for the internal system to consider the "external" address provided by NAT-66 as a "virtual interface", similar to what would be obtained for example by a tunnel to the exter…

Considering only the NAT66 case, I would think an RA extension would be a far preferable way to advertise such things to hosts.  Define a way to associate external prefixes with internal prefixes advertised by routers, in the same packets that advertise the internal prefixes to hosts in the first place.

Though again, I don't think a mechanism that only works for NAT66 would be sufficient.  I think we need a mechanism that works for NAT46 and NAT64 as well.  And therefore it has to be able to handle port translation.  DNS falls apart here because (among many other reasons) it was never intended to advertise transport addresses (i.e address/port pairs).

Keith

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Oct 2010 09:07:23 +0200

Le 28 oct. 2010 à 20:51, Chris Engel a écrit :

> That's exactly the type of scenario most Enterprises DON'T want to see work. In cases of INBOUND connections, Enterprises generally WANT them to fail unless the Enterprise has taken explicit measures to make them work.

Can't FW's  do that without needing address translation;?

> Furthermore, more often then not, when the Enterprise does want them to work, it's going to FORCE said apps to go through some well known, centrally managed point (i.e. some sort of Proxy/ALG) where it can be monitored/audited/controlled and perhaps some policies regarding how it is being used can be enforced.

If some proxy is traversed, what is the use of NAT66?

> 
> In other words, NAT generally isn't breaking anything that the Enterprise doesn't want broken anyway.... and *may* actually be helping to break certain things that would be somewhat more difficult to break without it.

Could you be more precise (asterisks added)?

> This is an area where Enterprises and Transit Providers seem to be entirely different animals with different priorities.

Agreed, but questions about enterprise configurations that really need NAT66 are still legitimate.
 
> "We have a record of every call originating from our network. Searching the call log db we can see that a call was placed to this number at 5:02 PM from Operator #231 at workstation 211 in the Hous…

That's clear.
But WHY would this require address translation?

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Oct 2010 15:16:59 +0200

Hi, all,

Here is a view of where we are, in my understanding, in view of the two parallel discussions on v6ops and NAT66 mailing lists:

1.
- Some consider that some form of NAT66 is useful for some real customer needs. 
- Clear descriptions of which scenarios benefit from which type of NAT66 are however still missing. (At this stage, this seems to only be scenarios where baring all incoming connectivity is found desirable, but more precisions are lacking.)
- If, once documented, such scenarios are convincing, documenting in IETF NAT66 characteristics that fit them will make sense.

2
- Some contributors advocate that "NAT66" should only designate *stateless NAT66*.
- Making clear that "NAT66" may also designate *stateful NAT66* would eliminate ambiguity and misunderstanding we have seen in current discussions. 

3.  
- 6to4-PMT is a proposal to add stateless NAT66's to 6to4 relays (without tool available for customers to know that their 6to4 addresses are now translated).  
- So far, there seems to be no common understanding that this breaks a legitimate use of 6to4 that exist today (6to4 addresses used for incoming connectivity). 
- Unless this understanding would be proved to be wrong, it should justify that IETF doesn't endorse 6to4-PMT. 
- This is despite the recognized improvement 6to4-PMT can bring for other uses of 6to4, because:
   . These uses have known limitations, but they won't get worse with 6to4 relays kept unchanged 
   . The Hippocrates principle for disease treatments still holds: PRIMUM NON NOCERE (en.wikipedia.org/wiki/Hippocratic_Oath)

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Oct 2010 15:37:59 +0200

Hi, Dave,

>> systems could learn the available address through some configuration function.

Agreed (what SAF "was", to be purist ;-))

I hope we can discuss once more, in Beijing, the relationship between "SAF + stateless NAT66", on one hand, and the "multihoming application of SAM" on the other hand (SAM/TRAM as it will now be called, for TRAnsparent Multihoming).

As we noted already, they have much in common.
In my understanding, SAM/TRAM is more complete in that:
- It includes a mechanism for the right CPE selection in case of multihoming with PAs.
- It permits a receiving host to know, when communicating with another host of its site, to know whether the source address used by the source application was its ULA or a global address. 

> Yes, that's one valid SAF mechanism.

Yes, idem for SAM parameters.

Regards,
RD

---

From: Andrew Yourtchenko <[email-masked]>
Date: Fri, 29 Oct 2010 15:48:23 +0200 (CEST)

> users get the privacy they require, freedom from vendor lock-in, and are

I've been watching this discussion with great interest, and I think the above 
may be optimistic.

http://panopticlick.eff.org/ behaves identically with or without NATs.

cheers,
andrew

---

From: Chris Engel <[email-masked]>
Date: Fri, 29 Oct 2010 10:19:22 -0400

> From: Rémi Després [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 3:07 AM
> To: Chris Engel
> Cc: 'james woodyatt'; Roger Marquis; NAT66 HappyFunBall
> > That's exactly the type of scenario most Enterprises DON'T
> want to see
> > work. In cases of INBOUND connections, Enterprises
> generally WANT them
> > to fail unless the Enterprise has taken explicit measures
> to make them
> > work.
>

Yes they can. The point I'm making here is that NAT isn't doing much HARM to the Enterprise since it's not breaking anything they wouldn't want broken anyways. The functionality it provides in this context is to add an extra layer of partial protection in case the FW filter rules fail (i.e. someone misconfigured them). With IPV4 NAT none of the devices with MANY:1 mappings are able to recieve inbound connections even if the FW filters would allow it. Those sort of devices also tend to be the ones most likely to be easly exploitable if they did recieve such traffic.

> > Furthermore, more often then not, when the Enterprise does
> want them
> > to work, it's going to FORCE said apps to go through some
> well known,
> > centrally managed point (i.e. some sort of Proxy/ALG) where
> it can be
> > monitored/audited/controlled and perhaps some policies
> regarding how
> > it is being used can be enforced.
>

NAT tends to break such apps even if the FW rules let them pass. This can be true of OUTBOUND connections as well. For example, it's impractical to impose a DENY HTTP OUT ALL on most workstations simply due to the fact that alot of them will legitimately need web access. Yet it can be difficult for a filter to differentiate between legitimate web traffic and some P2P application encapsulating it's communications in HTTP to bypass FW filters. The filter has to be pretty sophisticated and do some deep packet inspection. Yet even if the filter lets traffic out...if the app is reporting an RFC 1918 address to it's peer...that ip isn't going to be particularly usefull for the peer.... and if the app tries to use some well known external intermediary to facilitate comminications....well you CAN black hole those...unlike some poor dial-up customers DHCP address. Thus NAT helps FORCE such apps to use ALG's setup by the Enterprise Admin in order to work successfully. Granted, it's not a complete solution, as many apps will find a way to work across the NAT boundary....and you are generaly better off trying to control such apps by imposing strict software policies on the individual workstations. However it DOES make it more difficult for Apps to work without some intervention on the Enterprise's part...and for many Enterprises anything that helps do that is a good thing.
>
>
> >
> > In other words, NAT generally isn't breaking anything that the
> > Enterprise doesn't want broken anyway.... and *may* actually be
> > helping to break certain things that would be somewhat more
> difficult
> > to break without it.
>

See above examples.

>
> > This is an area where Enterprises and Transit Providers seem to be
> > entirely different animals with different priorities.
>

Yes they are, but generaly the most informed opinions about that are going to be coming from people actually RUNNING enterprise configurations. Roger is not wrong when he claims that a very large majority of those ARE looking for NAT-like functionality. At least that's been my anecdotal experience from the most of the other people running Enterprises that I've talked to about it.

>
> > Let's look at something like VOIP. From the individual
> consumers point
> > of view the idea that you can sit down at any internet connection
> > anywhere in the world and have a free/low cost voice
> conversation with
> > anyone at an internet connection anywhere else in the world is
> > awesomely cool. However from the perspective of many
> Enterprises this
> > is very problematic for business related calls. Enterprises may
> > require specific things happen in relation to business
> calls (such as
> > monitoring, auditing, recording) that are infinitely harder
> to achieve
> > unless such calls are FORCED to go through a central service.
> >
> > So for example, when customer calls up the company and
> says... "One of
> > your Operators called me up at 2 AM and promised me X".
> The response
> > from IT isn't....
> >
> > "OK we'll try to search through every single workstation in the
> > company, including those which are out for repairs, and see
> If anyone
> > was running Skype at 2 AM....and Oh god, I hope they were following
> > policy and recording the call if they did....and Oh god, I hope
> > someone didn't screw up and let a personal device plug into our
> > network jacks."
> >
> > The response is....
> >
> > "We have a record of every call originating from our network.
> > Searching the call log db we can see that a call was placed to this
> > number at 5:02 PM from Operator #231 at workstation 211 in
> the Houston
> > Branch. Here is the voice-recording of the content of that
> call. Shall
> > I play it for you so that you can hear exactly what was said?"
>
> That's clear.

Doesn't REQUIRE it. But nothing about address translation harms such a usage case...and in some instances it MAY (see above examples) help insure it.

Christopher Engel

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 11:11:27 -0400

> 
> Yes they can. The point I'm making here is that NAT isn't doing much HARM to the Enterprise since it's not breaking anything they wouldn't want broken anyways.

Why should all enterprises have to deal with your extremely simplistic and naive view of what their security needs are and what their security strategy should be?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 11:11:27 -0400

Keith

---

From: Chris Engel <[email-masked]>
Date: Fri, 29 Oct 2010 11:43:12 -0400

> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, October 29, 2010 11:11 AM
> To: Chris Engel
> Cc: 'Rémi Després'; [email-masked]; Roger Marquis; HappyFunBall
> > Yes they can. The point I'm making here is that NAT isn't
> doing much
> > HARM to the Enterprise since it's not breaking anything
> they wouldn't
> > want broken anyways.
>
> Why should all enterprises have to deal with your extremely
> simplistic and naive view of what their security needs are
> and what their security strategy should be?
>
> Keith
>

Who's saying they will?  I'm not forcing them to use NAT anymore then I'm telling them what their FW rules must be...or what OS to standardize their hosts/servers on.

Nowhere, either in this draft or any of the hypothetical cases people have argued for Statefull NAT66 have I seen ANYONE try to argue that there should be ANY standard which REQUIRES an Enterprise to implement any flavor of NAT.

The only argument I've ventured is that there ARE legitimate usage cases for NAT (both the flavor being described in this document and a statefull NAT similar to what exists in IPv4 today). IF that's true, then it would be helpful (IMO) to EVERYONE that some standards be published that provide recommendations on how those technologies might be expected to behave.

If the argument is that an RFC should only be published if the usage case which it describes must be applicable to 100% of the internet community (rather then some subset)...then I think you are going to need to invalidate 99.99999% of the RFC's out there.

Furthermore, if you believe that that the technology goals which I have described are atypical of Enterprises...I will simply state that your experience of the Enterprise environment must run entirely counter to my own.

Christopher Engel

---

From: Chris Engel <[email-masked]>
Date: Fri, 29 Oct 2010 11:43:12 -0400

Christopher Engel

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 14:32:50 -0400

> Who's saying they will?  I'm not forcing them to use NAT anymore then I'm telling them what their FW rules must be...or what OS to standardize their hosts/servers on.

NATs harm everybody, not just those who are forced to sit behind them.  By arguing for NATs to be standardized and used for purposes for which they are not well-suited and not needed, you are trying to promote things that do harm.

> The only argument I've ventured is that there ARE legitimate usage cases for NAT (both the flavor being described in this document and a statefull NAT similar to what exists in IPv4 today). 

you're grossly exaggerating those use cases.  security is NOT a legitimate use case for NAT.   security is NOT enhanced by imposing mechanisms that make network policy enforcement less flexible.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 14:32:50 -0400

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Oct 2010 18:53:30 -0400

On Oct 29, 2010, at 9:16 AM, Rémi Després wrote:
> - Clear descriptions of which scenarios benefit from which type of  
> NAT66 are however still missing. (At this stage, this seems to only  
> be scenarios where baring all incoming connectivity is found  
> desirable, but more precisions are lacking.)
> - If, once documented, such scenarios are convincing, documenting in  
> IETF NAT66 characteristics that fit them will make sense.

I do not consider this to be an accurate summary of arguments in favor  
of publishing NAT66.

The NAT66 document clearly states a use case for NAT66 that does _not_  
rely on blocking all incoming connections:  address independence  In  
discussions on the nat66 list, enterprise administrators have  
confirmed that this is a valid need, and that NAT66 would allow some  
enterprises that are currently blocking on the need for NAT in IPv6 to  
deploy IPv6 in their enterprises.

There _also_ seem to be use cases where enterprise administrators use  
NAT specifically for the purpose of blocking (most or all?) incoming  
connections.  I do not know if we have explored that use cases well  
enough to know if it could be served by a stateful firewall and/or a  
combination of NAT66 and a stateful firewall.  I think it would make  
sense for the IETF to look into those use cases in more detail, as was  
already done for CPE equipment.

> - Some contributors advocate that "NAT66" should only designate  

You are the only person I have heard make that statement.  If others  
hold this opinion, they should share it with me.

> - 6to4-PMT is a proposal to add stateless NAT66's to 6to4 relays  
> (without tool available for customers to know that their 6to4  
> addresses are now translated).

I am unfamiliar with this proposal, so I can't comment on it.

Margaret

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 16:07:18 -0700

On Oct 29, 2010, at 3:53 PM, Margaret Wasserman wrote:

> You are the only person I have heard make that statement.  If others hold this opinion, they should share it with me.

I do. The draft in question is draft-mrw-nat66-nn.txt, and it describes a stateless NAT.

Why do I want that limitation? First, because that is the discussion this list was created to have. Second, because every argument I hear that uses the acronym is about stateful NAT, and the volume of "I have to have..." and "I am absolutely apposed to ..." prevents any discussion of the proposal actually on the table.

As I have said to you many times, I wish you had called it what it is, which is prefix translation or locator translation. Keith thinks that since it changes the locator it is equivalent to network address translation, and I will give him 10% of that point. But unless and until we can have a discussion on the topic that is actually on-topic, I continue to think that the topic we have actually proposed is not being discussed.

There is an alternative. We can create a different list for discussion of stateless network prefix translation, named

    [email-masked]

and abandon this one to "abandon hope all ye who enter here". If we do, I will sign off this list. Except that's what we thought we were building here.

Oh, the 6ai BOF had the same problem. Did you notice that you weren't actually permitted to speak to the topic on the table, other speakers were brought in to confuse the discussion including Remi, who wanted to talk about 6rd tunneling and as always jumped on every venue that opened up with a view to talking about it, and the l-o-n-g line of people at the mike complaining about NATs were all complaining about stateful NAT and often specifically IPv4/IPv4 NAT?

The filibuster is getting Really Old. It would be nice to be able to have an actual technical discussion of the proposal that is actually on the table. For the first time since it was brought up.

---

From: Margaret Wasserman <[email-masked]>
Date: Fri, 29 Oct 2010 19:36:10 -0400

I have objected to the prefix/locator translation name because some  
versions of the document, including the current one, also modify the  
identifier/IID portion of the address.

I think the important distinction here that Remi wants to make (if I  
understand correctly) is not in what part of the address is  
translated, but in the fact that this translation is algorithmic and  
reversable and does not require any sort of per-flow state.  The  
devices is _not_ stateless, however, because as others have pointed  
out there is configured state.

So, if it is felt we need a special qualifier in the title of the  
document to distinguish this from other types of NAT, I could go for  
"Algorithmic NAT66"... Would that address the concerns that you and  
Remi have about calling it simply "NAT66"?

Margaret

On Oct 29, 2010, at 7:07 PM, Fred Baker wrote:

>> You are the only person I have heard make that statement.  If  
>> others hold this opinion, they should share it with me.
>
> Why do I want that limitation? First, because that is the discussion  
> this list was created to have. Second, because every argument I hear  
> that uses the acronym is about stateful NAT, and the volume of "I  
> have to have..." and "I am absolutely apposed to ..." prevents any  
> discussion of the proposal actually on the table.
>
> As I have said to you many times, I wish you had called it what it  
> is, which is prefix translation or locator translation. Keith thinks  
> that since it changes the locator it is equivalent to network  
> address translation, and I will give him 10% of that point. But  
> unless and until we can have a discussion on the topic that is  
> actually on-topic, I continue to think that the topic we have  
> actually proposed is not being discussed.
>
> There is an alternative. We can create a different list for  
> discussion of stateless network prefix translation, named
>
> and abandon this one to "abandon hope all ye who enter here". If we  
> do, I will sign off this list. Except that's what we thought we were  
> building here.
>
> Oh, the 6ai BOF had the same problem. Did you notice that you  
> weren't actually permitted to speak to the topic on the table, other  
> speakers were brought in to confuse the discussion including Remi,  
> who wanted to talk about 6rd tunneling and as always jumped on every  
> venue that opened up with a view to talking about it, and the l-o-n- 
> g line of people at the mike complaining about NATs were all  
> complaining about stateful NAT and often specifically IPv4/IPv4 NAT?
>
> The filibuster is getting Really Old. It would be nice to be able to  
> have an actual technical discussion of the proposal that is actually  
> on the table. For the first time since it was brought up.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Oct 2010 13:43:13 +1300

Maybe "Deterministic NAT66" is even clearer. But really we
need to call it "Not NAPT66" to avoid irrelevant discussions.
That's the basic problem of the quarrel we've been having.
People who want to discuss NAPT66 as an alternative to
RFC 4864 and draft-ietf-v6ops-cpe-simple-security should
really not be discussing draft-mrw-nat66.

Regards
   Brian Carpenter

On 2010-10-30 12:36, Margaret Wasserman wrote:
> understand correctly) is not in what part of the address is translated,
> but in the fact that this translation is algorithmic and reversable and
> does not require any sort of per-flow state.  The devices is _not_
> stateless, however, because as others have pointed out there is
> configured state.
> 
> "Algorithmic NAT66"... Would that address the concerns that you and Remi
> have about calling it simply "NAT66"?
> 
> Margaret
> 
>> that uses the acronym is about stateful NAT, and the volume of "I have
>> to have..." and "I am absolutely apposed to ..." prevents any
>> As I have said to you many times, I wish you had called it what it is,
>> which is prefix translation or locator translation. Keith thinks that
>> since it changes the locator it is equivalent to network address
>> translation, and I will give him 10% of that point. But unless and
>> until we can have a discussion on the topic that is actually on-topic,
>> I continue to think that the topic we have actually proposed is not
>> being discussed.
>>
>> There is an alternative. We can create a different list for discussion
>> of stateless network prefix translation, named
>>
>> Oh, the 6ai BOF had the same problem. Did you notice that you weren't
>> actually permitted to speak to the topic on the table, other speakers
>> were brought in to confuse the discussion including Remi, who wanted
>> to talk about 6rd tunneling and as always jumped on every venue that
>> opened up with a view to talking about it, and the l-o-n-g line of
>> people at the mike complaining about NATs were all complaining about
>> stateful NAT and often specifically IPv4/IPv4 NAT?
>>

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 17:45:12 -0700

On Oct 29, 2010, at 4:36 PM, Margaret Wasserman wrote:

> I could go for "Algorithmic NAT66"... Would that address the concerns that you and Remi have about calling it simply "NAT66"?

Or "stateless".

Anything that would distinguish it from stateful network address translation, which is what triggers the filibuster and prevents discussion of the actual proposal.

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Oct 2010 17:46:52 -0700

> really not be discussing draft-mrw-nat66.

Yes. But I can't get them to stop DDOSing the discussion.

---

From: Rémi Després <[email-masked]>
Date: Sat, 30 Oct 2010 09:34:10 +0200

Le 30 oct. 2010 à 00:53, Margaret Wasserman a écrit :

> I do not consider this to be an accurate summary of arguments in favor of publishing NAT66.
> 
> The NAT66 document clearly states a use case for NAT66 that does _not_ rely on blocking all incoming connections:  address independence  

In my understanding, address independence is a (useful) "feature", but not a "use case" per se.
The complete description of a use case would permit to discuss.

The draft says (asterisks added): "NAT66 provides a simple and *compelling* solution to meet the Address Independence requirement in IPv6".
I don't see this a compelling at all.
SAM, applied to IPv6-in-IPv6 tunneling (the SAM/TRAM application), does provide Address Independence and, to hosts that support it, does it without sacrificing incoming connectivity.
(BTW, I will be happy to answer any clarification questions you may have about SAM, in Beijing in particular.)

> In discussions on the nat66 list, enterprise administrators have confirmed that this is a valid need, and that NAT66 would allow some enterprises that are currently blocking on the need for NAT in IPv6 to deploy IPv6 in their enterprises.

I don't think I negated that.
Yet, I am interested in looking to the explicit configuration and functional requirement of at least one of them, so that we can ask for clarification on what we don't understand. 
(In particular, it isn't clear to me that, in their particular cases, they couldn't remain IPv4-only until more complete solutions are available.)

> There _also_ seem to be use cases where enterprise administrators use NAT specifically for the purpose of blocking (most or all?) incoming connections.  I do not know if we have explored that use cases well enough to know if it could be served by a stateful firewall and/or a combination of NAT66 and a stateful firewall.  I think it would make sense for the IETF to look into those use cases in more detail, as was already done for CPE equipment.

Agreed.

> You are the only person I have heard make that statement.

Yet the statement is true, unless you negate that "Some contributors advocate that "NAT66" should only designate *stateless NAT66*.

>  If others hold this opinion, they should share it with me.

I read several e-mails including talking about "stateful NAT66".
In my understanding, stateful NAT66 is generally understood as a particular case of NAT66.
If this is so, NAT66 can't designate ONLY stateless NAT66.
I haven't heard arguments against this logic.

If opinions are shared on this subject, it should IMHO be shared *on the list*.

> I am unfamiliar with this proposal, so I can't comment on it.

You could ask James Woodyatt (a great friend of 6to4), or look at what he wrote to v6ops, to see how harmful it would be to 6to4.

Regards,
RD

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 13:39:43 +0200

Thus wrote Andrew Yourtchenko ([email-masked]):

> I've been watching this discussion with great interest, and I think
> the above may be optimistic.
> 

Application layer gateways that understand what they are transporting tend
to be better at this game, which is why I'd prefer using them where ever
available over any methods that munge packet headers but don't look at the
payload.

Especially with the case of hiding a web server (or web servers) and mail
servers behind one stable address (as far as your provider agreements let
you), setting up a reverse proxy (if not a fully-fledged WAF) and a
filtering mail relay beats plain stateful NATs by a lot.

That requires application gateways to be available, though, and they incur
extra cost (device, power, cooling, maintenance), so may not be practical
for everybody.

To get back to the topic of the proposal (stateless nat66 prefix
translation), and no longer referring to the cited mail:

I could cover my strict business needs with a selection of proxies
and telling users who need to connect to anything in the Internet
by other means to either cough up the money for the application gateway
or to use their phone. Mind that connections to business partners
don't fall under this heading because they run through IPSEC tunnels,
and my ULA net talking to their ULA net is expected to work just fine.

I would like to do somewhat better regarding Internet traffic, though.

I can get a situation where I can let users machines directly connect
to some outside services if I get prefix translation. It has the
benefit that it does as little to the packet as it can get away with,
and that appeals to me from a simple-is-good aesthetic.

Using stateful NAT would not fix anything I want to achieve, because I
have better options to achieve what it would bring me. That is, of course,
just one data point.

I have a use case for port redirection (eg bouncing traffic to port 80
to port 8080), but I wouldn't necessarily consider that in scope for
this list (addresses don't get translated :).

So please consider me a proponent of the draft as is, modulo a few typos,
and +1 on "this isn't stateful NAT" clarification on the abbreviation.

regards,
	spz
-- 
[email-masked] (S.P.Zeidler)

---

From: Scott Brim <[email-masked]>
Date: Sat, 30 Oct 2010 08:30:02 -0400

Fred Baker allegedly wrote on 10/29/2010 19:07 EDT:
> this list was created to have.

Agree completely with this.  "NAT66" was originally bound to a stateless
approach and that binding should hold precedence unless overwhelmed by
what latecomers say.

> do, I will sign off this list. Except that's what we thought we were

I suppose <groan>.

Alternatively keep the name the same but fix the list description, currently

  The purpose of this list is to discuss the needs that may drive the
  adoption of IPv6-to-IPv6 NAT, and to discuss solutions to meet those
  needs, possibly including specification of an IPv6 NAT mechanism,
  that will work better and be less harmful to the Internet than direct
  ports of IPv4 NA(P)T functionality.

, so that new subscribers know exactly what it is about.

Margaret Wasserman allegedly wrote on 10/29/2010 19:36 EDT:
> The devices is _not_

That's just a quibble about the use of "state", and not directly related
to the essential nature of the behavior.  That's a different kind of
state, in that it is not associated with individual endpoints or flows.

> have about calling it simply "NAT66"?

I could tolerate "algorithmic", since it could mean lots of things so
people will have to ask.  Be careful of being abbreviated ANAT.

Scott

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 19:28:13 +0200

> - Clear descriptions of which scenarios benefit from which type of NAT66 are however still missing. (At this stage, this seems to only be scenarios where baring all incoming connectivity is found d…

A case for stateless prefix translation with the intention to pick the
correct source address for a given connection:

Site A:
                         /-- FWE-A1 -- Provider A1
Internal -- FWI-A -- DMZ  -- FWE-A2 -- Provider A2
   |                     \-- FWE-A3 -- Provider A3
   |
Site B:
   |
Internal -- FWI-B -- DMZ  -- FWE-B1 -- Provider B1
                         \-- FWE-B2 -- Provider B2

The DMZs contain IPSEC tunnel routers, mail relays, web proxies and
reverse proxies for services where the users know there are alternates
(and to pick foo2 or foo3 if foo1 is slow or unavailable).
The DMZs are not flat, and use both private and public addresses.

"Internal" is supposed to run on ULA in the future, as are the destinations
of the IPSEC tunnels (so tunneled communications never need renumbering).
The DMZs get a snippet of the local ULA, so communications that
don't cross the external firewalls also never need renumbering.

Prefix translation would happen on the external firewalls for selected
parts of the ULA space:
There are hosts on the internal network that communicate with partners
not through a IPSEC tunnel router but that open their own individual
secured connections. A simple default route would not allow to pick the
best upstream to reach a given partner. Expecting the hosts in the internal
network to be able to cope with two dozen routes and 6 prefixes announced
via RA faultlessly is naive IMHO, expecting fast failover in case one
upstream breaks even more so. The network admin does not administrate the
internal hosts, and the admins of the hosts are by no means network admins.

Rerouting will break all previous connections for the route that gets
changed. Expected reason for such a change is a network outage. This will
create some colorful cursing from the affected users, but not too much
damage if they can re-open their connections via a different path within
5 minutes or so; waiting half an hour OTOH would be too slow.

Automation via monitoring, at present, with v4, switches routes ons
the internal firewalls (plus other cleanup) if tests indicate that
an outside link went missing, within the acceptable timeframe.

Using PI and an AS would be technically simple and even prevent breaking
of connections, but would cost significantly more.

Without prefix translation and PI, the realistic method is to set up
vhosts that have a decent static network config for a communication partner
that can be changed by automation, and have the users connect remotely
from their desktops. This gives us extra DMZ hosts, extra management
effort (thus, extra cost) and is annoying for the users.
Being able to connect to a news server via nntp or similar would probably
not have enough of a business case to be implemented; currently that's
allowed to 'reputable' destinations since it costs nothing extra now.

Cost considerations will likely make us use translation whether it's
standardized or not. Currently available translation is stateful, which is
more interference with the packets than needed here.

regards,
	spz

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Oct 2010 19:22:30 -0400

> approach and that binding should hold precedence unless overwhelmed by

Just like the word "hacker" was originally NOT used to refer to someone acting out of malice or recklessness.  We know how well that worked out.

Look, this proposal really does look to be significantly useful.  If the authors can see their way to putting in some sort generalizable support for letting hosts/apps find out their external/global addresses (by generalizable, I mean a protocol that can be extended for stateful NA[p]T and NA[p]T between v4 and v6 also), I'm inclined to support it.  

But insisting that it be named a particular way doesn't help the protocol work better, and it really does seem to hinder understanding of the protocol.  I'd hate to see this protocol fail to get due consideration in the wider community because people didn't understand what it did because of the name.  I've made that mistake before too, more than once actually, and in both cases my choice of name made it far more difficult for people to look at the proposal itself.  

The name of the proposal is surely the least important aspect from a technical point-of-view.  Names are for marketing.  Please chose another name that is optimized to help people understand what this does.

Keith

---

From: Fred Baker <[email-masked]>
Date: Sat, 30 Oct 2010 16:39:43 -0700

On Oct 30, 2010, at 4:22 PM, Keith Moore wrote:

>  If the authors can see their way to putting in some sort generalizable support for letting hosts/apps find out their external/global addresses (by generalizable, I mean a protocol that can be extended for stateful NA[p]T and NA[p]T between v4 and v6 also), I'm inclined to support it.  

I'm not at all opposed to doing that, and have already contacted the behave chairs for advice. I actually do think that's a protocol, separate from the function of the translator, but I have no problem with its existence. I do have a question why; from statements made in this forum, the reason seems to be "in order to populate dynamic dns correctly" and "in order to know the external address(es) of a peer that I will refer sessions to". Is that a correct summary?

I do have a problem with one aspect of that, though, which is that you want the mechanism to be the same for stateful translators that will potentially come up up with a different TCP four-tuple per session AND apply to the stateless (configured but no dynamic state, with no port translation) version. With NAT66 as specified, you can do this once and know the values until you have a change of hardware or your company has a change of contract. If you're doing NA(P)T and the NAT is configured with a set of addresses on its public side, you have to do it per session. I'm not convinced you want the same solution for both. I understand why you would like me to provide one, but I'm honestly not sure you really want one. Think that assymetry through and tell me that you really want to design your software so that something you can do daily or weekly has to be done for each of the 10-20 sessions that potentially open when you click on a web link, and I'll think about that.

I continue to wonder - if remote systems find it adequate to do a reverse DNS lookup to validate an IP address by associating it with a DNS name, why local systems can't do a DNS query "once and know the values until the peer has a change of hardware or your company has a change of contract" to find what addresses that name might have associated with it. No, not a great idea per session. But I'm not looking at something that changes per session.

If that's not adequate - and no, I don't accept "it's not adequate" as an answer, I'd really like an explanation, because I don't see why not in the stateless case - then I find myself thinking in terms of ICMP or something akin to it. If I could send a datagram that would follow the same path to the same DMZ, perhaps as an anycast or multicast, and get zero or more responses saying "I would have changed your source address to []", would that be adequate?

---

From: Keith Moore <[email-masked]>
Date: Sun, 31 Oct 2010 01:31:18 -0400

> I'm not at all opposed to doing that, and have already contacted the behave chairs for advice. I actually do think that's a protocol, separate from the function of the translator, but I have no pro…

I agree that the protocol is separate from the function of the translator.  I'm not sure of the best way to proceed, though.  I want the control/query protocol something that can stand on its own and apply to all NATs rather than just NAT66.  But I doubt that you want to make NAT66 dependent on approval of a generalized new protocol especially when NAT66 doesn't need that generality.  Offhand I'm thinking that the thing to do is to define an interface for NAT66 that can be extended into a general purpose interface to NATs in general.

Knowing the external address(es) to give to a peer is for me the primary justification for such a protocol.   Populating DDNS correctly only applies to the stateless 1-1 NAT case which of course is true for your proposal.  It would not apply to other use cases for such a protocol.

> I do have a problem with one aspect of that, though, which is that you want the mechanism to be the same for stateful translators that will potentially come up up with a different TCP four-tuple per session AND apply to the stateless (configured but no dynamic state, with no port translation) version.

Right.   I have done a bit of work in this area in conjunction with an earlier proposal that I did.  I think it suffices if the request is something that can be meaningful for both stateless and stateful NAT (also for NAT and NAPT) and the response from the NAT can be different for different kinds of NAT.  But obviously the details would have to be worked out.

> With NAT66 as specified, you can do this once and know the values until you have a change of hardware or your company has a change of contract. If you're doing NA(P)T and the NAT is configured with a set of addresses on its public side, you have to do it per session. I'm not convinced you want the same solution for both. I understand why you would like me to provide one, but I'm honestly not sure you really want one. Think that assymetry through and tell me that you really want to design your software so that something you can do daily or weekly has to be done for each of the 10-20 sessions that potentially open when you click on a web link, and I'll think about that.

If you're writing an application that interacts with a NAT, you want it to be general enough to work with any kind of NAT that supports this kind of mechanism, so you're probably going to do it once per session anyway.   Maybe if the first response you get back says "the mapping is 1-1 and algorithmic and will never change" you can optimize and not bother to do the query again for any addresses in that range, but your code has to potentially be able to do it.  

If you're trying to put code into a host stack to support this semi-transparently (sort of like RSIP) you'd probably do the optimization rather than issue a query either time.  But my main goal is to provide applications with a uniform interface for dealing with NAT without requiring them to have a server in the core of the network.

> I continue to wonder - if remote systems find it adequate to do a reverse DNS lookup to validate an IP address by associating it with a DNS name, why local systems can't do a DNS query "once and kn…

I'm not sure what any of this has to do with validating an IP address.  Nor do I know of any purpose for which it's "adequate" to do a reverse DNS lookup.  Lots of apps do such lookups, but the results are not an assurance of much of anything.  In particular you can't expect hosts to be listed in DNS in either forward or reverse zones.  It's just not generally true in practice that they are.

> If that's not adequate - and no, I don't accept "it's not adequate" as an answer, I'd really like an explanation, because I don't see why not in the stateless case - then I find myself thinking in…

I need to go back and look over my notes from before when (if I recall correctly) I worked this out in detail.  I seem to remember that there were some constraints on how this had to work, but I don't remember what they were.

Keith

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sun, 31 Oct 2010 14:19:45 +0100

Hi,

Thus wrote Fred Baker ([email-masked]):

> I do have a problem with one aspect of that, though, which is that you want the mechanism to be the same for stateful translators that will potentially come up up with a different TCP four-tuple per session AND apply to the stateless (configured but no dynamic state, with no port translation) version. With NAT66 as specified, you can do this once and know the values until you have a change of hardware or your company has a change of contract. 

Only if the packets pass the same algorithmic NAT. They may not.

[...]

> If that's not adequate - and no, I don't accept "it's not adequate" as an answer, I'd really like an explanation, because I don't see why not in the stateless case - then I find myself thinking in…

That would probably be necessary.

regards,
	spz

---

From: JFC Morfin <[email-masked]>
Date: Sun, 31 Oct 2010 15:43:31 +0100

ICANN use to introduce itself as follows: "ICANN's mission is to 
ensure a stable, secure and unified global Internet. To reach another 
person on the Internet you have to type an address into your computer 
- a name or a number. That address has to be unique so computers know 
where to find each other. ICANN coordinates these unique identifiers 
across the world. Without that coordination we wouldn't have one 
global Internet. ICANN [] participants from all over the world [are] 
dedicated to keeping the Internet secure, stable and interoperable. 
It promotes competition and develops policy on the Internet's unique 
identifiers."

I am not interested in discussing this text. However, I am interested 
in seeing addressed the confusion introduced in the (GAC) governments 
decision makers and (ISP customers) purchasers' mind when proposed 
IPv6 and/or NAT66 and/or ICANN addresses that have to be unique for 
the Internet to be stable, secure and unified/interoperable on a global basis.

There is a need for a single, simple, clear sentence, in tune with 
the ICANN's claim, able to make people understand what are the 
purpose, the risks and the legitimacy of nat66.
jfc

---

From: james woodyatt <[email-masked]>
Date: Sun, 31 Oct 2010 08:01:03 -0700

On Oct 31, 2010, at 06:19 , S.P.Zeidler wrote:
> [Fred Baker] writes:
>> 
>> If I could send a datagram that would follow the same path to the same DMZ, perhaps as an anycast or multicast, and get zero or more responses saying "I would have changed your source address to []", would that be adequate?
> 

But not sufficient.  Evidence that a NAT was there in the not-so-distant past is not an assurance from the network that a NAT won't be changing in the not-so-distant future.

---

From: Roger Marquis <[email-masked]>
Date: Sun, 31 Oct 2010 09:11:44 -0700 (PDT)

Keith Moore wrote:
>> The only argument I've ventured is that there ARE legitimate usage cases
>> for NAT (both the flavor being described in this document and a statefull
>> NAT similar to what exists in IPv4 today).
> 
> you're grossly exaggerating those use cases. security is NOT a legitimate
> use case for NAT. security is NOT enhanced by imposing mechanisms that make
> network policy enforcement less flexible.

Keith,

Such extreme statement do need to be backed-up with evidence to be taken
seriously.  Your opinion condradicts 99% of current practices including
sites with no other use for NAT than security.

So please do backup your statements with a list, preferably a long one,
of real world examples of large sites that are getting on without NAT.

Roger Marquis

---

From: Roger Marquis <[email-masked]>
Date: Sun, 31 Oct 2010 09:11:44 -0700 (PDT)

Keith,

Roger Marquis

---

From: Fred Baker <[email-masked]>
Date: Sun, 31 Oct 2010 09:38:52 -0700

> Only if the packets pass the same algorithmic NAT. They may not.

Well, one going to the same upstream. If you have multiple DMZs using the same configuration, they will come up with the same result.

---

From: Fred Baker <[email-masked]>
Date: Sun, 31 Oct 2010 09:58:45 -0700

> of real world examples of large sites that are getting on without NAT.

one has to define "without NAT". If you mean "without NAT between the network and the upstream, as a security procedure", Cisco is on that list. We have NAT internally as a way to use RFC 1918 addresses in addition to those we have had allocated by our RIRs, but that isn't even address amplification per se.

---

From: Fred Baker <[email-masked]>
Date: Sun, 31 Oct 2010 09:58:45 -0700

---

From: james woodyatt <[email-masked]>
Date: Sun, 31 Oct 2010 10:50:02 -0700

> one has to define "without NAT". If you mean "without NAT between the network and the upstream, as a security procedure", Cisco is on that list. We have NAT internally as a way to use RFC 1918 addr…

You'd also have to count Apple, whose enterprise network is numbered for IPv4 from its legacy 17/8 allocation and for IPv6 from its PI space obtained from ARIN.  All the various boxen on my desk in Cupertino have globally routed IPv4 and IPv6 addresses today.  No NAT used at all.  (Even the WiFi on the commuter shuttle assigns a globally routed non-translated address.)

---

From: Keith Moore <[email-masked]>
Date: Sun, 31 Oct 2010 18:51:46 -0400

> sites with no other use for NAT than security.

I'm taking you far more seriously than you deserve.  

Security experts don't recommend particular practices just because other people recommend them.  They make recommendations based on whether they make good sense for the situation at hand.

You're confusing engineering with fashion.   If you want to be a lemming, feel free, but this is not the place to do it.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 31 Oct 2010 18:51:46 -0400

Keith