[6bone] In the summer time, we got cleaning to do... Where is UUNET?

[John Fraizer]

On Thu, 1 Aug 2002, Michel Py wrote:

> >> John Fraizier wrote:
> >> Border2-BGP(config)# ipv6 prefix-list test1 seq 30 permit
> >> 2002::/16 ge 16 le 48
> >> % Invalid prefix range for 2002::/16, make sure: len
> >> < ge-value <= le-value
> >> Any suggestions are greatly appreciated!
> 
> > Itojun wrote:
> > you wouldn't want to allow 2002::/16 le 48. there should be
> > 2002::/16, nothing else.  see 6to4 RFC.
> 
> I tend to agree. John, what are you trying to achieve here? Load-balance
> between more than one 6to4 relay?
> 
> Besides, I would highly recommend to be your own 6to4 relay if this
> router has IPv4 connectivity, which still is the case for most.
> 
> Michel.


I was simply building filters based on the following quote from Jeroen:

=======BEGIN QUOTE=======
Just to make sure everybody gets it again:
8<--------------------
3ffe::/18 ge 24 le 24
3ffe:4000::/18 ge 32 le 32
3ffe:8000::/20 ge 28 le 28
2000::/3 ge 16 le 16
2001::/16 ge 29 le 35
2002::/16 ge 16 le 48

or as seen on 6bone.net:
3ffe:0000::/24 thru 3ffe:3f00::/24      /24
3ffe:4000::/32 thru 3ffe:7fff::/32      /32
3ffe:8000::/24 thru 3ffe:83f0::/24      /28

3ffe:8400::/32 thru 3ffe:ffff::/32 can be filtered
out completely as it will be unassigned for a long time to come.

RIR space (2001::/16) will become /32 only in the long run.
-------------------->8

IPv6 - Just keep it clean, filter.

Greets,
 Jeroen
=======END QUOTE=======



Notice the line that says "2002::/16 ge 16 le 48"...  That's why I was
trying to build the filter that way.

I've since updated our filters on peers as follows:

(We'll use your peering session as an example Michel)



router bgp 13944
 neighbor 3ffe:1ced:ff02::2 remote-as 23169
 neighbor 3ffe:1ced:ff02::2 description ARNEILLPY
 no neighbor 3ffe:1ced:ff02::2 activate
!
 address-family ipv6
 neighbor 3ffe:1ced:ff02::2 activate
 neighbor 3ffe:1ced:ff02::2 next-hop-self
 neighbor 3ffe:1ced:ff02::2 prefix-list AS-ARNEILLPY in
 neighbor 3ffe:1ced:ff02::2 prefix-list subTLA-only out
 neighbor 3ffe:1ced:ff02::2 route-map AS-ARNEILLPY in
 exit-address-family
!
ipv6 prefix-list AS-ARNEILLPY seq 10 permit 3ffe:1ced:a002::/48
ipv6 prefix-list subTLA-only seq 1 permit 3ffe:1ced::/32
ipv6 prefix-list subTLA-only seq 5 permit 3ffe::/18 ge 24 le 24
ipv6 prefix-list subTLA-only seq 10 permit 3ffe:4000::/18 ge 32 le 32
ipv6 prefix-list subTLA-only seq 15 permit 3ffe:8000::/20 ge 28 le 28
ipv6 prefix-list subTLA-only seq 20 permit 2000::/3 ge 16 le 16
ipv6 prefix-list subTLA-only seq 25 permit 2001::/16 ge 29 le 35
ipv6 prefix-list subTLA-only seq 30 permit 2002::/16
ipv6 prefix-list subTLA-only seq 500 deny any
!
route-map AS-ARNEILLPY permit 10
 match ipv6 address prefix-list subTLA-only
!
route-map AS-ARNEILLPY permit 20
 match ipv6 address prefix-list AS-ARNEILLPY
 set community no-export additive
!




Basically, on YOUR peering session, I'm prefix-list filtering you based on
ipv6 prefix-list AS-ARNEILLPY.  The route-map is a "stock" route-map that
is applied to EVERY peer.

If the peer isn't being prefix-list filtered on the way in, and they show
us VALID prefixes that pass ipv6 prefix-list subTLA-only, we accept them
and will redistribute them.

If they are showing us more-specifics (unaggregated) that I have allowed
in ipv6 prefix-list AS-[PEERNAME] we accept them but tag them with the
no-export community and don't redistribute them.

After applying the new filters, we had one peer go from WELL over 300
prefixes to 253 prefixes.

So, in summary, we'll accept more-specifics, by arrangement, but will not
redistribute them outside of our AS.  Everything else has to be within the
aggregation guidelines or we don't accept it at all and with the exception
of 3ffe:1ced::/32 (and we all know the story behind that) we shouldn't be
showing anyone any prefixes that are outside of the aggregation
guidelines.

Does anyone see any flaw in the above policy?  I've thought about how to
do this correctly for the past week or so and finally implemented the new
policy a few minutes ago.

It looks like we're showing peers 254 prefixes right now INCLUDING the
3ffe:1ced::/32 specific.

Any comments appreciated.

---
John Fraizer              | High-Security Datacenter Services |
EnterZone, Inc            | Dedicated circuits 64k - 155M OC3 |
http://www.enterzone.net/ | Virtual, Dedicated, Colocation    |