Re: Robustness principle and multicast source address

Hi Jen,

On Thu, 15 Nov 2018 at 17:32, Jen Linkova <furry13@gmail.com> wrote:
>
> The section 2.7 of RFC4921 says:
>
> Multicast addresses must not be used as source addresses in IPv6
> packets or appear in any Routing header.
>
> (https://tools.ietf.org/html/rfc4291#section-2.7)
>
> Does it mean that any packets with multicast source MUST be dropped by
> the receiver? Or shall Postel's Law still apply?
>

I'd be saying MUST, and silently.

A multicast source address fundamentally doesn't really make sense. A
multicast address represents a group of addresses, so a multicast
address in a single packet's source address field suggests the single
packet somehow has multiple sources, which suggests multiple devices
built parts of the single packet. IPv6 doesn't support multi-source
multi-part single packets! (Has any protocol?)

Source addresses are also commonly used as destination addresses for
responses, so a multicast source address where a unicast address
should be can mean a link layer flooded multicast instead of unicast
response. (For IPv4, RFC1122 specifies that received, link-layer
broadcast IPv4 packets that do not have an IPv4 broadcast or multicast
address should be silently ignored, mitigating this scenario.)

With old enough Ethernet switch firmware that supports translational
bridging, the I/G bit in the Ethernet source address field actually
means there is a source route information field, following the
destination address
(https://www.cisco.com/c/en/us/support/docs/ibm-technologies/token-ring/24501-trb-rif.html).
If there isn't, the switch might drop the packet, which some server
colleagues of mine found out when they tried to use the Linux IPtables
ClusterIP extension, as it tries to use "multicast" source Ethernet
addresses.

> In particular (practical question...): shall an NA packet from the
> multicast source be dropped (if one applies the NA validation rules
> from https://tools.ietf.org/html/rfc4861#section-7.1.2 such packet
> would be still a valid advertisement...)
>

This draft did specify some more stringent NA source address
validation, as well as other validation e.g. Source Link Layer Address
option does not contain a multicast link layer address.

"Security Assessment of Neighbor Discovery (ND) for IPv6"
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-nd-security-00

Regards,
Mark.

> --
> SY, Jen Linkova aka Furry
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------