Hi, those of you that have been to Barcelona have heard the presentation by Paul Wilson from APNIC concerning the RIPE-261 document. In short, it's a proposal how to reorganize distributing IPv6 allocations "from the root" to the LIRs, fixing the way it's done now (ICANN allocating /23 fragments to the RIRs, and the RIRs having to fill them quite thoroughly, not leaving space for an ISP to grow past a /29). Technically, this is a matter between the RIRs and ICANN, but as this proposal affects routing and filtering as well, it would be useful to have consensus among the members that it's a good thing. So: please read the document (ftp://ftp.ripe.net/ripe/docs/ripe-261.txt) and comment on it. Note: this e-mail goes to ipv6-wg and lir-wg, but please don't followup to ipv6-wg - keep all of the discussion in the lir-wg mailing list. Speaking as "me personally" (this is not the official WG chair speaking here, just a concerned IPv6 user!), I have the following comments: - The /23 allocations ICANN -> RIRs are bad, because they lead to address space fragmentation, and the blocks are too small to do useful allocation towards the LIRs. Something NEEDS to be changed here. - Nevertheless, I do NOT like the idea of a "common address pool". People want to be able to see the "region" that a prefix is coming from by looking at the address. This is working fine now in v4 (except for the swamp and part of ERX) and in the so-far IPv6 allocations (except that due to the /23s it's getting messy), but would be broken by the CAP. - As a technical reason: people want to be able to filter IPv6 prefixes by region, like "I only have one uplink that provides me with US connectivity, so there's no need to carry any US prefixes in my routing table, I just point a summary down that line". This is not yet done, but I am convinced that we shouldn't break routing hierarchy without good need. - If people *really* go into "multiple /48s per site" multihoming, source address selection works by doing a longest-match check, and this will work better if same-region addresses have something like a common prefix, instead of "everythins smeared everywhere". So my personal recommendation would be: - change the /23 allocation boundary ICANN -> RIR to something more useful, like a /12 or so (a /12 means "512 of them are available, so we're not yet burning bridges - but a /8 would work as well. A /16 is already somewhat tight). - every RIR still gets its own allocation from where RIR->LIR allocations are taken - inside that RIR allocation, use the binary chop algorithm described in RIPE-261 for the RIR->LIR distribution. So - let the discussion start now! Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 54837 (54495) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299