As I currently ready 6.5.5.1 there are two classes of addresses that are required to be SWIP'd A. any re-allocation or re-assignment that is a /47 or less specific (/46, /45, ...) B. any sub-deligation that will be individually announced
I recall there being a third class, any re-allocation. A re-allocation is when I ISP provides addresses to their down stream ISP customer who then in turn will further sub-delegate address space to their customer (who may also be an ISP with customers... and so on). Can I suggest a friendly amendment of: 6.5.5.1. Re-allocation / reassignment information Each static IPv6 re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced, ... ___Jason On Wed, Aug 30, 2017 at 1:15 PM, Jason Schiller <[email protected]> wrote: > The new policy (along with pre-existing text) will read as follows: > > 6.5.5.1. Reassignment information > Each static IPv6 assignment containing a /47 or more addresses, or > subdelegation > of any size that will be individually announced, shall be registered in > the WHOIS > directory via SWIP or a distributed service which meets the standards set > forth in section 3.2. Reassignment registrations shall include each > client's > organizational information, except where specifically exempted by this > policy. > > 6.5.5.2. Assignments visible within 7 days > All assignments shall be made visible as required in section 6.5.5.1 > within seven > calendar days of assignment. > > 6.5.5.3. Residential Subscribers > 6.5.5.3.1. Residential Customer Privacy > 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. > > 6.5.5.4 Registration Requested by Recipient > If the downstream recipient of a static assignment of /64 or more > addresses requests > publishing of that assignment in ARIN's registration database, the ISP > must register > that assignment as described in section 6.5.5.1. > > > > On Tue, Aug 29, 2017 at 9:02 PM, <[email protected]> wrote: > >> I think we got it this time. >> >> I support. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Tue, 22 Aug 2017, ARIN wrote: >> >> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_5.html >>> >>> Note that the Draft Policy title has changed from "Equalization of >>> Assignment Registration requirements between IPv4 and IPv6" >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will >>> evaluate the discussion in order to assess the conformance of this draft >>> policy with ARIN's Principles of Internet number resource policy as stated >>> in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP 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, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>> >>> 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 >>> subdelegation of any size that will be individually announced," >>> >>> and >>> >>> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the >>> NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1" >>> >>> and >>> >>> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM >>> by deleting the phrase "holding /64 and larger blocks" >>> >>> and >>> >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the >>> NRPM, to read: "If the downstream recipient of a static assignment of /64 >>> or more addresses requests publishing of that assignment in ARIN's >>> registration database, the ISP must register that assignment as described >>> in section 6.5.5.1." >>> >>> 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. >>> _______________________________________________ >>> 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. >>> >>> _______________________________________________ >> 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. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected]|571-266-0006 <(571)%20266-0006> > > -- _______________________________________________________ Jason Schiller|NetOps|[email protected]|571-266-0006
_______________________________________________ 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.
