Re: [babel] I-D Action: draft-ietf-babel-v4viav6-01.txt

Donald Eastlake <> Tue, 13 April 2021 19:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0574F3A24C0 for <>; Tue, 13 Apr 2021 12:42:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 fkM3mKMC5fl3 for <>; Tue, 13 Apr 2021 12:42:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 380D13A24CB for <>; Tue, 13 Apr 2021 12:42:40 -0700 (PDT)
Received: by with SMTP id l19so11207506ilk.13 for <>; Tue, 13 Apr 2021 12:42:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9/5tfAz/QBxenn+A5ST5lNyzJ1K5HACXLB5cOvzI3U4=; b=hEYFW+kMgZitQOPgLHN4bOJsv9u0yAEEp1DqNu+yT8u+JZN9QY3vkytAbI/eQid1Vx HiQpDRupdpkVJPA7oJAghMByPZY/NJznx46E/Z65hzdRh8qTIRSiHHv2OPfA4AMOtBN1 jLxkIlVvAaOgPRzeKC/lQH6hzJkaOCWLXzMb7zxHz4auI57VYDk8OYoyWs44CzvoagX9 4e1qw6TCsqQ1Z2CxAwTMEBbF0iwrJ6ozLQZ+CY1zRsjbArG2wm+XbnLdVBueOkKKUkt6 k99ZqFNzqNiMyKR9dkFY8ZiHvEGbCZWe8+iof7+z65G26qlLL//j78zrJYdWj4FxAA/1 qROA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9/5tfAz/QBxenn+A5ST5lNyzJ1K5HACXLB5cOvzI3U4=; b=BYUnO4AcYY5rLhpNn8ZFGRp6CvL3YSUSpK33mMAtu19YqZQxvmhVZoinDRUpiPilc6 yob6BjjWH7+sC5bJlSk1Pmjqu/LvTZa3fiJTvdR2t77840LnTJyfJ4O3gbCD3D7oDQ7N fKc5zPFbiIsykS3bLCQmHkdE7/eZEt6kL/gB/CoxcT+5J9Cr/LGpYUS2kydumUds7dC6 JwApFcwsFFhgYDmuyujCm69KlDt6eqvdswUGxl/dKXvS+zvd07+O42UOjavCraRkQKsS vQv9TUxLsxMWtcffXvs4frgEgr10vPQjtmvKMCxr9MfIR32yWSmrDnO9eBoQ2q6HnTHA uIqg==
X-Gm-Message-State: AOAM530AA1uTscegdbV6iSpQ/qWbLvJwYyWmFzItM3bW4y6cmuyLx/WP f8tWm4Qrq2Ip3aaog9Zi3ArmmcUWfwZbAXCE/YE=
X-Google-Smtp-Source: ABdhPJzd06DZKZExQJb6gkpLIAc3S2yFFC7WCLv8CtzyvwFjBqgsWw7f25qHqHrQ1dhI7E/3pgtupxtUs9rgsBY1oN4=
X-Received: by 2002:a05:6e02:16cf:: with SMTP id 15mr7576966ilx.199.1618342957789; Tue, 13 Apr 2021 12:42:37 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Tue, 13 Apr 2021 15:42:26 -0400
Message-ID: <>
To: Juliusz Chroboczek <>
Cc: Babel at IETF <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Apr 2021 19:42:45 -0000

Just speaking as a wg member:

Hi  Juliusz,

I believe an important part of "engineering" is assessing the balance
of factors in favor of or against various choices. Simplicity is a
good thing so it would be nice if IPv4-less Babel routers did one
simple thing for a source address. On the other hand, minimizing
restrictions on implementers and being able to adapt to different
conditions is good. In this case, I think the balance is towards the
second point and alternatives should be provided.

On Tue, Apr 13, 2021 at 9:11 AM Juliusz Chroboczek <> wrote:
> > I can see questions about using a dummy address, since it implies
> > multiple routers with the same address. But I really don't see any
> > problem with a dynamically allocated IPv4 address (a la RFC 3927) as
> > another example of a way to meet the requirement.
> Ok, let's see if I read the group right.
> 1. David suggests that I mention, the dummy address assigned
>    for 4rd (RFC 7600).

 A "dummy" address is a reasonable alternative. I think the source IP
address in an ICMP serves two functions. One is to make the packet
"legal" so it wouldn't be thrown away as malformed or malicious. The
other is to provide information that helps to identify the source for
management/debugging/whatever purposes. A "dummy" address is not going
to provide much information but if an implementer is going to follow
that path, it might as well be a Babel specific dummy address. The
existing "dummy" IPv4 address seems to have to do with IPv4 ICMP
messages created by converting ICMPv6 messages [RFC7600]. Possibly
there could be a network in which both could be generated as a source
address and with a separate Babel dummy address, you at least have one
bit of specificity.

> 2. Donald wants me to suggest dynamic allocation from the RFC 3927 range.

Well, I did want that option but your quotes from RFC 3927 convinced
me that the risk of packets with such a "link local" source address
being discarded by routers was too high so I no longer support that.

> Concerning 1, the current draft explicitly uses the term "dummy address",
> which is a nod in David's direction.  On the other hand, I'm a little
> reluctant to mention RFC 7600 explicitly, since I'd rather we avoid being
> associated with packet translation techniques.  Yuck.

Another reason to go with a Babel dummy address.

> Concerning 2, I'm going to add a mention of dynamically drawn addresses,
> but I'm going to avoid mentioning 3927 explicitly, since I'm not sure that
> using 3927 addresses outside of the local link is legit.  Additionally,
> doing otherwise might imply that the conflict detection and defense
> mechanisms in that document are applicable (or desirable) in our context.

Sounds reasonable.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

> Ok?  If not, yell!
> -- Juliusz