sTLA alloc policies [Re: [6bone] pTLA request NDSOFTWARE - review closes 23 October 2002]

[Carlos Morgado]

On Sun, Oct 20, 2002 at 05:36:10PM +0300, Pekka Savola wrote:
> On Sun, 20 Oct 2002, Gert Doering wrote:
> > On Sun, Oct 20, 2002 at 02:19:19PM +0200, Jeroen Massar wrote:
> > > [ RIPE rules for IPv6 address space ]
> > > 
> > > That's what I meant to express. They do have political reasons though.
> > > And as most people know politics are not nice.
> > 
> > Partly political, but also partly technical - the multihoming issue
> > isn't really solved yet, and have every end site have their own /32
> > announced into the global table is not a scalable approach.
> > 
> > The political part is the "200 customer rule", which I personally did
> > not like very much (it came from ARIN and APNIC), but hey, for a serious
> > ISP that actually is connecting customers, it's not a major obstacle.
> 
> Speaking of which, I'd be really interested in knowing how Internet 
> Software Consortium is going to fill the "200 customer rule":
> 

CPR Marconi (PTComunicações now) routes about 80% of the portuguese commercial 
internet traffic. We have an IPv4 /19 and are pretty much multihomed in
IPv4 as any self respecting internet whole saler should be. However, after
reading RIPE's IPv6 policies I came to the conclusion we can't request a
block from them. "Get it from your upstream" is pretty much useless for 
multihomed nets so we're pretty much stuck.

All our customers however can get /32s from RIPE as they can fill a plan
saying "we have 250 PoPs". Soooo, our larger upstreams have IPv6 blocks,
our *client* ISPs have IPv6 blocks but we, *their upstream*, can't get a
block. 
Pretty much laughable eh ?

-- 
Carlos Morgado <chbm@cprm.net> - Internet Engineering - Phone +351 214146594
GPG key: 0x75E451E2 FP: B98B 222B F276 18C0 266B  599D 93A1 A3FB 75E4 51E2
The views expressed above do not bind my employer.