Subject: Re: IP network address assignments/allocations information?

From: Vernon Schryver <[email-masked]>
Date: Fri, 26 Nov 1999 17:50:08 -0700 (MST)

> > All I know is that we have thousands of sites using private address space,
> > which completely falsifies any real data and makes it impossible to attach
> > any real meaning to concepts such as "running out of addresses".
>
> the original question was not whether address panic was justified.  it asked
> for data on assignments/allocations.  these are real measurable numbers
> which should be easily available, not a platform for political or social
> grandstanding.

I didn't notice any platforms or political or social grandstands.  Maybe
there is some unstated context that implies an agenda.

Provided "data on assignments/allocations" means nothing more interesting
than what ARIN can say, there are surely easily measurable, available
numbers.  Was such a relatively boring number the original topic? 

Why should more interesting numbers be measurable, not to mention
available?  Do you think that the number of IP addresses have been seen
in IP headers somewhere on the ICMP-Echo-Request-answering-without-NAT
Internet within the last 12 months is easily measurable?  If you extend
the definition of the Internet to include the bazillions of hosts that
think they are are using RFC 1597 addresses and can still answer ICMP Echo
Requests, then what does it mean to ask how many addresses have been
allocated?  If 100,000 hosts think they have been using 10.1.2.3 but have
really been using 10,000 ports on 1,000 dial-up IP addresses, do you count
them as 100,000, 1,000, or some other weight?

Those would be interesting numbers, but I doubt I'd believe more order of
(decimal) magnitude values without a lot of supporting argumentation.
Would you?

Vernon Schryver    [email-masked]

---

From: "Fleischman, Eric W" <[email-masked]>
Date: Mon, 29 Nov 1999 08:47:16 -0800

A few questions for the list:
1) If we effectively ran out of addresses when RFC 1597 was published, has running out of addresses hurt us in any way? 
2) Originally we had anticipated using IPv6 to save us from IPv4 address depletion. What's the status of IPv6? How does IPv6 traffic compare in volume with IPv4 traffic? Do non-IPv6-supporting vendors (e.g., Microsoft) have plans to eventually support IPv6?
3) Given the current situation of corporations using private addresses internally and a smaller set of global IPv4 addresses on their periphery, and a global IPv4 internet, one should theoretically be able to say how many public IPv4 addresses have been assigned and therefore how many remain unassigned and by so doing estimate how long until consumption. Why is this not possible in practice?

> ----------
> From: 	Brian E Carpenter[SMTP:[email-masked]]
> Sent: 	Friday, November 26, 1999 1:35 PM
> To: 	Randy Bush
> Cc: 	Bill Manning; Pete Loshin; [email-masked]
> Subject: 	Re: IP network address assignments/allocations information?
> 
> Well, let's not focus on Bill's data. Frankly, I haven't seen any data
> on this topic from any source that really convinces me that it
> means much. All I know is that we have thousands of sites using
> private address space, which completely falsifies any real data and
> makes it impossible to attach any real meaning to concepts such as
> "running out of addresses". My personal opinion is that we ran out
> of addresses in practical terms around about when RFC 1597 was published.
> 
>   Brian
> 
> Randy Bush wrote:
> > 
> > > www.isi.edu/~bmanning/in-addr-audit.html
> > >       It does not cover specific /16 & /24 delegations, it just looks at
> > > all of the SOA entries. Still, it does give a representation of how much
> > > space is delegated.
> > 
> > uh, as these data appear to be the statistics of an attempt to walk the
> > dns in-addr.arpa tree what confidence is there that this fairly represents
> > address space assignment/allocation?
> > 
> > e.g. there are 153 /16 announcements in 133.0.0.0 and the table at
> > http://www.isi.edu/~bmanning/in-addr-data.html shows one in-addr.arpa
> > allocation entries.
> > 
> > e.g. there are 166 announcements (of 175 /16 equivalents of space) in
> > 147.0.0.0 and the table at http://www.isi.edu/~bmanning/in-addr-data.html
> > shows 193 in-addr.arpa entries.
> > 
> > so how can the data at www.isi.edu/~bmanning/in-addr-audit.html be
> > interpreted to give a useful representation of how much space is
> > assignmed/allocated?
> > 
> > randy
>

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 29 Nov 1999 10:42:22 -0700 (MST)

> From: "Fleischman, Eric W" <[email-masked]>

> 1) If we effectively ran out of addresses when RFC 1597 was
> published, has running out of addresses hurt us in any way?

I think, as Brian pointed out today, 
draft-carpenter-transparency-04.txt argues that it has.

> 2) Originally we had anticipated using IPv6 to save us from IPv4
> address depletion. What's the status of IPv6? How does IPv6 traffic
> compare in volume with IPv4 traffic? Do non-IPv6-supporting vendors
> (e.g., Microsoft) have plans to eventually support IPv6?

I used to work (and not as a manager, system administrator, salesperson,
or other less technical job) for a UNIX vendor that had been working on
IPv6 for a matter of years when I left.  Shipping support for IPv6 in the
same sense as shipping support for IPv4 is not as trivial as it sounds to
managers, network administrators, salespeople, and standards committee
go-ers.  It would be merely a major pain if all anyone cared about was
sending IPv6 packets, but there are other things, such as naming, routing,
and the reason for the exercise, applications.  And no, while the changes
to applications are generally conceptually trivial, in practice finding
and making the required changes is not.  If nothing else, the size of the
bloated IPv6 address has painful, time consuming implications for
applications, standards committee choruses not withstanding.

> 3) Given the current situation of corporations using private
> addresses internally and a smaller set of global IPv4 addresses on
> their periphery, and a global IPv4 internet, one should theoretically
> be able to say how many public IPv4 addresses have been assigned
> and therefore how many remain unassigned and by so doing estimate
> how long until consumption. Why is this not possible in practice?

The number of public IPv4 addresses that have been assigned can be known;
simply ask ARIN &co.   However, I don't see how past assignments imply
anything useful about the future.  The vast majority of currently assigned
IPv4 addresses could be reassigned for varying costs.  At one extreme, it
would be almost free to reassign many of old class-C's that are not
currently routed.  In the middle, you could force corporations that own
A's and B's to reassign to RFC 1597 numbers in their internal networks
and yield their blocks.   At the other extreme, you could force routed
networks to be compressed.

In other words, the question is meaningless unless you also somehow
specify how much pain you can or will impose or tolerate until the end
and what you consider the end.

Regardless of one's beliefs in the futures of IPv4 and IPv6 and
whether you agree with Brian's apparent personal conclusion,
draft-carpenter-transparency-04.txt lists many of the relevant issues.

---

From: Vernon Schryver <[email-masked]>
Date: Mon, 29 Nov 1999 10:42:22 -0700 (MST)

---

From: Steve Hultquist <[email-masked]>
Date: Mon, 29 Nov 1999 22:18:23 GMT

Many of the people who have deployed NATs are responding directly to the
address scarcity (and resultant cost). If you consider that many ISPs now
have different pricing models for multiple IP addresses than they do for a
single (regardless of bandwidth used), it isn't surprising. I also think
that it's interesting to consider that security concerns are the other
primary reason for use of NAT.

ssh

                    Keith Moore                                                                                
                    <[email-masked]        To:     "Fleischman, Eric W" <[email-masked]>         
                    .edu>                cc:     Randy Bush <[email-masked]>, "'Brian E Carpenter'"             
                                         <[email-masked]>, Bill Manning <[email-masked]>, Pete Loshin 
                    11/29/1999           <[email-masked]>, [email-masked]                                      
                    11:08 AM             Subject:     Re: IP network address assignments/allocations           
                                         information?                                                          

> 1) If we effectively ran out of addresses when RFC 1597 was published,
> has running out of addresses hurt us in any way?

absolutely.  partially as a result of (perceived or actual) address
scarcity,
people have deployed NATs everywhere, and this has had an large adverse
effect on the Internet's ability to support certain types of applications -
particularly distributed applications (multi-party conferencing, games,
simulations, distributed computations) and applications where the "user"
end needs to be able to accept incoming traffic which is initiated
from "outside".  NATs also impair the reliability of the network because
they can discard address mappings for connections that are still being
used by applications.

Keith

---

From: "Steve Hultquist" <[email-masked]>
Date: Mon, 29 Nov 1999 23:46:08 GMT

I'm sorry that I wasn't clearer in my reply, but I agree completely. Hence 
my claim that it's "interesting". Frankly, similar to most hacks, there 
are no really good reasons for NAT, but it seems for many an easy way to 
solve a near-term problem. I think it's good that the implications are now 
becoming more clear to so many.

ssh

Brian E Carpenter <[email-masked]>
11/29/99 04:06 PM

        To:     Steve Hultquist <[email-masked]>
        cc:     Pete Loshin <[email-masked]>, [email-masked]
        Subject:        Re: IP network address assignments/allocations information?

Steve Hultquist wrote:
...
>  I also think

As had been repeatedly pointed out, this is a totally bogus argument
for NAT. Filtering routers were around long before NAT, and protect
systems against intrusion just as well as NAT.

  Brian

---

From: "Steve Hultquist" <[email-masked]>
Date: Mon, 29 Nov 1999 23:46:08 GMT

ssh

Steve Hultquist wrote:
...

  Brian

---

From: Pete Loshin <[email-masked]>
Date: Mon, 29 Nov 1999 22:20:05 -0500

At 10:44 AM 11/29/99 -0800, Tony Hain (Exchange) wrote: 

>
> 2) Yes Microsoft plans to support IPv6, and work has started. 

Can you say anything more specific about that? Earlier this fall there were
reports in the trade press that IPv6 was probably not going to make it into the
initial release of Win2K, and that Cerf and Gates were supposed to schedule a
meeting to talk it over. Are my recollections of those reports correct? Did
anything happen? Is anything going to happen?

Inquiring minds want to know...

regards,
-pl

+-------------------------------------------------------------+
| Pete Loshin                    http://Internet-Standard.com |
|                                                             |
| _IPv6 Clearly Explained_ Morgan Kaufmann January 1999       |
| _TCP/IP Clearly Explained_ 3rd ed Morgan Kaufmann June 1999 |
|                                                             |
+-------------------------------------------------------------+

---

From: Pete Loshin <[email-masked]>
Date: Mon, 29 Nov 1999 22:20:05 -0500

regards,
-pl

---

From: "Tony Hain (Exchange)" <[email-masked]>
Date: Mon, 29 Nov 1999 10:44:07 -0800

1) Yes ... We have been forced into a world of NAT where simple applications
such as Real Player won't work without real-time manual intervention at the
NAT.

3) We have moved from a world where Internal/External (and the associated
management burden) was an option, to one where it is required. If
corporations wanted to remove their firewalls (using IPSec instead) they
couldn't. 

 -----Original Message-----
From: 	Fleischman, Eric W [mailto:[email-masked]] 
Sent:	Monday, November 29, 1999 8:47 AM
To:	Randy Bush; 'Brian E Carpenter'
Cc:	Bill Manning; Pete Loshin; [email-masked]
Subject:	RE: IP network address assignments/allocations information?

A few questions for the list:
1) If we effectively ran out of addresses when RFC 1597 was published, has
running out of addresses hurt us in any way? 
2) Originally we had anticipated using IPv6 to save us from IPv4 address
depletion. What's the status of IPv6? How does IPv6 traffic compare in
volume with IPv4 traffic? Do non-IPv6-supporting vendors (e.g., Microsoft)
have plans to eventually support IPv6?
3) Given the current situation of corporations using private addresses
internally and a smaller set of global IPv4 addresses on their periphery,
and a global IPv4 internet, one should theoretically be able to say how many
public IPv4 addresses have been assigned and therefore how many remain
unassigned and by so doing estimate how long until consumption. Why is this
not possible in practice?

> > 147.0.0.0 and the table at
http://www.isi.edu/~bmanning/in-addr-data.html

---

From: "Tony Hain (Exchange)" <[email-masked]>
Date: Mon, 29 Nov 1999 10:44:07 -0800

---

From: Ian King <[email-masked]>
Date: Mon, 29 Nov 1999 22:45:17 -0800

Yes, my ISP is charging me for my DNS entry -- a static entry made once in a
zone file, but I'm paying monthly to have a domain name!  Never mind that I
don't use their mail server or Web page service or DNS server....  

And yes, additional IP addresses were going to cost dramatically more.  NAT
was a simple case of economics... but on the other hand, I don't experience
any "lack" because of it.  I don't play UDP-based games or employ any of the
other relatively new protocols that are so sensitive to end-to-end-ness
(should they be? was that a valid assumption?), so a NAT is a great solution
for me.  

NAT would be bad if an ISP were using it to artificially expand its address
space; the use of NAT at the "small-time" end user's site seems quite
practical and beneficial, especially in a world where ISPs are going to hold
up non-naive users for ransom.  Cheers -- Ian 

-----Original Message-----
From: Richard Shockey [mailto:[email-masked]]
Sent: Monday, November 29, 1999 8:00 PM
To: Keith Moore
Cc: [email-masked]
Subject: Re: IP network address assignments/allocations information? 

At 07:02 PM 11/29/1999 -0500, Keith Moore wrote:
> > single (regardless of bandwidth used), it isn't surprising.
>
>no, not surprising (and in fact some people predicted it), but
>it is surely unfortunate.

I can personally testify to the above comments. Consider...we are all IP 
professionals ...so we'd like to occasionally play with all of the 
wonderful toys we've built...at home. Our fathers stuck their heads under 
the hoods of cars or played with short wave radios...we play with IP.

Now try and ask your friendly neighborhood DSL or Cable Modem provider 
about getting a nice chunk of IP addresses. Well we all know what DSL 
really means ..._D_riveway _S_ite _L_iaison  or the modern version of "Who 
on first?".

You want to run a web server, DNS (from home?)  IPP printer accessible 
printer ( DUH what's IPP?), SIP phone .. pick your application.  To the 
service providers the request for IP addresses is some sort of strange 
signal that you're running a eCommerce site from home or worse a Game/Porn 
site. Something that they believe they should charge more money for.

The path of least resistance is just install a NAT. The market for NAT 
device/software products are being driven by in part the lack of IP4 
numbers but certainly the lack of knowledge, marketing skills or just plain 
greed of the ISP community.

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: Paul Ferguson <[email-masked]>
Date: Tue, 30 Nov 1999 07:10:05 -0500

Hi Tony,

Well, the statement below is not true -- I sit behind a NAT/PAT
device and Real PLayer works just fine for me. I've only found a
couple of applications that will not work for me (e.g. ICQ, NTP,
SNMP), but then again, I'm not a gamer so I can't speak to the
broader range of applications that it _does_ break.

In any event, I've always personally been of the opinion that
if applications don't work in the face of NAT, then the
applications themselves are functionally deficient and should be
fixed.  :-)

Cheers,

- paul

At 10:44 AM 11/29/1999 -0800, Tony Hain (Exchange) wrote:

>1) Yes ... We have been forced into a world of NAT where simple 
>applications such as Real Player won't work without real-time manual 
>intervention at the NAT.

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 30 Nov 1999 15:37:22 GMT

1) It doesn't have to stay that way with IPv6 or an equivalent technology.

2) That's good news. More details would be useful.

3) I think this is a red herring. With most organizations moving to DHCP 
and many to LDAP-driven policy management, this is completely possible. 
What makes you argue that such a transition isn't possible? It's much 
easier than (say) migrating operating systems.

ssh
--
Steve Hultquist, CTO and VP of Technology
Leopard
Boulder, Colorado, http://www.leopard.com/

"Tony Hain (Exchange)" <[email-masked]>
11/29/99 11:44 AM

        To:     "Fleischman, Eric W" <[email-masked]>, Randy Bush 
<[email-masked]>, "'Brian E Carpenter'" <[email-masked]>
        cc:     Bill Manning <[email-masked]>, Pete Loshin <[email-masked]>, 
[email-masked]
        Subject:        RE: IP network address assignments/allocations information?

 -----Original Message----- 
From:   Fleischman, Eric W [mailto:[email-masked]] 
Sent:   Monday, November 29, 1999 8:47 AM 
To:     Randy Bush; 'Brian E Carpenter' 
Cc:     Bill Manning; Pete Loshin; [email-masked] 
Subject:        RE: IP network address assignments/allocations 
information? 

3) Given the current situation of corporations using private addresses 
internally and a smaller set of global IPv4 addresses on their periphery, 
and a global IPv4 internet, one should theoretically be able to say how 
many public IPv4 addresses have been assigned and therefore how many 
remain unassigned and by so doing estimate how long until consumption. Why 
is this not possible in practice?

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 30 Nov 1999 15:37:22 GMT

ssh

 -----Original Message----- 
From:   Fleischman, Eric W [mailto:[email-masked]] 
Sent:   Monday, November 29, 1999 8:47 AM 
To:     Randy Bush; 'Brian E Carpenter' 
Cc:     Bill Manning; Pete Loshin; [email-masked] 
Subject:        RE: IP network address assignments/allocations 
information?

---

From: [email-masked]
Date: Tue, 30 Nov 1999 09:44:40 -0600

> applications themselves are functionally deficient and should be

I'm certainly not going to disagree with you about that,
but H.323 does not work through NAT without extremely
sophisticated stateful inspection/rewrite capabilities
in the NAT, and it will not work, period, if the signaling
streams are encrypted.  For better or worse (and let's
not get into that), there's a lot of H.323 out there
and there's going to be much, much more over the
coming years.  RSIP isn't going to work cleanly with
H.323, either (although there are some rather disgusting
things you can do in the application about that).

We can "should" until the cows come home (Hey!  They're
home!), but there's a lot of real software out there that
is broken by network address translation.

Melinda
-- 
Melinda Shore
Member of the Scientific Staff
Nokia IP Telephony
127 West State Street
Ithaca, NY  14850
+1 607 273 0724 (office)
+1 607 275 3610 (fax)
+1 607 227 4096 (mobile)
[email-masked]

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 30 Nov 1999 15:53:24 GMT

While it is important to focus on building protocols that are as 
functional as possible in as many different environments as possible, I 
find the statement that protocols are "functionally deficient" that do not 
take NAT and firewalls into account to be misguided. The ultimate goal of 
a network, in my mind, is to create an invisible connection between 
process running in distributed systems regardless of their location or 
connectivity. While protocol development is an appropriate place to 
address issues introduced by lower-level elements of the overall system, 
development of the lower levels should be focused on making development at 
higher levels as straight-forward as is practical.

As has been discussed more exhaustively and ably by others than I am able 
to, NAT breaks this model. By introducing a single point-of-failure into 
the overall system and by also introducing artificial limitations linked 
directly to the temporary scarcity of address space, it is an anomoly in 
the overall development of the network system.

The overall design philosophy for the network system, at least in my way 
of thinking, is one of inclusion and direct communication. We should 
endeavor to develop with that mindset.

ssh

Paul Ferguson <[email-masked]>
11/30/99 05:10 AM

        To:     "Tony Hain (Exchange)" <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: IP network address assignments/allocations information?

Hi Tony,

Cheers,

- paul

>applications such as Real Player won't work without real-time manual

-
This message was passed through [email-masked], which
is a sublist of [email-masked]. Not all messages are passed.
Decisions on what to pass are made solely by Harald Alvestrand.

---

From: "Steve Hultquist" <[email-masked]>
Date: Tue, 30 Nov 1999 15:53:24 GMT

ssh

Hi Tony,

Cheers,

- paul

-

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Nov 1999 08:10:56 -0800 (PST)

--- Keith Moore <[email-masked]> wrote:
> understood.  and you may never miss any of those distributed applications 
> or applications that want your end to be the "server" for the very reason
> that NAT prevents them from having enough market share to be successful.
> 
> i.e.  just because you don't know what you're missing doesn't mean that NAT
> hasn't done you harm.
> 

Keith - There is no denying that NAT devices break a bunch of applications 
and protocols. But, they did get us through the rough times when IP 
addresses are scarce and many people wanted to hop on the Internet. In a
way, NATs helped people keep their trust in IP and in the engineering 
community as a whole to come up with solutions that meet the need of the
time. Having said this, I do believe, people who market NAT devices should
warn customers of the limitations and not pretend like there arent any. 

There are some folks who believe NATs are behind the creation of private
addresses. The fact of the matter of the matter is the other way around.
People have been using private addresses to build their networks; People 
change their providers, but do not want to renumber their networks each 
time they change their providers. NATs were able to provide connetivity 
to external world without requiring them to renumber their addresses in 
the private network.

If nothing else, I would say that NATs were able to bring to bear an 
awareness in the minds of protocol/application designers a need to
seperate names and addresses. That in itself seems like an accomplishment.
 
> if you think of NAT as a short-term strategy and are fully aware of its
> limitations, it probably won't cause you much harm as an individual.  
> 
> then again, there are dozens of products out there claiming to offer
> something like "internet connection sharing" without bothering to mention
> the limitations of that approach...which seems like misleading advertising
> at best.
>

I agree.
 
> Keith

regards,
suresh
__________________________________________________
Do You Yahoo!?
Thousands of Stores.  Millions of Products.  All in one place.
Yahoo! Shopping: http://shopping.yahoo.com

---

From: "Tony Dal Santo" <[email-masked]>
Date: Tue, 30 Nov 1999 11:28:50 -0500

Valdis Kletnieks wrote:

> However, I do agree that anybody designing a protocol in the last 3-4
> years *should* have designed it to be firewall and NAT friendly.
> (Yes, I know that can be difficult in practice.  I guess that's today's
> "Welcome to Reality").

Daniel Senie wrote:

> ...and [NAT] must be taken into consideration when designing protocols.
>
>    ....        New protocols should, in my opinion, provide descriptions
> of how they work or don't work with NAT. If there is a reason why they
> aren't going to work (carriage of port or address information), a
> description of how to build an Application Layer Gateway (ALG) should be
> provided.

I really think trying to make everything "NAT aware" or "NAT friendly"
is spending effort heading in the wrong direction.  While I am forced to
concede the wide deployment of NAT technology, I believe the problems it
solves (or at least claims to) are better solved by other means, or
require different solutions.

Protocols are difficult enough to get right.  I'd rather see time spent
developing good algorithms than NAT compatibility.  What about future
NAT "features"?  Are protocol designers supposed to guess at what new
convolutions will be dreamt up?

About the only serious issues NAT really addresses are the perceived IP
address shortage, and being forced to renumber when changing ISPs.  As
for the shortage, this thread seems to indicate there isn't a real firm
idea of how many addresses are actually being used.  Have all the minimally
used class A and B addresses been reclaimed?  I suspect not, which tells
me the immediate shortage can't be that great.  And if switching to IPv6
in the long term has problems, effort should be spent solving those.

As for being forced to renumber (can't take your address with you),
is this really a technical routing problem (tables too large), or more
of an economic/political/turf issue?  While renumbering can be painful,
DNS should hide the change, and things like DHCP can make it less so.
Besides it shouldn't be too difficult for small organizations, and large
ones should be able to take their address as they move.

While NAT is an adequate stopgap solution to IP address dilemmas, in my
opinion, it shouldn't be the final solution.

> We are at a crossroads where architectural purity has intersected
> operational reality.

Let's not continue down the wrong road.

Tony

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Nov 1999 09:54:34 -0800 (PST)

--- Keith Moore <[email-masked]> wrote:
> > time. 
> the latter statement seems a bit extreme.  one could as easily make the 
> statement that NATs are giving the engineering community a bad reputation 
> in the eyes of the public, given that so many problems are now being caused 
> by them.  (also an extreme statement, but no less so than the first one)
> 

I wasnt meaning to make an extreme statement. You are right; Neither of 
the statements by itself is complete. Fair is somewhere in the middle. 

> I'd rather just say that (a) NATs are a short-term fix with limited 
> applicability, (b) for the long term general solution we will need 
> longer addresses - as in IPv6, and (c) with careful definition of
> adaptation mechanisms such as NAT-PT and 6to4, devices with NAT
> and ALG functionality can be part of a transition path to IPv6. 
> 
That sounds good. Thanks.

> absolutely true.
> > seperate names and addresses.
> 
> though folks are indeed looking into the implications of such a separation,
> it's far from clear that this is a 'need'.  every additional layer 
> of indirection imposes a cost in terms of money, performance, reliability, 
> and flexibility - all of which need to be weighted against whatever
> advantages might be obtained from such a separation.
> 

Address-renumbering and host-mobility come to mind as areas that can benefit
from seperation of name and address semantics. Surely, this should be weighed
against other metrics, as you say. No one solution fits all.

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Nov 1999 09:54:34 -0800 (PST)

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Nov 1999 10:40:00 -0800 (PST)

--- Henning Schulzrinne <[email-masked]> wrote:
> [email-masked] wrote:
> > 
> Agreed.
> Any protocol that wants to have out-of-band control will have
> difficulties with existing NATs (without ALGs). 

Good point. Out-of-band control will require an ALG. No argument there.
But, that is not to say you shouldnt think about ALGs. 

>                                                 Thus, by saying "let's
> design NAT-friendly protocols", we are effectively ruling out a whole
> class of designs and only allow protocols with outgoing TCP connections
> (and possibly UDP request-response protocols). 

I dont think, that is what is being said at all. 

If you could design applications that can work with NAT enroute, without
needing an ALG; that would be great. But, if the applications do require 
an ALG enroute (as in the case of voice-over-IP which uses out-of-band 
call-control segnalling), then the application designers should also 
consider what it takes to build an ALG enroute. This is an issue not just 
with NATs, but also with firewalls and perhaps security gateways.
  
>                                                In the case of telephony,
> it would mean keeping a TCP connection open continuously to some outside
> server that would then use that TCP connection to send incoming calls
> behind the NAT.
> 

Are you refering to the TCP connection so you can retain the name-to-address
mapping? I suspect, you need to do more than just that to permite RTP streams
across NAT boundaries. In which case, you are better off monitoring the
name-to-address mapping as part of the ALG, instead of relying on a TCP
call-control session.

> Thus, this is not just a matter of existing software, but fundamentally
> restricting protocol design to a very narrow class of design choices,
> choices which are basically inappropriate for anything related to
> efficient multimedia carriage (real-time multimedia over TCP isn't
> exactly a great option).
> 

Please see my comments above. Protocol design will be deemed successful
only as they are deployed. It does not harm to think of their impact on
NATs, firewalls and security gateways - all of which are already deployed
in a large number of locations. 

> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
> 
> 

regards,
suresh

---

From: Pyda Srisuresh <[email-masked]>
Date: Tue, 30 Nov 1999 10:40:00 -0800 (PST)

regards,
suresh

---

From: Bob Braden <[email-masked]>
Date: Tue, 30 Nov 1999 10:55:45 -0800 (PST)

*> 
  *> I'll grant FTP an exemption, it came well before NAT units became
  *> prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).

There certainly was.  FTP and Telnet were both ARPANET NCP protocols
in use since ~1972.

Bob Braden

  *> However, I do agree that anybody designing a protocol in the last 3-4
  *> years *should* have designed it to be firewall and NAT friendly.
  *> (Yes, I know that can be difficult in practice.  I guess that's today's
  *> "Welcome to Reality").
  *> 
  *> 				Valdis Kletnieks
  *> 				Operating Systems Analyst
  *> 				Virginia Tech
  *> 
  *>

---

From: Bob Braden <[email-masked]>
Date: Tue, 30 Nov 1999 10:55:45 -0800 (PST)

*> 

Bob Braden

---

From: [email-masked]
Date: Tue, 30 Nov 1999 13:06:37 -0600

> If you could design applications that can work with NAT 
> enroute, without needing an ALG; that would be great. 
> But, if the applications do require an ALG enroute 
> (as in the case of voice-over-IP which uses out-of-band 
> consider what it takes to build an ALG enroute. 

The problem of encrypted signaling remains, however.
Should you choose to deal with this problem by terminating
signaling on the ALG you have to consider the performance 
implications, as well, which have very real consequences 
when dealing with timing requirements imposed by 
interworking with the PSTN, where applicable.  Not to 
mention, of course, key management soup.  ALGs are a 
good solution for many NAT-related problems, but not 
for all of them.

Melinda

---

From: [email-masked]
Date: Tue, 30 Nov 1999 13:06:37 -0600

Melinda

---

From: Ian King <[email-masked]>
Date: Tue, 30 Nov 1999 11:03:25 -0800

I think the below statement provides important perspective.  NAT is not the
Antechrist, nor is it salvation.  Much of the work on "improving" NAT seems
much like "improving" the Band-Aid so it will last for a year, although no
one wears one for more than a couple of days!  When IPv6 is deployed and
everyone's toaster can have its own IP address, I suspect that most folks
will be perfectly happy to decommission their NAT boxes.  

Firewalls are another and likely more significant issue.  However, focusing
on firewalls narrows the issue considerably; how many corporations are
concerned whether their firewalls are Quake-friendly?  For those protocols
that are of interest to users of firewalls, the necessary work can be done
to either build ALGs, figure out tunneling methods, or design
firewall-friendly protocols; that work will be driven by a business need,
rather than an academic discussion of what "should" work.  

It's important to know which protocols are broken by NAT and firewalls --
Keith Moore's work on that is very useful.  But does each instance of
"breakage" represent something that needs to be "fixed"?  Part of this
problem (NAT) will almost certainly go away; the other part (firewalls)
requires at most a subset solution.  

Maybe we're trying too hard?  :-)  -- Ian 

-----Original Message-----
From: Tony Dal Santo [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 8:29 AM
To: [email-masked]
Subject: Re: IP network address assignments/allocations information?

[snip]

[snip]

---

From: Ian King <[email-masked]>
Date: Tue, 30 Nov 1999 11:03:25 -0800

-----Original Message-----
From: Tony Dal Santo [mailto:[email-masked]]
Sent: Tuesday, November 30, 1999 8:29 AM
To: [email-masked]
Subject: Re: IP network address assignments/allocations information?

[snip]

[snip]

---

From: "Tony Hain (Exchange)" <[email-masked]>
Date: Tue, 30 Nov 1999 13:37:33 -0800

Valdis,

This is the kind of BS that keeps these debates running. NAT problems exist
anytime a connection originates on the public side and there is not a
preexisting clear mapping to the private side. I didn't pick on Real Player
at random. My house is connected through a NATPT, and my wife couldn't get a
video stream opened back to her machine. If I had pre-mapped those ports to
her machine, then my son would not have been able to get them on his. If I
pre-map them, all the bogus security arguments about NAT become invalid.
Clearly NAT has allowed me to create an environment which is not
sustainable, but at least I know enough to know what the problem is, the
average guy on the street doesn't stand a chance.

Yes there are problems with protocols that carry addresses, but ignoring
encrypted traffic that really amounts to acquiring and synchronizing
deployments of ALGs. In the early stages this doesn't sound hard, but will
vendors be willing to add new ALGs to 3 year old NAT hardware? Will they
create an update process that is easy enough for the average user? Will the
average user be able to figure out which NAT needs updating, and what
version it needs? Add the fact that people want to encrypt their traffic for
privacy, and one wonders why so much effort is spent on this dead-end
technology. 

Tony 

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]] 
Sent:	Tuesday, November 30, 1999 12:05 AM
To:	Ian King
Cc:	[email-masked]
Subject:	Re: IP network address assignments/allocations information? 

> (should they be? was that a valid assumption?), so a NAT is a great
solution

Well.. Urm... TCP and UDP both assume that one endpoint is talking
directly in real time to another endpoint.  The NAT problems only
start when the protocol carries IP address/port information (such
as the FTP 'PORT' command), and the NAT isn't aware of that protocol's
translation requirements (If you see *this* at offset 80 of *that*
packet, smash it to read *foobar* instead).

I'll grant FTP an exemption, it came well before NAT units became
prevalent (Was there an FTP-over-NCP before The Great IP Deployment?).
However, I do agree that anybody designing a protocol in the last 3-4
years *should* have designed it to be firewall and NAT friendly.
(Yes, I know that can be difficult in practice.  I guess that's today's
"Welcome to Reality").

				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 30 Nov 1999 17:48:35 -0500

Tony,

I wouldn't be so quick to characterize NAT as a "dead-end" technology.

Personally, I think NAT is just fine, but I'm a self-proclaimed cynic
and also consider myself somewhat of a pragmatist. In any event, it
works for me, but I could certainly be in the minority.

I think most of the hoopla surrounding NAT's revolve around engineering
purism. And I agree that statements that assert that NAT's provide some
sort of "security through obscurity" are complete red herrings.

Having said that, I ask you: What do you foresee as a realistic IPv6
transition plan? Dual stacks? I don't see it happening, to tell you
the truth. (Maybe this 6-in-4 stuff will actually help here.)

The truth is that NAT's allow organizations to deploy machines in
networks which otherwise would not have enough address space. To
say that NAT's are unequivocally evil is unfair, methinks.

- paul

At 01:37 PM 11/30/1999 -0800, Tony Hain (Exchange) wrote:

>create an update process that is easy enough for the average user? Will 
>the average user be able to figure out which NAT needs updating, and what 
>version it needs? Add the fact that people want to encrypt their traffic 
>for privacy, and one wonders why so much effort is spent on this dead-end 
>technology.

---

From: Paul Ferguson <[email-masked]>
Date: Tue, 30 Nov 1999 17:48:35 -0500

Tony,

- paul

---

From: Bob Braden <[email-masked]>
Date: Tue, 30 Nov 1999 20:06:50 -0800 (PST)

*> 
  *> The problem is not to make applications "NAT aware" or "NAT friendly".  The
  *> problem is to make applications "IP address unaware".  What is an
  *> application doing exchanging and using names for things 2 layers below it?
  *> Sounds like a design for trouble if I ever heard of one.

I don't believe this argument, John.  The IP address is (part of) the
transport layer end point address, something that an application can
reasonably be expected to know about in the existing Internet
architecture.

Bob Braden

---

From: Bob Braden <[email-masked]>
Date: Tue, 30 Nov 1999 20:06:50 -0800 (PST)

*> 

Bob Braden