* Gert Doering
> On Mon, Oct 31, 2022 at 01:49:46PM +0100, Tore Anderson wrote:
> > I never quite understood why we appear to be totally OK with not
> > requiring each individual IPv6 customer assignment to be registered in
> > the database, while we continue to require it for IPv4.
>
> For pool assignments (dynamic IP addresses handed out to dial-in
> customers), we as a LIR just registered them as ASSIGNED PA assigned
> to ourselves (and "back then" these assignments fell under the
> INFRA-AW clause).
>
> But for "static assignments", I think policy never permitted this.
Not sure about the history, but the current version of this "loophole"
is quite narrowly defined in the current policy (section 6.2):
«IP addresses used solely for the connection of an End User to a
service provider (e.g. point-to-point links) are considered part of the
service provider's infrastructure.»
While it does not differentiate between dynamic and static assignments,
do note the use of work «solely».
Playing devil's advocate, I would argue that the moment some broadband
subscriber decides to set up a port forwarding of 443/tcp to some web
server on the LAN where a cake recipe blog is hosted or whatever, the
LIR/ISP is then instantly obligated to create a individualised /32
assignment for that address.
Cloud providers such as myself are clearly not covered by the loophole.
Our customers can freely create and destroy VPSes with shorter
lifetimes that your average fruit fly, yet to follow policy we are
required to create and destroy the IPv4 /32 assignments in the same
rate. I'll admit it, we don't. While we don't expect to get in trouble
over this intentional policy violation, it does irk me quite a bit
because we do prefer to play by the rules.
For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
to be able to ("legally") do something similar for IPv4.
Tore
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/address-policy-wg
