headers
Ricardo Patara | 2 Sep 2009 13:22
Favicon

Re: LACNIC IPv6 Stats Question in Stockholm

Hello Daniel,

This is the correct answer. Iljitsch was explained about it after the  
IEPG (not by me, but by others that had this clear also).

In lacnic region there are two NIRs. One in Brazil and one in Mexico.  
Lacnic, at this moment, allocates blocks of IP address to them for  
further allocation to organization inside these two countries.

So, that /16 is not allocated to a single organization, but it is a  
kind of pool for further allocatino.
And according the the NIR in Brazil, it is about 1% used

regards
Ricardo Patara
--
   Technical Area Manager
   LACNIC - Latin American and Caribbean Address Registry - http://lacnic.net

Em 02/09/2009, às 08:10, Daniel Karrenberg escreveu:

> Hello all,
>
> just a short not regarding a question from Ilijtsch in Stockholm:
>
> "Iljitsch van Beijnum asked whether we saw any significant changes  
> in the patterns
> of IPv6 allocations and assignments and specifically he questioned  
> the amount
> of IPv6 address space reported for LACNIC."
(Continue reading)

Permalink | Reply |
headers
Jeroen Massar | 2 Sep 2009 15:40
Favicon
Gravatar

Re: LACNIC IPv6 Stats Question in Stockholm

Ricardo Patara wrote:
> Hello Daniel,
> 
> This is the correct answer. Iljitsch was explained about it after the
> IEPG (not by me, but by others that had this clear also).
> 
> In lacnic region there are two NIRs. One in Brazil and one in Mexico.
> Lacnic, at this moment, allocates blocks of IP address to them for
> further allocation to organization inside these two countries.

The same goes for APNIC as for LACNIC (afaik no others have a NIR
concept): would it be possible to produce a separate stats file for
these prefixes?

For BRNIC I have:
 ftp://ftp.registro.br/pub/stats/delegated-ipv6-nicbr-latest

for JPNIC I also have:
ftp://ftp.apnic.net/apnic/whois-data/JPIRR/split/jpirr.db.route6.gz

But no stats for the latter. It would be good for the various people who
maintain statistics, filters etc, that this information was available in
the same format (stats files would be great already).

Greets,
 Jeroen
Permalink | Reply |
headers
George Michaelson | 3 Sep 2009 00:57
Favicon

Re: LACNIC IPv6 Stats Question in Stockholm

Jeroen, you may like to know that APNIC implements what is called a  
'direct allocation' process with the NIR, and that instead of large- 
block assignments to NIR, we pass over to them on a case-by-case basis  
the resources required.

This was not formerly the case, but all significant V6 deployments in  
recent times, and most IPv4 assignment/allocations except for the  
remaining fragments of their older block-assigns are in fact directly  
accounted for.

AS numbers are unfortunately still handed out in blocks. We're  
discussing how this can be amended in our operational processes

-george

PS this is not a formal APNIC message, I work in the R&D section.

On 02/09/2009, at 11:40 PM, Jeroen Massar wrote:

> Ricardo Patara wrote:
>> Hello Daniel,
>>
>> This is the correct answer. Iljitsch was explained about it after the
>> IEPG (not by me, but by others that had this clear also).
>>
>> In lacnic region there are two NIRs. One in Brazil and one in Mexico.
>> Lacnic, at this moment, allocates blocks of IP address to them for
>> further allocation to organization inside these two countries.
>
> The same goes for APNIC as for LACNIC (afaik no others have a NIR
(Continue reading)

Permalink | Reply |
headers
Jeroen Massar | 3 Sep 2009 11:03
Favicon
Gravatar

Re: LACNIC IPv6 Stats Question in Stockholm

George Michaelson wrote:
> Jeroen, you may like to know that APNIC implements what is called a
> 'direct allocation' process with the NIR, and that instead of
> large-block assignments to NIR, we pass over to them on a case-by-case
> basis the resources required.

Thanks, yes, I am aware of that, which makes it 'easier' than the
BRNIC/MXNIC(?) case where one gets in the RIR a /16.

In these cases, monitoring the stats file and doing a whois on new
blocks is sufficient to get the new updates (and notices that some
blocks get de-allocated). Only thing one misses then is whois updates,
but that is something that can be in some cases solves with the
mirroring of the database.

I am fairly sure that that the various projects that do statistics on
resource allocations would benefit from a single interface so that they
have correct data (then again, it happened already several times that
due to the human component in checking data, that slight errors where
found and then fixed by the RIR ;).

Greets,
 Jeroen
Permalink | Reply |
headers
Ricardo Patara | 3 Sep 2009 14:05
Favicon

Re: LACNIC IPv6 Stats Question in Stockholm

>> Jeroen, you may like to know that APNIC implements what is called a
>> 'direct allocation' process with the NIR, and that instead of
>> large-block assignments to NIR, we pass over to them on a case-by- 
>> case
>> basis the resources required.
>
> Thanks, yes, I am aware of that, which makes it 'easier' than the
> BRNIC/MXNIC(?) case where one gets in the RIR a /16.

Just to mention that we are working now on a project to avoid this  
kind of situation. Meaning that allocation to orgs in the NIRs area  
would be presented the same way allocations to other organization, and  
will also be available at the stats file. This is something for the  
next year calendar.

By now and regarding to IPv6 we have some statistics per country at:
http://portalipv6.lacnic.net/en/ipv6/statistics/country

And some other graphs/stats at:
http://lacnic.net/en/registro/estadisticas.html

> In these cases, monitoring the stats file and doing a whois on new
> blocks is sufficient to get the new updates (and notices that some
> blocks get de-allocated). Only thing one misses then is whois updates,
> but that is something that can be in some cases solves with the
> mirroring of the database.

in our case, we have what we call "jwhois" or joint whois. A query  
directed to our whois but regarding to a ip block allocated by one of  
the NIRs would be "proxied" to the NIR whois and a complete/detailed
(Continue reading)

Permalink | Reply |

Gmane