Re: Comments on Routing and Allocation Policy Wanted

["Forrest W. Christian" <forrestc () imach com>]

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