[ppml] Suggestion for ARIN to deligate smaller IP blocks

[Owen DeLong]

On May 31, 2007, at 6:00 PM, Ted Mittelstaedt wrote:

>
>
>> -----Original Message-----
>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On  
>> Behalf Of
>> John Santos
>> Sent: Thursday, May 31, 2007 4:39 PM
>> To: ppml at arin.net
>> Subject: Re: [ppml] Suggestion for ARIN to deligate smaller IP blocks
>>
>>
>>
>> This is completely wrong.  In Leroy's scenario, his company does not
>> own and does not manage the 2000 firewalls.  Those belong to his
>> customers.  He is not providing a soup-to-nuts internet service to
>> those customers.  He is providing one specific service on one (or a
>> small) number of specific ports, from one (or a small number of  
>> specific)
>> servers.  The *CUSTOMER* has to open the *CUSTOMER'S* firewall to
>> those specific ports and services in order to utilize Leroy's  
>> service.
>>
>> It is the 2000 customers who would have to pay the cost.
>
> You and I both know this but Leroy conveniently did not include this.
> Because, of course, it means that it's no longer monstorously unfair
> to Leroy's company.  Just a little unfair.  And life is full of
> little unfairnesses.
>
No, actually, it is still monstrously unfair to Leroy's company  
_BECAUSE_
it puts him at a significant competitive disadvantage relative to other
organizations that are either large or unethical enough to get  
assignments
under current policy.

> Sorry, I had to renumber more customers than that when MCI pulled out
> of North America and took their blocks with them, I have no sympathy.
> And we are NOT ACME giant ISP, either.  We used those support calls
> to do quite a lot of checking of customer settings and we found lots
> of problems that we corrected - such as people using old DNS names of
> servers long since decomissioned - which would have generated support
> calls from those customers eventually anyhow - and probably when they
> were much more frustrated and ready to quit.  We also got a rare  
> window
> into customer networks and managed to make a number of product  
> sales as a
> result of discovered opportunities.
>
And you'd like to repeat this on an annual basis?  Because, that's about
how often bandwidth pricing changes make changing providers attractive
if you want to stay competitive on cost.  I'm betting that if you  
don't have
PI addresses, you aren't changing providers annually.  Of course,  
there's
the old standby of get your addresses from some really cheap connection
that you don't actually use for bandwidth, then advertise those  
chunks on
your bandwidth de jour, but, at that point, the routing table is  
carrying your
routes anyway, and, the internet isn't gaining anything from your PA  
space,
so, we might as well give you PI, right?

> There are ways to manage a transition, even with as large a set as
> 2000 customers.  Sitting around whining about it and complaining to
> ARIN isn't the way to do it.  The only scenario with any believability
> is if Leroy wanted to reserve the right to threaten his current  
> service
> provider with immediate disconnection (thereby losing the numbers they
> allocated to him) because he got the proverbial hair up his arse or  
> some
> such.
>
There are ways to live years with HIV, too.  That doesn't mean it's
an activity you want to engage in if you don't have to.  Nobody is
sitting around whining.  We're trying to change policy to make it more
reasonable and more even handed for smaller organizations.

[snip]

>
>>
>> If they were to start changing IP addresses frequently, we would  
>> start
>> looking for a new service provider.
>>
>
> OK, so what your saying as I understand it is that you have such a low
> regard for the knowledge of the admins running your filtering  
> service, that
> you do not think they haven't thought of this already, and taken
> contractual steps with their own ISP so that this wouldn't happen -  
> yet
> you are still using them?  Facinating!
>
No, what he's saying is that they should be able to switch ISPs
at will without affecting his service.  Their choice of ISP and any
difficulties they have should be transparent to him as a customer.

No amount of knowledge can overcome the fact that if you are
using PA addresses, you can't switch ISPs without renumbering.
No amount of knowledge can make renumbering a service transparent
to your customers.
>
> MCI  -WAS-  an ACME GIANT ASP INC. - yet, somehow they couldn't  
> guarentee
> it for their customers, either.
>
Um, no.  MCI was an ACME GIANT ISP INC.  Not an ASP.  There's a
rather large difference between an ISP and an ASP.  MCI didn't
renumber... They took their addresses with them when they left.
Sure, that affected their former customers, but, it didn't affect their
current customers.

>> Of course, Leroy could game the system and provide each of his  
>> customers
>> with a single, unique IP address (thus requiring 8 class C's) and
>> then forward them all to the same handfull of servers at his  
>> firewalls.
>>
>
> I do not see that this is "gaming the system"   It is, in fact, a  
> rather
> legitimate use of IP.  IP addresses are just numbers after all.   
> There is
> really no such thing as a shortage of numbers - I can put you into  
> a corner
> and tell you to start counting and you could spend the rest of your  
> life
> doing
> it.  No shortage there!  And the entire point of IPv6 is to have so  
> many
> numbers that you aren't going to have shortages.
>
Yes, but, since the IPv6 numbers don't currently talk to the internet
in a meaningful way, we're stuck with the rather finite set of IPv4
numbers.  I think most on this list would agree that the stated usage
of IP addresses does constitute gaming the system if it is done
solely for the purpose of consuming enough addresses to justify
a larger block in order to qualify under current policy.

>> So is it better for the overburdened routers to route to one Class C
>> (what Leroy actually requires), or to 8 of them?  (Especially given
>> there is no guarantee the 8 would be contiguous and thus could be
>> treated as a single /21 for routing purposes.)
>>
>
> If Leroy is moral, he will have the decency to give his customers some
> sort of reassurance of reliability by becoming multihomed, getting an
> AS, and getting a portable block the normal way.  If I'm one of his
> customers I certainly have the right after paying Leroy to expect that
> his service is going to be redundant.
>
If Leroy is moral, he would prefer to do that with a portable block  
of the
minimum size he needs so he is not consuming addresses for the sake
of consumption.  However, current policy requires Leroy to use a /22
in order to do what you state, even though he can do it perfectly well
in a /24.
> If Leroy is criminal, this discussion is pointless, because Leroy is
> just going to do whatever is cheapest for him, and damn the rest of  
> us.
>
If Leroy is moral, but, pragmatic, he'll potentially find a  
legitimate way
to multiply his IP usage by some needed number (8, for example), and
then apply for a block of the size required in order to get one, but,  
Leroy,
being moral will regret having to do so and will continue to believe  
that
policy should be changed to facilitate doing this honestly without the
excess address wastage.

> Your basically arguing here that people should have the freedom to  
> put a
> car on the road with green brake lights because they think it looks  
> pretty,
> and drive 100Mph on every road, in the LH lane.  IP numbering is a  
> shared
> resource like a road.  You have to do things like putting red brake  
> lights
> on
> the ass end of your car because it helps other people and the roads  
> would
> not work if everyone put whatever color they wanted on brake lights.
>
No, actually, he's arguing that people should be allowed to put smaller
cars on the road because they are more fuel efficient and that they  
shouldn't
be prohibited just because they weren't made by Ford, GM, or Toyota.

Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2105 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070531/d369dc4e/attachment.p7s>