IPv6: Don’t Forget About Your Switches!

When preparing a network for IPv6, I often hear network administrators say that their switches are agnostic and that there is no need to worry about them.  Not so fast.

Yes, LAN switches function mainly at layer 2 by forwarding Ethernet frames regardless of whether the packet inside is IPv4 or IPv6 (or even something else!)  However, there are some functions on a switch that operate at layer 3 or higher.  They include:

  • Dynamic ARP Inspection (DAI)
  • DHCP Snooping
  • Multicast Listener Discovery (MLD) Snooping (equivalent of IGMP Snooping)
  • Quality of Service (QoS) marking for Differentiated Services treatment
  • Access Lists (e.g., VLAN or regular ACLs).

These features were developed to push certain functions to the access layer where a network is often the most vulnerable or where it provides the closest point to the end user and thus the best place to apply certain logic and policies to application traffic.  To function properly, they require layer 3 or upper layer information.  They inspect the packet header or payload inside the Ethernet frame.  These features may be necessary to translate your IPv4 network functionality to IPv6.  While these features do not necessarily qualify the device as a layer 3 “switch” or an IPv6 router per se, they do act on more than just the Ethernet frame.

There is also the IP management interface on the switch, although I expect most networks will be dual stacked for the foreseeable future and will not abandon their IPv4 management interfaces, at least not until they can get their management systems to catch up.

The aforementioned features may not be things you are doing now, but you never know when you will.  Security requirements and hardening guidelines are recommending things like DAI, DHCP Snooping and ACLs at the access layer.  The more streaming video gets moved to IP networks, the more the need for multicast, and MLD Snooping is necessary to improve performance.  Finally, the continued convergence of voice, video and other rich media and interactive applications to IP networks is furthering the need for QoS, and it is always best to mark traffic as close to the edge as possible.

So don’t forget about your switches.  A thorough IPv6 readiness assessment must consider the entire network, end to end, and everything in between.

Note: The previous list was off the top of my head and by no means all inclusive.  I would welcome any comments that would help to compile a complete list.

IPv6 Martian and Bogon Filters

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.



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” 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:            Default (can be advertised in BGP if desired)            Self identification           Broadcast           Private Networks (RFC 1918)          Loopback  IANA Reserved (RFC 3330) Private Networks (RFC 1918) Local Reserved (RFC 3330)  IANA Reserved (RFC 3330)  Test-Net (RFC 3330) Networks (RFC 1918) Network Interconnect Device Benchmark Testing     Special Use Networks (RFC 3330)          Multicast          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: /96 IPv4-mapped addresses
:: /100 Compatible address (IPv4 format)
:: /104 Compatible address (IPv4 format)
:: /104 Compatible address (IPv4 format)
:: /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 network)
2002:ac10:: /28 Invalid 6to4 packets (IPv4 private network)
2002:c0a8:: /32 Invalid 6to4 packets (IPv4 private 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” 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 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:


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:




 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




 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




 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)




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






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












ipv6 prefix-list NOT-BOGONS  deny 2001:0DB8::/32 le 128






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;





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!