This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/ipv6-wg@ripe.net/
[ipv6-wg at ripe.net] Allocation behaviour (organisations getting multiple /32's)]
- Previous message (by thread): [ipv6-wg at ripe.net] Allocation behaviour (organisations getting multiple /32's)]
- Next message (by thread): [ipv6-wg at ripe.net] Allocation behaviour (organisations getting multiple /32's)]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jeroen Massar
jeroen at unfix.org
Mon Jul 11 16:22:49 CEST 2005
On Mon, 2005-07-11 at 18:07 +1000, John Tran wrote: > Hi Jeroen, > > It is great to know that you are paying attention to allocations that are being > made in other region. I would like to clarify the reason why APNIC made muliple > allocations to UUNET. Of course I have an interrest, routing changes happening in the Asian region affect the rest of the world. And what if I decided to move around the world? RIR areas don't split up the internet ;) > UUNET have multiple memberships with APNIC based on the networks in the region. This could have sound plausible, but they are all assigned to 1 person according to the registry information, in the US which is not even the APNIC region, not to different organisations/memberships/economys whatever name you would give it. To me this just seems like a nice way to get PI space, while being the same provider. But we will see soon enough from which ASN's they get originated. Does this btw mean that we will soon see the various /20's and larger blocks being cut up to "region blocks", or even /32's being cut up to regional blocks, because that is easier for announcement and so that one does not have to carry it's own traffic around the world? One of the reasons, afaik, to give huge chucks to LIR's was to make sure that the routing table would stay at a minimum, but when RIR's start giving out /32's per country an ISP is in, then that won't hold true, especially in the AS department. In the latter case the RIR's could better opt for giving out /48's per organisation directly and help out in the multihoming problem quite a bit. > As each economy, membership, managing their own address space therefore they > also requesting for IP address separately. For aggregation purpose APNIC > normally make allocations from contiguous block, as you can see from these > allocations. This is similar to making a large allocation to an organisation > then they further splitting between network for each economy. Except that these are bound to be announced separately. Getting a block from ARIN, one from RIPE and one from APNIC seems plausible to me, but getting a block for every country one is in defeats the whole aggregation idea. Greets, Jeroen > > -------- Original Message -------- > > Subject: [ipv6-wg at ripe.net] Allocation behaviour (organisations getting > > multiple /32's) > > Date: Sat, 09 Jul 2005 12:52:33 +0200 > > From: Jeroen Massar <jeroen at unfix.org> > > Organization: Unfix > > To: ipv6-wg at ripe.net > > > > I just noticed that UUNET/MCI got an additional 3 /32's: > > > > inet6num: 2001:4441::/32 > > netname: UUNET-AU-NETBLOCK-20050708 > > descr: UUNET Australia Limited > > descr: UUNET Network > > country: AU > > > > inet6num: 2001:4440::/32 > > netname: UUNET-HK-NETBLOCK-20050708 > > descr: UUNET Worldcom Hong Kong Ltd > > descr: UUNET Network > > country: HK > > > > inet6num: 2001:4442::/32 > > netname: UUNET-JP-NETBLOCK-20050708 > > descr: UUNET Japan, Ltd > > descr: UUNET Network > > country: JP > > > > They where all assigned to 1 person, who apparently works for UUNET/MCI > > in the US, not even the APNIC region, not even a role. > > > > Did somebody say goodbye to aggregation? > > > > Btw UUNET also has: > > 2001:600::/32 (Europe) > > > > Apparently nothing in the US, in total 4x /32. 4 slots gone away. > > Are all global companies going to request separate /32's ? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 240 bytes Desc: This is a digitally signed message part URL: </ripe/mail/archives/ipv6-wg/attachments/20050711/3e159842/attachment.sig>
- Previous message (by thread): [ipv6-wg at ripe.net] Allocation behaviour (organisations getting multiple /32's)]
- Next message (by thread): [ipv6-wg at ripe.net] Allocation behaviour (organisations getting multiple /32's)]
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]