[Roll] Proposed new multicast group for AODV-RPL

Charlie Perkins <charles.perkins@earthlink.net> Sun, 17 April 2022 18:23 UTC

Return-Path: <charles.perkins@earthlink.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1225E3A0DD8 for <roll@ietfa.amsl.com>; Sun, 17 Apr 2022 11:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net
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 6KHdvo1HDVN6 for <roll@ietfa.amsl.com>; Sun, 17 Apr 2022 11:23:25 -0700 (PDT)
Received: from nmtao102.oxsus-vadesecure.net (mta-102b.oxsus-vadesecure.net [51.81.61.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13FFB3A0DCF for <roll@ietf.org>; Sun, 17 Apr 2022 11:23:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; bh=nl0B06f6pz+9CCF+P1b5fKjbUPSZNXYZBnzRG/ iKYN0=; c=relaxed/relaxed; d=earthlink.net; h=from:reply-to:subject: date:to:cc:resent-date:resent-from:resent-to:resent-cc:in-reply-to: references:list-id:list-help:list-unsubscribe:list-subscribe:list-post: list-owner:list-archive; q=dns/txt; s=dk12062016; t=1650219803; x=1650824603; b=ezW5QAoFuclFRSUUCMgpvHAQLE9JexYys1qwm19jtddTXjOEoAQTPhu uw1O0CZ4YmfQovd7px70F83B/RHll3ndI9be8UJ/MdRh4hTq1pS09T54X5T11CTLlzwDl8/ epmEPSMMMgyAI8gH7X200m3B0/pYcm8kR3u5IGJopuwkwK2QjNHbUQxDZrCyu3ga9OA0Cza lwsTiuEmplvYiYJl1+wY/+iEN6mTnMZqdN0UhxCleteMYEWv0nOet1CS/EDiSF1IqPahStc U3GGO+KA0x4ZnYTCGv8bNuniRrysx3y40Dk6wTmmdym0cKj+P88UMDB5GpPioe5lCtkek4M ndA==
Received: from [192.168.1.72] ([99.51.72.196]) by smtp.oxsus-vadesecure.net ESMTP oxsus1nmtao02p with ngmta id ec03a55d-16e6c22b1016139d; Sun, 17 Apr 2022 18:23:23 +0000
Message-ID: <9ce28d04-d586-9b77-2b4b-8e92ac2536dc@earthlink.net>
Date: Sun, 17 Apr 2022 11:23:22 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.8.0
From: Charlie Perkins <charles.perkins@earthlink.net>
References: <835adc29-d9a0-91c7-2c7a-185195ee1296@lupinlodge.com>
Content-Language: en-US
To: Routing Over Low power and Lossy networks <roll@ietf.org>
In-Reply-To: <835adc29-d9a0-91c7-2c7a-185195ee1296@lupinlodge.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Authentication-Results: oxsus-vadesecure.net; auth=pass smtp.auth=charles.perkins@earthlink.net smtp.mailfrom=charles.perkins@earthlink.net;
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/CgLY4kWrz9djszgDdX0dbELLP64>
Subject: [Roll] Proposed new multicast group for AODV-RPL
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 17 Apr 2022 18:23:28 -0000

Hello folks,

AODV-RPL messages could possibly be confusing to nodes that implement 
other protocols with MOP==4, and so we propose to create a new multicast 
group, perhaps called "All-AODV-RPL-nodes".  Nodes joining that 
multicast group MUST implement AODV-RPL and in particular have the 
ability to process and transmit RREQ and RREP messages.  AODV-RPL does 
not place any requirement on other nodes using MOP==4.

This is an efficient way of resolving a possible issue for other devices 
implementing RPL protocols with MOP==4.  I had originally thought that 
such other implementations would simply drop packets with unrecognized 
options.  But, as it turns out, that is not what RFC 6550 specifies.  I 
still think that good implementations would not forward unrecognized 
AODV-RPL options, but there is ambiguity on this point.  Moreover, 
without a new multicast group, it is possible to imagine implementations 
that would mix AODV-RPL options with other non-AODV-RPL options.  That 
would be more likely to cause errors.

Regards,
Charlie P.