Re: ARIN?

[owen () DeLong SJ CA US (Owen DeLong)]

> > 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.
Some minor technicalities:
        /32     Single host
        /31     Not feasible.  No host addresses, network and broadcast only.
        /30     Network, two hosts, broadcast.
        /29     Network, 6 hosts, broadcast.

> 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).
I think this misses the point.  ARIN doesn't require or want you to SWIP
your /30 and /32 allocations.  A network that small just doesn't require
that level of public contact visibility.  As you've pointed out, you'll
be doing most of the things that matter (from a contact perspective)
for those customers.  As such, it makes sense to use your larger block
contact information instead of SWIPing such small networks.  In fact,
I'd rather see ARIN move the SWIP requirement back to /26 or so.

> 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?
Yes.  You simply have to document the number of /30's you've handed out in
your application.  They've been quite willing to accept us allocating multiple
clasee C's to /30's just for point-to-point links.

> 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.
Although DBMS scaleability is an issue, it's not the driving one in my desire
to not SWIP small blocks.  In my opinion, the value of the information
contained in the SWIPs is minimal at best.

> 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.

We probably are pretty unlikely to fill the IPv6 prefix space.  Remember, the
prefix space is 8 octets.

Owen