Subject: Re: IPv6 networking: Bad news for small biz

From: [email-masked] (Noel Chiappa)
Date: Wed, 4 Apr 2012 17:21:35 -0400 (EDT)

> From: Doug Barton <[email-masked]>

    > My comments were directed towards those who still have the mindset,
    > "NAT is the enemy, and must be slain at all costs!"

In semi-defense of that attitude, NAT (architecturally) _is_ a crock - it puts
'brittle' (because it's hard to replicate, manage, etc) state in the middle of
the network. Having said that, I understand why people went down the NAT road
- when doing a real-world cost/benefit analysis, that path was, for all its
problems, the preferable one.

Part of the real problem has been that the IETF failed to carefully study, and
take to heart, the operational capabilities which NAT provided (such as
avoidance of renumbering, etc, etc), and then _failed to exert every possible
effort_ to provide those same capabilities in an equally 'easy to use' way.

	Noel

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Apr 2012 08:46:39 +1000

In message <[email-masked]>, Noel Chiappa write
> effort_ to provide those same capabilities in an equally 'easy to use' way.

Most of the renumbering issues that remain are outside of the perview
of the IETF.  Hosts have had the ability to securely register
themselves in the DNS for a decade now.  Microsoft AD has hosts
register themselves using these mechanisms.  DHCP handles both
static and dynamic addresses.  Now we may want a way for a host to
register itself securely with the firewall.  That way when a host's
IP address changes the firewall gets updated.

Most of the renumber problem in people refusing to get out of the
way of automation.

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

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 4 Apr 2012 21:31:46 -0400

> problems, the preferable one.

NAT didn't really exist when the basic shape of v6 was selected.
> effort_ to provide those same capabilities in an equally 'easy to use' way.

They thought -- or claimed -- that they had renumbering...

v6 is not the protocol I would have chosen.  For that matter, it's not the
protocol I pushed for, as hard as I could, in the IPng directorate.  At this
point -- with all of its technical mistakes, IETF omissions, and difficulty
of converting, we're stuck with it; we simply do not have time -- even if
we agreed now on what we should have done, way back when -- to start over.
Do the arithmetic...  Assume we know, today, the basic structure of a
perfect replacement for v4.  It would take a minimum of 3 years to get
through the IETF, not because of process but because there are so many
things that it touches, like the DNS, BGP, OSPF, and more.  There are
also all of the little side-pieces, like the ARP/ND replacement, the PPP
goo, etc.  After that, it's 3 years of design/code/test by Microsoft,
Apple, Cisco, Juniper, et al., following which we have the whole education
cycle, the replacement cycle while old boxes die off and are replaced, and
more.  (Look at how many Windows XP boxes still exist -- and we're well
into the second major release of Windows since then, and Windows 8 might
be out before the end of the year.)  By my arithmetic, it's a dozen years
minimum, *after* we've agreed on the basic design.  

		--Steve Bellovin, https://www.cs.columbia.edu/~smb

---

From: David Meyer <[email-masked]>
Date: Wed, 4 Apr 2012 18:39:23 -0700

> NAT didn't really exist when the basic shape of v6 was selected.

Perhaps, but that it would happen is obvious (even to the most causal observer).

Dave

---

From: Christian Huitema <[email-masked]>
Date: Thu, 5 Apr 2012 01:52:33 +0000

> Part of the real problem has been that the IETF failed to carefully 
> study, and take to heart, the operational capabilities which NAT 
> provided (such as avoidance of renumbering, etc, etc), and then 
> _failed to exert every possible effort_ to provide those same capabilities in an equally 'easy to use' way.

I agree with Noel on that one -- as surprising as it may sound. The IETF did recognize several problems, from privacy to renumbering to multi-homing, but the quality of the proposed solutions has been uneven. The IPV6 response to privacy protects the host with privacy addresses, but exposes internal network routes. Renumbering works fairly well in small networks, but does not provide a replacement for folks who insist in hardwiring IP addresses into filters. The response to multi-homing requires an additional layer of protocol in the hosts and is probably 15 years from being deployed.

Of course, NAT does not really solve multi-homing either -- it is one of the points where the brittleness is most apparent. But NAT's do hide the internals of a network, and do isolate networks from renumbering issues. NAT also break lots of applications, which is why so many of us hate them. But so do firewalls, and it seems that IPv6 firewalls are encouraged. Oh well.

-- Christian Huitema

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 12:01:32 +0900

> NAT didn't really exist when the basic shape of v6 was selected.

Yes, it did.

At 27th IETF in 1993, there was a NAT BOF:

	http://www.ietf.org/proceedings/27.pdf

	The following BOFs and working groups in the Internet
	Area met during the Amsterdam IETF:

	¯ Network Address Translators BOF (NAT)

If I remember correctly, there was an informal BoF at 26th.

RFC1631 was published in 1994.

Granted that there were not much operational experiences
on NAT accumulated, when RFC1883 was published in 1995.

However, it is not an excuse for IETF poorly designed
IPv6, because IPv6 must and could have designed to avoid
operational problems before operational experiences on
IPv6 was accumulated.

						Masataka Ohta

---

From: Steven Bellovin <[email-masked]>
Date: Wed, 4 Apr 2012 23:05:56 -0400

> Perhaps, but that it would happen is obvious (even to the most causal observer).

I do not agree.  I remember discussing the concept with folks, a couple
of years before that; we agreed that NATs would be very challenging
because of the need for protocol-dependent packet inspection and
modification.  Add to that an underestimate of how long it would take
before v6 was adopted, and a gross underestimate of how large the
Internet would be -- remember, IPng happened before the Web explosion --
and it was very easy to ignore the possibility of NAT, let alone the
renumbering and (questionable) firewall benefits of it.  In retrospect,
sure, but in 1993-1994?  It was not at all obvious.

---

From: Martin Rex <[email-masked]>
Date: Thu, 5 Apr 2012 06:57:27 +0200 (MEST)

Steven Bellovin wrote:
> David Meyer wrote:

While the features and aspects varied, the underlying concept was
pretty real in 1993.

I remember that in 1992/1993 I used a software called "term"
on my Linux box to forward multiple multiplexed TCP connections
through a regular modem dial-up.  Since it sliced the data down
into very tiny chunks, supported priorities and lacked the
entire IP overhead, it was significantly better than SLIP/PPP
and you could still use telnet with an acceptably low impact
on echo responses while doing downloads on a 9600 bps dialup.

The beauty was, that you could make it work with *EVERY*
unix login (even through telnet!) as a vaniall user, no
admin rights required, not IP address assignment & routing config
issues, you simply compiled and started the daemon counterpart
on the remote end after login (doing I/O though stdin/stdout)
and all your local software would be sharing the IP address
of the dial-in machine.   Somewhat similar to virtual
machines sharing their hosts network adapter through NAT these days.

-Martin

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 14:53:18 +0900

> sure, but in 1993-1994?  It was not at all obvious.

Underestimate?

One of a fatal problem of IPv6 that IPv6 address is 16B long
while 8B is a lot more than enough is a result of gross
overestimate of how large the Internet would be.

RFC1715 killed IPv6.

						Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 05 Apr 2012 07:56:40 +0200

Hi Steven,

While it is obvious that we have no time to redesign IPv6 for the set of 
valid reasons you mentioned one could observe that we do have time to 
deploy it wisely via ID/LOC split architecture model.

Dual stack networks and all networking gear stays intact and depending 
on the choice of ID/LOC split solution some hosts may require a patch.

I believe some/most of problems from the quoted article and repeated in 
this thread would get solved with such model.

Perhaps it's time to build LISP to ILNP inter-working and roll.

Regards,
R.

> minimum,*after*  we've agreed on the basic design.
>
>
> 		--Steve Bellovin,https://www.cs.columbia.edu/~smb

---

From: Hector <[email-masked]>
Date: Thu, 05 Apr 2012 02:57:03 -0400

> sure, but in 1993-1994?  It was not at all obvious.

No doubt.

Its easy to have 20/20 hindsight regarding "IPv6 failures" to become 
ideally acceptable across the board. While there were warnings of 
complexities, there were also clearly many market forces going on 
between 1992 and 1996 that perhaps didn't allow IPv6 to be taken 
seriously.

Speaking as one of the early vendors to offer fast entry ISP hosting 
commercial solutions,  I can  tell you for sure, IPv6 was not on my 
radar.  The main reality was that the internet was still coming out of 
the academia/federal contract only closet into the commercial arena.

Thanks to Gore's 1991 effort and eventual infamous "invention of the 
internet" with the then new 1992 administration first white house 
initiative to address the digital divide by bring the internet to the 
mass public. Many may recall the new presidency 1994 Superhighway Summit:

       http://en.wikipedia.org/wiki/The_Superhighway_Summit

Only then, did "things" begin to take off, at least when it came to 
pricing, affordability and 24x7 connectivity.

I personally feel the market failures of IPv6 is partially related to 
a terrible inconsistent technical "What is it, how do we migration" 
considerations, masked with conflicts with new business profit model, 
confusing with current IPv4 holders letting go their possession, 
marketing and policy problems and also unfortunate conflict of having 
to try to change direction to IPv6 when the market was not only still 
trying to catch up with IPv4 solutions but also trying to integrate it 
with the then current commercial solutions of the then blossoming 
telecommunications industry.

A key reality back then was that 24x7 connectivity was still limited 
to the BBS modem dialup hosting systems, early ISP and private 
corporate environments with leased line ISDN, T1 environments, 
including download only satellite feeds like Planet Connect.  The 
topology was still star oriented, i.e. organized with local, state, 
region country routing like with Fidonet and and less peer to peer.

24x7 connectivity at all levels only became pretty mush feasibly 
possible with the 1982 anti-trust breakup of Ma Bell (AT&T) and the 
slow emergence of new ISP competition with lower cost entry points and 
eventually new business models using fixed-fee toll charges.  The 
latter finally allowed the end-users, originally isolated to local 
hosting services, to begin roaming the new "Wild Wild West" of the 
global internet-connected world - it also wrote the writing on the 
wall and began kill our horizontal market position too. :)

--
Hector Santos, CTO
http://www.santronics.com
http://hector.wildcatblog.com

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 05 Apr 2012 09:48:28 +0100

On 05/04/2012 03:52, Christian Huitema wrote:
> Of course, NAT does not really solve multi-homing either

it doesn't solve provider multihoming, but it solves end-user multihoming.
 For better or worse, there are ~40k asns announced on the internet, so
that problem is reasonably well contained.  There are many more multihomed
end-users whose multihoming requirements are solved completely adequately
by nat, and for whom ipv6 w/o NAT is a pointless pain with relatively high
cost and no real business benefit.

Nick

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Apr 2012 06:35:41 -0400

Hi Robert,

Do you realize that NPTv6 _is_ an ID/LOC split solution?  The external addresses are locators, much like the outer header addresses in LISP, and the internal addresses are IDs, much like the inner header addresses in LISP.  The tunnel is compressed away through the use of algorithmic, 1:1 translation. NPTv6 has a great advantage over LISP and other tunnel-based ID/LOC solutions in that the packet format of NPTv6 packets remains fully backward compatible with IPv6, allowing for full incremental deployment (one site can deploy it, without losing connectivity to anyone) through seamless backward-compatibility with existing IPv6 implementations.  

An NPTv6-aware end-node within an NPTv6 site could "un-do" the translation of internal addresses within its own stack, so that applications on the end-node would actually be using their own external addresses, rather than their internal addresses.  If this were widely implemented, it could restore end-to-end transparency, eliminating the need for ALGs and restoring the ability to do third-party referrals by IP address, etc.  To enable this translation, the end node would need to be configured with its own external prefix(es), perhaps via DHCPv6 or IPv6 RAs.

Of course, IPv4 NAT can also be viewed as an ID/LOC split solution.  In fact, the advantages of an ID/LOC split solution (address independence, avoiding renumbering, internal topology hiding, etc.) are the main drivers for the wide-spread deployment of IPv6 NAT in enterprises.  In most casts, those enterprises already have sufficient IPv4 "swamp space" to number their internal networks, or would have no difficulty getting sufficient IPv4 addresses from their ISP, so their use of NAT is _not_ motivated by an IPv4 address shortage.  The major problems with IPv4 NA(P)T are caused by port mapping/address sharing and state-based (vs. algorithmic) translation, both of which were eliminated in NPTv6.  It is possible, though, that these issues could be (at least partially) addressed through the use of PCP (the Port Control Protocol) on an IPv4 NAT-aware end-node.

In fact, if we can briefly set aside our distaste for NAT-based solutions, I think we'll realize that NAT-based ID/LOC solutions (such as NPTv6) have several advantages over tunnel-based ID/LOC solutions (such as LISP), particularly in the areas of incremental deployment and backwards compatibility.

Unfortunately, it is not clear that the market cares enough about end-to-end transparency to fund the development of NPTv6 or IPv4 NAT-aware end-nodes, because while end-to-end transparency is something that we in the IETF hold dear, it does not have enough practical value for Internet-connected enterprises that they have been willing to incur any cost or inconvenience to maintain it.  In fact, in many cases, they prefer _not_ to have it.

Margaret

> Hi Steven,
> 
> While it is obvious that we have no time to redesign IPv6 for the set of valid reasons you mentioned one could observe that we do have time to deploy it wisely via ID/LOC split architecture model.
> 
> Dual stack networks and all networking gear stays intact and depending on the choice of ID/LOC split solution some hosts may require a patch.
> 
> I believe some/most of problems from the quoted article and repeated in this thread would get solved with such model.
>

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 05 Apr 2012 12:05:33 +0100

On 05/04/2012 11:35, Margaret Wasserman wrote:
> Unfortunately, it is not clear that the market cares enough about
> end-to-end transparency to fund the development of NPTv6 or IPv4
> NAT-aware end-nodes, because while end-to-end transparency is something
> that we in the IETF hold dear, it does not have enough practical value
> for Internet-connected enterprises that they have been willing to incur
> any cost or inconvenience to maintain it.  In fact, in many cases, they
> prefer _not_ to have it.

quite the opposite: they view it as an unnecessary liability, a cost
centre.  Why should their internal business continuity depend on a business
relationship with an upstream provider which is worth €50 / month, and
which they might decide to change with almost zero notice?

Renumbering is not a solution to this problem because it causes things to
break.  The CEO doesn't care about end-to-end transparency, but he does
care about the fact that he can't print his financials 10 minutes before a
tense board meeting because the printer was originally set up using a
hard-coded IP address, because the printer driver was coded to ignore the
DNS because the printer driver manufacturers realised that most SMEs don't
have enough clue to make internal DNS work on their tiny internal network
with 10 PCs, and that if they made their product default to using IP
addresses instead of DNS, their end-users have a generally more reliable
user experience and buy more of their printers in future.  And repeat for
basically all LAN services.

You may not like it, but this is the reality for the vast majority of SME,
SOHO and home users out there.  If ipv6 causes breakage, then ipv6 will not
happen.  End users don't care about the protocol.  They care whether their
printer works and whether they can check their email.  If the protocol gets
in the way of that, then the protocol is broken.

Speaking as someone who deals with SMEs on a regular basis, and leaving
aside the rhetoric, The Register article basically got it spot on.

Nick

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 20:20:59 +0900

> deploy it wisely via ID/LOC split architecture model.

Only architectural implication, if any, of ID/LOC separation
is that, with N addresses, plain 16B long addresses costs 16*N
bytes, while ID/LOC separated 16B long addresses costs 8*(N+1)
bytes.

However, as 8B long addresses cloud have cost 8*B bytes and
that 6B long addresses with 4B IPv4 addresses and 2B port
numbers, which is the address space provided by NAT, is more
than enough, there is no point to have IPv6 ID/LOC separation
nor IPv6, especially because NAT can be end to end transparent.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 20:33:04 +0900

Margaret Wasserman wrote:

> Unfortunately, it is not clear that the market cares enough
> about end-to-end transparency to fund the development of
> NPTv6 or IPv4 NAT-aware end-nodes, because while end-to-end
> transparency is something that we in the IETF hold dear, it
> does not have enough practical value for Internet-connected
> enterprises that they have been willing to incur any cost or
> inconvenience to maintain it.  In fact, in many cases, they
> prefer _not_ to have it.

Totally wrong.

Many internet-connected enterprises have been willing to pay
extra money to have fixed IP addresses, and, worse, independent
global routing table entries for multihoming, to reliably
maintain the end to end transparency to reach their servers.

They do have practical values.

That's why the global routing table have bloated so much.

						Masataka Ohta

---

From: Margaret Wasserman <[email-masked]>
Date: Thu, 5 Apr 2012 07:37:17 -0400

> maintain the end to end transparency to reach their servers.

Earlier comments on this list indicated that there are ~40K enterprises that have chosen to incur these costs.

How many enterprises have chosen to use IPv4 NAT instead?

Margaret

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 05 Apr 2012 20:55:44 +0900

Margaret Wasserman wrote:

> Earlier comments on this list indicated that there are ~40K
> enterprises that have chosen to incur these costs.

I'm afraid the number is too large, which will make the Internet,
regardless of whether it is IPv4 or IPv6 based, collapse.

> How many enterprises have chosen to use IPv4 NAT instead?

Most of them, if I don't underestimate how large the Internet is.

All of them should be happy with IPv4 NAT with the end to end
transparency.

					Masataka Ohta

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 05 Apr 2012 14:32:11 +0200

Hi Margaret,

Indeed by no means I meant to exclude NPTv6 from the ID/LOC split 
solutions. I have just mentioned ILNP and LISP as host and network based 
most recent examples.

/* In fact I do not recall any one proposing NPTv6 via all the RRG 
ID/LOC split debates, but maybe I have just missed it. */

 > NAT-aware end-nodes, because while end-to-end transparency is
 > something that we in the IETF hold dear, it does not have enough
 > practical value for Internet-connected enterprises that they have
 > been willing to incur any cost or inconvenience to maintain it.  In
 > fact, in many cases, they prefer _not_ to have it.

I think this little thread so far shows that they are interested.

However one can not claim we have solution till we start with creating 
registry which could allocate enterprises and end users permanent 
globally scoped Identifiers. And truly I don't think this is for the 
enterprise X or vendor Y to propose it. It should be driven by IETF and 
perhaps executed by local RIRs.

Till I can go to URL or better just login on my device which will 
automagically retrieve one of my IDs then seamlessly go via any 
translation points I happen to be closest to in order get to any point 
in the Internet we will still be very far from achieving any form of 
practical value for ID/LOC technology.

Regards,
R.

> Hi Robert,
>
> Do you realize that NPTv6 _is_ an ID/LOC split solution?  The
> external addresses are locators, much like the outer header addresses
> in LISP, and the internal addresses are IDs, much like the inner
> header addresses in LISP.  The tunnel is compressed away through the
> use of algorithmic, 1:1 translation. NPTv6 has a great advantage over
> LISP and other tunnel-based ID/LOC solutions in that the packet
> format of NPTv6 packets remains fully backward compatible with IPv6,
> allowing for full incremental deployment (one site can deploy it,
> without losing connectivity to anyone) through seamless
> backward-compatibility with existing IPv6 implementations.
>
> An NPTv6-aware end-node within an NPTv6 site could "un-do" the
> translation of internal addresses within its own stack, so that
> applications on the end-node would actually be using their own
> external addresses, rather than their internal addresses.  If this
> were widely implemented, it could restore end-to-end transparency,
> eliminating the need for ALGs and restoring the ability to do
> third-party referrals by IP address, etc.  To enable this
> translation, the end node would need to be configured with its own
> external prefix(es), perhaps via DHCPv6 or IPv6 RAs.
>
> Of course, IPv4 NAT can also be viewed as an ID/LOC split solution.
> In fact, the advantages of an ID/LOC split solution (address
> independence, avoiding renumbering, internal topology hiding, etc.)
> are the main drivers for the wide-spread deployment of IPv6 NAT in
> enterprises.  In most casts, those enterprises already have
> sufficient IPv4 "swamp space" to number their internal networks, or
> would have no difficulty getting sufficient IPv4 addresses from their
> ISP, so their use of NAT is _not_ motivated by an IPv4 address
> shortage.  The major problems with IPv4 NA(P)T are caused by port
> mapping/address sharing and state-based (vs. algorithmic)
> translation, both of which were eliminated in NPTv6.  It is possible,
> though, that these issues could be (at least partially) addressed
> through the use of PCP (the Port Control Protocol) on an IPv4
> NAT-aware end-node.
>
> In fact, if we can briefly set aside our distaste for NAT-based
> solutions, I think we'll realize that NAT-based ID/LOC solutions
> (such as NPTv6) have several advantages over tunnel-based ID/LOC
> solutions (such as LISP), particularly in the areas of incremental
> deployment and backwards compatibility.
>
> NAT-aware end-nodes, because while end-to-end transparency is
> something that we in the IETF hold dear, it does not have enough
> practical value for Internet-connected enterprises that they have
> been willing to incur any cost or inconvenience to maintain it.  In
> fact, in many cases, they prefer _not_ to have it.
>
> Margaret
>
>
>> Hi Steven,
>>
>> While it is obvious that we have no time to redesign IPv6 for the
>> set of valid reasons you mentioned one could observe that we do
>> have time to deploy it wisely via ID/LOC split architecture model.
>>
>> Dual stack networks and all networking gear stays intact and
>> depending on the choice of ID/LOC split solution some hosts may
>> require a patch.
>>
>> I believe some/most of problems from the quoted article and
>> repeated in this thread would get solved with such model.
>>
>> Regards, R.
>>> v6 is not the protocol I would have chosen.  For that matter,
>>> it's not the protocol I pushed for, as hard as I could, in the
>>> IPng directorate.  At this point -- with all of its technical
>>> mistakes, IETF omissions, and difficulty of converting, we're
>>> stuck with it; we simply do not have time -- even if we agreed
>>> now on what we should have done, way back when -- to start over.
>>> Do the arithmetic...  Assume we know, today, the basic structure
>>> of a perfect replacement for v4.  It would take a minimum of 3
>>> years to get through the IETF, not because of process but because
>>> there are so many things that it touches, like the DNS, BGP,
>>> OSPF, and more.  There are also all of the little side-pieces,
>>> like the ARP/ND replacement, the PPP goo, etc.  After that, it's
>>> 3 years of design/code/test by Microsoft, Apple, Cisco, Juniper,
>>> et al., following which we have the whole education cycle, the
>>> replacement cycle while old boxes die off and are replaced, and
>>> more.  (Look at how many Windows XP boxes still exist -- and
>>> we're well into the second major release of Windows since then,
>>> and Windows 8 might be out before the end of the year.)  By my
>>> arithmetic, it's a dozen years minimum,*after*  we've agreed on
>>> the basic design.
>>>
>>>

---

From: Sabahattin Gucukoglu <[email-masked]>
Date: Thu, 5 Apr 2012 13:52:07 +0100

> nor IPv6, especially because NAT can be end to end transparent.

How do you propose to make end-to-end crypto of packets possible where NATs are involved?  I'm assuming you think everything can be solved with signalling, yes?  I ask because NPT could be the end of it if we all agreed to use the right kind of signalling.

Cheers,
Sabahattin

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 05 Apr 2012 14:59:14 +0100

On 05/04/2012 13:52, Sabahattin Gucukoglu wrote:
> How do you propose to make end-to-end crypto of packets possible where
> NATs are involved?

same way as we've done for years: payload authentication/encryption only.
header authentication makes no sense.

Nick

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 5 Apr 2012 10:19:30 -0400

> From: Christian Huitema [[email-masked]]
> 
> Of course, NAT does not really solve multi-homing either -- it is one
> of the points where the brittleness is most apparent. But NAT's do
> hide the internals of a network, and do isolate networks from
> renumbering issues. NAT also break lots of applications, which is why
> so many of us hate them. But so do firewalls, and it seems that IPv6
> firewalls are encouraged. Oh well.

To a great extent, NATs allow the organization network to be managed
without great concern for anything which happens in the external
network.  And in any organization, what happens inside its network is
far more important on a day-to-day basis than its external
connectivity.  Part of the trouble is that in the IETF, we don't think
much about that, since our attention is on global connectivity.

Also, NAT provides the ability to connect a small network to a service
provider that only provides a single DHCP address, or wants to charge
extra for every device you attach to its network.  NAT is a
significant technical tool in the business conflict between user and
service provider.

Dale

---

From: Ofer Inbar <[email-masked]>
Date: Thu, 5 Apr 2012 11:00:55 -0400

> significant technical tool in the business conflict between user and

Having been the admin of some small offices that set up Internet
connections, from my perspective it worked like this:

In the mid-90s, we just got enough address space for our hosts.
Simplest thing to do.

Later on, that got too expensive.  Why?  IPv4 address exhaustion.
Addresses where nowhere near exhausted, but ARIN started putting
the brakes on and making ISPs justify their address use more, and
it was costing more, so "just get enough address space" started
getting significantly more expensive.  So we'd get some sort of
basic "business class" service with, say, 4 IPs, and NAT the office
behind a simple high-end consumer grade NAT router.

Did we ever do this because we *wanted* NAT?  Far from it.
A very small office doesn't care, in my experience, about any
of the things NAT provides.  Renumbering?  Chances are we'd
move to a new building across town long before that happened,
and get new Internet service.  We have too few hosts, and the
couple of in-house servers would not be any trouble.  Internal
network structure?  It's just a bunch of hosts on one switch.

It's not a conflict with the ISP.  If they could, they'd provide us
the IP address space we want at an incrementally higher price, and
we'd pay it.  They'd get more money that way.  But they can't afford
to, so they charge a price high enough to make us, the small office,
deal with the annoyance of setting up and administering NAT.  Because
it *is* an annoyance we'd rather do without.  If we could pay the ISP
a bit more for the simplicity of just having a /26 that our network
could comfortably fit in, we'd do it.

Once an office gets large enough, NAT starts to provide benefits.
But in my experience with very small offices (say, under 25 people),
NAT is an annoyance we'd rather do without if we could affordably
get the IP space we want.

In other words, it's just a natural consequence of there not being
enough IPv4 address space.  ISPs and small offices are reacting in
a reasonable way to that fact, and doing so cooperatively.  Both
of them could be a bit happier if there were enough address space
for everyone - ISPs would make a bit more money, small offices would
have a simpler Internet connection without NAT - but that's not an
option.

I haven't admin'ed a small office in enough years, that IPv6 was
not an option when I did, and I don't know what the practical
state of it is today.  If an ISP offered native IPv6 with their
regular business class service, and the host OSes on our network
just worked with it, that's what I'd have picked, so we could avoid
the choice between NAT and address scarcity.  All IPv6 would need
to offer would be the combination of enough address space to avoid
NAT, and a cost not significantly higher than the 4-address IPv4 service.

As a small office, we wouldn't worry about multihoming, renumbering,
or any of the other things that keep coming up on this thread.  We'd
just want to be connected as simply as possible.  NAT is complexity
we never wanted.
  -- Cos

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 06 Apr 2012 07:45:10 +0900

> How do you propose to make end-to-end crypto of packets possible
> where NATs are involved?

My proposal in draft-ohta-e2e-nat-00.txt is to use 32 bit SPI as
16 bit source and destination port numbers:

   The same location may be usable for some protocols. For example, ESP
   packets may be demultiplexed based on the lower 16 bit of SPI. To do
   so, a destination host must be able to control the lower 16 bit of
   SPI.

   Other protocols may use different location, for which E2ENAT may
   provide special care.  Considering that an ICMP packet generated
   against an IP packet contains only the first 64 bits of payload of
   the original packet, demultiplexing information for source transport
   is implicitly assumed to be located in the 64 bits. So, it is natural
   that demultiplexing information for destination transport is also
   located in the same field. If the information is 16 bit word and 16
   bit aligned, there are only four variations on the location. This
   memo assumes so.

   For example, AH packets may be demultiplexed as if the lower 16 bit
   of SPI, located at the seventh and eighth bytes of a payload, is a
   destination port number.

Though existing NAT boxes may not support such behavior, upgrading
is necessary only by those who want to use IPSEC behind NAT.

> I'm assuming you think everything can be solved with signalling,
> yes?  I ask because NPT could be the end of it if we all agreed
> to use the right kind of signalling.

Signaling between what?

SPI negotiation may be called signaling.

						Masataka Ohta

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 05 Apr 2012 16:09:27 +0200

> effort_ to provide those same capabilities in an equally 'easy to use' way.

The bottom end of of this space has little trouble renumbering. Laptops
renumber all the time, reboot your router, interfaces flap and the
devices that dhcped get addresses out of the pool in a different order.
lack of address stability across interface transitions is generally
assumed across dynamically configured devices.

---

From: Joel jaeggli <[email-masked]>
Date: Thu, 05 Apr 2012 15:59:04 +0200

> Perhaps, but that it would happen is obvious (even to the most causal observer).

Effective address expansion through port-overload is agnostic for the
most part (obvious exceptions abound) about the application layer...

The alternative then as now was up at the application layer and there
are good reasons why that was a more bad idea at the time. Today, foo
over http/https:// is a big chunk of the solution space for application
layer tunneling.