[babel] Investigating ICMP behaviour of the Linux kernel in IPv6-only mode

Toke Høiland-Jørgensen <toke@toke.dk> Tue, 15 June 2021 12:04 UTC

Return-Path: <toke@toke.dk>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id C4FDB3A2D2B for <babel@ietfa.amsl.com>; Tue, 15 Jun 2021 05:04:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=toke.dk
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id sgyrtmvYCjhz for <babel@ietfa.amsl.com>; Tue, 15 Jun 2021 05:04:35 -0700 (PDT)
Received: from mail.toke.dk (mail.toke.dk [IPv6:2a0c:4d80:42:2001::664]) (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 DB4C33A2D28 for <babel@ietf.org>; Tue, 15 Jun 2021 05:04:34 -0700 (PDT)
From: Toke Høiland-Jørgensen <toke@toke.dk>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=20161023; t=1623758669; bh=xpGPlsb18ohsfg3NFhEVsTiE/9AZKy795vKaMuCL0Uk=; h=From:To:Subject:Date:From; b=YQUIBlNRmWpdZoaAl6UIkUyVYEoyWJaonPjXKuRkSyZf0ty/2Hwg6CI7fS/OckLDb iMv+l1hDgpFBjhvD/M9+n3wvtDf+0ljzonr+0s9i11XswsxVRvcy9sSOSoW/VdQYT2 0Pw0pm6zaBwbr3d/S+sGmrEZUh4qRVYw1m7u2CGwBm1UsIUDsUQqIuel3Rb8DyyBud MqwoRepF9lFz6790rkBnF8YAIkPPniQtACZDjx/Np6uLBxCP+5yZHdVPIKatzKCZwj 8ZjggkUivE3tpkgTaNuZ3ciGejNMvktNnGe60Uob8EyoBusKyf5DBPKMzC5PizxXt4 Sps4zyOsp3+IQ==
To: babel@ietf.org
Date: Tue, 15 Jun 2021 13:38:40 +0200
X-Clacks-Overhead: GNU Terry Pratchett
Message-ID: <87a6nrs6gv.fsf@toke.dk>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/spHONhJlP-_PV3Kj4TzVGId87sg>
Subject: [babel] Investigating ICMP behaviour of the Linux kernel in IPv6-only mode
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2021 12:04:40 -0000

Hi everyone

Juliusz poked me to take a closer look at the Linux kernel behaviour
when sending ICMP messages in an IPv6-only environment, and figured I'd
share the results here. This is relevant for draft-ietf-babel-v4viav6
when it's implemented on Linux-based hosts.

What I found was that the kernel is perfectly happy to send out ICMP
messages with an all-zero source address if no real address is
configured on any interface. This can be demonstrated simply using
network namespaces like so:

# ip netns add ns0
# ip l add type veth peer netns ns0
# ip l set dev veth0 up
# ip a add dev veth0
# ip a add fc00:dead:cafe:42::1/64 dev veth0
# ip r add via inet6 fc00:dead:cafe:42::2
# ip -n ns0 l set dev veth0 up
# ip -n ns0 a add fc00:dead:cafe:42::2/64 dev veth0
# ip -n ns0 r add via inet6 fc00:dead:cafe:42::1
# ip netns exec ns0 sysctl -w net.ipv4.icmp_ratelimit=0
# ip netns exec ns0 sysctl -w net.ipv4.ip_forward=1
# tcpdump -tpni veth0 -c 2 icmp &
# ping -w 1 > /dev/null
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on veth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP > ICMP echo request, id 29, seq 1, length 64
IP > ICMP net unreachable, length 92
2 packets captured
2 packets received by filter
0 packets dropped by kernel

This is obviously not ideal for the behaviour we want in the v4viav6
draft. I've submitted a patch[0] to make the kernel fall back to the
dummy address specified in RFC7600. In the meantime, this can also be
achieved by adding the dummy address on the 'lo' interface of the Linux
host (and if any other v4 address is configured on any interface, that
will be used as the source instead of all-zeros).


[0] https://lore.kernel.org/netdev/20210615110709.541499-1-toke@redhat.com/