Re: Packets with LL src and GUA dst
Owen DeLong <owen@...
2016-06-23 20:33:27 GMT
> On Jun 23, 2016, at 06:39 , Alexandre Petrescu <alexandre.petrescu <at> gmail.com> wrote:
> Le 23/06/2016 à 00:47, Owen DeLong a écrit :
>>> In all cases, the need is there: in some widespread vehicular
>>> communications there is no unicast nature of communication semantics (a
>>> car can't unicast a packet to another car) - it is all 'broadcast'.
>>> Each car broadcasts data every 1/30th seconds (30Hz) and each other car
>>> hears everybody else. The ESSID and the dst MAC address is
>>> ff:ff:ff:ff:ff:ff, even though the src MAC address is that card's address.
>> Then perhaps you should get a reserved multicast group number for “all cars”.
> Well I wonder about the name.
> The too familiar 'cars' could be more pedantic 'vehicles' or 'light vehicles'.
> But 'vehicles' would look strange in the current list of nodes, routers, servers or agents
I don’t care what you name it as long as it makes sense and is properly descriptive.
Cars was just an example for the sake of discussion, not an actual recommendation.
>> Then, you can use “all cars on link” for link scoped communications where
>> a LL source address would be valid and “all cars within ORG” for an ORG scoped
>> communication using a ULA source, etc.
> 'ORG' - 'organization' is obviously not the right word for something ephemeral happening between a few
cars on a highway none of which being more entitled than another.
Depends. if it’s all the vehicles that belong to e.g. DHL that you are trying to reach, that could be a
perfectly legitimate use of ORG.
There are lots of other scopes to choose from as well.
Point is that with ULA SRC, agreement among the participants to forward ULA network numbers, and a proper
multicast scope, you can do what you want without breaking half the RFCs to do it.
Sure, your forwarding is now forwarding at layer 3, but that’s better in most cases anyway.
Ad-Hoc random layer 2 forwarding DOES NOT SCALE.
>> There are clean ways to do this, but the proposals you have put forth so far,
>> however, are not.
> I am looking for clean ways dealing with situations where it's hard to say who is the 'owner' or the control
entity which keeps track of multicast registrations in some scope.
That’s the beauty of having a registered multicast group.
The scope is a choice made at packet creation time, but the semantics of the group number remain the same
regardless of scope.
So, for example, All Nodes multicast is always ALL Nodes. You can make it All Nodes on Link, All Nodes within
ORG, All Nodes Globally, or whatever. That’s why the group ID and the Scope are separate fields in the
IPv6 Multicast address and why there’s a flag to indicate whether the Group ID is permanent/global or
valid only within the current context.
(chances of real world forwarding of multicast obviously diminish with increasing scope choice, but
that’s a separate matter).
>> There is no concept of broadcast in IPv6, so you can’t do “broadcast-only”.
>> You have to use multicast.
> The word 'broadcast' can be ambiguous in this discussion. In vehicular communications 'broadcasting'
means to send in the ether, as opposed to sending on a wired Ethernet; and it also means there is no return
path - a little bit like in 'TV broadcast'. In a particular report, they say "DSRC operates in constant
broadcast-and-receive mode": you periodically broadcast to everyone else and always receive from
everyone else, but you can not send to just one entity. This 'broadcast' concept of vehicles is
independent of the fact that the MAC dst address is ff:ff:ff:ff:ff:ff (MAC broadcast address).
That’s a simply stupid definition of the term and can only lead to confusion when you talk to people
involved in networking.
> But yes I agree with you when it comes to IPv6 it should use multicast addressing, not broadcast addressing.
Exactly. And it should limit the Multicast to a group assigned to the particular purpose. You might need
multiple multicast group numbers for different applications to do this right.
> So I think we should suggest to use 33:33::1 MAC address instead of the ff:ff:ff:ff:ff:ff MAC address when
IPv6 is used over these links. I will put that in some draft.
That’s probably a good start.
v6ops mailing list
v6ops <at> ietf.org