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] 2010-02 New Draft Document Published (Allocations from the last /8)
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tore Anderson
tore.anderson at redpill-linpro.com
Wed Jul 7 15:01:14 CEST 2010
>From the analysis: > This address space may not be a single aggregated /8 and can contain > prefixes as long as a /29 or more. Therefore it is possible that at > some point the RIPE NCC will be unable to allocate a single /22 > block to an LIR and will have to allocate multiple prefixes that > total 1,024 IP addresses. Because of this situation, there will > effectively no longer be a minimum allocation size within the RIPE > NCC service region when this happens. As I understand it, RIPE NCC is guaranteed to receive one last contiguous /8 from IANA (cf. http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm section 2.1). I think it would be prudent to reserve this particular /8 for the implementation of this policy, instead of specifying «a threshold of a total of one /8». That way the potential problem with fragmentation will only occur once the entire /8 has been allocated and the only thing that is remaining in the pool is returned allocations smaller than /22. >From the proposed policy: > a. LIRs may only receive one allocation from this /8. The size of the > allocation made under this policy will be no larger than a /22. This obviously conflicts with the current minimum allocation size (/21). Does the proposed policy intend to change the minimum allocation size to /22 so that all LIRs are eligible to receive a /22 (no more, no less), or to remove the minimum allocation size completely as suggested by the analysis - even when contiguous /22s are available in the unallocated pool? The language of the policy seems to imply the latter, as it says specifically «no larger» and «at most» (but makes no mention of «no smaller» and/or «at minimum»). I can easily see that being perceived as unfair, as one RIR might only be allocated a /23 at first and then be unable to come back later for another /23 (due to the one allocation only rule). So I'd favour it being a /22, no more, no less (until fragmentation makes that impossible). Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com/ Tel: +47 21 54 41 27
- Previous message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
- Next message (by thread): [address-policy-wg] 2010-02 New Draft Document Published (Allocations from the last /8)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]