This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
- Previous message (by thread): [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Pekka Savola
pekkas at netcore.fi
Thu Apr 20 18:15:15 CEST 2006
On Thu, 20 Apr 2006, Michael.Dillon at btradianz.com wrote: >> I don't think that follows, but unless ARIN legal counsel or someone >> who is a real lawyer has made a statement here, I'm not sure how >> seriously to take this. Pointer to such official legal counsel would >> be appreciated. >... > If you are interested in understanding this then start here > http://nys-stlc.syr.edu/lawlibrary/antitrust/antitrustbasics.aspx This includes important gold nuggets such as ".. whether the practice complained of _unreasonably_ restrains competition", "The true test of legality is whether the restraint imposed is such as _merely regulates_ and perhaps thereby promotes competition ..." .. which imply that reasonable restraints may be OK (and many could count e.g., continued well-being of the common Internet routing system a reasonable thing), or that such acts may not necessarily be restrictive, but rather leveling the competion. But all of this is irrelevant, as I'm not interested in your or my arm-chair lawyering. I'm interested in reference to what ARIN legal counsel has said on this. > Because you are crossposting this thread to a global V6 list > and to a RIPE mailing list, it seems to me that you feel there > should be a single unitary global policy. No, the discussion has been recently brought up at least on those lists, and it would seem unwise to repeat it on every list. Even if each region made its own policies, it might be much easier for everyone (IMHO) if the discussion was held on a common list, and then when the time comes, folks would each go to their own individual RIR to make their informed or uninformed decisions. >> I wouldn't object to reserving a /44 just in case, but make no >> provisions (at this point) for applying more. If someone needs more >> than /48, it needs to justify another one, and get a separate /48 >> (with its own reserved /44). > > I think you misunderstand ARIN's allocation algorithm here. The purpose > of a reserved block is to allow an applicant to receive an increased > allocation from the reserved block in order to be able to aggregate > the new and old allocations. If the recipient of a /48 allocation > applies for more and receieves the rest of their reserved /44 then > they can announce a single /44 prefix instead of two /48 prefixes (or > more). > This minimizes the impact on the global routing table. The ARIN IPv4 > allocation algorithm works the same way. I understand the policy very well. If the above only were the case. The possible outcomes are (in an example case of expansion to /47): - the site advertises a 2001:db8:0::/47 - the site advertises a 2001:db8:0::/48 and 2001:db8:1::/48 - the site advertises a 2001:db8:0::/47 and one of /48's - the site advertises a 2001:db8:0::/47 and both of /48's Based on observations in v4 land, there are sites that specifically want to do something other than the first option, and I specifically want to preclude them from doing so. For almost every site, a /48 is enough. For those for whom it's not enough, they already want separable advertisements for TE purposes (e.g., multiple data centers), so they need either multiple /48's or tricks like above in any case. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
- Previous message (by thread): [address-policy-wg] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
- Next message (by thread): [address-policy-wg] Re: [GLOBAL-V6] Re: [ppml] Just say *NO* to PI space -- or how to make it less destructive
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]