Subject: Re: Robustness principle and multicast source address

From: Ola Thoresen <[email-masked]>
Date: Mon, 3 Dec 2018 11:00:44 +0100

On 01.12.2018 04:43, Mark Smith wrote:

> Don't understand the use case well enough.
>

I am not saying I have a real use for this - at least not now. It was 
just an example of a situation where it CAN make sense to send a packet 
with a multicast _source_ address.  I am not going to create a new 
protocol here and now, but let's consider the following.

Most of the auto-configure protocols (upnp, bonjour) rely on the clients 
asking for a service when they need it.  Unsolicited advertisements of 
services is not very common, but we have at least one well known 
protocol that is announcing the presence of a certain service - the 
regular unsolicited sending of Router Advertisements. The routers are 
telling the network that they exist (in addition to hosts sending RDs if 
they need to).

This might, or might not, be a good idea.  But slightly related to the 
discussion about the "no ipv4"-flag we have had going on for some time, 
it _could_ in some situations be smart if the provider of a service 
announced that it was there, so the clients could drop asking for it if 
they believed it was not present in the network.  Depending of course on 
whether the noise from the "service provider" (the unsolicited 
announcements) would cause more traffic than all the clients 
continuously checking if the service is present or not.

A quick and dirty example (note that this is NOT a full spec of a new 
protocol, merely a simple example of something that _could_ be done):

- Set up a recursive DNS-server that listens on a multicast address
- Have the DNS-server send an unsolicited announcement of the service 
FROM the service-multicast address TO the "all hosts" address
- Clients can then chose to use the multicast-address instead of unicast 
to reach the recursive DNS server in that network (at least for UDP).

- If no DNS-servers are announcing that they exists (e.g. nobody is 
sending packets with that source address) the clients know that they 
don't need to send any requests to that MC-group as it is highly 
unlikely that anyone is going to respond.

This would make even more sense if the vendors started to implement the 
different MC-scopes properly (e.g SLPv2).  Today, way to many protocols 
are using the link-local scope, while they _should_ (in my mind) use the 
site-local or admin-local scopes to ensure they can be used across 
different network segments, but that is another discussion...

---

From: Mark Smith <[email-masked]>
Date: Tue, 4 Dec 2018 10:38:51 +1100

> telling the network that they exist (in addition to hosts sending RDs if

It's been quite a while since I looked into them, however I'm pretty
sure SSDP and mDNS are using periodic announcements. I have both
operating on my home LAN, and see multicast traffic from those
protocols quite often even when I'm not using the devices/services
announced using them.

> to reach the recursive DNS server in that network (at least for UDP).

So in your scenario, you only have a single DNS server? What is the
point of using a "multiple device" address in the source address field
when there is only one device that clients can talk to? A unicast
address identifies a unique device, and in your scenario you have a
single unique DNS server.

What problem would you be trying to solve that makes you want to use a
"multiple source" or ambiguous source address/identifier for a single
DNS resolver?

Your use case sounds like it might be one for anycast rather than
multicast. RFC 7094, "Architectural Considerations of IP Anycast",

https://tools.ietf.org/html/rfc7094

 describes quite a lot of examples of use of anycast for services,
including DNS, and one might match your goal.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 4 Dec 2018 11:33:38 +0100

Le 04/12/2018 à 00:38, Mark Smith a écrit :
[...]
> What problem would you be trying to solve that makes you want to use
> a "multiple source" or ambiguous source address/identifier for a
> single DNS resolver?

It is exploratory.

There are however use-cases where neither the unicast src-dst nor the 
unicast src multicast dst (typical IP) make much sense.

We need to see how IP could be made to work on these cases.

Multicast-to-multicast is an exploratory concept to which maybe IP 
people will not agree.

Broadcast-to-broadcast is a concept seen often in the same settings that 
I call above 'use-case'.  Some people may call this 
broadcast-to-broadcast an error of implementation, others not.

Discussing about it is beneficial.

One side effect is that it raises the question to IEEE whether 
ff:ff:ff:ff:ff:ff (either src or dst) should still be used or rather 
replaced totally by 33::1.

Because in 802.11 OCB mode, the ESSID name is replaced by this 
'ff:...ff', yet when we put IPv6 on it this latter does not accept 
ff:...ff and prefers 33::1.  But the preference of IPv6 is in dst 
addresses not in BSSID.  IPv6 does not care about BSSID.  So one may 
wonder whether IPv6 accepts ff:...ff in the BSSID, without accepting it 
in src/dst.

This answer to this question (does IPv6 accept ff:...ff in BSSID, or 
rather prefers 33::1 in it) is a subject to a new Internet Draft that 
should be called "IPv6 over WiFi".

It is exploratory in purpose.

Alex

> Regards, Mark.
>> - If no DNS-servers are announcing that they exists (e.g. nobody
>> is sending packets with that source address) the clients know that
>> they don't need to send any requests to that MC-group as it is
>> highly unlikely that anyone is going to respond.
>> 
> 
> 
> 
>> 
>> 
>> This would make even more sense if the vendors started to implement
>> the different MC-scopes properly (e.g SLPv2).  Today, way to many
>> protocols are using the link-local scope, while they _should_ (in
>> my mind) use the site-local or admin-local scopes to ensure they
>> can be used across different network segments, but that is another
>> discussion...
>> 
>> 
> 
> -------------------------------------------------------------------- 
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6 
> --------------------------------------------------------------------
>

---

From: Christian Huitema <[email-masked]>
Date: Tue, 4 Dec 2018 07:57:42 -0800

> On Dec 4, 2018, at 2:33 AM, Alexandre Petrescu <[email-masked]> wrote:
> 
> Multicast-to-multicast is an exploratory concept to which maybe IP people will not agree.

Actually, the IETF has a pretty good experience with many to many protocols, starting with a variety of protocols running on the MBONE. RTP and RTSP, for example.

These protocols are many to many at the application layer, but the transmissions are 1 to many. This provides for a good equilibrium. The network can identify the source and use it to compute paths or send back control messages. The application knows that messages shall be sent to the group, not to the individual participant.

But you never need to use a multicast address as a source address, because this generates many failure points and creates a vulnerability to DOS attacks.

-- Christian Huitema

---

From: Simon Hobson <[email-masked]>
Date: Tue, 4 Dec 2018 19:25:53 +0000

Mark Smith <[email-masked]> wrote:

> sure SSDP and mDNS are using periodic announcements.

Correct, they do.
IIRC it's a sort of hybrid arrangement - there are periodic announcements, but also a host can broadcast a request for specific service types (other devices will see the resulting service notification broadcasts as well).
For many uses, hosts can maintain a list of services simply by passive listening - and so the cache provides a rapid response to a user action (eg opening a network browser to find a printer). But a host entering such a state (eg user looking for printers) can ask suitable nodes to respond which should "wake up" any nodes which for whatever reason weren't already in the cache.

Upside is that it's great for users - plug in a printer, open UI to pick a printer, printer appears and can be used. User doesn't need to know anything about IP addresses, it works even in an isolated network with no address provisioning (LL addresses used).
Downside is that it's "a bit chatty" - on a large network there can be many broadcasts, and the packets themselves can be quite large. This is one of the main reasons for the "can we have a flag to 'kill' IPv4 ?" thread that went on so long.

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Dec 2018 07:20:57 +1100

Detail not relevant here. You're treating this as though this is a
forum of beginners, not a protocol development group.
On Wed, 5 Dec 2018 at 06:26, Simon Hobson <[email-masked]> wrote:
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Mark Smith <[email-masked]>
Date: Wed, 5 Dec 2018 09:49:47 +1100

> Multicast-to-multicast is an exploratory concept to which maybe IP

What I don't understand is the specific problem for which an ambiguous
multicast source address would be the best solution.

If source ambiguity is the desired property, then the unspecified ::0
address would sound to me like the better option, because it is a unicast
address, meaning that it won't have the possible issues that an unexpected
multicast source address does.

> broadcast-to-broadcast an error of implementation, others not.

On a link only directly attaching two devices, then unique link layer
addressing isn't required, because implicitly, the identity of all packet
sources and destinations is and can only be the other device on the link.

For example, as a protocol, HDLC supports more than two devices on a link,
and has an address field in the header, however when HDLC is used for PPP
framing per RFC1662, the (single) address field is set to the HDLC
broadcast value.

On an Ethernet type link that only and will only ever have two devices,
then the src and dst addresses could be set to something ambiguous like the
broadcast address (noting that that currently a broadcast source address
looks to violate IEEE specs).

However, in that scenario, I still think it would be better to continue to
use the two devices' unicast addresses (limiting broadcast/multicast addr
to dest addr) because it is conventional and expected.

(An idea I had a quite a while back to eke out some more bandwidth on a
true physical point to point Ethernet link would be to switch both of the
devices' interfaces into promiscuous mode, and then put something else in
the now available 12 octets of each frames' source and destination address
fields e.g. MPLS label stack, similar to how MPLS uses the frame relay DLCI
and ATM VPI/VCI fields. IEEE violation, and debatable value of the
throughput increase.)

Regards,
Mark.

---

From: Jen Linkova <[email-masked]>
Date: Wed, 5 Dec 2018 14:07:11 +1100

Sorry for being silent, I've spent some time trying to convince
engineers of one routing vendor that packets with multicast source
should be discarded..

On Tue, Nov 20, 2018 at 12:45 PM Mark Smith <[email-masked]> 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.

I start thinking that "MUST" SHOULD be written down more clearly.
Apparently RFC4921 could be read (as I suspected) as "a host is not
expected to send such packets...if it does...well, we forward them"
and there is no clear requirements for IPv6 routers (btw for IPv4
there is one, https://tools.ietf.org/html/rfc1812#section-5.3.7 says
'SHOULD NOT").

> A multicast source address fundamentally doesn't really make sense.

I agree. My question now: shall we right it down or is it so obvious
that only some TAC engineers would disagree? ;)

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

Well, the link layer was not multicast in my case. It was just NA
source address being a solicited node multicast address ;)

--
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Wed, 5 Dec 2018 14:25:03 +1100

On Fri, Nov 30, 2018 at 10:05 PM Alexandre Petrescu
<[email-masked]> wrote:
> Le 15/11/2018 à 07:31, Jen Linkova a écrit :
>
> Jen,
> There is no such restrictions for link-layer addresses like IEEE MAC addresses.
>
> Since there is a very tight relationship between IP and MAC, whose rule should prevail?  IP's or MAC's?

I'm not sure I understand - most likely because I know almost nothing
about WSMP etc..
Could you provide an example when such a very tight relationship
between IP and MAC would cause a conflict?

> I am asking because I was just been pointed by a fellow IETFer (to whom I thank very much) to a link-layer message send from a broadcast address to another broadcast address.  It's been captured between cars and RSUs, probably in America.  URL available upon request.

Is it an IPv6 packet?

---

From: Ola Thoresen <[email-masked]>
Date: Wed, 5 Dec 2018 09:55:25 +0100

On 04.12.2018 23:49, Mark Smith wrote:

>
>
> On Tue., 4 Dec. 2018, 21:34 Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]> wrote:
>
>
>

There could be one, there could be multiple.  "DNS" is not important 
here.  You can replace that with some kind of "syslog over multicast" or 
some other duplicating storage solutions or something completely new 
service where multicast makes sense.  The idea was just that by using a 
multicast source address for "reverse service discovery", the "service 
provider" can just send an unsolicited icmp message with the 
service-address (multicast address) as _source_ to inform all relevant 
hosts on the network that the service is available. Nothing more.

If the hosts have support for this service, they will understand that it 
is up and running just by receiving this packet, and can start using 
it.  Other service discovery methods will either require each host to 
ASK the network if the service is present, or will require the hosts to 
look for e.g. specific SSDP-messages to be notified of the presence of a 
service.

Rgds.

Ola (T)

---

From: Brian Haberman <[email-masked]>
Date: Wed, 5 Dec 2018 10:59:57 -0500

Hi Jen,

> engineers of one routing vendor that packets with multicast source

Did you happen to mention BCP 38 to them?

Regards,
Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 17:37:37 +0100

Le 05/12/2018 à 04:25, Jen Linkova a écrit :
> I'm not sure I understand - most likely because I know almost
> nothing about WSMP etc.. Could you provide an example when such a
> very tight relationship between IP and MAC would cause a conflict?

I think the conflict is in IPv6 ignoring ff:..:ff MAC broadcast address 
and vice-versa.

A MAC multicast address (33:...) is routinely mapped back and forth to 
an IPv6 multicast address.

A MAC broadcast address (ff:..:ff) is never mapped neither back nor 
forth to an IPv6 address.

802.11 still uses MAC broadcast addresses extensively (e.g. WSMP).

IPv6 over 802.11 specification does not exist.  What IETF specifies is 
IPv6 over Ethernet.

802.11 headers are unknown at IETF.  What IETF knows is 'Ethernet II' 
headers.

802.11 headers contain 4 addresses: Receiver address, Transmitter 
address, Destination, Source and a BSS Id field.  Ethernet II headers 
contain just Source and Destination MAC addresses.

802.11 headers (when 802.11 is OCB mode - Outside de Context of a BSS 
Id, the contrary of BSS aka Infrastructure, and contrary to 'ad-hoc' 
mode) contain ff:...:ff in many of the 4 fields, some times all.  The 
BSS Id field is always ff:..:ff if in OCB mode.

Let's put IPv6 on 802.11 in OCB mode.  In this mode, as explained, often 
there are ff:..:ff addresses in many of the 802.11 fields.

Into what IP address to map the ff:...:ff present in some of the fields 
of 802.11?

If there were a spec of IPv6-over-802.11 then I would look for help in 
that spec.

Should IPv6 ignore that often there are ff:..:ff address in 802.11 
headers and, in particular, in OCB mode?

Should IEEE stop using ff:...:ff.

>> I am asking because I was just been pointed by a fellow IETFer (to
>> whom I thank very much) to a link-layer message send from a
>> broadcast address to another broadcast address.  It's been captured
>> between cars and RSUs, probably in America.  URL available upon
>> request.
> 
> Is it an IPv6 packet?

No.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 5 Dec 2018 17:38:52 +0100

> that only some TAC engineers would disagree? ;)

Depends how it's written :-)

What is TAC in TAC engineer?

Alex

---

From: Christian Huitema <[email-masked]>
Date: Wed, 5 Dec 2018 08:48:29 -0800

> On Dec 5, 2018, at 12:55 AM, Ola Thoresen <[email-masked]> wrote:
> 
> The idea was just that by using a multicast source address for "reverse service discovery", the "service provider" can just send an unsolicited icmp message with the service-address (multicast address) as _source_ to inform all relevant hosts on the network that the service is available.

But MDNS already does that. The client sends a multicast query to all nodes; the server sends a multicast response; all nodes can cache query and response. But MDNS never uses a multicast address ss a source address. It always uses an unicast address of the sending node.

The same design could be applied in your ICMP scenario. Define a specific ICMP message, and then define how replies to that message are sent using multicast. And explain at thesame time  how you deal with multicast storms, and how you prevent DOS attacks.

-- Christian Huitema

---

From: Dennis Ferguson <[email-masked]>
Date: Wed, 5 Dec 2018 12:53:54 -0800

> On Dec 4, 2018, at 07:57, Christian Huitema <[email-masked]> wrote:
> 

I think it is actually even stricter than this. If you want a multicast to be routed you are probably precluded from using a multicast source address.

To generalize, the problem multicast routing needs to deal with is to figure out where *not* to flood packets. Having two multicast routers forward copies of the same packet onto the same link is sort of the multicast equivalent of a unicast forwarding loop. To avoid this requires that a forwarding router know where the source of the packet is located in the topology so it can figure out which outgoing interfaces are “downstream” from there and which aren’t. This means that multicasts are essentially forwarded based on the source address and that address is required to be a topologically unique unicast address.  I think packets with multicast or routed anycast source addresses lack the information needed to forward them properly.

This argument does not apply to link-local scoped multicasts of course, but it is probably bad practice to design protocols to preclude multicast forwarding when there isn’t a strong reason to do that.

Dennis Ferguson

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Dec 2018 12:52:03 +1100

> engineers of one routing vendor that packets with multicast source

So I think the RFC you can point the vendor support to is the default
address selection RFC6724, as it says that the unspecified and
multicast addresses are not to be used as source addresses,

"4.  Candidate Source Addresses"

...

" In any case, multicast addresses and the unspecified address MUST NOT
   be included in a candidate set."

So those packets shouldn't be sent, and therefore it would be quite
valid and robust for receivers to silently ignore them.

A security reason to ignore them is because they can be used to create
amplification attacks, when the destination address that should be a
unicast is a multicast.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 09:04:33 +0100

> multicast source address would be the best solution.

These are some problems of putting IPv6 I was confronted with recently:

- IoT devices sending their temperature value to common cloud server
   unnecessarily crowd the common link; a reverse IP multicast concept
   (many-to-single) could save bandwidth.

- single pdf document is signed by several parties ('petition')
   currently in a chained manner: the 2nd party wont sign if verifying
   the first fails; a real petition, or a multi-party contract, is signed
   by all simultaneously without intermediary verification.

- in cyclical broadcast and compute models (e.g. in car networks models,
   but there are other models) presence information is sent by each to
   all, and a same world view is subsequently
   derived by each, in a lockstep manner.  Unicast IP obviously does
   not fit; multicast IP needs rigidly formed groups: one could not send
   a multicast IP packet to a group whose formation depends on the
   receivers having already received that packet (so they could derive
   the group from that world view).
   In this problem, a multicast-to-multicast kind of solution could help:
   in a 1st step send from multicastaddress-to-multicastaddress to form
   the groups, and in a second step send from unicast-address-to-
   multicast group address in a traditional way.

> address would sound to me like the better option, because it is a 
> unicast address, meaning that it won't have the possible issues that an 
> unexpected multicast source address does.

The unspecified property of ::0 could indeed be a good idea.

For the IoT example above it would not help gain bandwidth, but it would 
be good to send temperature on UDP to server without specifying the src 
address (because server does not need to reply).

For the pdf signature problem: I dont know.

For the cyclical broadcast-and-compute models (car networks), the ::0 
could be both a source and a destination in some kind of solution.  Yet 
we dont know how to map ::0 to a MAC address.  This is absolutely 
necessary in an IPv6-over-foo document (foo is WiFi in OCB mode, or 
802.11-NGV more recently).

> addressing isn't required, because implicitly, the identity of all 
> packet sources and destinations is and can only be the other device on 
> the link.
> 
> For example, as a protocol, HDLC supports more than two devices on a 
> link, and has an address field in the header, however when HDLC is used 
> for PPP framing per RFC1662, the (single) address field is set to the 
> HDLC broadcast value.
> 
> then the src and dst addresses could be set to something ambiguous like 
> the broadcast address (noting that that currently a broadcast source 
> address looks to violate IEEE specs).
> 
> However, in that scenario, I still think it would be better to continue 
> to use the two devices' unicast addresses (limiting broadcast/multicast 
> addr to dest addr) because it is conventional and expected.
> 
> true physical point to point Ethernet link would be to switch both of 
> the devices' interfaces into promiscuous mode, and then put something 
> else in the now available 12 octets of each frames' source and 
> destination address fields e.g. MPLS label stack, similar to how MPLS 
> uses the frame relay DLCI and ATM VPI/VCI fields. IEEE violation, and 
> debatable value of the throughput increase.)

I have read it.

Alex

>      > IETF IPv6 working group mailing list [email-masked]
>     <mailto:[email-masked]> Administrative
>     [email-masked] <mailto:[email-masked]>

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Dec 2018 20:02:21 +1100

>    (many-to-single) could save bandwidth.

That's not a function you'll be doing at i.e. only the IPv6 layer.
You'll be accepting those packets and handing them up through the
transport layer to the application.

Use unicast or anycast to reach a local to the data sources
aggregation server, and then have that aggregate the data together,
and then it can unicast the now aggregated data, in packets newly
originated at the aggregation server, to somewhere else (the so called
"edge computing" model).

>    by all simultaneously without intermediary verification.

That's not a function you'll be doing at the IPv6 layer.

>    In this problem, a multicast-to-multicast kind of solution could help:

I don't understand what a "multicast-to-multicast kind of solution" really is.

All that has really been discussed here has been putting a multicast
address in the source address field.

All other conversation such as yours and others' examples talk about
this idea as though there is a well known and understood model of
"multicast-to-multicast" operation, and it is also clear why unicast
source/multicast destination either doesn't work or has unacceptable
limitations.

Is there such a model described somewhere? It seems you're are jumping
to the "it exists" stage, meaning that how it works is well described
and that it doesn't suffer from any fatal flaws (I think Dennis
Ferguson pointed out one), and then looking for uses for it.

I think it is better to try harder to use what exists before inventing
something new, because the trouble with new is that it is not well
known or tested, or even proven feasible in comparison to what already
exists and is already being commonly used.

> The unspecified property of ::0 could indeed be a good idea.

The question is, what is the harm in using the device's actual unicast
address as a source and then if the receiver doesn't care about it,
the receiver application ignores it (which is the default behaviour
when applications receive packets).

If may be a useful saving if it was possible to send packets that
didn't have a source address field at all, saving bandwidth, but that
doesn't exist in IPv6.

> address (because server does not need to reply).

So what if one of your 500 000 IoT devices fails, and starts sending a
flood of these UDP packets. How are you going to know which of the 500
000 to fix or replace? You'd have to disconnect or power on/off each
of them individually until the flood of UDP packets goes away to
identify which device is faulty.

Even if you don't need a source address for normal operation because
it is unidirectional communication, it is essential to be able to a
device from its emitted packets during troubleshooting when there is
more than say 5 to 10 devices.

> could be both a source and a destination in some kind of solution.

How can a packet be delivered to a, literally, unspecified destination?

How can a network know where to deliver a packet to if you don't tell
the network where the packet needs to be delivered to?

This is starting to sound quite nonsensical.

> Yet

If you let the source host automatically fill in its unicast address
as the packet source address, that problem goes away.

Regards,
Mark.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 11:02:08 +0100

> That's not a function you'll be doing at i.e. only the IPv6 layer.

Why not?

I can tell you why we need it at IP layer.

In general, I do agree that many things that look 'esoteric' to network 
layer are better adapted to app layer.  It is the case, e.g., putting 
the geographical coordinates: better in an app than at network layer.

But in IoT devices better have as little software as possible, maybe no 
app layer at all.  Ping could put the temperature in its payload.

And, in vehicular networks, one wants the 'broadcast' messages (sending 
from one to many) to happen maybe at a 20Hz frequency and be very short. 
  At app layer it would be too heavy, but the network layer could.  With 
IPv6 we dont know how to send 'broadcast' messages (sending from one to 
many).  With IPv4 we know how to (dont use link-layer multicast but use 
link-layer broadcast ff:...ff).

If you think you have a solution to that (how to use IPv6 to send from 
one to many in vehicular networks where groups are not formed) I would 
be very grateful to read.

> originated at the aggregation server, to somewhere else (the so called

But that (each sensor unicasts temperature to an edge computer which 
then aggregates towards a cloud server) breaks the end-to-end principle: 
the network-layer communication of the sensor to the server is broken.

> That's not a function you'll be doing at the IPv6 layer.

Why not?

I am not saying pdf signature should be done at network layer.

But I am saying the IP packet signature is to be done at network layer.

One may want an IP packet that is signed by several parties (like a 
petition).

> source/multicast destination either doesn't work or has unacceptable

It is very much clear that src==unicast to dst==multicast does not work 
in vehicular networks.  It has unacceptable limitations.

I can explain why, but not sure where to start.

> Ferguson pointed out one), and then looking for uses for it.

Sounds so to many people.

The "it exists" (broadcast-to-broadcast at link layer) stage is an 
additional indicator I was pointed to just recently.

There are earlier signs: (1) in v6ops WG we discussed extensively a few 
years ago about how to use multicast in vehicular networks.  There was 
no agreement.  Some say it was so because myself 'painting myself in a 
corner'.  This is no more the case.

(2) the pdf multi-party contract signature is an illustrative example of 
the problem of signing an IP packet by multiple parties simultaneously. 
It is not because IP can not do it that it is not necessary (multi-party 
signature) to IP packets.

There are other signs.

Alex

---

From: Fred Baker <[email-masked]>
Date: Thu, 6 Dec 2018 08:34:20 -0500

> On Dec 6, 2018, at 3:04 AM, Alexandre Petrescu <[email-masked]> wrote:
> 

With respect, if many messages from many individual senders are sent on a link, the bandwidth consumed will be the same regardless of the source address. To use less bandwidth, you need some form of summarization before the link to reduce the message count and therefore the bandwidth.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 6 Dec 2018 14:48:30 +0100

Le 06/12/2018 à 14:34, Fred Baker a écrit :
>> - IoT devices sending their temperature value to common cloud
>> server unnecessarily crowd the common link; a reverse IP multicast
>> concept (many-to-single) could save bandwidth.
> 
> With respect, if many messages from many individual senders are sent
> on a link, the bandwidth consumed will be the same regardless of the
> source address. To use less bandwidth, you need some form of
> summarization before the link to reduce the message count and
> therefore the bandwidth.

YEs, if all senders are on same link.

But when senders are on distinct links, no.

Alex

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 18:21:19 +1100

> multicast addresses are not to be used as source addresses,

Oh no. It does not say anything different from RFC4291, and both of
them sound like "*it's sender's responsibility not to put multicast
address into the Source Address field". My original question was: if
the sender still violates all standards and sends a packet with
multicast source, what shall the router or receiver do?

For IPv4 we do have a clear answer for routers: SHOULD discard, MAY
route but it MUST be confugurable with the default to discard. For
IPv6 we have nothing written clearly.

> valid and robust for receivers to silently ignore them.

I agree but it means some additional work for receiver, so they just
don't do that 'because nobody has asked us'.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 18:24:20 +1100

> Did you happen to mention BCP 38 to them?

It's a different story. BCP38 is done by using explicit firewall
filters. What we are talking about here is basic validity checks
performed on the packet.
(yes, sure I could add 'block mcast source' rule on every single
router interface but I was curious if I can expect any sane
implementation to block it for me automatically)
-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 18:37:31 +1100

> I think the conflict is in IPv6 ignoring ff:..:ff MAC broadcast address

I'm still confused, sorry ;( What does IPv6 have to do with MAC addresses?

> an IPv6 multicast address.

"back and forth"? I believe a host would select a multicast
destination  MAC based on the multicast destination IPv6 address of
the packet.
When might the host need to: a) select a *source* multicast MAC based
on source IP address?
b) select an IPv6 address (source or destination) based on multicast MAC?

> Into what IP address to map the ff:...:ff present in some of the fields

If the host is sending this packet, isn't the IP addresses (both src
and dst) are known/selected *before* L2 addresses need to be chosen?
So I'm not sure why/how the host need to map L2 addresses to IPv6 addresses...

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 09:16:39 +0100

[...]
> amplification attacks, when the destination address that should be a

The security arguments are wrongly used here.

The DDoS attacks happen daily without involving any multicast addresses, 
but involving unicast addresses.  Attackers synchronise in underground 
chat (an out-of-band mechanism) and send simultaneously from many 
sources to a victim and ask reply.  Generating the replies overloads the 
CPU/disk even if the interface cards can keep up.

Generating packet storms is not particular to src==multicast.  You get 
packet storms with ARP too (ARP does not use multicast), too frequent 
handovers (Mobile IP), and others.

The AH header (a security tool) uses SAs whose index can very well be a 
multicast address.

That is a problem (invoking a wrongly understood DDoS risk, and the 
silent ability of AH to protect multicast).

The solution is the following: make a new reverse multicast mechanism 
where computers sending from multiple sources can be distinguished from 
badly intended computers doing DDoS.  Then apply AH to it, it works.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 09:18:27 +0100

> I'm still confused, sorry ;( What does IPv6 have to do with MAC addresses?

It's in RFC 2464 titled "IPv6 over Ethernet".  An IPv6 multicast MAC 
address is mapped on an IPv6 multicast address.  'Mapped' means back and 
forth.

I will read the below later.  I have no more batter

Alex

---

From: Mark Smith <[email-masked]>
Date: Fri, 7 Dec 2018 19:22:32 +1100

> don't do that 'because nobody has asked us'.

Well I assume it's causing a problem, because you've noticed it. There
doesn't need to be a RFC to demonstrate why they should ignore them if
accepting them is causing a problem.

You can of course also say to them that their competitor's equipment
ignores them, and you'll be making it a requirement at the next RFP.

---

From: Jen Linkova <[email-masked]>
Date: Fri, 7 Dec 2018 19:44:36 +1100

On Fri, Dec 7, 2018 at 7:18 PM Alexandre Petrescu
<[email-masked]> wrote:
> address is mapped on an IPv6 multicast address.

Just out of curiosity, which section of RFC2464 are you referring to?

MAC -> IP "mapping" is mentioned in the Section 4, Stateless Autoconfiguration.
It says "

The Interface Identifier [AARCH] for an Ethernet interface is based
   on the EUI-64 identifier [EUI64] derived from the interface's built-
   in 48-bit IEEE 802 address."

So there is no way multicast MAC appears here.

IP -> MAC mapping: Section 7 "Address Mapping -- Multicast"
explicitly talks about mapping the destination IPv6 to the destination
MAC (so the packet can be sent)

>'Mapped' means back and forth.

Still can not see the scenario when a host needs to map a random
(multicast) MAC address to an IPv6 address which needs to be used as a
source address.

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 11:26:56 +0100

Jen,

Le 07/12/2018 à 09:44, Jen Linkova a écrit :
[...]
> MAC (so the packet can be sent)

Indeed, I made an error in that argument.

RFC 2464 "IP/Eth" maps multicast _dst_ IP address to dst MAC address (no 
just any address).

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 7 Dec 2018 11:38:13 +0100

> So I'm not sure why/how the host need to map L2 addresses to IPv6 addresses...

So I am not sure why do we call it mapping and not unidirectional 
mapping :-)

On another hand, I am sure that if I look at the code I will find many 
instances where bidirectional mapping happens, or is assumed, between 
MAC address and IP address be they multicast or unicast.

I will not look at the code, because the question sounds like a similar 
raised in other contexts.  In privacy identifiers, backers of needs of 
new methods were succesfull at persuading that attacker may take 
advantage of a reverse mapping between an IP address containing a MAC 
address and the MAC address, even though the question of who does such 
kind of reverse mapping was not clearly answered. (Inverse ND does it).

Alex

---

From: 神明達哉 <[email-masked]>
Date: Fri, 7 Dec 2018 11:56:39 -0800

At Fri, 7 Dec 2018 18:21:19 +1100,

In the beginning of this thread you said:

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

So is your specific case that some node sends an NA with a multicast
source address to a router and the router accepts it?  If so, does
that cause an actual operational problem or is it just that you found
it awkward?  I totally agree that such an NA is bogus, but in my
understanding the handling of incoming NA doesn't depend on the source
address of the NA, so I'm curious...

--
JINMEI, Tatuya