Requesting P.I. Space from ARIN - latest issues?

2005-10-11 Thread up


After taking IP space from upstreams for years, I am on the verge of
requesting PI space from ARIN, but after reviewing their guidelines, I
have a couple of questions:

1) I meet the Multihoming requirement, which means I can get a block as
small as a /22, which is about right for my needs.  Are there still any
concerns about networks (as Verio and Sprint have done in the past)
filtering out longer prefixes, and if so, does it depend on whether it;s
former class A, B, C or swamp space?  I know when I got my current block
from my upstream, I had to make sure I got swamp space, because the former
class B block they initially allocated to me wouldn't have made it past
Verio's filters at that time.

2) I currently have a /21 from an upstream, for which I met the
requirements for when I got it, but since outsourcing the dialup, I am
probably well below ARIN's guidelines for efficient utilization at this
time.  Would this cause a problem in my application, even though I am
applying for a smaller block?

Thanks in advance,

James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]   
http://3.am
=






Re: Requesting P.I. Space from ARIN - latest issues?

2005-10-11 Thread Justin M. Streiner


On Tue, 11 Oct 2005, [EMAIL PROTECTED] wrote:


1) I meet the Multihoming requirement, which means I can get a block as
small as a /22, which is about right for my needs.  Are there still any
concerns about networks (as Verio and Sprint have done in the past)
filtering out longer prefixes, and if so, does it depend on whether it;s
former class A, B, C or swamp space?  I know when I got my current block
from my upstream, I had to make sure I got swamp space, because the former
class B block they initially allocated to me wouldn't have made it past
Verio's filters at that time.


Most if not all of the /8s that get assigned to ARIN have a prescribed 
minimum allocation size.  How rigorously that is followed is another 
story :-)  I don't think you can specifically request that ARIN assign you 
space out of the swamp these days.


jms


Re: Requesting P.I. Space from ARIN - latest issues?

2005-10-11 Thread Joe Abley



On 11-Oct-2005, at 11:33, Justin M. Streiner wrote:


On Tue, 11 Oct 2005, [EMAIL PROTECTED] wrote:

1) I meet the Multihoming requirement, which means I can get a  
block as
small as a /22, which is about right for my needs.  Are there  
still any

concerns about networks (as Verio and Sprint have done in the past)
filtering out longer prefixes, and if so, does it depend on  
whether it;s
former class A, B, C or swamp space?  I know when I got my current  
block
from my upstream, I had to make sure I got swamp space, because  
the former
class B block they initially allocated to me wouldn't have made it  
past

Verio's filters at that time.


Most if not all of the /8s that get assigned to ARIN have a  
prescribed minimum allocation size.  How rigorously that is  
followed is another story :-)


I believe it is followed rigourously for new assignments, and that / 
22 assignments are made from a range of addresses whose minimum  
allocation size is /22 (or longer).


ISPs who filter based on prefix length according to RIR minimum  
allocation sizes should not block a route based on such an  
assignment, assuming their filters are up-to-date.


Whether or not any particular prefix is blocked is best determined  
experimentally (e.g. feed a box with two interface addresses from  
different ranges a list of hosts to ping at a polite, low frequency,  
and compare the results sourced from each address).


I have had dealings with many ISPs who have announced blocks based on  
fairly long-prefix assignments from RIRs, following policies such as  
ARIN's multi-homing assignment policy, and I haven't heard of any  
substantial problems due to the prefix length. James' MMV, of course.


I don't think you can specifically request that ARIN assign you  
space out of the swamp these days.


You can request anything you like. Whether it makes a difference is  
another thing entirely :-)



Joe