[ppml] Policy Proposal 2006-2: Micro-allocations for Internal Infrastructure

[Louis Lee]

Comments inline.  I support this policy proposal with the
following modifications....

By the way, I withdraw my comments about allocations vs.
assignments.  In my experience of requesting micro-allocations,
whether a small block is allocated or assigned (in the strict
sense) was based more on whether my organization is an
end-site or an ISP.

On Fri, Feb 17, 2006 at 02:31:06PM -0500, Member Services wrote:
>
> Policy Proposal 2006-2: Micro-allocations for Internal
> Infrastructure
>
> Author: Jason Schiller, Chris Morrow, Heather Skanks, Greg
> Stilwell, Beth Vu
>
> Proposal type: modify
>
> Policy term: permanent
>
> Policy statement:
>
> To replace section 6.10
>
> 6.10 Micro-allocation
>
> ARIN will make micro-allocations for critical infrastructure,
> and the RIRs and IANA as defined in the sub-sections
> below.

There is no reference to RIRs & IANA in the sub-sections.  Since
the idea for this policy proposal seems to be to add internal
infrastructure for justification without removing the current
justification guidelines, perhaps another sub-section should
added to the 3 that are proposed.  Might I suggest 6.10.4?

Jason, I know when we last spoke, I was going to add RIRs &
IANA to the 6.10.2 sub-section.  I now think that the
justification is sufficiently different enough that it should
be a separate sub-section.  However, I am still offering
alternate wording for the second paragraph of 6.10.2 for 
consistency.  (See below.)

So if we one of Randy's two wishes come true about setting
aside specific blocks for DNS, a whole sub-section can be
removed without modifying text. :)

> These allocations will be no longer (more specific) than a
> IPv6 /48. Multiple allocations may be granted in certain
> situations. Micro-allocations MUST be provided from a specific
> range of addresses. ARIN will make a list of these blocks
> publicly available.  ISPs and other organizations receiving
> these micro-allocations will be charged under the ISP fee
> schedule, while end-users will be charged under the fee
> schedule for end-users.  This policy does not preclude
> organizations from requesting address space under other
> policies.
>
> 6.10.1 Micro-allocation for public exchange points
>
> Public Internet exchange point operators must provide
> justification for the micro-allocation, including: connection
> policy, location, other participants (minimum of two total),
> ASN, and contact information.
>
> Exchange point allocations MUST be allocated from specific
> blocks reserved only for this purpose.
>
> 6.10.2 Micro-allocation for core DNS service providers
>
> Core DNS service providers (e.g. ICANN-sanctioned root, gTLD,
> and ccTLD operators) must provide justification for the
> micro-allocation, including: name of core DNS server, location,
> ASN, and contact information.
>
> Core DNS server allocations MUST be allocated from the
> micro-allocation block.  This block must be separate from
> the exchange point micro-allocation block and the internal
> infrastructure micro-allocation block.

I suggest this text for the second paragraph of 6.10.2:

  Core DNS server allocations MUST be allocated from
  specific blocks reserved only for this purpose.

The originally proposed text is unnecessarily cumbersome to
read through and implement.  It was already stated earlier that
"Micro-allocations MUST be provided from a specific range of
addresses".  Since the subsections within 6.10 are meant to cover
all cases for v6 micro-allocation, there would not be a case
where an assignment for something else is made out of the DNS IP
allocation block.

Now, I'm curious if there are actually any network operators who
have configured route filters or IP filters based specifically on
DNS server IP blocks.  It is understood that learning an IX
micro-allocation prefix from your eBGP peer will usually cause
routing problems.  The same issue doesn't exist for the DNS IP
blocks.  But since I didn't participant in the discussion for
the same justification for IPv4, I can't say that there weren't
any non-technical (e.g. political) reasons for root servers to
be in PI space.

> 6.10.3 Micro-allocation for internal infrastructure
> 
> Organizations that currently hold IPv6 allocations may
> apply for a micro-allocation for internal infrastructure.
> Applicant must provide justification indicating why a separate
> non-routed block is required.  Justification must include why a
> sub-allocation of currently held IP space cannot be utilized.
>
> Internal infrastructure allocations MUST NOT be routed on
> global Internet.

For now, this sentence saying that "Internal infrastructure
allocations MUST NOT be routed on global Internet" should be
removed.  I fully understand the reason for it to be there.  But
for its inclusion, we should change the stance that ARIN would
not address routability.  (Policy text that mention NAT and
RFC1918 space is on the edge of that stance.)

> Internal infrastructure allocations MUST be allocated from
> specific blocks reserved only for this purpose.

How about the following text for 6.10.4?  I don't know that we
have to provide any strict guidelines.  There is no indication or
evidence of abuse, so I'm refraining from imposing restrictions.
(Is there a compelling reason to document the reason for the new
micro-allocation.)

  6.10.4 Micro-allocation for RIRs and IANA

  RIRs and IANA may be allocated a micro-allocation upon
  request.

  Allocations to RIRs and IANA MUST be allocated from
  specific blocks reserved only for this purpose.

Just some additional thoughts....

ARIN already documents the micro-allocations as lists:
http://www.arin.net/reference/micro_allocations.html

That being the case, is it really necessary to have specific
blocks reserved for each of the 3 (or 4) categories (times 2: one
set for v4 and another set for v6)?  I'd imagine that operators
may find it convenient to configure route filters and IP filters
so they can treat each block differently.  But is that happening
today?  And would someone with a crystal ball tell me if these
filters will be built based on these blocks in the future? ;)


Best regards,
Louie
-- 
Louis Lee
Sr. Network Architect
New Service Development
Equinix, Inc.
louie at equinix.com
desk: 408/360-5253
main: 650/513-7000