Subject: Re: [nat66] Fwd: New Version Notification for draft-mrw-nat66-00

From: Roger Marquis <[email-masked]>
Date: Thu, 21 Oct 2010 12:43:45 -0700 (PDT)

"S.P.Zeidler" wrote:
> Remains the question why you'd bother with NAT66? What advantage does it
> deliver over using the public addresses directly?

This question has been answered many times in many forums.  Please refer
to arin-ppml and/or nanog for reasons why nat66, or some other form of
nat, is prerequisite to IPv6 uptake.  The nat66 list is really not the
proper forum for this particular question.

IMO,
Roger Marquis

---

From: "S.P.Zeidler" <[email-masked]>
Date: Fri, 22 Oct 2010 00:58:57 +0200

> proper forum for this particular question.

You are citing me out of context.
  
Why would you use NAT66 in a way where you renumber the internal network
each time the (in that model, by necessity, singular) external prefix
changes? i.e. when it gives you neither address independence nor delayed
routing decision advantages? While still being stateless, so not serving
as cheap connection diode either?
   
Does -that- have multiple answers on NANOG etc?

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

---

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

> You are citing me out of context.

Evidently, and thanks for the correction.

> Does -that- have multiple answers on NANOG etc?

:-)  I bet it does not.

Roger

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 09:55:47 +0200

Le 21 oct. 2010 à 21:43, Roger Marquis a écrit :

> nat, is prerequisite to IPv6 uptake.

IPv6 has been extensively deployed by Free in France since december 2007, and later by SoftBank in Japan, without NAT66.
This is enough, in my understanding, to contradict that NAT66 is a "prerequisite to IPv6 uptake".

Besides, breaking e2e address transparency is the worse that can happen to discourage people to deploy and use IPv6.

>  The nat66 list is really not the

This is then not the proper forum either to say that NAT66 is a prerequisite to IPv6 uptake.
Right?

RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2010 13:17:21 +0200

Hi,

> This is enough, in my understanding, to contradict that NAT66 is a "prerequisite to IPv6 uptake".

Different target customers.  For "end user" customers, NAT66 is no longer
needed or desirable - but Petra (in this thread) is talking about medium
sized enterprises that do not want a slot in the global routing table, 
and at the same time want to be multihomed to multiple providers, and 
*not* have multiple /64s on every LAN in the enterprise.

> Besides, breaking e2e address transparency is the worse that can happen 
> to discourage people to deploy and use IPv6.

Enterprises do not want e2e transparency regarding their networks - they
want well-controlled and well-regulated communications, managed by a 
border gateway device (call it firewall, nat box, ...).

Gert Doering
        -- NetMaster
-- 
did you enable IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 13:59:47 +0200

Le 25 oct. 2010 à 13:17, Gert Doering a écrit :

> ... Petra (in this thread) is talking about medium

That's what tools.ietf.org/html/draft-despres-softwire-sam-01 sec. 3.3 is about.
Provided hosts support it:
- e2e addresses are preserved
- it works even with an independent CPE per ISP (which isn't the case with NAT66)

I didn't find the time to write a new draft on just this case for Beijing, but I plan it for after IETF 79.
The intention is to call it TRANsparent Multihoming (TRAM), a name discussed with Dan Wing in Maastricht.
  
If you take time to look at the SAM draft, your reactions will be most welcome. 

> border gateway device (call it firewall, nat box, ...)

Where they are desired, firewalls have to do their own work (they by no means need addresses translation for this).

Per se, the stateless mechanism proposed by Margaret and Fred in their NAT66 draft, does break e2e address preservation, but doesn't do anything to prevent incoming calls. (Their NAT66 draft says: "RECOMMENDED that NAT66 devices include an IPv6 firewall function, and the firewall function SHOULD be configured by default to block all incoming connections."). 

Regards
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 09:03:17 -0400

> - it works even with an independent CPE per ISP (which isn't the  

Could you explain what you mean here?  As long as both devices support  
NAT66, NAT66 should work fine in this environment, AFAIK.

> Where they are desired, firewalls have to do their own work (they by  
> no means need addresses translation for this).
>
> Per se, the stateless mechanism proposed by Margaret and Fred in  
> their NAT66 draft, does break e2e address preservation, but doesn't  
> do anything to prevent incoming calls. (Their NAT66 draft says:  
> "RECOMMENDED that NAT66 devices include an IPv6 firewall function,  
> and the firewall function SHOULD be configured by default to block  
> all incoming connections.").

This is stated specifically to discourage vendors from shipping a  
product that, by default, blocks all incoming connections for IPv4  
(due to the IPv4 NAT functionality) and does not block inbound  
connections for IPv6.  The advantage to separating the NAT and  
firewall functionality, though, is that with NAT66, enterprise  
administrators _can_ enable whatever inbound connectivity they like.   
Every node can be made accessible on all of its available ports, using  
a  a distinct address per node.

At the time I wrote this, the v6ops group was (I think) recommending  
that all sites deploy firewall functionality in IPv6.  I've been told  
more recently that I should check what those recommendations actually  
were, to make sure I am aligned and/or reference them rather than  
stating the recommendation here, which would be fine with me.

Margaret

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 15:35:32 +0200

Le 25 oct. 2010 à 15:03, Margaret Wasserman a écrit :

> Could you explain what you mean here?  As long as both devices support NAT66, NAT66 should work fine in this environment, AFAIK.

OK, I could have explained more what I was referring to.
This relates to ingress filtering.
If a host sends a packet, it has no way, with NAT66 to make sure it goes to the right CPE (that of the ISP whose prefix is at the beginning of the source address. 

> This is stated specifically to discourage vendors from shipping a product that, by default, blocks all incoming connections for IPv4 (due to the IPv4 NAT functionality) and does not block inbound connections for IPv6.

IMHO, for unmanaged CPE's they should rather be encouraged than discouraged:
- Free's customers have been using such products successfully for years now. 
- Being among them, I prefer this product behavior to that you suggest.
- If punching holes in CPEs become as necessary in IPv6 as in IPv4 to have incoming connections, the main advantage of IPv6 is lost.

Every OS that supports IPv6 has AFAIK its internal FW, at least to the point where its doesn't accept unwanted incoming connections.

>  The advantage to separating the NAT and firewall functionality, though, is that with NAT66, enterprise administrators _can_ enable whatever inbound connectivity they like.  Every node can be made accessible on all of its available ports, using a  a distinct address per node.

> At the time I wrote this, the v6ops group was (I think) recommending that all sites deploy firewall functionality in IPv6.

I consistently opposed that.
Fortunately it has become a vendor responsibility to decide whether unmanaged CPEs are shipped with transparent mode by default or not.

My hope is that the majority of vendors of IPv6-capable unmanaged CPEs will understand that the transparent mode is the one that favors IPv6 deployment:
- no need to manage CPEs to take advantage of incoming connectivity
- unwanted incoming connectivity is filtered by OS internal firewalls

>  I've been told more recently that I should check what those recommendations actually were, to make sure I am aligned and/or reference them rather than stating the recommendation here, which would be fine with me.

IMHO, a reference would be better than alignment (but both work for me).

Regards,
RD

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 09:51:37 -0400

Hi Remi,

On Oct 25, 2010, at 9:35 AM, Rémi Després wrote:
>> Could you explain what you mean here?  As long as both devices  
>> support NAT66, NAT66 should work fine in this environment, AFAIK.
>
> If a host sends a packet, it has no way, with NAT66 to make sure it  
> goes to the right CPE (that of the ISP whose prefix is at the  
> beginning of the source address.

What problem are you trying to solve here?

(1) You want the internal host to control what ISP is used to send a  
packet based?

OR

(2) You don't care which ISP is used, but you don't want packets to be  
thrown away by ingress filters?

Problem (1) is an internal routing problem, and I don't see how NAT66  
makes this problem any harder, or any easier, than it would be without  
NAT66.

Problem (2) is an a source address selection problem, and NAT66 will  
resolve this issue by translating the source address of the packet to  
an address in the right prefix for that ISP.  So, as long as the NAT66  
box is configured with the correct global prefix for the ISP it  
connects to, ingress filtering is not a problem.  This is actually a  
significant advantage of NAT66, because unlike the end host, the NAT66  
device is perfectly situated in the network to know which source  
address prefix should be used for a given packet.

> My hope is that the majority of vendors of IPv6-capable unmanaged  
> CPEs will understand that the transparent mode is the one that  
> favors IPv6 deployment:

I think that it's likely to be the case for some time that all of the  
vendors of IPv6 CPEs are really vendors of IPv4/IPv6 CPEs.  So, they  
are not going to be motivated to do something that "favors IPv6  
deployment", they are going to be motivated to do things that work  
well for their customers.
>
>> I've been told more recently that I should check what those  
>> recommendations actually were, to make sure I am aligned and/or  
>> reference them rather than stating the recommendation here, which  
>> would be fine with me.
>

Okay.  Thanks.

Margaret

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 07:01:11 -0700

On Oct 25, 2010, at 6:51 AM, Margaret Wasserman wrote:

> (1) You want the internal host to control what ISP is used to send a packet based?
> 
> OR
> 
> (2) You don't care which ISP is used, but you don't want packets to be thrown away by ingress filters?

Both problems are solved if one implements RFC 3704. The next question is how to implement it; in one internet draft that I didn't pursue, I suggested that a multi-path default route could be discriminated based on the source address; what RFC 3704 looks at it tunnels among the egress gateways with policy routing - if a packet gets to the wrong gateway, it is thrown into a tunnel to the right one.

Of course, NAT66 eliminates ingress filtering as a question, as the source address is forced to a prefix that won't be filtered.

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 16:25:00 +0200

> Problem (1) is an internal routing problem, and I don't see how NAT66 makes this problem any harder, or any easier, than it would be without NAT66.

Without translation, hosts know global addresses they have for each of the ISPs.
They can then chose those that have the longest match with destination addresses. 
Then, they need packets to go via the right CPEs.
That's what I had in mind.

But you are right, since hosts of the NAT66 model only use their private addresses, they have no conflict with ingress filtering.
My statement needs therefore to be corrected by deleting the parenthesis in "it works even with an independent CPE per ISP (which isn't the case with NAT66)".
Thanks for pointing this out.

> Problem (2) is an a source address selection problem, and NAT66 will resolve this issue by translating the source address of the packet to an address in the right prefix for that ISP.  So, as long as the NAT66 box is configured with the correct global prefix for the ISP it connects to, ingress filtering is not a problem.  This is actually a significant advantage of NAT66, because unlike the end host, the NAT66 device is perfectly situated in the network to know which source address prefix should be used for a given packet.
> 
> I think that it's likely to be the case for some time that all of the vendors of IPv6 CPEs are really vendors of IPv4/IPv6 CPEs.  So, they are not going to be motivated to do something that "favors IPv6 deployment", they are going to be motivated to do things that work well for their customers.

Well, if they don't want to "favor IPv6 deployment", that's their problem.
Being myself a real friend of IPv6 (convinced that it will promote growth of the Internet business), I rather spend my energy to increase native IPv6 use cases, than to make IPv6 purposely worse.

Now, considering that working with hosts using global IPv6 addresses "doesn't work well for customers", is contrary to my experience as a user of Free.fr since 2008.
IMHO, stating it can only increase unjustified FUD about IPv6.
 
regards,
RD

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 10:37:19 -0400

It's a little off subject, but vendors are going to do whatever they think serves thier customers best. I'm not sure what, if anything, that would have to do with a NAT66 standard.

Vendors who are concerned about thier clients security are not going to offload responsibility for that security entirely on the OS, that would be irresponsible of them. It's well known in security that a best practice is to provide multiple layers of defence...that would mean blocking packets at the network boundary (CPE) AND on the individual device level. This becomes especialy important in the IPv6 world...where we are starting to see OS's and devices come enabled with IPv6 connectivity by default...and your average end user may not even be aware that such connectivity exists, let alone how to account for protecting it. IPv6 is a huge security time bomb, waiting to happen...as has been written about by many security proffesionals.

Regardless, that has very little to do with NAT66. The flavor of NAT, the authors are proposing here neither prevents nor mandates filters which would block traffic. A mention or reference about security issues sounds like a pretty responsible thing for the authors to do...since NAT in IP4 featured statefull inspection and at least many to one NAT (the type I would actualy like to see exist in IPv6) had some functionality to block incoming connections by default. Many organizations relied on this as an extra layer of protection for thier internal infrastructure..... and many vendors (wrongly) used it on CPE as a weak sort of firewall. Most folks I think should be able to figure out from the fact this is stateless, that such functionality has been depricated. However, I don't see anything wrong with the authors mentioning that it may be prudent to consider FW filters for blocking incoming connections if a vendor wanted to recover some of that same functionality that existed in IPv4 Dynamic NAT.

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Rémi Després
> Sent: Monday, October 25, 2010 9:36 AM
> To: Margaret Wasserman
> Cc: Roger Marquis; [email-masked]
> Subject: [SPAM] - Re: [nat66] Fwd: New Version Notification
> for draft-mrw-nat66-00 - Email has different SMTP TO: and
> MIME TO: fields in the email addresses
>
>
>
> >> That's what tools.ietf.org/html/draft-despres-softwire-sam-01 sec.
> >> 3.3 is about. Provided hosts support it:
> >> - it works even with an independent CPE per ISP (which
> isn't the case
> >> with NAT66)
> >
> If a host sends a packet, it has no way, with NAT66 to make
> sure it goes to the right CPE (that of the ISP whose prefix
> is at the beginning of the source address.
>
> >
> > connections for IPv6.
> - If punching holes in CPEs become as necessary in IPv6 as in
> IPv4 to have incoming connections, the main advantage of IPv6 is lost.
>
> Every OS that supports IPv6 has AFAIK its internal FW, at
> least to the point where its doesn't accept unwanted incoming
> connections.
>
>
> >  The advantage to separating the NAT and firewall functionality,
> > though, is that with NAT66, enterprise administrators _can_ enable
> > whatever inbound connectivity they like.  Every node can be made
> > accessible on all of its available ports, using a  a
> distinct address
> > per node.
>
> > that all sites deploy firewall functionality in IPv6.
>
> Fortunately it has become a vendor responsibility to decide
> whether unmanaged CPEs are shipped with transparent mode by
> default or not.
>
> My hope is that the majority of vendors of IPv6-capable
> unmanaged CPEs will understand that the transparent mode is
> the one that favors IPv6 deployment:
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66
>

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 11:02:29 -0400

Remi,

In my opinion, the best way to foster the growth of IPv6 is to allow organizations to replicate functionality similar to that which they enjoy under IPv4 today. For example, my organization has specificaly avoided even considering deployment of IPv6 due to lack of NAT support for it. We are hardly atypical in that. The flavor of NAT66 being proposed here wouldn't even cover it.... since we would want something statefull that supports both 1:1 and many:1 translations as well as Port Translations and has some built in level of blocking Inbound traffic (i.e. exactly what we have in IPv4 NAT now). However, the flavor of NAT66 being proposed here will go a long way toward helping SOME organizations consider adoption of IPv6. Stating that deploying FW packet filtering rules which default to closed, isn't spreading FUD about IPv6... it's helping address some of the real security concerns that organizations and individuals have about IPv6 adoption. Note that those SAME rules generaly existed by default as a best practice in IPv4 world... with deprication of statefull many:1 NAT...many organizations are actualy LOOSING a layer of protection here.... some of which (including mine) consider that in itself a barrier to adoption of IPv6.

Christopher Engel

> Sent: Monday, October 25, 2010 10:25 AM
> To: Margaret Wasserman
> >>>> That's what
> tools.ietf.org/html/draft-despres-softwire-sam-01 sec.
> This relates
> >> to ingress filtering. If a host sends a packet, it has no
> way, with
> >> NAT66 to make sure it goes to the right CPE (that of the ISP whose
> >> prefix is at the beginning of the source address.
> >
> Without translation, hosts know global addresses they have
> for each of the ISPs. They can then chose those that have the
> longest match with destination addresses.
> But you are right, since hosts of the NAT66 model only use
> their private addresses, they have no conflict with ingress
> filtering. My statement needs therefore to be corrected by
> deleting the parenthesis in "it works even with an
> independent CPE per ISP (which isn't the case with NAT66)".
> >> CPEs will understand that the transparent mode is the one
> that favors IPv6 deployment:
> Well, if they don't want to "favor IPv6 deployment", that's
> their problem. Being myself a real friend of IPv6 (convinced
> that it will promote growth of the Internet business), I
> rather spend my energy to increase native IPv6 use cases,
> than to make IPv6 purposely worse.
>
> Now, considering that working with hosts using global IPv6
> addresses "doesn't work well for customers", is contrary to
> my experience as a user of Free.fr since 2008. IMHO, stating
> it can only increase unjustified FUD about IPv6.
>
> regards,
> RD
>
>
>
> >>
> >> IMHO, a reference would be better than alignment (but both
> work for
> >> me).
> >
> > Okay.  Thanks.
> >
> > Margaret
> >
>
>

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 11:07:40 -0400

On Oct 25, 2010, at 11:02 AM, Chris Engel wrote:

> Remi,
> 
> In my opinion, the best way to foster the growth of IPv6 is to allow organizations to replicate functionality similar to that which they enjoy under IPv4 today.

That's also the best way to make IPv6 as broken as IPv4 is today.  I understand the value of mindshare in fostering deployment, but trying to make IPv6 as much like IPv4 as possible strikes me as at best, a waste of energy; and at worst, a good way to ensure that the net continues its trend of making it harder and harder to field new applications.

Keith

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 17:41:30 +0200

Le 25 oct. 2010 à 16:37, Chris Engel a écrit :

> Vendors who are concerned about thier clients security are not going to offload responsibility for that security entirely on the OS, that would be irresponsible of them.

My point is that if I have the choice, I will chose a vendor that doesn't require that I manage its CPE to obtain IPv6 incoming connectivity.
Vendors clearly do what they want, but their clients too.

> It's well known in security that a best practice is to provide multiple layers of defence...that would mean blocking packets at the network boundary (CPE) AND on the individual device level.

Yes, but there are places where there are so many protection codes to remember that people, especially if they are old, can't even re-enter their homes.
Staying at home is one more protection against accidents in the streets, but it isn't necessarily the wisest choice.

> This becomes especialy important in the IPv6 world...where we are starting to see OS's and devices come enabled with IPv6 connectivity by default...and your average end user may not even be aware that such connectivity exists, let alone how to account for protecting it.

> IPv6 is a huge security time bomb, waiting to happen...as has been written about by many security proffesionals.

Some security professionals may like to arouse fear, uncertainty, and doubt.

But, again, many users already use "native" IPv6 (neither 6to4 nor Teredo) and no bomb has exploded.
And AFAIK no bomb is timed to explode either.
 
> Regardless, that has very little to do with NAT66. The flavor of NAT, the authors are proposing here neither prevents nor mandates filters which would block traffic. A mention or reference about security issues sounds like a pretty responsible thing for the authors to do...since NAT in IP4 featured statefull inspection and at least many to one NAT (the type I would actualy like to see exist in IPv6) had some functionality to block incoming connections by default. Many organizations relied on this as an extra layer of protection for thier internal infrastructure..... and many vendors (wrongly) used it on CPE as a weak sort of firewall. Most folks I think should be able to figure out from the fact this is stateless, that such functionality has been depricated.

Of course, if you could show that some IPv6-capable OS's accept dangerous incoming connections by default, this would be useful, but AFAIK this isn't the case.

> However, I don't see anything wrong with the authors mentioning that it may be prudent to consider FW filters for blocking incoming connections if a vendor wanted to recover some of that same functionality that existed in IPv4 Dynamic NAT.

I have tried to explain.
E2e address preservation is a key advantage of IPv6 that shouldn't be lost from the outset.

RD

>> work for me).

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 11:42:09 -0400

Keith,

Not going to rehash this whole argument we've had before. No one is talking about changing the fundamentals of how IPv6 or IPv4 work. They are talking about the technologies that are AVAILABLE to deploy as an OPTION in conjunction with IPv4/6. Your approach essentially boils down to... "Don't tell me what you want. I'll tell you what you want. Now shut up and like it." ..... Then wondering why you are having trouble getting folks to jump at that sales pitch. That approach may work well in boot camp...not so much in a free market economy... where people are used to exercising some level of individual choice.

End to end transparency is a goal that many organizations/individuals do NOT want.... at least not on all portions of their networks. If you can't accept that, then we are simply going to have to agree to disagree.

Regardless, nothing the authors are doing with this flavor of NAT (unless I'm mistaken about it) should break end to end connectivity between devices running IPv6 since it's a 1:1 stateless mapping. A FW with statefull inspection and packet filtering rules would...but in that case the person deploying the FW WANTS that connectivity broken. If you're trying to argue that people should not be allowed to deploy FW's.... well then, good luck with that.

Christopher Engel

> From: Keith Moore [mailto:[email-masked]]
> Sent: Monday, October 25, 2010 11:08 AM
> To: Chris Engel
> Cc: 'Rémi Després'; Margaret Wasserman; Roger Marquis; [email-masked]
> Subject: Re: [nat66] Fwd: New Version Notification for
> draft-mrw-nat66-00
>
>
>
> > In my opinion, the best way to foster the growth of IPv6 is
> to allow
> > organizations to replicate functionality similar to that which they
> > enjoy under IPv4 today.
>
> That's also the best way to make IPv6 as broken as IPv4 is
> today.  I understand the value of mindshare in fostering
> deployment, but trying to make IPv6 as much like IPv4 as
> possible strikes me as at best, a waste of energy; and at
> worst, a good way to ensure that the net continues its trend
> of making it harder and harder to field new applications.
>
> Keith
>
>
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 17:54:12 +0200

Le 25 oct. 2010 à 17:42, Chris Engel a écrit :

> Keith,
> 
> Not going to rehash this whole argument we've had before. No one is talking about changing the fundamentals of how IPv6 or IPv4 work. They are talking about the technologies that are AVAILABLE to deploy as an OPTION in conjunction with IPv4/6. Your approach essentially boils down to... "Don't tell me what you want. I'll tell you what you want. Now shut up and like it."

If 

> ..... Then wondering why you are having trouble getting folks to jump at that sales pitch. That approach may work well in boot camp...not so much in a free market economy... where people are used to exercising some level of individual choice.
> 
> Regardless, nothing the authors are doing with this flavor of NAT (unless I'm mistaken about it) should break end to end connectivity between devices running IPv6 since it's a 1:1 stateless mapping.

It breaks INCOMING connectivity (not e2e connectivity).
This is because one can no longer advertise its own IPv6 address to be reached.
Peer-to-peer applications are then broken.

> A FW with statefull inspection and packet filtering rules would...but in that case the person deploying the FW WANTS that connectivity broken. If you're trying to argue that people should not be allowed to deploy FW's.... well then, good luck with that.

Please don't misrepresent others arguments.
People are obviously allowed to deploy FWs.
Some others should however be allowed not to have to disarm them in order to do work as usual.

RD

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2010 17:59:39 +0200

Hi,

> And AFAIK no bomb is timed to explode either.

Please understand that *your* customers are not the type of networks
Chris Engel talks about.  Residential and enterprise are the most distant
points in a spectrum - residential *wants* e2e and p2p apps, while enterprise
does *not* want that.

This discussion has been rehashed a number of times now, and it's time
that the "anti-NAT" crowd starts to accept that e2e is not a desirable 
property in some networks, and thus, this aspect of NAT doesn't do "harm".

Gert Doering

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 18:09:09 +0200

> property in some networks, and thus, this aspect of NAT doesn't do "harm".

It seems you accept that it may do some "harm" in the residential case (which is the case I discuss: unmanaged CPEs).

IMHO, it is rather time that NAT addicts start to listen to the following argument:
As soon as you have a FW in a customer site, you don't need to break the e2e address preservation of IPv6 to protect this site.

RD

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 12:09:30 -0400

On Oct 25, 2010, at 11:42 AM, Chris Engel wrote:

> Keith,
> 
> Not going to rehash this whole argument we've had before. No one is talking about changing the fundamentals of how IPv6 or IPv4 work. They are talking about the technologies that are AVAILABLE to deploy as an OPTION in conjunction with IPv4/6.

IETF does not determine what is available.  IETF makes recommendations for things that it believes will work well for the Internet.  You want IETF to endorse NAT in IPv6, you need to make an argument that it works well.  All evidence is to the contrary.

> Your approach essentially boils down to... "Don't tell me what you want. I'll tell you what you want. Now shut up and like it."

Your approach essentially boils down to "People want NAT because they want NAT.  It doesn't matter whether it works well or not.  IETF should endorse it because they want it."

If people say they want to be able to change ISPs without renumbering their internal networks, I get that.  That's a valid technical concern.    I understand why NATs are an attractive approach to addressing that concern.  I would like to find a better way (and still have routing scale), but I acknowledge that we're struggling to do that.

Saying that people want NAT because they want NAT isn't a technical argument.   It might even reflect how some people think, but it doesn't help produce something that works well.  We understand that effective marketing is needed to foster deployment, but there's very little point in implementing/producing/marketing something that doesn't work better than IPv4.  And with the hodgepodge of NAT solutions that are being proposed for IPv6 we are in danger of making IPv6 worse than IPv4.

> ..... Then wondering why you are having trouble getting folks to jump at that sales pitch. That approach may work well in boot camp...not so much in a free market economy... where people are used t…

Choice for whom?  Users or network operators?  You want to champion NAT as a triumph of individual choice, but what it does is hamper the networks' ability to support applications and users' ability to choose new applications.  

There comes a point at which freedom of individual choice, if widely exercised, actually impairs individual choice.   We need freedom of choice so that people who need to make exceptions to conventions are able to do so, not so that everyone can make exceptions to the conventions that let things work well.   IETF doesn't limit freedom of choice, but it does help define the conventions that help the Internet work well.

It's understandable that network operators resist change - they're having enough trouble coping with the network as it is.   But if I were running a company and my network operator came to me and said "I want to cripple our company's network so that it cannot easily support new applications that might be valuable to us", I'd fire him on the spot.  Which is pretty much what NAT does.

> End to end transparency is a goal that many organizations/individuals do NOT want.... at least not on all portions of their networks. If you can't accept that, then we are simply going to have to a…

I do understand that.   But just because those organizations/individuals want a lack of address transparency does not mean that IETF should recommend or endorse the practice.

> Regardless, nothing the authors are doing with this flavor of NAT (unless I'm mistaken about it) should break end to end connectivity between devices running IPv6 since it's a 1:1 stateless mapping.

where have you been for the last 25 years?  the only way you can say that NAT66 doesn't break things is if you have a very high threshold for breakage.  

> A FW with statefull inspection and packet filtering rules would...but in that case the person deploying the FW WANTS that connectivity broken. If you're trying to argue that people should not be al…

what I believe is that mechanisms to enforce policy should be explicitly tailored to do that.  mangling addresses is a very crude way to implement policy, and it does a lot of collateral damage.

Keith

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2010 18:11:37 +0200

Hi,

> It seems you accept that it may do some "harm" in the residential case (which is the case I discuss: unmanaged CPEs).

I have not seen anybody in this thread talk about residential CPEs.

To the contrary, my statement above was very clear: for residential, we
*want* e2e and p2p, and that implies "anything that breaks this is bad"
- and for residential, I don't see any benefits of NAT66 at all (in the 
single-homed case).  But that's not what people are talking about here.

Gert Doering
        -- NetMaster

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 09:19:21 -0700

> Regardless, nothing the authors are doing with this flavor of NAT (unless I'm mistaken about it) should break end to end connectivity between devices running IPv6 since it's a 1:1 stateless mapping…

Agreed. Not that there are not issues with prefix translation; there are applications and application deployments that make the (for the past 15 years indefensible) assumption that an address carried as a literal in an application will be meaningful to its peer, and those applications will have the same RFC 2993 problems that IPv4 NAT imposes. However, as your say, prefix translation enables any two interfaces in the network to communicate as long as the application doesn't depend on that assumption.

By the way, those applications have problems with IPv4 to IPv6 transition even without the NAT. Imagine that Alice and Bob have IPv6 connectivity but not IPv4 connectivity - we have progressed to a point at which either one of them lacks an IPv4 address at all or routing between their IPv4 domains is broken. Imagine Alice connects to Bob to open an http, sip, or whatever session, and Bob replies with either an IPv4-literal referral or an image pointer that contains an IPv4 literal. Alice won't be able to access it.

So, from my perspective, the time has come to get over it. Applications should deal in application concepts like DNS names, and should not impose any coupling to the network layer. That has to become true with or without NAT for the transition to occur. Once we have done that, giving the edge networks independence from their upstream (internally they can use a ULA or whatever) and the transit networks the ability to assume that prefixes are PA (there are O(10^4) networks they care about, not O(10^7) or greater) should be straightforward.

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 18:28:57 +0200

> I have not seen anybody in this thread talk about residential CPEs.

Well statements that something applies to all CPEs seemed to include unmanaged CPEs.
I don't believe I misinterpreted, but sorry if I did.

> single-homed case).

Good that we agree on that.
At least between us, no more to be said.

>  But that's not what people are talking about here.

For manage CPEs, the point that remains was in my previous mail:
"As soon as you have a FW in a customer site, you don't need to break the e2e address preservation of IPv6 to protect this site, be it globally or selectively."

RD

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 12:30:15 -0400

> > It's a little off subject, but vendors are going to do
> whatever they
> > think serves thier customers best. I'm not sure what, if anything,
> > that would have to do with a NAT66 standard.
> >
> > Vendors who are concerned about thier clients security are
> not going
> > to offload responsibility for that security entirely on the
> OS, that
> > would be irresponsible of them.
>
> My point is that if I have the choice, I will chose a vendor
> that doesn't require that I manage its CPE to obtain IPv6
> incoming connectivity. Vendors clearly do what they want, but
> their clients too.
>

 Remi, that's great. I don't think anyones trying to tell you what vendors you must choose or your vendors what choices they must make in thier deployments. That's kinda been my whole point all along. The only thing which I THINK is being said is... hey under many NATv44 deployments certain things were true, under NATv66 those things are no longer true. If you want a way to recover some of that same functionality, you can do this.

Heck, were I a vendor responsible for deploying CPE for public end users under IPv6 (I'm not), I think I would actualy give clients a CHOICE of which way thier CPE was delivered to them when provisioning services... with a little plain language explanation of what each choice meant...and nice little radio button/check box for them to indicate thier choice. How crazy is that?

>
> > It's well known in security that a best practice is to provide
> > multiple layers of defence...that would mean blocking
> packets at the
> > network boundary (CPE) AND on the individual device level.
>
> Yes, but there are places where there are so many protection
> codes to remember that people, especially if they are old,
> can't even re-enter their homes. Staying at home is one more
> protection against accidents in the streets, but it isn't
> necessarily the wisest choice.
>

Depends on the situation of usage case involved. Not all situations are the same. The door to your storage shed and the door to a missle silo at NORAD are both doors and they both need to support being opened and closed....but the circumstances under which that occurs is very different in each case. The first step in any security evaluation is a RISK ASSESMENT... understanding the relatives risks involved, the consequences for failing to address them, and the cost on all levels (that includes functionality/ease of use complications) which is appropriate to mitigate those risks. The right choice for your storage shed is not neccesarly the right choice for NORAD's missle silo. However the designers of something as basic in concept as "a door" need to be able to account for both communities of users and everything in between in thier design. Right now, you are only thinking from the aspect of one community of users.

>
> > This becomes especialy important in the IPv6 world...where we are
> > starting to see OS's and devices come enabled with IPv6
> connectivity
> > by default...and your average end user may not even be
> aware that such
> > connectivity exists, let alone how to account for protecting it.
>
> > IPv6 is a huge security time bomb, waiting to happen...as has been
> > written about by many security proffesionals.
>
> But, again, many users already use "native" IPv6 (neither
> 6to4 nor Teredo) and no bomb has exploded. And AFAIK no bomb
> is timed to explode either.
>
> > Regardless, that has very little to do with NAT66. The
> flavor of NAT,
> > the authors are proposing here neither prevents nor
> mandates filters
> > which would block traffic. A mention or reference about security
> > issues sounds like a pretty responsible thing for the authors to
> > do...since NAT in IP4 featured statefull inspection and at
> least many
> > to one NAT (the type I would actualy like to see exist in IPv6) had
> > some functionality to block incoming connections by default. Many
> > organizations relied on this as an extra layer of
> protection for thier
> > internal infrastructure..... and many vendors (wrongly)
> used it on CPE
> > as a weak sort of firewall. Most folks I think should be able to
> > figure out from the fact this is stateless, that such functionality
> > has been depricated.
>
> Of course, if you could show that some IPv6-capable OS's
> accept dangerous incoming connections by default, this would
> be useful, but AFAIK this isn't the case.
>

Sure... Windows Vista, Windows 7, Windows Server 2008, and any number of "IP capable" printers/fax's/scanners/garbage disposals, etc.  The whole point behind the principle of multiple security layers is that devices/OS's are designed and configured by human beings and thus subject to unexpected flaws. If this weren't true then you would never see any vendor issue a security patch, ever.

>
> > However, I don't see anything wrong with the authors
> mentioning that
> > it may be prudent to consider FW filters for blocking incoming
> > connections if a vendor wanted to recover some of that same
> > functionality that existed in IPv4 Dynamic NAT.
>
> I have tried to explain.

It's only being lost where the people responsible for these systems WANT to loose it. That was even true under IPv4....at least until address shortages became an issue. Under IPv6 the address shortage issue goes away...and thankfully that community of users who WISH to preserve e2e address transparency can get to do so. However, what about the community of users who DON'T want to preserve e2e address transparency. I don't think there is anything in this or any other proposed standard (for the general public) which says NAT MUST be deployed when you deploy IPv6.

> >> From: [email-masked] [mailto:[email-masked]] On
> >> Behalf Of Rémi Després
> >> Subject: [SPAM] - Re: [nat66] Fwd: New Version Notification for
> >> draft-mrw-nat66-00 - Email has different SMTP TO: and MIME
> TO: fields
> >> in the email addresses
> >>
> >>
> >>
> >> - If punching holes in CPEs become as necessary in IPv6 as
> in IPv4 to
> >> have incoming connections, the main advantage of IPv6 is lost.
> >>
> >> Every OS that supports IPv6 has AFAIK its internal FW, at least to
> >> the point where its doesn't accept unwanted incoming connections.
> >>
> >>
> >> Fortunately it has become a vendor responsibility to
> decide whether
> >> unmanaged CPEs are shipped with transparent mode by default or not.
> >>

Christopher Engel

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 12:32:42 -0400

On Oct 25, 2010, at 12:19 PM, Fred Baker wrote:

> Agreed. Not that there are not issues with prefix translation; there are applications and application deployments that make the (for the past 15 years indefensible) assumption that an address carried as a literal in an application will be meaningful to its peer, and those applications will have the same RFC 2993 problems that IPv4 NAT imposes.

Fred, it's not an indefensible assumption.  It's how the Internet was designed to work.  it's the behavior specified by the core Internet protocol standards.

Applications need to have a predictable, well-documented environment in which to operate.   Why in the world you think that networks should be able to violate the standards  and that somehow it's the application developers' responsibility to adapt to whatever random brain damage the network operators decide to impose is beyond me.  But it makes no sense from an engineering perspective.

If there really is a need for NATs in the network (which has not been established) then it's incumbent for IETF to standardize them in such a way that applications still have a predictable environment which lets them do what they need to do (modulo policy).  So far, IETF has not done that.  What it has mostly done is fail to provide clear direction.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 12:41:01 -0400

Hi Chris,

On Oct 25, 2010, at 11:02 AM, Chris Engel wrote:
>  The flavor of NAT66 being proposed here wouldn't even cover it....  
> since we would want something statefull that supports both 1:1 and  
> many:1 translations as well as Port Translations and has some built  
> in level of blocking Inbound traffic (i.e. exactly what we have in  
> IPv4 NAT now).

Do you think that what you want could be provided by NAT66 coupled  
with a stateful firewall?  Or is there something more that you would  
need?

It sounds like the many:1 translation might be missing...  What is  
that used for?

> However, the flavor of NAT66 being proposed here will go a long way  
> toward helping SOME organizations consider adoption of IPv6. Stating  
> that deploying FW packet filtering rules which default to closed,  
> isn't spreading FUD about IPv6... it's helping address some of the  
> real security concerns that organizations and individuals have about  
> IPv6 adoption. Note that those SAME rules generaly existed by  
> default as a best practice in IPv4 world... with deprication of  
> statefull many:1 NAT...many organizations are actualy LOOSING a  
> layer of protection here.... some of which (including mine) consider  
> that in itself a barrier to adoption of IPv6.

It is my impression that you can achieve that same level of protection  
from a stateful IPv6 firewall as you would from an IPv4 NAT.  Does  
that match your experience?

Margaret

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 18:41:41 +0200

Margaret, 

My previous answer to your question about Multi-CPE-Multihoming with NAT66 was incomplete, and erroneous.
Sorry for that.
The picture is in fact more complex.

If a private-site network has two CPEs giving access to two ISPs, the CPE via which a packet goes to the Internet depends on the intra-site routing.
If this routing doesn't make sure that all packets from a given host always go to the same CPE, then TCP connections will be broken:
- packets that go via a CPE different from that traversed by the the SYN packet will be OK as far as ingress filtering is concerned, but they will be discarded by their destination (having a different source address, they will not be considered as belonging to the TCP connection) 
- SIP or SCTP won't help because hosts don't know global addresses at which they can be reached (while with e2e preserved addresses SIP and SCTP can work).

It therefore remains true that, unless some precautions in intra-site routing are taken (that need to be documented, and that are not necessarily easy to enforce), NAT66 isn't compatible with multi-CPE-multihoming.

In my understanding, SAM, provided hosts support it, does bring a solution that works independently of intra-site routing properties, and does leverage the potential of SHIM6 and SCTP to maintain connections in case of failures.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 18:50:26 +0200

> Remi, that's great. I don't think anyones trying to tell you what vendors you must choose or your vendors what choices they must make in thier deployments. That's kinda been my whole point all alon…

Yes, and my contribution is to add "and you can also do that, with the following pros and cons".
(In this case, and unless I am mistaken, more pros than cons ;-))

> Heck, were I a vendor responsible for deploying CPE for public end users under IPv6 (I'm not), I think I would actualy give clients a CHOICE of which way thier CPE was delivered to them when provisioning services... with a little plain language explanation of what each choice meant...and nice little radio button/check box for them to indicate thier choice.

> How crazy is that?

Not crazy at all.
Actually, draft-ietf-v6ops-cpe-simple-security-16, AFAIK about to become an RFC says:

REC-49: Internet gateways with IPv6 simple security capabilities MUST provide an easily selected configuration option that permits a "transparent mode" of operation that forwards all unsolicited flows regardless of forwarding direction, i.e. not to use the IPv6 simple security capabilities of the gateway.  The transparent mode of operation MAY be the default configuration.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 09:53:51 -0700

> Fred, it's not an indefensible assumption.  It's how the Internet was designed to work.  it's the behavior specified by the core Internet protocol standards.

It also is definitely *not* the way the Internet has been deployed for the past fifteen years. Anyone that puts IPv4 literals into HTTP or SIP/SDP headers *has* to use a global address, or anyone across a NAT can't communicate with them. What I am pointing out, in case you missed it, is that there is also a problem in the transition/coexistence phase with the assumption that just because I speak IPv[46] that you can speak IPv[46] and that there is a reliable route using IPv[46] between us. Putting an IPv[46] literal into an application header is not only stupid because of the coupling implied - that your address space and mine overlap - but because of the coexistence coupling.

> Applications need to have a predictable, well-documented environment in which to operate.   Why in the world you think that networks should be able to violate the standards  and that somehow it's t…

Perhaps. It is, however, reality.

> If there really is a need for NATs in the network (which has not been established) then it's incumbent for IETF to standardize them in such a way that applications still have a predictable environm…

Well, it actually has been established. That's the point the people you are so actively not listening to are trying to make. The need for address translation has nothing to do with topology obfuscation, although that point is frequently brought up; if I can read your SMTP envelopes I can figure out your topology well enough for any nefarious purposes I might have. And it has nothing to do with address amplification, which I suspect is what you're responding to as "unproven". It has to do with the sizes of route tables in the core and the politics of attachment at the edge. 

If we use the existing prefix allocation policy assumptions, which are built around enumerating the objects at the edge, we wind up with as many routes in the route table as we have objects at the edge. Aggregation of routes, which is what we use to make routing scale in the Internet, simply doesn't exist. Current estimates I see talk about 10^7 routes within 15 years, and in a world of 10^10 people I suspect it's a lot more than that over time. If you want to pay for the silicon, heat, and power, I'll happily sell you the routers, but it turns out that you're talking about a lot of silicon, a lot of heat, and a lot of power, which is to say a lot of money. Transit providers are looking for solutions there.

At the edge, there is a huge push for PI addressing. You can say that shim6-or-etc enables the edge networks to be independent of their providers by having a prefix from each of them; the edge networks are voting with their feet in that regard and saying it's not a network they're willing to operate. They want address independence, and they don't want to have to do anything when they change providers. They see PI addressing as the solution.

And I will argue that ILNP (which requires every host in the world to be upgraded and therefore is IMHO a non-starter, although as a solution I prefer it) or NAT66 as proposed in this document (which reduces the problem to one of updating CPEs by updating the checksum) handles both issues. The transit networks get to view their route tables as entirely PA, and therefore as having been advertised by O(10^4) ISPs or large corporate networks, and the edge networks get the address independence they desire. That may be "broken" from your perspective, but from the guy-paying-the-money's perspective that is not broken. It is exactly what they are looking for.

This is the last note that I will post to this thread. I'm really not interested in further rehashing this. I have a life.

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 13:05:08 -0400

Hi Remi and Keith (among others),

On Oct 25, 2010, at 12:09 PM, Rémi Després wrote:
> It seems you accept that it may do some "harm" in the residential  
> case (which is the case I discuss: unmanaged CPEs).

Then we are in complete agreement.  NAT66 isn't needed for most home  
users -- a stateful firewall would serve the same purpose.

That doesn't say _anything_ about the NAT66 document we are discussing  
on this list, though, as it is intended to provide address  
independence for _enterprise_ networks.  When Chris talks about the  
people who are waiting for IPv6 NAT before they will deploy IPv6, he  
is talking about _enterprises_.  Not ISPs, not home users.  (I'm  
making an assumption here -- Chris, please correct me if I am wrong).

> As soon as you have a FW in a customer site, you don't need to break  
> the e2e address preservation of IPv6 to protect this site.

Most enterprise network managers are intelligent, well-educated, well- 
informed, rational members of our community.  They are our peers, and  
we need to start treating them as such.   There are valid (or at least  
defensible) _reasons_ why they make the trade-offs they make.  Until  
you can see why so many of our peers use NAT in enterprise networks in  
IPv4, you can't even begin to make a well-founded statement that they  
aren't necessary in IPv6.

Please consider three facts:

- Firewalls existed in IPv4, too.
- Many large enterprises have more than enough "swamp space" (AKA IPv4  
provider-independent addresses)
- Many of _those_ enterprises use NAT (for remote sites, B-to-B  
network or their whole corporate networks)

Until you can offer an insightful explanation of _why_ they use NAT in  
IPv4 , please stop telling them that they don't need NAT in IPv6...

Margaret

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 10:12:33 -0700

On Oct 25, 2010, at 10:05 AM, Margaret Wasserman wrote:

> Then we are in complete agreement.  NAT66 isn't needed for most home users -- a stateful firewall would serve the same purpose.

You may be interested to review 
http://tools.ietf.org/html/draft-troan-multihoming-without-nat66
  "IPv6 Multihoming without Network Address Translation", Ole Troan, David
  Miles, Satoru Matsushima, Tadahisa Okimoto, Dan Wing, 26-Jul-10

The question of multihoming with or without NAT66 (specifically referring to this draft) was brought up by a large residential access provider, who given current solutions sees NAT66 as the only solution to its *residential* problems. Basically, the point of the draft is to describe their scenario and state that they need solutions to three residential problems or they will consider themselves as having no alternative to NAT66.

---

From: Gert Doering <[email-masked]>
Date: Mon, 25 Oct 2010 19:19:01 +0200

Hi,

On Mon, Oct 25, 2010 at 09:53:51AM -0700, Fred Baker wrote:
> And I will argue that ILNP (which requires every host in the world
> to be upgraded and therefore is IMHO a non-starter, although as a
> solution I prefer it) or NAT66 as proposed in this document (which
> reduces the problem to one of updating CPEs by updating the checksum)
> handles both issues. The transit networks get to view their route
> tables as entirely PA, and therefore as having been advertised by
> O(10^4) ISPs or large corporate networks, and the edge networks get
> the address independence they desire. That may be "broken" from
> your perspective, but from the guy-paying-the-money's perspective
> that is not broken. It is exactly what they are looking for.

Amen.

Gert Doering

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 13:29:04 -0400

Hi Fred,

On Oct 25, 2010, at 1:12 PM, Fred Baker wrote:
>> Then we are in complete agreement.  NAT66 isn't needed for most  
>> home users -- a stateful firewall would serve the same purpose.
>
> The question of multihoming with or without NAT66 (specifically  
> referring to this draft) was brought up by a large residential  
> access provider, who given current solutions sees NAT66 as the only  
> solution to its *residential* problems. Basically, the point of the  
> draft is to describe their scenario and state that they need  
> solutions to three residential problems or they will consider  
> themselves as having no alternative to NAT66.

Wow, I do have to read that.  From the name, I thought the document  
said exactly the opposite, although I should have trusted that author  
list to come up with something insightful.  Thanks for the pointer!

Margaret

---

From: Rémi Després <[email-masked]>
Date: Mon, 25 Oct 2010 19:33:58 +0200

Le 25 oct. 2010 à 19:12, Fred Baker a écrit :

>> Then we are in complete agreement.  NAT66 isn't needed for most home users
>> -- a stateful firewall would serve the same purpose.

My point is that a FW isn't needed and is even harmful in UNMANAGED CPEs, and is even harmful because without CPE management it would prevent any incoming connectivity and simple IPv6 peer-to-peer.

> The question of multihoming with or without NAT66 (specifically referring to this draft) was brought up by a large residential access provider, who given current solutions sees NAT66 as the only so…

I can only repeat that I tried to find a solution without NAT66, and that I believe it does exists.
It is described in tools.ietf.org/html/draft-despres-softwire-sam-01, in particular sec 3.3.

Claiming that there is no alternative to NAT66 without looking at it and commenting is IMHO unfortunate.
One reason for it to be unfortunate is that restoring e2e address preservation is what can make SHIM6 and SCTP to work.

Regards,
RD

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 13:44:42 -0400

What Fred is talking about here sounds a whole heck of alot like the philosophy behind the OSI model that I was taught some 20 years ago or so..... The idea that higher level applications shouldn't neccesarly dictate choices far lower in the Model. That's a vaulable thing, IMO. Now, I realize that reality is far different in practice then theory...but I think efforts would be better spent improving reporting capabilities of higher level naming schemes rather then mandating lower level protocol choices. Going that route, a guy could be running IPX/SPX and your application (in theory) would still be able to function.

Christopher Engel

> From: Fred Baker [mailto:[email-masked]]
> Sent: Monday, October 25, 2010 12:19 PM
> To: Chris Engel
> Cc: 'Keith Moore'; Roger Marquis; Wasserman; [email-masked];
> [email-masked]
> > Regardless, nothing the authors are doing with this flavor of NAT
> > (unless I'm mistaken about it) should break end to end connectivity
> > between devices running IPv6 since it's a 1:1 stateless
> mapping. A FW
> > with statefull inspection and packet filtering rules would...but in
> > that case the person deploying the FW WANTS that
> connectivity broken.
> > If you're trying to argue that people should not be allowed
> to deploy
> > FW's.... well then, good luck with that.
>
> Agreed. Not that there are not issues with prefix
> translation; there are applications and application
> deployments that make the (for the past 15 years
> indefensible) assumption that an address carried as a literal
> in an application will be meaningful to its peer, and those
> applications will have the same RFC 2993 problems that IPv4
> NAT imposes. However, as your say, prefix translation enables
> any two interfaces in the network to communicate as long as
> the application doesn't depend on that assumption.
>
> By the way, those applications have problems with IPv4 to
> IPv6 transition even without the NAT. Imagine that Alice and
> Bob have IPv6 connectivity but not IPv4 connectivity - we
> have progressed to a point at which either one of them lacks
> an IPv4 address at all or routing between their IPv4 domains
> is broken. Imagine Alice connects to Bob to open an http,
> sip, or whatever session, and Bob replies with either an
> IPv4-literal referral or an image pointer that contains an
> IPv4 literal. Alice won't be able to access it.
>
> So, from my perspective, the time has come to get over it.
> Applications should deal in application concepts like DNS
> names, and should not impose any coupling to the network
> layer. That has to become true with or without NAT for the
> transition to occur. Once we have done that, giving the edge
> networks independence from their upstream (internally they
> can use a ULA or whatever) and the transit networks the
> ability to assume that prefixes are PA (there are O(10^4)
> networks they care about, not O(10^7) or greater) should be
> straightforward.
>

---

From: Chris Engel <[email-masked]>
Date: Mon, 25 Oct 2010 14:23:10 -0400

> It sounds like the many:1 translation might be missing...  What is

Margaret, unfortunately NAT66 coupled with an SI firewall...although a decent architecture doesn't quite cut it for us. We use both static (1:1) and dynamic (many:1) NAT as well as port translation (i.e. port 80 on public IP = port 43480 on private IP, etc). This gives us alot of versatility in customizing our internal architecture and abstracting it from our external presence.

We use many:1 NAT for connections that we KNOW and purposefully INTEND connectivity only be one way (mainly end user workstations, etc). That way an external source has no way of even addressing the device unless an entry exists for it in the boundary devices state table (i.e. an OUTGOING connection has already been established). Thus even if the FW rule is removed (due to misconfiguration or otherwise).... There is SOME measure of protection against external connections...Multiple Layers instead of just one. Furthermore, it complicates, at least on the network level tracking and profiling individual devices (even though that capability might exist at higher levels).

Port Translation is also an important function for us....so that we can present a single public IP address as say an SMTP and and HTTP server...and have different devices handle providing that service without needing to run some sort of load balancing hardware or renumbering IP's internaly.

Maybe I'm just ignorant but I'm not even sure how compatible Load Balancing and High Availability is with the principle of End to End transparency being espoused by some folks here.

The scenerios I've always experienced work something like this.....

1) You have 1 DNS entry for your Load Balanced/HA Application. Entry points to 1 Public Address.

2) Your load balancer acts as a proxy for that public IP...farms it out to the individual devices responsible for delivering that service based upon whatever algorthym you specify for it.

3) Client Application has no knowledge that it's communication is with Device A rather then Device B....as far as it's concerned everything is going to the 1 public IP.

Seems to me that functionality which many service providers depend on runs pretty much countrary to the e2e transparency that some folks here are contending is neccesary for the growth of the internet.

Christopher Engel

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Oct 2010 11:28:28 -0700

On Oct 25, 2010, at 10:29, Margaret Wasserman wrote:
> 
> Wow, I do have to read that.  From the name, I thought the document said exactly the opposite, although I should have trusted that author list to come up with something insightful.  Thanks for the pointer!

Oh, dratz.  I made the same mistake.  I'm gonna need to read that asap.

Is that draft an appropriate topic of discussion for this mailing list?

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

---

From: "S.P.Zeidler" <[email-masked]>
Date: Mon, 25 Oct 2010 20:35:19 +0200

> It's understandable that network operators resist change - they're having enough trouble coping with the network as it is.   But if I were running a company and my network operator came to me and s…

Question back, very concrete and not at all concerned with networking
ideals:

Do you want your bank to allow you to attempt opening a connection to any
of their networked devices, trusting that the device itself will not have
any bugs that will allow a hacker to gain access to your bank account data?
Please keep in mind that a sizeable fraction of these machines will
be some variant of Windows.

Do you want your electricity provider also to have their network entirely
open for end-to-end traffic, trusting each and every host to keep itself
secure?

Your hospital? You know that many life-sustaining machines in a hospital
are networked these days?

regards,
	spz

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 11:52:08 -0700

I believe that it is being discussed in v6ops. However, if you want to tell us how to scalably manage O(10^7) IPv6 PI prefixes without translation, without rearranging all of the operator's transit contracts (which would be one of the side-effects of Metro Addressing), and without aggregation, I guess I'm all ears. The alternative I would come up with is a messaging architecture. *That* would be a discussion for another list, but it's one that I'll probably detail at some point.

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 25 Oct 2010 12:17:29 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Margaret Wasserman
> Sent: Monday, October 25, 2010 10:29 AM
> To: Fred Baker
> Cc: Keith Moore; [email-masked] HappyFunBall
> Subject: Re: [nat66] Residential use case
> 
> 
> Hi Fred,
> 

No insight, other than:  fix four problems on hosts to eliminate
four reasons for NAT66.  Solutions to those four problems are 
already moving forward in MIF.

-d

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 25 Oct 2010 16:27:28 -0400

Hi James,

On Oct 25, 2010, at 2:28 PM, james woodyatt wrote:

>> said exactly the opposite, although I should have trusted that  
>> author list to come up with something insightful.  Thanks for the  
>> pointer!
>

While I don't object to discussing it here, it would probably be more  
effective to discuss it on the v6ops list.

Margaret

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Oct 2010 13:30:44 -0700

On Oct 25, 2010, at 11:52, Fred Baker wrote:

> I believe that it is being discussed in v6ops. 

Then I'll look for discussion of that draft there.

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 13:34:53 -0700

Thanks.

It was presented in Maastricht, and the work proposed is currently under discussion in MIF. Ole Troan will be commenting on it in v6ops at IETF-79.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 17:28:42 -0400

> It also is definitely *not* the way the Internet has been deployed for the past fifteen years. Anyone that puts IPv4 literals into HTTP or SIP/SDP headers *has* to use a global address, or anyone a…

Oh, of course.  If one peer is speaking only v4 and the other only v6, then there has to be some sort of NAT or proxy between them, and trying to do referrals across a v4/v6 boundary using the traditional host interface isn't likely to work.   What is really needed is to define a general purpose and universally supported way for a v4-only host to open up a connection to a v6 address, and vice versa.  Absent that, referrals need to contain both a (global) v4 and v6 address so that any peer can deal with them...though I don't see what any of that has to do with NAT66.

(And there's nothing at all that's stupid about assuming that your address space and mine overlap.   That's one of the fundamental assumptions of IP.  What's stupid is to assume that we can somehow manage to have apps interoperate in a world where every network is free to define its own address space.)

> Perhaps. It is, however, reality.

Which RFC documents "reality"?  Or to put it another way, where is the document that explains what applications are expected to do to cope with this "reality" of which you speak?  And absent such a document, assuming that someone manages to write an application that copes with present-day reality, what's the chance that the application will continue to work next year?

We used to have a clear separation of function between hosts/applications and the network.  The hosts/applications gave traffic to the network to be delivered to destination addresses; the network made a best effort to deliver them intact to those addresses.   The network could lose or duplicate packets but could not deliberately alter them.  That was a very simple and elegant separation of function with a very useful result: if the network couldn't get some packets to their destinations, it wasn't the responsibility of the hosts or applications to deal with it - since the network was already doing its best effort and the network was in a better position to get them there than the hosts.   The hosts/apps had the responsibility to deal with the occasional dropped packet or connection but not to try to build their own packet routing systems. 

Now we have a world where network operators feel free to alter packets for any reason that they see fit, not just including NAT but also interception proxies, traffic shapers, connection forwarders, etc.  And application writers are expected to cope with this undocumented "reality".  So, for instance, they become port agile (even when they have assigned ports), they tunnel traffic over HTTP, they define their own address spaces, they do their own routing, they set up dedicated intermediaries residing in global address space that can do referrals and traffic forwarding, they to obscure their traffic so that the intermediaries imposed by the network don't screw them up.  And "reality" just keeps getting more complicated every year.  NATs aren't the only things to blame, but the fact that there are other culprits doesn't lessen the culpability of NATs.

This isn't at all specific to NAT66, but it applies here as much as it does anywhere.  If NATs are going to be in the network long term, then they need to be explicitly visible, and there needs to be a standard (as in well-defined and well-documented), universally applicable, viable way for applications to do what they need to do that works both when NATs are not present and when they are.  And that includes referrals.

> If we use the existing prefix allocation policy assumptions, which are built around enumerating the objects at the edge, we wind up with as many routes in the route table as we have objects at the…

And somehow we're going to solve this problem by pushing it to hosts and applications?  Without even giving them a global address space to work with?  

> At the edge, there is a huge push for PI addressing. You can say that shim6-or-etc enables the edge networks to be independent of their providers by having a prefix from each of them; the edge netw…

I think the general statement is that everybody wants routing scaling to be somebody else's problem.  The transit networks don't want to change how they route packets, the enterprise networks don't want to accept PA addressing, the application writers don't want to have to try to probe the network to figure out which combinations of source interface, source address, destination address, and (sometimes) intermediary will get the traffic there. 

> And I will argue that ILNP (which requires every host in the world to be upgraded and therefore is IMHO a non-starter, although as a solution I prefer it)

haven't looked at ILNP (I will) but I seem to recall that the hosts deployed IPv6 far, far ahead of everything else.  

> or NAT66 as proposed in this document (which reduces the problem to one of updating CPEs by updating the checksum) handles both issues. The transit networks get to view their route tables as entirely PA, and therefore as having been advertised by O(10^4) ISPs or large corporate networks, and the edge networks get the address independence they desire. That may be "broken" from your perspective, but from the guy-paying-the-money's perspective that is not broken. It is exactly what they are looking for.

depends on what business you're in, doesn't it?  if you're in the business of writing applications, it doesn't look very good at all.

Keith

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2010 11:30:00 +1300

Gert,

> property in some networks, and thus, this aspect of NAT doesn't do "harm".

The problem comes when one of the ends tries to participate in
a multi-party protocol. The state that a NAPT creates to permit
a two-party protocol to work isn't able to support a third party.

So, people whose model of connection to the Internet only involves
two-party client-server protocols can use the arguments Chris Engel
has expressed, but if they want multi-party protocols they have to
start using some kind of kludge. (I am including things like ICE
in the category "kludge".)

Has anyone analysed how stateless NAT66 will impact multi-party
applications? Since it doesn't break address uniqueness, there
may be hope.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Mon, 25 Oct 2010 15:33:23 -0700

> applications? Since it doesn't break address uniqueness, there

My *belief* is that the hope you think you see is in fact there.

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 19:16:07 -0400

> My *belief* is that the hope you think you see is in fact there. 

The situation is definitely better if you can count on addresses being unique.  But that doesn't mean that the problem is solved.

ICE is not a suitable solution.  Nor is any other solution that requires that every application that wants to communicate across NAT boundaries have dedicated "real estate" in public IP space.

If NATs were required to implement additional functionality to help apps with the referral service (so they don't need that "real estate"), that would help a lot.

But I think there are better solutions still, that either don't use NAT at all (within v6) or do dual-NAT in such a way that the hosts/applications never see the addresses used for routing by the network core.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Mon, 25 Oct 2010 23:36:05 +0000

> Of course, NAT66 eliminates ingress filtering as a question, as the source address is forced to a prefix that won't be filtered.

Maybe. But NAT66 doesn't eliminate the other problem linked to ingress filtering, direct consequence of managing several egress addresses. If an internal routing change causes the packets from internal host H to external host X to be routed through a different egress, then the external address of X will change... and the TCP connection between H and X will break.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 19:57:37 -0400

On Oct 25, 2010, at 1:44 PM, Chris Engel wrote:

> What Fred is talking about here sounds a whole heck of alot like the philosophy behind the OSI model that I was taught some 20 years ago or so..... The idea that higher level applications shouldn't neccesarly dictate choices far lower in the Model.  That's a vaulable thing, IMO.

ah yes.  OSI worked so well....

>  Now, I realize that reality is far different in practice then theory...but I think efforts would be better spent improving reporting capabilities of higher level naming schemes rather then mandating lower level protocol choices. Going that route, a guy could be running IPX/SPX and your application (in theory) would still be able to function.

Fred likes to refer to reality...well, the reality is that lower level protocol choices do affect applications, in subtle and not-so-subtle ways.  And it's all well and good in theory to say that applications should be agile enough to tolerate differences in lower protocol choices (like TCP vs. SCTP, say, or IPv4 vs IPv6, or NAT vs. no NAT.  What that means in practice is that you want applications to not have a predictable environment in which to operate.   And that is simply unacceptable.

The people who keep wanting to impose arbitrary brain damage onto apps are the ones who need to "get over it".

You can make an Internet without NATs.  You can't get there from here without some fairly disruptive changes in how routing is done, but it can be done.  You can also make an Internet with NATs as an explicit part of the architecture, though I think it's suboptimal.  

What doesn't work is to try to make an Internet where the NATs aren't explicit - where applications are expected to work in the presence of NATs that they don't interact with directly and which try to guess what the applications need.  So you have the applications second-guessing the NATs and the NATs second-guessing the apps.   And that's exactly where we are heading, and we're heading that way because of a failure to make an architectural decision about direction.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 25 Oct 2010 20:26:53 -0400

> be some variant of Windows.

Do I want a bank that runs lots of Windows boxes?  Hell no.  :)

Here's what I want from a bank, or any other institution whose machines I have to trust:

- trusted platforms are kept to a minimum.  the system is designed so that most platforms are not trusted.
- careful selection of trusted host platform hardware/os, and every application that runs on those platforms.  (that pretty much rules out Windows right there)
- regular auditing of trusted platforms to see that they're running unmodified apps and appropriate versions of those apps
- a centrally-specified policy that says which apps run on which platforms, and what subset of those apps can communicate with untrusted hosts
  (any host not covered by that policy is inherently untrusted)
- all communications between apps which require trust use strong authentication - merely using the source IP address to convey trust is not acceptable
- frequent auditing of hosts to make sure that they conform to policy, with alarms when there is a discrepancy
- network monitoring to make sure that traffic conforms to policy, with alarms when there is a discrepancy
- one or more levels of firewall to make sure that traffic conforms to policy, with alarms when there is a discrepancy
- isolation (e.g. firewalls) between hosts that run sensitive apps and ordinary hosts
- user authentication into sensitive apps (e.g. those which can access multiple customers' data) requires multiple-factor authentication, at least one of which requires a credential that is incapable of being stored/cached/replayed.
- "regression testing" against the policy and implementation to see that the policy permits known valid use cases and forbids known invalid use cases.
- all transactions are logged
- there's a very good mechanism in place for data recovery
- etc.

The salient point for this discussion is that the policy is flexible, and all of the mechanisms that exist to implement and reinforce the policy are also flexible.  If there's a need to run a new application,  the policy can be changed to accommodate it.

Also, in a world where most hosts are mobile, it becomes less and less viable to try to divide the world up into trusted vs. untrusted hosts based on their IP addresses.

Keith

---

From: Roland Bless <[email-masked]>
Date: Tue, 26 Oct 2010 09:57:00 +0200

Hi Brian,

> in the category "kludge".)

But you also have to use a kludge in case your protocol carries
IP addresses inside. While it's well known to better avoid that,
some protocols cannot live without it, e.g., transport protocols.
So new transport protocols or other applications will still have
a hard time when it's time to deploy them. Hence, multi-party protocols
are IMHO not the only problem.

Regards,
 Roland

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 12:45:23 +0200

> Then we are in complete agreement.  NAT66 isn't needed for most home users

To be a real agreement it has though to be disjoint from the next sentence
 
> -- a stateful firewall would serve the same purpose.

In my understanding, stateful firewalls aren't needed either in UNMANAGED CPEs. 

> That doesn't say _anything_ about the NAT66 document we are discussing on this list, though, as it is intended to provide address independence for _enterprise_ networks.

If this is so, it should be clear in the document.
I suggest to have it at least in the abstract. 
 
>  When Chris talks about the people who are waiting for IPv6 NAT before they will deploy IPv6, he is talking about _enterprises_.  Not ISPs, not home users.  (I'm making an assumption here -- Chris, please correct me if I am wrong).

OK.
This is clear now, but had to be clarified.

> Most enterprise network managers are intelligent, well-educated, well-informed, rational members of our community.  

No doubt from me on this!

> They are our peers, and we need to start treating them as such.

Never tried to do otherwise.
My sentence above was an answer to "It's time that the "anti-NAT" crowd starts to accept that e2e is not a desirable property in some networks" (which BTW I do accept, although I believe I was considered part of the "anti-NAT" crowd). 

>   There are valid (or at least defensible) _reasons_ why they make the trade-offs they make.

Never thought differently.

>  Until you can see why so many of our peers use NAT in enterprise networks in IPv4, you can't even begin to make a well-founded statement that they aren't necessary in IPv6.

Does this mean that, because you suppose I ignore why enterprises have NAT44's,
my technical arguments wouldn't need to be looked at?

(I would appreciate to be also considered a peer, and treated as such.)

> - Many large enterprises have more than enough "swamp space" (AKA IPv4 provider-independent addresses)
> - Many of _those_ enterprises use NAT (for remote sites, B-to-B network or their whole corporate networks)

Did I ever suggest anything against these well-know facts *in IPv4*?

> Until you can offer an insightful explanation of _why_ they use NAT in IPv4 ,

I have read, and I believe understood, what is said in RFC 4864:
   2.  Perceived Benefits of NAT and Its Impact on IPv4 
     2.1.  Simple Gateway between Internet and Private Network 
     2.2.  Simple Security Due to Stateful Filter Implementation 
     2.3.  User/Application Tracking
     2.4.  Privacy and Topology Hiding  
     2.5.  Independent Control of Addressing in a Private Network
     2.6.  Global Address Pool Conservation 
     2.7.  Multihoming and Renumbering with NAT 
To me, it covers well the subject.

If you have more insight to provide on what I should have understood, it will of course be welcome. 

> please stop telling them that they don't need NAT in IPv6...

They will do what they want anyway, but what they will want may be usefully influenced by complementary explanations and new proposals.

That's why I try to explain that:
1. NAT66 (stateless or stateful) breaks the e2e address preservation that facilitates various applications.
2. If these applications need to be barred, firewalls can do the job without needing NAT66 translations
3. NAT66 doesn't completely solve the multi-cpe PA-based multihoming problem (even with complex precautions as to which CPE is reached from where, it remains incompatible with SHIM6)
4. There is with SAM an approach worth looking at, because does better in this respect and can be incrementally deployed.

Yet, I acknowledge that NAT66 can work if:
- a site is single-homed or multihomed with an IPv6 PI prefix
- it is known that incoming connectivity may be barred for all hosts, and for a long time, 
What I don't quite see though, in this case, is why the site wouldn't stay IPv4-only for the time being.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 15:21:32 +0200

Le 25 oct. 2010 à 18:53, Fred Baker a écrit :
> ...
> Well, it actually has been established.

> That's the point the people you are so actively not listening to are trying to make.

Sorry to get the impression that, on your side, you are "actively not listening" to solutions that, being based on stateless automatic tunneling, do provide an alternative to NAT66, and have distinctive properties like e2e address preservation. 

> The need for address translation has nothing to do with topology obfuscation, although that point is frequently brought up; if I can read your SMTP envelopes I can figure out your topology well enough for any nefarious purposes I might have. And it has nothing to do with address amplification, which I suspect is what you're responding to as "unproven".

> It has to do with the sizes of route tables in the core and the politics of attachment at the edge. 

We do agree that we want PA-based multihoming.

> ...
> At the edge, there is a huge push for PI addressing. You can say that shim6-or-etc enables the edge networks to be independent of their providers by having a prefix from each of them; the edge networks are voting with their feet in that regard and saying it's not a network they're willing to operate.

> They want address independence, and they don't want to have to do anything when they change providers.

We do agree that this requirement makes a lot of sense for large private networks.

> They see PI addressing as the solution.

One solution, they are right, but the ONLY ONE, no.
Don't you believe that, for smaller networks, e.g. those of SOHO's, multihoming should be made to work with PA's and SHIM6? 

> And I will argue that ILNP (which requires every host in the world to be upgraded and therefore is IMHO a non-starter, although as a solution I prefer it)

Agreed that it is a non starter.

> or NAT66 as proposed in this document (which reduces the problem to one of updating CPEs by updating the checksum) handles both issues.

AKAIK, NAT66 ins NOT compatible with SHIM6 (which requires hosts to know their global addresses).
Do I miss something? 

> The transit networks get to view their route tables as entirely PA, and therefore as having been advertised by O(10^4) ISPs or large corporate networks, and the edge networks get the address independence they desire. That may be "broken" from your perspective, but from the guy-paying-the-money's perspective that is not broken. It is exactly what they are looking for.
> 
> 

Unfortunate indeed.
Not that you have a life, of course ;-), but that, although you are a coauthor of the stateless NAT66 drafts, you seem to refuse to give answers to legitimate concerns people have about what you propose.

One of these concerns is that, in my understanding:
*NAT66 (be it stateless or stateful) is NOT compatible with SHIM6 because SHIM6 does require that hosts know their GLOBAL addresses.*

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 15:32:49 +0200

> applications? Since it doesn't break address uniqueness, there

It doesn't break address uniqueness, but it does break host awareness of their "unique" addresses.
SAM's multihoming application breaks neither.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 15:34:04 +0200

+1

---

From: Chris Engel <[email-masked]>
Date: Tue, 26 Oct 2010 09:58:31 -0400

Brian,

The point I'm trying to make is why should individuals feel compelled to oppose the creation of a standard simply because that standard is only applicable to a particular scope of usage cases. For example, my company doesn't utilize VoIP.... is it reasonable for us to oppose the existance of VoIP standards or some-one elses choice to utilize VoIP as a technology simply because we won't utilize it?

The same should hold true for NAT. Those of us on the Enterprise side who CHOOSE to deploy NAT know full well that it will break certain types of apps. In general we DON'T want those type of apps crossing our network boundaries in the first place.....and take steps to try to block them even without NAT. We further recognize that IF we do want to utilize one of those apps through NAT WE bear the burden/cost for establishing a work around. Why is it not acceptable for us to ask for a standard for NAT in IPv6 that would cover our usage case?

No one is arguing for a standard that NAT MUST be deployed across the entire internet. People simply want a standard by which organizations which CHOOSE to deploy it on their OWN network boundaries can expect it to behave consistently.

Christopher Engel

> On Behalf Of Brian E Carpenter
> Sent: Monday, October 25, 2010 6:30 PM
> To: Gert Doering
> Cc: Roger Marquis; Margaret Wasserman; [email-masked]
> Subject: [nat66] e2e [New Version Notification for draft-mrw-nat66-00]
>
>
> Gert,
>
> >> But, again, many users already use "native" IPv6 (neither 6to4 nor
> >> Teredo) and no bomb has exploded. And AFAIK no bomb is timed to
> >> explode either.
> >
> > Chris Engel talks about.  Residential and enterprise are the most
> > distant points in a spectrum - residential *wants* e2e and
> p2p apps,
> > while enterprise does *not* want that.
> >
> The problem comes when one of the ends tries to participate
> in a multi-party protocol. The state that a NAPT creates to
> permit a two-party protocol to work isn't able to support a
> third party.
>
> So, people whose model of connection to the Internet only
> involves two-party client-server protocols can use the
> arguments Chris Engel has expressed, but if they want
> multi-party protocols they have to start using some kind of
> kludge. (I am including things like ICE in the category "kludge".)
>
> Has anyone analysed how stateless NAT66 will impact
> multi-party applications? Since it doesn't break address
> uniqueness, there may be hope.
>
>     Brian
>

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Oct 2010 10:20:13 -0400

On Oct 26, 2010, at 9:58 AM, Chris Engel wrote:

> Brian,
> 
> The point I'm trying to make is why should individuals feel compelled to oppose the creation of a standard simply because that standard is only applicable to a particular scope of usage cases.

what's this about feeling compelled?  why shouldn't individuals object to IETF endorsement of things that have been demonstrated to cause harm to the Internet?

nobody is telling you that you can't have NATs in your network.   you're free to do what you want there.  but you seem to think that you can demand IETF endorsement not only of NATs but of the kinds of NATs you want to use.  this is utterly bizarre.

you say you want consistent behavior of NATs.  ideally, the consistent behavior should be one where there is no NAT involved.  use of NAT should be the odd corner case, which will inherently vary from one situation to the next.   it's inherently difficult to standardize those cases.

fwiw, I could support a standard that specifies consistent behavior of NATs, but only if it applies to _all_ NATs (i.e. those that claim to conform to the standard) and only if it imposes a burden on _all_ such NATs to make them explicitly visible to, and controllable by, hosts/applications in such a way that those hosts/applications can still work in terms of globally-scoped addresses.  

but IETF has never been good at telling people "if you must do this bad thing, please do it this way".   it has a hard enough time just getting people to understand the different levels of maturity for its standards for protocols that aren't believed to do harm.  for that matter, vendors probably don't want to implement a standard that claims to do harm.  

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Oct 2010 10:47:16 -0400

Hi Remi,

On Oct 26, 2010, at 9:21 AM, Rémi Després wrote:
>
> Sorry to get the impression that, on your side, you are "actively  
> not listening" to solutions that, being based on stateless automatic  
> tunneling, do provide an alternative to NAT66, and have distinctive  
> properties like e2e address preservation.

Remi, I have read at least two versions of the SAM draft, and I have  
talked to you about it at length.  I've also talked to Mark Townsley  
about it, in an attempt to understand it.  I certainly don't remember  
every detail, but I do basically understand it.  Unless it has  
fundamentally changed since the last time I read it , SAM requires  
changes at every site and, ultimately, on every host.  Deploying  
something like that is on the scale of deploying IPv6 -- it would take  
10 or more years to do it.  I am aware that you attribute a lot of  
benefits to SAM, but for the purpose of people trying to bring up IPv6  
networks today, SAM doesn't even exist.

I have not ignored you.  I have spent hours trying to understand your  
specification, and I just don't agree that it is a superior, or even  
workable, solution to this problem right now.  You are free to work on  
it, and to try to convince people to use it, but it isn't applicable  
to the situations where people want to use NAT66 right now to deploy  
IPv6 networks.

>> or NAT66 as proposed in this document (which reduces the problem to  
>> one of updating CPEs by updating the checksum) handles both issues.
>

Nothing that requires hosts to know and use their global addresses is  
compatible with the notion of Address Independence.  Dead stop.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Oct 2010 10:50:28 -0400

On Oct 26, 2010, at 10:47 AM, Margaret Wasserman wrote:

> Nothing that requires hosts to know and use their global addresses is compatible with the notion of Address Independence.  Dead stop.

Absent a network architecture that provides a separate Identifier and robustly maintains Identifier<>Address mappings, Address Independence is a Bad Idea.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Oct 2010 10:54:33 -0400

Hi Chris,

On Oct 26, 2010, at 9:58 AM, Chris Engel wrote:
> No one is arguing for a standard that NAT MUST be deployed across  
> the entire internet. People simply want a standard by which  
> organizations which CHOOSE to deploy it on their OWN network  
> boundaries can expect it to behave consistently.

Some people have argued that we don't need a standard for NAT, because  
NATs don't have to interoperate.  That argument doesn't really apply  
to NAT66, though, because if all NAT66 devices implement the same  
algorithm, it would be possible to put multiple NAT66 boxes at the  
borders of a site, configure them with the same prefixes, and not  
worry about whether inbound traffic for a given flow runs through the  
same NAT66 box as outbound traffic.

Margaret

---

From: Chris Engel <[email-masked]>
Date: Tue, 26 Oct 2010 11:58:37 -0400

Margaret,

Not to mention the fact that if some-one were attempting to create applications/protocols which worked across a NAT boundary, having a consistent base of expected behavior for NAT implementations would be quite important, I would think.

Even where systems don't need to interoperate, standards are useful as a sort of "best practices" document. I've seen quite a number of RFC's of that type. For instance, something like RFC 4864. It's "informational", not a "standard" and I'll fully confess that the nuances of IETF's document classification system are lost on me. Without an enforcement mechanism, I don't see much practical difference between the two. Regardless, there is alot of value with RFC's of that nature, simply in terms of knowledge share for individuals/organizations seeking to implement their own solutions to common problems. That improves everyone's efficiency which I think benefits the community as a whole.

For instance, if someone with less experience then many of us here is being marketed a particular solution that is compliant with an RFC standard. They can go to that document and read and understand exactly how that solution is supposed to function. The known benefits and drawbacks of that solution. They have a good base for understanding whether that solution might be appropriate for them. I think that's a very important function RFC's can provide....beyond any interoperability concerns.

Christopher Engel

> From: Margaret Wasserman [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 10:55 AM
> To: Chris Engel
> Cc: 'Brian E Carpenter'; Gert Doering; Roger Marquis; [email-masked]
> Subject: Re: [nat66] e2e [New Version Notification for
> draft-mrw-nat66-00]
>
>
>
> Hi Chris,
>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 18:11:23 +0200

Le 26 oct. 2010 à 16:47, Margaret Wasserman a écrit :

> Remi, I have read at least two versions of the SAM draft, and I have talked to you about it at length.

Yes you took time to have explanations about draft-despres-sam-02 in July 2009, telling me that it was to report to Jari.
Following that, I don't remember having seen any comment or questions from you on it, or on its successors.

>  I've also talked to Mark Townsley about it, in an attempt to understand it.  I certainly don't remember every detail, but I do basically understand it.

What follows tells me that you only "believe" to have understood it.

> Unless it has fundamentally changed since the last time I read it , SAM requires changes at every site

This sentence shows that you don't understand that each site can become SAM-capable independently of others (like sites supporting 6rd of RFC 5969). 
This hasn't changed.

> and, ultimately, on every host.  

This shows that you don't understand that all hosts that want to take advantage of PA-based multihoming with SHIM6 will have to do something new anyway.
(Which doesn't mean that all hosts have to want it.)

> Deploying something like that is on the scale of deploying IPv6 -- it would take 10 or more years to do it.  I am aware that you attribute a lot of benefits to SAM, but for the purpose of people trying to bring up IPv6 networks today, SAM doesn't even exist.

> I have not ignored you.  I have spent hours trying to understand your specification, and I just don't agree that it is a superior, or even workable, solution to this problem right now.

It depends on what you consider to be "this problem".

In any case this shows that you don't understand that SAM does work for SHIM6 to be usable in multihomed sites having PA prefixes.
 
It also suggests that you feel secure that NAT66 won't create new problems with IPv6-capable hosts hosts as they are today (presumably using IPv6 addresses according to RFC 3484, at a time when a revision of this RFC is under study, to be deployed in all IPv6-capable hosts). 
I would not be so confident.

> ...
> Nothing that requires hosts to know and use their global addresses is compatible with the notion of Address Independence.  

This confirms that you don't understand that, in a site that routes ULAs, SAM-capable hosts can use their global addresses, which they know, in e2e packets tunneled across the site.

> Dead stop.

Your choice.

Fortunately, Dan and Jari with whom I chatted in Maastricht have been more encouraging.
The next draft on SAM for TRAnsparent Multihoming (SAM/TRAM), which I couldn't have in time for this meeting, should be better in many respects.
I hope you will then be more open to accept that it does useful things that aren't done otherwise so far.

RD

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Oct 2010 13:15:49 -0400

Remi, I have read the SAM work twice and, as you say, I don't  
understand it.  Fine.

I am working on a solution that I understand to a problem that I think  
I understand.  So far, Fred and I have been contacted by multiple  
people who are implementing this solution, and by some enterprise  
administrators who want to deploy it.  We are trying to make something  
that works for them.

The fact that SAM _could_, in your opinion, be applied to the same  
problem is not really material to whether NAT66 resolves a problem in  
enterprise networks in a way that would help enterprises with their  
IPv6 deployment.  The fact that I wrote this document doesn't stop you  
from writing your document, or from promoting it as a solution to  
anything you want to promote it as a solution to.

The fact exists, I have _not_ ignored you.  I invested time in an  
effort to understand your solution, and apparently, even after  
spending hours on the attempt, I still don't understand it.  Maybe  
that means that you should work on describing it more clearly?  That  
doesn't really have anything to do with NAT66, though.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Oct 2010 13:24:34 -0400

> Not to mention the fact that if some-one were attempting to create applications/protocols which worked across a NAT boundary, having a consistent base of expected behavior for NAT implementations w…

I certainly can't argue with that.  But if we're trying to define consistent behavior for NAT implementations for the benefit of applications/protocols, the scope would have to be a lot wider than NAT66.

> Even where systems don't need to interoperate, standards are useful as a sort of "best practices" document.

What about "least harmful bad practices"?  That seems to be what's called for here.  

Keith

---

From: Rémi Després <[email-masked]>
Date: Tue, 26 Oct 2010 19:40:56 +0200

Le 26 oct. 2010 à 19:15, Margaret Wasserman a écrit :

> 
> Remi, I have read the SAM work twice and, as you say, I don't understand it.  Fine.
> 
> I am working on a solution that I understand to a problem that I think I understand.  So far, Fred and I have been contacted by multiple people who are implementing this solution, and by some enterprise administrators who want to deploy it.  We are trying to make something that works for them.
> 
> The fact that SAM _could_, in your opinion, be applied to the same problem is not really material to whether NAT66 resolves a problem in enterprise networks in a way that would help enterprises with their IPv6 deployment.

It is a solution to a different problem in my understanding, because it permits to use SHIM6 in multi homed sites that have PA prefixes in IPv6, which NAT66 doesn't.

>  The fact that I wrote this document doesn't stop you from writing your document, or from promoting it as a solution to anything you want to promote it as a solution to.
> 
> The fact exists, I have _not_ ignored you.  I invested time in an effort to understand your solution, and apparently, even after spending hours on the attempt, I still don't understand it.  

> Maybe that means that you should work on describing it more clearly?  

It certainly does mean that.
Be sure I will try to do better.

> That doesn't really have anything to do with NAT66, though.

To a good extent, I agree.
But when it is claimed that NAT66, be it stateless or stateful, solves the multihoming problem with PAs and independent CPEs, I do object because, as I try to explain, this is technically wrong.

I also tell people that, despite some people stating that this problem is unsolvable, it is in fact solvable.
Making this statement without a pointer to a solution would rightly be criticizable. 

RD

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 27 Oct 2010 08:27:41 +0200

> - a site is single-homed or multihomed with an IPv6 PI prefix

The entire point of NAT66 use cases is to gain some benefits of
a PI prefix without incurring the associated cost. This is subject
to RFC1925 point 2 (7a); that is usually well understood.

In other words: NAT66 when you have PI is supremely pointless.

regards,
	spz

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Oct 2010 11:38:43 +0200

Le 27 oct. 2010 à 08:27, S.P.Zeidler a écrit :

> a PI prefix without incurring the associated cost.

As I tried to explain in a previous mail on this list:
- If a private-site network has two CPEs giving access to two ISPs with PA prefixes, the CPE via which a packet goes to the Internet depends on the intra-site routing.
- If intra-site routing DOESN'T make sure that all packets from a given host always go to the same CPE, then TCP connections will be broken because:
 . packets that go via a CPE different from that traversed by the the SYN packet will be received with a different source address
 . they will then be discarded at their destination because they have a different source address than that of the 5-tuple that identifies the connection.
 . the available tool to work with several source addresses, SHIM6,  can't help because, due to NAT66, hosts don't know their global addresses.
- If intra-site routing DOES make sure that all packets from a given host always go to the same CPE, incoming connection that come via the other CPE will be broken because outgoing packets will never have the right global source address.

This being said, I do agree that there is a small window of opportunity for NAT66 in multihoming sites with multiple PAs, namely IF:
- No incoming connection to any host is intended to be desirable in IPv6
- There is a need that some hosts do reach IPv6-only servers
- Intra-site routing is such that outgoing packets of a hosts always go to the same CPE, at least in the absence of ISP-access failure.
- There is no intention that any host can use SHIM6 as a tool to maintain connections when an ISP access fails.

I find these conditions extremely restrictive but, clearly, one is free to accept them.

Technical comments on the above are welcome.
If this is wrong, explaining why will be a progress.
If this is right, these limitations should IMHO be documented, e.g. in the applicability section of the NAT66 document.

Regards,
RD

> ...
> NAT66 when you have PI is supremely pointless.

To be remembered.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 08:14:16 -0400

IMO, a minimum requirement for any v6 NAT approved by IETF is that hosts/apps MUST have a way to determine the external/global addresses associated with a connection without needing an external server in global address space for ICE or similar tricks.
This mechanism MUST be the same mechanism for all standard NATs.
People need to stop insisting that hosts and apps don't need to know their addresses.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 05:28:32 -0700

> This mechanism MUST be the same mechanism for all standard NATs.

I can think of ways to do that, for example for populating your Dynamic DNS entry, but it also has issues. Depending on the source address you choose (for example if you are in a multihomed host for which the default route in the network differs in the various subnets), you may take different exit gateways in routing, and therefore may have different addresses as seen by your peer. Ideally, ILNP or NAT66 minimizes that, but it is still a possibility in the local network. Hence, in order to accomplish that, you will have to in some way ask the routing system. ICE accomplishes it by routing a packet to a remote peer that can report your address as it perceived it. At minimum, I should think you would have to communicate with the DMZ that updates your prefix. As a result, I doubt that it will be a procedure you can execute autonomously, or that could be done by, say, your DNS server.

> People need to stop insisting that hosts and apps don't need to know their addresses.

People are not insisting that applications don't need to know their own addresses. What people (I) are pointing out is that the assumption that your address is meaningful to someone *else* is a problem. This is the root cause of the issues raised in RFC 2993.

On Oct 25, 2010, at 9:53 AM, Fred Baker wrote:
> Anyone that puts IPv4 literals into HTTP or SIP/SDP headers *has* to use a global address, or anyone across a NAT can't communicate with them. What I am pointing out, in case you missed it, is that there is also a problem in the transition/coexistence phase with the assumption that just because I speak IPv[46] that you can speak IPv[46] and that there is a reliable route using IPv[46] between us. Putting an IPv[46] literal into an application header is not only stupid because of the coupling implied - that your address space and mine overlap - but because of the coexistence coupling.

---

From: "S.P.Zeidler" <[email-masked]>
Date: Wed, 27 Oct 2010 14:34:36 +0200

Hi,

> - If intra-site routing DOESN'T make sure that all packets from a given host always go to the same CPE, then TCP connections will be broken because:

That is actually not correct. You need to ensure that a source-destination
pair always goes the same way. That is trivially done by setting static
routes and making sure that you have the 'right' source address for the
chosen path. Source prefix substitution in this case is just a way to
make sure that the source address for a given route is correct (without
the sourcing host being required to be smart enough to do it by itself).

[...]
>  . the available tool to work with several source addresses, SHIM6,  can't help because, due to NAT66, hosts don't know their global addresses.

It also doesn't help because the hosts I deal with today don't do SHIM6,
nor are expected to do so within the next 4 years. I need a solution that
works by ~ June 2011.

[...]

> - No incoming connection to any host is intended to be desirable in IPv6

In my opinion, hosts that can be talked to from the outside belong in
the DMZ and are few enough that they can be manually configured, and thus
have hand-crafted policies. These may actually run multi-homed with
N>>2 prefixes, and if they have to be renumbered it'll not be the
"internal" address that changes, but just one of the outside prefixes,
which is work and annoying but not a near-catastrophic event with weeks
of fall-out. DMZ hosts IMO should not be subject to NAT anyway. YMMV.

regards,
	spz

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 08:37:55 -0400

On Oct 27, 2010, at 8:28 AM, Fred Baker wrote:

> I can think of ways to do that, for example for populating your Dynamic DNS entry, but it also has issues.

yeah, including that some ISPs (like mine) intercept traffic to port 53.   and the fact that not all sites maintain DNS records for all of their hosts, or want to.
also, DNS works on a per-host basis but NATs in general (not NAT66) work on a per-binding basis, so a general mechanism for letting hosts/apps know what address is associated with a connection can't use DNS .. at least not in the way we currently use DNS.

> Depending on the source address you choose (for example if you are in a multihomed host for which the default route in the network differs in the various subnets), you may take different exit gateways in routing, and therefore may have different addresses as seen by your peer. Ideally, ILNP or NAT66 minimizes that, but it is still a possibility in the local network. Hence, in order to accomplish that, you will have to in some way ask the routing system.

why not put the burden on the part that's causing the problem?   i.e. why not build the functionality into the NAT? 

> ICE accomplishes it by routing a packet to a remote peer that can report your address as it perceived it. At minimum, I should think you would have to communicate with the DMZ that updates your prefix. As a result, I doubt that it will be a procedure you can execute autonomously, or that could be done by, say, your DNS server.
> 

the address is only (okay, mostly) meaningful because it's the only way to contact a process that's already using the address. 

Keith

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Oct 2010 14:57:01 +0200

> This mechanism MUST be the same mechanism for all standard NATs.

I agree with this, but then host modifications are needed anyway.

Then a key supposed advantage of NAT66 (stateful or stateless) over solutions that depend on host upgrades vanishes.
Do you agree?

Besides, the technical analysis below of the relationship between NAT66, PA-prefixes, and multihoming, doesn't depend on hosts knowing or not their addresses.
I do hope someone will eventually comment its technical contents.

> People need to stop insisting that hosts and apps don't need to know their addresses.`

Yes, some apps need it, and therefore some hosts do need it.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Oct 2010 15:14:04 +0200

Le 27 oct. 2010 à 14:34, S.P.Zeidler a écrit :

> chosen path.

You are right, the sentence should have said "all packets from a given host to a given destination".

Note that I didn't say it wasn't feasible, just that it needs to be done.
How "trivial" this configuration is a matter of appreciation, but it does work.
A drawback however is that, without further precautions, it breaks the ability to use another CPE when one fails.

> of fall-out. DMZ hosts IMO should not be subject to NAT anyway. YMMV.

The sentence would have been more precise with "No incoming connection to any host *behind the NAT66* is intended to be desirable in IPv6.
I agree.

Thanks,
RD

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 09:36:02 -0400

> I agree with this, but then host modifications are needed anyway.

If the mechanism were defined carefully, an app could determine what the NAT was doing without host support.   Apps that don't care about addresses could continue to work without any host changes; apps that do care about addresses would have a way to adapt to the NATted world without waiting for host OS to be upgraded.  

The trick is then for the OS vendor to figure out how to upgrade the network API without breaking apps that were working.   This is nontrivial, but it can be done if people resist the temptation to try to create illusions for apps.   If the OS wants to create an abstraction that apps can optionally use that provides a simpler programming model, that's fine, but trying to create the illusion of a simple addressing model on a NATted internet is certain to produce yet another set of very obscure failures which are difficult to diagnose and more difficult to fix.

Having NATs in the network is certainly not my preferred solution, because it's *very* difficult to work out all of the cases so that things work well - and I don't have much faith in IETF's and vendors' ability to work out and implement those cases in sufficient detail.   But having NATs with explicit visibility (and ideally control) by apps is much, much better than the traditional strategies of pretending that NATs don't break apps and/or trying to have the NATs act as ALGs for the apps.

> Then a key supposed advantage of NAT66 (stateful or stateless) over solutions that depend on host upgrades vanishes.

Any time you introduce NATs into the network you're going to break apps, and force those apps to try to cope.   The solution doesn't necessarily require host upgrades so much as app upgrades for those apps that break, but host OS vendors will inevitably want to provide support for those apps.   However the host upgrade doesn't have to be a prerequisite.  

In general, I agree that proposals that require simultaneous upgrades to both the host and the routing system are imposing too high a barrier.  But if the two upgrades can be decoupled, I don't think that's too high a barrier.  The necessary condition is that every upgrade (of a router or host or app) should not degrade existing operations, and also provide at least the potential for improved functionality.

Keith

---

From: Rémi Després <[email-masked]>
Date: Wed, 27 Oct 2010 15:54:34 +0200

Chris,

I would like to make sure that, despite our recent exchange of arguments, you don't count me among those who would "oppose the creation" of a NAT66 standard, or even of two (one for stateless and one for stateful).

If you find any sentence from me suggesting such an opposition, I will for sure amend it.

My points are about MAKING CLEAR what these specification do achieve, and don't achieve.

Regards,
RD

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 08:19:39 -0700

> why not put the burden on the part that's causing the problem?   i.e. why not build the functionality into the NAT? 

well, I'm willing enough to put something comparable to ICE/STUN functionality into the DMZ system. One could, for example, send a datagram from each of the addresses on each of the host's interfaces to an anycast address and get a response, and define the anycast address as "all translators". But you said, or I thought your said, that you didn't want to send a datagram. Got a problem there; your host isn't the NAT, and only the NAT or a host beyond it knows for sure.

I still don't understand the reason you need your *external* addresses apart from populating DDNS.

In private email to someone else that was requesting that hosts implement the expired SAF virtual interface functionality, I said the following. Tell me, if you would, where I'm wrong?

On Oct 27, 2010, at 7:31 AM, Fred Baker wrote:
> Personally, I think the expired SAF draft is lacking in some important ways.
> 
> The notion of a virtual interface on which the host knows its external addresses is intriguing. However, I don't know of any such implementation on Windows, Apple, Solaris, Linux, FreeBSD, or other platform. One of the objectives of NAT66 is to enable the deployment of scalable routing in the transit backbone without impacting host implementations; if I were willing to require changes to host implementations, I would be pushing ILNP. That is IMHO a technically superior solution (the host identifier is the same regardless of exit gateway, while with NAT66 EID checksum adjustments the host identifier changes), but requires all TCP and UDP implementations be simultaneously updated. So requiring a host change seems to me an ill-considered - and untested - poison pill.
> 
> Also, routing can be highly variable depending on the route chosen. A case in point was tested by Geoff Huston at my request for the IAB in perhaps 1999 or 2000. My point was to demonstrate that the choice of source and destination address pair affected a session's experience of the network. Geoff, from his host in Canberra, pinged two hosts in Singapore that were physically under a kilometer apart but had different routing due to difference in contract. One route followed a cable directly from Australia to Singapore and was under 100 ms RTT; the other went to Singapore via San Francisco and was over 600 ms RTT. Presumably, if they had been the same multihomed host with addresses from two providers, the user experience would be at the mercy of the vagaries of address selection. Putting those conflicting addresses on the same virtual interface gives the application very little guidance and less control over that experience.
> 
> The latter point comes back to the "happy eyeballs" draft; I think that applications should not be in the business of choosing their addresses, and the underlying operating systems should take on the task of opening sessions that have something that approximates the best RTT available; the specific algorithm proposed in the "happy eyeballs" draft may not work on all operating systems, but the results it achieves should be achievable, and are important to users.
> 
> As to the value of an application knowing its external addresses, to my way of thinking that is debatable. It is necessary for DNS to advertise all of the relevant addresses, and in the case of Dynamic DNS the host will need to be able to determine what those addresses are. Once that is done, the only reason an application has for knowing its own address is if it will do something different based on its own address in a session; other than that, it may express curiosity, but sessions that get to it obviously used one of its addresses. I know of applications that do something different based on peer addresses (mail MTAs, for example, often do a reverse DNS lookup on the peer's address and applies an anti-spam policy based on it), but can't say I know of applications that do something different depending on which address of their own is used. And in any event, in a network that places NAT66 between itself and its upstream, the datagram would never arrive at the end system using the external address - it would always be the internal address. So such discrimination would be difficult.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Oct 2010 08:43:14 -0700

On Oct 27, 2010, at 06:36, Keith Moore wrote:
> If the mechanism were defined carefully, an app could determine what the NAT was doing without host support.   Apps that don't care about addresses could continue to work without any host changes; apps that do care about addresses would have a way to adapt to the NATted world without waiting for host OS to be upgraded.  [...]

I have to concur with Keith.  I'll vigorously argue against any NAT66 proposal that doesn't include some kind of standard self-address fixing mechanism that applications can use dynamically to find the exterior destination addresses that match the exterior source addresses in use for them at the translator.

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Oct 2010 08:50:10 -0700

On Oct 27, 2010, at 08:43, james woodyatt wrote:

> to find the exterior destination addresses that match the exterior source addresses in use for them at the translator.

I need to proofread better before I choose the "Send..." option.  This is exactly backward.  It needs to read "to find the exterior source address that corresponds to an exterior destination address at the translator."

---

From: Chris Engel <[email-masked]>
Date: Wed, 27 Oct 2010 12:05:48 -0400

Remi,

I don't count you against such things. Nor do I really have any issue with Fred and Margaret designing their draft the way the intend it to work. I think it'll be a useful solution for some sub-set of the community. The only real issues I've had is with claims that NAT44 or abstraction in general aren't useful aside from address conservation. Clearly they are, or so many folks wouldn't be using them for things other then that. For instance PCI DSS has squat to do with address conservation but if you check it out, NAT is listed as a requirement in there (though they do leave the possibility open to use other compensating controls to provide similar functionality).

I see alot of hostility toward NAT in organizations like IETF and in part I understand it. Participation in such organizations, from what I've observed, seems to be heavily weighted toward application and protocol designers with transit operators being another large group. I can fully understand antagonism toward NAT among such groups (especially App and Protocol designers) as I'm sure it's existence majorly complicates their work.

I'm more on the Enterprise Operations side of thing (Actually Enterprise and SaaS but our apps are traditional client/server web based stuff..so no real complications from NAT). Enterprise Operators, especially small and mid-sized, seem woefully underrepresented in IETF and similar organizations. So occasionally I participate on such lists trying to offer a perspective from my side of things. As on of the people who actually use and deploy many of the things folks here design (or rather things vendors build based on the RFC's you create).

I've been working in the trenches on this side of things for nearly 20 years, 10 at my current organization. NAT is a VERY valuable tool in my toolbox of solutions for dealing with many of the issues I've described. Clearly it's not the only tool...but it's valuable enough that we are holding off even considering IPv6 deployment until we see clear vendor support for achieving the same sort of things NAT did for us under IPv4 in a reasonable manner. Understand that while the technology itself can change between IPv4 and IPv6...the technology goals need to remain the same. From my perspective I could care squat whether I'm using IPv4, IPv6, IPX/SPX or IPv9999. I care about meeting my technology goals. Right now, I don't see any good alternative to something very much like IPv4 statefull NAT which does that. Now some people may claim that NAT isn't really doing what I believe it's doing for me or possibly even that my technology goals don't make sense. However, for the past 10 years that I've been running this side of things, my organization has had a spotless security record and a nearly spotless operational record. That's something very few similar organizations can boast. We get rave reviews from our very demanding customers on those aspects and our owners and management are entirely pleased with the results. So if I'm deluded about NAT and our technology goals...then I think I'm going to stick with that delusion :)

Bottom line, alot of folks are wondering why so many Enterprises like mine are dragging our feet about jumping on the IPv6 band-wagon... or for that matter other protocols/technologies that are being designed/proposed. If folks want to avoid that happening, then they need to start listening to us.... understand what we need/want to achieve, how we go about using our tools on a daily basis and the factors that are important to us.  If that doesn't happen, then 5 years from now they are still going to be wondering why folks aren't chomping to jump on the IPv6 (or any other protocol you choose to name) bandwagon. What I see in many cases, is a large disconnect between the people writing RFC's and the people using solutions based on them. In my own blunt and pig-headed way, I'm trying to bridge that gap a little.

Frankly, I think organizations like IETF could benefit alot from wider public participation. Though perhaps, there needs to be some better separation between lists intended for specific recommendations on RFC drafts and lists intended for public input on the goals/issues those RFC's are trying to address.

Christopher Engel

> From: Rémi Després [mailto:[email-masked]]
> Sent: Wednesday, October 27, 2010 9:55 AM
> To: Chris Engel
> Cc: 'Brian E Carpenter'; Gert Doering; Roger Marquis;
> Margaret Wasserman; [email-masked]
> I would like to make sure that, despite our recent exchange
> of arguments, you don't count me among those who would
> "oppose the creation" of a NAT66 standard, or even of two
> (one for stateless and one for stateful).
>
> > The point I'm trying to make is why should individuals feel
> compelled
> > to oppose the creation of a standard simply because that
> standard is
> > only applicable to a particular scope of usage cases.
>
>
>
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 12:08:25 -0400

> I still don't understand the reason you need your *external* addresses apart from populating DDNS.

That app still needs an address that functions as a referral address for any host to which it might need to make a referral.  And the app has no way of knowing which realms those hosts are in.  So basically it needs a global address.

There are lots of problems with relying on DNS to do referrals which have been reiterated several times.  The bottom line is that DNS is one way of doing referrals which is suitable in many cases, but far from suitable for every case.

> In private email to someone else that was requesting that hosts implement the expired SAF virtual interface functionality, I said the following. Tell me, if you would, where I'm wrong?

You cannot impose NAT of any kind without breaking apps, and therefore, without requiring changes to hosts.  The objective of NAT66 might have been to not impact host implementations, but that was unrealistic.    Or maybe you defined "host" in such a way as to not include apps, but the bottom line is that either way the contents of files on hosts have to change in order to cope with the NAT.  (Assuming approximately the same barrier to deployment in both cases, it makes MORE sense to require only host operating systems to upgrade than to require apps to upgrade - though in practice the latter might be easier because (a) most apps probably don't need to be upgraded, so there's less initial pain, and (b) it aids deployment immensely if host/app upgrades can be decoupled from network upgrades.)

If you're going to impose NAT, it makes more sense to define NAT in such a way that apps and hosts can reliably find out how to function in that world, than to expect apps and hosts to use heuristics in the hope that they can function in that world.

I need to look more at ILNP - but I think what is needed is a solution that doesn't immediately require host upgrades to work.  On the other hand, if a non-upgraded host would still work but an upgraded host got better performance, that would provide an incentive to upgrade the hosts.

Ideally, the application doesn't want to fool with address selection.  But unless the host stack and/or network do a good job of getting packets from the source to the destination, via an effective route and without corrupting those packets, some applications are forced to deal with such things.    So there are definitely hazards associated with virtual interfaces that try to do address selection - unless those virtual interfaces have access to reliable information that lets them make good choices.   (Note also that address selection is in some sense a quality-of-service issue - one pair of addresses might work well for one application, and a different pair work better for a different application.)

Also note that putting "all relevant addresses" in DNS doesn't remove the burden of address selection - it just moves the problem around.  But again, DNS is simply not suitable as a general-purpose referral mechanism.   

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 12:22:39 -0400

> I see alot of hostility toward NAT in organizations like IETF and in part I understand it. Participation in such organizations, from what I've observed, seems to be heavily weighted toward applicat…

application implementors are grossly under-represented in IETF, which is why IETF hasn't reacted more vigorously and more uniformly against NATs.

network equipment vendors have the most clout of any group in IETF.  several of those guys were encouraging NAT and discouraging IETF from telling the truth about NAT, because they were in the business of selling NATs, and because NATs moved their problems into someone else's space. 

NATs are a lot like drugs.  drugs are indeed useful when used judiciously - in specific cases where they're indicated and with due regard for their limitations.  but over-use of drugs, especially without proper supervision, causes huge public health problems.    this is true for antibiotics, it's true for statins, it's true for antidepressants, etc.  and it's true for NATs.

you keep insisting on IETF endorsing v4-like NATs in IPv6 - but the effect of what you're trying to do is make IPv6 as broken as IPv4 is.  no thanks.

---

From: Chris Engel <[email-masked]>
Date: Wed, 27 Oct 2010 13:04:13 -0400

I actually wouldn't have any objection to some mechanism built into NAT that allowed for a requesting host/application to be informed of the Public Address it would be assigned by the NAT device. My only caveat would be that the Administrator SHOULD be able to disable such functionality on a given interface if they choose. It could be enabled by default, but there should be an option to turn it off if you explicitly choose to do so.

Note that I understand the reluctance for applications to rely overly on DNS. For practical purposes with propagation and caching issues, TTL's are often not respected. So even if you can anticipate a TTL which is reasonable for your needs (not always the case), it's pot-luck whether any given end point outside your control will actually pay attention to it and get the right IP address. For hosts that change IP's on even an occasional basis, that can be a real issue. In fact, that's one of the usage cases we currently have for NAT. Once we establish a public DNS entry for a host, we almost never change it. If we need to change the device providing that service, we simply change the NAT mapping on the boundary device. That way we can control the timing of the change exactly and we don't need to worry about who has what cached and will be pointing to the wrong device for some period of time.

Not sure if those issues will still be prevalent with DNS under IPv6, but they are in the IPv4 world today.

Christopher Engel

> On Behalf Of Keith Moore
> Sent: Wednesday, October 27, 2010 12:08 PM
> To: Fred Baker
> Cc: NAT66
> >>> Depending on the source address you choose (for example
> if you are
> >>> in a multihomed host for which the default route in the network
> >>> differs in the various subnets), you may take different exit
> >>> gateways in routing, and therefore may have different
> addresses as
> >>> seen by your peer. Ideally, ILNP or NAT66 minimizes that,
> but it is
> >>> still a possibility in the local network. Hence, in order to
> >>> accomplish that, you will have to in some way ask the routing
> >>> system.
> >>
> >> why not put the burden on the part that's causing the
> problem?   i.e. why not build the functionality into the NAT?
> >
> > well, I'm willing enough to put something comparable to ICE/STUN
> > functionality into the DMZ system. One could, for example, send a
> > datagram from each of the addresses on each of the host's
> interfaces
> > to an anycast address and get a response, and define the anycast
> > address as "all translators". But you said, or I thought your said,
> > that you didn't want to send a datagram. Got a problem there; your
> > host isn't the NAT, and only the NAT or a host beyond it knows for
> > sure.
> >
> > I still don't understand the reason you need your
> *external* addresses
> > apart from populating DDNS.
>
> That app still needs an address that functions as a referral
> address for any host to which it might need to make a
> referral.  And the app has no way of knowing which realms
> those hosts are in.  So basically it needs a global address.
>
> There are lots of problems with relying on DNS to do
> referrals which have been reiterated several times.  The
> bottom line is that DNS is one way of doing referrals which
> is suitable in many cases, but far from suitable for every case.
>
> > In private email to someone else that was requesting that hosts
> > implement the expired SAF virtual interface functionality,
> I said the
> > following. Tell me, if you would, where I'm wrong?
>
> You cannot impose NAT of any kind without breaking apps, and
> therefore, without requiring changes to hosts.  The objective
> of NAT66 might have been to not impact host implementations,
> but that was unrealistic.    Or maybe you defined "host" in
> such a way as to not include apps, but the bottom line is
> that either way the contents of files on hosts have to change
> in order to cope with the NAT.  (Assuming approximately the
> same barrier to deployment in both cases, it makes MORE sense
> to require only host operating systems to upgrade than to
> require apps to upgrade - though in practice the latter might
> be easier because (a) most apps probably don't need to be
> upgraded, so there's less initial pain, and (b) it aids
> deployment immensely if host/app upgrades can be decoupled
> from network upgrades.)
>
> If you're going to impose NAT, it makes more sense to define
> NAT in such a way that apps and hosts can reliably find out
> how to function in that world, than to expect apps and hosts
> to use heuristics in the hope that they can function in that world.
>
> I need to look more at ILNP - but I think what is needed is a
> solution that doesn't immediately require host upgrades to
> work.  On the other hand, if a non-upgraded host would still
> work but an upgraded host got better performance, that would
> provide an incentive to upgrade the hosts.
>
> Ideally, the application doesn't want to fool with address
> selection.  But unless the host stack and/or network do a
> good job of getting packets from the source to the
> destination, via an effective route and without corrupting
> those packets, some applications are forced to deal with such
> things.    So there are definitely hazards associated with
> virtual interfaces that try to do address selection - unless
> those virtual interfaces have access to reliable information
> that lets them make good choices.   (Note also that address
> selection is in some sense a quality-of-service issue - one
> pair of addresses might work well for one application, and a
> different pair work better for a different application.)
>
> Also note that putting "all relevant addresses" in DNS
> doesn't remove the burden of address selection - it just
> moves the problem around.  But again, DNS is simply not
> suitable as a general-purpose referral mechanism.
>
> Keith
>
>
> >
> >> The notion of a virtual interface on which the host knows its
> >> external addresses is intriguing. However, I don't know of
> any such
> >> implementation on Windows, Apple, Solaris, Linux, FreeBSD,
> or other
> >> platform. One of the objectives of NAT66 is to enable the
> deployment
> >> of scalable routing in the transit backbone without impacting host
> >> implementations; if I were willing to require changes to host
> >> implementations, I would be pushing ILNP. That is IMHO a
> technically
> >> superior solution (the host identifier is the same
> regardless of exit
> >> gateway, while with NAT66 EID checksum adjustments the host
> >> identifier changes), but requires all TCP and UDP
> implementations be
> >> simultaneously updated. So requiring a host change seems to me an
> >> ill-considered - and untested - poison pill.
> >>
> >> Also, routing can be highly variable depending on the
> route chosen. A
> >> case in point was tested by Geoff Huston at my request for
> the IAB in
> >> perhaps 1999 or 2000. My point was to demonstrate that the
> choice of
> >> source and destination address pair affected a session's
> experience
> >> of the network. Geoff, from his host in Canberra, pinged
> two hosts in
> >> Singapore that were physically under a kilometer apart but had
> >> different routing due to difference in contract. One route
> followed a
> >> cable directly from Australia to Singapore and was under
> 100 ms RTT;
> >> the other went to Singapore via San Francisco and was over 600 ms
> >> RTT. Presumably, if they had been the same multihomed host with
> >> addresses from two providers, the user experience would be at the
> >> mercy of the vagaries of address selection. Putting those
> conflicting
> >> addresses on the same virtual interface gives the application very
> >> little guidance and less control over that experience.
> >>
> >> The latter point comes back to the "happy eyeballs" draft; I think
> >> that applications should not be in the business of choosing their
> >> addresses, and the underlying operating systems should take on the
> >> task of opening sessions that have something that approximates the
> >> best RTT available; the specific algorithm proposed in the "happy
> >> eyeballs" draft may not work on all operating systems, but the
> >> results it achieves should be achievable, and are
> important to users.
> >>
> >> As to the value of an application knowing its external
> addresses, to
> >> my way of thinking that is debatable. It is necessary for
> DNS to advertise all of the relevant addresses, and in the
> case of Dynamic DNS the host will need to be able to
> determine what those addresses are. Once that is done, the
> only reason an application has for knowing its own address is
> if it will do something different based on its own address in
> a session; other than that, it may express curiosity, but
> sessions that get to it obviously used one of its addresses.
> I know of applications that do something different based on
> peer addresses (mail MTAs, for example, often do a reverse
> DNS lookup on the peer's address and applies an anti-spam
> policy based on it), but can't say I know of applications
> that do something different depending on which address of
> their own is used. And in any event, in a network that places
> NAT66 between itself and its upstream, the datagram would
> never arrive at the end system us
>  ing the external address - it would always be the internal
> address. So such discrimination would be difficult.
> >
>

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 10:35:28 -0700

> That app still needs an address that functions as a referral address for any host to which it might need to make a referral.  And the app has no way of knowing which realms those hosts are in.  So…

Well, and it needs to supply both IPv4 and IPv6 addresses when appropriate, and there may be multiple of each that might be relevant. To me, that translates to "DNS Name". If it really has to be a literal, which I already pointed out has some brain-deadness related to IPv4 and IPv6 routing (the fact that you and I both have an IPv[46] address doesn't mean that the network has a route that connects them, even if the addresses are global). But that is not is not its *own* address; it is the address of a neighbor.

> There are lots of problems with relying on DNS to do referrals which have been reiterated several times.  The bottom line is that DNS is one way of doing referrals which is suitable in many cases,…

If you are adamant that the web/sip/whatever referral can't be a DNS name, will you allow the referring host to look it up in DNS? As noted, DNS will have the external addresses of any system it has a name for.

> You cannot impose NAT

In several statements here you make the statement "you...impose NAT". Note that I am, and Margaret is, doing nothing of the kind. Network operators are trying to solve a very real problem, one that has been articulated in detail, and Margaret and I are providing a tool to enable them to do that. Absent the problem, the solution isn't needed and won't be deployed. The folks on this list that have been telling you that they plan to deploy something are telling you they have a problem that needs to be solved.

> of any kind without breaking apps, and therefore, without requiring changes to hosts.  The objective of NAT66 might have been to not impact host implementations, but that was unrealistic.    Or maybe you defined "host" in such a way as to not include apps, but the bottom line is that either way the contents of files on hosts have to change in order to cope with the NAT.  (Assuming approximately the same barrier to deployment in both cases, it makes MORE sense to require only host operating systems to upgrade than to require apps to upgrade - though in practice the latter might be easier because (a) most apps probably don't need to be upgraded, so there's less initial pain, and (b) it aids deployment immensely if host/app upgrades can be decoupled from network upgrades.)
> 

I agree that host upgrades should not be required. That is the reason that Margaret and I are proposing a solution that doesn't require host upgrades that we know of.

> Ideally, the application doesn't want to fool with address selection.  But unless the host stack and/or network do a good job of getting packets from the source to the destination, via an effective route and without corrupting those packets, some applications are forced to deal with such things.

"Happy Eyeballs". http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6. If the socket API were rationally designed, what it is saying would be buried in a connect_to_name() call that was handed a name and returned a connected socket or an error. I agree that the OS should supply this. The socket API isn't designed that way; the application is forced to supply the missing code. Sorry, not my choice. I believe that this is being discussed in apparea.

> So there are definitely hazards associated with virtual interfaces that try to do address selection - unless those virtual interfaces have access to reliable information that lets them make good choices.   (Note also that address selection is in some sense a quality-of-service issue - one pair of addresses might work well for one application, and a different pair work better for a different application.)
> 

Thanks for answering my question regarding the text following. It implies to me that my analysis is correct.

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 13:38:46 -0400

> I actually wouldn't have any objection to some mechanism built into NAT that allowed for a requesting host/application to be informed of the Public Address it would be assigned by the NAT device. M…

Why are you trying to cripple apps?

If you don't want certain apps to function across your network border, disable their traffic at the firewall.   You're trying way too hard to make NATs do a firewall's job.

> Note that I understand the reluctance for applications to rely overly on DNS. For practical purposes with propagation and caching issues, TTL's are often not respected.

True, but there's a lot more to it than that.

Here's a quick example:  Say you want to write an app that needs to do referrals.   Say further that the app needs to be port-agile because of the potential for NAPTs in the signal path.  Let's say further that the app uses ICE or some other heuristic to find its external/global transport address.  Where in DNS is the app going to store that transport address?  (Don't say that the application vendor should provide zones and servers for that purpose - that's basically tantamount to saying that every app needs to have its own referral servers in the public network.  Also don't say that the app should be able to use the host's DNS zones, because admins are highly unlikely to allow that.)  How is it going to reliably store/update that transport address given that some ISPs intercept port 53?  How does the app get credentials to allow it to write RRs to that zone?   And how much does that really help the referral problem?  Sure it provides some insulation against the transport address changing - assuming the app notices the change it can update the transport address in DNS.  But there is the TTL problem, as you point out.  DNS is fundamentally designed for storing data that doesn't change often, and where the changes are managed events.    And even if you can use small TTLs and get all of the parties involved to respect those TTLs, that doesn't fix TCP connections that break when the transport address changes.

And that's just one example.

Keith

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 10:40:23 -0700

> network equipment vendors have the most clout of any group in IETF.  several of those guys were encouraging NAT and discouraging IETF from telling the truth about NAT, because they were in the busi…

I presume, in that, that you are talking about me. If you're going to do so, it would be nice if your comments reflected having read mine. My arguments have nothing to with Cisco's bottom line, and have everything to do with network operational issues. If it's Cisco's bottom line that is at issue, we can provide the memory to represent O(10^7) routes in the route table and will happily do so - bigger high margin routers are excellent for Cisco's bottom line.

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 10:45:05 -0700

On Oct 27, 2010, at 10:04 AM, Chris Engel wrote:

> I actually wouldn't have any objection to some mechanism built into NAT that allowed for a requesting host/application to be informed of the Public Address it would be assigned by the NAT device.

I don't object to that either. I do question the requirement apart from Dynamic DNS. Keith's comment earlier today indicated that he didn't like the mechanisms that exist for doing so, and specifically didn't want to have to send a datagram to another system. I'll happily suggest an alternative mechanism, but without asking the routing system, there is an issue. So anything I suggest will involve sending a datagram, and that datagram will be sent to one of:

1) a DNS server that already knows the answer
2) a DMZ that can generate the answer
3) an application beyond a DMZ that can generate the answer

---

From: Chris Engel <[email-masked]>
Date: Wed, 27 Oct 2010 14:38:29 -0400

> Sent: Wednesday, October 27, 2010 1:39 PM
> To: Chris Engel
> Cc: Fred Baker; NAT66
> Subject: crippling apps ; dns as a generic referral mechanism (not)
>
>
>
> > I actually wouldn't have any objection to some mechanism built into
> > NAT that allowed for a requesting host/application to be
> informed of
> > the Public Address it would be assigned by the NAT device. My only
> > caveat would be that the Administrator SHOULD be able to
> disable such
> > functionality on a given interface if they choose. It could
> be enabled
> > by default, but there should be an option to turn it off if you
> > explicitly choose to do so.
>
> If you don't want certain apps to function across your
> network border, disable their traffic at the firewall.
> You're trying way too hard to make NATs do a firewall's job.
>

Enterprise Admins spend a great deal of time keeping unauthorized apps from running. Many such apps are problematic to use in an Enterprise environment, even when they aren't intended to be malicious and have legitimate functions outside such environments.

What I'm trying to accomplish is insure that the people responsible for deploying and maintaining such a hypothetical mechanism on thier OWN boundary are able to excersize some degree of control over how it functions. There may well be legitimate reasons for an engineer to NOT want a host/application to be aware of it's external IP.

In the case given we would be talking about an OPTION that was disabled by default and had to be explicitly enabled in order to disallow such functionality. There could even be strong language reccomending against doing so and listing the consequences of such. In that case, the only people who would be breaking apps, would be doing so on purpose.

Where is the problem with allowing the people who own and are responsible for deploying and administering a solution some granularity of control over how it works?

> > Note that I understand the reluctance for applications to
> rely overly
> > on DNS. For practical purposes with propagation and caching issues,
> > TTL's are often not respected.
>
> Here's a quick example:  Say you want to write an app that
> needs to do referrals.   Say further that the app needs to be
> port-agile because of the potential for NAPTs in the signal
> path.  Let's say further that the app uses ICE or some other
> heuristic to find its external/global transport address.
> Where in DNS is the app going to store that transport
> address?  (Don't say that the application vendor should
> provide zones and servers for that purpose - that's basically
> tantamount to saying that every app needs to have its own
> referral servers in the public network.  Also don't say that
> the app should be able to use the host's DNS zones, because
> admins are highly unlikely to allow that.)  How is it going
> to reliably store/update that transport address given that
> some ISPs intercept port 53?  How does the app get
> credentials to allow it to write RRs to that zone?   And how
> much does that really help the referral problem?  Sure it
> provides some insulation against the transport address
> changing - assuming the app notices the change it can update
> the transport address in DNS.  But there is the TTL problem,
> as you point out.  DNS is fundamentally designed for storing
> data that doesn't change often, and where the changes are
> managed events.    And even if you can use small TTLs and get
> all of the parties involved to respect those TTLs, that
> doesn't fix TCP connections that break when the transport
> address changes.
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 15:07:27 -0400

> What I'm trying to accomplish is insure that the people responsible for deploying and maintaining such a hypothetical mechanism on thier OWN boundary are able to excersize some degree of control ov…

I get that.  What I don't get is that the granularity for such control should be on a per-NAT basis, rather than on a per-application basis.  For every app that should not be aware of its external IP address, there's an app that should be aware of its external IP address.  

And furthermore, if you want to keep an app from being aware of its external IP address, the only reliable way to do that is to block that app from communicating with any external host.  If you just tell the NAT to disable that functionality, there's at least some chance the app can still use ICE on some other external server.  So you're not buying yourself any security benefit by disabling the functionality in the NAT.  All you're doing is making apps more complex and harder for people like yourself to control.

Again, you're trying way too hard to make the NAT do the firewall's job.

> In the case given we would be talking about an OPTION that was disabled by default and had to be explicitly enabled in order to disallow such functionality. There could even be strong language recc…

Typing the word OPTION in all caps doesn't keep it from doing harm.  What app writers need is a predictable environment, not one that changes at the whim of a network administrator.   I'm not saying that apps should be able to do everything that they want, I'm saying that IETF shouldn't endorse a mechanism that can't be made to work fairly consistently from one network to the next.   There's a world of difference between creating a practical necessity for an app to try using the NAT's ICE mechanism, and if that fails, to try using an external server to do the same thing; from creating a uniform way for apps to ask for an external address and having the app be told "it's a violation of policy for you to send a referral to an external peer".    And the only way to make the latter kind of mechanism viable is to do it on a per-app basis.

In general, apps have no way in the current network architecture to distinguish explicitly chosen network policy, from network failures and the inability of access control mechanisms to be applied with sufficient granularity.   Apps are often expected "to do the right thing" (even by network administrators) in the face of NATs, firewalls, etc. that block traffic on a very coarse-grained basis, and "the right thing" for the app to do is not (in general) to just fall over and play dead when the network, NAT, firewall, etc. doesn't permit the first thing that the app tries to do (especially when the app generally has no idea why the first thing it tried to do didn't work).

So what I see is that you need two things:

1. Control over access to network resources on a per-app basis.

2. A mechanism that allows an app to know whether what it is trying to do would violate network policy.  Then it at least becomes possible for well-behaved apps to know when they're crossing a line and to issue useful error messages to users ("this operation is prohibited by your network administrator, whose address is [email-masked]").

Both of these are in the firewall space.  Neither one is in the NAT space?

> Where is the problem with allowing the people who own and are responsible for deploying and administering a solution some granularity of control over how it works?

The problem is that you keep trying to get IETF to endorse brain-damaged mechanisms.  It's not that you don't have legitimate concerns, it's that you keep insisting that IETF recommend that people  use the wrong tools for the job.

Keith

---

From: Roger Marquis <[email-masked]>
Date: Wed, 27 Oct 2010 13:48:23 -0700 (PDT)

Keith Moore wrote:
> you keep insisting on IETF endorsing v4-like NATs in IPv6 - but the effect
> of what you're trying to do is make IPv6 as broken as IPv4 is. no thanks.

NATs are not broken in IPv4.  This is a statement of fact given the
evidence (user-base and rate of growth).  Statements that v4-style NATs
will make v6 broken are opinion, unsupportable opinion given v6's rate of
adoption.

As long as consumers and security experts continue demanding v4-style
(stateful) NAT in IPv6 efforts to kill it and/or proclaim it dead are
greatly exaggerated, at best.

In the real world we recognize that IPv6 is and will continue to go
nowhere until working NAT64 and NAT66 implementations are available.
That's not opinion but simple, objective, agenda-free observation.

Roger Marquis

---

From: Roger Marquis <[email-masked]>
Date: Wed, 27 Oct 2010 13:51:01 -0700 (PDT)

> That's not opinion but simple, objective, agenda-free observation.

Not to imply that there's no demand for stateless NAT in v6, there
certainly is, but it is a small market niche compared to that of stateful
NAT.

IMO,
Roger Marquis

---

From: Gert Doering <[email-masked]>
Date: Wed, 27 Oct 2010 22:54:48 +0200

Hi,

> That's not opinion but simple, objective, agenda-free observation.

Hear, hear.  (IPv6 seems to go somewhere here, and it's unclear whether
"stateful NAT66" or "no demand" or "no vendor support" or "no time to
work on it" or "we have enough IPv4 addresses" is the main driver, 
so I find it a bit hard to observe *why* things are happening).

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2010 10:11:56 +1300

Roland,

> are IMHO not the only problem.

Correct, although our architectural recommendation against carrying
IP addresses in upper layer protocols has existed for just about
as long as NATs have existed.

This is exactly why I'm working on draft-carpenter-referral-ps, which
is intended to include the two-party case as a subset.

    Brian

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 19:14:08 -0400

On Oct 27, 2010, at 4:48 PM, Roger Marquis wrote:

> evidence (user-base and rate of growth).  

garbage.  you can't expect to be taken seriously when you say things like that. 

> Statements that v4-style NATs

also garbage.  there is now 15 years of experience with ipv4 NAT among application developers and users that indicates otherwise.

> greatly exaggerated, at best.

there are many valid reasons for killing it, and few valid reasons for keeping it.    some of us doing our best to eliminate the few valid reasons that remain.

> nowhere until working NAT64 and NAT66 implementations are available.

people who cite the "real world" as a justification for anything are already on thin ice.  what this essentially means is "you should conform to my prejudices because I cannot defend them". 

> That's not opinion but simple, objective, agenda-free observation.

it's not even observation.  it's delusion.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 19:15:40 -0400

> certainly is, but it is a small market niche compared to that of stateful

which is precisely why 

a) every NAT proposal (even those that do less harm than others) has to be treated with extreme skepticism.
b) if we're going to endorse NATs at all, we need a common mechanism to allow apps to deal with them that applies across all NATs.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 19:16:43 -0400

> as long as NATs have existed.

that recommendation is, and always was, naive.

Keith

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Oct 2010 16:41:36 -0700

On Oct 27, 2010, at 10:45, Fred Baker wrote:
> I don't object to that either. I do question the requirement apart from Dynamic DNS. [...]

I can offer an answer to that question.

The DNS, assuming it's extended by <http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd>, is only one of many available service directory protocols, and it may not be the most appropriate for all applications.  Some applications may very well prefer to trade the federated administration for more responsive service availability signaling.

Applications that incorporate different or integrated service directories must themselves be allowed to perform self-address fixing by communicating directly with any translators in all the paths between any hosts.

On the other hand, there is another cross-cutting concern, i.e. applications that rely on their hosts using Dynamic DNS but need to be made transparent in the face of NAT66. The B2B usage scenario for NAT66 implies that exterior source addresses correspond to destinations in private enclaves.  Those source addresses may be unique-local [RFC 4193], and in any case not publicly reachable.  Therefore, they should not be published in the public DNS horizon.  This means we probably need something like DNS66 alongside NAT66, so that when a host advertises its interior address with Dynamic DNS, there is a DNS66 process that transfers that registration into any private DNS horizons as required.

---

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

> it's not even observation.  it's delusion.

I doubt any of my statistics professors (at UC Berkeley) would agree with
you and I guarantee none of my IT security colleagues would.  This is, of
course, my opinion.  But if you have data indicating otherwise we'd all
be glad to evaluate it.

Roger Marquis

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 20:21:27 -0400

On Oct 27, 2010, at 1:35 PM, Fred Baker wrote:

> Well, and it needs to supply both IPv4 and IPv6 addresses when appropriate, and there may be multiple of each that might be relevant. To me, that translates to "DNS Name".

The DNS name doesn't really solve the problem, at best it just moves it.  In one case, peer B gets a list of IPv4 and/or IPv6 addresses from peer A.  In another case, peer B gets one or more DNS names from peer A which can be used to obtain a list of IPv4 and/or IPv6 addresses.  Either way, peer B still has the problem of figuring out which of those addresses to use given that there might be NATs, firewalls, ALGs, interception proxies, traffic shapers, etc. in the way; and that some of the addresses which were useful in peer A's scope might not be useful in peer B's scope.

> If it really has to be a literal, which I already pointed out has some brain-deadness related to IPv4 and IPv6 routing (the fact that you and I both have an IPv[46] address doesn't mean that the network has a route that connects them, even if the addresses are global). But that is not is not its *own* address; it is the address of a neighbor.

The referral doesn't have to be a literal in all cases, but a DNS name is not a general solution that applications developers can use.   DNS wasn't designed for this, and in practice it's just too dysfunctional in too many ways for this.   (And it is an Extremely Bad Idea to try to make DNS smart enough to do address selection on behalf of hosts/apps.  That would be like trying to live on the fourth story of a house of playing cards.)

> If you are adamant that the web/sip/whatever referral can't be a DNS name, will you allow the referring host to look it up in DNS? As noted, DNS will have the external addresses of any system it ha…

see above.  A DNS name is not a general solution.  It's certainly not suitable for widespread use in SIP.   If you try to insist that all apps use DNS for referrals you're basically requiring all apps that do referrals to maintain their own DNS space (probably with a separate zone for each instance of the app) and generate/distribute credentials for every instance of their app.  DNS doesn't even begin to have the kind of support that is needed for that - existing DNS servers, resolvers, and libraries aren't written to handle that, it would make the apps extremely fragile to various kinds of attack, DNS doesn't have suitable RR types, DNS's TTL-based caching mechanism isn't well suited for this, some ISPs block DNS updates from port 53, it wouldn't work on an isolated LAN or other ad-hoc network, etc., etc.  It's a complete non-starter.

> In several statements here you make the statement "you...impose NAT". Note that I am, and Margaret is, doing nothing of the kind. Network operators are trying to solve a very real problem, one that…

I certainly acknowledge that the problem NAT66 is trying to address really does need to be solved.  But in the process of trying to solve it what you're also trying to do is get IETF endorsement for a kind of NAT (think slippery slope), and you're also trying to do that without addressing many of the problems that NATs are well known to cause for applications (think bad precedent).

I also agree that we need NAT46 and NAT64 for transition purposes, and I acknowledge that (whether it makes good technical sense or not) there is market demand for other kinds of NAT.  So I accept that we're going to have some amount of NAT (and also multiple kinds of NAT) in the network for the forseeable future.  

What I think we probably need to do, then, are the following:

- Define a single, standard, mechanism that applies regardless of which kind of NATs are being used, that lets applications cope.  This includes things like finding an global transport address that's associated with an internal transport address, creating bindings (subject to policy) that allow incoming connections, maintaining bindings in stateful NATs, destroying bindings when they're no longer used, hooks to allow both application and host OS access to such functions, support for split NAT, etc.  (for there to be a single standard mechanism it has to be more versatile than NAT66 needs)
- Standardize such NATs as are found to be strictly necessary, but do so in such a way that minimizes the harm done by NATs (e.g. by requiring support for hairpinning or something similar) and by requiring support for the above mechanism.
- Continue to work to provide better solutions to the problems that NATs purport to solve, so as to encourage adoption of better alternatives.

> I agree that host upgrades should not be required. That is the reason that Margaret and I are proposing a solution that doesn't require host upgrades that we know of.

But it does require host upgrades.  Not to the host OS, perhaps, but the apps on the hosts still have to be changed.  You can't expect apps to work without change in a world where some of their peers need one kind of address and other of their peers need an address from a different realm, and the apps have no good way of finding out which addresses work where.  I mean, ideally, in a NAT66 world apps that do referrals could always use their external addresses, and the NATs would be required to do hairpinning.  But even that is suboptimal for both the router and the LAN.  You also want the apps to be able to find their peers even if they find themselves disconnected from their external network access - so long as those peers are reachable of course.  The NAT shouldn't have to be reachable for that to work.

> "Happy Eyeballs". http://tools.ietf.org/html/draft-wing-v6ops-happy-eyeballs-ipv6. If the socket API were rationally designed, what it is saying would be buried in a connect_to_name() call that was…

I appreciate the intent, but the approach is very naive.  Often it's not a question of whether IPv4 or IPv6 is broken.  They're both broken in different ways, the kind of breakage depends on the source-destination address pair, and the optimal choice depends both on the specific kind of application and kind of breakage.  You'll get vastly different results using native ipv4 with a local destination address, linklocal ipv4 address, native ipv4 with a global destination address, native ipv4 with one of the addresses behind a NAT, native ipv4 with both addresses behind different NATs, 6to4 addresses, teredo, ipv6 using tunnel broker, linklocal ipv6, global ipv6. ULIAs, host VPNs, mobile IP, all throw other wrenches into the works.

There is no way to "rationally design" this into the socket layer because the host/socket library simply doesn't have the kind of information required to make these decisions at the granularity that is needed.   (generally, neither does the app, but at least the app knows what kind of service it needs, which is more than the socket API knows.)   And the reason the socket API doesn't have that kind of information is because the network wasn't designed to provide that kind of information to hosts.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 20:25:43 -0400

On Oct 27, 2010, at 1:40 PM, Fred Baker wrote:

> I presume, in that, that you are talking about me.

I wasn't talking about you at all, and didn't intend for it to be taken that way.    Sorry if that wasn't clear.

I don't recall an occasion where you personally tried to suppress information about NATs.  I do recall such efforts from others in IESG and IAB who happened to work for major equipment vendors.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 20:31:33 -0400

On Oct 27, 2010, at 1:45 PM, Fred Baker wrote:

> I don't object to that either. I do question the requirement apart from Dynamic DNS. Keith's comment earlier today indicated that he didn't like the mechanisms that exist for doing so, and specifically didn't want to have to send a datagram to another system.

I'm not sure where the latter bit came from.  I don't object to having the apps or hosts send a datagram (or open up a tcp connection) to an address in order to obtain a global transport address associated with a connection.    (there are cases where a datagram request is better and cases where it makes more sense to have a tcp or similar connection - but I'm also envisioning a more general mechanism that also deals with additional problems caused by stateful NATs.)

What I object to is requiring apps that do referrals to have "prime real estate" (in the form of servers that reside in global address space) that exist to allow those apps to do referrals between address realms.  That's essentially what ICE requires, and it's an unreasonable burden to impose on all apps that need to do referrals.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 20:39:09 -0400

> course, my opinion.  But if you have data indicating otherwise we'd all

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 you can't represent wisdom required from firsthand experience as mere data.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Oct 2010 21:20:43 -0400

> On the other hand, there is another cross-cutting concern, i.e. applications that rely on their hosts using Dynamic DNS but need to be made transparent in the face of NAT66. The B2B usage scenario…

Trying to make DNS smart enough to only expose addresses that are usable for a given peer strikes me as another slippery slope toward disaster.

Just to take one small example, it's simply not the case that a DNS resolver and the hosts that talk to it can be expected to be in the same realm(s).  Especially not in a world where it's increasingly common for hosts to have multiple active network interfaces (real or pseudo).

(I don't even agree that ULIAs shouldn't be published in DNS, though I'll certainly agree that current address selection heuristics aren't sufficient to inform a choice between use of ULIAs vs. other kinds of addresses.)

Some useful principles:

- The network's job is to route packets transparently, not to second-guess the apps.  Network components that try to second-guess apps will inevitably create tussles.  This includes stateful NATs, ALGs, firewalls, traffic shapers, interception proxies, etc.
- Whenever the network can do a job well, generally the hosts and apps should let it do so.  That's just good separation of function.  The "best effort" routing in a traditional single-realm IP network with (in the vast majority of cases) one interface per host was a good example of this - as long as the network honestly did best effort routing, the hosts and apps were extremely unlikely to do better.  
- If the network can't do parts of its job well, it should let the apps try to do a better job rather than trying to prevent them from doing a better job.  At least the apps know what kind of service they need.

Trying to have DNS hide "unreachable" addresses is an example of trying to keep apps from doing a better job.  The DNS resolver doesn't know what's accessible to a particular host or app.

Keith

---

From: Xiangsong Cui <[email-masked]>
Date: Thu, 28 Oct 2010 12:08:12 +0800

Hi Chris,

I don't understand your points.

In my mind, all IETF participants are individual, not delegate of
organization.
Regarding NAT66, I believe we (everyone) are FREE to express our opinions.
And regarding standard of NAT66, I believe we SHOULD carefully consider its
advantage, and disadvantage, or even danger, harm ...

> The point I'm trying to make is why should individuals feel compelled to
oppose
> the creation of a standard simply because that standard is only applicable
to a
> particular scope of usage cases. For example, my company doesn't utilize
> VoIP.... is it reasonable for us to oppose the existance of VoIP standards
or
> some-one elses choice to utilize VoIP as a technology simply because we
won't
> utilize it?

If you are not interested in VoIP, let me say, it's better to keep silent to
VoIP standards.
And again, we are speaking here not because our organizations manufacture or
sell NAT66 boxes, or competitive organizations manufacture/sell NAT66 box,
it is just because we individuals are interested in this topic.

> 
> The same should hold true for NAT. Those of us on the Enterprise side who
> CHOOSE to deploy NAT know full well that it will break certain types of
apps. In
> general we DON'T want those type of apps crossing our network boundaries
in
> the first place.....and take steps to try to block them even without NAT.
We
> further recognize that IF we do want to utilize one of those apps through
NAT
> WE bear the burden/cost for establishing a work around. Why is it not
> acceptable for us to ask for a standard for NAT in IPv6 that would cover
our
> usage case?

Everyone are free to ask for any standard of anything here, imho, that (the
behavior of asking, but not the content) is of course acceptable. But,
before the acceptance and standardization, it is also acceptable that the
items are deeply discussed. Maybe you don't care the end customers and
internet users behind you (or maybe you intend to control something, e.g.
filtering something), but you can not oppose others to consider these
issues. I also believe, for any solution (the worst one included), there is
always someone can get benefit from it, but many solutions cannot become
standard solution, because their advantage are less than their disadvantage.
This means, standardization need to balance the advantage and disadvantage.

> 
> No one is arguing for a standard that NAT MUST be deployed across the
entire
> internet. People simply want a standard by which organizations which
CHOOSE
> to deploy it on their OWN network boundaries can expect it to behave
> consistently.

I believe, if there was NO NAT66 standard, in technology, everyone is FREE
to invent/manufacture/sell/develop/etc. their OWN NAT66 box.

Regards,
Xiangsong

---

From: Fred Baker <[email-masked]>
Date: Wed, 27 Oct 2010 21:46:56 -0700

> The DNS name doesn't really solve the problem, at best it just moves it.  In one case, peer B gets a list of IPv4 and/or IPv6 addresses from peer A.  In another case, peer B gets one or more DNS na…

Or BCP 38.

> The referral doesn't have to be a literal in all cases, but a DNS name is not a general solution that applications developers can use.

Select an alternative. If a DNS name, which encompasses all reasonable IP[46] addresses, is unreasonable, and a single literal that may or may not have a functional route associated with it from its peer's perspective is unreasonable, what is reasonable? I haven't heard you suggest an alternative that predictably works. 

> see above.  A DNS name is not a general solution.

I repeat. You have given a lot of crap about how you don't like solutions that have been offered. I have offered solutions. Pick one or suggest one. 

You have 48 hours before your email address goes into my kill file as a waste of bandwidth. Describe something that in your opinion works and addresses the problem that even you agree has to be solved.

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 01:07:10 -0400

> Select an alternative. If a DNS name, which encompasses all reasonable IP[46] addresses, is unreasonable, and a single literal that may or may not have a functional route associated with it from it…

Given that DNS names don't even begin to solve the problem, and there's not currently support in the network for any identifier that will work, the most workable approach for now requires applications to pass IP addresses to peers in referrals (perhaps with some additional information) and for those peers to make heuristic guesses about which addresses to try first.  Granted that's not a very good solution, but it's way better than trying to prevent apps from making those decisions.

As for an eventual good solution: Building a fast, secure, reliable split ID/LOC system strikes me as approximately as difficult as building a routing system that scales to 10^7 prefixes - because the likely solution to both seems to involve a very highly replicated, reliable, fast, and secure distributed database that everyone is willing to trust.   It doesn't mean we shouldn't try to solve both problems but that the answers aren't likely to be simple enough to be communicated in an email for which you're only willing to wait 48 hours.

> I repeat. You have given a lot of crap about how you don't like solutions that have been offered. I have offered solutions.

I don't recall you offering any solutions.  You keep saying DNS but I've explained why DNS doesn't even begin to work.   Do you need more detail?  I thought we'd been over this many times before...

> Pick one or suggest one. 

seems like you're insisting on simple answers to things that inherently aren't simple.

Keith

---

From: Christian Huitema <[email-masked]>
Date: Thu, 28 Oct 2010 07:02:06 +0000

> ...  the most workable approach for now requires applications to pass IP addresses to peers 
> in referrals (perhaps with some additional information) and for those peers to make heuristic 
> guesses about which addresses to try first.  Granted that's not a very good solution, but it's 
> way better than trying to prevent apps from making those decisions.

Keith, it seems that you are describing ICE. Of course, ICE only really works for UDP based applications. So we may need to run TCP or a new equivalent protocol on top of UDP. Of course, if we do that, we can also get a solution that works through not only NAT, but also basic stateful firewalls. 

ICE, STUN, TURN forever. Not exactly what we were shooting for in 1992. Oh well.

-- Christian Huitema

---

From: Rémi Després <[email-masked]>
Date: Thu, 28 Oct 2010 11:06:56 +0200

> greatly exaggerated, at best.

I agree that, if a NAT66 is combined with a FW, stateful NAT66 seems more logical than stateless.

> nowhere until working NAT64 and NAT66 implementations are available.

As is, this statement is much too general to be defendable:
IPv6 has already gone somewhere, and will continue, at least for many residential customers (Free in France, SoftBank in japan, Comcast trials in the US...)

> That's not opinion but simple, objective, agenda-free observation.

Apparently, you know customers that want NAT66 (in addition to their stateful FWs) because they want IPv6 asap, and find they need IPv6 address translation for this.
Then, describing in detail at least one of their configurations, and for which use they need IPv6 asap, would be a very useful contribution.
(So far, we have statements that such customers exist, but technical descriptions of what they want to do are IMHO badly missing.)

Regards,
RD

---

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

On Oct 28, 2010, at 3:02 AM, Christian Huitema wrote:

> Keith, it seems that you are describing ICE.

not specifically, no.  I'm speaking in general terms here.   given the considerable constraints associated with the current operating environment, different applications will make different tradeoffs.

> Of course, ICE only really works for UDP based applications. So we may need to run TCP or a new equivalent protocol on top of UDP. Of course, if we do that, we can also get a solution that works through not only NAT, but also basic stateful firewalls. 
> 

not what I'm shooting for now either.  but neither do I want to prevent such things from working (for those apps that can use them) in the interim.

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 07:42:33 -0400

On Oct 28, 2010, at 5:06 AM, Rémi Després wrote:

>> As long as consumers and security experts continue demanding v4-style (stateful) NAT in IPv6 efforts to kill it and/or proclaim it dead are greatly exaggerated, at best.
> 

The (relatively) "nice" feature about NAT66 (from the point of view of applications) is that the mapping between internal-external addresses is stateless.  It means that apps dealing with such a beast would not have to worry about having to recover from the NAT killing their associations, and having to refind and resync with their peers.   That doesn't mean that a combined NAT/FW would have to be stateless.

(Though in practice I have to wonder how many apps would find it useful to special-case NAT66 handling.  Probably most would not do so unless the vast majority of NATs found within v6 were NAT66.  But apps built to tolerate NAT in general would likely perform better in the presence of only NAT66 than with arbitrary NAT.)

Keith

---

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

Keith,

A complete comparison would include that, if you have a NAT66, having it stateful provides *more* privacy to users, and provides topology hiding.

Besides, until a convincing scenario showing that, where IPv6 FWs are available, the pros of any NAT66 outweighs the cons, I keep doubts that deploying NAT66 is a good choice. 

Yet, if some *users* have firm plans to deploy NAT66 anyway, some with stateful NATs, some with stateless NATs, that's up to them.
Under this assumption, their wish to standardize theses NATs is obviously legitimate.

Regards,
RD

---

From: Keith Moore <[email-masked]>
Date: Thu, 28 Oct 2010 08:50:33 -0400

> A complete comparison would include that, if you have a NAT66, having it stateful provides *more* privacy to users, and provides topology hiding.

true, but there are better ways than NAT of discouraging address tracking.

a stateless NAT can still hide topology.  nothing says that a stateless mapping has to be one where the prefix bits in the internal address have to be a fixed offset from those in the external address.  you could generate an invertable/stateless mapping by encrypting/decrypting those bits with a constant key and symmetric cipher.  the mapping would still be stateless, but the externally visible addresses would have an apparently random relationship with the internal addresses.  

> Besides, until a convincing scenario showing that, where IPv6 FWs are available, the pros of any NAT66 outweighs the cons, I keep doubts that deploying NAT66 is a good choice. 

I share those doubts.  But it's hard for every email message about the topic to encompass the entire range of concerns that necessarily weigh into this discussion.

> Under this assumption, their wish to standardize theses NATs is obviously legitimate.

strongly disagree.  the desire to standardize mechanisms that are known to do harm to applications is not legitimate.  nor is this consistent with long-established IETF standardization criteria.

Keith

---

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

> true, but there are better ways than NAT of discouraging address tracking.

Maybe so, but this is not the subject here.
(The only stateless NAT66 I consider is that proposed in draft-mrw-nat66-00.) 

> I share those doubts.

Good to hear.

>  But it's hard for every email message about the topic to encompass the entire range of concerns that necessarily weigh into this discussion.

Sure, no problem.

> strongly disagree.  the desire to standardize mechanisms that are known to do harm to applications is not legitimate.  nor is this consistent with long-established IETF standardization criteria.

I was implicitly assuming that their proposed design wouldn't break anything for any user of their very specific sites (no incoming connections foreseen...), and wouldn't break anything for users of other sites.

Note that, if I detect that a proposed specification breaks something that works today, like the NAT66-6to4 combination does break current uses of 6to4, I do argue against it (see the "Reasons not to endorse NAT66/6to4" discussion in v6ops.)

In summary we seem to agree more than we disagree, right?

Regards,
RD

---

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

> IPv6 has already gone somewhere, and will continue, at least
> for many residential customers (Free in France, SoftBank in
> japan, Comcast trials in the US...)
>
>
> Apparently, you know customers that want NAT66 (in addition
> to their stateful FWs) because they want IPv6 asap, and find
> they need IPv6 address translation for this. Then, describing
> in detail at least one of their configurations, and for which
> use they need IPv6 asap, would be a very useful contribution.
> (So far, we have statements that such customers exist, but
> technical descriptions of what they want to do are IMHO badly
> missing.)
>
>
> Regards,
> RD
>
>

Remi,

I wont pretend to answer for Roger, but I'll answer for myself. Perhaps it will give you an idea of exactly what we are using NAT for today, and what we want it (or an appropriate substitute) to accomplish for us in future.

Firstly, we are an Enterprise ourselves and a SaaS provider. Therefore we maintain or own corporate Enterprise Network as well as an environment for hosting our SaaS applications.

We don't anticipate any immediate need for IPv6 and indeed adoption of it will entail some significant costs for us. Regardless, we recognize the importance of IPv6 in terms of growth of the internet (from our perspective the SOLE advantage it providers over IPv4 is allowing more people to connect to the internet) and it make sense to us to start establishing plans to support connectivity with IPv6 only addresses in future. Ideally in the very long term, I'd prefer to run IPv6 natively as well...not because I see any inherent advantage in IPv6 over IPv4 for us...but because it makes sense to deal with as few protocols as you can get away with.

However, we have some functions that NAT44 currently provides us that we will still need to have met in future.....

1) Simple Security: We have a variety of devices on our networks, including servers, workstations, printers, scanners, etc. The vast majority of these devices will never and should never expect INBOUND connections, though a fair number of them may need some OUTBOUND connectivity. We have all the standard security devices/controls one would normal expect from an Enterprise of our nature, including Statefull Inspection Firewalls on all of our network boundaries. Yet we understand full well that reliance on single points of failure for security is foolhardy and that robust security entails multiple layers of compensating controls. Simply put, without NAT, if my SI Firewall filters fail (say due to misconfiguration) then I have hundreds of devices of all types potentially exposed to INBOUND attacks from beyond the network perimeter. With MANY:1 NAT, all those devices avoid exposure since an external attacker has no way to address INBOUND connections to them.  THAT has value to us.

2) Infrastructure Abstraction: Since we also provide various services that expect external connections INBOUND (appropriately hardened, filtered, and placed in DMZ's). We have a need to maintain consistent unchanging external advertisements of those services. Furthermore those advertisements need to be the IP addresses since...a) We cannot predict that all applications connecting to said services are capable of supporting higher level referrals, b) Even with those that support DNS, there are many issues involved with caching, propagation and the simple fact that the host (or some intermediary) controls DNS resolution that make reliance on DNS undesirable, c) In many cases, our clients or business partners make explicit holes in their own firewalls for connectivity to such services, changing the IP address assigned to said advertisement would necessitate a process of contacting each of these and arranging to have them MANUALLY adjust their FW filters accordingly. Using static NAT mappings of internal IP:Port to external IP:Port for these services on our network boundaries allows us to change around the internal architecture in whatever manner we wish, use whatever internal addressing scheme makes sense to us and maintain consistent external advertisement of services. It also allows us to accomplish this by generally making changes on a very few number of (NAT) devices, which obviously has simplified management benefits.

3) Centralized Control: Like many Enterprise organizations. We desire to maintain some control, management and monitoring over the various tools our employees utilize to perform their work when representing us. There are many different mechanisms which aid in said task, including things like local and group policy enforcements, etc. NAT actually has some role here as well, due to the vary fact that it does certain classes of applications (P2P) more difficult to function without some intervention on IT's part. Essentially from a filtering perspective it's not practical to block OUTBOUND connectivity from a workstation to any arbitrary address out on the internet (DENY OUT ALL). Now if my filters can recognize the specific application generating such traffic they can seek to block it. However this is very often not practical due to the frequency with which new applications are released and the increasingly common practice of application developers to hide their applications traffic by encapsulating it in well known "allowed" protocols and ports (i.e. HTTP on Port 80) in an effort to thwart filters. NAT does tend to break the end-user to end-user connectivity of such apps...or at the very least forces them to use well known, statically addressed intermediaries which I CAN black-hole/filter against.  Though not a perfect solution, it does provide value to us.

4) Privacy: At the network level, NAT helps shield end user/end device addresses from one another and makes it more difficult (not impossible, just more difficult) to track their activity and profile them and the infrastructure they come from. This has some value to us.

I hope this provides you with at least some insight of some of the goals which we need to support, both now and in the future. Note I'm not at all opposed to IPv6... I'm just opposed to forcing everyone into a One Size Fits ALL deployment scenario for IPv6.

I'm sure that organizations like mine WILL EVENTUALLY find vendors willing to provide us with statefull NAT66 devices that meet our needs regardless of RFC's or the IETF. Simply due to the fact that those needs/desires are not going to go away...and too many companies like mine are going to be throwing too much money on the table for such solutions for vendors to ignore it. I'd just prefer that some standards exist for how those solutions might work. In my view, that would make it easier for everyone involved, including guys like Keith... to understand and predict how they might behave.

Christopher Engel

---

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

> not what I'm shooting for now either.  but neither do I want to prevent such things from working (for those apps that can use them) in the interim.

I'd invite people who think this topic is of general importance to
read draft-carpenter-referral-ps and send comments to its authors
(or to the [email-masked] list). It's proving quite hard to make headway
in getting the IETF to recognise referrals as a problem area in its
own right, but I really think we need to do that, instead of bickering
about the side-effects of various individual mechanisms that break
up the address space or the name space.

     Brian

---

From: "S.P.Zeidler" <[email-masked]>
Date: Fri, 29 Oct 2010 10:18:25 +0200

[...]
> - Define a single, standard, mechanism that applies regardless of which kind of NATs are being used, that lets applications cope.  This includes things like finding an global transport address that…

You seem to fail to grasp that in a network where NAT is not forced on the
local network admin for lack of address space, but chosen as a vote
of no confidence regarding the hosts that are being NATted and because of
scaling problems, applications that need what you propose will go splat on
the firewall anyway. It's not for installations with a small enough number
of hosts that you'd renumber the lot with a bit of grousing on a Saturday
afternoon, it's for large and/or complex networks, and there will be
stateful firewalls as a matter of course long before there will be a need
for NAT.

In a world where even subnets are plenty, if I have a few hosts that I want
to run an app like that I can assign them their very own public /64 in their
own DMZlet. A /56 has as many subnets as a v4 /24 has addresses. A /48 has
as many subnets as a v4 /16 has addresses. Stateless prefix translation
as suggested here only uses up one /64 per inside /64, there'll still be
enough to go round. Uses will be found once one can wallow in address space :>

regards,
	spz

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 08:24:30 -0400

On Oct 29, 2010, at 4:18 AM, S.P.Zeidler wrote:

> the firewall anyway.

You seem to fail to grasp that there is a far wider variety of things that people and enterprises legitimately want to do with their networks, and a far wider variety of legitimate patters for application traffic, than you can imagine.   In other words, you're simply incorrect.  

And the effect of what you're trying to do is to cripple the Internet architecture so that nobody can run apps that don't conform to your narrow-minded ideas of how apps should work.  

> own DMZlet. 

As long as you're trying to make a destination IP address be an authentication token for your hosts, your security is always going to be very weak and fragile.

Keith

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 00:31:02 +0200

> And the effect of what you're trying to do is to cripple the Internet architecture so that nobody can run apps that don't conform to your narrow-minded ideas of how apps should work.  

Because cascaded IPv4 NATs would be so much better ...

> As long as you're trying to make a destination IP address be an authentication token for your hosts, your security is always going to be very weak and fragile.

I'm not sure where you get "authentication token" where I simply say
"I can afford to exempt a few hosts from NATting but not all of them".

I'm really curious what types of novel apps you envision that are so
compelling even enterprises that have to be paranoid by law will want
to have on each and every one of their devices, while being unable to run
across application proxies. You wrote I was too daft, well go ahead and
educate me then.

regards,
	spz

---

From: Keith Moore <[email-masked]>
Date: Fri, 29 Oct 2010 23:45:18 -0400

On Oct 29, 2010, at 6:31 PM, S.P.Zeidler wrote:

> I'm not sure where you get "authentication token" where I simply say "I can afford to exempt a few hosts from NATting but not all of them".

it's the idea that you need to NAT all or most of your hosts for security reasons that is fatally flawed.

> across application proxies. You wrote I was too daft, well go ahead and

being concerned about security (whether or not by law) and running NATs have nothing to do with each other.  at least not if you know what you're doing.

Keith

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 09:29:48 +0200

> it's the idea that you need to NAT all or most of your hosts for security reasons that is fatally flawed.

No, I don't need to NAT for security reasons, I need to restrict the
network exchanges that may happen with un-hardened hosts for security
reasons. The result is that NAT+firewall rules does not give any less
connectivity than the firewall rules alone. Adding NAT on top of the
security measures that need to be there anyway does not lessen the
amount of connectivity these squishy hosts get, but it -may- improve it.

regards,
	spz

---

From: Keith Moore <[email-masked]>
Date: Sat, 30 Oct 2010 07:18:36 -0400

On Oct 30, 2010, at 3:29 AM, S.P.Zeidler wrote:

> connectivity than the firewall rules alone.

For your firewall, and for your policies, today.  This falls apart as soon as you have a need to let any of your hosts inside the NAT run an application for which NAT interferes.   You might think it won't happen, but the usage of the Internet keeps changing, people keep finding new ways to use it.  It strikes me as shortsighted to design a network in such a way that it impairs (by design rather than policy) the use of potentially valuable applications.  

And you might say that if such an app appears, that you can set up a separate subnet for the hosts that need to run that app.  But you don't know where that app needs to live on your network, nor how many hosts it needs to run on.  Such a solution might suffice or it might not.

You can of course do as you think best with your own network.  But IETF needs to be more farsighted than that.

> Adding NAT on top of the security measures that need to be there anyway does not lessen the amount of connectivity these squishy hosts get, but it -may- improve it.

NAT -will- impair the flexibility of your network to support applications.  NAT -will- impair your ability to adapt your security policy enforcement to suit your future needs.  Usually, having a less flexible enforcement mechanism does not improve your security, but rather degrades it, as you're forced to relax your security enforcement more than you would otherwise like to do.

Keith

---

From: jefsey <[email-masked]>
Date: Sat, 30 Oct 2010 12:23:23 +0200

At 16:25 25/10/2010, Rémi Després wrote:
>Now, considering that working with hosts using global IPv6 addresses 
>"doesn't work well for customers", is contrary to my experience as a 
>user of Free.fr since 2008.

I certainly concur with this.

Local IDs with global scope (what we call IDv6 for clarity sake) is 
most probably the overlooked user need that explains the user 
disinterest (and lack of funding) in IPv6. Idealy IP universal 
addresses should have been initially built as IPv4+IDv6. Our current 
post IDNA2008 (*) considerations of the Internet Use Interface (IUI, 
i.e. the user side independent location of a better use of the 
Internet) lead us to consider such a user centric addressing support. 
Also to use it to support a cross technology/addressing plans unified 
addressing. In such an approach the translatted address is the 
network part of the address depending on the used (Internet or 
others) service provider, not the user part.

(*) IDNA2008 has introduced a possible new yet respectfull user 
reading of the same Internet architecture supporting what Fuller 
would call "multiplication by division", centering the network on its 
diversified use rather than on its operations. It did it, at the 
occasion of the needs resulting from linguistic diversity, in 
exemplifying how the Internet architecture copes with any diversity. 
This is something the IETF and IUsers communities must digest and 
experiment. There are several engaged possibly converging efforts to 
that end. At this stage, my own work is initially in the IDN+IDv6 area.

jfc

---

From: "S.P.Zeidler" <[email-masked]>
Date: Sat, 30 Oct 2010 22:03:57 +0200

Thus wrote Keith Moore ([email-masked]):

> For your firewall, and for your policies, today.

Change happens. With a bit of luck, when I get to the point where 
NAT goes from a crutch that doesn't get in the way much to a problem,
better alternatives to what I try to solve with the NAT will be available.

At present, better cost-effective alternatives are not available.
If my employer wants a new app enough, and there aren't better cheap
solutions yet, we can deploy the available solution, namely running
our own AS.

I'm looking at the current situation being the case for the next 4-5 years
if the better solution is something hosts need to do, and falls off the sky
tomorrow. Getting solutions that only need firewalls and routers to
change can happen much faster, once they become available, especially if
they only need a software upgrade.

regards,
	spz