This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
- Previous message (by thread): [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
- Next message (by thread): [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore at fud.no
Tue Nov 1 11:25:32 CET 2022
* 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
- Previous message (by thread): [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
- Next message (by thread): [address-policy-wg] 2022-02 New Policy Proposal (Remove mandatory IPv4 PA assignment registration in the RIPE Database)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]