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] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Ondřej Caletka
Ondrej.Caletka at cesnet.cz
Mon Jan 9 14:46:00 CET 2017
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 at 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. 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: > The current RIPE Database business rules prevent the creation of more specific objects under an object with the status “ASSIGNED PI”, 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/011943.html -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3718 bytes Desc: Elektronicky podpis S/MIME URL: </ripe/mail/archives/address-policy-wg/attachments/20170109/7f8bce73/attachment.p7s>
- Previous message (by thread): [address-policy-wg] 2016-04 Review Phase: Draft Document and Impact Analysis Published (IPv6 PI Sub-assignment Clarification)
- Next message (by thread): [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]