[lir-wg] Discussion about RIPE-261

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 at Space.Net
Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
80807 Muenchen              Fax : +49-89-32356-299