Re: Robustness principle and multicast source address

[Alexandre Petrescu <[e-mail]>]

Le 20/11/2018 à 02:45, Mark Smith a écrit :
> Hi Jen,
>
> On Thu, 15 Nov 2018 at 17:32, Jen Linkova <[e-mail]> 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?)


Not yet, but why not.

This idea of a packet coming from we dont know where and sent to many 
others could be useful.

I routinely look at packets without caring where they come from.

Many routers forward packets without carying where they come from.

So instead of being useless, maybe call it useless.  That could be a 
specific address, like "usel:ess::"

In vehicular networking the broadcast of PoI has this kind of absence of 
precision: when one receives a PoI one just learns that in that area 
(dont know precisely where, no src) there is an important point like a 
gas station.

Alex

>
> 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
>> [e-mail]
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>