[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