[TriLUG] Adding to the list of topics: IPv6

Jon Carnes jonc at nc.rr.com
Thu Jan 22 09:57:09 EST 2004


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
> > 
> > 




More information about the TriLUG mailing list