Re: [v6ops] MAC and IP multicast addresses in vehicular networks

[Alexandre Petrescu <[e-mail]>]

Hi Joe,

Le 08/07/2016 à 00:08, Joe Touch a écrit :
>
>
> On 7/7/2016 5:19 AM, Alexandre Petrescu wrote:
>>
>>
>> Le 05/07/2016 à 19:03, Joe Touch a écrit :
>>>
>>>
>>> On 7/4/2016 11:16 AM, Alexandre Petrescu wrote:
>>>>
>>>>
>>>> Le 23/06/2016 à 22:51, Joe Touch a écrit :
>>>>> ... IMO, it'd be better to say you're using "all nodes" and
>>>>> cite RFC2464 rather than opaquely using the MAC that
>>>>> results.
>>>>
>>>> Well "all nodes" direction sounds better compared to previous
>>>> "all cars".  But RFC2464 does not define such MAC address,
>>>> neither such IP address, so one wouldnt cite RFC2464
>>>> meaningfully.
>>>>
>>>> The Group ID "all nodes" for an IP address is defined in
>>>> RFC4291 and the allocations are managed at
>>>> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>  But "all nodes" means actually any IP-capable node, not
>>>> necessarily those that run 802.11-OCB (aka 802.11p) - i.e.
>>>> WiFi, LTE and others.
>>>
>>> That's because IP multicast addresses are assigned based on
>>> protocols that run OVER IP, not those that operate underneath.
>>
>> Yes, IP multicast addresses are so assigned.
>>
>> But some IP multicast addresses correspond to some MAC group
>> addresses, on a 1-to-1 basis:  for the 'all-nodes' link-scoped IP
>> multicast address there is a 'all-nodes' MAC group address.
>>
>> The other way around too: for a 'all-nodes' MAC group address
>> there is an IP multicast address called 'all-nodes' with link
>> scope.
>
> That's not really "the other way around"; that happened because the
> corresponding IP multicast "all nodes" address within link scope was
>  defined as such.

I suppose it's not a coincidence that IEEE and IETF both call these
addresses "all-nodes" but I have no trace of that.

>> And, over 802.11p too a MAC multicast address corresponds to an IP
>>  multicast address.
>
> AFAICT, IP multicast addresses are explicitly assigned. That's why
> the table here includes corresponding IPv6 addresses for only a
> subset of Ethernet multiacast addresses:
> https://en.wikipedia.org/wiki/Multicast_address#IPv6

Thank you for the wikipedia pointer but I am trying to keep away as much
as possible.

I am trying to identify the precise IEEE authoritative reference that
says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant.

Worse, if you look at the wikipedia page it says "802.11 wireless
networks use the same 01:00:5E:xx:xx:xx and 33:33:xx:xx:xx:xx MAC
addresses for multicasting as Ethernet."  This is obviously an error for
at least two reasons: there should be only _one_ such address for 
interoperability, and 2nd I never saw this "01:00" address in a IP/wifi 
capture, it's always "33:33:...".  This is an error that wikipedia 
should correct.

Additionally, the IEEE lists multicast addresses there:
https://standards.ieee.org/develop/regauth/grpmac/public.html
(and there is no "01:00:" address either).

So I stay away from wikipedia on these matters.

>>>> I could not find a MAC address "all nodes" defined at IEEE.
>>>
>>> That's usually what all 1's is used for. At the link layer,
>>> there isn't much difference between broadcast and multicast "all
>>> nodes".
>>
>> No no, there _is_ a difference.  IPv6 does not work with all 1s MAC
>> broadcast address, it only works with 33-33-0-0-0-1 MAC multicast
>> address.  IPv4 only works with all 1s MAC broadcast address.
>
> I was speaking of "all 1's" as representing "link broadcast", i.e.,
> as behaving like all 1's in IPv4. Yes, that's not the address used
> for IPv6.

Ah I see, ok.

>>>> At IEEE I found a 48bit "All Multicast Capable End Systems
>>>> Address" 01-80-C2-00-00-1B; it is listed there:
>>>> https://standards.ieee.org/develop/regauth/grpmac/public.html
>>>
>>> That's listed as LLDP too - and that makes sense if you want to
>>> use a link address over which to find 802.11p-capable nodes.
>>
>> A-ha, it makes sense.  So the question is: which group MAC address
>>  should IPv6-over-80211p use:
>>
>> - ff:ff:ff:ff:ff:ff - obviously the answer is no.
>
> But the correct corresponding "all nodes" might be appropriate:
> ff02::1

Yes, this IP "all-nodes" is very appropriate, I agree.

>> - 33:33:00:00:00:01 - like IPv6-over-WiFi does
>
> All of the 33:33:: addresses are IPv6 multicast, as per RFC 2464,
> but I don't see anywhere where any of these addresses are assigned
> (or assignable) to a single protocol.

Well, there are multiple things here.

The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP addresses).

Curiously enough, they are defined in an IETF RFC (RFC 2464
"IPv6-over-Ethernet" lists hexa "3333").  I can not find them defined at
IEEE even though there is an IEEE place listing IEEE MAC multicast
addresses:
https://standards.ieee.org/develop/regauth/grpmac/public.html

It is curious because IETF should not define MAC address formats or
contents, right?

As an additional curiosity, the well-known 'cavebear' registry lists
33-33 as an Ethernet Multicast Address:
http://www.cavebear.com/archive/cavebear/Ethernet/multicast.html
as an "IPv6 Neighbor Discovery" explanation.

It is curious because this "33-33-" MAC address is used below other IPv6
protocols like DHCPv6, not only Neighbor Discovery.

To correct all these, the following can be proposed:

- IETF define notation "33:33:0:0:0:0:1" (and not "33-33-0-0-0-0-1") to
   mean a 6-byte MAC address, and not an IPv6 address, despite the
   column use.
- IEEE tells where is this "3333" address defined so we can see it
   publicly.
- wikipedia stops writing wrong articles.
- RFC2464 gets update to mean it also works on WiFi not only on
   Ethernet.
- cavebear tells "33" to mean all IPv6 not only ND.

Unfortunately none of these is my goals here.  I am trying to just
identify the right MAC multicast address for 802.11p below IPv6 (or
IPv6-over-80211p if you wish).

>> - 01-80-C2-00-00-1B - like LLDP does - request a new one?
>>
>>>> Remark (1) I have never seen this 48bit IEEE address in
>>>> vehicular network trials and (2) it is not a
>>>> "33-33-XX-XX-XX-XX" address, which _is_ present in some IPv6
>>>> vehicular prototypes.
>>>>
>>>> In this context, I believe it can make sense to think of
>>>> requesting IANA (rather than IEEE) for an allocation of a
>>>> 112bit Group ID named "All 802.11-OCB interfaces";
>>>
>>> There are no other IPv6 multicast addresses that group nodes by
>>> link type. This sort of request doesn't make sense to me at all;
>>> it's a bit backwards.
>>
>> I agree there are no other IPv6 multicast addresses that group the
>>  nodes by link type (you dont have an address called "all Ethernet
>>  nodes" for example).  However, 802.11p is not really a particular
>> link type - it is WiFi.
>
> To IP, WiFi is a link type. Granted, it may have a variety of
> physical layers underneath and include various subsets of
> extensions, but WiFi is not a network-layer protocol or higher-layer
> (e.g., app-layer) service, e.g., as routing or DHCP are.

I agree.

>> Moreover, we are not concerned here with a request to IEEE.  An
>> IPv6-over-foo I-D describes _mappings_, i.e. what number gets
>> mapped from IETF to IEEE identifier.
>
> It's exactly because you'd need this assigned by IETF that it makes
> no sense.

But an IETF stds track document should tell which is the MAC multicast
address on which to map some IP address.  And it should be only one, and
agreed by IEEE.

>> As such, it is reasonable to request at IETF a 112bit Group
>> Identifier, parts of which may get mapped to some bytes of a group
>>  multicast address.
>
> In a general sense, yes, IANA would be the right party to assign a
> group ID here, but that assumes that a group ID should be allocated
> to a link type. There is no precedent for that.

Then we should go with "all-nodes" address (not all-OCB-nodes).  But we
need to know whether that is "33" MAC prefix or some other prefix.

And the fact that RFC2464 says it's "33" prefix it's not sufficient -
RFC2464 is for Ethernet (wired) not for WiFi.  802.11OCB (aka 802.11p)
is a kind of WiFi not a kind of Ethernet.

Unless maybe IEEE tells we should use this "33" MAC prefix.

>> The overall goal is that people stop using the MAC broadcast
>> address on 802.11p (all 1s) and start using a single MAC group
>> address (not various).
>
> Although I understand your goal, I don't see why a separate *IP*
> multicast group is the right way to solve it.

In order to get rid of all the above doubts (wikipedia, cavebear, IEEE
and RFC2464 seem each contradictory to each other) and start afresh.

Just get a new allocation fresh only for vehicular communications, and
advertise that in an RFC.  Not care about fixing old problems like wired
Ethernet and wikipedia.

> If you want to reach all nodes, you already can on IPv6 using
> ff02::1

YEs.

> If you want to reach all 802.11p nodes, you need to define an
> IP-visible service that selects for that property, and ask for a
> group ID *for that service*, IMO.

In a sense yes, but the 'service' layer is much higher than a networking
layer which would send a Router Advertisement.

It would be a chicken and egg problem: before establishing network
connectivity one would need to set up app-layer multicast groups.

>>> AFAICT, you either really want to use LLDP at the link layer or
>>> the existing SSDP IPv6 multicast address to identify your
>>> service.
>>
>> YEs, later, when we discuss application-level services that is a
>> very good direction.  For example we need to identify a group of
>> all taxis in a cell to send them a call.
>>
>> But for now we need a group MAC address on 802.11p on which we can
>>  send network-layer messages like Router Advertisements.
>
> If you want to send router advertisements, send them to ff02::2 (all
>  routers).

If I do so, what does the dst field in the MAC header contain?

"33:33:0:0:0:2"?  What is the authoritative reference for that "3333"?

> If you want to specify a subset of those routers, you really ought
> to do so the same way as everyone else - by the IP-layer *routing
> protocol* spoken (e.g., OSPF, RIP, etc.).

OSPF also sends HELLOs to "allSPFrouters" ff02::5 IPv6 multicast
address.  I guess such HELLO gets carried by a MAC header with MAC dst
address 33:33:0:0:0:5, even though this 3333 prefix is not specified by
IEEE, and even though cavebear says it's for IPv6 ND only (not OSPF).

But OSPF is not my problem at this time.

Alex

>
> Joe
>