[address-policy-wg] 2013-06 New Policy Proposal (PA/PI Unification IPv6 Address Space)

Hi,

the discussion phase for this is coming to an end, and what I've heard
so far is mostly "great idea, way too complex approach to solving it".

Anyway, to answer some of these...

On Tue, Oct 29, 2013 at 03:33:18PM +0100, Tore Anderson wrote:
> > The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of
> > address space, "IPv6 addresses".  This is the goal.
> 
> A goal which I support. However, the proposal does go a bit further than
> just this. For example, it:

I think these are really unavoidable consequences if you

 - unify PA and PI
 - keep the "there is LIR" and "there is users of sponsored LIRs" model

> - unifies [PA] allocations and [PA] assignments
> - unifies the LIR and End User roles
> - allows an infinitely deep hierarchy of LIR+EU organisations
> - in doing so, significantly changes the structure of the Internet
> Registry System

This is basically a consequence of the policy we currently *have* - PA
space can be sub-allocated, even though this is slightly hidden in the
policy...

   http://www.ripe.net/ripe/docs/ripe-589#lir-to-isp

("status: ALLOCATED-BY-LIR").  While the database does not have a status:
value for "ALLLOCATED-BY-CUSTOMER-OF-LIR", there is nothing in the policy
text that wouldn't allow multiple layers of "subordinate ISPs" for PA
space - as long as "all /48 assignments" are properly documented...


So - if you unify PI and PA, and continue to permit sub-allocations, this
is where you end...  (and it seems to match "reality" somewhat better than
"there are LIRs and there are end-users, and no other categories in between").

> - dramatically increases the maximum undocumented delegation size from 1
> /29 per LIR to $NUMSITES * /29.

There's that, yes.  If we accept the prerequisites above, this is a certain
risk, which is why we tried countering this with "large blocks are somewhat
more expensive".

> [.. reasons why this proposal exists ..]

> Is this concern really specific to PI? I'd say this is more a
> problematic property of IPv6 *assignments* - regardless of them being PI
> or PA. Being a data centre operator and LIR, I believe I cannot
> currently make an IPv6 PA assignment to a customer of mine who wants to
> run a cloud service where their customers can rent virtual servers in
> turn. (A customer of theirs may in turn run some sort of web hotel for
> another set of customers on those VMs, and so on and so on.) 

You can :-) - ripe-589, 5.3.

Well, you wouldn't "assign" the addresses to your customers, but 
"sub-allocate", and he would then assign individual /56s or whatever
to the final end customers.  But the addressing hierarchy is possible.

[..]
> Of course, this wouldn't by itself yield PI/PA unification. However I
> think that too may be accomplished in a less intrusive way than 2013-06
> currently proposes: Delete section 7, and add a new section to the
> appendix or even just the supporting notes saying that it should be
> possible to obtain become an LIR and hold PA space without being a
> direct member of the RIPE NCC, and that this should cost about the same
> as holding PI does today, and that all pre-existing PI holders and their
> blocks/inet6nums should be automatically converted to this new arrangement.

Sounds easy, but I'm not sure this would actually solve all the questions
that arise, like

 - why should anyone become a RIPE member if they can have their address
   space for 50 EUR/year insteaad?
 - under which conditions can an entity get two "LIR blocks", then?
 - which size of address block would a "non RIPE member" LIR receive?

... so in the end, the answers would likely be similarily lengthy than
what was provided here.


But anyway, just trying to shine some light on why I think the complexity
is not exactly avoidable - but I get the message "this is too much too
digest, and the problem it is solving does not seem to be that big after
all".

Gert Doering
        -- ripe policy victim
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: </ripe/mail/archives/address-policy-wg/attachments/20131120/fcd587c5/attachment.sig>