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.
There are two purposes for SWIP. One is to provide contact information. And for that purpose, SWIPping /30 and /32, and many of our larger assignments, does not make much sense. The other purpose, however, is used to justify address space allocation. The majority of my larger networks are really no different than the /30's in terms of wanting to contact someone who really knows what is going on. The persons listed in the SWIPs for most of our networks have no idea what SWIP is, what ARIN is, or why you'd even bother to email or call them. If the only purpose of SWIP is to just provide a point of contact, then I really don't have very many SWIP templates to send in, if any at all.
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.
Of course some may argue that this is bad, and I acknowledge some issues, but in balance I find the advantages outway the disadvantages, so I have set up all my links that don't specifically need to reach the Internet in 172.30.0.0/16. When I do hand out real /30's, what I have done so far is send in an "aggregate SWIP" simply stating that the space is for /30's. At least something is on record for it. And this may be totally satisfactory.
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.
But I'm not trying to address the information availability issue. Instead, I am trying to address the network space justification issue. The only reason I do not my my own name as contact for the SWIPs for all my customers is so that they look like valid SWIPs that ARIN or my upstream can validate and verify the usage with. They can contact the customer listed and see if they really do exist and really are a customer of mine to be sure I am not just padding my network (and I am sure that practice goes on, so I would encourage such verification, at least on a spot-random basis). So how would you feel if the requirement to send in SWIP data was lifted so that only those networks allocated for resale, or otherwise have a specific and different point of contact, need to be SWIPped? Keep in mind this would mean that I would probably have about 4 or 5 of them, total.
We probably are pretty unlikely to fill the IPv6 prefix space. Remember, the prefix space is 8 octets.
And one of the needs for doing SWIP goes away at that point. ARIN will still have work to do as any space, no matter how large, still has to be managed. It will be a lot easier. It surely won't be any big deal to allocate a /96 to me in IPv6 space. Routing may become very interesting, though. -- -- *-----------------------------* Phil Howard KA9WGN * -- -- | Inturnet, Inc. | Director of Internet Services | -- -- | Business Internet Solutions | eng at intur.net | -- -- *-----------------------------* philh at intur.net * --