Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet"

From: "Toerless Eckert (eckert)" <[email-masked]>
Date: Sun, 17 Jul 2016 12:18:54 +0000

3333 is for ipv6 multicast. That other address mentioned in the thread is probably for isis, which does not use ip/ipvt

typos = smartphone

On Jul 8, 2016 8:32 AM, Jen Linkova <[email-masked]> wrote:
On Fri, Jul 8, 2016 at 4:49 PM, Alexandre Petrescu
<[email-masked]> wrote:
>>> RFC2464 "IPv6 over Ethernet" says:
>>>> 7.  Address Mapping -- Multicast
>>>>
>>>> An IPv6 packet with a multicast destination address DST, consisting
>>>> of the sixteen octets DST[1] through DST[16], is transmitted to the
>>>> Ethernet multicast address whose first two octets are the value 3333
>>>> hexadecimal and whose last four octets are the last four octets of
>>>> DST.
>>>
>>>
>>> Where is this "3333" value defined?  Obviously an RFC is not the place to
>>> define an Ethernet multicast address.
>>
>>
>> https://tools.ietf.org/html/rfc5342#section-2.3.1
>>
>> Please note that it has 'local; bit set so that OUI range (33-33-XX
>> did not need to be purchased).
>
>
> Why isn't this address listed by IEEE "GROUP MAC PUBLIC LISTING"?
> https://standards.ieee.org/develop/regauth/grpmac/public.html

> Why IEEE lists _other_ addresses that can be used for same role:
> 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542
> "All Multicast Capable Intermediate Systems Address"

Because the OUI 33-33- is *locally administered* (it has the Local bit set).
It is not allocated by any registry. The link you are referring to
lists addresses
from the Universally Administered Address Block.

> RFC5342 says:
>>
>>   All MAC-48 multicast identifiers prefixed "33-33" (that is, the 2**32
>>    multicast MAC identifiers in the range from 33-33-00-00-00-00 to
>>    33-33-FF-FF-FF-FF) are used by the IETF for global IPv6 multicast
>>    [RFC2464].
>
>
> What does "global IPv6 multicast" mean?  The term "global" is misleading
> because of that 'local' bit set you said above, and because RFC2464 is
> happening only on a link.  Maybe it meant "IPv6 multicast"?
>
> Why does it refer to RFC2464?  RFC2464 is only for Ethernet, not for other
> kinds of links.
>
> It reads as if all Internet-connected nodes were on Ethernet and as if any
> IP multicast address could be mapped into the 32bits left of a MAC multicast
> address (they cant - they are 112bit length).

AFAIR  RFC3307 has some recommendations on how to minimize the chance
of address collision.

--
SY, Jen Linkova aka Furry

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 19 Jul 2016 18:17:08 +0200

Thanks for the reply.

I could not find "C9" or "multicast" in ISIS IPv6 RFC5308.  Is there a 
reference RFC for the ISIS use of it.

(the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC 9542
  "All Multicast Capable Intermediate Systems Address")

Alex

Le 17/07/2016 à 14:18, Toerless Eckert (eckert) a écrit :
> 3333 is for ipv6 multicast. That other address mentioned in the thread
> is probably for isis, which does not use ip/ipvt
>
> typos = smartphone
>

---

From: Hemant Singh <[email-masked]>
Date: Tue, 19 Jul 2016 18:40:01 -0400

As others have said, it's rfc2464 that mentions the multicast mac first two
octects for IPv6 multicast traffic.  One should not expect the same for
IS-IS because IS-IS is a link-layer routing protocol.  From day one, IS-IS
defines the two multicast mac-address for use with link-layer multicast.

Hemant

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 11:49:59 +0200

Le 20/07/2016 à 00:40, Hemant Singh a écrit :
> As others have said, it's rfc2464 that mentions the multicast mac
> first two octects for IPv6 multicast traffic.

The problem is that that RFC has no authority outside the group of IP
users.  Nobody reads it other than people who use IP.

That means the non-IP people can use 33-33- multicast group without
worrying to clash anything.  They set the L local bit just like anybody 
else.

Where IPv6 to use a multicast address within the IANA OUI 01-00-5E- (not 
the C9 of IS-IS) then there would be no such risk: IEEE assigns that OUI 
to IETF, IETF is sure to be alone on it, it has no L bit set.

> One should not expect the same for IS-IS because IS-IS is a
> link-layer routing protocol.  From day one, IS-IS defines the two
> multicast mac-address for use with link-layer multicast.

Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in addition 
to that C9).

Alex

>
> Hemant
>
> On Tue, Jul 19, 2016 at 12:17 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> Thanks for the reply.
>
> I could not find "C9" or "multicast" in ISIS IPv6 RFC5308.  Is there
> a reference RFC for the ISIS use of it.
>
> (the other address is 01-80-C2-00-00-1D ISO/IEC JTC1/SC6 ISO/IEC
> 9542 "All Multicast Capable Intermediate Systems Address")
>
> Alex
>
>
>
>
>
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6

---

From: Hemant Singh <[email-masked]>
Date: Wed, 20 Jul 2016 08:52:15 -0400

On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu <
[email-masked]> wrote:
>
>
> >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in addition to
> that C9).

No.  For Level-1 adjacencies, the packets are sent to 01-80-C2-00-00-14,
and for Level-2 adjacencies, the packets are sent to 01-80-C2-00-00-15

Hemant

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 20 Jul 2016 19:24:47 +0200

Can IS-IS run on IPv6 and if so which MAC multicast address?

Alex

Le 20/07/2016 à 14:52, Hemant Singh a écrit :
>
>
> On Wed, Jul 20, 2016 at 5:49 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     >Does IS-IS also make use of 01-00-5E- multicast IANA OUI? (in
>     addition to that C9).
>
>

---

From: Hemant Singh <[email-masked]>
Date: Wed, 20 Jul 2016 20:23:37 -0400

Please read rfc 5308 and also rfc1195.  Many folks have already said IS-IS
does not run at the IP layer and thus the question does not arise if IS-IS
runs on IPv6.  IS-IS is extensible in that it uses TLV's to support IPv4
and IPv6 adjacency information between routing peers.   IS-IS running at
the link layer decided long time back to use two mac-addresses to multicast
messages to.

We should stop chasing IS-IS for any rfc2460bis or other rfc bis and any
multicast IPv6 mac discussion.

Hemant

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Jul 2016 10:25:11 +0200

Le 21/07/2016 à 02:23, Hemant Singh a écrit :
> Please read rfc 5308 and also rfc1195.  Many folks have already said
> IS-IS does not run at the IP layer and thus the question does not
> arise if IS-IS runs on IPv6.  IS-IS is extensible in that it uses
> TLV's to support IPv4 and IPv6 adjacency information between routing
> peers. IS-IS running at the link layer decided long time back to use
> two mac-addresses to multicast messages to.

That's fine.

> We should stop chasing IS-IS for any rfc2460bis or other rfc bis and
> any multicast IPv6 mac discussion.

Misunderstanding.

I am not chasing IS-IS, but I point out that IS-IS seems to be using a
globally unique (OUI) for its MAC multicast addresses, even though IS-IS
is obviously a local protocol.  This MAC address is allocated at IEEE
and noted at IANA.

And, on the other hand, IPv6 global protocol seems to be using a
'locally administered' MAC multicast address (no OUI), which is not
allocated by IEEE in any way; it is however noted at IANA.

In other words: why IS-IS deserves an OUI whereas IPv6 gets along with
only a locally-administered MAC?  That's not normal.

Alex

>
>
> Hemant
>
>
> On Wed, Jul 20, 2016 at 1:24 PM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>
> <mailto:[email-masked]
> <mailto:[email-masked]>>> wrote:
>
>
> No.  For Level-1 adjacencies, the packets are sent to
> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are sent
> to 01-80-C2-00-00-15
>
> Hemant
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 21 Jul 2016 11:02:10 +0200

IS-IS is not an IETF protocol but an OSI ISO one.

Regards

[email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 11:09:48 +0200 (CEST)

> multicast IPv6 mac discussion.

I agree. So whilst there are implementations of ISIS that run over either 
IP or UDP-in-IP, and there is draft text that describe this, I don't think 
this is anything that needs to be brought up in 2460bis context.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 21 Jul 2016 11:11:59 +0200 (CEST)

> IS-IS is not an IETF protocol but an OSI ISO one.

Since there is an active IETF working group called "isis" that actively 
develops ISIS related standards using IETF RFC process, I would argue the 
opposite.

Yes, ISIS started in OSI, but most of all implementations now implement 
ISIS protocol mechanisms based on documents that are handled by IETF.

---

From: Karsten Thomann <[email-masked]>
Date: Thu, 21 Jul 2016 11:23:58 +0200

> > any multicast IPv6 mac discussion.
Support

> is obviously a local protocol.  This MAC address is allocated at IEEE

IS-IS has no OUI, it has reserved MAC addresses from a special purpose range, 
take a look at http://standards.ieee.org/develop/regauth/grpmac/public.html
for assignements from that range.

I didn't understand the meaning of "local protocol" in your sentence.

> allocated by IEEE in any way; it is however noted at IANA.
As I've already written in another mail, that are completely different layers.
The IEEE allows free use of MAC adresses if the locally administered bit is 
set. 

> only a locally-administered MAC?  That's not normal.
Short answer: History.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 21 Jul 2016 16:54:25 +0200

Le 21/07/2016 à 11:23, Karsten Thomann a écrit :
>>> Please read rfc 5308 and also rfc1195.  Many folks have already
>>> said IS-IS does not run at the IP layer and thus the question
>>> does not arise if IS-IS runs on IPv6.  IS-IS is extensible in
>>> that it uses TLV's to support IPv4 and IPv6 adjacency information
>>> between routing peers. IS-IS running at the link layer decided
>>> long time back to use two mac-addresses to multicast messages
>>> to.
>>
>> That's fine.
>>
>>> We should stop chasing IS-IS for any rfc2460bis or other rfc bis
>>> and any multicast IPv6 mac discussion.
> Support
>
>>
>> Misunderstanding.
>>
>> I am not chasing IS-IS, but I point out that IS-IS seems to be
>> using a globally unique (OUI) for its MAC multicast addresses, even
>> though IS-IS is obviously a local protocol.  This MAC address is
>> allocated at IEEE and noted at IANA.
>
> IS-IS has no OUI, it has reserved MAC addresses from a special
> purpose range, take a look at
> http://standards.ieee.org/develop/regauth/grpmac/public.html for
> assignements from that range.
>

By 'local protocol'  I mean that it happens locally in closed
environments.  I can't send send an IS-IS packet from here to Japan, as
I would do with ping6 for example.

>> 'locally administered' MAC multicast address (no OUI), which is
>> not allocated by IEEE in any way; it is however noted at IANA.
> As I've already written in another mail, that are completely
> different layers. The IEEE allows free use of MAC adresses if the
> locally administered bit is set.

Yes, and the address for 01-80-C2- for IS-IS does not have that
'locally-administered' bit set.  I.e. it's a 'globally unique' (OUI
enforced) even though IS-IS is more of a local nature (cant send packets
to Japan as I do with ping6).

It's maybe a stretch, but that's how I see it.

>> In other words: why IS-IS deserves an OUI whereas IPv6 gets along
>> with only a locally-administered MAC?  That's not normal.
> Short answer: History.

That's fine.

Alex

>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>>
>>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets are
>>> sent to 01-80-C2-00-00-15
>>>
>>> Hemant
>>
>> [email-masked] Administrative Requests:

---

From: Karsten Thomann <[email-masked]>
Date: Fri, 22 Jul 2016 11:22:05 +0200

Hi,

Am Donnerstag, 21. Juli 2016, 16:54:25 CEST schrieb Alexandre Petrescu:
> > Am Donnerstag, 21. Juli 2016, 10:25:11 CEST schrieb Alexandre
> > 
> > Petrescu:
Yes and No.
CLNS isn't really used anymore to transport anything except IS-IS, but 
technically within a global backbone which uses IS-IS you can reach every 
router within the network via e.g. clns ping to the ISO address of the other 
router. As the ISO protocol family lost the protocal "war" against IP, there 
is simply no interdomain connectivity left to get CLNS packets from one 
carrier to another.

> It's maybe a stretch, but that's how I see it.
As I explained above, CLNS was "global" and there were times where it was 
possible to reach big parts of the World via CLNS beneath IP.
I highly recommend to read something about the history of IP and ISO 
protocols, I don't know where I read about it, but a short version is at 
http://spectrum.ieee.org/computing/networks/osi-the-internet-that-wasnt

As Stig Venaas already wrote in the other thread, the multicast addresses from 
33-33 are used as a link local optimization to allow the host to discard 
unwanted multicast traffic at the MAC layer, instead of the IP Layer.

> >>> <mailto:[email-masked]>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 22 Jul 2016 12:39:05 +0200

Le 22/07/2016 à 11:22, Karsten Thomann a écrit :
>>>>> Please read rfc 5308 and also rfc1195.  Many folks have
>>>>> already said IS-IS does not run at the IP layer and thus the
>>>>> question does not arise if IS-IS runs on IPv6.  IS-IS is
>>>>> extensible in that it uses TLV's to support IPv4 and IPv6
>>>>> adjacency information between routing peers. IS-IS running at
>>>>> the link layer decided long time back to use two
>>>>> mac-addresses to multicast messages to.
>>>>
>>>> That's fine.
>>>>
>>>>> We should stop chasing IS-IS for any rfc2460bis or other rfc
>>>>> bis and any multicast IPv6 mac discussion.
>>>
>>> Support
>>>
>>>> Misunderstanding.
>>>>
>>>> using a globally unique (OUI) for its MAC multicast addresses,
>>>> even though IS-IS is obviously a local protocol.  This MAC
>>>> address is allocated at IEEE and noted at IANA.
>>>
>> environments.  I can't send send an IS-IS packet from here to
>> Japan, as I would do with ping6 for example.
> Yes and No. CLNS isn't really used anymore to transport anything
> except IS-IS, but technically within a global backbone which uses
> IS-IS you can reach every router within the network via e.g. clns
> ping to the ISO address of the other router. As the ISO protocol
> family lost the protocal "war" against IP, there is simply no
> interdomain connectivity left to get CLNS packets from one carrier to
> another.

So that's local in the ISO protocol family.

>>>> And, on the other hand, IPv6 global protocol seems to be using
>>>> a 'locally administered' MAC multicast address (no OUI), which
>>>> is not allocated by IEEE in any way; it is however noted at
>>>> IANA.
>>>
>>> different layers. The IEEE allows free use of MAC adresses if
>>> the locally administered bit is set.
>>
>> 'locally-administered' bit set.  I.e. it's a 'globally unique'
>> (OUI enforced) even though IS-IS is more of a local nature (cant
>> send packets to Japan as I do with ping6).
>>
> As I explained above, CLNS was "global"

That would be global in geographical terms, but not global in
universality terms as IP is.  That makes CLNS local.

> and there were times where it was possible to reach big parts of the
> World via CLNS beneath IP. I highly recommend to read something about
> the history of IP and ISO protocols, I don't know where I read about
> it, but a short version is at

I will read that some time.

The problem is not only to reach a very far point (Japan) but also to 
start from here.  I.e. use my laptop on wifi to ping Japan - that is 
global reach. (or otherwise see the tortue dancing on kame.net)

Everything else is local.

That's why I continue to think that if a local protocol like IS-IS 
deserves a global OUI for its MAC multicast addressing then a global 
protocol like IPv6 deserves that even more.  33-33- is not such.

>  As Stig Venaas already wrote in the other thread, the multicast
> addresses from 33-33 are used as a link local optimization to allow
> the host to discard unwanted multicast traffic at the MAC layer,
> instead of the IP Layer.

Ok.

Alex

>
>>
>>>> In other words: why IS-IS deserves an OUI whereas IPv6 gets
>>>> along with only a locally-administered MAC?  That's not
>>>> normal.
>>>
>>> Short answer: History.
>>
>> That's fine.
>>
>> Alex
>>
>>>> Alex
>>>>
>>>>> Hemant
>>>>>
>>>>>
>>>>> 01-80-C2-00-00-14, and for Level-2 adjacencies, the packets
>>>>> are sent to 01-80-C2-00-00-15
>>>>>
>>>>> Hemant
>>>>