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]/
[ipv6-wg at ripe.net] New Document available: RIPE-343
- Previous message (by thread): [ipv6-wg at ripe.net] New Document available: RIPE-343
- Next message (by thread): [ipv6-wg at ripe.net] New Document available: RIPE-343
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Iljitsch van Beijnum
iljitsch at muada.com
Wed Feb 23 14:41:19 CET 2005
On 23-feb-05, at 14:14, Gert Doering wrote: >> 1) Which parts of the community rejected the doc in its previous >> incarnation and why? > It was mostly disliked because of the use of a global common address > pool, which means that you give up any chance to be able to > filter/aggregate > on region boundaries ("why do I need to know any details about ASes > located outside my region?") - whether or not someone is doing this > today > doesn't matter, but it was felt that it shouldn't be made impossible > right from the start. I'm sorry, but I have to object here. The notion that divvying up the globe into four or five parts in order to save on routing table expenditures in nonsense. Either filtering out "far away" information is a good idea, and then we should do it right, or it isn't, and then we don't need to do it at all. By doing it right I mean putting several layers of geographical hierarchy into addresses. In Europe, this would mean at least the country level, in large countries like the US, China and India the state/province level. >> 2) Why is IANA not a co-author - only the RIRs? > ICANN/IANA has been very passive and very resistive regarding any > attempts > to make the IANA->RIR allocations more reasonable. For many years now. They've been hesitant to change things in the absence of a new policy. Now that the IANA is more closely related to the ICANN they're probably getting an overdose of lawyer exposure... About the new document: this is unnecessarily complex, and it suffers from terrible end-game properties: when the space starts to run out (which isn't as unthinkable as it seems with the H/R thing, especially if we end up with several new RIRs and/or a middle layer of NIRs) the space will be fragmented very badly. Just give RIRs tightly stacked /12 allocations, or at most /10s. That's 2048 - 8192 times more than they were getting until recently. If this turns out unworkably small at less than 1000 IPv6 ASes then there is a bug in the system somewhere that we'd better fix before the other 17000 ASes start doing v6 too.
- Previous message (by thread): [ipv6-wg at ripe.net] New Document available: RIPE-343
- Next message (by thread): [ipv6-wg at ripe.net] New Document available: RIPE-343
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]