Hi list & Ondřej, I Share this feeling. An end user to me is a user that permanently with or without a contract uses a certain (call it assigned or agreed) or logical block of addresses. The wifi will probably not give out permanent addresses that can be claimed back the next time, so I see no point in the sub allocation either. Rgds, Ray -----Original Message----- From: address-policy-wg [mailto:address-policy-wg-bounces@ripe.net] On Behalf Of Ondrej Caletka Sent: 9. tammikuuta 2017 15:46 To: address-policy-wg@ripe.net Subject: 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 <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...

Anno domini 2017 JORDI PALET MARTINEZ scripsit:

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: [...]

So, for shooting myself into my own foot (to steal your wording): I'm inclined to agree with you. After reading the IA I'm unsure wether the prefix length approach is leading to the best solution of this problem. I thought on this a while and basicly came up with similar ideas to yours but had a hard time putting it into words. So whatever journey this proposal will have from here on, at least we got into a discussion about an issue we at least can agree on exists. :)

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.

(SMEs are Small and medium-sized enterprises?) That would be something I'd be rather fine with. It solves the problems people faced in a more general way. I opens up some use cases and scenarios - which I tried to avoid to keep the scope of this discussion limited - but might be a nifty solution to clear these problems once and for all. This will however touch the PI/PA question as it opens up the usage of PI space for hosting providers and the like which I was trying to avoid, too.

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.

That would be bit to vague for my taste.

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 ????

That in particular was a subject I tried to avoid touching ;-) Best Max -- "First they ignore you, then they laugh at you, then they fight you, then you win." -- Mahatma Gandhi