[6bone] Summer cleanup time for IPv6 aggregation!

Roger Jorgensen rjorgensen@upctechnology.com
Fri, 26 Jul 2002 16:50:19 +0200


Someone out there has now recently opened up their filters and are
passing on /48's and lots of other things. Check older stats and you'll
see that much of this crap wasn't there before.


My point of view on this can be put this way:

1) If you want to have strict aggregation (after the RFC) you filter incoming
AND outgoing

2) If you want less strict aggregation it's okay to allow upto /48's
both incoming and outgoing (I assume people do filter away not wanted
announcment if they follow the RFC letter by letter) and incoming.
Anything smaller than /48's are not accepted under any circumstances)



At 01:17 PM 7/25/2002 +0200, Jeroen Massar wrote:
<SNIP>

since I'm part of the IPv6 team here at chello (UPC Technology is more correct)
I'll comment on this part.

>8<---------
>CHELLO (AS6830) announced 16 route(s)
>     3ffe:2501:100::/48 path 10566 6939 6830 8733 (TVD -- 52%)
>     3ffe:8070:1010::/48 path 12199 145 11537 786 109 4618 (INET-TH --
>4%)
>     3ffe:8070:1010::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:2900:2004::/48 path 12199 145 11537 786 109 4618 (INET-TH --
>4%)
>     3ffe:2900:2004::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:1300:7::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%)
>     3ffe:1300:7::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:327e:1::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%)
>     3ffe:327e:1::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:4005:a::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%)
>     3ffe:4005:a::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:80ee:556::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%)
>     3ffe:80ee:556::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:200:c::/48 path 10566 6939 6830 2847 ( -- 52%)
>     3ffe:80b0:1002::/48 path 10566 6939 6830 8733 (TVD -- 52%)
>     2001:6e0:202::/48 path 12199 145 11537 786 109 5539 1853 6830 8209 (
>-- 4%)
>     3ffe:400b:6002::/48 path 12199 145 11537 786 109 4618 (INET-TH --
>4%)
>     3ffe:400b:6002::/48 path 10566 6939 6830 (CHELLO -- 100%)
>     3ffe:81a0:1012::/48 path 12199 145 11537 786 109 4618 (INET-TH --
>4%)
>     3ffe:81a0:1012::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:2500:322::/48 path 12199 145 11537 786 109 4618 (INET-TH -- 4%)
>     3ffe:2500:322::/48 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:8271:a080::/44 path 12199 145 11537 786 109 4618 (INET-TH --
>4%)
>     3ffe:8271:a080::/44 path 10566 6939 6830 (CHELLO -- 52%)
>     3ffe:82bf::/32 path 10566 6939 6830 24643 (NEXTGEN-LAB -- 52%)
>     3ffe:2640::/32 path 10566 6939 6830 790 6793 (TELIAFI -- 51%)
>--------->8
>And even more /48's, /44's and /32's and even double entries, great to
>spread those.
>
>inet6num:     3FFE:82B0::/28
>netname:      WEBONLINE-NET
>descr:        WebOnline AS
>
>Keep those peerings private...

3ffe:82bf::/32 is delegated to AS24643, also us. It's been in the list forever.
AS8209 is also us, think I maybe should create a 6bone entry for it.


and a general comment:

What's wrong with letting through 3ffe::/16 le /32 ? (know it break the current
RFC), but wouldn't it be an idea to let both 2001 and 3ffe space be aggregated
upto /32 ? (2001 are, but 3ffe aren't)

And on a later stage, maybe we should change the RFC and allow even something
bigger than /32 be let through, /40 ? (/48's are too big to be let through 
on a RFC base)




---
Roger Jorgensen (rjorgensen@chello.com)
System Engineer @ UPC Technology / IP engineering
handles: ROJO1-6BONE ROJO9-RIPE RJC10-NORID