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

"James A. (Jim) Stevens" <james.a.stevens@collins.com> Wed, 05 August 2020 04:19 UTC

Return-Path: <james.a.stevens@collins.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59D4B3A0A2E for <bier@ietfa.amsl.com>; Tue, 4 Aug 2020 21:19:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.995
X-Spam-Level:
X-Spam-Status: No, score=-1.995 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=collins.com header.b=Z9FBLdEG; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=rockwellcollins.com header.b=w47FhKz0
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 uTh2KGtE2EsJ for <bier@ietfa.amsl.com>; Tue, 4 Aug 2020 21:19:38 -0700 (PDT)
Received: from mx0b-00105401.pphosted.com (mx0b-00105401.pphosted.com [67.231.152.184]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAF83A0AA6 for <bier@ietf.org>; Tue, 4 Aug 2020 21:19:38 -0700 (PDT)
Received: from pps.filterd (m0074334.ppops.net [127.0.0.1]) by mx0b-00105401.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 0754I7ul018491 for <bier@ietf.org>; Wed, 5 Aug 2020 00:19:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=collins.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=POD051818; bh=ewsiQxpfQPhZ95OStDxnP4FURHymPFIRLP3K+ziACV8=; b=Z9FBLdEGTjIOQA3jOgbTy1Dr54QlDXH4pd0rQFQufS5q5E+Y0dVUnErPhHQ19RaYGwLl YxiLyVC5+bXgPhopZzs2pY2vaVOL43Q9sjvnn+2iXSzYynLc9pVpUuMERbZrV1Na2/Tq rXpb6Gj0/9NyGNSX8e7f9cqZw74Zfg72qLOhXU6NfEAaqrJtI37It6M2jZJcML3v0pHF WI2fO2cvnNl+vIn7iBTtxmat/tggBVr1VP2U/nQBMBhG6BzJ+gXM8tOYUzXidfOqZq/b e9c0AboS2NJj9vSOlkVhsXqme6QdbFwS+J6gb5NCTltacts+RDK2g77ClB1RYHbvpm0m zg==
Received: from xnwpv37.utc.com ([167.17.239.17]) by mx0b-00105401.pphosted.com with ESMTP id 32n8dg5svt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <bier@ietf.org>; Wed, 05 Aug 2020 00:19:37 -0400
Received: from uusmna14.utc.com (uusmna14.utc.com [159.82.227.148]) by xnwpv37.utc.com (8.16.0.27/8.16.0.27) with ESMTPS id 0754Jah4107526 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <bier@ietf.org>; Wed, 5 Aug 2020 00:19:36 -0400
Received: from secvs04.rockwellcollins.com ([10.172.224.19]) by uusmna14.utc.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id 0754JZko005322 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <bier@ietf.org>; Wed, 5 Aug 2020 00:19:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rockwellcollins.com; s=hrcrc2020; h=mime-version:references:in-reply-to:from:date:message-id: subject:to:cc; bh=ewsiQxpfQPhZ95OStDxnP4FURHymPFIRLP3K+ziACV8=; b=w47FhKz0ngNXdS54U2xdJLzcnIuABOVVM3tmO8GkBseDY0U6MHts9Hif gTmkb10fJFBGFWNUuTDuIwknQKTgCtkWuEqzf1HHoVMOBTmJreyVFFsL2 fhBPjPNyQJp/Fah6Ysu1QRV7UPXGlYmaR3H/KZJATC/hCr4TvHxcKkpVl TRmLv63FGDniOxOHcaAxNc8mLCyrvuVc7JxlH++q5WXxF00n5aEoHS3Q9 zzhxDPP4sgmEFeoW8zZmy5SVJZE4qglwFXJYxoRyhIA+C+D8jN3iW4BXZ 9TripaRutpcq6GYnpa71iu/Yi2ZY/yPgvjpHYu4UHyZ0kMb2jV7GnfVRY w==;
IronPort-SDR: T0bKfs08niPNGZgoryTXeX8dw+neO1QfOeG08BocQu2zFa3F3piAupwonhK8FGrSlStjpV7+Ui MjimTeT/J8jfGxS99u1ia4CEJ3wf/Ci0rieuSgspqZCgLAdELDlXNaoU/3rAetnP0iMSJp+M95 d34FB6Ma9wHIQ3BajYfvGvzBOdALM0c1i3xs6FhwzK7WR/KwB9z/MvIv+Ej7WoXaFif9lLFGzX wR2eBAX13pmZP04zYMp2SdXKMjAwixtl0WMO2t3T0qEOZ/jMY3L1lBXDhRTZ6BKQLkKN6ARDXE Pis=
X-RC-All-From: , 205.175.225.60, No hostname, james.a.stevens@rockwellcollins.com, "James A. (Jim) Stevens" <James.A.Stevens@rockwellcollins.com>, ,
X-RC-Attachments: , ,
X-RC-RemoteIP: 205.175.225.60
X-RC-RemoteHost: No hostname
X-RC-IP-Hostname: secip04.rockwellcollins.com
X-RC-IP-MID: 38357030
X-RC-IP-Group: GOOGLE_RELAYED
X-RC-IP-Policy: $GOOGLE_RELAYED
X-RC-IP-SBRS: None
X-RCRedirectFilterUsed:
Received: from unknown (HELO mail-il1-f198.google.com) ([205.175.225.60]) by secvs04.rockwellcollins.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 04 Aug 2020 23:19:35 -0500
Received: by mail-il1-f198.google.com with SMTP id e12so5427998ile.14 for <bier@ietf.org>; Tue, 04 Aug 2020 21:19:35 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ewsiQxpfQPhZ95OStDxnP4FURHymPFIRLP3K+ziACV8=; b=QzwXS/0KRmvWSXBW2XtQkWUKFhe+SAAxaCqFoi+GdIT3x2a3Mlibx46q87rRFlZI8K ulI0ZfRg31EfbUjqdnqZ6BW+oGLpm2JunTNfXqhuY6QXP1N5IGseQIDQMKhbtfJKxVcD HWngo7mdvyYPAIOzP7uSwtmPjGcM+N7hps4GnRVUBbX7YMIqSDgVH5mJ2tSIPROXbsuL ZxWtV3Q6g+/m92E9yHBkxQObdLtccAJlnSBlj294YdjACXyx6TYL7KKXxDwo/nA5Xl2g 6maAlWbtOV8ilDKbFYWv58lFqEbcydh/Ftlk86Z1xRIf0rN8eFkojU9B9WW9PDGxvAKd 0jbw==
X-Gm-Message-State: AOAM531uEvWDY8pPfo8Q/Emkz8gJ0+eLuo9qEUSf6WLw8rZefIN6b67/ jWdQabpMTL58ir5gSBmgfd6HIYgtHFCv5YCO2sYIpxcyeAUPPEAtIvt3sFB52xKLCF+HEsH9veD DbtLnFkSjG2XucgV1b4gGqlfmEnkRcdTUSxM2Y/k=
X-Received: by 2002:a05:6e02:88:: with SMTP id l8mr2030695ilm.69.1596601174367; Tue, 04 Aug 2020 21:19:34 -0700 (PDT)
X-Google-Smtp-Source: ABdhPJzIaMfsk+1nUod0MnVmrbW+xcoMS536IUqG4k298TGWYMStByO6/yVQdwI29qNFjRApt4ukqC0z7asb47PDaVI=
X-Received: by 2002:a05:6e02:88:: with SMTP id l8mr2030675ilm.69.1596601174071; Tue, 04 Aug 2020 21:19:34 -0700 (PDT)
MIME-Version: 1.0
References: <CAH8Jh6BsVgLW5rV00Ugp9CCwKcDaBvsWCRtc_o83ks83PxGz_w@mail.gmail.com> <2446466B-4F73-421F-AC68-38AAE64E3C3C@strayalpha.com>
In-Reply-To: <2446466B-4F73-421F-AC68-38AAE64E3C3C@strayalpha.com>
From: "James A. (Jim) Stevens" <james.a.stevens@collins.com>
Date: Tue, 04 Aug 2020 23:19:18 -0500
Message-ID: <CAH8Jh6B2JDSZEjay-DhtKONkqTPvGXGsjN3LoYAUuq6hDAco=Q@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: mboned@ietf.org, pim@ietf.org, bier@ietf.org
Content-Type: multipart/alternative; boundary="000000000000d4356f05ac19ad56"
X-Proofpoint-Spam-Details: rule=outbound_default_notspam policy=outbound_default score=0 phishscore=0 malwarescore=0 clxscore=1015 mlxscore=0 mlxlogscore=951 priorityscore=1501 suspectscore=0 adultscore=0 impostorscore=0 lowpriorityscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2008050038
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/_-1oIhOYnB9qSArWpffKVH5_0P8>
Subject: Re: [Bier] [External] Re: [MBONED] Unambiguous IPv4 Multicast to Ethernet Address mapping?
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Aug 2020 04:19:40 -0000

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