Subject: RE: Why IPv6 is a must?

From: "Peter Ford" <[email-masked]>
Date: Mon, 12 Nov 2001 10:33:37 -0800

I disagree with Keith on some basic assumptions.  IPv6 is not a software
upgrade in its' dominant mode.   IPv6 was done with the belief that the
raw number of systems will grow huge enough that 2**32 is not enough.
There was this CIDR thing created to solve this other problem.

In terms of raw numbers, IPv6 deployment will take the form of hardware
purchases for IPv6 nodes that do not exist today:

1) Cell phones (historically <2 yr replacement cycle)
2) PCs with IPv6 installed (less than 5 yr replacement cycle)
3) new devices that plug into residential networks (mostly new)

We should note IPv6 has been planned, products have been built and
deployment will occur.  It is being driven by people who have a vested
interest in having a solution to the address run-out problem.

(good news in the last 10 years is that Internet has gotten really good
at deploying HTTP proxies, something we did not really bet on back in
1991/1992.   This is going to aid transition immensely as we move
forward).

I concur that the routing guys have some work in front of them.   May I
suggest people take a closer look at hierarchical routing, combined
provider and geographic hierarchies, and adult supervision?

Regards, peter

---

From: Keith Moore <[email-masked]>
Date: Mon, 12 Nov 2001 17:36:51 -0500

> upgrade in its' dominant mode.   

actually, I think we do agree.  *existing* systems can migrate to IPv6 
with a software upgrade, and it's important to have a story for existing
systems.. but my guess is that the vast majority of IPv6 systems in the 
long run will not be general-purpose computers (existing or new), but 
fixed-function appliances that will ship with IPv6 built-in.

Keith

---

From: "Rinka Singh" <[email-masked]>
Date: Mon, 26 Nov 2001 19:09:21 +0530

One question.

> 3) new devices that plug into residential networks (mostly new)

What stops the new devices from having v4 with NAT to translate between the
internet and the house.  I understand there's a security issues but then so
what.  I'm concerned that if this does happen then the migration to v6 will
slow down.

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Nov 2001 08:47:38 -0500

> internet and the house. 

nothing stops them, but if you want to access the devices from outside the
house (and in many cases that's the point of such devices) then NAT gets 
in the way.

Keith

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 26 Nov 2001 15:45:23 -0600 (CST)

> house (and in many cases that's the point of such devices) then NAT gets 

That's exactly why you want NAT/firewalling and other existing mechanisms.
These are devices that do not require global addressability. In fact they
SHOULD NOT be globally addressable.

IPv6 needs to be justified on the number of nodes that truly need a 
globally accessible public address, not by insisting on counting devices
that should remain anonymous or under limited (and controlled) visibility.

At times I suspect an administrative standard for uniquely referring
to a private IP address is a specific private IP network would have
been the only required improvement in global addressing.

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Nov 2001 15:43:24 -0500

> SHOULD NOT be globally addressable.

first, don't confuse NAT with firewalls.    they have entirely separate 
functions which often happen to be provided in the same box.  NAT provides 
very little additional security by itself, and you can implement any 
firewall function without doing address translation.

second, firewalls are not a general-purpose security mechanism. at best 
they are a means of decreasing the effort required to analye potential 
security threats.  they are not a substitute for implementing security
at the end system.

third, it seems quite presumptious for you to declare that someone else's
device or application does not, or should not, require global addressability.  
in fact there are numerous cases where global addressability is desirable.  
the needs of the network are more diverse than your security model can 
accomodate.

> that should remain anonymous or under limited (and controlled) visibility.

you appear to be confusing visibility with accessibility.
 
> been the only required improvement in global addressing.

that's because you aren't bothering to consider the needs of applications.

Keith

---

From: Caitlin Bestler <[email-masked]>
Date: Mon, 26 Nov 2001 17:25:59 -0600 (CST)

> you appear to be confusing visibility with accessibility.

No, that is exactly what I am not confusing.

If a node only requires accessibility by a few specialized nodes (such
as a water meter) then making it *visible* to more is just creating
a security hole that has to be plugged.

Yes, the hole can be plugged easily.

I am merely pointing out that the opportunity to add more rules to
an IPv6 firewall to plug a security hole that IPv6 created is *not*
an argument for IPv6.

Further, NAT boxes are very friendly to meter-type devices. They
can receive their IPv4 address via DHCP (eliminating the need
to administer addresses) and then they can contact the collection
server. The upper-layer protocols will identify the meter,
which they would have done for authentication reasons anyway.

There are also a large number of solutions using L2 tunneling.

My point remains, a globally meaningful address is something that
should only be applied when it is useful for that endpoint to
be globally addressable.

---

From: Keith Moore <[email-masked]>
Date: Mon, 26 Nov 2001 18:01:41 -0500

> a security hole that has to be plugged.

that's simply false.   security and visibility are largely orthogonal.

the fact that a resource is visible to the network simply means that it is 
potentially accessible, with appropriate credentials, by another party 
on the network.

the common mistake is assuming that accessibility should have something
to do with network topology, or more precisely, with source IP address.
this works only for a limited subset of applications and user communities.

while it might be reasonable to trust such mechanisms for limited-purpose
networks, it's simply naive to insist that such mechanisms are generally
applicable.

> Yes, the hole can be plugged easily.

again, that's simply false.

in general, if an application or an end-system has a security hole
that allows access by unauthorized parties, you can't plug that hole 
by external means.  you may be able to work around the problem using 
a firewall by exploiting network access patterns - for instance, if 
you know in advance that the only legitimate users of a resource are 
located within a particular subnet and you can ensure that the only 
traffic with that subnet's source address actually originated from 
within that subnet.  but this is an exception, not a general rule.

to insist that application security realms should be constrained to 
reflect network topologies is either to severely limit that kinds of 
applications that can be run or to make your network much more expensive
than it needs to be.  and this strategy doesn't hold up in a world
in which the devices you use access those resources may be attached
to the network via any of a variety of provider networks - and may also
need to be able to access resources on multiple networks.  folks aren't
going to carry separate PDAs to access the office email, the baby cam 
at the day care center, and the home security system.  they're going 
to carry a single PDA and expect it to authenticate to each, independently
of their current location.

> an IPv6 firewall to plug a security hole that IPv6 created is *not*

IPv6 doesn't create any new security holes.  to the extent that
holes exist in applications (and of course they do) that are worked
around by firewalls, it becomes necessary to apply the same filters
for IPv6 that exist for IPv4.  but the holes existed already.  

> Further, NAT boxes are very friendly to meter-type devices. 

false.  many such devices need to be accessible from outside the NAT.
furthermore, meter-type devices are only one kind of application that 
would benefit from global addressibility.

> They can receive their IPv4 address via DHCP (eliminating the need
> to administer addresses) 

DHCP is orthogonal to NAT.  You can have DHCP (for better or worse)
without NAT.  

> and then they can contact the collection server. The upper-layer 
> protocols will identify the meter, which they would have done for 
> authentication reasons anyway.

true, but it's irrelevant to your argument - unless you were somehow
presuming that the address would have been used for authentication.

> There are also a large number of solutions using L2 tunneling.

not if you want them to work in arbitrary remote environments.
 
> should only be applied when it is useful for that endpoint to

you haven't said anything to support such an outrageous assertion.

Keith

p.s. of course there are some vulnerabilities that are introduced
whenever you make a network accessible - these include the ability
to exploit security holes on hosts, the ability to scan for potential
targets, and the ability to attack the network itself.  but to the
extent that you can use firewalls to thwart such attacks, you can
do so without NAT.  about the only thing that NAT does for you is to
hide an "inside" client host's source address as seen from the 
outside. so you could say it provides a measure of privacy.
but it does this in a very inflexible way - it constrains all 
applications (regardless of their needs) on all hosts behind the NAT.
and once you install a NAT, it's very difficult to fix the problems
that the NATs caused.

---

From: Lars Eggert <[email-masked]>
Date: Mon, 26 Nov 2001 15:03:37 -0800

> a security hole that has to be plugged.

How do you control visibility? Authentication. How do you control 
accessibility? Authentication. What's the difference? Silently ignoring 
unauthenticated peers vs. replying "go away". Limiting visibility does 
not make a service more secure.

> should only be applied when it is useful for that endpoint to

I have a hard time coming up with *any* service that should be 
restricted to local-only at all times. If you believe that 
authentication works, you may as well make everything world-visible.

I do agree that firewalls can reduce the risk of exposing buggy service 
implementations to the world, e.g. risking buffer overflow attacks, etc. 
This has nothing to do with NATs, however, as others have already 
pointed out.

Lars
-- 
Lars Eggert <[email-masked]>               Information Sciences Institute
http://www.isi.edu/larse/              University of Southern California

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 26 Nov 2001 16:16:08 -0800

> should only be applied when it is useful for that endpoint to

This is your only valid point, and has nothing to do with NAT,
Firewalls, or anything else on this thread today... There are cases
where an application context calls for local scope addresses (like I may
not want my light switch available outside the home), but that is
exactly why IPv6 provides local link & site scope addresses. If you have
a device that is being used in a local scope application context, then
it should not acquire a global scope prefix.

At the same time there may be other applications sharing the wire that
are global scope (like my son and I run independent web servers). For
this context the global scope IPv6 addresses are exactly what is
required, because sharing a port doesn't work.

From my observations over time, the hardest thing for network
technologists to wrap their heads around is the fact that with IPv6
nodes are capable of multiple addresses simultaneously, and those
addresses have different scopes of applicability. It is a matter of
local policy which addresses get used, so match the address scope to the
use policy. In any case, stop saying that NAT is required to keep a node
hidden, because it is not. Also by definition if a NAT is aware of the
'hidden' device, the device is no longer hidden from the world.

Tony

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 27 Nov 2001 02:19:48 +0100

Caitlin writes:

> That's exactly why you want NAT/firewalling and
> other existing mechanisms.  These are devices
> that do not require global addressability.  In
> fact they SHOULD NOT be globally addressable.

That's exactly why you only need one telephone per family.  These are people who
don't need to be individually reachable.  The head of the household can have one
telephone, and he or she can just physically seek out whoever else in the family
is wanted and put that person in front of the telephone.

That's also exactly why you only need one telephone per business.  These are
employees who don't need to be individually reachable.  The receptionist can
have one telephone, and he or she can just physically bring any other employee
who needs to be contacted to the phone in the reception area.

> IPv6 needs to be justified on the number of nodes
> that truly need a globally accessible public
> address ...

IPv6, like any other expansion of the address space, is ultimately not something
that has to be justified, but simply something that cannot be avoided.

Additionally, the mere need for a unique public address doesn't even necessarily
justify IPv4.  After all, we don't yet have four billion computers on the
Internet.  But because of convenient but space-wasteful allocation policies for
the existing address space, we will appear to run out of addresses long before
the actual theoretical address space is exhausted, unless we resort to
allocating them sequentially until every slot is gone.

The allocation for IPv6 will inevitably be far more space-wasteful than that for
IPv4, human beings being the way they are, and so it will eventually be
exhausted as well, as hard as it may be to believe that now.

> ... not by insisting on counting devices that should
> remain anonymous or under limited (and controlled)
> visibility.

Similar arguments were advanced against private telephone lines.  The most
consistent and serious error made by engineers in designing new systems is
dramatic underestimation of the capacity that will ultimately be required.

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 27 Nov 2001 01:26:09 +0000 (GMT)

> Yes, the hole can be plugged easily.

deliberate lack of visibility deliberately precludes the possibility
of emergent behaviour and use by new applications that then become
widely deployed.

(never mind administrative changes in the network after the time the
hard-coded water-meter is built.)

> There are also a large number of solutions using L2 tunneling.

L2 tunnelling is a large number of new problems.

> should only be applied when it is useful for that endpoint to

I think we're lucky that this point was not applied to the design of
IP twenty-odd years ago. We'd then have a bunch of restricted gateways
that translate email - badly - no universal telnet, no universal ftp,
and certainly no web...

a requirement for immediate utility precludes future imagination and
creativity.

L.

'of what use is a newborn child?' - Faraday to a bunch of short-term
 thinking legislators on electricity.

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

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 27 Nov 2001 02:27:31 +0100

Caitlin writes:

> If a node only requires accessibility by a
> few specialized nodes (such as a water meter)
> then making it *visible* to more is just
> creating a security hole that has to be plugged.

Only if the information made thus available itself constitutes a security
breach, which is not necessarily the case.  Knowing how much water someone
consumes or how many cans of Coke remain in a distributing machine would
probably not be a security issue for most users, just as answering a ping on the
Internet today is not considered to be a security breach by most people (and
those who do consider it so can block it).

> My point remains, a globally meaningful address
> is something that should only be applied when it
> is useful for that endpoint to be globally addressable.

Unfortunately, if no provision has been made for a global address in the first
place, it may not be possible to put anything in place as quickly as required if
the need arises, and for critical applications, this is not acceptable.

---

From: Aidan Williams <[email-masked]>
Date: Tue, 27 Nov 2001 11:36:27 +1100

> SHOULD NOT be globally addressable.

"SHOULD NOT be globally addressable"?  Every conceivable device in
the home?  That's quite a broad policy to impose on home networks.

I draw two distinctions:
  - firewalling is a technology designed to implement policy
  - NAT is intended to enable connectivity

It is quite possible for globally addressable IPv6 devices to be firewalled
according to some policy, i.e. IPv6 supports *both* global connectivity
and security of the firewalling variety.

> that should remain anonymous or under limited (and controlled) visibility.

I think it was being justified on the basis of enabling connectivity,
specifically from outsite-the-home to inside-the-home.  This is a
problematic scenario for privately addressed IPv4 networks using NAT.

Also, there is no reason why IPv6 devices in the home can't decline
global addresses and stick with link-local or site-local addressing.

> been the only required improvement in global addressing.

Like RSIP?

- aidan

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2001 00:48:20 -0500

>>>>> "Anthony" == Anthony Atkielski <[email-masked]> writes:
    Anthony> That's exactly why you only need one telephone per family.
    Anthony> These are people who don't need to be individually reachable.

  Families are going toward a telephone per person with caller id and/or
distinctive ring to figure out who should answer. That sure sounds like NAT
to me!

  They would take a phone number per person, but someone there aren't enough
phone numbers available cheaply enough or a mechanism to communicate them to
the end-node to make this work.

  Mobile phone companies are offering cell phones for each member of the
family with calling plans.
  My wife and I possess a total of 5 telephone numbers (counting mobile and
pagers) because the phone company does not offer the equivalent of mobileIP.

  Plus her work number, at which I can't reach her after the receptionist has
gone home, and her mobile phone is non-functional due to building issues, but
that's okay since her patient's pace-makers prefer it that way.

    Anthony> That's also exactly why you only need one telephone per
    Anthony> business.  These are employees who don't need to be individually
    Anthony> reachable.  The receptionist can have one telephone, and he or
    Anthony> she can just physically bring any other employee who needs to be
    Anthony> contacted to the phone in the reception area.

  That works for some businesses perhaps. It fails in most white collar work.

  Ever try to get ahold of someone *AFTER THE RECEPTIONIST HAS GONE HOME*?

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Nov 2001 15:21:07 +0100

> On Mon, 26 Nov 2001, Caitlin Bestler wrote:
...
> that translate email - badly - no universal telnet, no universal ftp,

Actually, it *was* applied earlier (by default), and it was as a 
result of the ensuing disconnects and general uselessness that
the Internet (a.k.a. Catenet) concept was developed  by Pouzin,
Cerf and Kahn. NAT has simply pushed us back to the pre-1978
situation. The references are in RFC 2775, section 2.3.

   Brian

---

From: Ken Hornstein <[email-masked]>
Date: Tue, 27 Nov 2001 10:47:32 -0500

>that's okay since her patient's pace-makers prefer it that way.

Let me see if I understand this correctly ... your wife is behind a NAT
(the receptionist) and it's causing a denial of service? :-)

--Ken

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Nov 2001 14:01:00 -0500

> (the receptionist) and it's causing a denial of service? :-)

close.  the receptionist is an ALG.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 27 Nov 2001 14:30:13 -0500

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> close.  the receptionist is an ALG.

  Application Layer Gateway. Yes. that precisely true.

  Caused by the lack of ability to address the phone in her lab directly.
  PBXs with extensions are just the application layer gateways that speak DTMF.

  The point is that: the phone certainly should *NOT* be held up as an
example of a system that functions well despite lack of end-node
identification. In fact, large amounts of money have been spent (and made,
which is the problem - it created new opportunities, which people want to
exploit. Ditto for NAT) on the problem.

---

From: "Anthony Atkielski" <[email-masked]>
Date: Tue, 27 Nov 2001 22:33:00 +0100

Michael writes:

> Families are going toward a telephone per person
> with caller id and/or distinctive ring to figure
> out who should answer. That sure sounds like NAT
> to me!

How so?  Are they all using the same telephone number?

> They would take a phone number per person, but
> someone there aren't enough phone numbers available
> cheaply enough or a mechanism to communicate
> them to the end-node to make this work.

Where is this?

> My wife and I possess a total of 5 telephone
> numbers (counting mobile and pagers) because the
> phone company does not offer the equivalent
> of mobileIP.

So how is this anything like NAT?  NAT would be one telephone number.

> in most white collar work.

It fails in all businesses, in this century.

> RECEPTIONIST HAS GONE HOME*?

Ever try to connect to machine B when NAT insists in directing all incoming
connections to a given port on the one and only external IP address to machine
A?

---

From: Peter Deutsch <[email-masked]>
Date: Tue, 27 Nov 2001 15:02:37 -0800

Anthony Atkielski wrote:
> probably not be a security issue for most users...

I can't help myself.

Actually, having access to such stats as amount of power used, coke consumed,
late-night pizzas ordered from the Pentagon, or number of routine status
messages transmitted from ships of a specific call sign, can reveal a surprising
amount of detail.

It's fairly well known that the Americans had broken the Japanese codes during
World War II, but it's less well known that this was not a one shot break, but
an ongoing process of breaks, loss of capability and rebreaks. Periodically the
Japanese would reissue their code books and change the callsigns of their
various ships. The U.S. code breakers would then have to recreate their
penetration by identifying each vessel's new call sign, identify specific
message types and using these to rediscover the code groups.

One technique they had for this was to detect traffic patterns from specific
callsigns; by detecting similar patterns before and after the change, they could
identify specific ships. They could then attack the message traffic looking for
identical or similar messages, which in turn would lead to new breaks into the
system. Another technique was to monitor ambient traffic patterns. A spike in
traffic for a vessel or group would indicate potential upcoming operations,
especially if you were monitoring major capital ships.

Operations research has come a long way since then, and these or similar
techniques are now used in industry for marketing and sales purposes. U.S. law
enforcement was even using power consumption (as measured by infrared detectors)
as an indicator of potential pot growing in your hydroponic basement garden for
a while. This last one ran afoul of the illegal search and seizure bits of the
U.S. constitution but The World Is A Very Big Place and not everybody might be
as picky as the U.S. on such things.

The moral of the story? Traffic patterns and metadata can be powerful tools and
one person's junk is another person's data. You should not assume that the
majority of people shouldn't or wouldn't care about it leaking out, even if at
first glance it seems pretty mundane.

					- peterd

-- 
----------------------------------------------------------------------
Peter Deutsch                     work email:  [email-masked]
Director of Engineering
Edge Delivery Products
Content Networking Business Unit     private:  [email-masked]
Cisco Systems

  Many people can predict the future. Me, I can predict the past...

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

---

From: "Anthony Atkielski" <[email-masked]>
Date: Wed, 28 Nov 2001 01:03:48 +0100

> I can't help myself.

So I see.

> Actually, having access to such stats as amount
> of power used, coke consumed, late-night pizzas
> ordered from the Pentagon, or number of routine
> status messages transmitted from ships of a specific
> call sign, can reveal a surprising amount of detail.

Yes, but it does not necessarily reveal anything you wish to keep secret, and
even if it does, the traffic analysis required to recover the information may be
more costly than the information is worth.

> It's fairly well known that the Americans had
> broken the Japanese codes during World War II,
> but it's less well known that this was not a one
> shot break, but an ongoing process of breaks,
> loss of capability and rebreaks.

So I suppose anyone planning to bomb Pearl Harbor should use NAT.

> U.S. law enforcement was even using power consumption
> (as measured by infrared detectors) as an indicator
> of potential pot growing in your hydroponic basement
> garden for a while.

They need to recalibrate their equipment.  I don't have a garden.  I don't even
have a basement.

> This last one ran afoul of the illegal search
> and seizure bits of the U.S. constitution but
> The World Is A Very Big Place and not everybody
> might be as picky as the U.S. on such things.

The U.S. is getting pretty fast and loose on the respect of these rights, too.

> The moral of the story? Traffic patterns and metadata
> can be powerful tools and one person's junk is
> another person's data.

Sure ... but I really don't think that monitoring Coke machines or water meters
is likely to be a source of major security breaches.  And for anyone who feels
otherwise, there are firewalls, proxies, NAT, and so on.

> You should not assume that the majority of people
> shouldn't or wouldn't care about it leaking out,
> even if at first glance it seems pretty mundane.

I'm not merely assuming it, I'm certain of it.  Anyone willing to put his
signature on a charge slip that contains all his credit-card information is not
likely to care about someone monitoring his water consumption, and certainly if
he does then he has some pretty skewed priorities.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Nov 2001 20:06:19 -0500

> Actually, having access to such stats as amount of power used, coke 
> consumed, late-night pizzas ordered from the Pentagon, or number of 
> routine status messages transmitted from ships of a specific call sign, 
> can reveal a surprising amount of detail.

entirely agree.  and you can tell a lot about me by watching the
temperature sensors at my house 
(http://www.cs.utk.edu/~moore/home_temp.html)

security is potentially important for any device or service, no
matter how trivial it seems.  and since you can't rely on network 
topology to provide security, security has to be implemented
- at least partially - by the device itself.

Keith

---

From: "Anthony Atkielski" <[email-masked]>
Date: Wed, 28 Nov 2001 02:11:23 +0100

Keith writes:

> entirely agree.  and you can tell a lot about me by
> watching the temperature sensors at my house

Such as what?  Your home heating system cycles frequently, but that's about it.
I can't read the stuff in bright green.

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Nov 2001 20:14:19 -0500

> Such as what? 

that would be telling.

---

From: Sandy Wills <[email-masked]>
Date: Tue, 27 Nov 2001 21:19:53 -0500

Anthony Atkielski wrote:
> Keith writes:
> > .....and you can tell a lot about me by

   Well, for starters, he lists temperature in both F and C, so he's
probably not an "American".  In fact, he lists C first, so it's almost
certain that he's not 'Merkin.
   Also, the general locus of values for outside air temp would imply
that it's damned cold outside, so he's probably somewhere rather closer
to the North pole than I am.  Another conclusion, probably related to
this, is that he consistantly keeps his house significantly warmer than
the outside, so he is likely to be a mammal, a bird, or a reptile.

   What else?  Ah, yes.... investigating the periodic changes in outside
temperature, it becomes clear that it is, in fact, on a daily cycle, but
it's nothing like the skewed sine wave one would expect from a
sun-driven heat system.  It's more like a sawtooth waveform.
   Hmmm.  The temperature is lowest in late morning, long after the sun
would have started warming things up if his idea of "outside" involved
things that the sun would warm, but then it skyrockets upward until late
afternoon, whereupon it starts a slow drop back down.  Perhaps Keith's
outside air thermometer is _really_ outside, in full view of the sun,
but on the west side of his house so the sun doesn't start cooking it
until about 9 AM or so?  This would explain the absurdly fast
temperature rise that is both compressed, and delayed from normal
daylight heating hours.

   See?  Nothing more than a simple graph, and we have learned a great
deal about this "Keith" character (and probably more about the rest of
us).

   If his thermometers (and his thermostat) are available through the
web, perhaps we could run some tests here........  What kind of
experiments would we need to run, in order to tie this sub-thread back
into the security discussion?

-- 
: Unable to locate coffee.  Operator halted.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2001 11:10:27 +0100

Peter Deutsch wrote:
...
> first glance it seems pretty mundane.

Absolutely true. Nothing to do with NATs. Any router conceals internal traffic 
patterns. Any router can hide internal addresses that don't talk to the outside. 
All the NAT hides is the number of logically (not physically) distinct hosts 
inside that do talk to the outside. This is not security; it might hide
the IP address of your fridge, but it doesn't hide your fridge.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 28 Nov 2001 10:44:03 -0500

>>>>> "Sandy" == Sandy Wills <[email-masked]> writes:
    Sandy>    If his thermometers (and his thermostat) are available through the
    Sandy> web, perhaps we could run some tests here........  What kind of
    Sandy> experiments would we need to run, in order to tie this sub-thread back
    Sandy> into the security discussion?

  Are these thermometers tied at all to his furnace?

  If we can manipulate one (say the external one) either by putting foil
around it or insulation on top of it, can we cause his furnace to misbehave?
(Worse would be if we can do this with SNMP Set's...) 
  
  With finer resolution data we might be able to determine when he wakes up
in the morning, how late he is up each day. Why is the basement temperature
important? Maybe he has an office there? No, looks too cold.

  As for him being further north - I suspect that he is rather at higher
elevations as it does look cold for Kentucky. 

  As for the comments about C/F --- the presence of F at all means that he
was raised in the US. The presence of C means that he is an academic.

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Nov 2001 11:32:06 -0500

Brian> NAT has simply pushed us back to the pre-1978 situation. 

On the contrary, NAT has  allowed us to maintain global connectivity without
requiring every system  to have a globally unique address.   NAT is what has
prevented us from returning to the pre-1978 situation.  

That's not  to say  it wouldn't be  better to  have a million  more globally
unique addresses.  Sure  it would, unless that would  stress out the routing
system  unduly.  If  adding a  million more  globally unique  addresses will
stress out  the routing system, then  one might argue that  a solution which
provides the  addresses but doesn't  change the routing system  isn't really
deployable, and hence  doesn't really solve the addressing  problem. I think
this is the point  that Noel keeps trying to drive home,  and I'm not sure I
understand what the answer is supposed to be.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Nov 2001 17:48:42 +0100

Eric,

First of all we are talking about several billion more addresses.

Second, you're correct, the NAT kludge has allowed us to delay
IPv6, i.e. simulate global connectivity some of the time. But
it is hardly a strategy for the next hundred years.

IPv6 was designed to help address aggregation, i.e. at least to
start from a point not worse than CIDR. But it was a conscious
choice not to try to invent a new routing model at the same
time. We know that. We have to solve that, *and* we need the
several billion addresses too.

  Brian

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 28 Nov 2001 17:32:08 +0000 (GMT)

On Wed, 28 Nov 2001, Michael Richardson wrote:

> was raised in the US.

or communicates the data to people who are, for their convenience.

L.

which would be why I'm speaking English to you on this list, eh?

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Nov 2001 14:51:54 -0500

> prevented us from returning to the pre-1978 situation.

this is true only if you believe that 

- all applications should be client-server, 
- hosts can reasonably be partitioned into client-only hosts and server 
  hosts, and 
- the network can reasonably be organized so that all server hosts are 
  located outside NATs.  

i.e., it's true only if you believe that the Internet should be crippled.

it's rather odd to argue that a technology that partitions the network
into separate realms, such that the hosts in those realms can't talk to 
each other except by coincidence, is allowing us to maintain global 
connectivity.

Keith

---

From: Eric Rosen <[email-masked]>
Date: Wed, 28 Nov 2001 15:23:51 -0500

Eric> NAT is what has prevented us from returning to the pre-1978 situation.  

Keith> this is true only if you believe that [blah blah blah]

The  situation today  with NAT  is that  hosts in  separate realms  can only
communicate in 99% of the desired applications, though perhaps this falls to
80%  if  one  stubbornly  ignores   the  existence  of  tunneling  and  port
redirection.

Pre-1978,  you were  either directly  attached to  the Arpanet  or  you were
pretty much out of luck. 

You have to be very much in  the grip of a theory to regard these situations
as comparable. 

Granted, it's  easier to  talk about the  evils of  NAT than to  explain how
billions of  new routable addresses  are going to  be added to  the existing
routing system.

---

From: Keith Moore <[email-masked]>
Date: Wed, 28 Nov 2001 15:35:21 -0500

> communicate in 99% of the desired applications, 

to the extent this is true, it's only because the only applications 
that people become aware of, are those that can run over NAT.  many
more useful applications exist, but since they can survive only in  
less restricted environments, they aren't as well-known. 

> billions of  new routable addresses  are going to  be added to  the existing

if you're willing to constrain those billions of addresses to use
a single path to the net (as NAT does) then the existing routing
system does just fine.

Keith

---

From: "R.P. Aditya" <[email-masked]>
Date: Wed, 28 Nov 2001 13:58:35 -0800

> less restricted environments, they aren't as well-known. 

I agree entirely; I will just note, <sarcasm>curiously</sarcasm>, that the
"explosive growth" of the Internet coincides with the widespread desire for
access to a *few* "client-server" type applications. It's not clear that
growth in those applications cannot be satisfied by NATized environments. That
said, the network cannot be designed for just that paradigm of application.

I'm hoping there will be a different class of "killer application" that will
attract many more people to the Internet and more than likely, I suspect it
will _not_ be amenable to a NATized environment.

> a single path to the net (as NAT does) then the existing routing

We could also hope that the next set of "killer applications" be more
adaptable and carry sessions over multiple paths with multiple addresses at
the endpoints as end-host multihoming is likely to be more scaleable than the
present regime. That would mean not having to give up multihoming for future
applications and having to build shims for current ones if no "magic bullet"
routing system is found for IPv6 that allows multihoming as familiar as is
common under IPv4.

Anyone have an idea for robust source-address selection? anyone?

Adi

---

From: Lloyd Wood <[email-masked]>
Date: Wed, 28 Nov 2001 21:59:03 +0000 (GMT)

> 80%  if  one  stubbornly  ignores   the  existence  of  tunneling  and  port

for about 99% of *existing* desired applications. It's the limits on
future applications that are more of a worry.

Doesn't NAT basically enforce stateless client-server communication,
since anything more complex winds up demanding some form of ALG?

L.

---

From: Steve Deering <[email-masked]>
Date: Wed, 28 Nov 2001 20:58:04 -0800

>billions of  new routable addresses  are going to  be added to  the existing

It's not the size (of the address) that matters, but how you use it.

Whether you assign one IPv4 address per subscriber and make them use NAT,
or give them each a block of a zillion IPv6 addresses, the routing cost
is the same.

If you really believe it's the total number of addresses that determines
the size/cost of the routing system, you'd better start working on moving
the world away from IPv4 to IPv-1 with 17-bit addresses.

Steve

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Nov 2001 11:23:47 +0100

Eric Rosen wrote:
...
> billions of  new routable addresses  are going to  be added to  the existing

They're going to be added by aggregating them much more effectively than
for IPv4 (since the need for aggregation is understood from the start).
The hard part of the problem is mainly what's being discussed in the
MULTI6 WG, plus the issues in draft-iab-bgparch-02.txt

There's no news here. I'm not sure this thread is producing any new ideas.

  Brian

---

From: Eric Rosen <[email-masked]>
Date: Thu, 29 Nov 2001 08:36:13 -0500

Sure, in  theory one could add  zillions of new  globally routable addresses
without increasing the  size of the routing tables  in the default-free zone
at all. 

The skepticism is about whether there is (or even could be) a realistic plan
to make this happen.

---

From: "Meritt James" <[email-masked]>
Date: Thu, 29 Nov 2001 09:33:11 -0500

I wish to express doubt on the (as you mentioned in an aside) there
should be.  Consider what these addresses would be for and the
implications of THAT.

-- 
James W. Meritt CISSP, CISA
Booz | Allen | Hamilton
phone: (410) 684-6566

---

From: Steve Deering <[email-masked]>
Date: Thu, 29 Nov 2001 07:02:26 -0800

>The skepticism is about whether there is (or even could be) a realistic plan

What's the realistic plan to prevent the IPv4 routing table from growing
to 2^32 route entries?

Steve

---

From: Bill Manning <[email-masked]>
Date: Thu, 29 Nov 2001 08:19:47 -0800 (PST)

% At 8:36 AM -0500 11/29/01, Eric Rosen wrote:
% >Sure, in  theory one could add  zillions of new  globally routable addresses
% >without increasing the  size of the routing tables  in the default-free zone
% >at all. 
% >
% >The skepticism is about whether there is (or even could be) a realistic plan
% >to make this happen.
% 
% What's the realistic plan to prevent the IPv4 routing table from growing
% to 2^32 route entries?
% 
% Steve

	trolling again? :)
	Nothing, as long as I don't mind lengthy convergence times.

--bill

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Nov 2001 12:53:22 -0500

> % What's the realistic plan to prevent the IPv4 routing table from growing

it's about as reasonable as the question about the IPv6 routing table.

as long as the Internet grows, the routing table is going to grow also.
you might be able to slow the rate of growth, but forcing most of the 
internet into a tree structure has its own scaling problems.

the only benefit that IPv4 has over IPv6 (relative to routing table
size) is that IPv4 discourages growth of the Internet.

Keith

---

From: Bill Manning <[email-masked]>
Date: Thu, 29 Nov 2001 10:05:01 -0800 (PST)

% 
% > % What's the realistic plan to prevent the IPv4 routing table from growing
% > % to 2^32 route entries?
% > 
% >         trolling again? :)
% > 
% 
% it's about as reasonable as the question about the IPv6 routing table.
% 
% Keith
% 

back in the day, I told the CIDR/PIARA folks that it would be a good idea 
to plan for 2^32 entries in the routing system and was hooted from the
fora. :)

I stand in respect for Bill Fenner who has agreed to act as the routing area 
AD in guiding the effort to seek, prove, and deploy a reasonable routing solution.

--bill

---

From: Keith Moore <[email-masked]>
Date: Thu, 29 Nov 2001 17:16:48 -0500

> "Only"?  Please.
> An obvious benefits of v4 over v6 is that it is deployed.  

that's why I said "relative to routing table size".

Keith

---

From: "David R. Conrad" <[email-masked]>
Date: Thu, 29 Nov 2001 14:02:20 -0800

"Only"?  Please.

An obvious benefits of v4 over v6 is that it is deployed.  Another benefit
is the operational experience gained over the years running v4
infrastructures.  NAT, despite being the spawn of the devil, at the very
least leverages both of these advantages.

More realistically, some might consider IPv4 address allocation policies as
discouraging the growth of the Internet (I am not among them), but I remain
unconvinced IPv6 address allocation policies will be significantly
different in the aspects that cause people to be discouraged.  Most, if not
all, of the same people who are refused IPv4 address allocations will (or
should if we expect not to re-create the swamp) be refused allocations of
IPv6 addresses.

Rgds,
-drc