[arin-ppml] Recommended Draft Policy ARIN-2019-10: Inter-RIR M&A

[hostmaster at uneedus.com]

We have some who has been hit hard with comment spam, mostly from RIPE and 
APNIC address blocks.  It used to be IPv4 only, but since making nearly 
everything dual stack we have discovered in the last year or so that these 
spammers have adopted IPv6 as well.

In the IPv4 world we know there is some blocking, but not nearly as much 
as it might seem, since more addresses have seemed to leave ARIN than ARIN 
has gained. These customers request we block all RIPE and APNIC /8s. If 
there is a problem with an identifed customer ip, we will whitelist.

The block table for IPv6 is of course a lot shorter, and thus far not as 
abused as much.  I am unaware of having to whitelist any IPv6 addresses.

As for satellite Internet, if it is an issue, we will address it in the 
whitelist process.  We host local message boards for many HOA's so we 
could even get to the point of only allowing the local wireline carrier 
and the local cable provider along with the big 4 mobile in each area if 
the comment spam gets bad, since that is where 99% of the valid traffic is 
coming from.

Of course, these kind of filtering rules would never be able to be used on 
any site with any worldwide traffic.

I look at IPv6 blocks similar to zip codes where by knowing the block, I 
will know what RIR it is assigned to. I think it should stay that way, and 
see no need to allow transfers.

As for those that want to allow it to simplify numbering, I do not think 
that it right to pass your costs to others. From the beginning days of 
IPv6, it was known you might have to renumber when you change ISP's, let 
alone RIR's.

If OS vendors or the IETF can come up with a better solution for using PA 
space for multihoming, there would be less need for PI space. The major 
problem in this regard is that a major NorthWestern US OS vendor that will 
not use more than one default route, nor drop the current default route in 
preference to another when a RA is received for that route with a lifetime 
of zero. Other OS's do much better in this regard, but no one is demanding 
the major OS vendor fix its IPv6 stack.  IPv6 was designed to allow more 
than one route and more than one address and subnet, but this OS vendor 
does not care.

Why cause more work for the RIR's and others tracking IPv6 RIR transfers 
just for the benefit of those very few people wanting to avoid 
renumbering.  Programing effort is not free, and I doubt the systems at 
ARIN and other RIR's are already set up to allow IPv6 blocks to be 
portable between RIR's.  In effect, those very few networks that would 
benefit from transfers are avoiding that cost by passing it on to everyone 
else in the form of fees to program their systems to allow it.

Albert Erdmann
Network Administrator
Paradise On Line Inc.



On Mon, 14 Oct 2019, William Herrin wrote:

> On Mon, Oct 14, 2019 at 11:24 AM <hostmaster at uneedus.com> wrote:
>       Right now, without a policy change I can look at that list and know
>       that 100% of each Block of IPv6 addresses is managed by the RIR listed.
>       That allows for clean filter lists in IPv6 for those that choose to filter
>       out abuse routes from other RIR's.  Allowing transfers will eliminate that
>       clean fixed line that currently exists.
> 
> 
> Hi Albert,
> 
> Would you explain your reasoning here? How do you get from the RIR delegation by IANA to blocking abuse sources?
> 
> If you filter all supernets delegated to APNIC, you will mangle some of your U.S. mainland traffic. Even if following rir boundaries was an administrative requirement
> placed on the registrant (it isn't) there are too many ambiguous cases. Who addresses the fiber ethernet link from Tokyo to San Francisco? What about the end users of
> global satellite Internet?
> 
> Regards,
> Bill Herrin
> 
> 
> --
> William Herrin
> bill at herrin.us
> https://bill.herrin.us/
> 
>