[Task]: Don't restrict an entire /32 when automatically restricting an IP6 network

[diox]

Description

For extreme cases, we have a scanner action that can be triggered automatically that not only prevents auto-approval of the add-on but also restricts all the associated IP addresses, preventing them from submitting (Delay auto-approval indefinitely and add restrictions to future approvals).

Because IP restrictions are made for an entire network, we have the following code:

IPNetworkUserRestriction.objects.get_or_create(
    network=f'{ip}/32',
    restriction_type=restriction_type,
    defaults=restriction_defaults,
)

This is an ugly shortcut, but it works for IPv4 as /32 will be a network made of that single IP. For IPv6 though, it's doubly wrong:

• It defines a netmask but the relevant bits of the address are not 0 (causing Python to raise a has host bits set ValueError when the strict=False argument it omitted - we consider that as invalid when an admin is trying to submit such a restriction)
• a /32 is too wide

What netmask we should use is an interesting question - since this is an automated action, perhaps it should just be a /64.

Acceptance Criteria

  ### Milestones/checkpoints
  - [ ] IP restrictions added for IPv6 as part of a scanner action are valid network
  - [ ] IP restrictions added for IPv6 as part of a scanner action have a more appropriate "netmask" (/64)

Checks

• [X] If I have identified that the work is specific to a repository, I have removed "repository:addons-server" or "repository:addons-frontend"

┆Issue is synchronized with this Jira Task

[diox]

it should just be a /64 or /128 to be safe, but OTOH most providers will give their users a /56 or /48, so for a restriction to be effective, maybe it should be at least a /56.

Looking at other IP ban implementations out there the consensus seems to be /64 strikes the best balance between effectiveness and potential side effects. This is only for this particular scanner action anyway, and it can be changed by admins if necessary.

[ioanarusiczki]

• got restricted for add-on submissions automatically with an ipv6 ip address, could not continue making new submissions.
• with other ip in ipv6 format, submissions worked.
• repeated the steps for ipv4, same results.