I'd say having excessively long lease time is not a good idea. The lease will change whenever someone changes MAC address. A potential malicious customer might therefore easily deplete your lease pool by sending requests with different MACs, and filling up the pool within the span of a few days.
That would be pretty tough to do. A lot of work changing spoofing MAC addresses with no reward. That is an interesting idea that I hadn't thought of, though.
It kind of reminds me of a problem we saw when I was in grad school in the 1970s. The school had an IBM mainframe and a couple of very bright undergrads I knew took note of the fact that the job numbers were all four digits long. Every time someone loaded another deck of cards, it would increment the number until it got until 9999 and then it would restart at 0100, skipping job numbers that were still in use. So their idea was to submit 10,000 jobs to the mainframe with each job waiting for a procedure before they could continue. They wanted to see if they could lock the machine down so that nobody could load another deck of cards until something was able to run.
Each job card at the start of the deck had a unique identifier. They started by duplicating the job cards but I pointed out to them that if it is possible for the computer operator to delete all jobs with that identifier then he could delete all their jobs with just one command. Each job was about four cards long and the other two cards were identical. So we wrote a FORTRAN program (of course) to generate the 10,000 card decks they needed.
On the appointed day, April 1 of 1979 or 1980 (I forget which year), they took their boxes of cards over to the computer center and started loading them about 7 pm. I wasn't back from out of town until about 10 pm so I missed it. Although the card reader could read the cards quite fast (normally a 1,000 cards just took a minute or so to read), there was a pause between each job and so it took them quite a while per box of 1,000 cards. After they got about 3,000 jobs read in, everything shut off for about 15 minutes and then started back up with all their jobs gone.
So for their weeks of planning and an evening of being a minor nuisance to other students waiting to do their homework, it ended up being somewhat anticlimatic.
Anyway, I have two reasons for using such long addresses:
1) Minor curiosity about how many individual connections we will see over the course of a few months. With a sufficiently long lease, I just have to count the number of entries in the lease file.
2) More importantly, if the DHCP daemon should crash and I don't notice it, the customers wouldn't need to renew their IP address leases. Being a small ISP, if I'm out of town and something goes down, it doesn't get fixed until I get back to town.
But it may be a good idea, just in case, to expand my subnet of 100.64/10 from a /16 to maybe a /14, just in case.
By the way, I'm getting ready to add three more NAT devices for the CGN. Each will handle a portion of the address space and have its own routable pool of about 50 IP addresses. Then if the server itself should crash, most everything could automatically switch to another NAT device. The customer units do a ping every 5 minutes to our gateway and if they miss 3 pings in a row, the devices reboot. When they reboot, then they will pick up an IP address from one of the devices aailable.
