Re: [manet] AODVv2 implementation

Christopher Dearlove <> Tue, 28 November 2023 12:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57AAEC14CE36 for <>; Tue, 28 Nov 2023 04:21:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D7Egfdi46Gku for <>; Tue, 28 Nov 2023 04:21:15 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (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 (Postfix) with ESMTPS id D7121C14F749 for <>; Tue, 28 Nov 2023 04:21:15 -0800 (PST)
Received: by with SMTP id ffacd0b85a97d-332e58d4219so3068370f8f.0 for <>; Tue, 28 Nov 2023 04:21:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701174074; x=1701778874;; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=qugQdUz7lGEqXsRPhWO9MPbEGDmS6a3iqvyKP35gbtI=; b=higSg8SosCL1Nyjh4tXPzWY61yOQSS7S6cWcpt5ahkKbvTAjSHK5gP+LEkTYESQtFV McVLPkXXUNshnaUG/2LrS+ljKRm/b4EuviGDLExkqr5WRvRe79EYOD9BuSbkMKoPwhfl 1GzLKc+4JxzDriDcxJ9uSJMf2k1wQvFwP6+dH3QqJ2C6mTGgC0Ma8a6n3GQuNCgP7Frd N2oi5TVxlyt1bB+pT+FylckCYb+UAwisGz5M7rwByiqUBZF3n1UnWsYeWNK4nqLX6Dam dss5xCbbxSmMNcW/At6Zg3Zun/TrPS2KSUbD8403fHyemqB09H21cGzLP9UGGOEBIKcN mwxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20230601; t=1701174074; x=1701778874; h=to:references:message-id:content-transfer-encoding:cc:date :in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=qugQdUz7lGEqXsRPhWO9MPbEGDmS6a3iqvyKP35gbtI=; b=nQFUooOx8FAlxbU6FBX3V+Z43e++1LGsoP6DT8haV2wfzIqjvti302hG/n+YcYF5Jv OQkd9HCP5mOdCIsGvn6r7P9KOlcWgqmUgdSdFsugTI3kZi2dLBCqW6C8Dn7AqaClRJNc BkPendMFC9JuYiB9ujTVoKbBsIMBrC0dCOt1Oh8Znlhrt16wYOnVhnu/6h1cg5hqUIx7 fY9SKnXTT6OvZIA7s68Bi+D+3Fc0xqf9sTO1MHI21sv9IlwT6s/kpjZ4je3wFJIBZ2G3 hRlbNc73TbUKoacoQBfYs7+gmZ5qCFLOohZQW9UnpcpslWnICYgFFY6fpEpoOle2KA7r jXGQ==
X-Gm-Message-State: AOJu0Yyu+C3u1LRm6NV7aWAZpvngxZn7awnLF+712KbfVTuK2uXSdxZs cn1WtkfohNpyoF8ZkZOfAD1eNrBQ7N4=
X-Google-Smtp-Source: AGHT+IGQ/V489Y4uDtjRMAAouEeW0qAcy79IITu563yMx8AZhUwbRtKjpzgQhmvdHG3qBUlSeNkrTg==
X-Received: by 2002:a5d:4562:0:b0:333:135f:a7f4 with SMTP id a2-20020a5d4562000000b00333135fa7f4mr92339wrc.56.1701174073422; Tue, 28 Nov 2023 04:21:13 -0800 (PST)
Received: from ( []) by with ESMTPSA id v19-20020adfd053000000b0032f79e55eb8sm14540116wrh.16.2023. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Nov 2023 04:21:12 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.\))
From: Christopher Dearlove <>
In-Reply-To: <>
Date: Tue, 28 Nov 2023 12:20:58 +0000
Cc: Anders Nilsson Plymoth <>, "" <>, Juliusz Chroboczek <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Henning Rogge <>
X-Mailer: Apple Mail (2.3774.
Archived-At: <>
Subject: Re: [manet] AODVv2 implementation
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Mobile Ad-hoc Networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Nov 2023 12:21:20 -0000

I think it’s worth noting that the problems of triggering the need for a route request (from ICMP or however) are not the only reason for needing an implementation. We don’t of course have that need for OLSR (v1 or v2) but still needed implementation to create well-defined protocols. Of course OLSRv2 is a more complicated protocol than basic AODV - although if AODVv2 includes such things as multiple and heterogeneous interfaces the complexity starts rising - but I think it’s still well beyond the point where you can be satisfied all is well without an implementation. And then there’s the issue of performance, which is hard to assess even with an implementation.

> On 28 Nov 2023, at 06:23, Henning Rogge <> wrote:
> Hi,
> it's good to hear that at least someone built an IPv6 implementation
> of AODV... the existence of the "ICMPv6 Code Field" (AODVv2 13.6)
> suggested that there were at least plans for implementations in the
> past, but I never heard about one of them before.
> Just as a personal note, I always wondered why nobody tried to
> implement AODV with standard (Linux?) policy routing and a TUN device
> as a sink for unreachable IP traffic...
> Henning Rogge
> On Tue, Nov 28, 2023 at 2:18 AM Anders Nilsson Plymoth
> <> wrote:
>> Hi Henning,
>> I feel like I need to step into this discussion. First, I agree with you that I would like to see an implementation of AODVv2. It is needed because guidance is needed to steer the implementation, with example. Second.
>> Actually I would like to have access to a working implementation of AODV (v1), but my team haven't found one (the existing one have degraded into deprecation and non compilation so we are forced to use OLSRv1/2, (with success)).
>> AODVv2 would be implementable should someone have the resources, desire and skills for it.
>> I worked as an intern in Charlie's group 20+ years ago now at NRC, and at the time, they had an AODVv6 implementation. That implementation was promoted by Nokia's effort to drive IPv6 in general, with inputs from Bob Hinden being part of the team as well. Me, at the time, while working as an intern, also worked with HUT in Helsinki who in close collaboration with Nokia and their IPv6 implementation tried to introduce some additional research features. Some of this early work was adapted by Ryuji Wakikawa (now Toyota) into NRCs AODVv6 IPv6 and then Nokia and Toyota NEMO work, and on which me and Ryuji did some collaboration. As part of this work, I forked AODV-UU into the IPv6 Usagi branch with those mentioned research extensions. As for ICMPv6 "hacks", Ryuji and Charlie (and team) worked quite a bit on that, and made some specific modifications and submitted a couple of drafts to this group about that. It should be in the archives. In addition, I know the guys at Ericsson in Stockholm (forgot the names) were interested in this too. For Nokia, this was part of their core efforts of Nokia breaking into cellular Networking, where IPv6 was a key part of that strategy, including that AODVv6 implementation albeit somewhat on the periphery.
>> Anyway, fast forward to the future and about a year ago I was in need of an ad hoc routing implementation in Linux, and for our use case, reactive routing would make more sense in terms of topology changes. We couldn’t find any compilable AODV implementations for Linux, with patches, hacks etc. It was too far gone. We have instead versions of OLSR and OLSRv2 running in our prototypes, with some inadequacies I must say, but doing the job just fine.  But sadly an AODV implementation is currently not available, and neither anTo  AODVv2 implementation as per this thread, but the feasibility should not be in doubt. But again, even pushing a sponsored draft towards RFCx should have a current implementation. I am sorry to say this, but even here you need a big car, and my Outback is not that kind of car.
>> To get to the point, someone with muscle and money needs to step up.
>> Thanks,
>> Anders
>> On Mon, Nov 27, 2023 at 7:11 AM Henning Rogge <> wrote:
>>> On Sat, Nov 25, 2023 at 3:32 PM Juliusz Chroboczek <> wrote:
>>>> Hi Charlie,
>>>>> I do not have an implementation.
>>>> It is my understanding that Henning has concerns about the implementability
>>>> of AODVv2.  Given Henning's track record, I recommend that we should not
>>>> dismiss his concerns.
>>> Hi Juliusz, hi Charlie,
>>> I would not say that AODV (v1 or v2) is impossible to implement (some
>>> people have done it), but it's much harder to do on most general
>>> purpose operation systems than OLSR(v1 or v2) because of its necessary
>>> interaction with the forwarding plane.
>>> I think I have seen three AODV (v1) implementations in my life, two of
>>> them NS-2 emulator patches (I don't trust NS-2 code at all, most
>>> routing implementations take a lot of liberties that cannot be done on
>>> real software/hardware)  and one of them Linux... the Linux one was a
>>> mess, completely with a Linux Kernel module for a kernel 5+ years old
>>> (which made it in fact unsable).
>>> It seems no one ever took the time to seem if there is a good way to
>>> write the "ICMP-trickery/route-status-monitoring" in a clean way,
>>> which is most likely also the reason why I never heard about an IPv6
>>> AODV implementation, which would need a different ICMPv6 based hack.
>>> That's why I would like to see a running implementation of AODVv2...
>>> it's the only way to validate that you can build interoperable
>>> implementations from the current draft. It's also the only way to test
>>> if the metric integration in AODVv2 is working reasonably well,
>>> because I don't think ANY routing protocol will do us good with
>>> hop-count metric on any wireless radio that supports multiple data
>>> rates.
>>> Henning Rogge
>>> _______________________________________________
>>> manet mailing list
> _______________________________________________
> manet mailing list