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

Brian Haberman <brian@innovationslab.net> Wed, 08 June 2022 13:16 UTC

Return-Path: <brian@innovationslab.net>
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 5DD1DC14CF1A for <pim@ietfa.amsl.com>; Wed, 8 Jun 2022 06:16:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.78
X-Spam-Level:
X-Spam-Status: No, score=-3.78 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=innovationslab-net.20210112.gappssmtp.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 9fC5zoM99XiC for <pim@ietfa.amsl.com>; Wed, 8 Jun 2022 06:16:20 -0700 (PDT)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 1240CC14F724 for <pim@ietf.org>; Wed, 8 Jun 2022 06:16:19 -0700 (PDT)
Received: by mail-qt1-x835.google.com with SMTP id y15so14840043qtx.4 for <pim@ietf.org>; Wed, 08 Jun 2022 06:16:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=innovationslab-net.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=VbSktK4syU43GiSXnwp+fL6bAhhQUbfZ3+Z2BhsobUI=; b=2x7FuKTVDelfKQsHTqk6xOAHpt8fsdhTp6zI+1cBWazTCtBPUVQMJNTP6Vi7nAYCZu 8Ju2yUYYNgzTRPMJCnk2gsOTCMFdHYoov6HNudI2FmqWtAHauLdUaO+WsQ1Qy7ojQCLH SkJQ6vP5Jx+ZGE7cI7NK8g/qRIUNMYb2Su0CC1vojP9lPXbxMTo2fXlta49pvHZ5cpgS PbY1mk4dEx+kZ5rIm3vsHL0+vueJZ+OESeWyLiWDrs3yPQdR9cSX/jIWNPWI9v7u/VUz XJCU3EHTqiROHpCM8NNZXQ77opNIdDRqYW4K6T258DmpuiiKcJYYiWpbuzq0A7NMcYA4 RhaA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=VbSktK4syU43GiSXnwp+fL6bAhhQUbfZ3+Z2BhsobUI=; b=1WlVN48JxZ3WArNr/iFIUeQn4NNAVpWgKRWU8lScql2RxWYM0KshUrkmNsgrShLvjN Rcp0ivDVcygDjvXUTLCDsyZ2indzK6q/rXpyfu/nQEYWf63WP4JL0NABWMQvqq6zMK1c P2PxzgY+8bvbElq3U0Jm6Np8fdyOGdWFpGPVQyLA9ct4B7pMU6isCYqP7x7FHx3ZI1Ig NLuG3y76BQp6zk4JAV2geZXiqOe+1a1Cbimines4ZIm+tUu/xlrVwYG7a9rCGYSfn30k PXcRLgqNbwP2XTBvga5nWo9sDEJ4VorolBWqH5iclxXOM37RCCLF7AeI3rdfO8/RcXj1 03SA==
X-Gm-Message-State: AOAM531o9SpG308a2RP+DCt6ka4TWm+kbTInmZrwVLXkaEnPwMawH2wS AC/W/GJduFUHLwS4nw6gAJccZaTDlklPig==
X-Google-Smtp-Source: ABdhPJwAitcssP4esAtnr6Bw4d3VCR1qadvFd8yPUdhYJ1Ajx67wpYcEvn/T2iEvWugWhhA0HjV93w==
X-Received: by 2002:ac8:59c5:0:b0:304:fe09:6c33 with SMTP id f5-20020ac859c5000000b00304fe096c33mr5525173qtf.224.1654694178223; Wed, 08 Jun 2022 06:16:18 -0700 (PDT)
Received: from ?IPV6:2601:5ce:300:84e:2156:c7ed:b0ee:5133? ([2601:5ce:300:84e:2156:c7ed:b0ee:5133]) by smtp.gmail.com with ESMTPSA id cc17-20020a05622a411100b00304ef50af9fsm5512343qtb.2.2022.06.08.06.16.17 for <pim@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jun 2022 06:16:17 -0700 (PDT)
Message-ID: <6660129a-3136-210a-3969-1fadc5db101d@innovationslab.net>
Date: Wed, 08 Jun 2022 09:16:16 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.9.1
Content-Language: en-US
To: pim@ietf.org
References: <5849be0fcd234c4998f9573e88d85cf1@garmin.com>
From: Brian Haberman <brian@innovationslab.net>
In-Reply-To: <5849be0fcd234c4998f9573e88d85cf1@garmin.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------DgvHEuqefcvAeILvRlHKYUMV"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pim/U4-jJmfxchz_Yj3Tmj6XYZ-OuLE>
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: Wed, 08 Jun 2022 13:16:22 -0000

Have you read RFC 3306?

On 5/26/22 1:17 PM, Karstens, Nate 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