On Sun, Jul 23, 2017 at 1:23 PM, <[email protected]> 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 <[email protected]> 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 ([email protected]). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact [email protected] if you experience any issues. >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:[email protected] >> 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 ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues. > -- =============================================== David Farmer Email:[email protected] 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 ===============================================
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
