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/address-policy-wg@ripe.net/
[address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
- Previous message (by thread): [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
- Next message (by thread): [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Iljitsch van Beijnum
iljitsch at muada.com
Mon Nov 5 12:46:27 CET 2007
On 31 okt 2007, at 0:04, Geoff Huston wrote: >>> Leo has already proved that a (fairly simple) reclamation job >>> takes a lot of time and resource. This is for a /8 that no one >>> much wanted and no one much used. >> Was that the 14/8 thing? Only 129 individual addresses out of >> 16777216 where used. Maybe just reclaiming the other 16777087 would >> have been more efficient. >> But I'm pretty sure it's too late anyway, just like it's too late >> to make 240/4 usable. > 14/8 is useable - even with an extremely small number of legacy > allocations, the address block is useable. There is no OS stack that > says "bad address" for 14/8, which is the essential difference > between 14/8 and 240/4. What I meant by "too late" is that a big push to get a good part of the legacy class A blocks back is probably going to take so much time that we won't have the extra space by the time that we're going to need it. Obviously getting "easy" stuff such as 14/8 back is something we can still do.
- Previous message (by thread): [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
- Next message (by thread): [address-policy-wg] 2007-08 New Policy Proposal (Enabling Methods for Reallocation of IPv4 Resources)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]