[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21
David Farmer
farmer at umn.edu
Sun Jul 23 15:27:30 EDT 2017
On Sun, Jul 23, 2017 at 1:23 PM, <hostmaster at uneedus.com> wrote:
> Boy, am I learning from this process. Please let me know if I am not
> defining these terms we are discussing below properly:
>
Not quite: see NRPM section 2.5;
2.5. Allocate and Assign
A distinction is made between address allocation and address assignment,
i.e., ISPs are "allocated" address space as described herein, while
end-users are "assigned" address space.
Allocate - To allocate means to distribute address space to IRs for the
purpose of subsequent distribution by them.
Assign - To assign means to delegate address space to an ISP or end-user,
for specific use within the Internet infrastructure they operate.
Assignments must only be made for specific purposes documented by specific
organizations and are not to be sub-assigned to other parties.
And re-[allocate or assign] means an ISP is doing it not ARIN.
Ok, now that I have the terms out of the way, lets talk.
>
> There seems to be a current disconnect identified in the policy between
> Re-allocation and assignment because the term "Reassignment" in 6.5.5 is
> not defined.
>
> Many have identified that the minimum unit of assignment should be a /48
> and ARIN policy should not change this fact by putting policies in place
> that would make it more likely that assignments of less than /48 will be
> made by ISPs/LIRs. Therefore I propose the following amendments to the
> draft to address the issues that have been identified:
>
> Add new section 2.17 as follows:
>
> 2.17 Reassignment
>
> The term shall mean all cases where an Internet Registry, as defined in
> section 2.1 assigns or Re-allocates a portion of the addresses received
> from ARIN or another Internet Registry, for the use by end users or another
> Internet Registry. This term shall include within it the terms assignment
> and Re-allocation.
>
I might suggest this get added to section 2.5 or at least you reference the
definitions in that section.
I'll digest the rest of this later;
Amend 6.5.5.1 as follows:
>
> Change "Each static IPv6 assignment" to "Each static IPv6 reassignment".
>
> Change the word "sub-delegation" to "reassignment".
>
>
> Now some examples of how this draft policy will work with different size
> IPv6 blocks with the current global routing rules:
>
> For sites with exactly /48, there will be two classes of sites:
>
> 1) Those sites with a /48 assigned to them, and using the same routing as
> the parent block (Allocation or Re-allocation) above them.
>
> 2) Those sites with a /48 assigned to them, where the entity with the /48
> has made arrangements to have their /48 assignment routed differently than
> the parent block (Allocation or Re-allocation) above them.
>
> It is the intent of the language proposed to require 2) above to be
> registered in SWIP (since they have different routing), and to exempt 1)
> above from the SWIP requirement, as they are using the standard routing of
> their parent block, and for the most part will be normal sites that use
> just a single IPv4 address which no SWIP requirement exists, and a single
> /48 assigned to them for their site which has been identified as the best
> practice for all sites.
>
> I think this is the confusing part of the language, since a /48 can go
> either way, SWIP or no SWIP depending on independent routing, while
> anything larger is ALWAYS SWIP'ed and and everything smaller would under
> current best practices would never require SWIP.
>
> Under the draft, For any reassignment with a /47 or More of addresses, ALL
> will require SWIP. This should cover ALL Re-allocation cases, as the
> reallocated block received must for technical reasons be large enough for
> the reallocator to have 1 or more /48's to assign to the customers below
> them.
>
> Under the draft, For any site of any size, if the GRT policy is ever
> changed from a /48, all such sites smaller than the new limit that has
> independent routing MUST be registered in SWIP. The policy intent expressed
> is SWIP registration of all independently routed blocks, not a specific
> block size, since routing is not an ARIN decision. Since current best
> practice does not allow independent routing of less than a /48, all sites
> regardless of any attempts of independent routing that are smaller than /48
> actually are not independently routed since those routes will not appear in
> the GRT, and thus are exempt from SWIP. This level of /48 could change in
> the future via processes outside of the control of ARIN.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Sun, 23 Jul 2017, David Farmer wrote:
>
> The rewrite is a pretty good step forward, and I support this policy as
>> written, but I also would like to see some additional changes.
>>
>> The following is a summary of what I would like to see the overall policy
>> look like, it is not in policy language but provided as list of
>> requirement, with some additional notes, then I note what I think is
>> missing from the current proposed policy text;
>>
>> Reallocations:
>> - All reallocations* MUST have a SWIP provided regardless of size.
>>
>> Reassignments:
>> - For prefixes shorter than /48 a SWIP MUST be provided.
>> - For prefixes at /48 or longer a SWIP is provided at the discretion** of
>> the ISP, except;
>> - If requested by the end-user, then a SWIP MUST be provided, or;
>> - If intended to appear in global routing table, then a SWIP SHOULD*** be
>> provided.
>>
>> * Reallocations are made to other ISPs which then can make reassignments,
>> for IPv6 it is RECOMMENDED that all ISPs obtain an allocation directly
>> from
>> ARIN, however reallocations are still permitted. Further, reallocations
>> for
>> prefixes /48 or longer are NOT RECOMMENDED. SWIPs for reallocations need
>> to be required because the abuse and other POC for the down stream ISP
>> need
>> to be know.
>>
>> ** There should be some guidance (NOT policy enforced by ARIN) to ISPs
>> making reassignments at /48 or longer: SWIPs for business customers,
>> especially those with information technology(IT) operations sophisticated
>> enough to handle their own abuse and/or technical incidents, are of
>> interest to the community. SWIPs for residential customers (individual
>> persons) are NOT normally of interest to the community.
>>
>> *** This might be more appropriate as MUST, however as ARIN does not
>> define
>> routing policy, therefore SHOULD seems more appropriate.
>>
>> So, I think the following is missing from the current proposed policy
>> text;
>>
>> 1. Any mention of reallocations, but this wasn't in the original policy
>> either
>> 2. A requirement that SWIP is provided if requested by end-user
>> 3. Guidance for SWIPs for /48 or longer, while these SWIPs aren't
>> required,
>> some guidance still might be useful.
>>
>> Thanks
>>
>> On Fri, Jul 21, 2017 at 11:44 AM, Leif Sawyer <lsawyer at gci.com> wrote:
>>
>> Happy Friday, everybody.
>>>
>>>
>>>
>>> As promised, here is the latest rewrite of the draft policy below, and
>>> it
>>> will soon be updated at:
>>>
>>> https://www.arin.net/policy/proposals/2017_5.html
>>>
>>>
>>>
>>> There are two changes noted in the policy statement: the first of which
>>> reflects what seems to be the current
>>>
>>> consensus of the PPML regarding netblock sizing; the second is to strike
>>> language that may be read as either restrictive
>>>
>>> or non-operational.
>>>
>>>
>>>
>>> ----
>>>
>>>
>>>
>>> Problem Statement:
>>>
>>> Current ARIN policy has different WHOIS directory registration
>>> requirements for IPv4 vs IPv6 address assignments.
>>>
>>> IPv4 registration is triggered for an assignment of any address
>>> block equal to or greater than a /29 (i.e., eight IPv4 addresses).
>>>
>>> In the case of IPv6, registration occurs for an assignment of any
>>> block equal to or greater than a /64, which constitutes one entire IPv6
>>> subnet and is the minimum block size for an allocation.
>>>
>>> Accordingly, there is a significant disparity between IPv4 and
>>> IPv6
>>> WHOIS registration thresholds in the case of assignments, resulting in
>>> more
>>> work in the case of IPv6 than is the case for IPv4.
>>>
>>> There is no technical or policy rationale for the disparity, which
>>> could serve as a deterrent to more rapid IPv6 adoption.
>>>
>>> The purpose of this proposal is to eliminate the disparity and
>>> corresponding adverse consequences.
>>>
>>>
>>>
>>> Policy statement:
>>>
>>> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to
>>> strike "/64 or more addresses" and change to "/47 or more addresses, or
>>> sub-delegation of any size that will be individually announced,"
>>>
>>> and
>>>
>>> 2) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the
>>> NRPM by deleting the phrase "holding /64 and larger blocks"
>>>
>>>
>>>
>>> Comments:
>>>
>>> a. Timetable for implementation:
>>>
>>> Policy should be adopted as soon as possible.
>>>
>>>
>>>
>>> b. Anything else:
>>>
>>> Author Comments:
>>>
>>> IPv6 should not be more burdensome than the equivalent IPv4
>>> network size.
>>>
>>> Currently, assignments of /29 or more of IPv4 space (8
>>> addresses)
>>> require registration
>>>
>>> The greatest majority of ISP customers who have assignments of
>>> IPv4 space are of a single IPv4 address which do not trigger any ARIN
>>> registration requirement when using IPv4.
>>>
>>> This is NOT true when these same exact customers use IPv6, as
>>> assignments of /64 or more of IPv6 space require registration.
>>>
>>> Beginning with RFC 3177, it has been standard practice to assign
>>> a minimum assignment of /64 to every customer end user site, and less is
>>> never used.
>>>
>>> This means that ALL IPv6 assignments, including those customers
>>> that only use a single IPv4 address must be registered with ARIN if they
>>> are given the minimum assignment of /64 of IPv6 space.
>>>
>>> This additional effort may prevent ISP's from giving IPv6
>>> addresses because of the additional expense of registering those
>>> addresses
>>> with ARIN, which is not required for IPv4.
>>>
>>> The administrative burden of 100% customer registration of IPv6
>>> customers is unreasonable, when such is not required for those customers
>>> receiving only IPv4 connections.
>>>
>>>
>>>
>>>
>>>
>>> ---
>>>
>>>
>>>
>>> Leif Sawyer
>>>
>>> Advisory Council
>>>
>>>
>>>
>>> _______________________________________________
>>> 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.
>>>
>>>
>>
>>
>> --
>> ===============================================
>> David Farmer Email:farmer at umn.edu
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota
>> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815>
>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952>
>> ===============================================
>>
>> _______________________________________________
> 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.
>
--
===============================================
David Farmer Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 612-626-0815
Minneapolis, MN 55414-3029 Cell: 612-812-9952
===============================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170723/afbb067c/attachment.htm>
More information about the ARIN-PPML
mailing list