I've gotten a rash of responses about the Static allocation of IP addresses to our SLIP/PPP customers. I'll look into that, however, I can't see much real gain for our situation, in that we probably will never exceed 2 class C's for our Static SLIP/PPP users. What I'd really like to hear is some critisisms about the prefixes in a later section of the document. Just so you have some background on this, we are going to be renumbering the following blocks into a single /18, dependent on the approval of the Internic. 2 blocks of /19 1 block of /20 1 block of /23 5 customer (I.E. internic allocated to customer) blocks of /24 and 1 customer block of /24, not yet routed. (These blocks will be returned to the issuing NIC after the renumber) Some people actually chastised me for not conserving number space with the SLIP/PPP issue, and being concerned for my own good instead of the good of the net. I'd really like to hear some opinions on whether the prefixes listed in one of the lower sections are reasonable to assume that they might be routed on the net, so we don't have to force our users to renumber yet again. As we reallocate blocks to customers, we are going to be auditing each customer's network use and plan and only allocate the size of subnets needed for the customer. Considering we have equipment that only handles RIP V1, this could prove to be interesting. SO, I'd ask that you take a look at the ENTIRETY of the original posting and ignore the Static SLIP/CSLIP/PPP section, and let me know what you think of the REST of the document. Thanks, forrestc@imach.com On Sat, 30 Sep 1995, D. Brian Kimmel wrote:
forrestc@imach.com writes
Standard Dialup SLIP, CSLIP and PPP customers will be allocated a Single Static IP Address to be used to configure their software. There are many advantages to be gained by Statically allocating the numbers, including the ability to have multiple mailboxes by using SMTP, etc.
How about a pool of dynamic addresses for most folks and static for only those who have a _real_ need for such a thing. That way you don't tie up a lot of addresses for occasional and casual users who have no _real_ need for static addresses.
Ease of configuration of software should not be a reason for static addresses.
Brian D. Brian Kimmel Kimbro, Inc. Voice: (206) 937-8381 Seattle, WA USA http://www.kimbro.com briank@kimbro.com Washington Internet Provider List http://www.kimbro.com/providers.html