[arin-ppml] Simplified IPv6 policy

[Scott Leibrand]

On 12/23/2009 2:53 AM, William Herrin wrote:
> On Wed, Dec 23, 2009 at 4:05 AM, Scott Leibrand<scottleibrand at gmail.com>  wrote:
>    
>> Here's an attempt at how we might simplify IPv6 policy, incorporating many
>> of the ideas we've discussed recently.  It's much simpler than current
>> policy, but is still quite long.  It's also late, so I reserve the right to
>> make mistakes, and to disagree with myself later.  :-)
>>      
>
> Hi Scott,
>
> I think your proposal offers a major improvement on existing IPv6 policy.
>
>
> Problems addressed by your proposal:
>
> * Enables effective TE filtering where ISPs determine that
> disaggregate TE is undesirable.
>
> * Unifies ISP/end-user policy so that all organizations are treated fairly
>    

<nod>

> Problems not resolved by your proposal:
>
> * Offers no IPv6 replacement for organizations with small but valuable
> server infrastructures which today multihome with either a legacy
> address block or a /24 ISP cutout.
>    

If you have (or acquire via 8.3) a legacy address block, then you can 
qualify for a PI /48.

If you multihome with a PA /24 today, the equivalent in v6 would be to 
multihome with a PA /48.  At the moment, such cutouts are not routable, 
but to me that's not something policy can fix.  If your upstreams won't 
take your money to accept your /48 cutout from each other, then how are 
we going to get them to agree to route a whole bunch of new PI /48s that 
they don't necessarily get paid for?  This is not a theoretical problem: 
AFAIK Verizon has not yet started accepting the PI /48s ARIN is already 
allocating.  If we give out PI /48s to anyone who wants to multihome, 
they (and others) will be even less likely to accept those.

> * Retains ARIN as the gatekeeper for Internet routing policy. ISPs
> must accept and route all allocations, even the x-small ones, or
> they'll lose access to critical infrastructure.
>    

Not as currently written.  Among the extra critical infrastructure text 
I kept is a requirement that critical infrastructure blocks be allocated 
from a dedicated block so that ISPs can selectively accept those.

I agree that the policy retains ARIN as the gatekeeper for Internet 
routing policy.  Perhaps we can change that, but I'm pretty sure that a 
policy proposal doing so by liberalizing assignment policy to the point 
where ISPs *have to* filter would generate a large amount of 
opposition.  Owen is just the most willing-to-speak-up tip of that 
iceberg of opposition.

> Some specific comments inline:
>
>    
>> Replacement text:
>>
>> 1.1.  Number resources not to be considered property
>>
>> It is contrary to the goals of this document and is not in the interests of
>> the Internet community as a whole for address space to be considered
>> freehold property.
>>
>> The policies in this document are based upon the understanding that
>> globally-unique number resources are licensed for use rather than owned.
>> Specifically, IP addresses and ASNs will be allocated and assigned on a
>> license basis, with licenses subject to renewal on a periodic basis. The
>> granting of a license is subject to specific conditions applied at the start
>> or renewal of the license, as definied in the ARIN Registration Services
>> Agreement.
>>
>> Note that when a license is renewed, the new license will be evaluated under
>> and governed by the applicable number resource policies in place at the time
>> of renewal, which may differ from the policy in place at the time of the
>> original allocation or assignment.
>>      
> Good or bad, I'm not sure 1.1 is germane to the rest of the proposal.
> Can it be left out without impacting the rest or does it change
> something crucial?
>    

It seemed like something that had enough value to be worth keeping.  
If/when this ever gets to draft policy stage, we can ask ARIN Counsel's 
opinion on whether to keep it.

>> 6.2.  Policies for IPv6 allocations and assignments
>>
>> 6.2.1.  Allocations and assignments
>> To meet the goal of Fairness, ARIN makes both allocations and assignments
>> according to common criteria.  Allocations are made to LIRs, and assignments
>> to certain end users.
>>      
> In a policy designed to enable disaggregate filtering, the distinction
> between a LIR and an ISP is not technologically sound. There are no
> LIRs who allocate or assign addresses to entities they don't also
> supply Internet service to. I suggest replacing all instances of LIR
> with ISP.
>    

Section 2.4. defines a Local Internet Registry (LIR) as "an IR that 
primarily assigns address space to the users of the network services 
that it provides. LIRs are generally ISPs, whose customers are primarily 
end users and possibly other ISPs."

I don't think it matters one way or the other.


>> 6.2.2.  Assignments from LIRs/ISPs
>> End-users are assigned an end site assignment from their LIR or ISP. The
>> exact size of the assignment is a local decision for the LIR or ISP to make,
>> using a minimum value of a /64 (when only one subnet is anticipated for the
>> end site) up to the normal maximum of /48, except in cases of extra large
>> end sites where a larger assignment can be justified.
>>
>> The following guidelines may be useful (but they are only guidelines):
>>
>>     * /64 when it is known that one and only one subnet is needed
>>     * /56 for small sites, those expected to need only a few subnets over the
>> next 5 years.
>>     * /48 for larger sites
>>
>> For end sites to whom reverse DNS will be delegated, the LIR/ISP should
>> consider making an assignment on a nibble (4-bit) boundary to simplify
>> reverse lookup delegation.
>>
>> ARIN is not concerned about which address size an LIR/ISP actually assigns.
>> Accordingly, ARIN will not request the detailed information on IPv6 user
>> networks as in IPv4, except for the purpose of measuring utilization as
>> defined in this document.
>>
>> 6.2.3. Allocations and assignments from ARIN
>>
>> 6.2.3.1  Goals
>> To balance the goals of Aggregation, Conservation, Fairness, and Minimized
>> Overhead, ARIN normally makes allocations only in the discrete sizes of /48,
>> /40, /32, /28, or /24 or larger.  Each organization or discrete network may
>> qualify for one allocation or assignment of each size, and must pay fees
>> according to ARIN's<a
>> href="https://www.arin.net/fees/fee_schedule.html">fee schedule</a>
>> for each size assigned.
>>      
> Good.
>
>
>    
>> 6.2.3.2  X-Small (/48)
>> To qualify for a /48 allocation or assignment, an organization must:
>>     * Serve at least 500 hosts, if multihomed; or
>>     * Serve at least 1000 hosts; or
>>      
> IPv6 addressing is LAN-centric rather than host-centric. Accordingly I
> suggest expressing this in terms of a number of LANs served. Perhaps
> 50 or 100 LANs instead of 500 or 1000 hosts?
>    

Why is number of LANs a better metric than number of hosts to determine 
who deserves a routing slot?  We're not really talking efficient 
utilization here, so I don't think number of LANs is relevant.  Besides, 
I can create 100 VLANs on a single inexpensive switch.  Creating 500 VMs 
(with running OSs) at least requires gear with more than a few dozen GB 
of RAM

These numbers were adapted from existing IPv4 PI policy.  Perhaps we 
should lower the numbers to better reflect the lower IPv4 requirements 
currently on the table.  Perhaps 250 or 500 hosts?

>>     * Demonstrate efficient utilization of all direct IPv4 assignments and
>> allocations, each of which must be covered by any current ARIN RSA; or
>>     * Be a critical infrastructure provider of the Internet, including public
>> exchange points, core DNS service providers (e.g. ICANN-sanctioned root,
>> gTLD, and ccTLD operators) as well as the RIRs and IANA; or
>>     * Qualify for a Micro-allocations for Internal Infrastructure per
>> 6.3.3.2.2.
>>
>> 6.2.3.2.1 Critical Infrastructure
>> Organizations qualified as critical infrastructure providers may be granted
>> multiple /48 allocations in certain situations.  Exchange point allocations
>> MUST be allocated from specific blocks reserved only for this purpose. All
>> other micro-allocations WILL be allocated out of other blocks reserved for
>> micro-allocation purposes. ARIN will make a list of these blocks publicly
>> available. Exchange point operators must provide justification for the
>> allocation, including: connection policy, location, other participants
>> (minimum of two total), ASN, and contact information. 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 exchange point operators from
>> requesting address space under other policies.
>>      
> At work I operate a ground station for a satellite constellation. The
> non-IP satellite devices deliver messages to the ground station which
> disperses them via the Internet.
>
> This very high value application uses 5 T1s from 5 different ISPs, a
> 100 meg ISP link and a 100 meg peering link. It uses only a few score
> hosts and a handful of LANs.
>
> I use an ARIN AS# to announce an IPv4 /24 cutout from an ISP block via
> BGP on all the ISP and peering links. Because it's multihomed, this is
> in full compliance with ARIN policy. Because it's impractical to
> filter announcements /24 and shorter, it works great.
>
> How do I get usable IPv6 addresses?
>    

As I mentioned above, if you can't pay your upstreams enough money to 
accept PA /48s from each other, perhaps your application isn't 
high-value enough to justify a routing table slot.  In this case, I 
think it is, but as I mentioned above, I think you should have to work 
that out with your upstreams, not rely on ARIN to make them accept a 
whole bunch of lower-value PI /48s.

>> 6.2.3.2.2 Micro-allocations for Internal Infrastructure
>> 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.
>>
>> 6.2.3.3  Small (/40)
>> To qualify for a /40 allocation or assignment, an organization must qualify
>> for two or more /48s.
>>
>> 6.2.3.4  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
>>     * Have a plan to provide IPv6 connectivity to other organizations and
>> assign at least 100 end-site assignments to those organizations within 5
>> years.
>>
>> 6.2.3.5  Large (/28)
>> To qualify for a /28, an organization must demonstrate the need to make
>> assignments and/or reallocations equal to at least 20,000 /48s.
>>      
> Why not demonstrate that they -have made- at least 20,000 /48
> assignments from their /32?
>    

That would be OK, but I was hoping to avoid having to make an ISP get a 
/32, start using it, and then renumber everything into a /28 if they 
know from the start they have more customers than will fit in a /32.

>> 6.2.3.6  X-Large (/24 or larger)
>> Allocations or assignments of /24 or larger may be made only in exceptional
>> cases, to organizations that require more than a /28, and have submitted
>> documentation that reasonably justifies the request. If approved, the
>> allocation size will be based on the number of existing users and the extent
>> of the organization's infrastructure.
>>
>> 6.3. Registration
>>
>> When an organization holding an IPv6 address allocation makes IPv6 address
>> assignments, it must register assignment information in a database,
>> accessible by RIRs as appropriate (information registered by ARIN may be
>> replaced by a distributed database for registering address management
>> information in future). Information is registered in units of assigned /56
>> networks. When more than a /56 is assigned to an organization, the assigning
>> organization is responsible for ensuring that the address space is
>> registered in an ARIN database.
>>      
> Might want to put some verbiage here about assignments/reallocations
> to legal entities other than the registrant so that you don't have to
> register internal assignments for the printer LAN.
>    

The text in section 6.3 is only slightly modified (i.e. to replace 
RIR/NIR with ARIN) from what's already in the NRPM.  I think we're 
changing enough already.  :-)

>> IRs shall maintain systems and practices that protect the security of
>> personal and commercial information that is used in request evaluation, but
>> which is not required for public registration.
>>
>> 6.3.1. Residential Customer Privacy (2003-3)
>>
>> To maintain the privacy of their residential customers, an organization with
>> downstream residential customers may substitute that organization's name for
>> the customer's name, e.g. 'Private Customer - XYZ Network', and the
>> customer's street address may read 'Private Residence'. Each private
>> downstream residential reassignment must have accurate upstream Abuse and
>> Technical POCs visible on the WHOIS record for that block.
>>      
> Is residential privacy already in effect? If not, it probably isn't
> germane to the rest of the policy proposal. Potentially valuable but
> better off in a separate proposal.
>    

This is also already in the NRPM, and is really just another subsection 
renumbering.

>> 6.3.2. Reverse lookup
>>
>> When ARIN delegates IPv6 address space to an organization, it also delegates
>> the responsibility to manage the reverse lookup zone that corresponds to the
>> allocated IPv6 address space. Each organization should properly manage its
>> reverse lookup zone. When making an address assignment, the organization
>> must delegate to an assignee organization, upon request, the responsibility
>> to manage the reverse lookup zone that corresponds to the assigned address.
>>      
> That would be totally sweet if ISPs were required to delegate RNDS to
> the customers on request. I have a long-running argument with Cox on
> the subject. But is this really ARIN's job?

Again, already in the NRPM, just moved it and made some insubstantial edits.

-Scott