[sig-policy]Re: FW: [ipv6-wg@ripe.net] Discussion about RIPE-261 (fwd)
Thanks for this. In addition, for those interested, there is
an excellent webcast archive of the discussion at the RIPE
meeting at:
http://www.ripe.net/ripe/meetings/ripe-45/webcast-archive.html
in lir-2
This proposal was also made at the last APNIC meeting. There
was general consensus to continue the discussion on the mailing
list.
Some issues had been raised with the proposal (the same as
those cited below) in that if this proposal went ahead it would make
regional filtering difficult.
It would be useful to know if others on this mailing list
think this is an issue.
If so, where do we go from here with this proposal? What
are peoples thoughts on Gert's suggestions below?
Your feedback is appreciated.
kind regards,
Anne
APNIC Secretariat
--
> Dear SIG members,
>
> There is an excellent article about IPv6 address space management.
> [http://www.ripe.net/ripe/docs/ipv6-sparse.html]
>
> The following email is a good summary for the document discussion.
> Please read the document and feel free to comment on it.
>
> Best Regards
>
>
> Kenny Huang
> Co-Chair, Address Policy SIG
> huangk at alum dot sinica dot edu
>
> >
> > ---------- Forwarded message ----------
> > Date: Fri, 23 May 2003 14:01:14 +0200
> > From: Gert Doering <gert@Space.Net>
> > Reply-To: lir-wg at ripe dot net
> > To: lir-wg at ripe dot net, ipv6-wg at ripe dot net
> > Subject: [ipv6-wg at ripe dot net] 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
>
>