[TriLUG] Adding to the list of topics: IPv6

[William Sutton]

Just a few more questions for thought,,,

Most of the appliances (HVAC, fridges, etc) are presently entirely 
mechanical.  Even in a day and age when they are regulated by computer, 
they will still by nature be largely mechanical.  It's one thing for a 
tech in Pakistan to change the operating code; it's something else 
entirely for him to change the compressor :)

Like Magnus, I prefer my devices to be dumb.  They need to do the job, do 
it simply and reliably, and do it without extraneous bells and whistles.  
Yes, some technophiles will like being able to hack their refrigerator to 
order a case of beer when their Tivo tells them that the Super Bowl is 
coming, but the majority of folks out there will neither know nor care 
about such capabilities.

Likewise the cell phone/laptop/pda/digital camera argument.  As someone 
pointed out, communication between the devices themselves can be 
accomplished via non-ip systems (bluetooth, irda, wires, rf, whatever).  
Cell phones can already connect online, so your personal mobile setup 
could be routed through one of the above protos to the cell and up to the 
tower.  I can see business applications where this might be desirable, 
but, again, for the average Joe I don't see it making sense.

William

On 22 Jan 2004, Jon Carnes wrote:

> On Thu, 2004-01-22 at 01:22, William Sutton wrote:
> > I'm still not sure I want my appliances logging in and telling the 
> > manufacturer who-knows-what, but under the supposition that they do, I'm 
> > curious:  Why not have your appliances NAT'd behind the router for your 
> > house?
> 
> Well, how many houses run a firewall or have a NAT?  How many houses
> have a refrigerator?
> 
> The NAT argument is fine - you can get these things to work behind a
> NAT, but...
> 
> 1) That removes the functionality from the masses. Manufacturers would
> then be setting up these systems to work for only an elite few.
> That destroys your economy of scale and makes it too expensive to setup.
> 
> 2) The connection then becomes proprietary (or you've got to come up
> with a host of standards and ports for use through the NAT for every
> possible appliance - we already have - in it's simplest form it's called
> IPv6) 
> 
> 3) The onus of contact behind a NAT relies on the hidden computing
> device.  That's why Red Hat users have to run a special daemon that
> connects out at regular intervals looking for updates. If Red Hat could
> initiate the contact with the daemon then it could push out any security
> updates immediately!  Your machine wouldn't be sitting there with a
> vulnerability waiting for the RHN daemon to kick off its daily look-see
> for anything new.
> 
> 4) If every household with a refrigerator wants to run the service
> (behind a NAT), we will quickly run out of IP addresses (6+billion
> households vs. 4.3billion available IP's from the current IPv4).
> 
> 5) NAT is not the only way to secure a device against being hacked or
> probed.  You can setup the same type of protection on your router - only
> now you'll have the greater security provided by the use of IPv6 (the
> packet can't be spoofed - you know its true source, or at least it's
> entry point onto the IPv6 internet).
> 
> 6) It's much easier to make a secure stripped down OS for an appliance -
> especially if the device's OS doesn't use RAM accessible to the data
> store.
> 
> 
> > 
> > The example given for the HVAC is a good one:  keep your HVAC inside the 
> > router on a 192.168 address.  When it needs to log into Train's web site 
> > (for example), it makes a connection.  Once the connection is made, the 
> > remote site can carry on a chat over the connection.  If it's REALLY an 
> > issue, there are plenty of unassigned ports.  Designate ports for each 
> > class of appliance and default routers to forward those ports.  Mind you, 
> > I still don't think it's good idea to have outside sources controlling 
> > what my inside devices are doing, but even in the above scenario, I still 
> > don't see a compelling reason to assign a real IP address to each device.
> > 
> > Maybe I'm missing the point here, but it still seems to me that we're 
> > better served by not putting everything on a real, publicly accessible, IP 
> > address.
> > 
> > William
> > 
> > On 21 Jan 2004, Jon Carnes wrote:
> > 
> > > On Wed, 2004-01-21 at 14:52, William Sutton wrote:
> > > > PMBIB,
> > > > 
> > > > Just why do we want things like toaster, refrigerators, and toilets to 
> > > > have their own IP addresses?  Why, for that matter, do we want digital 
> > > > cameras and pdas to have their own addresses?  Workstations, servers, 
> > > > printers, and networking gear I can understand, but appliances?
> > > > 
> > > > William
> > > 
> > > This is a good question, and I hope my answer is equally as good...
> > > 
> > > First of all there are some items that most folks really want on the
> > > internet - Mobile phones are a great example. Mapping systems in cars
> > > are another example.
> > > 
> > > And then there are appliances like say a Heating/Airconditioning
> > > system....  I see a time in the future when your HVAC system alerts you
> > > to a systems failure and checks to see if it's under warranty (and with
> > > who) then logs in to a dispatch center for remote diagnoses and
> > > scheduling of a repair roll.  You even pay a maintenance fee just so
> > > that all this happens in the background while you are at work; by the
> > > time you get home, everything is back up and running again.
> > > 
> > > You buy a TV from Best Buy, and you actually pay that hoky Maintenance
> > > Fee, and with that you get remote diagnosis of any problems on your set,
> > > and the local TV schedules downloaded to your TV every week.  You even
> > > get remote upgrades via the net, like picture within a picture or V-chip
> > > type filtering.  While you are at work you can monitor what your
> > > children are watching on TV - you can even change the channel and then
> > > lock it remotely (or simply turn it off and lock it with a pass code).
> > > 
> > > Your Refrigerator will come with a bar code reader and will connect up
> > > to your favorite grocery chain (Lowes Food).  When you run out of milk,
> > > you'll push the request button and then scan the old milk carton in
> > > (before tossing it in the recycle bin).  Your Trilug buddies are coming
> > > over on Thursday, you'll want to stock up on that beer that Jim likes,
> > > so you login to the Refrigerator and scroll through the past inventory
> > > picking out that special beer and a few other things to be added to your
> > > order.  On your way home from work the next day, you drop by your
> > > favorite food store and everything is already bagged up and waiting for
> > > you.
> > > 
> > > Your camera has a nice built in buffer and it can store up to a 100
> > > large shots, and when it gets a nice signal for internet access it logs
> > > in remotely to your PC and dumps those shots in the buffer out to your
> > > harddrive.  You never load film, and you don't mess with wire hook-ups
> > > to your home-based PC or your walk-about tablet. You just take pictures
> > > and enjoy them.
> > > The photo frame on your desk logs into your PC remotely and draws from
> > > the new pictures and displays them one at a time for ten seconds each.
> > > Your wifes photo frame picks up the same pictures and she scrolls
> > > through them with a few taps and then sends four of them off to
> > > Grandma's photo frame device.
> > > 
> > > None of these things is from the future. They exist now, but they need
> > > the infrastructure and security that comes with IPv6 in order to
> > > function properly.
> > > 
> > > Jon Carnes
> > > 
> > > 
> 
>