The purpose of this post is to determine the best practice for IPv6 martian and bogon filters.
IPv4 martian and bogon filters have been around a while and are fairly well known and stable. But IPv6 is new and best practices for martian and bogon filters have not fully evolved. In researching around, I have found several variations and quite a bit of uncertainty. This post is an attempt to come to consensus as to what are the most accurate martian and bogon filters for use in network access-lists and BGP configurations.
Background
For those of you not familiar with the terms “martian” or “bogon” filter, it goes as follows. Keep in mind that these terms are not exactly defined in the Webster dictionary but have kind of just evolved, and sometimes they are used interchangeably.
Martians
“Martians” are prefixes that are not valid for use on the public Internet. They include a variety of reserved or otherwise unusable network addresses. The prefixes cannot be assigned to globally routable hosts, therefore a network should never see traffic sourced from those addresses. In the IPv4 world they include RFC 1918 private subnets, the multicast block, the reserved “Class E” block and a few others. Of course, some of these blocks are valid within a private network, obviously the RFC 1918 addresses. It is predominantly when two separate Autonomous Systems are connected where these prefixes must be considered.
As of this writing, the typical list of IPv4 martians includes:
| 0.0.0.0/0 | Default (can be advertised in BGP if desired) |
| 0.0.0.0/8 | Self identification |
| 0.0.0.0/32 | Broadcast |
| 10.0.0.0/8 | Private Networks (RFC 1918) |
| 127.0.0.0/8 | Loopback |
| 128.0.0.0/16 | IANA Reserved (RFC 3330) |
| 172.16.0.0/12 | Private Networks (RFC 1918) |
| 169.254.0.0/16 | Local |
| 191.255.0.0/16 | Reserved (RFC 3330) |
| 192.0.0.0/24 | IANA Reserved (RFC 3330) |
| 192.0.2.0/24 | Test-Net (RFC 3330) |
| 192.168.0.0/16 | Networks (RFC 1918) |
| 198.18.0.0/15 | Network Interconnect Device Benchmark Testing |
| 223.255.255.0/24 | Special Use Networks (RFC 3330) |
| 224.0.0.0/4 | Multicast |
| 240.0.0.0/4 | Class E Reserved |
The IPv4 list does not map exactly to IPv6, but there are some similar addresses in IPv6 that should not be seen as the source of traffic nor should be advertised or accepted as a BGP route. They include:
| ::/0 | Default (can be advertised as a route in BGP to peers if desired) |
| ::/96 | IPv4-compatible IPv6 address – deprecated by RFC4291 |
| ::/128 | Unspecified address |
| ::1 /128 | Local host loopback address |
| ::ffff:0.0.0.0 /96 | IPv4-mapped addresses |
| ::224.0.0.0 /100 | Compatible address (IPv4 format) |
| ::127.0.0.0 /104 | Compatible address (IPv4 format) |
| ::0.0.0.0 /104 | Compatible address (IPv4 format) |
| ::255.0.0.0 /104 | Compatible address (IPv4 format) |
| 0000:: /8 | Pool used for unspecified, loopback and embedded IPv4 addresses |
| 0200:: /7 | OSI NSAP-mapped prefix set (RFC4548) – deprecated by RFC4048 |
| 3ffe::/16 | Former 6bone, now decommissioned |
| 2001:db8::/32 | Reserved by IANA for special purposes and documentation |
| 2002:e000:: /20 | Invalid 6to4 packets (IPv4 multicast) |
| 2002:7f00:: /24 | Invalid 6to4 packets (IPv4 loopback) |
| 2002:0000:: /24 | Invalid 6to4 packets (IPv4 default) |
| 2002:ff00:: /24 | Invalid 6to4 packets |
| 2002:0a00:: /24 | Invalid 6to4 packets (IPv4 private 10.0.0.0/8 network) |
| 2002:ac10:: /28 | Invalid 6to4 packets (IPv4 private 172.16.0.0/12 network) |
| 2002:c0a8:: /32 | Invalid 6to4 packets (IPv4 private 192.168.0.0/16 network) |
| fc00:: /7 | Unicast Unique Local Addresses (ULA) – RFC 4193 |
| fe80:: /10 | Link-local Unicast |
| fec0:: /10 | Site-local Unicast – deprecated by RFC 3879 (replaced by ULA) |
| ff00:: /8 | Multicast |
Bogons
“Bogons” are network prefixes that are valid but have not yet been allocated by IANA to an RIR (who would in turn allocates prefixes downstream to an LIR / service provider, who in turn assigns prefixes to end-user organizations.) Because they have not been allocated, a network should never see traffic sourced from those addresses as it may be attack traffic that is using an invalid source address for the purpose of concealing the attacker’s identity and/or misdirecting the return traffic. The prefixes should also not be accepted as valid routes in BGP nor should they be advertised by BGP between public BGP peers (although a few of the prefixes may be advertised within in BGP within an AS.)
As of this writing the IPv6 bogon list includes:
| 2001:db8::/32 | 2410::/12 | 2628::/13 |
| ::/3 | 2420::/11 | 2630::/12 |
| 2000::/16 | 2440::/10 | 2640::/10 |
| 2001:1::/32 | 2480::/9 | 2680::/9 |
| 2001:2::/31 | 2500::/8 | 2700::/8 |
| 2001:4::/30 | 2610:200::/23 | 2810::/12 |
| 2001:8::/29 | 2610:400::/22 | 2820::/11 |
| 2001:10::/28 | 2610:800::/21 | 2840::/10 |
| 2001:20::/27 | 2610:1000::/20 | 2880::/9 |
| 2001:40::/26 | 2610:2000::/19 | 2900::/8 |
| 2001:80::/25 | 2610:4000::/18 | 2a10::/12 |
| 2001:100::/24 | 2610:8000::/17 | 2a20::/11 |
| 2001:1000::/23 | 2611::/16 | 2a40::/10 |
| 2001:4e00::/23 | 2612::/15 | 2a80::/9 |
| 2001:6000::/19 | 2614::/14 | 2b00::/8 |
| 2001:c000::/18 | 2618::/13 | 2c10::/12 |
| 2003:4000::/18 | 2620:200::/23 | 2c20::/11 |
| 2003:8000::/17 | 2620:400::/22 | 2c40::/10 |
| 2004::/14 | 2620:800::/21 | 2c80::/9 |
| 2008::/13 | 2620:1000::/20 | 2d00::/8 |
| 2010::/12 | 2620:2000::/19 | 2e00::/7 |
| 2020::/11 | 2620:4000::/18 | 3000::/4 |
| 2040::/10 | 2620:8000::/17 | 4000::/2 |
| 2080::/9 | 2621::/16 | 8000::/1 |
| 2100::/8 | 2622::/15 | |
| 2200::/7 | 2624::/14 |
(Reference: Team Cymru, http://www.cymru.com/Bogons/v6bogon.html)
Because the IPv6 address pool is so large – and because right now IPv6 adoption is slow – it is probable that the bogon list will remain static for a while. The prefixes currently allocated by IANA to RIRs should last for a long time. However, it is still important to routinely check the status of the bogon list and update filters accordingly, if not automate the process, just to be safe. Otherwise you may cause a lot of headaches for the people whose traffic you deny. Until such a time when a lot of IPv6 space has been allocated by IANA, it is easier to permit the allocated blocks while denying the rest of the IPv6 pool.
Similarities, Differences and Operational Concerns
Generally, martians and bogons look similar as they are both networks that should not be permitted on a network either as a source address or as a prefix accepted by eBGP in public peering sessions.
The main difference between a “martian” and “bogon” filter is that a martian filter contains reserved blocks that will likely never be valid, not unless IANA releases them for public use, while a bogon filter contains prefixes that are not currently but may one day become valid public prefixes once they are allocated.
From an administrative point of view, a bogon filter is a little more cumbersome to maintain. You need to keep up on the state of allocated prefixes and update your bogon filters as IANA allocates new prefixes into circulation. Because of the rate of IPv4 depletion, the IPv4 bogon list changes frequently as IANA allocates new /8s from the reserved pool to RIRs. Without an automated script or tool that can track new allocations via IANA and RIR websites and databases, keeping bogon lists update can be cumbersome. Inaccurate bogon filters can lead to inadvertently filtered traffic or inadvertently rejected BGP routes. In IPv6, because the amount of allocated space is so low it is actually simpler to permit the allocated prefixes and deny everything else rather than vice versa as is done in IPv4.
Because of this risk and effort, some network administrators implement martian filters but don’t bother with bogon filters. A martian filter is easier to maintain because it is likely to remain reasonably static, although network administrators should still keep up on IANA polices and review their filters occasionally to make sure nothing has changed. For example, IANA recently recovered the 14.0.0.0/8 IPv4 network and will allocate the block. Bogon filters will need to be updated accordingly.
The list of IPv6 allocated prefixes can be found at IANA’s website at:
http://www.iana.org/assignments/ipv6-unicast-address-assignments
Security Concerns
The reason that it is important to implement martian and bogon filters is because some network attacks use those prefixes as source addresses to hide their actual identity so that they cannot be traced and/or so that return traffic is directed to an invalid address. As such, martian and bogon filters should be implemented in at least two places.
1.At the network perimeter in routers or firewalls – Access-lists and firewall filters at the perimeter of a network should be configured to drop any packet that has a source address with a martian or bogon address.
2.In BGP routers – Prefix filters should be configured such that BGP routers rejects any route received from a public eBGP peer that is a martian or bogon prefix. The route should not be installed in the router’s routing table. It may be acceptable to accept some IPv6 martians within an AS in your iBGP session depending on your network’s configuration and requirements. As a safety precaution, BGP routers should also be configured to not advertise martian and bogon prefixes. The exception to this may be ULAs, which can be advertised and received in BGP within an AS.
Cisco Access-list and BGP route filters
In trying to determine what is the most accurate bogon and martian filters, searching around the Internet and in text books yields various results. Two very good sources came to light, one of which borrowed from the other.
Team Cymru (http://www.cymru.com) has done excellent work to keep track of allocated, unallocated and invalid prefixes. They provide sample router filters as well.
Additionally, a new and excellent IPv6 book – IPv6 Security, by Scott Hogg and Eric Vyncke, Cisco Press, December 2008 – sheds additional light on the issue, as well as referencing Team Cymru’s IPv6 work.
Drawing from both sources and a few others, the following is an IPv6 access list that drops any packets with martian or bogon source addresses:
ipv6 access-list FILTER-MARTIANS-AND-BOGONS
remark ACL TO DROP ALL PACKETS WITH IPv6 BOGON OR MARTIAN SOURCE ADDRESSES
remark FIRST THE MARTIANS
deny ipv6 ::/0 any
deny ipv6 ::/96 any
deny ipv6 ::/128 any
deny ipv6 ::1/128 any
deny ipv6 ::ffff:0000:0000/96 any
deny ipv6 ::df00:0000/100 any
deny ipv6 ::7f00:0000/104 any
deny ipv6 ::0000:0000/104 any
deny ipv6 ::ff00:0000/104 any
deny ipv6 0000::/8 any
deny ipv6 0200::/7 any
deny ipv6 3ffe::/16 any
deny ipv6 2001:db8::/32 any
deny ipv6 2002:e000::/20 any
deny ipv6 2002:7f00::/24 any
deny ipv6 2002:0000::/24 any
deny ipv6 2002:ff00::/24 any
deny ipv6 2002:ff00::/24 any
deny ipv6 2002:0a00::/24 any
deny ipv6 2002:ac10::/28 any
deny ipv6 2002:c0a8::/32 any
deny ipv6 fc00::/7 any
deny ipv6 fe80::/10 any
deny ipv6 fec0::/10 any
deny ipv6 ff00::/8 any
!
remark NOW THE BOGONS – THIS NEEDS TO BE KEPT UP TO DATE!
!
deny ipv6 2001:db8::/32 any
deny ipv6 ::/3 any
deny ipv6 2000::/16 any
deny ipv6 2001:1::/32 any
deny ipv6 2001:2::/31 any
deny ipv6 2001:4::/30 any
deny ipv6 2001:8::/29 any
deny ipv6 2001:10::/28 any
deny ipv6 2001:20::/27 any
deny ipv6 2001:40::/26 any
deny ipv6 2001:80::/25 any
deny ipv6 2001:100::/24 any
deny ipv6 2001:1000::/23 any
deny ipv6 2001:4e00::/23 any
deny ipv6 2001:6000::/19 any
deny ipv6 2001:c000::/18 any
deny ipv6 2003:4000::/18 any
deny ipv6 2003:8000::/17 any
deny ipv6 2004::/14 any
deny ipv6 2008::/13 any
deny ipv6 2010::/12 any
deny ipv6 2020::/11 any
deny ipv6 2040::/10 any
deny ipv6 2080::/9 any
deny ipv6 2100::/8 any
deny ipv6 2200::/7 any
deny ipv6 2410::/12 any
deny ipv6 2420::/11 any
deny ipv6 2440::/10 any
deny ipv6 2480::/9 any
deny ipv6 2500::/8 any
deny ipv6 2610:200::/23 any
deny ipv6 2610:400::/22 any
deny ipv6 2610:800::/21 any
deny ipv6 2610:1000::/20 any
deny ipv6 2610:2000::/19 any
deny ipv6 2610:4000::/18 any
deny ipv6 2610:8000::/17 any
deny ipv6 2611::/16 any
deny ipv6 2612::/15 any
deny ipv6 2614::/14 any
deny ipv6 2618::/13 any
deny ipv6 2620:200::/23 any
deny ipv6 2620:400::/22 any
deny ipv6 2620:800::/21 any
deny ipv6 2620:1000::/20 any
deny ipv6 2620:2000::/19 any
deny ipv6 2620:4000::/18 any
deny ipv6 2620:8000::/17 any
deny ipv6 2621::/16 any
deny ipv6 2622::/15 any
deny ipv6 2624::/14 any
deny ipv6 2628::/13 any
deny ipv6 2630::/12 any
deny ipv6 2640::/10 any
deny ipv6 2680::/9 any
deny ipv6 2700::/8 any
deny ipv6 2810::/12 any
deny ipv6 2820::/11 any
deny ipv6 2840::/10 any
deny ipv6 2880::/9 any
deny ipv6 2900::/8 any
deny ipv6 2a10::/12 any
deny ipv6 2a20::/11 any
deny ipv6 2a40::/10 any
deny ipv6 2a80::/9 any
deny ipv6 2b00::/8 any
deny ipv6 2c10::/12 any
deny ipv6 2c20::/11 any
deny ipv6 2c40::/10 any
deny ipv6 2c80::/9 any
deny ipv6 2d00::/8 any
deny ipv6 2e00::/7 any
deny ipv6 3000::/4 any
deny ipv6 4000::/2 any
deny ipv6 8000::/1 any
!
! ADD OTHER SPECIFIC RULES HERE BASED ON YOUR SPECIFIC REQUIREMENTS ***
!
permit ipv6 any any
*** Of course, you may have other more specific permit and denies to add to the access-list and you may not want the global permit any any at the end, so modify the filter according to your needs.
Similarly, the following represents a BGP prefix filter that rejects inbound martian and bogon routes that might be inadvertently announced by BGP peers, allowing valid routes to be accepted. This strategy can also be applied to outbound route announcements from your network if you are advertising full Internet routing tables to customers and want to be absolutely sure that you don’t mistakenly advertise bogons downstream to your customers. Mistakes in the BGP configuration between you and your upstream transit provider could cause this to happen.
Note: Because the IPv6 address pool is so enormous but little of it has been allocated, it is easier to permit the allocated addresses explicitly and implicitly reject everything else. The route filters below are structured in this way. Note that in the route-map statement that refers to the bogons prefix list, the prefix list is actually called “NOT-BOGONS” since that is what it is composed of rather than the bogons themselves.
Note: The access-list defined earlier could be similarly structured to permit packets with source addresses only from allocated prefixes (not-bogons) and deny everything else.
Also, your route maps will likely include other more-specific policy statements based on your routing policy. Below is just an example of the martian and bogon portion.
router bgp (YOUR BGP ASN)
neighbor (YOUR NEIGHBOR’S PEERING IP ADDRESS) route-map ACCEPT-ROUTES in
!
!
route-map ACCEPT-ROUTES deny 10
match ip address prefix-list MARTIANS
!
route-map ACCEPT-ROUTES permit 20
match ip address prefix-list NOT-BOGONS
!
!
!
! FIRST THE MARTIANS
!
ipv6 prefix-list MARTIANS description MARTIAN PREFIX-LIST
ipv6 prefix-list MARTIANS seq 10 permit ::/0 le 128
ipv6 prefix-list MARTIANS seq 20 permit ::/96 le 128
ipv6 prefix-list MARTIANS seq 30 permit ::/128
ipv6 prefix-list MARTIANS seq 40 permit ::1/128 le 128
ipv6 prefix-list MARTIANS seq 50 permit ::ffff:0000:0000/96 le 96
ipv6 prefix-list MARTIANS seq 60 permit ::df00:0000/100 le 100
ipv6 prefix-list MARTIANS seq 70 permit ::7f00:0000/104 le 104
ipv6 prefix-list MARTIANS seq 80 permit ::0000:0000/104 le 04
ipv6 prefix-list MARTIANS seq 90 permit ::ff00:0000/104 le 104
ipv6 prefix-list MARTIANS seq 100 permit 0000::/8 le 128 le 128
ipv6 prefix-list MARTIANS seq 110 permit 0200::/7 le 128 le 128
ipv6 prefix-list MARTIANS seq 120 permit 3ffe::/16 le 128 le 128
ipv6 prefix-list MARTIANS seq 130 permit 2001:db8::/32 le 128
ipv6 prefix-list MARTIANS seq 140 permit 2002:e000::/20 le 20
ipv6 prefix-list MARTIANS seq 150 permit 2002:7f00::/24 le 24
ipv6 prefix-list MARTIANS seq 160 permit 2002:0000::/24 le 24
ipv6 prefix-list MARTIANS seq 170 permit 2002:ff00::/24 le 24
ipv6 prefix-list MARTIANS seq 180 permit 2002:0a00::/24 le 24
ipv6 prefix-list MARTIANS seq 190 permit 2002:ac10::/28 le 28
ipv6 prefix-list MARTIANS seq 200 permit 2002:c0a8::/32 le 32
ipv6 prefix-list MARTIANS seq 210 permit fc00::/7 le 128
ipv6 prefix-list MARTIANS seq 220 permit fe80::/10 le 128
ipv6 prefix-list MARTIANS seq 230 permit fec0::/10 le 128
ipv6 prefix-list MARTIANS seq 240 permit ff00::/8 le 128
!
!
! NEXT, THE ALLOCATED PREFIXES OR “NOT-BOGONS”
!
ipv6 prefix-list NOT-BOGONS description PREFIX-LIST OF ALLOCATED IPv6 PREFIXES
!
! NOTE: THE NEXT PREFIX IS INCLUDED IN THE MARTIAN LIST BUT IS
! REPEATED HERE IN THE EVENT THAT YOU WANT TO USE EITHER MARTIAN
! OR BOGON FILTERS INDEPENDENTLY. IF YOU COMBINE THEM INTO ONE
! FILTER YOU CAN OMIT THE NEXT LINE.
!
ipv6 prefix-list NOT-BOGONS deny 2001:0DB8::/32 le 128
!
! NOTE: PER THE HOGG / VYNCKE BOOK, IT IS BEST PRACTICE TO HERE INCLUDE YOUR
! OWN IPv6 ALLOCATIONS SO THAT YOU DON’T ACCEPT THEM FROM A NEIGHBOR IF THEY
! SHOULD MISTAKENLY ADVERTISE THEM TO YOU.
!
ipv6 prefix-list NOT-BOGONS permit 2001:0000::/32
ipv6 prefix-list NOT-BOGONS permit 2001:0200::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0400::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0600::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0800::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0A00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0C00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:0E00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1200::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1400::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1600::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1800::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1A00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:1C00::/22 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:2000::/20 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:3000::/21 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:3800::/22 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4000::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4200::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4400::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4600::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4800::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4A00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:4C00::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:5000::/20 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:8000::/19 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:A000::/20 le 64
ipv6 prefix-list NOT-BOGONS permit 2001:B000::/20 le 64
ipv6 prefix-list NOT-BOGONS permit 2002:0000::/16 le 64
ipv6 prefix-list NOT-BOGONS permit 2003:0000::/18 le 64
ipv6 prefix-list NOT-BOGONS permit 2400:0000::/12 le 64
ipv6 prefix-list NOT-BOGONS permit 2600:0000::/12 le 64
ipv6 prefix-list NOT-BOGONS permit 2610:0000::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2620:0000::/23 le 64
ipv6 prefix-list NOT-BOGONS permit 2800:0000::/12 le 64
ipv6 prefix-list NOT-BOGONS permit 2A00:0000::/12 le 64
ipv6 prefix-list NOT-BOGONS permit 2C00:0000::/12 le 64
The martian and bogon prefix lists are kept separate in this example since the first list – the martians – are denied in the first route-map statement, while the second list – prefixes that are not bogons – are permitted. Of course, you could first permit the NOT-BOGONS prefix list then let the implicit deny-all at the end reject the martians, but it may be good practice to stay cognizant of invalid routes and explicitly deny them. This is personal preference, however.
Juniper Access-list and BGP route filters
A similar BGP route-filter for Juniper routers would be as follows:
policy-options {
policy-statement IPv6-MARTIAN-BOGON-ROUTE-FILTER {
term MARTIANS {
from {
route-filter ::/0 orlonger;
route-filter ::/96 orlonger;
route-filter ::/128 orlonger;
route-filter ::1/128 orlonger;
route-filter ::ffff:0000:0000/96 orlonger;
route-filter ::df00:0000/100 orlonger;
route-filter ::7f00:0000/104 orlonger;
route-filter::0000:0000/104 orlonger;
route-filter ::ff00:0000/104 orlonger;
route-filter 0000::/8 prefix-length-range /8-/64;
route-filter 0200::/7 prefix-length-range /7-/64;
route-filter 3ffe::/16 prefix-length-range /16-/64;
route-filter 2002:e000::/20 prefix-length-range /20-/64;
route-filter 2002:7f00::/24 prefix-length-range /24-/64;
route-filter 2002:0000::/24 prefix-length-range /24-/64;
route-filter 2002:ff00::/24 prefix-length-range /24-/64;
route-filter 2002:ff00::/24 prefix-length-range /24-/64;
route-filter 2002:0a00::/24 prefix-length-range /24-/64;
route-filter 2002:ac10::/28 prefix-length-range /28-/64;
route-filter 2002:c0a8::/32 prefix-length-range /32-/64;
route-filter 0000::/8 prefix-length-range /8-/64;
route-filter 0200::/7 prefix-length-range /7-/64;
route-filter 3ffe::/16 prefix-length-range /16-/64;
route-filter 2001:db8::/32 prefix-length-range /32-/64;
route-filter fc00::/7 prefix-length-range /7-/64;
route-filter fe80::/10 prefix-length-range /10-/64;
route-filter fec0::/10 prefix-length-range /10-/64;
route-filter ff00::/8 prefix-length-range /8-/64;
}
then reject;
}
term BOGONS {
from {
route-filter 2001:0DB8::/32 orlonger reject;
route-filter 2001:0000::/32 exact;
route-filter 2001:0200::/23 prefix-length-range /23-/64;
route-filter 2001:0400::/23 prefix-length-range /23-/64;
route-filter 2001:0600::/23 prefix-length-range /23-/64;
route-filter 2001:0800::/23 prefix-length-range /23-/64;
route-filter 2001:0A00::/23 prefix-length-range /23-/64;
route-filter 2001:0C00::/23 prefix-length-range /23-/64;
route-filter 2001:0E00::/23 prefix-length-range /23-/64;
route-filter 2001:1200::/23 prefix-length-range /23-/64;
route-filter 2001:1400::/23 prefix-length-range /23-/64;
route-filter 2001:1600::/23 prefix-length-range /23-/64;
route-filter 2001:1800::/23 prefix-length-range /23-/64;
route-filter 2001:1A00::/23 prefix-length-range /23-/64;
route-filter 2001:1C00::/22 prefix-length-range /22-/64;
route-filter 2001:2000::/20 prefix-length-range /20-/64;
route-filter 2001:3000::/21 prefix-length-range /21-/64;
route-filter 2001:3800::/22 prefix-length-range /22-/64;
route-filter 2001:4000::/23 prefix-length-range /23-/64;
route-filter 2001:4200::/23 prefix-length-range /23-/64;
route-filter 2001:4400::/23 prefix-length-range /23-/64;
route-filter 2001:4600::/23 prefix-length-range /23-/64;
route-filter 2001:4800::/23 prefix-length-range /23-/64;
route-filter 2001:4A00::/23 prefix-length-range /23-/64;
route-filter 2001:4C00::/23 prefix-length-range /23-/64;
route-filter 2001:5000::/20 prefix-length-range /20-/64;
route-filter 2001:8000::/19 prefix-length-range /19-/64;
route-filter 2001:A000::/20 prefix-length-range /20-/64;
route-filter 2001:B000::/20 prefix-length-range /20-/64;
route-filter 2002:0000::/16 prefix-length-range /16-/64;
route-filter 2003:0000::/18 prefix-length-range /18-/64;
route-filter 2400:0000::/12 prefix-length-range /12-/64;
route-filter 2600:0000::/12 prefix-length-range /12-/64;
route-filter 2610:0000::/23 prefix-length-range /23-/64;
route-filter 2620:0000::/23 prefix-length-range /23-/64;
route-filter 2800:0000::/12 prefix-length-range /12-/64;
route-filter 2A00:0000::/12 prefix-length-range /12-/64;
route-filter 2C00:0000::/12 prefix-length-range /12-/64;
}
then accept;
}
then reject;
}
}
Questions
Do the martian and bogon lists and filters in this post look accurate and up-to-date?
Can anyone improve the martian and bogon lists and filters shown in this post?
If someone out there has access to Juniper hardware, can you translate the Cisco access-list code shown here to valid JUNOS filter code, and check the route filter? Developing those in Excel is probably error-prone. And please check the Juniper BGP route filter for the same reason. Thanks!
Filed under: BGP, General, Routing Protocols, Security | Tagged: IPv6, Network Security, Networking | 10 Comments »
Millennia Systems
6session 