Hi Christian,
Discontinuous mask for IPv6 was supported in IOS-XR in release 5.2.2.
You can refer below link for details:
[https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620](https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp4831598620)
Regards,
Aseem
><i> On Wed, 19 Dec 2018 at 02:55, Philip Loenneker
</i>><i> <[Philip.Loenneker at tasmanet.com.au](https://mailman.nanog.org/mailman/listinfo/nanog)> wrote:
</i>> ><i> > I had a heck of a time a few years back trying to troubleshoot an issue
</i>><i> where an upstream provider had an ACL with an incorrect mask along the
</i>><i> lines of 255.252.255.0. That was really interesting to talk about once we
</i>><i> discovered it, though it caused some loss of hair beforehand...
</i>> ><i> Juniper originally didn't support them even in ACL use-case but were
</i>><i> forced to add later due to customer demand, so people do have
</i>><i> use-cases for them. If we'd still support them in forwarding, I'm sure
</i>><i> someone would come up with solution which depends on it. I am not
</i>><i> advocating we should, I'll rather take my extra PPS out of the HW.
</i>> ><i> However there is one quite interesting use-case for discontinuous mask
</i>><i> in ACL. If you have, like you should have, specific block for customer
</i>><i> linknetworks, you can in iACL drop all packets to your side of the
</i>><i> links while still allowing packets to customer side of the links,
</i>><i> making attack surface against your network minimal.
</i>
And unfortunately is still not supported by IOS-XR for IPv6, which could
mean not having a scaleable way on your edge to protect your internal
network.