<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 30, 2013 at 3:33 PM, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hi again Jan, :-)</blockquote><div><br></div><div>Hi again, Elvis, and thanks for your responses.<br></div><div> <br>…<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The scope of the policy has not been changed. In the current policy assignments lower than a /64 are not permitted. Therefore, nothing is changed.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Section 1, 1.1 Overview has this current sentence that is removed in the<br>
proposal:<br>
<br>
"All bits to the left of /64 are in scope."<br>
<br>
In one of the previous posts, making things easier for e.g. using<br>
separate IP addresses for SSL is an argument for this proposal, but as I<br>
read it right now, I would have to sub-allocate a /64 for each SSL<br>
certificate, rather than say a /128.<br>
<br>
I feel reasonably sure that this is not the intention of the authors.<br>
</blockquote>
<br></div>
You are right, it was not our intention to remove that line from section 1.1. However, even with the old policy, my understanding was that you should have assigned a /64 for the SSL certificate and not a /128.<br></blockquote>
<div><br></div><div>Uhm, no, that would be – and sorry for the strong word use here – insane.<br><br></div><div>What you're essentially saying is that for any case where one would create a reverse pointer, there would have to be a /64.<br>
<br></div><div>This does not scale at all.<br><br></div><div>In terms of routing, it currently makes sense to ensure that address space smaller than a /64 is not announced globally via BGP.<br><br></div><div>But preventing actual _use_ of smaller address space is a very bad idea.<br>
<br></div><div>One of the HUGE gains of IPv6 is that you can easily encode more information in the IP address itself than you could with IPv4. There is an enormous amount of flexibility thanks to the 128-bit size of the address space.<br>
<br>Also, if the rightmost /64 cannot ever be used, then IPv6 should've been a 64-bit address space, and I don't think policing this here is relevant.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

<br>
I am not sure that removing that line makes any difference, let's see what the others think and we could add it back if it really changes the policy scope.<br></blockquote></div><br clear="all"></div><div class="gmail_extra">
>From a n00b's point of view, the old policy reads something like this, in brief:<br><br></div><div class="gmail_extra">"This policy does not apply to address space smaller than /64"<br><br>And the old policy reads:<br>
<br></div><div class="gmail_extra">"This policy applies to address space regardless of its size"<br><br></div><div class="gmail_extra">To me, this is the difference between letting me use e.g. 2a01:5b40::80:88:dead:beef:cafe as the IPv6 address for <a href="http://www.oyet.no">www.oyet.no</a>, and having to use e.g. 2a01:5b40:88:cafe::1/64.</div>
<div class="gmail_extra">-- <br>Jan
</div></div>