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

From: Jon Crowcroft <[email-masked]>
Date: Wed, 01 Dec 1999 08:31:44 +0000

In message <[email-masked]>, Paul Ferguson typed:

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

i would.

NATs are classic short term optimisation kills long term benefoit of
the right way of doing things. also:
for NATs to scale to deal with the global net completely they must be
globally coordinated - we have failed to deploy a single globally
coordinated _infra-structural_ service since the DNS - sure there's
lots of sitelocal servers (dhcp, time etc)< and there's content
servers which may even deign to take part in proxy cacheing, and
there's intra-ISP servers.....but nothing inter-domain apart fron DNS
really - and if NATs dont do this (and all the ANTs to date dont so
they only deal with access-to-core which is a incy-wincy piece of the
problem in the LONG run), then something else will....whether IPv6
(best case scenario to date), or
application level relays with name based routes which would be a real
shame coz reliability, cheapness and security will all be unattainable
then too...
 
 >>Personally, I think NAT is just fine, but I'm a self-proclaimed cynic
 >>and also consider myself somewhat of a pragmatist. In any event, it
 >>works for me, but I could certainly be in the minority.

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

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

well, how about we just start to turn it on in some routers? - it works
in most host OSs now, dual stack, just fine.

the value of the net is the square of the number of people connected -
NAT is a square root function.

 >>The truth is that NAT's allow organizations to deploy machines in
 >>networks which otherwise would not have enough address space. To
 >>say that NAT's are unequivocally evil is unfair, methinks.
 >>
 >>- paul
 >>
 >>At 01:37 PM 11/30/1999 -0800, Tony Hain (Exchange) wrote:
 >>
 >>>Yes there are problems with protocols that carry addresses, but ignoring 
 >>>encrypted traffic that really amounts to acquiring and synchronizing 
 >>>deployments of ALGs. In the early stages this doesn't sound hard, but will 
 >>>vendors be willing to add new ALGs to 3 year old NAT hardware? Will they 
 >>>create an update process that is easy enough for the average user? Will 
 >>>the average user be able to figure out which NAT needs updating, and what 
 >>>version it needs? Add the fact that people want to encrypt their traffic 
 >>>for privacy, and one wonders why so much effort is spent on this dead-end 
 >>>technology.
 >>

 cheers

   jon

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 01 Dec 1999 08:31:44 +0000

i would.

 cheers

   jon

---

From: "Perry E. Metzger" <[email-masked]>
Date: 03 Dec 1999 20:06:28 -0500

> NAT is a square root function.

NAT has actually created a simple transition plan for us.

I'd say at this point that 95% of the corporate networks in the
U.S. use private addressing and a NAT or proxy box at the
border. Switching from this to using v6 internally with a v6 to v4
NAT/proxy at the border for communicating with v4 is trivial -- since
they don't have globally routable addresses now, they won't be hurt by
the switch.

As more and more people switch to this configuration, they'll start
finding themselves talking to more and more things over the net
natively, and fewer and fewer through the translator. Suddenly,
they'll discover they *do* have globally routable addresses again,
just like we did in the old days before net 10 was turned into the
universal addressing ghetto.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 03 Dec 1999 20:06:28 -0500

Perry

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 04 Dec 1999 18:01:35 -0800

Perry,
 
> universal addressing ghetto.

This could go as you described *until* these folks would start to move
from one provider to another, and therefore will be faced with the need
to renumber. At that point NAT could become quite an attractive
alternative from cost/benefit point of view again.  And now these folks
will be back to where they've been with IPv4, but but with the extra
cost of IPv4 to IPv6 transition.

Yakov.

P.S. While one could argue that renumbering with IPv6 could be made
simpler than with IPv4, what one really needs to compare is renumbering
with IPv6 vs renumbering with NAT.

---

From: Yakov Rekhter <[email-masked]>
Date: Sat, 04 Dec 1999 18:01:35 -0800

Perry,

Yakov.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 1999 12:13:53 -0600

> universal addressing ghetto.

By the way, the 6to4 mechanism was conceived as the natural first mechanism
for such NATted sites to use. 

In answer to Yakov, the idea is that IPv6 site renumbering will be so much
easier than for IPv4 that renumbering will be *less* painful than NATting.
Theoretically this is taken care of in IPv6 today, but we need to see 
some practical experience of renumbering to find out if it's true.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Dec 1999 12:13:53 -0600

Brian

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 13:47:38 -0500

> some practical experience of renumbering to find out if it's true.

I'm not sure we're there yet in the support technology for
renumbering. We have good ideas but we haven't pushed them totally out
the door yet. However, we do have good ideas.

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

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 13:47:38 -0500

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 11:20:00 -0800

> the idea is that IPv6 site renumbering will be so much easier than for
> IPv4 that renumbering will be *less* painful than NATting.

this needs to be reconciled with the *much* more conservative statements on
v6 renumber-ability coming from respected v6 folk such as deering et alia.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 11:20:00 -0800

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 11:39:11 -0800

> I'm not sure we're there yet in the support technology for renumbering.
> We have good ideas but we haven't pushed them totally out the door yet.
> However, we do have good ideas.

[ flame, not directed at you personally but at this thread ]

this is not the internet marketing task force.

get real.  a LOT of folk have deployed nat, hundreds every day.  it's easy.
it solves the customer's perception of their problem.  it's not expensive.
[ yes it sucks architecturally.  what's that got to do with customer/market
reality?  the office buildings we work in suck architecturally too. ]

we'll have to be at least three times (cheaper*better*easier) to replace
nat, that's market reality.  currently we are not proposing anything that
the customer perceives as cheaper, better, or easier.  this does not bode
well. 

until we change this by making our technology, or at least the perceprion
of it, cheaper, better, and easier, pontification, scare tactics, and nat-
bashing make us look foolish and poison our credibility in the long term.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Dec 1999 11:39:11 -0800

randy

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 15:02:10 -0500

> it solves the customer's perception of their problem.  it's not expensive.

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.

I'll keep posting this so long as people keep on with the "NAT is
cheap and works well" myth. NAT is a fine solution for someone running
three Macs and a Linux box behind a cable modem. It does not, however,
scale, and This Costs Big Time. If you expect to run a large
enterprise on NAT, be prepared to do the moral equivalent of ripping
up $100 bills and flushing them down the toilet, hour after hour.

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 15:02:10 -0500

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Dec 1999 15:31:45 -0500

> Actual Live Large Companies.

The counter argument is that for the Home Networking case, which is a
HUGE market, it is indeed cheap and easy to use. Please accept THAT
reality.

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.

> up $100 bills and flushing them down the toilet, hour after hour.

Fine. Let's focus on your corporate use of NAT issue, since that's where
you have problems. I, for one, would like to hear more about how these
companies are using NAT, and perhaps we can from there work toward some
solutions.

I'd suggested the other day allocation of a block of addresses, to be
handed out by a registry in small chunks, specifically for use in
interconnects between companies. I had heard lots of rumblings in the
past that this is where NAT in large companies was causing trouble. From
the lack of any response, perhaps the problem is otherwise. Since you're
having such troubles, and since many of us apparently don't understand
the situations where you're getting into trouble, please enlighten us.

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.

-- 
-----------------------------------------------------------------
Daniel Senie                                        [email-masked]
Amaranth Networks Inc.            http://www.amaranthnetworks.com

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Dec 1999 15:31:45 -0500

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 07 Dec 1999 14:40:06 -0600

> v6 renumber-ability coming from respected v6 folk such as deering et alia.

Whoa, Randy, time out.  Can you cite such a statement which conflicts
with what Brian wrote above?
					Matt

---

From: "Matt Crawford" <[email-masked]>
Date: Tue, 07 Dec 1999 14:40:06 -0600

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 15:58:15 -0500

> HUGE market, it is indeed cheap and easy to use. Please accept THAT

I'm not even sure its a good thing there.

You're at work. You want to check your answering machine. Its behind a
NAT, so you can't. You want to program your VCR. You can't. Its behind
a NAT...

> to do about the large corporation issue.

I don't agree that NAT scales, ever. Its a great kludge if you are
using it for a very limited number of things. As I said, letting two
people surf the web behind one cable modem with one IP address works
on a NAT. Does NAT scale to true home networks, where every light bulb
is SNMP manageable? No. Does it scale even to a modest home network?
Only if you think the sole application is letting you surf the web on
your toaster, which I doubt is the future.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 15:58:15 -0500

Perry

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 20:49:26 -0500

> to do about the large corporation issue.

NAT is a good hammer for a home network if and only if the only 
purpose of a home network is to allow multiple web clients at home
to talk to servers in the outside world.  

If you want to use a home network to be able to access your devices
at home *from* the outside world - e.g. IP telephony, IP fax, 
instant messaging to your home, IP printing to your home printer 
from elsewhere, setting your vcr, setting your thermostat so that the 
house will be warm when you get there, checking the house temperature to 
see if the air conditioner has died again, taking a peek at the kid 
you've left home with the babysitter (or by himself) to see that 
he's okay, investigating the alert you got from your intrusion 
detection system, personal web server for home or home office -
NATs start to look like a pretty poor hammer even for home use.
(unless, of course, you think the purpose of hammers is to break things)

OTOH, if you combine NAT with 6to4 for home networks, the
picture starts to look a bit better.  Think of 6to4 as the 
generic ALG that rids you of the need to have separate ALGs
for most of the applications that NAT happens to break.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 20:49:26 -0500

Keith

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Dec 1999 21:17:49 -0500

> (unless, of course, you think the purpose of hammers is to break things)

Sounds to me like at best I'd trade a NAT box with firewalling for a
serious firewall. I have ZERO interest in allowing the kinds of things
you describe to occur from outside. While you may not mind someone
hacking into the microphone on your PC and using it as a bug I am a
little less trusting.

> for most of the applications that NAT happens to break.

So, will any of our ISP readers go on the record as saying they'll
provide users of dialup and DSL/Cable lines to have a large block of
addresses each, instead of just a single host address? The way I read
the ARIN IPv6 allocation policy, they're going to manage the new space
about the same as IPv4 space. Which is to say I don't expect space to be
readily available.

---

From: Daniel Senie <[email-masked]>
Date: Tue, 07 Dec 1999 21:17:49 -0500

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 21:20:52 -0500

> hacking into the microphone on your PC and using it as a bug I am a

obviously you have to have some security measures in place
before you open up such things to the outside world.  but 
that's an argument for better authentication technology, not for NAT.
without the NAT in place I could use IPSEC to authenticate myself
and punch a hole through my home firewall; with NAT in place that's 
just not possible.

> about the same as IPv4 space. Which is to say I don't expect space to be

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.

2. at any rate, 6to4 doesn't need IPv6 blocks allocated by ARIN
   or anybody else; it just needs a single IPv4 address for each
   customer.  i.e. there's already a block of IPv6 addresses 
   allocated for every v4 address and a well defined way to
   route to such v6 addresses over the v4 Internet.

   see draft-ietf-ngtrans-6to4-*

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 21:20:52 -0500

Keith

---

From: Tripp Lilley <[email-masked]>
Date: Tue, 7 Dec 1999 22:36:49 -0500 (EST)

> for most of the applications that NAT happens to break.

Mine is not a stand in favor of NATs, let me get that out first :-)
However, the arguments against NATs in the home all center around
end-to-end connectivity to various devices in the home (light bulbs,
toasters, VCRs, thermostats, etc).

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. I'm not
saying that's the right solution for everyone, but I think it's certainly
worth thinking about as we're designing VCR control and LBMP (Light Bulb
Management protocol).

That is, I think it's important to consider that folks (via their vendors)
will want to deploy ALGs at the boundary of the house, NAT or not. I know
I will be, even after the internal v6 infrastructure meets up with the
rest of the world in the far flung future.

I don't think NATs are architecturally "correct", but I think they're
teaching us an important lesson about the (initially valid) assumptions
about end to end connectivity. Even after we eradicate NATs through
wholesale migration to v6 (optimist hat on), the paranoid will still
deploy ALGs on their firewalls to mediate access to those globally
routable lightbulb and security camera addresses. After all, I wouldn't
want the world getting illicit shots of me in my underwear in the
evenings. Well, perhaps it's the world that wouldn't want to be getting
those shots, but you get my point...

-- 
   Tripp Lilley  *  [email-masked]  *  http://stargate.sg505.net/~tlilley/
------------------------------------------------------------------------------
  "There are plenty of things out there that people should be offended about.
   Put your indignation into some more productive and appropriate fight."

   - Larry Rosensweig
     in http://www.cnn.com/1999/US/12/03/pokemon.swastika.ap/index.html

---

From: Tripp Lilley <[email-masked]>
Date: Tue, 7 Dec 1999 22:36:49 -0500 (EST)

- Larry Rosensweig

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 22:05:58 -0500

Tripp Lilley <[email-masked]> writes:
> Is this really the "right" model for that sort of interaction?

Yes. I don't want to invent fifteen thousand different protocols to
handle things. IP already does what I need most of the time.

> routable lightbulb and security camera addresses.

I'm not sure that's the right model, actually. IP addresses are too
easy to forge. The right way to stop people from doing that sort of
thing is to deploy end to end security protocols that strongly
authenticate both ends.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 07 Dec 1999 22:05:58 -0500

Perry

---

From: Tripp Lilley <[email-masked]>
Date: Tue, 7 Dec 1999 23:07:33 -0500 (EST)

> handle things. IP already does what I need most of the time.

Perhaps I wasn't clear... IP (v4 or v6 or what have you) is a fine way of
determining the end points of the communication. But at higher levels
(MEGACO, SIP, LBMP, etc.), I believe it makes sense to allow in the
protocol design that people might want to consolidate funcionality in an
ALG (more below)

> thing is to deploy end to end security protocols that strongly

Realistically, in the home environment (which is quite specifically the
domain I'm constraining these statements to, even though they might have
broader applicability), it's unreasonable to expect that every light bulb
(light fixture) is going to carry the silicon to handle authentication
(and/or encryption).

I think it makes sense to consider a boundary (firewall+ALG) that defines
a "trusted zone" within the house, establishes ACLs for a given
"connection", be it a tunnel or otherwise, defined by an authentication
event, and mediates the activity over that connection as long as it's
active.

Treating each and every action into that trusted zone as a separate
request, carrying separate overhead for connection setup and teardown
(over the WAN), and separate overhad for authentication and encryption
puts us in the same boat as HTTP/1.0. 

I'm not saying we should consider anything other than IP to establish the
desired endpoints of the given transacion. I'm not saying we should try to
hide topology and addressing behind a NAT. I'm saying that even *with* a
connection that's end-to-end for the purposes of designating participants,
we might want to consider that someone in the middle will be mediating the
conversation, acting on behalf of one or both participants.

An example to wit: I want to be able to plug my Extend-A-Home 2000 (tm)
intelligent brick into the ethernet jack in my hotel room, then unpack all
the rest of my goodies (portable printer, portable scanner, wireless
IP phone, Palm Connected Organizer(tm), MP3 player, etc.) and have them
"just work". Now, I realize that all of this can be accomplished through a
combination of DHCP, DDNS, and IP Mobility. But that requires an awful lot
of complexity in each device, when that complexity *could* be hidden
inside the Extend-A-Home 2000 (tm). I plug it in and *voila*, my hotel
room is an extension of my home. All of my permissions into my home remain
intact (with only an authentication exchange between the Extend-A-Home
2000 and the Home-Weiller 2000 Border Establishment Unit(tm)).

You also have to consider that just because IP is the "right" answer
doesn't mean it's what will end up in the stacks of all of these micro
devices (especially light bulbs). There will be gateways and proxies for
LON and CANbus and X-10 and so forth for a while to come, possibly
forever.

All I'm saying is that taking ALGs into account for reasons *other* than
NAT doesn't seem like such a bad idea as we're doing new work.

   - Larry Rosensweig

---

From: Tripp Lilley <[email-masked]>
Date: Tue, 7 Dec 1999 23:07:33 -0500 (EST)

- Larry Rosensweig

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 22:40:40 -0500

> 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: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 22:40:40 -0500

why not?

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 22:48:32 -0500

> event, and mediates the activity over that connection as long as it's

you're confusing trust boundaries with network topology.

trust boundaries don't follow network topology even today,
or you have to do a fair amount of work to make them do so.
they're even less likely to follow network topology in the future
when a significant number of the devices we want to talk to are
running wireless IP.

and just because I have multiple devices in my home doesn't mean
that I trust my (roommate, spouse, kid, babysitter, houseguest,
burglar, landlord, friendly neighborhood cop) to have net access 
to everything in my home merely by having physical presence there.

nor do I want to have to run separate protocols to access devices
on my home network than for the same kinds of devices located 
in other environments.

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 07 Dec 1999 22:48:32 -0500

Keith

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 07 Dec 1999 20:03:24 -0800

>thing is to deploy end to end security protocols that strongly

Anythink mankind can lock, mankind can unlock. You will never get
rid of firewalls. At least not in our lifetimes.

---

From: Matt Holdrege <[email-masked]>
Date: Tue, 07 Dec 1999 20:03:24 -0800

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Dec 1999 00:35:15 -0500

> rid of firewalls. At least not in our lifetimes.

actually, I'm recently forming a radical opinion that firewalls
need to be first-class components of the internet architecture.

only: (a) they should be thought of as "access control checkpoints"
rather than as held responsible for authentication (just because
you can get through a firewall doesn't mean you're authenticated
for all services beyond that firewall), (b) we need authentication
mechanisms that allow our packets to traverse multiple firewalls
(including both ingoing and outgoing firewalls) and still serve 
as authentication for services at their destination.  that is, we 
need to be able to attach (perhaps multiple) credentials to packets,
that stay with those packets end-to-end rather than having to do
tunneling.  those credentials (sadly) may need to be based on both 
user identity and current network location.  it should follow that 
(c) IP addresses have nothing to do with authentication in such a 
world - there will be too many cases where trust boundaries and IP 
topology don't coincide, and trying to do VPN-like things for all 
of the different things you want to authenticate to from the 
same host will be too hairy.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Dec 1999 00:35:15 -0500

Keith

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Dec 1999 22:36:52 -0800 (PST)

% need to be able to attach (perhaps multiple) credentials to packets,
% that stay with those packets end-to-end rather than having to do
% tunneling.  those credentials (sadly) may need to be based on both 
% user identity and current network location.  it should follow that 
% (c) IP addresses have nothing to do with authentication in such a 
% world - there will be too many cases where trust boundaries and IP 
% topology don't coincide, and trying to do VPN-like things for all 
% of the different things you want to authenticate to from the 
% same host will be too hairy.
% 
% Keith

Erp,
	"current network location" == IP address
	your model needs to be extended a bit.  I see
	three types of "things", where the node is,
	where applications are being housed, & who is 
	running them.  Credentials apply to all three.

--bill
	(thinking that renumbering the Internet every 
	20minutes is a desireable goal... again :)
	More work on supporting untethered nodes & nets
	is a good thing.  DynamicDNS & DHCP are a good
	first start.  "fixing" the transport protocols
	... another kettle of fish ...

---

From: Bill Manning <[email-masked]>
Date: Tue, 7 Dec 1999 22:36:52 -0800 (PST)

Erp,

--bill

---

From: Tripp Lilley <[email-masked]>
Date: Wed, 8 Dec 1999 02:23:15 -0500 (EST)

> need to be first-class components of the internet architecture.

I don't think that's radical, but some people think I'm radical, so it
might not matter :-)

> same host will be too hairy.

I agree with this... My earlier point about ALG's wasn't intended to be in
support of NAT (I specifically disclaimed that, in fact), nor was it
intended to suggest that trust boundaries and IP topology coincide (even
though my examples were of situations where they did).

I guess I was being too specific about a perhaps more general problem,
which is that of allowing border devices to act as proxies, agents,
interlopers, etc., for interior devices. Whether "border" and "interior"
are defined in IP topology terms for a given installation or in
authenticated identity and trust relationship terms is, I think,
immaterial. The point is not to *assume* that the actual endpoint (as
specified by the IP/port tuple) is going to be the one engaging in all
phases of the interaction on its own behalf, and to consider how that
non-assumption affects the protocol designs. 

That is, NAT has taught us a lesson. NAT is bad, but the lesson is good.
Don't throw the lesson out with the NAT.

Furthermore, I'm not asking anyone to solve the problem of how you
maintain those proxies or ALGs or whatever they are. I'm simply asking
folks not to build a world in which they cannot work without significant
"hackish" after-engineering.

   - Larry Rosensweig

---

From: Tripp Lilley <[email-masked]>
Date: Wed, 8 Dec 1999 02:23:15 -0500 (EST)

- Larry Rosensweig

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 1999 12:36:23 +0100

At 21:17 07.12.99 -0500, Daniel Senie wrote:

>serious firewall.

Right. Insecure devices require protection, always.

>  I have ZERO interest in allowing the kinds of things
>addresses each, instead of just a single host address?

If you do the "native" IPv6 address assignment, it's impossible to route on 
anything smaller than a /64.
You then have 2^63 addresses for manual configuration within the subnet, in 
addition to the ability to connect anything with a MAC address without an 
address clash.

So the answer is "yes".
--
Harald Tveit Alvestrand, EDB Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 1999 12:36:23 +0100

So the answer is "yes".

---

From: Daniel Senie <[email-masked]>
Date: Wed, 08 Dec 1999 10:58:50 -0500

> addition to the ability to connect anything with a MAC address without an

I'm still concerned that dialup and other such "end user" accounts will
be viewed as workstations to which single addresses will be assigned. I
know IPv6 is specified to require handing out blocks. I just wonder
whether that's how it'll happen.

From ARIN's policy: "Addresses for dial-up lines should be assigned from
the SLA block. It is expected that longer prefixes should be used for
non-permanent, single-user connections." How will providers interpret
this? ARIN's policy says "The minimum assignment to end-user
organizations is a /48." But how does one define "end-user customer?" If
cable modem and DSL users (perhaps even dialups) do get this much space,
I think we'll all be very happy to be able to do without NAT. Until IPv6
service is offered for dialup and cable/DSL, we can just guess.

---

From: Daniel Senie <[email-masked]>
Date: Wed, 08 Dec 1999 10:58:50 -0500

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Dec 1999 11:29:13 -0500

> that's an argument for better authentication technology, not for NAT.

Fully agreed.

Indeed, I doubt any average homeowner could effectively run a
firewall. It is necessary that the devices be secure ab initio, and
only communicate to properly authenticated and authorized
sources.

Perry

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Dec 1999 11:29:13 -0500

Fully agreed.

Perry

---

From: Ed Gerck <[email-masked]>
Date: Wed, 08 Dec 1999 09:34:47 -0800

"Perry E. Metzger" wrote:

> I doubt any average homeowner could effectively run a

And yet, there is a trend towards "personal firewalls". Linux
includes a firewall out of the box (with the ipfwadm and ipchains
components). Several products are on the market for Windows
-- see http://grc.com/su-firewalls.htm . One product is very
user-friendly, it seems to me that any homeowner could use it.

So, perhaps the same company could also make a NAT that
any homeowner could use?  Because if the problem of NATs is
easy of use, and this is the key being banged here (the NY  School
Board example, etc.) then it is a problem of design.  However,
if the problem is concept, in which way are NATs different
from gateways, conceptually speaking?  And, gateways are
useful, no?

Further, it seems to me that if NATs are to be blamed for the
demise of IPv6, or its ad eternum delay, then maybe this is
what the market wants -- a multiple-protocol Internet,
where tools for IPv4/IPv6 interoperation will be needed
... and valued.  A commercial opportunity, clearly.  Which
can, undoubtably, be put in a sound theoretical framework
for NATs, in network topology.  NATs do not have to be a
hack.  They seem to have been discovered before being
modeled, that is all.

So, much as I side with Perry's defense of IPV6 though, I
cannot side with a downplay of NATs in order to leave
more room for IPv6.  Indeed, NATs can help IPv6
interoperate... so, it is by definition, useful.  And firewalls are
IMO much more homeowner-friendly than "ab initio security".

So, we need to be careful otherwise the baby goes with the
baby water ;-)

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 08 Dec 1999 09:34:47 -0800

Cheers,

Ed Gerck

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 1999 11:50:59 -0600

Matt Holdrege wrote:
...
> rid of firewalls. At least not in our lifetimes.

Probably not; they are after all such attractive targets for attackers, and much more 
worth the effort than lightbulbs.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Dec 1999 11:50:59 -0600

Matt Holdrege wrote:
...

  Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 1999 17:47:59 +0100

At 10:58 08.12.99 -0500, Daniel Senie wrote:

>organizations is a /48." But how does one define "end-user customer?"

A /48 leaves 16 bits for subnetting, before you hit the 64 bits of flatspace.

>  If

That's for sure.

                    Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 08 Dec 1999 17:47:59 +0100

That's for sure.

                    Harald

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Dec 1999 20:03:17 -0500

> A /48 leaves 16 bits for subnetting, before you hit the 64 bits of flatspace.

And remember, if we ever need to, we can start subnetting the bottom
64 bits, at the loss of one form of stateless autoconf (which I'm
starting to find, in deployment, is too unpleasant to use on my nets anyway).

---

From: "Perry E. Metzger" <[email-masked]>
Date: 08 Dec 1999 20:03:17 -0500

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Dec 1999 23:25:41 -0500

> Board example, etc.) then it is a problem of design.  

NAT's problem is not ease of use.  NAT's problem is that they
break things in subtle ways.  Many users can install a NAT,
but fixing the problems caused by NATs is beyond the ability
of all but the most sophisticated users.  (and those who do
have the ability would far rather their time not be wasted
on such pursuits)

> However, if the problem is concept, in which way are NATs 
> different from gateways, conceptually speaking?  And, 
> gateways are useful, no?

NATs, backhoes, dynamite, carbon tetrachloride.  All of these are useful, 
in limited situations, by professional experts who know the risks of using
them and take adequate precautions to minimize the danger associated with 
their use.  That doesn't mean you should try using them at home.
 
> what the market wants 

perhaps.  but we should not confuse the market with intelligence, 
or "what the market wants" with sound design.  there is sometimes a 
rightness to "what the market wants" (meaning that the market is sometimes
wiser than widely publicized experts) but the market is not an infallable 
source of wisdom.  and the market cannot choose wisely if engineers and 
vendors don't provide it with good options.

> -- a multiple-protocol Internet,

if you do a cost-benefit analysis for NATs vs a large flat address
space you will alomst certainly find that NATs have a favorable
short-term benefit/cost ratio (for some cases) and a very unfavorable 
long-term benefit/cost ratio.  this might be fine if NATs are treated as
a short term hack or a method of transition to IPv6.  but if the 
market overinvests in NATs in the short-term there is some possibility
that you cannot reap the long-term benefits of IPv6.  the market
is not necessarily endowed with foresight (indeed, our economic
system seems to artifically and unwisely favor short-term gains), and 
hill-climbing strategies often do not yield good results.

>  And firewalls are

they shouldn't be thought of as mutually-exclusive;
they each need to exist and they need to work well together.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 08 Dec 1999 23:25:41 -0500

Keith

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 09 Dec 1999 09:03:36 -0600

> starting to find, in deployment, is too unpleasant to use on my nets anyway).

Ugh.  Ick.  You're not wrong, of course, but just ... "Yecchh."

---

From: "Matt Crawford" <[email-masked]>
Date: Thu, 09 Dec 1999 09:03:36 -0600

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Dec 1999 23:56:11 +0100

>from gateways, conceptually speaking?  And, gateways are

I like Einar Stefferud's gateway one-liner:
"All gateways lose information. Some do it more efficiently than others."

Someone once called this one "Alvestrand's equality":
"Gateways = Pain".

This was after too many years spent on email gateways.

                      Harald

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Dec 1999 23:56:11 +0100

Harald

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Dec 1999 00:25:53 -0800

> "All gateways lose information. Some do it more efficiently than others."

Technically, a gateway  is used to interconnect a number of independent
networks so that hosts in the networks can communicate with one another
*without any change* to the respective networks, usually by means of a
database in a programmable device or devices that perform automatic
address translation in transmission and/or address and name translation in
reception for each formatted message.

So, if I know Stef, he was not being against a system (gateway) that lets each
one "do their own thing" and yet all communicate.  His point was rather that
imperfection is a small price to pay for freedom ;-) ... and, the price is never
zero ;-))

> This was after too many years spent on email gateways.

:-) Communication results from the transfer of data.  Gateways are exactly the
opposite.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Fri, 10 Dec 1999 00:25:53 -0800

Cheers,

Ed Gerck

---

From: John Stracke <[email-masked]>
Date: Fri, 10 Dec 1999 12:12:04 -0500

> to everything in my home merely by having physical presence there.

Download an ActiveX control and your garage door opens and your security
system shuts down...

--
/=================================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.   |
|Chief Scientist |================================================|
|eCal Corp.      |You're just jealous because the voices only talk|
[email-masked]|to me.                                          |
\=================================================================/

---

From: John Stracke <[email-masked]>
Date: Fri, 10 Dec 1999 12:12:04 -0500