[j-nsp] ipv6 firewall filter matching MLD

Zenon Mousmoulas zmousm at admin.grnet.gr
Fri Jun 10 03:53:32 EDT 2011


Hi,

I want to match MLD packets in an IPv6 firewall filter. The filter is applied ingress on a loopback interface.

Quoting from RFC 3810:

   MLDv2 is a sub-protocol of ICMPv6, that is, MLDv2 message types are a
   subset of ICMPv6 messages, and MLDv2 messages are identified in IPv6
   packets by a preceding Next Header value of 58.  All MLDv2 messages
   described in this document MUST be sent with a link-local IPv6 Source
   Address, an IPv6 Hop Limit of 1, and an IPv6 Router Alert option
   [RFC2711] in a Hop-by-Hop Options header.  (The Router Alert option
   is necessary to cause routers to examine MLDv2 messages sent to IPv6
   multicast addresses in which the routers themselves have no
   interest.)  MLDv2 Reports can be sent with the source address set to
   the unspecified address [RFC3513], if a valid link-local IPv6 source
   address has not been acquired yet for the sending interface.  (See
   section 5.2.13. for details.)


I've tried to match it using such filter conditions:

from {
    next-header icmpv6;
    icmp-type [ membership-report membership-termination membership-query ];
}

from {
    next-header icmpv6;
    icmp-type [ 130 131 132 143 ];
}

or even just match on icmpv6:

from {
    next-header icmpv6;
}

but none of this matches MLD packets. The only thing that works is matching on the hop-by-hop options header:

from {
    next-header hop-by-hop;
}

but you can not match on both this header and the next header, i.e. ICMPv6:

from {
    next-header [ hop-by-hop icmpv6 ];
}

So it seems that JUNOS is not capable of matching a nested next-header but rather only identifies the packet from the first header, even if it is a special header that is bound to be followed by a protocol header, as in the case of hop-by-hop options.

This is verified by looking at the firewall log. It shows that packets which are most certainly carrying MLD payload (judging from the MLDv2 Listener Report destination address ff02::16) are identified as protocol 0 (H-B-H) rather than ICMPv6.

Time      Filter    Action Interface     Protocol        Src Addr                         Dest Addr
16:25:11  pfe       A      ge-0/0/8.400  ICMPv6          fe80::a4a9:1ddc:484:87e6         ff02::1:ff38:e808
16:24:18  pfe       A      ge-0/0/8.400  0                     fe80::a4a9:1ddc:484:87e6         ff02::16
16:24:17  pfe       A      ge-0/0/8.400  0                     fe80::9571:e508:f653:e2d5        ff02::16
16:24:17  pfe       A      ge-0/0/8.400  0                     fe80::a4a9:1ddc:484:87e6         ff02::16
16:24:16  pfe       A      ge-0/0/8.400  0                     fe80::607d:b982:9750:bdc4       ff02::16


Since H-B-H is mainly used to carry the Router Alert option, which is required also e.g. for RSVP, is it right to assume that JUNOS firewall filter will not match any such protocols?

Am I missing something? Any ideas?

This has been tested on 9.6R3.8 and 10.4R4.5 (multiple platforms, but that is irrelevant).

Thanks,
Zenon Mousmoulas



More information about the juniper-nsp mailing list