Mailing List Archive

Jimmy Sadri wrote:

Hi Jimmy,

> Does anyone have any good links to ipv6 bogon lists so far I've found
> this one http://www.space.net/~gert/RIPE/ipv6-filters.html but it
> seems a little outdated. Actually, if you people wouldn't mind I'd
> like to see what people are actually using on their routers? post
> your bogon filter if you want. If you could give a little
> explaination as to why you block things and weather you consider it
> to be a strict or more loose.

I'm currently using the following filters

! documentation prefix, RFC3849
ipv6 prefix-list strict deny 2001:DB8::/32 le 128
! ARIN Microallocations
ipv6 prefix-list strict permit 2001:500::/30 ge 48 le 48
! ARIN IXP
ipv6 prefix-list strict permit 2001:504::/30 ge 48 le 48
! RIPE IXP
ipv6 prefix-list strict permit 2001:7F8::/32 ge 48 le 48
! APNIC IXP
ipv6 prefix-list strict permit 2001:7FA::/32 ge 48 le 48
! Allow 6to4 anycast prefix
ipv6 prefix-list strict permit 2002::/16
ipv6 prefix-list strict deny 2002::/16 le 128
! rest of unicast
ipv6 prefix-list strict permit 2000::/3 ge 17 le 35
ipv6 prefix-list strict deny ::/0 le 128

As some people may know I still don't think supporting IPv6 multihoming
with random /48-/40 more-specifics chunked from larger PA allocations is
wise, so my filters strictly block them. The only exception is for the
known blocks where /48s are issued (IXP and ARIN microallocations). IXP
space may be filtered, that is up to you.

The rest of 2000::/3 is opened up to the current in-the-wild maximum
allocation prefix len of /35. In published filters you could often see
something like

permit 2001::/32 ge 17 le 35
permit 2003::/32 ge 17 le 35

since now 2600:: and 2a00:: are (about to be) allocated and a bogus
prefix somewhere in the middle of free space (3123:abcd::/32) does not
do more or less harm than something in the allowed holes of RIR space
(2001:db9::/32) this does not make sense in my opinion.

WARNING: These filters are certainly _not_ fire and forget. If there is
the probability that the system might run on autopilot at some day (as
happened with many of the prior 6bone-participants) you should open the
filters for anything up to /48, there might be /48s allocations from
other blocks ("IPv6 PI") at a later time.

Other than that, to my observation more-specific paths are often longer
and useless (leaked iBGP, clueless operator, filtered on a couple of
transits), so if you can keep your filters up to date if something in
the allocation rules changes, you should filter them IMHO.

Bernhard

P.S.: Please don't send HTML mails to mailinglists.

On Mon, May 23, 2005 at 04:30:24PM -0700, Jimmy Sadri wrote:
> Hi all,
>
> Does anyone have any good links to ipv6 bogon lists
> so far I've found this one
> http://www.space.net/~gert/RIPE/ipv6-filters.html
> but it seems a little outdated. Actually, if you people wouldn't mind
> I'd like
> to see what people are actually using on their routers... post your
> bogon filter
> if you want. If you could give a little explaination as to why you
> block things and
> weather you consider it to be a strict or more loose.
>
> Thanks
>
> ============================================
> Jimmy Sadri
> Network Engineer
> Infinity Internet
> Email: jsadri@infinityinternet.com
> Phone: 360-816-9153 = 800-689-4303 ext. 39153
> Fax: 360-254-3898
> www.iinet.com
>

Hi Jimmy,

This is what we use:

cr1.ord1.us> sh ipv prefix ipv6-ebgp-relaxed
ipv6 prefix-list ipv6-ebgp-strict: 8 entries
seq 5 deny 2001:db8::/32 le 128
seq 10 permit 2002::/16
seq 15 deny 2002::/16 le 128
seq 20 deny ::/8 le 128
seq 25 deny fe00::/9 le 128
seq 30 deny ff00::/8 le 128
seq 35 permit ::/0 le 48
seq 40 deny ::/0 le 128

We used to filter aggressively using strict filters in the past however
just recently we decided to stop doing that and switched to relaxed bogon
filtering for two reasons:

1. With increasing routers with peering sessions on the network, it is
starting to become more cumbersome to update these all the time. The
strict filters are always _never_ "install and forget", "one time setup"
filtering, you always have to maintain it each time there is a new
allocation.

2. Some of our enterprise-oriented downstreams had difficulties in
acquiring a /48 PI block. While it is true that ARIN is pretty nice in
approving /32 PI blocks, it was unreasonable to request /32 size when
the network is not big enough to make such a justification. We believe
it is better to allow legitimate multihoming by these entities than
maintain strict bogon filtering which require continuing maintenance.


-J

--
James Jun
Infrastructure and Technology Services
TowardEX Technologies
Office +1-617-459-4051 x179 | Mobile +1-978-394-2867
james@towardex.com | www.towardex.com

Bernhard Schmidt wrote:
> The rest of 2000::/3 is opened up to the current in-the-wild maximum
> allocation prefix len of /35. In published filters you could often see
> something like
>
> permit 2001::/32 ge 17 le 35
> permit 2003::/32 ge 17 le 35

I believe that all /35's are/were within 2001::/21.

- Kevin

Kevin Loch wrote:

Hi,

>> The rest of 2000::/3 is opened up to the current in-the-wild maximum
>> allocation prefix len of /35. In published filters you could often see
>> something like
>>
>> permit 2001::/32 ge 17 le 35
>> permit 2003::/32 ge 17 le 35
>
>
> I believe that all /35's are/were within 2001::/21.

True, that was just a quick example. In fact, according to
http://www.sixxs.net/tools/grh/tla/all/ there are only a few /35 left
(currently announced)

Not updated allocation:
2001:228::/35 [jp] Japan JENS-JP-19991027
2001:338::/35 [jp] Japan U-NETSURF-JPNIC-JP-20011005
2001:4c0::/35 [mx] Mexico PROTEL-RED-1-V6
2001:4c8::/35 [mx] Mexico UNINET-NETV6-1
2001:6c0::/35 [se] Sweden SE-TELIANET-20010102

Updated but only announcing the /35:
2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
2001:438::/32 [us] United States ABOVENET-IPV6
2001:4d8::/32 [us] United States DOTNET-001

You will not see those if you filter /35. I don't know whether you would
miss them.

Updated and announcing both /32 and /35:
2001:258::/32 [jp] Japan INFOWEB-JPNIC-JP-2000502
2001:2c0::/32 [jp] Japan INFOSPHERE-JPNIC-JP-20010208
2001:340::/32 [jp] Japan FINE-JPNIC-JP-20011030
2001:3d0::/32 [jp] Japan PTOP-JPNIC-JP-20020521
2001:400::/32 [us] United States ESNET-V6
2001:420::/32 [us] United States CISCO-IPV6-1
2001:450::/32 [us] United States GBLX-V6
2001:490::/32 [us] United States NOKIA-1
2001:4b0::/32 [us] United States AOLTIMEWARNER

those a probably afraid of the famous BGP ghosting or just haven't got
around to kill the announcements.

Disclaimer: I did not check whether the reports in GRH are correct, but
it looks like that.

Bernhard

Bernhard Schmidt wrote:
> Updated but only announcing the /35:
> 2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
> 2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
> 2001:438::/32 [us] United States ABOVENET-IPV6
> 2001:4d8::/32 [us] United States DOTNET-001

and Qwest 2001:428::/32 (which for some reason doesn't show up in the
sixxs.net tla visibility charts.

A few weeks ago I sent a friendly reminder to the four networks in the
ARIN reigon that were announcing only a /35. One of them updated
their announcement but the other three apparently don't care.

- Kevin

Some networks in Poland which are /32 are divided into a few /33 or /35
and announced under different AS numbers. (there are only a few sTLa so
far like this, but a few more will follow, for example 2001:b10::/33)
This is because we have to implement different routing policy (under
different AS numbers) and RIPE policy don't allow us to get additional /32

So, for us, it would be better to not be filtered (between /32-/35)
:-)

Regards,
Bart


Bernhard Schmidt wrote:

>Kevin Loch wrote:
>
>Hi,
>
>
>
>>>The rest of 2000::/3 is opened up to the current in-the-wild maximum
>>>allocation prefix len of /35. In published filters you could often see
>>>something like
>>>
>>>permit 2001::/32 ge 17 le 35
>>>permit 2003::/32 ge 17 le 35
>>>
>>>
>>I believe that all /35's are/were within 2001::/21.
>>
>>
>
>True, that was just a quick example. In fact, according to
>http://www.sixxs.net/tools/grh/tla/all/ there are only a few /35 left
>(currently announced)
>
>Not updated allocation:
>2001:228::/35 [jp] Japan JENS-JP-19991027
>2001:338::/35 [jp] Japan U-NETSURF-JPNIC-JP-20011005
>2001:4c0::/35 [mx] Mexico PROTEL-RED-1-V6
>2001:4c8::/35 [mx] Mexico UNINET-NETV6-1
>2001:6c0::/35 [se] Sweden SE-TELIANET-20010102
>
>Updated but only announcing the /35:
>2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
>2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
>2001:438::/32 [us] United States ABOVENET-IPV6
>2001:4d8::/32 [us] United States DOTNET-001
>
>You will not see those if you filter /35. I don't know whether you would
>miss them.
>
>Updated and announcing both /32 and /35:
>2001:258::/32 [jp] Japan INFOWEB-JPNIC-JP-2000502
>2001:2c0::/32 [jp] Japan INFOSPHERE-JPNIC-JP-20010208
>2001:340::/32 [jp] Japan FINE-JPNIC-JP-20011030
>2001:3d0::/32 [jp] Japan PTOP-JPNIC-JP-20020521
>2001:400::/32 [us] United States ESNET-V6
>2001:420::/32 [us] United States CISCO-IPV6-1
>2001:450::/32 [us] United States GBLX-V6
>2001:490::/32 [us] United States NOKIA-1
>2001:4b0::/32 [us] United States AOLTIMEWARNER
>
>those a probably afraid of the famous BGP ghosting or just haven't got
>around to kill the announcements.
>
>Disclaimer: I did not check whether the reports in GRH are correct, but
>it looks like that.
>
>Bernhard
>
>

Hi all,

On Mon, 23 May 2005, Kevin Loch wrote:
> Bernhard Schmidt wrote:
> >The rest of 2000::/3 is opened up to the current in-the-wild maximum
> >allocation prefix len of /35. In published filters you could often see
> >something like
> >
> >permit 2001::/32 ge 17 le 35
> >permit 2003::/32 ge 17 le 35
>
> I believe that all /35's are/were within 2001::/21.

Since /35 prefixes are still tolerated we have an exception
for /35 in our filters.

permit 2001::/16 ge 35 le 35
permit 2001::/16 ge 19 le 32

Also there is one organization which is using the /35 acceptance
to split their /32 to be used for diffrent locations.

2001:490::/32 origin by 14277
2001:490::/35 origin by 1248
2001:490:C000::/35 origin by 18666

What are the opinions for such a split ?

Regards,
Gerrit

Hi,

>
> 2001:490::/32 origin by 14277
> 2001:490::/35 origin by 1248
> 2001:490:C000::/35 origin by 18666
>
> What are the opinions for such a split ?
>

We would like to do the same, ie. announce /35 and /32 under different AS'es
We need to have different routing policy for them.

Regards

Jurek

Gerrit Wenig wrote:

>Also there is one organization which is using the /35 acceptance
>to split their /32 to be used for diffrent locations.
>
>2001:490::/32 origin by 14277
>2001:490::/35 origin by 1248
>2001:490:C000::/35 origin by 18666
>
>What are the opinions for such a split ?
>
>
As I wrote previously, we would be glad not to split our /32 but
according to RIPE policy I am unable to get second /32 (for the same,
one LIR). So the only way is to split it.

Bart

>Regards,
>Gerrit
>
>

On Tue, 24 May 2005, Bartek Gajda wrote:
> Some networks in Poland which are /32 are divided into a few /33 or /35
> and announced under different AS numbers. (there are only a few sTLa so
> far like this, but a few more will follow, for example 2001:b10::/33)
> This is because we have to implement different routing policy (under
> different AS numbers) and RIPE policy don't allow us to get additional /32

Note that advertising the /32 is still required by the RIPE policy.

"c) plan to provide IPv6 connectivity [...] by advertising that
connectivity through _its single aggregated address allocation_; and"

(emphasis mine.)

So, don't complain if folks filter out those more specifics.

--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

On Tue, May 24, 2005 at 08:36:02AM +0000, Gerrit Wenig wrote:
> Also there is one organization which is using the /35 acceptance
> to split their /32 to be used for diffrent locations.
>
> 2001:490::/32 origin by 14277
> 2001:490::/35 origin by 1248
> 2001:490:C000::/35 origin by 18666
>
> What are the opinions for such a split ?

That's what we get from withholding PI. Enterprises pretending to be
ISPs (not in Nokia's case as far as I know, as they "slipped thru"
before the restrictions came in place in ARIN land... they were quick
enought) and splitting the allocation as they can't pretend to have
enough "ISP operations" inside their enterprise.

We do see this from other shops as well, also enterprises. *looking
at a certain network gear vendor here* :-)

This will be more and more common. Even smaller companies who can afford
paying LIR fees do get allocations. Other examples include Microsoft and
Akamai.

To come back to the operational side of the question "What are the
opinions for such a split ?"... difficult to say. I can fully understand
those folks in their desires. Still, it's against the current rules...
if only against the intentions behind them.

The operational question in that is "how good connectivity do you want
to those folks".

If you filter more-specifics, YOU (and _only_ you) will follow the
aggregate... for the hope that you'll reach the other ASses who announce
the specifics via the aggregate advertiser. One can easily argue that it's
the aggregate advertiser's job to make sure that this works.

But as I stressed, this is a _local_ decision. The next AS on your path
to the aggregate might NOT filter and follow the more-specific
announcement. So your routing gets far more nondeterministic than it
could be - and far harder to debug when problems occur.

Now looking at the other side of the coin. With many people filtering
more-specifics, the AS_PATHs for them become long at times. Especially
when the advertisers are deep burried in 6BONE "structures". People
connected to (or indirectly have upstream from) the large EU-US IPv6
transits who do allow more-specific multihoming (C&W, Tiscali) usually
still have very good AS_PATHs, "if it's seen, it has a good AS_PATH".

For an example look at DENIC's /48 PA more-specific here:
http://www.sixxs.net/tools/grh/lg/?prefix=2001:608::/32

So wether PA more-specific multi-homing "works" highly depends on who
the upstreams are. But factually it's no real multi-homing as DENIC
_will_ lose connectivity to _many_ places when the aggregate /32 goes
down.

It's hard to discuss this without directly diving into policy land...

My operational recommendation is to NOT filter those kind of
announcements until the PI policy problem is solved for good. YMMV.


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

dr@cluenet.de (Daniel Roesen) wrote:

> Now looking at the other side of the coin. With many people filtering
> more-specifics, the AS_PATHs for them become long at times. Especially
> when the advertisers are deep burried in 6BONE "structures". People
> connected to (or indirectly have upstream from) the large EU-US IPv6
> transits who do allow more-specific multihoming (C&W, Tiscali) usually
> still have very good AS_PATHs, "if it's seen, it has a good AS_PATH".
>
> For an example look at DENIC's /48 PA more-specific here:
> http://www.sixxs.net/tools/grh/lg/?prefix=2001:608::/32
>
> So wether PA more-specific multi-homing "works" highly depends on who
> the upstreams are. But factually it's no real multi-homing as DENIC
> _will_ lose connectivity to _many_ places when the aggregate /32 goes
> down.

Since you mentioned our /48 as an example, I'd like to comment a bit...

Since we're an end site (yes, we're a LIR, but that doesn't help
with IPv6), there's no way to obtain an allocation from any of the
RIRs. This does not greatly bother us, since we chose our transit
providers carefully. We are as happy as someone with an assignment
from a LIR allocation can be, but that is a product of both a good
v6 transit ISP _and_ good peers at the local exchange who for the
most part do accept the /48 unfiltered from us (there are inetnum6
and route objects anyway, so auto-generated filters should let
that prefix pass).

I am not sure what will happen the moment we add another v6 transit
provider; due to the nature of our business (critical to a lot of
ISPs in Germany), we will go multi-homed as soon as we can. We will
try reaching an appropriate agreement with all our transit ISPs,
not to filter the /48 and to properly propagate it to their peers
and customers. If this works out, we see no necessity of v6 PI
space for our home network (we have a different application we
need v6 PI lookalike for, but that's a different thing).

Like with any prefix at all, beyond your own sphere of influence,
nobody can predetermine who will filter the prefix or not. That's
the way the Internet works. We are quite confident that in the case
of someone filtering the /48, and it not showing up somewhere, or
showing up with a very long path, the allocation prefix will bring
the traffic close enough to us so that the /48 catches again :-)

In brief:
- PA space multihoming depends on your transit/peering ISPs
- our prefix is well-documented
- we would prefer people not filtering it
- if they do, we trust in the power of aggregation

Yours,
Elmar.

--

"Begehe nur nicht den Fehler, Meinung durch Sachverstand zu substituieren."
(PLemken, <bu6o7e$e6v0p$2@ID-31.news.uni-berlin.de>)

--------------------------------------------------------------[ ELMI-RIPE ]---

[.can I invite ISP's who are not peering with GRH to peer with the
system? See http://www.sixxs.net/tools/grh/peering/ for the details.
The more information it receives the better the quality.]

On Mon, 2005-05-23 at 20:55 -0400, Kevin Loch wrote:
> Bernhard Schmidt wrote:
> > Updated but only announcing the /35:
> > 2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
> > 2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
> > 2001:438::/32 [us] United States ABOVENET-IPV6
> > 2001:4d8::/32 [us] United States DOTNET-001
>
> and Qwest 2001:428::/32 (which for some reason doesn't show up in the
> sixxs.net tla visibility charts.

There was a silly matching problem, blame me, fixed now, if I am correct.
The /32 is not there, but the /35 is btw, in total, as per:

https://noc.sixxs.net/tools/grh/tla/all/?country=all

The database currently holds 990 IPv6 TLA's.
Of which 30 (3.03%) are returned to the pool, 401 (40.51%) IPv6 TLA's
didn't have a routing entry.
Thus 559 (56.46%) networks are currently announced.
9 (0.91%) only announced a /35 while they have been allocated a /32.
8 (0.81%) announce both their /32 and their /35.

Have a /32 but announce a /35:
2001:230::/32 [kr] Korea ETRI-KRNIC-KR-19991124
2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
2001:428::/32 [us] United States QWEST-IPV6-1
2001:438::/32 [us] United States ABOVENET-IPV6
2001:450::/32 [us] United States GBLX-V6
2001:4d8::/32 [us] United States DOTNET-001
2001:6d8::/32 [pl] Poland PL-CYFRONET-20010221
2001:dc0::/32 [ap] Asian Pacific APNIC-AP-V6-20030124

Announcing both the /32 and /35:
2001:258::/32 [jp] Japan INFOWEB-JPNIC-JP-2000502
2001:2c0::/32 [jp] Japan INFOSPHERE-JPNIC-JP-20010208
2001:340::/32 [jp] Japan FINE-JPNIC-JP-20011030
2001:3d0::/32 [jp] Japan PTOP-JPNIC-JP-20020521
2001:400::/32 [us] United States ESNET-V6
2001:420::/32 [us] United States CISCO-IPV6-1
2001:490::/32 [us] United States NOKIA-1
2001:4b0::/32 [us] United States AOLTIMEWARNER

<smileyhat> (Cisco and Nokia don't trust their own routers? :) </smileyhat>

Greets,
Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
Url : http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20050524/c103b9ac/attachment.bin

And what about prefixes between /32 and /35
I can see at least two like this:

2001:5C0:8000::/34
inet6num: 2001:05e8:0000:0000:0000:0000:0000:0000/32
netname: PSCNET-V6
descr: Pittsburgh Supercomputing Center
country: US

2001:5E8::/33
inet6num: 2001:05c0:0000:0000:0000:0000:0000:0000/32
netname: HEXAGO-V6-NET1
country: CA

These are bad guys and deserve punishment from their RIR!?
:-/

Bart

Jeroen Massar wrote:

>[.can I invite ISP's who are not peering with GRH to peer with the
>system? See http://www.sixxs.net/tools/grh/peering/ for the details.
>The more information it receives the better the quality.]
>
>On Mon, 2005-05-23 at 20:55 -0400, Kevin Loch wrote:
>
>
>>Bernhard Schmidt wrote:
>>
>>
>>>Updated but only announcing the /35:
>>>2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
>>>2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
>>>2001:438::/32 [us] United States ABOVENET-IPV6
>>>2001:4d8::/32 [us] United States DOTNET-001
>>>
>>>
>>and Qwest 2001:428::/32 (which for some reason doesn't show up in the
>>sixxs.net tla visibility charts.
>>
>>
>
>There was a silly matching problem, blame me, fixed now, if I am correct.
>The /32 is not there, but the /35 is btw, in total, as per:
>
>https://noc.sixxs.net/tools/grh/tla/all/?country=all
>
>The database currently holds 990 IPv6 TLA's.
>Of which 30 (3.03%) are returned to the pool, 401 (40.51%) IPv6 TLA's
>didn't have a routing entry.
>Thus 559 (56.46%) networks are currently announced.
>9 (0.91%) only announced a /35 while they have been allocated a /32.
>8 (0.81%) announce both their /32 and their /35.
>
>Have a /32 but announce a /35:
>2001:230::/32 [kr] Korea ETRI-KRNIC-KR-19991124
>2001:358::/32 [jp] Japan MIND-JPNIC-JP-20011115
>2001:390::/32 [kr] Korea HANINTERNET-KRNIC-KR-20020207
>2001:428::/32 [us] United States QWEST-IPV6-1
>2001:438::/32 [us] United States ABOVENET-IPV6
>2001:450::/32 [us] United States GBLX-V6
>2001:4d8::/32 [us] United States DOTNET-001
>2001:6d8::/32 [pl] Poland PL-CYFRONET-20010221
>2001:dc0::/32 [ap] Asian Pacific APNIC-AP-V6-20030124
>
>Announcing both the /32 and /35:
>2001:258::/32 [jp] Japan INFOWEB-JPNIC-JP-2000502
>2001:2c0::/32 [jp] Japan INFOSPHERE-JPNIC-JP-20010208
>2001:340::/32 [jp] Japan FINE-JPNIC-JP-20011030
>2001:3d0::/32 [jp] Japan PTOP-JPNIC-JP-20020521
>2001:400::/32 [us] United States ESNET-V6
>2001:420::/32 [us] United States CISCO-IPV6-1
>2001:490::/32 [us] United States NOKIA-1
>2001:4b0::/32 [us] United States AOLTIMEWARNER
>
><smileyhat> (Cisco and Nokia don't trust their own routers? :) </smileyhat>
>
>Greets,
> Jeroen
>
>
>

On Tue, May 24, 2005 at 12:33:08PM +0200, Bartek Gajda wrote:
> And what about prefixes between /32 and /35
> I can see at least two like this:
>
> 2001:5C0:8000::/34
> inet6num: 2001:05e8:0000:0000:0000:0000:0000:0000/32
> netname: PSCNET-V6
> descr: Pittsburgh Supercomputing Center
> country: US
>
> 2001:5E8::/33
> inet6num: 2001:05c0:0000:0000:0000:0000:0000:0000/32
> netname: HEXAGO-V6-NET1
> country: CA
>
> These are bad guys and deserve punishment from their RIR!?
> :-/

I see nothing which forbids them to announce more-specifics, so on
what basis would anyone want to punish (and how)?

The PSC /33 (not a /34!) seems more like a mistake as GRH sees only
paths _11537_5050$ for both the /32 and the /33. Perhaps some weird
kind of traffic engineering internally or with private peers for
special purposes, and the /33 leaking outside of the Abilene cloud
(however this can be defined).


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

We are currently announcing 2001:06c0::/35. We never applied for a /32
because it would be to small. Our new allocation is 2001:2000::/20 so we
are about to migrate our /35 network to the /20 network. However, it is
not done yet so it would be good if you don't filter out /35 networks
yet.


/// Mattias Lignell - TeliaSonera

On 24 May 2005, at 06:51, Daniel Roesen wrote:

>
> The PSC /33 (not a /34!) seems more like a mistake as GRH sees only
> paths _11537_5050$ for both the /32 and the /33. Perhaps some weird
> kind of traffic engineering internally or with private peers for
> special purposes, and the /33 leaking outside of the Abilene cloud
> (however this can be defined).

The latter. We'll try to fix this in the next few days via the
appropriate community tag to Abilene.

Michael

-----------
Michael H. Lambert Network Engineer
Pittsburgh Supercomputing Center V: +1 412 268 4960
4400 Fifth Avenue F: +1 412 268 8200
Pittsburgh, PA 15213 USA

On Tue, May 24, 2005 at 09:23:52AM -0400, Michael H. Lambert wrote:
> >The PSC /33 (not a /34!) seems more like a mistake as GRH sees only
> >paths _11537_5050$ for both the /32 and the /33. Perhaps some weird
> >kind of traffic engineering internally or with private peers for
> >special purposes, and the /33 leaking outside of the Abilene cloud
> >(however this can be defined).
>
> The latter. We'll try to fix this in the next few days via the
> appropriate community tag to Abilene.

Great, thanks!


Best regards,
Daniel

--
CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0

On 24-mei-2005, at 10:52, Bartek Gajda wrote:

>> 2001:490::/32 origin by 14277
>> 2001:490::/35 origin by 1248
>> 2001:490:C000::/35 origin by 18666

>> What are the opinions for such a split ?

> As I wrote previously, we would be glad not to split our /32 but
> according to RIPE policy I am unable to get second /32 (for the same,
> one LIR). So the only way is to split it.

Why is this necessary???

The RIRs say you can filter at /32. (Well, except for micro
allocations.)

But I don't keep all RIR allocations and assignments in a database,
so let's have a look:

mysql> select count(*) as delegations, num as prefixlength from
addrspace where type="ipv6" group by num order by num;
+-------------+--------------+
| delegations | prefixlength |
+-------------+--------------+
| 1 | 19 |
| 2 | 20 |
| 2 | 21 |
| 1 | 22 |
| 1 | 23 |
| 1 | 24 |
| 2 | 27 |
| 1 | 28 |
| 1 | 29 |
| 2 | 30 |
| 3 | 31 |
| 702 | 32 |
| 112 | 33 |
| 112 | 34 |
| 231 | 35 |
| 54 | 48 |
| 5 | 64 |
+-------------+--------------+
17 rows in set (0.31 sec)

This is actually pretty shocking!

Hi Iljitsch,

On May 25, 2005, at 12:05 pm, Iljitsch van Beijnum wrote:

[...]

> The RIRs say you can filter at /32. (Well, except for micro
> allocations.)
>
> But I don't keep all RIR allocations and assignments in a database,
> so let's have a look:
>
> mysql> select count(*) as delegations, num as prefixlength from
> addrspace where type="ipv6" group by num order by num;
> +-------------+--------------+
> | delegations | prefixlength |
> +-------------+--------------+
> | 1 | 19 |
> | 2 | 20 |
> | 2 | 21 |
> | 1 | 22 |
> | 1 | 23 |
> | 1 | 24 |
> | 2 | 27 |
> | 1 | 28 |
> | 1 | 29 |
> | 2 | 30 |
> | 3 | 31 |
> | 702 | 32 |
> | 112 | 33 |
> | 112 | 34 |
> | 231 | 35 |
> | 54 | 48 |
> | 5 | 64 |
> +-------------+--------------+
> 17 rows in set (0.31 sec)
>
> This is actually pretty shocking!

When you look at the statistics published by the RIPE NCC you will
often see several prefixes reported for a single allocation. This is
because we report each allocation event separately.

In quite a few cases LIRs expanded their /35 allocations into /32s
(or even shorter prefixes where justified). In a situation where a /
35 was 'grown' into a /32 you'll see prefixes like these reported:

2001:07b8::/35
2001:07b8:2000::/35
2001:07b8:4000::/34
2001:07b8:8000::/33

but if you look in the Whois database you'll see a /32 with the
ALLOCATED-BY-RIR status, not any more specific prefixes.

I hope this explains why you see a bunch of /33s and /34s in the
statistics we publish.

Regards,

--
leo vegoda
Registration Services Manager
RIPE NCC

Hi Leo,

My attention was caught by this list of prefixes [my employer's]:

| 2001:07b8::/35
| 2001:07b8:2000::/35
| 2001:07b8:4000::/34
| 2001:07b8:8000::/33
This is nl.bit and its numberplan goes way back [at least conceptually].
IIRC these prefixes are not assignments, but allocations to fit a
templating scheme I conjured up when we received the allocation.

I cannot find these inet6nums in the RIPE database currently. Can you
comment on how you got this information ? I'd like to clean up where
possible, because we are not using this numberplan anymore currently.

Thanks, groet,
Pim
--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim@ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------

Hi,

On May 25, 2005, at 2:19 pm, Pim van Pelt wrote:

> Hi Leo,
>
> My attention was caught by this list of prefixes [my employer's]:
>
> | 2001:07b8::/35
> | 2001:07b8:2000::/35
> | 2001:07b8:4000::/34
> | 2001:07b8:8000::/33
> This is nl.bit and its numberplan goes way back [at least
> conceptually].
> IIRC these prefixes are not assignments, but allocations to fit a
> templating scheme I conjured up when we received the allocation.
>
> I cannot find these inet6nums in the RIPE database currently. Can you
> comment on how you got this information ? I'd like to clean up where
> possible, because we are not using this numberplan anymore currently.

I just pulled the numbers for nl.bit at random in an effort to
explain why the statistics show /33 and /34 prefixes as having been
allocated.

Those ranges are what we have recorded in our internal systems for
when we expanded the /35 to a /32 - we show each additional prefix
required to grow a /35 to a /32 as a separate allocation. We also do
the same thing when we expand an IPv4 /20 into a /19, /18 or whatever.

The only records for this growth are our internal files and the
published statistics (because they are based on that data). These
'interim' prefixes were never registered in the Whois database.

I hope this clarifies things.

Regards,

--
leo vegoda
Registration Services Manager
RIPE NCC

Hi Leo,

| Those ranges are what we have recorded in our internal systems for
| when we expanded the /35 to a /32 - we show each additional prefix
| required to grow a /35 to a /32 as a separate allocation. We also do
| the same thing when we expand an IPv4 /20 into a /19, /18 or whatever.
|
| The only records for this growth are our internal files and the
| published statistics (because they are based on that data). These
| 'interim' prefixes were never registered in the Whois database.
|
| I hope this clarifies things.
Yes, I'm enlightened. Thanks for taking the time to explain this to me;
I'm sure others found it useful too!

Back to the original thread at hand, it might be a good idea to filter
out these more specific internal prefixes in statistics-output.

groet,
Pim

--
---------- - - - - -+- - - - - ----------
Pim van Pelt Email: pim@ipng.nl
http://www.ipng.nl/ IPv6 Deployment
-----------------------------------------------

Hi,

On May 26, 2005, at 8:37 am, Pim van Pelt wrote:

[...]

> Back to the original thread at hand, it might be a good idea to filter
> out these more specific internal prefixes in statistics-output.

In some cases it is useful to filter that kind of information out.
However, some people do use it (mainly in IPv4 statistics, I think).
I know that people have used this information to research the number
of 'transactions' that took place for prefixes.

We're always open to requests for how we can make the statistics more
useful, though. It may be possible to produce a 'filtered' and an
'unfiltered' set of statistics if that is what people want from us.

Regards,

--
leo vegoda
Registration Services Manager
RIPE NCC