Re: [pim] [External] [MBONED] Unambiguous IPv4 Multicast to Ethernet Address mapping?

Joseph Touch <> Wed, 05 August 2020 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AE1AF3A0A9F; Wed, 5 Aug 2020 08:03:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.217
X-Spam-Status: No, score=-1.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LOTS_OF_MONEY=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2l665I9xoHT5; Wed, 5 Aug 2020 08:03:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 90FC33A0A9C; Wed, 5 Aug 2020 08:03:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8czORDpCZ+DxLbgZbEmA9gZ+g5UAj0dL87yxaswdwoc=; b=qvnJfShHbifPTuxWv7eRH3z7/ j5fdMBf/ji7FJig5GVR4vTBwYIZTDpKnlSdiwUeC8TFkzEdO9/0VY0CJyKDhqqdQ1BQjpavmvGV2e e7OQFoDWQN4LRJgGn4RVEeIHjV9Qngi+QXp8/L/91sX+P68TSUp9siwvY4p+C01qGNkn/L8s5hnw4 X0oKVy4Zh9QCZ5tUJ3VqR0vyakCafBBMd7b3v6gNN2z+qU5rPw5mxKLGpzrcDsBJrABfd23Yn5j4c R9CayMKpo8ohON1cDhNmiyS474sMqcrm+GgcUloNfLqlIcJ/l8wKOQCZYfN4vHc9C0JfzPVG1VryS 5QcjpmQgQ==;
Received: from ([]:53107 helo=[]) by with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <>) id 1k3Kws-000ich-M7; Wed, 05 Aug 2020 11:03:27 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_16C42EEB-EEBE-4A3A-A416-9427127BADFE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Joseph Touch <>
In-Reply-To: <>
Date: Wed, 5 Aug 2020 08:03:21 -0700
Message-Id: <>
References: <> <> <>
To: "James A. (Jim) Stevens" <>
X-Mailer: Apple Mail (2.3608.
X-OutGoing-Spam-Status: No, score=-0.9
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [pim] [External] [MBONED] Unambiguous IPv4 Multicast to Ethernet Address mapping?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Protocol Independent Multicast <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Aug 2020 15:03:31 -0000


IPv4 and IPv6 operate differently. IPv4 assumes global coordination of addresses, so it makes sense that it relies on a reserved block of Ethernet addresses for multicast.

IPv6 creates its addresses by combining router prefixes with local addresses and supports duplicate address detection (which IPv4 lacks), so it makes sense that it would use locally administered addresses instead.

At least that’s from where I sit. History may have a different story to tell - I happen to run the Internet History email list (not associated with the IETF, but supported on the ISOC servers here: <>). You may have better luck finding the legacy info there.

Beyond the history, if your concern is that “there’s another way to do this” that requires upending existing, established, and deployed standards, the real question is “why bother”? You answered that several times - given there’s not that much overhead and IP expects Ethernet can do Ethernet’s job (i.e., L2 forwarding), there’s no need. If you’re designing a new L2 (your MANET layer), then I would ask why you are using Ethernet addresses if they cause a problem for your multihop forwarding. IP expects L2 to do its job, including supporting multicast and broadcast (as per RFC 3819); when that doesn’t happen, IP still works (e.g., over carrier pigeons), but less efficiently.

So, IMO, the real flaw here is adopting Ethernet addresses for your MANET, not how IP maps multicast.


> On Aug 4, 2020, at 9:19 PM, James A. (Jim) Stevens <> wrote:
> Joe – good question.
> We are currently working with proprietary multi-hop MANET wireless network protocols that use Ethernet addressing at the MAC layer but aren’t WiFi networks. For IP multicast, there is ambiguity in the multicast routing since multiple multicast groups can map to the same MAC layer address.  Of course, the probability that there are multiple user IP multicast addresses that  map to the same MAC layer address is low, so there isn’t really that much of an overhead in extra forwarded packets multihop to nodes that don’t need to forward them.    
> It’s really more of a “why did they do it that way” type question on my part.  Especially when I found read the history - and then wondered why it was never turned into an unambiguous mapping. 
> The idea of creating our own proprietary locally administered Ethernet address mapping is a good suggestion and something we will look into for our own use.
> However, I am surprised that an industry standard, like RFC 2464, used a locally administered addresses in a global standard like this.  Doesn’t this really violate the spirit of a locally administered address?  And do any of y’all know why the IETF didn’t get a globally administered address, similar to what was done for IPv4 (other than the cost of getting that many 24 bit Organizationally Unique Identifiers to only use the upper 16 bits)?   It would seem to be a low priority that some locally administered multicast address would collide with RFC 2464, but it could; and even if it does, it should probably not be that large of an extra overhead on the network.
> IEEE came out with the Structured Local Address Plan (SLAP) that divides the locally administered addresses into 4 quadrants in IEEE 802C.  RFC 2464 fits into what is called the Administratively Assigned Identifier (AAI) quadrant due to the value of the first octet value 33 (802C SLAP bits Z & Y = 00).  SLAP defines a Standards Assigned Identifier quadrant (SAI) that uses bits X & Y set to 11. IEEE documentation says use of the SAI Specification of the use of the SAI quadrant for SLAP address assignments is reserved for the standard forthcoming from IEEE P802.1CQ. And, an SAI is assigned by a protocol specified in an IEEE 802 standard.  It would seem like an RFC defined address would fit more into an SAI than an AAI role.
> So, I wonder if there are any plans to update RFC 2464 to use the SAI quadrant.  Again, not really solving a practical problem because probability of collision is small – especially the if locally assigning organization is aware of RFC 2464 – but the chance of collision does exist.  So this is another “wonder if it could/should change” question.
> Jim
> On Mon, Jul 27, 2020 at 1:35 AM Joe Touch < <>> wrote:
> First question - why?
> As in, what problem has been observed that this would solve?
> Note that the IPv6 is a locally administered Ethernet address, not one registered by the IEEE for the IETF.
> Joe
>> On Jul 26, 2020, at 10:44 PM, James A. (Jim) Stevens < <>> wrote:
>> RFC 1112 maps the 28 unique IPv4 multicast address bits to 23 bits within the Ethernet address so that there is not a unique one to one mapping.
>> According to <;!!MvWE!XdeY2ViVVq1tW_2eLECUTCzWVH8h-l3Gjp4YuMQo0rP7u41EVHMo-PYq-G3GWD8yG2F_$>, this was because it would have cost $16,000 in 1990 to have reserved 16 OUIs (Organizational Unique Identifiers) to IP multicast MAC addresses so that the IPv4 multicast to Ethernet multicast addressing would be unique.
>> IPv6 in RFC 2464, maps the lower 32 bits of the IPv6 multicast addresses into the lower 32 bits of the Ethernet Address - so it looks like IEEE supports other IP address to ethernet multicast address mappings.
>> Question - Is any interest within IETF about working with IEEE to come up with an IPv4 to Ethernet multicast address mapping so that the 28 unique IPv4 addresses map uniquely to Ethernet Addresses?
>> For example, this could be a new Proposed Standard RFC that also allows the existing RFC 1112 to continue to be used for backwards compatibility?
>> Jim Stevens
>> _______________________________________________
>> MBONED mailing list
>> <>
>> <;!!MvWE!XdeY2ViVVq1tW_2eLECUTCzWVH8h-l3Gjp4YuMQo0rP7u41EVHMo-PYq-G3GWLpfXc_f$>