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

From: Thomas Narten <[email-masked]>
Date: Wed, 01 Dec 1999 07:31:28 -0500

John,

> You are absolutely right.  Time should be spent developing "good
> algorithms" which is common "good architecture".  What NAT does is just
> another form of the same thing that X.25, ATM, and MPLS do with different
> identifiers.  It is not bad algorithm there nor bad architecture.

This is the second time you've said this, the first time I just
cringed.

> I would tend to agree.  As I have said elsewhere, NATs in and of themselves
> do nothing wrong.  They are doing things within the Internet/Network Layer
> that are perfectly legal.  (In essence, they are treating the network
> address in much the same way that X.25, ATM, and MPLS treat their
> addresses.)

I find this assertion to be amazing. It's perfectly legal for a device
to modify any field in the IP header if it so desires? Do you also
agree that it's legal to modify the IP ident field (and potentially
break fragmentation?) What about the length field, or flags field,
etc., etc.??

Also, NATs have to modify the TCP/UDP checksum, i.e., look inside the
upper layer protocol it is carrying and modify the payload. This is
also not "bad architecture"?

> The problem is that applications lacking an "application address
> space" are using the Network address space inappropriately.

IMO, this is a widespread oversimplification of the situation.

If you want to point fingers, TCP is also broken from the perspective
of NAT, because transport layer addresses are formed from both IP
addresses and port numbers. It's not just applications sending
addresses in payloads that "are broken", it's a key aspect of the
basic TCP (and UDP) design.

Sure, there are folks that say "fix TCP". But this is also naive.
There is a good reason why TCP is designed this way. Having transport
addresses be completely independent of the IP address in the IP header
requires having some way of mapping from one name space (e.g., the TCP
transport identifier of a service one wants to communicate with) to
the IP address (so that the TCP header can be put into an IP packet
and sent to the actual destination).

Although folks have talked about doing something like this for years,
it has not been done (i.e., where is a document showing how it can be
done?) and folks have argued endlessly about whether building such a
system is feasible or really solves the problem as opposed to just
creating a new (hard) problem elsewhere that then needs solving.
 
Thomas

---

From: Bob Braden <[email-masked]>
Date: Wed, 1 Dec 1999 09:12:01 -0800 (PST)

*> > 
  *> > 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.
  *> 
  *> Unfortunately the existing Internet is no longer an implementaion
  *> of the existing Internet architecture. That's why we have a problem.
  *> 
  *>   Brian
  *> 
Brian,

I don't disagree with you.  I was only trying to counter what seemed
to me a bogus appeal to the abstract principles of the Internet
architecture.

Bob

---

From: Bob Braden <[email-masked]>
Date: Wed, 1 Dec 1999 09:12:01 -0800 (PST)

*> > 

Bob

---

From: "Tony Dal Santo" <[email-masked]>
Date: Wed, 1 Dec 1999 15:17:16 -0500

John Day wrote:

> Cmon, surely you can come up with a better counterargument than that!  ;-))
> I certainly could.  If it is architecturally acceptable for those protocols
> to rewrite the address field at every hop, why shouldn't it be for IP?  How
> does it differ?  Basically a NAT is doing what an ATM switch does. How does
> an MPLS tag differ?

Here is the difference between NAT and the other things you mention.
The only changes to the IP header and encapsulated data should be the
TTL and fragmentation information.  Granted ATM chops the packet into
small cells, but when its put back together the packet looks the same.  This
cannot be said of NAT.

>               But it would be a big step to solving the problem.  However,
> there are so many special cases now of people doing strange things with IP
> addresses that they shouldn't be doing that there may not be anyway out of
> the problem.

Ok, here is where the rubber meets the road.  What is "the problem"?
My guess is that you think the protocols/applications are broke, or
architecturally unsound.  I think the problem is that NAT became
"necessary".

> I am well aware of the issues, but I did want to push back on people who
> see no problem with applications exchanging IP-addresses.

Is there a constraint/expectation that these applications/protocols run on
something other than IP?  Is it a requirement that when (if) the switch
is made to IPv6, that all IPv4 applications will work over IPv6, and even
better yet work across an IPv4/IPv6 "converter"?

While these would all be nice things to have, are they design
requirements?  Is the goal to have a stackable streams-like system
where I can slide in/out or replace "modules" letting me (in theory)
run any application using any transport over any physical medium?

It's a nice idea, but certainly brings with it lots of complexity.
My personal opinion is that the IETF's goals essentially boil down
to "IP on everything".  Unfortunately, this means if IP changes,
everything much change with it.  Just as IP's predecessor is gone,
so would vanish old versions of IP.

This of course has its own problems, but I think identifies (at
least for some) the current mindset.  If the IETF has to identify
and specify the entire behavior from user interface to bit order
on the wire, their charter needs to be expanded.

Tony

---

From: "Tony Dal Santo" <[email-masked]>
Date: Wed, 1 Dec 1999 15:17:16 -0500

Tony

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 1 Dec 1999 16:12:06 -0500

Everyone, this conversation isn't really going to be very productive. The
people who like A aren't about to start liking B, and vice versa. (And then
there are the people who don't like either - but they aren't going to change
their minds either! :-) So discussion on this point is not going to be very
productive.
	
The various approaches to growing the Internet (IPv6, NAT's, etc) all have
costs and benefits - but each differing costs and benefits. In a system as
large as the Internet, it is to be expected that some people will evaluate
the costs and benefits, and decide that for their particular situation,
option A is to be preferred. Others will prefer option B.

In the end, if a single approach does become the predominant one, it will be
the market that decides (as individuals look at the costs and benefits in
their individual cases), not the IETF. The IETF can't do a lot to influence
this outcome - we don't have a police force, nor an army, so we can't stop
someone from using A, or force them to use B.

The IETF has always done much better at *designing* protocols than it has
done at *choosing* protocols. Let's stick to designing, and stop arguing
about which one to pick, eh?

	Noel

---

From: Ian King <[email-masked]>
Date: Thu, 2 Dec 1999 15:39:35 -0800

So what you're saying is that NAT doesn't scale well, at least from a
management perspective.  I'm not surprised.  Again, I would suggest that NAT
is not a silver bullet, but rather a useful "hack" in some circumstances.
The situation you describe appears to be demonstrative of its limitations.
(BTW, one time I forgot to change the NAT rules when I moved my sendmail
server on my four-machine network, and....)  :-) 

But then again, I would expect that a large corporation would see the need
to own a large address space, rather than attempting to "pseudo-expand" its
address space through the use of NAT.  (My company, with a fairly
substantial intranet, uses proxying as its internal solution.)  Maybe I
don't understand the usage you're describing, but the point I keep trying to
make is that NAT isn't evil; that doesn't mean it solves every problem, OR
that it should be re-engineered so that it does.  -- Ian 

-----Original Message-----
From: Perry E. Metzger [mailto:[email-masked]]
Sent: Thursday, December 02, 1999 2:54 PM
To: Ian King
Cc: 'Richard Shockey'; Keith Moore; [email-masked]
Subject: Re: IP network address assignments/allocations information?

Ian King <[email-masked]> writes:
> 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.

You aren't a large corporation trying to deal with huge numbers of
private customer connections running over IP. When you've been
awakened in the middle of the night every night for a week, because
the NAT rules to deal with the fact that you have several
intercommunicating networks all of which think they're 10.0.0.0/8 have
become so complex no human can really remember them all any more,
you'd experience what many of the rest of us feel week after week. The
lack in question is a lack of sleep.

Anyone out there who thinks NAT works well and is harmless is not
familiar with how the brave new world of pseudo-internetworking
works.

"Oh, no. When we moved the mail hub for the client access networks in
location A, it seems no one remembered to update the NAT rules for the
systems in location C. That's why the help desk has been inundated
for three days..."

Perry

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 3 Dec 1999 11:44:45 -0500

> From: "Perry E. Metzger" <[email-masked]>

    > When you've been awakened in the middle of the night every night for a
    > week, because the NAT rules to deal with the fact that you have several
    > intercommunicating networks all of which think they're 10.0.0.0/8
    > ... Anyone out there who thinks NAT works well and is harmless is not
    > familiar

Perry, I'm curious about the technical aspects of the problems you're seeing,
in particular:

  Are the problems you are seeing due to i) the need for NAT boxes to grope
  around in packets, ii) the fact that hosts don't have permanent, globally
  visible internetwork-level 'names', or iii) something else (e.g. complex
  configuration management)?

The reason I ask is twofold.

First, there is an alternative technology being proposed for local addresses
in IPv4, RSIP, which should avoid i), but still leaves us with ii) and iii).
So, to the extent the problems you are seeing are ii) and iii) we're still
kind of stuck, even if RSIP happens. To the extent that the problem is really
i), though, RSIP might alleviate the situation.

Second, when examining the transition technologies for deployment of the
proposed new internetwork layer, I've been pondering the problem of an
non-upgraded host trying to talk to an upgraded host with an address which is
only expressible in the new internetwork layer. The proposed transition
technologies I've examined (i.e. NAT-PT, AIIH, and SIIT) *all* seem to have
(at least as far as the IPv4 world is concerned) characteristic ii) - in that
as far as non-upgraded hosts are concerned, upgraded hosts using those
schemes don't have a permanent 'name' at the internetwork layer.

So I'd really be curious to know a little more about the "forest-level"
nature of the problems you're seeing out there - I think it will be very
insightful in considering a number of potential forward directions.

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 3 Dec 1999 12:46:23 -0500

> The situation right now is really horrible. People are pretending it
    > isn't, but the pretense really has to end. The End to End model isn't
    > just a "nice idea" -- its actually needed for people to manage and
    > maintain networks cost effectively. Its effectively dead a the moment,
    > and frankly, I'd like the internet back again, instead of this kludge
    > we're using instead these days.

Perry, one other thing I'm curious about (based on your messages in
particular, from this thread), and perhaps you can enlighten me.

While I'm not saying that NAT's are a Great Thing, I do wonder if people are
experiencing a bit of "grass is greener on the other side" syndrome here.
NAT's are in wide-spread use, and lots of people (e.g. you :-) are being
forced to struggle with their manifold downsides on a daily basis. In dealing
with this (and wishing they didn't have to deal with these problems :-), I
wonder if people are assuming (perhaps incorrectly) that the alternative is
relatively pain-free?

(My examination of some of the transition strategies indicates to me, as my
previous email alluded to, that perhaps they are going to suffer from many
of the same root causes that makes NAT painful too.)

So my question is: do you know of any site, one which has a lot of interaction
with the rest of the Internet, which has actually converted to the
alternative, for use on an ordinary daily basis, for the bulk of their
activity? (This is, after all, the stress level we're subjecting NAT boxes to,
these days.)

If so, it would be interesting to hear of their experience, so we can find
out to what degree the results of a conversion are any "greener".

	Noel

---

From: "Linscheid, Sven" <[email-masked]>
Date: Mon, 6 Dec 1999 08:59:56 +0100

First of All, sorry that I enter your discussions ;-)

Ian King <[email-masked]> writes:
>> address space through the use of NAT.

It's right Perry, everyone want to own a own adress Space that is protect
for
him, her or for the company. But It isn't quite good to expand the IP's to 
monsters of numbers.

I think the IETF has to think about a whole new method to cover that
problem.

> You are assuming they could get such a space. They can't. No one can
> if you aren't a provider. The registries will simply tell you to go
> off in the corner and use private address space instead.

If I think to real future (means in up to 5 - 10 years) so many Computers
and
other Hardware will connect to the Internet that also the method of
expanding
the IP - adress space wouldn't be enough. The organization of the IP -
Adress
coverage should be checked. 

Think about that.

At the moment the companys, the provider and the adress space organziations
handle the IP - Pool. But wouldn't be better to check the really needed 
adress spaces for a company or an provider, instat giving them A-class and 
so on number-spaces away? Such saying you aren't using this IP's now for
3 Month, sorry we'll have to give them away?

It is not possible that organizations or company block adress spaces and 
then don't use them. I know, the companys and the private People too, wanna
have secured adress spaces, but at the moment it seems that a kind of 
IP - grebing is started.

Well, is only a feeling and I also have no solution for that problem, but
also IPV6 wouldn't cover that. Is a kind of handling Problem!

> isn't, but the pretense really has to end.

I only could say YES! This situation is now really horrible.

> The End to End model isn't just a "nice idea" -- its actually needed
> for people to manage and maintain networks cost effectively. Its
> effectively dead a the moment, and frankly, I'd like the internet back
> again, instead of this kludge we're using instead these days.

*g* I also miss the beginng's of the internet, but at all. It's better 
today (some ways) ;-)

>Perry

Sven Linscheid
Senior Developer Dresder Bank Internet - Section Germany PC,CC
Hacking Test Section
Internet Knowledge Center
Windmuehlstreet 14
60316 Frankfurt / Main
Germany
+49(0)69 263 51512
[email-masked]

---

From: "Linscheid, Sven" <[email-masked]>
Date: Mon, 6 Dec 1999 08:59:56 +0100

Think about that.

Sven Linscheid

---

From: "Polinsky, Steven" <[email-masked]>
Date: Mon, 6 Dec 1999 14:07:19 -0500

>   configuration management)?

To me the biggest problem here, is the common situation such that companies
have separate (and necessary) Internet and Remote Access firewalls. RA
firewalls exist in multiple global locations within an enterprise.

Multiple instances of the same Private addresses would enter (or exit) the
enterprise network via Private lines from different companies if not for
careful configuration management across and negotiation between "NAT
Administrators", within the enterprise, and between enterprises. The most
difficult part is the negotiation with client/vendor site NAT Admins as to
who should NAT which addresses into which addresses. We often need to
negotiate between 3 RA connected companies. Not only is this painful, but
one can never sleep comfortably, knowing that a NAT Admin at a 3rd company
will not make a mistake and connect someone new at our NATed address. 

There are not enough Private Addresses to go around.

I would propose that an additional block of addreses be added to those
designated in RFC1918. That would be a big practical help.

Steven

Steven M. Polinsky
Vice President, Information Technology
Goldman, Sachs & Co.
180 Maiden Lane
New York, NY 10038
212-902-3669

---

From: "Polinsky, Steven" <[email-masked]>
Date: Mon, 6 Dec 1999 17:14:08 -0500

Clearly, many organizations do use Net 10, but at the majority of
organizations I've worked with, for Remote Access, people realize that 10 is
unique among Private Addresses in classfull space.  

If we'd have more Private space, particularly, in the classful Class C
space, many of us would put it to good use. Without it we'll continue to
struggle.

Steven

Steven M. Polinsky

-----Original Message-----
From: Perry E. Metzger [mailto:[email-masked]]
Sent: Monday, December 06, 1999 4:34 PM
To: Polinsky, Steven
Cc: J. Noel Chiappa; [email-masked]
Subject: Re: IP network address assignments/allocations information?

> designated in RFC1918. That would be a big practical help.

It won't help, I'm afraid. Most of the organizations I know of have
hardly exhausted network 10 -- they just all decide to start numbering
from the bottom. Adding another block of them won't fix the situation.

-- 
Perry Metzger		[email-masked]
--
"Ask not what your country can force other people to do for you..."

---

From: "Polinsky, Steven" <[email-masked]>
Date: Mon, 6 Dec 1999 17:14:08 -0500

Steven

Steven M. Polinsky

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 6 Dec 99 18:08:25 EST

> There are not enough Private Addresses to go around.

This sounds to me like more of an argument why private addresses
should be used on networks connected to public networks.  It is not
an argument for more private networks but for the move to IPv6 and
the banning of NATs.

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 6 Dec 99 18:08:25 EST

---

From: "Polinsky, Steven" <[email-masked]>
Date: Mon, 6 Dec 1999 18:20:15 -0500

I'm not advocating one technology over another. I am claiming that in the
IPV4/Private/Public/NAT world, a bigger pool of Private space would be a big
help to many organizations.

Steven

Steven M. Polinsky

---

From: Ian King <[email-masked]>
Date: Mon, 6 Dec 1999 22:22:51 -0800

Can we take this off the IETF list?  This sounds like a perfect argument for
the NAT list, rather than the general IETF list.  This has been going on for
days, and this single subject keeps overflowing my inbox....  -- Ian 

-----Original Message-----
From: Josh Duffek [mailto:[email-masked]]
Sent: Monday, December 06, 1999 4:05 PM
To: Josh Duffek; Polinsky, Steven; [email-masked]
Cc: 'Perry E. Metzger'; J. Noel Chiappa; [email-masked]
Subject: RE: IP network address assignments/allocations information?

Classles routing rather :)

Josh

> From: Josh Duffek [mailto:[email-masked]]
> Sent: Monday, December 06, 1999 5:44 PM
> To: Polinsky, Steven; [email-masked]
> In a perfect world with proper network design I would have to
> disagree with
> you.  I believe that properly subnetted the private address space
> allocated
> would be enough.  Classful routing and VLSM should take care of this
> problem.
>
> But in the real world, with not so great network design I have seen many
> cases where more space is needed.
>
> Josh
> [email-masked]
>
> > From: Polinsky, Steven [mailto:[email-masked]]
> > Sent: Monday, December 06, 1999 5:20 PM
> > To: [email-masked]'

---

From: Scott Bradner <[email-masked]>
Date: Tue, 7 Dec 1999 15:51:20 -0500 (EST)

> It is *astonishingly* expensive. It only seems cheap until you have to
> maintain it. And yes, I'm going by Actual Live Customer Experience In
> Actual Live Large Companies.

if it were easy to show this we would not be discussing the topic
I don't know many companies who decide to do "*astonishingly*
expensive" things if there are cheaper options

Scott

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 7 Dec 99 16:11:16 EST

> I've generally been of the opinion that NAT is a very workable solution
> for the small office and home network, and questionable for larger
> networks. Sounds like you're saying the same.

The New York City Board of Education is using NATs as a security
measure to keep their 1000+ schools off of the public network.
Teachers are reporting that the networks are unusable because of them.
Many of the educational benefits that the schools want to gain from
being connected to the internet are unaccessible because of the
limitations NATs place on the types of connections that may be made
(and accepted.)

The NYC BOE does not have the money or staff to figure out how to
properly configure and maintain these devices.  But they were put in
place most likely because they were presented to the high level admins
as an easy way of securing the network.

The teachers (as consumers of the technology) have chosen not to use 
the Internet in the classroom experience because they can't get the
same access from the classroom that they are able to receive from AOL
at home.

---

The use of NATs in home or small office environment must be voluntary
by the end user.  It is somewhat scary that an end user must now know
enough about NATs to ask their proposed ISP whether or not a NAT is
going to be used to allocate them an IP address.  And if so, be able
to instruct the ISP how it should be configured for them.  I forsee a
day when the use of NATs and the failure by ISPs to disclose their use
will result in lawsuits by Ralph Nadar and the Attorney General's
offices of several states for fraudulant advertising.

---

NATs are workable solutions for the home environment if and only if
they are implemented by knowledgeable people or are used by
individuals whose range of Internet access is severely limited.

---

From: Jeffrey Altman <[email-masked]>
Date: Tue, 7 Dec 99 16:11:16 EST

---

---

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Tue, 7 Dec 1999 16:22:31 -0500

> From: Daniel Senie <[email-masked]>

    > The counter argument is that for the Home Networking case, which is a
    > HUGE market, it is indeed cheap and easy to use. ... NAT can be used
    > for a variety of things. Perhaps we can agree that it's a good hammer
    > when the nail is a home network, and concentrate on what to do about
    > the large corporation issue.

This relates to a thought I've been having over the last couple of days,
which is that I recently read that the Internet usage numbers in many large
cities in the US (sorry, no idea about the rest of the world, and in any case
this point relates to ARIN only) is now at or over 50% of citizens - i.e. in
the US, the logistic growth curve for that group (which ought to be the
largest possible market segment) has started to tip over.

So my question is: I've been hearing that ARIN is the stingiest of the
registries when it comes to handing out IPv4 addresses - is there any valid
reason for this extreme parsimoniousness (particularly when the plan is to
move over to IPv6, so there ought to be no reason for extreme hoarding of
IPv4 addresses)?

Perhaps a little loosening of the address allocation tap at ARIN, when it
comes to allocating addresses for non-home use, could make life substantially
easier for the segment where some people are finding NAT making their life
difficult?

	Noel

---

From: Sean Doran <[email-masked]>
Date: Wed, 8 Dec 1999 00:29:15 +0100 (CET)

Perry Metzger announced:

| Actually, to a large extent, the "internet" as "transparent end to end
| catanet" *is* dead
  ^^^^^^^

What's a "transparent end to end catanet"?

Does that have anything to do with the networks with "hidden" 
infrastructure in the discussion on translating internet [sic]
addresses to local addresses starting towards the bottom of
page 5 of IEN 48?

	Sean.

- --
Sean Doran <[email-masked]>
Mike Padlipsky Fan Club

---

From: Sean Doran <[email-masked]>
Date: Wed, 8 Dec 1999 06:57:25 +0100 (CET)

| 1. if IPv6 allocation policies aren't a fair amount more liberal
|    than IPv4 ones in how much address space is doled out, they're
|    broken.  there's still a need to aggregate addresses for routing
|    purposes, but there's no need to be stingy about doling them out.

We are agreed that there is absolutely a need to aggregate
addresses for routing purposes, whether we are talking IPv4
or IPv6.

So, how many /20s are there in IPv6?

	Sean.

---

From: Ian King <[email-masked]>
Date: Wed, 8 Dec 1999 00:19:08 -0800

Will this never end...? 

If you want to be able to control individual lightbulbs in your house, how
about an IP <-> X10 gateway?  X10 (as an example, not because I have any
particular attachment to it) is a useful protocol for controlling devices
(usually with limited "intelligence") within a home; that's what it was
designed for.  Do you use SMTP to program your router?  Let's use
appropriate protocols at appropriate times and places.  

PDA?  Why can't I talk to my home machine?  I do it all the time (not with a
PDA, but with other devices), even though the machine is inside a NAT
"boundary".  Yes, it took a little configuration magic, but nothing as
complex as e.g. RSIP.  

Why is this about "controlling the household from the outside"?  I thought
this thread was about "big companies controlling large private address
spaces"?  Or end-to-end UDP for the latest version of Quake?  Or SNMP to
flush my toilet from McMurdo Sound?  This thread has wandered over a lot of
territory.  

NAT IS A HACK.  Is it a useful hack?  In some circumstances, yes.  I use it,
without a lot of attention on it; my wife uses this computer to browse the
Web and read email, and when I say NAT she reaches for the bug spray.  :-)  

Does NAT work at the ISP level?  Depends on what the ISP is selling.  I had
a lot of problems with ISPs who wanted to sell me a "black box" of Internet
connectivity -- I'm a geek, I know what I want, and some of them didn't want
to sell it to me (in large part because their sales reps didn't understand
what I was talking about).  Does an AOL user care about his place in the
address space hierarchy?  Likely not, nor does he "purchase" a right to
care.  Do I care?  Yes, and I pay for it, and I get it.  

Does NAT work for corporations?  Depends on what they are hoping to buy with
it.  A NAT client at Foo Corp can attempt to access resources across the
net; if Bar Industries is also using NAT, Bar's NAT must be configured to
direct the incoming requests.  But that can work just fine.  Multilevel NAT
(i.e. within an organization) is as prone to problems as multilevel
marketing; Just Say No.  

Corporations can use firewalling, internal network addressing, and proxies.
Microsoft does this, and I rarely experience a situation in which I cannot
do the "end to end"-ish thing I want to do.  (You can't do it from outside,
but that's why it's a firewall.)  

NAT IS A HACK.  Why is there so much effort going in to somehow either
"legitimizing" it, or demonizing it?  As I've said before, I use it because
my ISP is greedy and wants a lot of money for more than one IP address; I
think they assume I'm doing something "commercial".  (I also pay a premium
for my DSL connection because it's not the base "consumer" speed, and USWest
assumes it's "commercial".)  As a side-effect, it creates a level of
security; my "inside" machines are not directly on the Internet, and it
makes it harder for them to be compromised.  (Not impossible, but harder,
and there's nothing there that makes it worth it.)  That's why I use NAT.  

Is NAT right for you?  NAT IS A HACK.  Does it serve your purposes?  If so,
cool, go for it.  If you are a vendor to others, does it serve your
customers' purposes?  If not, and you are selling them something you can't
and don't provide, then you are a crook and legal process should be invoked
to deal with you.  

Does SMTP give you "end to end connectivity" to each email user you address?
No, they can be on completely disjunct machines, with incompatible (or no)
network capabilities.  (When you send me email, you are NOT sending it to
the machine where I read it, nor could you get here from there.)  There are
certainly some protocols that fail without "real" end-to-end connectivity.
There are many that do not.  

It is an invalid assumption that, as a class, devices won't be able to
communicate with your home devices because of a NAT -- in some cases it's
true, in others, false, in others, it requires a little more hacking.  NAT
IS A HACK.  Maybe a particular circumstance requires a little more hacking,
maybe it requires an ALG, or maybe it requires a redesign of its protocol to
allow for NAT.  Question: is what you get, worth the effort?  Long term?  

NAT IS A HACK.  Let's step back and focus on ways to fix the problems that
led people to think of NAT in the first place, rather than trying to
engineer NAT as a long-term solution to those problems.  Perhaps NAT will
remain as a solution for a certain, smaller class of problems -- cool.  If
NAT isn't solving your problems, DO SOMETHING ELSE.  But building a world on
NAT is building a world on a HACK.  

PS: my bathroom light is OFF.    

-----Original Message-----
From: Keith Moore [mailto:[email-masked]]
Sent: Tuesday, December 07, 1999 7:41 PM
To: Tripp Lilley
Cc: Keith Moore; Daniel Senie; Perry E. Metzger; Randy Bush; ietf
Subject: Re: IP network address assignments/allocations information? 

> Is this really the "right" model for that sort of interaction? Personally,
> my home network (in which every light bulb *will* be on the 'net within
> the year) is not something I want end-to-end connectivity to.

why not?

seems like if you want your light bulbs to be independently addressable
or pollable (can't wait for the SNMP lightbulb MIB!)
you want the ability to talk to them directly.  OTOH, if for the
specific case of light bulbs you want some sort of "light management
system", then maybe you want to talk to that light management system 
rather than to the individual light bulbs.

the point is, even though you might want some local resource managers
to mediate the use of light bulbs, whatever, that doesn't
mean that you want to block all outside connectivity to every device
in your home.  if you have to have an ALG for everything you want
to control from outside that is going to impose a serious barrier
to the kinds of controllable devices you can have in your home -
because you won't be able to control it unless your NAT supports
the right ALG for each device you want to use.

and it's downright silly to have a wireless PDA (say a palm vii
or a pdq phone) and not be able to use it to talk to your devices
within the home just because your PDA and your home are on opposite
sides of a NAT.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 8 Dec 1999 13:58:43 -0500

> From: Ed Gerck <[email-masked]>

    > maybe this is what the market wants -- a multiple-protocol Internet,
    > where tools for IPv4/IPv6 interoperation will be needed ... and valued.

This relates to an approach that seems more fruitful, to me - let's try and
figure out things that sidestep this incredibly divisive, upsetting and
fundamentally unproductive argument, and try and find useful things we can do
to make things work better.

    > Which can, undoubtably, be put in a sound theoretical framework for
    > NATs, in network topology. NATs do not have to be a hack.

Well, the fundamental architectural premise of NAT's *as we know them today* -
that there are no globally unique names at the internetwork level - is one
which is inherently problematic (long architectural rant explaining why
omitted). So I don't think that the classic NAT model is a good idea,
long-term.

However, I think it's a bit of a logical fault to think that the only options
are i) IPv6 and ii) NAT's. That's like saying that if my dog's not in my
office, he must be on Mars - there are other alternatives! This is especially
true in the long run; we may be stuck with NAT in the very short term, but
in the longer term we can explore other alternatives.

    > NATs ... seem to have been discovered before being modeled, that is
    > all.

Umm, not quite, IIRC. Papers by Paul Tsuchiya and Van Jacobsen discussed the
concept a long time before any were commercially available.

	Noel

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 8 Dec 1999 10:27:22 -0800 (PST)

Folks,

Hammers are inteded to solve a certain problem space. So, we should
not use hammer to solve every problem we encounter, (or) ban hammers
altogeher because they do not solve all problems. 

Now, the reality check. NATs donot respect end node ownership of 
IP entities (IP-Addr, port # etc). Thats how they accomplish address
conservation and obviate address renumbering. This lack of IP address
sactity clearly  violates the assmptions made by a large number of
problems. So, NAT is not the hammer to use.

Make the problems go away (or) show clearly superior solutions to solve
the problems. Then, may be, we wont need the NAT hammer. I dont have a
problem with that. There are efforts going on in the IETF to 
precisely do the above. That is great and I am all for it. Soon, the market
place will tell us when it is time to retire or replace the NAT hammers.

Until then, let us not engage in NAT flaming (or) overtly push NATs to
be a save-all solution. To that end, I encourage you to participate in
in the NAT working group, addressing precisely these issues.
 
There is a draft to desctibe NAT complications (i.e., limitations of NAT
problem space) and your input to draft authors/editors is most welcome. 

The NAT WG also has a draft to define NAT friendly criteria  that new
applications need to adhere to for acceptability into NAT problem space. 
If you have some input you could provide, Please do.

Lastly, there is an IAB draft describing architectural issues with NAT. 
Once again, do send in your comments to the draft authors.
 
Thanks.

regards,
suresh

=====

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

---

From: Pyda Srisuresh <[email-masked]>
Date: Wed, 8 Dec 1999 10:27:22 -0800 (PST)

Folks,

 

 
Thanks.

regards,
suresh

=====

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 8 Dec 1999 14:57:25 -0500

> From: Yakov Rekhter <[email-masked]>

    >> the fundamental architectural premise of NAT's *as we know them today*
    >> - that there are no globally unique names at the internetwork level

    > I would say that the fundamental architectural premise of NATs is that
    > globally unique names at the internetwork layer are not carried in the
    > network layer header. This is not to say that such names don't exist -
    > just that they aren't in the IP header.

That may be true in some future variant of NAT - and if so, I'd be *much*
happier with it (I don't any problem with limited use of names with local
scope) - but my take is that it's not the case today.

And no, DNS names are *not* what I was thinking of when I said "names at the
internetwork level"! :-) For one thing, they don't contain *location*
information.

	Noel

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 8 Dec 1999 14:57:25 -0500

Noel

---

From: Sean Doran <[email-masked]>
Date: Thu, 9 Dec 1999 18:08:59 +0100 (CET)

Christian -

| Sean, the appropriate answer to your question is RTFM (as in, read the
| manual.) The top 48 bits of IPv6 addresses are anything but flat. The flat
| space is initially limited to the top 16 bits, 3 of which are used as a
| format prefix, leaving a "flat space" table size of 8K entries.

I was merely using the wording Harald Alvestrand put forward:

> Message-Id: <[email-masked]>
> 
> A /48 leaves 16 bits for subnetting, before you hit the 64 bits of flatspace.

I think by "flatspace" he meant the _lower_ 64 bits here.

| These
| entries are supposed to be assigned to "top level" providers -- the
| equivalent of v4's default-free ISPs. There is indeed a concern that 8K may
| not be enough in the long run, which has lead to place the next 8 bits in
| reserve. Each of these "top level" prefixes thus contains 24 bits of
| address space for organization or delegation by the provider. 

So, forgive me for asking a stupid question, but RFC 2374 is
full of oddities, especially in s3.2.   Are you of the belief that
as a matter of policy, everyone but "top level" providers will have
addresses from a "top level" provider, with no exceptions?

Do you also beleive that for inter-TLA routing information-exchange 
purposes, with respect to the destination address, ONLY the 13 (to
21) TLA (+ RES) bits you mention should ever be considered by a
router in the core of the global network, except where two
directly-peering TLAs agree to exchange some NLA information?

	Sean.

---

From: Sean Doran <[email-masked]>
Date: Thu, 9 Dec 1999 23:42:18 +0100 (CET)

| This is the plan. We start out with no holes in BGP and we try to
| keep it that way.

Ah, BGP.

Ok, so it seems like there is a 1-1 mapping of TLAs to AS numbers --
after all, why would an AS encompass more than one TLA prefix?

What happens if and when the 8k limit on TLAs is relaxed, because
the number of organizations qualifying for (however this might happen)
a TLA assignment exceeds that number, given that the relaxation might
well take us beyond 16 bits of TLA (I take this as implied by Christian's
earlier comment).  

The second half of the question above: why would one split a TLA
across multiple ASes in the default-free zone? For NLA<>TLA, do
you propose to have (possibly floating) static routes be the means
of handling NLRI?   That is, we configure default on each operational
connection to the TLA that the NLA connects to (and deconfigure at
each interface when it is not operating), while we configure static
routes to the NLA addresses at the border of the TLA.  Yes?

I found no FM to R on this subject.

Will any effort be made to keep the NLA IDs both globally unique
and portable?  Or, because TLA+NLA may share the same NLA bit
pattern with another 2nd-level network TLA'+NLA, will 2nd-level
networks who multihome to multiple TLAs do one of:

	a/ be "promoted" and become a TLA themselves
	b/ carry multiple NLAs, assigned by each TLA they interconnect with

?  If (b) do we make the tunnel hack work, or do we make the NAT hack work,
or both, or do we just ignore what to do about losing connectivity
to one or more of the TLAs to which a 2nd-level network is connected?  

On the other hand, if the NLA bit patterns _are_ kept globally unique
and portable, how will reachability via one or the other of multiple
TLAs be announced to the global core network?

	Sean.

P.S.: Someone should eliminate the apostrophe in the first line of 3.4
      of RFC 2374

---

From: Sean Doran <[email-masked]>
Date: Thu, 9 Dec 1999 23:51:39 +0100 (CET)

| so i had a nearby scheme interpreter

yay.  (now go fix all the buggy scheme and lisp packages in -current :) :) :) )

| It seems obvious to me that the only way routing can scale with
| addresses this large is with very aggressive aggregation.

It would work better still with abstraction, hence my (maybe stupid)
questions to Brian and Christian.

| The only way multihoming can work when aggressive aggregation is in
| place is if hosts end up with multiple addresses (one from each
| prefix) and know how to use them intelligently... 

Even trickier: how to get non-local hosts to use them intelligently.

The DNS as a mechanism for policy-based routing (in the sense of
remotely influencing other people's path selection) is not totally
without appeal.  But then again, I'm a loon, and like NAT.

	Sean.

---

From: Steve Hultquist <[email-masked]>
Date: Fri, 10 Dec 1999 22:19:03 GMT

Actually, I think this is the case more often than many people may realize.
Right now, for example, one of my sites is running in this mode for exactly
this reason. Yes, there are issues, but not ones that aren't relatively
easily mitigated.

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

                    Jessica Yu                                                                                 
                    <[email-masked]>        To:     Bill Sommerfeld <[email-masked]>          
                                         cc:     Jessica Yu <[email-masked]>, Keith Moore <[email-masked]>,     
                    12/10/1999           Christian Huitema <[email-masked]>, Sean Doran        
                    01:01 PM             <[email-masked]>, [email-masked]                                        
                                         Subject:     Re: IP network address assignments/allocations           
                                         information?                                                          

>> There is also a potential scaling issue of using multiple addresses
>> as general purpose multihomging mechanism. This is because if this
>> is the case, most of the Internet hosts will end up with multiple
>> addresses.
>
>I don't see why this is inherently a problem.

        This is paradigm shift in the Internet from majority of hosts
     with single IP address to the majority of the hosts with
     multiple IP addresses.  Many existing support mechanisms such as
     routing (see Keith's message), DNS name look up, traffic engineering
     network managment,etc. may not be adequate. It may also break the
     things that we have not even thought of.  And do not forget about
     operational complexity issues. Are we really ready for such a
     major shift?

     So I would not say so quickly that it's not a problem.

                              --Jessica

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 10 Dec 1999 19:54:04 -0500

> Now we're busy pushing technology to ensure routing table sizes won't
    > increase because the present generation of hardware can't handle larger
    > routing tables. Are we being a bit short-sighted? 

No. The issue with routing table size is not the memory required to store it,
but the stabilization time when a topology change happens. That is a factor
of a number of things, including the speed of light, which isn't going to get
faster any time soon... :-)

	Noel

PS: The following bits and pieces of old emails which I dug up talk
about this in a little more detail:
 
  think about what factors go into the equation which describes the
  stabilization time curve.

  (I say "curve" since a mere average is useless; if you have design A in
  which it always stabilizes in 3T, and design B in which is sometimes
  stabilizes in T and occasionally in 100T, the *average* for both may be
  the same, but in real service you'd probably prefer the predictability
  and boundedness of design A.)

  There are factors in there *other* than node processing power, such as
  i) the propogation time of updates (which is heavily dependent on
  the speed of light), and ii) the number of nodes in the network
  through which the updates have to propogate.

  After the above, what share of the stabilization time is affected by
  processing power in the nodes? Put another way, what does your model
  predict for the stabilization time if you have *infinite* processing
  power in the nodes? If your answer is zero, your model has gone wrong
  somewhere.

  As an insight, assuming processing power is infinite, how does the
  stabilization time vary in the number of nodes in the graph? (Hint:
  what is the average path length in a random graph of N nodes?) ...
  is the stabilization time linear in the number of nodes through which
  the computation has to pass, or what?

  Assuming processing power is infinite, how does the stabilization time
  vary in the number of nodes in the graph? If the number of nodes is
  held constant, what is the effect of propogation time on the curve? Do
  you know any way, chearp or otherwise, to reduce propogation times?

  Stabilization time is larger in a larger network. Full stop. A larger
  network will *also* have more topology changes per unit time. As a net
  gets larger, you are caught between two closing jaws: increasing
  stabilization time, and decreasing MTB topology changes. There are
  solutions, but throwing more processing power in the routers at the
  problem isn't it.

  ...

  There *are* some ways to deal with these problems (e.g. by bounding
  the number of nodes that updates have to propogate through, by careful
  design of topology and abstraction hierarchy, and limiting inter-level
  linkage) but they demand a more engineered (on the large,
  inter-provider scale) net than we have now.

---

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 10 Dec 1999 19:54:04 -0500

Noel

  ...

---

From: Sean Doran <[email-masked]>
Date: Sat, 11 Dec 1999 15:41:04 +0100 (CET)

| > It's possible that some multihomed sites will have to assign 4 or even 
| > more ip addresses per host, depend on what kind of ISPs they multihoming 
| > with. E.g. a site that happen to multihome to two tier-2 ISPs, each 
| > multihomed with two different tier-1 ISPs, each host in this multihomed
| > site will have 4 IP addresses in order to get full benefit of redundancy. 
| > One can image even more complicated case.
|
| I believe that it should be fairly straightforward to extend
| implementations to deal with this case; some of the proposals floating
| about actually significantly simplify the API's used by real
| applications.

Great, so an end-system with multiple IP addresses has to be able
to figure out:

	-- when one of the addresses is invalid for a particular 
           destination (or set of destinations) because of a partition
	   somewhere in the Internet
	-- which of the addresses to use to talk to which address
           presented by a DNS AAAA query that coughs up a number of
	   addresses for another end-system it wants to connect to

Christian Huitema's brute force system suddenly looks less
attractive: instead of a singly-numbered host sending out n packets
towards a destination with n addresses, we would instead do an m-numbered
host sending out n packets from each of the m addresses.   Whee.
This would make T/TCP *lots* of fun to use.

Then, assuming one kept the state necessary to handle the best
(or even first) SYN-ACK and abort all the non-best (or subsequent)
SYN-ACKs, there is the problem that the ES is now not well equipped
to deal with partitions or topology changes that make the connection
inefficient.   That is, when we have chosen the best (FSVO best)
source/destination address combination, and suddenly have that
pair not work, there is no mechanism in place to choose a new
source/destination pair, because we've inherited the non-survivability
during renumbering problem from IPv4.

In any event, when the network is hiccoughing, tossing a number
of non-flow-controlled packets to choose a new source/destination
pair from n*m - 1 combinations into it is probably a really bad idea.

	Sean.

---

From: Sean Doran <[email-masked]>
Date: Sat, 11 Dec 1999 15:41:04 +0100 (CET)

Sean.

---

From: Sean Doran <[email-masked]>
Date: Sat, 11 Dec 1999 16:44:14 +0100 (CET)

| given TCP's inability to do congestion-sensitive backoff during
| connection establishment, I'm not so sure that increasing the number
| of concurrent connection attempts is a good idea.

I am pretty sure it is NOT a good idea.

| the selection of the server with the ... lowest [RTT] 
| was often ... good but rarely ... optimal.

One of the things which is becoming apparent to a number
of service providers is that that a low RTT is necessary
but insufficient for "user happiness" - RTT _stability_ is
often more important.

Regrettably, there is little to no way for an end system
to understand the short term stability of a path other than
by trying to move traffic across it.

| no, I can't see how a routing-system-based multihoming
| will scale down to SOHO networks either.

Why not?  It should be an explicit goal of the next cut
at an IPng, and shouldn't just stop at SOHO -- it should
go right to individual homes, _at least_.  I have multiple sets of
wires coming into my flat, and live in a regulatory environment
where each of those wires (and some new ones) is allowed to carry
data/POTS/ISDN/cabletv/you-name-it.

And then there's Sweden, which is several steps ahead.
Check http://www.bredbandsbolaget.se/eng/node103.asp?ID=16
Yes, they really are serious about more than a quarter of a million
homes which will have the moment-to-moment chance to use
any or all of: FTTC/FTTB/FTTH from these folks, cable modems,
or the various offerings from the various telcos (xDSL, dialup)
for Internet connectivity.

The days when only a handful of middle-aged Swedish women have broadband
connections like this: http://www.stupi.se/Bilder/7296-3251-0759/g.html
into their apartments are numbered.  (BTW, if you look closely, you'll
see her apartment's network was multihomed already.)

The assumption that only larger organizations will want multihoming
and at-will-provider-changing is a bad one.

	Sean.

---

From: Jessica Yu <[email-masked]>
Date: Tue, 14 Dec 1999 14:07:58 -0500

Brain,

Looks like we have a teminology issue. Notice I did not say routing 
system but ROUTING will have problem.  Because the choice of a 
multi-addressed host to use one of its IP address to include in
packet header implies routing decision, the host, in effect, does 
some routing decision making.  How a host intellegently choose the 
ip address as the source address to send packets or DNS intellegently 
choosing an ip address for a query are complex issues which we do not 
have an answer for as you indicated in your message.  

So I disagree with those who think it's not a problem in the Internet 
where majority of hosts with multiple addresses. 

						--Jessica  

------- Forwarded Message

Date: Mon, 13 Dec 1999 16:05:48 -0600
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Jessica Yu <[email-masked]>
CC: [email-masked]
Subject: Re: IP network address assignments/allocations information?
Content-Length: 2452

Jessica,

I don't think this is a problem for the routing system. It will deliver to
whatever destination address is in the packet. The problem is for hosts
to choose which destination address to use when there is a choice,
and ditto for the source address.

I don't agree with those who see this as asking the host to guess at
routing decisions. However, it's a complex topic that is already 
an active work item in the IPNG WG.

   Brian

Jessica Yu wrote:
> 
> You seem to disagree with my statement of "routing may not be adequate."
> in the Internet where majority of the hosts with multiple IP addresses.
> 
> Do you really believe that there is an adequate support for the routing
> issue described below in majority-hosts-with-multiple-ip-addresses
> environment?
> 
>                                                 --Jessica
> 
> Date:    Fri, 10 Dec 1999 12:49:57 EST
> To:      Bill Sommerfeld <[email-masked]>
>          Christian Huitema <[email-masked]>,
>          Sean Doran <[email-masked]>, [email-masked]
> 
> From:    Keith Moore <[email-masked]>
> Return-Path: [email-masked]
> X-URI:   http://www.cs.utk.edu/~moore/
> In-reply-to: Your message of "Fri, 10 Dec 1999 12:32:18 EST."
>          <[email-masked]>
> Sender:  [email-masked]
> Content-Type: text
> Content-Length: 913
> 
> it's a problem because it's essentially asking the sending host to do
> routing in the absence of any routing information.
> 
> if multiple addresses are available for a host, the chances are good
> that the paths associated with some of those addresses are significantly
> better, or worse, than others.  with IPv4 multihoming, the routing system
> sorts out which path to use.  this doesn't work perfectly but at least
> the decision is made in light of some information about the nature and
> current state of those paths.  with IPv6 multihoming, the sending host is
> just guessing.  it's difficult to believe that this will work well.

------- End of Forwarded Message

---

From: Jessica Yu <[email-masked]>
Date: Thu, 16 Dec 1999 13:39:34 -0500

Christian,

First all of, it's good that we agree that we have a problem or 
problems to solve.  Whether I overstated the problem or you 
under-estimated the problem is yet to be seen.

In your message, you did not address the issue of how a host 
intelligently choose one of its multiple ip addresses as its source 
address when initiate a connection.  This is an issue. For example, 
a host X with two IP addresses A1 and A2. When it sends a packet to 
host Y, it chooses A1 as source address, that means Y will use A1 as 
destination address when sending traffic back to X.  If at the time, 
A1 is not routable at Y's network, (due to outage,etc.), Y will not 
be able to send traffic back to X resulting no reachability between 
X and Y. At all this time, A2 could be perfectly routable from Y's 
network, should X choose A2 instead of A1 as its source address, Y 
would be able to send traffic back to X thus communicating with X.  
X picked wrong address as source address simply because if has no 
routing knowledge beyond its local network.  In short, we can have an 
unnecessary outage just due to the fact that host picking 'wrong' address. 

This will potentially complicate trouble shooting or cause confusion.
E.g. X can not reach Y due to the problem described above while at the
same time, traffic initiated from Y can reach X with no problem
because from DNS Y got A2 as destination to reach X.  One can image 
other trouble shooting confusions resulting from multiple addresses 
per host, especially the majority of the host in the Internet with 
multiple addresses.

Other part is that host X in the example has to get an IP address
associated with Y to use as destination address to reach Y. It will 
query DNS and DNS will return an IP address.

You seems to indicate that there are two ways of doing this : 1) DNS
intelligently determines which path is less congested and picks
the appropriate address and 2) DNS just randomly picks one address 
among multiple addresses associated with a host.  

For 1), how does DNS gain knowledge of congestions of networks
along the path?  The congestion picture changes frequently, how
how often will the knowledge get updated? I do not believe any such 
mechanism is defined at this point and it'd be interesting to see a 
mechanism that works and is scalable.  
		            ********

Random selection of address is easier but it introduces unpredicatable 
behavior: a host will take different path to send traffic to the same 
destination host depending on what address DNS picking. Unpredicatability 
is always not friendly to operation and trouble shooting. In comparison 
to BGP, it picks routes in a predicatable fashion based on well known 
rules of BGP and network administrator's policies.

Also, in both random selection or picking based on congestion cases,
DNS should pick an address which is routable at the time. How does a 
DNS server know if an address is routable several hops away?  It needs 
to have routing knowledge.  Then how DNS get Internet routing knowledge 
and how often will it be updated?  Again, it'd be interesting to see
a proposal which works and scalable. 

cheers! 
					--Jessica  

Date: Tue, 14 Dec 1999 15:26:59 -0500
To: Jessica Yu <[email-masked]>
From: Christian Huitema <[email-masked]>
Subject: Re: IP network address assignments/allocations information?
Cc: [email-masked]
Content-Length: 3725

At 02:07 PM 12/14/99 -0500, you wrote:
>some routing decision making.  How a host intelligently choose the 
>ip address as the source address to send packets or DNS intelligently 

Jessica,

I believe you overstate the problem. To begin with, a domain manager is
never obliged to advertize all possible routing prefixes for all its hosts.
In principle, it will only advertize those network connections that are
deemed "good enough." So, at a 10,000 feet level, picking an address at
random in the list, without any information whatsoever, gives you a
connection that may not be optimal, but is probably reasonable. Which means
that the proverbial "five lines client", which presumably will transfer 5
packets, will get adequate service. You will tell me that this may not be
optimal, but then, explain me exactly how the current BGP fabric guarantees
that routes are picked optimally? In fact, in their communication at the
last ACM SIGCOMM conference, "On Estimating End-to-End Network Path
Properties", Mark Allman and Vern Paxson observe that it is quite frequent
for interdomain routing to converge on a less than optimal route today.

The question indeed arises when one of the addresses in the list goes
through a provider that is experiencing heavy congestion. Let's first
remark that, if clients were to pick addresses at random from a list, we
would obtain automatically some level of traffic spreading, which would
generally tend to ease congestion -- but we all agree that congestion will
not be eliminated. If the congestion is already present at the beginning of
the connection, the answer is simple. The first SYN packet gets lost, and
the client simply picks another address in the list and tries again. Again,
this may not be optimal, but it will provide an adequate solution for even
the most brain dead of clients. The smart clients will no doubt find how to
resolve the problem in a smarter way.

So lets focus on the remaining part of the problem. What happens if a
client picks an address at the beginning of a connection, only to find out
that the transit networks are becoming congested. There are solutions,
which require minimal adaptation to TCP. An example is discussed at
http://www.chem.ucla.edu/~beichuan/etcp/; another solution is developed as
part of MobileIP. Indeed, if there is no modification to TCP, there is no
good solution. But then, this is not very different from the current state
of the art. a TCP connection can only survive the loss of a transit network
if BGP manages to detect and correct the loss faster than it takes for the
TCP timers to break. If I believe the recent reports to Nanog, this is far
from guaranteed today.

So, yes, we have a problem. We need to somehow adapt the TCP stack to
survive losses of transit networks. But we should not overstate that
problem. It only affects long connections, it only makes a difference if a
connection to a transit provider breaks, and if the routing tables could
have been repaired by BGP. In any cases, there are simple modification to
TCP, for which we already have some experience, that could handle the
problem. In the long run, once these modifications are in place, we are
better off than in the current situation, because we will rely less on the
speed at which interdomain routing converges.
- -- Christian Huitema

---

From: Graham Klyne <[email-masked]>
Date: Fri, 17 Dec 1999 10:40:45 +0000

At 16:25 14/12/99 -0800, Dave Crocker wrote:
>At 02:50 PM 12/14/1999 , Christian Huitema wrote:
>>No. This is no different from the present situation. BGP does not recompute
>>routes in case of congestion. It is a problem that we are stuck with today,
>>that multi-address multi-homing actually gives us the hope of solving.
>
>
>Only minimally, as long as a TCP connection is tied to an IP address...
>
>d/
>
>ps.  Christian and I separately suggested changing this, to support IP 
>mobility, a few years ago.

Would IPv6 anycast not be an alternative approach here?

#g

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

---

From: Graham Klyne <[email-masked]>
Date: Fri, 17 Dec 1999 10:40:45 +0000

#g

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