<br><br><div class="gmail_quote">On Tue, Mar 30, 2010 at 14:50, David Farmer <span dir="ltr"><<a href="mailto:farmer@umn.edu">farmer@umn.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">David Farmer wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
William Herrin wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
On Fri, Mar 26, 2010 at 10:39 AM, David Farmer <<a href="mailto:farmer@umn.edu" target="_blank">farmer@umn.edu</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
A <a href="http://ula.nro.net" target="_blank">ula.nro.net</a> type mechanism is the way to coordinate the creation of the<br>
random prefixes. How about something like this.<br>
</blockquote>
<br>
David,<br>
<br>
Something is escaping me here. For *registered* ULA's what's the point<br>
of randomization? Wouldn't we better served with sparse? Or perhaps<br>
split the space and do half sparse and the other half linear when the<br>
requested net count is too large for the largest free space in the<br>
sparse area?<br>
</blockquote>
<br>
I'm not sure it is entirely necessary. But, there is an elegance to both kinds of ULA using an identical prefix selection algorithm. The only difference is if the Local/Central is being set or not. Which I believe was the original intent of how ULA was designed. This would also underscore the differences between ULA-C and PI addressing.<br>
<br>
Some people have said that ULA-C needed to have a random prefix selection algorithm too, I don't really care either way. But, if we allocate large blocks to the RIRs, why not let the RIRs manage the whole assignment process and just use their normal processes. I don't see any benefit to allocating large blocks and then requiring the RIRs to use a random prefix selection algorithm within those blocks. If your going to have a different prefix selection algorithm, between ULA-C and ULA-L, why make a third one, just use the RIRs normal one.<br>
</blockquote>
<br>
</div><div class="im"><a href="mailto:michael.dillon@bt.com" target="_blank">michael.dillon@bt.com</a> wrote:<br></div>
>David Farmer wrote:<br>
>> for assignment to organizations using process similar to<br>
>> those used for GUA today and using policies designated by the<br>
>> RIRs.<br>
><br>
> This risks people doing things like blocking ULA-C addresses<br>
> from other RIR regions but routing them openly in one region.<br>
> The current thinking has been to allocate them randomly so<br>
> that they cannot be aggregated either by network or by region.<br>
<br>
As I said I'm agnostic on this point, there are a number of people on the list who want large blocks assigned to each RIR, we need to pick one or the other. Who wants to compromise? But their is no point trying to move this forward if we can't find consensus on this point.</blockquote>
<div><br>Allocating them randomly (no regional blocks) will further discourage their use as cheap-GUA-equivalents at any point in the future as it causes the most pain to do so. Therefor, this is the best course of action if we want ULA-C.<br>
<br>This is of course slightly more complicated than handing out regional blocks since it requires a truly central registry (as opposed to the five distinct registries for GUA, ASNs and IPv4) but I think that can be overcome without too much difficulty. There are three possibilities:<br>
1) IANA takes on the duty directly<br>2) IANA delegates the duty to an existing RIR (or group of RIRs)<br>3) IANA/ICANN create a new ULA-C registry<br><br>In any case, the assignee interface should remain at the current RIR level, keeping the new duties to the bare minimum required to guarantee uniqueness (a prefix generator and a directory).<br>
<br>~Chris<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div class="h5"><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
===============================================<br>
David Farmer <a href="mailto:Email%3Afarmer@umn.edu" target="_blank">Email:farmer@umn.edu</a><br>
Networking & Telecommunication Services<br>
Office of Information Technology<br>
University of Minnesota <br>
2218 University Ave SE Phone: 612-626-0815<br>
Minneapolis, MN 55414-3029 Cell: 612-812-9952<br>
===============================================<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>@ChrisGrundemann<br><a href="http://weblog.chrisgrundemann.com">weblog.chrisgrundemann.com</a><br><a href="http://www.burningwiththebush.com">www.burningwiththebush.com</a><br>
<a href="http://www.coisoc.org">www.coisoc.org</a><br>