Comments on Routing and Allocation Policy Wanted
Forrest W. Christian
forrestc at imach.com
Sat Sep 30 18:49:50 UTC 1995
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.
forrestc at imach.com
On Sat, 30 Sep 1995, D. Brian Kimmel wrote:
> forrestc at 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
> D. Brian Kimmel Kimbro, Inc. Voice: (206) 937-8381
> Seattle, WA USA http://www.kimbro.com briank at kimbro.com
> Washington Internet Provider List http://www.kimbro.com/providers.html
More information about the NANOG