From hostmaster at uneedus.com Wed Jul 5 04:48:18 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 5 Jul 2017 04:48:18 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59384CCF.3080009@arin.net> <949A0F0F-F895-4303-8E09-3443A4328B4B@gmail.com> Message-ID: It has now been about 4 weeks since ARIN-2017-5 was last revised. Based on the comments received, "more than a /56" is the consensus. I ask that the AC revise the proposal to this value, so it can be further considered. This is the tally so far: /56 9 votes Any of these levels are OK - 2 votes /60 2 votes /61 1 vote /57 1 vote /53 1 vote /49 1 vote Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 7 Jun 2017, Leif Sawyer wrote: > That was not changed yet, as I'm still waiting for more folks to respond. > > The update was only for the removal of the IPv4 portion, as I mentioned in my previous email. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Wednesday, June 07, 2017 11:13 AM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > [External Email] > > It looks like /60 still needs to be changed to /56 to reflect the consensus on PPML. Or was there some reason not to do that (yet)? > > Scott > >> On Jun 7, 2017, at 11:58 AM, ARIN > wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.html >> >> 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) >> >> >> >> >> >> Problem Statement: >> >> 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 or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6. >> >> Currently, 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. >> >> IPv6 assignments are therefore treated stricter than IPv4 assignments. Policy should either treat both protocols the same, or provide incentive for the IPv6 future. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size. >> >> In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 6.5.5.1 clearly requires this. >> >> It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv6 /64 networks. This would treat IPv6 slightly better than IPv4, and provide additional encouragement for adoption. >> >> Policy statement: >> >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". >> >> Comments: >> >> a. Timetable for implementation: >> >> Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size. >> >> b. Anything else: >> >> The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less IPv6 networks (/60) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's. >> >> There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is cu! rr > ently the case, and thus, this policy needs to be changed. >> _______________________________________________ >> 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. > From lsawyer at gci.com Wed Jul 5 12:30:25 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 5 Jul 2017 16:30:25 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59384CCF.3080009@arin.net> <949A0F0F-F895-4303-8E09-3443A4328B4B@gmail.com> Message-ID: Thanks, Albert. We're taking all of this feedback under consideration, and I'll endeavor to have updates after the holiday week is over. Leif Sawyer ARIN Advisory Council From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of hostmaster at uneedus.com Sent: Wednesday, July 05, 2017 12:48 AM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 [External Email] It has now been about 4 weeks since ARIN-2017-5 was last revised. Based on the comments received, "more than a /56" is the consensus. I ask that the AC revise the proposal to this value, so it can be further considered. This is the tally so far: /56 9 votes Any of these levels are OK - 2 votes /60 2 votes /61 1 vote /57 1 vote /53 1 vote /49 1 vote Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 7 Jun 2017, Leif Sawyer wrote: > That was not changed yet, as I'm still waiting for more folks to respond. > > The update was only for the removal of the IPv4 portion, as I mentioned in my previous email. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Wednesday, June 07, 2017 11:13 AM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > [External Email] > > It looks like /60 still needs to be changed to /56 to reflect the consensus on PPML. Or was there some reason not to do that (yet)? > > Scott > >> On Jun 7, 2017, at 11:58 AM, ARIN >> wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.html> >> >> 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) >> >> >> >> >> >> Problem Statement: >> >> 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 or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6. >> >> Currently, 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. >> >> IPv6 assignments are therefore treated stricter than IPv4 assignments. Policy should either treat both protocols the same, or provide incentive for the IPv6 future. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size. >> >> In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 6.5.5.1 clearly requires this. >> >> It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv6 /64 networks. This would treat IPv6 slightly better than IPv4, and provide additional encouragement for adoption. >> >> Policy statement: >> >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". >> >> Comments: >> >> a. Timetable for implementation: >> >> Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size. >> >> b. Anything else: >> >> The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less IPv6 networks (/60) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's. >> >> There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is cu! rr > ently the case, and thus, this policy needs to be changed. >> _______________________________________________ >> 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. > _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 11 20:32:34 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Jul 2017 17:32:34 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> > On May 30, 2017, at 06:41 , William Herrin wrote: > > On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin > wrote: > Hello all, > > I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. > > Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. > > With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. > > That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. > > Howdy, > > I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. This is one of those rare occasions when I absolutely agree with Bill. If we?re going to do this, I would support a requirement as follows: 1. For customers fitting the definition in NRPM 2.13, /47 or shorter. 2. For customers not fitting the definition in NRPM 2.13 /63 or shorter. > Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. Yes? The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router. If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 11 20:41:03 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Jul 2017 17:41:03 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> Message-ID: <658F1D2F-F4A8-4E28-B9A8-C0D5513C942B@delong.com> > I also question why 100% SWIP on v6, because 99.9% of ISP's are not coming back for a new assignment. While SWIP is useful for network security and contact needs, this is NOT the purpose it was established. It was established to document an ISP's address utilization rates for ARIN to be used when the ISP requests more space. Since very few have come back to ARIN for more v6 space, I think its purpose is not needed until such time as an ISP needs to get its ducks together to ask for more IPv6 space, which with the larger space of v6 will be never for most ISP?s. As someone who was around back when much of this was hashed out, I can assure you that SWIP (and WHOIS before it) was not deployed primarily for ISPs to document utilization. It was, in fact, primarily for security and contact purposes from the first days of the WHOIS protocol. RIR uses (and RIRs themselves) came much later in the game. The RIR rules and requirements around SWIP and WHOIS were actually put in place primarily to protect this ability to have security and contact information where needed. Later the RIRs discovered the usefulness of this same data for utilization validation, but it was NOT the original purpose for collecting the data. > I also do not think ARIN's policies should be supporting the business models of the Geolocation providers, of which one of the most annoying customers of same is the Copyright Trolls. Even the "Residential Privacy" people must publically declare a zipcode, a goldmine for the Geolocation providers. As one who works for a company that is not strictly a geolocation provider, but which does a great deal of geolocation as part of its other business needs, I will say this simply isn?t true. Any geolocation provider basing their conclusions on whois is an extremely inaccurate geolocation provider. Owen From owen at delong.com Tue Jul 11 20:50:24 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 11 Jul 2017 17:50:24 -0700 Subject: [arin-ppml] Discussion on elimination of SWIP requirements. In-Reply-To: <03381116-0F5E-44F5-B923-0E52454D907D@arin.net> References: <551ebd1d-517e-5fb2-e379-0c45674b1f9d@linuxmagic.com> <50144.1496527569@segfault.tristatelogic.com> <20170604152843.onjuibc4s3eqzgcw@mx4.yitter.info> <03381116-0F5E-44F5-B923-0E52454D907D@arin.net> Message-ID: <91AE652C-5C8F-4B0D-8E80-CB7BC48374A5@delong.com> > On Jun 4, 2017, at 08:46 , John Curran wrote: > > On 4 Jun 2017, at 10:28 AM, Andrew Sullivan wrote: >> On Sat, Jun 03, 2017 at 03:06:09PM -0700, Ronald F. Guilmette wrote: >> >>> if anything, the existing SWIP rules strengthened, rather than >>> diluted, and, more importantly, would like to see them actually >>> enforced someday. >> >> By whom? "Enforcement" implies that there is some authority that >> really can make such things happen. The Internet Cops. The ITU. >> "Law enforcement", whoever that is. Someone. >> >> I"n my opinion, it is fortunate for us that we do not have such a >> body. What we have are registries whose ability to "enforce" anything >> largely depends on the interests of the enforced-upon, so that making >> the Internet work in our shared and common interest is the real test >> of the value of these policies. > > Andrew - > > Full agreement with your sentiment, but I must make one point quite clear > to the community participating in this policy development - > > As noted earlier, if this community develops and adopts policy regarding how > the number registry is to be operated, ARIN will indeed implement such policy > (including marking or revocation of number resources blocks as appropriate > per policy.) I am in no way advocating for, or against, any policy change, but > simply making clear that the ARIN community does have the ability to specify > how the registry will be operated and ARIN will enforce any resulting policy, > at least with respect to registry operation. With the notable exception that the board has preempted the community from actually making any policy about revocation due to non-utilization actually stick by creating terms in the RSA which specifically preclude such revocation. Owen From bill at herrin.us Tue Jul 11 21:03:17 2017 From: bill at herrin.us (William Herrin) Date: Tue, 11 Jul 2017 21:03:17 -0400 Subject: [arin-ppml] Discussion on elimination of SWIP requirements. In-Reply-To: <91AE652C-5C8F-4B0D-8E80-CB7BC48374A5@delong.com> References: <551ebd1d-517e-5fb2-e379-0c45674b1f9d@linuxmagic.com> <50144.1496527569@segfault.tristatelogic.com> <20170604152843.onjuibc4s3eqzgcw@mx4.yitter.info> <03381116-0F5E-44F5-B923-0E52454D907D@arin.net> <91AE652C-5C8F-4B0D-8E80-CB7BC48374A5@delong.com> Message-ID: On Tue, Jul 11, 2017 at 8:50 PM, Owen DeLong wrote: > With the notable exception that the board has preempted the community from > actually > making any policy about revocation due to non-utilization actually stick > by creating > terms in the RSA which specifically preclude such revocation. > But Owen! Revocation is not a policy, it's a business practice! Because... John! Just like deciding which resources to include or exclude from revenue eligibility is not number policy. Because ARIN staff shouldn't just set rates, they should also decide for us which services are free to the public in support of ARIN's mission and which are not. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From abagrin at mydigitalshield.com Tue Jul 11 23:56:04 2017 From: abagrin at mydigitalshield.com (Andrew Bagrin) Date: Tue, 11 Jul 2017 23:56:04 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <658F1D2F-F4A8-4E28-B9A8-C0D5513C942B@delong.com> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <658F1D2F-F4A8-4E28-B9A8-C0D5513C942B@delong.com> Message-ID: True, but it does help when it is being used. If we could increase the adoption of SWIP from the service providers, it would also be used more heavily for geolocation services, and the upward spiral begins. There will always be some abuse of geolocation services as long as there are georestrictions for media etc.. It's between service provider authenticity and the service that requires geolocation that the trust needs to be formed. It's up to us to provide a mechanism/tool/information to allow them to build that trust. I'm all for having the ability to SWIP per IP, and it's up to me as a service provider to keep it as authentic as I can, so Netflix can trust me. When applying this to IPv6 (and forgive my lack of knowledge) but part of the address is identifying the physical interface (hardware). Seems a SWIP registration should be on that part of the address and then regardless of service provider that host will always be identified the same, owned by Bob Smith. As a service provider (SDWAN provider) I would NAT their network portion of their traffic to return to me, but keep the host the same. If I'm trying to hide the identity of the host by doing a full NAT with an encrypted tunnel, I'm clearly up to no good and shouldn't be trusted by content providers anyway. Trying to hide who I am is not security, it's trying to disguise myself to obtain something my actual ID would not allow me to, or I wouldn't want someone knowing I'm trying to obtain something. All in all, I think we need to provide a mechanism that can allow SP's and applications to build trust through that mechanism. My newbie 2 cents. -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Tuesday, July 11, 2017 8:41 PM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > I also question why 100% SWIP on v6, because 99.9% of ISP's are not coming > back for a new assignment. While SWIP is useful for network security and > contact needs, this is NOT the purpose it was established. It was > established to document an ISP's address utilization rates for ARIN to be > used when the ISP requests more space. Since very few have come back to > ARIN for more v6 space, I think its purpose is not needed until such time > as an ISP needs to get its ducks together to ask for more IPv6 space, > which with the larger space of v6 will be never for most ISP?s. As someone who was around back when much of this was hashed out, I can assure you that SWIP (and WHOIS before it) was not deployed primarily for ISPs to document utilization. It was, in fact, primarily for security and contact purposes from the first days of the WHOIS protocol. RIR uses (and RIRs themselves) came much later in the game. The RIR rules and requirements around SWIP and WHOIS were actually put in place primarily to protect this ability to have security and contact information where needed. Later the RIRs discovered the usefulness of this same data for utilization validation, but it was NOT the original purpose for collecting the data. > I also do not think ARIN's policies should be supporting the business > models of the Geolocation providers, of which one of the most annoying > customers of same is the Copyright Trolls. Even the "Residential Privacy" > people must publically declare a zipcode, a goldmine for the Geolocation > providers. As one who works for a company that is not strictly a geolocation provider, but which does a great deal of geolocation as part of its other business needs, I will say this simply isn?t true. Any geolocation provider basing their conclusions on whois is an extremely inaccurate geolocation provider. Owen _______________________________________________ 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. From hostmaster at uneedus.com Wed Jul 12 02:26:49 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 12 Jul 2017 02:26:49 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> Message-ID: First of all, ALL changes to v4 have been withdrawn from this proposal. This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or more) and this is unequal with v4 that has an 8 or more address standard for SWIP. I think that drawing the SWIP boundary for IPv6 based upon residential/non residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would treat v6 and v4 differently. Currently in v4, it is 8 or more addresses. Residential or Non Residential does not change the SWIP requirement in IPv4 in any way. Thus, whatever boundary is chosen for v6, I think it should be a fixed value, just like in IPv4. I would like to hear the exact reasons why it has been proposed that there should be a residential/non residential difference in SWIP policy, and what this difference in policy is meant to address. If it is a valid reason, this should carry over to IPv4. Some commenters have suggested that routeability should be a factor in determining if SWIP is needed. In IPv4, it is not possible to route anything smaller than a /24, but the current SWIP v4 standard is /29 or more, much smaller than the routability standard. In IPv6, nothing smaller than a /48 is routable, so I kinda think that IPv4 /29 is very close to equal to IPv6 more than a /56, and also not independently routable. The comments I have been watching have strongly supported setting the SWIP level for IPv6 at more than a /56. This is only one nibble away from /60 in the current proposal. I also note that it seems quite universal that most commenters think that a /64 is wrong, and everyone, even dynamic residential customers deserve to have at least a /60 so that they can route packets in v6. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 11 Jul 2017, Owen DeLong wrote: > >> On May 30, 2017, at 06:41 , William Herrin wrote: >> >> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin > wrote: >> Hello all, >> >> I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. >> >> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. >> >> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. >> >> That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. >> >> Howdy, >> >> I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. > > This is one of those rare occasions when I absolutely agree with Bill. If we???re going to do this, I would support a requirement as follows: > > 1. For customers fitting the definition in NRPM 2.13, /47 or shorter. > 2. For customers not fitting the definition in NRPM 2.13 /63 or shorter. > >> Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. > > Yes??? The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router. > > If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification. > > Owen > > From owen at delong.com Thu Jul 13 00:56:29 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jul 2017 21:56:29 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> Message-ID: <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> > On Jul 11, 2017, at 23:26 , hostmaster at uneedus.com wrote: > > First of all, ALL changes to v4 have been withdrawn from this proposal. This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or more) and this is unequal with v4 that has an 8 or more address standard for SWIP. > > I think that drawing the SWIP boundary for IPv6 based upon residential/non residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would treat v6 and v4 differently. Currently in v4, it is 8 or more addresses. Residential or Non Residential does not change the SWIP requirement in IPv4 in any way. You are entitled to your opinion, but IPv6 _IS_ fundamentally different from IPv4. The line is drawn where it is in IPv4 because for the most part, in IPv4, it?s actually rare for a residential customer to have 8 or more addresses assigned to their service and in such cases, it?s usually not a purely residential service. Further, at the time that line was drawn for IPv4, the definition of a residential customer and the residential customer privacy policies did not exist in the NRPM. > Thus, whatever boundary is chosen for v6, I think it should be a fixed value, just like in IPv4. I would like to hear the exact reasons why it has been proposed that there should be a residential/non residential difference in SWIP policy, and what this difference in policy is meant to address. If it is a valid reason, this should carry over to IPv4. There already is a residential/non-residential difference in that residential customers are allowed to be SWIPd with limited information. Further, as I stated above, the /29 boundary was chosen primarily because it was a convenient proxy for residential vs. business utilization. > Some commenters have suggested that routeability should be a factor in determining if SWIP is needed. In IPv4, it is not possible to route anything smaller than a /24, but the current SWIP v4 standard is /29 or more, much smaller than the routability standard. In IPv6, nothing smaller than a /48 is routable, so I kinda think that IPv4 /29 is very close to equal to IPv6 more than a /56, and also not independently routable. Trying to draw such comparisons between IPv4 and IPv6 is utterly and completely specious, generally speaking. For any parallel you can draw I can cite multiple examples where it simply doesn?t fit. The simple fact of the matter is that IPv4 is a densely allocated space with a serious shortage of addresses. IPv6 is an entirely different addressing architecture with entirely different requirements and (hopefully) entirely different management styles. > The comments I have been watching have strongly supported setting the SWIP level for IPv6 at more than a /56. This is only one nibble away from /60 in the current proposal. I also note that it seems quite universal that most commenters think that a /64 is wrong, and everyone, even dynamic residential customers deserve to have at least a /60 so that they can route packets in v6. IMHO, even dynamic residential customers deserve to have at least a /48 as is the fundamental design intention of IPv6. I realize that there are those who oppose this view, but I?m quite certain that if you research it, you will find that there are no convincing arguments favoring longer prefixes for residential. In fact, almost every argument offered favoring these longer prefixes is based almost entirely on IPv4-think (shortage mentality and conservation). In 2000::/3 (1/8th of the total IPv6 space which the IETF has currently set aside as GUA), there are 2^45 /48s. That?s 35,184,372,088,832 (35 trillion) /48s. The total population of the world is 7 Billion. So in this first 1/8th of the IPv6 space, we have enough /48s to issue 5,000 to every single person on earth. (Yes, I realize there?s also addresses needed for servers, infrastructure, etc., but I think we can take that out of the extra 4,999 /48s per person and still have room to spare). If it turns out I?m wrong and we somehow exhaust the first /3 within my lifetime, I?ll join others in advocating more conservative policy for the next /3. There are still at least 3 more empty /3s after that and 3 more nearly empty /3s beyond those. (IETF is talking about issuing addresses from a third /3 for some special purpose I forget in addition to the minimal allocations out of the end of e000::/3 (multicast, ULA, etc.) and 0000::/3 (unknown, default, loopback, IPv4 mapped, etc.)). So, while at the time of drafting, the IPv4 policy used /29 as a proxy for the distinction between business and residential and while there was concern about transparency of utilization and not wanting to allow ISPs to hide artificially large allocations by calling them residential, those issues really don?t apply in the IPv6 world. Since ARIN policy fully supports, and even encourages /48s being issued to residential customers for IPv6, I see no reason that a SWIP boundary of larger than /56 is any more desirable than a SWIP boundary of larger than /48 with the proviso that businesses should be SWIPd regardless as I fail to see a public good from privacy protections for address assignments to businesses. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > > On Tue, 11 Jul 2017, Owen DeLong wrote: > >> >>> On May 30, 2017, at 06:41 , William Herrin wrote: >>> >>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin > wrote: >>> Hello all, >>> >>> I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. >>> >>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. >>> >>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. >>> >>> That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. >>> >>> Howdy, >>> >>> I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. >> >> This is one of those rare occasions when I absolutely agree with Bill. If we?re going to do this, I would support a requirement as follows: >> >> 1. For customers fitting the definition in NRPM 2.13, /47 or shorter. >> 2. For customers not fitting the definition in NRPM 2.13 /63 or shorter. >> >>> Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. >> >> Yes? The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router. >> >> If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification. >> >> Owen >> > _______________________________________________ > 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. From owen at delong.com Thu Jul 13 00:58:39 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 12 Jul 2017 21:58:39 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <658F1D2F-F4A8-4E28-B9A8-C0D5513C942B@delong.com> Message-ID: > When applying this to IPv6 (and forgive my lack of knowledge) but part of > the address is identifying the physical interface (hardware). Seems a SWIP > registration should be on that part of the address and then regardless of > service provider that host will always be identified the same, owned by Bob > Smith. As a service provider (SDWAN provider) I would NAT their network > portion of their traffic to return to me, but keep the host the same. > If I'm trying to hide the identity of the host by doing a full NAT with an > encrypted tunnel, I'm clearly up to no good and shouldn't be trusted by > content providers anyway. Trying to hide who I am is not security, it's > trying to disguise myself to obtain something my actual ID would not allow > me to, or I wouldn't want someone knowing I'm trying to obtain something. For better or worse, the IETF (and the OS vendors) have put significant effort into making sure that the above is completely and utterly false for all practical purposes. Owen From hostmaster at uneedus.com Thu Jul 13 12:32:57 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 13 Jul 2017 12:32:57 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> Message-ID: The main reason I advanced this proposal is because the policy for the average small user of IPv4 differs greatly from that of that same small user when they chose to go dual stack and add IPv6 to their network. The majority of all internet connections for residential and small/medium business use in IPv4 land is a single public (or in some cases CGnat) address behind a internal block of RFC1918 private network addresses. As to SWIP, ISP's might have just a single entry showing a given block of addresses are assigned to residential and small business customers to document the assignment of these addresses for ARIN. There is no actual SWIP down to the individual customer level. Only a small portion of total ISP customers hold more than a /29, so very few individual SWIP records are needed, and these are the customers that have 8 or more v4 addresses. ISP's have fees for assigning these blocks, so any registration costs are passed to the customer. In IPv6, that changes. Currently, even the smallest block (/64) must be registered when they are assigned to a customer. There is NO useable level that does not require registration, and this is the problem I seek to change. It was generally agreed during discussion that even the smallest v6 customer needs to be able to route, so that means the minimum block assigned to the smallest user cannot for technical reasons be any smaller than a /60, and giving out /64's is not wise. Since a /48 can be independently routed, of course a /48 should be subject to SWIP. Others have suggested the SWIP standard should be tied to the block being independently routed. However, that is not the standard in v4, where the routing standard is /24, and the SWIP standard is /29. Like the difference between /24, the smallest routable network in v4, /32, the amount of v4 space the majority of customers have, and /29, the current SWIP standard, a number for v6 between /48 and /60 should be chosen to be the level that triggers SWIP, instead of the current policy of SWIP everyone. I initially proposed the absolute minimum size in my proposal that permits routing which is to allow /60 and /64 subnets to be exempted from the SWIP policy. After discussion, the majority of commenters feel that a /56 should also be exempted and this was the consensus. In order to put the language in the same form as the IPv4 section, I understand the language will be changed to "/55 or more" instead of "more than a /56" in the next version of the draft, leaving /56, /60 and /64 exempted from mandatory SWIP registration, in much the same fashion as /30, /31 and /32 are exempted in the IPv4 world. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 12 Jul 2017, Owen DeLong wrote: > >> On Jul 11, 2017, at 23:26 , hostmaster at uneedus.com wrote: >> >> First of all, ALL changes to v4 have been withdrawn from this proposal. This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or more) and this is unequal with v4 that has an 8 or more address standard for SWIP. >> >> I think that drawing the SWIP boundary for IPv6 based upon residential/non residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would treat v6 and v4 differently. Currently in v4, it is 8 or more addresses. Residential or Non Residential does not change the SWIP requirement in IPv4 in any way. > > You are entitled to your opinion, but IPv6 _IS_ fundamentally different from IPv4. > > The line is drawn where it is in IPv4 because for the most part, in IPv4, it???s actually rare for a residential customer to have 8 or more addresses assigned to their service and in such cases, it???s usually not a purely residential service. Further, at the time that line was drawn for IPv4, the definition of a residential customer and the residential customer privacy policies did not exist in the NRPM. > >> Thus, whatever boundary is chosen for v6, I think it should be a fixed value, just like in IPv4. I would like to hear the exact reasons why it has been proposed that there should be a residential/non residential difference in SWIP policy, and what this difference in policy is meant to address. If it is a valid reason, this should carry over to IPv4. > > There already is a residential/non-residential difference in that residential customers are allowed to be SWIPd with limited information. > > Further, as I stated above, the /29 boundary was chosen primarily because it was a convenient proxy for residential vs. business utilization. > >> Some commenters have suggested that routeability should be a factor in determining if SWIP is needed. In IPv4, it is not possible to route anything smaller than a /24, but the current SWIP v4 standard is /29 or more, much smaller than the routability standard. In IPv6, nothing smaller than a /48 is routable, so I kinda think that IPv4 /29 is very close to equal to IPv6 more than a /56, and also not independently routable. > > Trying to draw such comparisons between IPv4 and IPv6 is utterly and completely specious, generally speaking. For any parallel you can draw I can cite multiple examples where it simply doesn???t fit. > > The simple fact of the matter is that IPv4 is a densely allocated space with a serious shortage of addresses. > IPv6 is an entirely different addressing architecture with entirely different requirements and (hopefully) entirely different management styles. > >> The comments I have been watching have strongly supported setting the SWIP level for IPv6 at more than a /56. This is only one nibble away from /60 in the current proposal. I also note that it seems quite universal that most commenters think that a /64 is wrong, and everyone, even dynamic residential customers deserve to have at least a /60 so that they can route packets in v6. > > IMHO, even dynamic residential customers deserve to have at least a /48 as is the fundamental design intention of IPv6. I realize that there are those who oppose this view, but I???m quite certain that if you research it, you will find that there are no convincing arguments favoring longer prefixes for residential. In fact, almost every argument offered favoring these longer prefixes is based almost entirely on IPv4-think (shortage mentality and conservation). > > In 2000::/3 (1/8th of the total IPv6 space which the IETF has currently set aside as GUA), there are 2^45 /48s. That???s 35,184,372,088,832 (35 trillion) /48s. The total population of the world is 7 Billion. So in this first 1/8th of the IPv6 space, we have enough /48s to issue 5,000 to every single person on earth. (Yes, I realize there???s also addresses needed for servers, infrastructure, etc., but I think we can take that out of the extra 4,999 /48s per person and still have room to spare). > > If it turns out I???m wrong and we somehow exhaust the first /3 within my lifetime, I???ll join others in advocating more conservative policy for the next /3. There are still at least 3 more empty /3s after that and 3 more nearly empty /3s beyond those. (IETF is talking about issuing addresses from a third /3 for some special purpose I forget in addition to the minimal allocations out of the end of e000::/3 (multicast, ULA, etc.) and 0000::/3 (unknown, default, loopback, IPv4 mapped, etc.)). > > So, while at the time of drafting, the IPv4 policy used /29 as a proxy for the distinction between business and residential and while there was concern about transparency of utilization and not wanting to allow ISPs to hide artificially large allocations by calling them residential, those issues really don???t apply in the IPv6 world. > > Since ARIN policy fully supports, and even encourages /48s being issued to residential customers for IPv6, I see no reason that a SWIP boundary of larger than /56 is any more desirable than a SWIP boundary of larger than /48 with the proviso that businesses should be SWIPd regardless as I fail to see a public good from privacy protections for address assignments to businesses. > > Owen > >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> >> On Tue, 11 Jul 2017, Owen DeLong wrote: >> >>> >>>> On May 30, 2017, at 06:41 , William Herrin wrote: >>>> >>>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin > wrote: >>>> Hello all, >>>> >>>> I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. >>>> >>>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. >>>> >>>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. >>>> >>>> That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. >>>> >>>> Howdy, >>>> >>>> I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. >>> >>> This is one of those rare occasions when I absolutely agree with Bill. If we???re going to do this, I would support a requirement as follows: >>> >>> 1. For customers fitting the definition in NRPM 2.13, /47 or shorter. >>> 2. For customers not fitting the definition in NRPM 2.13 /63 or shorter. >>> >>>> Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. >>> >>> Yes??? The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router. >>> >>> If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification. >>> >>> Owen >>> >> _______________________________________________ >> 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. > > From hostmaster at uneedus.com Thu Jul 13 08:51:26 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 13 Jul 2017 08:51:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <658F1D2F-F4A8-4E28-B9A8-C0D5513C942B@delong.com> Message-ID: Unlike IPv4 where most machines has one and only 1 IPv4 address, IPv6 allows easy assignment of addresses, and in fact almost every machine running any operating system actually has many IPv6 addresses. While the fixed addresses of SLAAC and DHCP exist, most OS's will use privacy addresses for outbound traffic. Thus, both statements are kinda true. Just as an example, Windows 7 and up will do the following by default: 1) A link local address, based on the MAC address. 2) If router advertisements are available, 1 address based on the prefix advertised by each router and the MAC address. One address per router. Multihome routing in v6 can be done in the workstation, as each router can be connected to a different upstream provider with a different prefix for each, but some OS's will use only one upstream in this case instead of using both, and also fail to go to the other one when that primary connection fails. This is an issue that still needs work in many v6 OS stacks. Since most networks only have one v6 router, this feature of multihome has not been used and tested enough to be bug free. 3) If DHCP6 is available, a DHCP assigned address from a block of addresses set up by the Network Administrator. 4) A randomly assigned "Privacy Address", that generally is replaced with a new one every 24 hours, and is the default address for all outbound v6 traffic. Some OS's will assign a privacy address in all available subnets and use them, while others will only set up one privacy address. Of course, the action of #4 can be turned off by the administrator and is done if the business requires logging its employee traffic. #4 was done specifically to prevent internet wide tracking of a given MAC address, which would happen if #2 were the only global address assigned. This is the problem you identified. In effect, the best of both worlds exist. Fixed addresses based on DHCP and SLAAC are available for inbound traffic, while outbound traffic not specifically bound to one of these fixed addresses always route via the changing random address, preventing tracking based on MAC address. While these privacy addresses "hide" things, the administrator can still track everything on his network if needed as all communication is still done locally by the MAC address. Good security practice is to restrict this data to that network's administrator. Privacy Addresses are also done to prevent tracking by external actors, which can be associated with stalking and other such crimes by random internet actors, or like cookies, the serving of advertisements. SWIP was never intended to register individual workstations as suggested, but to register contact addresses so that traffic and utilization of the total registered network segment. If someone on a given network segment is doing "bad" things, it gives you a point of contact. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 12 Jul 2017, Owen DeLong wrote: >> When applying this to IPv6 (and forgive my lack of knowledge) but part of >> the address is identifying the physical interface (hardware). Seems a SWIP >> registration should be on that part of the address and then regardless of >> service provider that host will always be identified the same, owned by Bob >> Smith. As a service provider (SDWAN provider) I would NAT their network >> portion of their traffic to return to me, but keep the host the same. >> If I'm trying to hide the identity of the host by doing a full NAT with an >> encrypted tunnel, I'm clearly up to no good and shouldn't be trusted by >> content providers anyway. Trying to hide who I am is not security, it's >> trying to disguise myself to obtain something my actual ID would not allow >> me to, or I wouldn't want someone knowing I'm trying to obtain something. > > For better or worse, the IETF (and the OS vendors) have put significant effort > into making sure that the above is completely and utterly false for all practical > purposes. > > Owen > > > From owen at delong.com Thu Jul 13 16:49:26 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 13 Jul 2017 13:49:26 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> Message-ID: > On Jul 13, 2017, at 09:32 , hostmaster at uneedus.com wrote: > > The main reason I advanced this proposal is because the policy for the average small user of IPv4 differs greatly from that of that same small user when they chose to go dual stack and add IPv6 to their network. Understood. > > The majority of all internet connections for residential and small/medium business use in IPv4 land is a single public (or in some cases CGnat) address behind a internal block of RFC1918 private network addresses. As to SWIP, ISP's might have just a single entry showing a given block of addresses are assigned to residential and small business customers to document the assignment of these addresses for ARIN. There is no actual SWIP down to the individual customer level. Only a small portion of total ISP customers hold more than a /29, so very few individual SWIP records are needed, and these are the customers that have 8 or more v4 addresses. ISP's have fees for assigning these blocks, so any registration costs are passed to the customer. Some ISPs have fees for assigning these blocks. There are no registration costs per se for SWIP. SWIP is free. > In IPv6, that changes. Currently, even the smallest block (/64) must be registered when they are assigned to a customer. There is NO useable level that does not require registration, and this is the problem I seek to change. And we are in agreement. I?ve expressed support for the change, I just want to be slightly more liberal about it while still preserving the integrity of the registry. > It was generally agreed during discussion that even the smallest v6 customer needs to be able to route, so that means the minimum block assigned to the smallest user cannot for technical reasons be any smaller than a /60, and giving out /64's is not wise. Since a /48 can be independently routed, of course a /48 should be subject to SWIP. Others have suggested the SWIP standard should be tied to the block being independently routed. However, that is not the standard in v4, where the routing standard is /24, and the SWIP standard is /29. Personally, I don?t believe that independent routability is a matter for the RIR to consider in policy as the RIR has no control over or participation in such a decision, it is entirely to the ISPs to determine. > Like the difference between /24, the smallest routable network in v4, /32, the amount of v4 space the majority of customers have, and /29, the current SWIP standard, a number for v6 between /48 and /60 should be chosen to be the level that triggers SWIP, instead of the current policy of SWIP everyone. Why? Why should we saddle IPv6 with the baggage of policy that was carefully crafted to deal with the unique shortage situation as it existed in IPv4 and the assignment policies that resulted from that unfortunate situation? > I initially proposed the absolute minimum size in my proposal that permits routing which is to allow /60 and /64 subnets to be exempted from the SWIP policy. After discussion, the majority of commenters feel that a /56 should also be exempted and this was the consensus. Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. > In order to put the language in the same form as the IPv4 section, I understand the language will be changed to "/55 or more" instead of "more than a /56" in the next version of the draft, leaving /56, /60 and /64 exempted from mandatory SWIP registration, in much the same fashion as /30, /31 and /32 are exempted in the IPv4 world. Again, you say this as if matching IPv4 policy is some lofty or higher goal. I absolutely disagree with this premise. The sooner we can abandon the baggage holding back the internet known as IPv4, the better. IPv4 policy was written by flawed human beings just like IPv6 policy. I say this as one of the largest single contributing authors of IPv4 (as well as IPv6) policy in the ARIN NRPM. There is absolutely nothing sacrosanct about IPv4 policy as it is currently written and we should only emulate IPv4 policy in developing IPv6 policy where that is the best IPv6 policy we can build. In this case, because IPv6 is so fundamentally different from IPv4 in its architecture and the way addresses are intended to be deployed, the only thing we can possibly achieve by saddling IPv6 policy in this area with IPv4 thinking is to further debilitate IPv6 unnecessarily. That is why I proposed that now that we have a definition of residential customers (we didn?t have one when the IPv4 SWIP policy was written) using it as a point of distinction can help achieve better policy goals. Perhaps taking a step back and reviewing the policy goals (overall strategic ideals, rather than specific policy objectives) we want to achieve is worth while. From my perspective, the overall IPv6 policy goals should be: 1. Do not encourage ISPs to issue long prefixes. 2. Discourage non-nibble-aligned allocations and assignments by ISPs. 3. Ensure that the WHOIS database remains a useful mechanism for transparency in resource allocations. A. Reasonable Accuracy and Currency of Data B. Sufficiently detailed to allow appropriate contacts for addressing technical, administrative, and abuse issues. C. Appropriate protections for residential customer privacy. 4. Prevent fragmentation where possible without sacrificing more important goals. 5. Make sure IPv6 addresses are readily available to any entity which needs them on a reasonable basis. It is my opinion that setting the SWIP boundary at ?shorter than /56? will not achieve these goals as well as if we set a residential boundary at ?shorter than /48? while preserving a stricter SWIP boundary for businesses. I?m willing and open to shorter prefixes for businesses than my proposed /63 or shorter being exempt from SWIP and would support any boundary up to and including ?shorter than /52?. Surely you can see the likely difference in responsibility and contact requirements between a residential site with a /48 and a business with a /48. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Wed, 12 Jul 2017, Owen DeLong wrote: > >> >>> On Jul 11, 2017, at 23:26 , hostmaster at uneedus.com wrote: >>> >>> First of all, ALL changes to v4 have been withdrawn from this proposal. This proposal is ONLY about v6. Currently ALL v6 requires SWIP (/64 or more) and this is unequal with v4 that has an 8 or more address standard for SWIP. >>> >>> I think that drawing the SWIP boundary for IPv6 based upon residential/non residential (NRPM 2.13) is wrong, as this is NOT done in IPv4 and would treat v6 and v4 differently. Currently in v4, it is 8 or more addresses. Residential or Non Residential does not change the SWIP requirement in IPv4 in any way. >> >> You are entitled to your opinion, but IPv6 _IS_ fundamentally different from IPv4. >> >> The line is drawn where it is in IPv4 because for the most part, in IPv4, it?s actually rare for a residential customer to have 8 or more addresses assigned to their service and in such cases, it?s usually not a purely residential service. Further, at the time that line was drawn for IPv4, the definition of a residential customer and the residential customer privacy policies did not exist in the NRPM. >> >>> Thus, whatever boundary is chosen for v6, I think it should be a fixed value, just like in IPv4. I would like to hear the exact reasons why it has been proposed that there should be a residential/non residential difference in SWIP policy, and what this difference in policy is meant to address. If it is a valid reason, this should carry over to IPv4. >> >> There already is a residential/non-residential difference in that residential customers are allowed to be SWIPd with limited information. >> >> Further, as I stated above, the /29 boundary was chosen primarily because it was a convenient proxy for residential vs. business utilization. >> >>> Some commenters have suggested that routeability should be a factor in determining if SWIP is needed. In IPv4, it is not possible to route anything smaller than a /24, but the current SWIP v4 standard is /29 or more, much smaller than the routability standard. In IPv6, nothing smaller than a /48 is routable, so I kinda think that IPv4 /29 is very close to equal to IPv6 more than a /56, and also not independently routable. >> >> Trying to draw such comparisons between IPv4 and IPv6 is utterly and completely specious, generally speaking. For any parallel you can draw I can cite multiple examples where it simply doesn?t fit. >> >> The simple fact of the matter is that IPv4 is a densely allocated space with a serious shortage of addresses. >> IPv6 is an entirely different addressing architecture with entirely different requirements and (hopefully) entirely different management styles. >> >>> The comments I have been watching have strongly supported setting the SWIP level for IPv6 at more than a /56. This is only one nibble away from /60 in the current proposal. I also note that it seems quite universal that most commenters think that a /64 is wrong, and everyone, even dynamic residential customers deserve to have at least a /60 so that they can route packets in v6. >> >> IMHO, even dynamic residential customers deserve to have at least a /48 as is the fundamental design intention of IPv6. I realize that there are those who oppose this view, but I?m quite certain that if you research it, you will find that there are no convincing arguments favoring longer prefixes for residential. In fact, almost every argument offered favoring these longer prefixes is based almost entirely on IPv4-think (shortage mentality and conservation). >> >> In 2000::/3 (1/8th of the total IPv6 space which the IETF has currently set aside as GUA), there are 2^45 /48s. That?s 35,184,372,088,832 (35 trillion) /48s. The total population of the world is 7 Billion. So in this first 1/8th of the IPv6 space, we have enough /48s to issue 5,000 to every single person on earth. (Yes, I realize there?s also addresses needed for servers, infrastructure, etc., but I think we can take that out of the extra 4,999 /48s per person and still have room to spare). >> >> If it turns out I?m wrong and we somehow exhaust the first /3 within my lifetime, I?ll join others in advocating more conservative policy for the next /3. There are still at least 3 more empty /3s after that and 3 more nearly empty /3s beyond those. (IETF is talking about issuing addresses from a third /3 for some special purpose I forget in addition to the minimal allocations out of the end of e000::/3 (multicast, ULA, etc.) and 0000::/3 (unknown, default, loopback, IPv4 mapped, etc.)). >> >> So, while at the time of drafting, the IPv4 policy used /29 as a proxy for the distinction between business and residential and while there was concern about transparency of utilization and not wanting to allow ISPs to hide artificially large allocations by calling them residential, those issues really don?t apply in the IPv6 world. >> >> Since ARIN policy fully supports, and even encourages /48s being issued to residential customers for IPv6, I see no reason that a SWIP boundary of larger than /56 is any more desirable than a SWIP boundary of larger than /48 with the proviso that businesses should be SWIPd regardless as I fail to see a public good from privacy protections for address assignments to businesses. >> >> Owen >> >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> >>> On Tue, 11 Jul 2017, Owen DeLong wrote: >>> >>>> >>>>> On May 30, 2017, at 06:41 , William Herrin wrote: >>>>> >>>>> On Tue, May 30, 2017 at 9:12 AM, Roberts, Orin > wrote: >>>>> Hello all, >>>>> >>>>> I am avidly following this discussion and based on my daily observances (daily swips /subnets ), I would say Andy is closest to being practical. >>>>> >>>>> Leave the IPv4 /29 requirements alone, THIS LIMIT IS ALREADY BEING PUSHED AT DAILY BY NON-RESIDENTIAL USERS and only the vague ARIN policy prevents total chaos. >>>>> >>>>> With regards to IPv6, I would recommend ANY USER/ENTITY/ORG that requests a /56 OR LARGER NETWORK assignment be swiped. >>>>> >>>>> That would still leave /60 to /64 assignments as minimum assignment or for dynamic usage for either residential or other usage. >>>>> >>>>> Howdy, >>>>> >>>>> I don't like putting the SWIP requirement at /56 or larger because I think that would encourage ISPs to assign /60s instead of /56s. The IPv6 experts I've read seem to have a pretty strong consensus that the minimum assignment to an end user should be either /48 or /56. Setting ARIN policy that encourages assignments smaller than -both- of these numbers would be a bad idea IMHO. >>>> >>>> This is one of those rare occasions when I absolutely agree with Bill. If we?re going to do this, I would support a requirement as follows: >>>> >>>> 1. For customers fitting the definition in NRPM 2.13, /47 or shorter. >>>> 2. For customers not fitting the definition in NRPM 2.13 /63 or shorter. >>>> >>>>> Again I remind everyone that a /64 assignment to an end user, even for dynamic or residential use, is absolutely positively 100% wrong. Doing so prevents the end user from configuring their local lans as IPv6 is designed. They need at least a /60 for that. If you are assigning /64's to end users, you are doing it wrong. >>>> >>>> Yes? The only place I can imagine assigning /64s to customers as a legitimate practice is for single-LAN datacenter installations where the customer has no router. >>>> >>>> If the customer might have a router, a /48 is the best and safest default choice and shorter should be possible with reasonable justification. >>>> >>>> Owen >>>> >>> _______________________________________________ >>> 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. >> From bill at herrin.us Thu Jul 13 18:11:36 2017 From: bill at herrin.us (William Herrin) Date: Thu, 13 Jul 2017 18:11:36 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> Message-ID: On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong wrote: > Consensus hasn?t yet been reached. I agree that there is significant > support for ?shorter than /56? actually (not /56 itself). Nonetheless, I > don?t believe that shorter than /56 is the ideal place to put the boundary. > Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Jul 13 20:56:40 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 13 Jul 2017 20:56:40 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> Message-ID: The various comments about this Draft got me to read the things that were discussed when ARIN-2010-14 changed the SWIP standard from /48 to /64. Nowhere could I find a specific reason for that change to 6.5.5.1. The draft only stated the SWIP value was being made /64, without mentioning that it was being changed from /48 or the reasons for doing so. The below is the only nugget about 6.5.5.1 specifically mentioned on the PPML at the time: ******** ARIN (info at arin.net) Tue Sep 21 10:10:45 EDT 2010 ...... Draft Policy 2010-14 Standardize IP Reassignment Registration Requirements ...... 3. Resource Impact This policy would have moderate to major resource impact. It is estimated that implementation would occur within 6 months to 9 months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: ... Potential Database impact if all /64s and larger assignments must now be swipped (there are ~4 billion /64s in a /32 so the scale of this goes beyond anything ARIN has seen). Changes to current business processes Updated templates Updated guidelines Staff training ********* As far as I can tell, this was the only mention of 6.5.5.1, when it was changed from /48 or more to /64 or more. This was a warning in the staff report that SWIP of every IPv6 assignment would have a moderate to major resource impact on ARIN. I think the only reason that this did not blow up the ARIN database between then and now is that even though the policy manual currently says this should be done by everyone, it is not in fact being done much at all by anyone. My main upstream is typical and has no SWIP records at all, even though myself and several others that I helped set up each have a static /48 assignment of IPv6. This staff report only discussed the impact of the change on ARIN, and did not consider at all the impact of the amount of ISP labor to populate the SWIP database, which is one of the reasons that I think it should be changed. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 13 Jul 2017, William Herrin wrote: > On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong wrote: > >> Consensus hasn???t yet been reached. I agree that there is significant >> support for ???shorter than /56??? actually (not /56 itself). Nonetheless, I >> don???t believe that shorter than /56 is the ideal place to put the boundary. >> > > Hi Owen, > > I think you're an outlier here. I see consensus that /48 should be swiped > and /56 should not. If there's debate that /52 or /49 should also not be > swiped or that a some more subtle criteria should determine what's swiped, > it's not exactly chewing up bandwidth on the mailing list. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > From narten at us.ibm.com Fri Jul 14 07:11:13 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 14 Jul 2017 07:11:13 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201707141111.v6EBBEHV008326@rotala.raleigh.ibm.com> Total of 13 messages in the last 7 days. script run at: Fri Jul 14 07:11:08 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 46.15% | 6 | 46.91% | 70356 | owen at delong.com 30.77% | 4 | 32.44% | 48649 | hostmaster at uneedus.com 15.38% | 2 | 12.70% | 19048 | bill at herrin.us 7.69% | 1 | 7.95% | 11916 | abagrin at mydigitalshield.com --------+------+--------+----------+------------------------ 100.00% | 13 |100.00% | 149969 | Total From alh-ietf at tndh.net Fri Jul 14 16:07:07 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 14 Jul 2017 13:07:07 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> Message-ID: <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> Bill, To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 13, 2017 3:12 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong wrote: Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Fri Jul 14 17:47:54 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 14 Jul 2017 21:47:54 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 References: <59384CCF.3080009@arin.net> <949A0F0F-F895-4303-8E09-3443A4328B4B@gmail.com> Message-ID: All - The recent additional discussion on the list has prompted me to reconsider how I'm approaching the rework of this policy. I'll be discussing this internally with other AC members, and provide updates at the conclusion. There will be plenty of opportunity to provide additional feedback afterword. Thank you for your patience. Leif From: Leif Sawyer Sent: Wednesday, July 05, 2017 8:30 AM To: arin-ppml at arin.net Cc: 'hostmaster at uneedus.com' Subject: RE: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Thanks, Albert. We're taking all of this feedback under consideration, and I'll endeavor to have updates after the holiday week is over. Leif Sawyer ARIN Advisory Council From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of hostmaster at uneedus.com Sent: Wednesday, July 05, 2017 12:48 AM To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 [External Email] It has now been about 4 weeks since ARIN-2017-5 was last revised. Based on the comments received, "more than a /56" is the consensus. I ask that the AC revise the proposal to this value, so it can be further considered. This is the tally so far: /56 9 votes Any of these levels are OK - 2 votes /60 2 votes /61 1 vote /57 1 vote /53 1 vote /49 1 vote Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 7 Jun 2017, Leif Sawyer wrote: > That was not changed yet, as I'm still waiting for more folks to respond. > > The update was only for the removal of the IPv4 portion, as I mentioned in my previous email. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Wednesday, June 07, 2017 11:13 AM > To: ARIN > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > [External Email] > > It looks like /60 still needs to be changed to /56 to reflect the consensus on PPML. Or was there some reason not to do that (yet)? > > Scott > >> On Jun 7, 2017, at 11:58 AM, ARIN >> wrote: >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_5.html> >> >> 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) >> >> >> >> >> >> Problem Statement: >> >> 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 or less (CGnat), which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6. >> >> Currently, 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. >> >> IPv6 assignments are therefore treated stricter than IPv4 assignments. Policy should either treat both protocols the same, or provide incentive for the IPv6 future. A typical ISP serving residential and small business customers with both IPv4 and IPv6 would typically provide the following assignments to each customer site: /32 (one IP) of IPv4 and a /64 (one network) of IPv6. Under the current policy, that small network customer is exempt from registration for their IPv4 assignment, but the ISP would be required to register ALL IPv6 customers, even those of this smallest network size. >> >> In actual fact, most ISP's that are providing their customers with a /64 or more of IPv6 space are not in fact registering this fact with ARIN, even though 6.5.5.1 clearly requires this. >> >> It is my belief that these residential and small business customers should not require registration if they did not require registration for the same size IPv4 network, including routers with Vlan and other security support. and thus I propose to make the standard for registration only those customers that have more than 16 IPv6 /64 networks. This would treat IPv6 slightly better than IPv4, and provide additional encouragement for adoption. >> >> Policy statement: >> >> Amend 6.5.5.1 of the policy manual to strike "/64 or more" and change to "more than a /60". >> >> Comments: >> >> a. Timetable for implementation: >> >> Policy should be adopted as soon as possible, as the new administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. IPv6 should not be more burdensome than the equivalent IPv4 network size. >> >> b. Anything else: >> >> The specific sizes chosen set the point of registration for each site to more than 16 networks or addresses, so that those with 16 or less IPv6 networks (/60) have no registration requirement. This change will result in both protocols being treated exactly the same, and removes residential and small business accounts from any registration requirement with ARIN, and the burden that will create for all ISP's. >> >> There are those that might argue that a residental customer will never have a need for more than a /64 of IPv6. Clearly this is false in an IOT and/or wireless world, as many routers already provide a separate address range for wired vs wireless to prevent wired hacking via the wireless space, and also may provide a guest wireless SSID apart from the one provided to the regular users of that same network. Such separation in the IPv4 world is currently done in RFC1918 space using NAT. In IPv6, the equivalent must be done with different /64 blocks. Since good security practices require use at least 2 /64 blocks for wireless and/or IOT isolation, this would require a minimum of a /60 of IPv6 space or up to 16 networks or vlans, an amount that is consistent with a residential or small business network. This type network does not trigger registration under the current IPv4 policy, and its equal should not trigger registration with ARIN based on the current IPv6 policy as is cu! rr > ently the case, and thus, this policy needs to be changed. >> _______________________________________________ >> 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. > _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Jul 14 17:57:35 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 14 Jul 2017 16:57:35 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> Message-ID: Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. Thanks. On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain wrote: > Bill, > > > > To avoid the situation of Owen being a lone voice, I have to echo his > point that it is insane that people persist with IPv4-think and extreme > conservation. Allocations longer than a /48 to a residence ensure that > automated topology configuration can?t happen, because /52?s won?t happen > and /56?s are too long for random consumer plug-n-play. Therefore a policy > that /48?s must be swiped ensures that we maintain single subnet consumer > networks. A policy that says /48?s might be swiped (will in a business and > not in a non-residential case) does not reinforce the braindead notion that > longer than /48 has some special meaning beyond the need to kill off a > generation of those with the ?addresses are a scarce resource? mindset. > > > > Tony > > > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *William > Herrin > *Sent:* Thursday, July 13, 2017 3:12 PM > *To:* Owen DeLong > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > > > > On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong wrote: > > Consensus hasn?t yet been reached. I agree that there is significant > support for ?shorter than /56? actually (not /56 itself). Nonetheless, I > don?t believe that shorter than /56 is the ideal place to put the boundary. > > > > Hi Owen, > > > > I think you're an outlier here. I see consensus that /48 should be swiped > and /56 should not. If there's debate that /52 or /49 should also not be > swiped or that a some more subtle criteria should determine what's swiped, > it's not exactly chewing up bandwidth on the mailing list. > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > _______________________________________________ > 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: From kevinb at thewire.ca Fri Jul 14 18:42:57 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 14 Jul 2017 22:42:57 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> Message-ID: <7E7773B523E82C478734E793E58F69E78EC19D9B@SBS2011.thewireinc.local> David, Your suggestion is like what I suggested on June 19th. I do like the addition of SWIP?ing a /48 if requested. I also want to echo what others have said in the past couple of days. I believe it will be a mistake to set the boundary requiring all /48?s to be SWIP?ed. Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Friday, July 14, 2017 5:58 PM To: Tony Hain Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. Thanks. On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain > wrote: Bill, To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 13, 2017 3:12 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong > wrote: Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: _______________________________________________ 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: From alh-ietf at tndh.net Fri Jul 14 21:25:47 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Fri, 14 Jul 2017 18:25:47 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> Message-ID: <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> David, While I totally agree with your reasoning, doesn?t that fly in the face of the policy that Arin says ?nothing about routing?? It is one thing to have a BCP stating expectations for being able to find a contact for a routing entry, it is another to have a ?policy? that a routing entry requires swiped contact info. Tony From: David Farmer [mailto:farmer at umn.edu] Sent: Friday, July 14, 2017 2:58 PM To: Tony Hain Cc: William Herrin; Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. Thanks. On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain wrote: Bill, To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 13, 2017 3:12 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong wrote: Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: _______________________________________________ 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: From owen at delong.com Fri Jul 14 22:18:32 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 14 Jul 2017 19:18:32 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> Message-ID: <02854197-2786-4A0C-A31F-62825F292370@delong.com> > On Jul 14, 2017, at 14:57 , David Farmer wrote: > > Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. I?d be fine with that, but I?ll point out it?s a much more complicated policy to express vs. the simple definition in section 2 that already exists for residential. As you stated, both mechanisms largely capture the same set of assignments. > My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. I?d argue that most /48s that are likely to be SWIP?d are unlikely to appear in the GRT because most of them are PA and people that want to advertise their own /48 are more likely to just pony up the $100/year to ARIN rather than get stuck in PA renumbering hell when they switch providers. Owen > > Thanks. > > On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain > wrote: > Bill, > > > > To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. > > > > Tony > > > > > > ? <> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of William Herrin > Sent: Thursday, July 13, 2017 3:12 PM > To: Owen DeLong > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 > > > > On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong > wrote: > > Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. > > > > Hi Owen, > > > > I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. > > > > Regards, > > Bill Herrin > > > > > > -- > > William Herrin ................ herrin at dirtside.com bill at herrin.us > Dirtside Systems ......... Web: > > > > _______________________________________________ > 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: From jcurran at arin.net Sat Jul 15 08:52:42 2017 From: jcurran at arin.net (John Curran) Date: Sat, 15 Jul 2017 12:52:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: Tony - To be clear, ARIN?s Internet number resource policy has historically avoided statements that direct or forbid routing of IP address blocks, as ARIN?s role as a Internet number registry is distinct from any role in administration of the Internet?s routing system. Such a separation doesn?t preclude the community from adopting policy which references the present or future state of routing (note, for example, the use of ?multihoming? criteria in several portions of the NRPM), but folks are reminded that in Internet number resource policy we should only be specifying how the ARIN registry is to be administered, not how things are to be routed, since the latter is up to each ISP. Thanks! /John John Curran President and CEO ARIN On 14 Jul 2017, at 9:25 PM, Tony Hain > wrote: David, While I totally agree with your reasoning, doesn?t that fly in the face of the policy that Arin says ?nothing about routing?? It is one thing to have a BCP stating expectations for being able to find a contact for a routing entry, it is another to have a ?policy? that a routing entry requires swiped contact info. Tony From: David Farmer [mailto:farmer at umn.edu] Sent: Friday, July 14, 2017 2:58 PM To: Tony Hain Cc: William Herrin; Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. Thanks. On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain > wrote: Bill, To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 13, 2017 3:12 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong > wrote: Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: _______________________________________________ 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 =============================================== _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sat Jul 15 13:24:52 2017 From: bill at herrin.us (William Herrin) Date: Sat, 15 Jul 2017 13:24:52 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: On Sat, Jul 15, 2017 at 8:52 AM, John Curran wrote: > Such a separation doesn?t preclude the community from adopting policy which > references the present or future state of routing (note, for example, the > use of > ?multihoming? criteria in several portions of the NRPM), but folks are > reminded > that in Internet number resource policy we should only be specifying how > the > ARIN registry is to be administered, not how things are to be routed, > since the > latter is up to each ISP. > Hi John, In the interests of clarifying your remarks: ARIN does not set or even recommend routing policy. Participants in the ARIN policy process routinely consider industry routing practices, IETF recommendations, etc. when suggesting ARIN address management policy and ARIN routinely enacts such policy. Right? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Sat Jul 15 13:42:42 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sat, 15 Jul 2017 10:42:42 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: On Sat, Jul 15, 2017 at 10:24 AM, William Herrin wrote: > On Sat, Jul 15, 2017 at 8:52 AM, John Curran wrote: > >> Such a separation doesn?t preclude the community from adopting policy >> which >> references the present or future state of routing (note, for example, the >> use of >> ?multihoming? criteria in several portions of the NRPM), but folks are >> reminded >> that in Internet number resource policy we should only be specifying how >> the >> ARIN registry is to be administered, not how things are to be routed, >> since the >> latter is up to each ISP. >> > > Hi John, > > In the interests of clarifying your remarks: > > ARIN does not set or even recommend routing policy. Participants in the > ARIN policy process routinely consider industry routing practices, IETF > recommendations, etc. when suggesting ARIN address management policy and > ARIN routinely enacts such policy. > > Right? > That is true, but I think John is making a stronger point, which I'll make here: It's perfectly fine for ARIN policy to be contingent on (applied differently depending on) how a particular block is (going to be) routed. So if we think it's the right thing to do, we could require in the NRPM that all blocks in the global routing system be SWIP'ed. But we *can't* enforce such a requirement by saying, for example, that ISPs can't accept a block until it's SWIP'ed. We can only issue guidelines on what should be SWIP'ed and make ARIN services (like allocation of additional blocks) contingent on whether such a policy is followed. If an enforced SWIP-before-routing rule is desired by the ISPs that participate in the global routing system, then they'll have to do so voluntarily by refusing to accept the announcement of non-SWIP'ed blocks. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Sat Jul 15 14:51:30 2017 From: pmcnary at cameron.net (Paul McNary) Date: Sat, 15 Jul 2017 13:51:30 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> Hello My concern is where the magic boundary will occur. If the swip boundary includes the recommended /XX for residential customers and small business. I could see where the whois database could be abused by harvesting our customer information. Competitors could, would have access and ability to harvest proprietary information concerning our ISP business. We would have to limit our end user details to the area which will not be swip'ed to protect our business. That might not be the proper way to utilize IPv6. Current guidance has been to assign a /56 to even residential customers and some have recommended a /48 as the minimum assignment. I don't want my customer information available in such a public accessible database as whois. They could count my subscribers, harvest their names, addresses and even contact phone numbers. I do not see this as being good. I would not even like my SMB businesses to have public information unless they ask for it. I would prefer that the boundary be greater than /48. With /48 not being swip'ed or /56 even that is the minimum end user allocation. If I understand correctly (many times I do not) RFC/common agreement that a /32 is the smallest allocation to be announced. I have also have heard /48. So in my case if it can't be BGP public routable, I don't want to swip it. What ever my BGP routers can publicly advertise, my BGP gateway, will be assigned to us. Everything smaller than that, I don't want to publicly advertise. Why would we want the ability to give the competition the tools to analyze our business with a publicly available tool (ie whois). I also don't think that if ARIN will not provide an allocation size it shouldn't be swip'ed. So if ARIN wants to directly provide /56 to end users, then I will rethink my thought process. Anything smaller than a minimum ARIN allocation, should not have to be swip'ed or under their control. Am I not understanding this correctly? Thank you Paul McNary McNary Computer Services pmcnary at cameron.net On 7/15/2017 12:42 PM, Scott Leibrand wrote: > On Sat, Jul 15, 2017 at 10:24 AM, William Herrin > wrote: > > On Sat, Jul 15, 2017 at 8:52 AM, John Curran > wrote: > > Such a separation doesn?t preclude the community from adopting > policy which > references the present or future state of routing (note, for > example, the use of > ?multihoming? criteria in several portions of the NRPM), but > folks are reminded > that in Internet number resource policy we should only be > specifying how the > ARIN registry is to be administered, not how things are to be > routed, since the > latter is up to each ISP. > > > Hi John, > > In the interests of clarifying your remarks: > > ARIN does not set or even recommend routing policy. Participants > in the ARIN policy process routinely consider industry routing > practices, IETF recommendations, etc. when suggesting ARIN address > management policy and ARIN routinely enacts such policy. > > Right? > > > That is true, but I think John is making a stronger point, which I'll > make here: It's perfectly fine for ARIN policy to be contingent on > (applied differently depending on) how a particular block is (going to > be) routed. So if we think it's the right thing to do, we could > require in the NRPM that all blocks in the global routing system be > SWIP'ed. But we *can't* enforce such a requirement by saying, for > example, that ISPs can't accept a block until it's SWIP'ed. We can > only issue guidelines on what should be SWIP'ed and make ARIN services > (like allocation of additional blocks) contingent on whether such a > policy is followed. If an enforced SWIP-before-routing rule is > desired by the ISPs that participate in the global routing system, > then they'll have to do so voluntarily by refusing to accept the > announcement of non-SWIP'ed blocks. > > -Scott > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Sat Jul 15 18:27:52 2017 From: jcurran at arin.net (John Curran) Date: Sat, 15 Jul 2017 22:27:52 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: <977D798D-8C24-48D9-8513-E124915FA3CA@arin.net> On 15 Jul 2017, at 1:24 PM, William Herrin > wrote: On Sat, Jul 15, 2017 at 8:52 AM, John Curran > wrote: Such a separation doesn?t preclude the community from adopting policy which references the present or future state of routing (note, for example, the use of ?multihoming? criteria in several portions of the NRPM), but folks are reminded that in Internet number resource policy we should only be specifying how the ARIN registry is to be administered, not how things are to be routed, since the latter is up to each ISP. Hi John, In the interests of clarifying your remarks: ARIN does not set or even recommend routing policy. Participants in the ARIN policy process routinely consider industry routing practices, IETF recommendations, etc. when suggesting ARIN address management policy and ARIN routinely enacts such policy. Almost correct; i.e. ARIN administers the IP number registry, but does not (and should not) administer Internet routing. It is acceptable for our policy to consider the state of Internet routing (such as occurs with NRPM and multihoming today) but such should be as only that which is necessary for proper administration of the registry. Not setting routing policy isn?t the same as not suggesting routing practices, and if the ARIN community wishes to suggest that blocks which are routed should be SWIP?ed, then that is fine but such should be advice, and nothing more. To do otherwise is to extend ARIN?s policy (which the community must follow) into an area which is not properly within ARIN?s scope of control. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Sat Jul 15 21:18:42 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sat, 15 Jul 2017 21:18:42 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> Message-ID: Harvesting of customer data is something that has not really been addressed in the ARIN region, because it has not been an issue for most customers or ISP's. Currently it seems that in IPv4 land that 95% to 99% of ISP customers only have a single IPv4 address. Thus, SWIP in v4 is not done, except single entries to mark the use of the total blocks for assignment purposes. Since individual addresses are not SWIP'ed, the customer privacy/proprietary information is not an issue for the greatest majority of total customers. In IPv6 the current standard provides for 100% SWIP of all assignments. This a big leak of proprietary information and a lot of work, as even with residential privacy, the zip code of each customer must be publically reported which can give competitors lots of inside information. I advocate changing the policy such that those 95% to 99% of customers with a single v4 address are still treated the same in regard to SWIP if I happen to add IPv6 to their service. There is a lot of ISP labor needed to create the SWIP records, and for what purpose, allowing my competitors to identify and grab my customers? I know who my customers are, so SWIP does not help me at all with my own customers. I also note that an ARIN staff report noted when the NRPM was being changed to SWIP requirement of /64 that a database problem might result if in fact all those v6 assignments were entered in the database and called for a 6-9 month leadtime. Other drafts discussed here have addressed the verification of POC's, which I understand is currently in the upper 600,000's. If all these extra POC records are in fact added due to SWIP requirements, 10 million POC's or more could be reached if all non-residential records are required to be added. The biggest cost of all is adding hundreds of millions of privacy protected SWIP residential records for each customer, which contacts will be a duplicate of the upstream record except for the customer zip code, an information leak. This effort I do not think is a benefit to the community, except maybe the subset of geolocation and advertising providers, and whatever contractor is hired to increase ARIN's database storage to contain these duplicate records. In reality, if a customer is abusing, it is unlikely they will stop just because they are notified using the SWIP data. Instead, the complaint will 99% of the time will go to the ISP, the exact entity that would be contacted if there was NO SWIP record for individual customers at all. The ISP will make the decision as to if to cut off the customer, warn them or do nothing. Contacting the ISP instead of the Customer seems to work best. The line needs to be placed somewhere. I, along with many others discussing this on PPML agree that the current standard of /64 needs to change. Being able to have up to a /56 of v6 without SWIP and its associated costs to the ISP seems to have consensus. It also seems to be consensus that /48's need to be SWIP'ed. Since it has been noted that ARIN does not control routing, I agree that routing should not be part of the policy, and like v4, a static value be chosen. We should also consider that the policy at /64 may have a big cost to ARIN when the providers actually start doing 100% v6 registration to expand the database if the current policy is kept. I think the current consensus of "more than a /56" or stated another way "/55 or more" is a good compromise, as these smaller assignments cannot be independently routed so no routed networks escape SWIP, something that is desireable. Those operators that choose to give out /48's to everyone would SWIP all customers. Those operators that choose to not SWIP everyone could give out /56's and many might make this choice in part based on the cost of SWIP to the ISP. While the recomendation in the NRPM is /48, and calculations of network size can be based on that number, nothing requires that a specific operator follow it. A operator could have a sparse assignment plan of reserving a /48 for each customer, but only assigning a /56 of that /48 unless that full /48 is requested by the customer. This is similar to the sparse assignment plan of ARIN, leaving space for each v6 allocation to expand without having to assign a new block. When initial allocations were changed from /35 to /32 is an example of this in action. This policy could also leave room for growth without further allocations if a future policy changes the suggested allocation from /48, to a smaller value such as /56. I started off with a proposal to allow /60 and /64 to avoid SWIP and its costs. The consensus thus far would add /56 to that list. Maybe the community wants to consider adding /52 to that list, or even /48 if it is not independently routed. Albert Erdmann Network Administrator Paradise On Line Inc. On Sat, 15 Jul 2017, Paul McNary wrote: > Hello > My concern is where the magic boundary will occur. If the swip boundary > includes the > recommended /XX for residential customers and small business. I could see > where the > whois database could be abused by harvesting our customer information. > Competitors > could, would have access and ability to harvest proprietary information > concerning > our ISP business. We would have to limit our end user details to the area > which will > not be swip'ed to protect our business. That might not be the proper way to > utilize IPv6. > Current guidance has been to assign a /56 to even residential customers and > some have > recommended a /48 as the minimum assignment. I don't want my customer > information > available in such a public accessible database as whois. They could count my > subscribers, > harvest their names, addresses and even contact phone numbers. I do not see > this > as being good. I would not even like my SMB businesses to have public > information > unless they ask for it. I would prefer that the boundary be greater than /48. > With /48 > not being swip'ed or /56 even that is the minimum end user allocation. > If I understand correctly (many times I do not) RFC/common agreement that a > /32 > is the smallest allocation to be announced. I have also have heard /48. So in > my > case if it can't be BGP public routable, I don't want to swip it. What ever > my BGP > routers can publicly advertise, my BGP gateway, will be assigned to us. > Everything > smaller than that, I don't want to publicly advertise. > > Why would we want the ability to give the competition the tools to analyze > our > business with a publicly available tool (ie whois). I also don't think that > if ARIN > will not provide an allocation size it shouldn't be swip'ed. So if ARIN wants > to directly > provide /56 to end users, then I will rethink my thought process. Anything > smaller than > a minimum ARIN allocation, should not have to be swip'ed or under their > control. > > Am I not understanding this correctly? > > Thank you > Paul McNary > McNary Computer Services > pmcnary at cameron.net > > > > On 7/15/2017 12:42 PM, Scott Leibrand wrote: >> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin > > wrote: >> >> On Sat, Jul 15, 2017 at 8:52 AM, John Curran > > wrote: >> >> Such a separation doesn???t preclude the community from adopting >> policy which >> references the present or future state of routing (note, for >> example, the use of >> ???multihoming??? criteria in several portions of the NRPM), but >> folks are reminded >> that in Internet number resource policy we should only be >> specifying how the >> ARIN registry is to be administered, not how things are to be >> routed, since the >> latter is up to each ISP. >> >> >> Hi John, >> >> In the interests of clarifying your remarks: >> >> ARIN does not set or even recommend routing policy. Participants >> in the ARIN policy process routinely consider industry routing >> practices, IETF recommendations, etc. when suggesting ARIN address >> management policy and ARIN routinely enacts such policy. >> >> Right? >> >> >> That is true, but I think John is making a stronger point, which I'll make >> here: It's perfectly fine for ARIN policy to be contingent on (applied >> differently depending on) how a particular block is (going to be) routed. >> So if we think it's the right thing to do, we could require in the NRPM >> that all blocks in the global routing system be SWIP'ed. But we *can't* >> enforce such a requirement by saying, for example, that ISPs can't accept a >> block until it's SWIP'ed. We can only issue guidelines on what should be >> SWIP'ed and make ARIN services (like allocation of additional blocks) >> contingent on whether such a policy is followed. If an enforced >> SWIP-before-routing rule is desired by the ISPs that participate in the >> global routing system, then they'll have to do so voluntarily by refusing >> to accept the announcement of non-SWIP'ed blocks. >> >> -Scott >> >> >> _______________________________________________ >> 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. > > From pmcnary at cameron.net Sun Jul 16 20:46:43 2017 From: pmcnary at cameron.net (Paul McNary) Date: Sun, 16 Jul 2017 19:46:43 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> Message-ID: Hello This is probably targeted to John and the ARIN staff I was reading some articles today. Under the current net privacy rules and proposed net neutrality rule making goes through or even if not, we are not allowed to put customer data in a publicly accessible data base. I don't think we are even allowed to provide that information to a third party without our customer's written opt-in. You can only get the IP "address holder's" information because of the contract we have with ARIN where we give up that right of privacy. So you can make us give you that information but you can not force us to break the law, if the end user doesn't have a contract with ARIN. Even if we would SWIP a current /24 and their information is disclosed to a third party (ie ARIN) and the end user doesn't have a contract with ARIN, I think we are in violation of the Internet privacy rules as they are and have been. John, can you and the ARIN staff get a written clarification from FCC about this. It basically guts the privacy rule making if SWIP is performed on a customer who does not give written approval. What am I missing? The WISPA lawyers say we are still required to follow the Internet policy rule making. Thank you Take care Paul McNary McNary Computer Services pmcnary at cameron.net On 7/15/2017 8:18 PM, hostmaster at uneedus.com wrote: > Harvesting of customer data is something that has not really been > addressed in the ARIN region, because it has not been an issue for > most customers or ISP's. > > Currently it seems that in IPv4 land that 95% to 99% of ISP customers > only have a single IPv4 address. Thus, SWIP in v4 is not done, except > single entries to mark the use of the total blocks for assignment > purposes. Since individual addresses are not SWIP'ed, the customer > privacy/proprietary information is not an issue for the greatest > majority of total customers. > > In IPv6 the current standard provides for 100% SWIP of all > assignments. This a big leak of proprietary information and a lot of > work, as even with residential privacy, the zip code of each customer > must be publically reported which can give competitors lots of inside > information. > > I advocate changing the policy such that those 95% to 99% of customers > with a single v4 address are still treated the same in regard to SWIP > if I happen to add IPv6 to their service. There is a lot of ISP labor > needed to create the SWIP records, and for what purpose, allowing my > competitors to identify and grab my customers? I know who my customers > are, so SWIP does not help me at all with my own customers. > > I also note that an ARIN staff report noted when the NRPM was being > changed to SWIP requirement of /64 that a database problem might > result if in fact all those v6 assignments were entered in the > database and called for a 6-9 month leadtime. Other drafts discussed > here have addressed the verification of POC's, which I understand is > currently in the upper 600,000's. If all these extra POC records are > in fact added due to SWIP requirements, 10 million POC's or more could > be reached if all non-residential records are required to be added. > The biggest cost of all is adding hundreds of millions of privacy > protected SWIP residential records for each customer, which contacts > will be a duplicate of the upstream record except for the customer zip > code, an information leak. This effort I do not think is a benefit to > the community, except maybe the subset of geolocation and advertising > providers, and whatever contractor is hired to increase ARIN's > database storage to contain these duplicate records. > > In reality, if a customer is abusing, it is unlikely they will stop > just because they are notified using the SWIP data. Instead, the > complaint will 99% of the time will go to the ISP, the exact entity > that would be contacted if there was NO SWIP record for individual > customers at all. The ISP will make the decision as to if to cut off > the customer, warn them or do nothing. Contacting the ISP instead of > the Customer seems to work best. > > The line needs to be placed somewhere. I, along with many others > discussing this on PPML agree that the current standard of /64 needs > to change. Being able to have up to a /56 of v6 without SWIP and its > associated costs to the ISP seems to have consensus. It also seems to > be consensus that /48's need to be SWIP'ed. Since it has been noted > that ARIN does not control routing, I agree that routing should not be > part of the policy, and like v4, a static value be chosen. We should > also consider that the policy at /64 may have a big cost to ARIN when > the providers actually start doing 100% v6 registration to expand the > database if the current policy is kept. > > I think the current consensus of "more than a /56" or stated another > way "/55 or more" is a good compromise, as these smaller assignments > cannot be independently routed so no routed networks escape SWIP, > something that is desireable. Those operators that choose to give out > /48's to everyone would SWIP all customers. Those operators that > choose to not SWIP everyone could give out /56's and many might make > this choice in part based on the cost of SWIP to the ISP. While the > recomendation in the NRPM is /48, and calculations of network size can > be based on that number, nothing requires that a specific operator > follow it. > > A operator could have a sparse assignment plan of reserving a /48 for > each customer, but only assigning a /56 of that /48 unless that full > /48 is requested by the customer. This is similar to the sparse > assignment plan of ARIN, leaving space for each v6 allocation to > expand without having to assign a new block. When initial allocations > were changed from /35 to /32 is an example of this in action. This > policy could also leave room for growth without further allocations if > a future policy changes the suggested allocation from /48, to a > smaller value such as /56. > > I started off with a proposal to allow /60 and /64 to avoid SWIP and > its costs. The consensus thus far would add /56 to that list. Maybe > the community wants to consider adding /52 to that list, or even /48 > if it is not independently routed. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Sat, 15 Jul 2017, Paul McNary wrote: > >> Hello >> My concern is where the magic boundary will occur. If the swip >> boundary includes the >> recommended /XX for residential customers and small business. I could >> see where the >> whois database could be abused by harvesting our customer >> information. Competitors >> could, would have access and ability to harvest proprietary >> information concerning >> our ISP business. We would have to limit our end user details to the >> area which will >> not be swip'ed to protect our business. That might not be the proper >> way to utilize IPv6. >> Current guidance has been to assign a /56 to even residential >> customers and some have >> recommended a /48 as the minimum assignment. I don't want my customer >> information >> available in such a public accessible database as whois. They could >> count my subscribers, >> harvest their names, addresses and even contact phone numbers. I do >> not see this >> as being good. I would not even like my SMB businesses to have public >> information >> unless they ask for it. I would prefer that the boundary be greater >> than /48. With /48 >> not being swip'ed or /56 even that is the minimum end user allocation. >> If I understand correctly (many times I do not) RFC/common agreement >> that a /32 >> is the smallest allocation to be announced. I have also have heard >> /48. So in my >> case if it can't be BGP public routable, I don't want to swip it. >> What ever my BGP >> routers can publicly advertise, my BGP gateway, will be assigned to >> us. Everything >> smaller than that, I don't want to publicly advertise. >> >> Why would we want the ability to give the competition the tools to >> analyze our >> business with a publicly available tool (ie whois). I also don't >> think that if ARIN >> will not provide an allocation size it shouldn't be swip'ed. So if >> ARIN wants to directly >> provide /56 to end users, then I will rethink my thought process. >> Anything smaller than >> a minimum ARIN allocation, should not have to be swip'ed or under >> their control. >> >> Am I not understanding this correctly? >> >> Thank you >> Paul McNary >> McNary Computer Services >> pmcnary at cameron.net >> >> >> >> On 7/15/2017 12:42 PM, Scott Leibrand wrote: >>> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin >> > wrote: >>> >>> On Sat, Jul 15, 2017 at 8:52 AM, John Curran >> > wrote: >>> >>> Such a separation doesn?t preclude the community from adopting >>> policy which >>> references the present or future state of routing (note, for >>> example, the use of >>> ?multihoming? criteria in several portions of the NRPM), but >>> folks are reminded >>> that in Internet number resource policy we should only be >>> specifying how the >>> ARIN registry is to be administered, not how things are to be >>> routed, since the >>> latter is up to each ISP. >>> >>> >>> Hi John, >>> >>> In the interests of clarifying your remarks: >>> >>> ARIN does not set or even recommend routing policy. Participants >>> in the ARIN policy process routinely consider industry routing >>> practices, IETF recommendations, etc. when suggesting ARIN address >>> management policy and ARIN routinely enacts such policy. >>> >>> Right? >>> >>> >>> That is true, but I think John is making a stronger point, which >>> I'll make here: It's perfectly fine for ARIN policy to be contingent >>> on (applied differently depending on) how a particular block is >>> (going to be) routed. So if we think it's the right thing to do, we >>> could require in the NRPM that all blocks in the global routing >>> system be SWIP'ed. But we *can't* enforce such a requirement by >>> saying, for example, that ISPs can't accept a block until it's >>> SWIP'ed. We can only issue guidelines on what should be SWIP'ed and >>> make ARIN services (like allocation of additional blocks) contingent >>> on whether such a policy is followed. If an enforced >>> SWIP-before-routing rule is desired by the ISPs that participate in >>> the global routing system, then they'll have to do so voluntarily by >>> refusing to accept the announcement of non-SWIP'ed blocks. >>> >>> -Scott >>> >>> >>> _______________________________________________ >>> 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. >> >> From jcurran at arin.net Sun Jul 16 22:38:48 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 02:38:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> Message-ID: <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> On 16 Jul 2017, at 8:46 PM, Paul McNary wrote: > > Hello > This is probably targeted to John and the ARIN staff > > I was reading some articles today. Under the current net privacy rules and proposed > net neutrality rule making goes through or even if not, we are not allowed to put > customer data in a publicly accessible data base. I don't think we are even allowed > to provide that information to a third party without our customer's written opt-in. > You can only get the IP "address holder's" information because of the contract we > have with ARIN where we give up that right of privacy. So you can make us give you > that information but you can not force us to break the law, if the end user doesn't have a > contract with ARIN. Even if we would SWIP a current /24 and their information is > disclosed to a third party (ie ARIN) and the end user doesn't have a contract with > ARIN, I think we are in violation of the Internet privacy rules as they are and have been. > > John, can you and the ARIN staff get a written clarification from FCC about this. > It basically guts the privacy rule making if SWIP is performed on a customer > who does not give written approval. > > What am I missing? The WISPA lawyers say we are still required to follow the > Internet policy rule making. Paul - ARIN obviously does not require you ?to break the law?, but to be able to further pursue this matter we?re going to need a bit more information. Do you have a reference for the particular law or rulemaking proceeding that the WISPA lawyers assert is in conflict? I would be happy to speak with them directly if that would help ? email me appropriate contact information when you have a moment. Thanks! /John John Curran President and CEO ARIN From hostmaster at uneedus.com Mon Jul 17 01:04:26 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 01:04:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> References: <59248105.8040703@arin.net> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: John, I think this is the FCC ruling he speaks of, and it does seem to shut down public disclosures of most of what is contained in SWIP/WHOIS without customer consent. This has been the rule for regular phone calls for a long time, called CPNI. Until today I did not realise the FCC extended this to the internet. It also appears that even someone with a contract with ARIN could require ARIN to restrict their data from third party disclosure, as it states that private contract provisions cannot override the right to insist on privacy. http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-22A1.pdf It looks like static and even dynamic IP addresses and MAC addresses are considered protected information. IP addresses are the bread and butter of ARIN. Domain names are protected, thus Email addresses are protected since they contain a domain name, and they have also ruled that name, address and telephone numbers are protected as well. They even talk of DNS lookups being protected. It kinda looks like the FCC has made a large part of SWIP/WHOIS unlawful with this order unless ARIN has been given consent by each holder of the information, even if they are a current member under contract. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, John Curran wrote: > On 16 Jul 2017, at 8:46 PM, Paul McNary wrote: >> >> Hello >> This is probably targeted to John and the ARIN staff >> >> I was reading some articles today. Under the current net privacy rules and proposed >> net neutrality rule making goes through or even if not, we are not allowed to put >> customer data in a publicly accessible data base. I don't think we are even allowed >> to provide that information to a third party without our customer's written opt-in. >> You can only get the IP "address holder's" information because of the contract we >> have with ARIN where we give up that right of privacy. So you can make us give you >> that information but you can not force us to break the law, if the end user doesn't have a >> contract with ARIN. Even if we would SWIP a current /24 and their information is >> disclosed to a third party (ie ARIN) and the end user doesn't have a contract with >> ARIN, I think we are in violation of the Internet privacy rules as they are and have been. >> >> John, can you and the ARIN staff get a written clarification from FCC about this. >> It basically guts the privacy rule making if SWIP is performed on a customer >> who does not give written approval. >> >> What am I missing? The WISPA lawyers say we are still required to follow the >> Internet policy rule making. > > Paul - > > ARIN obviously does not require you ?to break the law?, but to be able to further > pursue this matter we?re going to need a bit more information. > > Do you have a reference for the particular law or rulemaking proceeding that > the WISPA lawyers assert is in conflict? I would be happy to speak with them > directly if that would help ? email me appropriate contact information when you > have a moment. > > Thanks! > /John > > John Curran > President and CEO > ARIN > _______________________________________________ > 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. > From jcurran at arin.net Mon Jul 17 06:09:03 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 10:09:03 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: On 17 Jul 2017, at 1:04 AM, hostmaster at uneedus.com wrote: John, I think this is the FCC ruling he speaks of, and it does seem to shut down public disclosures of most of what is contained in SWIP/WHOIS without customer consent. This has been the rule for regular phone calls for a long time, called CPNI. Until today I did not realise the FCC extended this to the internet. It also appears that even someone with a contract with ARIN could require ARIN to restrict their data from third party disclosure, as it states that private contract provisions cannot override the right to insist on privacy. http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-22A1.pdf It looks like static and even dynamic IP addresses and MAC addresses are considered protected information. IP addresses are the bread and butter of ARIN. Domain names are protected, thus Email addresses are protected since they contain a domain name, and they have also ruled that name, address and telephone numbers are protected as well. They even talk of DNS lookups being protected. It kinda looks like the FCC has made a large part of SWIP/WHOIS unlawful with this order unless ARIN has been given consent by each holder of the information, even if they are a current member under contract. Albert - The FCC is well aware of the Internet Numbers Registry System and our processes for management of IP addresses, and their recent Open Internet/Title II reclassification order specifically acknowledges that the Title II change of broadband services does not assert their jurisdiction over the assignment or management of IP addressing - "This definitional change to our regulations in no way asserts Commission jurisdiction over the assignment or management of IP addressing by the Internet Numbers Registry System.? (Reclassification Order ? 391, note 1116) The Order makes plain that the use of ?public IP addresses? from the Internet Numbers Registry System are an element used in the provision of broadband Internet services, and there already exists specific CPNI exception that a carrier may permit access to customers? CPNI when necessary for provision of the telecommunications service. If ISPs can provide Internet services without use of IP addresses, then then permitting access to that customer information would not meet the limited exception, but that does not appear to be practical (and particularly not with respect to the IP address blocks which are routed on the public Internet, as being discussed in some variations of this draft policy) ISP?s who have a concern in this area should obtain their own legal advice, but compliance with community-developed registry policy is a prerequisite for access to the public IP addresses, and our review notes that such access is a necessary and required element for the provision of Internet services and thus should fall without the limited CPNI exception that is provided. (If somehow you can provision Internet services without the use of public IP address, then availability of the ?necessary for provision? exception would not be the case, but then again, you also would not need to worry about access to or compliance with the Internet Number Registry System?) Thanks, /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 17 09:31:33 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 08:31:33 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> References: <59248105.8040703@arin.net> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: <55a7ced1-6c45-57c6-9626-45f4e2ad4eb1@cameron.net> Hello John It would be the CPNI non-disclosure rules from the FCC. WISPA's counsel which does not represent me personally but WISPA as an organization is and expert on this. He knows the FCC inside and out and has been warning us about our CPNI requirements for non-disclosure and says it is not exempted from the small provider exclusion. His contact information is Stephen E. Coran Lerman Senter PLLC 2001 L Street, NW, Suite 400 Washington, DC 20036 202-416-6744 ? office 202-669-3288 ? mobile scoran at lermansenter.com ? email www.lermansenter.com @stevecoran ? twitter IANAL so I can only comment as such. But it does look like an issue. A law/regulation from the federal government vs an non government entity contract. It still appears to me that SWIP'ing CPNI information and displaying it in public WHOIS is a violation of law unless ARIN has an exemption that would gut the privacy for Internet users. I guess we could SWIP the IP but put in Customer one and our POC information. I am sure Steve can tell page and verse about this. Thanks you Take care Paul McNary McNary Computer Service pmcnary at cameron.net On 7/16/2017 9:38 PM, John Curran wrote: > On 16 Jul 2017, at 8:46 PM, Paul McNary wrote: >> Hello >> This is probably targeted to John and the ARIN staff >> >> I was reading some articles today. Under the current net privacy rules and proposed >> net neutrality rule making goes through or even if not, we are not allowed to put >> customer data in a publicly accessible data base. I don't think we are even allowed >> to provide that information to a third party without our customer's written opt-in. >> You can only get the IP "address holder's" information because of the contract we >> have with ARIN where we give up that right of privacy. So you can make us give you >> that information but you can not force us to break the law, if the end user doesn't have a >> contract with ARIN. Even if we would SWIP a current /24 and their information is >> disclosed to a third party (ie ARIN) and the end user doesn't have a contract with >> ARIN, I think we are in violation of the Internet privacy rules as they are and have been. >> >> John, can you and the ARIN staff get a written clarification from FCC about this. >> It basically guts the privacy rule making if SWIP is performed on a customer >> who does not give written approval. >> >> What am I missing? The WISPA lawyers say we are still required to follow the >> Internet policy rule making. > Paul - > > ARIN obviously does not require you ?to break the law?, but to be able to further > pursue this matter we?re going to need a bit more information. > > Do you have a reference for the particular law or rulemaking proceeding that > the WISPA lawyers assert is in conflict? I would be happy to speak with them > directly if that would help ? email me appropriate contact information when you > have a moment. > > Thanks! > /John > > John Curran > President and CEO > ARIN From hostmaster at uneedus.com Mon Jul 17 09:47:26 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 09:47:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: As far as ARIN having access, you are right, ARIN itself has the right to the CPNI data on assigned IP resources, but not the right to make it publically accessable to the world. The OP has confirmed that the issue is the CPNI rules. there already exists specific CPNI > exception that a carrier may permit access to customers??? CPNI when > necessary for provision of the telecommunications service. > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. In the telecom world, a circuit from A to B might go from ILEC A to Interexchange Carrier, then to ILEC B at the other end. Disclosure to each is permitted, as it is required for having the service. Publication of information regarding this circuit to other parties or the world is not. There is a large body of case law regarding CPNI disclosure, and maybe this is what the OP was talking about. I read the FCC1524A1 order, and while it does say that the FCC will not assert jurisdiction over the assignment or management of IP addresses, I see nothing in the order that would allow ARIN to insist that the assignments must be recorded in a public directory, where neither the customer has consented. The FCC has specifically been ruled that elements name, address and telephone number are protected CPNI. The customers are NOT ARIN members, so there is no contractual agreement with those parties to allow this disclosure. Maybe I am missing something, but my read of the order does not seem to grant ARIN the rights to EVER publish CPNI to third parties without consent. I have looked for the WISPA comments on line to find out exactly what the issue identified is, but I have not been able to find it. Information from the OP seems to state that I have found the correct order on CPNI. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, John Curran wrote: > On 17 Jul 2017, at 1:04 AM, hostmaster at uneedus.com wrote: > > John, > > I think this is the FCC ruling he speaks of, and it does seem to shut down public disclosures of most of what is contained in SWIP/WHOIS without customer consent. This has been the rule for regular phone calls for a long time, called CPNI. Until today I did not realise the FCC extended this to the internet. It also appears that even someone with a contract with ARIN could require ARIN to restrict their data from third party disclosure, as it states that private contract provisions cannot override the right to insist on privacy. > > http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-22A1.pdf > > It looks like static and even dynamic IP addresses and MAC addresses are considered protected information. IP addresses are the bread and butter of ARIN. Domain names are protected, thus Email addresses are protected since they contain a domain name, and they have also ruled that name, address and telephone numbers are protected as well. They even talk of DNS lookups being protected. > > It kinda looks like the FCC has made a large part of SWIP/WHOIS unlawful with this order unless ARIN has been given consent by each holder of the information, even if they are a current member under contract. > > Albert - > > The FCC is well aware of the Internet Numbers Registry System and > our processes for management of IP addresses, and their recent Open > Internet/Title II reclassification order specifically acknowledges that the > Title II change of broadband services does not assert their jurisdiction > over the assignment or management of IP addressing - > > "This definitional change to our regulations in no way asserts > Commission jurisdiction over the assignment or management of IP > addressing by the Internet Numbers Registry System.??? (Reclassification > Order ?? 391, note 1116) > > > The Order makes plain that the use of ???public IP addresses??? from the > Internet Numbers Registry System are an element used in the provision > of broadband Internet services, and there already exists specific CPNI > exception that a carrier may permit access to customers??? CPNI when > necessary for provision of the telecommunications service. > > If ISPs can provide Internet services without use of IP addresses, then > then permitting access to that customer information would not meet the > limited exception, but that does not appear to be practical (and particularly > not with respect to the IP address blocks which are routed on the public > Internet, as being discussed in some variations of this draft policy) > > ISP???s who have a concern in this area should obtain their own legal advice, > but compliance with community-developed registry policy is a prerequisite > for access to the public IP addresses, and our review notes that such access > is a necessary and required element for the provision of Internet services > and thus should fall without the limited CPNI exception that is provided. > (If somehow you can provision Internet services without the use of public > IP address, then availability of the ???necessary for provision??? exception would > not be the case, but then again, you also would not need to worry about > access to or compliance with the Internet Number Registry System???) > > Thanks, > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > > > > From jcurran at arin.net Mon Jul 17 10:42:07 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 14:42:07 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: > ,,, > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. > > The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. > > There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. Compliance with registry policy is indeed necessary to receive number resources; it is up to you to determine whether IP number resources are necessary for provision of your Internet services. If you choose not to make use of Internet Numbers Registry System resources for provision of Internet services (or not assign them to your customers), then that is your choice. Some ISPs may feel that it is necessary to seek consent of customers who wish to have public IP number resources assigned in the size that would result in their publication in the public registry, whereas others may not based on their reading of applicable regulations regarding handling of CPNI information. Such choices are an operational and business matter left to each ISP to decide based on their individual understanding and circumstances. Thanks! /John John Curran President and CEO ARIN From jschiller at google.com Mon Jul 17 12:13:59 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 17 Jul 2017 12:13:59 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> Message-ID: I am replying to bring the conversation to one of the suggestions on the table. Owen DeLong's suggesting of SWIP all IPv6 business users, and not Residential users, Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all prefixes that might show up as a more specific in the global routing table. These are roughly the same result, and have a question of which has a more easily understandable policy. The question is who here supports one or both of these proposals? Who oppose one (if so which one) or both of these proposals? I would like to suggest one friendly amendment... - ISPs are required to SWIP IP space that is a reallocation. - ISPs are required to SWIP IP space that is a reassignment whenever that down stream customer requests such. That SWIP must be a reassign detail, reassign simple, or a residential privacy (if applicable) per the customer request. ___Jason On Mon, Jul 17, 2017 at 10:42 AM, John Curran wrote: > On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: > > ,,, > > This is the problem. ARIN is not a carrier. While disclosure to ARIN > to obtain number resources for the connection is OK, Public disclosure by > or at the direction of ARIN policy of elements like domain name, name, > address and telephone number is not. Since name, address, telephone number > and domain name have already been identified have been defined in the order > as elements of CPNI that are protected, world disclosure by ARIN or because > of ARIN rules would not be a protected disclosure. > > > > The ISP might also be in trouble for providing the information to ARIN, > if they know that ARIN intends to publish this information in a public > directory, rather than disclosing it to ARIN solely to maintain number > resources. As suggested by the OP, might have to call them customer 1-n. > However that would violate the NRPM as written. Since the City, State and > Zip Code are part of the address, even the "protected" residential records > CPNI are being disclosed in violation of the CPNI Order. > > > > There is a big difference between disclosure to ARIN for taking care of > numbering policy, and disclosure to the entire world. Third party > disclosure is the main thing that the CPNI rules are intended to address. > That is only permitted when it is needed for the provision of service. > > Compliance with registry policy is indeed necessary to receive number > resources; > it is up to you to determine whether IP number resources are necessary for > provision > of your Internet services. > > If you choose not to make use of Internet Numbers Registry System > resources for > provision of Internet services (or not assign them to your customers), > then that is > your choice. Some ISPs may feel that it is necessary to seek consent of > customers > who wish to have public IP number resources assigned in the size that > would result in > their publication in the public registry, whereas others may not based on > their reading > of applicable regulations regarding handling of CPNI information. Such > choices are > an operational and business matter left to each ISP to decide based on > their individual > understanding and circumstances. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Mon Jul 17 13:03:02 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 13:03:02 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> Message-ID: I see the 2 proposals as quite a bit different. The first suggestion of SWIP business users, and not residential users I do not see as best. I would venture that for business, a numeric majority of these customers have only a single IPv4 address. Since these mostly small businesses are really no different network wise than residences, why should an ISP have to waste resources registering SWIP, just because they happened to think of the future and provided an assignment of v6 space to their customers? Under v4 no SWIP unless they reach 8 IPv4's. The second suggestion is more reasonable, which is to only require SWIP if that v6 space appears alone in the GRT. Setting the standard at "/55 or more" effectively means that those with assignments smaller than can be advertised in the GRT do not have to SWIP. "/48 or more" would do the same thing, but allow the customers a larger v6 block. Maybe the operative phrase to the proposal could be something like "/48 or more, unless the assignment does not appear in the Global Routing Table". This would do exactly what is suggested. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, Jason Schiller wrote: > I am replying to bring the conversation to one of the suggestions > on the table. > > Owen DeLong's suggesting of SWIP all IPv6 business users, and > not Residential users, > > Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all > prefixes that might show up as a more specific in the global routing > table. > > > These are roughly the same result, and have a question of which > has a more easily understandable policy. > > The question is who here supports one or both of these > proposals? > > Who oppose one (if so which one) or both of these proposals? > > > I would like to suggest one friendly amendment... > - ISPs are required to SWIP IP space that is a reallocation. > - ISPs are required to SWIP IP space that is a reassignment > whenever that down stream customer requests such. That > SWIP must be a reassign detail, reassign simple, or a > residential privacy (if applicable) per the customer request. > > ___Jason > > > > On Mon, Jul 17, 2017 at 10:42 AM, John Curran wrote: > >> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: >>> ,,, >>> This is the problem. ARIN is not a carrier. While disclosure to ARIN >> to obtain number resources for the connection is OK, Public disclosure by >> or at the direction of ARIN policy of elements like domain name, name, >> address and telephone number is not. Since name, address, telephone number >> and domain name have already been identified have been defined in the order >> as elements of CPNI that are protected, world disclosure by ARIN or because >> of ARIN rules would not be a protected disclosure. >>> >>> The ISP might also be in trouble for providing the information to ARIN, >> if they know that ARIN intends to publish this information in a public >> directory, rather than disclosing it to ARIN solely to maintain number >> resources. As suggested by the OP, might have to call them customer 1-n. >> However that would violate the NRPM as written. Since the City, State and >> Zip Code are part of the address, even the "protected" residential records >> CPNI are being disclosed in violation of the CPNI Order. >>> >>> There is a big difference between disclosure to ARIN for taking care of >> numbering policy, and disclosure to the entire world. Third party >> disclosure is the main thing that the CPNI rules are intended to address. >> That is only permitted when it is needed for the provision of service. >> >> Compliance with registry policy is indeed necessary to receive number >> resources; >> it is up to you to determine whether IP number resources are necessary for >> provision >> of your Internet services. >> >> If you choose not to make use of Internet Numbers Registry System >> resources for >> provision of Internet services (or not assign them to your customers), >> then that is >> your choice. Some ISPs may feel that it is necessary to seek consent of >> customers >> who wish to have public IP number resources assigned in the size that >> would result in >> their publication in the public registry, whereas others may not based on >> their reading >> of applicable regulations regarding handling of CPNI information. Such >> choices are >> an operational and business matter left to each ISP to decide based on >> their individual >> understanding and circumstances. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> _______________________________________________ >> 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. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > From daveid at panix.com Mon Jul 17 13:08:49 2017 From: daveid at panix.com (David Huberman) Date: Mon, 17 Jul 2017 13:08:49 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE 89-4E1E-9553-A7B80BC82EE2@arin.net> Message-ID: <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> In addition to these options/questions, I feel like we glossed over the question posed by Marty Hannigan: what is the value of REQUIRING SWIP anymore? As a community member (not as an AC member) I have trouble supporting any of these as I'm not sure I support SWIP being anything other than voluntary. Whois reassignments are not the proper place for the information LE wants, in my opinion, and has almost no value to NOCs. And ARIN doesn't need it anymore for qualification purposes for a scarce resource. So what's he point of all this? Genuine question; no tone implied. Sent from my iPhone > On Jul 17, 2017, at 12:13 PM, Jason Schiller wrote: > > I am replying to bring the conversation to one of the suggestions > on the table. > > Owen DeLong's suggesting of SWIP all IPv6 business users, and > not Residential users, > > Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all > prefixes that might show up as a more specific in the global routing > table. > > > These are roughly the same result, and have a question of which > has a more easily understandable policy. > > The question is who here supports one or both of these > proposals? > > Who oppose one (if so which one) or both of these proposals? > > > I would like to suggest one friendly amendment... > - ISPs are required to SWIP IP space that is a reallocation. > - ISPs are required to SWIP IP space that is a reassignment > whenever that down stream customer requests such. That > SWIP must be a reassign detail, reassign simple, or a > residential privacy (if applicable) per the customer request. > > ___Jason > > > >> On Mon, Jul 17, 2017 at 10:42 AM, John Curran wrote: >> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: >> > ,,, >> > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. >> > >> > The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. >> > >> > There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. >> >> Compliance with registry policy is indeed necessary to receive number resources; >> it is up to you to determine whether IP number resources are necessary for provision >> of your Internet services. >> >> If you choose not to make use of Internet Numbers Registry System resources for >> provision of Internet services (or not assign them to your customers), then that is >> your choice. Some ISPs may feel that it is necessary to seek consent of customers >> who wish to have public IP number resources assigned in the size that would result in >> their publication in the public registry, whereas others may not based on their reading >> of applicable regulations regarding handling of CPNI information. Such choices are >> an operational and business matter left to each ISP to decide based on their individual >> understanding and circumstances. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> _______________________________________________ >> 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. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rsuc.gweep.net Mon Jul 17 13:34:06 2017 From: ppml at rsuc.gweep.net (Joe Provo) Date: Mon, 17 Jul 2017 13:34:06 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <20170717173405.GA9797@gweep.net> On Mon, Jul 17, 2017 at 01:08:49PM -0400, David Huberman wrote: > In addition to these options/questions, I feel like we glossed > over the question posed by Marty Hannigan: what is the value of > REQUIRING SWIP anymore? As a community member (not as an AC member) > I have trouble supporting any of these as I'm not sure I support > SWIP being anything other than voluntary. Whois reassignments are > not the proper place for the information LE wants, in my opinion, > and has almost no value to NOCs. I find this assertion at odds with both my experience and direct inquiries to those in the anti-abuse community. Upon what basis is it made? > And ARIN doesn't need it anymore > for qualification purposes for a scarce resource. So what's he > point of all this? Genuine question; no tone implied. As a community, we (used to?) value accountability and transparency. Having a direct contact associated with a resource has IME always worked better than trying to contact a porvider with whom I have no business relationship. [snip] > > On Jul 17, 2017, at 12:13 PM, Jason Schiller wrote: > > > > I am replying to bring the conversation to one of the suggestions > > on the table. > > > > Owen DeLong's suggesting of SWIP all IPv6 business users, and > > not Residential users, > > > > Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all > > prefixes that might show up as a more specific in the global routing > > table. > > > > > > These are roughly the same result, and have a question of which > > has a more easily understandable policy. > > > > The question is who here supports one or both of these > > proposals? > > > > Who oppose one (if so which one) or both of these proposals? Since my concern is associated with the resource usage, and we in ARIN-land historically wash our hands of connectivity/reachability, as much as the second is appealing the former is more relevant and workable. I personally dislike the blanket exception embedded within it, but know there's not going to be any upside to fighting that one so would rather take what I can get. > > I would like to suggest one friendly amendment... > > - ISPs are required to SWIP IP space that is a reallocation. > > - ISPs are required to SWIP IP space that is a reassignment > > whenever that down stream customer requests such. That > > SWIP must be a reassign detail, reassign simple, or a > > residential privacy (if applicable) per the customer request. > > > > ___Jason I like the addition. Cheers! Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From chris at semihuman.com Mon Jul 17 13:35:56 2017 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 17 Jul 2017 10:35:56 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE 89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <83DEA316-EE44-489A-BA34-8186DC6C26BD@semihuman.com> I?d argue that SWIP has historically been the primary mechanism by which recipients of allocations document their utilization of received space; is this still the case? Or are other means of documenting utilization now acceptable for allocations? (Asking as someone who hasn?t done a SWIP in 7+ years)... -C > On Jul 17, 2017, at 10:08 AM, David Huberman wrote: > > In addition to these options/questions, I feel like we glossed over the question posed by Marty Hannigan: what is the value of REQUIRING SWIP anymore? As a community member (not as an AC member) I have trouble supporting any of these as I'm not sure I support SWIP being anything other than voluntary. Whois reassignments are not the proper place for the information LE wants, in my opinion, and has almost no value to NOCs. And ARIN doesn't need it anymore for qualification purposes for a scarce resource. So what's he point of all this? Genuine question; no tone implied. > > Sent from my iPhone > > On Jul 17, 2017, at 12:13 PM, Jason Schiller > wrote: > >> I am replying to bring the conversation to one of the suggestions >> on the table. >> >> Owen DeLong's suggesting of SWIP all IPv6 business users, and >> not Residential users, >> >> Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all >> prefixes that might show up as a more specific in the global routing >> table. >> >> >> These are roughly the same result, and have a question of which >> has a more easily understandable policy. >> >> The question is who here supports one or both of these >> proposals? >> >> Who oppose one (if so which one) or both of these proposals? >> >> >> I would like to suggest one friendly amendment... >> - ISPs are required to SWIP IP space that is a reallocation. >> - ISPs are required to SWIP IP space that is a reassignment >> whenever that down stream customer requests such. That >> SWIP must be a reassign detail, reassign simple, or a >> residential privacy (if applicable) per the customer request. >> >> ___Jason >> >> >> >> On Mon, Jul 17, 2017 at 10:42 AM, John Curran > wrote: >> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: >> > ,,, >> > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. >> > >> > The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. >> > >> > There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. >> >> Compliance with registry policy is indeed necessary to receive number resources; >> it is up to you to determine whether IP number resources are necessary for provision >> of your Internet services. >> >> If you choose not to make use of Internet Numbers Registry System resources for >> provision of Internet services (or not assign them to your customers), then that is >> your choice. Some ISPs may feel that it is necessary to seek consent of customers >> who wish to have public IP number resources assigned in the size that would result in >> their publication in the public registry, whereas others may not based on their reading >> of applicable regulations regarding handling of CPNI information. Such choices are >> an operational and business matter left to each ISP to decide based on their individual >> understanding and circumstances. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> _______________________________________________ >> 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. >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com |571-266-0006 >> >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Mon Jul 17 13:54:08 2017 From: daveid at panix.com (David R Huberman) Date: Mon, 17 Jul 2017 13:54:08 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <20170717173405.GA9797@gweep.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: Hello Joe, Thanks for the reply. A reminder that I'm *asking* a genuine question. Now, I wrote: >> Whois reassignments are not the proper place for the information LE >> wants, in my opinion, and has almost no value to NOCs. Joe replied: > I find this assertion at odds with both my experience and direct > inquiries to those in the anti-abuse community. Upon what basis > is it made? So a few things. 1) I specifically said 'reassignments', and by that I meant end-user data. I have always been in favor of 'reallocations' (to downstream ISPs) being in Whois. 2) The *vast* majority (and we're talking 99%+ -- I've studied the data many times) of end-user SWIP data is things like: AT&T Internet Services SBCIS-SIS80-1005 (NET-69-0-0-0-1) 69.0.0.0 - 69.0.127.255 THE MEDICINE SHOPPE SBC069000000000030204 (NET-69-0-0-0-2) 69.0.0.0 - 69.0.0.7 When you lookup the specific /29, you get: CustName: THE MEDICINE SHOPPE Address: 310 ORANGE ST City: NEW HAVEN StateProv: CT PostalCode: 06510 Country: US ... with vanilla AT*T contact information from the parent /17. Yes: I assert this data has no value to NOCs or general internetworking operations, in my experience, and I wrote that I do not believe this is the proper place for LE to be gleaning it's info. (That's a whole other conversation, but it's my opinion here.) I don't understand how this SWIP data provides value in terms of transparency? It is, as others have noted, just giving out customer lists -- information which is typically considered confidential. ARIN policy *can* require this information, but *should* it? Additing to this conversation, two other items: 3) Since 2004, when Dave Barger first got up to a microphone at an ARIN meeting (Reston) and admitted that his company's SWIPs were non-compliant because of software issues, we've had huge swaths of SWIP data that is just wrong. It's very difficult (especially at scale) to both publish and maintain accurate SWIP data. There's a real cost to requiring accurate SWIP data for providers -- large and small. If we're going to put this cost on them for IPv6, I'd really like us to have a solid justification that's relevant to 2017 network operations, and not based on what was true in 1999. 4) And finally, we go back to an early convversation point that as presently drafted, this policy idea (required SWIPs for IPv6) is not enforceable by ARIN. In a world where you generally do not go back to the RIR for additional IPv6 prefixes, ARIN has no enforcement tools in the policy -- and the one's they could have that I can envisage, I don't support. David From alh-ietf at tndh.net Mon Jul 17 14:20:16 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 17 Jul 2017 11:20:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> Message-ID: <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> John, So you are OK with a policy that says ARIN is required to revoke address space if other ISP?s choose to accept it into the routing table, but there is no SWIP for it? To me that says you are making a statement about ?how things are routed? by requiring a database entry before it gets accepted into routing. I have no problem with a BCP to the effect that the data SHOULD exist, but as a policy this has ARIN stomping right on the line it claims to avoid. Tony From: John Curran [mailto:jcurran at arin.net] Sent: Saturday, July 15, 2017 5:53 AM To: Tony Hain Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Tony - To be clear, ARIN?s Internet number resource policy has historically avoided statements that direct or forbid routing of IP address blocks, as ARIN?s role as a Internet number registry is distinct from any role in administration of the Internet?s routing system. Such a separation doesn?t preclude the community from adopting policy which references the present or future state of routing (note, for example, the use of ?multihoming? criteria in several portions of the NRPM), but folks are reminded that in Internet number resource policy we should only be specifying how the ARIN registry is to be administered, not how things are to be routed, since the latter is up to each ISP. Thanks! /John John Curran President and CEO ARIN On 14 Jul 2017, at 9:25 PM, Tony Hain wrote: David, While I totally agree with your reasoning, doesn?t that fly in the face of the policy that Arin says ?nothing about routing?? It is one thing to have a BCP stating expectations for being able to find a contact for a routing entry, it is another to have a ?policy? that a routing entry requires swiped contact info. Tony From: David Farmer [ mailto:farmer at umn.edu] Sent: Friday, July 14, 2017 2:58 PM To: Tony Hain Cc: William Herrin; Owen DeLong; arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Rather than base it on the criteria of business vs. residential customer, how about simply basing it on the criteria, is the assignment intended to be or is used within the global routing system or not, or if the customer requests their assignment be SWIPed. Most residential assignments be they /56 or /48 won't be in the global routing system, neither will many business assignments either, after that then an assignment is only SWIPed if the customer requests it. My reasoning for wanting to have /48s SWIPed isn't based on business vs residential customer type, which has a fuzzy definition sometimes anyway. Its that /48s might appear in the routing table. So just make that the criteria in the first place, if we are not going to based it on a specific size like we did in IPv4. Also, then any policy violations become easily apparent. If an ISP doesn't SWIP some of there business customers, how are you going to know anyway? However, if a route is in the route table and there is no SWIP that is fairly self apparent. Thanks. On Fri, Jul 14, 2017 at 3:07 PM, Tony Hain < alh-ietf at tndh.net> wrote: Bill, To avoid the situation of Owen being a lone voice, I have to echo his point that it is insane that people persist with IPv4-think and extreme conservation. Allocations longer than a /48 to a residence ensure that automated topology configuration can?t happen, because /52?s won?t happen and /56?s are too long for random consumer plug-n-play. Therefore a policy that /48?s must be swiped ensures that we maintain single subnet consumer networks. A policy that says /48?s might be swiped (will in a business and not in a non-residential case) does not reinforce the braindead notion that longer than /48 has some special meaning beyond the need to kill off a generation of those with the ?addresses are a scarce resource? mindset. Tony From: ARIN-PPML [mailto: arin-ppml-bounces at arin.net] On Behalf Of William Herrin Sent: Thursday, July 13, 2017 3:12 PM To: Owen DeLong Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On Thu, Jul 13, 2017 at 4:49 PM, Owen DeLong < owen at delong.com> wrote: Consensus hasn?t yet been reached. I agree that there is significant support for ?shorter than /56? actually (not /56 itself). Nonetheless, I don?t believe that shorter than /56 is the ideal place to put the boundary. Hi Owen, I think you're an outlier here. I see consensus that /48 should be swiped and /56 should not. If there's debate that /52 or /49 should also not be swiped or that a some more subtle criteria should determine what's swiped, it's not exactly chewing up bandwidth on the mailing list. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: < http://www.dirtside.com/> _______________________________________________ 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 =============================================== _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alh-ietf at tndh.net Mon Jul 17 14:28:19 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 17 Jul 2017 11:28:19 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE 89-4E1E-9553-A7B80BC82 EE2@arin.net> Message-ID: <029001d2ff2a$76b74fc0$6425ef40$@tndh.net> Jason, I support the concept that there should be SWIP data for any more specific in the routing table, but I don?t see how that can be an ARIN policy. This appears to be the wrong venue for the discussion because the only recourse is for ARIN to revoke space that someone accepts into global routing without SWIP data. Since a 3rd party has ?accepted? the announcement, by taking the only recourse of revocation, ARIN would be stating that the routing actions of the involved ISPs are invalid. In effect making a clear statement about -how- routing is done. This is out-of-scope for ARIN. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller Sent: Monday, July 17, 2017 9:14 AM To: John Curran Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 I am replying to bring the conversation to one of the suggestions on the table. Owen DeLong's suggesting of SWIP all IPv6 business users, and not Residential users, Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all prefixes that might show up as a more specific in the global routing table. These are roughly the same result, and have a question of which has a more easily understandable policy. The question is who here supports one or both of these proposals? Who oppose one (if so which one) or both of these proposals? I would like to suggest one friendly amendment... - ISPs are required to SWIP IP space that is a reallocation. - ISPs are required to SWIP IP space that is a reassignment whenever that down stream customer requests such. That SWIP must be a reassign detail, reassign simple, or a residential privacy (if applicable) per the customer request. ___Jason On Mon, Jul 17, 2017 at 10:42 AM, John Curran wrote: On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: > ,,, > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. > > The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. > > There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. Compliance with registry policy is indeed necessary to receive number resources; it is up to you to determine whether IP number resources are necessary for provision of your Internet services. If you choose not to make use of Internet Numbers Registry System resources for provision of Internet services (or not assign them to your customers), then that is your choice. Some ISPs may feel that it is necessary to seek consent of customers who wish to have public IP number resources assigned in the size that would result in their publication in the public registry, whereas others may not based on their reading of applicable regulations regarding handling of CPNI information. Such choices are an operational and business matter left to each ISP to decide based on their individual understanding and circumstances. Thanks! /John John Curran President and CEO ARIN _______________________________________________ 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. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon Jul 17 14:33:52 2017 From: jschiller at google.com (Jason Schiller) Date: Mon, 17 Jul 2017 14:33:52 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: David, Can you define voluntary? Is the voluntary choice to record a reassignment up to the USP? Or does the choice belong to the end-user? I suspect if reassignment is voluntary for ISPs, then they will just stop doing it. In some cases it is beneficial to the end-user, supporting multi-homing, having their own abuse contact info, etc... __Jason On Mon, Jul 17, 2017 at 1:08 PM, David Huberman wrote: > In addition to these options/questions, I feel like we glossed over the > question posed by Marty Hannigan: what is the value of REQUIRING SWIP > anymore? As a community member (not as an AC member) I have trouble > supporting any of these as I'm not sure I support SWIP being anything other > than voluntary. Whois reassignments are not the proper place for the > information LE wants, in my opinion, and has almost no value to NOCs. And > ARIN doesn't need it anymore for qualification purposes for a scarce > resource. So what's he point of all this? Genuine question; no tone > implied. > > Sent from my iPhone > > On Jul 17, 2017, at 12:13 PM, Jason Schiller wrote: > > I am replying to bring the conversation to one of the suggestions > on the table. > > Owen DeLong's suggesting of SWIP all IPv6 business users, and > not Residential users, > > Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all > prefixes that might show up as a more specific in the global routing > table. > > > These are roughly the same result, and have a question of which > has a more easily understandable policy. > > The question is who here supports one or both of these > proposals? > > Who oppose one (if so which one) or both of these proposals? > > > I would like to suggest one friendly amendment... > - ISPs are required to SWIP IP space that is a reallocation. > - ISPs are required to SWIP IP space that is a reassignment > whenever that down stream customer requests such. That > SWIP must be a reassign detail, reassign simple, or a > residential privacy (if applicable) per the customer request. > > ___Jason > > > > On Mon, Jul 17, 2017 at 10:42 AM, John Curran wrote: > >> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: >> > ,,, >> > This is the problem. ARIN is not a carrier. While disclosure to ARIN >> to obtain number resources for the connection is OK, Public disclosure by >> or at the direction of ARIN policy of elements like domain name, name, >> address and telephone number is not. Since name, address, telephone number >> and domain name have already been identified have been defined in the order >> as elements of CPNI that are protected, world disclosure by ARIN or because >> of ARIN rules would not be a protected disclosure. >> > >> > The ISP might also be in trouble for providing the information to ARIN, >> if they know that ARIN intends to publish this information in a public >> directory, rather than disclosing it to ARIN solely to maintain number >> resources. As suggested by the OP, might have to call them customer 1-n. >> However that would violate the NRPM as written. Since the City, State and >> Zip Code are part of the address, even the "protected" residential records >> CPNI are being disclosed in violation of the CPNI Order. >> > >> > There is a big difference between disclosure to ARIN for taking care of >> numbering policy, and disclosure to the entire world. Third party >> disclosure is the main thing that the CPNI rules are intended to address. >> That is only permitted when it is needed for the provision of service. >> >> Compliance with registry policy is indeed necessary to receive number >> resources; >> it is up to you to determine whether IP number resources are necessary >> for provision >> of your Internet services. >> >> If you choose not to make use of Internet Numbers Registry System >> resources for >> provision of Internet services (or not assign them to your customers), >> then that is >> your choice. Some ISPs may feel that it is necessary to seek consent of >> customers >> who wish to have public IP number resources assigned in the size that >> would result in >> their publication in the public registry, whereas others may not based on >> their reading >> of applicable regulations regarding handling of CPNI information. Such >> choices are >> an operational and business matter left to each ISP to decide based on >> their individual >> understanding and circumstances. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> _______________________________________________ >> 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. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 17 14:53:07 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 13:53:07 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <325f0ba7-b164-4865-a343-116eb34d14b6@cameron.net> > Compliance with registry policy is indeed necessary to receive number > resources; > it is up to you to determine whether IP number resources are necessary > for provision > of your Internet services. But doesn't ARIN registry policy have to follow the law concerning CPNI ? This is where I have always had trouble with your comments John, you are constantly making "veil" threats about our ability to receive ARIN resources. Then your staff says to ignore your "veil" threats. Paul McNary pmcnary at cameron.net On 7/17/2017 1:33 PM, Jason Schiller wrote: > David, > > Can you define voluntary? > > Is the voluntary choice to record a reassignment > up to the USP? > > Or does the choice belong to the end-user? > > > I suspect if reassignment is voluntary for ISPs, then they > will just stop doing it. In some cases it is beneficial to the > end-user, supporting multi-homing, having their own abuse > contact info, etc... > > __Jason > > > On Mon, Jul 17, 2017 at 1:08 PM, David Huberman > wrote: > > In addition to these options/questions, I feel like we glossed > over the question posed by Marty Hannigan: what is the value of > REQUIRING SWIP anymore? As a community member (not as an AC > member) I have trouble supporting any of these as I'm not sure I > support SWIP being anything other than voluntary. Whois > reassignments are not the proper place for the information LE > wants, in my opinion, and has almost no value to NOCs. And ARIN > doesn't need it anymore for qualification purposes for a scarce > resource. So what's he point of all this? Genuine question; no > tone implied. > > Sent from my iPhone > > On Jul 17, 2017, at 12:13 PM, Jason Schiller > wrote: > >> I am replying to bring the conversation to one of the suggestions >> on the table. >> >> Owen DeLong's suggesting of SWIP all IPv6 business users, and >> not Residential users, >> >> Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all >> prefixes that might show up as a more specific in the global routing >> table. >> >> >> These are roughly the same result, and have a question of which >> has a more easily understandable policy. >> >> The question is who here supports one or both of these >> proposals? >> >> Who oppose one (if so which one) or both of these proposals? >> >> >> I would like to suggest one friendly amendment... >> - ISPs are required to SWIP IP space that is a reallocation. >> - ISPs are required to SWIP IP space that is a reassignment >> whenever that down stream customer requests such. That >> SWIP must be a reassign detail, reassign simple, or a >> residential privacy (if applicable) per the customer request. >> >> ___Jason >> >> >> >> On Mon, Jul 17, 2017 at 10:42 AM, John Curran > > wrote: >> >> On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com >> wrote: >> > ,,, >> > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number >> resources for the connection is OK, Public disclosure by or >> at the direction of ARIN policy of elements like domain name, >> name, address and telephone number is not. Since name, >> address, telephone number and domain name have already been >> identified have been defined in the order as elements of CPNI >> that are protected, world disclosure by ARIN or because of >> ARIN rules would not be a protected disclosure. >> > >> > The ISP might also be in trouble for providing the >> information to ARIN, if they know that ARIN intends to >> publish this information in a public directory, rather than >> disclosing it to ARIN solely to maintain number resources. >> As suggested by the OP, might have to call them customer 1-n. >> However that would violate the NRPM as written. Since the >> City, State and Zip Code are part of the address, even the >> "protected" residential records CPNI are being disclosed in >> violation of the CPNI Order. >> > >> > There is a big difference between disclosure to ARIN for >> taking care of numbering policy, and disclosure to the entire >> world. Third party disclosure is the main thing that the >> CPNI rules are intended to address. That is only permitted >> when it is needed for the provision of service. >> >> Compliance with registry policy is indeed necessary to >> receive number resources; >> it is up to you to determine whether IP number resources are >> necessary for provision >> of your Internet services. >> >> If you choose not to make use of Internet Numbers Registry >> System resources for >> provision of Internet services (or not assign them to your >> customers), then that is >> your choice. Some ISPs may feel that it is necessary to >> seek consent of customers >> who wish to have public IP number resources assigned in the >> size that would result in >> their publication in the public registry, whereas others may >> not based on their reading >> of applicable regulations regarding handling of CPNI >> information. Such choices are >> an operational and business matter left to each ISP to decide >> based on their individual >> understanding and circumstances. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> ARIN >> >> >> _______________________________________________ >> 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. >> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com >> |571-266-0006 >> >> _______________________________________________ >> 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. > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com > |571-266-0006 > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Mon Jul 17 15:11:42 2017 From: daveid at panix.com (David R Huberman) Date: Mon, 17 Jul 2017 15:11:42 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: > Can you define voluntary? > > Is the voluntary choice to record a reassignment > up to the USP? > > Or does the choice belong to the end-user? I think that's a business decision the two parties make together. I think an ISP can choose to SWIP whatever it wants, and should do so with the consent of the end-user. I think an end-user should be able to demand a SWIP entry, and the ISP should generally comply. From pmcnary at cameron.net Mon Jul 17 15:17:48 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 14:17:48 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: The way I understand, SWIP can be voluntary but with consequences at ARIN if we don't. Am I hearing wrong? Take care Paul pmcnary at cameron.net On 7/17/2017 2:11 PM, David R Huberman wrote: > >> Can you define voluntary? >> >> Is the voluntary choice to record a reassignment >> up to the USP? >> >> Or does the choice belong to the end-user? > > I think that's a business decision the two parties make together. I > think an ISP can choose to SWIP whatever it wants, and should do so > with the consent of the end-user. I think an end-user should be able > to demand a SWIP entry, and the ISP should generally comply. > > _______________________________________________ > 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. > > From jcurran at arin.net Mon Jul 17 15:25:00 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 19:25:00 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> Message-ID: <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> On 17 Jul 2017, at 11:20 AM, Tony Hain > wrote: John, So you are OK with a policy that says ARIN is required to revoke address space if other ISP?s choose to accept it into the routing table, but there is no SWIP for it? To me that says you are making a statement about ?how things are routed? by requiring a database entry before it gets accepted into routing. I have no problem with a BCP to the effect that the data SHOULD exist, but as a policy this has ARIN stomping right on the line it claims to avoid. Tony - ARIN number resource policy must be germane to administration of the registry; i.e. if you want a policy that says an address block will only be issued for a certain reason (and that reason includes some routing characteristic, such as multihoming) then ARIN will have parties represent that they intend to use in accordance with that requirement, and will investigate representations that appear to be fraudulent. For example, a policy that states that "IPv6 blocks will have SWIP performed for any sub-delegations which are going to be individually announced by the ISP" would be a policy which is enforceable, since the ISP is representing that they?ll do ?X" under certain circumstances, and it?s trivial to revoke if they fail to follow through and we receive a fraud report from the community calling attention to that fraud. Just remember, any characteristic or behavior that you intend to promulgate in this manner effectively effective defines or extends the scope of ARIN?s mission, so it?s worth being very cautious and very certain before proposing such? The fact that parties need IP address space mean that they have little effective remedy to the implications of community-developed number policy, and so requirements that aren?t directly and clearly related to ARIN?s mission (e.g. ?requester agrees that they will put a statute of ARIN?s CEO in their lobby within 12 months of issuance?) are likely to be found out of scope by ARIN?s Board of Trustees... Thanks! /John John Curran President and CEO American Registry of Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From ppml at rsuc.gweep.net Mon Jul 17 15:26:02 2017 From: ppml at rsuc.gweep.net (Joe Provo) Date: Mon, 17 Jul 2017 15:26:02 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> Message-ID: <20170717192602.GA73898@gweep.net> On Mon, Jul 17, 2017 at 01:04:26AM -0400, hostmaster at uneedus.com wrote: > John, > > I think this is the FCC ruling he speaks of, and it does seem to shut down > public disclosures of most of what is contained in SWIP/WHOIS without > customer consent. This has been the rule for regular phone calls for a > long time, called CPNI. Until today I did not realise the FCC extended > this to the internet. I'm not currently providing this service, but I did so when the discussion came around and recall when this was extended. It was specifically regarding services. All the CPNI rules stremmed from a customer's existing providers having an unfair marketing advantage by looking at the customer's services and usage. It was rooted in the age of slamming and "pretexting". Even expanding that to generic Internet service did not change the definition to remove the scope of services provided to a customer. [snip] > http://hraunfoss.fcc.gov/edocs_public/attachmatch/FCC-07-22A1.pdf [snip] In that doc, see "Discussion" section F "Extension of CPNI Requirements to Providers of Interconnected VoIP Service". Even with ISPs under title 2, without inclusion of service information a public registry has [IME] no relationship to the CPNI issue. That said, my personal suggestion would be to not include type of service ( -DSL-, -FTTH-, etc) in the SWIP netblock name or elsewhere in the record purely from an infosec PoV. :-) Cheers (this is not legal advice), Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From jcurran at arin.net Mon Jul 17 15:28:57 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 19:28:57 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <325f0ba7-b164-4865-a343-116eb34d14b6@cameron.net> References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <325f0ba7-b164-4865-a343-116eb34d14b6@cameron.net> Message-ID: On 17 Jul 2017, at 11:53 AM, Paul McNary wrote: > > >> Compliance with registry policy is indeed necessary to receive number resources; >> it is up to you to determine whether IP number resources are necessary for provision >> of your Internet services. > > But doesn't ARIN registry policy have to follow the law concerning CPNI ? Paul - if you are a regulated service provider, then you need to comply with the appropriate regulations, and that may govern how your firm interacts with its customers and how you interact with ARIN. ARIN is neither a regulated service provider nor subject to the regulations that you reference, and we will operate accordingly to the community-developed policy. Thanks, /John John Curran President and CEO ARIN From chris at semihuman.com Mon Jul 17 15:32:27 2017 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 17 Jul 2017 12:32:27 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM In-Reply-To: References: <59495DF4.8010504@arin.net> Message-ID: <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> Hello, Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response to the proposal in its current state appears to be universally negative. Having read the comments on this proposal, it could be plausible that an alternate solution to the problem statement could be that in lieu of retiring most of the section, specific sections could be substantially simplified by pointing to the currently-duplicated clauses in Section 6, eliminating the need to manually keep these sections in sync by applying similar policy to both where warranted (in particular, the sections around utilization justification seem like the best candidates). Does the community feel that this is a viable route to explore, which would simplify Section 4 while keeping the necessary relevant sections, in lieu of the original proposal? Thanks, -Chris > On Jun 21, 2017, at 12:16 PM, Austin Murkland wrote: > > I do not support this policy for the reasons Kevin and Albert outlined. This seems a bit premature. > > Thanks, > > Austin Murkland > > On Tue, Jun 20, 2017 at 1:40 PM, ARIN > wrote: > On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft Policy status. > > Draft Policy ARIN-2017-7 is below and can be found at: > https://www.arin.net/policy/proposals/2017_7.html > > 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-7: Retire Obsolete Section 4 from the NRPM > > Problem Statement: > > Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The community elected, instead of revamping and modernizing section 4 in light of this to, instead, recreate the relevant parts of section 4 in section 8.5. As a result, section 4 is generally obsolete and can be mostly retired. Since some small amounts of space do occasionally recreate the free pool, a mechanism for addressing this must remain and therefore a much reduced section 4 is proposed here instead of outright retirement. > > Policy statement: > > Replace section 4 of the NRPM with the following: > > 4. IPv4 > > 4.1 IPv4 Requests > > 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall be evaluated based on the criteria for transfer recipients contained in section 8.5. > > 4.1.2 Any approved requests which cannot be met from the ARIN free pool shall be handled according to section 4.2. > > 4.2 Unmet requests > > In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable. > > Repeated requests are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. > > Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. > > 4.2.1. Waiting list > > The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. > > 4.2.2. Fulfilling unmet needs > > As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. > > Comments: > > a. Timetable for implementation: Immediate > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Mon Jul 17 15:49:18 2017 From: rjletts at uw.edu (Richard J Letts) Date: Mon, 17 Jul 2017 19:49:18 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> Message-ID: I have too many roles and job-titles, so below is my opinion only (as I'm at lunch right now) My 2c. As a residential customer with IPv6: There are many valid reasons not to expose individual residential customer addresses. For example someone being stalked or harassed by an ex. If their IPv6 address is exposed in any way that leads someone too easily back to them then that is not a good thing. I feel that the length should mirror what is implicitly provided for ipv4 because the customer expectation has some importance here. I'm going to note that Comcast is currently handing out /60 to residential customers. Therefore I think swipping: /60 & smaller : Bad idea (does not provide the same _implicit_ privacy that IPv4 does) /56: maybe if that's your default assignment block /52: maybe if that's your default assignment block /48: should be required. I'm also going to note that with IPv6 I can have multiple IPv6 addresses from different providers if I am simply multi-homed (i.e. not exchanging routing information). As a NOC manager: I find SWIP records occasionally useful for reaching people I need to when discussing routing or abuse issues. It's not often but they are useful when they are there. For the WA-State K20 network we do our best to ensure that we have these correctly published so people can reach the right contacts on that network (we are not always told when contacts leave) I find SWIP records a pain to manage, but given I find them useful I'm quite happy to publish them as a help to the community. It's as easy to SWIP a /56 as a /48 if I'm already doing the /48 -- it's all just database updates and a SMOP. Anyone getting a /56 or /48 isn't likely to be a residential customer. (note: WA-K20 State network default assignment is a /48 -- but that's not relevant to the point here) Business are generally required to have registered address for communications, they can always use that for their registration. Richard Letts Manager: Network Operations Center: UW, UW Medicine, WA-K20, PNWGP, PacificWave, WRN Process Manager: Incident Management, Event Management Service Manager: Wired Network Service UW Information Technology Mail: Box 354840 Street: 4545 15th Ave NE, Seattle, WA, 98105 206.685.1699 | mobile 206.790.5837 rjletts at uw.edu From farmer at umn.edu Mon Jul 17 16:08:34 2017 From: farmer at umn.edu (David Farmer) Date: Mon, 17 Jul 2017 15:08:34 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman wrote: > > Can you define voluntary? >> >> Is the voluntary choice to record a reassignment >> up to the USP? >> >> Or does the choice belong to the end-user? >> > > I think that's a business decision the two parties make together. I think > an ISP can choose to SWIP whatever it wants, and should do so with the > consent of the end-user. I think an end-user should be able to demand a > SWIP entry, and the ISP should generally comply. > And if the ISP doesn't comply with the user's demand, can one of their recourses be to appeal to ARIN? Obviously, in a healthy market another, and maybe more effective, option is to get another ISP. However, not all markets are healthy and too frequently users have only one realistic option for an ISP, especially in rural areas. I think it is important that if a user requests a SWIP from an ISP, and they not given the SWIP, this should be at very least a technical violation of ARIN policy. Is ARIN going to revoke an ISP's address space because of a single complaint from a user in this regard, of course not, but I would expect ARIN to intercede with an ISP on behalf of the user. However, if there are repeated issues, especially large numbers of them, and if there are other policy violations too, then I would expect harsher actions by ARIN eventually. Thanks -- =============================================== 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: From alh-ietf at tndh.net Mon Jul 17 17:25:30 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 17 Jul 2017 14:25:30 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> Message-ID: <02fe01d2ff43$37556240$a60026c0$@tndh.net> John, I think we are in violent agreement here, other than the ARIN membership is the wrong venue (not broad enough to encompass the appropriate community) for the base statement that SWIP data must exist for a routing entry. If the appropriately broad community established that BCP; a policy enforceable by ARIN staff would be ?complies with community established BCP?s related to routing?. The only problem I have with the general braindead conservation mindset that says a /48 is non-consumer, and must be SWIPed while longer values would be only consumer and therefore exempt. As far as it goes, if a consumer convinced the ISP they had a technical need for a /36, that should be exempt based on consumer protection. Length has nothing to do with it. Identifiable routing slot contact info is the ?need? here, so anything that is not broken out doesn?t ?need? SWIP data. That said, this whole paragraph, and most of the current discussion belongs in another venue. Tony From: John Curran [mailto:jcurran at arin.net] Sent: Monday, July 17, 2017 12:25 PM To: Tony Hain Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On 17 Jul 2017, at 11:20 AM, Tony Hain wrote: John, So you are OK with a policy that says ARIN is required to revoke address space if other ISP?s choose to accept it into the routing table, but there is no SWIP for it? To me that says you are making a statement about ?how things are routed? by requiring a database entry before it gets accepted into routing. I have no problem with a BCP to the effect that the data SHOULD exist, but as a policy this has ARIN stomping right on the line it claims to avoid. Tony - ARIN number resource policy must be germane to administration of the registry; i.e. if you want a policy that says an address block will only be issued for a certain reason (and that reason includes some routing characteristic, such as multihoming) then ARIN will have parties represent that they intend to use in accordance with that requirement, and will investigate representations that appear to be fraudulent. For example, a policy that states that "IPv6 blocks will have SWIP performed for any sub-delegations which are going to be individually announced by the ISP" would be a policy which is enforceable, since the ISP is representing that they?ll do ?X" under certain circumstances, and it?s trivial to revoke if they fail to follow through and we receive a fraud report from the community calling attention to that fraud. Just remember, any characteristic or behavior that you intend to promulgate in this manner effectively effective defines or extends the scope of ARIN?s mission, so it?s worth being very cautious and very certain before proposing such? The fact that parties need IP address space mean that they have little effective remedy to the implications of community-developed number policy, and so requirements that aren?t directly and clearly related to ARIN?s mission (e.g. ?requester agrees that they will put a statute of ARIN?s CEO in their lobby within 12 months of issuance?) are likely to be found out of scope by ARIN?s Board of Trustees... Thanks! /John John Curran President and CEO American Registry of Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 17 17:44:42 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 16:44:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <02fe01d2ff43$37556240$a60026c0$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> <02fe01d2ff43$37556240$a60026c0$@tndh.net> Message-ID: <97f0cfcb-3515-3261-9f65-e7b0b44b574a@cameron.net> Tony Do you mean BGP instead of BCP. I agree that IP's that are BGP routable should be the proper place to place the SWIP requirement. Anything not BGP routable should be considered local routed. Paul On 7/17/2017 4:25 PM, Tony Hain wrote: > > John, > > I think we are in violent agreement here, other than the ARIN > membership is the wrong venue (not broad enough to encompass the > appropriate community) for the base statement that SWIP data must > exist for a routing entry. If the appropriately broad community > established that BCP; a policy enforceable by ARIN staff would be > ?complies with community established BCP?s related to routing?. > > The only problem I have with the general braindead conservation > mindset that says a /48 is non-consumer, and must be SWIPed while > longer values would be only consumer and therefore exempt. As far as > it goes, if a consumer convinced the ISP they had a technical need for > a /36, that should be exempt based on consumer protection. Length has > nothing to do with it. Identifiable routing slot contact info is the > ?need? here, so anything that is not broken out doesn?t ?need? SWIP > data. That said, this whole paragraph, and most of the current > discussion belongs in another venue. > > Tony > > *From:*John Curran [mailto:jcurran at arin.net] > *Sent:* Monday, July 17, 2017 12:25 PM > *To:* Tony Hain > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > > On 17 Jul 2017, at 11:20 AM, Tony Hain > wrote: > > John, > > So you are OK with a policy that says ARIN is required to revoke > address space if other ISP?s choose to accept it into the routing > table, but there is no SWIP for it? To me that says you are making > a statement about ?how things are routed? by requiring a database > entry before it gets accepted into routing. > > I have no problem with a BCP to the effect that the data SHOULD > exist, but as a policy this has ARIN stomping right on the line it > claims to avoid. > > Tony - > > ARIN number resource policy must be germane to administration of the > registry; > > i.e. if you want a policy that says an address block will only be > issued for a certain > > reason (and that reason includes some routing characteristic, such as > multihoming) > > then ARIN will have parties represent that they intend to use in > accordance with > > that requirement, and will investigate representations that appear to > be fraudulent. > > For example, a policy that states that "IPv6 blocks will have SWIP > performed for any > > sub-delegations which are going to be individually announced by the > ISP" would be > > a policy which is enforceable, since the ISP is representing that > they?ll do ?X" under > > certain circumstances, and it?s trivial to revoke if they fail to > follow through and we > > receive a fraud report from the community calling attention to that > fraud. > > Just remember, any characteristic or behavior that you intend to > promulgate in this > > manner effectively effective defines or extends the scope of ARIN?s > mission, so it?s > > worth being very cautious and very certain before proposing such? > The fact that > > parties need IP address space mean that they have little effective > remedy to the > > implications of community-developed number policy, and so requirements > that aren?t > > directly and clearly related to ARIN?s mission (e.g. ?requester agrees > that they will > > put a statute of ARIN?s CEO in their lobby within 12 months of > issuance?) are likely > > to be found out of scope by ARIN?s Board of Trustees... > > Thanks! > > /John > > John Curran > > President and CEO > > American Registry of Internet Numbers > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 17 17:47:31 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 16:47:31 -0500 Subject: [arin-ppml] Correcte: Re: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <02fe01d2ff43$37556240$a60026c0$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> <02fe01d2ff43$37556240$a60026c0$@tndh.net> Message-ID: <54018ee9-1da3-99d1-a31f-51f63269db63@cameron.net> Tony If BCP (Best Current Practices) = BGP I would agree that IP's that are BGP routable should be the proper place to place the SWIP requirement. Anything not BGP routable should be considered local routed. That is my current idea of what would work. Paul On 7/17/2017 4:25 PM, Tony Hain wrote: > > John, > > I think we are in violent agreement here, other than the ARIN > membership is the wrong venue (not broad enough to encompass the > appropriate community) for the base statement that SWIP data must > exist for a routing entry. If the appropriately broad community > established that BCP; a policy enforceable by ARIN staff would be > ?complies with community established BCP?s related to routing?. > > The only problem I have with the general braindead conservation > mindset that says a /48 is non-consumer, and must be SWIPed while > longer values would be only consumer and therefore exempt. As far as > it goes, if a consumer convinced the ISP they had a technical need for > a /36, that should be exempt based on consumer protection. Length has > nothing to do with it. Identifiable routing slot contact info is the > ?need? here, so anything that is not broken out doesn?t ?need? SWIP > data. That said, this whole paragraph, and most of the current > discussion belongs in another venue. > > Tony > > *From:*John Curran [mailto:jcurran at arin.net] > *Sent:* Monday, July 17, 2017 12:25 PM > *To:* Tony Hain > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > Assignment Registration requirements between IPv4 and IPv6 > > On 17 Jul 2017, at 11:20 AM, Tony Hain > wrote: > > John, > > So you are OK with a policy that says ARIN is required to revoke > address space if other ISP?s choose to accept it into the routing > table, but there is no SWIP for it? To me that says you are making > a statement about ?how things are routed? by requiring a database > entry before it gets accepted into routing. > > I have no problem with a BCP to the effect that the data SHOULD > exist, but as a policy this has ARIN stomping right on the line it > claims to avoid. > > Tony - > > ARIN number resource policy must be germane to administration of the > registry; > > i.e. if you want a policy that says an address block will only be > issued for a certain > > reason (and that reason includes some routing characteristic, such as > multihoming) > > then ARIN will have parties represent that they intend to use in > accordance with > > that requirement, and will investigate representations that appear to > be fraudulent. > > For example, a policy that states that "IPv6 blocks will have SWIP > performed for any > > sub-delegations which are going to be individually announced by the > ISP" would be > > a policy which is enforceable, since the ISP is representing that > they?ll do ?X" under > > certain circumstances, and it?s trivial to revoke if they fail to > follow through and we > > receive a fraud report from the community calling attention to that > fraud. > > Just remember, any characteristic or behavior that you intend to > promulgate in this > > manner effectively effective defines or extends the scope of ARIN?s > mission, so it?s > > worth being very cautious and very certain before proposing such? > The fact that > > parties need IP address space mean that they have little effective > remedy to the > > implications of community-developed number policy, and so requirements > that aren?t > > directly and clearly related to ARIN?s mission (e.g. ?requester agrees > that they will > > put a statute of ARIN?s CEO in their lobby within 12 months of > issuance?) are likely > > to be found out of scope by ARIN?s Board of Trustees... > > Thanks! > > /John > > John Curran > > President and CEO > > American Registry of Internet Numbers > > > > _______________________________________________ > 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 contactinfo at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 17 17:52:10 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 21:52:10 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <02fe01d2ff43$37556240$a60026c0$@tndh.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> <02fe01d2ff43$37556240$a60026c0$@tndh.net> Message-ID: <09570849-7FBE-4B2C-9097-1212D2F08BE4@arin.net> On 17 Jul 2017, at 2:25 PM, Tony Hain > wrote: John, I think we are in violent agreement here, other than the ARIN membership is the wrong venue (not broad enough to encompass the appropriate community) for the base statement that SWIP data must exist for a routing entry. If the appropriately broad community established that BCP; a policy enforceable by ARIN staff would be ?complies with community established BCP?s related to routing?. The only problem I have with the general braindead conservation mindset that says a /48 is non-consumer, and must be SWIPed while longer values would be only consumer and therefore exempt. As far as it goes, if a consumer convinced the ISP they had a technical need for a /36, that should be exempt based on consumer protection. Length has nothing to do with it. Identifiable routing slot contact info is the ?need? here, so anything that is not broken out doesn?t ?need? SWIP data. That said, this whole paragraph, and most of the current discussion belongs in another venue. Tony - This is an open forum ? i.e. one does not have to be an ARIN Member to participate in the discussion. To that end, if there is number resource policy to be developed by the community which is applicable to the ARIN registry, then such policy is developed on the ARIN Public Policy mailing list and associated (also open w/o charge to all) ARIN Public policy meetings. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Mon Jul 17 17:52:52 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 17:52:52 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <97f0cfcb-3515-3261-9f65-e7b0b44b574a@cameron.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <028b01d2ff29$56c9bf50$045d3df0$@tndh.net> <3AA6E44B-A0C3-4F69-B6B8-20F52EDBAF2F@arin.net> <02fe01d2ff43$37556240$a60026c0$@tndh.net> <97f0cfcb-3515-3261-9f65-e7b0b44b574a@cameron.net> Message-ID: Maybe the rule could be SWIP for a /48 or more if the downstream customer also has an ASN so that they can receive BGP announcements, otherwise SWIP would not be required. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, Paul McNary wrote: > Tony > > Do you mean BGP instead of BCP. I agree that IP's that are BGP routable > should be the proper place > to place the SWIP requirement. Anything not BGP routable should be considered > local routed. > > Paul > On 7/17/2017 4:25 PM, Tony Hain wrote: >> >> John, >> >> I think we are in violent agreement here, other than the ARIN membership is >> the wrong venue (not broad enough to encompass the appropriate community) >> for the base statement that SWIP data must exist for a routing entry. If >> the appropriately broad community established that BCP; a policy >> enforceable by ARIN staff would be ???complies with community established >> BCP???s related to routing???. >> >> The only problem I have with the general braindead conservation mindset >> that says a /48 is non-consumer, and must be SWIPed while longer values >> would be only consumer and therefore exempt. As far as it goes, if a >> consumer convinced the ISP they had a technical need for a /36, that should >> be exempt based on consumer protection. Length has nothing to do with it. >> Identifiable routing slot contact info is the ???need??? here, so anything >> that is not broken out doesn???t ???need??? SWIP data. That said, this >> whole paragraph, and most of the current discussion belongs in another >> venue. >> >> Tony >> >> *From:*John Curran [mailto:jcurran at arin.net] >> *Sent:* Monday, July 17, 2017 12:25 PM >> *To:* Tony Hain >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of >> Assignment Registration requirements between IPv4 and IPv6 >> >> On 17 Jul 2017, at 11:20 AM, Tony Hain > > wrote: >> >> John, >> >> So you are OK with a policy that says ARIN is required to revoke >> address space if other ISP???s choose to accept it into the routing >> table, but there is no SWIP for it? To me that says you are making >> a statement about ???how things are routed??? by requiring a database >> entry before it gets accepted into routing. >> >> I have no problem with a BCP to the effect that the data SHOULD >> exist, but as a policy this has ARIN stomping right on the line it >> claims to avoid. >> >> Tony - >> >> ARIN number resource policy must be germane to administration of the >> registry; >> >> i.e. if you want a policy that says an address block will only be issued >> for a certain >> >> reason (and that reason includes some routing characteristic, such as >> multihoming) >> >> then ARIN will have parties represent that they intend to use in accordance >> with >> >> that requirement, and will investigate representations that appear to be >> fraudulent. >> >> For example, a policy that states that "IPv6 blocks will have SWIP >> performed for any >> >> sub-delegations which are going to be individually announced by the ISP" >> would be >> >> a policy which is enforceable, since the ISP is representing that they???ll >> do ???X" under >> >> certain circumstances, and it???s trivial to revoke if they fail to follow >> through and we >> >> receive a fraud report from the community calling attention to that fraud. >> >> Just remember, any characteristic or behavior that you intend to promulgate >> in this >> >> manner effectively effective defines or extends the scope of ARIN???s >> mission, so it???s >> >> worth being very cautious and very certain before proposing such??? The >> fact that >> >> parties need IP address space mean that they have little effective remedy >> to the >> >> implications of community-developed number policy, and so requirements that >> aren???t >> >> directly and clearly related to ARIN???s mission (e.g. ???requester agrees >> that they will >> >> put a statute of ARIN???s CEO in their lobby within 12 months of >> issuance???) are likely >> >> to be found out of scope by ARIN???s Board of Trustees... >> >> Thanks! >> >> /John >> >> John Curran >> >> President and CEO >> >> American Registry of Internet Numbers >> >> >> >> _______________________________________________ >> 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. > > From hostmaster at uneedus.com Mon Jul 17 17:53:21 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 17:53:21 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: Just a couple of questions regarding the carrots and the sticks for the ARIN staff: Other than those who came back to change their initial /35 to a /32, how many ARIN customers have come back for another allocation of IPv6 space because they used the first one to the extent the rules require, which I think is 75% of /48 block assignments. And, how many customers have received a first allocation of IPv6? Divide, and I can find out what percentage came back for more. What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? Another bit of info I would like to know if possible: what percentage of customers with a v6 allocation has actually put any of their assignments into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every allocation should be there. The answers are useful to determine as far as the documenting the assignment for ARIN, how useful SWIP is for that purpose. I have a /48 from 2 upstreams. Only one is registered. The other ISP does not appear to have ANY SWIP entries, even though I have set up the network with static v6 for at least a dozen customers, each of which received a /48. Another "proxy" for to consider in deciding to SWIP or not might be the delegation of the reverse DNS for the allocated block. If there is a delegation, this is another way to find the technical contact other than SWIP if there is a problem. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, David Farmer wrote: > On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman wrote: > >> >> Can you define voluntary? >>> >>> Is the voluntary choice to record a reassignment >>> up to the USP? >>> >>> Or does the choice belong to the end-user? >>> >> >> I think that's a business decision the two parties make together. I think >> an ISP can choose to SWIP whatever it wants, and should do so with the >> consent of the end-user. I think an end-user should be able to demand a >> SWIP entry, and the ISP should generally comply. >> > > And if the ISP doesn't comply with the user's demand, can one of their > recourses be to appeal to ARIN? Obviously, in a healthy market another, > and maybe more effective, option is to get another ISP. However, not all > markets are healthy and too frequently users have only one realistic option > for an ISP, especially in rural areas. > > I think it is important that if a user requests a SWIP from an ISP, and > they not given the SWIP, this should be at very least a technical violation > of ARIN policy. Is ARIN going to revoke an ISP's address space because of > a single complaint from a user in this regard, of course not, but I would > expect ARIN to intercede with an ISP on behalf of the user. However, if > there are repeated issues, especially large numbers of them, and if there > are other policy violations too, then I would expect harsher actions by > ARIN eventually. > > Thanks > > -- > =============================================== > 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 > =============================================== > From lsawyer at gci.com Mon Jul 17 18:09:01 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Mon, 17 Jul 2017 22:09:01 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: Shepherd of the draft policy chiming in. Thanks for the lively discussion, everybody. There's certainly a lot to think about here. Just as a reminder to folk, the current policy under question is located here: https://www.arin.net/policy/nrpm.html#six551 And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" in lieu of actual names and street addresses. -- With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more preferential rewrite of the opening sentence of 6.5.5.1? a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. b) Each static IPv6 assignment containing a /55 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. Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" Third: If none of these options are palatable, do you have a proposed approach? Thanks, Leif Sawyer Advisory Council -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 17 18:40:12 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 17:40:12 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> Leif If I understand your question: Originally /48 to anyone was the BCP for future efficiency. I can change my BCP to /56. /48 is my preference, however, which is the BGP boundary. Otherwise I have little issue with choice "b" if forced. I would prefer to give my residential users a /48 for the future but a /56 could work, just a pain. Again rDNS could be a problem. Do AS's use ARIN reverse DNS for size smaller than /48? If rDNS will not work worldwide except with /48 advertising, I think that should be the SWIP boundary. I know for a while some AS's required /32. I think that has finally changed. However ARIN's assignment web page indicates we should be SWIP'ing /29's on IPv4 by policy or risk ARIN action. Thank you Paul McNary pmcnary at cameron.net On 7/17/2017 5:09 PM, Leif Sawyer wrote: > > Shepherd of the draft policy chiming in. > > Thanks for the lively discussion, everybody. There's certainly a lot > to think about here. > > Just as a reminder to folk, the current policy under question is > located here: > > https://www.arin.net/policy/nrpm.html#six551 > > And, to help clarify some confusion, per 6.5.5.3.1 > (https://www.arin.net/policy/nrpm.html#six5531) > > residential customers "holding/64 and larger blocks" may use > censored data, i.e. "Private Customer/Residence" > > in lieu of actual names and street addresses. > > -- > > With that said, I have a couple of questions to ask, based on > potential rewrites that are brewing. > > First: Assuming a preference for /56 (based on PPML feedback) for > the moment, which is the more > > preferential rewrite of the opening sentence of 6.5.5.1? > > a)Each static IPv6 assignment containing a /55 or more addresses shall > be registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2. > > > b)Each static IPv6 assignment containing a /55 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. > > Second: Given your specific choice of A or B, are you preferentially > inclined to choose the provided bit-boundary, or "/48" > > Third: If none of these options are palatable, do you have a proposed > approach? > > Thanks, > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Mon Jul 17 18:46:01 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 17 Jul 2017 18:46:01 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: The language of "b)" actually makes more sense with a /47: 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. The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 17 Jul 2017, Leif Sawyer wrote: > Shepherd of the draft policy chiming in. > > Thanks for the lively discussion, everybody. There's certainly a lot to think about here. > > Just as a reminder to folk, the current policy under question is located here: > https://www.arin.net/policy/nrpm.html#six551 > > And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) > residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" > in lieu of actual names and street addresses. > > -- > > With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. > > First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more > preferential rewrite of the opening sentence of 6.5.5.1? > > > a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. > > > > b) Each static IPv6 assignment containing a /55 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. > > > Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" > > Third: If none of these options are palatable, do you have a proposed approach? > > > > Thanks, > > Leif Sawyer > Advisory Council > > From pmcnary at cameron.net Mon Jul 17 18:54:59 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 17 Jul 2017 17:54:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <0e1e523a-de65-2edf-7a03-265a622b8e49@cameron.net> +1 That is what I agree with. However reading the ARIN reassignment web page they are showing policy that /60 should be SWIP'ed on IPv6 and /29 on IPv4. Thanks you Paul On 7/17/2017 5:46 PM, hostmaster at uneedus.com wrote: > The language of "b)" actually makes more sense with a /47: > > 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. > > The major difference is that this language eliminates the SWIP > requirement for /48 blocks that are not announced, but all larger > blocks require SWIP, and blocks smaller than /48 are also exempt and > of course also non-routeable. > > This is best for those that think SWIP should be limited to only > blocks that are individually announced. I could go either way on this > issue. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Mon, 17 Jul 2017, Leif Sawyer wrote: > >> Shepherd of the draft policy chiming in. >> >> Thanks for the lively discussion, everybody. There's certainly a >> lot to think about here. >> >> Just as a reminder to folk, the current policy under question is >> located here: >> https://www.arin.net/policy/nrpm.html#six551 >> >> And, to help clarify some confusion, per 6.5.5.3.1 >> (https://www.arin.net/policy/nrpm.html#six5531) >> residential customers "holding/64 and larger blocks" may use >> censored data, i.e. "Private Customer/Residence" >> in lieu of actual names and street addresses. >> >> -- >> >> With that said, I have a couple of questions to ask, based on >> potential rewrites that are brewing. >> >> First: Assuming a preference for /56 (based on PPML feedback) >> for the moment, which is the more >> preferential rewrite of the opening sentence of 6.5.5.1? >> >> >> a) Each static IPv6 assignment containing a /55 or more >> addresses shall be registered in the WHOIS directory via SWIP or a >> distributed service which meets the standards set forth in section 3.2. >> >> >> >> b) Each static IPv6 assignment containing a /55 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. >> >> >> Second: Given your specific choice of A or B, are you >> preferentially inclined to choose the provided bit-boundary, or "/48" >> >> Third: If none of these options are palatable, do you have a >> proposed approach? >> >> >> >> Thanks, >> >> 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. > > From bill at herrin.us Mon Jul 17 19:02:18 2017 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jul 2017 19:02:18 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> Message-ID: On Mon, Jul 17, 2017 at 6:40 PM, Paul McNary wrote: > I would prefer to give my residential users a /48 for the future but a /56 > Hi Paul, This is acceptable under current ARIN policy and would remain so under variant of the policy currently under discussion. > could work, just a pain. Again rDNS could be a problem. > > Do AS's use ARIN reverse DNS for size smaller than /48? > If rDNS will not work worldwide except with /48 advertising, > RDNS for IPv6 works best with allocations on nibble boundaries. /48, /52, /56, /60, /64, etc. It's only fractionally more work on non-nibble boundaries but not nearly as clean. Clean solutions are desirable. > I think that should be the SWIP boundary. > I know for a while some AS's required /32. > You may be confusing RDNS with BGP. For a while, a few Internet backbones refused to accept and route BGP prefixes longer than (less than) a /32. The last holdout gave up a couple years ago; standard practice is now /48. It's unlikely to change to anything longer than a /48, ever. IPv6 RDNS has always worked at any CIDR level and continues to work most cleanly at any nibble boundary. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Mon Jul 17 19:04:25 2017 From: bill at herrin.us (William Herrin) Date: Mon, 17 Jul 2017 19:04:25 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> Message-ID: On Mon, Jul 17, 2017 at 7:02 PM, William Herrin wrote: > On Mon, Jul 17, 2017 at 6:40 PM, Paul McNary wrote: > >> I would prefer to give my residential users a /48 for the future but a /56 >> > Hi Paul, > > This is acceptable under current ARIN policy and would remain so under > variant of the policy currently under discussion. > Any variant. Trying to say "any variant" there. If you like the idea of assigning /48s to your customers, the proposal on the table will not stop you from doing so. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Jul 17 19:36:13 2017 From: jcurran at arin.net (John Curran) Date: Mon, 17 Jul 2017 23:36:13 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> Albert - We?ll research into these questions and report back shortly. Thanks! /John > On 17 Jul 2017, at 2:53 PM, hostmaster at uneedus.com wrote: > > Just a couple of questions regarding the carrots and the sticks for the ARIN staff: > > Other than those who came back to change their initial /35 to a /32, how many ARIN customers have come back for another allocation of IPv6 space because they used the first one to the extent the rules require, which I think is 75% of /48 block assignments. > > And, how many customers have received a first allocation of IPv6? > > Divide, and I can find out what percentage came back for more. > > What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? > > Another bit of info I would like to know if possible: what percentage of customers with a v6 allocation has actually put any of their assignments into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every allocation should be there. > > The answers are useful to determine as far as the documenting the assignment for ARIN, how useful SWIP is for that purpose. > > I have a /48 from 2 upstreams. Only one is registered. The other ISP does not appear to have ANY SWIP entries, even though I have set up the network with static v6 for at least a dozen customers, each of which received a /48. > > Another "proxy" for to consider in deciding to SWIP or not might be the delegation of the reverse DNS for the allocated block. If there is a delegation, this is another way to find the technical contact other than SWIP if there is a problem. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Mon, 17 Jul 2017, David Farmer wrote: > >> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman wrote: >> >>> >>> Can you define voluntary? >>>> >>>> Is the voluntary choice to record a reassignment >>>> up to the USP? >>>> >>>> Or does the choice belong to the end-user? >>>> >>> >>> I think that's a business decision the two parties make together. I think >>> an ISP can choose to SWIP whatever it wants, and should do so with the >>> consent of the end-user. I think an end-user should be able to demand a >>> SWIP entry, and the ISP should generally comply. >>> >> >> And if the ISP doesn't comply with the user's demand, can one of their >> recourses be to appeal to ARIN? Obviously, in a healthy market another, >> and maybe more effective, option is to get another ISP. However, not all >> markets are healthy and too frequently users have only one realistic option >> for an ISP, especially in rural areas. >> >> I think it is important that if a user requests a SWIP from an ISP, and >> they not given the SWIP, this should be at very least a technical violation >> of ARIN policy. Is ARIN going to revoke an ISP's address space because of >> a single complaint from a user in this regard, of course not, but I would >> expect ARIN to intercede with an ISP on behalf of the user. However, if >> there are repeated issues, especially large numbers of them, and if there >> are other policy violations too, then I would expect harsher actions by >> ARIN eventually. >> >> Thanks >> >> -- >> =============================================== >> 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 >> =============================================== >> > _______________________________________________ > 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. From jcurran at arin.net Tue Jul 18 10:41:44 2017 From: jcurran at arin.net (John Curran) Date: Tue, 18 Jul 2017 14:41:44 +0000 Subject: [arin-ppml] IPv6 additional allocation and reassignment query (was: Re: Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6) In-Reply-To: References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <04638AD5-C6A7-43A4-B834-30F84B185946@arin.net> On 17 Jul 2017, at 2:53 PM, hostmaster at uneedus.com wrote: > > Just a couple of questions regarding the carrots and the sticks for the ARIN staff: > > Other than those who came back to change their initial /35 to a /32, how many ARIN customers have come back for another allocation of IPv6 space because they used the first one to the extent the rules require, which I think is 75% of /48 block assignments. > > And, how many customers have received a first allocation of IPv6? > > Divide, and I can find out what percentage came back for more. > > What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? > > Another bit of info I would like to know if possible: what percentage of customers with a v6 allocation has actually put any of their assignments into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every allocation should be there. > > The answers are useful to determine as far as the documenting the assignment for ARIN, how useful SWIP is for that purpose. Albert - As requested ? As far as ARIN staff can ascertain, no ISP/LIR has yet qualified for an additional allocation based on having used enough of their existing allocation to qualify for more. There have been some additional allocations under other circumstance, e.g. - Multiple Discrete Networks (I have a /32, I?m opening a second autonomous site, I need more) - ?Do-over? (I got a /32, I did my addressing plan, I now realize I need a /28) - Downstream ISP customers (I have a /32, I have a downstream ISP customer, therefore I need additional space so I can assign them a /32) Regarding reassignments: there are 3,346 IPv6 direct allocations. Of those, 283 (8.5%) have one or more reassignments. For comparison, there are 20,217 IPv4 direct allocations. Of those, 10,230 (50.7%) have one or more reassignments. May you find this information useful in your policy development efforts! /John John Curran President and CEO ARIN From hostmaster at uneedus.com Tue Jul 18 13:26:34 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 18 Jul 2017 13:26:34 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6) In-Reply-To: <04638AD5-C6A7-43A4-B834-30F84B185946@arin.net> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <04638AD5-C6A7-43A4-B834-30F84B185946@arin.net> Message-ID: It looks to me like as far as using SWIP as a tool to track IPv6 assignments so that we know if they have reached the 75% mark to ask for more, this is not happening. As reported, NOONE has come back to ARIN at this time for more IPv6 space because they have exhausted their initital allocation. Thus, the need to have SWIP in IPv6 for this purpose is zero. Since noone is coming back for more v6, looks like that stick for doing SWIP is not there. As far as recording IPv6 assignments in SWIP, it looks like that only 8.5% have recorded any assignments at all to date. Even though the current policy for the past 6 years says /64 or more, effectively 100% registration required, it does not look like it is being done. Since there is only 8.5% of the total with ANY amount of IPv6 recorded in SWIP, maybe this is the right time to propose that IPv6 SWIP requirements be eliminated in total. As far as policy proposals go, this would be done with the following language: Strike from the NRPM the following sections: 6.5.5.1, 6.5.5.2, 6.5.5.3, and 6.5.5.3.1. It does not in fact appear that IPv6 SWIP has ever been used to document for ARIN the need for future assignments, nor does the 8.5% of the reassignment records make that much difference to people using SWIP for other reasons. In fact, the community appears to ignored the current SWIP requirement that has been policy for quite a while. This language is the way to go if we want to get rid of SWIP for IPv6. Otherwise, if this is not acceptable, I still suggest option "b)" from yesterday, with the size of "/47". Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 18 Jul 2017, John Curran wrote: > Albert - > > As requested ? > > As far as ARIN staff can ascertain, no ISP/LIR has yet qualified for an additional allocation > based on having used enough of their existing allocation to qualify for more. There have > been some additional allocations under other circumstance, e.g. > > - Multiple Discrete Networks (I have a /32, I?m opening a second autonomous site, I need more) > - ?Do-over? (I got a /32, I did my addressing plan, I now realize I need a /28) > - Downstream ISP customers (I have a /32, I have a downstream ISP customer, > therefore I need additional space so I can assign them a /32) > > Regarding reassignments: there are 3,346 IPv6 direct allocations. Of those, 283 (8.5%) have one > or more reassignments. For comparison, there are 20,217 IPv4 direct allocations. Of those, 10,230 > (50.7%) have one or more reassignments. > > May you find this information useful in your policy development efforts! > /John > > John Curran > President and CEO > ARIN > > > > From owen at delong.com Tue Jul 18 16:23:25 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 18 Jul 2017 13:23:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> Message-ID: > On Jul 17, 2017, at 16:36 , John Curran wrote: > > Albert - > > We?ll research into these questions and report back shortly. > > Thanks! > /John > >> On 17 Jul 2017, at 2:53 PM, hostmaster at uneedus.com wrote: >> >> Just a couple of questions regarding the carrots and the sticks for the ARIN staff: >> >> Other than those who came back to change their initial /35 to a /32, how many ARIN customers have come back for another allocation of IPv6 space because they used the first one to the extent the rules require, which I think is 75% of /48 block assignments. Not many?. Yet. I know a few years ago, I filed the first such application (or at least so said RSHD at the time) on behalf of my employer at the time (HE) which requested (and received) a subsequent /24 to augment their existing /32 which was, in fact, more than 75% utilized. >> And, how many customers have received a first allocation of IPv6? >> >> Divide, and I can find out what percentage came back for more. The problem with this theory is that IPv6 is just getting started and the vast majority of ARIN customers that have received an initial IPv6 allocation or assignment haven?t yet achieved full IPv6 deployment even to the point of parity with their IPv4 deployment. As such, measurements to date will be badly skewed to the low side of future reality. >> What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? Your gut is definitely correct to date. However, prior performance does not predict future results. It?s true that a lot fewer organizations are likely to come back for additional IPv6 blocks and all will certainly come back less frequently than in IPv4. Nearly nobody is probably true today. It will probably remain less than ?most? for the foreseeable future, but I don?t think ?nearly nobody? is a permanent state. >> Another bit of info I would like to know if possible: what percentage of customers with a v6 allocation has actually put any of their assignments into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every allocation should be there. Again, this isn?t necessarily going to yield accurate results. Many providers use RWHOIS as an alternative to SWIP. Many end users receive a /48 and it is directly registered by ARIN, so nothing to SWIP. There are also other situations (dynamic assignments, etc.) that are legitimately unlikely to result in SWIP. >> The answers are useful to determine as far as the documenting the assignment for ARIN, how useful SWIP is for that purpose. >> >> I have a /48 from 2 upstreams. Only one is registered. The other ISP does not appear to have ANY SWIP entries, even though I have set up the network with static v6 for at least a dozen customers, each of which received a /48. If that is the case, then that ISP is, indeed, in violation of ARIN policy and a fraud/abuse report to ARIN would not be out of order. >> Another "proxy" for to consider in deciding to SWIP or not might be the delegation of the reverse DNS for the allocated block. If there is a delegation, this is another way to find the technical contact other than SWIP if there is a problem. Not really reliable. In reality, there?s only one POC in the SOA and most providers in my experience populate that POC entry with meaningless unusable addresses. Owen >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Mon, 17 Jul 2017, David Farmer wrote: >> >>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman wrote: >>> >>>> >>>> Can you define voluntary? >>>>> >>>>> Is the voluntary choice to record a reassignment >>>>> up to the USP? >>>>> >>>>> Or does the choice belong to the end-user? >>>>> >>>> >>>> I think that's a business decision the two parties make together. I think >>>> an ISP can choose to SWIP whatever it wants, and should do so with the >>>> consent of the end-user. I think an end-user should be able to demand a >>>> SWIP entry, and the ISP should generally comply. >>>> >>> >>> And if the ISP doesn't comply with the user's demand, can one of their >>> recourses be to appeal to ARIN? Obviously, in a healthy market another, >>> and maybe more effective, option is to get another ISP. However, not all >>> markets are healthy and too frequently users have only one realistic option >>> for an ISP, especially in rural areas. >>> >>> I think it is important that if a user requests a SWIP from an ISP, and >>> they not given the SWIP, this should be at very least a technical violation >>> of ARIN policy. Is ARIN going to revoke an ISP's address space because of >>> a single complaint from a user in this regard, of course not, but I would >>> expect ARIN to intercede with an ISP on behalf of the user. However, if >>> there are repeated issues, especially large numbers of them, and if there >>> are other policy violations too, then I would expect harsher actions by >>> ARIN eventually. >>> >>> Thanks >>> >>> -- >>> =============================================== >>> 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 >>> =============================================== >>> >> _______________________________________________ >> 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. From bjones at vt.edu Tue Jul 18 17:13:36 2017 From: bjones at vt.edu (Brian Jones) Date: Tue, 18 Jul 2017 21:13:36 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> Message-ID: On Tue, Jul 18, 2017 at 4:24 PM Owen DeLong wrote: > > > On Jul 17, 2017, at 16:36 , John Curran wrote: > > > > Albert - > > > > We?ll research into these questions and report back shortly. > > > > Thanks! > > /John > > > >> On 17 Jul 2017, at 2:53 PM, hostmaster at uneedus.com wrote: > >> > >> Just a couple of questions regarding the carrots and the sticks for the > ARIN staff: > >> > >> Other than those who came back to change their initial /35 to a /32, > how many ARIN customers have come back for another allocation of IPv6 space > because they used the first one to the extent the rules require, which I > think is 75% of /48 block assignments. > > Not many?. Yet. I know a few years ago, I filed the first such application > (or at least so said RSHD at the time) on behalf of my employer at the time > (HE) which requested (and received) a subsequent /24 to augment their > existing /32 which was, in fact, more than 75% utilized. > > >> And, how many customers have received a first allocation of IPv6? > >> > >> Divide, and I can find out what percentage came back for more. > > The problem with this theory is that IPv6 is just getting started and the > vast majority of ARIN customers that have received an initial IPv6 > allocation or assignment haven?t yet achieved full IPv6 deployment even to > the point of parity with their IPv4 deployment. As such, measurements to > date will be badly skewed to the low side of future reality. > +1 Even heavy users of IPv6 for years such as my organization are just now realizing that we wished we had opted for for a /27 instead of a /32 now. Even though we are mostly dual stacked everywhere we are just now seeing the potential of being able to allocate IPv6 addressing in a more meaningful way, and with all the research taking place with robots, drones, driverless vehicles, bio-engineering, aerospace, etc? etc? we really may have to go back to the well. > >> What I would like to know is my gut feeling correct, which is that > after receiving an allocation of IPv6, nearly nobody ever returns to the > well for more, or at least not like it was back in the IPv4 days when ARIN > had IPv4 address space to allocate, and thus there are no sticks? > > Your gut is definitely correct to date. However, prior performance does > not predict future results. It?s true that a lot fewer organizations are > likely to come back for additional IPv6 blocks and all will certainly come > back less frequently than in IPv4. Nearly nobody is probably true today. It > will probably remain less than ?most? for the foreseeable future, but I > don?t think ?nearly nobody? is a permanent state. > > >> Another bit of info I would like to know if possible: what percentage > of customers with a v6 allocation has actually put any of their assignments > into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every > allocation should be there. > > We do have our IPv6 assignment in SWIP, not sure what percentage of folks do, but it is useful information. > Again, this isn?t necessarily going to yield accurate results. Many > providers use RWHOIS as an alternative to SWIP. Many end users receive a > /48 and it is directly registered by ARIN, so nothing to SWIP. There are > also other situations (dynamic assignments, etc.) that are legitimately > unlikely to result in SWIP. > > >> The answers are useful to determine as far as the documenting the > assignment for ARIN, how useful SWIP is for that purpose. > >> > >> I have a /48 from 2 upstreams. Only one is registered. The other ISP > does not appear to have ANY SWIP entries, even though I have set up the > network with static v6 for at least a dozen customers, each of which > received a /48. > > If that is the case, then that ISP is, indeed, in violation of ARIN policy > and a fraud/abuse report to ARIN would not be out of order. > > >> Another "proxy" for to consider in deciding to SWIP or not might be the > delegation of the reverse DNS for the allocated block. If there is a > delegation, this is another way to find the technical contact other than > SWIP if there is a problem. > > Not really reliable. In reality, there?s only one POC in the SOA and most > providers in my experience populate that POC entry with meaningless > unusable addresses. > > Owen > > >> > >> Albert Erdmann > >> Network Administrator > >> Paradise On Line Inc. > >> > >> > >> On Mon, 17 Jul 2017, David Farmer wrote: > >> > >>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman > wrote: > >>> > >>>> > >>>> Can you define voluntary? > >>>>> > >>>>> Is the voluntary choice to record a reassignment > >>>>> up to the USP? > >>>>> > >>>>> Or does the choice belong to the end-user? > >>>>> > >>>> > >>>> I think that's a business decision the two parties make together. I > think > >>>> an ISP can choose to SWIP whatever it wants, and should do so with the > >>>> consent of the end-user. I think an end-user should be able to demand > a > >>>> SWIP entry, and the ISP should generally comply. > >>>> > >>> > >>> And if the ISP doesn't comply with the user's demand, can one of their > >>> recourses be to appeal to ARIN? Obviously, in a healthy market > another, > >>> and maybe more effective, option is to get another ISP. However, not > all > >>> markets are healthy and too frequently users have only one realistic > option > >>> for an ISP, especially in rural areas. > >>> > >>> I think it is important that if a user requests a SWIP from an ISP, and > >>> they not given the SWIP, this should be at very least a technical > violation > >>> of ARIN policy. Is ARIN going to revoke an ISP's address space > because of > >>> a single complaint from a user in this regard, of course not, but I > would > >>> expect ARIN to intercede with an ISP on behalf of the user. However, > if > >>> there are repeated issues, especially large numbers of them, and if > there > >>> are other policy violations too, then I would expect harsher actions by > >>> ARIN eventually. > >>> > >>> Thanks > >>> > >>> -- > >>> =============================================== > >>> 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. > > > > _______________________________________________ > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Tue Jul 18 20:50:00 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 18 Jul 2017 17:50:00 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM In-Reply-To: <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> References: <59495DF4.8010504@arin.net> <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> Message-ID: If there is general community support for pruning back section 4 now that run-out has happened and section 8 contains the transfer requirements. I can pull out my previous drafts and revise and present those as alternatives to this specific draft text. Andrew On 7/17/2017 12:32 PM, Chris Woodfield wrote: > Hello, > > Reviving the thread on Draft Policy ARIN-2017-7. So far, the community > response to the proposal in its current state appears to be > universally negative. > > Having read the comments on this proposal, it could be plausible that > an alternate solution to the problem statement could be that in lieu > of retiring most of the section, specific sections could be > substantially simplified by pointing to the currently-duplicated > clauses in Section 6, eliminating the need to manually keep these > sections in sync by applying similar policy to both where warranted > (in particular, the sections around utilization justification seem > like the best candidates). > > Does the community feel that this is a viable route to explore, which > would simplify Section 4 while keeping the necessary relevant > sections, in lieu of the original proposal? > > Thanks, > > -Chris > >> On Jun 21, 2017, at 12:16 PM, Austin Murkland >> > wrote: >> >> I do not support this policy for the reasons Kevin and Albert >> outlined. This seems a bit premature. >> >> Thanks, >> >> Austin Murkland >> >> On Tue, Jun 20, 2017 at 1:40 PM, ARIN > > wrote: >> >> On 15 June 2017, the ARIN Advisory Council (AC) advanced >> "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft >> Policy status. >> >> Draft Policy ARIN-2017-7 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_7.html >> >> >> 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-7: Retire Obsolete Section 4 from the NRPM >> >> Problem Statement: >> >> Since IPv4 free pool exhaustion, policy focus has shifted to >> transfers. The community elected, instead of revamping and >> modernizing section 4 in light of this to, instead, recreate the >> relevant parts of section 4 in section 8.5. As a result, section >> 4 is generally obsolete and can be mostly retired. Since some >> small amounts of space do occasionally recreate the free pool, a >> mechanism for addressing this must remain and therefore a much >> reduced section 4 is proposed here instead of outright retirement. >> >> Policy statement: >> >> Replace section 4 of the NRPM with the following: >> >> 4. IPv4 >> >> 4.1 IPv4 Requests >> >> 4.1.1 Any new requests for IPv4 addresses allocated or assigned >> by ARIN shall be evaluated based on the criteria for transfer >> recipients contained in section 8.5. >> >> 4.1.2 Any approved requests which cannot be met from the ARIN >> free pool shall be handled according to section 4.2. >> >> 4.2 Unmet requests >> >> In the event that ARIN does not have a contiguous block of >> addresses of sufficient size to fulfill a qualified request, ARIN >> will provide the requesting organization with the option to >> specify the smallest block size they'd be willing to accept, >> equal to or larger than the applicable minimum size specified >> elsewhere in ARIN policy. If such a smaller block is available, >> ARIN will fulfill the request with the largest single block >> available that fulfills the request. If no such block is >> available, the organization will be provided the option to be >> placed on a waiting list of pre-qualified recipients, listing >> both the block size qualified for and the smallest block size >> acceptable. >> >> Repeated requests are not allowed: an organization may only >> receive one allocation, assignment, or transfer every 3 months, >> but ARIN, at its sole discretion, may waive this requirement if >> the requester can document a change in circumstances since their >> last request that could not have been reasonably foreseen at the >> time of the original request, and which now justifies additional >> space. >> >> Qualified requesters whose request cannot be immediately met will >> also be advised of the availability of the transfer mechanism in >> section 8.3 as an alternative mechanism to obtain IPv4 addresses. >> >> 4.2.1. Waiting list >> >> The position of each qualified request on the waiting list will >> be determined by the date it was approved. Each organization may >> have one approved request on the waiting list at a time. >> >> 4.2.2. Fulfilling unmet needs >> >> As address blocks become available for allocation, ARIN will >> fulfill requests on a first-approved basis, subject to the size >> of each available address block and a timely re-validation of the >> original request. Requests will not be partially filled. Any >> requests met through a transfer will be considered fulfilled and >> removed from the waiting list. >> >> Comments: >> >> a. Timetable for implementation: Immediate >> _______________________________________________ >> 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. > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joelja at bogus.com Tue Jul 18 23:14:38 2017 From: joelja at bogus.com (joel jaeggli) Date: Wed, 19 Jul 2017 05:14:38 +0200 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> Message-ID: On 7/18/17 22:23, Owen DeLong wrote: > >> On Jul 17, 2017, at 16:36 , John Curran wrote: >>> What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? > > Your gut is definitely correct to date. However, prior performance does not predict future results. It?s true that a lot fewer>organizations are likely to come back for additional IPv6 blocks and all will certainly come back less frequently than in IPv4.>Nearly nobody is probably true today. It will probably remain less than ?most? for the foreseeable future, but I don?t think >?nearly nobody? is a permanent state. A fair number of initial allocations were way too small. e.g. pre 2004 LIR/ISP assignments. Failure of imagination seems like a common trope for direct/ciritical assignments which makes returning to the well inevitable. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: OpenPGP digital signature URL: From arin at reg.dd.org Wed Jul 19 08:51:39 2017 From: arin at reg.dd.org (Dave Lawrence) Date: Wed, 19 Jul 2017 08:51:39 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> Message-ID: <22895.21979.950697.692774@gro.dd.org> Paul McNary writes: > If rDNS will not work worldwide except with /48 advertising, For the record there's no technical limitation in the DNS on making reverse DNS work for anything from /1 to /128. It's all policy and conventions. From hostmaster at uneedus.com Wed Jul 19 10:06:22 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 19 Jul 2017 10:06:22 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <8FC293DF-ABC7-4BEE-A3B0-2CFA8042C09A@arin.net> Message-ID: For the record, I would be happy if this policy stopped at changing the 100% SWIP requirement for v6 assignments to allowing /56 and smaller to not have to SWIP. However, if the community agrees, I have no issues with taking additional actions in this draft, up to and including elimination of v6 SWIP. Of course, as with any discussion of SWIP, there have been suggestions that SWIP in v6 has outlived its usefulness in IP address management and should be eliminated, and others that have suggested language that limited the use of V6 SWIP to only those networks that are independently routed from the main block. I asked for some facts regarding the actual amounts of assignments, and if anyone had reached the 75% assignment level and had returned for more. I found the reassignment rate is 8.5%, and that noone has returned for more after exhausting their initial allocation of IPv6. I suggest that nearly everyone who has a allocation of v6 is using it in some form or another. The people with their head in the sand, and thinking v4 will be fine forever have likely not even have obtained a v6 allocation and are not counted in these stats. The proposal "b)" from the other day with the language requiring SWIP for all independently routable blocks of any size, and all blocks /47 or larger is the best idea between the "leave it alone" camp on one side, and the "Dump v6 SWIP" camp on the other. ARIN staff has already identified possible database issues if the current policy of registering every /64 or more is actually done. The only thing that has prevented this issue is the low 8.5% registration rate identified during my information request. For small networks, which according to the standards may be up to a /48 of assignment, generally unless they have their own routing, any abuse issues are going to be addressed to the holder of the main block anyway, so absence of SWIP does not matter. For those who have their own routes, SWIP is needed and this proposal states that independently routed blocks must appear in SWIP. While I am not opposed to v6 SWIP elimination, those who state this is too soon do have a point. The Proposal "b)" is a good middle ground, retaining SWIP assignment records for those networks that need it because of independent routing, and eliminating the requirement for those networks up to a /48 that do not have independent routing. This also reduces the number of required SWIP records, taking pressure of unneeded growth of the SWIP database. In the discussion of the CPNI rules of the FCC, and residential privacy provided for in the NRPM, I would like to suggest that ISP's also be able to withhold the City State and Zip Fields in SWIP reporting. This is especially true if a 9 digit zip code is used, as these can be assigned to a single addresss, totally unmasking the residental customer. All 3 elements are part of a complete address, which has been identified as protected CPNI by the FCC, and we should be permitted to do this if our lawyer so advises, without fear of ARIN sanctions. Also discussed was limitations of using rDNS in abuse tracking. I admit that the SOA record often has invalid data. If it does, I use the contacts for the Domain Registration associated with the rDNS assigned to the IP address. This often gets me a contact, even when SWIP has no data. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 18 Jul 2017, Owen DeLong wrote: > >> On Jul 17, 2017, at 16:36 , John Curran wrote: >> >> Albert - >> >> We?ll research into these questions and report back shortly. >> >> Thanks! >> /John >> >>> On 17 Jul 2017, at 2:53 PM, hostmaster at uneedus.com wrote: >>> >>> Just a couple of questions regarding the carrots and the sticks for the ARIN staff: >>> >>> Other than those who came back to change their initial /35 to a /32, how many ARIN customers have come back for another allocation of IPv6 space because they used the first one to the extent the rules require, which I think is 75% of /48 block assignments. > > Not many?. Yet. I know a few years ago, I filed the first such application (or at least so said RSHD at the time) on behalf of my employer at the time (HE) which requested (and received) a subsequent /24 to augment their existing /32 which was, in fact, more than 75% utilized. > >>> And, how many customers have received a first allocation of IPv6? >>> >>> Divide, and I can find out what percentage came back for more. > > The problem with this theory is that IPv6 is just getting started and the vast majority of ARIN customers that have received an initial IPv6 allocation or assignment haven?t yet achieved full IPv6 deployment even to the point of parity with their IPv4 deployment. As such, measurements to date will be badly skewed to the low side of future reality. > >>> What I would like to know is my gut feeling correct, which is that after receiving an allocation of IPv6, nearly nobody ever returns to the well for more, or at least not like it was back in the IPv4 days when ARIN had IPv4 address space to allocate, and thus there are no sticks? > > Your gut is definitely correct to date. However, prior performance does not predict future results. It?s true that a lot fewer organizations are likely to come back for additional IPv6 blocks and all will certainly come back less frequently than in IPv4. Nearly nobody is probably true today. It will probably remain less than ?most? for the foreseeable future, but I don?t think ?nearly nobody? is a permanent state. > >>> Another bit of info I would like to know if possible: what percentage of customers with a v6 allocation has actually put any of their assignments into SWIP? Since the current policy for SWIP in IPv6 is /64 or more, every allocation should be there. > > Again, this isn?t necessarily going to yield accurate results. Many providers use RWHOIS as an alternative to SWIP. Many end users receive a /48 and it is directly registered by ARIN, so nothing to SWIP. There are also other situations (dynamic assignments, etc.) that are legitimately unlikely to result in SWIP. > >>> The answers are useful to determine as far as the documenting the assignment for ARIN, how useful SWIP is for that purpose. >>> >>> I have a /48 from 2 upstreams. Only one is registered. The other ISP does not appear to have ANY SWIP entries, even though I have set up the network with static v6 for at least a dozen customers, each of which received a /48. > > If that is the case, then that ISP is, indeed, in violation of ARIN policy and a fraud/abuse report to ARIN would not be out of order. > >>> Another "proxy" for to consider in deciding to SWIP or not might be the delegation of the reverse DNS for the allocated block. If there is a delegation, this is another way to find the technical contact other than SWIP if there is a problem. > > Not really reliable. In reality, there?s only one POC in the SOA and most providers in my experience populate that POC entry with meaningless unusable addresses. > > Owen > >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> On Mon, 17 Jul 2017, David Farmer wrote: >>> >>>> On Mon, Jul 17, 2017 at 2:11 PM, David R Huberman wrote: >>>> >>>>> >>>>> Can you define voluntary? >>>>>> >>>>>> Is the voluntary choice to record a reassignment >>>>>> up to the USP? >>>>>> >>>>>> Or does the choice belong to the end-user? >>>>>> >>>>> >>>>> I think that's a business decision the two parties make together. I think >>>>> an ISP can choose to SWIP whatever it wants, and should do so with the >>>>> consent of the end-user. I think an end-user should be able to demand a >>>>> SWIP entry, and the ISP should generally comply. >>>>> >>>> >>>> And if the ISP doesn't comply with the user's demand, can one of their >>>> recourses be to appeal to ARIN? Obviously, in a healthy market another, >>>> and maybe more effective, option is to get another ISP. However, not all >>>> markets are healthy and too frequently users have only one realistic option >>>> for an ISP, especially in rural areas. >>>> >>>> I think it is important that if a user requests a SWIP from an ISP, and >>>> they not given the SWIP, this should be at very least a technical violation >>>> of ARIN policy. Is ARIN going to revoke an ISP's address space because of >>>> a single complaint from a user in this regard, of course not, but I would >>>> expect ARIN to intercede with an ISP on behalf of the user. However, if >>>> there are repeated issues, especially large numbers of them, and if there >>>> are other policy violations too, then I would expect harsher actions by >>>> ARIN eventually. >>>> >>>> Thanks >>>> >>>> -- >>>> =============================================== >>>> 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 >>>> =============================================== >>>> >>> _______________________________________________ >>> 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. > > From theone at uneedus.com Wed Jul 12 04:20:27 2017 From: theone at uneedus.com (theone at uneedus.com) Date: Wed, 12 Jul 2017 04:20:27 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> Message-ID: I would like to give an example of why the current /64 or more rule for IPv6 SWIP vs IPv4 is an issue for a project I am working on: I am working on a project to enable public IPv6 on Public Transit busses. Currently we have a public V4 address assigned by the winner of a State Government Contract with a major wireless provider used for each bus in the fleet, which is in excess of 1000 busses. Originally we used this connection only for administrative use, such as communicating the real time location of each bus back to headquarters and access to cameras and reporting in an emergency. In the last few months, we added an additional RFC1918 IPv4 private address subnet so that a wireless access point for public wifi is available on each bus. In order to address the administrative equipment from headquarters, we must have a static address to connect to. Because it is a State Government contract, the major wireless provider still has to provide us public, static IPv4 addresses until the end of this contract, which is Sept 30, 2018. This major provider has publiclly announced that they will no longer provide Static IPv4 addresses to anyone, and we have been told they will not bid on the next contract if that contract would require an option to assign static v4 addresses like the current contract, as they are leasing the IPv4 addresses we are using. We have been told if we want Static assignments, they now must be only IPv6, and they will provide up to a /56 for each bus out of a /48 of their space assigned to all our busses. Thus, there is a plan to put the administrative parts of the busses onto IPv6 before the end of the contract. We wont care if the carrier v4 address is static, public, or even CGnat, as it would then only be only used for the public v4 wifi. We might also consider a PI v6 allocation from ARIN if they will route it to us. This would keep us from having to renumber if the State Contract provider changes, and a /48 of space would be plenty for all v6 use. Here is the SWIP issue: The major provider according to the current rules must SWIP each static "Serving site"(NRPM 2.14), which in this case is a transit bus. Each bus is its own account with the wireless provider, and will have its own static IPv6 network and IPv4 address assigned. NRPM 2.12 requires each SWIP entry must contain Street Address, City, State, and Zip Code. How can I give a Street Address for a mobile serving site as required by NPRM 2.12? Each bus covers 200-300 miles a day, and about 1/2 do not return to our central location during any portion of their daily trips. I am sure that the abuse address for the SWIP will attract attention because of public wifi on each bus, and our intent to enable v6 connections on each "Serving Site" (Transit Bus) including the public wifi. If the current proposal at more than a /60, or a greater amount such as more than a /56 is adopted, the wireless provider no longer has to SWIP each site (Transit Bus) just like v4. This would allow us to avoid having to SWIP each "Serving Site" as the current IPv6 rules would require and keep us legal with the policy manual. If the community comes out against relaxing the IPv6 SWIP rules, my only other choices are to hope the wireless provider will ignore the NRPM, or write another proposal to add language to 2.12 to allow mobile "Serving Sites" to be registered to a central location to avoid the street address and city problem with mobile "Serving Sites". The wireless provider is unlikely to allow all the busses to be SWIP'ed to the Central site because they would be the one trying to explain to ARIN why 1000 networks are all registered at the same location. This was never an issue with IPv4, as each bus has only one IPv4 address, which did not trigger any SWIP requirement. This example also shows how the different treatment of v4 and v6 affects small users of v6. I Would love to hear some input as to the issue of dealing with "Serving Sites" that are mobile (like Transit Busses), or do not have a street address assigned, like some of the rural WISP sites I work with including my own home. If I decided to put a non residental circuit there that includes any amount of IPv6, it would not be able to be SWIP'ed as I have no Street Address and the rules do not allow the field to be left blank. What then??? Albert Erdmann Network Administrator Paradise On Line Inc. From scottleibrand at gmail.com Wed Jul 19 14:12:09 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 19 Jul 2017 11:12:09 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> Message-ID: As I understand it, if the ISP assigned you a /48 and individually routed the /64s for you, they would only have to create a single SWIP entry for the /48, and the street address of your central location (or your administrative HQ, if different) would be perfectly appropriate for that SWIP. I agree that eliminating the need to SWIP /64s and residential /56s would be good, and still support the general idea of this proposal (and most of the variations that have been proposed thus far). However, I think this use case does highlight the need to make sure that we *do* consider requiring SWIP of /48 aggregates like the one your ISP is assigning you, even if they're routing the pieces of that aggregate independently to different "sites". -Scott On Wed, Jul 12, 2017 at 1:20 AM, wrote: > I would like to give an example of why the current /64 or more rule for > IPv6 SWIP vs IPv4 is an issue for a project I am working on: > > I am working on a project to enable public IPv6 on Public Transit busses. > Currently we have a public V4 address assigned by the winner of a State > Government Contract with a major wireless provider used for each bus in the > fleet, which is in excess of 1000 busses. Originally we used this > connection only for administrative use, such as communicating the real time > location of each bus back to headquarters and access to cameras and > reporting in an emergency. In the last few months, we added an additional > RFC1918 IPv4 private address subnet so that a wireless access point for > public wifi is available on each bus. In order to address the > administrative equipment from headquarters, we must have a static address > to connect to. > > Because it is a State Government contract, the major wireless provider > still has to provide us public, static IPv4 addresses until the end of this > contract, which is Sept 30, 2018. This major provider has publiclly > announced that they will no longer provide Static IPv4 addresses to anyone, > and we have been told they will not bid on the next contract if that > contract would require an option to assign static v4 addresses like the > current contract, as they are leasing the IPv4 addresses we are using. We > have been told if we want Static assignments, they now must be only IPv6, > and they will provide up to a /56 for each bus out of a /48 of their space > assigned to all our busses. > > Thus, there is a plan to put the administrative parts of the busses onto > IPv6 before the end of the contract. We wont care if the carrier v4 address > is static, public, or even CGnat, as it would then only be only used for > the public v4 wifi. We might also consider a PI v6 allocation from ARIN if > they will route it to us. This would keep us from having to renumber if > the State Contract provider changes, and a /48 of space would be plenty for > all v6 use. > > Here is the SWIP issue: > > The major provider according to the current rules must SWIP each static > "Serving site"(NRPM 2.14), which in this case is a transit bus. Each bus > is its own account with the wireless provider, and will have its own static > IPv6 network and IPv4 address assigned. > > NRPM 2.12 requires each SWIP entry must contain Street Address, City, > State, and Zip Code. How can I give a Street Address for a mobile serving > site as required by NPRM 2.12? Each bus covers 200-300 miles a day, and > about 1/2 do not return to our central location during any portion of their > daily trips. I am sure that the abuse address for the SWIP will attract > attention because of public wifi on each bus, and our intent to enable v6 > connections on each "Serving Site" (Transit Bus) including the public wifi. > > If the current proposal at more than a /60, or a greater amount such as > more than a /56 is adopted, the wireless provider no longer has to SWIP > each site (Transit Bus) just like v4. This would allow us to avoid having > to SWIP each "Serving Site" as the current IPv6 rules would require and > keep us legal with the policy manual. > > If the community comes out against relaxing the IPv6 SWIP rules, my only > other choices are to hope the wireless provider will ignore the NRPM, or > write another proposal to add language to 2.12 to allow mobile "Serving > Sites" to be registered to a central location to avoid the street address > and city problem with mobile "Serving Sites". The wireless provider is > unlikely to allow all the busses to be SWIP'ed to the Central site because > they would be the one trying to explain to ARIN why 1000 networks are all > registered at the same location. > > This was never an issue with IPv4, as each bus has only one IPv4 address, > which did not trigger any SWIP requirement. This example also shows how > the different treatment of v4 and v6 affects small users of v6. > > I Would love to hear some input as to the issue of dealing with "Serving > Sites" that are mobile (like Transit Busses), or do not have a street > address assigned, like some of the rural WISP sites I work with including > my own home. If I decided to put a non residental circuit there that > includes any amount of IPv6, it would not be able to be SWIP'ed as I have > no Street Address and the rules do not allow the field to be left blank. > What then??? > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Jul 19 14:28:38 2017 From: jcurran at arin.net (John Curran) Date: Wed, 19 Jul 2017 18:28:38 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> Message-ID: <73F933EE-E047-4D8C-8E8C-D821BC4E80B0@arin.net> On 19 Jul 2017, at 11:12 AM, Scott Leibrand wrote: > > As I understand it, if the ISP assigned you a /48 and individually routed the /64s for you, they would only have to create a single SWIP entry for the /48, and the street address of your central location (or your administrative HQ, if different) would be perfectly appropriate for that SWIP. FYI - Present NRPM policy regarding residential privacy would provide for the reassignment to show the city, state, and postal code of the assignee (omitting the street address) To the extent that one is aware of a detailed postal code which has a unique association with a single location, it is appropriate to use a less specific one to comply with the intent of the policy. Thanks, /John John Curran President and CEO ARIN From michael at linuxmagic.com Wed Jul 19 18:03:02 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 19 Jul 2017 15:03:02 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: On 17-07-17 10:54 AM, David R Huberman wrote: > AT&T Internet Services SBCIS-SIS80-1005 (NET-69-0-0-0-1) 69.0.0.0 - > 69.0.127.255 > THE MEDICINE SHOPPE SBC069000000000030204 (NET-69-0-0-0-2) 69.0.0.0 - > 69.0.0.7 > > When you lookup the specific /29, you get: > > CustName: THE MEDICINE SHOPPE > Address: 310 ORANGE ST > City: NEW HAVEN > StateProv: CT > PostalCode: 06510 > Country: US It depends, who do you want to be authorative for contact information on issues related to that network. If ATT wants to deal with every issue related to every IP address in that /17, no need to do SWIP, however if you want the Medicine Shoppe to be be able to authoratively speak for the usage of that /29, you better give them SWIP/rwhois. It also is a 'boundary' condition, eg can speak to the operations of the /29, but should not have to worry about activity from surrounding blocks.. Now, in terms of an ISP providing IP allocations to customers, it may not have to be SWIP'ed on the IP boundary, as for instance a /21 may ALL be dynamic IP Addresses for customers, which can be SWIP'ed as such, and the holder of the SWIP (poc) will be responsible for the combined behavior of the pool. However, if a statically assigned IP to a business customer, it might want to be SWIP'ed so that the specific customer can set a 'boundary' on behavior, eg my IP is not like the rest around me, and I will be responsible for my IP's activity. Aside from the concept's of SWIP helping 'justify' usage for resources, (and there is a slippery slope, if you don't care about justification for IPv6 but you do for IPv4 in terms of legal contests), the idea of setting a control boundary via SWIP and/or rwhois is a very important concept. As such, I would suggest making this concept a basis for when SWIP 'might' be used, but not enforced.. eg. SWIP should not be needed at any lower level than the boundary of responsibility. An ISP could set that boundary for one household, or one business, IF that is the boundary of responsibility, and the household or business 'chooses' to be the responsible party for that boundary, and in that case they should expect that their POC information be publicized. It would be better if the concept of 'boundaries' be enshrined, instead of the actual number of IP (v6 or otherwise) or segments.. In some cases in the future it 'could' be a boundary be specified as low as a /56, but in reality, the segment would be different depending on the use case. If you want to enshrine 'use cases' into the proposal, then you might come to agreement for a specific use case, when/how to SWIP it. Also, remember, 'rwhois' is available at a lower granularity than SWIP might require as well.. -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From hostmaster at uneedus.com Wed Jul 19 19:36:38 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 19 Jul 2017 19:36:38 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <73F933EE-E047-4D8C-8E8C-D821BC4E80B0@arin.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <73F933EE-E047-4D8C-8E8C-D821BC4E80B0@arin.net> Message-ID: As someone that once worked with certified zip code matching software development, I suggest that only a 5 digit code be used for SWIP. Otherwise you are giving away in that 9 digit zip code enough information to locate the city block with your customer, or even the exact address. This is because each full 9 digit code pinpoints the exact block, and also which side of the block, each block by default has 2 zip+4 codes. Each side has on average 9 delivery points, but can go as high as 50 or as low as one. Businesses and residences that get more than 10 pieces of mail on average per day are assigned their own code that is unique to their address. Multi unit places and places with cluster boxes get one or more codes for each cluster box. Like looking up addresses in Whois with multiple matches returned, the software assigns the most specific Zip +4 code if possible, instead of the general code for the side of the block. While thinking about it John, there was some discussion over using the main facility address in a single SWIP for an entire block that contained many sites. Is this allowed? The reason I ask is one of the projects I have coming up involves placing 2 IPv6 blocks (one public, one administrative) on a large group (over 500) transit busses. The Major Wireless provider the State has a contract with to provide connectivity to the busses will no longer provide static v4 addresses when the current contract expires in 2018, and the current wifi and administrative network currently operates over a single static IPv4 per bus. If we want static addresses, they insist that we go to v6. According to the current rules, we technically are supposed to SWIP each site, in this case a bus, complete with a Street Address. Busses are mobile so this cannot be done. We could use the Bus Number instead of the address, or if allowed we could have the provider SWIP the entire v6 block for all busses in one entry. Any "proper" suggestions for dealing with this? Of course I am hoping my proposal is adopted, and that each bus could receive a block small enough that SWIP is not required for each bus. A /60 in each bus would allow a /48 to serve a lot of bus growth.... Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 19 Jul 2017, John Curran wrote: > On 19 Jul 2017, at 11:12 AM, Scott Leibrand wrote: >> >> As I understand it, if the ISP assigned you a /48 and individually >> routed the /64s for you, they would only have to create a single SWIP >> entry for the /48, and the street address of your central location (or >> your administrative HQ, if different) would be perfectly appropriate >> for that SWIP. > > FYI - Present NRPM policy regarding residential privacy would provide for > the reassignment to show the city, state, and postal code of the assignee > (omitting the street address) > > To the extent that one is aware of a detailed postal code which has a unique > association with a single location, it is appropriate to use a less specific one > to comply with the intent of the policy. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > 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. > From jcurran at arin.net Wed Jul 19 21:01:42 2017 From: jcurran at arin.net (John Curran) Date: Thu, 20 Jul 2017 01:01:42 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <73F933EE-E047-4D8C-8E8C-D821BC4E80B0@arin.net> Message-ID: On 19 Jul 2017, at 4:36 PM, hostmaster at uneedus.com wrote: > > While thinking about it John, there was some discussion over using the main facility address in a single SWIP for an entire block that contained many sites. Is this allowed? Albert - Alas, the only ?advice? that I can provide will be based upon the adopted policy in the NRPM and accompanying policy discussion in PPML during the policy development process. As best as I can discern, the intent of the current policy is to provide that address blocks of ?significant" size which are reassigned will have accurate technical and abuse contacts, while also respecting the need for residential privacy in the case where the street address or postal code would be allow for personal identification. To the extent that ISPs are attempting in good faith to follow the existing policy regarding registration of reassignments, ARIN will consider such efforts compliant. If the community wishes specific outcomes for particular scenarios, then it will be necessary to provide additional policy language which covers those cases. Thanks! /John John Curran President and CEO ARIN From Pallieter at pallieter.org Thu Jul 20 02:48:13 2017 From: Pallieter at pallieter.org (Pallieter Koopmans) Date: Thu, 20 Jul 2017 08:48:13 +0200 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: Hello, ARIN could quantify and require rules for when to SWIP, but in the end, there are going to be exceptions needed if the rules are to be strictly followed. Many will not separately SWIP a separately routed sub-block if it is too difficult or pointless to gather and share that data back upstream to ARIN. Thus a more fuzzy rule to require a best-effort and to add a rule-based reason (preferably both a carrot and a stick) for block owners to do their best to provide (only) useful data. In order to do that, one needs to look back at why that data is needed. For a block owner to assign the SWIP on a sub-block, he basically delegates tech and abuse contact requests down to those that are probably more likely to be able to actually act on the tech/abuse requests (and thus reduce request-handling workload higher up and overall). But for that to work, those tech/abuse contact requests need to be actually handled, otherwise, it is better to leave them with the block owner. In the end, the contact details should be as close to the "person" that is actually capable to both handle (think: volume/languages/etc) and act (think: authority) on the tech/abuse requests. eBrain Innovative Internet Ideas Pallieter Koopmans Managing Director +31-6-3400-3800 (mon-sat 9-22 CET) Skype: PallieterKoopmans From owen at delong.com Thu Jul 20 15:50:29 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 12:50:29 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> References: <59248105.8040703@arin.net> <5D106C75D5C2DD41AB2B4B823FE0EC052DEE1FA0@CWWAPP480.windstream.com> <21300f952d9f4bf381f06d10a2139c4a@DG2MBX04-DOR.bell.corp.bce.ca> <800D71FE-4481-40D1-9F12-CFE0E3A354C1@delong.com> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e! 2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> Message-ID: <73A2B8EE-94FA-43B0-8BA2-BAAFCF19D66C@delong.com> Paul, Residential customer privacy policy in the NRPM means even if you SWIP them, you?re not giving up much more data than their Postal code (or possibly a near-by or inclusive generic Postal code in some cases). As such, I think your argument here is a bit specious. Owen > On Jul 15, 2017, at 11:51 , Paul McNary wrote: > > Hello > My concern is where the magic boundary will occur. If the swip boundary includes the > recommended /XX for residential customers and small business. I could see where the > whois database could be abused by harvesting our customer information. Competitors > could, would have access and ability to harvest proprietary information concerning > our ISP business. We would have to limit our end user details to the area which will > not be swip'ed to protect our business. That might not be the proper way to utilize IPv6. > Current guidance has been to assign a /56 to even residential customers and some have > recommended a /48 as the minimum assignment. I don't want my customer information > available in such a public accessible database as whois. They could count my subscribers, > harvest their names, addresses and even contact phone numbers. I do not see this > as being good. I would not even like my SMB businesses to have public information > unless they ask for it. I would prefer that the boundary be greater than /48. With /48 > not being swip'ed or /56 even that is the minimum end user allocation. > If I understand correctly (many times I do not) RFC/common agreement that a /32 > is the smallest allocation to be announced. I have also have heard /48. So in my > case if it can't be BGP public routable, I don't want to swip it. What ever my BGP > routers can publicly advertise, my BGP gateway, will be assigned to us. Everything > smaller than that, I don't want to publicly advertise. > > Why would we want the ability to give the competition the tools to analyze our > business with a publicly available tool (ie whois). I also don't think that if ARIN > will not provide an allocation size it shouldn't be swip'ed. So if ARIN wants to directly > provide /56 to end users, then I will rethink my thought process. Anything smaller than > a minimum ARIN allocation, should not have to be swip'ed or under their control. > > Am I not understanding this correctly? > > Thank you > Paul McNary > McNary Computer Services > pmcnary at cameron.net > > > > On 7/15/2017 12:42 PM, Scott Leibrand wrote: >> On Sat, Jul 15, 2017 at 10:24 AM, William Herrin > wrote: >> On Sat, Jul 15, 2017 at 8:52 AM, John Curran > wrote: >> Such a separation doesn?t preclude the community from adopting policy which >> references the present or future state of routing (note, for example, the use of >> ?multihoming? criteria in several portions of the NRPM), but folks are reminded >> that in Internet number resource policy we should only be specifying how the >> ARIN registry is to be administered, not how things are to be routed, since the >> latter is up to each ISP. >> >> Hi John, >> >> In the interests of clarifying your remarks: >> >> ARIN does not set or even recommend routing policy. Participants in the ARIN policy process routinely consider industry routing practices, IETF recommendations, etc. when suggesting ARIN address management policy and ARIN routinely enacts such policy. >> >> Right? >> >> That is true, but I think John is making a stronger point, which I'll make here: It's perfectly fine for ARIN policy to be contingent on (applied differently depending on) how a particular block is (going to be) routed. So if we think it's the right thing to do, we could require in the NRPM that all blocks in the global routing system be SWIP'ed. But we *can't* enforce such a requirement by saying, for example, that ISPs can't accept a block until it's SWIP'ed. We can only issue guidelines on what should be SWIP'ed and make ARIN services (like allocation of additional blocks) contingent on whether such a policy is followed. If an enforced SWIP-before-routing rule is desired by the ISPs that participate in the global routing system, then they'll have to do so voluntarily by refusing to accept the announcement of non-SWIP'ed blocks. >> >> -Scott >> >> >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 20 15:53:50 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 12:53:50 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <90171621-A99D-41D9-B445-4B0A2426A110@delong.com> <055c01d2fcdc$c5292b60$4f7b8220$@tndh.net> <000501d2fd09$4979d5a0$dc6d80e0$@tndh.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-E! E89-4E1E-9553-A7B80BC82EE2@arin.net> Message-ID: <87771933-8869-4E05-A638-3EE7047164C9@delong.com> I can accept any of the (now 3) proposals contained in this email. Owen > On Jul 17, 2017, at 09:13 , Jason Schiller wrote: > > I am replying to bring the conversation to one of the suggestions > on the table. > > Owen DeLong's suggesting of SWIP all IPv6 business users, and > not Residential users, > > Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all > prefixes that might show up as a more specific in the global routing > table. > > > These are roughly the same result, and have a question of which > has a more easily understandable policy. > > The question is who here supports one or both of these > proposals? > > Who oppose one (if so which one) or both of these proposals? > > > I would like to suggest one friendly amendment... > - ISPs are required to SWIP IP space that is a reallocation. > - ISPs are required to SWIP IP space that is a reassignment > whenever that down stream customer requests such. That > SWIP must be a reassign detail, reassign simple, or a > residential privacy (if applicable) per the customer request. > > ___Jason > > > > On Mon, Jul 17, 2017 at 10:42 AM, John Curran > wrote: > On 17 Jul 2017, at 9:47 AM, hostmaster at uneedus.com wrote: > > ,,, > > This is the problem. ARIN is not a carrier. While disclosure to ARIN to obtain number resources for the connection is OK, Public disclosure by or at the direction of ARIN policy of elements like domain name, name, address and telephone number is not. Since name, address, telephone number and domain name have already been identified have been defined in the order as elements of CPNI that are protected, world disclosure by ARIN or because of ARIN rules would not be a protected disclosure. > > > > The ISP might also be in trouble for providing the information to ARIN, if they know that ARIN intends to publish this information in a public directory, rather than disclosing it to ARIN solely to maintain number resources. As suggested by the OP, might have to call them customer 1-n. However that would violate the NRPM as written. Since the City, State and Zip Code are part of the address, even the "protected" residential records CPNI are being disclosed in violation of the CPNI Order. > > > > There is a big difference between disclosure to ARIN for taking care of numbering policy, and disclosure to the entire world. Third party disclosure is the main thing that the CPNI rules are intended to address. That is only permitted when it is needed for the provision of service. > > Compliance with registry policy is indeed necessary to receive number resources; > it is up to you to determine whether IP number resources are necessary for provision > of your Internet services. > > If you choose not to make use of Internet Numbers Registry System resources for > provision of Internet services (or not assign them to your customers), then that is > your choice. Some ISPs may feel that it is necessary to seek consent of customers > who wish to have public IP number resources assigned in the size that would result in > their publication in the public registry, whereas others may not based on their reading > of applicable regulations regarding handling of CPNI information. Such choices are > an operational and business matter left to each ISP to decide based on their individual > understanding and circumstances. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > _______________________________________________ > 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. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 20 15:55:51 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 12:55:51 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <20170717173405.GA9797@gweep.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: <75AFF6A1-0C6A-4FF6-B718-6F94E758A7A1@delong.com> +1? Well said, Joe. Owen > On Jul 17, 2017, at 10:34 , Joe Provo wrote: > > > > On Mon, Jul 17, 2017 at 01:08:49PM -0400, David Huberman wrote: >> In addition to these options/questions, I feel like we glossed >> over the question posed by Marty Hannigan: what is the value of >> REQUIRING SWIP anymore? As a community member (not as an AC member) >> I have trouble supporting any of these as I'm not sure I support >> SWIP being anything other than voluntary. Whois reassignments are >> not the proper place for the information LE wants, in my opinion, >> and has almost no value to NOCs. > > I find this assertion at odds with both my experience and direct > inquiries to those in the anti-abuse community. Upon what basis > is it made? > >> And ARIN doesn't need it anymore >> for qualification purposes for a scarce resource. So what's he >> point of all this? Genuine question; no tone implied. > > As a community, we (used to?) value accountability and transparency. > Having a direct contact associated with a resource has IME always > worked better than trying to contact a porvider with whom I have no > business relationship. > > [snip] >>> On Jul 17, 2017, at 12:13 PM, Jason Schiller wrote: >>> >>> I am replying to bring the conversation to one of the suggestions >>> on the table. >>> >>> Owen DeLong's suggesting of SWIP all IPv6 business users, and >>> not Residential users, >>> >>> Or Kevin Blumberg (and David Farmer) suggestion of SWIP'ing all >>> prefixes that might show up as a more specific in the global routing >>> table. >>> >>> >>> These are roughly the same result, and have a question of which >>> has a more easily understandable policy. >>> >>> The question is who here supports one or both of these >>> proposals? >>> >>> Who oppose one (if so which one) or both of these proposals? > > Since my concern is associated with the resource usage, and we > in ARIN-land historically wash our hands of connectivity/reachability, > as much as the second is appealing the former is more relevant and > workable. I personally dislike the blanket exception embedded within > it, but know there's not going to be any upside to fighting that one > so would rather take what I can get. > >>> I would like to suggest one friendly amendment... >>> - ISPs are required to SWIP IP space that is a reallocation. >>> - ISPs are required to SWIP IP space that is a reassignment >>> whenever that down stream customer requests such. That >>> SWIP must be a reassign detail, reassign simple, or a >>> residential privacy (if applicable) per the customer request. >>> >>> ___Jason > > I like the addition. > > Cheers! > > Joe > > > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling > _______________________________________________ > 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. From owen at delong.com Thu Jul 20 16:01:08 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 13:01:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM In-Reply-To: <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> References: <59495DF4.8010504@arin.net> <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> Message-ID: <93E78F44-1CAC-4288-B754-400B32A02A36@delong.com> > On Jul 17, 2017, at 12:32 , Chris Woodfield wrote: > > Hello, > > Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response to the proposal in its current state appears to be universally negative. > > Having read the comments on this proposal, it could be plausible that an alternate solution to the problem statement could be that in lieu of retiring most of the section, specific sections could be substantially simplified by pointing to the currently-duplicated clauses in Section 6, eliminating the need to manually keep these sections in sync by applying similar policy to both where warranted (in particular, the sections around utilization justification seem like the best candidates). I think you mean section 8 as section 6 applies to IPv6 policy and would be absurd if applied to IPv4. > Does the community feel that this is a viable route to explore, which would simplify Section 4 while keeping the necessary relevant sections, in lieu of the original proposal? Perhaps. Or perhaps we just abandon this proposal. Owen > > Thanks, > > -Chris > >> On Jun 21, 2017, at 12:16 PM, Austin Murkland > wrote: >> >> I do not support this policy for the reasons Kevin and Albert outlined. This seems a bit premature. >> >> Thanks, >> >> Austin Murkland >> >> On Tue, Jun 20, 2017 at 1:40 PM, ARIN > wrote: >> On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft Policy status. >> >> Draft Policy ARIN-2017-7 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_7.html >> >> 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-7: Retire Obsolete Section 4 from the NRPM >> >> Problem Statement: >> >> Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The community elected, instead of revamping and modernizing section 4 in light of this to, instead, recreate the relevant parts of section 4 in section 8.5. As a result, section 4 is generally obsolete and can be mostly retired. Since some small amounts of space do occasionally recreate the free pool, a mechanism for addressing this must remain and therefore a much reduced section 4 is proposed here instead of outright retirement. >> >> Policy statement: >> >> Replace section 4 of the NRPM with the following: >> >> 4. IPv4 >> >> 4.1 IPv4 Requests >> >> 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall be evaluated based on the criteria for transfer recipients contained in section 8.5. >> >> 4.1.2 Any approved requests which cannot be met from the ARIN free pool shall be handled according to section 4.2. >> >> 4.2 Unmet requests >> >> In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable. >> >> Repeated requests are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. >> >> Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. >> >> 4.2.1. Waiting list >> >> The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. >> >> 4.2.2. Fulfilling unmet needs >> >> As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. >> >> Comments: >> >> a. Timetable for implementation: Immediate >> _______________________________________________ >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 20 16:06:38 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 13:06:38 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4b185247-11a0-0998-96a4-09a7f6915f93@cameron.net> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <4b1852! 47-11a0-0998-96a4-09a7f6915f93@cameron.net> Message-ID: <1959B335-CDD9-4EF3-9610-51416A07B270@delong.com> This makes the best case I can imagine for why setting the boundary at /56 is a bad idea and we should not be considering anything longer than /48. Owen > On Jul 17, 2017, at 15:40 , Paul McNary wrote: > > Leif > If I understand your question: > > Originally /48 to anyone was the BCP for future efficiency. > I can change my BCP to /56. > /48 is my preference, however, which is the BGP boundary. > Otherwise I have little issue with choice "b" if forced. > > I would prefer to give my residential users a /48 for the future but a /56 > could work, just a pain. Again rDNS could be a problem. > > Do AS's use ARIN reverse DNS for size smaller than /48? > If rDNS will not work worldwide except with /48 advertising, > I think that should be the SWIP boundary. > I know for a while some AS's required /32. > I think that has finally changed. > However ARIN's assignment web page indicates we should be > SWIP'ing /29's on IPv4 by policy or risk ARIN action. > > Thank you > Paul McNary > pmcnary at cameron.net > > On 7/17/2017 5:09 PM, Leif Sawyer wrote: >> Shepherd of the draft policy chiming in. >> >> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >> >> Just as a reminder to folk, the current policy under question is located here: >> https://www.arin.net/policy/nrpm.html#six551 >> >> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531 ) >> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >> in lieu of actual names and street addresses. >> >> -- >> >> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >> >> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >> preferential rewrite of the opening sentence of 6.5.5.1? >> >> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >> >> >> b) Each static IPv6 assignment containing a /55 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. >> >> >> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >> >> Third: If none of these options are palatable, do you have a proposed approach? >> >> >> >> Thanks, >> >> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 20 16:07:10 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 13:07:10 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> Message-ID: <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> My recommendation was ?shorter than /48? which would essentially mean the same thing. Owen > On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: > > The language of "b)" actually makes more sense with a /47: > > 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. > > The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. > > This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Mon, 17 Jul 2017, Leif Sawyer wrote: > >> Shepherd of the draft policy chiming in. >> >> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >> >> Just as a reminder to folk, the current policy under question is located here: >> https://www.arin.net/policy/nrpm.html#six551 >> >> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >> in lieu of actual names and street addresses. >> >> -- >> >> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >> >> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >> preferential rewrite of the opening sentence of 6.5.5.1? >> >> >> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >> >> >> >> b) Each static IPv6 assignment containing a /55 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. >> >> >> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >> >> Third: If none of these options are palatable, do you have a proposed approach? >> >> >> >> Thanks, >> >> 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. From chris at semihuman.com Thu Jul 20 16:12:40 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 20 Jul 2017 13:12:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM In-Reply-To: <93E78F44-1CAC-4288-B754-400B32A02A36@delong.com> References: <59495DF4.8010504@arin.net> <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> <93E78F44-1CAC-4288-B754-400B32A02A36@delong.com> Message-ID: <20903801-EB67-450D-8544-024710FC5E0E@semihuman.com> You are correct, I was meaning to refer to Section 8. Thanks for pointing out the error :) -C > On Jul 20, 2017, at 1:01 PM, Owen DeLong wrote: > >> >> On Jul 17, 2017, at 12:32 , Chris Woodfield > wrote: >> >> Hello, >> >> Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response to the proposal in its current state appears to be universally negative. >> >> Having read the comments on this proposal, it could be plausible that an alternate solution to the problem statement could be that in lieu of retiring most of the section, specific sections could be substantially simplified by pointing to the currently-duplicated clauses in Section 6, eliminating the need to manually keep these sections in sync by applying similar policy to both where warranted (in particular, the sections around utilization justification seem like the best candidates). > > I think you mean section 8 as section 6 applies to IPv6 policy and would be absurd if applied to IPv4. > >> Does the community feel that this is a viable route to explore, which would simplify Section 4 while keeping the necessary relevant sections, in lieu of the original proposal? > > Perhaps. Or perhaps we just abandon this proposal. > > Owen > >> >> Thanks, >> >> -Chris >> >>> On Jun 21, 2017, at 12:16 PM, Austin Murkland > wrote: >>> >>> I do not support this policy for the reasons Kevin and Albert outlined. This seems a bit premature. >>> >>> Thanks, >>> >>> Austin Murkland >>> >>> On Tue, Jun 20, 2017 at 1:40 PM, ARIN > wrote: >>> On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-7 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_7.html >>> >>> 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-7: Retire Obsolete Section 4 from the NRPM >>> >>> Problem Statement: >>> >>> Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The community elected, instead of revamping and modernizing section 4 in light of this to, instead, recreate the relevant parts of section 4 in section 8.5. As a result, section 4 is generally obsolete and can be mostly retired. Since some small amounts of space do occasionally recreate the free pool, a mechanism for addressing this must remain and therefore a much reduced section 4 is proposed here instead of outright retirement. >>> >>> Policy statement: >>> >>> Replace section 4 of the NRPM with the following: >>> >>> 4. IPv4 >>> >>> 4.1 IPv4 Requests >>> >>> 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall be evaluated based on the criteria for transfer recipients contained in section 8.5. >>> >>> 4.1.2 Any approved requests which cannot be met from the ARIN free pool shall be handled according to section 4.2. >>> >>> 4.2 Unmet requests >>> >>> In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable. >>> >>> Repeated requests are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. >>> >>> Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.2.1. Waiting list >>> >>> The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. >>> >>> 4.2.2. Fulfilling unmet needs >>> >>> As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jul 20 16:16:53 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 20 Jul 2017 13:16:53 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen > On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. From pmcnary at cameron.net Thu Jul 20 16:25:07 2017 From: pmcnary at cameron.net (Paul McNary) Date: Thu, 20 Jul 2017 15:25:07 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <1959B335-CDD9-4EF3-9610-51416A07B270@delong.com> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <4b1852! 47-11a0-0998-96a4-09a7f6915f93@cameron.net> <1959B335-CDD9-4EF3-9610-51416A07B270@delong.com> Message-ID: <64e8616d-956c-22c4-68be-1bec682546a6@cameron.net> Owen I agree 100% with your statement below! Longer than a /48. That would eliminate any concerns I have. /48's could be assigned to each POP giving basic location information for any downstream. That is similar to BCP of a /24 for IPv4. If a downstream business request SWIP that we can accommodate. Take care Paul On 7/20/2017 3:06 PM, Owen DeLong wrote: > This makes the best case I can imagine for why setting the boundary at > /56 is a bad idea and we should not be considering anything longer > than /48. > > Owen > >> On Jul 17, 2017, at 15:40 , Paul McNary > > wrote: >> >> Leif >> If I understand your question: >> >> Originally /48 to anyone was the BCP for future efficiency. >> I can change my BCP to /56. >> /48 is my preference, however, which is the BGP boundary. >> Otherwise I have little issue with choice "b" if forced. >> >> I would prefer to give my residential users a /48 for the future but >> a /56 >> could work, just a pain. Again rDNS could be a problem. >> >> Do AS's use ARIN reverse DNS for size smaller than /48? >> If rDNS will not work worldwide except with /48 advertising, >> I think that should be the SWIP boundary. >> I know for a while some AS's required /32. >> I think that has finally changed. >> However ARIN's assignment web page indicates we should be >> SWIP'ing /29's on IPv4 by policy or risk ARIN action. >> >> Thank you >> Paul McNary >> pmcnary at cameron.net >> >> >> On 7/17/2017 5:09 PM, Leif Sawyer wrote: >>> Shepherd of the draft policy chiming in. >>> Thanks for the lively discussion, everybody. There's certainly a >>> lot to think about here. >>> Just as a reminder to folk, the current policy under question is >>> located here: >>> https://www.arin.net/policy/nrpm.html#six551 >>> And, to help clarify some confusion, per 6.5.5.3.1 >>> (https://www.arin.net/policy/nrpm.html#six5531) >>> residential customers "holding/64 and larger blocks" may use >>> censored data, i.e. "Private Customer/Residence" >>> in lieu of actual names and street addresses. >>> -- >>> With that said, I have a couple of questions to ask, based on >>> potential rewrites that are brewing. >>> First: Assuming a preference for /56 (based on PPML feedback) for >>> the moment, which is the more >>> preferential rewrite of the opening sentence of 6.5.5.1? >>> a)Each static IPv6 assignment containing a /55 or more addresses >>> shall be registered in the WHOIS directory via SWIP or a distributed >>> service which meets the standards set forth in section 3.2. >>> >>> >>> b)Each static IPv6 assignment containing a /55 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. >>> Second: Given your specific choice of A or B, are you >>> preferentially inclined to choose the provided bit-boundary, or "/48" >>> Third: If none of these options are palatable, do you have a >>> proposed approach? >>> Thanks, >>> 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 contactinfo 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 contactinfo at arin.net if you experience >> any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Thu Jul 20 16:26:31 2017 From: pmcnary at cameron.net (Paul McNary) Date: Thu, 20 Jul 2017 15:26:31 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> Message-ID: <20d4eaea-9201-dc25-94c2-1799bab43802@cameron.net> Yes /48 is the SWIP boundary. /48 is SWIP'ed. /49 is not. Paul On 7/20/2017 3:07 PM, Owen DeLong wrote: > My recommendation was ?shorter than /48? which would essentially mean the same thing. > > Owen > >> On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: >> >> The language of "b)" actually makes more sense with a /47: >> >> 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. >> >> The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. >> >> This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> On Mon, 17 Jul 2017, Leif Sawyer wrote: >> >>> Shepherd of the draft policy chiming in. >>> >>> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >>> >>> Just as a reminder to folk, the current policy under question is located here: >>> https://www.arin.net/policy/nrpm.html#six551 >>> >>> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >>> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >>> in lieu of actual names and street addresses. >>> >>> -- >>> >>> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >>> >>> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >>> preferential rewrite of the opening sentence of 6.5.5.1? >>> >>> >>> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >>> >>> >>> >>> b) Each static IPv6 assignment containing a /55 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. >>> >>> >>> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >>> >>> Third: If none of these options are palatable, do you have a proposed approach? >>> >>> >>> >>> Thanks, >>> >>> 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. > _______________________________________________ > 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. From ppml at rsuc.gweep.net Thu Jul 20 16:34:33 2017 From: ppml at rsuc.gweep.net (Joe Provo) Date: Thu, 20 Jul 2017 16:34:33 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> Message-ID: <20170720203432.GA45269@gweep.net> Hey David, On Mon, Jul 17, 2017 at 01:54:08PM -0400, David R Huberman wrote: > Hello Joe, > > Thanks for the reply. A reminder that I'm *asking* a genuine question. Sure, and I was supplying my genuine response. My personal hat is still firmly on my head, fwiw. > Now, I wrote: > > >> Whois reassignments are not the proper place for the information LE > >> wants, in my opinion, and has almost no value to NOCs. > > Joe replied: > > > I find this assertion at odds with both my experience and direct > > inquiries to those in the anti-abuse community. Upon what basis > > is it made? Nit - I should have trimmed LE because my scope in response was regarding the NOC comment. I work in the operational realm, not legal interface. > So a few things. > > 1) I specifically said 'reassignments', and by that I meant end-user data. > I have always been in favor of 'reallocations' (to downstream ISPs) being > in Whois. I find both to be of value in the data gathering phase of investigating anamolies, dealing with incidents, and so on. Frankly, most all data sources are noisy and therefore multiple sources of medium confidence are better than attempting to pin high confidence to fewer sources. > 2) The *vast* majority (and we're talking 99%+ -- I've studied the data > many times) of end-user SWIP data is things like: > > AT&T Internet Services SBCIS-SIS80-1005 (NET-69-0-0-0-1) 69.0.0.0 - > 69.0.127.255 > THE MEDICINE SHOPPE SBC069000000000030204 (NET-69-0-0-0-2) 69.0.0.0 - > 69.0.0.7 > > When you lookup the specific /29, you get: > > CustName: THE MEDICINE SHOPPE > Address: 310 ORANGE ST > City: NEW HAVEN > StateProv: CT > PostalCode: 06510 > Country: US > > ... with vanilla AT*T contact information from the parent /17. > > Yes: I assert this data has no value to NOCs or general internetworking > operations, in my experience, and I wrote that I do not believe this is > the proper place for LE to be gleaning it's info. (That's a whole other > conversation, but it's my opinion here.) > > I don't understand how this SWIP data provides value in terms of > transparency? It is, as others have noted, just giving out customer lists > -- information which is typically considered confidential. ARIN policy > *can* require this information, but *should* it? Even if the published *contact* data is incorrect, it is a trivial step to get contact data for the reassigned entity which is published via other vectors. Your straw-man provides me the info to contact the user of the designated resources directly ["Hi, you are owned"] rather than contact an entity with which I have no association. There are a vast number of organizations across the globe who will not accept external reports or contacts regardless of impact. If you aren't a customer or have subpeona power, you don't exist as they are optimized around call metrics. Avoiding them is a win, and even if the direct contact ends up being fruitless, the attempt can be made (and documented for evidence if need be). > Additing to this conversation, two other items: > > 3) Since 2004, when Dave Barger first got up to a microphone at an ARIN > meeting (Reston) and admitted that his company's SWIPs were non-compliant > because of software issues, we've had huge swaths of SWIP data that is > just wrong. It's very difficult (especially at scale) to both publish and > maintain accurate SWIP data. There's a real cost to requiring accurate > SWIP data for providers -- large and small. If we're going to put this > cost on them for IPv6, I'd really like us to have a solid justification > that's relevant to 2017 network operations, and not based on what was true > in 1999. Sadly those we can't rely upon for accurate SWIP data also couldn't be trusted for accurate rWHOIS data. I'd be interested in hearing other distributed options, and suspect there's an answer involving blockchain buried in there but I'm just not clever enough to unearth it. If as a community we still value being able to get things done without involving legal action then providing an reasonable accounting of how an organization is using the community's resources (and let's make no mistake - that is what the concensus pool of addressing *is*) is simply the cost of doing business. If recouping the cost of data publication and upkeep isn't built into their product or customer relations then they probably have a broken business plan. > 4) And finally, we go back to an early convversation point that as > presently drafted, this policy idea (required SWIPs for IPv6) is not > enforceable by ARIN. In a world where you generally do not go back to the > RIR for additional IPv6 prefixes, ARIN has no enforcement tools in the > policy -- and the one's they could have that I can envisage, I don't > support. I see this to be a fundamental failing of our region's fragmented model. We dither over things which are non-problems in other regions due to decisions made quite some time ago... that would be a "2017 rather than 1999" conversation worth having, IMNSHO. Cheers, Joe -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From pmcnary at cameron.net Thu Jul 20 16:51:19 2017 From: pmcnary at cameron.net (Paul McNary) Date: Thu, 20 Jul 2017 15:51:19 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Owen The reassignment policy page says IPv6 has to be done vi API. Is that something else that is incorrect on the web site? Paul On 7/20/2017 3:16 PM, Owen DeLong wrote: > How can it be overly difficult to fill out an email template with your customers? > Name, Address, Phone Number? > > Really? > > Owen > >> On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: >> >> Hello, >> >> ARIN could quantify and require rules for when to SWIP, but in the >> end, there are going to be exceptions needed if the rules are to be >> strictly followed. Many will not separately SWIP a separately routed >> sub-block if it is too difficult or pointless to gather and share that >> data back upstream to ARIN. >> >> Thus a more fuzzy rule to require a best-effort and to add a >> rule-based reason (preferably both a carrot and a stick) for block >> owners to do their best to provide (only) useful data. In order to do >> that, one needs to look back at why that data is needed. For a block >> owner to assign the SWIP on a sub-block, he basically delegates tech >> and abuse contact requests down to those that are probably more likely >> to be able to actually act on the tech/abuse requests (and thus reduce >> request-handling workload higher up and overall). But for that to >> work, those tech/abuse contact requests need to be actually handled, >> otherwise, it is better to leave them with the block owner. >> >> In the end, the contact details should be as close to the "person" >> that is actually capable to both handle (think: volume/languages/etc) >> and act (think: authority) on the tech/abuse requests. >> >> eBrain >> Innovative Internet Ideas >> >> Pallieter Koopmans >> Managing Director >> >> +31-6-3400-3800 (mon-sat 9-22 CET) >> Skype: PallieterKoopmans >> _______________________________________________ >> 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. From chris at datacate.com Thu Jul 20 16:54:49 2017 From: chris at datacate.com (Chris James) Date: Thu, 20 Jul 2017 13:54:49 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: @Paul - The API key is to email it. @Owen - Very difficult when you have dynamic ranges, and vps/container platforms spanning tens of thousands of instances across these dynamic ranges. On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: > Owen > > The reassignment policy page says IPv6 has to be done vi API. > Is that something else that is incorrect on the web site? > > Paul > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: > >> How can it be overly difficult to fill out an email template with your >> customers? >> Name, Address, Phone Number? >> >> Really? >> >> Owen >> >> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>> wrote: >>> >>> Hello, >>> >>> ARIN could quantify and require rules for when to SWIP, but in the >>> end, there are going to be exceptions needed if the rules are to be >>> strictly followed. Many will not separately SWIP a separately routed >>> sub-block if it is too difficult or pointless to gather and share that >>> data back upstream to ARIN. >>> >>> Thus a more fuzzy rule to require a best-effort and to add a >>> rule-based reason (preferably both a carrot and a stick) for block >>> owners to do their best to provide (only) useful data. In order to do >>> that, one needs to look back at why that data is needed. For a block >>> owner to assign the SWIP on a sub-block, he basically delegates tech >>> and abuse contact requests down to those that are probably more likely >>> to be able to actually act on the tech/abuse requests (and thus reduce >>> request-handling workload higher up and overall). But for that to >>> work, those tech/abuse contact requests need to be actually handled, >>> otherwise, it is better to leave them with the block owner. >>> >>> In the end, the contact details should be as close to the "person" >>> that is actually capable to both handle (think: volume/languages/etc) >>> and act (think: authority) on the tech/abuse requests. >>> >>> eBrain >>> Innovative Internet Ideas >>> >>> Pallieter Koopmans >>> Managing Director >>> >>> +31-6-3400-3800 (mon-sat 9-22 CET) >>> Skype: PallieterKoopmans >>> _______________________________________________ >>> 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. >> > > _______________________________________________ > 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. -- This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Jul 20 17:28:41 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 20 Jul 2017 17:28:41 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. Current policy says SWIP every /64 or more, which is every network in v6. I did a check here, and in v4, only 1% of customers have more than 8 ip's, and these customers are colocation customers who have a bunch of SSL sites. These are grandfathered. New customers are told to use 1 IPv4 address and SNI or better yet, IPv6, as we do not have the money to buy more V4. We would rather use our v4 inventory for access customers. Yes, it is just a few pieces of information for SWIP. However, we do not have clerical staff to do it, because except for the SSL colocates, there never has been v4 SWIP's required here. Why should the policy state that just because we give each customer an assignment of v6, we must SWIP that same small customer that did not require SWIP in v4? (Welcome to IPv6, now fill out this form.....) Also noted is that the SWIP registration details without written permission might get us in trouble with the FCC over CPNI. As a WISP that has licensed microwave links, we do pay attention to Uncle Charlie. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 20 Jul 2017, Chris James wrote: > @Paul - The API key is to email it. > > @Owen - Very difficult when you have dynamic ranges, and vps/container > platforms spanning tens of thousands of instances across these dynamic > ranges. > > > On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: > >> Owen >> >> The reassignment policy page says IPv6 has to be done vi API. >> Is that something else that is incorrect on the web site? >> >> Paul >> >> >> On 7/20/2017 3:16 PM, Owen DeLong wrote: >> >>> How can it be overly difficult to fill out an email template with your >>> customers??? >>> Name, Address, Phone Number? >>> >>> Really? >>> >>> Owen >>> >>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>> wrote: >>>> >>>> Hello, >>>> >>>> ARIN could quantify and require rules for when to SWIP, but in the >>>> end, there are going to be exceptions needed if the rules are to be >>>> strictly followed. Many will not separately SWIP a separately routed >>>> sub-block if it is too difficult or pointless to gather and share that >>>> data back upstream to ARIN. >>>> >>>> Thus a more fuzzy rule to require a best-effort and to add a >>>> rule-based reason (preferably both a carrot and a stick) for block >>>> owners to do their best to provide (only) useful data. In order to do >>>> that, one needs to look back at why that data is needed. For a block >>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>> and abuse contact requests down to those that are probably more likely >>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>> request-handling workload higher up and overall). But for that to >>>> work, those tech/abuse contact requests need to be actually handled, >>>> otherwise, it is better to leave them with the block owner. >>>> >>>> In the end, the contact details should be as close to the "person" >>>> that is actually capable to both handle (think: volume/languages/etc) >>>> and act (think: authority) on the tech/abuse requests. >>>> >>>> eBrain >>>> Innovative Internet Ideas >>>> >>>> Pallieter Koopmans >>>> Managing Director >>>> >>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>> Skype: PallieterKoopmans >>>> _______________________________________________ >>>> 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. >>> >> >> _______________________________________________ >> 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. > > -- > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. This company is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > From chris at datacate.com Thu Jul 20 19:08:25 2017 From: chris at datacate.com (Chris James) Date: Thu, 20 Jul 2017 16:08:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Well I think in the bus example you would swip to the overall authority. But seriously this conversation has gone in so many different directions do any of us remember the original point? My vote as it applies to v6: Non-residential allocations of greater than or equal to a /48. If you as an ISP choose to allocate a /48 to a residential customer - then have fun. But this does not affect the purpose of the policy as most use it these days which is abuse management. Also as I understand it, there is an exception to the CPNI as it applies to business customers as long as they have an account manager and adequate language in the contract. How many of the smaller ISPs have a customer deserving of a /48 or better that does not have a larger account or spend? If a customer requests a large enough block from us, regardless of v4 vs v6, they agree via email/ticketing/contract that their business information will be made public. This is not difficult to put in your signed agreements with your business customers thus making the CPNI argument invalid. -Chris On Thu, Jul 20, 2017 at 2:28 PM, wrote: > My transit bus example is another example of SWIP difficulty. Very hard > to provide a street address to SWIP a bus when it is mobile 16 hours a day. > > Current policy says SWIP every /64 or more, which is every network in v6. > > I did a check here, and in v4, only 1% of customers have more than 8 ip's, > and these customers are colocation customers who have a bunch of SSL > sites. These are grandfathered. New customers are told to use 1 IPv4 > address and SNI or better yet, IPv6, as we do not have the money to buy > more V4. We would rather use our v4 inventory for access customers. > > Yes, it is just a few pieces of information for SWIP. However, we do not > have clerical staff to do it, because except for the SSL colocates, there > never has been v4 SWIP's required here. Why should the policy state that > just because we give each customer an assignment of v6, we must SWIP that > same small customer that did not require SWIP in v4? (Welcome to IPv6, now > fill out this form.....) Also noted is that the SWIP registration details > without written permission might get us in trouble with the FCC over CPNI. > As a WISP that has licensed microwave links, we do pay attention to Uncle > Charlie. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Thu, 20 Jul 2017, Chris James wrote: > > @Paul - The API key is to email it. >> >> @Owen - Very difficult when you have dynamic ranges, and vps/container >> platforms spanning tens of thousands of instances across these dynamic >> ranges. >> >> >> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >> >> Owen >>> >>> The reassignment policy page says IPv6 has to be done vi API. >>> Is that something else that is incorrect on the web site? >>> >>> Paul >>> >>> >>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>> >>> How can it be overly difficult to fill out an email template with your >>>> customers? >>>> Name, Address, Phone Number? >>>> >>>> Really? >>>> >>>> Owen >>>> >>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>> > >>>> >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>> end, there are going to be exceptions needed if the rules are to be >>>>> strictly followed. Many will not separately SWIP a separately routed >>>>> sub-block if it is too difficult or pointless to gather and share that >>>>> data back upstream to ARIN. >>>>> >>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>> owners to do their best to provide (only) useful data. In order to do >>>>> that, one needs to look back at why that data is needed. For a block >>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>> and abuse contact requests down to those that are probably more likely >>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>> request-handling workload higher up and overall). But for that to >>>>> work, those tech/abuse contact requests need to be actually handled, >>>>> otherwise, it is better to leave them with the block owner. >>>>> >>>>> In the end, the contact details should be as close to the "person" >>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>> and act (think: authority) on the tech/abuse requests. >>>>> >>>>> eBrain >>>>> Innovative Internet Ideas >>>>> >>>>> Pallieter Koopmans >>>>> Managing Director >>>>> >>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>> Skype: PallieterKoopmans >>>>> _______________________________________________ >>>>> 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. >>>> >>>> >>> _______________________________________________ >>> 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. >>> >> >> -- >> This e-mail message may contain confidential or legally privileged >> information and is intended only for the use of the intended recipient(s). >> Any unauthorized disclosure, dissemination, distribution, copying or the >> taking of any action in reliance on the information herein is prohibited. >> E-mails are not secure and cannot be guaranteed to be error free as they >> can be intercepted, amended, or contain viruses. Anyone who communicates >> with us by e-mail is deemed to have accepted these risks. This company is >> not responsible for errors or omissions in this message and denies any >> responsibility for any damage arising from the use of e-mail. Any opinion >> and other statement contained in this message and any attachment are >> solely >> those of the author and do not necessarily represent those of the company. >> > > _______________________________________________ > 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. > -- This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Jul 21 00:53:34 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 21 Jul 2017 00:53:34 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201707210453.v6L4rYBb023170@rotala.raleigh.ibm.com> Total of 80 messages in the last 7 days. script run at: Fri Jul 21 00:53:28 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.00% | 12 | 17.01% | 245901 | pmcnary at cameron.net 15.00% | 12 | 13.63% | 197010 | jcurran at arin.net 13.75% | 11 | 9.36% | 135245 | hostmaster at uneedus.com 11.25% | 9 | 11.84% | 171164 | owen at delong.com 6.25% | 5 | 10.02% | 144901 | alh-ietf at tndh.net 3.75% | 3 | 5.05% | 73023 | chris at semihuman.com 2.50% | 2 | 4.74% | 68536 | lsawyer at gci.com 3.75% | 3 | 2.47% | 35759 | daveid at panix.com 3.75% | 3 | 2.27% | 32764 | bill at herrin.us 2.50% | 2 | 3.18% | 46014 | chris at datacate.com 3.75% | 3 | 1.92% | 27742 | ppml at rsuc.gweep.net 2.50% | 2 | 2.94% | 42431 | jschiller at google.com 2.50% | 2 | 2.58% | 37338 | farmer at umn.edu 2.50% | 2 | 2.32% | 33610 | scottleibrand at gmail.com 1.25% | 1 | 2.31% | 33453 | kevinb at thewire.ca 1.25% | 1 | 2.05% | 29705 | andrew.dul at quark.net 1.25% | 1 | 1.88% | 27172 | bjones at vt.edu 1.25% | 1 | 1.07% | 15427 | rjletts at uw.edu 1.25% | 1 | 0.76% | 10921 | joelja at bogus.com 1.25% | 1 | 0.74% | 10648 | theone at uneedus.com 1.25% | 1 | 0.70% | 10077 | michael at linuxmagic.com 1.25% | 1 | 0.59% | 8464 | pallieter at pallieter.org 1.25% | 1 | 0.58% | 8314 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 80 |100.00% | 1445619 | Total From marilson.mapa at gmail.com Fri Jul 21 00:45:38 2017 From: marilson.mapa at gmail.com (Marilson) Date: Fri, 21 Jul 2017 01:45:38 -0300 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Gentlemen, let me introduce practical elements into this "difficult and onerous" attitude, but ethical, on the tech and abuse contact requests. Let's see in practice how it works when organizations accept and disclose absolutely false data, and when questioned, they simply lie or ignore it. We have on one side a well-known and hated spammer, on the other an ISP who insists on ignoring the denunciations, norms and laws, protecting and maintaining the profits that this spammer provides. And above all an entity that is self-titled as the regulator of good practice on the internet: From: Marilson Sent: Wednesday, July 19, 2017 3:55 AM To: compliance at icann.org ; complaints at icann.org Cc: crain at icann.org ; tips at nytimes.com ; spam at uce.gov ; privacy at council.bbb.org ; iana at iana.org ; anonbrpt at anonymousbrasil.com Subject: Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Lie! The domain was not suspended and neither the Registrar or ISP suspended, deleted, cancelled or even deactivated the domain name. The spammer continues with their totally incorrect WHOIS data, making it impossible to take any defensive action because he has the protection of his ISP, Registrar, RIR and ICANN. What makes me impressed is how all of you treat the complaints, as if we were all morons. Your behavior is exactly like the behavior of most ISPs when receiving spam and scam complaints. Greed and lack of ethics in protecting spammers and scammers, to increase traffic on the internet, has no limits. You... (truncated). And you survive because you have the protection of your governments that are, as a rule, run by corrupt politicians. Thanks for nothing Marilson ******************************************************************************************************************************* From: compliance-tickets at icann.org Sent: Monday, July 17, 2017 11:43 PM To: marilson.mapa at gmail.com Subject: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Dear Marilson, Thank you for submitting a Whois Inaccuracy complaint concerning the domain name boasvendas.info. ICANN has reviewed and closed your complaint because: - Based on the current Whois data, the domain was suspended when the complaint was received by ICANN, or the registrar demonstrated that it took reasonable steps to investigate the Whois inaccuracy claim by suspending, deleting, cancelling or otherwise deactivating the domain name. ICANN considers this matter now closed. Please do not reply to the email. If you require future assistance, please email compliance at icann.org; if you have a new complaint, please submit it at http://www.icann.org/resources/compliance/complaints . ICANN is requesting your feedback on this closed complaint. Please complete this optional survey at https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 . Sincerely, ICANN Contractual Compliance ############################################ The problem summary: Reporter Name: Marilson Reporter Email: marilson.mapa at gmail.com Domain being reported: boasvendas.info Time of submission/processing: Wed Jun 28 17:59:43 2017 Problem in whois block: Expiration Date --- Error in date: Nothing to report Problem in whois block: Technical Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registrant Contact --- Error in address: Incorrect address --- Error in name: Wrong person or entity --- Comment: Registrant ID: C205479611-LRMS Registrant Name: BenL. A. - FAKE ? DOESNOT EXIST Registrant Organization: ??? Registrant Street: Estrada J. C. - FAKE ? DOESNOT EXIST Registrant City: Curtume - FAKE ? DOESNOT EXIST Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 - FAKE ? DOESNOT EXIST Registrant Country: BR Registrant Phone: +55.4333566600 - FAKE ? DOESNOT EXIST He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registration Date --- Error in date: Nothing to report Problem in whois block: Administrative Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: Boasvendas.info is a spammer and someone want to keep him hidden from his victims. The whois at the time of processing is: REGISTRY WHOIS: Domain Name: BOASVENDAS.INFO Registry Domain ID: D503300000040848348-LRMS Registrar WHOIS Server: Registrar URL: http://www.wildwestdomains.com Updated Date: 2017-06-24T11:29:56Z Creation Date: 2017-06-19T21:44:52Z Registry Expiry Date: 2018-06-19T21:44:52Z Registrar Registration Expiration Date: Registrar: Wild West Domains, LLC Registrar IANA ID: 440 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Registry Registrant ID: C205479611-LRMS Registrant Name: BenL. A. Registrant Organization: Registrant Street: Estrada J. C. Registrant City: Curtume Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 Registrant Country: BR Registrant Phone: +55.4333566600 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: bouces1967 at gmail.com Registry Admin ID: C205479613-LRMS Admin Name: BenL. A. Admin Organization: Admin Street: Estrada J. C. Admin City: Curtume Admin State/Province: Sao Paulo Admin Postal Code: 18110000 Admin Country: BR Admin Phone: +55.4333566600 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: bouces1967 at gmail.com Registry Tech ID: C205479612-LRMS Tech Name: BenL. A. Tech Organization: Tech Street: Estrada J. C. Tech City: Curtume Tech State/Province: Sao Paulo Tech Postal Code: 18110000 Tech Country: BR Tech Phone: +55.4333566600 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: bouces1967 at gmail.com Registry Billing ID: C205479614-LRMS Billing Name: BenL. A. Billing Organization: Billing Street: Estrada J. C. Billing City: Curtume Billing State/Province: Sao Paulo Billing Postal Code: 18110000 Billing Country: BR Billing Phone: +55.4333566600 Billing Phone Ext: Billing Fax: Billing Fax Ext: Billing Email: bouces1967 at gmail.com Name Server: NS1.BOASVENDAS.INFO Name Server: NS2.BOASVENDAS.INFO DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of WHOIS database: 2017-06-28T17:59:03Z <<< For more information on Whois status codes, please visit https://icann.org/epp -------------------------------------------------------------------------------- That is it. Marilson ******************************************************************************************************************************* From: Owen DeLong Sent: Thursday, July 20, 2017 5:16 PM To: Pallieter Koopmans Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen > On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jul 21 07:23:18 2017 From: jcurran at arin.net (John Curran) Date: Fri, 21 Jul 2017 11:23:18 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Marilson - Please indicate whether you are in favor or opposed to the policy change being discussed, including any supporting reasoning. Thank you, /John John Curran President and CEO ARIN On 21 Jul 2017, at 12:45 AM, Marilson > wrote: Gentlemen, let me introduce practical elements into this "difficult and onerous" attitude, but ethical, on the tech and abuse contact requests. Let's see in practice how it works when organizations accept and disclose absolutely false data, and when questioned, they simply lie or ignore it. We have on one side a well-known and hated spammer, on the other an ISP who insists on ignoring the denunciations, norms and laws, protecting and maintaining the profits that this spammer provides. And above all an entity that is self-titled as the regulator of good practice on the internet: From: Marilson Sent: Wednesday, July 19, 2017 3:55 AM To: compliance at icann.org ; complaints at icann.org Cc: crain at icann.org ; tips at nytimes.com ; spam at uce.gov ; privacy at council.bbb.org ; iana at iana.org ; anonbrpt at anonymousbrasil.com Subject: Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Lie! The domain was not suspended and neither the Registrar or ISP suspended, deleted, cancelled or even deactivated the domain name. The spammer continues with their totally incorrect WHOIS data, making it impossible to take any defensive action because he has the protection of his ISP, Registrar, RIR and ICANN. What makes me impressed is how all of you treat the complaints, as if we were all morons. Your behavior is exactly like the behavior of most ISPs when receiving spam and scam complaints. Greed and lack of ethics in protecting spammers and scammers, to increase traffic on the internet, has no limits. You... (truncated). And you survive because you have the protection of your governments that are, as a rule, run by corrupt politicians. Thanks for nothing Marilson ******************************************************************************************************************************* From: compliance-tickets at icann.org Sent: Monday, July 17, 2017 11:43 PM To: marilson.mapa at gmail.com Subject: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Dear Marilson, Thank you for submitting a Whois Inaccuracy complaint concerning the domain name boasvendas.info. ICANN has reviewed and closed your complaint because: - Based on the current Whois data, the domain was suspended when the complaint was received by ICANN, or the registrar demonstrated that it took reasonable steps to investigate the Whois inaccuracy claim by suspending, deleting, cancelling or otherwise deactivating the domain name. ICANN considers this matter now closed. Please do not reply to the email. If you require future assistance, please email compliance at icann.org; if you have a new complaint, please submit it at http://www.icann.org/resources/compliance/complaints . ICANN is requesting your feedback on this closed complaint. Please complete this optional survey at https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 . Sincerely, ICANN Contractual Compliance ############################################ The problem summary: Reporter Name: Marilson Reporter Email: marilson.mapa at gmail.com Domain being reported: boasvendas.info Time of submission/processing: Wed Jun 28 17:59:43 2017 Problem in whois block: Expiration Date --- Error in date: Nothing to report Problem in whois block: Technical Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registrant Contact --- Error in address: Incorrect address --- Error in name: Wrong person or entity --- Comment: Registrant ID: C205479611-LRMS Registrant Name: BenL. A. - FAKE ? DOESNOT EXIST Registrant Organization: ??? Registrant Street: Estrada J. C. - FAKE ? DOESNOT EXIST Registrant City: Curtume - FAKE ? DOESNOT EXIST Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 - FAKE ? DOESNOT EXIST Registrant Country: BR Registrant Phone: +55.4333566600 - FAKE ? DOESNOT EXIST He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registration Date --- Error in date: Nothing to report Problem in whois block: Administrative Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: Boasvendas.info is a spammer and someone want to keep him hidden from his victims. The whois at the time of processing is: REGISTRY WHOIS: Domain Name: BOASVENDAS.INFO Registry Domain ID: D503300000040848348-LRMS Registrar WHOIS Server: Registrar URL: http://www.wildwestdomains.com Updated Date: 2017-06-24T11:29:56Z Creation Date: 2017-06-19T21:44:52Z Registry Expiry Date: 2018-06-19T21:44:52Z Registrar Registration Expiration Date: Registrar: Wild West Domains, LLC Registrar IANA ID: 440 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Registry Registrant ID: C205479611-LRMS Registrant Name: BenL. A. Registrant Organization: Registrant Street: Estrada J. C. Registrant City: Curtume Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 Registrant Country: BR Registrant Phone: +55.4333566600 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: bouces1967 at gmail.com Registry Admin ID: C205479613-LRMS Admin Name: BenL. A. Admin Organization: Admin Street: Estrada J. C. Admin City: Curtume Admin State/Province: Sao Paulo Admin Postal Code: 18110000 Admin Country: BR Admin Phone: +55.4333566600 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: bouces1967 at gmail.com Registry Tech ID: C205479612-LRMS Tech Name: BenL. A. Tech Organization: Tech Street: Estrada J. C. Tech City: Curtume Tech State/Province: Sao Paulo Tech Postal Code: 18110000 Tech Country: BR Tech Phone: +55.4333566600 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: bouces1967 at gmail.com Registry Billing ID: C205479614-LRMS Billing Name: BenL. A. Billing Organization: Billing Street: Estrada J. C. Billing City: Curtume Billing State/Province: Sao Paulo Billing Postal Code: 18110000 Billing Country: BR Billing Phone: +55.4333566600 Billing Phone Ext: Billing Fax: Billing Fax Ext: Billing Email: bouces1967 at gmail.com Name Server: NS1.BOASVENDAS.INFO Name Server: NS2.BOASVENDAS.INFO DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of WHOIS database: 2017-06-28T17:59:03Z <<< For more information on Whois status codes, please visit https://icann.org/epp ________________________________ That is it. Marilson ******************************************************************************************************************************* From: Owen DeLong Sent: Thursday, July 20, 2017 5:16 PM To: Pallieter Koopmans Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen > On Jul 19, 2017, at 23:48 , Pallieter Koopmans > wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abagrin at mydigitalshield.com Fri Jul 21 07:23:48 2017 From: abagrin at mydigitalshield.com (Andrew Bagrin) Date: Fri, 21 Jul 2017 07:23:48 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Wow, what did I miss? I hope we?re not trying solve a security problem through a strict requirement of SWIP or anything that we?re doing. I hate to break it to everyone, but bad guys always find another way around and don?t really care about following any rules we create. We should be more focused on what makes sense and will benefit the general population when used correctly. As soon as ARIN decides to do something for ?security? and that enforcement is ?worked around?, ARIN will be looked at as a failure. As long the tool is available and all ISP are motivated to use it properly, it will work in general. There will always be exceptions. (fake entries etc..) some for bad reasons (like spammers) and some for good reasons (anonymity). I?m good with any of the proposed. I would like to see more SWIP occurring and motivate ISP?s to do it by default unless the customer specifies they do not want their info tied to that IP address (commercial and residential). *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of * Marilson *Sent:* Friday, July 21, 2017 12:46 AM *To:* Owen DeLong ; Pallieter Koopmans < Pallieter at pallieter.org> *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Gentlemen, let me introduce practical elements into this "difficult and onerous" attitude, but ethical, on the tech and abuse contact requests. Let's see in practice how it works when organizations accept and disclose absolutely false data, and when questioned, they simply lie or ignore it. We have on one side a well-known and hated spammer, on the other an ISP who insists on ignoring the denunciations, norms and laws, protecting and maintaining the profits that this spammer provides. And above all an entity that is self-titled as the regulator of good practice on the internet: *From:* Marilson *Sent:* Wednesday, July 19, 2017 3:55 AM *To:* compliance at icann.org ; complaints at icann.org *Cc:* crain at icann.org ; tips at nytimes.com ; spam at uce.gov ; privacy at council.bbb.org ; iana at iana.org ; anonbrpt at anonymousbrasil.com *Subject:* Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Lie! The domain was not suspended and neither the Registrar or ISP suspended, deleted, cancelled or even deactivated the domain name. The spammer continues with their totally incorrect WHOIS data, making it impossible to take any defensive action because he has the protection of his ISP, Registrar, RIR and ICANN. What makes me impressed is how all of you treat the complaints, as if we were all morons. Your behavior is exactly like the behavior of most ISPs when receiving spam and scam complaints. Greed and lack of ethics in protecting spammers and scammers, to increase traffic on the internet, has no limits. You... (truncated). And you survive because you have the protection of your governments that are, as a rule, run by corrupt politicians. Thanks for nothing Marilson ******************************************************************************************************************************* *From:* compliance-tickets at icann.org *Sent:* Monday, July 17, 2017 11:43 PM *To:* marilson.mapa at gmail.com *Subject:* [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Dear Marilson, Thank you for submitting a Whois Inaccuracy complaint concerning the domain name boasvendas.info. ICANN has reviewed and closed your complaint because: - Based on the current Whois data, the domain was suspended when the complaint was received by ICANN, or the registrar demonstrated that it took reasonable steps to investigate the Whois inaccuracy claim by suspending, deleting, cancelling or otherwise deactivating the domain name. ICANN considers this matter now closed. Please do not reply to the email. If you require future assistance, please email compliance at icann.org; if you have a new complaint, please submit it at http://www.icann.org/resources/compliance/complaints . ICANN is requesting your feedback on this closed complaint. Please complete this optional survey at https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 . Sincerely, ICANN Contractual Compliance ############################################ The problem summary: Reporter Name: Marilson Reporter Email: marilson.mapa at gmail.com Domain being reported: boasvendas.info Time of submission/processing: Wed Jun 28 17:59:43 2017 Problem in whois block: Expiration Date --- Error in date: Nothing to report Problem in whois block: Technical Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registrant Contact --- Error in address: Incorrect address --- Error in name: Wrong person or entity --- Comment: Registrant ID: C205479611-LRMS Registrant Name: BenL. A. - FAKE ? DOESNOT EXIST Registrant Organization: ??? Registrant Street: Estrada J. C. - FAKE ? DOESNOT EXIST Registrant City: Curtume - FAKE ? DOESNOT EXIST Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 - FAKE ? DOESNOT EXIST Registrant Country: BR Registrant Phone: +55.4333566600 - FAKE ? DOESNOT EXIST He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registration Date --- Error in date: Nothing to report Problem in whois block: Administrative Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: Boasvendas.info is a spammer and someone want to keep him hidden from his victims. The whois at the time of processing is: REGISTRY WHOIS: Domain Name: BOASVENDAS.INFO Registry Domain ID: D503300000040848348-LRMS Registrar WHOIS Server: Registrar URL: http://www.wildwestdomains.com Updated Date: 2017-06-24T11:29:56Z Creation Date: 2017-06-19T21:44:52Z Registry Expiry Date: 2018-06-19T21:44:52Z Registrar Registration Expiration Date: Registrar: Wild West Domains, LLC Registrar IANA ID: 440 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Registry Registrant ID: C205479611-LRMS Registrant Name: BenL. A. Registrant Organization: Registrant Street: Estrada J. C. Registrant City: Curtume Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 Registrant Country: BR Registrant Phone: +55.4333566600 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: bouces1967 at gmail.com Registry Admin ID: C205479613-LRMS Admin Name: BenL. A. Admin Organization: Admin Street: Estrada J. C. Admin City: Curtume Admin State/Province: Sao Paulo Admin Postal Code: 18110000 Admin Country: BR Admin Phone: +55.4333566600 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: bouces1967 at gmail.com Registry Tech ID: C205479612-LRMS Tech Name: BenL. A. Tech Organization: Tech Street: Estrada J. C. Tech City: Curtume Tech State/Province: Sao Paulo Tech Postal Code: 18110000 Tech Country: BR Tech Phone: +55.4333566600 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: bouces1967 at gmail.com Registry Billing ID: C205479614-LRMS Billing Name: BenL. A. Billing Organization: Billing Street: Estrada J. C. Billing City: Curtume Billing State/Province: Sao Paulo Billing Postal Code: 18110000 Billing Country: BR Billing Phone: +55.4333566600 Billing Phone Ext: Billing Fax: Billing Fax Ext: Billing Email: bouces1967 at gmail.com Name Server: NS1.BOASVENDAS.INFO Name Server: NS2.BOASVENDAS.INFO DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of WHOIS database: 2017-06-28T17:59:03Z <<< For more information on Whois status codes, please visit https://icann.org/epp ------------------------------ That is it. Marilson ******************************************************************************************************************************* *From:* Owen DeLong *Sent:* Thursday, July 20, 2017 5:16 PM *To:* Pallieter Koopmans *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen > On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri Jul 21 11:33:11 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 21 Jul 2017 11:33:11 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-7: Retire Obsolete Section 4 From the NRPM In-Reply-To: <93E78F44-1CAC-4288-B754-400B32A02A36@delong.com> References: <59495DF4.8010504@arin.net> <87C4D045-3C6D-4C28-BCA8-70DD64D04F71@semihuman.com> <93E78F44-1CAC-4288-B754-400B32A02A36@delong.com> Message-ID: I started looking at syncing the 2 sections, but I found the sections are not as much in sync as it was suggested, and my attempts to refer one to the other were not that successful. For example, 8.5.4 Initial block appears to refer to the similar section 4 passage 4.2.2, which is much more detailed than the section 8 passage. Section 8.5.3 specifies the minimum block to be transfered while 4.2.1.5 talks of the minimum block to be allocated. Both are /24. They are similar but not the same, so no real opportunity here. Section 4.2.2 specifies a 24 month window of utilization, whereas 8.5.6 the similar passage has no time standard. Other passages that I checked do not line up as well as these examples. I tried to figure how to line up and simplify the two sections, but it really is not going to be that easy. And as pointed out, there are micro allocations and v6 blocks that are not addressed in section 8. SWIP and reassignment rules are not addressed in section 8 as well, so regardless of effort, these parts of section 4 would need to remain. I suggest that we wait to a future time when v4 might not be used much at all before suggesting removal of section 4. I vote to abandon. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 20 Jul 2017, Owen DeLong wrote: > >> On Jul 17, 2017, at 12:32 , Chris Woodfield wrote: >> >> Hello, >> >> Reviving the thread on Draft Policy ARIN-2017-7. So far, the community response to the proposal in its current state appears to be universally negative. >> >> Having read the comments on this proposal, it could be plausible that an alternate solution to the problem statement could be that in lieu of retiring most of the section, specific sections could be substantially simplified by pointing to the currently-duplicated clauses in Section 6, eliminating the need to manually keep these sections in sync by applying similar policy to both where warranted (in particular, the sections around utilization justification seem like the best candidates). > > I think you mean section 8 as section 6 applies to IPv6 policy and would be absurd if applied to IPv4. > >> Does the community feel that this is a viable route to explore, which would simplify Section 4 while keeping the necessary relevant sections, in lieu of the original proposal? > > Perhaps. Or perhaps we just abandon this proposal. > > Owen > >> >> Thanks, >> >> -Chris >> >>> On Jun 21, 2017, at 12:16 PM, Austin Murkland > wrote: >>> >>> I do not support this policy for the reasons Kevin and Albert outlined. This seems a bit premature. >>> >>> Thanks, >>> >>> Austin Murkland >>> >>> On Tue, Jun 20, 2017 at 1:40 PM, ARIN > wrote: >>> On 15 June 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-242: Retire Obsolete Section 4 From the NRPM" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-7 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_7.html >>> >>> 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-7: Retire Obsolete Section 4 from the NRPM >>> >>> Problem Statement: >>> >>> Since IPv4 free pool exhaustion, policy focus has shifted to transfers. The community elected, instead of revamping and modernizing section 4 in light of this to, instead, recreate the relevant parts of section 4 in section 8.5. As a result, section 4 is generally obsolete and can be mostly retired. Since some small amounts of space do occasionally recreate the free pool, a mechanism for addressing this must remain and therefore a much reduced section 4 is proposed here instead of outright retirement. >>> >>> Policy statement: >>> >>> Replace section 4 of the NRPM with the following: >>> >>> 4. IPv4 >>> >>> 4.1 IPv4 Requests >>> >>> 4.1.1 Any new requests for IPv4 addresses allocated or assigned by ARIN shall be evaluated based on the criteria for transfer recipients contained in section 8.5. >>> >>> 4.1.2 Any approved requests which cannot be met from the ARIN free pool shall be handled according to section 4.2. >>> >>> 4.2 Unmet requests >>> >>> In the event that ARIN does not have a contiguous block of addresses of sufficient size to fulfill a qualified request, ARIN will provide the requesting organization with the option to specify the smallest block size they'd be willing to accept, equal to or larger than the applicable minimum size specified elsewhere in ARIN policy. If such a smaller block is available, ARIN will fulfill the request with the largest single block available that fulfills the request. If no such block is available, the organization will be provided the option to be placed on a waiting list of pre-qualified recipients, listing both the block size qualified for and the smallest block size acceptable. >>> >>> Repeated requests are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. >>> >>> Qualified requesters whose request cannot be immediately met will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. >>> >>> 4.2.1. Waiting list >>> >>> The position of each qualified request on the waiting list will be determined by the date it was approved. Each organization may have one approved request on the waiting list at a time. >>> >>> 4.2.2. Fulfilling unmet needs >>> >>> As address blocks become available for allocation, ARIN will fulfill requests on a first-approved basis, subject to the size of each available address block and a timely re-validation of the original request. Requests will not be partially filled. Any requests met through a transfer will be considered fulfilled and removed from the waiting list. >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> _______________________________________________ >>> 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. >> >> _______________________________________________ >> 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. > > From lsawyer at gci.com Fri Jul 21 12:44:12 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 21 Jul 2017 16:44:12 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri Jul 21 12:55:56 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 21 Jul 2017 12:55:56 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: This is a good rewrite of this, and you can count me in favor. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 21 Jul 2017, Leif Sawyer 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 > > From scottleibrand at gmail.com Fri Jul 21 13:34:40 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 21 Jul 2017 10:34:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: This looks good: I support. For clarity, so we don't all have to do it, and to help make sure we're not missing anything, here's what the resulting 6.5.5 looks like after modification: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /47 or more addresses, or sub-delegation 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 4.2.3.7.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. -Scott On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Fri Jul 21 16:58:36 2017 From: pmcnary at cameron.net (Paul McNary) Date: Fri, 21 Jul 2017 15:58:36 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: <48c5d8f0-820f-7c21-6e9c-a4c850b940ab@cameron.net> Leif While not a committee member, this is tolerable and workable. We can assign a /48 to every tower (POP) and that will geo locate good enough for the rural area. Geo location by address doesn't work that well in our rural area anyhow. Can be miles off. But using tower location will get it into less than 10 mile geo location. One comment is that most providers that I have dealt with are very reluctant to swip anything less than an IPv4 /24. This no longer affects me because these providers are in the process of reclaiming their IP space when we shifted to fiber. One was nice and one wasn't, but we basically had to shift all customers to NAT since we didn't make it in time to get our own IPv4 allocation. Getting an IPv6 allocation is waiting on our fiber provider providing dual stack and the issues you are some what addressing in this current policy making. Thanks Paul McNary pmcnary at cameron.net On 7/21/2017 11:44 AM, Leif Sawyer 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Fri Jul 21 17:00:06 2017 From: pmcnary at cameron.net (Paul McNary) Date: Fri, 21 Jul 2017 16:00:06 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: +1 On 7/21/2017 12:34 PM, Scott Leibrand wrote: > This looks good: I support. > > For clarity, so we don't all have to do it, and to help make sure > we're not missing anything, here's what the resulting 6.5.5 looks like > after modification: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to assignment histories, showing their efficient use. > > 6.5.5.1. Reassignment information > > Each static IPv6 assignment containing a /47 or more addresses, or > sub-delegation 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 4.2.3.7.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. > > -Scott > > On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer > 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. > > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 3johnl at gmail.com Fri Jul 21 23:31:44 2017 From: 3johnl at gmail.com (John Springer) Date: Fri, 21 Jul 2017 20:31:44 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: I support this Draft Policy as re-written. I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern. To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. John Springer On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Sat Jul 22 00:15:41 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 21 Jul 2017 21:15:41 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: > On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: > > I support this Draft Policy as re-written. > > I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern. > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. That's not what it says. It says /48s (or longer) should be individually SWIPped if they're going to be announced. Otherwise there's no reason for the extra clause. Blocks in the GRT need to be SWIPped to the announcing party if that's a different organization from the holder of the larger block. -Scott > >> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Sat Jul 22 08:56:51 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sat, 22 Jul 2017 08:56:51 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: Even though the /49, /50 ... /128 is technically covered by the "any size" language, for all practical purposes /48 or more is all that can be advertised, as nothing smaller than a /48 is contained in the GRT. Thus, your perception that it covers only sub-delegations of /48 or more is correct. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 21 Jul 2017, Scott Leibrand wrote: >> On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: >> >> I support this Draft Policy as re-written. >> >> I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern. >> >> To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. > > That's not what it says. It says /48s (or longer) should be individually SWIPped if they're going to be announced. Otherwise there's no reason for the extra clause. > > Blocks in the GRT need to be SWIPped to the announcing party if that's a different organization from the holder of the larger block. > > -Scott > >> >>> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. >> >> _______________________________________________ >> 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. > From marilson.mapa at gmail.com Sun Jul 23 03:39:07 2017 From: marilson.mapa at gmail.com (Marilson) Date: Sun, 23 Jul 2017 04:39:07 -0300 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <548334F38A45401280C2A46E1C9A193D@xPC> John, I'm in favor and opposed to the policy change being discussed. Simply because, what will be implemented, will certainly not address my concerns. On July 21, 2017 8:23 AM Andrew Bagrin wrote: "I hope we?re not trying solve a security problem..." "As soon as ARIN decides to do something for "security" and that enforcement is "worked around", ARIN will be looked at as a failure." Andrew, do not worry. Your business will continue to sell security. I do not intend to compete with your company. And certainly ARIN will never be your competitor. As a rule I seek protection against your bad customers, if you has some. Cheers Marilson From: John Curran Sent: Friday, July 21, 2017 8:23 AM To: Marilson Cc: mailto:arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 Marilson - Please indicate whether you are in favor or opposed to the policy change being discussed, including any supporting reasoning. Thank you, /John John Curran President and CEO ARIN On 21 Jul 2017, at 12:45 AM, Marilson wrote: Gentlemen, let me introduce practical elements into this "difficult and onerous" attitude, but ethical, on the tech and abuse contact requests. Let's see in practice how it works when organizations accept and disclose absolutely false data, and when questioned, they simply lie or ignore it. We have on one side a well-known and hated spammer, on the other an ISP who insists on ignoring the denunciations, norms and laws, protecting and maintaining the profits that this spammer provides. And above all an entity that is self-titled as the regulator of good practice on the internet: From: Marilson Sent: Wednesday, July 19, 2017 3:55 AM To: compliance at icann.org ; complaints at icann.org Cc: crain at icann.org ; tips at nytimes.com ; spam at uce.gov ; privacy at council.bbb.org ; iana at iana.org ; anonbrpt at anonymousbrasil.com Subject: Fw: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Lie! The domain was not suspended and neither the Registrar or ISP suspended, deleted, cancelled or even deactivated the domain name. The spammer continues with their totally incorrect WHOIS data, making it impossible to take any defensive action because he has the protection of his ISP, Registrar, RIR and ICANN. What makes me impressed is how all of you treat the complaints, as if we were all morons. Your behavior is exactly like the behavior of most ISPs when receiving spam and scam complaints. Greed and lack of ethics in protecting spammers and scammers, to increase traffic on the internet, has no limits. You... (truncated). And you survive because you have the protection of your governments that are, as a rule, run by corrupt politicians. Thanks for nothing Marilson ******************************************************************************************************************************* From: compliance-tickets at icann.org Sent: Monday, July 17, 2017 11:43 PM To: marilson.mapa at gmail.com Subject: [#HTK-505-74506]: Whois Inaccuracy complaint re: boasvendas.info closed Dear Marilson, Thank you for submitting a Whois Inaccuracy complaint concerning the domain name boasvendas.info. ICANN has reviewed and closed your complaint because: - Based on the current Whois data, the domain was suspended when the complaint was received by ICANN, or the registrar demonstrated that it took reasonable steps to investigate the Whois inaccuracy claim by suspending, deleting, cancelling or otherwise deactivating the domain name. ICANN considers this matter now closed. Please do not reply to the email. If you require future assistance, please email compliance at icann.org; if you have a new complaint, please submit it at http://www.icann.org/resources/compliance/complaints . ICANN is requesting your feedback on this closed complaint. Please complete this optional survey at https://www.surveymonkey.com/s/8F2Z6DP?ticket=HTK-505-74506 . Sincerely, ICANN Contractual Compliance ############################################ The problem summary: Reporter Name: Marilson Reporter Email: marilson.mapa at gmail.com Domain being reported: boasvendas.info Time of submission/processing: Wed Jun 28 17:59:43 2017 Problem in whois block: Expiration Date --- Error in date: Nothing to report Problem in whois block: Technical Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registrant Contact --- Error in address: Incorrect address --- Error in name: Wrong person or entity --- Comment: Registrant ID: C205479611-LRMS Registrant Name: BenL. A. - FAKE ? DOESNOT EXIST Registrant Organization: ??? Registrant Street: Estrada J. C. - FAKE ? DOESNOT EXIST Registrant City: Curtume - FAKE ? DOESNOT EXIST Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 - FAKE ? DOESNOT EXIST Registrant Country: BR Registrant Phone: +55.4333566600 - FAKE ? DOESNOT EXIST He is a spammer and someone want to keep him hidden from his victims. Problem in whois block: Registration Date --- Error in date: Nothing to report Problem in whois block: Administrative Contact --- Error in address: Incorrect address --- Error in phone number: Incorrect phone --- Error in name: Wrong person or entity --- Error in email: Nothing to report --- Error in fax number: Fax is missing --- Comment: Boasvendas.info is a spammer and someone want to keep him hidden from his victims. The whois at the time of processing is: REGISTRY WHOIS: Domain Name: BOASVENDAS.INFO Registry Domain ID: D503300000040848348-LRMS Registrar WHOIS Server: Registrar URL: http://www.wildwestdomains.com Updated Date: 2017-06-24T11:29:56Z Creation Date: 2017-06-19T21:44:52Z Registry Expiry Date: 2018-06-19T21:44:52Z Registrar Registration Expiration Date: Registrar: Wild West Domains, LLC Registrar IANA ID: 440 Registrar Abuse Contact Email: Registrar Abuse Contact Phone: Reseller: Domain Status: clientDeleteProhibited https://icann.org/epp#clientDeleteProhibited Domain Status: clientRenewProhibited https://icann.org/epp#clientRenewProhibited Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited Domain Status: clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited Domain Status: serverTransferProhibited https://icann.org/epp#serverTransferProhibited Registry Registrant ID: C205479611-LRMS Registrant Name: BenL. A. Registrant Organization: Registrant Street: Estrada J. C. Registrant City: Curtume Registrant State/Province: Sao Paulo Registrant Postal Code: 18110000 Registrant Country: BR Registrant Phone: +55.4333566600 Registrant Phone Ext: Registrant Fax: Registrant Fax Ext: Registrant Email: bouces1967 at gmail.com Registry Admin ID: C205479613-LRMS Admin Name: BenL. A. Admin Organization: Admin Street: Estrada J. C. Admin City: Curtume Admin State/Province: Sao Paulo Admin Postal Code: 18110000 Admin Country: BR Admin Phone: +55.4333566600 Admin Phone Ext: Admin Fax: Admin Fax Ext: Admin Email: bouces1967 at gmail.com Registry Tech ID: C205479612-LRMS Tech Name: BenL. A. Tech Organization: Tech Street: Estrada J. C. Tech City: Curtume Tech State/Province: Sao Paulo Tech Postal Code: 18110000 Tech Country: BR Tech Phone: +55.4333566600 Tech Phone Ext: Tech Fax: Tech Fax Ext: Tech Email: bouces1967 at gmail.com Registry Billing ID: C205479614-LRMS Billing Name: BenL. A. Billing Organization: Billing Street: Estrada J. C. Billing City: Curtume Billing State/Province: Sao Paulo Billing Postal Code: 18110000 Billing Country: BR Billing Phone: +55.4333566600 Billing Phone Ext: Billing Fax: Billing Fax Ext: Billing Email: bouces1967 at gmail.com Name Server: NS1.BOASVENDAS.INFO Name Server: NS2.BOASVENDAS.INFO DNSSEC: unsigned URL of the ICANN Whois Inaccuracy Complaint Form: https://www.icann.org/wicf/ >>> Last update of WHOIS database: 2017-06-28T17:59:03Z <<< For more information on Whois status codes, please visit https://icann.org/epp -------------------------------------------------------------------------------- That is it. Marilson ******************************************************************************************************************************* From: Owen DeLong Sent: Thursday, July 20, 2017 5:16 PM To: Pallieter Koopmans Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen > On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jul 23 08:25:31 2017 From: bill at herrin.us (William Herrin) Date: Sun, 23 Jul 2017 08:25:31 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <548334F38A45401280C2A46E1C9A193D@xPC> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <548334F38A45401280C2A46E1C9A193D@xPC> Message-ID: For the record, I continue to support changing current policy (all IPv6 reassignments are SWIPed) to allow ISP reassignments of /56 to /128 to be made without processing a SWIP entry while continuing to require assignments of /0 to /55 be SWIPed. I remain unconvinced by the more complicated proposals and outright oppose permitting /48 reassignments to be made without SWIP under any circumstances. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Sun Jul 23 08:34:29 2017 From: bill at herrin.us (William Herrin) Date: Sun, 23 Jul 2017 08:34:29 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: On Fri, Jul 21, 2017 at 12:44 PM, Leif Sawyer wrote: > 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 > I OPPOSE this policy as written. 1. Blocks large enough to independently route on the Internet under current operations best practice should not be assignable without publishing the holder's identity. 2. It is not general practice to review the address assignment upon changing the routing segment except to the extent of verifying the a routable-size block was assigned. Probability of non-compliance even by those who intend to comply is high. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Sun Jul 23 10:02:42 2017 From: farmer at umn.edu (David Farmer) Date: Sun, 23 Jul 2017 09:02:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: 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 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> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Sun Jul 23 14:23:06 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sun, 23 Jul 2017 14:23:06 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: Boy, am I learning from this process. Please let me know if I am not defining these terms we are discussing below properly: Allocation: Directly receiving a block of IP addresses from ARIN. Re-Allocation: Taking part of an Allocation from ARIN, and permitting another ISP/LIR to use this block for assignment to their end user customers. Assignment: When the original ARIN blockholder assigns a block from their allocation to an end user customer for their use in networks, OR when another ISP without an ARIN allocation for the original block (re-allocation), assigns a portion of their re-allocation to the end user customers. Reassignment: A superset of all the cases of Assignment, as well as all the cases of Re-allocation, which is not currently defined in the NRPM. 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. 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 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> > =============================================== > From farmer at umn.edu Sun Jul 23 15:27:30 2017 From: farmer at umn.edu (David Farmer) Date: Sun, 23 Jul 2017 14:27:30 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: On Sun, Jul 23, 2017 at 1:23 PM, 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 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: From hostmaster at uneedus.com Sun Jul 23 16:48:43 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sun, 23 Jul 2017 16:48:43 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: I simply added the next number in the section labeled "definitions". You are right that it best fits into 2.5. In that case maybe 2.5's title should be changed to "Allocate, Assign and Reassignment" and the definition be added after Allocate and Assign. Albert Erdmann Network Administrator Paradise On Line Inc. On Sun, 23 Jul 2017, David Farmer wrote: > On Sun, Jul 23, 2017 at 1:23 PM, 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 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 > =============================================== > From 3johnl at gmail.com Sun Jul 23 23:35:47 2017 From: 3johnl at gmail.com (John Springer) Date: Sun, 23 Jul 2017 20:35:47 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: Thanks, Scott, Are we energetically agreeing? You scared me there for a second. /48s are excluded, unless they are part of a "subdelegation of any size that will be individually announced". Yes. How is that defined by the way? Will be individually announced in 2 years, 2 days, right now? On another matter, this problem statement has been making me uneasy all along, but because it was only required to be clear and in scope to be accepted as Draft Policy, it was not appropriate for me to object. This seems like as good a time as any to address some concerns, which are my opinions only. "Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments." This is a correct statement! It is not a problem however, nor is it sufficient motive for trying to solve a problem, per se. "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," Two facts. The second is undoubtedly a great pity, but to entangle these logically is a fallacy of inconsistency, specifically a false equivalence. These two facts are unrelated. It does not help the case to try to make them interdependent. And it is not needed. All that is being attempted is to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. "which constitutes one entire IPv6 subnet and is the minimum block size for an allocation." I think I'm looking at current text. How did this make it this far? One ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 to /128. What does that have to do with anything? And, yeah, the SWIP boundary being the so called "minimum" allocation seems broken, but that is its own thing. "There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption." Possibly true, but irrelevant. There is no technical or policy rationale for them being alike either, nor is there any reason to suppose that if they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for V6. Concentrate on that. We can make policy for V6 without needing to refer to V4. "The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences." With respect, it is not. The disparity does not qualify as a logical motive. The brokenness of SWIPing /64s does not require injustice and if /64 SWIPing is a deterrent to V6 adoption, that is its own good and sufficient reason. If you had to refer to an analogy, you could say, "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". So all you need is: Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this proposal is to pick a different number. 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.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" BUT. These observations do not appear to have any effect one way or the other on the policy text. To me, picking a different number does not have anything to do with disparity, but so what? Changing the IPV6 SWIP threshold is not unfair and partial if someone makes unfounded assertions regarding linkages between v4 and V6. And it is not technically unsound to make fallacious observations if they are kind of orthogonal to the meat of the matter. So, still support. I'd rather see it simpler, but I guess I can tolerate a little hand waving. Writing solely on my own behalf, John Springer On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand wrote: > On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: > > I support this Draft Policy as re-written. > > I shared the author's distaste for the requirement that IPV6 /64s be > SWIP'd, but was not reassured when the discussion veered to consider > prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to > apply for their allocations based on the idea of assigning a /48 to each > 'customer' to provide room for unknown technologies, among other things. I > did not wish to endanger that premise, but current language appears to moot > that concern. > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any > size that will be individually announced," refers to /47s, /46s, /45s ... > and not /48s, /49s, /50s, etc. > > > That's not what it says. It says /48s (or longer) should be individually > SWIPped if they're going to be announced. Otherwise there's no reason for > the extra clause. > > Blocks in the GRT need to be SWIPped to the announcing party if that's a > different organization from the holder of the larger block. > > -Scott > > > On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. >> > > _______________________________________________ > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Jul 24 01:10:54 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Sun, 23 Jul 2017 22:10:54 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> No. It says: Each static IPv6 assignment containing a /47 or more addresses, or sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory I read that as: Each static IPv6 assignment containing a /47 or more addresses, and each sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory So a /48 sub-delegation shall be registered if it will be individually announced. You said: > To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. That entire quoted clause refers to /48s (or longer, if such becomes possible) that will be individually announced. So your clarification, as originally stated, does not match my reading of the text. However, it now sounds like that's not what you meant, and you were trying to say: > To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. If that's what you actually meant, then yes, that is the way to read "more": as equivalent to "/47 or shorter". Leif, it seems like we have some potential ambiguity in the new text as to whether "or sub-delegation of any size" is part of the subject of the sentence, or a subordinate clause to "containing". Does my rewrite above clarify your intent? Or were you intending it to mean "Each static IPv6 assignment containing a ... sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory"? That interpretation makes no sense to me, as the sub-delegation clause would be redundant. So if that's what you meant, I'd appreciate some clarity on what it is intended to accomplish. Scott > On Jul 23, 2017, at 8:35 PM, John Springer <3johnl at gmail.com> wrote: > > Thanks, Scott, > > Are we energetically agreeing? You scared me there for a second. /48s are excluded, unless they are part of a "subdelegation of any size that will be individually announced". Yes. > > How is that defined by the way? Will be individually announced in 2 years, 2 days, right now? > > On another matter, this problem statement has been making me uneasy all along, but because it was only required to be clear and in scope to be accepted as Draft Policy, it was not appropriate for me to object. This seems like as good a time as any to address some concerns, which are my opinions only. > > "Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments." > > This is a correct statement! It is not a problem however, nor is it sufficient motive for trying to solve a problem, per se. > > "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," > > Two facts. The second is undoubtedly a great pity, but to entangle these logically is a fallacy of inconsistency, specifically a false equivalence. These two facts are unrelated. It does not help the case to try to make them interdependent. And it is not needed. All that is being attempted is to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. > > "which constitutes one entire IPv6 subnet and is the minimum block size for an allocation." > > I think I'm looking at current text. How did this make it this far? One ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 to /128. What does that have to do with anything? And, yeah, the SWIP boundary being the so called "minimum" allocation seems broken, but that is its own thing. > > "There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption." > > Possibly true, but irrelevant. There is no technical or policy rationale for them being alike either, nor is there any reason to suppose that if they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for V6. Concentrate on that. We can make policy for V6 without needing to refer to V4. > > "The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences." > > With respect, it is not. The disparity does not qualify as a logical motive. The brokenness of SWIPing /64s does not require injustice and if /64 SWIPing is a deterrent to V6 adoption, that is its own good and sufficient reason. If you had to refer to an analogy, you could say, "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". > > So all you need is: > > Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this proposal is to pick a different number. > > 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.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" > > BUT. These observations do not appear to have any effect one way or the other on the policy text. To me, picking a different number does not have anything to do with disparity, but so what? Changing the IPV6 SWIP threshold is not unfair and partial if someone makes unfounded assertions regarding linkages between v4 and V6. And it is not technically unsound to make fallacious observations if they are kind of orthogonal to the meat of the matter. > > So, still support. I'd rather see it simpler, but I guess I can tolerate a little hand waving. > > Writing solely on my own behalf, > > John Springer > >> On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand wrote: >>> On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: >>> >>> I support this Draft Policy as re-written. >>> >>> I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern. >>> >>> To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. >> >> That's not what it says. It says /48s (or longer) should be individually SWIPped if they're going to be announced. Otherwise there's no reason for the extra clause. >> >> Blocks in the GRT need to be SWIPped to the announcing party if that's a different organization from the holder of the larger block. >> >> -Scott >> >>> >>>> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. >>> >>> _______________________________________________ >>> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Mon Jul 24 07:03:54 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 24 Jul 2017 07:03:54 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> References: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> Message-ID: /47 or more addresses is intended to be /47, /46 ..... /1 and not the reverse. The current language is "/64 or more", and I read that same phrase as /64, /63 ..... /1. For comparison, the current IPv4 language is "/29 or more", and that seems clear to mean /29, /28 ..... /1, and not the reverse. I do not think the "/X or more" language in the current NRPM or the proposal is unclear. As far as the remainder, I read this draft as two statements connected with an OR. Thus there are 2 classes of assignments that are required to be SWIP'ed. They are: 1) ANY IPv6 assignment containing a /47 or more addresses. 2) ANY sub-delegation of any size that will be individually announced. Due to rules for the GRT, this means /49 or less is not covered by 2). However, should the rules for the GRT ever change, 2) will cover it. The intent of 2) is to require SWIP on ALL sub-delegations, without expressing that level, which is outside of ARIN control. I do agree that "will be" is a problem as to WHEN to SWIP. This is best corrected by changing that to "is". 6.5.5.2 the next section makes it clear that the time frame to SWIP is within 7 calendar days of the assignment being made. As far as John's comment, this proposal began with a suggestion that changed the v4 requirement as well, making both "more than 16" networks or IPv4 addresses. Since changing the v4 language from 8 addresses to more than 16 addresses was clearly not desired by the community, the v4 language was removed from the draft. The comments still reflect that the equality of the policy between v4 and v6 was the original idea. You are correct that this draft now is only about changing the v6 part. Are you suggesting that the older portions of description that are no longer in it, due to the community input needs to be removed? Albert Erdmann Network Administrator Paradise On Line Inc. On Sun, 23 Jul 2017, Scott Leibrand wrote: > No. It says: > > Each static IPv6 assignment containing a /47 or more addresses, or > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > I read that as: > > Each static IPv6 assignment containing a /47 or more addresses, and each > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > So a /48 sub-delegation shall be registered if it will be individually > announced. > > You said: >> To be explicit, to me, "/47 or more addresses, or sub-delegation of any >> size that will be individually announced," refers to /47s, /46s, /45s >> ... and not /48s, /49s, /50s, etc. > > > That entire quoted clause refers to /48s (or longer, if such becomes > possible) that will be individually announced. So your clarification, as > originally stated, does not match my reading of the text. However, it > now sounds like that's not what you meant, and you were trying to say: > >> To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, >> /45s ... and not /48s, /49s, /50s, etc. > > If that's what you actually meant, then yes, that is the way to read > "more": as equivalent to "/47 or shorter". > > > Leif, it seems like we have some potential ambiguity in the new text as > to whether "or sub-delegation of any size" is part of the subject of the > sentence, or a subordinate clause to "containing". Does my rewrite above > clarify your intent? Or were you intending it to mean "Each static IPv6 > assignment containing a ... sub-delegation of any size that will be > individually announced, shall be registered in the WHOIS directory"? > That interpretation makes no sense to me, as the sub-delegation clause > would be redundant. So if that's what you meant, I'd appreciate some > clarity on what it is intended to accomplish. > > Scott > >> On Jul 23, 2017, at 8:35 PM, John Springer <3johnl at gmail.com> wrote: >> >> Thanks, Scott, >> >> Are we energetically agreeing? You scared me there for a second. /48s >> are excluded, unless they are part of a "subdelegation of any size that >> will be individually announced". Yes. >> >> How is that defined by the way? Will be individually announced in 2 >> years, 2 days, right now? >> >> On another matter, this problem statement has been making me uneasy all >> along, but because it was only required to be clear and in scope to be >> accepted as Draft Policy, it was not appropriate for me to object. This >> seems like as good a time as any to address some concerns, which are my >> opinions only. >> >> "Current ARIN policy has different WHOIS directory registration >> requirements for IPv4 vs IPv6 address assignments." >> >> This is a correct statement! It is not a problem however, nor is it >> sufficient motive for trying to solve a problem, per se. >> >> "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," >> >> Two facts. The second is undoubtedly a great pity, but to entangle >> these logically is a fallacy of inconsistency, specifically a false >> equivalence. These two facts are unrelated. It does not help the case >> to try to make them interdependent. And it is not needed. All that is >> being attempted is to modify V6 SWIP requirements. Do that. And DO NOT >> settle on 8 subnets. >> >> "which constitutes one entire IPv6 subnet and is the minimum block size >> for an allocation." >> >> I think I'm looking at current text. How did this make it this far? One >> ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way >> from /0 to /128. What does that have to do with anything? And, yeah, >> the SWIP boundary being the so called "minimum" allocation seems >> broken, but that is its own thing. >> >> "There is no technical or policy rationale for the disparity, which >> could serve as a deterrent to more rapid IPv6 adoption." >> >> Possibly true, but irrelevant. There is no technical or policy >> rationale for them being alike either, nor is there any reason to >> suppose that if they were, folks would adopt V6 faster. SWIPing /64 is >> definitely wrong for V6. Concentrate on that. We can make policy for V6 >> without needing to refer to V4. >> >> "The purpose of this proposal is to eliminate the disparity and >> corresponding adverse consequences." >> >> With respect, it is not. The disparity does not qualify as a logical >> motive. The brokenness of SWIPing /64s does not require injustice and >> if /64 SWIPing is a deterrent to V6 adoption, that is its own good and >> sufficient reason. If you had to refer to an analogy, you could say, >> "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". >> >> So all you need is: >> >> Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of >> this proposal is to pick a different number. >> >> 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.3.1. "Residential Customer Privacy" of >> the NRPM by deleting the phrase "holding /64 and larger blocks" >> >> BUT. These observations do not appear to have any effect one way or the >> other on the policy text. To me, picking a different number does not >> have anything to do with disparity, but so what? Changing the IPV6 SWIP >> threshold is not unfair and partial if someone makes unfounded >> assertions regarding linkages between v4 and V6. And it is not >> technically unsound to make fallacious observations if they are kind of >> orthogonal to the meat of the matter. >> >> So, still support. I'd rather see it simpler, but I guess I can >> tolerate a little hand waving. >> >> Writing solely on my own behalf, >> >> John Springer >> >>> On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand >>> wrote: >>>> On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: >>>> >>>> I support this Draft Policy as re-written. >>>> >>>> I shared the author's distaste for the requirement that IPV6 /64s be >>>> SWIP'd, but was not reassured when the discussion veered to consider >>>> prefixes between /48 and /64. AFAIK, ISPs have long been encouraged >>>> to apply for their allocations based on the idea of assigning a /48 >>>> to each 'customer' to provide room for unknown technologies, among >>>> other things. I did not wish to endanger that premise, but current >>>> language appears to moot that concern. >>>> >>>> To be explicit, to me, "/47 or more addresses, or sub-delegation of >>>> any size that will be individually announced," refers to /47s, /46s, >>>> /45s ... and not /48s, /49s, /50s, etc. >>> >>> That's not what it says. It says /48s (or longer) should be >>> individually SWIPped if they're going to be announced. Otherwise >>> there's no reason for the extra clause. >>> >>> Blocks in the GRT need to be SWIPped to the announcing party if that's >>> a different organization from the holder of the larger block. >>> >>> -Scott >>> >>>> >>>>> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer >>>>> 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. >>>> >>>> _______________________________________________ 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. >> > From 3johnl at gmail.com Mon Jul 24 10:13:23 2017 From: 3johnl at gmail.com (John Springer) Date: Mon, 24 Jul 2017 07:13:23 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> References: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> Message-ID: Scott, thanks again. Yes, your precise reading is correct and welcome. As you may have discerned, my concerns with this matter reveal my small ISP priorities. When we got our /32 (2005) and to this day, the religious wars seemed to have settled on /48 as the 'default' assignment for customers. We had exactly one IPV4 /29 in our history. My approach to that situation was to plan to divide the /32 into logical subnets, assign those to our exchanges so that every customer got a /48 and retain one or more chunks to assign /40s or /44s out of, so that the customer could then also assign /48s out of them. I get that people want to announce /48s. Do what you wish to them. I am primarily concerned that my small concern is not SWIPing all of its customer /48s. So yes, I did omit the /48 announcement clause in my discussion, to focus on the precept of non-announced /48s not being required to SWIP. Thanks again for helping me clarifying that. John Springer On Sun, Jul 23, 2017 at 10:10 PM, Scott Leibrand wrote: > No. It says: > > Each static IPv6 assignment containing a /47 or more addresses, or > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > I read that as: > > Each static IPv6 assignment containing a /47 or more addresses, and each > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > So a /48 sub-delegation shall be registered if it will be individually > announced. > > You said: > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any > size that will be individually announced," refers to /47s, /46s, /45s ... > and not /48s, /49s, /50s, etc. > > > That entire quoted clause refers to /48s (or longer, if such becomes > possible) that will be individually announced. So your clarification, as > originally stated, does not match my reading of the text. However, it now > sounds like that's not what you meant, and you were trying to say: > > To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, /45s > ... and not /48s, /49s, /50s, etc. > > > If that's what you actually meant, then yes, that is the way to read > "more": as equivalent to "/47 or shorter". > > > Leif, it seems like we have some potential ambiguity in the new text as to > whether "or sub-delegation of any size" is part of the subject of the > sentence, or a subordinate clause to "containing". Does my rewrite above > clarify your intent? Or were you intending it to mean "Each static IPv6 > assignment containing a ... sub-delegation of any size that will be > individually announced, shall be registered in the WHOIS directory"? That > interpretation makes no sense to me, as the sub-delegation clause would be > redundant. So if that's what you meant, I'd appreciate some clarity on what > it is intended to accomplish. > > Scott > > On Jul 23, 2017, at 8:35 PM, John Springer <3johnl at gmail.com> wrote: > > Thanks, Scott, > > Are we energetically agreeing? You scared me there for a second. /48s are > excluded, unless they are part of a "subdelegation of any size that will be > individually announced". Yes. > > How is that defined by the way? Will be individually announced in 2 years, > 2 days, right now? > > On another matter, this problem statement has been making me uneasy all > along, but because it was only required to be clear and in scope to be > accepted as Draft Policy, it was not appropriate for me to object. This > seems like as good a time as any to address some concerns, which are my > opinions only. > > "Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments." > > This is a correct statement! It is not a problem however, nor is it > sufficient motive for trying to solve a problem, per se. > > "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," > > Two facts. The second is undoubtedly a great pity, but to entangle these > logically is a fallacy of inconsistency, specifically a false equivalence. > These two facts are unrelated. It does not help the case to try to make > them interdependent. And it is not needed. All that is being attempted is > to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. > > "which constitutes one entire IPv6 subnet and is the minimum block size > for an allocation." > > I think I'm looking at current text. How did this make it this far? One > ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 > to /128. What does that have to do with anything? And, yeah, the SWIP > boundary being the so called "minimum" allocation seems broken, but that is > its own thing. > > "There is no technical or policy rationale for the disparity, which could > serve as a deterrent to more rapid IPv6 adoption." > > Possibly true, but irrelevant. There is no technical or policy rationale > for them being alike either, nor is there any reason to suppose that if > they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for > V6. Concentrate on that. We can make policy for V6 without needing to refer > to V4. > > "The purpose of this proposal is to eliminate the disparity and > corresponding adverse consequences." > > With respect, it is not. The disparity does not qualify as a logical > motive. The brokenness of SWIPing /64s does not require injustice and if > /64 SWIPing is a deterrent to V6 adoption, that is its own good and > sufficient reason. If you had to refer to an analogy, you could say, > "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". > > So all you need is: > > Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this > proposal is to pick a different number. > > 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.3.1. "Residential Customer Privacy" of the > NRPM by deleting the phrase "holding /64 and larger blocks" > > BUT. These observations do not appear to have any effect one way or the > other on the policy text. To me, picking a different number does not have > anything to do with disparity, but so what? Changing the IPV6 SWIP > threshold is not unfair and partial if someone makes unfounded assertions > regarding linkages between v4 and V6. And it is not technically unsound to > make fallacious observations if they are kind of orthogonal to the meat of > the matter. > > So, still support. I'd rather see it simpler, but I guess I can tolerate > a little hand waving. > > Writing solely on my own behalf, > > John Springer > > On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand > wrote: > >> On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: >> >> I support this Draft Policy as re-written. >> >> I shared the author's distaste for the requirement that IPV6 /64s be >> SWIP'd, but was not reassured when the discussion veered to consider >> prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to >> apply for their allocations based on the idea of assigning a /48 to each >> 'customer' to provide room for unknown technologies, among other things. I >> did not wish to endanger that premise, but current language appears to moot >> that concern. >> >> To be explicit, to me, "/47 or more addresses, or sub-delegation of any >> size that will be individually announced," refers to /47s, /46s, /45s ... >> and not /48s, /49s, /50s, etc. >> >> >> That's not what it says. It says /48s (or longer) should be individually >> SWIPped if they're going to be announced. Otherwise there's no reason for >> the extra clause. >> >> Blocks in the GRT need to be SWIPped to the announcing party if that's a >> different organization from the holder of the larger block. >> >> -Scott >> >> >> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. >>> >> >> _______________________________________________ >> 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. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 3johnl at gmail.com Mon Jul 24 10:49:35 2017 From: 3johnl at gmail.com (John Springer) Date: Mon, 24 Jul 2017 07:49:35 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> Message-ID: "As far as John's comment, this proposal began with a suggestion that changed the v4 requirement as well, making both "more than 16" networks or IPv4 addresses. Since changing the v4 language from 8 addresses to more than 16 addresses was clearly not desired by the community, the v4 language was removed from the draft. The comments still reflect that the equality of the policy between v4 and v6 was the original idea. You are correct that this draft now is only about changing the v6 part. Are you suggesting that the older portions of description that are no longer in it, due to the community input needs to be removed?" Needs? No. The older parts of the problem statement referencing V4 and disparity are, in my view, vestigial and irrelevant at best, but do not actively disqualify the Draft Proposal from being technically sound and enabling fair and impartial number policy. It may be felt that the older parts need to remain to somehow entice further community support. I don't think that is optimum, but whatever. At this point, I think it would be cleaner to modify the Problem Statement and Author Comments to reflect only the current Policy statement intent, but that is not my decision. I am still, somewhat reluctantly, in support. John Springer -------------- next part -------------- An HTML attachment was scrubbed... URL: From theone at uneedus.com Fri Jul 21 03:09:21 2017 From: theone at uneedus.com (theone at uneedus.com) Date: Fri, 21 Jul 2017 03:09:21 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: As for discussion of SWIP for /48's, some have suggested since these are the recommended minimum assignment for an end site, /48 should not trigger SWIP unless independently routed. Others believe all /48's be SWIP'ed. Thus the two main ideas for this proposal currently are: 1) SWIP all independently routed (in the GRT) networks regardless of size but in actual fact they must be at least a /48 to be in the GRT, and all other assignments greater than a /48. This is the "b)" language using /47 from the other day. 2) SWIP every /48 regardless of routing, smaller are exempt. This is the "/48 or more" language. Since the standard site size is /48, this catches a lot of small sites that are not independently routed but avoids setting the policy based on routing. If this is chosen many ISP's are likely to choose giving out /52 or less instead of /48's. As pointed out by others, a major cable ISP in the US already gives out only a /60 with their prefix delegation server. Although like the mobile networks, they do have a current valid argument against SWIP, since these are not "static". We are in agreement that anything smaller than /48 including /56 should not require SWIP. I would be happy with either result, but am biased toward not requiring SWIP for /48 blocks not independently routed. The inequality between v4 and v6 is why I drafted this proposal. The bus network I speak of operates today using a single static v4 address per bus. The wireless provider will no longer provide static v4 after the contract ends next year. There are currently two RFC1918 v4 subnets on each bus, one for administrative, and one for wifi. and each device on the bus is accessable from headquarters via forwarded ports from the bus router's static v4. There has never been a SWIP requirement for having a single static v4 address. Now that we want to change the bus administrative network to v6 for lack of v4 static assignments from the contract wireless provider, we run into the ARIN 100% SWIP registration requirement of /64 or more in NRPM 6.5.5.1. as v6 does not use NAT. The policy of /64 or more is what I seek to change, to allow smaller v6 networks, like these busses to avoid a SWIP requirement. Switching the same size network with the same number of hosts from v4 to v6 should not change the SWIP requirement, but current policy does. This is where the debate is, where to draw that line. The thing to remember is that currently a /48, according to the 2.15 of the NRPM is the recommended value for every end site, residential or commercial. Current ARIN policy would allow the transit agency to receive a /36 and assign each bus a /48. I have suggested they instead obtain a single end user /48 from either ARIN or a /48 assignment from a /32 block already controlled by state government for their bus use to avoid renumbering during contract provider changes, and use a /60 on each bus. Either saves money over getting a /36 from ARIN. As far as public disclosure of CPNI, the size of an organization does not matter. In the example discussed here of that 69.0.0.0/29 block we have been talking of, unless AT&T has written permission from that customer, they have committed a CPNI violation by simply publishing the name and address of that customer in SWIP, and AT&T could in theory be fined for that disclosure, even though ARIN policy requires the information be disclosed in SWIP. If the FCC in fact takes action is a different story. The usefulness of this SWIP record is also in doubt, as staff at that location, even if contacted might be unable to deal with an "owned" box. It is better to have tech records with the contact info of actual technicians. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 20 Jul 2017, Chris James wrote: > Well I think in the bus example you would swip to the overall authority. > But seriously this conversation has gone in so many different directions do > any of us remember the original point? > > My vote as it applies to v6: Non-residential allocations of greater than or > equal to a /48. > > If you as an ISP choose to allocate a /48 to a residential customer - then > have fun. But this does not affect the purpose of the policy as most use it > these days which is abuse management. Also as I understand it, there is an > exception to the CPNI as it applies to business customers as long as they > have an account manager and adequate language in the contract. How many of > the smaller ISPs have a customer deserving of a /48 or better that does not > have a larger account or spend? If a customer requests a large enough block > from us, regardless of v4 vs v6, they agree via email/ticketing/contract > that their business information will be made public. This is not difficult > to put in your signed agreements with your business customers thus making > the CPNI argument invalid. > > -Chris > > > > On Thu, Jul 20, 2017 at 2:28 PM, wrote: > >> My transit bus example is another example of SWIP difficulty. Very hard >> to provide a street address to SWIP a bus when it is mobile 16 hours a day. >> >> Current policy says SWIP every /64 or more, which is every network in v6. >> >> I did a check here, and in v4, only 1% of customers have more than 8 ip's, >> and these customers are colocation customers who have a bunch of SSL >> sites. These are grandfathered. New customers are told to use 1 IPv4 >> address and SNI or better yet, IPv6, as we do not have the money to buy >> more V4. We would rather use our v4 inventory for access customers. >> >> Yes, it is just a few pieces of information for SWIP. However, we do not >> have clerical staff to do it, because except for the SSL colocates, there >> never has been v4 SWIP's required here. Why should the policy state that >> just because we give each customer an assignment of v6, we must SWIP that >> same small customer that did not require SWIP in v4? (Welcome to IPv6, now >> fill out this form.....) Also noted is that the SWIP registration details >> without written permission might get us in trouble with the FCC over CPNI. >> As a WISP that has licensed microwave links, we do pay attention to Uncle >> Charlie. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> On Thu, 20 Jul 2017, Chris James wrote: >> >> @Paul - The API key is to email it. >>> >>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>> platforms spanning tens of thousands of instances across these dynamic >>> ranges. >>> >>> >>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>> >>> Owen >>>> >>>> The reassignment policy page says IPv6 has to be done vi API. >>>> Is that something else that is incorrect on the web site? >>>> >>>> Paul >>>> >>>> >>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>> >>>> How can it be overly difficult to fill out an email template with your >>>>> customers??? >>>>> Name, Address, Phone Number? >>>>> >>>>> Really? >>>>> >>>>> Owen >>>>> >>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>> >>>>> >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>> data back upstream to ARIN. >>>>>> >>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>> that, one needs to look back at why that data is needed. For a block >>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>> and abuse contact requests down to those that are probably more likely >>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>> request-handling workload higher up and overall). But for that to >>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>> otherwise, it is better to leave them with the block owner. >>>>>> >>>>>> In the end, the contact details should be as close to the "person" >>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>> and act (think: authority) on the tech/abuse requests. >>>>>> >>>>>> eBrain >>>>>> Innovative Internet Ideas >>>>>> >>>>>> Pallieter Koopmans >>>>>> Managing Director >>>>>> >>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>> Skype: PallieterKoopmans >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>>> >>>> _______________________________________________ >>>> 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. >>>> >>> >>> -- >>> This e-mail message may contain confidential or legally privileged >>> information and is intended only for the use of the intended recipient(s). >>> Any unauthorized disclosure, dissemination, distribution, copying or the >>> taking of any action in reliance on the information herein is prohibited. >>> E-mails are not secure and cannot be guaranteed to be error free as they >>> can be intercepted, amended, or contain viruses. Anyone who communicates >>> with us by e-mail is deemed to have accepted these risks. This company is >>> not responsible for errors or omissions in this message and denies any >>> responsibility for any damage arising from the use of e-mail. Any opinion >>> and other statement contained in this message and any attachment are >>> solely >>> those of the author and do not necessarily represent those of the company. >>> >> >> _______________________________________________ >> 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. >> > > -- > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. This company is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > From owen at delong.com Mon Jul 24 14:22:39 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:22:39 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <20d4eaea-9201-dc25-94c2-1799bab43802@cameron.net> References: <59248105.8040703@arin.net> <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> <20d4eaea-9201-dc25-94c2-1799bab43802! @cameron.net> Message-ID: <2090CBD7-72C5-4704-BFB6-5A4843711673@delong.com> That?s not what the new language actually says. Owen > On Jul 20, 2017, at 13:26 , Paul McNary wrote: > > Yes > > /48 is the SWIP boundary. /48 is SWIP'ed. > /49 is not. > > Paul > > > On 7/20/2017 3:07 PM, Owen DeLong wrote: >> My recommendation was ?shorter than /48? which would essentially mean the same thing. >> >> Owen >> >>> On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: >>> >>> The language of "b)" actually makes more sense with a /47: >>> >>> 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. >>> >>> The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. >>> >>> This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> On Mon, 17 Jul 2017, Leif Sawyer wrote: >>> >>>> Shepherd of the draft policy chiming in. >>>> >>>> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >>>> >>>> Just as a reminder to folk, the current policy under question is located here: >>>> https://www.arin.net/policy/nrpm.html#six551 >>>> >>>> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >>>> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >>>> in lieu of actual names and street addresses. >>>> >>>> -- >>>> >>>> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >>>> >>>> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >>>> preferential rewrite of the opening sentence of 6.5.5.1? >>>> >>>> >>>> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >>>> >>>> >>>> >>>> b) Each static IPv6 assignment containing a /55 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. >>>> >>>> >>>> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >>>> >>>> Third: If none of these options are palatable, do you have a proposed approach? >>>> >>>> >>>> >>>> Thanks, >>>> >>>> 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. >> _______________________________________________ >> 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. From owen at delong.com Mon Jul 24 14:28:06 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:28:06 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com> > On Jul 20, 2017, at 13:51 , Paul McNary wrote: > > Owen > > The reassignment policy page says IPv6 has to be done vi API. > Is that something else that is incorrect on the web site? > > Paul I?m not sure what the ?reassignment policy page? you refer to is, but here?s the quote from the NRPM: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses 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 4.2.3.7.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 holding /64 and larger blocks 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. I?ll call your attention to the phrase in 6.5.5.1 which states "registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2? which at this point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP. I?ll also note that 6.5.5.3.1 provides for the residential customer privacy as I defined it, regardless of the mechanism used to make the data available. Given that, can you clarify your above statement? Owen > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: >> How can it be overly difficult to fill out an email template with your customers? >> Name, Address, Phone Number? >> >> Really? >> >> Owen >> >>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans wrote: >>> >>> Hello, >>> >>> ARIN could quantify and require rules for when to SWIP, but in the >>> end, there are going to be exceptions needed if the rules are to be >>> strictly followed. Many will not separately SWIP a separately routed >>> sub-block if it is too difficult or pointless to gather and share that >>> data back upstream to ARIN. >>> >>> Thus a more fuzzy rule to require a best-effort and to add a >>> rule-based reason (preferably both a carrot and a stick) for block >>> owners to do their best to provide (only) useful data. In order to do >>> that, one needs to look back at why that data is needed. For a block >>> owner to assign the SWIP on a sub-block, he basically delegates tech >>> and abuse contact requests down to those that are probably more likely >>> to be able to actually act on the tech/abuse requests (and thus reduce >>> request-handling workload higher up and overall). But for that to >>> work, those tech/abuse contact requests need to be actually handled, >>> otherwise, it is better to leave them with the block owner. >>> >>> In the end, the contact details should be as close to the "person" >>> that is actually capable to both handle (think: volume/languages/etc) >>> and act (think: authority) on the tech/abuse requests. >>> >>> eBrain >>> Innovative Internet Ideas >>> >>> Pallieter Koopmans >>> Managing Director >>> >>> +31-6-3400-3800 (mon-sat 9-22 CET) >>> Skype: PallieterKoopmans >>> _______________________________________________ >>> 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. > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Jul 24 14:28:54 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:28:54 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <676A1F14-B799-4B2C-A61F-EA0A21D6DE7B@delong.com> Dynamic assignments are not required to be registered? STATIC assignments are required to be registered, so that argument doesn?t work. Owen > On Jul 20, 2017, at 13:54 , Chris James wrote: > > @Paul - The API key is to email it. > > @Owen - Very difficult when you have dynamic ranges, and vps/container platforms spanning tens of thousands of instances across these dynamic ranges. > > > On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: > Owen > > The reassignment policy page says IPv6 has to be done vi API. > Is that something else that is incorrect on the web site? > > Paul > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: > How can it be overly difficult to fill out an email template with your customers? > Name, Address, Phone Number? > > Really? > > Owen > > On Jul 19, 2017, at 23:48 , Pallieter Koopmans > wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. > > _______________________________________________ > 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. > > > This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company._______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Jul 24 14:31:48 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:31:48 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: > On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: > > My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. [rest trimmed because we are in agreement on that part] Owen > On Thu, 20 Jul 2017, Chris James wrote: > >> @Paul - The API key is to email it. >> >> @Owen - Very difficult when you have dynamic ranges, and vps/container >> platforms spanning tens of thousands of instances across these dynamic >> ranges. >> >> >> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >> >>> Owen >>> >>> The reassignment policy page says IPv6 has to be done vi API. >>> Is that something else that is incorrect on the web site? >>> >>> Paul >>> >>> >>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>> >>>> How can it be overly difficult to fill out an email template with your >>>> customers? >>>> Name, Address, Phone Number? >>>> >>>> Really? >>>> >>>> Owen >>>> >>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>> wrote: >>>>> >>>>> Hello, >>>>> >>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>> end, there are going to be exceptions needed if the rules are to be >>>>> strictly followed. Many will not separately SWIP a separately routed >>>>> sub-block if it is too difficult or pointless to gather and share that >>>>> data back upstream to ARIN. >>>>> >>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>> owners to do their best to provide (only) useful data. In order to do >>>>> that, one needs to look back at why that data is needed. For a block >>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>> and abuse contact requests down to those that are probably more likely >>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>> request-handling workload higher up and overall). But for that to >>>>> work, those tech/abuse contact requests need to be actually handled, >>>>> otherwise, it is better to leave them with the block owner. >>>>> >>>>> In the end, the contact details should be as close to the "person" >>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>> and act (think: authority) on the tech/abuse requests. >>>>> >>>>> eBrain >>>>> Innovative Internet Ideas >>>>> >>>>> Pallieter Koopmans >>>>> Managing Director >>>>> >>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>> Skype: PallieterKoopmans >>>>> _______________________________________________ >>>>> 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. >>>> >>> >>> _______________________________________________ >>> 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. >> >> -- >> This e-mail message may contain confidential or legally privileged >> information and is intended only for the use of the intended recipient(s). >> Any unauthorized disclosure, dissemination, distribution, copying or the >> taking of any action in reliance on the information herein is prohibited. >> E-mails are not secure and cannot be guaranteed to be error free as they >> can be intercepted, amended, or contain viruses. Anyone who communicates >> with us by e-mail is deemed to have accepted these risks. This company is >> not responsible for errors or omissions in this message and denies any >> responsibility for any damage arising from the use of e-mail. Any opinion >> and other statement contained in this message and any attachment are solely >> those of the author and do not necessarily represent those of the company. > _______________________________________________ > 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. From owen at delong.com Mon Jul 24 14:45:47 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:45:47 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> Message-ID: <8AD16E8D-1619-4829-945D-4E03FB74360B@delong.com> > On Jul 24, 2017, at 04:03 , hostmaster at uneedus.com wrote: > > /47 or more addresses is intended to be /47, /46 ..... /1 and not the reverse. The current language is "/64 or more", and I read that same phrase as /64, /63 ..... /1. For comparison, the current IPv4 language is "/29 or more", and that seems clear to mean /29, /28 ..... /1, and not the reverse. I do not think the "/X or more" language in the current NRPM or the proposal is unclear. > > As far as the remainder, I read this draft as two statements connected with an OR. Thus there are 2 classes of assignments that are required to be SWIP'ed. They are: > > 1) ANY IPv6 assignment containing a /47 or more addresses. > 2) ANY sub-delegation of any size that will be individually announced. > > Due to rules for the GRT, this means /49 or less is not covered by 2). However, should the rules for the GRT ever change, 2) will cover it. The intent of 2) is to require SWIP on ALL sub-delegations, without expressing that level, which is outside of ARIN control. There are no rules for the GRT. There are only each ASNs rules for what they will accept and announce and what ends up in any particular routing table is the intersection of routes accepted and routes advertised by peers. Just a quick sampling from Route-views: * 2001:218:200e:100::/56 2a01:73e0::1 0 47872 2914 i * 2001:67c:22dc:def1::1 0 31019 41887 2914 i * 2c0f:fc00::2 0 3741 2914 i * 2001:d98::19 0 18106 4657 2914 i * 2001:418:0:1000::f000 17346 0 2914 i * 2a00:1728::2d:bbbb 0 0 34224 2914 i *> 2001:418:0:1000::f002 11266 0 2914 i * 2001:218:200e:200::/56 2a01:73e0::1 0 47872 2914 i * 2001:67c:22dc:def1::1 0 31019 41887 2914 i * 2c0f:fc00::2 0 3741 2914 i * 2001:d98::19 0 18106 4657 2914 i * 2001:418:0:1000::f000 17346 0 2914 i * 2a00:1728::2d:bbbb 0 0 34224 2914 i *> 2001:418:0:1000::f002 11266 0 2914 i * 2001:218:200e:300::/56 2a01:73e0::1 0 47872 2914 i * 2001:67c:22dc:def1::1 0 31019 41887 2914 i * 2c0f:fc00::2 0 3741 2914 i * 2001:d98::19 0 18106 4657 2914 i * 2001:418:0:1000::f000 17346 0 2914 i * 2a00:1728::2d:bbbb 0 0 34224 2914 i *> 2001:418:0:1000::f002 11266 0 2914 i * 2001:218:200e:400::/56 2a01:73e0::1 0 47872 2914 i * 2001:67c:22dc:def1::1 0 31019 41887 2914 i * 2c0f:fc00::2 0 3741 2914 i * 2001:d98::19 0 18106 4657 2914 i * 2001:418:0:1000::f000 17346 0 2914 i * 2a00:1728::2d:bbbb 0 0 34224 2914 i *> 2001:418:0:1000::f002 11266 0 2914 i So clearly it is possible to announce at least a /56 and even maybe a /126: *> 2001:218:4000:5000::338/126 2001:d98::19 0 18106 132602 ? *> 2001:218:4000:5000::368/126 2001:d98::19 0 18106 132602 ? *> 2001:218:4000:5000::42c/126 2001:d98::19 0 18106 132602 ? (though that doesn?t seem to have gotten very far) But this /64 got a bit further: * 2001:254:1:b::/64 2001:d98::19 0 18106 4635 10103 3662 3662 3662 3662 3662 3662 3662 ? * 2402:c100::104 0 23673 4635 10103 3662 3662 3662 3662 3662 3662 3662 ? *> 2404:cc00:1::1 0 24441 4635 10103 3662 3662 3662 3662 3662 3662 3662 ? As did this one: * 2001:2b8:0:ffd0::/64 2001:b08:2:280::4:100 0 3277 3267 2603 17579 1237 17832 i * 2001:d98::19 0 18106 4635 17579 1237 17832 i * 2402:c100::104 0 23673 4635 17579 1237 17832 i *> 2404:cc00:1::1 0 24441 4635 17579 1237 17832 i I wouldn?t say that announcing longer prefixes is reliable, but it?s quite clear to me that people are doing so with at least some degree of success getting them propagated beyond their local ASN or even their direct peers. > I do agree that "will be" is a problem as to WHEN to SWIP. This is best corrected by changing that to "is". 6.5.5.2 the next section makes it clear that the time frame to SWIP is within 7 calendar days of the assignment being made. I think ?will be? is fine as I believe it conveys an obligation to SWIP if the delegation is intended to be announced separately when it is delegated vs. no requirement to SWIP if until such an intent exists. > As far as John's comment, this proposal began with a suggestion that changed the v4 requirement as well, making both "more than 16" networks or IPv4 addresses. Since changing the v4 language from 8 addresses to more than 16 addresses was clearly not desired by the community, the v4 language was removed from the draft. The comments still reflect that the equality of the policy between v4 and v6 was the original idea. You are correct that this draft now is only about changing the v6 part. Are you suggesting that the older portions of description that are no longer in it, due to the community input needs to be removed? John?s comments are still correct that any theory of equality between the two protocols is a false equivalence which cannot, in practice, be achieved. IPv6 policy can certainly be improved and made no more onerous than IPv4 policy, but any argument of equivalence is doomed to failure due to the staggering differences in the address management strategies and subnetting practices of the two protocols. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Sun, 23 Jul 2017, Scott Leibrand wrote: > >> No. It says: >> >> Each static IPv6 assignment containing a /47 or more addresses, or sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory >> >> I read that as: >> >> Each static IPv6 assignment containing a /47 or more addresses, and each sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory >> >> So a /48 sub-delegation shall be registered if it will be individually announced. >> >> You said: >>> To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. >> >> >> That entire quoted clause refers to /48s (or longer, if such becomes possible) that will be individually announced. So your clarification, as originally stated, does not match my reading of the text. However, it now sounds like that's not what you meant, and you were trying to say: >> >>> To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. >> >> If that's what you actually meant, then yes, that is the way to read "more": as equivalent to "/47 or shorter". >> >> >> Leif, it seems like we have some potential ambiguity in the new text as to whether "or sub-delegation of any size" is part of the subject of the sentence, or a subordinate clause to "containing". Does my rewrite above clarify your intent? Or were you intending it to mean "Each static IPv6 assignment containing a ... sub-delegation of any size that will be individually announced, shall be registered in the WHOIS directory"? That interpretation makes no sense to me, as the sub-delegation clause would be redundant. So if that's what you meant, I'd appreciate some clarity on what it is intended to accomplish. >> >> Scott >> >>> On Jul 23, 2017, at 8:35 PM, John Springer <3johnl at gmail.com> wrote: >>> >>> Thanks, Scott, >>> >>> Are we energetically agreeing? You scared me there for a second. /48s are excluded, unless they are part of a "subdelegation of any size that will be individually announced". Yes. >>> >>> How is that defined by the way? Will be individually announced in 2 years, 2 days, right now? >>> >>> On another matter, this problem statement has been making me uneasy all along, but because it was only required to be clear and in scope to be accepted as Draft Policy, it was not appropriate for me to object. This seems like as good a time as any to address some concerns, which are my opinions only. >>> >>> "Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments." >>> >>> This is a correct statement! It is not a problem however, nor is it sufficient motive for trying to solve a problem, per se. >>> >>> "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," >>> >>> Two facts. The second is undoubtedly a great pity, but to entangle these logically is a fallacy of inconsistency, specifically a false equivalence. These two facts are unrelated. It does not help the case to try to make them interdependent. And it is not needed. All that is being attempted is to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. >>> >>> "which constitutes one entire IPv6 subnet and is the minimum block size for an allocation." >>> >>> I think I'm looking at current text. How did this make it this far? One ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 to /128. What does that have to do with anything? And, yeah, the SWIP boundary being the so called "minimum" allocation seems broken, but that is its own thing. >>> >>> "There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption." >>> >>> Possibly true, but irrelevant. There is no technical or policy rationale for them being alike either, nor is there any reason to suppose that if they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for V6. Concentrate on that. We can make policy for V6 without needing to refer to V4. >>> >>> "The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences." >>> >>> With respect, it is not. The disparity does not qualify as a logical motive. The brokenness of SWIPing /64s does not require injustice and if /64 SWIPing is a deterrent to V6 adoption, that is its own good and sufficient reason. If you had to refer to an analogy, you could say, "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". >>> >>> So all you need is: >>> >>> Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this proposal is to pick a different number. >>> >>> 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.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" >>> >>> BUT. These observations do not appear to have any effect one way or the other on the policy text. To me, picking a different number does not have anything to do with disparity, but so what? Changing the IPV6 SWIP threshold is not unfair and partial if someone makes unfounded assertions regarding linkages between v4 and V6. And it is not technically unsound to make fallacious observations if they are kind of orthogonal to the meat of the matter. >>> >>> So, still support. I'd rather see it simpler, but I guess I can tolerate a little hand waving. >>> >>> Writing solely on my own behalf, >>> >>> John Springer >>> >>>> On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand wrote: >>>>> On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: >>>>> >>>>> I support this Draft Policy as re-written. >>>>> >>>>> I shared the author's distaste for the requirement that IPV6 /64s be SWIP'd, but was not reassured when the discussion veered to consider prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to apply for their allocations based on the idea of assigning a /48 to each 'customer' to provide room for unknown technologies, among other things. I did not wish to endanger that premise, but current language appears to moot that concern. >>>>> >>>>> To be explicit, to me, "/47 or more addresses, or sub-delegation of any size that will be individually announced," refers to /47s, /46s, /45s ... and not /48s, /49s, /50s, etc. >>>> >>>> That's not what it says. It says /48s (or longer) should be individually SWIPped if they're going to be announced. Otherwise there's no reason for the extra clause. >>>> >>>> Blocks in the GRT need to be SWIPped to the announcing party if that's a different organization from the holder of the larger block. >>>> >>>> -Scott >>>> >>>>> >>>>>> On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. >>>>> >>>>> _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 24 14:53:18 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 24 Jul 2017 13:53:18 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <2090CBD7-72C5-4704-BFB6-5A4843711673@delong.com> References: <59248105.8040703@arin.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> <20d4eaea-9201-dc25-94c2-1799bab43802! @cameron.net> <2090CBD7-72C5-4704-BFB6-5A4843711673@delong.com> Message-ID: <92cd608e-e9d5-0560-f06a-1e2adbb8a699@cameron.net> What does the new language say? I then am totally confused as I am with the rest of the NPRM! So many contradictions using Missouri English. Paul On 7/24/2017 1:22 PM, Owen DeLong wrote: > That?s not what the new language actually says. > > Owen > >> On Jul 20, 2017, at 13:26 , Paul McNary wrote: >> >> Yes >> >> /48 is the SWIP boundary. /48 is SWIP'ed. >> /49 is not. >> >> Paul >> >> >> On 7/20/2017 3:07 PM, Owen DeLong wrote: >>> My recommendation was ?shorter than /48? which would essentially mean the same thing. >>> >>> Owen >>> >>>> On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: >>>> >>>> The language of "b)" actually makes more sense with a /47: >>>> >>>> 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. >>>> >>>> The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. >>>> >>>> This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. >>>> >>>> Albert Erdmann >>>> Network Administrator >>>> Paradise On Line Inc. >>>> >>>> On Mon, 17 Jul 2017, Leif Sawyer wrote: >>>> >>>>> Shepherd of the draft policy chiming in. >>>>> >>>>> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >>>>> >>>>> Just as a reminder to folk, the current policy under question is located here: >>>>> https://www.arin.net/policy/nrpm.html#six551 >>>>> >>>>> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >>>>> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >>>>> in lieu of actual names and street addresses. >>>>> >>>>> -- >>>>> >>>>> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >>>>> >>>>> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >>>>> preferential rewrite of the opening sentence of 6.5.5.1? >>>>> >>>>> >>>>> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >>>>> >>>>> >>>>> >>>>> b) Each static IPv6 assignment containing a /55 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. >>>>> >>>>> >>>>> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >>>>> >>>>> Third: If none of these options are palatable, do you have a proposed approach? >>>>> >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> 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. >>> _______________________________________________ >>> 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. > > From owen at delong.com Mon Jul 24 14:58:41 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 11:58:41 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: > On Jul 21, 2017, at 00:09 , theone at uneedus.com wrote: > > As for discussion of SWIP for /48's, some have suggested since these are the recommended minimum assignment for an end site, /48 should not trigger SWIP unless independently routed. Others believe all /48's be SWIP'ed. Thus the two main ideas for this proposal currently are: > > 1) SWIP all independently routed (in the GRT) networks regardless of size but in actual fact they must be at least a /48 to be in the GRT, and all other assignments greater than a /48. This is the "b)" language using /47 from the other day. As I demonstrated in my previous post, the GRT is not entirely as restrictive as stated, so I would say that your option 1 would be better (and more accurately) restated as: 1) SWIP all independently announced networks regardless of size and all assignments shorter than /48 (i.e. /0../47). This is the option which I currently support. > 2) SWIP every /48 regardless of routing, smaller are exempt. This is the "/48 or more" language. Since the standard site size is /48, this catches a lot of small sites that are not independently routed but avoids setting the policy based on routing. If this is chosen many ISP's are likely to choose giving out /52 or less instead of /48's. As pointed out by others, a major cable ISP in the US already gives out only a /60 with their prefix delegation server. Although like the mobile networks, they do have a current valid argument against SWIP, since these are not "static?. So far, I saw opposition to 1) favoring 2) only from Bill Herrin and generally good support for 1) otherwise. However, I admit this is not the result of a careful or detailed review of every message specifically for this determination, so I may have missed something along the way. > Now that we want to change the bus administrative network to v6 for lack of v4 static assignments from the contract wireless provider, we run into the ARIN 100% SWIP registration requirement of /64 or more in NRPM 6.5.5.1. as v6 does not use NAT. The policy of /64 or more is what I seek to change, to allow smaller v6 networks, like these busses to avoid a SWIP requirement. Switching the same size network with the same number of hosts from v4 to v6 should not change the SWIP requirement, but current policy does. This is where the debate is, where to draw that line. The reality is that the over-arching /48 containing all of the bus /64s could be SWIPd as a single block to the bus company and would be a completely legitimate solution to this issue. I suspect that the IPv4 aggregate containing the static IPv4 addresses for all the busses was also SWIPd previously (or at least should have been under policy). As such, I?m not sure this is the ideal example for your argument. > The thing to remember is that currently a /48, according to the 2.15 of the NRPM is the recommended value for every end site, residential or commercial. Current ARIN policy would allow the transit agency to receive a /36 and assign each bus a /48. I have suggested they instead obtain a single end user /48 from either ARIN or a /48 assignment from a /32 block already controlled by state government for their bus use to avoid renumbering during contract provider changes, and use a /60 on each bus. Either saves money over getting a /36 from ARIN. Yes, but the bus isn?t necessarily technically considered a separate end site (or at least not necessarily one that has to be SWIPd). For example, a major corporation that is numbering a variety of end-sites on multiple corporate campuses around the world can qualify for nx/48 as an aggregate, let?s say /40 for convenience here. (some value >128 and less than 256 end sites). Said corporation would not need to SWIP each and every campus. The corporation is not considered an LIR, but an end-user (unless they choose to be an LIR for reasons of their own) and as such could register the entire /40 as a single block to Corporate HQ without issue and without being required to make any more specific SWIPs. Similarly, the bus company could register their aggregate IPv6 address block (/48, /36, /32, or whatever) to an appropriate headquarters address and be done. There is no need to register the assignments to the individual busses. In fact, if the busses become independently routed, this policy proposal would, in fact, increase the registration requirement from what it is today rather than decrease it. > As far as public disclosure of CPNI, the size of an organization does not matter. In the example discussed here of that 69.0.0.0/29 block we have been talking of, unless AT&T has written permission from that customer, they have committed a CPNI violation by simply publishing the name and address of that customer in SWIP, and AT&T could in theory be fined for that disclosure, even though ARIN policy requires the information be disclosed in SWIP. If the FCC in fact takes action is a different story. The usefulness of this SWIP record is also in doubt, as staff at that location, even if contacted might be unable to deal with an "owned" box. > It is better to have tech records with the contact info of actual technicians. I think you will find that the AT&T TOS cover this disclosure if you read them carefully. I could be wrong and IANAL, but most ISPs I?ve dealt with definitely include language covering the SWIP requirement somehow in their contracts and/or TOS. YMMV. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Thu, 20 Jul 2017, Chris James wrote: > >> Well I think in the bus example you would swip to the overall authority. >> But seriously this conversation has gone in so many different directions do >> any of us remember the original point? >> >> My vote as it applies to v6: Non-residential allocations of greater than or >> equal to a /48. >> >> If you as an ISP choose to allocate a /48 to a residential customer - then >> have fun. But this does not affect the purpose of the policy as most use it >> these days which is abuse management. Also as I understand it, there is an >> exception to the CPNI as it applies to business customers as long as they >> have an account manager and adequate language in the contract. How many of >> the smaller ISPs have a customer deserving of a /48 or better that does not >> have a larger account or spend? If a customer requests a large enough block >> from us, regardless of v4 vs v6, they agree via email/ticketing/contract >> that their business information will be made public. This is not difficult >> to put in your signed agreements with your business customers thus making >> the CPNI argument invalid. >> >> -Chris >> >> >> >> On Thu, Jul 20, 2017 at 2:28 PM, wrote: >> >>> My transit bus example is another example of SWIP difficulty. Very hard >>> to provide a street address to SWIP a bus when it is mobile 16 hours a day. >>> >>> Current policy says SWIP every /64 or more, which is every network in v6. >>> >>> I did a check here, and in v4, only 1% of customers have more than 8 ip's, >>> and these customers are colocation customers who have a bunch of SSL >>> sites. These are grandfathered. New customers are told to use 1 IPv4 >>> address and SNI or better yet, IPv6, as we do not have the money to buy >>> more V4. We would rather use our v4 inventory for access customers. >>> >>> Yes, it is just a few pieces of information for SWIP. However, we do not >>> have clerical staff to do it, because except for the SSL colocates, there >>> never has been v4 SWIP's required here. Why should the policy state that >>> just because we give each customer an assignment of v6, we must SWIP that >>> same small customer that did not require SWIP in v4? (Welcome to IPv6, now >>> fill out this form.....) Also noted is that the SWIP registration details >>> without written permission might get us in trouble with the FCC over CPNI. >>> As a WISP that has licensed microwave links, we do pay attention to Uncle >>> Charlie. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> On Thu, 20 Jul 2017, Chris James wrote: >>> >>> @Paul - The API key is to email it. >>>> >>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>> platforms spanning tens of thousands of instances across these dynamic >>>> ranges. >>>> >>>> >>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>> >>>> Owen >>>>> >>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>> Is that something else that is incorrect on the web site? >>>>> >>>>> Paul >>>>> >>>>> >>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>> >>>>> How can it be overly difficult to fill out an email template with your >>>>>> customers? >>>>>> Name, Address, Phone Number? >>>>>> >>>>>> Really? >>>>>> >>>>>> Owen >>>>>> >>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>> >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>> data back upstream to ARIN. >>>>>>> >>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>> request-handling workload higher up and overall). But for that to >>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>> >>>>>>> In the end, the contact details should be as close to the "person" >>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>> >>>>>>> eBrain >>>>>>> Innovative Internet Ideas >>>>>>> >>>>>>> Pallieter Koopmans >>>>>>> Managing Director >>>>>>> >>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>> Skype: PallieterKoopmans >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>>> >>>> >>>> -- >>>> This e-mail message may contain confidential or legally privileged >>>> information and is intended only for the use of the intended recipient(s). >>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>> taking of any action in reliance on the information herein is prohibited. >>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>> with us by e-mail is deemed to have accepted these risks. This company is >>>> not responsible for errors or omissions in this message and denies any >>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>> and other statement contained in this message and any attachment are >>>> solely >>>> those of the author and do not necessarily represent those of the company. >>>> >>> >>> _______________________________________________ >>> 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. >>> >> >> -- >> This e-mail message may contain confidential or legally privileged >> information and is intended only for the use of the intended recipient(s). >> Any unauthorized disclosure, dissemination, distribution, copying or the >> taking of any action in reliance on the information herein is prohibited. >> E-mails are not secure and cannot be guaranteed to be error free as they >> can be intercepted, amended, or contain viruses. Anyone who communicates >> with us by e-mail is deemed to have accepted these risks. This company is >> not responsible for errors or omissions in this message and denies any >> responsibility for any damage arising from the use of e-mail. Any opinion >> and other statement contained in this message and any attachment are solely >> those of the author and do not necessarily represent those of the company. > _______________________________________________ > 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. From pmcnary at cameron.net Mon Jul 24 15:01:17 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 24 Jul 2017 14:01:17 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com> Message-ID: <3d0e7e9a-ffa7-7409-3b26-34ec125f7f22@cameron.net> https://www.arin.net/resources/request/reassignments.html On 7/24/2017 1:28 PM, Owen DeLong wrote: > >> On Jul 20, 2017, at 13:51 , Paul McNary > > wrote: >> >> Owen >> >> The reassignment policy page says IPv6 has to be done vi API. >> Is that something else that is incorrect on the web site? >> >> Paul > > I?m not sure what the ?reassignment policy page? you refer to is, but > here?s the quote from the NRPM: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but > not limited to assignment histories, showing their efficient use. > > 6.5.5.1. Reassignment information > Each static IPv6 assignment containing a /64 or more addresses > 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 > 4.2.3.7.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 holding /64 and > larger blocks 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. > > I?ll call your attention to the phrase in 6.5.5.1 which states > "registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2? which at this > point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP. > > > I?ll also note that 6.5.5.3.1 provides for the residential customer > privacy as I defined it, regardless of the mechanism used to make the > data available. > > Given that, can you clarify your above statement? > > Owen > >> >> >> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>> How can it be overly difficult to fill out an email template with >>> your customers? >>> Name, Address, Phone Number? >>> >>> Really? >>> >>> Owen >>> >>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>> > wrote: >>>> >>>> Hello, >>>> >>>> ARIN could quantify and require rules for when to SWIP, but in the >>>> end, there are going to be exceptions needed if the rules are to be >>>> strictly followed. Many will not separately SWIP a separately routed >>>> sub-block if it is too difficult or pointless to gather and share that >>>> data back upstream to ARIN. >>>> >>>> Thus a more fuzzy rule to require a best-effort and to add a >>>> rule-based reason (preferably both a carrot and a stick) for block >>>> owners to do their best to provide (only) useful data. In order to do >>>> that, one needs to look back at why that data is needed. For a block >>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>> and abuse contact requests down to those that are probably more likely >>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>> request-handling workload higher up and overall). But for that to >>>> work, those tech/abuse contact requests need to be actually handled, >>>> otherwise, it is better to leave them with the block owner. >>>> >>>> In the end, the contact details should be as close to the "person" >>>> that is actually capable to both handle (think: volume/languages/etc) >>>> and act (think: authority) on the tech/abuse requests. >>>> >>>> eBrain >>>> Innovative Internet Ideas >>>> >>>> Pallieter Koopmans >>>> Managing Director >>>> >>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>> Skype: PallieterKoopmans >>>> _______________________________________________ >>>> 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. >> >> _______________________________________________ >> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Jul 24 15:00:10 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 24 Jul 2017 12:00:10 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <92cd608e-e9d5-0560-f06a-1e2adbb8a699@cameron.net> References: <59248105.8040703@arin.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> <20d4eaea-9201-dc25-94c2-1799bab43802! @cameron.net> <2090CBD7-72C5-4704-BFB6-5A4843711673@delong.com> <92cd608e-e9d5-0560-f06a-1e2adbb8a699@camer! on.net> Message-ID: <33AA61B2-0E09-4E34-8D0B-87C8F7F4A997@delong.com> The current proposal language says: /47 or shorter are SWIP?d in all cases. /48 or longer are SWIP?d if they are independently announced. Owen > On Jul 24, 2017, at 11:53 , Paul McNary wrote: > > What does the new language say? > I then am totally confused as I am with the rest of the NPRM! > > So many contradictions using Missouri English. > > Paul > > > On 7/24/2017 1:22 PM, Owen DeLong wrote: >> That?s not what the new language actually says. >> >> Owen >> >>> On Jul 20, 2017, at 13:26 , Paul McNary wrote: >>> >>> Yes >>> >>> /48 is the SWIP boundary. /48 is SWIP'ed. >>> /49 is not. >>> >>> Paul >>> >>> >>> On 7/20/2017 3:07 PM, Owen DeLong wrote: >>>> My recommendation was ?shorter than /48? which would essentially mean the same thing. >>>> >>>> Owen >>>> >>>>> On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: >>>>> >>>>> The language of "b)" actually makes more sense with a /47: >>>>> >>>>> 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. >>>>> >>>>> The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. >>>>> >>>>> This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. >>>>> >>>>> Albert Erdmann >>>>> Network Administrator >>>>> Paradise On Line Inc. >>>>> >>>>> On Mon, 17 Jul 2017, Leif Sawyer wrote: >>>>> >>>>>> Shepherd of the draft policy chiming in. >>>>>> >>>>>> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >>>>>> >>>>>> Just as a reminder to folk, the current policy under question is located here: >>>>>> https://www.arin.net/policy/nrpm.html#six551 >>>>>> >>>>>> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >>>>>> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >>>>>> in lieu of actual names and street addresses. >>>>>> >>>>>> -- >>>>>> >>>>>> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >>>>>> >>>>>> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >>>>>> preferential rewrite of the opening sentence of 6.5.5.1? >>>>>> >>>>>> >>>>>> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >>>>>> >>>>>> >>>>>> >>>>>> b) Each static IPv6 assignment containing a /55 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. >>>>>> >>>>>> >>>>>> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >>>>>> >>>>>> Third: If none of these options are palatable, do you have a proposed approach? >>>>>> >>>>>> >>>>>> >>>>>> Thanks, >>>>>> >>>>>> 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. >>>> _______________________________________________ >>>> 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. >> >> > > _______________________________________________ > 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. From pmcnary at cameron.net Mon Jul 24 15:03:23 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 24 Jul 2017 14:03:23 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <4a0a4c2d-5784-b6f5-7ad0-7160966d0236@cameron.net> Then that totally negates the reasoning for geolocation. The administrative address could be on the other side of the earth. Paul On 7/24/2017 1:31 PM, Owen DeLong wrote: >> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >> >> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. > Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. > > [rest trimmed because we are in agreement on that part] > > Owen > >> On Thu, 20 Jul 2017, Chris James wrote: >>> @Paul - The API key is to email it. >>> >>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>> platforms spanning tens of thousands of instances across these dynamic >>> ranges. >>> >>> >>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>> >>>> Owen >>>> >>>> The reassignment policy page says IPv6 has to be done vi API. >>>> Is that something else that is incorrect on the web site? >>>> >>>> Paul >>>> >>>> >>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>> >>>>> How can it be overly difficult to fill out an email template with your >>>>> customers? >>>>> Name, Address, Phone Number? >>>>> >>>>> Really? >>>>> >>>>> Owen >>>>> >>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>> wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>> data back upstream to ARIN. >>>>>> >>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>> that, one needs to look back at why that data is needed. For a block >>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>> and abuse contact requests down to those that are probably more likely >>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>> request-handling workload higher up and overall). But for that to >>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>> otherwise, it is better to leave them with the block owner. >>>>>> >>>>>> In the end, the contact details should be as close to the "person" >>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>> and act (think: authority) on the tech/abuse requests. >>>>>> >>>>>> eBrain >>>>>> Innovative Internet Ideas >>>>>> >>>>>> Pallieter Koopmans >>>>>> Managing Director >>>>>> >>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>> Skype: PallieterKoopmans >>>>>> _______________________________________________ >>>>>> 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. >>>>> >>>> _______________________________________________ >>>> 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. >>> -- >>> This e-mail message may contain confidential or legally privileged >>> information and is intended only for the use of the intended recipient(s). >>> Any unauthorized disclosure, dissemination, distribution, copying or the >>> taking of any action in reliance on the information herein is prohibited. >>> E-mails are not secure and cannot be guaranteed to be error free as they >>> can be intercepted, amended, or contain viruses. Anyone who communicates >>> with us by e-mail is deemed to have accepted these risks. This company is >>> not responsible for errors or omissions in this message and denies any >>> responsibility for any damage arising from the use of e-mail. Any opinion >>> and other statement contained in this message and any attachment are solely >>> those of the author and do not necessarily represent those of the company. >> _______________________________________________ >> 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. From bjones at vt.edu Mon Jul 24 15:03:24 2017 From: bjones at vt.edu (Brian Jones) Date: Mon, 24 Jul 2017 19:03:24 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <8AD16E8D-1619-4829-945D-4E03FB74360B@delong.com> References: <7EB48601-83C7-4DCD-92DE-1C006B73D7E4@gmail.com> <8AD16E8D-1619-4829-945D-4E03FB74360B@delong.com> Message-ID: On Mon, Jul 24, 2017 at 2:46 PM Owen DeLong wrote: > On Jul 24, 2017, at 04:03 , hostmaster at uneedus.com wrote: > > /47 or more addresses is intended to be /47, /46 ..... /1 and not the > reverse. The current language is "/64 or more", and I read that same > phrase as /64, /63 ..... /1. For comparison, the current IPv4 language is > "/29 or more", and that seems clear to mean /29, /28 ..... /1, and not the > reverse. I do not think the "/X or more" language in the current NRPM or > the proposal is unclear. > > As far as the remainder, I read this draft as two statements connected > with an OR. Thus there are 2 classes of assignments that are required to > be SWIP'ed. They are: > > 1) ANY IPv6 assignment containing a /47 or more addresses. > 2) ANY sub-delegation of any size that will be individually announced. > > Due to rules for the GRT, this means /49 or less is not covered by 2). > However, should the rules for the GRT ever change, 2) will cover it. The > intent of 2) is to require SWIP on ALL sub-delegations, without expressing > that level, which is outside of ARIN control. > > > There are no rules for the GRT. There are only each ASNs rules for what > they will accept and announce and what ends up in any particular routing > table is the intersection of routes accepted and routes advertised by peers. > > Just a quick sampling from Route-views: > > * 2001:218:200e:100::/56 > 2a01:73e0::1 0 47872 2914 i > * 2001:67c:22dc:def1::1 > 0 31019 41887 > 2914 i > * 2c0f:fc00::2 0 3741 2914 i > * 2001:d98::19 0 18106 4657 > 2914 i > * 2001:418:0:1000::f000 > 17346 0 2914 i > * 2a00:1728::2d:bbbb > 0 0 34224 2914 i > *> 2001:418:0:1000::f002 > 11266 0 2914 i > * 2001:218:200e:200::/56 > 2a01:73e0::1 0 47872 2914 i > * 2001:67c:22dc:def1::1 > 0 31019 41887 > 2914 i > * 2c0f:fc00::2 0 3741 2914 i > * 2001:d98::19 0 18106 4657 > 2914 i > * 2001:418:0:1000::f000 > 17346 0 2914 i > * 2a00:1728::2d:bbbb > 0 0 34224 2914 i > *> 2001:418:0:1000::f002 > 11266 0 2914 i > * 2001:218:200e:300::/56 > 2a01:73e0::1 0 47872 2914 i > * 2001:67c:22dc:def1::1 > 0 31019 41887 > 2914 i > * 2c0f:fc00::2 0 3741 2914 i > * 2001:d98::19 0 18106 4657 > 2914 i > * 2001:418:0:1000::f000 > 17346 0 2914 i > * 2a00:1728::2d:bbbb > 0 0 34224 2914 i > *> 2001:418:0:1000::f002 > 11266 0 2914 i > * 2001:218:200e:400::/56 > 2a01:73e0::1 0 47872 2914 i > * 2001:67c:22dc:def1::1 > 0 31019 41887 > 2914 i > * 2c0f:fc00::2 0 3741 2914 i > * 2001:d98::19 0 18106 4657 > 2914 i > * 2001:418:0:1000::f000 > 17346 0 2914 i > * 2a00:1728::2d:bbbb > 0 0 34224 2914 i > *> 2001:418:0:1000::f002 > 11266 0 2914 i > > So clearly it is possible to announce at least a /56 and even maybe a > /126: > > *> 2001:218:4000:5000::338/126 > 2001:d98::19 0 18106 132602 ? > *> 2001:218:4000:5000::368/126 > 2001:d98::19 0 18106 132602 ? > *> 2001:218:4000:5000::42c/126 > 2001:d98::19 0 18106 132602 ? > (though that doesn?t seem to have gotten very far) > > But this /64 got a bit further: > > * 2001:254:1:b::/64 > 2001:d98::19 0 18106 4635 > 10103 3662 3662 3662 3662 3662 3662 3662 ? > * 2402:c100::104 0 23673 4635 > 10103 3662 3662 3662 3662 3662 3662 3662 ? > *> 2404:cc00:1::1 0 24441 4635 > 10103 3662 3662 3662 3662 3662 3662 3662 ? > > As did this one: > * 2001:2b8:0:ffd0::/64 > 2001:b08:2:280::4:100 > 0 3277 3267 > 2603 17579 1237 17832 i > * 2001:d98::19 0 18106 4635 > 17579 1237 17832 i > * 2402:c100::104 0 23673 4635 > 17579 1237 17832 i > *> 2404:cc00:1::1 0 24441 4635 > 17579 1237 17832 i > > > I wouldn?t say that announcing longer prefixes is reliable, but it?s quite > clear to me that people are doing so with at least some degree of success > getting them propagated beyond their local ASN or even their direct peers. > > I do agree that "will be" is a problem as to WHEN to SWIP. This is best > corrected by changing that to "is". 6.5.5.2 the next section makes it > clear that the time frame to SWIP is within 7 calendar days of the > assignment being made. > > > I think ?will be? is fine as I believe it conveys an obligation to SWIP if > the delegation is intended to be announced separately when it is delegated > vs. no requirement to SWIP if until such an intent exists. > > As far as John's comment, this proposal began with a suggestion that > changed the v4 requirement as well, making both "more than 16" networks or > IPv4 addresses. Since changing the v4 language from 8 addresses to more > than 16 addresses was clearly not desired by the community, the v4 language > was removed from the draft. The comments still reflect that the equality > of the policy between v4 and v6 was the original idea. You are correct > that this draft now is only about changing the v6 part. Are you suggesting > that the older portions of description that are no longer in it, due to the > community input needs to be removed? > > > +1 We should be trying to make IPv6 policy equivalent to IPv6 because they are very different. The idea for IPv6 is that all will have access to plenty of address space without the same limitations as IPv4. Why are we attempting to saddle IPv6 with the same old problems. It makes sense to identify a reasonable boundary beyond which IPv6 allocations should be SWIP?ed, and add to that any more specific allocations or transfers that will be explicitly announced in the routing tables. ? Brian > John?s comments are still correct that any theory of equality between the > two protocols is a false equivalence which cannot, in practice, be > achieved. IPv6 policy can certainly be improved and made no more onerous > than IPv4 policy, but any argument of equivalence is doomed to failure due > to the staggering differences in the address management strategies and > subnetting practices of the two protocols. > > Owen > > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Sun, 23 Jul 2017, Scott Leibrand wrote: > > No. It says: > > Each static IPv6 assignment containing a /47 or more addresses, or > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > I read that as: > > Each static IPv6 assignment containing a /47 or more addresses, and each > sub-delegation of any size that will be individually announced, shall be > registered in the WHOIS directory > > So a /48 sub-delegation shall be registered if it will be individually > announced. > > You said: > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any > size that will be individually announced," refers to /47s, /46s, /45s ... > and not /48s, /49s, /50s, etc. > > > > That entire quoted clause refers to /48s (or longer, if such becomes > possible) that will be individually announced. So your clarification, as > originally stated, does not match my reading of the text. However, it now > sounds like that's not what you meant, and you were trying to say: > > To be explicit, to me, "/47 or more addresses," refers to /47s, /46s, /45s > ... and not /48s, /49s, /50s, etc. > > > If that's what you actually meant, then yes, that is the way to read > "more": as equivalent to "/47 or shorter". > > > Leif, it seems like we have some potential ambiguity in the new text as to > whether "or sub-delegation of any size" is part of the subject of the > sentence, or a subordinate clause to "containing". Does my rewrite above > clarify your intent? Or were you intending it to mean "Each static IPv6 > assignment containing a ... sub-delegation of any size that will be > individually announced, shall be registered in the WHOIS directory"? That > interpretation makes no sense to me, as the sub-delegation clause would be > redundant. So if that's what you meant, I'd appreciate some clarity on what > it is intended to accomplish. > > Scott > > On Jul 23, 2017, at 8:35 PM, John Springer <3johnl at gmail.com> wrote: > > Thanks, Scott, > > Are we energetically agreeing? You scared me there for a second. /48s are > excluded, unless they are part of a "subdelegation of any size that will be > individually announced". Yes. > > How is that defined by the way? Will be individually announced in 2 years, > 2 days, right now? > > On another matter, this problem statement has been making me uneasy all > along, but because it was only required to be clear and in scope to be > accepted as Draft Policy, it was not appropriate for me to object. This > seems like as good a time as any to address some concerns, which are my > opinions only. > > "Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments." > > This is a correct statement! It is not a problem however, nor is it > sufficient motive for trying to solve a problem, per se. > > "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," > > Two facts. The second is undoubtedly a great pity, but to entangle these > logically is a fallacy of inconsistency, specifically a false equivalence. > These two facts are unrelated. It does not help the case to try to make > them interdependent. And it is not needed. All that is being attempted is > to modify V6 SWIP requirements. Do that. And DO NOT settle on 8 subnets. > > "which constitutes one entire IPv6 subnet and is the minimum block size > for an allocation." > > I think I'm looking at current text. How did this make it this far? One > ENTIRE IPV6 subnet? There are lots of entire V6 subnets all the way from /0 > to /128. What does that have to do with anything? And, yeah, the SWIP > boundary being the so called "minimum" allocation seems broken, but that is > its own thing. > > "There is no technical or policy rationale for the disparity, which could > serve as a deterrent to more rapid IPv6 adoption." > > Possibly true, but irrelevant. There is no technical or policy rationale > for them being alike either, nor is there any reason to suppose that if > they were, folks would adopt V6 faster. SWIPing /64 is definitely wrong for > V6. Concentrate on that. We can make policy for V6 without needing to refer > to V4. > > "The purpose of this proposal is to eliminate the disparity and > corresponding adverse consequences." > > With respect, it is not. The disparity does not qualify as a logical > motive. The brokenness of SWIPing /64s does not require injustice and if > /64 SWIPing is a deterrent to V6 adoption, that is its own good and > sufficient reason. If you had to refer to an analogy, you could say, > "SWIPing /64s is analogous to SWIPing /32s and that seems dumb". > > So all you need is: > > Problem Statement: SWIPing IPV6 /64s is the problem. The purpose of this > proposal is to pick a different number. > > 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.3.1. "Residential Customer Privacy" of the > NRPM by deleting the phrase "holding /64 and larger blocks" > > BUT. These observations do not appear to have any effect one way or the > other on the policy text. To me, picking a different number does not have > anything to do with disparity, but so what? Changing the IPV6 SWIP > threshold is not unfair and partial if someone makes unfounded assertions > regarding linkages between v4 and V6. And it is not technically unsound to > make fallacious observations if they are kind of orthogonal to the meat of > the matter. > > So, still support. I'd rather see it simpler, but I guess I can tolerate a > little hand waving. > > Writing solely on my own behalf, > > John Springer > > On Fri, Jul 21, 2017 at 9:15 PM, Scott Leibrand > wrote: > > On Jul 21, 2017, at 8:31 PM, John Springer <3johnl at gmail.com> wrote: > > I support this Draft Policy as re-written. > > I shared the author's distaste for the requirement that IPV6 /64s be > SWIP'd, but was not reassured when the discussion veered to consider > prefixes between /48 and /64. AFAIK, ISPs have long been encouraged to > apply for their allocations based on the idea of assigning a /48 to each > 'customer' to provide room for unknown technologies, among other things. I > did not wish to endanger that premise, but current language appears to moot > that concern. > > To be explicit, to me, "/47 or more addresses, or sub-delegation of any > size that will be individually announced," refers to /47s, /46s, /45s ... > and not /48s, /49s, /50s, etc. > > > That's not what it says. It says /48s (or longer) should be individually > SWIPped if they're going to be announced. Otherwise there's no reason for > the extra clause. > > Blocks in the GRT need to be SWIPped to the announcing party if that's a > different organization from the holder of the larger block. > > -Scott > > > On Fri, Jul 21, 2017 at 9:44 AM, Leif Sawyer 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. > > > _______________________________________________ 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. > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Mon Jul 24 15:08:11 2017 From: pmcnary at cameron.net (Paul McNary) Date: Mon, 24 Jul 2017 14:08:11 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <33AA61B2-0E09-4E34-8D0B-87C8F7F4A997@delong.com> References: <59248105.8040703@arin.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <823A781E-973F-46F6-B5CE-8BEE81F31E45@delong.com> <20d4eaea-9201-dc25-94c2-1799bab43802! @cameron.net> <2090CBD7-72C5-4704-BFB6-5A4843711673@delong.com> <92cd608e-e9d5-0560-f06a-1e2adbb8a699@camer! on.net> <33AA61B2-0E09-4E34-8D0B-87C8F7F4A997@delong.com> Message-ID: <48ef6b4b-0e80-407d-2e79-860ae6e40143@cameron.net> I agree with that! Paul On 7/24/2017 2:00 PM, Owen DeLong wrote: > The current proposal language says: > > /47 or shorter are SWIP?d in all cases. > /48 or longer are SWIP?d if they are independently announced. > > Owen > >> On Jul 24, 2017, at 11:53 , Paul McNary wrote: >> >> What does the new language say? >> I then am totally confused as I am with the rest of the NPRM! >> >> So many contradictions using Missouri English. >> >> Paul >> >> >> On 7/24/2017 1:22 PM, Owen DeLong wrote: >>> That?s not what the new language actually says. >>> >>> Owen >>> >>>> On Jul 20, 2017, at 13:26 , Paul McNary wrote: >>>> >>>> Yes >>>> >>>> /48 is the SWIP boundary. /48 is SWIP'ed. >>>> /49 is not. >>>> >>>> Paul >>>> >>>> >>>> On 7/20/2017 3:07 PM, Owen DeLong wrote: >>>>> My recommendation was ?shorter than /48? which would essentially mean the same thing. >>>>> >>>>> Owen >>>>> >>>>>> On Jul 17, 2017, at 15:46 , hostmaster at uneedus.com wrote: >>>>>> >>>>>> The language of "b)" actually makes more sense with a /47: >>>>>> >>>>>> 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. >>>>>> >>>>>> The major difference is that this language eliminates the SWIP requirement for /48 blocks that are not announced, but all larger blocks require SWIP, and blocks smaller than /48 are also exempt and of course also non-routeable. >>>>>> >>>>>> This is best for those that think SWIP should be limited to only blocks that are individually announced. I could go either way on this issue. >>>>>> >>>>>> Albert Erdmann >>>>>> Network Administrator >>>>>> Paradise On Line Inc. >>>>>> >>>>>> On Mon, 17 Jul 2017, Leif Sawyer wrote: >>>>>> >>>>>>> Shepherd of the draft policy chiming in. >>>>>>> >>>>>>> Thanks for the lively discussion, everybody. There's certainly a lot to think about here. >>>>>>> >>>>>>> Just as a reminder to folk, the current policy under question is located here: >>>>>>> https://www.arin.net/policy/nrpm.html#six551 >>>>>>> >>>>>>> And, to help clarify some confusion, per 6.5.5.3.1 (https://www.arin.net/policy/nrpm.html#six5531) >>>>>>> residential customers "holding/64 and larger blocks" may use censored data, i.e. "Private Customer/Residence" >>>>>>> in lieu of actual names and street addresses. >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> With that said, I have a couple of questions to ask, based on potential rewrites that are brewing. >>>>>>> >>>>>>> First: Assuming a preference for /56 (based on PPML feedback) for the moment, which is the more >>>>>>> preferential rewrite of the opening sentence of 6.5.5.1? >>>>>>> >>>>>>> >>>>>>> a) Each static IPv6 assignment containing a /55 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. >>>>>>> >>>>>>> >>>>>>> >>>>>>> b) Each static IPv6 assignment containing a /55 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. >>>>>>> >>>>>>> >>>>>>> Second: Given your specific choice of A or B, are you preferentially inclined to choose the provided bit-boundary, or "/48" >>>>>>> >>>>>>> Third: If none of these options are palatable, do you have a proposed approach? >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks, >>>>>>> >>>>>>> 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. >>>>> _______________________________________________ >>>>> 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. >>> >> _______________________________________________ >> 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. > > From hostmaster at uneedus.com Mon Jul 24 15:48:23 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Mon, 24 Jul 2017 15:48:23 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4a0a4c2d-5784-b6f5-7ad0-7160966d0236@cameron.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <4a0a4c2d-5784-b6f5-7ad0-7160966d0236@cameron.net> Message-ID: In the case of that 69.0.0.0 block we were talking about, it may not be on the other side of the earth, but certainly in different states. That block had the serving site as CT, the parent record as TX, and a note in that record to send legal process to FL. Quite a trip. What is the purpose of the SWIP record, if the contact is nowhere near the site? Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 24 Jul 2017, Paul McNary wrote: > Then that totally negates the reasoning for geolocation. > The administrative address could be on the other side of the earth. > > Paul > > > On 7/24/2017 1:31 PM, Owen DeLong wrote: >>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>> >>> My transit bus example is another example of SWIP difficulty. Very hard >>> to provide a street address to SWIP a bus when it is mobile 16 hours a >>> day. >> Not at all. A bus would be SWIPd to the bus yard or administrative offices >> of the bus company. The SWIP data is not required to be the service >> address, it is required to be an address for administrative and/or >> technical contact regarding the network and/or legal process service >> regarding same. >> >> [rest trimmed because we are in agreement on that part] >> >> Owen >> >>> On Thu, 20 Jul 2017, Chris James wrote: >>>> @Paul - The API key is to email it. >>>> >>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>> platforms spanning tens of thousands of instances across these dynamic >>>> ranges. >>>> >>>> >>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>> >>>>> Owen >>>>> >>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>> Is that something else that is incorrect on the web site? >>>>> >>>>> Paul >>>>> >>>>> >>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>> >>>>>> How can it be overly difficult to fill out an email template with your >>>>>> customers? >>>>>> Name, Address, Phone Number? >>>>>> >>>>>> Really? >>>>>> >>>>>> Owen >>>>>> >>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>> >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>> data back upstream to ARIN. >>>>>>> >>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>> request-handling workload higher up and overall). But for that to >>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>> >>>>>>> In the end, the contact details should be as close to the "person" >>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>> >>>>>>> eBrain >>>>>>> Innovative Internet Ideas >>>>>>> >>>>>>> Pallieter Koopmans >>>>>>> Managing Director >>>>>>> >>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>> Skype: PallieterKoopmans >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>> -- >>>> This e-mail message may contain confidential or legally privileged >>>> information and is intended only for the use of the intended >>>> recipient(s). >>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>> taking of any action in reliance on the information herein is prohibited. >>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>> with us by e-mail is deemed to have accepted these risks. This company is >>>> not responsible for errors or omissions in this message and denies any >>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>> and other statement contained in this message and any attachment are >>>> solely >>>> those of the author and do not necessarily represent those of the >>>> company. >>> _______________________________________________ >>> 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. > From alh-ietf at tndh.net Mon Jul 24 15:51:03 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 24 Jul 2017 12:51:03 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: Message-ID: <028301d304b6$2f1c2910$8d547b30$@tndh.net> While I agree with the general direction David is heading, his text is still overly complex to deal with the goal. This whole thread only requires 3 lines: Reallocations MUST provide SWIP. Requests by the assignee MUST provide SWIP. Anything appearing independently in the global routing table SHOULD provide SWIP. All the rest is noise that doesn?t add to solving any problem known to mankind, and is simply an artifact of the IPv4-think insane conservation mindset. Size is irrelevant in both protocol versions, and even if you think it is, the only time it comes up is in #3. In any case the length of #3 might change over time, and there is no reason the policy text needs to change to track it. If something is independent, no matter what it?s length is, the intent is to have accurate contact info. Saying anything more is trying to legislate ISP behavior, which is explicitly outside the scope of ARIN. Tony From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Sunday, July 23, 2017 7:03 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 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 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 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvgeekwtrvl at gmail.com Mon Jul 24 16:48:14 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Mon, 24 Jul 2017 13:48:14 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <4a0a4c2d-5784-b6f5-7ad0-7160966d0236@cameron.net> Message-ID: On Mon, Jul 24, 2017 at 12:48 PM, wrote: > In the case of that 69.0.0.0 block we were talking about, it may not be on > the other side of the earth, but certainly in different states. That block > had the serving site as CT, the parent record as TX, and a note in that > record to send legal process to FL. Quite a trip. > > What is the purpose of the SWIP record, if the contact is nowhere near the > site? > > I don't care where you network is. I care that you know what it is doing and that when I contact you about your network you will deal with it. > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On a side note I agree with Tony's version. It's clear and concise and it doesn't require a re-write when a new assignment paradigm comes out to play. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Jul 24 17:07:39 2017 From: farmer at umn.edu (David Farmer) Date: Mon, 24 Jul 2017 16:07:39 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <028301d304b6$2f1c2910$8d547b30$@tndh.net> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> Message-ID: Honestly, I could live with it just those three lines. However, I'm willing to recognize at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /48. As for IPv4, I'd also be just fine with those three lines. Again, recognizing at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /24 On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain wrote: > While I agree with the general direction David is heading, his text is > still overly complex to deal with the goal. This whole thread only requires > 3 lines: > > > > Reallocations MUST provide SWIP. > > Requests by the assignee MUST provide SWIP. > Anything appearing independently in the global routing table SHOULD > provide SWIP. > > > > All the rest is noise that doesn?t add to solving any problem known to > mankind, and is simply an artifact of the IPv4-think insane conservation > mindset. Size is irrelevant in both protocol versions, and even if you > think it is, the only time it comes up is in #3. In any case the length of > #3 might change over time, and there is no reason the policy text needs to > change to track it. If something is independent, no matter what it?s length > is, the intent is to have accurate contact info. > > > > Saying anything more is trying to legislate ISP behavior, which is > explicitly outside the scope of ARIN. > > > > Tony > -- =============================================== 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: From farmer at umn.edu Mon Jul 24 17:52:46 2017 From: farmer at umn.edu (David Farmer) Date: Mon, 24 Jul 2017 16:52:46 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> Message-ID: Actually, let me revise that; I'm willing to recognize at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /40 for IPv6 and /24 for IPv4. Why, those numbers? They are the sizes at the bottom of ARIN's fee schedule, if anything smaller is the same fee, I'm not sure where there is a compelling community policy interest. On Mon, Jul 24, 2017 at 4:07 PM, David Farmer wrote: > Honestly, I could live with it just those three lines. However, I'm > willing to recognize at least the possibility there is a legitimate > community interest in having records for assignments that are shorter than > /48. > > As for IPv4, I'd also be just fine with those three lines. Again, > recognizing at least the possibility there is a legitimate community > interest in having records for assignments that are shorter than /24 > > On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain wrote: > >> While I agree with the general direction David is heading, his text is >> still overly complex to deal with the goal. This whole thread only requires >> 3 lines: >> >> >> >> Reallocations MUST provide SWIP. >> >> Requests by the assignee MUST provide SWIP. >> Anything appearing independently in the global routing table SHOULD >> provide SWIP. >> >> >> >> All the rest is noise that doesn?t add to solving any problem known to >> mankind, and is simply an artifact of the IPv4-think insane conservation >> mindset. Size is irrelevant in both protocol versions, and even if you >> think it is, the only time it comes up is in #3. In any case the length of >> #3 might change over time, and there is no reason the policy text needs to >> change to track it. If something is independent, no matter what it?s length >> is, the intent is to have accurate contact info. >> >> >> >> Saying anything more is trying to legislate ISP behavior, which is >> explicitly outside the scope of ARIN. >> >> >> >> Tony >> > > > -- > =============================================== > 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> > =============================================== > -- =============================================== 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: From alh-ietf at tndh.net Mon Jul 24 20:06:18 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Mon, 24 Jul 2017 17:06:18 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> Message-ID: <02a601d304d9$d7373450$85a59cf0$@tndh.net> I still don?t see any value in specifying length. What you are looking for is contact info for someone with a clue about how a given network works and using length as a really poor proxy. I could live with a fourth line: Any end network emitting SMTP system SHOULD provide SWIP. I just don?t know how that gets enforced in any reasonable way. In general SMTP & independent routing are the big targets needing accurate contact info, and length has absolutely nothing to do with either. Tony From: David Farmer [mailto:farmer at umn.edu] Sent: Monday, July 24, 2017 2:53 PM To: Tony Hain Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 Actually, let me revise that; I'm willing to recognize at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /40 for IPv6 and /24 for IPv4. Why, those numbers? They are the sizes at the bottom of ARIN's fee schedule, if anything smaller is the same fee, I'm not sure where there is a compelling community policy interest. On Mon, Jul 24, 2017 at 4:07 PM, David Farmer wrote: Honestly, I could live with it just those three lines. However, I'm willing to recognize at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /48. As for IPv4, I'd also be just fine with those three lines. Again, recognizing at least the possibility there is a legitimate community interest in having records for assignments that are shorter than /24 On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain wrote: While I agree with the general direction David is heading, his text is still overly complex to deal with the goal. This whole thread only requires 3 lines: Reallocations MUST provide SWIP. Requests by the assignee MUST provide SWIP. Anything appearing independently in the global routing table SHOULD provide SWIP. All the rest is noise that doesn?t add to solving any problem known to mankind, and is simply an artifact of the IPv4-think insane conservation mindset. Size is irrelevant in both protocol versions, and even if you think it is, the only time it comes up is in #3. In any case the length of #3 might change over time, and there is no reason the policy text needs to change to track it. If something is independent, no matter what it?s length is, the intent is to have accurate contact info. Saying anything more is trying to legislate ISP behavior, which is explicitly outside the scope of ARIN. Tony -- =============================================== 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 =============================================== -- =============================================== 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: From michael at linuxmagic.com Tue Jul 25 13:34:37 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Tue, 25 Jul 2017 10:34:37 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <02a601d304d9$d7373450$85a59cf0$@tndh.net> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> Message-ID: <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> On 17-07-24 05:06 PM, Tony Hain wrote: > I still don?t see any value in specifying length. What you are looking > for is contact info for someone with a clue about how a given network > works and using length as a really poor proxy. I could live with a > fourth line: > > Any end network emitting SMTP system SHOULD provide SWIP. > > I just don?t know how that gets enforced in any reasonable way. In > general SMTP & independent routing are the big targets needing accurate > contact info, and length has absolutely nothing to do with either. > > Tony While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing allocation information to the /32 level. This again goes to an earlier email where I described that it should be more conceptual, than specific ranges.. It should be, "if a party is responsible for the originating traffic", then that party should be displayed via SWIP/rwhois. Of course, we can just look at the sad state of this in IPv4, eg large cloud providers assigning IP(s), without any indication who the responsible party is (eg Amazon, MicroSoft, and many large hosting providers) The concern is again, writing something up that is a 'mandate', yet without any form of 'enforcement', it will simply be ignored... -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From info at arin.net Tue Jul 25 15:01:34 2017 From: info at arin.net (ARIN) Date: Tue, 25 Jul 2017 15:01:34 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - July 2017 Message-ID: <5977958E.4070406@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 20 July 2017. The AC is continuing to work on: * ARIN-2017-2: Removal of Community Networks * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 * ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-7: Retire Obsolete Section 4 from the NRPM 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) From owen at delong.com Tue Jul 25 17:25:47 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jul 2017 14:25:47 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <3d0e7e9a-ffa7-7409-3b26-34ec125f7f22@cameron.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com> <3d0e7e9a-ffa7-7409-3b26-34ec125f7f22@cameron.net> Message-ID: I think you?re misinterpreting something on that page. I might be blind, but I don?t read anything on that page to say that IPv6 reassignments must be done by RESTful API. I know that in practice you can do IPv6 reassignments via RWHOIS and I believe templates are also supported as well as ARIN On-Line. Certainly the NRPM is the authoritative governing document, so if there is a shortcoming in the process as implemented such that it doesn?t line up with policy, the correct response would be to bring this to staff?s attention and request that they address it. However, to the best of my knowledge, there is no such discrepancy. If you can highlight the portions of that page which you believe to be errant in nature, I?m happy to try and work with staff to make sure they get clarified. Owen > On Jul 24, 2017, at 12:01 , Paul McNary wrote: > > https://www.arin.net/resources/request/reassignments.html > > > On 7/24/2017 1:28 PM, Owen DeLong wrote: >> >>> On Jul 20, 2017, at 13:51 , Paul McNary > wrote: >>> >>> Owen >>> >>> The reassignment policy page says IPv6 has to be done vi API. >>> Is that something else that is incorrect on the web site? >>> >>> Paul >> >> I?m not sure what the ?reassignment policy page? you refer to is, but here?s the quote from the NRPM: >> >> 6.5.5. Registration >> >> ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. >> >> 6.5.5.1. Reassignment information >> Each static IPv6 assignment containing a /64 or more addresses 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 4.2.3.7.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 holding /64 and larger blocks 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. >> >> I?ll call your attention to the phrase in 6.5.5.1 which states "registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2? which at this point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP. >> >> >> I?ll also note that 6.5.5.3.1 provides for the residential customer privacy as I defined it, regardless of the mechanism used to make the data available. >> >> Given that, can you clarify your above statement? >> >> Owen >> >>> >>> >>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>> How can it be overly difficult to fill out an email template with your customers? >>>> Name, Address, Phone Number? >>>> >>>> Really? >>>> >>>> Owen >>>> >>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans > wrote: >>>>> >>>>> Hello, >>>>> >>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>> end, there are going to be exceptions needed if the rules are to be >>>>> strictly followed. Many will not separately SWIP a separately routed >>>>> sub-block if it is too difficult or pointless to gather and share that >>>>> data back upstream to ARIN. >>>>> >>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>> owners to do their best to provide (only) useful data. In order to do >>>>> that, one needs to look back at why that data is needed. For a block >>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>> and abuse contact requests down to those that are probably more likely >>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>> request-handling workload higher up and overall). But for that to >>>>> work, those tech/abuse contact requests need to be actually handled, >>>>> otherwise, it is better to leave them with the block owner. >>>>> >>>>> In the end, the contact details should be as close to the "person" >>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>> and act (think: authority) on the tech/abuse requests. >>>>> >>>>> eBrain >>>>> Innovative Internet Ideas >>>>> >>>>> Pallieter Koopmans >>>>> Managing Director >>>>> >>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>> Skype: PallieterKoopmans >>>>> _______________________________________________ >>>>> 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. >>> >>> _______________________________________________ >>> 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. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jul 25 17:26:37 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jul 2017 14:26:37 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <4a0a4c2d-5784-b6f5-7ad0-7160966d0236@cameron.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <4a0a4c2d-! 5784-b6f5-7ad0-7160966d0236@cameron.net> Message-ID: Huh? WHOIS is not a geolocation service and anyone who thinks it is should reduce their use of recreational pharmaceuticals. Owen > On Jul 24, 2017, at 12:03 , Paul McNary wrote: > > Then that totally negates the reasoning for geolocation. > The administrative address could be on the other side of the earth. > > Paul > > > On 7/24/2017 1:31 PM, Owen DeLong wrote: >>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>> >>> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >> >> [rest trimmed because we are in agreement on that part] >> >> Owen >> >>> On Thu, 20 Jul 2017, Chris James wrote: >>>> @Paul - The API key is to email it. >>>> >>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>> platforms spanning tens of thousands of instances across these dynamic >>>> ranges. >>>> >>>> >>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>> >>>>> Owen >>>>> >>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>> Is that something else that is incorrect on the web site? >>>>> >>>>> Paul >>>>> >>>>> >>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>> >>>>>> How can it be overly difficult to fill out an email template with your >>>>>> customers? >>>>>> Name, Address, Phone Number? >>>>>> >>>>>> Really? >>>>>> >>>>>> Owen >>>>>> >>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>> data back upstream to ARIN. >>>>>>> >>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>> request-handling workload higher up and overall). But for that to >>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>> >>>>>>> In the end, the contact details should be as close to the "person" >>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>> >>>>>>> eBrain >>>>>>> Innovative Internet Ideas >>>>>>> >>>>>>> Pallieter Koopmans >>>>>>> Managing Director >>>>>>> >>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>> Skype: PallieterKoopmans >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>> -- >>>> This e-mail message may contain confidential or legally privileged >>>> information and is intended only for the use of the intended recipient(s). >>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>> taking of any action in reliance on the information herein is prohibited. >>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>> with us by e-mail is deemed to have accepted these risks. This company is >>>> not responsible for errors or omissions in this message and denies any >>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>> and other statement contained in this message and any attachment are solely >>>> those of the author and do not necessarily represent those of the company. >>> _______________________________________________ >>> 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. From owen at delong.com Tue Jul 25 17:31:46 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jul 2017 14:31:46 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> Message-ID: <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> > On Jul 25, 2017, at 10:34 , Michael Peddemors wrote: > > On 17-07-24 05:06 PM, Tony Hain wrote: >> I still don?t see any value in specifying length. What you are looking for is contact info for someone with a clue about how a given network works and using length as a really poor proxy. I could live with a fourth line: >> Any end network emitting SMTP system SHOULD provide SWIP. >> I just don?t know how that gets enforced in any reasonable way. In general SMTP & independent routing are the big targets needing accurate contact info, and length has absolutely nothing to do with either. >> Tony > > While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing allocation information to the /32 level. > > This again goes to an earlier email where I described that it should be more conceptual, than specific ranges.. > > It should be, "if a party is responsible for the originating traffic", then that party should be displayed via SWIP/rwhois. Well? That?s hard to implement in practice. How do we go about SWIPing all those home windows boxes to the hackers that are actually controlling the emitted traffic? Owen From pmcnary at cameron.net Tue Jul 25 18:11:03 2017 From: pmcnary at cameron.net (Paul McNary) Date: Tue, 25 Jul 2017 17:11:03 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <8109519E-DD0A-4C02-8C2B-248CDE62B9EE@arin.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <2388FEC4-86C3-48CD-8BFD-B186E214828F@delong.com> <3d0e7e9a-ffa7-7409-3b26-34ec125f7f22@cameron.net> Message-ID: <5f3929de-3d30-fb61-7eed-2553d4961b85@cameron.net> "NOTE: IPv6 simple reassigns are only available in the RESTful web service ." On 7/25/2017 4:25 PM, Owen DeLong wrote: > I think you?re misinterpreting something on that page. I might be > blind, but I don?t read anything on that page to say that IPv6 > reassignments must be done by RESTful API. > > I know that in practice you can do IPv6 reassignments via RWHOIS and I > believe templates are also supported as well as ARIN On-Line. > > Certainly the NRPM is the authoritative governing document, so if > there is a shortcoming in the process as implemented such that it > doesn?t line up with policy, the correct response would be to bring > this to staff?s attention and request that they address it. However, > to the best of my knowledge, there is no such discrepancy. > > If you can highlight the portions of that page which you believe to be > errant in nature, I?m happy to try and work with staff to make sure > they get clarified. > > Owen > >> On Jul 24, 2017, at 12:01 , Paul McNary > > wrote: >> >> https://www.arin.net/resources/request/reassignments.html >> >> >> >> On 7/24/2017 1:28 PM, Owen DeLong wrote: >>> >>>> On Jul 20, 2017, at 13:51 , Paul McNary >>> > wrote: >>>> >>>> Owen >>>> >>>> The reassignment policy page says IPv6 has to be done vi API. >>>> Is that something else that is incorrect on the web site? >>>> >>>> Paul >>> >>> I?m not sure what the ?reassignment policy page? you refer to is, >>> but here?s the quote from the NRPM: >>> >>> 6.5.5. Registration >>> >>> ISPs are required to demonstrate efficient use of IP address >>> space allocations by providing appropriate documentation, >>> including but not limited to assignment histories, showing their >>> efficient use. >>> >>> 6.5.5.1. Reassignment information >>> Each static IPv6 assignment containing a /64 or more addresses >>> 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 >>> 4.2.3.7.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 holding /64 >>> and larger blocks 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. >>> >>> I?ll call your attention to the phrase in 6.5.5.1 which states >>> "registered in the WHOIS directory via SWIP or a distributed service >>> which meets the standards set forth in section 3.2? which at this >>> point includes (IIRC) SWIP, RestFUL API, RWHOIS, and possibly RDAP. >>> >>> >>> I?ll also note that 6.5.5.3.1 provides for the residential customer >>> privacy as I defined it, regardless of the mechanism used to make >>> the data available. >>> >>> Given that, can you clarify your above statement? >>> >>> Owen >>> >>>> >>>> >>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>> How can it be overly difficult to fill out an email template with >>>>> your customers? >>>>> Name, Address, Phone Number? >>>>> >>>>> Really? >>>>> >>>>> Owen >>>>> >>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>> > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>> sub-block if it is too difficult or pointless to gather and share >>>>>> that >>>>>> data back upstream to ARIN. >>>>>> >>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>> that, one needs to look back at why that data is needed. For a block >>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>> and abuse contact requests down to those that are probably more >>>>>> likely >>>>>> to be able to actually act on the tech/abuse requests (and thus >>>>>> reduce >>>>>> request-handling workload higher up and overall). But for that to >>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>> otherwise, it is better to leave them with the block owner. >>>>>> >>>>>> In the end, the contact details should be as close to the "person" >>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>> and act (think: authority) on the tech/abuse requests. >>>>>> >>>>>> eBrain >>>>>> Innovative Internet Ideas >>>>>> >>>>>> Pallieter Koopmans >>>>>> Managing Director >>>>>> >>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>> Skype: PallieterKoopmans >>>>>> _______________________________________________ >>>>>> 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. >>>> >>>> _______________________________________________ >>>> 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. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Tue Jul 25 18:12:38 2017 From: pmcnary at cameron.net (Paul McNary) Date: Tue, 25 Jul 2017 17:12:38 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <4a0a4c2d-! 5784-b6f5-7ad0-7160966d0236@cameron.net> Message-ID: Owen Several weeks ago geolocation was one of the arguments for having accurate whois in this thread. This is no longer being argued? Paul On 7/25/2017 4:26 PM, Owen DeLong wrote: > Huh? > > WHOIS is not a geolocation service and anyone who thinks it is should reduce their use of recreational pharmaceuticals. > > Owen > >> On Jul 24, 2017, at 12:03 , Paul McNary wrote: >> >> Then that totally negates the reasoning for geolocation. >> The administrative address could be on the other side of the earth. >> >> Paul >> >> >> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>>> >>>> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >>> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >>> >>> [rest trimmed because we are in agreement on that part] >>> >>> Owen >>> >>>> On Thu, 20 Jul 2017, Chris James wrote: >>>>> @Paul - The API key is to email it. >>>>> >>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>>> platforms spanning tens of thousands of instances across these dynamic >>>>> ranges. >>>>> >>>>> >>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>>> >>>>>> Owen >>>>>> >>>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>>> Is that something else that is incorrect on the web site? >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>>> >>>>>>> How can it be overly difficult to fill out an email template with your >>>>>>> customers? >>>>>>> Name, Address, Phone Number? >>>>>>> >>>>>>> Really? >>>>>>> >>>>>>> Owen >>>>>>> >>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>>> data back upstream to ARIN. >>>>>>>> >>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>>> request-handling workload higher up and overall). But for that to >>>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>>> >>>>>>>> In the end, the contact details should be as close to the "person" >>>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>>> >>>>>>>> eBrain >>>>>>>> Innovative Internet Ideas >>>>>>>> >>>>>>>> Pallieter Koopmans >>>>>>>> Managing Director >>>>>>>> >>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>>> Skype: PallieterKoopmans >>>>>>>> _______________________________________________ >>>>>>>> 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. >>>>>>> >>>>>> _______________________________________________ >>>>>> 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. >>>>> -- >>>>> This e-mail message may contain confidential or legally privileged >>>>> information and is intended only for the use of the intended recipient(s). >>>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>>> taking of any action in reliance on the information herein is prohibited. >>>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>>> with us by e-mail is deemed to have accepted these risks. This company is >>>>> not responsible for errors or omissions in this message and denies any >>>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>>> and other statement contained in this message and any attachment are solely >>>>> those of the author and do not necessarily represent those of the company. >>>> _______________________________________________ >>>> 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. > > From scottleibrand at gmail.com Tue Jul 25 18:17:33 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 25 Jul 2017 15:17:33 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: If I, as an End User network, want to inform geolocation providers of where I'm using each netblock, having them assigned to me in the whois DB with an appropriate address is one of the best ways to do that. But if I'm running a geolocation service, I can't rely on whois as the sole source of data on where an address is used. If I have other info that contradicts the whois information, I'd probably just ignore the whois data and go with the facts on the ground. -Scott On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary wrote: > Owen > Several weeks ago geolocation was one of the arguments for having accurate > whois in this thread. > This is no longer being argued? > Paul > > > On 7/25/2017 4:26 PM, Owen DeLong wrote: > >> Huh? >> >> WHOIS is not a geolocation service and anyone who thinks it is should >> reduce their use of recreational pharmaceuticals. >> >> Owen >> >> On Jul 24, 2017, at 12:03 , Paul McNary wrote: >>> >>> Then that totally negates the reasoning for geolocation. >>> The administrative address could be on the other side of the earth. >>> >>> Paul >>> >>> >>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>> >>>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>>>> >>>>> My transit bus example is another example of SWIP difficulty. Very >>>>> hard to provide a street address to SWIP a bus when it is mobile 16 hours a >>>>> day. >>>>> >>>> Not at all. A bus would be SWIPd to the bus yard or administrative >>>> offices of the bus company. The SWIP data is not required to be the service >>>> address, it is required to be an address for administrative and/or >>>> technical contact regarding the network and/or legal process service >>>> regarding same. >>>> >>>> [rest trimmed because we are in agreement on that part] >>>> >>>> Owen >>>> >>>> On Thu, 20 Jul 2017, Chris James wrote: >>>>> >>>>>> @Paul - The API key is to email it. >>>>>> >>>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>>>> platforms spanning tens of thousands of instances across these dynamic >>>>>> ranges. >>>>>> >>>>>> >>>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary >>>>>> wrote: >>>>>> >>>>>> Owen >>>>>>> >>>>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>>>> Is that something else that is incorrect on the web site? >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>>>> >>>>>>> How can it be overly difficult to fill out an email template with >>>>>>>> your >>>>>>>> customers? >>>>>>>> Name, Address, Phone Number? >>>>>>>> >>>>>>>> Really? >>>>>>>> >>>>>>>> Owen >>>>>>>> >>>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans < >>>>>>>> Pallieter at pallieter.org> >>>>>>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>>>> strictly followed. Many will not separately SWIP a separately >>>>>>>>> routed >>>>>>>>> sub-block if it is too difficult or pointless to gather and share >>>>>>>>> that >>>>>>>>> data back upstream to ARIN. >>>>>>>>> >>>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>>>> owners to do their best to provide (only) useful data. In order to >>>>>>>>> do >>>>>>>>> that, one needs to look back at why that data is needed. For a >>>>>>>>> block >>>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates >>>>>>>>> tech >>>>>>>>> and abuse contact requests down to those that are probably more >>>>>>>>> likely >>>>>>>>> to be able to actually act on the tech/abuse requests (and thus >>>>>>>>> reduce >>>>>>>>> request-handling workload higher up and overall). But for that to >>>>>>>>> work, those tech/abuse contact requests need to be actually >>>>>>>>> handled, >>>>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>>>> >>>>>>>>> In the end, the contact details should be as close to the "person" >>>>>>>>> that is actually capable to both handle (think: >>>>>>>>> volume/languages/etc) >>>>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>>>> >>>>>>>>> eBrain >>>>>>>>> Innovative Internet Ideas >>>>>>>>> >>>>>>>>> Pallieter Koopmans >>>>>>>>> Managing Director >>>>>>>>> >>>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>>>> Skype: PallieterKoopmans >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>> 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. >>>>>>> >>>>>> -- >>>>>> This e-mail message may contain confidential or legally privileged >>>>>> information and is intended only for the use of the intended >>>>>> recipient(s). >>>>>> Any unauthorized disclosure, dissemination, distribution, copying or >>>>>> the >>>>>> taking of any action in reliance on the information herein is >>>>>> prohibited. >>>>>> E-mails are not secure and cannot be guaranteed to be error free as >>>>>> they >>>>>> can be intercepted, amended, or contain viruses. Anyone who >>>>>> communicates >>>>>> with us by e-mail is deemed to have accepted these risks. This >>>>>> company is >>>>>> not responsible for errors or omissions in this message and denies any >>>>>> responsibility for any damage arising from the use of e-mail. Any >>>>>> opinion >>>>>> and other statement contained in this message and any attachment are >>>>>> solely >>>>>> those of the author and do not necessarily represent those of the >>>>>> company. >>>>>> >>>>> _______________________________________________ >>>>> 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. >>>> >>> >> >> > _______________________________________________ > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pmcnary at cameron.net Tue Jul 25 18:46:42 2017 From: pmcnary at cameron.net (Paul McNary) Date: Tue, 25 Jul 2017 17:46:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <94d8a1f6-60a1-f2da-b5f1-d6611b1675d7@cameron.net> Let me change "geolocation" to "address tracking". For instance, Netflix blocks a certain region and whois is showing customer in that region, whereas the customer is actually in a non-blocked region. If I had my own IPv4 /24 or above I don't have any issue making this entry correct to ARIN. But I have a /25 block from a datacenter that shows I am in California. Their SWIP policy on IPv4 is /24 to SWIP. We are trying to minimize these issues as we deploy IPv6 when we have direct allocation. I am not debating the "address tracking" issue just brought it up because I think John made a comment about it. We see ebay, amazon, craig's list all using whois information. Also our /25's have been blocked at the /24 and /18 level. We had /24's blocked that are reallocated at the parent /18 level. So unless there is some way to enforce, it just seems to be words on paper. CHANGE of subject not topic -------------------------------------- What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each Tower(WISP), each POP(ISP) I would want that switched as will as any individually announced block smaller than that. Haven't decided but have a separate /48 to handle DNS, mail servers, etc. ie Our Infrastructure Anything less specific that a /48 would just add noise to the world and would be somewhat proprietary. I give away some info just advertising my POP's/Towers but I think that would be for the collective good. :-) The world doesn't need to know my Access Points or neighborhood routers, etc. I think I need to get off my soapbox and take a nap now! I know I ramble a lot, but getting too old to change much! :-) Thanks Take care Paul On 7/25/2017 5:17 PM, Scott Leibrand wrote: > If I, as an End User network, want to inform geolocation providers of > where I'm using each netblock, having them assigned to me in the whois > DB with an appropriate address is one of the best ways to do that. > But if I'm running a geolocation service, I can't rely on whois as the > sole source of data on where an address is used. If I have other info > that contradicts the whois information, I'd probably just ignore the > whois data and go with the facts on the ground. > > -Scott > > On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary > wrote: > > Owen > Several weeks ago geolocation was one of the arguments for having > accurate whois in this thread. > This is no longer being argued? > Paul > > > On 7/25/2017 4:26 PM, Owen DeLong wrote: > > Huh? > > WHOIS is not a geolocation service and anyone who thinks it is > should reduce their use of recreational pharmaceuticals. > > Owen > > On Jul 24, 2017, at 12:03 , Paul McNary > > wrote: > > Then that totally negates the reasoning for geolocation. > The administrative address could be on the other side of > the earth. > > Paul > > > On 7/24/2017 1:31 PM, Owen DeLong wrote: > > On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com > wrote: > > My transit bus example is another example of SWIP > difficulty. Very hard to provide a street address > to SWIP a bus when it is mobile 16 hours a day. > > Not at all. A bus would be SWIPd to the bus yard or > administrative offices of the bus company. The SWIP > data is not required to be the service address, it is > required to be an address for administrative and/or > technical contact regarding the network and/or legal > process service regarding same. > > [rest trimmed because we are in agreement on that part] > > Owen > > On Thu, 20 Jul 2017, Chris James wrote: > > @Paul - The API key is to email it. > > @Owen - Very difficult when you have dynamic > ranges, and vps/container > platforms spanning tens of thousands of > instances across these dynamic > ranges. > > > On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > > wrote: > > Owen > > The reassignment policy page says IPv6 has > to be done vi API. > Is that something else that is incorrect > on the web site? > > Paul > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: > > How can it be overly difficult to fill > out an email template with your > customers? > Name, Address, Phone Number? > > Really? > > Owen > > On Jul 19, 2017, at 23:48 , Pallieter > Koopmans > > > wrote: > > Hello, > > ARIN could quantify and require > rules for when to SWIP, but in the > end, there are going to be > exceptions needed if the rules are > to be > strictly followed. Many will not > separately SWIP a separately routed > sub-block if it is too difficult > or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require > a best-effort and to add a > rule-based reason (preferably both > a carrot and a stick) for block > owners to do their best to provide > (only) useful data. In order to do > that, one needs to look back at > why that data is needed. For a block > owner to assign the SWIP on a > sub-block, he basically delegates tech > and abuse contact requests down to > those that are probably more likely > to be able to actually act on the > tech/abuse requests (and thus reduce > request-handling workload higher > up and overall). But for that to > work, those tech/abuse contact > requests need to be actually handled, > otherwise, it is better to leave > them with the block owner. > > In the end, the contact details > should be as close to the "person" > that is actually capable to both > handle (think: volume/languages/etc) > and act (think: authority) on the > tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 > (mon-sat > 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. > > _______________________________________________ > 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. > > -- > This e-mail message may contain confidential > or legally privileged > information and is intended only for the use > of the intended recipient(s). > Any unauthorized disclosure, dissemination, > distribution, copying or the > taking of any action in reliance on the > information herein is prohibited. > E-mails are not secure and cannot be > guaranteed to be error free as they > can be intercepted, amended, or contain > viruses. Anyone who communicates > with us by e-mail is deemed to have accepted > these risks. This company is > not responsible for errors or omissions in > this message and denies any > responsibility for any damage arising from the > use of e-mail. Any opinion > and other statement contained in this message > and any attachment are solely > those of the author and do not necessarily > represent those of the company. > > _______________________________________________ > 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. > > > > > _______________________________________________ > 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jul 26 02:13:16 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jul 2017 23:13:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <94d8a1f6-60a1-f2da-b5f1-d6611b1675d7@cameron.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <94d8a1f6-60a1-f2da-b5f1-d6611b1675d7@cameron.net> Message-ID: > On Jul 25, 2017, at 15:46, Paul McNary wrote: > > Let me change "geolocation" to "address tracking". > For instance, Netflix blocks a certain region and whois is showing customer > in that region, whereas the customer is actually in a non-blocked region. > If I had my own IPv4 /24 or above I don't have any issue making this entry correct to ARIN. I know for a fact that Netflix bases very little (if any) of their geo-fencing on Whois data. > But I have a /25 block from a datacenter that shows I am in California. > Their SWIP policy on IPv4 is /24 to SWIP. > We are trying to minimize these issues as we deploy IPv6 when we have direct allocation. > I am not debating the "address tracking" issue just brought it up because I think John made a comment about it. I think if you review the record I stated early on that I didn't believe geolocation was a practical use of Whois. > We see ebay, amazon, craig's list all using whois information. Really? Source needed. In my experience they use other geolocation providers. > Also our /25's have been blocked at the /24 and /18 level. > We had /24's blocked that are reallocated at the parent /18 level. > So unless there is some way to enforce, it just seems to be words on paper. Enforce what? Geolocation is a truly black art and there is no central clearing house or community driven policy body driving its practitioners. > > CHANGE of subject not topic > -------------------------------------- > What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each Tower(WISP), each POP(ISP) > I would want that switched as will as any individually announced block smaller than that. > Haven't decided but have a separate /48 to handle DNS, mail servers, etc. ie Our Infrastructure > Anything less specific that a /48 would just add noise to the world and would be somewhat proprietary. > I give away some info just advertising my POP's/Towers but I think that would be for the collective good. :-) > The world doesn't need to know my Access Points or neighborhood routers, etc. I see no reason you can't accomplish this under the proposed policy. I support the current draft as previously stated. Owen > > I think I need to get off my soapbox and take a nap now! > I know I ramble a lot, but getting too old to change much! :-) > Thanks > Take care > Paul > >> On 7/25/2017 5:17 PM, Scott Leibrand wrote: >> If I, as an End User network, want to inform geolocation providers of where I'm using each netblock, having them assigned to me in the whois DB with an appropriate address is one of the best ways to do that. But if I'm running a geolocation service, I can't rely on whois as the sole source of data on where an address is used. If I have other info that contradicts the whois information, I'd probably just ignore the whois data and go with the facts on the ground. >> >> -Scott >> >>> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary wrote: >>> Owen >>> Several weeks ago geolocation was one of the arguments for having accurate whois in this thread. >>> This is no longer being argued? >>> Paul >>> >>> >>>> On 7/25/2017 4:26 PM, Owen DeLong wrote: >>>> Huh? >>>> >>>> WHOIS is not a geolocation service and anyone who thinks it is should reduce their use of recreational pharmaceuticals. >>>> >>>> Owen >>>> >>>>> On Jul 24, 2017, at 12:03 , Paul McNary wrote: >>>>> >>>>> Then that totally negates the reasoning for geolocation. >>>>> The administrative address could be on the other side of the earth. >>>>> >>>>> Paul >>>>> >>>>> >>>>>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>>>>>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>>>>>> >>>>>>> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >>>>>> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >>>>>> >>>>>> [rest trimmed because we are in agreement on that part] >>>>>> >>>>>> Owen >>>>>> >>>>>>>> On Thu, 20 Jul 2017, Chris James wrote: >>>>>>>> @Paul - The API key is to email it. >>>>>>>> >>>>>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>>>>>> platforms spanning tens of thousands of instances across these dynamic >>>>>>>> ranges. >>>>>>>> >>>>>>>> >>>>>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>>>>>> >>>>>>>>> Owen >>>>>>>>> >>>>>>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>>>>>> Is that something else that is incorrect on the web site? >>>>>>>>> >>>>>>>>> Paul >>>>>>>>> >>>>>>>>> >>>>>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>>>>>> >>>>>>>>>> How can it be overly difficult to fill out an email template with your >>>>>>>>>> customers? >>>>>>>>>> Name, Address, Phone Number? >>>>>>>>>> >>>>>>>>>> Really? >>>>>>>>>> >>>>>>>>>> Owen >>>>>>>>>> >>>>>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>>>>>> data back upstream to ARIN. >>>>>>>>>>> >>>>>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>>>>>> request-handling workload higher up and overall). But for that to >>>>>>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>>>>>> >>>>>>>>>>> In the end, the contact details should be as close to the "person" >>>>>>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>>>>>> >>>>>>>>>>> eBrain >>>>>>>>>>> Innovative Internet Ideas >>>>>>>>>>> >>>>>>>>>>> Pallieter Koopmans >>>>>>>>>>> Managing Director >>>>>>>>>>> >>>>>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>>>>>> Skype: PallieterKoopmans >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >>>>>>>> -- >>>>>>>> This e-mail message may contain confidential or legally privileged >>>>>>>> information and is intended only for the use of the intended recipient(s). >>>>>>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>>>>>> taking of any action in reliance on the information herein is prohibited. >>>>>>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>>>>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>>>>>> with us by e-mail is deemed to have accepted these risks. This company is >>>>>>>> not responsible for errors or omissions in this message and denies any >>>>>>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>>>>>> and other statement contained in this message and any attachment are solely >>>>>>>> those of the author and do not necessarily represent those of the company. >>>>>>> _______________________________________________ >>>>>>> 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. >>>> >>>> >>> >>> _______________________________________________ >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jul 26 02:14:08 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 25 Jul 2017 23:14:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <4a0a4c2d-! 5784-b6f5-7ad0-7160966d0236@cameron.net> Message-ID: <159A99B2-A1A6-412D-872F-99175D3FCC13@delong.com> I called it specious when it was first argued and I continue to call it specious. Owen > On Jul 25, 2017, at 15:12, Paul McNary wrote: > > Owen > Several weeks ago geolocation was one of the arguments for having accurate whois in this thread. > This is no longer being argued? > Paul > >> On 7/25/2017 4:26 PM, Owen DeLong wrote: >> Huh? >> >> WHOIS is not a geolocation service and anyone who thinks it is should reduce their use of recreational pharmaceuticals. >> >> Owen >> >>> On Jul 24, 2017, at 12:03 , Paul McNary wrote: >>> >>> Then that totally negates the reasoning for geolocation. >>> The administrative address could be on the other side of the earth. >>> >>> Paul >>> >>> >>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>>>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>>>> >>>>> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >>>> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >>>> >>>> [rest trimmed because we are in agreement on that part] >>>> >>>> Owen >>>> >>>>>> On Thu, 20 Jul 2017, Chris James wrote: >>>>>> @Paul - The API key is to email it. >>>>>> >>>>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>>>> platforms spanning tens of thousands of instances across these dynamic >>>>>> ranges. >>>>>> >>>>>> >>>>>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary wrote: >>>>>>> >>>>>>> Owen >>>>>>> >>>>>>> The reassignment policy page says IPv6 has to be done vi API. >>>>>>> Is that something else that is incorrect on the web site? >>>>>>> >>>>>>> Paul >>>>>>> >>>>>>> >>>>>>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>>>>>> >>>>>>>> How can it be overly difficult to fill out an email template with your >>>>>>>> customers? >>>>>>>> Name, Address, Phone Number? >>>>>>>> >>>>>>>> Really? >>>>>>>> >>>>>>>> Owen >>>>>>>> >>>>>>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> ARIN could quantify and require rules for when to SWIP, but in the >>>>>>>>> end, there are going to be exceptions needed if the rules are to be >>>>>>>>> strictly followed. Many will not separately SWIP a separately routed >>>>>>>>> sub-block if it is too difficult or pointless to gather and share that >>>>>>>>> data back upstream to ARIN. >>>>>>>>> >>>>>>>>> Thus a more fuzzy rule to require a best-effort and to add a >>>>>>>>> rule-based reason (preferably both a carrot and a stick) for block >>>>>>>>> owners to do their best to provide (only) useful data. In order to do >>>>>>>>> that, one needs to look back at why that data is needed. For a block >>>>>>>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>>>>>>> and abuse contact requests down to those that are probably more likely >>>>>>>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>>>>>>> request-handling workload higher up and overall). But for that to >>>>>>>>> work, those tech/abuse contact requests need to be actually handled, >>>>>>>>> otherwise, it is better to leave them with the block owner. >>>>>>>>> >>>>>>>>> In the end, the contact details should be as close to the "person" >>>>>>>>> that is actually capable to both handle (think: volume/languages/etc) >>>>>>>>> and act (think: authority) on the tech/abuse requests. >>>>>>>>> >>>>>>>>> eBrain >>>>>>>>> Innovative Internet Ideas >>>>>>>>> >>>>>>>>> Pallieter Koopmans >>>>>>>>> Managing Director >>>>>>>>> >>>>>>>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>>>>>>> Skype: PallieterKoopmans >>>>>>>>> _______________________________________________ >>>>>>>>> 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. >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. >>>>>> -- >>>>>> This e-mail message may contain confidential or legally privileged >>>>>> information and is intended only for the use of the intended recipient(s). >>>>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>>>> taking of any action in reliance on the information herein is prohibited. >>>>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>>>> with us by e-mail is deemed to have accepted these risks. This company is >>>>>> not responsible for errors or omissions in this message and denies any >>>>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>>>> and other statement contained in this message and any attachment are solely >>>>>> those of the author and do not necessarily represent those of the company. >>>>> _______________________________________________ >>>>> 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. >> >> From pmcnary at cameron.net Wed Jul 26 05:11:13 2017 From: pmcnary at cameron.net (Paul McNary) Date: Wed, 26 Jul 2017 04:11:13 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <94d8a1f6-60a1-f2da-b5f1-d6611b1675d7@cameron.net> Message-ID: <09e4aa8e-d50d-1de8-46cc-4939feb082cd@cameron.net> Hello Owen I think we are really almost in total agreement! :-) I think we use words a little differently, but It think we want a similar result. "Address Tracking" was not on my concerns list except for possible CPNI violations which I see a solution of how to handle this. Take care Paul On 7/26/2017 1:13 AM, Owen DeLong wrote: > > > On Jul 25, 2017, at 15:46, Paul McNary > wrote: > >> Let me change "geolocation" to "address tracking". >> For instance, Netflix blocks a certain region and whois is showing >> customer >> in that region, whereas the customer is actually in a non-blocked region. >> If I had my own IPv4 /24 or above I don't have any issue making this >> entry correct to ARIN. > > I know for a fact that Netflix bases very little (if any) of their > geo-fencing on Whois data. > >> But I have a /25 block from a datacenter that shows I am in California. >> Their SWIP policy on IPv4 is /24 to SWIP. >> We are trying to minimize these issues as we deploy IPv6 when we have >> direct allocation. >> I am not debating the "address tracking" issue just brought it up >> because I think John made a comment about it. > > I think if you review the record I stated early on that I didn't > believe geolocation was a practical use of Whois. > >> We see ebay, amazon, craig's list all using whois information. > > Really? Source needed. > > In my experience they use other geolocation providers. > >> Also our /25's have been blocked at the /24 and /18 level. >> We had /24's blocked that are reallocated at the parent /18 level. >> So unless there is some way to enforce, it just seems to be words on >> paper. > > Enforce what? Geolocation is a truly black art and there is no central > clearing house or community driven policy body driving its practitioners. > >> >> CHANGE of subject not topic >> -------------------------------------- >> What I had wished to do on IPv6 deployment is assign an IPv6 /48 to >> each Tower(WISP), each POP(ISP) >> I would want that switched as will as any individually announced >> block smaller than that. >> Haven't decided but have a separate /48 to handle DNS, mail servers, >> etc. ie Our Infrastructure >> Anything less specific that a /48 would just add noise to the world >> and would be somewhat proprietary. >> I give away some info just advertising my POP's/Towers but I think >> that would be for the collective good. :-) >> The world doesn't need to know my Access Points or neighborhood >> routers, etc. > > I see no reason you can't accomplish this under the proposed policy. I > support the current draft as previously stated. > > > Owen > >> >> I think I need to get off my soapbox and take a nap now! >> I know I ramble a lot, but getting too old to change much! :-) >> Thanks >> Take care >> Paul >> >> On 7/25/2017 5:17 PM, Scott Leibrand wrote: >>> If I, as an End User network, want to inform geolocation providers >>> of where I'm using each netblock, having them assigned to me in the >>> whois DB with an appropriate address is one of the best ways to do >>> that. But if I'm running a geolocation service, I can't rely on >>> whois as the sole source of data on where an address is used. If I >>> have other info that contradicts the whois information, I'd probably >>> just ignore the whois data and go with the facts on the ground. >>> >>> -Scott >>> >>> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary >> > wrote: >>> >>> Owen >>> Several weeks ago geolocation was one of the arguments for >>> having accurate whois in this thread. >>> This is no longer being argued? >>> Paul >>> >>> >>> On 7/25/2017 4:26 PM, Owen DeLong wrote: >>> >>> Huh? >>> >>> WHOIS is not a geolocation service and anyone who thinks it >>> is should reduce their use of recreational pharmaceuticals. >>> >>> Owen >>> >>> On Jul 24, 2017, at 12:03 , Paul McNary >>> > wrote: >>> >>> Then that totally negates the reasoning for geolocation. >>> The administrative address could be on the other side of >>> the earth. >>> >>> Paul >>> >>> >>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>> >>> On Jul 20, 2017, at 14:28 , >>> hostmaster at uneedus.com >>> wrote: >>> >>> My transit bus example is another example of >>> SWIP difficulty. Very hard to provide a street >>> address to SWIP a bus when it is mobile 16 hours >>> a day. >>> >>> Not at all. A bus would be SWIPd to the bus yard or >>> administrative offices of the bus company. The SWIP >>> data is not required to be the service address, it >>> is required to be an address for administrative >>> and/or technical contact regarding the network >>> and/or legal process service regarding same. >>> >>> [rest trimmed because we are in agreement on that part] >>> >>> Owen >>> >>> On Thu, 20 Jul 2017, Chris James wrote: >>> >>> @Paul - The API key is to email it. >>> >>> @Owen - Very difficult when you have dynamic >>> ranges, and vps/container >>> platforms spanning tens of thousands of >>> instances across these dynamic >>> ranges. >>> >>> >>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary >>> >> > wrote: >>> >>> Owen >>> >>> The reassignment policy page says IPv6 >>> has to be done vi API. >>> Is that something else that is incorrect >>> on the web site? >>> >>> Paul >>> >>> >>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>> >>> How can it be overly difficult to >>> fill out an email template with your >>> customers? >>> Name, Address, Phone Number? >>> >>> Really? >>> >>> Owen >>> >>> On Jul 19, 2017, at 23:48 , >>> Pallieter Koopmans >>> >> > >>> >>> wrote: >>> >>> Hello, >>> >>> ARIN could quantify and require >>> rules for when to SWIP, but in the >>> end, there are going to be >>> exceptions needed if the rules >>> are to be >>> strictly followed. Many will not >>> separately SWIP a separately routed >>> sub-block if it is too difficult >>> or pointless to gather and share >>> that >>> data back upstream to ARIN. >>> >>> Thus a more fuzzy rule to >>> require a best-effort and to add a >>> rule-based reason (preferably >>> both a carrot and a stick) for block >>> owners to do their best to >>> provide (only) useful data. In >>> order to do >>> that, one needs to look back at >>> why that data is needed. For a block >>> owner to assign the SWIP on a >>> sub-block, he basically >>> delegates tech >>> and abuse contact requests down >>> to those that are probably more >>> likely >>> to be able to actually act on >>> the tech/abuse requests (and >>> thus reduce >>> request-handling workload higher >>> up and overall). But for that to >>> work, those tech/abuse contact >>> requests need to be actually >>> handled, >>> otherwise, it is better to leave >>> them with the block owner. >>> >>> In the end, the contact details >>> should be as close to the "person" >>> that is actually capable to both >>> handle (think: volume/languages/etc) >>> and act (think: authority) on >>> the tech/abuse requests. >>> >>> eBrain >>> Innovative Internet Ideas >>> >>> Pallieter Koopmans >>> Managing Director >>> >>> +31-6-3400-3800 >>> (mon-sat >>> 9-22 CET) >>> Skype: PallieterKoopmans >>> _______________________________________________ >>> 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. >>> >>> _______________________________________________ >>> 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. >>> >>> -- >>> This e-mail message may contain confidential >>> or legally privileged >>> information and is intended only for the use >>> of the intended recipient(s). >>> Any unauthorized disclosure, dissemination, >>> distribution, copying or the >>> taking of any action in reliance on the >>> information herein is prohibited. >>> E-mails are not secure and cannot be >>> guaranteed to be error free as they >>> can be intercepted, amended, or contain >>> viruses. Anyone who communicates >>> with us by e-mail is deemed to have accepted >>> these risks. This company is >>> not responsible for errors or omissions in >>> this message and denies any >>> responsibility for any damage arising from >>> the use of e-mail. Any opinion >>> and other statement contained in this >>> message and any attachment are solely >>> those of the author and do not necessarily >>> represent those of the company. >>> >>> _______________________________________________ >>> 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. >>> >>> >>> >>> >>> _______________________________________________ >>> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From oroberts at bell.ca Wed Jul 26 09:50:20 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Wed, 26 Jul 2017 13:50:20 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Ref: Geolocation and SWIPs I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera in remote park. ?A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same?. Is this in ARIN?s policy? ?The SWIP data is not required to be the service address? [cid:image001.jpg at 01C9B448.7DFDA670] Orin Roberts - JNCIA, CCNA, ITILv3 IP PROVISIONING Bell Canada ' 905.614.9338 | ? oroberts at bell.ca On 7/24/2017 1:31 PM, Owen DeLong wrote: On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. [rest trimmed because we are in agreement on that part] Owen On Thu, 20 Jul 2017, Chris James wrote: @Paul - The API key is to email it. @Owen - Very difficult when you have dynamic ranges, and vps/container platforms spanning tens of thousands of instances across these dynamic ranges. On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: Owen The reassignment policy page says IPv6 has to be done vi API. Is that something else that is incorrect on the web site? Paul On 7/20/2017 3:16 PM, Owen DeLong wrote: How can it be overly difficult to fill out an email template with your customers? Name, Address, Phone Number? Really? Owen On Jul 19, 2017, at 23:48 , Pallieter Koopmans > wrote: Hello, ARIN could quantify and require rules for when to SWIP, but in the end, there are going to be exceptions needed if the rules are to be strictly followed. Many will not separately SWIP a separately routed sub-block if it is too difficult or pointless to gather and share that data back upstream to ARIN. Thus a more fuzzy rule to require a best-effort and to add a rule-based reason (preferably both a carrot and a stick) for block owners to do their best to provide (only) useful data. In order to do that, one needs to look back at why that data is needed. For a block owner to assign the SWIP on a sub-block, he basically delegates tech and abuse contact requests down to those that are probably more likely to be able to actually act on the tech/abuse requests (and thus reduce request-handling workload higher up and overall). But for that to work, those tech/abuse contact requests need to be actually handled, otherwise, it is better to leave them with the block owner. In the end, the contact details should be as close to the "person" that is actually capable to both handle (think: volume/languages/etc) and act (think: authority) on the tech/abuse requests. eBrain Innovative Internet Ideas Pallieter Koopmans Managing Director +31-6-3400-3800 (mon-sat 9-22 CET) Skype: PallieterKoopmans _______________________________________________ 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. _______________________________________________ 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. -- This e-mail message may contain confidential or legally privileged information and is intended only for the use of the intended recipient(s). Any unauthorized disclosure, dissemination, distribution, copying or the taking of any action in reliance on the information herein is prohibited. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, or contain viruses. Anyone who communicates with us by e-mail is deemed to have accepted these risks. This company is not responsible for errors or omissions in this message and denies any responsibility for any damage arising from the use of e-mail. Any opinion and other statement contained in this message and any attachment are solely those of the author and do not necessarily represent those of the company. _______________________________________________ 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. _______________________________________________ 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 2491 bytes Desc: image001.jpg URL: From michael at linuxmagic.com Wed Jul 26 10:20:03 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Wed, 26 Jul 2017 07:20:03 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> Message-ID: <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> On 17-07-25 02:31 PM, Owen DeLong wrote: > >> On Jul 25, 2017, at 10:34 , Michael Peddemors wrote: >> >> On 17-07-24 05:06 PM, Tony Hain wrote: >>> I still don?t see any value in specifying length. What you are looking for is contact info for someone with a clue about how a given network works and using length as a really poor proxy. I could live with a fourth line: >>> Any end network emitting SMTP system SHOULD provide SWIP. >>> I just don?t know how that gets enforced in any reasonable way. In general SMTP & independent routing are the big targets needing accurate contact info, and length has absolutely nothing to do with either. >>> Tony >> >> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing allocation information to the /32 level. >> >> This again goes to an earlier email where I described that it should be more conceptual, than specific ranges.. >> >> It should be, "if a party is responsible for the originating traffic", then that party should be displayed via SWIP/rwhois. > > Well? That?s hard to implement in practice. How do we go about SWIPing all those home windows boxes to the hackers that are actually controlling the emitted traffic? > > Owen > I assume you were being flippant/joking. The person who should be contacted if the device is hacked in that case, would 'normally' be the ISP, unless the person notified the ISP that they were taking responsibility. (Same way as they now request a static IP address instead of dynamic) But, in keeping with your 'flippant' style, we do have some ISP's that aren't responsible for the traffic that happens on their networks too ;) -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From hostmaster at uneedus.com Wed Jul 26 11:34:13 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 26 Jul 2017 11:34:13 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: Im sure glad that /32's of static IPv4 are not subject to SWIP, and that SWIP does not require GPS info. If it did, we would be in trouble, as our GPS tracking only updates every 300 seconds or 5 minutes, and we would need a T1 of bandwidth just to keep the SWIP updated, and for what purpose? In all cases the only place that will address abuse is our NOC. Right now, all 500+ busses use a static IPv4 address, that is assigned by the Major wireless provider. They are NOT in a block reserved for us. They are scattered around several blocks of addresses of the provider, some of which they appear to be leasing from another party, and those SWIP records list the leasing company. None of them have a SWIP to us, our provider has to forward the reports to us, sometimes thru the leasing co. Before the bus wifi was added, we had NO abuse reports. Now, out of this fleet, we draw about 2 a month, all associated with the public wifi. We do filter port 25 to keep spammers from setting up on our busses, along with a block of other problem ports and locations. As we move to v6, I am hoping the policy will change from 100% SWIP to a level not requiring it. This is because our provider insists the current ARIN rule requires a street address for each bus. I think I will point them to the thread that states the site address is not required in SWIP, and we can use the ADMIN address, or better yet wait for the policy to change and let them forward reports just like they do in v4. In any case, my guess is that nearly no abuse will happen on v6 for lack of customer abuse, and we will continue to receive a couple of reports a month on the new contract dynamic addresses, if they at the provider can even figure out who to send them to, as in the future the addresses for v4 might be CGnat, and they would have to figure out who did it. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 26 Jul 2017, Roberts, Orin wrote: > Ref: Geolocation and SWIPs > > I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera in remote park. > > ???A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same???. > > Is this in ARIN???s policy? ???The SWIP data is not required to be the service address??? > > > > > [cid:image001.jpg at 01C9B448.7DFDA670] > > > > Orin Roberts - JNCIA, CCNA, ITILv3 > IP PROVISIONING > Bell Canada > > ' 905.614.9338 | ??? oroberts at bell.ca > > > > On 7/24/2017 1:31 PM, Owen DeLong wrote: > On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: > > My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. > Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. > > [rest trimmed because we are in agreement on that part] > > Owen > On Thu, 20 Jul 2017, Chris James wrote: > @Paul - The API key is to email it. > > @Owen - Very difficult when you have dynamic ranges, and vps/container > platforms spanning tens of thousands of instances across these dynamic > ranges. > > > On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: > Owen > > The reassignment policy page says IPv6 has to be done vi API. > Is that something else that is incorrect on the web site? > > Paul > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: > How can it be overly difficult to fill out an email template with your > customers??? > Name, Address, Phone Number? > > Really? > > Owen > > On Jul 19, 2017, at 23:48 , Pallieter Koopmans > > wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. > _______________________________________________ > 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. > -- > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. This company is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > _______________________________________________ > 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. > > > _______________________________________________ > 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. > > From sethm at rollernet.us Wed Jul 26 11:50:42 2017 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 26 Jul 2017 08:50:42 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: On 7/26/17 08:34, hostmaster at uneedus.com wrote: > Im sure glad that /32's of static IPv4 are not subject to SWIP, and that > SWIP does not require GPS info. > > If it did, we would be in trouble, as our GPS tracking only updates > every 300 seconds or 5 minutes, and we would need a T1 of bandwidth just > to keep the SWIP updated, and for what purpose? In all cases the only > place that will address abuse is our NOC. If anyone really cares about the GPS location of a given IP at any time, just dynamically update some DNS LOC records. This entire thread has gone beyond insane. I can't believe this list is actually discussing where a bus is located in whois. The only thing I give a crap about whois for is that the contact is someone with authority over the IP in question. ~Seth From jschiller at google.com Wed Jul 26 13:47:29 2017 From: jschiller at google.com (Jason Schiller) Date: Wed, 26 Jul 2017 13:47:29 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> Message-ID: David, Tony, Thank you for bringing up the IPS must SWIP when address user asks. Scott, Thank you for putting the changes in context. I oppose as written. I support with the David/Tony friendly admendment. Why? > It should be required for an ISP to SWIP / Rwhois any reassignment > when the down stream address user has requested such. > > It is sometimes useful to SWIP the reassignemnts to the down stream > organization so that the down stream organization can provide their abuse > contact or technical support contact info, or public comments. > > I fear without my friendly amendment the policy change may send > the wrong message and suggest that an ISP can safely conclude > that if they are never going to support mutli-homing, and if they never > give out anything larger than a /48, that they do not need to support the > facility to SWIP at all, and can openly refuse all SWIPs for IPv6 > re-assignments. Possible simple text addition: On Fri, Jul 21, 2017 at 1:34 PM, Scott Leibrand wrote: > > > For clarity, so we don't all have to do it, and to help make sure we're > not missing anything, here's what the resulting 6.5.5 looks like after > modification: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to assignment histories, showing their efficient use. > > 6.5.5.1. Re-allocation / Reassignment information > > Each of the following 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. > > - static IPv6 re-assignment containing a /47 or more addresses, > - sub-delegation of any size that will be individually announced, - any re-assignment where the address holder specifically requests a reassign simple, reassign detail, or (if applicable) privacy registration - re-allocations of any size > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.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. > > -Scott > > I'd like to (mostly) stay out of the MUST/SHOULD discussion wrt the requirement to SWIP if the intent is to route. I prefer MUST over SHOULD and SHOULD over no advice. I feel strongly that at the least the advice should be preserved. __Jason On Mon, Jul 24, 2017 at 5:07 PM, David Farmer wrote: > Honestly, I could live with it just those three lines. However, I'm > willing to recognize at least the possibility there is a legitimate > community interest in having records for assignments that are shorter than > /48. > > As for IPv4, I'd also be just fine with those three lines. Again, > recognizing at least the possibility there is a legitimate community > interest in having records for assignments that are shorter than /24 > > On Mon, Jul 24, 2017 at 2:51 PM, Tony Hain wrote: > >> While I agree with the general direction David is heading, his text is >> still overly complex to deal with the goal. This whole thread only requires >> 3 lines: >> >> >> >> Reallocations MUST provide SWIP. >> >> Requests by the assignee MUST provide SWIP. >> Anything appearing independently in the global routing table SHOULD >> provide SWIP. >> >> >> >> All the rest is noise that doesn?t add to solving any problem known to >> mankind, and is simply an artifact of the IPv4-think insane conservation >> mindset. Size is irrelevant in both protocol versions, and even if you >> think it is, the only time it comes up is in #3. In any case the length of >> #3 might change over time, and there is no reason the policy text needs to >> change to track it. If something is independent, no matter what it?s length >> is, the intent is to have accurate contact info. >> >> >> >> Saying anything more is trying to legislate ISP behavior, which is >> explicitly outside the scope of ARIN. >> >> >> >> Tony >> > > > -- > =============================================== > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at egh.com Wed Jul 26 13:51:50 2017 From: john at egh.com (John Santos) Date: Wed, 26 Jul 2017 13:51:50 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: On 7/26/2017 11:34 AM, hostmaster at uneedus.com wrote: > > Right now, all 500+ busses use a static IPv4 address, that is assigned > by the Major wireless provider. They are NOT in a block reserved for > us. They are scattered around several blocks of addresses of the > provider, some of which they appear to be leasing from another party, > and those SWIP records list the leasing company. None of them have a > SWIP to us, our provider has to forward the reports to us, sometimes > thru the leasing co. When one ISP leases addresses to a 2nd ISP, shouldn't that 1st ISP SWIP those address blocks to the lessee? In your case, this would reduce the complexity of abuse report handling, since everything would (or should) go directly to your ISP and directly from them to you. As far as SWIPing the individual buses to their constantly changing locations, that sounds to me utterly pointless. Would someone be expecting the bus driver to handle abuse complaints about a passenger on the bus who sent a lot of spam two days ago? Clearly, the SWIP records should point to the Org contact (i.e. your bus company or transit authority) and the Org POC information, (i.e. the person or group which handles abuse and technical issues relating to the buses.) This is borne out by actually looking at the information ARIN requires, is exactly the information requested on the ARIN form "ARIN-REASSIGN-DETAILED", which is the form your ISP should be using to SWIP your bus networks (if they are using the "email a SWIP request", which I assume is the same set of information as would be required by the RESTful or online assignment methods.) Furthermore, if the ORG already has an ORG-ID on file, the only information required is the Org ID, the IP address block, the network's name and the upstream AS. The contact information would necessarily be identical for every bus. As for the policy, I support the current version, i.e. not changing the current IPv4 policy (which as far as I can tell, would require all the individual bus subnets to be SWIPed to the bus company, not to the individual buses, with the contact info for the bus company's network tech staff*), and changing the IPv6 size so as to exclude residences and small businesses which typically let their ISP handle technical and abuse issues. The exact value of the IPv6 network size is not important to me, but I think if /48 is the current best practice recommendation, the limit should be /47 or larger, which /48 SWIPable at the customer's request. [*]Which, I think, can be contracted out to some other organization, i.e. the email and physical address can be that of a service provider, not necessarily a bus company employee or the physical address of the bus yard or the building where the bus company's offices are, as long as they are contractually responsible for network management for the bus company.) -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From owen at delong.com Wed Jul 26 15:20:43 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 12:20:43 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: <09e4aa8e-d50d-1de8-46cc-4939feb082cd@cameron.net> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <94d8a1f6-60a1-f2da-b5f1-d6611b1675d7@cameron.net> ! <09e4aa8e-d50d-1de8-46cc-4939feb082cd@cameron.net> Message-ID: <8FDF93CD-C3CC-48D8-BDD7-D947B4572500@delong.com> I believe that both the existing and proposed policies handle the CPNI issues sufficiently through the ARIN requirement that providers require similar reassignment terms from their assignees and other recipients. Otherwise, yes, I think we are in agreement about the policy. Owen > On Jul 26, 2017, at 02:11 , Paul McNary wrote: > > Hello Owen > I think we are really almost in total agreement! :-) > I think we use words a little differently, but It think > we want a similar result. "Address Tracking" was not > on my concerns list except for possible CPNI violations > which I see a solution of how to handle this. > Take care > Paul > > On 7/26/2017 1:13 AM, Owen DeLong wrote: >> >> >> On Jul 25, 2017, at 15:46, Paul McNary > wrote: >> >>> Let me change "geolocation" to "address tracking". >>> For instance, Netflix blocks a certain region and whois is showing customer >>> in that region, whereas the customer is actually in a non-blocked region. >>> If I had my own IPv4 /24 or above I don't have any issue making this entry correct to ARIN. >> >> I know for a fact that Netflix bases very little (if any) of their geo-fencing on Whois data. >> >>> But I have a /25 block from a datacenter that shows I am in California. >>> Their SWIP policy on IPv4 is /24 to SWIP. >>> We are trying to minimize these issues as we deploy IPv6 when we have direct allocation. >>> I am not debating the "address tracking" issue just brought it up because I think John made a comment about it. >> >> I think if you review the record I stated early on that I didn't believe geolocation was a practical use of Whois. >> >>> We see ebay, amazon, craig's list all using whois information. >> >> Really? Source needed. >> >> In my experience they use other geolocation providers. >> >>> Also our /25's have been blocked at the /24 and /18 level. >>> We had /24's blocked that are reallocated at the parent /18 level. >>> So unless there is some way to enforce, it just seems to be words on paper. >> >> Enforce what? Geolocation is a truly black art and there is no central clearing house or community driven policy body driving its practitioners. >> >>> >>> CHANGE of subject not topic >>> -------------------------------------- >>> What I had wished to do on IPv6 deployment is assign an IPv6 /48 to each Tower(WISP), each POP(ISP) >>> I would want that switched as will as any individually announced block smaller than that. >>> Haven't decided but have a separate /48 to handle DNS, mail servers, etc. ie Our Infrastructure >>> Anything less specific that a /48 would just add noise to the world and would be somewhat proprietary. >>> I give away some info just advertising my POP's/Towers but I think that would be for the collective good. :-) >>> The world doesn't need to know my Access Points or neighborhood routers, etc. >> >> I see no reason you can't accomplish this under the proposed policy. I support the current draft as previously stated. >> >> >> Owen >> >>> >>> I think I need to get off my soapbox and take a nap now! >>> I know I ramble a lot, but getting too old to change much! :-) >>> Thanks >>> Take care >>> Paul >>> >>> On 7/25/2017 5:17 PM, Scott Leibrand wrote: >>>> If I, as an End User network, want to inform geolocation providers of where I'm using each netblock, having them assigned to me in the whois DB with an appropriate address is one of the best ways to do that. But if I'm running a geolocation service, I can't rely on whois as the sole source of data on where an address is used. If I have other info that contradicts the whois information, I'd probably just ignore the whois data and go with the facts on the ground. >>>> >>>> -Scott >>>> >>>> On Tue, Jul 25, 2017 at 3:12 PM, Paul McNary > wrote: >>>> Owen >>>> Several weeks ago geolocation was one of the arguments for having accurate whois in this thread. >>>> This is no longer being argued? >>>> Paul >>>> >>>> >>>> On 7/25/2017 4:26 PM, Owen DeLong wrote: >>>> Huh? >>>> >>>> WHOIS is not a geolocation service and anyone who thinks it is should reduce their use of recreational pharmaceuticals. >>>> >>>> Owen >>>> >>>> On Jul 24, 2017, at 12:03 , Paul McNary > wrote: >>>> >>>> Then that totally negates the reasoning for geolocation. >>>> The administrative address could be on the other side of the earth. >>>> >>>> Paul >>>> >>>> >>>> On 7/24/2017 1:31 PM, Owen DeLong wrote: >>>> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >>>> >>>> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >>>> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >>>> >>>> [rest trimmed because we are in agreement on that part] >>>> >>>> Owen >>>> >>>> On Thu, 20 Jul 2017, Chris James wrote: >>>> @Paul - The API key is to email it. >>>> >>>> @Owen - Very difficult when you have dynamic ranges, and vps/container >>>> platforms spanning tens of thousands of instances across these dynamic >>>> ranges. >>>> >>>> >>>> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: >>>> >>>> Owen >>>> >>>> The reassignment policy page says IPv6 has to be done vi API. >>>> Is that something else that is incorrect on the web site? >>>> >>>> Paul >>>> >>>> >>>> On 7/20/2017 3:16 PM, Owen DeLong wrote: >>>> >>>> How can it be overly difficult to fill out an email template with your >>>> customers? >>>> Name, Address, Phone Number? >>>> >>>> Really? >>>> >>>> Owen >>>> >>>> On Jul 19, 2017, at 23:48 , Pallieter Koopmans > >>>> wrote: >>>> >>>> Hello, >>>> >>>> ARIN could quantify and require rules for when to SWIP, but in the >>>> end, there are going to be exceptions needed if the rules are to be >>>> strictly followed. Many will not separately SWIP a separately routed >>>> sub-block if it is too difficult or pointless to gather and share that >>>> data back upstream to ARIN. >>>> >>>> Thus a more fuzzy rule to require a best-effort and to add a >>>> rule-based reason (preferably both a carrot and a stick) for block >>>> owners to do their best to provide (only) useful data. In order to do >>>> that, one needs to look back at why that data is needed. For a block >>>> owner to assign the SWIP on a sub-block, he basically delegates tech >>>> and abuse contact requests down to those that are probably more likely >>>> to be able to actually act on the tech/abuse requests (and thus reduce >>>> request-handling workload higher up and overall). But for that to >>>> work, those tech/abuse contact requests need to be actually handled, >>>> otherwise, it is better to leave them with the block owner. >>>> >>>> In the end, the contact details should be as close to the "person" >>>> that is actually capable to both handle (think: volume/languages/etc) >>>> and act (think: authority) on the tech/abuse requests. >>>> >>>> eBrain >>>> Innovative Internet Ideas >>>> >>>> Pallieter Koopmans >>>> Managing Director >>>> >>>> +31-6-3400-3800 (mon-sat 9-22 CET) >>>> Skype: PallieterKoopmans >>>> _______________________________________________ >>>> 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. >>>> >>>> _______________________________________________ >>>> 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. >>>> -- >>>> This e-mail message may contain confidential or legally privileged >>>> information and is intended only for the use of the intended recipient(s). >>>> Any unauthorized disclosure, dissemination, distribution, copying or the >>>> taking of any action in reliance on the information herein is prohibited. >>>> E-mails are not secure and cannot be guaranteed to be error free as they >>>> can be intercepted, amended, or contain viruses. Anyone who communicates >>>> with us by e-mail is deemed to have accepted these risks. This company is >>>> not responsible for errors or omissions in this message and denies any >>>> responsibility for any damage arising from the use of e-mail. Any opinion >>>> and other statement contained in this message and any attachment are solely >>>> those of the author and do not necessarily represent those of the company. >>>> _______________________________________________ >>>> 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. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jul 26 15:21:55 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 12:21:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <47320475-F70F-43F5-BC3B-F2D9AF260F5B@delong.com> I don?t know if it is spelled out in policy, but it is certainly widespread practice and I know of nothing prohibiting it. Owen > On Jul 26, 2017, at 06:50 , Roberts, Orin wrote: > > Ref: Geolocation and SWIPs > > I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera in remote park. > > ?A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same?. > > Is this in ARIN?s policy? ?The SWIP data is not required to be the service address? > > > > > > > > Orin Roberts - JNCIA, CCNA, ITILv3 > IP PROVISIONING > Bell Canada > ' 905.614.9338 | * oroberts at bell.ca > > > > On 7/24/2017 1:31 PM, Owen DeLong wrote: > On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: > > My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. > Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. > > [rest trimmed because we are in agreement on that part] > > Owen > > On Thu, 20 Jul 2017, Chris James wrote: > @Paul - The API key is to email it. > > @Owen - Very difficult when you have dynamic ranges, and vps/container > platforms spanning tens of thousands of instances across these dynamic > ranges. > > > On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: > > Owen > > The reassignment policy page says IPv6 has to be done vi API. > Is that something else that is incorrect on the web site? > > Paul > > > On 7/20/2017 3:16 PM, Owen DeLong wrote: > > How can it be overly difficult to fill out an email template with your > customers? > Name, Address, Phone Number? > > Really? > > Owen > > On Jul 19, 2017, at 23:48 , Pallieter Koopmans > > wrote: > > Hello, > > ARIN could quantify and require rules for when to SWIP, but in the > end, there are going to be exceptions needed if the rules are to be > strictly followed. Many will not separately SWIP a separately routed > sub-block if it is too difficult or pointless to gather and share that > data back upstream to ARIN. > > Thus a more fuzzy rule to require a best-effort and to add a > rule-based reason (preferably both a carrot and a stick) for block > owners to do their best to provide (only) useful data. In order to do > that, one needs to look back at why that data is needed. For a block > owner to assign the SWIP on a sub-block, he basically delegates tech > and abuse contact requests down to those that are probably more likely > to be able to actually act on the tech/abuse requests (and thus reduce > request-handling workload higher up and overall). But for that to > work, those tech/abuse contact requests need to be actually handled, > otherwise, it is better to leave them with the block owner. > > In the end, the contact details should be as close to the "person" > that is actually capable to both handle (think: volume/languages/etc) > and act (think: authority) on the tech/abuse requests. > > eBrain > Innovative Internet Ideas > > Pallieter Koopmans > Managing Director > > +31-6-3400-3800 (mon-sat 9-22 CET) > Skype: PallieterKoopmans > _______________________________________________ > 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. > > _______________________________________________ > 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. > -- > This e-mail message may contain confidential or legally privileged > information and is intended only for the use of the intended recipient(s). > Any unauthorized disclosure, dissemination, distribution, copying or the > taking of any action in reliance on the information herein is prohibited. > E-mails are not secure and cannot be guaranteed to be error free as they > can be intercepted, amended, or contain viruses. Anyone who communicates > with us by e-mail is deemed to have accepted these risks. This company is > not responsible for errors or omissions in this message and denies any > responsibility for any damage arising from the use of e-mail. Any opinion > and other statement contained in this message and any attachment are solely > those of the author and do not necessarily represent those of the company. > _______________________________________________ > 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. > > > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jul 26 15:24:19 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 12:24:19 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: > On Jul 26, 2017, at 07:20 , Michael Peddemors wrote: > > On 17-07-25 02:31 PM, Owen DeLong wrote: >>> On Jul 25, 2017, at 10:34 , Michael Peddemors wrote: >>> >>> On 17-07-24 05:06 PM, Tony Hain wrote: >>>> I still don?t see any value in specifying length. What you are looking for is contact info for someone with a clue about how a given network works and using length as a really poor proxy. I could live with a fourth line: >>>> Any end network emitting SMTP system SHOULD provide SWIP. >>>> I just don?t know how that gets enforced in any reasonable way. In general SMTP & independent routing are the big targets needing accurate contact info, and length has absolutely nothing to do with either. >>>> Tony >>> >>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing allocation information to the /32 level. >>> >>> This again goes to an earlier email where I described that it should be more conceptual, than specific ranges.. >>> >>> It should be, "if a party is responsible for the originating traffic", then that party should be displayed via SWIP/rwhois. >> Well? That?s hard to implement in practice. How do we go about SWIPing all those home windows boxes to the hackers that are actually controlling the emitted traffic? >> Owen > > I assume you were being flippant/joking. The person who should be contacted if the device is hacked in that case, would 'normally' be the ISP, unless the person notified the ISP that they were taking responsibility. (Same way as they now request a static IP address instead of dynamic) Yes, Of course I was joking, but my point is that it really isn?t ?the party responsible for originating the traffic? rather than ?the closest knowledgeable party to the party responsible for the operation of the machine originating the traffic. > But, in keeping with your 'flippant' style, we do have some ISP's that aren't responsible for the traffic that happens on their networks too ;) Well? We have ISPs that fail to act responsibly about traffic that happens on their network. Saying they are not actually responsible is another question which I don?t necessarily agree with. Owen From owen at delong.com Wed Jul 26 15:43:55 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 12:43:55 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <6CD3654F-EE89-4E1E-9553-A7B80BC82EE2@arin.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> > On Jul 26, 2017, at 08:34 , hostmaster at uneedus.com wrote: > > Im sure glad that /32's of static IPv4 are not subject to SWIP, and that SWIP does not require GPS info. > > If it did, we would be in trouble, as our GPS tracking only updates every 300 seconds or 5 minutes, and we would need a T1 of bandwidth just to keep the SWIP updated, and for what purpose? In all cases the only place that will address abuse is our NOC. If your GPS updates every 5 minutes, then that?s a $GPGGA and possibly a $GPRMC sentence every 300 seconds. In general, each of these sentences is under 80 characters (usually around 64 characters IIRC). Conservatively using 80 characters, we have 80*8=640 bits every 300 seconds. This leaves 1,572,224 bits per second on a T1 for protocol overhead. OTOH, if you?re talking about the SWIP template size (reassign simple is all that this really calls for), then that?s a bit larger, weighing in at 463*8 = 3,704 bits without any data added to the basic template. Let?s assume another an average of 40 characters (probably closer to 20, but let?s again be conservative) for each of the 12 fields giving us an additional 480*8=3,804 bits for a total of 7,508 bits. Adding EMAIL message size overhead and TCP/IP overhead, let?s call it an even 16Kbits per SWIP. (that?s pretty high overhead, I think) At that rate (16kbb per 300 seconds, A T1 requirement means you need to support 28,800 busses in your system. As such, 1,000 busses or less actually fit on a DS0 with room to spare. > Right now, all 500+ busses use a static IPv4 address, that is assigned by the Major wireless provider. They are NOT in a block reserved for us. They are scattered around several blocks of addresses of the provider, some of which they appear to be leasing from another party, and those SWIP records list the leasing company. None of them have a SWIP to us, our provider has to forward the reports to us, sometimes thru the leasing co. While there may be people willing to SWIP GPS coordinates, I would argue this is the exception rather than the rule and constantly updating SWIP to reflect the location of a mobile element rather than simply SWIPing it to a headquarters location is illogical in the extreme. > As we move to v6, I am hoping the policy will change from 100% SWIP to a level not requiring it. This is because our provider insists the current ARIN rule requires a street address for each bus. I think I will point them to the thread that states the site address is not required in SWIP, and we can use the ADMIN address, or better yet wait for the policy to change and let them forward reports just like they do in v4. In any case, my guess is that nearly no abuse will happen on v6 for lack of customer abuse, and we will continue to receive a couple of reports a month on the new contract dynamic addresses, if they at the provider can even figure out who to send them to, as in the future the addresses for v4 might be CGnat, and they would have to figure out who did it. The provider is mistaken. The current ARIN rule requires a street address for each customer delegation in excess of a /64. If he delegates a /48 to the bus company (or even a /32 or a /24 or whatever), then he only needs to SWIP the address of the bus company on that particular block and he has fulfilled his ARIN obligations. (This is my personal opinion and not an official statement from ARIN staff or the AC, however, I?m sure one of those entities will correct me quickly and publicly if I am wrong). I?ve worked for and with a number of ISPs and end users and dealt with many ARIN allocations and assignments as well as many reallocations and reassignments to downstream customers. I assure you that SWIPing individual busses even if each bus got an IPv4 /24 would be considered illogical by virtually anyone involved in the process and that SWIPing an aggregate block to the bus company would make much more sense. If each bus gets a random IPv6 static assignment individually and they can?t be aggregated, then, they would have to be SWIP?d individually, but they could still be SWIP?d to the address and name of the bus company without requiring the current location of the individual bus in question. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Wed, 26 Jul 2017, Roberts, Orin wrote: > >> Ref: Geolocation and SWIPs >> >> I have seen SWIPs with GPS coordinates similar to the bus example; wifi/camera in remote park. >> >> ?A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same?. >> >> Is this in ARIN?s policy? ?The SWIP data is not required to be the service address? >> >> >> >> >> [cid:image001.jpg at 01C9B448.7DFDA670] >> >> >> >> Orin Roberts - JNCIA, CCNA, ITILv3 >> IP PROVISIONING >> Bell Canada >> >> ' 905.614.9338 | ? oroberts at bell.ca >> >> >> >> On 7/24/2017 1:31 PM, Owen DeLong wrote: >> On Jul 20, 2017, at 14:28 , hostmaster at uneedus.com wrote: >> >> My transit bus example is another example of SWIP difficulty. Very hard to provide a street address to SWIP a bus when it is mobile 16 hours a day. >> Not at all. A bus would be SWIPd to the bus yard or administrative offices of the bus company. The SWIP data is not required to be the service address, it is required to be an address for administrative and/or technical contact regarding the network and/or legal process service regarding same. >> >> [rest trimmed because we are in agreement on that part] >> >> Owen >> On Thu, 20 Jul 2017, Chris James wrote: >> @Paul - The API key is to email it. >> >> @Owen - Very difficult when you have dynamic ranges, and vps/container >> platforms spanning tens of thousands of instances across these dynamic >> ranges. >> >> >> On Thu, Jul 20, 2017 at 1:51 PM, Paul McNary > wrote: >> Owen >> >> The reassignment policy page says IPv6 has to be done vi API. >> Is that something else that is incorrect on the web site? >> >> Paul >> >> >> On 7/20/2017 3:16 PM, Owen DeLong wrote: >> How can it be overly difficult to fill out an email template with your >> customers? >> Name, Address, Phone Number? >> >> Really? >> >> Owen >> >> On Jul 19, 2017, at 23:48 , Pallieter Koopmans > >> wrote: >> >> Hello, >> >> ARIN could quantify and require rules for when to SWIP, but in the >> end, there are going to be exceptions needed if the rules are to be >> strictly followed. Many will not separately SWIP a separately routed >> sub-block if it is too difficult or pointless to gather and share that >> data back upstream to ARIN. >> >> Thus a more fuzzy rule to require a best-effort and to add a >> rule-based reason (preferably both a carrot and a stick) for block >> owners to do their best to provide (only) useful data. In order to do >> that, one needs to look back at why that data is needed. For a block >> owner to assign the SWIP on a sub-block, he basically delegates tech >> and abuse contact requests down to those that are probably more likely >> to be able to actually act on the tech/abuse requests (and thus reduce >> request-handling workload higher up and overall). But for that to >> work, those tech/abuse contact requests need to be actually handled, >> otherwise, it is better to leave them with the block owner. >> >> In the end, the contact details should be as close to the "person" >> that is actually capable to both handle (think: volume/languages/etc) >> and act (think: authority) on the tech/abuse requests. >> >> eBrain >> Innovative Internet Ideas >> >> Pallieter Koopmans >> Managing Director >> >> +31-6-3400-3800 (mon-sat 9-22 CET) >> Skype: PallieterKoopmans >> _______________________________________________ >> 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. >> _______________________________________________ >> 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. >> -- >> This e-mail message may contain confidential or legally privileged >> information and is intended only for the use of the intended recipient(s). >> Any unauthorized disclosure, dissemination, distribution, copying or the >> taking of any action in reliance on the information herein is prohibited. >> E-mails are not secure and cannot be guaranteed to be error free as they >> can be intercepted, amended, or contain viruses. Anyone who communicates >> with us by e-mail is deemed to have accepted these risks. This company is >> not responsible for errors or omissions in this message and denies any >> responsibility for any damage arising from the use of e-mail. Any opinion >> and other statement contained in this message and any attachment are solely >> those of the author and do not necessarily represent those of the company. >> _______________________________________________ >> 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. >> >> >> _______________________________________________ >> 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. From hostmaster at uneedus.com Wed Jul 26 18:19:12 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 26 Jul 2017 18:19:12 -0400 (EDT) Subject: [arin-ppml] Policy Question for ARIN regarding SWIP In-Reply-To: <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> Message-ID: There has been some discussion regarding this question on the PPML, and since I received different answers regarding this and nothing official that I can find in the NRPM, I have decided to reach out to someone from ARIN for an answer. Currently NRPM 6.5.5.1 requires a static assignment of a /64 or more of IPv6 space to be registered in SWIP. When registered, can the contact address be that of a central site managing that site, or is the service address of the site itself, including the Zip Code required? The following is background information: I have need for a static assignment of IPv6 from a certain Major wireless provider, because said provider will no longer provide us static IPv4 addresses after our current contract ends. We currently have 500+ sites with one static IPv4 address each. We want to add at minimum a /60 of static IPv6 to each site, which according to the current NRPM requires SWIP. Each "Site" is a public transit bus, operated by a unit of State Government, and its location is not fixed. Said Major wireless provider tells me that ARIN requires a street address for each site in SWIP, and this information must be the service address, and that each site's address must be unique. I maintain that we should be able to use the contact address of the administrative headquarters where all the bus networks are centrally operated for the SWIP for all of the 500+ sites. The only employee at each site is the bus operator, and he/she has no access to this network other than as a member of the public on the public wifi, and no access whatsoever to the administrative portions of the network that notifies the central location of the location of the bus, Fare input and location, as well as emergency notification and audio/video from the bus. Advertising data and bus destination sign updates are also planned. Is it acceptable for a group of sites that is managed centrally to use contact information for the central management site, even if because of the detached nature of the assignments, each assignment must be individually placed in SWIP? Albert Erdmann Network Administrator Paradise On Line Inc. From admin at wsfnet.org Wed Jul 26 18:56:36 2017 From: admin at wsfnet.org (Whitestone IT) Date: Wed, 26 Jul 2017 14:56:36 -0800 Subject: [arin-ppml] Policy Question for ARIN regarding SWIP In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> Message-ID: Albert wrote: On Wed, Jul 26, 2017 at 2:19 PM, wrote: > > > Said Major wireless provider tells me that ARIN requires a street address > for each site in SWIP, and this information must be the service address, > and that each site's address must be unique. > Not to muddy the water; this raises a curious point. I run (among other things) a small rural ISP which has customers using a /29 or more of IPv4 space. These customers live in an unorganized borough; technically, this means that the nearest city ? responsible for maintaining street address records ? has no legitimate way to register street addresses in a national database. Consequently, about 30% (rough estimate from me) of real addresses city-wide cannot be validated using the USPS database, and therefore third-party databases (which typically use the USPS db as a starting point) fail to contain them as well. For some entire /24 blocks, I have (ARIN-registered) street addresses that on the surface would look bogus to a brief online validation. While I can assure you they are not, this does raise a point that is not covered in the current NRPM ? what constitutes a valid service address? I find three examples of "street address" in the current NRPM, with no definition. And in cases where the SWIP is meant to discover POC, the street address would be pointless as a contact given that there is no postal service delivery to street addresses ? though no doubt helpful to law enforcement. Admittedly this is an edge case, but it does make me ask the question, "What are the actual definitions and requirements for a valid service address / street address?" I don't find the requirements (as clearly re-stated by Albert above) in the current NRPM. Jeremy Austin -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jul 26 21:04:54 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 18:04:54 -0700 Subject: [arin-ppml] Policy Question for ARIN regarding SWIP In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> Message-ID: > On Jul 26, 2017, at 15:19 , hostmaster at uneedus.com wrote: > > There has been some discussion regarding this question on the PPML, and since I received different answers regarding this and nothing official that I can find in the NRPM, I have decided to reach out to someone from ARIN for an answer. > > Currently NRPM 6.5.5.1 requires a static assignment of a /64 or more of IPv6 space to be registered in SWIP. When registered, can the contact address be that of a central site managing that site, or is the service address of the site itself, including the Zip Code required? > > The following is background information: > > I have need for a static assignment of IPv6 from a certain Major wireless provider, because said provider will no longer provide us static IPv4 addresses after our current contract ends. We currently have 500+ sites with one static IPv4 address each. We want to add at minimum a /60 of static IPv6 to each site, which according to the current NRPM requires SWIP. Each "Site" is a public transit bus, operated by a unit of State Government, and its location is not fixed. First, calling each bus a site makes some sense from an assignment perspective in that it is perfectly fine to treat each bus as an end-site under NRPM6 for purposes of being able to issue up to a /48 to each end site without further justification. > Said Major wireless provider tells me that ARIN requires a street address for each site in SWIP, and this information must be the service address, and that each site's address must be unique. It isn?t actually necessary to SWIP each bus as a separate end site. Probably the easiest thing to do (assuming your upstream wireless carrier will cooperate) is to get an ARIN direct assignment for the bus operator (whether company, state government agency, etc.) registered to the bus operator?s administrative offices, with the number of busses added to the number of office sites/etc. to be covered added together to get the total tally of sites. This would qualify the bus operator for n x /48 rounded up to a nibble boundary under the ARIN direct assignment policy and would enable you to put a /48 on every bus and in ever office. The aggregate would be all that is registered with ARIN. If the upstream won?t cooperate in this, then they have no greater SWIP requirement under ARIN policy and they are free to SWIP the customer with the larger aggregate block serving multiple end sites. This is covered in part in NRPM 6.3.4 Further, in 6.5.4 it is made clear that the policy for direct assignments shall also apply to LIR/ISP assignments to end users. 6.5.5.1 calls for the registration of each static assignment of a /64 or more. IMHO and in common practice, this includes any shorter prefix and there is nothing in the NRPM to prohibit issuing, e.g. a /36 to a company with 500+ end-sites as a single static assignment to that company. If ARIN had a problem with this, I would have run afoul of that issue many times in the past. It has not been an issue. So, there you have it? Officially in the NRPM, at least as I read it, a single large assignment can be registered at a single address even though it covers multiple end-sites. Of course, if the ISP won?t delegate you an aggregate and insists on delegating multiple discrete assignments, then you have a different problem. > I maintain that we should be able to use the contact address of the administrative headquarters where all the bus networks are centrally operated for the SWIP for all of the 500+ sites. The only employee at each site is the bus operator, and he/she has no access to this network other than as a member of the public on the public wifi, and no access whatsoever to the administrative portions of the network that notifies the central location of the location of the bus, Fare input and location, as well as emergency notification and audio/video from the bus. Advertising data and bus destination sign updates are also planned. I believe this to be true regardless of whether you are issued a single large assignment or multiple smaller ones. Hopefully ARIN staff will clarify this shortly. > Is it acceptable for a group of sites that is managed centrally to use contact information for the central management site, even if because of the detached nature of the assignments, each assignment must be individually placed in SWIP? I know of a number of large organizations that have received end-user direct assignments shorter than /48 from ARIN (IIRC, some even /40 or shorter) and do not SWIP their individual end-sites. Since the NRPM makes it clear that the requirements are intended to be equivalent, I see no requirement in the NRPM that places any greater burden on reassignments. Owen From owen at delong.com Wed Jul 26 21:07:38 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 26 Jul 2017 18:07:38 -0700 Subject: [arin-ppml] Policy Question for ARIN regarding SWIP In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> Message-ID: The examples are just that. IMHO, as a general rule, the address published in whois should be an address where legal process can be served regarding the network. I know that in some case, the address listed in whois is a P.O. Box. I doubt that anyone has implemented a SWIP-sized network inside a post office box. I suspect the USPS would frown on such a thing, actually. Owen > On Jul 26, 2017, at 15:56 , Whitestone IT wrote: > > > Albert wrote: > > On Wed, Jul 26, 2017 at 2:19 PM, > wrote: > > Said Major wireless provider tells me that ARIN requires a street address for each site in SWIP, and this information must be the service address, and that each site's address must be unique. > > Not to muddy the water; this raises a curious point. I run (among other things) a small rural ISP which has customers using a /29 or more of IPv4 space. > > These customers live in an unorganized borough; technically, this means that the nearest city ? responsible for maintaining street address records ? has no legitimate way to register street addresses in a national database. > > Consequently, about 30% (rough estimate from me) of real addresses city-wide cannot be validated using the USPS database, and therefore third-party databases (which typically use the USPS db as a starting point) fail to contain them as well. > > For some entire /24 blocks, I have (ARIN-registered) street addresses that on the surface would look bogus to a brief online validation. While I can assure you they are not, this does raise a point that is not covered in the current NRPM ? what constitutes a valid service address? I find three examples of "street address" in the current NRPM, with no definition. > > And in cases where the SWIP is meant to discover POC, the street address would be pointless as a contact given that there is no postal service delivery to street addresses ? though no doubt helpful to law enforcement. > > Admittedly this is an edge case, but it does make me ask the question, "What are the actual definitions and requirements for a valid service address / street address?" I don't find the requirements (as clearly re-stated by Albert above) in the current NRPM. > > Jeremy Austin > > _______________________________________________ > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Jul 27 01:58:11 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 27 Jul 2017 01:58:11 -0400 (EDT) Subject: [arin-ppml] Policy Question for ARIN regarding SWIP In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> <105B4879-494C-4A92-91C0-1E4815A2C6B7@delong.com> Message-ID: Of course, I can understand why a PO Box is used, if the place where the network is set up does not have a street address assigned, and their mail delivery is therefore required to be sent via a PO Box or otherwise. I work with a WISP in my area which covers some remote places. About 1/2 of these customers are among properties not having a street address. My own residence, served by this WISP does not have a street address, and because of this I get a fee exempt PO Box to receive mail in town. Until recently, even the WISP itself had no street address and was therefore using a PO Box in their ARIN allocation records. They got bigger and now moved their operation to an office that actually has a street address and updated their ARIN record. Thus, I suggest that whatever policy that ARIN follows, there must be some way under the policy to deal with the small number of cases where street addresses do not exist. As an example in the ARIN database of a record without a street address, look up 192.68.112.0/24. This is Berea College, which uses berea.edu. This school is in the middle of nowhere, but I am sure the local sheriff will know even without a street address where to take the process, and addressing a letter simply to Berea College, Berea KY 40404 will get there every time, since the Postmaster of Berea also knows. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 26 Jul 2017, Owen DeLong wrote: > The examples are just that. IMHO, as a general rule, the address published in whois should be an address where legal process can be served regarding the network. > > I know that in some case, the address listed in whois is a P.O. Box. I doubt that anyone has implemented a SWIP-sized network inside a post office box. I suspect the USPS would frown on such a thing, actually. > > Owen > >> On Jul 26, 2017, at 15:56 , Whitestone IT wrote: >> >> >> Albert wrote: >> >> On Wed, Jul 26, 2017 at 2:19 PM, > wrote: >> >> Said Major wireless provider tells me that ARIN requires a street address for each site in SWIP, and this information must be the service address, and that each site's address must be unique. >> >> Not to muddy the water; this raises a curious point. I run (among other things) a small rural ISP which has customers using a /29 or more of IPv4 space. >> >> These customers live in an unorganized borough; technically, this means that the nearest city ??? responsible for maintaining street address records ??? has no legitimate way to register street addresses in a national database. >> >> Consequently, about 30% (rough estimate from me) of real addresses city-wide cannot be validated using the USPS database, and therefore third-party databases (which typically use the USPS db as a starting point) fail to contain them as well. >> >> For some entire /24 blocks, I have (ARIN-registered) street addresses that on the surface would look bogus to a brief online validation. While I can assure you they are not, this does raise a point that is not covered in the current NRPM ??? what constitutes a valid service address? I find three examples of "street address" in the current NRPM, with no definition. >> >> And in cases where the SWIP is meant to discover POC, the street address would be pointless as a contact given that there is no postal service delivery to street addresses ??? though no doubt helpful to law enforcement. >> >> Admittedly this is an edge case, but it does make me ask the question, "What are the actual definitions and requirements for a valid service address / street address?" I don't find the requirements (as clearly re-stated by Albert above) in the current NRPM. >> >> Jeremy Austin >> >> _______________________________________________ >> 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. > > From info at arin.net Thu Jul 27 08:08:15 2017 From: info at arin.net (ARIN) Date: Thu, 27 Jul 2017 08:08:15 -0400 Subject: [arin-ppml] Board Adopts New Policies Message-ID: <5979D7AF.4050002@arin.net> On 22 June 2017, the Board of Trustees adopted the following Recommended Draft Policies: Recommended Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers Recommended Draft Policy ARIN-2016-9: Streamline Merger & Acquisition Transfers These adopted policies will be implemented no later than 22 September 2017, in accordance with their Staff and Legal Reviews, which rated the policies' resource impacts as minimal. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From jschiller at google.com Thu Jul 27 10:52:57 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 27 Jul 2017 10:52:57 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: > On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong wrote: > > On Jul 26, 2017, at 07:20 , Michael Peddemors wrote: > > > > But, in keeping with your 'flippant' style, we do have some ISP's that aren't responsible for the traffic that happens on their networks too ;) > Well? We have ISPs that fail to act responsibly about traffic that happens on their network. Saying they are not actually responsible is another > question which I don?t necessarily agree with. three points: 1. This proposal is not trying to address the problem of how ISPs handle abuse. If that is a problem the community wants to tackle, lets define the problem and propose policy in a DIFFERENT proposal 2. I do not believe the suggested changes impact how ISPs handle abuse. How ISPs handle abuse is orthogonal to this proposal. 3. How ISPs handle abuse is complicated and opaque and requires more nuance and clarity about what is actually required for compliance. As is said before compliance tends to be very good when it is either required, or beneficial to the organization. If an organization is trying in good faith, to follow ARIN rules, then they will try to keep SWIP information for their networks accurate, as well as for their down stream customers. There is no ARIN requirement that a provider need to process or respond to abuse complaints on their network space, nor that they take action on downstream customers who fail to process abuse complaints. In some cases their are particular legal rules in particular countries that some types of abuse complaints are required to be processed, for example legal take down requests. I suspect you will find very high compliance in processing these types of abuse complaints. In other cases there are unwritten standards of conduct that when violated results in a TOS agreement violation leading to loss of service. I suspect you will find a wide mix in terms of what is permitted under various TOS (although generally it is expected that the requirements are at least as strict for down stream customers) as well as a wide mix on level of compliance in processing TOS abuse complaints. In yet other cases, media agreements will contractually require DMCA violations to be processed. These are often completed by a pre-defined process and not through abuse@ email contact. These will also have a wide range of compliance directly proportional to the strength of the contract and importance of the media agreement. In yet other cases there is an unwritten standard of conduct that when violated results in being published on a black list. This also has a wide mix in terms of what is needed to be added and removed from the blacklist. Furthermore there is a wide mix of corresponding behavior by blacklisted organizations from aggressively cleaning up black listed space and maintain a positive reputation (and usable IP space for its customers), to organizations that do not engage black listers. Often times innocent customers are caught in the middle, and network abusers move on to new IP space often with newly stolen credentials, with very little that well meaning providers can do to prevent re-occurrence. On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong wrote: > > > On Jul 26, 2017, at 07:20 , Michael Peddemors > wrote: > > > > On 17-07-25 02:31 PM, Owen DeLong wrote: > >>> On Jul 25, 2017, at 10:34 , Michael Peddemors > wrote: > >>> > >>> On 17-07-24 05:06 PM, Tony Hain wrote: > >>>> I still don?t see any value in specifying length. What you are > looking for is contact info for someone with a clue about how a given > network works and using length as a really poor proxy. I could live with a > fourth line: > >>>> Any end network emitting SMTP system SHOULD provide SWIP. > >>>> I just don?t know how that gets enforced in any reasonable way. In > general SMTP & independent routing are the big targets needing accurate > contact info, and length has absolutely nothing to do with either. > >>>> Tony > >>> > >>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', > and that should be pointed out, as rwhois is more flexible in the IPv4 > space, eg providing allocation information to the /32 level. > >>> > >>> This again goes to an earlier email where I described that it should > be more conceptual, than specific ranges.. > >>> > >>> It should be, "if a party is responsible for the originating traffic", > then that party should be displayed via SWIP/rwhois. > >> Well? That?s hard to implement in practice. How do we go about SWIPing > all those home windows boxes to the hackers that are actually controlling > the emitted traffic? > >> Owen > > > > I assume you were being flippant/joking. The person who should be > contacted if the device is hacked in that case, would 'normally' be the > ISP, unless the person notified the ISP that they were taking > responsibility. (Same way as they now request a static IP address instead > of dynamic) > > Yes, Of course I was joking, but my point is that it really isn?t ?the > party responsible for originating the traffic? rather than ?the closest > knowledgeable party to the party responsible for the operation of the > machine originating the traffic. > > > But, in keeping with your 'flippant' style, we do have some ISP's that > aren't responsible for the traffic that happens on their networks too ;) > > Well? We have ISPs that fail to act responsibly about traffic that happens > on their network. Saying they are not actually responsible is another > question which I don?t necessarily agree with. > > Owen > > _______________________________________________ > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From oroberts at bell.ca Thu Jul 27 12:46:05 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Thu, 27 Jul 2017 16:46:05 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 In-Reply-To: References: <1e2526da-d43c-1f1f-74bf-ee46c4097352@cameron.net> <901394A1-E98C-481C-8337-52E2D840D4BD@panix.com> <20170717173405.GA9797@gweep.net> <338B6332-4894-43E9-B3AB-3EAD777F6C6C@delong.com> Message-ID: <718f4f226a3b443598e64322ca473eda@DG2MBX04-DOR.bell.corp.bce.ca> On the contrary, it questions the validity and purpose of a swip. Why is a SWIP necessary for IPv6? When is it necessary? And is necessity dependent on network/allocation size? All questions others have asked. For all direct allocations , there are several POC's and an Organisation Name & Address, I think validation should be compulosary by ARIN at this level. The ORG I work for has a min of 4, ADMIN, NOC, ABUSE, TECH per supernet (IPv4 /16 or IPv6 /32). Beyond this I share your view point ~ "The only thing I give a crap about whois for is that the contact is someone with authority over the IP in question" Now if "Authority" is defined as IANA>>ARIN>>Direct Allocation>>Realloaction# and the buck stops here. There won't be a need for Reassignment SWIPS on IPv6! For IPv4 , we can ignore purpose and move straight to the issue of End User service address v.s. End User Legal address/tech contact address vs Service Provider address. Right now the model is mixed. Most SWIPs are End User Service address but a few are the Service Provider Address or Legal Owner address (hence the bus analogy). I simple wanted clarity on what is general practice vs what is OBLIGATORY as per ARIN existing policy. Orin -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Seth Mattinen Sent: July-26-17 11:51 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 On 7/26/17 08:34, hostmaster at uneedus.com wrote: > Im sure glad that /32's of static IPv4 are not subject to SWIP, and > that SWIP does not require GPS info. > > If it did, we would be in trouble, as our GPS tracking only updates > every 300 seconds or 5 minutes, and we would need a T1 of bandwidth > just to keep the SWIP updated, and for what purpose? In all cases the > only place that will address abuse is our NOC. If anyone really cares about the GPS location of a given IP at any time, just dynamically update some DNS LOC records. This entire thread has gone beyond insane. I can't believe this list is actually discussing where a bus is located in whois. The only thing I give a crap about whois for is that the contact is someone with authority over the IP in question. ~Seth _______________________________________________ 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. From hostmaster at uneedus.com Thu Jul 27 13:10:26 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 27 Jul 2017 13:10:26 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: I agree that we need to act on THIS draft, and not load up the discussion with other issues that this draft is not intended to address. The one question regarding SWIP/WHOIS policy in general I have moved to another thread since it is unrelated to this draft. This draft is about changing the Assignment Registration rules to allow minimum static assigments of IPv6 space to be made most of the time without triggering a SWIP requirement. Current policy is effectively 100% registration, which is not true for the same customer using IPv4. After discussing changing the standard from /64 to /60 or /56, we appear to have agreed that the end user site minimum assignment should be /48, and that operators should not be assigning less. The last draft has language that I understood to have the effect of: * /47 or more MUST SWIP, as these sizes are larger than an end user. * Any size that is separately routed, which under most routing policies would be a /48 or larger, shall also SWIP. This also leaves the decision as to what level is routed to others, as this is not an ARIN decision. * Otherwise SWIP is not required for a /48, as this size is the basic end user or site assignment, similar to demanding /32 SWIP's in v4. There has also been some discussion that the current draft language does not reflect the above concepts, and suggesting changes. These are in scope. However problems with SWIP, WHOIS, abuse, etc are not in scope for this draft, and are not helpful in deciding what we need to have in this draft. If there are others that seek to fix these other issues, lets have them propose a different draft to do so, rather than trying to insert that here into this one. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 27 Jul 2017, Jason Schiller wrote: > > three points: > 1. This proposal is not trying to address the problem of how ISPs handle > abuse. > > If that is a problem the community wants to tackle, lets define the problem > and propose policy in a DIFFERENT proposal > > 2. I do not believe the suggested changes impact how ISPs handle abuse. > > How ISPs handle abuse is orthogonal to this proposal. > > 3. How ISPs handle abuse is complicated and opaque and requires more > nuance and clarity about what is actually required for compliance. > > > As is said before compliance tends to be very good when it is either > required, or beneficial to the organization. > > > If an organization is trying in good faith, to follow ARIN rules, then they > will try to keep SWIP information for their networks accurate, as well as > for their down stream customers. > > There is no ARIN requirement that a provider need to process or respond > to abuse complaints on their network space, nor that they take action on > downstream customers who fail to process abuse complaints. > > In some cases their are particular legal rules in particular countries that > some > types of abuse complaints are required to be processed, for example legal > take > down requests. I suspect you will find very high compliance in processing > these > types of abuse complaints. > > In other cases there are unwritten standards of conduct that when violated > results > in a TOS agreement violation leading to loss of service. I suspect you > will find a > wide mix in terms of what is permitted under various TOS (although > generally it is > expected that the requirements are at least as strict for down stream > customers) > as well as a wide mix on level of compliance in processing TOS abuse > complaints. > > In yet other cases, media agreements will contractually require DMCA > violations to > be processed. These are often completed by a pre-defined process and not > through > abuse@ email contact. These will also have a wide range of compliance > directly > proportional to the strength of the contract and importance of the media > agreement. > > In yet other cases there is an unwritten standard of conduct that when > violated results > in being published on a black list. This also has a wide mix in terms of > what is needed > to be added and removed from the blacklist. Furthermore there is a wide > mix of > corresponding behavior by blacklisted organizations from aggressively > cleaning up > black listed space and maintain a positive reputation (and usable IP space > for its > customers), to organizations that do not engage black listers. Often times > innocent > customers are caught in the middle, and network abusers move on to new IP > space > often with newly stolen credentials, with very little that well meaning > providers can do > to prevent re-occurrence. From rjletts at uw.edu Thu Jul 27 14:28:10 2017 From: rjletts at uw.edu (Richard J Letts) Date: Thu, 27 Jul 2017 18:28:10 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: I believe we should SWIP for /48. I believe we may SWIP for /56 or longer if the Service provider deems it useful. As an example we assign /48's to school districts, colleges, and universities in the State of Washington. I want each of them to have their own SWIP records so any issues with traffic originating from the site can get addressed by the local network administrators before they get escalated up to me as the WA-K20 NOC manager. We do not advertise separate routing for most of these /48 -- I do not want any linkage between SWIP and routing. Stating SWIP is not required for /48 leaves me open to them asking me not to SWIP (for some reason), and it is absolutely not the same as /32 SWIP in v4. Thank you Richard Letts Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, PWAVE, WRN > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of > hostmaster at uneedus.com > Sent: Thursday, July 27, 2017 10:10 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment > Registration requirements between IPv4 and IPv6 - updated 2017-07-21 > > I agree that we need to act on THIS draft, and not load up the discussion with > other issues that this draft is not intended to address. The one question > regarding SWIP/WHOIS policy in general I have moved to another thread > since it is unrelated to this draft. > > This draft is about changing the Assignment Registration rules to allow > minimum static assigments of IPv6 space to be made most of the time > without triggering a SWIP requirement. Current policy is effectively 100% > registration, which is not true for the same customer using IPv4. > > After discussing changing the standard from /64 to /60 or /56, we appear to > have agreed that the end user site minimum assignment should be /48, and > that operators should not be assigning less. > > The last draft has language that I understood to have the effect of: > > * /47 or more MUST SWIP, as these sizes are larger than an end user. > > * Any size that is separately routed, which under most routing policies would > be a /48 or larger, shall also SWIP. This also leaves the decision as to what > level is routed to others, as this is not an ARIN decision. > > * Otherwise SWIP is not required for a /48, as this size is the basic end user > or site assignment, similar to demanding /32 SWIP's in v4. > > There has also been some discussion that the current draft language does > not reflect the above concepts, and suggesting changes. These are in scope. > However problems with SWIP, WHOIS, abuse, etc are not in scope for this > draft, and are not helpful in deciding what we need to have in this draft. If > there are others that seek to fix these other issues, lets have them propose > a different draft to do so, rather than trying to insert that here into this one. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Thu, 27 Jul 2017, Jason Schiller wrote: > > > > three points: > > 1. This proposal is not trying to address the problem of how ISPs > > handle abuse. > > > > If that is a problem the community wants to tackle, lets define the > > problem and propose policy in a DIFFERENT proposal > > > > 2. I do not believe the suggested changes impact how ISPs handle abuse. > > > > How ISPs handle abuse is orthogonal to this proposal. > > > > 3. How ISPs handle abuse is complicated and opaque and requires more > > nuance and clarity about what is actually required for compliance. > > > > > > As is said before compliance tends to be very good when it is either > > required, or beneficial to the organization. > > > > > > If an organization is trying in good faith, to follow ARIN rules, then > > they will try to keep SWIP information for their networks accurate, as > > well as for their down stream customers. > > > > There is no ARIN requirement that a provider need to process or > > respond to abuse complaints on their network space, nor that they take > > action on downstream customers who fail to process abuse complaints. > > > > In some cases their are particular legal rules in particular countries > > that some types of abuse complaints are required to be processed, for > > example legal take down requests. I suspect you will find very high > > compliance in processing these types of abuse complaints. > > > > In other cases there are unwritten standards of conduct that when > > violated results in a TOS agreement violation leading to loss of > > service. I suspect you will find a wide mix in terms of what is > > permitted under various TOS (although generally it is expected that > > the requirements are at least as strict for down stream > > customers) > > as well as a wide mix on level of compliance in processing TOS abuse > > complaints. > > > > In yet other cases, media agreements will contractually require DMCA > > violations to be processed. These are often completed by a > > pre-defined process and not through > > abuse@ email contact. These will also have a wide range of compliance > > directly > > proportional to the strength of the contract and importance of the > > media agreement. > > > > In yet other cases there is an unwritten standard of conduct that when > > violated results in being published on a black list. This also has a > > wide mix in terms of what is needed to be added and removed from the > > blacklist. Furthermore there is a wide mix of corresponding behavior > > by blacklisted organizations from aggressively cleaning up black > > listed space and maintain a positive reputation (and usable IP space > > for its customers), to organizations that do not engage black listers. > > Often times innocent customers are caught in the middle, and network > > abusers move on to new IP space often with newly stolen credentials, > > with very little that well meaning providers can do to prevent > > re-occurrence. > _______________________________________________ > 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. From alh-ietf at tndh.net Thu Jul 27 16:43:24 2017 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 27 Jul 2017 13:43:24 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: <053301d30718$fe7ab320$fb701960$@tndh.net> Richard J Letts wrote: > I believe we should SWIP for /48. > I believe we may SWIP for /56 or longer if the Service provider deems it > useful. Effectively, length is irrelevant. SWIP to the responsible & responsive network operator. > > As an example we assign /48's to school districts, So you believe in forced-renumbering ... You SHOULD be assigning blocks to school districts sufficient that they can reassign a /48 to each school. > colleges, and universities in > the State of Washington. A college/university is a service provider to their student clients. They SHOULD be assigned blocks large enough to reassign a /48 to each of their customers, as any other service provider. > I want each of them to have their own SWIP > records so any issues with traffic originating from the site can get addressed > by the local network administrators before they get escalated up to me as > the WA-K20 NOC manager. I agree that this is the appropriate use of SWIP, but it has absolutely nothing to do with prefix length. > We do not advertise separate routing for most of these /48 -- I do not want > any linkage between SWIP and routing. While the unadvertised case is a local call, I assume you would want the ability to find contact info for a prefix that was independently routed in the global table.?.?. > Stating SWIP is not required for /48 leaves me open to them asking me not to > SWIP (for some reason), and it is absolutely not the same as /32 SWIP in v4. So establish a firm policy that for DMCA and any other jurisdictionally appropriate legal tracking; all assignments are published, period. Length has nothing to do with it. While I agree that it is often handy to have a 3rd party policy to resolve local political issues, in this case DMCA is useful, and avoids the need to have overly restrictive ARIN policy that impacts everyone else. Tony > > Thank you > > Richard Letts > Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, > PWAVE, WRN > > > -----Original Message----- > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of > > hostmaster at uneedus.com > > Sent: Thursday, July 27, 2017 10:10 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > > Assignment Registration requirements between IPv4 and IPv6 - updated > > 2017-07-21 > > > > I agree that we need to act on THIS draft, and not load up the > > discussion with other issues that this draft is not intended to > > address. The one question regarding SWIP/WHOIS policy in general I > > have moved to another thread since it is unrelated to this draft. > > > > This draft is about changing the Assignment Registration rules to > > allow minimum static assigments of IPv6 space to be made most of the > > time without triggering a SWIP requirement. Current policy is > > effectively 100% registration, which is not true for the same customer using > IPv4. > > > > After discussing changing the standard from /64 to /60 or /56, we > > appear to have agreed that the end user site minimum assignment should > > be /48, and that operators should not be assigning less. > > > > The last draft has language that I understood to have the effect of: > > > > * /47 or more MUST SWIP, as these sizes are larger than an end user. > > > > * Any size that is separately routed, which under most routing > > policies would be a /48 or larger, shall also SWIP. This also leaves > > the decision as to what level is routed to others, as this is not an ARIN > decision. > > > > * Otherwise SWIP is not required for a /48, as this size is the basic > > end user or site assignment, similar to demanding /32 SWIP's in v4. > > > > There has also been some discussion that the current draft language > > does not reflect the above concepts, and suggesting changes. These are in > scope. > > However problems with SWIP, WHOIS, abuse, etc are not in scope for > > this draft, and are not helpful in deciding what we need to have in > > this draft. If there are others that seek to fix these other issues, > > lets have them propose a different draft to do so, rather than trying to > insert that here into this one. > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > > > On Thu, 27 Jul 2017, Jason Schiller wrote: > > > > > > three points: > > > 1. This proposal is not trying to address the problem of how ISPs > > > handle abuse. > > > > > > If that is a problem the community wants to tackle, lets define the > > > problem and propose policy in a DIFFERENT proposal > > > > > > 2. I do not believe the suggested changes impact how ISPs handle abuse. > > > > > > How ISPs handle abuse is orthogonal to this proposal. > > > > > > 3. How ISPs handle abuse is complicated and opaque and requires more > > > nuance and clarity about what is actually required for compliance. > > > > > > > > > As is said before compliance tends to be very good when it is either > > > required, or beneficial to the organization. > > > > > > > > > If an organization is trying in good faith, to follow ARIN rules, > > > then they will try to keep SWIP information for their networks > > > accurate, as well as for their down stream customers. > > > > > > There is no ARIN requirement that a provider need to process or > > > respond to abuse complaints on their network space, nor that they > > > take action on downstream customers who fail to process abuse > complaints. > > > > > > In some cases their are particular legal rules in particular > > > countries that some types of abuse complaints are required to be > > > processed, for example legal take down requests. I suspect you will > > > find very high compliance in processing these types of abuse complaints. > > > > > > In other cases there are unwritten standards of conduct that when > > > violated results in a TOS agreement violation leading to loss of > > > service. I suspect you will find a wide mix in terms of what is > > > permitted under various TOS (although generally it is expected that > > > the requirements are at least as strict for down stream > > > customers) > > > as well as a wide mix on level of compliance in processing TOS abuse > > > complaints. > > > > > > In yet other cases, media agreements will contractually require DMCA > > > violations to be processed. These are often completed by a > > > pre-defined process and not through > > > abuse@ email contact. These will also have a wide range of compliance > > > directly > > > proportional to the strength of the contract and importance of the > > > media agreement. > > > > > > In yet other cases there is an unwritten standard of conduct that > > > when violated results in being published on a black list. This also > > > has a wide mix in terms of what is needed to be added and removed > > > from the blacklist. Furthermore there is a wide mix of > > > corresponding behavior by blacklisted organizations from > > > aggressively cleaning up black listed space and maintain a positive > > > reputation (and usable IP space for its customers), to organizations that > do not engage black listers. > > > Often times innocent customers are caught in the middle, and network > > > abusers move on to new IP space often with newly stolen credentials, > > > with very little that well meaning providers can do to prevent > > > re-occurrence. > > _______________________________________________ > > 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. From hostmaster at uneedus.com Thu Jul 27 19:21:22 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 27 Jul 2017 19:21:22 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: <053301d30718$fe7ab320$fb701960$@tndh.net> References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> <053301d30718$fe7ab320$fb701960$@tndh.net> Message-ID: > Richard J Letts wrote: >> As an example we assign /48's to school districts, If it is a really small school district, that is unlikely to expand beyond 16 sites, you could give them a /44, otherwise each district should get at least a /40 or more. A university might need more, or maybe a /40 for each college within it if each college within the university takes care of their own needs. This gives them room to give each of their schools or other sites a /48. Either way, the policy proposal would require SWIP for the main block assigned to that district, but no SWIP requirement for individual schools or other sites, all of which will be SWIP'ed to that specific district or college. The only reason you are complaining about the school districts getting away without SWIP under the proposal is that you are assigning them too small of a block. Each school, bus depot, admin headquarters, etc should be getting a /48. I assume that instead you expect the districts to assign smaller blocks to their sites, like a /56, instead of the recommended /48. Doing so follows the intent of the policy proposal to require larger allocations (/47 or larger) to be SWIP'ed, but /48's belonging to a single site without special routing not requiring SWIP. Doing this does everything you want, because each assigned district block will be SWIP'ed as a whole, making that district responsible. In the case of a University, 2 levels of SWIP might be needed, one for the University, and one under it for each College of that University, or other unit like a facilities group. >> I want each of them to have their own SWIP >> records so any issues with traffic originating from the site can get > addressed >> by the local network administrators before they get escalated up to me as >> the WA-K20 NOC manager. Give them the proper sized blocks, and your wish will be required by the policy proposal. A /47 or more in the policy means ALL your assignments to districts and colleges require SWIP, getting you out of the abuse loop. It also relieves you and the district/college from any burden of having to SWIP the individual sites of each district/college. Much better than the current policy where you would be responsible to SWIP all the way down to the site level, as the current standard is a /64 or more of static space. Albert Erdmann Network Administrator Paradise On Line Inc. From rjletts at uw.edu Thu Jul 27 19:56:39 2017 From: rjletts at uw.edu (Richard J Letts) Date: Thu, 27 Jul 2017 23:56:39 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> <053301d30718$fe7ab320$fb701960$@tndh.net> Message-ID: On this thread we've gone from near-real-time update of bus GPS co-ordinates to suggesting allocating over 64 subnets per student for most of our school districts was a bad idea and we should have allocated more(!) Some stats for SY2017 # districts: 317; # districts <=100 students: 46 ; # districts <=1000 students: 173 (including the 46) ; # districts >= 10,000: 33 (source: http://www.k12.wa.us/DataAdmin/enrollment.aspx) Initial allocations have been around for more than 7 years. In 7+ years no school district has come back and asked for more or a larger allocation than a /48. I'm going to point out the current policy supports how we're swiping address space and it's up to you to persuade me your change is worthwhile. Richard From hostmaster at uneedus.com Thu Jul 27 21:55:28 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 27 Jul 2017 21:55:28 -0400 (EDT) Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> <053301d30718$fe7ab320$fb701960$@tndh.net> Message-ID: The first draft of my proposal was very conservative. For v6 I proposed the two smallest possible subnet values be exempted from SWIP, which was /60 and /64. I figured that this would be enough for 16 subnets, enough for IOT and/or guest,wired, and wireless networks on different segments. Those in the know on this list suggested that I was setting my sights too low, and we quickly added values up to /56 to be exempted from SWIP and reached consensus on "more than a /56". The bus networks I speak of are just an example of many networks I know of in the real world where a single public IPv4 address is used, or a /32, which has never required SWIP, and the thinking that simply adding v6 should not change this. Because of SLAAC, the smallest v6 subnet used is /64. However, unlike v4, the current rule requires this smallest size network be SWIP'ed. Unlike your government network, in the real ISP world, 95-99 percent of the customers have only a single v4 address, and therefore most customers in the v4 world has never triggered the SWIP requirements. Adding the minimum /64 for v6 now triggers 100% SWIP and all the associated labor, and this is what I seek to address with this draft. I do not believe that these small size networks should trigger SWIP simply because they decided to do the right thing and add IPv6. Others spoke that getting rid of the conserving v4 mentality is what is needed, and that even ARIN policy considers the default end user site should be a /48. This is in fact what I have at my home, divided into 3 /64's, which seems very wasteful in v4 mentality which would suggest that I should not require more than a /60. Others here pointed out the benefits of all end sites being /48, which will allow automatic configuration in future devices, uniformity of all networks, and expansion into things using their own subnets that we may not even consider viable at this time. While my conserving nature tells me I should be happy with a /56 or /60, I have been convinced by others in the know that the benefits described are worth the extra address space, which will be grown into in the future. These same voices speak with the desire for uniformity of network size and that we should have a policy of /48 for each end site. This third round of the draft is where we are at. Quite a bit of consensus has been reached so far that the draft policy should not do anything to encourage operators to assign less than a /48 to each site. Since the numbers work for you and the assignments are already in place, maybe the majority opinion of not less than a /48 per site will not work for you, and nothing in the draft would require you to change this. In fact with my bus example, I have been actually considering assigning /60's out of a master /48 to reduce the amount of fees paid to ARIN, a site non-standard subnet size of /60. In defense of the current proposal, do remember the principle of "your network, your rules". If you require each district or university to be registered in SWIP in order to reduce your own abuse workload, go ahead and make SWIP a local requirement of receiving an assignment of your allocation. The draft assumes every end point is a /48 and therefore is an endpoint not requiring registration, a fact that is not true on your network. Based on your own statements, it sounds like you will be mostly SWIP'ing /48's for each district, and the districts will be assigning something smaller for its sites, such as a /56. I note that the draft proposal is just a minimum standard, and does not forbid an operator from requiring additional SWIP registration above these requirements in order to receive space from your allocation. If I were you, I would record a proper SWIP record of /48 for each district and call it a day, unless a district asks to subdelegate their space to more than one contact, in which case I would divide their assignment into however administrative abuse contacts they require and hope that number is a power of 2. This takes care of all of your identifed needs with your smaller than /48 end site assignments, but allows the default policy values for SWIP which are in your case too large for your network that is already in place. The draft is based on the recommendation of /48 per end user site, so that future networks are encouraged to follow the /48 per site rule. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 27 Jul 2017, Richard J Letts wrote: > > On this thread we've gone from near-real-time update of bus GPS co-ordinates to suggesting allocating over 64 subnets per student for most of our school districts was a bad idea and we should have allocated more(!) > > Some stats for SY2017 # districts: 317; # districts <=100 students: 46 ; # districts <=1000 students: 173 (including the 46) ; # districts >= 10,000: 33 (source: http://www.k12.wa.us/DataAdmin/enrollment.aspx) > Initial allocations have been around for more than 7 years. In 7+ years no school district has come back and asked for more or a larger allocation than a /48. > > I'm going to point out the current policy supports how we're swiping address space and it's up to you to persuade me your change is worthwhile. > > Richard > > > _______________________________________________ > 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. > From narten at us.ibm.com Fri Jul 28 00:53:23 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 28 Jul 2017 00:53:23 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201707280453.v6S4rNDo019660@rotala.raleigh.ibm.com> Total of 76 messages in the last 7 days. script run at: Fri Jul 28 00:53:18 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 23.68% | 18 | 25.36% | 414219 | owen at delong.com 13.16% | 10 | 15.77% | 257528 | pmcnary at cameron.net 17.11% | 13 | 10.54% | 172138 | hostmaster at uneedus.com 5.26% | 4 | 7.68% | 125420 | scottleibrand at gmail.com 5.26% | 4 | 7.26% | 118606 | 3johnl at gmail.com 5.26% | 4 | 6.14% | 100218 | farmer at umn.edu 3.95% | 3 | 5.20% | 85017 | alh-ietf at tndh.net 2.63% | 2 | 3.53% | 57608 | oroberts at bell.ca 2.63% | 2 | 3.04% | 49705 | jschiller at google.com 1.32% | 1 | 4.34% | 70892 | bjones at vt.edu 2.63% | 2 | 2.04% | 33380 | rjletts at uw.edu 2.63% | 2 | 1.20% | 19525 | bill at herrin.us 2.63% | 2 | 1.07% | 17524 | michael at linuxmagic.com 2.63% | 2 | 0.74% | 12059 | info at arin.net 1.32% | 1 | 1.81% | 29617 | lsawyer at gci.com 1.32% | 1 | 1.19% | 19445 | theone at uneedus.com 1.32% | 1 | 0.79% | 12847 | admin at wsfnet.org 1.32% | 1 | 0.67% | 10988 | hvgeekwtrvl at gmail.com 1.32% | 1 | 0.58% | 9552 | john at egh.com 1.32% | 1 | 0.57% | 9375 | narten at us.ibm.com 1.32% | 1 | 0.48% | 7877 | sethm at rollernet.us --------+------+--------+----------+------------------------ 100.00% | 76 |100.00% | 1633540 | Total From jschiller at google.com Fri Jul 28 11:49:49 2017 From: jschiller at google.com (Jason Schiller) Date: Fri, 28 Jul 2017 11:49:49 -0400 Subject: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6 - updated 2017-07-21 In-Reply-To: References: <028301d304b6$2f1c2910$8d547b30$@tndh.net> <02a601d304d9$d7373450$85a59cf0$@tndh.net> <6aeb49d5-e68d-1973-a30d-30572bbdb6f9@linuxmagic.com> <88420691-5ED7-4F35-9EE7-D215765658B5@delong.com> <36b6a189-a9df-e24d-d67d-19c5f75a9d09@linuxmagic.com> Message-ID: An ISP may always choose to SWIP or Rwhois. You can SWIP an IPv4 /32 if you like. This is not something which needs protecting... What needs to be protected is the inverse, when the ISP says we don't have to SWIP, so we aren't going to and you can't make us. For clarity, it may be useful to add language that is effectively a no-op. "ISPs and Registration-services members will not be prevented from registering a SWIP of any size from their address holdings." ___Jason On Thu, Jul 27, 2017 at 2:28 PM, Richard J Letts wrote: > > I believe we should SWIP for /48. > I believe we may SWIP for /56 or longer if the Service provider deems it > useful. > > As an example we assign /48's to school districts, colleges, and > universities in the State of Washington. I want each of them to have their > own SWIP records so any issues with traffic originating from the site can > get addressed by the local network administrators before they get escalated > up to me as the WA-K20 NOC manager. > We do not advertise separate routing for most of these /48 -- I do not > want any linkage between SWIP and routing. > Stating SWIP is not required for /48 leaves me open to them asking me not > to SWIP (for some reason), and it is absolutely not the same as /32 SWIP in > v4. > > Thank you > > Richard Letts > Manager: Network Operations Center: WA-K20, UW, UW Medicine, PNWGP, PWAVE, > WRN > > > -----Original Message----- > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of > > hostmaster at uneedus.com > > Sent: Thursday, July 27, 2017 10:10 AM > > To: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-5: Equalization of > Assignment > > Registration requirements between IPv4 and IPv6 - updated 2017-07-21 > > > > I agree that we need to act on THIS draft, and not load up the > discussion with > > other issues that this draft is not intended to address. The one > question > > regarding SWIP/WHOIS policy in general I have moved to another thread > > since it is unrelated to this draft. > > > > This draft is about changing the Assignment Registration rules to allow > > minimum static assigments of IPv6 space to be made most of the time > > without triggering a SWIP requirement. Current policy is effectively > 100% > > registration, which is not true for the same customer using IPv4. > > > > After discussing changing the standard from /64 to /60 or /56, we appear > to > > have agreed that the end user site minimum assignment should be /48, and > > that operators should not be assigning less. > > > > The last draft has language that I understood to have the effect of: > > > > * /47 or more MUST SWIP, as these sizes are larger than an end user. > > > > * Any size that is separately routed, which under most routing policies > would > > be a /48 or larger, shall also SWIP. This also leaves the decision as > to what > > level is routed to others, as this is not an ARIN decision. > > > > * Otherwise SWIP is not required for a /48, as this size is the basic > end user > > or site assignment, similar to demanding /32 SWIP's in v4. > > > > There has also been some discussion that the current draft language does > > not reflect the above concepts, and suggesting changes. These are in > scope. > > However problems with SWIP, WHOIS, abuse, etc are not in scope for this > > draft, and are not helpful in deciding what we need to have in this > draft. If > > there are others that seek to fix these other issues, lets have them > propose > > a different draft to do so, rather than trying to insert that here into > this one. > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > > > On Thu, 27 Jul 2017, Jason Schiller wrote: > > > > > > three points: > > > 1. This proposal is not trying to address the problem of how ISPs > > > handle abuse. > > > > > > If that is a problem the community wants to tackle, lets define the > > > problem and propose policy in a DIFFERENT proposal > > > > > > 2. I do not believe the suggested changes impact how ISPs handle abuse. > > > > > > How ISPs handle abuse is orthogonal to this proposal. > > > > > > 3. How ISPs handle abuse is complicated and opaque and requires more > > > nuance and clarity about what is actually required for compliance. > > > > > > > > > As is said before compliance tends to be very good when it is either > > > required, or beneficial to the organization. > > > > > > > > > If an organization is trying in good faith, to follow ARIN rules, then > > > they will try to keep SWIP information for their networks accurate, as > > > well as for their down stream customers. > > > > > > There is no ARIN requirement that a provider need to process or > > > respond to abuse complaints on their network space, nor that they take > > > action on downstream customers who fail to process abuse complaints. > > > > > > In some cases their are particular legal rules in particular countries > > > that some types of abuse complaints are required to be processed, for > > > example legal take down requests. I suspect you will find very high > > > compliance in processing these types of abuse complaints. > > > > > > In other cases there are unwritten standards of conduct that when > > > violated results in a TOS agreement violation leading to loss of > > > service. I suspect you will find a wide mix in terms of what is > > > permitted under various TOS (although generally it is expected that > > > the requirements are at least as strict for down stream > > > customers) > > > as well as a wide mix on level of compliance in processing TOS abuse > > > complaints. > > > > > > In yet other cases, media agreements will contractually require DMCA > > > violations to be processed. These are often completed by a > > > pre-defined process and not through > > > abuse@ email contact. These will also have a wide range of > compliance > > > directly > > > proportional to the strength of the contract and importance of the > > > media agreement. > > > > > > In yet other cases there is an unwritten standard of conduct that when > > > violated results in being published on a black list. This also has a > > > wide mix in terms of what is needed to be added and removed from the > > > blacklist. Furthermore there is a wide mix of corresponding behavior > > > by blacklisted organizations from aggressively cleaning up black > > > listed space and maintain a positive reputation (and usable IP space > > > for its customers), to organizations that do not engage black listers. > > > Often times innocent customers are caught in the middle, and network > > > abusers move on to new IP space often with newly stolen credentials, > > > with very little that well meaning providers can do to prevent > > > re-occurrence. > > _______________________________________________ > > 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. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: