Hello Owen; The original intent was to make it possible for multi-homed ASN to get a minimum address block (a /24), without any other particular qualifications. There was considerable debate, as you would expect on a proposal that took 3 Public Policy Meetings and 14 months to get through. As approved, it says merely :
------ Address Policy for Multi-homed Networks Multi-homed organizations may justify and obtain a block of address space with prefix length extending to /22 directly from ARIN. When prefixes are longer than /20, these micro-allocations or micro-assignments will be from a reserved block for that purpose. ------ Regardless of Section 4.2.2.2 may say, the above is what was voted on at the Chicago meeting. Given the original intent of 2002-3, and given the wording of it as passed, I view multi-homing as a strong justification for a /22. Clearly, if you get an make use of two /24 from your upstreams, you should qualify. If not, it may take more convincing, but it should not be ruled out. What comes to mind, though, is is this a tempest in a tea pot ? Has anyone gotten a microassignment ? What is their experience ? Please send any info to me offlist. (One of the points that we kept making about 2002-3 was that not many people would use it in practice.) Regards Marshall Eubanks On Sat, 13 Nov 2004 09:11:55 -0800 Owen DeLong <[EMAIL PROTECTED]> wrote: > Actually, that's not true. The requirement for a direct end-user assignment > of any size includes multihoming. Since RFC-compliant multihoming requires > an ASN (consistent origin AS), one of the metrics used to determine if an > organization is multihomed is the possession of (or application for) an ASN. > This applies to any prefix size. Initially, there were going to be separate > more stringent rules for obtaining a /24 microallocation, but, in the > process of watering 2002-3 down to a /22, most of these additional > requirements were also removed. The resulting policy is, in fact, > essentially > identical to the current policy except for the minimum allocation unit, and, > the specification that /22 and /21 assignments and allocations will be taken > from a different address pool than the larger ones. > > Owen > > > --On Saturday, November 13, 2004 4:38 AM -0500 Marshall Eubanks > <[EMAIL PROTECTED]> wrote: > > > > > On Fri, 12 Nov 2004 15:57:46 -0700 > > Michael Loftis <[EMAIL PROTECTED]> wrote: > >> > > > > The original intent of 2002-3 : Micro-Assignments for Multihomed Networks > > was to give a /24 to any party with an ASN, as it was possible to become > > an AS without having the ability to get your own address space. > > In the year+ before it was approved last Fall > > in Chicago, this was watered down to a /22. (FWIW, I opposed that.) > > > > However, to become an AS means that you have to be multi homed, i.e., have > > a connection to 2 or more providers. Since it is not hard to get a /24 > > from a provider if you are paying for a connection with them, then my > > understanding of the intent was that any ASN with two /24's should be > > able to get a /22. (I.e., for the microassignment, having an ASN was the > > crucial factor.) This is not the same as requesting an assignment for a > > /20 or smaller prefix, where different rules apply. > > > > If you are an ASN with two address blocks, I think that you qualify and > > should apply. > > > > Regards > > Marshall Eubanks > > > > > >> > >> > >> --On Friday, November 12, 2004 14:14 -0500 Alex Kamantauskas > >> <[EMAIL PROTECTED]> wrote: > >> > >> > > >> > Yep, I blinked while going through the small town of ARIN Policy and > >> > missed it :) > >> > > >> > ARIN Number Resource Policy Manual, 4.2.2.2: "When requesting a /22, > >> > demonstrate the efficient utilization of a minimum contiguous or > >> > noncontiguous /23 (two /24s) from an upstream." > >> > >> I'm still not exactly clear on the definition of 'efficient utilization' > >> --- in other places it' mentions 80%, but that's only as ISP allocation > >> and request for additional space... > >> > >> Anyone have a pointer as to the ARIN official definition of this > >> language? > > > > > > -- > If it wasn't crypto-signed, it probably didn't come from me.