[arin-ppml] Updated text for Simplified IPv6 Policy
On 12/23/2009 4:23 PM, Steve Bertrand wrote:
> Scott Leibrand wrote:
>> * Demonstrate efficient utilization of all direct IPv4 assignments
>> and allocations, each of which must be covered by any current ARIN
>> RSA; or
> How is "current RSA" defined? If I signed an RSA five years ago and
> they've updated the RSA three times since then, does that mean that I
> have to re-sign my existing assignment/allocation into the most recent
> RSA to qualify?
If you request new IPv4 space, is ARIN going to require you to sign the
updated RSA to get it? (If you don't know, we'd have to ask ARIN
staff. I think there were some discussions about this back when we
passed 2007-21, but I can't remember the details.) If so, then you'd
need to do so before getting IPv6 under this policy (2007-21) as well.
If not, then ARIN considers your version current, and you're fine.
>> * Qualify for a Micro-allocations for Internal Infrastructure per
>> 126.96.36.199.1 Micro-allocations for Internal Infrastructure /(Copied from
>> NRPM 6.10.2)/
>> Organizations that currently hold IPv6 allocations may apply for a /48
>> micro-allocation for internal infrastructure. Applicant must provide
>> technical 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 be allocated from specific blocks reserved only for this purpose.
> Why is it that the critical infrastructure blocks "must be allocated
> from specific blocks reserved only for this purpose"?
> Why can't this text be removed from this sub-section, and include a
> global section that claims that 'each type of assignment/allocation must
> be allocated/assigned from specific blocks reserved only for this purpose'?
> I don't currently know how ARIN carves up the space, so the above is
> just a clueless remark, while thinking along the lines of
Actually, that is a really good point. I think I'll incorporate it.
To answer your question, it is only that way for critical and internal
infrastructure because when we passed those policies we wanted to make
sure that ISPs could poke holes in their filters to allow CI routes
through and filter II routes.
>> 188.8.131.52 Medium (/32)
>> To qualify for a /32 allocation or assignment, an organization must:
>> * Qualify for 100 or more /48s; or
>> * Be an existing, known LIR; or
> I'm assuming this means that so long as I'm already an ISP/LIR with
> _any_ IPv4 space (from ARIN) that I can get IPv6 with essentially no
> questions asked?
Yep. The same is true of existing policy.
On 12/23/2009 4:34 PM, Steve Bertrand wrote:
> Steve Bertrand wrote:
>> Also, I don't like the N hosts rule. I'd rather see that changed to
>> something like 'N connected interfaces' (including sub-ints and
>> virtual-ints), or 'N number of subnets/networks'.
> Replying to my self, I don't like any of this. For instance:
> If I have five Apache server 'hosts', each with 200 domains on them, and
> I feel that I can use the luxury of IPv6 to assign an IPv6 address to
> each domain to provide the domain owner better service, I can't see how
> this could be classified as host, interface etc, but I've managed to
> assign 1k addresses. (not that I'd ever do such a thing... I've learnt
> by having to renumber entire networks to do with as few addresses as
> possible, where possible ;)
Actually, I think that's totally reasonable. There are more than enough
IPs in a /64 to do that for every registered domain on the planet. Just
don't expect that to justify getting more than a /48. :-)
> Perhaps it would be better to either get rid of the clause entirely, or
> have it read something such as "have 1,000 IPv6 address assignable
> objects", where 'object' could be defined as 'any network resource that
> can be addressed'.
I'm still waiting for someone to come up with the magic metric here.
But right now, I still think hosts are the best technical metric we have
for defining the size class of a network. I'm not really trying to
define "how many subnets you need", but rather "are you big enough to
fit into this size class", for purposes of routing table slots, etc.