[comp.admin.policy] IP Number management

pkrause@triton.unm.edu (Paul Krause CIRT) (05/22/91)

Perhaps this is a good group for a discussion of IP number management.  I
posted to comp.protocols.tcp-ip without much response.  

We have several thousand numbers out there and while we have a database of
who is assigned each number, it is static.  With the way people 
move around, hard drives get trashed, employees are hired or replaced, etc.
the data gets stale real fast. 

I gather that dynamic solutions are technically difficult (and probably not
real intersting to non administrative types).  

Any comments, suggestions, words of wisdom?

Paul
pkrause@triton.unm.edu
 

paw@eleazar.dartmouth.edu (Pat Wilson) (05/22/91)

pkrause@triton.unm.edu (Paul Krause CIRT) writes:

>We have several thousand numbers out there and while we have a database of
>who is assigned each number, it is static.  With the way people 
>move around, hard drives get trashed, employees are hired or replaced, etc.
>the data gets stale real fast. 

It's never occurred to me to assign IP numbers to _people_ rather
than machines - what are your reasons for doing things this way?
How does a hard drive getting trashed affect the IP number, anyway?


-- 
Pat Wilson
Systems Manager, Project NORTHSTAR
paw@northstar.dartmouth.edu

verber@pacific.mps.ohio-state.edu (Mark Verber) (05/22/91)

In article <1991May21.203820.11396@ariel.unm.edu> pkrause@triton.unm.edu (Paul Krause CIRT) writes:

   Perhaps this is a good group for a discussion of IP number management.  I
   posted to comp.protocols.tcp-ip without much response.  

I am sure that IETF has a working group that is looking at this.  I don't
recall which group it might be.. but I assume UNM has someone who has been
involve with IETF and can help you out.

   We have several thousand numbers out there and while we have a database of
   who is assigned each number, it is static.  With the way people 
   move around, hard drives get trashed, employees are hired or replaced, etc.
   the data gets stale real fast. 

Well... this is one of the reasons for subnets and delegated
authority.  Except in very rare situations there should be no need for
a central database with 1000s of IP addresses.  In the university
environment let departments colleges, or whatever division of labor
makes sense in your environment to take responcibility for pieces
of your address space.

Having people move around is a good reason *not* to bind IP addresses
to people.  It would be routing hell.  I don't see why hard drives
getting trashed should change IP number.


Mark Verber
Ohio State Physics Dept / Computing Services

pkrause@triton.unm.edu (Paul Krause CIRT) (05/23/91)

In article <1991May22.130444.1410@dartvax.dartmouth.edu> paw@eleazar.dartmouth.edu (Pat Wilson) writes:
>It's never occurred to me to assign IP numbers to _people_ rather
>than machines - what are your reasons for doing things this way?
>How does a hard drive getting trashed affect the IP number, anyway?
>-- 
>Pat Wilson
>Systems Manager, Project NORTHSTAR
>paw@northstar.dartmouth.edu

When people change offices they usually take their equipment with them.  I find
that a name is often very usefull in finding a particular machine.  Hard drives
get invloved when John Doe accidently erases his and asks Jane Doe if he can
copy the files from hers.  Now they both have the same number.  However, Jane
doesn't use hers much so they never happen to conflict.  Jane gets a job in
another department of the university where they buy her a new pc and she gets
another IP number.  Harry is hired to replace Jane, he likes his pc so now
we get a call from John that he is having conflict problems. 

Paul

kludge@grissom.larc.nasa.gov ( Scott Dorsey) (05/23/91)

In article <1991May22.171817.21820@ariel.unm.edu> pkrause@triton.unm.edu (Paul Krause CIRT) writes:
>When people change offices they usually take their equipment with them.  I find
>that a name is often very usefull in finding a particular machine.  Hard drives
>get invloved when John Doe accidently erases his and asks Jane Doe if he can
>copy the files from hers.  Now they both have the same number.  However, Jane
>doesn't use hers much so they never happen to conflict.  Jane gets a job in
>another department of the university where they buy her a new pc and she gets
>another IP number.  Harry is hired to replace Jane, he likes his pc so now
>we get a call from John that he is having conflict problems. 
>
>Paul

   Oh my god.   This is a joke, right?
--scott

pkrause@triton.unm.edu (Paul Krause CIRT) (05/23/91)

In article <1991May22.201938.6749@news.larc.nasa.gov> kludge@grissom.larc.nasa.gov ( Scott Dorsey) writes:
>In article <1991May22.171817.21820@ariel.unm.edu> pkrause@triton.unm.edu (Paul Krause CIRT) writes:
>>When people change offices they usually take their equipment with them.  I find
>>that a name is often very usefull in finding a particular machine.  Hard drives
>>get invloved when John Doe accidently erases his and asks Jane Doe if he can
>>copy the files from hers.  Now they both have the same number.  However, Jane
>>doesn't use hers much so they never happen to conflict.  Jane gets a job in
>>another department of the university where they buy her a new pc and she gets
>>another IP number.  Harry is hired to replace Jane, he likes his pc so now
>>we get a call from John that he is having conflict problems. 
>>
>>Paul
>
>   Oh my god.   This is a joke, right?
>--scott

Only a little.  We have had multiple cases of people erasing their hard drive
and copying all the files from someone else with a resulting conflict.  We 
did have an employee quit, another person start using his machine and him
then coming back and getting a 2nd number.  It does not require a large
intuitive leap to envision more "interesting" problems that I don't know
about yet.
Paul

merlyn@iwarp.intel.com (Randal L. Schwartz) (05/23/91)

In article <1991May22.224555.2248@ariel.unm.edu>, pkrause@triton (Paul Krause CIRT) writes:
| Only a little.  We have had multiple cases of people erasing their hard drive
| and copying all the files from someone else with a resulting conflict.  We 
| did have an employee quit, another person start using his machine and him
| then coming back and getting a 2nd number.  It does not require a large
| intuitive leap to envision more "interesting" problems that I don't know
| about yet.

You know, if the boxes supported RARP, and you had a RARP server, you
wouldn't have these problems.  Ether addresses are pretty darn unique
and can't be copied just by copying hard disks.

Just another network admin,
-- 
/=Randal L. Schwartz, Stonehenge Consulting Services (503)777-0095 ==========\
| on contract to Intel's iWarp project, Beaverton, Oregon, USA, Sol III      |
| merlyn@iwarp.intel.com ...!any-MX-mailer-like-uunet!iwarp.intel.com!merlyn |
\=Cute Quote: "Intel: putting the 'backward' in 'backward compatible'..."====/

phil@inetg1.ARCO.COM (Phil Meyer) (05/23/91)

In article <1991May21.203820.11396@ariel.unm.edu>, pkrause@triton.unm.edu (Paul
Krause CIRT) writes:
> Perhaps this is a good group for a discussion of IP number management.  I
> posted to comp.protocols.tcp-ip without much response.  
> 
> We have several thousand numbers out there and while we have a database of
> who is assigned each number, it is static.  With the way people 
> move around, hard drives get trashed, employees are hired or replaced, etc.
> the data gets stale real fast. 
> 
> I gather that dynamic solutions are technically difficult (and probably not
> real intersting to non administrative types).  

Here at ARCO, we are beginning to use DNS to help break up our networks into
smaller more managable sub-domains.  The admin. of each sub-domain is now able
to assign IP address at will, without having to contact the MIS IP address
aministrator.  The use of DNS (domain name service) will automatically update
the tables at the central name server, thus providing a current listing (within
one hour of reality) on demand.

The downsides to DNS are many: SAs must learn DNS, sendmail needs some work,
users don't like using fully qualified host names, etc., etc..

I would also be interested in other peoples solutions.
-- 
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Phil Meyer         phil@arco.com  Work:(214) 754-6805                      |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+

buckaroo@medisg.Stanford.EDU (Matthew N. Petach) (05/24/91)

In article <1991May22.171817.21820@ariel.unm.edu> pkrause@triton.unm.edu (Paul Krause CIRT) writes:
>In article <1991May22.130444.1410@dartvax.dartmouth.edu> paw@eleazar.dartmouth.edu (Pat Wilson) writes:
>>It's never occurred to me to assign IP numbers to _people_ rather
>>than machines - what are your reasons for doing things this way?
>>How does a hard drive getting trashed affect the IP number, anyway?
>>-- 
>>Pat Wilson
>>Systems Manager, Project NORTHSTAR
>>paw@northstar.dartmouth.edu
>
>When people change offices they usually take their equipment with them.  I find
>that a name is often very usefull in finding a particular machine.  Hard drives
>get invloved when John Doe accidently erases his and asks Jane Doe if he can
>copy the files from hers.  Now they both have the same number.  However, Jane
>doesn't use hers much so they never happen to conflict.  Jane gets a job in
>another department of the university where they buy her a new pc and she gets
>another IP number.  Harry is hired to replace Jane, he likes his pc so now
>we get a call from John that he is having conflict problems. 
>
>Paul


Wouldn't it seem more reasonable to use BootP to obtain IP addresses?
That way all numbers are allocated dynamically, and there is no
problem with potential conflicts (unless someone manages to copy the
PROM from one interface to another, so the hardware addresses are the
same).

Matt Petach
Information Systems Group,
Stanford University Medical School

-- 
************************************************************************
Alaric Morgan Kestrel   |buckaroo@med, mpetach@portia (.stanford.edu)    
"For every problem, there exists a simple and elegant solution which is 
absolutely wrong." -- J. Wagoner, U.C.B. Mathematics

russell@ccu1.aukuni.ac.nz (Russell J Fulton;ccc032u) (05/24/91)

merlyn@iwarp.intel.com (Randal L. Schwartz) writes:

>In article <1991May22.224555.2248@ariel.unm.edu>, pkrause@triton (Paul Krause CIRT) writes:
>| Only a little.  We have had multiple cases of people erasing their hard drive
>| and copying all the files from someone else with a resulting conflict.  We 
>| did have an employee quit, another person start using his machine and him
>| then coming back and getting a 2nd number.  It does not require a large
>| intuitive leap to envision more "interesting" problems that I don't know
>| about yet.

>You know, if the boxes supported RARP, and you had a RARP server, you
>wouldn't have these problems.  Ether addresses are pretty darn unique
>and can't be copied just by copying hard disks.

This is exactly how we tackled this problem execpt that we use bootp rather
than RARP. We have a lot of publicly accessable PC attached to the net which
are used either on Novell or as terminals to bigger systems (We have every
from MVS on down :-(.) and we had constant problems with people swapping
boot disks around and so on. What we do now is have the termial emulator 
software on a Novell server and use bootp to serv IP addesses. With bootp
you can get about 80 chars of other infomation as well (intended to supply
name of boot program and parameters etc) and we use this to tell the 
terminal emulator various details about the hardware it is running on eg.
what type of keyboard the machine has. This approach also means that we 
can upgrade the software by relplacing one file rather than driving the 
technicians to distraction by changing the disketts in dozens of PCs.

We are also encouraging private users of PCs to register with us so they
don't have to worry about their configuration files. 

BTW we are running a locally written terminal emulator with the IP stuff
borrowed from NCSA telnet, which has support for both RARP and BOOTP.

People with UNIX workstation are *assumed* to know what they are doing :-)
and IP address for these are allocated on a departmental bases like others
have described.


-- 
Russell Fulton, Computer Center, University of Auckland, New Zealand.
<rj_fulton@aukuni.ac.nz>

trier@usenet.INS.CWRU.Edu (Stephen C. Trier) (05/28/91)

What we use around here is BOOTP.  IP addresses are assigned to ethernet
cards, and BOOTP handles the translation when the IP subsystem starts up.
We have a user database that has (almost) every ethernet card in it, so
we can easily search by ethernet address and get the owner of the computer
or the department contact person for computer services.  It works well,
except for the occasional department that does networking themselves or
hires an outside consultant.  The outside consultants never seem to realize
that on a network of thousands of computers, we might want a database of
ether addresses!  :-)

All PC and Mac software is distributed with BOOTP as its default system.
Users routinely copy the software from each other, and as long as they
use a driver that matches their card, there are no problems.  Redundandant
BOOTP servers are provided, scattered across several network segments for
reliability.

Unix and VMS machines do not use BOOTP.  This hasn't been a problem (yet).

-- 
Stephen Trier                        Work: trier@ins.cwru.edu
Case Western Reserve University      Home: sct@seldon.clv.oh.us
Information Network Services

phil@inetg1.ARCO.COM (Phil Meyer) (05/29/91)

In article <1991May28.051212.10733@usenet.ins.cwru.edu>,
trier@usenet.INS.CWRU.Edu (Stephen C. Trier) writes:
> What we use around here is BOOTP.  IP addresses are assigned to ethernet
> cards, and BOOTP handles the translation when the IP subsystem starts up.
> We have a user database that has (almost) every ethernet card in it, so
> we can easily search by ethernet address and get the owner of the computer
> or the department contact person for computer services.  It works well,
> except for the occasional department that does networking themselves or
> hires an outside consultant.  The outside consultants never seem to realize
> that on a network of thousands of computers, we might want a database of
> ether addresses!  :-)
> 
> All PC and Mac software is distributed with BOOTP as its default system.
> Users routinely copy the software from each other, and as long as they
> use a driver that matches their card, there are no problems.  Redundandant
> BOOTP servers are provided, scattered across several network segments for
> reliability.
> 
> Unix and VMS machines do not use BOOTP.  This hasn't been a problem (yet).

UNIX systems can use rarp (reverse arp) for determining IP address.  On SUNOS
you can set up /etc/ethers on your NIS master to do this.  The new preinstalled
SUN systems will configure themselves (including IP address) when you first
plug them in, *IF* their ethernet address is in ehters, and you have already
assigned them an IP address in the hosts database.  Pretty cool stuff.

bootp is used for software distribution on SGI machines, and they are certainly
UNIX machines.  VMS can also use bootp to distribute software.  We use bootp
from VMS machines to load stuff like LANWORKS to all of our Macs.  Of course,
nearly all Xterminals can use bootp to load software, and all of ours use bootp
to boot up initially.

The problem with automatic assignment of IP addresses comes into play with
routers and sub-domains.  I would love to take my machine to a conference room
in another part of our complex and have it work, but NIS just doesn't work that
way.  So no matter what I do, some kind of re-configuration is required before
my machine will work in a conference room (or any other room) outside of my
physical subnet.  This is a necessary evil.  There is a price to pay for
keeping network bandwidth reasonable (routing), and easier systems managemant
(NIS).  You sacrafice convenience.
-- 
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+
| Phil Meyer         phil@arco.com  Work:(214) 754-6805                      |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+