* Jérôme Nicolle

> Thank you for your honest statement. I feel likewise.
> 
> Le 31/10/2022 à 14:41, Tore Anderson a écrit :
> > 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.
> 
> It is neither wanted (would potentially conflicts with EU' GDPR in some 
> ways), nor technically feasible (would create way too much load on the 
> database as we'd all have to update it in realtime).

The policy in question allows the LIR to replace the End User's contact
information with its own, in case the End User is an individual. This
solves the GDPR issue, but it does not allow for aggregating a pool of
such assignments – unless they are *solely* used for the connection of
the End User to the service provider.

https://www.ripe.net/publications/docs/ripe-733#62

> > For IPv6 we use AGGREGATED-BY-LIR for these ranges, and would be nice
> > to be able to ("legally") do something similar for IPv4.
> 
> That's what LIR' "Provider Assignments" are for : you stick them up to 
> your BNG's and it never had to do with any individual customers.
> 
> I'm not sure we have an issue here, it has been best practice and well 
> adopted since I came around…
> 
> Some zeolots of course did declare each and every B2B customer as to 
> brag about it or offload their hotlines, but that's probably a 
> misinterpretation of current policies. As far as I know it never 
> happened on residential broadband yet.

Actually, declaring each and every customer assignment in that way is
probably the correct and de jure way to following the policy to the
letter – again, unless the assigned addresses in question are all
*solely* used for the connection to the service provider.

However, given a thousand random broadband customers, you're pretty
much certain to find at least one that uses the IPv4 address for
something additional, like running a server of some sort. The policy
*does* require separate assignments for those (regardless of them being
individuals or organisations).

Now, as you say, the best practice or de facto interpretation of policy
is to simply ignore that requirement because it's not really
technically feasible.

Yet, https://www.ripe.net/publications/docs/ripe-767#612 suggest that
least some LIRs are pedantically following policy to the letter, by
«overassigning» individual /32s.

I think, therefore, that it would be good to bring the policy text
itself in alignment with the de facto/best practice interpretation most
of us follow. 2022-02 in its current form is one way to do that, while
backporting IPv6's AGGREGATED-BY-LIR would be another.

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

Reply via email to