Subject: Re: NATs *ARE* evil!

From: "J. Noel Chiappa" <[email-masked]>
Date: Thu, 14 Dec 2000 03:53:06 -0500

> From: [email-masked] (Sean Doran)

    > Even Noel Chiappa ... says that they are an architectural hack.

Let me expand on this a teensy bit. As currently used, NAT boxes are a severe
architectural ugliness.

Were we to i) incrementally deploy and start using new globally unique
namespace(s) [either a single one functioning much as IPv4 addresses
functioned originaly, or, as many of us think would be wise, two separate
ones, one to identify entities for end-end communication and another to give
topologically related names to communication devices], and then ii)
reinterpret the 32-bit fields as "local forwarding tags", then NAT boxes
would cease to be an architectural ugliness, and become merely engineering
ugliness.

"I trust I make myself obscure." (And a tip of the hatly hat to anyone who
recognizes the source of that quotation... :-)

	Noel

---

From: "Iliff, Tina" <[email-masked]>
Date: Thu, 14 Dec 2000 20:52:31 +0000

I could see valid cases for both reasons suggested below.  Another reason
from the customer point of view may be to lower costs.

Tina Iliff

-----Original Message-----
From: Tony Dal Santo [mailto:[email-masked]]
Sent: Thursday, December 14, 2000 1:54 PM
To: Dennis Glatting
Cc: Sean Doran; [email-masked]; [email-masked]
Subject: Re: NATs *ARE* evil!

Dennis Glatting wrote:

> On Thu, 14 Dec 2000, Sean Doran wrote:
>
> > So, why are people deploying them?
>
> Just to name two...
>
> 1) With NAT I ask for much smaller address spaces. Consequently, I don't
> have to disclose my network details, deployment is less likely to be
> delayed, and both my non-recurring and recurring cost is lower.
>
> 2) I don't have to renumber my entire enterprise should I change service
> providers, rather only the Internet interface devices.

What exactly is the state of the IPv4 "address pool"?  I realize there is
a PERCEIVED shortage, and this is usually the main motivation for NAT.
But is there a real shortage?  Are "reasonable" requests for addresses
being denied?

As for the renumbering hassle, if you have a small installation,
renumbering shouldn't be all that difficult (especially when using
DHCP).  For large installations, doesn't the organization own the
address pool, and take it with them when they change ISPs?  I know
this used to be the case.

If it isn't an address issue, is it a routing issue?  Is it that the
routing tables/protocols/hardware can't handle the large number of routes?
Are ISPs refusing to carry reasonable routes?  Seems to me if the entire
address space was broken up into subnets of 4096, there would be about 1
million routes.  What is the current size?  I think I remember seeing
numbers on the order of 50,000.

If there is a real shortage or routing problem, I understand the motivation
to use NAT.  There really wouldn't be a reasonable alternative.  But I have
yet to hear anyone claim that a reasonable request has been denied.  Based
on that, I tend to think most NAT installations are motiviated by other
(and in my opinion less valid) issues such as "security".

Tony Dal Santo

---

From: "Iliff, Tina" <[email-masked]>
Date: Fri, 15 Dec 2000 18:01:16 +0000

Well, let me correct myself.  It is more along the lines of firewall
security being broken in the sense of all firewalls would have to be open to
entire networks instead of limiting individual hosts.  IP would be broken in
the sense of routers not being able to distinguish which route to choose in
the case of multiple hosts having the same IP address but they are located
behind different firewalls, routers, etc in different enterprises.

Tina Iliff

-----Original Message-----
From: Iliff, Tina 
Sent: Friday, December 15, 2000 11:48 AM
To: 'Dave Robinson'; Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

Yes!  TCP breaks due to the fact that "true" source/destination sockets
cannot be defined.  The destination would not know where to send a response
except in the case where DNS is used...unless I need to do more reading

Tina Iliff

-----Original Message-----
From: Dave Robinson [mailto:[email-masked]]
Sent: Friday, December 15, 2000 11:11 AM
To: Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

What's the problem with locally significant addresses?  Having thousands of
10 networks will never present a problem unless those networks at some point
would like to talk to each other.  Is that where this whole discussion is
going (or coming from) - that ultimately the more NAT'ing we do, the more
headaches we're creating for ourselves en route to true global connectivity?

Dave

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, December 15, 2000 10:56 AM
To: Dave Robinson
Cc: Keith Moore; M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: Re: NATs *ARE* evil! 

because in a NATted network the same addresses are used in different
parts of the network.  addresses are meaningless.

---

From: "David Higginbotham" <[email-masked]>
Date: Fri, 15 Dec 2000 13:17:49 -0500

Don't get me wrong, NAT is an odd booger to be sure, personally I think it
is another $BIG_SOFTWARE_COMPANY conspiracy ;-) But... they do not have the
same identity, when NAT occurs the device then bears a globally unique IP
address at least to all those with whom there may be a conflicting address
and those are the only ones that count. yes no maybe? It does not matter
whether you call the street my house is on Maple street or 4th street or
four streets down from main street as long as the Post Office (read NAT box)
knows what you mean
happy friday and merry holidays,
David H

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 15, 2000 12:22 PM
To: Scott Brim
Cc: Keith Moore; Dave Robinson; M Dev; Sean Doran; [email-masked];
[email-masked]

On Fri, 15 Dec 2000 08:54:36 PST, Scott Brim said:
> How much meaning does "Keith Moore" have?  Somehow we have a planet
with
> billions of people on it and those who need to still manage to find
the
> appropriate "Keith Moore".  How do they do that?  Are there any
lessons
> to be learned?

The lesson to be learned is that we say "The Keith Moore that works at
UTK".

In fact, there's a word for when two people use the same exact
identifier -
it's called "identity theft" and usually makes life very difficult for
all
concerned - for many of the same reasons that 2 hosts with the same IP
address don't play nice.
--
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Chris Millikin <[email-masked]>
Date: Fri, 15 Dec 2000 10:35:15 -0800

It's already happening.  Try running IPSec from one 10 network to another 10
network.  Much pain.

-C

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, December 15, 2000 9:24 AM
To: Dave Robinson
Cc: Keith Moore; M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: Re: NATs *ARE* evil! 

> would like to talk to each other.  

right.  if net 10 networks stay completely isolated from one another,
then there's no problem.  the problem only exists when people want to
tie those networks together. but it's inevitable that the vast majority 
of private networks *will* want to communicate with the public Internet
in ways that NAT does not facilitate.

> Is that where this whole discussion is

in a nutshell, yes.

Keith

---

From: Chris Millikin <[email-masked]>
Date: Fri, 15 Dec 2000 10:50:07 -0800

Well, in this case a device that is doing NAT (properly anyway)would replace
the ip and socket headers, much the way each router replaces physical
addresses.

-Chris Millikin

-----Original Message-----
From: Iliff, Tina [mailto:[email-masked]]
Sent: Friday, December 15, 2000 9:48 AM
To: 'Dave Robinson'; Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

Tina Iliff

-----Original Message-----
From: Dave Robinson [mailto:[email-masked]]
Sent: Friday, December 15, 2000 11:11 AM
To: Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

Dave

---

From: "David Higginbotham" <[email-masked]>
Date: Fri, 15 Dec 2000 14:11:45 -0500

RFC 2993 Architectural Implications of NAT's ?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, December 15, 2000 12:55 PM
To: Dave Robinson
Cc: [email-masked]
Subject: Re: NATs *ARE* evil! 

> What's the problem with locally significant addresses?  Having
thousands of

Hmm.. this from a guy posting from endtoend.com?  I'm not sure if the
right word is "ironic" or "sarcastic".  In any case, didn't we just
release an RFC detailing in excruciating detail?
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 15 Dec 2000 14:34:40 -0500

>> the problems with NAT are not generally due to implementation. they
    >> are inherent in the very idea of NAT, which destroys the global
    >> Internet address space. 

    > From: Dave Robinson <[email-masked]>

    > How does the idea of NAT destroy the global Internet address space?

Ah, Keith was using a little verbal shorthand here. He meant "NAT removes the
global *uniqueness* of NAT'd Internet addresses". Similarly, when he said:

    > addresses are meaningless.

he really meant "NAT'd addresses are no longer capable of uniquely globally
identifying people". NAT'd addresses do still have *some* meaning, of course,
it's just a more complex and restricted meaning than they used to.

<This message brought to you by the Society for More Accurate Technical
Terminology. :->

	Noel

---

From: Chris Millikin <[email-masked]>
Date: Fri, 15 Dec 2000 12:20:41 -0800

Point taken.  Rather than reiterate my point I will refer to the following
excerpt from RFC 2993:

"
   -  NATs enable casual use of private addresses.  These uncoordinated
      addresses are subject to collisions when companies using these
      addresses merge or want to directly interconnect using VPNs.
"

This is becoming a major drawback to NAT.

-Chris

-----Original Message-----
From: Matt Holdrege [mailto:[email-masked]]
Sent: Friday, December 15, 2000 10:19 AM
To: [email-masked]
Subject: Re: NATs *ARE* evil!

Folks should read and *refer* to the NAT WG documents before commenting. An 
awful lot of work was put into the content and wording of these documents.

RFC 2663
draft-ietf-nat-protocol-complications-06.txt
&
RFC 2993

---

From: Kevin Farley <[email-masked]>
Date: Fri, 15 Dec 2000 15:12:45 -0800 (PST)

> parts of the network.  addresses are meaningless.

So what? Why is this the big problem?

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - 35mm Quality Prints, Now Get 15 Free!
http://photos.yahoo.com/

---

From: Chris Millikin <[email-masked]>
Date: Fri, 15 Dec 2000 10:35:15 -0800

-C

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Friday, December 15, 2000 9:24 AM
To: Dave Robinson
Cc: Keith Moore; M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: Re: NATs *ARE* evil! 

in a nutshell, yes.

Keith

---

From: Chris Millikin <[email-masked]>
Date: Fri, 15 Dec 2000 10:50:07 -0800

-Chris Millikin

-----Original Message-----
From: Iliff, Tina [mailto:[email-masked]]
Sent: Friday, December 15, 2000 9:48 AM
To: 'Dave Robinson'; Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

Tina Iliff

-----Original Message-----
From: Dave Robinson [mailto:[email-masked]]
Sent: Friday, December 15, 2000 11:11 AM
To: Keith Moore
Cc: M Dev; Sean Doran; [email-masked]; [email-masked]
Subject: RE: NATs *ARE* evil!

Dave

---

From: [email-masked] (Sean Doran)
Date: Sun, 17 Dec 2000 22:05:40 +0100 (CET)

Keith Moore writes:

| if you try to build a global network out of limited-scope addresses
| you eventually end up reinventing IP at a higher layer.

Correct, that's (some of) the point of CATNIP (RFC 1707): you construct
a network layer out of a virtual superset of the component internets'
address spaces.   Simple translations can avoid burning huge numbers
of bits in the "CATNIP" (the super-internet address space) as well
as providing a host-to-network interface, a network-to-super-network 
interface, and so forth.   1707 itself is simply an example of one
of many possible CATNIPs that can coexist simultaneously in different
parts of a global Internet.

The important thing for the flexibility to handle multiple simultaneous
disjoint network layer protocols is a session layerish "who"
namespace disjoint from the various routing namespaces of various
scopes, yet which in any scope can be used to look up a locally-relevant
hni/nsni/nni "label", yet is used end-to-end for demuxing and other
purposes that require the mutual identification of endpoints.

IPv6 makes a perfectly reasonable host-to-network interface,
as many people have indicated based on experiences posted to this
list.   It would make a better one if it separated "who" from "where".
If it does so sensibly, it could even make a half-decent in-network
protocol, although more importantly, it would readily coexist
with better-tuned network layers within a super-Internet.

	Sean.

---

From: [email-masked] (Sean Doran)
Date: Mon, 18 Dec 2000 13:33:46 +0100 (CET)

Keith Moore writes:

| but I'm fairly convinced that we are *far* better off with a global
| name space for network attachment points, which are exposed and
| visible to hosts and applications, than we are with only locally
| scoped addresses visible to hosts and applications

Out of curiosity, do you (as a hosts and applications person)
really care what is in use in the network(s) between
the network attachment points in question, if the edges
of the network all have the properties in your lines above?

	Sean.

---

From: Kevin Farley <[email-masked]>
Date: Mon, 18 Dec 2000 08:09:40 -0800 (PST)

> of the network all have the properties in your lines above?

You know, concerns over global name spaces and architectural purity are
valid to the engineer/operator. But to Joe User who just got his first
cable modem and got rid of AOL, he just wants to connect his computer
to the Internet. Then he wants to share that connection with his kids'
computer and their $50 e-bay printer server.

That's why so many of the little NAT gadgets are sold. Because Joe User
doesn't want to shell out extra bucks for more IP addresses and Joe
User needs simplicity.

Also _most_ average users just want to browse the web, get their email,
download software, and maybe exchange music files.

It is up to the networking professionals to make sure Big Company X and
Big Company Y connect when and where they have to. But its up to Joe
User to manage his home network.

Lets try to at least make that simple for Mr. and Mrs. Joe User.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

---

From: "Tony Dal Santo" <[email-masked]>
Date: Mon, 18 Dec 2000 11:27:05 -0500

Perry E. Metzger wrote:

> They can't avoid it. They need to get their work done. They have no
> way of getting registered addresses. They're told to use NAT by
> organizations like ARIN, and so they do the only thing they can.

I have a hard time believing ARIN is telling people to use NAT, when
the customer intends these hosts to have "external visibility".  I
can believe ARIN would send you to an ISP for small address blocks.
I can also believe companies don't want to pay the fees, and instead use
NAT to reduce the cost.

If ARIN is indeed refusing requests, on what basis are requests being
granted or refused?  By the use of the addresses (e.g. .org versus .com)?
Are these requests for "IPv4 ISP Registration" or "Individual IPv4 Address
Space Assignment to End Users"?  Perry, can you provide some more
details on what happened, or is this just what you were told by an ISP?

> Anyone notice how odd the growth charts look for the v4 allocation
> space? It is because we've already run out of addresses, folks -- or
> at least we're acting as though we have.

I think that is exactly it; we are acting as though we've run out of
addresses.  I've yet to hear of a significant effort to "reclaim"
unused addresses.  Recovering a single class A picks up 16 million
addresses.  Until such an effort occurs, I refuse to believe the
address space is truely exhausted.  And if the address space isn't
gone, I don't see any justification for refusing reasonable requests.

Now whether we can route all of these addresses is another (much
different) question.  And if people aren't bothering to request
addresses because of routing issues, fine.  Let's say that instead
of saying we are out of addresses.

Granted, when addresses really start getting tight, and if the next
generation technology isn't ready, I can see the justification for
refusing some requests.  But then I'd expect a well defined criteria
describing how these decisions are being made.

Tony

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 18 Dec 2000 11:48:13 EST

> Lets try to at least make that simple for Mr. and Mrs. Joe User.

Funny.  I believe that is why the cable companies are giving each user
5 or 6 IP addresses.  To make it easy so that the end user doesn't
need to know how to manage a NAT.

The answer is to give people the address space they need, not force
them to understand the subtle problems that are caused by the use of
NATs.

You have no idea how many students complain that they can't access
campus services due to the fact that Kerberos can't work through a
NAT.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

From: Geoff Huston <[email-masked]>
Date: Tue, 19 Dec 2000 07:35:24 +1100

At 12/18/00 01:07 PM -0500, Theodore Y. Ts'o wrote:
>The flaw in your argument is that you're assuming that the only reason
>to do NAT is because of the address space problem.   My concern is that
>it may turn out that some transport/routing people may conclude that we
>may also need to do NAT to solve the routing problem.   In which case,
>we're back to where we started.
>
>I'd feel a lot better if we could get key routing/transport people to
>sign some contract in blood stating that the IPV6 address is guaranteed
>to be invariant, and that any attempt to design boxes which muck with
>the IPV6 address in transit is architecturally out of bounds.  That may
>seem to you to be obviously true, but I 10 years ago we assumed the same
>would be true for IPV4 addresses.

I'm not sure that this is possible - part of the characteristics of today's 
Internet is that its is flattening out. The concept of hierarchical 
connectivity with 'upstreams' and 'downstreams' is one which appears to 
have relied on a high marginal cost of communications services. Now as I 
understand the current deployment plan there are TLAs and sub TLAs, and an 
apparent hierarchical view of the world again.

Imagine, for a second, what the topology of the Internet would be if 
communications services were free. Now turn up the unit cost knob an little 
and do the same thought experiment.

Part of the issue we faced in the Big Internet discussions, and part of the 
issue we face now is the semantics of the address and the level to which 
these semantics are overloaded. Is an address an identification of 
identity? A key to absolute location? A key to relative location? An 
encoding of the local topology? My concern, and the reason why I'm chiming 
on Ted's signing blood proposal is that in looking at the structure of V6 
addresses, at least the structure of the immediate deployment 1/4 or so of 
the addresses, we appear to have adopted an approach which is not far 
removed from the provider address hierarchy structure of V4 today. My 
lurking concern is that it is not working in the V4 routing system given 
the large percentage of table entries which are more specific 
advertisements of aggregate announcments (approx 40%) and it won't work for 
V6 either (using the term 'work' very loosely in terms of being able to 
route accurately, efficiently and with a clear scaling property).

It appears that the intended address structure and deployment structure 
appear to be at variance, and when that happens the temptation to alter the 
address in flight to suit each local region's environment may well be 
overwhelming. So I'd prefer to keep my blood to myself, thanks as its a 
contract I suspect we'll break within the operations environment. (and no I 
don't think that this would be a clever move, and yes, we will regret it 
afterwards.)

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 19 Dec 2000 00:48:34 -0500

> From: Geoff Huston <[email-masked]>

    > part of the characteristics of today's Internet is that its is
    > flattening out. The concept of hierarchical connectivity with
    > 'upstreams' and 'downstreams' ... as I understand the current
    > deployment plan there are TLAs and sub TLAs, and an apparent
    > hierarchical view of the world again.
 
I'm not quite sure if this is what Ted was referring to - and we have indeed
wandered a bit. Your point is an important one, though - but the answer takes
us even further afield, into routing theory. (Briefly!)

There is a great misconception, in the IETF as a whole, that hierarchical
location-names mean that either i) topological connections have to be
hierarchical, or ii) paths have to be hierarchical. Both suppositions are
absolutely, completely, untrue.

As to the first, if you will consult the classic paper on hierarchical
routing:

  Leonard Kleinrock, Farouk Kamoun; "Hierarchical Routing for Large
    Networks: Performance Evaluation and Optimization"; Computer Networks 1
    (1977); North-Holland Publishing Co.; pp. 155-174.

you will see that their work utilizes a random graph (that's a technical
definition, not a judgemental term :-), so that disposes of the first one. It
does use strictly hierarchical routing (i.e. their abstraction naming
boundaries are congruent with their abstraction action boundaries), but even
so it's worth noting their conclusion:

  "As regards the network path length, we were able to place an upper bound
  on its increase due to the introduction of hierarchical routing ... in the
  limit of very large networks, enormous table [size] reductions may be
  achieved with essentially no increase in network path lengths"

Use of non-hierarchical routing with hierarchical location-names is a complex
topic, one I can't explore here because it's tied in with all sorts of hairy
conflicting optimization (overhead, path length, etc) questions. However, it
is easy to provide non-hierarchical routing, even when the naming system you
are using is hierarchical.

    > part of the issue we face now is the semantics of the address ... Is an
    > address an identification of identity? A key to absolute location? A
    > key to relative location? An encoding of the local topology?

There are interesting questions, and ones that unfortunately have not been
previously settled in a consistent way across the community.

(I would say more about the fundamental technical issues, in particular what
technical tasks we ought to be using "place-names" for, but this probably
isn't the right time/place.)

    > in looking at the structure of V6 addresses ... we appear to have
    > adopted an approach which is not far removed from the provider address
    > hierarchy structure of V4 today.

From my point of view, the problem is not with the hierarchical nature of the
IPv6 address (since something like a hierarchy exists in every large-scale
routing system I've ever seen), but rather with the point you just raised -
just what it is that those things name, and how they name them.

    > My lurking concern is that it is not working in the V4 routing system
    > given the large percentage of table entries which are more specific
    > advertisements of aggregate announcments (approx 40%) and it won't work
    > for V6 either

The problem you're touching on, of multi-homing, is basically not a problem
with the addressing. It is a problem of i) the overall system architecture,
and ii) the architecture of the routing system.

It's a problem with the overall system architecture because providing the
benefits of multi-homing by imposing the cost of supporting it *entirely* on
the routing system - which is the way we are supporting multi-homing now -
may not be the way to go. Multi-homing is a complex topic, but I do think
there are other mechanisms which might be more cost-effective *in some
circumstances* than shoving the whole job off on the routing (e.g. use of
multiple addresses - but note that these addresses are still hierarchical).

(And may I take a moment to point out that if we were charging for routes,
the costs of having the routing "do it all" would be more apparent, and there
would be more incentive to explore other mechanisms.)

It's a problem with the routing architecture because in many cases, one
needn't expand to a global scope for the advertisement of a multi-homed site,
but the routing system as currently architected has no tools to help us with
either i) determing, or ii) setting scopes. All we have is either i) purely
local, or ii) global.

    > appear to be at variance, and when that happens the temptation to alter
    > the address in flight to suit each local region's environment may well
    > be overwhelming.

I can't conceive of any reason that the path selection would want to change
an address (at least, in the sense of "location-name") in flight.

That doesn't mean there aren't lots of other things that would. NAT is one,
but for anything (e.g. traffic aggregate based forwarding) that needs "bits
in the header" that aren't there now, mutating the address is an obvious
kludge.

	Noel

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 19 Dec 2000 12:57:44 -0500

In message <[email-masked]>, Mike Fi
sk writes:

>
>The marginal value I see in IPsec is that it is useful for protocols other
>than TCP.  For TCP applications, I confess that I don't see much value in
>IPsec (not that TLS has any particular merits, it just became more common
>first).
>

Why do I think I'm having this discussion for the Nth time?  IPsec has 
two other advantages:  it protects *all* transmissions without touching 
the applications, which would otherwise need to be converted one at a 
time; it also protects TCP against one-packet denial-of-service 
attacks.  All I have to do to tear down a TLS session is send one 
packet with the correct port and sequence numbers.  TLS will notice 
that the packet doesn't belong, and will tear down the session.  With 
IPsec, TCP will never even see the garbage packet, since it will fail 
the integrity check before it gets to that layer.

		--Steve Bellovin

---

From: Matt Holdrege <[email-masked]>
Date: Thu, 21 Dec 2000 10:30:14 -0800

>> Excellent.  We've agreed that IPv6's problems are a subset of IPv4's.

From: Randy Bush <[email-masked]>
 >unfortunately, we have not shown it is a proper subset.  e.g. the larger
 >address space may exacerbate issues already causing problems in v4, such as
 >the increasing number of routes.

 >and i am not 'taunting' but trying to see how the hell we can solve some of
 >the serious problems we have today and not take them with us to the v6 land
 >of milk and honey, e.g. the multi6 discussion.

 >if we don't get much smarter quickly, we'll just be making the same mess on
 >a larger (in one dimension) scale.  we need to take a very serious look at
 >8+8 again.  we need to be open to other good ideas.

You are absolutely right Randy. Unfortunately the coda for the IETF these 
days is "Rough Consensus and Shipping Code". One of the biggest problems 
these days is that we have people demanding backwards compatibility with 
things that don't really exist yet in a meaningful way. We are becoming 
more and more like the ITU these days.

Several WG's such as SIP have engineers complaining about tiny little 
changes in a specification that would affect *their* code. So we can't fix 
a known problem in the spec even though hardly anyone is using this stuff yet.

---

From: V Guruprasad <[email-masked]>
Date: Fri, 22 Dec 2000 08:21:14 -0500

{I had written:}
> | from label switching, so what I'm suggesting is that we take the bull by
> | the horns once and for all and run MPLS over IP instead of under it... 
> 
> an mplsd-like tag fits neatly in the first half of an ipvsux destination 
> address, although there are other places in the vsux header you can put 
> tag bits if you're inclined to do so for stacking reasons or whatnot.
> ...
> this has all the same problems of NAT where there is no end-to-end
> namespace that is not TOPOLOGICAL in nature separate from but convertible
> between a namespace populated with globally unique IDENTITY names.
> (where that namespace can mean single hosts or service locations or whatever,
> but not two or more of these things simultaneously! overloading bad.)
> 
>         Sean.

The NATty problems also go away when the theme is completed with the
globally unique etc. namespace, with a different topology (but yet
a spanning tree by definition), and the conversion is formally handled
by automatic translation using a context-free attribute grammar distributed
en route, so that the label switched path is synthesised e2e without
having to return addresses to the client application. I.e. no "overloading".

The final architecture one then gets would be that described in
	draft-guruprasad-addressless-internet-00.txt

-p.