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

Dear Address Policy WG,

On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:
> A proposed change to RIPE Documents ripe-589, "IPv6 Address 
> Allocation and Assignment Policy", ripe-451, "IPv6 Address 
> Space Policy For Internet Exchange Points" and ripe-233, 
> "IPv6 Addresses for Internet Root Servers In The RIPE Region" 
> is now available for discussion.
[..]
> We encourage you to review this proposal and send your comments to
> <address-policy-wg at ripe.net> before 25 October 2013.

The discussion phase for this proposal is now over, but after the
feedback received at the RIPE meeting in Athens (and here on the list,
even if in the wrong thread :) ) the chairs have deviced to take a step
back, and re-state the fundamental "do we want to go there?" question
(and extend the discussion phase by +4 weeks).

The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of
address space, "IPv6 addresses".  This is the goal.

The idea to go there came from various people in the community, mostly
for one reason - having two differently "coloured" addresses that do 
the same thing, routingwise, but follow different policies and have
different strings attached, creates quite some confusion for the folks 
out there that can no longer be nicely separated into "ISPs" (->become 
RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming
and/or upstream independence is required).  

Most notably, "garage style hosting providers" seem to have issues 
with the requirement of the IPv6 PI policy that PI space MUST NOT be 
sub-assigned, which the NCC interprets most strictly (because the vast
amount of "grey" between "ok" and "not ok" is hard to codify into 
hostmaster guidelines).  OTOH, I have not heard that complaint from
actual hosting providers for a while, so maybe the issue is not that 
big anymore.


*If* we go to "there is only one type of addresses" anymore, we have two
options

 - abandon IPv6 PI (as in "not so expensive, but independent space") 
   completely, problem solved  -> I do not think we can reasonably do that

 - find a way to solve the needs for both RIPE members and non-members,
   with maximum flexibility, with only one type of addresses, taking
   "real world" address distribution chains (LIR->network operator->
   hosting provider->customer->hosted virtual machines, for example) 
   and "real world" financial constraints into account.

2013-06 aims to achieve the latter, while proposing / finding specific 
solutions for all the small details that come up if such a radical change
is implemented.


I think the presentation at RIPE67 was a bit too fast for the WG - it 
could have spent a bit more time on the background and "do we want to 
go there" before overwhelming you with questions about details to be 
solved.  For that, I apologize - I did review the presentation beforehand
with the proposers, and assumed "yes, this should work out nicely"...


Anyway.  I think what we need to hear now from the community (*you*) is
where we want to go:

 - do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine

 - keep the distinction, work on the IPv6 PI policy (if the pain is 
   large enough that someone actually volunteers to come with a proposal)

 - go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail
   problems that need to be addressed if we go there.


Going for one of the first options would mean abandoning 2013-06 - but
if that's what the community wants, it's much better to do it *now* than
to invest more time in text, impact analysis, a few rounds of review
phase, and *then* give up the project.

Gert Doering
        -- APWG chair
-- 
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/20131025/726785b6/attachment.sig>