Re: PI space under IPv6
Jeroen Massar <jeroen-LqLoW1FB7k/[email protected]> Thu, 18 Jan 2007 10:34:48 +0000
| Newsgroups | gmane.org.apnic.global-v6 |
|---|---|
| Organization | Unfix |
| Message-ID | <[email protected]> |
On 2007-01-17 17:42, Gert Doering wrote: > Hi, > > On Wed, Jan 17, 2007 at 05:38:14PM +0100, Brian E Carpenter wrote: >>> Calling it "PI" or calling it "we open the policy so everybody can get >>> their own independent address block" is technically pretty much the >>> same. >> Yes, technically it's called the swamp. > > No. The swamp is "everybody just gets address space, without clear > rules who and why". Why do RIR's then allocated multiple blocks to 1 single company!? (below a 'random' but rather good example') 2001:588::/32 2001:600::/32 2001:4218::/32 2001:4440::/32 2001:4441::/32 2001:4442::/32 2001:408::/32 2001:506::/48 2404:e0::/28 2600:800::/27 That is 1 company that got these blocks. Yes they are a pretty huge company (and most likely they might split at some point causing deaggregation anyway if they where allocated one block). But those 2001:444x::/32 is completely silly on APNIC's part. What use does it have to call that "PA" when the RIR already breaks it up ? Especially the ARIN "Micro-allocations for internal infrastructure" is funny in this context, why the *PEEP* does one need a single /48 when one has 3x /28 and 7x /32 available? These allocation procedures do match what I say about all of it: Give address space to organizations that need it. It does FAR from conserve routing table slots though, which indeed is not something the RIR's are involved with, but they should of course try a little IMHO. Greets, Jeroen _______________________________________________ global-v6 mailing list [email protected] http://mailman.apnic.net/mailman/listinfo/global-v6
signature.asc
(application/pgp-signature, 311 B)
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/ iHUEARECADUFAkWvTUguFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I084AKCIoMobyaEDo4V69J/aqgifop5I 0gCgodH+/kkQF5Gegr+iA1VyQPgHo6g= =t50v -----END PGP SIGNATURE-----