Fully agree. I’ve also expressed my concern about this being the wrong way.
I’ve also discussed in private with the author regarding several issues, including how wrong is having a text that mention something like /80. From RFC7136: For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long. If derived from an IEEE MAC-layer address, they must be constructed in Modified EUI-64 format. The impact analysis mention /64 as the minimum, but is not the minimum, is the ONLY valid value. There is only an exception to that: point-to-point links. Now, what happens if the assignment is not /64, but several /64 for each “machine”, as being suggested by new IETF work? For example, the servers and employee computers in a company that has received a /48 IPv6 PI, will be in this case. They may decide to allocate a single /64 for each VLAN (computers may be from the company or from employees, such as cellular phones, tablets, laptops), but maybe they prefer to allocate a /64 for each computer … and may be in the future several /64 for each computer, because they are running virtual machines in different VLANs. I suggested several options, for example trying to adjust the definition of “infrastructure”, “assign”, or even other choices such as: The PI assignment cannot be further assigned to other organisations. An exception to this will be managed services to third parties or point to point links, using the PI owner, own managed infrastructure; in that case, will not be subjected to registration, and it will not be considered as a sub-assignment, regardless size of the addressing space being used for those services (from a single address to multiple /64). An example of this will be a company offering managed networking services to SMEs to connect user-devices or even servers, such as: Users in public hot spots, employees or guest SSIDs or VPNs or VLANs or LAN segments in organizations, servers in a data centre. or Within the context of this policy, assignments not done to end-sites by means of point-to-point links are not considered sub-assignments. I know is not neither of those are perfect, and may not work, but it may be a starting point for some more discussion. And last idea (shooting to my own foot, as original author of the IPv6 PI policy proposal) … Do we really need anymore a different rule for IPv6 PA and IPv6 PI ???? Regards, Jordi -----Mensaje original----- De: address-policy-wg <[email protected]> en nombre de Ondřej Caletka <[email protected]> Responder a: <[email protected]> Fecha: lunes, 9 de enero de 2017, 14:46 Para: <[email protected]> Asunto: Re: [address-policy-wg] 2016-04 Review Phase (IPv6 PI Sub-assignment Clarification) On 2.1.2017 v 13:59 Marco Schmidt wrote: > > We encourage you to review this proposal and send your comments to <[email protected]> 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 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
