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

Toerless Eckert <tte@cs.fau.de> Sun, 09 August 2020 22:39 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: mboned@ietfa.amsl.com
Delivered-To: mboned@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74BF03A0E3C; Sun, 9 Aug 2020 15:39:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.117
X-Spam-Level:
X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, LOTS_OF_MONEY=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A78v6RjJGhCO; Sun, 9 Aug 2020 15:38:59 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B03433A0E4F; Sun, 9 Aug 2020 15:38:58 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4368B54802F; Mon, 10 Aug 2020 00:38:51 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 3552B440059; Mon, 10 Aug 2020 00:38:51 +0200 (CEST)
Date: Mon, 10 Aug 2020 00:38:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: "James A. (Jim) Stevens" <james.a.stevens=40collins.com@dmarc.ietf.org>
Cc: Joe Touch <touch@strayalpha.com>, mboned@ietf.org, bier@ietf.org, pim@ietf.org
Message-ID: <20200809223851.GA10736@faui48f.informatik.uni-erlangen.de>
References: <CAH8Jh6BsVgLW5rV00Ugp9CCwKcDaBvsWCRtc_o83ks83PxGz_w@mail.gmail.com> <2446466B-4F73-421F-AC68-38AAE64E3C3C@strayalpha.com> <CAH8Jh6B2JDSZEjay-DhtKONkqTPvGXGsjN3LoYAUuq6hDAco=Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CAH8Jh6B2JDSZEjay-DhtKONkqTPvGXGsjN3LoYAUuq6hDAco=Q@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/mboned/NoRz8S8b0DVGUQNtsAqVONs-atE>
Subject: Re: [MBONED] [External] Re: Unambiguous IPv4 Multicast to Ethernet Address mapping?
X-BeenThere: mboned@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Mail List for the Mboned Working Group <mboned.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mboned>, <mailto:mboned-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mboned/>
List-Post: <mailto:mboned@ietf.org>
List-Help: <mailto:mboned-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mboned>, <mailto:mboned-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 22:39:13 -0000

On Tue, Aug 04, 2020 at 11:19:18PM -0500, 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.

If your MANET nodes route/forward on the layer 3 address, then the L2 ambiguity
is irrelevant. It is only relevant if your forwarders operate on L2, but
then it is not a MANET router, but some form of MANET L2 switch.

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

Probability of ambiguity depends on how addresses are allocated. There
have been common examples of IPv4 multicast address allocations that
caused the MAC ambiguity to kick in and required re-education of app
developers.

> 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 reason is well documented: The MAC mapping was part of Steve Deering
PhD thesis at Stanford (1991), and a 24 bit OUI cost USD 1,000, so David
Cheriton (Steve's PhD advisor) didn't want to spend 16 x $1,000 to fully
map Ethernet but bought just one and gave Steve only half of it (23 bits),
thus keeping another 23 bit for other experiments. Later the block was given
by Stanford to IETF.

This was never changed because the pain was never high enough. In a time
of IGMP snooping switches, ambiguous traffic only is passed on to hosts
when the switch only performs IGMP snooping based on DMAC, but more intelligent
IGMP snooping switches have been filtering/forwarding based on Destination
IP address for a long time.

My personal theory of course is that a 1:1 mapping of the 28 bit IPv4
multicast addrsses to MAC addresses would have made IPv4 better than
IPv6 could ever be (can't 1:1 map IPv6 multicast addresses into 48 bit
ethernet). So why improve the protocol version that many would rather
like to kill. I think this qualifies as a conspiracy theory ;-)

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

Sounds like you don't only want to go down the painfull path of IGMP snooping,
but then also creating a non-standard solution for that. I'd be doubtfull this
is the best option, but of course i can only guess given how its
proprietary.

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

I don't know if/what discussion there was in the process of defining rfc2464
about this point.

Might be a good question to as on internet history or to Bob Hinden directly,
ipng mailing list archive as listed on datatracker does not exist anymore.

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

As soon as no other L2 application would create a lot of CPU overhead
for receiving non-IP 3333' MAC addresses, i would be surprised if IETF
would do anything in this regards. But you are of course always welcome
to propose and lead work. I don't think there would be resistance to
updating the mapping, but a) you would have to do all the work, b) you
shouldn't be frustrated if no vendor picks up the change.

Cheers
    Toerless

> Jim
> 
> On Mon, Jul 27, 2020 at 1:35 AM Joe Touch <touch@strayalpha.com> 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 <james.a.stevens=
> > 40collins.com@dmarc.ietf.org> 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
> > https://networklessons.com/multicast/multicast-ip-address-to-mac-address-mapping
> > <https://urldefense.com/v3/__https://networklessons.com/multicast/multicast-ip-address-to-mac-address-mapping__;!!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
> > MBONED@ietf.org
> > https://www.ietf.org/mailman/listinfo/mboned
> > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/mboned__;!!MvWE!XdeY2ViVVq1tW_2eLECUTCzWVH8h-l3Gjp4YuMQo0rP7u41EVHMo-PYq-G3GWLpfXc_f$>
> >
> >

> _______________________________________________
> MBONED mailing list
> MBONED@ietf.org
> https://www.ietf.org/mailman/listinfo/mboned


-- 
---
tte@cs.fau.de