ARIN?

Tue Nov 10 18:39:39 UTC 1998

Roeland M.J. Meyer wrote:

> Lets look at this further. If we assume that only domain-name holders will
> manage their DNS entries and make them manage their individual users and
> hosts, the there'll be at least two hosts per domain (one server and one
> workstation). For a clean sub-net (/31), this burns four IP addresses
> (assuming a 1:1 domain/sub-net relation) for two hosts. That's also one
> busy server because there's no room for a router or anything else. It's not
> exactly efficient either.
> 
> Let's skip the intermediate example and go straight to a /29, because a /30
> isn't much better (6 ip addresses and four hosts, not much room there
> either). Now we have room for a router, file-server, print-server,
> web-server, and four workstations. This is a small office. I actually see
> the sense in ARIN not SWIPing smaller than a /29. This is the smallest unit
> that makes sense. Arranged differently, using NAT, one could have up to 7
> workstations and one production server in the Internet and any number of
> servers/routers in the intra-net (I actually don't see need for more than
> 30 of these. That would be a very data-intensive company). This should
> cover most small businesses. The trick is in finding out how many servers
> and workstations have to have internet visibility and how many are only
> there for infrastructure (intra-net).

Most small businesses don't want to deal with the details of managing a
name server, much less a file server.  They just want stuff that works
and want someone else to take care of that for them.  Of course there are
plenty of exceptions, but as the Internet is expanding from those who get
online first to those who are getting online later or even last, the
attitudes we find are very different.  Even among many technically inclined
people, they want someone else to do the dirty work.

I think only a handful of our customers do their own DNS.  And then I think
it is because their network integrator just set it up that way.  But we are
moving into that market territory (network integration) and will probably be
doing the DNS for the vast majority of our customers (we are now, anyway).

Our customers are also becoming more security conscious.  That doesn't mean
they want to run their own firewall; they still want us to do so.  But it
does mean they are well prepared, and in our experience very happy, to keep
the Internet at "arms length" in the office.

Home offices, small offices, and even up to some medium sized corporations
are interested primarily in these few things:
    1.  E-mail access
    2.  Web surfing access
    3.  An online web site

One server with 2 ethernet NIC cards can serve a small office easily.  It can
be the POP/IMAP mail server for the LAN, and it can be the web proxy server
to allow them to surf the web.  Some customers actually want to disallow web
access and that can certainly be easily accomodated.

A few do want some other stuff, like an FTP server (for example printing
companies receiving large documents from their customers, and engineering
tooling companies receiving CAD files for very complex machine parts).
Although not a regular demand, even these things can be accomodated on
just one server.

Only a couple customers actually want to run their own web site from their
own connection.  Otherwise, their web sites are usually run either by us or
some outside web hosting provider.  If they do want to run their own web
site, we can make the site appear at the IP address of their firewall server
whether it is actually served there or on another server in their LAN.

Most of these customers use 64K or 128K dedicated ISDN.  We usually set them
up with a Pipeline 50 or 75 auto-dialing to one of our Ascend Maxes.  This is
done using an unnumbered link.  The max has one IP address on our LAN, and
the address of the remote router is the address it has on the crossover "LAN".
This uses exactly TWO addresses, one for the router and one for the server.
This fits a /30 exactly.  So we assign our space in units of /30 for these
customers.

A few customers are starting to use NAT in the router itself.  This can be
configured so that you can still run servers, and even do so on different
machines.  NAT can be configured to translate to different IP addresses based
on the port number.  We only have a couple of these customers right now, but
this looks to be a somewhat popular approach.  Those that do not have any
servers at all can get their IP from the dialup pool.  Those that do have
one or more servers need a static IP, and they get ONE ... so it's a /32.
Only if they have more than one server that needs to be reached on the same
port would we need to give them more space than that.

I'm also working on packaging a Linux box that runs off a CDROM, using hard
disk space only for storage, such as mail spool, which will be able to dial
in using ISDN (I may be looking at Frac-T1 or Frame Relay for this next) and
do all the above mentioned services, and maybe even IP masquerading on top
of that, all with a single static IP address ... again just a /32.

I have a few /30 and /32 customers now.  And I expect the ratio by customer
count to not only increase, but to overtake the number of customers with
larger networks.

Thus I expect to eventually have a substantial number of /30 and /32 "networks"
to SWIP to ARIN.  Perhaps this is not the appropriate way for ARIN to actually
handle it.  A /32 is not usually even thought of as a network, but maybe we
need to re-think our ways.

If the number of /30 and /32 SWIPs to ARIN would overwhelm their database,
then I would refer to that as the very justification, based on the numbers,
to do so.  If there are that many /30 and /32 assignments, then they do need
to be considered when ARIN is evaluating new allocations of network space.
They need to be considered not just for the volume of usage, but also for
the effort to keep the space usage at minimal and efficient levels.  Those
who do more /30's and /32's, IMHO, do justify more space when they do reach
then end of what they have (which hopefully won't be as soon).

What if an ISP dealt exclusively in just customers that wanted these server
based connections?  Would an ISP with 2000 /30's be able to come to ARIN
and ask for more space because their /19 was nearly full?

> We've now cut down our worst-case scenario, by a factor of eight, to
> 536,870,912 sub-nets. Even if we assume 2048B per RDBMS entry that comes
> out to 1,099,511,627,776 (1.1TB). Hmmm, that's a bit out-there, but do-able
> for Oracle. The disk system (15 cascaded RAID5 sub-systems at 100GB each)
> should cost about $150KUS at today's prices. However, notice that this is a
> worst-case maximum use scenario. We are nowhere near there yet. Kim should
> have a better idea, but the real numbers should be one quarter of that,
> present utilization, allowing for pre-assigned ip-blocks, and the swamp.
>
> Notice something else, I just talked my-self out of SWIPing anything less
> than a /29 and backed into the probable reason ARIN doesn't SWIP anything
> less that a /29. Kim; this is NOT an obvious line of reasoning, but is
> probably what your analysts went through. You'd catch a LOT less flack if
> y'all published these things.

Perhaps a better solution is a distributed SWIP database.  Perhaps a SWIP
record can be added to DNS to indicate the name of the server to query for
detail information by network.  It would then co-exist along side the PTR
records.  Appropriate SWIP lookup clients would resolve for SWIP data in
the in-addr.arpa space and then query that server (or servers) for the real
data about the network in question.

IPv6 will probably force the issue, anyway, since it opens the door to
what will at least today be a nearly infinite address space.  Try putting
that on few terabytes of Oracle.

-- 
 --    *-----------------------------*      Phil Howard KA9WGN       *    --
  --   | Inturnet, Inc.              | Director of Internet Services |   --
   --  | Business Internet Solutions |       eng at intur.net        |  --
    -- *-----------------------------*      philh at intur.net       * --