Re: Robustness principle and multicast source address

[Alexandre Petrescu <[e-mail]>]

Le 30/11/2018 à 13:37, Mark Smith a écrit :
> 
> 
> On Fri., 30 Nov. 2018, 22:05 Alexandre Petrescu 
> <[e-mail] <mailto:[e-mail]> wrote:
> 
> 
>     Le 20/11/2018 à 02:45, Mark Smith a écrit :
>      > Hi Jen,
>      >
>      > On Thu, 15 Nov 2018 at 17:32, Jen Linkova <[e-mail]
>     <mailto:[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.
> 
> 
> So the above is about a multi-source, multi-part packet, that is at some 
> point and at some place combined into a single packet, rather than a 
> single packet originated by an unimportant and unspecified source.
> 
> (For unidirectional communication, the source address is optional, in 
> the sense that because there will be no reply, the actual source 
> device's address is not essential, although it may 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::"
> 
> 
> 
> ::0, the unspecified address, is the source address you're looking for.

Sounds better indeed.

But it does not map in a corresponding MAC address :-(

Alex

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