Rob / Jeroen / IPv6 folk, [I wonder if this is the best list, but it started here. I will post something related to idr soon]
> Rob Thomas wrote: > I am attempting to put together an IPv6 version of the bogon > template, and I could definitely use some help. I have the very > rough BETA version available, but I don't have a live IPv6 feed > or much IPv6 experience. I'm sure I have some amazing errors, > and I'd like to know about them. :) If you have a few moments, > I would welcome your ideas and insight. > <http://www.cymru.com/Documents/bogonv6-list.html> Rob, before we begin the work on the actual bogon list, I think we need to have a sound discussion about the distribution methods, see below. > Jeroen Massar wrote: > Though, dear vendors, maybe it would be nice to have some kind of > distribution method for filters, another use of this would be to > quickly distribute a prefix which would need to be dropped (ddos etc). Actually, I think that there would be little work to adapt BGP Prefix-Based Outbound Route Filtering (ORF) do make it capable of applying the received prefix-list to other interfaces; See below. I wrote a little taxonomy about IPv6 bogon filtering; this is very, very crude and I welcome your comments. Taxonomy of IPv6 bogon filtering. ================================= There are five basic ways to handle the IPv6 bogon filtering issue: 1. Manually configured prefix-lists. 2. BGP feed of "bad" prefix aggregates. 3. BGP feed of anomalies. 4. BGP feed of "good" prefixes. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). 1. Manually configured prefix-lists. ------------------------------------ This involves one or more volunteers (likely from the to: field :-) to maintain a prefix-list that is to be configured manually on routers. The issue with this is change management: as we have seen with the 69/8 fiasco not that long ago, some people do _not_ update their filters regularly, and when the bogon prefix-list is modified it can take weeks to be upgraded, which is not good. In terms of granularity, this is what gives the finest control. 2. BGP feed of "bad" prefix aggregates. --------------------------------------- This is the mechanism currently used by team cymru's bogon route servers. The issue with this is that the domain of applicability is limited to networks that do not receive a full feed. If one gets a full feed, this method does not prevent bad prefixes if they are smaller than the bogon feed, because of the longest match rule. So, this is an option only for networks with private peering only and a default route outside, because a blackhole route is installed to dump all the bogon traffic instead of sending it to the default route. 3. BGP feed of anomalies. ------------------------- A finer version of the previous one. Real-time monitoring of the routing table at different points allows to build a list of bad announcements. Contrary to the previous option, this allows to deal with specific announcements. The issue with this is that it does not prevent the bad announcement to be received, it actually adds another path that will be made preferred to the offending announcement and used to dump the traffic in a blackhole. Compared to the feeding of bad aggregates, this method extends the domain of applicability to defaultless networks, at the expense of aggravating the routing table size issue. 4. BGP feed of "good" prefixes. ------------------------------- Jeroen, I'm sorry but I still can't figure out how you can make this work. Can you post a Cisco example please? Both ends, route server and client. 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF). ----------------------------------------------------------------- http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_ guide09186a0080134a57.html http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt Unfortunately the actual capabilities of this are that the filter-list received from the peer is applied only outbound to the same peer. This would be a very promising technique for bogon route servers, but we need to enhance it. Please send comments. Michel. --------------------------------------------------------------------- The IPv6 Users Mailing List Unsubscribe by sending "unsubscribe users" to [EMAIL PROTECTED]
