Subject: Re: [midcom] WG scope/deliverables

From: Joe Touch <[email-masked]>
Date: Wed, 31 Jan 2001 22:27:43 -0800

Ed Gerck wrote:
> 
> Keith Moore wrote:
> 
> > I expressed an opinion that this group should confine itself to addressing
> > short-term goals rather than trying to make NATs a part of the Internet
> > architecture.
> 
> NATs are already part of the Internet, and gaining share.

An alternate perspective is that the Internet continues
to (mostly) work despite the presence of NATs.

It is a paradox to begin one standard by selectively omitting
current standards (e.g., RFC1122). 

Joe

---

From: Anshul Jain <[email-masked]>
Date: Wed, 31 Jan 2001 23:56:29 -0800 (PST)

Hi,

I am not clear in basics of ip address format, why we are not using the
first bit as 0 to define new class of addresses, may this double the
available IPs,

Regards,

__________________________________________________
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

---

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Thu, 01 Feb 2001 19:30:47 +0700

> current standards (e.g., RFC1122).

I believe that that is called "making progress". Cited 
from section 4.20 of RFC-1336:
  "I think three factors contribute to the success of the 
   Internet: 
   1) public documentation of the protocols, 
   2) free (or cheap) software for the popular machines, and 
   3) vendor independence."

Thus, it is not "end-to-end-purity" or because the existence
of any organization.

Speaking of keeping standards, I am wondering why STD-2
is still RFC-1700, although the current version is kept by
IANA at http://www.iana.org/numbers.htm .

regards,

-- 
Rahmat M. Samik-Ibrahim - VLSM-TJT - http://rms46.vlsm.org
- Good bye hegemony - http://sapi.vlsm.org/DLL/linuxrouter

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 1 Feb 2001 15:53:01 +0000 (GMT)

On Wed, 31 Jan 2001, Ed Gerck wrote:

> You miss at least one other possibility.  If it is possible to develop
> an addressing scheme that works in a heterogeneous network, then
> we can have point-to-point functionality across system borders and
> do not require a homogeneous address space to do so.   Now, if you
> look into the science of Thermodynamics (for example) you will see that
> this involves a meta-problem that was already solved two centuries ago.

Explain.

> NATs are a consequence of a choice rather than makers of a choice.
> The choice is to use heterogeneous networks.

NATs fake a homogeneous address space for disjoint/overlapping
*homogeneous networks*. You just layer IP over the top of the
heterogeneous networks - so we already have that addressing scheme you
want.

NATs are primarily a consequence of heterogeneous administration with
short-term local-optimisation goals that dictate use of homogeneous
network technology. (Address space shortages are also a result of
heterogeneous administration of a homogeneous and limited resource. As
are most things.)

Considered use of truly heterogeneous networks does not offer the
local optimisation NATs do (more translation, gateway maintenance),
and is rejected.

> I contend that the reasons for this choice can be found in Nature

well, yes. everything can be found in nature.

> -- for example, to adapt to local needs
> without imposing more expensive non-local changes.  This is not an Internet
> phenomenon, it is IMO the reflection of a more general principle.

Oh, right. Since we're waffling;

http://pespmc1.vub.ac.be/SUBOPTIM.html

and Gleick's 'Faster' (and Vinge's 'Deepness in the Sky', for that
matter) make some interesting statements and predictions about the
system-wide dangers of local optimisations. The zeroth law of
thermodynamics does not, IMO; entropy analogies can be highly
misleading.

It's useful to reflect on why we should be designing protocols with a
lot of overhead, redundancy, and slack in them. Contrast the success,
adaptability, longevity and utility of the ever-so-slack http with
that of the bit-efficient gopher. The lack of slack in the ATM header.
Or the slack in the GSM control channel that led almost by accident to
SMS.

If there's no slack, there's no serendipity, no escaping the local
minimum by subverting it. 

That doesn't have much to do with anything other than the work
required to handle the protocol reliably in NAT, though.

L.

IETF: optimising everything into a dead-end local minimum since 1986.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Feb 2001 11:26:22 -0600

Well, I don't think this is about midcom any more but something here
made my head hurt...

Ed Gerck wrote:
...
> we can have point-to-point functionality across system borders 

er, that is what the Internet concept was invented for
by Pouzin, Cerf and Kahn in the early 1970's. The references
are in RFC 1958. That addressing scheme is called IP; the problem
is that 32 bits are no longer enough. 

> .....and
> do not require a homogeneous address space to do so.   

at some level you must have an unambiguous namespace. If 10.1.1.1 is used
in two different places there must be a way of distinguishing them.
Unfortunately, today we do this without the benefit of an explicit
namespace - the distinction is implicit in the instantaneous state
of NAT automata, i.e. the internal state of all NATs is an extension to
the IPv4 address space. 

Thus when 10.1.1.1 is behind a NAT that has loaned it address 9.1.1.1,
its implicit address is 9.1.1.1+10.1.1.1. That's an unambiguous
address space; it's just implicit. (NAPT, multiple NAT or NAT-PT make 
it a bit more complex, but don't change what I'm saying in principle -
the implicit address just gets longer.)

A rendez-vous service for NATted peers would have to construct an
identifier explicitly, and it might as well be this implicit one.

  Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Feb 2001 09:59:28 -0800

>    2) free (or cheap) software for the popular machines, and

The unstated assumption of #1 is that there are protocols,
that they are designed carefully and conservatively to result
in a stable specification to code to.

Certainly protocols evolve and even are replaced. It's
more productive to replace a standard than ignore it, though.

> Thus, it is not "end-to-end-purity" or because the existence

I asserted neither per se. 

> IANA at http://www.iana.org/numbers.htm .

Very good question. I'll be glad to raise the issue with IANA;
at least 1700 and STD-2 should be obsoleted in their current form.

Joe

---

From: Dave Crocker <[email-masked]>
Date: Thu, 01 Feb 2001 10:05:39 -0800

>do not require a homogeneous address space to do so.

There is roughly 30 years of experience in this realm that suggests otherwise.

The difference between theory and practise is practise.

If you wish to formulate a detailed technical specification, and subject it 
to community review and testing, perhaps you will indeed show show us an 
approach that will work.  Until then, your suggestion is just an untested 
theory.

d/

---

From: Greg Minshall <[email-masked]>
Date: Thu, 01 Feb 2001 10:18:06 -0800

from some of the discussion, esp. yesterday, i had thoughts of deriving an 
anti-NAT polemic and posting it.  i planned on mentioning all of the other 
brain-dead, obsolete technologies "we" (IP) had in the past ignored, and how 
we had triumphed while they had died off.

i was thinking of things like IBM mainframes, BSC, SDLC, and ultimately got 
around to thinking of things "in our community" such as UUCP over asynch 
(mostly) phone lines, etc.

but as i thought of it, i realized that what "we" successfully  ignored in the 
past were things that had little use (the ISO acronym popped up in my mind).

things that were heavily used, we somehow brought into the fold and, in some 
sense, stepped on their shoulders on our way to "the world of greater 
connectivity".

the examples are numerous, and happened in different ways.  "we" invented ways 
of interconnecting (at least at the level of e-mail, the killer app of the 
80s) with IBM mainframes, VMS boxes, etc.

we ran IP over BSC and SDLC.

we invented MX records, as well as bizarre addressing formats (!%.etc.), to 
interconnect between the SMTP world and the UUCP world.

i guess if i think anything about all that, it is that if NATs are ubiquitous, 
we should figure out how to deal with them.  and, that (hopefully), we will 
achieve the "greater interconnectivity" on top of, and to some extent in spite 
of NATs.

cheers,  Greg Minshall

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 01 Feb 2001 12:58:10 -0600

Joe Touch wrote:
...
> at least 1700 and STD-2 should be obsoleted in their current form.

afaik nothing in 1700 has been rescinded, so it isn't obsolete;
it's simply updated by http://www.iana.org/numbers.htm 

IANA can't change the status of an STD - that's an IESG action.
If you think this matters, I would raise it with the latter.

  Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 01 Feb 2001 11:05:51 -0800

> it's simply updated by http://www.iana.org/numbers.htm

I was using the term 'obsolete' as in 'obsoleted by',
as used in other standards that have been updated by
subsequent RFCs.
 
> If you think this matters, I would raise it with the latter.

Agreed. 

I was expecting that IANA would initiate taking the action with
the IESG, not that they would supercede it.

Joe

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Feb 2001 14:10:29 -0500

[recipient list trimmed]

> we should figure out how to deal with them. 

perhaps.  but I note that for many of the examples you quoted, "dealing 
with them" was not nearly as nice as "not having to deal with them".

for instance, having email gateways was clearly better than not having
any way to exchange mail between Internet/DECnets/BITNET/uucp/CSnet/etc.
at the same time, email gateways never worked as well as we would have
liked. they often required users to know arcane details about addressing
in foreign email systems and how the addressing from different email
systems were combined (things like "ATLAS::BITNET%\"USER@NODE\""@xxx.yyy
were entirely too common), they introduced many additional kinds of 
failure which were difficult to diagnose, non-delivery reports from 
foreign systems were unreliable (either going to the wrong place or
not being able to be returned to the sender) and hard to decipher, and 
return addresses were often trashed so that replies didn't work.  Even 
the simple question "what is your email address?" was not simple to 
answer - the answer depended on context, and many users honestly didn't 
know the answer for anything beyond a very local (to them) context.
Many users couldn't give their email addresses to others.

I'll also note that email gateways were once ubiquitous, but now are
much less common.

we do need NATs in IPv4 to work around the address space shortage
as well as to allow connectivity for networks using private address 
space which cannot easily be renumbered, just as we once needed mail 
gateways.  but just like mail gateways, they don't have to stay around 
forever, and NAT use will also decline when better alternatives are 
available.

Keith
(who wrote email gateways in a past life)

---

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Fri, 02 Feb 2001 17:57:14 +0700

> Agreed.

I was not aware that there was ever a proposed STD-1 I-D and/
or last call. Anyway, is it possible to declare (by whoever)
the http://www.iana.org/numbers.htm as STD-2? Or, perhaps a 
mini RFC as STD-2 that informs where to get the current 
numbers?

I also believe that more information should be added into an
RFC:
- where to get an RFC
- where to get the recent status of an RFC
It is sometimes very confusing for the internet community at
large, to trace back the source of accurate information.

PS, these following was cited from a standard /etc/services:

--------------------------------------------------------------

# Note that it is presently the policy of IANA to assign a single well-known
# port number for both TCP and UDP; hence, most entries here have two entries
# even if the protocol doesn't support UDP operations.
# Updated from RFC 1700, ``Assigned Numbers'' (October 1994).  Not all ports
# are included, only the more common ones.
[...]
# From ``Assigned Numbers'':
#> The Registered Ports are not controlled by the IANA and on most systems
#> can be used by ordinary user processes or programs executed by ordinary
#> users.
#> Ports are used in the TCP [45,106] to name the ends of logical
#> connections which carry long term conversations.  For the purpose of
#> providing services to unknown callers, a service contact port is
#> defined.  This list specifies the port used by the server process as its
#> contact port.  While the IANA can not control uses of these ports it
#> does register or list uses of these ports as a convienence to the
#> community.

regards,

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Feb 2001 10:19:52 -0800

"Rahmat M. Samik-Ibrahim" wrote:
> or last call.

STDs are labels of existing standard RFCs which go through
the usual procedure. From RFC1718, the Tao of the IETF:

>    To help clear up some confusion, there are now two special sub-series
>    within the RFCs: FYIs and STDs.  The For Your Information RFC sub-
>    series was created to document overviews and topics which are
>    introductory.  Frequently, FYIs are created by groups within the IETF
>    User Services Area.  The STD RFC sub-series was created to identify
>    those RFCs which do in fact specify Internet standards.

> Anyway, is it possible to declare (by whoever)

The procedure would generally be to update RFC1700, 
resubmit it, and _then_ have STD-2 point to that new RFC.
(something IANA would do)

Alternately, or at least as an interim, the text in STD2 could
include the URL. However, URLs are not considered "normative
references", so it doesn't appear it would be appropriate to
use just the URL as a persistent solution here.

> - where to get the recent status of an RFC

As far as I know, the recent status is supposed to be
at the top of the RFC.

As to where to get them, that's already in rfc-index.txt
(which is in the same directory as the RFCs):

> Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
> an EMAIL message to:  [email-masked] 
> with the message body help: ways_to_get_rfcs.  
>  
> For example:
>  
>         To: [email-masked]
>         Subject: getting rfcs
>  
>         help: ways_to_get_rfcs

Joe

---

From: Greg Minshall <[email-masked]>
Date: Fri, 02 Feb 2001 11:53:26 -0800

Keith,

> with them" was not nearly as nice as "not having to deal with them".

absolutely.  i was very happy when we moved from the previous world to the 
(more or less pure) IP world.

i will be very happy when we move from the NAT world to the (more or less 
pure) IPv6 world.

Greg (who wrote email gateways in a past life)

---

From: Ed Gerck <[email-masked]>
Date: Fri, 02 Feb 2001 14:00:45 -0800

> Greg (who wrote email gateways in a past life)

I think that it is a truism that homogeneous networks are simpler.  However,
if this becomes "the" reason not to use heteregenous networks (and NATs), then
we are denying the usefulness of local solutions to local problems. We are also
restraing locally controlled growth and optimizations.

Since it is also a truism that a local maximum (or, minimum) does not have to
be a global maximum (or, minimum), then we see that a homogeneous network
must not be the best global solution either.

In other words, that is why the Net never was and resists being be a homogeneous
network. It would be a less efficient design. Thus, we need to be able to cope with
diversity, not try to iron it out. The NAT ugly duckling, the misfit to some,  may well
be a harbinger.

Cheers,

Ed Gerck

---

From: Keith Moore <[email-masked]>
Date: Fri, 02 Feb 2001 17:19:24 -0500

Ed,

We agree that the net has never been entirely homogeneous, and that it
would be a Bad Thing if people were forced to make their local nets
conform to someone's idea of the Right Way to do their networks.

Thus, I have few problems with folks who want to use NATs within their
local networks and who understand and accept the limitations of that
approach - even though, as you are fond of pointing out, this is an
example of a local optimization that is sub-optimal for the global 
Internet community.

OTOH, I have a big problem with constraining and/or encouraging folks 
to use NATs, while misleading folks about their limitations; and with 
attempts to make NATs a part of the Internet architecutre and thereby
forcing everyone to accept those limitations.

Thus we are objecting to much the same thing - not only the attempt to 
constrain what people can do with their local networks (e.g. preventing
folks from getting global addresses) but also the attempt to constrain
the kinds of software that people can deploy.

Keith

---

From: Ed Gerck <[email-masked]>
Date: Fri, 02 Feb 2001 15:03:17 -0800

> conform to someone's idea of the Right Way to do their networks.

Yes.

> example of a local optimization that is sub-optimal for the global

If it would be imposed. But IMO it is, however, globally optimal for the Internet
community to be able to solve their problems locally.

> to use NATs, while misleading folks about their limitations;

misleading is always bad.

> and with attempts to make NATs a part of the Internet architecutre and thereby

This is where we seem to diverge. IMO: (1) NATs are part of the Net archictecture and
a harbinger, not an intrusion or a misfit; (2) everything has limitations, but having no
choice is always the worse limitation.

So, rather than following the "let a thousand standards bloom" dictum, I think
that NATs (and similar approaches) are actually a way to provide for interoperation
and reduce heterogeneity -- and its effect, which is isolation.

Cheers,

Ed Gerck

---

From: Grenville Armitage <[email-masked]>
Date: Fri, 02 Feb 2001 15:06:13 -0800

Ed Gerck wrote:
	[..]
> Thus, we need to be able to cope with
> diversity, not try to iron it out.

Depends why the diversity exists. Coping is the reaction
of people who feel they cannot change the underlying causes.
Apparently not everyone feels so powerless that NAT is their
only answer. What you call "ironing out", others call "minimising
the reasons for gratutitous diversity"

cheers,
gja
________________________________________________________________________
Grenville Armitage                    http://members.home.net/garmitage/
Bell Labs Research Silicon Valley

---

From: "Rahmat M. Samik-Ibrahim" <[email-masked]>
Date: Mon, 05 Feb 2001 13:46:14 +0700

> the usual procedure. 

But, neither I was aware that there was ever an I-D and/or a 
last call for RFC-2600 or RFC-2700.

> (something IANA would do)

I believe this is a problem. Accurate information exists,
but it can not be published because it is not in a
traditional RFC format :-(.

> (which is in the same directory as the RFCs):

Unfortunately, it is not so obvious (especially for the one who
has no idea about the RFC-Editor mechanism) that rfc-index.txt
exists. 

regards,

---

From: Joe Touch <[email-masked]>
Date: Mon, 05 Feb 2001 10:18:13 -0800

> last call for RFC-2600 or RFC-2700.

RFC2026 indicates that there are some RFCs, notably STD1, 
which are reissued periodically, and it isn't clear that 
this goes back through the draft procedure.

Assigned numbers, by its own description, is a snapshot of
an ongoing process. The fact that it was accepted as an RFC
implies that it ncan and should be updated periodicaly.

Finally, the document itself declares that the current 
values for the assigned numbers are NOT in the document, but
rather in a file at the following address:

> The files in this directory document the currently assigned values for
> several series of numbers used in network protocol implementations.
> 
>         ftp://ftp.isi.edu/in-notes/iana/assignments

--

> >> mini RFC as STD-2 that informs where to get the current

The 'mini RFC' is already in STD-2, FWIW.

> has no idea about the RFC-Editor mechanism) that rfc-index.txt

Search engines are your friend in this case.
A quick search on Google points, first shot, to
the RFC-Editor, which indicates the index:

	http://www.rfc-editor.org/

The IETF's RFC pages also contain a link to that RFC:

	http://www.ietf.org/rfc.html

Joe

---

From: "Michael W. Condry" <[email-masked]>
Date: Wed, 14 Feb 2001 17:53:10 -0800

Well the message I got earlier was the IPv6 will not fix
the NAT problem - true or not true?  I assume
with IPv6 there is no need for NATs. Who thinks
they will still be around - humm maybe if the ISP charge
a fortune for 4 IP addresses vs 1 IP address (IPv6 or IPv4).

>Greg (who wrote email gateways in a past life)

Michael W. Condry
Director, Network Edge Technology

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 21:44:38 -0500

> the NAT problem - true or not true?  

depends on how you define "the NAT problem"

- if you define it as a shortage of addresses, then IPv6 *does*
  solve the NAT problem - provided, of course, that the RIRs
  are willing to assign reasonable sized blocks (much larger
  than IPv4 assignments) and similarly, that ISPs do not charge 
  onerous amounts to route reasonably sized address blocks to 
  customers.

- if you define it as the ability to "plug and ping" small networks
  into the Internet, then (as far as I can tell) we still need
  a small piece of protocol beyond IPv6 to have a "pure IPv6" 
  plug-and-ping solution.  in the interim, either PPP or DHCP 
  will give you an IPv4 address; this combined with 6to4
  gives you a /64 on a plug-and-ping basis, and the protocol work
  for this is already done.

- if you define the NAT problem as the ability to easily renumber
  networks (or more precisely, the ability to avoid needing to 
  renumber networks), then IPv6 probably still needs a bit of work
  until renumbering an IPv6 network is as painless an operation
  as "renumbering" an IPv4 network using a NAT.  of course the
  NAT produces its own kind of pain, which you might or might not
  realize is part of the cost of using a NAT to renumber.

- if you define the NAT problem as the ability to provide the
  security and illusion of security that folks get from NATs, 
  rest assured that the same degree of security and illusion 
  can be provided using IPv6 mechanisms.  However, with IPv6,
  the NATs won't prevent applications that need stable addresses
  from having them.

- if you define the NAT problem as the inability to run 
  certain kinds of applications, then yes, IPv6 does solve
  those problems. however you have to modify your application
  to run IPv6. 

- if you define the NAT problem as the difficulty associated
  with trying to bilaterally connect together various IPv4 networks,
  each of which uses potentially overlapping address spaces, then yes
  IPv6 solves this problem.  (IPv6 seems like a big win for B2B 
  communications)

so to answer your question succinctly I'd say "mostly true".

> I assume with IPv6 there is no need for NATs. Who thinks

it's probably misleading to think of IPv6 vs. NATs as an either-or
situation.  NATs will definitely be around for awhile - to provide 
connectivity for legacy v4-based applications and networks,
(email and web will be primarily v4-based for a long time)
and NAT-PT to provide some measure of interoperability between
v6 and v4 apps.  However, one hopes that NATs will not interfere
with pure v6 connectivity, so that applications that are written
for IPv6 will be able to rely on the increased functionality.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 21:47:55 -0500

>   for this is already done.

it should read

"...this, combined with 6to4 gives you a /48 on a plug-and-ping basis..."

Keith

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 14 Feb 2001 18:52:12 -0800

At 05:53 PM 2/14/2001 -0800, Michael W. Condry wrote:
>I assume with IPv6 there is no need for NATs.

IPv6 does not solve the need to renumber if you change providers (and no, 
not everyone can be a provider -- IPv6 uses CIDR, just like IPv4).  Until 
that issue is addressed, there will be NATs.  Even for v6.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 22:02:38 -0500

> that issue is addressed, there will be NATs.  Even for v6.

I don't think so -  first, because IPv6 has more hooks for renumbering
than v4 (though more work is needed); and second, because a lot of folks 
will want to use IPv6 precisely because they need to avoid NAT breakage.

I'm not saying that there won't be any v6 NATs in the world (though we
should solidly and firmly declare them to be a protocol violation), 
but they should be few and far between.

Keith

---

From: "David R. Conrad" <[email-masked]>
Date: Wed, 14 Feb 2001 19:24:29 -0800

Keith,

At 10:02 PM 2/14/2001 -0500, Keith Moore wrote:
>than v4 (though more work is needed);

If end users are required to modify configuration files, you will see NAT 
so they don't have to.

>and second, because a lot of folks

Technogeeks, perhaps.  The vast majority of people on the Internet who are 
behind NATs most likely don't even know it.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Wed, 14 Feb 2001 22:44:47 -0500

> If end users are required to modify configuration files, you will see NAT

not if the NATs cause more pain than modifying the config files.
 
> behind NATs most likely don't even know it.

I presume that "technogeeks" includes networking professionals who can't
make their B2B applications work reliably over NATs?

there are two major classes of NAT users: (1) home users of "internet
connection sharing"  and (2) businesses using NATs to connect private
networks to the Internet and to one another.  both groups are generally
aware that the NATs exist, though the home users might not use the term
NAT to describe them and might not be as well versed in how they function.
it's hardly surprising that professional network administrators are more 
likely than the average home user to understand the limitations of NATs, 
and the home user is often less demanding - the casual home user who just 
wants to be able to browse the web at the same time as the kids might never
notice the difference.  but overall, both kinds of users are learning that 
the presence of a NAT causes some things to break, just as people once had 
to learn that rewriting of email addresses across gateways caused things 
to break.

a significant percentage of the folks who will drive v6 deployment will 
be those who have learned about those problems the hard way and are in 
need of a real solution. they won't be fooled again.

Keith

---

From: "Eliot Lear" <[email-masked]>
Date: Wed, 14 Feb 2001 20:42:57 -0800

Dave,

> behind NATs most likely don't even know it.

With all the discussion of Napster and so-called "peer to peer" networking,
I think NATs are going to become far more visible to users as these
applications grow in popularity.  Today, you can use something like Gnutella
if at least one party is not behind a NAT.

---

From: John Kristoff <[email-masked]>
Date: Thu, 15 Feb 2001 04:44:46 -0600

[...]

Keith,

It has been my experience that many of the current network admins
today believe NAT is the de facto way of connecting to the Internet.
In fact, in one of the network classes I teach, it takes a lot of
convincing on my part to show that NAT offers them very little security.
Most net admins today have only seen a world through NAT eyes so they
don't see the benefits of not having it.

If you want people to live in a world without NAT, I think you have
to have the killer application that simply will not function properly
with it.  This is much more difficult than it sounds.  As hard as
people like the IETF try, many new network protocols will continue
to fail if 1) legacy applications are not supported or 2) killer
applications are not available to drive the demand.

John

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 15 Feb 2001 06:54:26 -0500

David,

> that issue is addressed, there will be NATs.  Even for v6.

Odd. Every time I renumbered some site (hq.af.mil and sundry other sites
sharing similar characteristics), there was neither a NAT prior to, nor
subsequent to, the renumbering.

I suggest that renumbering pre-existed, and did not motivate, NATtage of
the NET.

Eric

---

From: "Melinda Shore" <[email-masked]>
Date: Thu, 15 Feb 2001 07:31:38 -0500

> the NAT problem - true or not true?

Well, it won't fix the NAT problem in scenarios
where v6 is not deployed.  But aside from the
other answers you've received so far, I've also
heard several people mention the need to support
something they call "address policy domains."
I don't understand why they need it and I don't
understand why an address policy domain couldn't
be described as, say, 209.4.89.208/28 and I don't
understand why it would *require* NAT, but it
is something I've heard on several occasions.

Melinda

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 Feb 2001 07:01:21 -0600

It's our collective job to ensure that IPv6 doesn't
leave any of the motivations to do NAT intact. The
"hiding" motivation (aka address policy domains)
is bogus anyway, and has never been a valid reason for 
doing IPv4 NAT, so it's particularly hard to combat.

  Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2001 05:16:51 -0800

> leave any of the motivations to do NAT intact.

i suggest that, for most of us, there are more useful and concrete major
direct goals of ipv6 than anti-nat religion.

randy

---

From: V Guruprasad <[email-masked]>
Date: Thu, 15 Feb 2001 08:42:39 -0500

Eliot,

> if at least one party is not behind a NAT.

With the addressless overlay architecture, you don't need any party to be
outside the firewalls. So the premise is incorrect. I'm keeping relatively
quiet because I'm busy implementing a prototype system myself, and hope to
demo it within this semester (honto ni) :-)

(Please read my soon-to-be-published revised paper, which Carpenter says
is much clearer than my I-D, temporarily housed at
	http://affine.watson.ibm.com/tmp/ - see Annals
- unlike the Triad, this one's been peer-reviewed and published twice,
plus almost all IP protocols would work, not just TCP.)

regards,
prasad.

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Feb 2001 09:42:44 -0500

> don't see the benefits of not having it.

As I've seen a lot of this kind of thinking even in IETF, I have no 
trouble at all believing it exists elsewhere.

But people can learn over time, even without a killer app.    Of course 
the problem with NAT is that it inhibits the spread of killer apps - 
people will never see useful new applications that could run without 
NATs because NATs prevent them from having a chance to try them out. 
For me, the entire motiviation behind 6to4 was to give people a way to 
deploy new kinds of apps without first having to upgrade the infrastructure - 
the biggest hurdle being to get rid of NATs.

> applications are not available to drive the demand.

My goals are more modest than that.  I accept that NAT will be a fixture
in IPv4 forever, and that IPv4 will be used to support important legacy 
apps for a long time, maybe 20 more years.  But I'm trying to get folks 
in IETF to recognize the problems with NATs (you have to start somewhere),
I'm trying to get us to strongly discourage NATs in IPv6, and I'm trying
to get us to develop technically sound alternatives to the problems that
NATs purport to solve.

Keith

---

From: V Guruprasad <[email-masked]>
Date: Thu, 15 Feb 2001 09:50:21 -0500

On Thu, 2001.02.15, Lloyd Wood wrote:

> that webpage is still black on black.

The style file on http://affine.watson.ibm.com/tmp/ has been commented out,
since some versions of Mozilla (4.05 on SunOS 5.6??) appear to be broken.

-p.

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Feb 2001 10:01:54 -0500

> direct goals of ipv6 than anti-nat religion.

to the extent that anti-NAT is a religion it is because NAT is a religion - 
in the sense that it is accepted without question as good and necessary.  
for folks who have already accepted NATs as gospel, the only kind of argument 
that will get their attention is a religious one.  you have to start somewhere.

folks who understand how NATs directly obstruct some of those 'useful 
and concrete major direct goals', can stop thinking of "anti-nat" as 
a religion and start thinking of a NAT-free network as a sub-goal.

even so, those 'major and concrete direct goals' will differ from one
person to another.  my goal is to have an internet that is versatile 
enough to support a wide variety of applications - peer-to-peer
and multi-peer applications in particular.  others want to make money
by producing a particular kind of product.

many folks who have different 'major and concrete direct goals' might 
still have 'anti-nat' as a common sub-goal.

blind acceptance of anti-NAT is no more desirable than blind acceptance
of NAT.  especially in this community, people need to *understand* 
the implications of each choice.

Keith

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2001 07:47:23 -0800

> to the extent that anti-NAT is a religion it is because NAT is a religion

no, it's a market reality.  we may not like it, but we'd be fools to deny
it.

randy

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 15 Feb 2001 15:51:12 +0000 (GMT)

On Thu, 15 Feb 2001, V Guruprasad wrote:

> On Thu, 2001.02.15, Lloyd Wood wrote (in a private mail):
> 

Nothing to do with it.

After several months of having entirely too much faith in his own
assumptions, guruprasad has noticed and attempted to fix the
<bgcolor=0>.

L.

---

From: Lloyd Wood <[email-masked]>
Date: Thu, 15 Feb 2001 15:57:49 +0000 (GMT)

> to the extent that anti-NAT is a religion it is because NAT is a religion

the seeds of religion are always sown in the oppressed.

L.

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Feb 2001 11:02:25 -0500

> no, it's a market reality.  we may not like it, but we'd be fools to deny

I agree that one would be a fool to deny that NATs exist and are widely
deployed.  Indeed, there would be no need for an anti-NAT effort if this
were not the case - so the anti-NAT folks inherently accept this.

But NATs are a religion even beyond the reality of present-day deployment. 
Indeed, it's the tendency of people to make the leap from "market reality" 
to "this is the way things should be" or "things cannot possibly be any
different" that causes me the greatest concern.

Such views, I submit, are a form of religion.

Keith

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Feb 2001 09:19:03 -0800

This is apparently the most recent one;
  http://weblog.mercurycenter.com/ejournal/2001/02/14

  [...] 
  In that world, every client -- that is, every PC and other device
  connected to the Net -- should also be a server. Lots of people are
  working on this, but a Menlo Park startup called KnowNow has
  figured out something that just might set off a new Net revolution.

  I didn't know this before today, but it turns out that a Web
  browser can hold open the connection to the server. Normally, a
  browser sends a request for information, which is delivered by the
  server. The connection ends.

  KnowNow holds the connection open. Then it adds some JavaScript
  and, voila, you have a mini-server inside the browser. You're not
  necessarily using lots of bandwidth, but you are pretending, in
  effect, that you're downloading a very, very long document while
  the browser keeps communicating with the server.

I wonder how/if they deal with proxies, in terms of connection
handling and identifying the client... 

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

---

From: [email-masked]
Date: Thu, 15 Feb 2001 12:39:11 -0500

>   necessarily using lots of bandwidth, but you are pretending, in

Nothing new here that wasn't already available the instant browsers
started supporting Java.  And considering the contrasting security
models of Java and Javascript, and the track records so far, this looks
like a giant step backwards....
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 15 Feb 2001 10:15:16 -0800

>direct goals of ipv6 than anti-nat religion.

And in fact, the anti-NAT religion hurts deployment of IPv6
because it is hard to get customers to throw away things
they have already bought. 

I would also suggest that the rapidity at which NAT is
being deployed for IPv4 suggests that we need to think about 
how to deploy IPv6 in an environment where IPv4 NATs are prevalent. 
Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather
it will augment them.

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2001 10:18:52 -0800

> Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather

and, if we can make v6 very attractive (left as exercise to student) then
its success may relieve some perceived need for nats.  but there are far
more useful goals to achieve by making it attractive and deployed.  and we
should focus on them, not the anti-nat obsession.  

[ unless, of course, we think that there is enough left of our foot to
  keep shooting at it. ]

randy

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Feb 2001 15:17:56 -0500

> they have already bought. 

When it is necessary to couch arguments in strong terms, subtleties
inevitably get lost.    Nobody is arguing that customers will simply
throw away NATs.  On the other hand, there are lots of paths being 
proposed (including proposals by NAT proponents) that require adding 
some functionality to what is now a NAT box.

anyway, what's the half-life of a piece of network equipment?  2-3 years?
existing NATs are going to be discarded, or at least upgraded, within a short
time anyway.

NATs are more entrenched in people's minds than they are in reality. 

> how to deploy IPv6 in an environment where IPv4 NATs are prevalent. 

it's being worked on.  watch the I-D directory.

> Thus, it is unlikely that IPv6 will displace IPv4 NATs; tather

agreed.

Keith

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 15 Feb 2001 12:39:15 -0800

Keith,

>not if the NATs cause more pain than modifying the config files.

True.  However, a company that produces a NAT that is more painful to 
use/operate than modifying config files will not likely be in business long.

>make their B2B applications work reliably over NATs?

Given the penetration of NAT, particularly in the business world, I suspect 
B2B applications that do not work with NAT will not exist too long.

Rgds,
-drc

---

From: Keith Moore <[email-masked]>
Date: Thu, 15 Feb 2001 15:43:26 -0500

> use/operate than modifying config files will not likely be in business long.

In many cases, NATs are already more painful than modifying config files...
it's just that the pain associated with using NATs comes later.  
 
> B2B applications that do not work with NAT will not exist too long.

hence the desire to tunnel everything over HTTP, which produces its own
pain.

Keith

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Feb 2001 13:15:27 -0800

> Given the penetration of NAT, particularly in the business world, I
> suspect B2B applications that do not work with NAT will not exist too
> long.

from the little i have seen, because b2b usually wants authentication,
authorization, and encryption, a lot of that stuff goes through gateways/
proxies/firewalls that seem to ship with nat turned on by default.  often
this is not needed <sigh>.

randy

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Thu, 15 Feb 2001 16:36:47 -0800 (GMT-0800)

> anyway, what's the half-life of a piece of network equipment?  2-3 years?

In the consumer space, it's probably the life of the customer's 
arrangement with the service provider. While turnover is high with dialup 
ISPs, it is presumably lower with xDSL and Cable modems. So I would be 
looking at more like 4-5 year lifetimes (roughly equal to a PC) without 
upgrading the NAT code load (which means that even if IPv6 native support 
were available, most customers would not do the upgrade). 

> existing NATs are going to be discarded, or at least upgraded, within a short

I wish that were true -- but in the consumer space, people just aren't 
very interested in futzing with network equipment unless their provider 
tells them to. So it is more realistic to assume that equipment stays in 
place for a substantial period.

> NATs are more entrenched in people's minds than they are in reality. 

Today, NAT penetration among consumers isn't very high because networked 
multi-PC homes are relatively rare. However, as multiple device homes 
proliferate along with home networking, I would expect the majority of 
consumer PCs to be behind NATs by 2005. Unless we start thinking now 
about the minimal NAT functionality necessary to deploy IPv6, and get 
this into shipping  NATs soon, we will face very substantial barriers to 
IPv6 adoption down the road. 

> It's being worked on. Watch the I-D directory. 

I'm watching ;)

---

From: John C Klensin <[email-masked]>
Date: Thu, 15 Feb 2001 21:41:18 -0500

--On Thursday, 15 February, 2001 16:36 -0800 "Bernard D. Aboba"
<[email-masked]> wrote:

> In the consumer space, it's probably the life of the
> customer's  arrangement with the service provider. While
> turnover is high with dialup  ISPs, it is presumably lower
> with xDSL and Cable modems. So I would be  looking at more
> like 4-5 year lifetimes (roughly equal to a PC) without 
> upgrading the NAT code load (which means that even if IPv6
> native support  were available, most customers would not do
> the upgrade). 

Although, FWIW, there is some, possibly growing, tendency to
treat the CPE xDSL and Cable modems as being on the ISP side of
the demarcation point.  That, of course, parallels the decisions
a number of ISPs made some time ago about customer-side edge
routers in order to improve the ISPs' ability to manage their
networks and provide improved service.  Then, to the extent that
those boxes can be reprogrammed (or flashed) from the ISP side,
making code changes would not require customers to change
equipment or to actively engage in upgrade activities.

>> existing NATs are going to be discarded, or at least
>> upgraded, within a short time anyway.
> 
> I wish that were true -- but in the consumer space, people
> just aren't  very interested in futzing with network equipment
> unless their provider  tells them to. So it is more realistic
> to assume that equipment stays in  place for a substantial
> period.

Modulo the above, I agree with this.  And "their provider tells
them to" is likely to be a rare event: I would imagine that at
least some providers would be concerned that some users would
respond by seeking providers who would issue such
aggravation-causing instructions less frequently.

> Today, NAT penetration among consumers isn't very high because
> networked  multi-PC homes are relatively rare. However, as
> multiple device homes  proliferate along with home networking,
> I would expect the majority of  consumer PCs to be behind NATs
> by 2005. 

We should not underestimate the complexity of the policy
interactions behind this one.  If an xDSL or cable provider says
"with your connection, you get enough IP addresses to set up a
reasonable house, you can get more if you need them, and we will
program the 'modem' will do the routing", then that provider's
customers are unlikely to rapidly increase the number of NATs.
If, by contrast, the provider says "you get one address; if you
think you need more, you are a commercial customer and we will
charge you 10 times as much", then almost every household with
two or more devices in it is going to end up behind a NAT.  And,
of course, the causes of those ISP statements recurse to the
ISP's provider, etc., until one gets to PI space, and then to
RIR policies and strategies for home networking.   

Worse, one can imagine xDSL or cable ISPs adopting
address-restrictive policies for management or economic reasons
completely unrelated to the availability of address space to
that ISP.

And IPv6 is, or is not, a solution depending precisely on those
choices of policies.

    john

---

From: "Kyle Lussier" <[email-masked]>
Date: Thu, 15 Feb 2001 23:57:27 -0500

> a fortune for 4 IP addresses vs 1 IP address (IPv6 or IPv4).

I think what we need is the ability to provide for NAT like 
functionality in a logical / theoretical sense in the IPv6
namespace, but without the "physical action of translation".
I.e., we need a logical construct that resides on IPv6 global
space that is mobile.

Why would you want this?  What problem is there to solve?

It was raised by a very sharp person a little while back on 
this list, specifically the ability to switch providers without
consequences.  We need a logical / functional mapping  or 
construct on top of IPv6 that allows a company to "move 
it's entire self around" in the IPv6 namespace.

What immediately comes to mind, is that IPv6 should have some
kind of "relative addressing" capability, where a company
can build a network on the relative space, but move it at
a whim if they switch providers, or for any other purpose.

My point / the difference in this suggestion from NATs is
that it should be logical and defined on IPv6 requiring
no actual translation.

In summary, IPv6 should support absolute addressing as well 
as relative addressing, and even indexed addressing as
primitive IPv6 operations.

Kyle Lussier
www.AutoNOC.com

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 15 Feb 2001 22:30:27 -0800

Eric,

>subsequent to, the renumbering.

If they are already using NAT, it is most likely they wouldn't need your 
services to renumber, no?

Rgds,
-drc

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Fri, 16 Feb 2001 07:43:26 -0500

David,

Ron Natalie and I renumbered hq.af.mil the week of the Loma Prieta quake.

List the NAT implementations deployed at the time.

The point you'll have made is that an-aide-to-renumbering NATs weren't.

If they are marketed now as such, happy, but not necessary, is the marketeer.

Eric

---

From: "Tony Hain" <[email-masked]>
Date: Fri, 16 Feb 2001 11:30:32 -0800

See RFC 2373  2.5.8 Local-Use IPv6 Unicast Addresses

-----Original Message-----
From: Kyle Lussier [mailto:[email-masked]]
Sent: Thursday, February 15, 2001 8:57 PM
To: Michael W. Condry
Cc: [email-masked]
Subject: IPv6 / NAT

Kyle Lussier
www.AutoNOC.com

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Feb 2001 10:04:06 -0600

Bernard,

Exactly. That is why 6to4 came out the way it did - it offers a way
for a NATted IPv4 site to introduce non-NATted IPv6 without losing
anything or throwing away anything.

There are RFCs explaining the issues with NAT technically and objectively.
I don't see why this generates comments about anti-NAT religion.
It's obvious when you read those RFCs and think about P2P computing
that NAT is a problem. If we don't avoid that problem in IPv6
we will have failed as engineers.

  Brian

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 18 Feb 2001 12:02:49 +0100

>IPv6 adoption down the road.

I think (as far as I can think :-) that the minimum functionality needed to 
deploy (say) 6to4 behind a NAT is the ability to configure it to pass all 
packets carrying 6to4 traffic to a separate box.

Other scenarios have other requirements.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]