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

* Gert Doering
> On Mon, Sep 30, 2013 at 06:41:14PM +0200, Tore Anderson wrote:
>> Q: How would that work?
>> A: We could end up with two levels of RIPE NCC membership, e.g. "full"
>> like we have today, and "associate". Both would be fully-blown LIRs, but
>> to keep the operational overhead in NCC billing/finance low, the
>> membership fee for these "associate" members would be charged by the NCC
>> to the full members who are sponsoring them (just like with PI).
> 
> I'm not exactly sure what the difference between an "associate member" 
> and today's "consumer of resources provided by a sponsoring LIR" would
> then be, except for the title on the contract.   On the contrary, some
> enterprises just don't want to deal with the RIPE NCC if they can make
> a contract with their friendly neighbouring LIR instead...

The difference would be that an "associate member" (which is just an
idea, and outside the scope of APWG anyway) would be an LIR, and would
therefore be able to assign address space to its customer in turn.

PI holders currently cannot assign address space to their customers, and
that's what I understand this proposal to be all about changing, but it
does it in a way that defines a new "breed" of End User who a) does not
at all fit the original definition of an End User, while b) does
completely fit the definition of an Internet Registry. Put it another
way, the new (1st level) type of End User created by the proposal
appears to me to be an LIR in all but name.

So what I'm thinking is that it's better to call a spade a spade as far
as address policy go, and instead have the NCC/AGM/Board decide exactly
how they want to go about charging for the different flavours of spades.

But that's just my €0.02. Like I said earlier, this should not be
mistaken for opposition to the current proposal, just a suggestion.

> So I'm not sure it's worth abandoning the established concept of sponsoring 
> LIR right away (especially since doing away with it would affect IPv4 PI
> as well...).  It wouldn't make a difference anyway :-) - if we want to
> give people the option to take a /48 because it's big enough for them,
> we'd then still have "two standard sizes"...

Or we could simply tell the requesters to pick their favourite number
between 28 and 49... as long as policy says it's should be possible to
extend up to and including /29 it doesn't really matter what they start
out with as far as keeping delegations aggregated go (and routing is
another matter entirely).

> So, yes, another avenue could be "abandon /48 assignments/allocations",
> but *that* brings up another can of worms (what about an enterprise that
> has 5 locations that all have local ISP upstreams and want to do BGP
> multihoming?  5x /48 suits them well today, 1x /32 with someone blocking
> more-specifics from that because no site is announcing the /32 aggregate
> would not be that good).

But that's the route6 object, not the inet6num. If someone is filtering
on the inet6num without accepting more specifics they're already asking
for trouble (their users would surely complain about lack of
connectivity to the more-specifics inside 2a02:26f0::/32, for starters).

Tore