<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Hi Tom,<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 22 Sep 2017, at 14:28, Tom Hill <<a href="mailto:tom.hill@bytemark.co.uk" class="">tom.hill@bytemark.co.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On 22/09/17 14:16, Anna Wilson wrote:<br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">1. It will not serve to improve IPv6 deployment<br class=""></blockquote><br class="">My memory is that the original /8 policy was implemented, not to<br class="">encourage/discourage IPv6 adoption among existing IPv4 holders, but<br class="">because we recognised that new entrants joining the internet, even when<br class="">IPv6 capable throughout, still require at least a little bit of IPv4.<br class="">Best I can tell, that's still the case.<br class=""><br class="">So we're neutral on getting existing holders to shift, but I think this<br class="">proposal is highly positive on the number of new entrants who'll be able<br class="">to take this path.<br class=""></blockquote><br class="">The current 'last /8' policy is already doing what it was designed to<br class="">do, as far as I can determine (and has been mentioned already).<br class=""></div></div></blockquote><div><br class=""></div><div>Oh yes, it is, and without further intervention it will continue to do so for a finite amount of time, then it will stop. So the proposal is to extend that finite time.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">We're now beyond the time of making the 'last /8' policy, by many years,<br class="">and I believe that we should be concentrating on making improvements to<br class="">IPv6 - ensuring that it's an excellent future for all - instead of<br class="">slicing IPv4 thinner. Picking-up the long tail of stubborn/disinterested<br class="">organisations is going to be really fun.<br class=""></div></div></blockquote><div><br class=""></div><div>I agree but I don't understand why this is an either/or. This proposal doesn't stop that work.</div><div><br class=""></div><div>I'd gently suggest the counter:</div><div><br class=""></div><div>- that new entrants are most likely to support IPv6 (because very little IPv4 can be got);</div><div>- that even fully IPv6-ed new entrants need some IPv4 to make IPv6 work;</div><div>- reaching IPv4 runout while this is still the case will hurt those new entrants disproportionately;</div><div>- and so the worst effects fall on those who are likely to be the biggest supporters of IPv6 anyway.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><blockquote type="cite" class=""><blockquote type="cite" class="">2. It may go as far as to seriously impact the size of the DFZ<br class=""></blockquote><br class="">I don't want to dismiss the impact that RIR policies have on the DFZ<br class="">(it's why we started making them, after all) but the DFZ ultimately<br class="">operates on its own (very raw) consensus. Fragmented blocks do work<br class="">today, down to /24 - and we have no idea how full runout will change the<br class="">dynamics of already-routed blocks.<br class=""></blockquote><br class="">The concern was that once the minimum size is a /24, as proposed, there<br class="">will be a need to permit /25 or /26 announcements to permit certain<br class="">traffic engineering strategies. Not that /22s will continued to be<br class="">disaggregated. Disaggregation to /24 is bad enough as it is, IMO.<br class=""></div></div></blockquote></div><div class=""><br class=""></div><div class="">I take the point that the immediate pressure to deaggregate /24s could increase. And on the other side, Nick is pointing out what a small proportion of address space this proposal would affect; but nonetheless, they're both genuine points.</div><div class=""><br class=""></div><div class="">So the problem we face with the DFZ I think is not specifically "smallest prefix in the table" but "growth of number of entries over time." Entries over time keeps going up, and RIR policies have very successfully kept that growth contained.</div><div class=""><br class=""></div><div class="">Right now, the number of additional DFZ entries under the existing last /8 policy is between 1 and 4 times the number of applications approved under that policy. (1 if no deaggregation, 4 if deaggregated into 4x/24.)</div><div class=""><br class=""></div><div class="">Even in the scenario of deaggregation down to /26, this would remain the case under the new proposal: 1 entry if no deaggregation, 4 if deaggregated into 4x/26 (plus possible additional 4x deaggregation of the existing last /8 blocks.) And if this is done on foot of a RIPE policy, then it's possible to manage this deaggregation in a controlled manner based on the /8 boundary.</div><div class=""><br class=""></div><div class="">If you then fear that this deaggregation would spread to the rest of the DFZ: yes, I share this fear. In fact I think we can be very sure that this is coming, one way or another; Randy explained how based on history earlier in the thread.</div><div class=""><br class=""></div><div class="">But in a world of run-out, I don't know how to avoid it. What I do know is that for as long as RIPE allocates IPv4 space, we can make policies which provide the routing infrastructure with some boundaries to try to manage this deaggregation. Once we hit full runout, we lose that ability.</div><div class=""><br class=""></div><div class="">Best regards,</div><div class="">Anna</div><div class=""><br class=""></div><div class=""> <div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">-- <br class="">Anna Wilson<br class="">Service Desk Manager<br class="">HEAnet CLG, Ireland’s National Education and Research Network<br class="">1st Floor, 5 George’s Dock, IFSC, Dublin D01 X8N7, Ireland<br class="">+353 (0)1 6609040 <a href="mailto:anna.wilson@heanet.ie" class="">anna.wilson@heanet.ie</a> <a href="http://www.heanet.ie" class="">www.heanet.ie</a><br class="">Registered in Ireland, No. 275301. CRA No. 20036270</div> </div> <br class=""></div></body></html>