[arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

[Gary T. Giesen]

Richard

They are not multiple discreet networks in the NRPM sense. It is expected to be a contiguous network with preferably a single announcement. If you change providers then you still have renumber dozens of sites. By comparison c. and d. could potentially be a single site, and the economic burden of renumbering was considered high enough that an allowance was made for those cases. I'd argue the economic burden of this case has the potential to be much, much higher.

As for the numbering issue, there was is a note in the general comments section:

b. General Comments:

- Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and insert a new subsection e. with the following text:

"By having a contiguous network that has a minimum of 13 active sites within 12 months, or;"


I'm not particularly stuck on the reordering of the elements, the qualification can become f) for all I care, I just thought from a style standpoint it was cleaner to have all the explicit cases listed first and the catchall at the end.

GTG

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Richard J. Letts
Sent: June-25-15 2:32 PM
To: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2015-1: Modification to Criteria for IPv6 Initial End-User Assignments

I still do not think the problem statement is a real issue.

If you have Multiple Discrete Networks (using the IPv4 terminology) then that would seem to me be reason enough to apply for space under 6.5.8.1(e) i.e. given a geographically dispersed location then that seems reasonable to need separate space for each. Has ARIN actually denied space for this reason?

Why if I have ULA do I also need to have NAT66? Why can't the workstations have a ULA address for internal communications, and a provider-provided IPv6 address for global internet conversations that changes with ISP? It seems that this argument is predicated on how IPv4 has been traditionally deployed.

With IPv6 I thought it was the expectation that a node would HAVE multiple IPv6 addresses assigned and would choose dynamically the most appropriate source address (https://tools.ietf.org/html/rfc6724). As an example my own IPv6-enabled desktop currently has six IPv6 addresses as a result of recent network changes here -- I have not yet had to renumber anything and nothing has stopped working during the transitions.

I would have expected expect an organization would make use of ULA for internal-only services and establish VPN connections between disconnected networks. Changing providers would then only be a matter of updating the VPN tunnels linking these ULA networks. You will then be assured your inter-site traffic is encrypted, and there is no requirement to renumber your ULA services if you change IPv6 providers. 

Yes, you would have to renumber any public services, but this is the same problem you have with IPv4 (and if you have multiple locations providing publically accessible services then surely the MDN-equivalency of 6.5.8.1(e) would apply)?

Richard Letts

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] 
> On Behalf Of ARIN
> Sent: 23 June 2015 1:07 PM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Recommended Draft Policy ARIN-2015-1: 
> Modification to Criteria for IPv6 Initial End-User Assignments
> 
> Recommended Draft Policy ARIN-2015-1
> Modification to Criteria for IPv6 Initial End-User Assignments
> 
> On 18 June 2015 the ARIN Advisory Council (AC) recommended
> ARIN-2015-1 for adoption, making it a Recommended Draft Policy.
> 
> ARIN-2015-1 is below and can be found at:
> https://www.arin.net/policy/proposals/2015_1.html
> 
> You are encouraged to discuss Draft Policy 2015-1 on the PPML prior to 
> the ARIN Public Policy Consultation at ARIN 36 in Montreal in October 2015.
> Both the discussion on the list and at the meeting will be used by the 
> ARIN Advisory Council to determine the community consensus for 
> adopting this as policy.
> 
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
> 
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> ## * ##
> 
> 
> Recommended Draft Policy ARIN-2015-1
> Modification to Criteria for IPv6 Initial End-User Assignments
> 
> Date: 23 June 2015
> 
> AC's assessment of conformance with the Principles of Internet Number 
> Resource Policy:
> 
> ARIN-2015-1 enables fair and impartial number resource administration 
> by providing a concrete threshold (13 active sites) under which 
> end-user organizations who have a large number of potentially 
> geographically dispersed sites, or sites with low subnet and/or user 
> counts, can be reasonably assured of receiving IPv6 address space from 
> ARIN. This proposal is technically sound, in that it retains 
> reasonable thresholds on obtaining IPv6 assignments from ARIN in order 
> to support the aggregation of Internet number resources in a 
> hierarchical manner to the extent feasible. It has been well supported 
> by the community on PPML and at the ARIN PPC at NANOG in San 
> Francisco, where nearly everyone agreed that this was a step in the 
> right direction. To the extent that some in the community desire even 
> more relaxed IPv6 assignment policy, the AC encourages those community 
> members to discuss on PPML and/or submit as additional policy proposals any further changes they would like to see.
> 
> Problem Statement:
> 
> Current policy for assignment to end users excludes a class of users 
> whose costs to renumber would far exceed what current policy is 
> designed to mitigate.
> 
> Current measures designed to minimize the economic cost of renumbering 
> per NRPM 6.5.8.1 (Initial Assignment Criteria) are:
> 
> c. By having a network that makes active use of a minimum of 2000 IPv6 
> addresses within 12 months, or; d. By having a network that makes 
> active use of a minimum of 200 /64 subnets within 12 months, or;
> 
> These two measures fail to take into account end users who have a 
> large number of potentially geographically dispersed sites, or sites 
> with low subnet and/or user counts. The economic costs for this class 
> of end user would likely far exceed the costs that 6.5.8.1 c. and d. 
> are designed to mitigate.
> 
> While an end user could possibly apply (and receive an assignment) 
> under
> 6.5.8.1 e. ("By providing a reasonable technical justification 
> indicating why IPv6 addresses from an ISP or other LIR are 
> unsuitable"), it fails to provide a concrete threshold under which 
> this class of end-user can be reasonably assured of receiving address space.
> 
> Without having the reasonable assurance of IPv6 address number 
> resource continuity that a direct assignment allows, many smaller 
> enterprises are unlikely to adopt IPv6 (currently perceived as an 
> already tenuous proposition for most users given current 
> cost/benefit); or are likely to adopt technical measures (such as 
> using ULA addressing + NAT66) that are widely held to be damaging to the IPv6 Internet.
> 
> Policy Statement:
> 
> Replace the contents of NRPM 6.5.8.1 with:
> 
> 6.5.8.1. Initial Assignment Criteria
> 
> Organizations may justify an initial assignment for addressing devices 
> directly attached to their own network infrastructure, with an intent 
> for the addresses to begin operational use within 12 months, by 
> meeting one of the following criteria:
> 
> a. Having a previously justified IPv4 end-user assignment from ARIN or 
> one of its predecessor registries, or; b. Currently being IPv6 
> Multihomed or immediately becoming IPv6 Multihomed and using an 
> assigned valid global AS number, or; c. By having a network that makes 
> active use of a minimum of
> 2000 IPv6 addresses within 12 months, or; d. By having a network that 
> makes active use of a minimum of 200 /64 subnets within 12 months, or; e.
> By having a contiguous network that has a minimum of 13 active sites 
> within 12 months, or; f. By providing a reasonable technical 
> justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable.
> 
> Examples of justifications for why addresses from an ISP or other LIR 
> may be unsuitable include, but are not limited to:
> 
> > An organization that operates infrastructure critical to life safety
> or the functioning of society can justify the need for an assignment 
> based on the fact that renumbering would have a broader than expected 
> impact than simply the number of hosts directly involved. These would
> include: hospitals, fire fighting, police, emergency response, power 
> or energy distribution, water or waste treatment, traffic management 
> and control, etc.
> > Regardless of the number of hosts directly involved, an organization
> can justify the need for an assignment if renumbering would affect 
> 2000 or more individuals either internal or external to the organization.
> > An organization with a network not connected to the Internet can
> justify the need for an assignment by documenting a need for 
> guaranteed uniqueness, beyond the statistical uniqueness provided by 
> ULA (see RFC 4193).
> > An organization with a network not connected to the Internet, such 
> > as
> a VPN overlay network, can justify the need for an assignment if they 
> require authoritative delegation of reverse DNS.
> 
> Comments:
> a. Timetable for implementation: Immediate b. General Comments:
> 
> - Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and 
> insert a new subsection e. with the following text:
> 
> "By having a contiguous network that has a minimum of 13 active sites 
> within 12 months, or;
> 
> - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which 
> specifies 13 sites as the minimum number of sites required to receive 
> a
> /40 initial assignment, to attempt to provide a balance between the 
> costs of carrying the prefix vs. the costs to the end-user in renumbering.
> 
> - Further constraints were added in that the sites must be in a 
> contiguous network, to further attempt to reduce the costs of carrying 
> the prefix
> 
> - By introducing this new threshold, we attempt to restore equivalency 
> of number resources for those end-users whose economic costs to 
> renumber are equal to that of other end-users who would qualify for a 
> direct assignment under 6.5.8.1 c. and d.
> 
> c. Example:
> 
> Example of an end-user who would not qualify under 6.5.8.2 c. or d.:
> 
> - 50 locations (IPVPN) spread across the country/continent
> - 10 staff per location (average; 500 total)
> - 20 devices per location (average; 1000 total)
> - 2 subnets (voice & data) per location (average, 100 total)
> - Not multihomed
> - Currently using RFC1918 IPv4 space + NAT
> 
> This end-user only benefits minimally from IPv6 multihoming as they 
> are using an IPVPN, and multihoming provides benefit only for Internet 
> transit, not within their IPVPN. As such requiring the end-user to 
> multihome under NRPM 6.5.8.2 b. is wasteful.
> 
> This end user currently uses RFC1918 IPv4 address space + a relatively 
> small amount of IPv4 GUA + NAT (currently accepted industry practice 
> for IPv4). Changing providers involves only renumbering the small 
> amount of
> IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment 
> under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 
> assignment is incredibly wasteful of a valuable and limited number 
> resource. It also forces the customer occupy more routing table space, 
> as now an IPv4 PI prefix must be routed in addition to an IPv6 PI 
> prefix, instead of using
> IPv4 PA + IPv6 PI (where only space for an IPv6 PI prefix is required).
> 
> #####
> 
> ARIN STAFF ASSESSMENT
> 
> Draft Policy ARIN-2015-1
> Modification to Criteria for IPv6 Initial End-User Assignments 
> https://www.arin.net/policy/proposals/2015_1.html
> 
> Date of Assessment: June 11, 2015
> 
> ___
> 1. Summary (Staff Understanding)
> This proposal would add a criteria item to 6.5.8.1 (Initial Assignment 
> Criteria). Because each of the existing criteria items in that section 
> can independently qualify an organization for IPv6 address space from 
> ARIN, this new criteria item adds an additional qualification criteria.
> It makes it easier for some organizations to qualify, and does not 
> make it more difficult for anyone. In particular, it creates a new 
> criteria point that allows any end-user organization large enough to 
> have 13 sites to immediately qualify for IPv6 address space from ARIN.
> 
> ___
> 2. Comments
> A. ARIN Staff Comments
> This proposal can be implemented as written. Minimal staff training 
> and preparation would be needed to implement this if it were to become policy.
> We see no negative impacts.
> 
> B. ARIN General Counsel – Legal Assessment Counsel sees no material 
> legal issues in this policy.
> 
> ___
> 3. Resource Impact
> This policy would require minimal staff training and preparation. We 
> see no negative impacts.
> 
> ___
> 4. Proposal / Draft Policy Text Assessed
> 
> Draft Policy ARIN-2015-1
> Modification to Criteria for IPv6 Initial End-User Assignments
> 
> Date: 24 March 2015
> 
> Problem Statement:
> Current policy for assignment to end users excludes a class of users 
> whose costs to renumber would far exceed what current policy is 
> designed to mitigate.
> 
> Current measures designed to minimize the economic cost of renumbering 
> per NRPM 6.5.8.1 (Initial Assignment Criteria) are:
> 
> c. By having a network that makes active use of a minimum of 2000 IPv6 
> addresses within 12 months, or; d. By having a network that makes 
> active use of a minimum of 200 /64 subnets within 12 months, or;
> 
> These two measures fail to take into account end users who have a 
> large number of potentially geographically dispersed sites, or sites 
> with low subnet and/or user counts. The economic costs for this class 
> of end user would likely far exceed the costs that 6.5.8.1 c. and d. 
> are designed to mitigate.
> 
> While an end user could possibly apply (and receive an assignment) 
> under
> 6.5.8.1 e. ("By providing a reasonable technical justification 
> indicating why IPv6 addresses from an ISP or other LIR are 
> unsuitable"), it fails to provide a concrete threshold under which 
> this class of end-user can be reasonably assured of receiving address space.
> 
> Without having the reasonable assurance of IPv6 address number 
> resource continuity that a direct assignment allows, many smaller 
> enterprises are unlikely to adopt IPv6 (currently perceived as an 
> already tenuous proposition for most users given current 
> cost/benefit); or are likely to adopt technical measures (such as 
> using ULA addressing + NAT66) that are widely held to be damaging to the IPv6 Internet.
> 
> Policy Statement:
> 
> Replace the contents of NRPM 6.5.8.1 with:
> 
> 6.5.8.1. Initial Assignment Criteria
> 
> Organizations may justify an initial assignment for addressing devices 
> directly attached to their own network infrastructure, with an intent 
> for the addresses to begin operational use within 12 months, by 
> meeting one of the following criteria:
> 
> a. Having a previously justified IPv4 end-user assignment from ARIN or 
> one of its predecessor registries, or; b. Currently being IPv6 
> Multihomed or immediately becoming IPv6 Multihomed and using an 
> assigned valid global AS number, or; c. By having a network that makes 
> active use of a minimum of
> 2000 IPv6 addresses within 12 months, or; d. By having a network that 
> makes active use of a minimum of 200 /64 subnets within 12 months, or; e.
> By having a contiguous network that has a minimum of 13 active sites 
> within 12 months, or; f. By providing a reasonable technical 
> justification indicating why IPv6 addresses from an ISP or other LIR are unsuitable.
> 
> Examples of justifications for why addresses from an ISP or other LIR 
> may be unsuitable include, but are not limited to:
> 
> > An organization that operates infrastructure critical to life safety
> or the functioning of society can justify the need for an assignment 
> based on the fact that renumbering would have a broader than expected 
> impact than simply the number of hosts directly involved. These would
> include: hospitals, fire fighting, police, emergency response, power 
> or energy distribution, water or waste treatment, traffic management 
> and control, etc.
> > Regardless of the number of hosts directly involved, an organization
> can justify the need for an assignment if renumbering would affect 
> 2000 or more individuals either internal or external to the organization.
> > An organization with a network not connected to the Internet can
> justify the need for an assignment by documenting a need for 
> guaranteed uniqueness, beyond the statistical uniqueness provided by 
> ULA (see RFC 4193).
> > An organization with a network not connected to the Internet, such 
> > as
> a VPN overlay network, can justify the need for an assignment if they 
> require authoritative delegation of reverse DNS.
> 
> Comments:
> a. Timetable for implementation: Immediate b. General Comments:
> 
> - Changes to NRPM 6.5.8.1 are to renumber subsection e. to f. and and 
> insert a new subsection e. with the following text:
> 
> "By having a contiguous network that has a minimum of 13 active sites 
> within 12 months, or;
> 
> - The threshold of 13 sites was chosen based on NRPM 6.5.8.2, which 
> specifies 13 sites as the minimum number of sites required to receive 
> a
> /40 initial assignment, to attempt to provide a balance between the 
> costs of carrying the prefix vs. the costs to the end-user in renumbering.
> 
> - Further constraints were added in that the sites must be in a 
> contiguous network, to further attempt to reduce the costs of carrying 
> the prefix
> 
> - By introducing this new threshold, we attempt to restore equivalency 
> of number resources for those end-users whose economic costs to 
> renumber are equal to that of other end-users who would qualify for a 
> direct assignment under 6.5.8.1 c. and d.
> 
> c. Example:
> 
> Example of an end-user who would not qualify under 6.5.8.2 c. or d.:
> 
> - 50 locations (IPVPN) spread across the country/continent
> - 10 staff per location (average; 500 total)
> - 20 devices per location (average; 1000 total)
> - 2 subnets (voice & data) per location (average, 100 total)
> - Not multihomed
> - Currently using RFC1918 IPv4 space + NAT
> 
> This end-user only benefits minimally from IPv6 multihoming as they 
> are using an IPVPN, and multihoming provides benefit only for Internet 
> transit, not within their IPVPN. As such requiring the end-user to 
> multihome under NRPM 6.5.8.2 b. is wasteful.
> 
> This end user currently uses RFC1918 IPv4 address space + a relatively 
> small amount of IPv4 GUA + NAT (currently accepted industry practice 
> for IPv4). Changing providers involves only renumbering the small 
> amount of
> IPv4 GUA. Forcing the end-user to acquire an IPv4 direct assignment 
> under NRPM 6.5.8.2 a. in order to be able to get a direct IPv6 
> assignment is incredibly wasteful of a valuable and limited number 
> resource. It also forces the customer occupy more routing table space, 
> as now an IPv4 PI prefix must be routed in addition to an IPv6 PI 
> prefix, instead of using
> IPv4 PA + IPv6 PI (where only space for an IPv6 PI prefix is required).
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to the ARIN 
> Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net if you experience any issues.