Clearly some of Matthew's customers are concerned with privacy, and wish to restrict the knowledge of their connection to the Internet, or some set of information related to that connection. So they wish the publicly- available information to be "sanitized". The NIC already has to base part of it's evaluation of address space use on methods other than SWIPs and RWHOIS data for address space allocated to the service provider which has been used internally by that organization. Could not the provider make the assignments to the customer "care of" the provider itself, listing a customer ID or similar, to meet the customers' wishes of privacy; then under an NDA, identification of these customers, with detailed contact info, could be made to the InterNIC? In a previous message, Kim Hubbard wrote:

...

Matthew,

The InterNIC bases additional allocation blocks on efficient utilization. We can only see the utilization from your SWIPs and RWHOIS info. If you refuse to supply contact information on your assignments, how can we tell what your utilization is?

And as for the routing table overload, although the initial allocation may be relatively small, it is almost always reserved from a larger block.

Bottom line, to receive additional address space all you have to do is the same thing everyone else does - submit reassignment information. You don't have to fly out here, you don't have to be nice to me, just follow the basic policies.

Regards,

Kim Hubbard InterNIC Registry

-- David Carmean WB6YZM DC574 <dlc@silcom.com> System/Network Administration, Silicon Beach Communications Unsolicited commercial e-mail not accepted. Violators will be LARTed.

David, Let's say, hypothetically speaking, that every ISP decides to do this. What's to stop some ISPs from listing a bunch of companies that are not their customers and are not really receiving address space from them for the purpose of getting more address space. Let's say I am an ISP and I receive a /19. All I have to do is go through the yellow pages and list a bunch of companies and their addresses because no one is going to see this any way except the InterNIC and they're certainly not going to start phoning every ISP customer to verify they are a customer. And just in case, I'll go ahead and list myself as the POC in case they do decide to call. Having the information public is one way to at least *attempt* to keep things honest. Kim

Clearly some of Matthew's customers are concerned with privacy, and wish to restrict the knowledge of their connection to the Internet, or some set of information related to that connection. So they wish the publicly- available information to be "sanitized".

The NIC already has to base part of it's evaluation of address space use on methods other than SWIPs and RWHOIS data for address space allocated to the service provider which has been used internally by that organization.

Could not the provider make the assignments to the customer "care of" the provider itself, listing a customer ID or similar, to meet the customers' wishes of privacy; then under an NDA, identification of these customers, with detailed contact info, could be made to the InterNIC?

In a previous message, Kim Hubbard wrote:

...

...

Matthew,

The InterNIC bases additional allocation blocks on efficient utilization. We can only see the utilization from your SWIPs and RWHOIS info. If you refuse to supply contact information on your assignments, how can we tell what your utilization is?

And as for the routing table overload, although the initial allocation may be relatively small, it is almost always reserved from a larger block.

Bottom line, to receive additional address space all you have to do is the same thing everyone else does - submit reassignment information. You don't have to fly out here, you don't have to be nice to me, just follow the basic policies.

Regards,

Kim Hubbard InterNIC Registry

-- David Carmean WB6YZM DC574 <dlc@silcom.com> System/Network Administration, Silicon Beach Communications Unsolicited commercial e-mail not accepted. Violators will be LARTed.

Since people seem interested in personal stories and anecdotes about the struggle for IP allocations, I'll leap in headfirst and mention our struggles from back in February of this year... (I'm leaving Chris and Kim's remarks included at the end of this, as further emphasis, and as a restating of what I found out in attending the Feb. NANOG meeting--Kim really is a real person, not a huge, pale-skinned vampire attempting to suck the life out of quivering little ISP's. :-) We went through the same problems at the beginning of the year; our growth rate was ramping up exponentially, our customer base was doubling twice as fast as we had expected, we were running low on address space in our existing blocks, and we begged for more. We had been lax in the recent use of SWIP entries for many of our blocks, because we issue /32's for ISDN terminal adapters, and figured "we don't need to mark those, because there's no way to indicate ownership of the /24 properly." When our requests were turned down time and time again, we blew up--I mailed Mark, Kim, and anyone else I could think of, I called, I moaned, I wept, and finally I bit the bullet, and downloaded a very early, barely supported beta version of rwhois, and wept and cried and pulled my hair out some more. It seemed ridiculous to try to put all the data in, but as it turned out, three weeks of putting our records straight, looking information up, and then finally sending a long list of referral records to the NIC, pointing to our newly installed rwhois server paid off, they agreed we had met the requirements, and allocated our next block to us. (I'm skipping the intervening pain and suffering I went through in getting 6000+ records into the early version of rwhois--those of you on the rwhois mailing list can read through the archives and relive the experience yourself. At the Feb. NANOG, I met not only Kim herself, sans fangs, but also Mark, who I gave several pieces of my mind to, for the state and condition of the rwhois code. I will congratulate him, and the rest of his team, on getting the code into a far more usable state, but it's still not yet to the point of being trivial to implement at an ISP. At least they're listening, and working on improving it now. :-) Anyhow, in meeting Kim down in San Diego, I realized she's actually got one of those jobs that must make you hate to answer the phone--you know what you're doing is necessary, but it doesn't make it any easier to face the poor network engineers who are ready to blow a gasket at the beaurocracy being thrust upon them. :-( Let's not drag her through the muck too harshly about this--after all, we're the ones staying locked into the limited IPv4 space like this. 'nuff said, back to the story--) We found out in the process that we had multiple blocks that we thought were allocated that no longer had customer records associated with them, we had blocks that were doubly allocated (?!), and we had FAR too many blocks that we just didn't have customer info on altogether. It actually helped our accouting group immensely having to comb through all of our address space, and account for as much of it as possible, because it forced us to confront all the random "back door deals" and legacy allocations that nobody had every really bothered to keep track of because "you could always just get more IP blocks." We also sent copies of the Hubbard draft to all corporate customers that were currently in the pipe awaiting /24's, and explained that they would instead be given /28's for fractional T1 frame relay service, /27's for full T1's, and /24's for T3 service, by default, unless justification for larger allocation was received in writing, with a complete network diagram showing current utilization and future growth. We highlighted and underscored the section that indicated that "administrative ease" was NOT considered sufficient reason for a larger allocation, and we've held to that restriction very well since then. Yes, customers have grumbled. Yes, some customers left, or cancelled pending orders when they found out the restrictions. Our only hope is that as more and more ISP's go back for new allocations, and find out that these rules apply to everyone, the unruly companies that are shopping around for and ISP that will hand them IP blocks carte blanche will realize that there ain't no such thing as a free IP block--if everyone follows the rules, customers will fall into line as well. We have also taken the step of charging a nominal fee for additional IP blocks, to prevent companies from simply fabricating supporting documentation. The one lone person in a garage tends to be much less casual about requesting larger and larger blocks when the find out that each additional block comes with a recurring monthly fee. It also lets us keep track of usage much more closely, because if a customer stops paying the monthly fee for an IP block, we give them notice, in the usual way, and eventually we KNOW we can reclaim the block. Previously, it was much harder to tell if a customer was still using a block, albeit infrequently, or had totally forgotten they requested it. :-) Anyhow, enough rambling, this is turning out to be a far longer missive than intended, and the wet towel is getting REALLY cold, so I'll wrap up by simply saying "This is life in IPv4 space--get used to it, or move on to IPv6." I don't mean that in a harsh way, and I don't intend it as a snub to anyone. We have a scarce resource that needs to be rationed. We have an alternative resource that is much less scarce, and needs far less rationing. If you wish to continue working with the scarce resource, you need to accept that rationing is part and parcel of utilizing that scarce resource, and as such, documenting your usage of the resource has a much higher priority. The only thing I WOULD reccomend is having the NIC sign an NDA for your company. This way, if information provided to you that you pass on to the InterNIC leaks out, or is used in a mass mailing, you DO then have a leg to stand on in taking the NIC to task for releasing confidential documentation. But that's standard business practice, so it hardly bears repeating. Again, 'nuff said, just wanted to throw in our personal testimony into the grist mill, and say "we were there, we went through the suffering, it CAN be conquered, and it will probably help your organizational record keeping in the process. Yes, it's painful, but so is juggling MED's at 4 am." We're not in a hedonistic business, and this isn't the Elysian Fields. Once you've got the software and processes in place, changing entries, and adding new ones isn't NEARLY as bad as having 3 /24's left, and taking your FIRST look at rwhois. I wish you the best of luck in getting everything straight with them, but as far as we've seen, don't expect to get around the requirements--they're here to stay, as long as IPv4 is around. Thanks for putting up with my ramblings, Matt Petach Network Engineer

...

Matthew,

The InterNIC bases additional allocation blocks on efficient utilization. We can only see the utilization from your SWIPs and RWHOIS info. If you refuse to supply contact information on your assignments, how can we tell what your utilization is?

And as for the routing table overload, although the initial allocation may be relatively small, it is almost always reserved from a larger block.

Bottom line, to receive additional address space all you have to do is the same thing everyone else does - submit reassignment information. You don't have to fly out here, you don't have to be nice to me, just follow the basic policies.

Regards,

Kim Hubbard InterNIC Registry

...

Original message <3.0.32.19961118224915.006f2b00@nap.net> From: "Chris A. Icide" <chris@nap.net> Date: Nov 18, 22:49 Subject: Re: Internic address allocation policy

...

...

...

Imagine my amazement when I met Kim in person and found out she didn't have fangs, horns, and a string with dried Network Engineers' ears 'round her neck. In fact, she is a very nice person doing a very difficult job. She has a set of rules she must live by. she has to be impartial, and show no preferences.

In fact, though, I have stories piling up via private email that shows that this "impartial and show no preferences" is in fact ignored on a fairly regular basis.

Thanks to everyone who has given me stuff via private email, and keep the stories coming in.

The allocation policies do in fact have fatal flaws. For instance, conservation of addresses which results in not filling an allocated block within 3 months is penalized, not rewarded. The penalty for using up addresses too slowly is to have future allocations blocked entirely, not simply limited to /19.

You are better off allocating /24's quickly than carefully analyzing customer needs and allocating smaller subnets. However, wasting addresses too quickly can get your subnet-size policy brought into question.

But, bigger providers are given much more slack with regard to their allocation policies, and their own public SWIP and rwhois information bears this out. There are dozens of examples of /24 subnets being handed out to people with very low numbers of actual hosts by Sprint, for instance, from their 207.40.0.0 block, and clearly they were able to receive their 208.0.0.0/12 block in spite of this. (I hate to pick on Sprint here, but that's the first set of data I pulled for examination).

It goes on and on.

Yes, by bringing this out into the public I've potentially made someone(s) at the Internic unhappy. Sorry. I've also received dozens of private emails thanking me for making this more widely known, and several other providers have contacted me because they're in the same situation... comply with the policy, and get screwed.

The fact is, I *don't* ever have to post stuff like this about my other "suppliers". For starters, I've never had a real supplier try to jerk me around so much, and secondly, there really aren't any other suppliers who are sole (monopolistic) sources.

If Cisco's tech support people were as hard to deal with as the Internic representatives, I'd go buy someone else's routers. I don't have this choice for IP addresses, and my complaints are going to be public as long as there's people who want to hear them.

-matthew kaufman matthew@scruz.net