Re: [ipv6-wg@ripe.net] New IPv6 Address Block Allocated to RIPE NCC

[Carlos Friacas <]

Hello,

/8, /9, /10, /11 or /12, but undoubtably something bigger than /23 is
needed *now*!

Please look at (these "unusual" assignments):
2001:1600::/31 [NL-LIBERTEL-20030902]
2001:1700::/27 [CH-SUNRISE-20031124]
2001:2000::/20 [EU-TELIANET-20040510]

Some guys really did their homework planning their future IPv6 networks
and came up with numbers that generated those assignments. When some more
people start doing the same task, and achieve the same conclusions, will
the RIRs get a new /23 block every week?

It really doesnt seem right that the RIRs have to be constantly asking for
more space -- and moreover unaggregated blocks, making everybody to mess
up with their filters frequently... :-(


Regards,
Carlos


On Mon, 14 Jun 2004, Tim Chown wrote:

> Giving /8's now seems quite practical.
>
> On Mon, Jun 14, 2004 at 03:19:37PM +0200, Gert Doering wrote:
> > Hi,
> >
> > On Mon, Jun 14, 2004 at 05:56:19AM -0700, william(at)elan.net wrote:
> > > Personally I don't see anything wrong with IANA reserving /8 for RIPE and
> > > specifying so on its page, but I really don't see why it should immedialy
> > > allocate that much space, as /8 would be what RIPE needs if half of its
> > > current membership requested ipv6 and somehow i dont think this is what
> > > is happening, you dont even have 10% of your membership doing it yet...
> >
> > The big advantage of using decent-size blocks is that the respective
> > RIRs can use more efficient distribution algorithms (binary-chop, for
> > example, see RIPE-261) inside their block.
> >
> > Also there is no *reason* for this, except "job security by introducing
> > needless bureaucracy".
> >
> > Conservation is not an issue (there are 64 /8s inside FP 001 - giving
> > each RIR a /8 will leave 59 /8s, with a high chance that the RIRs will
> > not ever come back asking for more), and "we need to make sure that
> > the RIRs know what they are doing" is also a non-issue, regarding the
> > given clue distribution at the ICANN / RIR level.
> >
> > Nobody has ever given a good reason for this insistence on /23 allocations,
> > except that, years ago, the IESG had recommended this (for the initial
> > ICANN -> RIR allocations).
> >
> > Gert Doering
> >         -- NetMaster
> > --
> > Total number of prefixes smaller than registry allocations:  60210  (58081)
> >
> > SpaceNet AG                 Mail: netmaster@localhost
> > Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
> > 80807 Muenchen              Fax : +49-89-32356-299