Hi Max, Thanks for the (quick) inputs! To be honest, I was not sure that you also need that for your own case (or if you know other cases that need that). I really think if you are a hosting/housing provider for third companies, you should become an LIR, but as said, this is only my personal view. Let's see what others believe. By the way, it will be interesting to compare this with IPv4. Do we allow this case in IPv4? Or we need also a policy proposal to amend that? Regards, Jordi -----Mensaje original----- De: address-policy-wg <address-policy-wg-bounces@ripe.net> en nombre de Maximilian Wilhelm <max@rfc2324.org> Fecha: martes, 17 de abril de 2018, 17:14 Para: <address-policy-wg@ripe.net> Asunto: Re: [address-policy-wg] 2018-02 New Policy Proposal (Assignment Clarification in IPv6 Policy) Anno domini 2018 JORDI PALET MARTINEZ via address-policy-wg scripsit: Hi, > As you probably remember, during the discussion of the recently implemented 2016-04, I complained that we should not approve a policy proposal with a wording that creates (in my opinion), discrepancies between the NCC impact analysis and the policy text. > > I was suggested that it can always be improved ... so that's what I'm doing here. > > I've also suggested the same text in the other 4 RIRs with equivalent policy proposal, because all them have the same problem. > > The main point is to clarify the actual interpretation to make clear that it is allowed from up to a single /64, to use non-permanently, any number of addresses (not just a single one). > > So basically, what I'm saying is: > 1) Is not a sub-assignment a point-to-point (maximum a /64) even if this is permanent. However, the point-to-point can't be used as permanent addressing for "actual" transit (so you can't use the point-to-point addressing and then makeup an IPv6 NAT/NPT, or something similar for devices behind it). > 2) Is not a sub-assignment up to a /64 if non-permanent. Example a device in a hot-spot, with use multiple addresses (example, VMs) from a single /64, or the same situation if an employee brings any kind of device to the enterprise WiFi or wired network. > > This means that I'm excluding the case of a data center allocating *permanent* /64 to server interfaces (non-permanent will be ok). Remember that this is for PI, and my personal opinion on this is that, a datacenter, should be an LIR, so using PA. > > This is an open question here, and I may be wrong. > > So, what do you think on the overall proposal and specially in this last point (data center can be PI and then we should have a more complex text that allows that case)? I like the overall thing, but I don't like the DC part (as you might have guessed :)). My approach deliberately included housing/hosting as you can read in the rationale and this is something I would like to keep included for small hosters. I think the argument of scale applies here. Having only a /48 for your DC including your own infrastructure and some customer stuff won't get you far (if you don't ignore RFCs and BCPs). So for me this would be fine. If you grow, become an LIR, get a /29, be happy, everyone is happy. Best Max -- The real problem with C++ for kernel modules is: the language just sucks. -- Linus Torvalds ********************************************** 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 exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.