Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses

Gyan Mishra <hayabusagsm@gmail.com> Fri, 10 June 2022 04:50 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: pim@ietfa.amsl.com
Delivered-To: pim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B980C165639 for <pim@ietfa.amsl.com>; Thu, 9 Jun 2022 21:50:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqVD-M9ep2GG for <pim@ietfa.amsl.com>; Thu, 9 Jun 2022 21:50:48 -0700 (PDT)
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26872C165624 for <pim@ietf.org>; Thu, 9 Jun 2022 21:50:48 -0700 (PDT)
Received: by mail-pj1-x1035.google.com with SMTP id w2-20020a17090ac98200b001e0519fe5a8so1140158pjt.4 for <pim@ietf.org>; Thu, 09 Jun 2022 21:50:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+PsTf6Qn4n6XcB/GdlQAsJ6oKQH0qX7zYA4nBaH27rQ=; b=g8oYDpZWNbwyil9ip3I4JIcDHq8mVDikwKfbJg2l9Z6Vc65/SWlhNCn4ZPpgs999h2 y/Wf+BHxcpIB8q1dTnTDz3STRgdpDaqUbXuTubZb842aE7k4Yd0Fbyp7HasI7hwhXmyc 41MY/kD2QKu9dK4/dGTWEXwI21XRAtWsRgKiz2dZJI7T1VEsSh/dSk/BVpou+PA5Qmpo qNd2wGqkodeIQwvMT7SBQyovlbNqQv2JU9D2bu+a8FZdZZCsfYBHq43mWnCupcZxAj2d haJOf1FbdSsl9wCZsQfUJPh1WTLk8OAsDkya15l1gscMSYr77e7L06IqVVIQQ8ohYX4K Po8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+PsTf6Qn4n6XcB/GdlQAsJ6oKQH0qX7zYA4nBaH27rQ=; b=7Nyg8woiazS1wsDpBwzTBPIWwkFEK8x098RtZ0kuYwBlDbdCd6o5F5MJ6jrmyTw0QT M8NeUJl7A9mpnV8iKU3pGBN9cseXUAo/n7XrCj6E0Nxx11xS9qVLLWHjk4JEHjf7I3sD ppmyOjBLPSooZDaj4TcJyyFwO+IdECIw0l0OGyTvCIygfPFtiy0BLWgrJmn+v1k1qxEy uMXg8Qfbt7lhISCB0KLW4K8JXJJXuAgwc7eRpa6Qnldjd9T7pKkBMBShtO980uneKX7Q 8jGrxwhv/9ITwOSrhsmDohcsBl3/z/tEtVa2N9wI/i/wFFVKCVQ/X34COBEUHTPNFWKb xFxA==
X-Gm-Message-State: AOAM530X/1MpxOD6DzRJWM40+eN0LN8j9IckTa8o/AzVDcavNg4bvZNV cKUkmqjbm2y51HBdP1xngSuAGEZLO7Gdj0P9RU+KWCJ7
X-Google-Smtp-Source: ABdhPJyIKCJvIzVjt8/xA7irFxtEDNa8zs1EUu7JZjVcJlNYmL42UP5DF8vxwGmUvoYFbQXIDm+A6tXnji/drHxo4Rg=
X-Received: by 2002:a17:90a:e558:b0:1e8:34d7:c742 with SMTP id ei24-20020a17090ae55800b001e834d7c742mr3550781pjb.93.1654836647495; Thu, 09 Jun 2022 21:50:47 -0700 (PDT)
MIME-Version: 1.0
References: <5849be0fcd234c4998f9573e88d85cf1@garmin.com>
In-Reply-To: <5849be0fcd234c4998f9573e88d85cf1@garmin.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Fri, 10 Jun 2022 00:50:36 -0400
Message-ID: <CABNhwV2tPU3v6uWTt=ucsH0j_3TuW9+GbKHxAqHBtvv4KH8bDg@mail.gmail.com>
To: "Karstens, Nate" <Nate.Karstens=40garmin.com@dmarc.ietf.org>
Cc: "pim@ietf.org" <pim@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000890c0805e110aed4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/POcfwEt7nYV_7sa35qwA6nQrvAI>
Subject: Re: [pim] Zero-Configuration Assignment of IPv6 Multicast Addresses
X-BeenThere: pim@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Protocol Independent Multicast <pim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pim>, <mailto:pim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pim/>
List-Post: <mailto:pim@ietf.org>
List-Help: <mailto:pim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pim>, <mailto:pim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2022 04:50:52 -0000

Hi Nate, et al

I believe what you are looking for is a RFC 2907 & RFC 2730 MADCAP style
method of dynamically allocating multicast address to clients.

I think that maybe the best option.

RFC 3306 Unicast Prefix based multicast basically refers to RFC 4291 IPv6
addressing architecture section 2.7 as all IPv6 multicast are prefix based
ffx0::/16 where x is the flag - P flag set for prefix based, R flag for
embedded RP and 4 bit scope flag all of which is standard for building your
IPv6 multicast group addresses to be used.

RFC 6034 Unicast prefix based IPv4 multicast provides a a similar IPv6
style unicast prefix based multicast address used UBM address mapping
unicast prefix into the multicast block.

This wiki is excellent for IPV6 multicast addressing bit wise breakdown.

https://en.m.wikipedia.org/wiki/Multicast_address#IPv4

For Layer 2 switch multicast IGMP snooping multicast MAC mapping RFC 5342
defines the IPv4 multicast Mac OUI 01-00-5e and last 3 octets of GDA is
mapped to remaining LSB bits creating the multicast Mac with some bits
lost, and similarly for IPV6 multicast mac mapping RFC 2464 IPv6 multicast
Mac 33-33 and last 32 bits of GDA mapped to form MAC address so bits are
lost as well and subject to overlap.

This is a different topic and it relates to IGMP snooping multicast MAC
address formation from GDA.  I believe Cisco, Juniper and most other vendor
s don’t use this deprecated mapping method for IPv4 and it’s a IP based
IGMP snooping so the 32 bit class D address is what seen by the switch in
its snooping escape logic which gets around the overlap issue.

I don’t think there is an official IETF standard for IP based IGMP snooping
which does not use the legacy Multicast mac mapping method where bits are
lost and subject to overlap.

For IPv6 address based IGMP snooping the same issue exists with the
multicast mac mapping and bits lost and subject to overlap but I don’t
think any vendors support an IPv6 based IGMP snooping which would be great.


Maybe a draft needs to be developed IPv6 address based IGMP snooping  and I
think it would be beneficial to operators and avoid the overlap issue.

Thanks

Gyan

On Thu, May 26, 2022 at 1:17 PM Karstens, Nate <Nate.Karstens=
40garmin.com@dmarc.ietf.org> wrote:

> Greetings,
>
>
>
> I am the chair of a standards committee at the National Marine Electronics
> Association (NMEA). We are in the final stages of developing NMEA OneNet, a
> standard for Ethernet/IPv6-based communication and control of marine
> systems (a little background: NMEA has existing standards, NMEA 0183 and
> NMEA 2000, that provide similar functionality over serial and CAN).
>
>
>
> Marine networks can be a mix of low-bandwidth embedded sensors and
> high-bandwidth streams for radar and video data, and most of this data is
> sent multicast on the local network. In order to prevent high-bandwidth
> streams from overwhelming low-bandwidth links, we assign traffic to
> different multicast addresses and then use multicast snooping to direct
> those streams only to hosts that request them.
>
>
>
> Source-specific multicast is not feasible due to the available switch
> hardware. As such, we believe we have identified a need for
> zero-configuration assignment of IPv6 multicast addresses on the local
> network.
>
>
>
> We investigated MADCAP, but this is not ideal because maritime systems try
> to avoid single points of failure. We also found ZMAAP, which seemed
> promising, but it was only a draft standard that expired in 2003.
> Link-scoped multicast addresses also seemed promising, but when you
> transmit these addresses on Ethernet you get 33:33 followed by 32 bits of
> the group ID, so even devices that assign their own IPv6 multicast
> addresses using a unique IID can still collide at the Ethernet layer due to
> the colliding group IDs.
>
>
>
> Another related complication is that multicast streams can originate from
> different applications on the same host, and there is no mechanism for
> those applications collaborating to avoid collisions at the IPv6 layer.
>
>
>
> Instead of developing our own method, we decided it may be preferable to
> work with IETF to develop an Internet standard that we could then use in
> our work. (Or, if there is something that will work for us but we’re not
> aware of, to learn about that). Alvaro recommended that we email this group
> to start the conversation and see where that leads us.
>
>
>
> Thanks,
>
>
>
> Nate Karstens
>
> Garmin International, Inc.
>
> Chair, NMEA OneNet TSC
>
> ------------------------------
>
> CONFIDENTIALITY NOTICE: This email and any attachments are for the sole
> use of the intended recipient(s) and contain information that may be Garmin
> confidential and/or Garmin legally privileged. If you have received this
> email in error, please notify the sender by reply email and delete the
> message. Any disclosure, copying, distribution or use of this communication
> (including attachments) by someone other than the intended recipient is
> prohibited. Thank you.
> _______________________________________________
> pim mailing list
> pim@ietf.org
> https://www.ietf.org/mailman/listinfo/pim
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*



*M 301 502-1347*