Subject: [nat66] New NAT66 Draft

From: Margaret Wasserman <[email-masked]>
Date: Mon, 9 Mar 2009 18:08:25 -0400

Hi All,

I just submitted a new NAT66 draft.  I had to submit it for manual  
posting, because of an internal meta-data error that I don't  
understand.  Anyway, it may take a couple of days to post, so here it  
is for your review and comments.

It still has the behave name, because I forgot about the name change  
until after the -00 submission deadline.  If we continue this work  
after SF, I will change the name.

Thanks,
Margaret

---

From: Fred Baker <[email-masked]>
Date: Mon, 9 Mar 2009 15:28:57 -0700

One suggestion I would make came out of a private discussion on the  
politics of the discussion. "Network Address Translation" is a pretty  
good description of the behavior of IPv4 NATs and their attendant  
issues detailed in RFC 4864. This is in fact a "Network Prefix  
Translation" draft; changing the name of the functionality might help  
have a more illuminating and less heated discussion.

On Mar 9, 2009, at 3:08 PM, Margaret Wasserman wrote:

> understand.  Anyway, it may take a couple of days to post, so here  
> it is for your review and comments.
>
> <draft-mrw-behave-nat66-02.txt>
> _______________________________________________
> nat66 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nat66

---

From: Rémi Després <[email-masked]>
Date: Tue, 10 Mar 2009 09:06:40 +0100

Hi Fred,

Comment and support below.

> have a more illuminating and less heated discussion.
I like this proposal.
With it, a NAT which is not a NAPT has finally got a name: it is a NPT.
IMHO, this should help clarify the discussion.

NPT66 is a useful concept.

Regards,

RD

---

From: Mark Townsley <[email-masked]>
Date: Tue, 10 Mar 2009 11:13:07 +0100

> With it, a NAT which is not a NAPT has finally got a name: it is a NPT.
Except that now we have to fight with NAPT, NPT, and NAT-PT in the 
industry - which are all very different things, with very similar names.

- Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 11 Mar 2009 11:13:22 +1300

> industry - which are all very different things, with very similar names.

Yes. I remind people that we wanted to title RFC4864 "NAP" (network
architecture protection) and were persuaded to drop that due to the
confusion effect. Also, I think calling it NAT66 is a preemptive strike
against anyone trying to sell a NAPT for IPv6. We can certainly make it
clear in the text that it's prefix translation.

But of course prefix translation doesn't provide the "benefit"
described in RFC4864 section 2.4.

    Brian

---

From: Fred Baker <[email-masked]>
Date: Tue, 10 Mar 2009 15:20:24 -0700

> described in RFC4864 section 2.4.

Very explicitly, which in my opinion is quite important. Specifically,  
under Margaret's model, an end host behind a N**66 can directly and  
predictably address another host behind a different N**66 and exchange  
any application's data flows with it. That's not true of the other N  
words...

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 10 Mar 2009 18:21:42 -0400

Hi Brian,

> described in RFC4864 section 2.4.

(For those without a handy copy of RFC 4864, section 2.4 = Topology  
Hiding).

That is absolutely correct.  A prefix translation mechanism, such as  
NAT66, _does_ provide the benefit of "Address Autonomy" (or what I  
call "Address Independence"), but it _does not_ provide any sort of  
topology hiding, security or privacy "benefits".  This can be a good  
thing or a bad thing, depending on how you look at it.

IMO, security benefits are better provided by an actual network  
security device, such as a firewall, that can be more flexibly  
configured to block or allow desired levels/types of access on a per- 
host or per-application basis.   Others' mileage may vary.

Margaret

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Mar 2009 15:52:19 -0700

On Mar 10, 2009, at 15:20, Fred Baker wrote:
> Very explicitly, which in my opinion is quite important.  
> Specifically, under Margaret's model, an end host behind a N**66 can  
> directly and predictably address another host behind a different  
> N**66 and exchange any application's data flows with it. That's not  
> true of the other N words...

They cannot exchange *ALL* application data flows.  Only *SOME*.

More specifically, only those application data flows in which nodes  
either A) do not exchange global scope IPv6 interface addresses with  
one another for callbacks, or B) coordinate by some as-yet-unimagined  
protocol with all the prefix-translating middleboxes in any given path  
between peers to make sure that each remote node uses the appropriate  
callback address to the local node for its routing realm.

That we keep forgetting this is a dismaying forewarning of the future  
architectural problems we will bring upon the Internet by advancing  
this proposal in the standards track.

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

---

From: Fred Baker <[email-masked]>
Date: Tue, 10 Mar 2009 15:54:25 -0700

> host or per-application basis.   Others' mileage may vary.

Very much agree. To give but one example of ways NAT-style topology  
hiding doesn't, here are the "Received" headers from your recent email  
as seen at my system. I'll leave it to you to decide what can be  
learned about networks and network topology if one reads one's email  
envelopes.

Received: from xbh-sjc-221.amer.cisco.com ([128.107.191.63]) by xmb- 
sjc-225.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 10 Mar 2009 15:22:07 -0700
Received: from sj-iport-3.cisco.com ([171.71.176.72]) by xbh- 
sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830);
	 Tue, 10 Mar 2009 15:22:07 -0700
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
  by sj-iport-3.cisco.com with ESMTP; 10 Mar 2009 22:22:07 +0000
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com  
[171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n2AMM54m017983;
	Tue, 10 Mar 2009 15:22:05 -0700
Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com  
[128.107.234.207])
	by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n2AMM5ZN006429;
	Tue, 10 Mar 2009 22:22:05 GMT

---

From: Fred Baker <[email-masked]>
Date: Tue, 10 Mar 2009 16:23:58 -0700

On Mar 10, 2009, at 3:52 PM, james woodyatt wrote:

>> Specifically, under Margaret's model, an end host behind a N**66  
>> can directly and predictably address another host behind a  
>> different N**66 and exchange any application's data flows with it.  
>> That's not true of the other N words...
>
> one another for callbacks, or B) coordinate by some as-yet- 
> unimagined protocol with all the prefix-translating middleboxes in  
> any given path between peers to make sure that each remote node uses  
> the appropriate callback address to the local node for its routing  
> realm.

OK, yes. You can't do routing exchanges across this if they assume a  
common address space.

> That we keep forgetting this is a dismaying forewarning of the  
> future architectural problems we will bring upon the Internet by  
> advancing this proposal in the standards track.

For the record, the issues with NAT came, and it was not on the  
standards track. It wasn't initially even documented in an RFC. Trying  
to kill the discussion isn't going to kill the concept.

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Mar 2009 18:03:40 -0700

On Mar 10, 2009, at 16:23, Fred Baker wrote:
> standards track. It wasn't initially even documented in an RFC.  
> Trying to kill the discussion isn't going to kill the concept.

===== <rant> =====

While I'm up on this soapbox now, let me just state for the record  
that I don't believe for a nanosecond that standards-track NAT66 will  
serve as anything but encouragement for people like my own engineering  
management to go "all the way" and implement NAPT66.

Please, I ask for forebearance to explain.

FWIW, I've been officially asked on more than one occasion about the  
viability of NAPT66 (not NAT66, about which nobody else at Apple seems  
to care), and the discussion on this BOF list has not made me feel  
safe resisting calls to implement it.

Has anyone else here read the Slashdot forums any time the subject of  
IPv6 comes up?  They're packed to the rafters with people who think  
the IETF is nuts for not making NAPT66 into a standard five years  
ago.  It's not much better on my employer's own discussion support  
forums.  Need I point out the *OG lists?  I have been arguing down  
enhancement requests for NAPT66 functions in our products for as long  
as they've had an IPv6 routing feature, and I don't know how much  
longer I can keep standing up in the wind.  And frankly, I don't plan  
to do so anymore.

NAPT66 would really only be a little bit worse than NAT66.  Just a  
tiny little bit.  Really.

And: people think they want it.  They might be willing to pay money  
for it at some point, if IPv6 becomes something people want to pay  
money for...  so, why shouldn't I just give up on DHCP6-PD altogether  
and learn to love the NAPT66?

Please, help me explain to my management, and by extension our  
customers, the teeming hordes on Slashdot and our discussion forums,  
why I shouldn't just turn on the NAPT66 code and give them what they  
really think they want.  Because I completely fail to see it at this  
point.  Yes, it breaks end-to-end reachability, but so does their  
stateful packet filter we turn on by default.  Yes, it breaks end-to- 
end addressability, but not really any worse than the NAT66 standard  
that everyone will soon be deploying everywhere at once, because  
honestly, who cares that NAT66 lets you manually provision the DNS  
with pre-translated AAAA records?

So, why should I continue resisting?  My managers don't think we need  
NAT66.  They think that if we're all going to be dealing with  
ubiquitous IPv6 address translation anyway, then *NAPT66* in our  
products will be easier to implement and involve less technical and UI  
risk for us.  And they're right.  How do I convince them that NAT66 is  
worth the extra energy?

===== </rant> ====

---

From: Fred Baker <[email-masked]>
Date: Tue, 10 Mar 2009 18:20:28 -0700

On Mar 10, 2009, at 6:03 PM, james woodyatt wrote:

> Yes, it breaks end-to-end addressability, but not really any worse  
> than the NAT66 standard that everyone will soon be deploying  
> everywhere at once, because honestly, who cares that NAT66 lets you  
> manually provision the DNS with pre-translated AAAA records?

Or use Stun and DDNS to do so dynamically?

how do we deploy DNS records in IPv4?

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Mar 2009 19:02:12 -0700

> how do we deploy DNS records in IPv4?

Yes, and with NAPT44, we use NAT-PMP or UPnP-IGD to find exterior port  
numbers and use those with DDNS to register SRV records for DNS-SD.   
It's a trivial extension to those existing protocols to make them  
support IPv6 for the same purpose with NAPT66.  This is what I predict  
we will end up doing in the long run.  In fact, I wouldn't be  
surprised to learn that somewhere in one of these buildings at Apple  
Campus, someone here has already done it.

NAT-PMP, one might be tempted to observe, has only one place in one of  
the packet formats where an IP address appears.  It's really not hard  
to make it carry an IPv6 address instead of an IPv4 one.

---

From: Rémi Després <[email-masked]>
Date: Sat, 14 Mar 2009 10:27:58 +0100

james woodyatt  -  le (m/j/a) 3/11/09 3:02 AM:
> we will end up doing in the long run. 

I share this prediction:
- With DNS SRV records, dynamically updated with with global addresses 
and locally available ports, many problems become simple.
- In particular, DNS proxies are no longer needed.
- It can also work with port-restricted IPv4 addresses if they are used 
as an alternative to NAT44 + UpnP-IGD/NAT-PMP.

regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Mar 2009 09:32:40 -0400

> as an alternative to NAT44 + UpnP-IGD/NAT-PMP.

most applications do not use SRV records.  if they did, they would be
less predictable and less reliable than they are now because DNS is so
often out of sync with reality.  it gets even worse because of
multi-faced DNS because the addressing domains and the visibility of
those DNS records do not match up, and DNS RRs leak outside of the
realms in which they're advertised.

advice to everyone working in the NAT space: stop trying to second guess
application behavior.

Keith

---

From: Keith Moore <[email-masked]>
Date: Sat, 14 Mar 2009 11:28:51 -0400

>> most applications do not use SRV records.
> Is it not true that those that use URLs and "connect by name" don't need
> to know whether a remote-endpoint address + port is obtained from an A,
> an AAAA, or an SRV record?

that's completely false.  each application is defined to work in a
certain way, and most are not defined to use SRV records.  furthermore
the SRV RFC explicitly forbids using SRV records for apps that aren't
defined to use them.  also, each implementation of an application is
different, so hacks that work with one implementation might not work
with another.

>>   if they did, they would be
>> often out of sync with reality.
> Well, there may be bugs to fix, but avoiding completely to depend on the
> DNS would seem strange to me.

adding useless complexity and making the behavior of both the network
and applications less predictable and less reliable seems strange to me.

>>   it gets even worse because of
> This is precisely why using only _global_ addresses simplifies a lot: no
> need to depend on double-faced DNSs, which tend indeed to create
> problems, but because of their double face.

that's right, using global IP addresses simplifies things a lot.

but trying to impose global DNS names on top of a space where each realm
has its own addressing does not simplify things - it makes them far, far
more complex.

>> application
> Note that this proposal is not really "in the NAT space".
> It is part of a model where e2e connections no longer need to be
> disturbed by NAT traversals.

but it doesn't actually solve that problem.

> Now, what is you opinion on "get host by name"?

I'll believe in applications using only host names when (a) there is a
global, secure, scalable, reliable, and fast name resolution system that
is everywhere tightly coupled with the underlying addressing and routing
system, and (b) when hosts' network stacks use host names rather than
addresses as connection/association endpoint identifiers.

Until then, host names are just for user convenience.

And note that in the present world, a host name means slightly different
things from one app to another.

---

From: Rémi Després <[email-masked]>
Date: Sun, 15 Mar 2009 08:39:17 +0100

Keith Moore  -  le (m/j/a) 3/14/09 4:28 PM:

each application is defined to work in a
certain way, and most are not defined to use SRV records.

My understanding so far is that if an application uses gethostbyname(),
and if its resolver, seeing that the URL is for a SRV RR (e.g.
_HTTP._TCP.MyWebServer/HomePage), asks for an SRV RR, then the
application, having submitted the URL transparently, doesn't know
whether the address and port it gets have been obtained directly in an
A or AAAAA, or after an intermediate SRV.

If this is wrong (it may be), can you please explain the reason?

furthermore
defined to use them.

I didn't see it in RFC 2052.

Could you indicate where in this RFC, or in which other RFC, this is?

Regards,

RD

---

From: Keith Moore <[email-masked]>
Date: Sun, 15 Mar 2009 06:49:38 -0400

Rémi Després wrote:
> whether the address and port it gets have been obtained directly in an A
> or AAAAA, or after an intermediate SRV.
> 

if an implementation of gethostbyname() works that way, it's broken, and
it's breaking its applications.  SRV is only for use by applications
that are defined to use it.

> Could you indicate where in this RFC, or in which other RFC, this is?

RFC 2782:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.

Keith

---

From: Rémi Després <[email-masked]>
Date: Sun, 15 Mar 2009 16:24:52 +0100

Keith Moore  -  le (m/j/a) 3/15/09 11:49 AM:

Rémi Després wrote:

if an implementation of gethostbyname() works that way, it's broken, and
it's breaking its applications.

Oops.

I wanted to say connect-by-name (as before) rather than gethostbyname.

(And I may have to learn more about socket APIs before pursuing the
subject.)

Apologies for this.

furthermore

RFC 2782:

Applicability Statement

I will think about reasons why this restriction is "expected".

Thanks for the reference.

RD

---

From: Keith Moore <[email-masked]>
Date: Sun, 15 Mar 2009 11:45:06 -0400

> (And I may have to learn more about socket APIs before pursuing the

Actually, I assumed you meant getaddrinfo() rather than gethostbyname(),
since getaddrinfo() actually has arguments to specify the transport
protocol and port which would allow a broken implementation of the API
to do a SRV lookup.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 16 Mar 2009 12:30:35 -0700

Forked from thread: "New NAT66 Draft".

On Mar 10, 2009, James Woodyatt wrote:

> My managers don't think we need NAT66.  They think that if we're all
> going to be dealing with ubiquitous IPv6 address translation anyway,
> then *NAPT66* in our products will be easier to implement and involve
> less technical and UI risk for us.  And they're right.  How do I
> convince them that NAT66 is worth the extra energy?

James and all -

I wrote an analysis that details why NAT is superior to NAPT.  It looks
at the potential problems that either technique can cause, and evaluates
the cost and completeness of solutions to those problems.

http://users.piuha.net/chvogt/pub/2009/draft-vogt-address-translation-
harmfulness-02.txt

Versions 00 and 01 are in the official IETF repositories, but revision
02 didn't make it before the deadline.  In the analysis, I use the term
"one-to-one address translation" to mean NAT, and the term "many-to-one
address translation" to mean NAPT.

Comments appreciated.

- Christian