Re: Robustness principle and multicast source address

[Mark Smith <[e-mail]>]

On Sat, 1 Dec 2018 at 02:08, Alexandre Petrescu
<[e-mail]> wrote:
>
>
>
> 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 :-(
>

Don't understand the problem you're trying to solve.

If you want an IPv6 source address that maps to a unique MAC address,
you can't use an unspecified / not stated source address.

Regards,
Mark.


> 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
> >     --------------------------------------------------------------------
> >