On 2.1.2017 v 13:59 Marco Schmidt wrote:
We encourage you to review this proposal and send your comments to <address-policy-wg@ripe.net> before 31 January 2017.
Hi list, I would like to express my disagreement with the proposal. As I stated before [1], I think this proposal goes completely wrong way. After reading the impact analysis, I'm even more sure this is the case: To quote impact analysis:
Section 5.4.1 of the RIPE IPv6 policy mandates a /64 as the minimum assignment size per End Site within IPv6 allocations, while this policy change will make subnets smaller than a /64 per customer possible within IPv6 PI assignments.
The current RIPE Database business rules prevent the creation of more specific objects under an object with the status “ASSIGNED PI”,
As I understand it, the proposer certainly don't want to lower the minimum of /64 per *End Site*. He just want to be able to operate a public Wi-Fi network within *his own End Site*. Another quote of impact analysis: therefore these small subnets used by customers of the requesting organisation cannot be documented in the RIPE Database. This is starting to get ridiculous. Even if the database allowed creating sub-assignments under ASSIGNED PI, there is no technical way how to register every single device pulling address via SLAAC/DHCPv6 to the RIPE database, nor has been anything like that needed any time before. The RIPE Database is not a pan-European DHCP pool, is it? We really have to fix the RIPE NCC interpretations of "End Site" and "Assignment" so they don't consider a laptop connected to Wi-Fi network to be a separate End Site requiring it's own sub-assignment. This is the part that is broken and needs to be fixed, not the PI assignment rules. Best Regards, Ondřej Caletka CESNET [1]: https://www.ripe.net/ripe/mail/archives/address-policy-wg/2016-November/0119...