<div dir="ltr">On Fri, Oct 25, 2013 at 8:03 PM, Gert Doering <span dir="ltr"><<a href="mailto:gert@space.net" target="_blank">gert@space.net</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear Address Policy WG,<br>
<div class="im"><br>
On Thu, Sep 26, 2013 at 04:36:24PM +0200, Marco Schmidt wrote:<br>
</div><div class="im">> A proposed change to RIPE Documents ripe-589, "IPv6 Address<br>
> Allocation and Assignment Policy", ripe-451, "IPv6 Address<br>
> Space Policy For Internet Exchange Points" and ripe-233,<br>
> "IPv6 Addresses for Internet Root Servers In The RIPE Region"<br>
> is now available for discussion.<br>
</div>[..]<br>
<div class="im">> We encourage you to review this proposal and send your comments to<br>
> <<a href="mailto:address-policy-wg@ripe.net">address-policy-wg@ripe.net</a>> before 25 October 2013.<br>
<br>
</div>The discussion phase for this proposal is now over, but after the<br>
feedback received at the RIPE meeting in Athens (and here on the list,<br>
even if in the wrong thread :) ) the chairs have deviced to take a step<br>
back, and re-state the fundamental "do we want to go there?" question<br>
(and extend the discussion phase by +4 weeks).<br>
<br>
The proposal aims to unify IPv6 PA and IPv6 PI space into one kind of<br>
address space, "IPv6 addresses". �This is the goal.<br>
<br>
The idea to go there came from various people in the community, mostly<br>
for one reason - having two differently "coloured" addresses that do<br>
the same thing, routingwise, but follow different policies and have<br>
different strings attached, creates quite some confusion for the folks<br>
out there that can no longer be nicely separated into "ISPs" (->become<br>
RIPE members, use PA) and "end-users" (->use PI, if BGP-based multihoming<br>
and/or upstream independence is required).<br></blockquote><div><br></div><div>In my opinion, this distinction is not particularly useful in itself, and could very well be a floating definition.</div><div><br></div><div>
Coming from the DNS registrar side, I cannot help thinking that looking at the registry/registrar model might be beneficial for making things clearer for people out there.</div><div><br></div><div>One way of seeing this, is that the LIRs are "registrars" for IP address space, and that their role could simply be about registering and brokering assignments and allocations for the RIR.</div>
<div><br></div><div>An ISP or an "end user" then becomes an unnecessary distinction, as they would both have to go to a LIR to get their address space, and it's just a matter of placing a request for the correct size, at the discretion of the applicant and the LIR.</div>
<div><br></div><div>Mind you, I think this is mostly about perspective, but if we could use the similarities with DNS registrations, then end customers (ISPs or whatever) might have less confusion.</div><div><br></div><div>
I could very well be wrong.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Most notably, "garage style hosting providers" seem to have issues<br>
with the requirement of the IPv6 PI policy that PI space MUST NOT be<br>
sub-assigned, which the NCC interprets most strictly (because the vast<br>
amount of "grey" between "ok" and "not ok" is hard to codify into<br>
hostmaster guidelines). �OTOH, I have not heard that complaint from<br>
actual hosting providers for a while, so maybe the issue is not that<br>
big anymore.<br></blockquote><div><br></div><div>From what I've seen � and this is anecdata � this is "solved" by subletting the address space without leaving other traces of it than a PTR record, if that.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
*If* we go to "there is only one type of addresses" anymore, we have two<br>
options<br>
<br>
�- abandon IPv6 PI (as in "not so expensive, but independent space")<br>
� �completely, problem solved �-> I do not think we can reasonably do that<br>
<br>
�- find a way to solve the needs for both RIPE members and non-members,<br>
� �with maximum flexibility, with only one type of addresses, taking<br>
� �"real world" address distribution chains (LIR->network operator-><br>
� �hosting provider->customer->hosted virtual machines, for example)<br>
� �and "real world" financial constraints into account.</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2013-06 aims to achieve the latter, while proposing / finding specific<br>
solutions for all the small details that come up if such a radical change<br>
is implemented.<br></blockquote><div><br></div><div>I think the latter is how it should be done, and I think it would be easier to explain.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
<br>
I think the presentation at RIPE67 was a bit too fast for the WG - it<br>
could have spent a bit more time on the background and "do we want to<br>
go there" before overwhelming you with questions about details to be<br>
solved. �For that, I apologize - I did review the presentation beforehand<br>
with the proposers, and assumed "yes, this should work out nicely"...<br>
<br>
<br>
Anyway. �I think what we need to hear now from the community (*you*) is<br>
where we want to go:<br>
<br>
�- do nothing, our policy for IPv6 PA and IPv6 PI "as of today" is fine<br>
<br>
�- keep the distinction, work on the IPv6 PI policy (if the pain is<br>
� �large enough that someone actually volunteers to come with a proposal)<br>
<br>
�- go the big step, unify IPv6 PA and IPv6 PI, and solve all the detail<br>
� �problems that need to be addressed if we go there.<br>
<br>
<br>
Going for one of the first options would mean abandoning 2013-06 - but<br>
if that's what the community wants, it's much better to do it *now* than<br>
to invest more time in text, impact analysis, a few rounds of review<br>
phase, and *then* give up the project.<br></blockquote><div><br></div><div>I think going the big step is where we need to go. But it's a nice extra workload.</div><div><br></div><div>Keeping the current policy is less work, and I don't think it will hurt much of anything.</div>
<div><br></div><div>But right now, I think the ideal should be the third option, especially considering that this will seem to be much harder to change at a later point in time.</div><div>�</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im HOEnZb"><br>
Gert Doering<br>
� � � � -- APWG chair<br>
</div><div class="HOEnZb"><div class="h5">--<br>
have you enabled IPv6 on something today...?</div><div class="h5"><br></div></div></blockquote></div><br>(Yes!)<br clear="all"><div><br></div>-- <br>Jan
</div></div>