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 Servicespkrause@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 | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+