Subject: Re: draft-ietf-nat-protocol-complications-02.txt

From: "J. Noel Chiappa" <[email-masked]>
Date: Sat, 22 Apr 2000 13:25:12 -0400

> From: Keith Moore <[email-masked]>

    >> I'm not exactly a big fan of NAT boxes either. Disgusting kludges.

    >> However, I've generally found that it's not really very useful to go
    >> around saying "it's not really raining, it's not really raining" while
    >> I'm walking in a thunderstorm.....
 
    > nobody is saying that it isn't raining.

Look, I have on my disk a file from June, 1992 (yes, that's not a typo -
*1992*) called "Problems with NAT".

However, as a close personal friend of the patron saint of Lost Causes (see
all the scars on my forehead? :-), let me tell you that I have (painfully :-)
learned to recognize a lost cause when I see one, and trying to put the NAT
geni back in the bottle definitely counts.

It's raining NAT's. Deal with it.

    >> I think we can regain the "end-end model", even with NAT boxes, if we
    >> accept that those 32-bit things are irrevocably destined to become just
    >> forwarding tags with only local scope.
 
    > we might regain the "end to end model" from doing this but we would
    > still prevent a lot of applications from working well. ... so a model
    > that assumes that everything is connection-oriented and can therefore
    > afford connection setup overhead ... doesn't look very attractive to me.
 
I'm not trying to deny there are real problems with the NAT world (and you've
pointed out at least very serious one - I wasn't sure of what you meant by
the others).

In fact, I 'embrace' NAT only in order to build things that enable us to
throw away NAT - ASAP!

And it won't be easy - but there is *no* forward path for growing the
Internet which is easy. Whatever we do, it's going to be painful.

But I don't think a forklift upgrade is workable in today's Internet. We have
to find an path consisting of many incremental steps. E.g. we have to build a
new end-end namespace, and modify applications one by one to use it. (That
still won't fix some of the problems you allude to, but's it's a necessary
preliminary step.) Then, with that as a fixed reference, we can more easily
deploy new location 'names'.

    > and I have yet to see someone who recommends that approach demonstrate
    > how to recover the functionality that you lose by doing so.

Well, the goal is to throw away NATs eventually (like 10 years down the road,
at the pace the gigantic beast called the Internet moves now). But we can't
get there unless we embrace NAT's in the short term.

    > except for the dubious benefit of NAT compatibility, I haven't been
    > able to figure out why it's so important to have yet another form of
    > local forwarding tag

Simple; I don't think anyone working with NAT's has any interest in another
form of local forwarding tag! People don't give a rat's anterior about
another local forwarding tag. They treat them that way because they have to,
not because they need/want a local forwarding tag.

    >> But it will have to be an incremental approach back to goodness, I
    >> fear...
 
    > if you mean an approach that can be deployed incrementally, I agree.

Good, something we concur on - although I suspect my "incremental" is perhaps
a lot more incremental than you realize.

    > the top of the NAT hill is a long way from goodness.

Absolutely. Which is why it's important to throw NAT's away as soon as we
can.

	Noel

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Apr 2000 17:10:03 -0400

> It's raining NAT's. Deal with it.

understood.  it's just that part of my strategy for dealing with the 
NAT problem is to try to counteract the "NATs are wonderful and don't
really cause any signifcant problems that can't be fixed with ALGs" 
propaganda that's being generated from some corners.  NATs are a big
problem for the Internet and we can't really solve it until folks realize 
that there's a problem. 

and just because I'm arguing against the above kinds of statements doesn't 
mean that I think we can convince folks to just discard their NATs.  I do 
however think that folks may be willing to upgrade and/or replace their 
NATs once something better exists that allows them to run applications that
they can't run with current NATs.  and I don't know of any way to 
improve things that doesn't require replacing/upgrading NATs in some sense.

another part of my strategy is to counteract the "we need to move away 
from using addresses as endpoint IDs" argument, which I might restate
as "we don't really need endpoint IDs which allow network addresses
to be algorithmically derived from them". because in my experience 
endpoint IDs that are not resolvable into network addresses aren't 
very useful, and endpoint IDs that require a distributed database lookup 
to translate them into network addresses are slow, inefficient, expensive, 
and error prone.

I do understand that there are scaling difficulties at the routing layer 
associated with having network addresses be derivable from endpoint IDs,
(e.g. having them be both stable and globally scoped) even though I 
don't think I could accurately describe those problems.  

> Internet which is easy. Whatever we do, it's going to be painful.

agreed.
 
> to find an path consisting of many incremental steps. 

I guess I think that forklift upgrades might be possible, but those 
have to be incremental as well - and the folks who pay for the upgrades 
have to see some benefit from doing so.

> E.g. we have to build a

I agree that applications will need to adapt to a new end to end namespace,
because a 32 bit space isn't enough for the long term even if the bits 
had no significance at all for network topoligy.   (you still would need
to have hierarchical delegation of the namespace and the associated 
inefficiences, just so that assignment would scale)

> get there unless we embrace NAT's in the short term.

this is not clear to me.  I understand that folks are going to use NATs
when NATs meet their immediate needs and when getting non NATted addresses
is too painful.  but there is an increasing demand for devices and 
applications that do not work well with NAT.
 
> not because they need/want a local forwarding tag.

okay, so you're not arguing that the architecture inherently needs more local
forwarding tags, but simply that this is the environment that NATs give us,
and if we can find a solution that works within that environment, we're 
better off.  I guess I don't see a way to actually solve applications' 
problems that doesn't either require some changes to the NAT (whether by a 
forklift or a rom upgrade), or requires that the NATted IP network be
treated as a link layer and that the "real" traffic be tunneled over it.  
(which is equivalent in difficulty to a forklift upgrade and more complex)
and if we're going to need to change the NATs anyway I'd just as soon
change them in such a way that we're back to having endpoint IDs
from which network addresses can be algorithmically derived.

> Absolutely. Which is why it's important to throw NAT's away as soon as we

sure.  see we do agree on some things!

Keith

---

From: Richard Shockey <[email-masked]>
Date: Sat, 22 Apr 2000 21:08:35 -0500

>improve things that doesn't require replacing/upgrading NATs in some sense.

Keith .I have been following this thread for some time and I am in total 
agreement with your position and the position of the IAB on this issue.

However we seem to be missing a rational strategy for dealing with the 
Layer 8 [economic] issue here which is the greed of the general ISP 
community in matters involving the issuance of  IP numbers, especially in 
the emerging home based SOHO broadband industry, cable or DSL.

Beyond the ongoing problem of installation nightmares, which are well 
documented in every print publication I see. We are hearing daily stories 
of  49.95 a month for DSL service with 1 IP address but if you want 5 its 
79.95 for "business class service". The ISP assumes that if you want more 
than 1 IP address you are running a server, forget that it could be a 
service like IPP, but some e-commerce site or whatever.

Our distinguished colleague Vint Cerf highlights these issues, once 
again,  in the latest issue of Upside May 2000 page 204 ( no its not online 
yet ).

Though I know this list is often populated with folks with a libertarian 
bent, may I remind some that there is one other form of global numbering 
that is allocated on a reasonable, fair and equitable basis to all comers. 
Telephone Numbers. This process is political but it works ( unless you live 
in Northern California ).

The problem is not NAT's. The problem is why people have to use 
NAT's...they can't get the numbers they need or want, in large measure, due 
to the greed of ISP's.

The problem, as I see it is really a Layer 9 issue [politicial] which is we 
have no national policy in the US, or any where else on the planet, for the 
issuance of IP addresses on request to those consumers or businesses who 
need them on a fair and equitable basis consistent with the requirements of 
the routing tables.

And yes I have a credit card ready, willing and able to purchase service 
for an ISP willing to give be a nice block of IP V6 numbers ( 50 will do ) 
at a reasonable price and the support necessary to implement them.

Dr. Cerf ..you have a customer.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Apr 2000 22:23:30 -0400

Richard,

I'm not entirely pleased with the current policies for address assignment,
nor with the pricing policies of certain ISPs for access for more than
one IP address.  However, I'm convinced that even with improvements to 
these policies, IPv4 address exhaustion would still be a major problem
(it could easily be a far worse problem) and would still be a significant 
motivation for NAT deployment.

Keith

---

From: "vinton g. cerf" <[email-masked]>
Date: Sat, 22 Apr 2000 23:50:05 -0400

big smile - vBNS+ is running IPv6 on a commercial basis. I'd be more than interested in
your opinion of a sensible (acceptable) policy on the minimum size of IPv6 space one might expect
to allocate to customers. 

Vint

At 09:08 PM 4/22/2000 -0500, Richard Shockey wrote:
>And yes I have a credit card ready, willing and able to purchase service for an ISP willing to give be a nice block of IP V6 numbers ( 50 will do ) at a reasonable price and the support necessary to implement them.
>

=================================================================
I moved to a new MCI WorldCom facility on Nov 11, 1999

MCI WorldCom
22001 Loudoun County Parkway
Building F2, Room 4115, ATTN: Vint Cerf
Ashburn, VA 20147
Telephone (703) 886-1690
FAX (703) 886-0047

"INTERNET IS FOR EVERYONE!" 
See you at INET2000, Yokohama, Japan July 18-21, 2000
http://www.isoc.org/inet2000

---

From: Mark Prior <[email-masked]>
Date: Sun, 23 Apr 2000 16:45:53 +0930

That is a huge generalisation. The ISP I work for offers customers as
many IP numbers as they can justify and at no additional cost to them.
Irrespective of the availability of public address space a large number
of customers choose to do NAT for their own reasons.

Mark.

---

From: "Bernard Aboba" <[email-masked]>
Date: Sun, 23 Apr 2000 00:21:02 -0700

>they can't get the numbers they need or want, in large measure, due
>to the greed of ISPs.

Rather than demonizing ISPs, it's more worthwhile to take
some time to stand in their shoes. Back in the mid '90s,
we faced these same issues in provisioning of small office/home
offices. It was generally much easier (and less expensive from
an administrative point of view) to roll out dialup infrastructure
on a mass scale allocating a single (dynamic address) than it
was to allocate and keep track of address space, with attendant
routing issues.

Early on, the hope was that RADIUS functionality like
Framed-Route and Framed-Routing could enable inexpensive
mass-provisioning of SOHOs connected via inexpensive
RIP-enabled analog and ISDN routers. This functionality
did make it easier to set up statically routed SOHOs.
However, it didn't scale very well as POPs grew to
encompass many access devices, and customers changed
their points of attachment, thus making it increasingly
difficult to administer from a routing point of view.

Support data also told us that those statically routed
customers were many times more likely to require
extensive support. All of this combined to make the
real costs of providing the "routed" service many
times that of giving customers a NAT and a dynamically
assigned address.

Since then, we've made remarkably little progress on
the auto-provisioning problem.

>at a reasonable price and the support necessary to implement them.
      ^^^^^^^^^^               ^^^^^^^

The words "reasonable" and "support" do not fit together well, since a
service that requires lots of support isn't likely to be reasonably
priced. What we probably should be shooting for is a service that can
be sold at a reasonable price, but that requires no support at all.

---

From: Brian Lloyd <[email-masked]>
Date: Sun, 23 Apr 2000 10:12:48 -0700

> > *1992*) called "Problems with NAT".

This is probably a naive viewpoint but I have always viewed NAT as a hack 
that would allow us to continue to use 32bit addresses until we could 
deploy a larger address.  When this discussion was going on back in 1992 
(yes, I remember the arguments) NAT was proposed as an interim solution, 
not a final solution.  So, whatever happened to IPv6?  128 bit addresses 
would certainly allow us to continue using IP addresses as endpoint 
identifiers thus eliminating the need for NAT.  It seems that this is a 
more reasonable solution than trying to make NAT work under all circumstances.

I hate to say it but if Microsoft deployed IPv6 in its OS products, this 
discussion would probably be moot because the endpoint users would upgrade 
most of the endpoints for us thus just requiring the backbone to run IPv4 
and IPv6 routing in parallel for a time.

Never mind.  I am sure I am just being naive.

Brian Lloyd                                    Lucent Technologies
[email-masked]                                3461 Robin Lane, Suite 1
http://www.livingston.com                      Cameron Park, CA  95682
+1.530.676.6513 - voice                        +1.530.676.3442 - fax

---

From: "Dick St.Peters" <[email-masked]>
Date: Sun, 23 Apr 2000 21:39:15 -0400 (EDT)

> was to allocate and keep track of address space, with attendant

While I fully agree that demonizing ISPs is not useful, routing issues
for user subnets ceased being a problem quite some time ago - since
OSPF became generally available in NAS boxes.

I have four service areas in which my dialup users have a choice of
access numbers that are answered in different POPs.  Users with a
routed subnet can disconnect from one number and immediately reconnect
via a number answered in a different town, and OSPF will route their
network to them.  TCP sessions remain intact, seeing only a pause.

Routing issues are not the reason for NAT deployment.  On my network
NAT exists because users prefer it.  We give any user, even analog
dialup users, a /29 free for the asking.  They are hard to give away.
Every user running NAT has chosen to do so rather than accept a free
subnet.

Currently, 0.8% of our dialup (including ISDN) users have taken us up
on our free subnet offer.  (I think I told someone 0.08% in private
mail a day or two ago - sorry about that.)  We even have a T1 client
that chose to take one IP address and run NAT.  Most users are not
networking geeks.  They like NAT because NAT boxes make what they want
to do so easy.

Note that giving away /29s to dialup users puts us in a tenuous
position with respect to the address use guidelines for ISPs in
RFC2050 - a BCP, under which assigning even a single /32 to a dialup
user is "strongly discouraged".  It also says "ISPs should have
documented justification available for each assignment."

Basically an ISP can A) violate RFC2050 by giving subnets without
documented justification, B) document willingness to pay extra for a
subnet as evidence of justification, or C) pry into users' business
asking what they want a subnet for.

We used to give free /27s to any user who asked.  However, when ARIN
put ISP address use under a microscope and RFC2050 gave the
guidelines, we did some checking of use and found that no dialup user
assigned a subnet had more than 4 addresses in use, so we reduced the
free subnet size (except for grandfathered users).

--
Dick St.Peters, [email-masked] 
Gatekeeper, NetHeaven, Saratoga Springs, NY
Saratoga/Albany/Amsterdam/BoltonLanding/Cobleskill/Greenwich/
GlensFalls/LakePlacid/NorthCreek/Plattsburgh/...
    Oldest Internet service based in the Adirondack-Albany region

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Apr 2000 23:44:12 -0400

> Most users are not

presumably they don't realize that the NATs are making it hard 
to do other things that they might want to do.

I wonder...how many of these folks really want network address 
translation, versus those who just want the other things that
NAT boxes often do?   (DHCP, firewall, hub, router, all with 
really easy setup)

maybe we need to make it as easy to connect a small net to the 
Internet, as it is to connect a host. 

Keith

---

From: Randy Bush <[email-masked]>
Date: Sun, 23 Apr 2000 20:55:27 -0700

>> Most users are not networking geeks.  They like NAT because NAT boxes
>> make what they want to do so easy.
>

bingo!

[ as easy for all parties, the user and the upstream ]

---

From: "Dick St.Peters" <[email-masked]>
Date: Mon, 24 Apr 2000 00:16:24 -0400 (EDT)

> NAT boxes often do?   (DHCP, firewall, hub, router, all with 

Bingo.  Most don't even know what NAT is.  They buy a box that does
what they want with easy setup and sometimes never mentions NAT.
(What they want doesn't include DHCP; they mostly don't know what that
is either.)

---

From: Peter Johansson <[email-masked]>
Date: Sun, 23 Apr 2000 21:20:41 -0700

>NAT boxes often do?   (DHCP, firewall, hub, router, all with 

I'm not a valid statistical sampling, just a point of anecdotal evidence in
support of your musings, Keith.

Less than four months ago I switched from dial-up access to ADSL. My ISP
was being less than forthcoming about the security risks inherent in a
24/7, so I had to do some research on my own. I settled on a DSL
modem/router with NAT capabilities in the belief that it would meet my
(modest) security needs. "Modest" because I have, as yet, no plans to
provide Internet services, only consume them.

Even today I know little about the nuts and bolts of NAT's operations. I've
started following this and other threads (notably zero configuration)
because I'm vitally interested in the "home network"---and come at it from
a Serial Bus (IEEE 1394) perspective.

So, YES, I think many could care less about NAT per se and only care about
the things that come with it.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: Richard Shockey <[email-masked]>
Date: Sun, 23 Apr 2000 23:06:31 -0500

>to allocate to customers.

Well that is a very interesting thought exercise depending on the market 
that is being addressed and what is the market growth in networked devices 
in the future.

If we were looking at a typicial household and you wanted to plan for the 
future I would have to assume 1 address for every single thing plugged in 
to any thing, phone, electrical appliances, water, maybe even sewage. Yes 
an IP address on your toilet. Now before we all giggle ourselves silly at 
that thought it might be reasonable to assume that at some point in the 
future sewage/water companies would want to monitor use in order to charge 
appropriately. Its been a desire of utility companies for some time to 
remotely retrieve usage data from households for the purposes of billing.

With "always on" IP and IP on anything this is closer to reality than we 
might think. In order to permit a reasonable allocation of addresses with 
room for growth the idea of 25 IP address per household and 10 person 
actually seems conservative.

Businesses are different but some of the needs are the same.  The typical 
business customer has multiple devices at their command, many of which are 
currently IP addressable or certainly should be, phone, cell phone, 
printer, copier, fax, scanners, PDA's, cameras. 15 addressees per employee?

Ive never seen any studies on what is current enterprise consumption of IP 
addresses is per employee or what differences there might be between 
consumption in the automobile industry vs the aircraft industry vs a 
consumer products company vs a typicial teleco.

Whatever it is now it would be reasonable to assume that address 
consumption per employee within 10 years will be 4x what it is now.

Richard Shockey
Shockey Consulting LLC

---

From: John Stracke <[email-masked]>
Date: Mon, 24 Apr 2000 13:19:26 -0400

Richard Shockey wrote:

> an IP address on your toilet.

[...]

> printer, copier, fax, scanners, PDA's, cameras. 15 addressees per employee?

Maybe more--business needs would probably be almost a superset of home needs
(only major appliances I can think of that are in my home but not my office
are the washer and dryer).  If the sewage utilities find it useful to monitor
toilets, they'll want to include businesses--they'll probably start with
businesses, in fact, which will be more amenable to price incentives.

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |"How can one conceive of a one party system in a|
[email-masked]|country that has over 200 varieties of cheese?" |
|                |--Charles de Gaulle                             |
\=================================================================/

---

From: Graham Klyne <[email-masked]>
Date: Tue, 25 Apr 2000 09:08:40 +0100

>actually seems conservative.

Following this line of thought, I'd suggest taking the number of electrical 
outlets and multiplying by some suitable constant (say, 10, or 1000).

And what about all those little wireless-connected gadgets;  an IP address 
for each TV remote-control (where everyone has their own, of course, for 
personalized access and prioritizing control conflicts...)

#g

------------
Graham Klyne
([email-masked])