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

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 4 Jul 2016 20:16:49 +0200

Le 23/06/2016 à 22:51, Joe Touch a écrit :
>
>
> On 6/23/2016 1:33 PM, Owen DeLong wrote:
>>> 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.
>
> 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.

I could not find a MAC address "all nodes" defined at IEEE.

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

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"; this Group ID could then be used with
scope link, or site, or admin - to make a full multicast IP address.
Then it would come down to define a link scope to be the scope between a
few nearby cars, site scope to be the scope between one platoon, and so on.

What do you think?

Alex

> Joe

---

From: Erik Marcus Kline <[email-masked]>
Date: Tue, 5 Jul 2016 09:52:45 +0900

> What do you think?

I think that until the subnet model is understood, i.e. this section
needs to be completed:

    https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04#section-5.6

the meaningful mapping of addresses cannot claimed to be understood,
i.e. this section is incomplete/inaccurate until the subnet model is
understood:

    https://tools.ietf.org/html/draft-petrescu-ipv6-over-80211p-04#section-5.4

---

From: Joe Touch <[email-masked]>
Date: Tue, 5 Jul 2016 10:03:16 -0700

On 7/4/2016 11:16 AM, Alexandre Petrescu wrote:
>> ...

That's because IP multicast addresses are assigned based on protocols
that run OVER IP, not those that operate underneath.

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

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

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

AFAICT, you either really want to use LLDP at the link layer or the
existing SSDP IPv6 multicast address to identify your service.

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 7 Jul 2016 14:19:04 +0200

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

And, over 802.11p too a MAC multicast address corresponds to an IP 
multicast address.

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

> 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.
- 33:33:00:00:00:01 - like IPv6-over-WiFi does
- 01-80-C2-00-00-1B - like LLDP does
- request a new one?

> type. This sort of request doesn't make sense to me at all; it's a bit

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.

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.

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.

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

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

Alex

---

From: Joe Touch <[email-masked]>
Date: Thu, 7 Jul 2016 15:08:16 -0700

On 7/7/2016 5:19 AM, Alexandre Petrescu wrote:
> 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.
>
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.

> And, over 802.11p too a MAC multicast address corresponds to an IP

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

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

> - ff:ff:ff:ff:ff:ff - obviously the answer is no.
But the correct corresponding "all nodes" might be appropriate:
ff02::1

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

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

> from IETF to IEEE identifier.

It's exactly because you'd need this assigned by IETF that it makes no
sense.

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

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

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

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.

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

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jul 2016 15:52:15 +0200

Hi Joe,

Le 08/07/2016 à 00:08, 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
>>>>  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.
>>
>> The other way around too: for a 'all-nodes' MAC group address
>> there is an IP multicast address called 'all-nodes' with link
>> scope.
>

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

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

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.

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

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

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

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

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

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

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

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

---

From: Owen DeLong <[email-masked]>
Date: Fri, 8 Jul 2016 11:18:56 -0700

[SNIP]

The IEEE document you referenced is not complete for all 802.x multicast addresses, but only covers 802.1D and 802.1Q.

The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI as explained in RFC-7042) and has also delegated
an OUI block 33-33-00 to 33-33-FF to IANA for IPv6 Multicast.

Once those OUIs were delegated to IANA, it is, in fact, up to IANA (through the IETF process) to register assignments
within those OUIs which is exactly what has happened in the RFCs to which you refer.

You can find more information from IANA about this here:

http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-1

Seems to me that the Wikipedia page is correct and that the Petrescu understanding is flawed.

Owen

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 11:57:14 -0700

> an OUI block 33-33-00 to 33-33-FF to IANA for IPv6 Multicast.
I saw the former (01-00-5E) at IEEE.

Is the latter documented anywhere at IEEE?

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jul 2016 21:02:57 +0200

Le 08/07/2016 à 20:18, Owen DeLong a écrit :
> [SNIP]
>
> The IEEE document you referenced is not complete for all 802.x
> multicast addresses, but only covers 802.1D and 802.1Q.
>
> The IEEE has delegated to IANA the management of 01-00-5E (IANA OUI
> as explained in RFC-7042) and has also delegated an OUI block
> 33-33-00 to 33-33-FF to IANA for IPv6 Multicast.
>
> Once those OUIs were delegated to IANA, it is, in fact, up to IANA
> (through the IETF process) to register assignments within those OUIs
>  which is exactly what has happened in the RFCs to which you refer.
>

That URL says:
> [...] while multicast addresses under the IANA OUI start with
> 01-00-5E. [...] 48-bit MAC addresses in the range
> 33-33-00-00-00-00 to 33-33-FF-FF-FF-FF are used for IPv6 multicast.

So there is an IETF protocol which is not an IPv6 protocol? (because it 
uses 01-00-5E at MAC, instead of 33-33-).

> Seems to me that the Wikipedia page is correct and that the Petrescu

Which of 01-00-5E and 33-33-00 should be used in dst field of multicast
IPv6 Router Advertisement packets sent on 802.11-OCB (aka 802.11p)?  And 
most importantly - why?

Alex

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 12:14:42 -0700

> addresses "all-nodes" but I have no trace of that.

Let's get down to the authorities:

IANA:
http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
    IANA does assign addresses starting with 01-00-5E for link multicast.
    IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for
IPv6 multicast.

IEEE:
    http://standards.ieee.org/develop/regauth/grpmac/public.html
        01-80-C2-00-00-1B = all multicast-capable endsystems
        01-80-C2-00-00-1D = all multicast-capable intermediate systems
        01-80-C2-00-00-00..0F = assigned for 802.1Q
            *** this appears to be where you might request an address
for your protocol ***

You also argued about "all 1's" not being Ethernet broadcast. It is
defined as exactly that on page 32 here:
www.ieee802.org/secmail/pdfocSP2xXA6d.pdf

However, it's also defined as "never assigned" as NULL or unintialized here:
https://standards.*ieee*.org/develop/.../eui48.pdf
> says "33-33-0-0-0-1" is the MAC 'all-nodes' address but I cant.

Same here - still looking, but I see only IANA's assertion of ownership
based on an RFC. Nothing at the IEEE yet.

> The 6-byte "33:33::" addresses are MAC addresses (not 16-byte IP
Yes - I was intending to say "the 33:33::" addresses are used within
IPv6 multicast as per RFC2464...

> It is curious because IETF should not define MAC address formats or

Agreed - I think there are a few of us looking, but if anyone knows,
please speak up!

> protocols like DHCPv6, not only Neighbor Discovery.
Yes.

>   mean a 6-byte MAC address, and not an IPv6 address, despite the
Agreed. I think you meant "colon" rather than "column", though.

> - IEEE tells where is this "3333" address defined so we can see it

Please!

> - wikipedia stops writing wrong articles.

Well, it is Wikipedia - if it's incorrect, we can change it...

> - RFC2464 gets update to mean it also works on WiFi not only on
I don't understand this at all. I thought WiFi was just a variety
wireless media layers over which 802 frames (colloquially known as
"ethernet") were sent.

> address on which to map some IP address.  And it should be only one, and
I think that's step 2; step 1 is getting the address from the IEEE.

> need to know whether that is "33" MAC prefix or some other prefix.

Agreed.
> advertise that in an RFC.  Not care about fixing old problems like wired
Although I agree it isn't useful to solve old problems, "all nodes" IP
multicast already exists. If that's what you should be using, then use it.

I still see absolutely no reason for "vehicular" assignment; assignments
are for protocols, not places where you deploy them.

> layer which would send a Router Advertisement.

You're either sending a link-layer routing protocol message (e.g., like
a IS-IS or Ethernet BPDUs) or you're sending an Internet routing
protocol (e.g., OSPF, RIP). Most Internet routing protocols operate as
"service" layers (i.e., "applications"), i.e., inside UDP or TCP inside IP.

Given you want to reach all 802.11p nodes, it seems like you should want
an MAC multicast address - but not an IP multicast address. IP multicast
is needed only to for IP-layer routing, not for link layer.

Joe

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Jul 2016 21:53:55 +0200

On Fri, Jul 8, 2016 at 9:14 PM, Joe Touch <[email-masked]> wrote:
> Agreed - I think there are a few of us looking, but if anyone knows, please
> speak up!

We have just discussed it in 6man email thread but in case you missed it:
33-33- has Local bit set. It is *locally assigned* MAC. Not globally
assigned by IEEE.

>> - IEEE tells where is this "3333" address defined so we can see it

I believe IEEE told us where 3333 is defined by saying that addresses
which Local bit set are locally administered ones.
IEEE RA is only responsible for assigning identifiers which are globally unique.

-- 
SY, Jen Linkova aka Furry

---

From: Joe Touch <[email-masked]>
Date: Fri, 8 Jul 2016 13:03:48 -0700

Hi, Jen,

Thanks - that helps.

So the right thing here would appear to be to use the existing IPv6
multicast for "all nodes" or "all routers", until one of two things happens:

- an routing protocol/service is developed that warrants a new IPv6
multicast address assignment
    (e.g., for a routing protocol that operates *over* IP)

- a "link layer"protocol/service is developed that warrants a direct
IEEE multicast assignment
    (e.g., for a routing protocol that operates at the IEEE 802 MAC layer)

However, I still have not heard the case for a *protocol* here. I keep
hearing about "vehicular networks" as if that were the same thing, but
it isn't.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Sat, 9 Jul 2016 12:53:18 -0700

> On Jul 8, 2016, at 12:02 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> So there is an IETF protocol which is not an IPv6 protocol? (because it uses 01-00-5E at MAC, instead of 33-33-).

IETF defined all of the stuff for IPv4 as well. I am not certain, but I think IETF also existed for part of the time during NCP prior to IPv4, but even if it didn’t, it’s predecessor did and probably IETF is now the official repository for that knowledge and its curation.

So, yes, of course IETF does more protocols than just IPv6.

> IPv6 Router Advertisement packets sent on 802.11-OCB (aka 802.11p)?  And most importantly - why?

Why would it be any different from the MAC address used for IPv6 RA on 802.11a/b/g/n/ac which I believe is also the same for 802.1, 802.2, 802.3, …

According to http://flylib.com/books/en/2.223.1.44/1/ the mapping is 0x33:33:XX:XX:XX:XX where XX:XX:XX:XX is the last 32 bits of the IPv6 multicast group number.

So, since you would send the IPv6 RA target is most likely “All nodes on link”, ff02::1 this would map to MAC address 0x33:33:0:0:0:1.

This is a universal mapping which applies to ALL 802.x (and possibly other) networks, not merely the ones listed above to the best of my knowledge.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jul 2016 12:43:25 +0200

>     IANA recognizes the use of 3-33-00-00-00-00 to 33-33-FF-FF-FF-FF for

I wonder what IETF protocol 01-00-5E has been assigned for.

It seems IANA has more authority over this address, and it is more 
likely to be unique.  As such maybe it is better to use it for 
IPv6-over-foo documents, rather than 33-33-.

>             *** this appears to be where you might request an address

Right.

So this would be a 4th alternative for a multicast address for 
IPv6-over-80211OCB.  Summarizing:

- all 1s
- 33-33- prefix (IANA local)
- 01-00-5E- prefix (IANA global)
- 01-80-C2- prefix (IEEE allocation)

> www.ieee802.org/secmail/pdfocSP2xXA6d.pdf

Thanks for the reference.  Yes, it's there.

> based on an RFC. Nothing at the IEEE yet.

If IEEE has no text about this 33-33- prefix then I think there can be 
problems.

> Agreed. I think you meant "colon" rather than "column", though.

YEs.  This makes think writing an I-D title "IETF notation of MAC 
addresses" could make sense to avoid confusion.

Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely used 
packet analyzer says "33:33:00:00:00:01".  Common dialogue with the 
IPv6-versed tends to say "33:33::1".  This may lead to confusion.

> wireless media layers over which 802 frames (colloquially known as

In principle it is that way.

For introduction I believe there may be some detail that RFC2464 overlooks.

I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, 
ethertype] - does not get sent over the 802.11 media.  I suspect there 
is a local adaptation layer in each WiFi computer which converts 
bidirectionaly between an Ethernet II header [dst, src, ethertype] and 
802.11 frames: for each Ethernet II header there is a corresponding 
tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an 
LLC header.  And it's this tuple that gets sent over the 802.11 media, 
not the Ethernet II header.

The difference can be seen between captures in normal and monitor mode.

RFC2464 is concerned only of that Ethernet II header captured in normal 
mode, even though it does not get sent over the air.

However, there can be some detail lost when considering only the 
Ethernet II header.  For example, if the 802.11 QoS Data Header is 
employed then some of its fields are invisible by the RFC2464 mapping 
process.  However, these fields could be useful for the Traffic Class or 
Flow Label fields of the IPv6 header.

In some vehicular network trials the 802.11 QoS Data Header is used 
below a WSMP protocol (a network layer-free app-layer protocol).  In 
these trials, if one considers the use of IPv6 below WSMP, then one has 
to consider the need of distinctive flows of IP datagrams (e.g. emergency).

It is also worth mentioning that the discrepancy between what the 
Ethernet II header has to offer and what many media need, can be seen 
not only on this 802.11-OCB mode for vehicles, but also by IoT documents 
at IETF describing adaptation layers for media like 802.15.4, lowpan, 
and more.

For these reasons I think 802.11 too deserves its own IPv6-over-80211 
document at IETF.

> are for protocols, not places where you deploy them.

I note that.

> is needed only to for IP-layer routing, not for link layer.

YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: 
re-use an existing one?  If yes which one?  Allocate a new one?  If yes 
where to ask?

For IP multicast address, let's see a bit later.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Mon, 11 Jul 2016 10:33:13 -0700

> On Jul 11, 2016, at 03:43 , Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> It seems IANA has more authority over this address, and it is more likely to be unique.  As such maybe it is better to use it for IPv6-over-foo documents, rather than 33-33-.

33-33 is a locally administered address. It is reasonable to presume that any local admin who wants IPv6 to work on their network will not conflict with 33-33 at this point.

Remember, MAC addresses are replaced at each routing hop, so they are only relevant on the local link.

The full IANA MAC registry is here:

Note that there are IANA assignments under 00-00-5E for non-multicast purposes as well.

The procedure for updating that registry is here:

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

> 
>> IEEE:
>>    http://standards.ieee.org/develop/regauth/grpmac/public.html <http://standards.ieee.org/develop/regauth/grpmac/public.html>

I think using this range would be ill advised for this purpose.

> 
> So this would be a 4th alternative for a multicast address for IPv6-over-80211OCB.  Summarizing:
> 
> - all 1s

Locally administered means that it is up to the owner of each link to decide if they want to use this or not.

IANA has suggested and there’s lots of code deployed that uses 33-33 for IPv6 multicast. As such, any local administrator that wants IPv6 to work on their network should probably respect this or expect a fair amount of pain.

I’d say that makes 33-33 fairly safe to use for any IPv6 multicast need.

> - 01-00-5E- prefix (IANA global)

It appears that IANA is unlikely to use this for IPv6 and I suspect that you will have a hard time getting agreement to allocate anything special here for your intent.

> - 01-80-C2- prefix (IEEE allocation)

Since your protocol is an application sitting on top of TCP or UDP or something else on top of IPv6, I think you are unlikely to get much traction here as well. Even if you do, I think it’s an abuse of the addresses.

>> https://standards.*ieee*.org/develop/.../eui48.pdf <https://standards.*ieee*.org/develop/.../eui48.pdf>
> If IEEE has no text about this 33-33- prefix then I think there can be problems.

Nope… It’s locally administered meaning each segment owner can do what they like. If they like IPv6, they’ll leave 33-33 alone for IPv6 multicast.

The worst that can happen is you end up with some stations receiving packets they don’t want.

> I suspect the 802.3 frame - e.g. an Ethernet II Header [dst, src, ethertype] - does not get sent over the 802.11 media.  I suspect there is a local adaptation layer in each WiFi computer which converts bidirectionaly between an Ethernet II header [dst, src, ethertype] and 802.11 frames: for each Ethernet II header there is a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS Data Header) plus an LLC header.  And it's this tuple that gets sent over the 802.11 media, not the Ethernet II header.

My understanding is that all happens in the hardware, so as far as all of the system software is concerned, it’s sending and receiving 802.3 frames to/from the interface.

> RFC2464 is concerned only of that Ethernet II header captured in normal mode, even though it does not get sent over the air.
> 
> However, there can be some detail lost when considering only the Ethernet II header.  For example, if the 802.11 QoS Data Header is employed then some of its fields are invisible by the RFC2464 mapping process.  However, these fields could be useful for the Traffic Class or Flow Label fields of the IPv6 header.

In general that would be a layering violation anyway.

> In some vehicular network trials the 802.11 QoS Data Header is used below a WSMP protocol (a network layer-free app-layer protocol).  In these trials, if one considers the use of IPv6 below WSMP, then one has to consider the need of distinctive flows of IP datagrams (e.g. emergency).

It’s unclear what you mean by “distinctive flows of IP datagrams”.

> It is also worth mentioning that the discrepancy between what the Ethernet II header has to offer and what many media need, can be seen not only on this 802.11-OCB mode for vehicles, but also by IoT documents at IETF describing adaptation layers for media like 802.15.4, lowpan, and more.

Not everything is an 802.3 network. Non-802.3 networks require different adaptation layers.

> For these reasons I think 802.11 too deserves its own IPv6-over-80211 document at IETF.

I’m not completely convinced of this as so far, you seem to be insisting on an approach of adapting IPv6 and 802.3 multicast to your idea of how things should work rather than adapting your application to the idea of how things actually work.

I haven’t seen anything in any of your posts that leads me to believe that the latter would not be the better approach.

>>> IPv6-over-80211p if you wish).

The right solution is:

	1.	Use the correct IPv6 multicast group ID.
		If you want all nodes on link, then that would be ff02::1.

	2.	Map that multicast group ID onto the IPv6 multicast MAC range.
		Assuming ff02::1 as above, then this would be 33-33-0-0-0-1

>> I think that's step 2; step 1 is getting the address from the IEEE.

Since IPv6 multicast uses a well defined set of “locally administered”
MAC addresses, there’s no need to involve IEEE.

You can debate the validity of using 33-33 instead of getting an OUI block
as much as you want, but there’s a lot of running code out there that is
already using 33-33 without any issues. As such, I think that’s a decision
we just have to live with at this point.

I certainly think that picking alternatives piecemeal protocol by protocol
or worse application by application is not a good approach.

>>> need to know whether that is "33" MAC prefix or some other prefix.

If it is an IPv6 datagram, then it should be 33-33. If it is an IPv4 datagram,
then it should probably be ff-ff-ff-ff-ff-ff. If it’s something else,
then the IETF doesn’t really care and isn’t involved.

>> is needed only to for IP-layer routing, not for link layer.

That’s not entirely true. All nodes on link (for example, ff02::1) is definitely a link-layer communication
for IPv6 that should not be routed at the IP layer.

There are reasons for interface and link scoped IPv6 multicast addresses.

Of course, if you want your packets routed, then you can use the same group IDs with different scopes.

> YEs, I need to have this MAC multicast address for IPv6-over-80211OCB: re-use an existing one?  If yes which one?  Allocate a new one?  If yes where to ask?
> 

All of this is asked and answered.

If your target is described already by a well known IPv6 multicast address (it is, All-nodes on link, ff02::1) then use
the appropriate group ID (::1 in this case) and the appropriate scope (Link = 2). The flags are 0 because (Reserved bit always 0, RP not embedded = 0, Group not based on prefix = 0, Group not transiet = 0). So: Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together to form Address (ff02::1).

Once you have the IPv6 multicast address, then you simply map the low order 32-bits onto the MAC prefix (33-33) and you get (33-33-0-0-0-1).

So for your stated purpose, it seems to me the best alternative is destination: ff02::1 @ 33-33-0-0-0-1.

There is nothing special here.

Owen

---

From: Joe Touch <[email-masked]>
Date: Mon, 11 Jul 2016 14:26:04 -0700

> I wonder what IETF protocol 01-00-5E has been assigned for.

You don't need to wonder. Look further down that link:

      IANA Multicast 48-bit MAC Addresses

Note

    These values are prefixed with 01-00-5E.

    00-00-00 to 7F-FF-FF 	IPv4 Multicast 	[RFC1112
    <http://www.iana.org/go/rfc1112>]
    80-00-00 to 8F-FF-FF 	MPLS Multicast 	[RFC5332
    <http://www.iana.org/go/rfc5332>]
    90-00-00 	MPLS-TP p2p 	[RFC7213 <http://www.iana.org/go/rfc7213>]
    90-00-01 	Bidirectional Forwarding Detection (BFD) on Link
    Aggregation Group (LAG) Interfaces 	[RFC7130
    <http://www.iana.org/go/rfc7130>]
    90-00-02 	AllL1MI-ISs 	[RFC6822 <http://www.iana.org/go/rfc6822>]
    90-00-03 	AllL2MI-ISs 	[RFC6822 <http://www.iana.org/go/rfc6822>]
    90-00-04 to 90-00-FF 	Unassigned (small allocations) 	
    90-01-00 	TRILL OAM 	[RFC7455 <http://www.iana.org/go/rfc7455>]
    90-01-01 to 90-01-FF 	Unassigned (small allocations requiring both
    unicast and multicast) 	
    90-02-00 to 90-0F-FF 	Unassigned 	
    90-10-00 to 90-10-FF 	Documentation 	[RFC7042
    <http://www.iana.org/go/rfc7042>]
    90-11-00 to FF-FF-FF 	Unassigned 	

Note that the only assignments in this block are for IETF-generated L2
protocols.

> IPv6-over-foo documents, rather than 33-33-.
It may be, but it is still inappropriate for the use you're seeking, IMO.

> IPv6-over-80211OCB.  Summarizing:

There should never be a multicast address for IPv6 over FOO for any FOO
that isn't a *protocol*.

Link layers are not protocols.

> If IEEE has no text about this 33-33- prefix then I think there can be

As others have noted, the link local bit is set, which means it is
covered by IEEE specs as being locally managed.

> not the Ethernet II header.

IP is a payload to 802. What that layer ends up sending out over the
physical media doesn't matter to IP.

> RFC2464 is concerned only of that Ethernet II header captured in
> normal mode, even though it does not get sent over the air.
See above; that's normal layer separation.

> process.  However, these fields could be useful for the Traffic Class
> or Flow Label fields of the IPv6 header.
See draft-szigeti-tsvwg-ieee-802-11e

> these trials, if one considers the use of IPv6 below WSMP, then one
> has to consider the need of distinctive flows of IP datagrams (e.g.
> emergency).
>
> not only on this 802.11-OCB mode for vehicles, but also by IoT
> documents at IETF describing adaptation layers for media like
> 802.15.4, lowpan, and more.
>

It might, as per the 802-11e doc above. But that's a long way from
necessarily needing a multicast MAC address assignment, either from the
IETF's managed block or directly from the IEEE.
...
> re-use an existing one?  If yes which one?  Allocate a new one?  If
> yes where to ask?
You might start by having that discussion with the IEEE.

> For IP multicast address, let's see a bit later.

Sure - once you explain how what you need runs OVER IP.

Joe

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jul 2016 13:09:27 +0200

Le 11/07/2016 à 19:33, Owen DeLong a écrit :
>
>> On Jul 11, 2016, at 03:43 , Alexandre Petrescu
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>
>>
>>>> ... I suppose it's not a coincidence that IEEE and IETF both
>>>> call these addresses "all-nodes" but I have no trace of that.
>>>
IANA does assign addresses starting with 01-00-5E for link
>>> multicast. IANA recognizes the use of 3-33-00-00-00-00 to
>>> 33-33-FF-FF-FF-FF for IPv6 multicast.
>>
> 33-33 is a locally administered address. It is reasonable to presume
> that any local admin who wants IPv6 to work on their network will not
> conflict with 33-33 at this point.
>
Note that there are IANA assignments under 00-00-5E for non-multicast
> purposes as well.
>>> 01-80-C2-00-00-00..0F = assigned for 802.1Q *** this appears to
>>> be where you might request an address for your protocol ***
>>
>> Right.
>
>> - all 1s - 33-33- prefix (IANA local)
>
> Locally administered means that it is up to the owner of each link
> to decide if they want to use this or not.
>
> IANA has suggested and there’s lots of code deployed that uses 33-33
>  for IPv6 multicast. As such, any local administrator that wants IPv6
>  to work on their network should probably respect this or expect a
> fair amount of pain.
>
> It appears that IANA is unlikely to use this for IPv6 and I suspect
> that you will have a hard time getting agreement to allocate anything
> special here for your intent.
>
> Since your protocol is an application sitting on top of TCP or UDP
> or something else on top of IPv6, I think you are unlikely to get
> much traction here as well. Even if you do, I think it’s an abuse of
> the addresses.
>
>>>> 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.
>>>
>>> Same here - still looking, but I see only IANA's assertion of
>>> ownership based on an RFC. Nothing at the IEEE yet.
>>
> Nope… It’s locally administered meaning each segment owner can do
> what they like. If they like IPv6, they’ll leave 33-33 alone for IPv6
> multicast.
>
>> ethertype] - does not get sent over the 802.11 media.  I suspect
>> there is a local adaptation layer in each WiFi computer which
>> converts bidirectionaly between an Ethernet II header [dst, src,
>> ethertype] and 802.11 frames: for each Ethernet II header there is
>>  a corresponding tuple made of a 802.11 Data Header (or 802.11 QoS
>>  Data Header) plus an LLC header.  And it's this tuple that gets
>> sent over the 802.11 media, not the Ethernet II header.
>
> My understanding is that all happens in the hardware, so as far as
> all of the system software is concerned, it’s sending and receiving
> 802.3 frames to/from the interface.
>
>> employed then some of its fields are invisible by the RFC2464
>> mapping process.  However, these fields could be useful for the
>> Traffic Class or Flow Label fields of the IPv6 header.
>
>> In some vehicular network trials the 802.11 QoS Data Header is
>> used below a WSMP protocol (a network layer-free app-layer
>> protocol). In these trials, if one considers the use of IPv6 below
>> WSMP, then one has to consider the need of distinctive flows of IP
>> datagrams (e.g. emergency).
>

For example an UDP/IP datagram carrying a warning approach would need to
be transmitted distinctively from an UDP/IP datagram carrying an
entertainment video frame.  This could be achieved by a special value in
an IPv6 Traffic Class field and in the QoS control fields of the IEEE
802.11 QoS Data header.

>> Ethernet II header has to offer and what many media need, can be
>> seen not only on this 802.11-OCB mode for vehicles, but also by
>> IoT documents at IETF describing adaptation layers for media like
> I’m not completely convinced of this as so far,

I just learned a new argument for an IPv6-over-80211 document: 802.3
Ethernet uses an MTU 1500bytes.  But 802.11 allows for larger MTUs.  So
why should IPv6-over-80211 restrain to only 1500bytes?  (1500bytes is
what RFC2464 requires).

> you seem to be insisting on an approach of adapting IPv6 and 802.3
> multicast to your idea of how things should work rather than adapting
> your application to the idea of how things actually work.

For clarification: I do not propose an application.  This is networking
I am talking about.

Adapting vehicular networking to the existing IPv6 networking has some
problems.  The problems we raise in this thread are really small.  Think
that other problems of this seem so huge to other people that they say
IPv6 is not meaningful at all in vehicular networks - so
WSMP/CAM/DENM/GN came to life.  These protocols are
application-glued-to-link protocols - i.e. no network-layer protocol at all.

> I haven’t seen anything in any of your posts that leads me to
> believe that the latter would not be the better approach.

Well, it is not an application I am considering but networks - vehicular
networks.  There is a need to make run IPv6 between vehicles.

>>>> 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).
>
>
> The right solution is:
>
> 1.Use the correct IPv6 multicast group ID. If you want all nodes on
> link, then that would be ff02::1.
>
> 2.Map that multicast group ID onto the IPv6 multicast MAC range.

Except that ff02 link scope has no meaning in 802.11-OCB networks -
there is no ESSID, no Association operations, no link.

>>>> 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.
> Since IPv6 multicast uses a well defined set of “locally
> administered” MAC addresses, there’s no need to involve IEEE.
>
> You can debate the validity of using 33-33 instead of getting an OUI
>  block as much as you want, but there’s a lot of running code out
> there that is already using 33-33 without any issues. As such, I
> think that’s a decision we just have to live with at this point.
>
> I certainly think that picking alternatives piecemeal protocol by
> protocol or worse application by application is not a good approach.
>
>>>> 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.
>>>
>>> Agreed.
>
> If it is an IPv6 datagram, then it should be 33-33. If it is an IPv4
> datagram, then it should probably be ff-ff-ff-ff-ff-ff. If it’s
> something else, then the IETF doesn’t really care and isn’t
> involved.
>
>
>>> Given you want to reach all 802.11p nodes, it seems like you
>>> should want an MAC multicast address - but not an IP multicast
>>> address. IP multicast is needed only to for IP-layer routing, not
>>> for link layer.
>
> That’s not entirely true. All nodes on link (for example, ff02::1)
> is definitely a link-layer communication for IPv6 that should not be
>  routed at the IP layer.
>
>> YEs, I need to have this MAC multicast address for
>> IPv6-over-80211OCB: re-use an existing one?  If yes which one?
>> Allocate a new one?  If yes where to ask?
>>
> If your target is described already by a well known IPv6 multicast
> address (it is, All-nodes on link, ff02::1) then use the appropriate
>  group ID (::1 in this case) and the appropriate scope (Link = 2).
> The flags are 0 because (Reserved bit always 0, RP not embedded = 0,
>  Group not based on prefix = 0, Group not transiet = 0). So:
> Multicast (ff), Flags (0) Scope (2) and Group ID (1) come together
> to form Address (ff02::1).

Allow me repeat myself: the scopes 'link' and 'site' make little if any
sense at all in networks of vehicles.

> Once you have the IPv6 multicast address, then you simply map the
> low order 32-bits onto the MAC prefix (33-33) and you get
> (33-33-0-0-0-1).
>

Noted.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 12 Jul 2016 13:35:51 +0200

> <http://www.iana.org/go/rfc1112>] 80-00-00 to 8F-FF-FF 	MPLS
> Multicast 	[RFC5332 <http://www.iana.org/go/rfc5332>] 90-00-00
> MPLS-TP p2p 	[RFC7213 <http://www.iana.org/go/rfc7213>] 90-00-01
> Bidirectional Forwarding Detection (BFD) on Link Aggregation Group
> (LAG) Interfaces 	[RFC7130 <http://www.iana.org/go/rfc7130>] 90-00-02
> AllL1MI-ISs 	[RFC6822 <http://www.iana.org/go/rfc6822>] 90-00-03
> AllL2MI-ISs 	[RFC6822 <http://www.iana.org/go/rfc6822>] 90-00-04 to
> 90-00-FF 	Unassigned (small allocations) 90-01-00 	TRILL OAM
> [RFC7455 <http://www.iana.org/go/rfc7455>] 90-01-01 to 90-01-FF
> Unassigned (small allocations requiring both unicast and multicast)
>  90-02-00 to 90-0F-FF 	Unassigned 90-10-00 to 90-10-FF 	Documentation
> [RFC7042 <http://www.iana.org/go/rfc7042>] 90-11-00 to FF-FF-FF
> Unassigned
>
> Note that the only assignments in this block are for IETF-generated
> L2 protocols.
>
>>
> There should never be a multicast address for IPv6 over FOO for any
> FOO that isn't a *protocol*.

Sounds as a good principle.  But what to do about the existing 33-33-
prefix for Ethernet multicast groups for which there is no MAC multicast
protocol (there is no MAC 'join' message like there is an IPv6 'join'
REPORT MLD protocol).

> Link layers are not protocols.

But what to think about the title of all IPv6-over-foo RFCs saying
"Transmission of IPv6 packets over XXX _Networks_".  They are not link
layers, nor protocols.

>> - all 1s - 33-33- prefix (IANA local) - 01-00-5E- prefix (IANA
>> global) - 01-80-C2- prefix (IEEE allocation)
>>
>>> You also argued about "all 1's" not being Ethernet broadcast. It
>>> is defined as exactly that on page 32 here:

Yes, but this does not stop somebody from sending non-IP messages to
33-33- prefixed MAC dst addresses.  Especially in settings where people
dont want IPv6 because of presumably too much overhead.

Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no conflict
with non-IP protocols.

(though it would be funny for IEEE to consider IPv6 as local opposed to
global, while IPv6 too considers IEEE links as link scope as opposed to
global Internet).

>>>>> But the correct corresponding "all nodes" might be
>>>>> appropriate: ff02::1
>>>>
>>>>> 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.
>>>>
>>> Yes - I was intending to say "the 33:33::" addresses are used
>>> within IPv6 multicast as per RFC2464...
>>>
>>>> "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:
>>>> It is curious because IETF should not define MAC address
>>>> formats or contents, right?
>>>
>>> Agreed - I think there are a few of us looking, but if anyone
>>> knows, please speak up!
>>>
>>>> As an additional curiosity, the well-known 'cavebear' registry
>>>> lists 33-33 as an Ethernet Multicast Address:
>>>> It is curious because this "33-33-" MAC address is used below
>>>> other IPv6 protocols like DHCPv6, not only Neighbor Discovery.
>>> Yes.
>>>
>>>>
>>>> - 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.
>>>
>> Where RFCs and IANA consistently say "33-33-00-00-00-01" a widely
>> used packet analyzer says "33:33:00:00:00:01".  Common dialogue
>> with the IPv6-versed tends to say "33:33::1".  This may lead to
>> confusion.
>>
>>>> - IEEE tells where is this "3333" address defined so we can see
>>>> it publicly.
>>>
>>> Please!
>>>
>>>> - RFC2464 gets update to mean it also works on WiFi not only
>>>> on Ethernet.
>>>
>>> I don't understand this at all. I thought WiFi was just a
>>> variety wireless media layers over which 802 frames (colloquially
>>> known as "ethernet") were sent.
>>

Well but there are huge differences between 802.X variants when it comes 
to parameters relevant to IP like MTU, access control...

Noted.

> necessarily needing a multicast MAC address assignment, either from
> the IETF's managed block or directly from the IEEE. ...

_If_ there is a new IPv6-over-80211 document then there is new 
discussion about it, with more parameters.  Sure it's a long way.

When that is settled then maybe IPv6-over-80211-OCB is much more 
straightforward.

Or maybe just write an IPv6-over-80211-OCB like all other IPv6-over-foo 
which have inherited from RFC2464 and get it done.

>>> You're either sending a link-layer routing protocol message
>>> (e.g., like a IS-IS or Ethernet BPDUs) or you're sending an
>>> Internet routing protocol (e.g., OSPF, RIP). Most Internet
>>> routing protocols operate as "service" layers (i.e.,
>>> "applications"), i.e., inside UDP or TCP inside IP.
>>>

Sure.

Alex

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 07:30:05 -0700

> an IPv6 Traffic Class field and in the QoS control fields of the IEEE

Agreed. It would be useful to understand whetehr the current 802.11 QoS
mapping draft is sufficient for your needs.

> why should IPv6-over-80211 restrain to only 1500bytes?  (1500bytes is
There appear to be several RFCs that set this limit for nearly every
Ethernet based technology because IP deals with 802.2 (which is what I
had intended to cite above) rather than the specific link technology
except for QoS markings and configuration.

> For clarification: I do not propose an application.  This is networking

In the above sentence, "application" is "the way you're using a network".

You're not talking about just networking - you're talking about
networking *used for intervehicular communications*.

> Adapting vehicular networking to the existing IPv6 networking has some
Vehicular networking isn't a protocol, it's a use of protocols and
networking for a purpose.

> The problems we raise in this thread are really small.  Think

You need to find a way to describe your system in terms of protocols,
not locations.

We don't have different versions of IPv6 to run between 2-story and
3-story houses.

> there is no ESSID, no Association operations, no link.

If there's no link, then what do you mean above when you say this?

> so

If there is no link, there is no communication.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Jul 2016 07:36:36 -0700

> there is no ESSID, no Association operations, no link.

Sigh… We’ve been over this before, and it appears you either are resistant
to accepting reality or you just aren’t getting it. It’s unclear which is
the case.

Link Scope means everything you can reach without crossing a router.

So there is, in fact, a link anywhere there is an interface.

It may be extremely variable what set of other vehicles are participating
in the same link at any given time due to differences in relative position,
propagation, interference, and other factors. There may not be meaningful
notification of host arrival on or departure from said link. Nonetheless,
there is, in fact, a link.

I agree that the amorphous nature of who is “on link” can present a variety
of unique challenges to applications making use of such links, but it doesn’t
change the fact that there is a link.

If you don’t like the Link scope and want to use a different scope for your
destination, that’s quite readily available as well. If you don’t like any
of the existing scopes, there are lots of undefined numbers for scopes so
perhaps you need to write up your new scope definitions in an I-D and try
to get numbers allocated to them.

> sense at all in networks of vehicles.

Repeating the same incorrect assertion over and over doesn’t make it any less
incorrect.

See above for ‘link’.

Site is by definition an “administratively defined” boundary determined by the
configuration of routers participating within (and at the borders of) the site,
so while “Site” might not seem like a meaningful term in your context, the ability
to define a “site” pretty much any way you choose makes it a viable concept
even if the term doesn’t fit comfortably.

As I’ve said, if you have unique scope requirements, then there’s a process
by which you can attempt to get the IETF to allocate you a scope number for
those particular requirements.

Nonetheless, it doesn’t change the relationship between the IPv6 multicast
address and the MAC address you should be using.

The scope is not part of the last 32 bits of the group ID, so it won’t
change the MAC address. If you want All Nodes in (any possible scope),
it’s still ff0x::1 and the MAC address is still 33-33-0-0-0-1.

Owen

---

From: Joe Touch <[email-masked]>
Date: Tue, 12 Jul 2016 07:40:47 -0700

> protocol (there is no MAC 'join' message like there is an IPv6 'join'

Then there is a link layer problem within the specification of that
variant of ethernet.

> "Transmission of IPv6 packets over XXX _Networks_".  They are not link

These fall into a two groups:

1) link layers (ethernet, FDDI, token ring)

2) groups of link layers defined by a property of the link behavior that
affects IPv6 (NBMA, IPv4 Domains without Explicit Tunnels)

> global, while IPv6 too considers IEEE links as link scope as opposed to

IPv6 operates over link local addressed links.
...
> Well but there are huge differences between 802.X variants when it
> comes to parameters relevant to IP like MTU, access control...

As you already noted, IP interacts with the 802.2 LLC layer when it
comes to MTU. If you want that fixed so IP can use different MTUs over
different physical layers below 802.2, then you should take up that
issue with the IEEE.

The ways in which other 802.X variants are defined as interacting with
IP in the IETF have typically been limited to configuration of the 802.X
layer, e.g., setting 802.X QOS parameters or CAPWAP
....
> Or maybe just write an IPv6-over-80211-OCB like all other
> IPv6-over-foo which have inherited from RFC2464 and get it done.

You can, but you should look at 2464 to at least see the types of
interactions that are specified.

Joe

---

From: Owen DeLong <[email-masked]>
Date: Tue, 12 Jul 2016 07:56:12 -0700

> protocol (there is no MAC 'join' message like there is an IPv6 'join'

Not relevant. The multicast bit being set in the ethernet address means
that switches will flood it accordingly. IIRC, there is no effective
difference between multicast and broadcast on the vast majority (all) 802
media.

In cases where there is some difference, it’s up to the applicable hardware
to do the right thing. This applies equally in all cases of multicast
regardless of which multicast MAC range is used.

> "Transmission of IPv6 packets over XXX _Networks_".  They are not link

Nor do they define new MAC addresses. You are conflating different things here.

RFCs for link type adaptation are relatively common. That’s got nothing to do
with the mapping of MAC addresses.

> dont want IPv6 because of presumably too much overhead.

So what? Your IPv6 stack should never see a non-IPv6 datagram. This is no different than the days when we commonly ran Appletalk, NetBEUI, IPX, and IP all at the same time on the same networks. It’s not like every host had a separate MAC address for each protocol.

The ethernet driver would pass the packet to the correct stack based on the ethernet EtherType field if said stack was available on the machine. If the machine didn’t have the applicable stack, the packet was silently ignored.

> Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no conflict

There’s no conflict anyway. The EtherType field of the ethernet header insures this. The IEEE has allocated that number for IPv6 and IIRC, it is 0x0800 for IPv4 and 0x86dd for IPv6.

> global, while IPv6 too considers IEEE links as link scope as opposed to

IEEE links are by definition link scope. IEEE does not have any definitions above layer 2.

There’s no need for IEEE to consider IPv6 as anything other than an EtherType.

You seem quite lost in your fundamental understandings here. Perhaps it is time to go back and read the Comer books.

> Well but there are huge differences between 802.X variants when it comes to parameters relevant to IP like MTU, access control…

MTU is not a huge variant and as long as it’s at least 1280, IPv6 doesn’t really care. The MTU is just a parameter passed up the stack which IPv6 adapts to whether the underlying link is 802.X or some other medium.

If the MTU is <1280, then the link adaptation layer must provide for segmentation and reassembly.

I’m not sure what you mean by “access control” in an IP context, so you’ll have to explain. If you’re talking about things like WPA for 802.11, then that is utterly and completely irrelevant to IP and is strictly handled by the link configuration before the IP stack is ever even started on the interface.

Sure, there are a few link level parameters that have to be passed back up to the IP stack to allow it to adapt to the underlying link.
These are generally interface configuration parameters that are passed to the IP stack when it is started on the interface.

But that doesn’t require a different specification for IP to adapt to each 802.x style link.

> _If_ there is a new IPv6-over-80211 document then there is new discussion about it, with more parameters.  Sure it's a long way.
> 
> When that is settled then maybe IPv6-over-80211-OCB is much more straightforward.

You still haven’t provided any sort of coherent explanation why IPv6 over 802.11OCB needs to be meaningfully different than IPv6 over any other 802.x link.

> Or maybe just write an IPv6-over-80211-OCB like all other IPv6-over-foo which have inherited from RFC2464 and get it done.

If you even need a separate document. So far, nothing you’ve explained leads me to believe this is even necessary.

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jul 2016 16:03:34 +0200

Le 12/07/2016 à 16:56, Owen DeLong a écrit :
>>>
>>> There should never be a multicast address for IPv6 over FOO for
>>> any FOO that isn't a *protocol*.
>>
>> Sounds as a good principle.  But what to do about the existing
>> 33-33- prefix for Ethernet multicast groups for which there is no
>> MAC multicast protocol (there is no MAC 'join' message like there
>> is an IPv6 'join' REPORT MLD protocol).
>
> Not relevant. The multicast bit being set in the ethernet address
> means that switches will flood it accordingly. IIRC, there is no
> effective difference between multicast and broadcast on the vast
> majority (all) 802 media.

If it's vast majority (all) hardware who are right then specs should no
longer use this multicast concept as an ideal.

> In cases where there is some difference, it’s up to the applicable
> hardware to do the right thing. This applies equally in all cases of
> multicast regardless of which multicast MAC range is used.
>
>> "Transmission of IPv6 packets over XXX _Networks_".  They are not
>> link layers, nor protocols.
>
> RFCs for link type adaptation are relatively common. That’s got
> nothing to do with the mapping of MAC addresses.

There is some misunderstanding here about link layers, networks and
mappings.  But we may clarify later.

>>>>> You also argued about "all 1's" not being Ethernet broadcast.
>>>>> It is defined as exactly that on page 32 here:
>>>>> <http://www.ieee802.org/secmail/pdfocSP2xXA6d.pdf>
>>>>
>>>>> Same here - still looking, but I see only IANA's assertion
>>>>> of ownership based on an RFC. Nothing at the IEEE yet.
>>>>
>>> As others have noted, the link local bit is set, which means it
>>> is covered by IEEE specs as being locally managed.
>>
>> Yes, but this does not stop somebody from sending non-IP messages
>> to 33-33- prefixed MAC dst addresses.  Especially in settings where
>> people dont want IPv6 because of presumably too much overhead.
>
> So what? Your IPv6 stack should never see a non-IPv6 datagram. This
> is no different than the days when we commonly ran Appletalk,
> NetBEUI, IPX, and IP all at the same time on the same networks. It’s
> not like every host had a separate MAC address for each protocol.
>
> The ethernet driver would pass the packet to the correct stack based
> on the ethernet EtherType field if said stack was available on the
> machine. If the machine didn’t have the applicable stack, the packet
> was silently ignored.

Yes, the ethertype helps to avoid some conflicts.  In that sense upper
layer processing would have further discarded, basing their decision on
other fields.  These checks may be consuming though.

There are other collisions that would need to be avoided.

A random generator of MAC addresses like the one used on WiFi on Windows
10 would need to discard output prefixed by 33-33-, such as to avoid
someone using a privacy MAC addresses starting with 33-33-.  It's not
sufficient to just set the L bit.

>> Were IEEE to state "33-33-" is for IPv6 then we'd be sure of no
>> conflict with non-IP protocols.
>
> There’s no conflict anyway. The EtherType field of the ethernet
> header insures this. The IEEE has allocated that number for IPv6 and
> IIRC, it is 0x0800 for IPv4 and 0x86dd for IPv6.
>
>> (though it would be funny for IEEE to consider IPv6 as local
>> opposed to global, while IPv6 too considers IEEE links as link
>> scope as opposed to global Internet).
>

But it's IEEE that should specify a random MAC address generator for
privacy, not IETF, right?

One doesnt want wireshark sniffers along roads to read all cars'
constant MAC addresses passing by.

One doesnt want to expose her constant MAC address to each other hotspot
she visits.

> You seem quite lost in your fundamental understandings here. Perhaps
> it is time to go back and read the Comer books.
>
>>> IP is a payload to 802. What that layer ends up sending out over
>>> the physical media doesn't matter to IP.
>>
>> comes to parameters relevant to IP like MTU, access control…
>
> MTU is not a huge variant and as long as it’s at least 1280, IPv6
> doesn’t really care. The MTU is just a parameter passed up the stack
> which IPv6 adapts to whether the underlying link is 802.X or some
> other medium.

But new specs should not refrain from using larger MTUs if the links
provided them.

It's not because 1998 RFC2464 says that the default MTU size for
Ethernet is 1500bytes that 802.11-OCB should say the same.

Codec methods and their chip implementations evolved in 20 years, such
as where wired Ethernet of 1998 was sending data at 10mbit/s at best,
today wireless 802.11 can go as high as 10gb/s.

> segmentation and reassembly.

I agree with seg/reassembly aspect.

> I’m not sure what you mean by “access control” in an IP context, so
> you’ll have to explain. If you’re talking about things like WPA for
> 802.11, then that is utterly and completely irrelevant to IP and is
> strictly handled by the link configuration before the IP stack is
> ever even started on the interface.

And that link configuration is pre-conditioned by selecting an ESSID. 
The ESSID with strongest signal, the last ESSID used, a pre-recorded 
list of sorted ESSIDs, or interactive user selection from a scroll-down 
list, are all common methods to select an ESSID.  But there's no
link configuration without this ESSID.  It's called "Network Name" in 
many GUIs.

In networks like 802.11-OCB where one can't select an ESSID the entire
link configuration is not happening.  So there is no link.

> Sure, there are a few link level parameters that have to be passed
> back up to the IP stack to allow it to adapt to the underlying link.
> These are generally interface configuration parameters that are
> passed to the IP stack when it is started on the interface.
>

I disagree.

>>> It might, as per the 802-11e doc above. But that's a long way
>>> from necessarily needing a multicast MAC address assignment,
>>> either from the IETF's managed block or directly from the IEEE.
>>> ...
>>
> You still haven’t provided any sort of coherent explanation why IPv6
> over 802.11OCB needs to be meaningfully different than IPv6 over any
> other 802.x link.

Well I am trying to with this ESSID but you seem to not understand what 
an ESSID is and how important is it in setting up 802.11 links.

> If you even need a separate document. So far, nothing you’ve
> explained leads me to believe this is even necessary.

I can further explain if necessary.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jul 2016 16:47:42 +0200

> Link Scope means everything you can reach without crossing a router.

Sounds reasonable, and there may be more characteristics of a link scope 
as thought of in a wired Ethernet.

2. Two link scopes dont overlap, unless they are actually one single
    big link scope.

3. Everyone hears each other within a link scope.

Each one of these 3 characteristics can be unfulfilled in an 802.11-OCB 
network.

> So there is, in fact, a link anywhere there is an interface.

Hm?  But there is a different scope called "interface scope".

> of unique challenges to applications making use of such links, but it
> doesn’t change the fact that there is a link.

But I think applications should not be exposed to these challenges of 
the link.

> to get numbers allocated to them.

Ok, let's see about that later.

> address and the MAC address you should be using.

Yes, but there starts the multicast headache - at MAC layer.

Noted.

The formats you mention make think that:

One couldnt get a scope (a ff0x number) for each centimeter-level radius 
circles around some map point, which is otherwise a perfectly fine GNSS 
resolution these days, and common talk "all taxis in Rose street".

One couldnt get a Group ID (the last X-X-X-X in MAC) for each car kinds.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Jul 2016 07:47:17 -0700

> On Jul 13, 2016, at 07:03, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 

At least some switches make use of MLD snooping and other techniques to optimize flooding. 

> mappings.  But we may clarify later.

If there is, I assure you it is on your end. 

> other fields.  These checks may be consuming though.

The ether type check is not consuming. 

> sufficient to just set the L bit.

Privacy MAC addresses would never conflict because they are Unicast and therefore would not set the multicast bit. Your argument here is nonsensical. 

If it's not IPv6, then ether type field eliminates conflict. If it is IPv6, then it is IPv6 multicast and there is no conflict because that is the Intended use. 

> privacy, not IETF, right?

No. Random privacy addresses also have the locally administered bit set so they are by definition bit IEEE administered. 

IEEE only specifies globally unique OUIs. 

> constant MAC addresses passing by.

I'm not sure how you intend to avoid that. 

> One doesnt want to expose her constant MAC address to each other hotspot

Good luck with that. 

> But new specs should not refrain from using larger MTUs if the links

Sure, but that doesn't require an RFC or any new document. It's just a parameter passed up the stack when IPv6 is started on the interface. 

> Ethernet is 1500bytes that 802.11-OCB should say the same.

Even modern Ethernet has jumbo frames and they work just fine. Default is just that. You can always configure a different value if it is supported by participating implementations. 

> today wireless 802.11 can go as high as 10gb/s.

Your point being?

> And that link configuration is pre-conditioned by selecting an ESSID. The ESSID with strongest signal, the last ESSID used, a pre-recorded list of sorted ESSIDs, or interactive user selection from a scroll-down list, are all common methods to select an ESSID.  But there's no
> link configuration without this ESSID.  It's called "Network Name" in many GUIs.
> 

In conventional 802.11 this is true because IP is not started until a network is associated. However, the defining event is starting the IP stack on the interface. The ESSID and/or AP association are merely a coincidental prerequisite to that start in existing 802.11 implementations. 

Obviously an OCB implementation would require starting the IP stack (and thus the link configuration) without association. 

> link configuration is not happening.  So there is no link.

There's also no ip stack starting so you've got some work to do there. However, once you are starting the IP stack, you'll have link configuration happening, so I'm not sure why you think this is an issue. 

>> to each 802.x style link.

Feel free, but disagreeing with an existing fact (many 802 networks run just fine without their own adaptation layer RFCs) seems rather silly. 

> Well I am trying to with this ESSID but you seem to not understand what an ESSID is and how important is it in setting up 802.11 links.

I understand completely. You are the one who is confused because you are putting a lot of nonexistent meaning on ESSID (and more accurately association) which isn't real. What is real is that existing implementations don't start the IP stack until after association. I took it as a given that you knew this and that you knew OCB would have to start the IP stack without association. 

Perhaps clarifying this will allow you to see things as they are. 

> I can further explain if necessary.

Hopefully you now further understand and further explanation is unnecessary. But feel free to further explain if you think there is something useful to explain. 

Owen

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jul 2016 17:19:53 +0200

Owen,

Le 13/07/2016 à 16:47, Owen DeLong a écrit :
[...]
>> Yes, the ethertype helps to avoid some conflicts.  In that sense
>> upper layer processing would have further discarded, basing their
>> decision on other fields.  These checks may be consuming though.
>

It depends how fast one wants it done.

>> A random generator of MAC addresses like the one used on WiFi on
>> Windows 10 would need to discard output prefixed by 33-33-, such
>> as to avoid someone using a privacy MAC addresses starting with
>> 33-33-.  It's not sufficient to just set the L bit.
>
> Privacy MAC addresses would never conflict because they are Unicast
> and therefore would not set the multicast bit. Your argument here is
> nonsensical.

Right, that's true.  Privacy MAC addresses would have the unicast bit set.

[...]
> I'm not sure how you intend to avoid that.

For privacy reasons people dont want others know their car was there at
that time.  (dont expose the OUI, dont expose always same MAC).

>> One doesnt want to expose her constant MAC address to each other
>> hotspot she visits.
>
> Good luck with that.

You mean Apple is not doing that already?

[...]

>> But new specs should not refrain from using larger MTUs if the
>> links provided them.
>
> Sure, but that doesn't require an RFC or any new document. It's just
> a parameter passed up the stack when IPv6 is started on the
> interface.

It's not the MTU alone which requires a new document, it's many other
things that we discussed, not the least important being that RFC2464
that everybody seems to love is outdated.

> Even modern Ethernet has jumbo frames and they work just fine.
> Default is just that. You can always configure a different value if
> it is supported by participating implementations.

If you want to configure some other MTU one has to go to the router and
configure it in the RA, make sure you put in the MTU variable some value
safely understood by each past present and future neighbor - it's a pain.

>> Codec methods and their chip implementations evolved in 20 years,
>> such as where wired Ethernet of 1998 was sending data at 10mbit/s
>> at best, today wireless 802.11 can go as high as 10gb/s.
>>
>
> Your point being?

RFC2464 is outdated.

[...]
>>> I’m not sure what you mean by “access control” in an IP context,
>>> so you’ll have to explain. If you’re talking about things like
>>> WPA for 802.11, then that is utterly and completely irrelevant
>>> to IP and is strictly handled by the link configuration before
>>> the IP stack is ever even started on the interface.
>>
>> And that link configuration is pre-conditioned by selecting an
>> ESSID. The ESSID with strongest signal, the last ESSID used, a
>> pre-recorded list of sorted ESSIDs, or interactive user selection
>> from a scroll-down list, are all common methods to select an
>> ESSID. But there's no link configuration without this ESSID.  It's
>> called "Network Name" in many GUIs.
>>
>
> In conventional 802.11 this is true because IP is not started until
> a network is associated. However, the defining event is starting the
> IP stack on the interface. The ESSID and/or AP association are merely
> a coincidental prerequisite to that start in existing 802.11
> implementations.
>
> Obviously an OCB implementation would require starting the IP stack
> (and thus the link configuration) without association.

True, but there is additional operation in 802.11-OCB.

In 802.11-OCB one has to first manually select one of 6 channels on the 
Host precisely the same as on the Router.  Then put the interface up and 
the IP stack gets configured if it receives a Router Advertisement.

In a lab setting that's all.

In a road setting a car receives RAs from multiple Routers in that 
channel; it has no idea which one is a car, an LTE car, or a road-side 
unit giving access to Internet.

This car obviously shouldnt self-configure an address and default route 
from each of the received RAs.

This problem does not exist in other 802.11-X: the computer 
self-configures an address and a default route only from the RA received 
from the router on the same ESSID.  The admin makes sure there is only 
one router on that ESSID.

Do not think a channel is same as ESSID: whereas one can create an 
unlimited number of ESSIDs the channels are regulated to be only 6 (and 
only 1 really powerful).

>> In networks like 802.11-OCB where one can't select an ESSID the
>> entire link configuration is not happening.  So there is no link.
>
> There's also no ip stack starting so you've got some work to do
> there. However, once you are starting the IP stack, you'll have link
> configuration happening, so I'm not sure why you think this is an
> issue.

Because the link configuration that is happening:

1. has to be preceded by manual selection of a channel.  There is no
    automation of this selection like there is automated ESSID
    selection with user-preferences, last network, or strongest signal.

2. leads to links with an unmanaged number of prefixes and default
    routers on them.  The number can not be managed like it is managed
    by admins setting ESSIDs and routers on them.

[...]
>>> You still haven’t provided any sort of coherent explanation why
>>> IPv6 over 802.11OCB needs to be meaningfully different than IPv6
>>> over any other 802.x link.
>>
>> Well I am trying to with this ESSID but you seem to not understand
>> what an ESSID is and how important is it in setting up 802.11
>> links.
>
> I understand completely. You are the one who is confused because you
> are putting a lot of nonexistent meaning on ESSID (and more
> accurately association) which isn't real. What is real is that
> existing implementations don't start the IP stack until after
> association. I took it as a given that you knew this and that you
> knew OCB would have to start the IP stack without association.
>

In networks where ESSIDs are used the number of Routers and what gets 
advertised is limited by sysadmins within the scope of a unique ESSID.

Without that the WiFi networks would be a complete mess.

Alex

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Jul 2016 08:21:49 -0700

> On Jul 13, 2016, at 07:47, Alexandre Petrescu <[email-masked]> wrote:
> 
> 
> 
> Sounds reasonable, and there may be more characteristics of a link scope as thought of in a wired Ethernet.
> 
This is usually, though not always true, but you cannot count on it. 

> 3. Everyone hears each other within a link scope.

By definition. 

> Each one of these 3 characteristics can be unfulfilled in an 802.11-OCB network.
> 

Nope. Not true. Item 2 isn't actually valid, even in some wired Ethernet cases (think PVLAN implementations for example). 

Item 1 and 3 apply equally to OCB. The difference is that the members of any given link are far more transient in OCB than in most 802.11 implementations. While that may pose unique challenges to applications running over IPv6 over OCB, it doesn't change the existence of not the behavior of a link. 

> Hm?  But there is a different scope called "interface scope".

Yes... The interface scope only reaches applications listening on the same interface on the local host. It never actually departs the machine.

> But I think applications should not be exposed to these challenges of the link.

How would you avoid it? When a laptop leaves an 802.11ac network, the other hosts on that link are no longer able to communicate with it there. 

I presume it would be the same for an OCB network. 

> Yes, but there starts the multicast headache - at MAC layer.

Huh?

What headache?

> One couldnt get a scope (a ff0x number) for each centimeter-level radius circles around some map point, which is otherwise a perfectly fine GNSS resolution these days, and common talk "all taxis in Rose street".

I doubt that IETF will use up slots in a 16-slot space for such silliness, but submit an ID if you think that's useful. 

> One couldnt get a Group ID (the last X-X-X-X in MAC) for each car kinds.

Presumably, one could, but I suspect if you want to do that, you'll need to use local group IDs. 

Owen

---

From: Owen DeLong <[email-masked]>
Date: Wed, 13 Jul 2016 08:38:21 -0700

> On Jul 13, 2016, at 08:19, Alexandre Petrescu <[email-masked]> wrote:
> 
> Owen,
> 

It happens in the minter face hardware in most cases. In other cases, the lookup table time to determine which networking stack to pass the payload to is identical whether the packet is passed to another protocol or not. In most cases, we are talking sub-microsecond. 

> that time.  (dont expose the OUI, dont expose always same MAC).

I understood the desire the first time. 

It doesn't change my statement as an appropriate ND search will elicit the needed response for detection regardless. 

> You mean Apple is not doing that already?

All hosts I know of which implement privacy addresses will still respond to ND for their persistent EUI-64 address also. 

If I'm roadside, I can search a 24-bit space fairly frequently with just a few stations. 

The total ND space is only 24 bits.

> that everybody seems to love is outdated.

The fact that everything still works even with 2464 being so out of date rather proves my point.if you feel an update is important or even useful, submit an ID. 

> safely understood by each past present and future neighbor - it's a pain.

So?

>>> at best, today wireless 802.11 can go as high as 10gb/s.

Then submit an ID to update it. 

> In 802.11-OCB one has to first manually select one of 6 channels on the Host precisely the same as on the Router.  Then put the interface up and the IP stack gets configured if it receives a Router Advertisement.
> 
> In a road setting a car receives RAs from multiple Routers in that channel; it has no idea which one is a car, an LTE car, or a road-side unit giving access to Internet.
> 
> This car obviously shouldnt self-configure an address and default route from each of the received RAs.
> 
> This problem does not exist in other 802.11-X: the computer self-configures an address and a default route only from the RA received from the router on the same ESSID.  The admin makes sure there is only one router on that ESSID.
> 
> Do not think a channel is same as ESSID: whereas one can create an unlimited number of ESSIDs the channels are regulated to be only 6 (and only 1 really powerful).

Clearly this is a challenge in your application, but it has nothing to do with IP. This challenge would exist in your application regardless of the layer three protocol. 

>   selection with user-preferences, last network, or strongest signal.

That's a problem in your choice of technologies. It doesn't change the existence or concept of a link or the mapping of multicast to MAC.

>   by admins setting ESSIDs and routers on them.

See above. 

You have made design decisions which are problematic and now you seem to think IETF should somehow alter the nature of IPv6 to overcome the difficulties you have created for yourself with your existing design decisions. 

> In networks where ESSIDs are used the number of Routers and what gets advertised is limited by sysadmins within the scope of a unique ESSID.
> 

Seems to be an argument as to why OCB is a particularly poor design decision for your application, but it's your design decision. You get the trade offs that come with it on both sides. 

Owen

---

From: Mark Smith <[email-masked]>
Date: Tue, 19 Jul 2016 15:09:47 +1000

Hi,

>>  rather than opaquely using the MAC that results.

<snip>

> few nearby cars, site scope to be the scope between one platoon, and so on.

No specific to above, however related.

I think it is better to avoid using generic "all node" IPv6 addresses
if possible, and instead use a function specific multicast address.

While I don't really like the layer violation, function specific IPv6
multicast addresses can more easily facilitate IPv6 packet filtering
at layer 2, because the IPv6 addresses are in a fixed location in the
frame, meaning the layer 2 device doesn't have to do as much
frame/packet parsing to perform IPv6 packet filtering.

For  example, as All_DHCP_Relay_Agents_and_Servers in DHCPv6 has
exclusive use of the FF02::1:2 multicast address, a simple way to
implement DHCPv6 guard would be to prevent any packets to those
multicast addresses being flooded to layer 2 device egress ports that
are not configured as attached to link authorised DHCPv6 servers.

RA Guard in part can be implemented that way - RSes are sent to the
All Routers (FF01::2) multicast address, so the layer 2 device could
control the flooding of those to only authorised ports attached to
authorised routers.

However, RAs are sent to the all nodes multicast address that isn't
exclusive to all Router clients. That means it wouldn't be possible to
apply an ingress layer 2 port filter to drop RAs from rogue routers.
Ideally, there would have been an "All router clients" specific
multicast address instead that RAs were sent to, that could have
facilitated ingress layer 2 filtering. (DHCPv6 doesn't have this
problem because DHCPv6 servers and relays don't periodically announce
themselves.)

It is probably wasteful to use function specific multicast addresses
for all functions/applications that somebody might want to filter in a
layer 2 device, as they're in effect encoding upper layer identifiers
such as UDP ports or ICMP types in addresses. Use of functional
multicast addresses could be limited to fundamental IPv6 operations
that might be typical of what people might want to filter in layer 2
devices.

Regards,
Mark.

> Alex
>
>>
>> Joe
>>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Joe Touch <[email-masked]>
Date: Tue, 19 Jul 2016 08:47:32 -0700

On 7/18/2016 10:09 PM, Mark Smith wrote:
...
> exclusive to all Router clients.

There is already a multicast address for "all routers".

>  That means it wouldn't be possible to
> multicast address 
"all router clients" == "all hosts", which already has a multicast address.

> instead that RAs were sent to, that could have

There are already quite a few of these. The key is that they are mapped
to *protocols* or *protocol node classes* (host/router).

Joe

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Jul 2016 08:26:03 +1000

> There is already a multicast address for "all routers".

RAs from rogue routers are sent to the all nodes IPv6 multicast address.
You can't block that address on layer 2 port ingress from non-router ports
without breaking anything else that might legitimately use the all nodes
IPv6 multicast address (off the top of my head, all nodes ping).

However, if RAs were sent to a RA specific multicast group, then dropping
on ingress based on that RA specific multicast destination address would
only drop rogue RAs and nothing else.

The current way to implement RA guard is to have to look deeper into the
all nodes packet to see if it is an RA or not. Matching on a RA specific
destination multicast address would be much simpler, and something I think
that could be done in TCAM because of the exact match on and fixed location
of the IPv6 DA in the frame.

Regards,
Mark.

---

From: Gert Doering <[email-masked]>
Date: Wed, 20 Jul 2016 13:46:16 +0200

Hi,

> of the IPv6 DA in the frame.

While I like that idea, it would also only work if target hosts would
refuse to accept a RA that is not destined to this "all-RA-clients"
multicast address.

How well such assumptions work can be seen with the recent router ND issue 
where routers happily received and processed ND packets with TTL != 255, in
violation of the standards, and the fe80:: issue where routers happily
forward fe80::-sourced packets...

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Mark Smith <[email-masked]>
Date: Wed, 20 Jul 2016 22:05:22 +1000

> refuse to accept a RA that is not destined to this "all-RA-clients"

Sure. I'm not saying it is feasible to implement now with RAs, more using
it as an example of a limitation of using the all nodes multi address.

So if something is being invented where multicasting to all nodes is
performed, I think it is worth considering and perhaps preferring a
function specific multicast address instead so that specific filtering or
classification by just using the destination multicast address can be
performed.

Regards,
Mark.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 20 Jul 2016 06:50:19 -0700

> On Jul 20, 2016, at 04:46 , Gert Doering <[email-masked]> wrote:
> 
> Hi,
> 

That’s problematic because some legitimate RAs can be unicast to the
targets unicast LL address in response to an RS from the target in question.

> forward fe80::-sourced packets…

We definitely should be trying to solve these problems wherever possible.

Owen