<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Oct 1, 2013 at 11:11 AM, Elvis Velea <span dir="ltr"><<a href="mailto:elvis@velea.eu" target="_blank">elvis@velea.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Jan,<br></blockquote><div><br></div><div>Hello again, Elvis. :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not talking about how much you would use on your router or reverse dns.<br>
<br>
I'm talking about how much to 'reserve' as minimum for a point-to-point link or for a service.<div class="im"><br></div></blockquote><div><br>…<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<br></div>
It's not preventing use of a smaller prefix, it's preventing assigning/sub-allocating less than a /64 for anything.</blockquote><div><br>…<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Well, I used to work as an IPRA at the RIPE NCC and my understanding of the policy then (and now) was that assignments and/or sub-allocations of anything below a /64 is out of scope and even if one IPv6 address is used within a /64, the whole subnet is considered to be used.</blockquote>
<div><br></div><div>While this particular paragraph is fine, the others are less than, uhm, clear.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
To me, this is the difference between letting me use e.g.<br>
2a01:5b40::80:88:dead:beef:<u></u>cafe as the IPv6 address for <a href="http://www.oyet.no" target="_blank">www.oyet.no</a><br></div>
<<a href="http://www.oyet.no" target="_blank">http://www.oyet.no</a>>, and having to use e.g. 2a01:5b40:88:cafe::1/64.<br>
</blockquote>
<br>
I don't actually see it like that. You can still use the whole IPv6 address to number a device, it's just that you can not split a /64 for different services.<br>
<br>
For example, you can use a /64 to number, let's say, 100 devices that are in the same vlan doing the same thing and providing the same service but you can not number 100 different customers within a /64.<br></blockquote>
</div><br></div><div class="gmail_extra">… because of this.<br><br></div><div class="gmail_extra">This doesn't make sense.<br clear="all"></div><div class="gmail_extra"><br></div><div class="gmail_extra">Why can I not number 100 (or indeed, hundreds of thousands of) addresses for different websites within a /64?<br>
<br></div><div class="gmail_extra">I think, perhaps, that the words "customer", "service" etc. are poorly defined and lead to significant misunderstanding, and that I have not made myself clear.<br><br>
Whatever a hosting provider chooses to do with their IPv6 space to perform comparatively fine-grained routing and other network organization, should be pretty much irrelevant, as long as what's exposed to peers is sane.<br>
<br></div><div class="gmail_extra">The example I came with is not randomly chosen, I know there has been similar issues with the understanding of semantics in IPv4 policy, which according to some NCC members seemed to imply that it would be impossible to use a separate IPv4 address per SSL site without comparatively major bureaucracy, since (the argument went) these addresses should be assigned and registered.<br>
<br></div><div class="gmail_extra">Now you seem to be telling me that I cannot have a single webserver serving two different websites with two different IPv6 addresses, if they are both within the same /64.<br><br>If this is really the case, IPv6 is, within RIPE, a 64-bit address space, not a 128-bit address space, and depletion is guaranteed to become a problem with the proposed policy, as well as the current policy, considering that every hosting provider would need _many_ /32 allocations, as I understand the policy and the argument you make.<br>
<br></div><div class="gmail_extra">If, however, we consider IPv6 an 128-bit address space, and the rightmost /64 as simply not governed by RIPE policy, then a /48 is a _humongous_ address space, providing a LIR with 65k networks which may be redelegated to lower-level customers, such as e.g. web hosting providers, as long as these are routed as a /64 block.<br>
<br></div><div class="gmail_extra">-- <br>Jan
</div></div>