[arin-ppml] Draft Policy ARIN-2017-5: Equalization of Assignment Registration requirements between IPv4 and IPv6
hostmaster at uneedus.com
hostmaster at uneedus.com
Wed Jul 19 10:06:22 EDT 2017
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
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.
Paradise On Line Inc.
On Tue, 18 Jul 2017, Owen DeLong wrote:
>> On Jul 17, 2017, at 16:36 , John Curran <jcurran at arin.net> wrote:
>> Albert -
>> We’ll research into these questions and report back shortly.
>>> 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.
>>> 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 <daveid at panix.com> 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.
>>>> 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
>>> You are receiving this message because you are subscribed to
>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>>> Unsubscribe or manage your mailing list subscription at:
>>> Please contact info at arin.net if you experience any issues.
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
>> Unsubscribe or manage your mailing list subscription at:
>> Please contact info at arin.net if you experience any issues.
More information about the ARIN-PPML