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 <[email protected]> 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
[email protected]
https://bill.herrin.us/

_______________________________________________
ARIN-PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
https://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to