Subject: Fwd: New Version Notification for draft-bchv-rfc6890bis-00.txt

From: Brian Haberman <[email-masked]>
Date: Fri, 1 Jul 2016 11:39:07 -0400

All,
     This draft is intended to fix the issue raised by Brian Carpenter
with respect to the IANA special-purpose address registries. It
incorporates the proposed change that updates the ULA entry in the
registry and adds a reference to find more info on the prefix.

     Comments/suggestions are encouraged.

Regards,
Brian

-------- Forwarded Message --------
Subject: New Version Notification for draft-bchv-rfc6890bis-00.txt
Date: Fri, 01 Jul 2016 08:36:41 -0700
From: [email-masked]
To: Ronald Bonica <[email-masked]>, Michelle Cotton
<[email-masked]>, Brian Haberman <[email-masked]>,
Leo Vegoda <[email-masked]>, Ron Bonica <[email-masked]>,
Michelle S. Cotton <[email-masked]>

A new version of I-D, draft-bchv-rfc6890bis-00.txt
has been successfully submitted by Brian Haberman and posted to the
IETF repository.

Name:		draft-bchv-rfc6890bis
Revision:	00
Title:		Special-Purpose IP Address Registries
Document date:	2016-07-01
Group:		Individual Submission
Pages:		22
URL:
https://www.ietf.org/internet-drafts/draft-bchv-rfc6890bis-00.txt
Status:         https://datatracker.ietf.org/doc/draft-bchv-rfc6890bis/
Htmlized:       https://tools.ietf.org/html/draft-bchv-rfc6890bis-00

Abstract:
   This memo updates the IANA IPv6 Special-Purpose Address Registries to
   address issues raised by the definition of a global prefix.  For
   completeness, this memo contains all the assignments made by RFC 6890
   to the IANA Special-Purpose Address Registries.

   This memo obsoletes RFC 6890.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

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

Hello,

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.

Alex

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Jul 2016 16:20:47 +0200

On Fri, Jul 8, 2016 at 3:56 PM, Alexandre Petrescu
<[email-masked]> wrote:
> 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).

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

-- 
SY, Jen Linkova aka Furry

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jul 2016 16:49:22 +0200

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

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

Alex

---

From: Jen Linkova <[email-masked]>
Date: Fri, 8 Jul 2016 17:31:32 +0200

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 8 Jul 2016 18:16:37 +0200

> from the Universally Administered Address Block.

Ah!  I see, ok.

Still, it looks too much like an allocation.  Maybe it should be at 
IANA, not in RFC.  And the doubt about IETF allocating MAC addresses 
still holds in my mind.

For example, can some non-IP protocol use "33-33-" to transmit non-IP 
datagrams to multicast MAC destinations?  If no, is it because it 
belongs somehow to IETF?

An example non-IP message is WSMP or CAM/DENM which get transmitted over 
802.11p without IP headers.  Currently they dont use "33-33-" as dst MAC 
address, but use "ff-ff-".

I guess that in your logic, if "33-33-"  is used then it can only be 
IPv6 and, reversely, if IPv6 is used then that could only be with "33-33-".

I could agree with this logic if this "33-33-" address where considered 
in many other SDO documents, not just RFC.

> AFAIR  RFC3307 has some recommendations on how to minimize the chance

Ok... but they are all for IPv6 multicast addresses, not for MAC 
multicast addresses.

It's next to impossible to make sure "33-33-" will not collide with some 
other organization using the same "33-33-" but without IP.

Alex

---

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

On Fri, Jul 8, 2016 at 6:16 PM, Alexandre Petrescu
<[email-masked]> wrote:
> Still, it looks too much like an allocation.  Maybe it should be at IANA,
> not in RFC.  And the doubt about IETF allocating MAC addresses still holds
> in my mind.

I'm afraid we begin to discuss nuances of what the word 'allocation' means.
There is a global registry and if you want a globally unique MAC
addresses - you can pay and
get an OUI. Or you can assign the MAC address yourself (with Local bit
set to 1) but that address has no guarantee of being unique.

> datagrams to multicast MAC destinations?  If no, is it because it belongs
> somehow to IETF?

I can not see why it can not. It might be the wisest decision as I'd
expect some implementations bugs to strike back..

> I guess that in your logic, if "33-33-"  is used then it can only be IPv6

Not at all. What makes you think that '33-33' can be only used by
IPv6? 33-33- has Local bit set, which means
'that MAC address was not assigned from the global pool of unique
addresses but was assigned by a local administrator'.
Someone else can pick up the same address.

> and, reversely, if IPv6 is used then that could only be with "33-33-".

I'd say 'SHOULD'. Because it is possible that multicast IPv6 packet
may have unicast MAC address (see
https://tools.ietf.org/html/rfc6085).
However if we are talking about multicast MACs - so far the standard
defines the only way (AFAIK) of choosing the destination MAC so
I'd expect the implementations following the standards to use 33-33.

> I could agree with this logic if this "33-33-" address where considered in
> many other SDO documents, not just RFC.

> Ok... but they are all for IPv6 multicast addresses, not for MAC multicast
> addresses.

Yes, but the idea is 'how to choose your IPv6 mcast addresses to
minimize the collision of the resulting MAC addresses'.

> other organization using the same "33-33-" but without IP.

Absolutely, '33-33-*' might not be globally unique. Someone (who has
never heard about how IPv6 works...) might decide to use 33-33- for
their new shiny protocol. However I'm not sure why it matters so much
if 33-33 is used for IPv6 multicast only. Nothing prevents you from
sending various protocols over Ethernet, so the host should be able to
look at ethertype and find out what is inside. (there will be broken
implementations indeed so that's why if I were developing a new
protocol today I'd rather refrain away from using MAC addresses
33-33-*)

---

From: Francis Dupont <[email-masked]>
Date: Sun, 10 Jul 2016 16:29:25 +0200

>  to define an Ethernet multicast address.

=> in the RFC you cited. Two remarks:
 - 3 means local (so it can be defined where you want) and multicast.
 - this was introduced before the 33rd IETF (I remembered I had to
  update one of two IPv6 implementations for this 3333 in the IPv6
  over Ethernet show during this IETF, nearly 21 years ago).

Regards

[email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 11 Jul 2016 14:35:00 +0200

Hi Francis,

Thanks for the reply.

>  - 3 means local (so it can be defined where you want) and multicast.

Ok - 3 00000011 means 'local' and 'multicast'.
      Could have also been 7 or 15.

>   over Ethernet show during this IETF, nearly 21 years ago).

Ah, that's why 3333!

I wonder whether at that time existed the allocation of 01-00-5E-
MAC global multicast addresses managed by IANA.
http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml#ethernet-numbers-1

Alex

---

From: Francis Dupont <[email-masked]>
Date: Mon, 11 Jul 2016 18:21:00 +0200

>  MAC global multicast addresses managed by IANA.

=> 01:00:5e was far before IPv6 and as far as I can remember this was
used before 33:33 was specified (the 00 I-D was published the
July 16, 1995) so just before the IETF meeting... Note that according
to my archives the idea to use 33:33 was from June 95:

(to identify the message I selected these lines from the header)

To: [email-masked]
Subject: (IPng 192) IPv6 ethertype, multicast address mapping, etc.
Date: Fri, 16 Jun 1995 18:32:30 PDT
From: Steve Deering <[email-masked]>
Message-Id: <[email-masked]> 
...

On another Ethernet-related topic, we have never specified how IPv6 multicast
addresses are to be mapped to Ethernet multicast addresses.  I believe that
some of the prototype IPv6 implementations are curently using the same
mapping as IPv4, that is, replacing the low-order 23 bits of the ethernet
address 01-00-5E-00-00-00 with the low-order 23 bits of the IP multicast
address.  It would be nice to use a slightly more efficient mapping for
IPv6 (extracting 23 bits is sorta fiddly).  I propose the following:

        replace the low-order 32 bits of the ethernet address
        33-33-00-00-00-00 with the low-order 32 bits of the
	IPv6 multicast address.

The 33-33- prefix has both the Group (Multicast) bit set and the Locally
Administered bit set. (They are the lowest-order and second lowest-order
bits, respectively, of the first octet, in the canonical address
representation.)  It would be more politically correct to use a
Universally Administered prefix, but those are handed out by the IEEE
at $1000 per 24-bit chunk, which would mean we'd have to pay a quarter
of a million dollars to get 32 bits of ethernet multicast address space,
even though almost all the the 46 bits of total ethernet multicast address
space is unused and will never be used.  If we instead use the locally-
administered space, we don't have to pay anyone, but we run the hazard of
colliding with some other local usage of that 33-33- prefix.  I suspect
that such collisions are highly improbable (I did check the database of
known ethernet address usage maintained at MIT, and there was no known
conflict recorded there), but if anyone knows of any existing use of that
prefix, please speak up -- I'd like to settle this question before the end
of the month.

By the way, this mapping would apply to Ethernet and FDDI, but *not* to
Token Ring, where most host adapters have insufficient multicast address
filtering to deal with proper multicast addresses.  Instead, on Token
Rings, IPv6 multicast addresses would all be mapped to the single
"functional" address already allocated to IP, that is 03-00-00-20-00-00
in canonical form (see RFC 1469, IP Multicast over Token-Ring LANs).

Regards

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Mon, 11 Jul 2016 19:58:50 +0000

All of which seems on the surface to be a "belts and suspenders" approach to IPv6 over Ethernet. After all, IPv6 payload can be differentiated from IPv4 payload, so there should be no reason for this multicast or for the IPv6 "type" in unicast, to be different from IPv4?

Unless the problem is that IPv4 implementations don't bother checking for IP version? Would have been nice to avoid this extra complication, I think.

Bert

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Francis Dupont
Sent: Monday, July 11, 2016 12:21
To: Alexandre Petrescu <[email-masked]>
Cc: IPv6 <[email-masked]>
Subject: Re: Reference to "3333" value of RFC2464 "IPv6 over Ethernet"

Regards

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 13 Jul 2016 14:50:31 +0200

Le 11/07/2016 à 18:21, Francis Dupont a écrit :
> => 01:00:5e was far before IPv6 and as far as I can remember this
> was used before 33:33 was specified (the 00 I-D was published the

This confirms more and more that 3333 stands for IETF 33, which looks cool.

But a less cool 0x3 could have accommodated more Group IDs from IPv6
multicast addresses.  Whereas 0x3333 can prefix 32bits of Group ID, 0x3
could prefix 40bits of Group ID.

(in RFC4291 "IPv6 addr arch" the Group ID is 112 bits long).

Allow me now to comment on this message:

> To: [email-masked] Subject: (IPng 192) IPv6 ethertype,
> multicast address mapping, etc. Date: Fri, 16 Jun 1995 18:32:30 PDT
> From: Steve Deering <[email-masked]> Message-Id:
> <[email-masked]> ...
>
> On another Ethernet-related topic, we have never specified how IPv6
> multicast addresses are to be mapped to Ethernet multicast addresses.
> I believe that some of the prototype IPv6 implementations are
> curently using the same mapping as IPv4, that is, replacing the
> low-order 23 bits of the ethernet address 01-00-5E-00-00-00 with the
>  low-order 23 bits of the IP multicast address.  It would be nice to
>  use a slightly more efficient mapping for IPv6 (extracting 23 bits
> is sorta fiddly).  I propose the following:
>
> 33-33-00-00-00-00 with the low-order 32 bits of the IPv6 multicast
> address.
>
> The 33-33- prefix has both the Group (Multicast) bit set and the
> Locally Administered bit set. (They are the lowest-order and second
> lowest-order bits, respectively, of the first octet, in the canonical
> address representation.)

For information, there is talk recently about privacy uses of the L bit
in the MAC address field of a MAC header carrying IPv6 packets.

This would make it for two distinct Local prefixes both for IETF.

> It would be more politically correct to use a Universally
> Administered prefix, but those are handed out by the IEEE at $1000
> per 24-bit chunk, which would mean we'd have to pay a quarter of a
> million dollars to get 32 bits of ethernet multicast address space,

I dont understand why this reasoning was not pushed further.  Using 0x3
instead of 0x3333 would have saved even more money.

> even though almost all the the 46 bits of total ethernet multicast
> address space is unused and will never be used.

I dont understand this claim of never expected be used.

The length of the Group ID in an IPv6 multicast address is 112bits.

The number of reserved Group IDs grows more and more (all-nodes,
all-routers, all-ntp-servers...).

One day there will be no place left in the MAC addresses to map each of
these Group IDs.

> If we instead use the locally- administered space, we don't have to
> pay anyone,

Yes.

> but we run the hazard of colliding with some other local usage of
> that 33-33- prefix.  I suspect that such collisions are highly
> improbable (I did check the database of known ethernet address usage
> maintained at MIT, and there was no known conflict recorded there),
> but if anyone knows of any existing use of that prefix, please speak
> up -- I'd like to settle this question before the end of the month.

Well we are now many years later, but I think the collision risk may
have grown:

- there are more non-IP protocols sitting on EthernetII headers than
   were at the time.
- some other non-multicast but IP protocols considering the use of the
   L bit appear.
- the 33-33 number is not mentioned anywhere by IEEE nowhere.

> By the way, this mapping would apply to Ethernet and FDDI, but *not*
>  to Token Ring, where most host adapters have insufficient multicast
>  address filtering to deal with proper multicast addresses.  Instead,
>  on Token Rings, IPv6 multicast addresses would all be mapped to the
>  single "functional" address already allocated to IP, that is
> 03-00-00-20-00-00 in canonical form (see RFC 1469, IP Multicast over
>  Token-Ring LANs).

This RFC is now Historic because IPv4.  The IPv6-over-token-ring RFC2470
does use 03-00- instead of 33-33-.

The IPv6-over-802154 RFC4944 uses a 16bit multicast MAC address which is
binary 100XXXXX-XXXXXXXX.  Other non-Ethernet IEEE links not using
33-33- are "IEEE 1394 highperf serial" RFC3146 - MCA type 2, and "IEEE
802.16" - bridged, so supposedly 48 1s.

On some undocumented yet popular links like USB or LTE the 33-33- is used.

Alex

---

From: [email-masked]
Date: Sat, 16 Jul 2016 14:23:49 +0200

> This confirms more and more that 3333 stands for IETF 33, which looks cool.

but it doesn't. it comes from:
https://www.parc.com/util/map.html

which was Steve's employer at the time.

Best regards,
Ole

---

From: Mark Smith <[email-masked]>
Date: Sun, 17 Jul 2016 13:57:07 +1000

> which was Steve's employer at the time.

I wonder if that was intended to be changed at some point, meaning
buying the required number of contiguous official OUIs.

Obviously too late now, however having been the victim of an upstream
supplier forcing us to route parts of their RFC1918 address space in
our network, I really don't agree with turning private, non-unique,
local scope address spaces into ones visible outside your network or
embedded in global products/protocols/software.

Regards,
Mark.

---

From: Hemant Singh <[email-masked]>
Date: Tue, 19 Jul 2016 08:14:47 -0400

Sorry for the delayed reply.  I read IETF emails sporadically.  See section
2.3.1 of RFC7042 for the definition.  IANA has also reserved the address.

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

Search at the above URL for rfc7042 and you will find the IPv6 multicast
mac first two octets in 3333.

Hemant

---

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

Le 19/07/2016 à 14:14, Hemant Singh a écrit :
> Sorry for the delayed reply.  I read IETF emails sporadically.  See
> section 2.3.1 of RFC7042 for the definition.  IANA has also reserved
> the address.
>

But that URL does not show the 33-33 address as an allocation proper,
along with other allocations.  It shows it as a given, in an
introductory paragraph.

It has this 'L' Local Authority bit set, it is not defined by IEEE, it's
not a IANA OUI, and so on.

> Search at the above URL for rfc7042 and you will find the IPv6
> multicast mac first two octets in 3333.

Ok, thanks.  But I dont think an RFC is a place to allocate a number
which belongs to a somehow fuzzy border between IP and MAC.

There are many non-IP protocols running on this MAC and their designers
would not all read this RFC - risking collisions.

Alex

>
> Hemant
>
> On Fri, Jul 8, 2016 at 9:56 AM, Alexandre Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>
> Where is this "3333" value defined?  Obviously an RFC is not the
> place to define an Ethernet multicast address.
>
> Alex
>
> IETF IPv6 working group mailing list [email-masked]
> <mailto:[email-masked]> Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6