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

Donald Eastlake <> Sun, 11 April 2021 01:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E10B73A23AD for <>; Sat, 10 Apr 2021 18:35:57 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 BLoA8UNS9IoY for <>; Sat, 10 Apr 2021 18:35:52 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A32B23A23AB for <>; Sat, 10 Apr 2021 18:35:52 -0700 (PDT)
Received: by with SMTP id i22so3282836ila.11 for <>; Sat, 10 Apr 2021 18:35:52 -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=opOpdn/ALhw07sg8CYC2CreO6iLXYo7rgu0yL6zA9Q4=; b=a4/pD/xq7l1uZy4+pyDfd3oMR+vWELjTLMWCD7OXWLDREssd7LcxvhtqMfTZWgfqcy rVQ1r4mzgGCVjlRuWmg+L6J73UhTnDYw8hMHa6cdH85eMnY2jzftYAnVHBwbOd5EVF9w Eis87fXV6HZ8M8QEdcEA1NNR3Am1QoM6Q+eE72+OlIbHOoiBjf4TiqVoNXLH2a+WTqBU hO5SmyVJ9zWZaHk/ApaA/fi+TS3bX/ZA1bpylddwTvQ9gPwYDD726Uq4k+279P0e+Sm4 JTdAh4+iH5NpJagf/s24mIuCl8zv943qi9465IyBW1u84eIDOi5bevbtDcuPh3iw5DUU b/sw==
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=opOpdn/ALhw07sg8CYC2CreO6iLXYo7rgu0yL6zA9Q4=; b=DTWzyhZ2AhMSRzPn2g2/IVxkIp+qvj0OZU51TE8bhdD85PDmiH3HFKPhgiM4FN95xU RStMdMfiUTtgHSmKzt+pmX9rFo6ML7t/ZLj8ojUpjjYGjsMl+G4Xae2HUuW86tXhOkSx K5B49OoUD8IY/+lCaNaQWOeNespxIcezaEvTJBElv9/Yx6dSaxJiLZpV6CBtp6y4Jplc DLeFzExJsRH5HvdRxIeaV85Q7bLnbL+Wf0UZaLk7xJT3QmMIcbb2f5V1JJTTmWGSv46b Xq6UTqIQwi0y35xd9qNh114RlcItLRlcqE9NIz/8LkC159AKgFF82Hp3wz1TPE0IcF6C 7Qgw==
X-Gm-Message-State: AOAM532hN5D4w32Qbro7FGdysdSolK1hauII52M/BBCA07iLTngSUzEs dTQwGw8H5cgmbwSI9ORjukhLZjBUlar95TkXHcQ=
X-Google-Smtp-Source: ABdhPJy8r1K/aVugqTaqfH79X+zZS/FueEZ9M42AJ7rnnjG4pTDDT9VknOwx1/lvx56/Sn6wmPA/DoPQfpGC0AoP67w=
X-Received: by 2002:a92:1a12:: with SMTP id a18mr6873984ila.168.1618104950866; Sat, 10 Apr 2021 18:35:50 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Sat, 10 Apr 2021 21:35:39 -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: Sun, 11 Apr 2021 01:35:58 -0000

Hi Juliusz,

We seem to generally be in agreement. See below.

On Sat, Apr 10, 2021 at 7:53 AM Juliusz Chroboczek <> wrote:
> Thanks for your review, Donald.
> > Maybe your first sentence is a little too restrictive. Perhaps "that
> > is primarily used to carry diagnostic and debugging information."
> > rather than "that carries diagnostic and debugging information".
> Right.
> > I don't have any problem with the above but, while path MTU discovery
> > may be the strongest reason for ICMP, I do not think we should imply
> > it is the only reason of significance.
> [...]
> > Anyway, I think there should be some sort of reference in passing to
> > "traceroute and other uses" or the like.
> You're right, I'll think about how to formulate it.  The point I'm trying
> to make is that while it might be okay for this extension to break
> diagnostic tools (presumably, it is preferable to partially break
> traceroute due to this extension rather than breaking it completely by
> using v4-in-v6 tunnelling), it is not okay to break higher-layer protocols
> that rely on ICMP.  (I'm also trying to hint at the fact that I consider
> it a dubious design for higher-layer protocols to rely on ICMP, but that's
> not the main point here.)

While traceroute is most useful if all the routers along the path have
unique IPv4 addresses, it still provides useful information if that is
not true.

> > 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.
> I need some time to think it over.  On the one hand, 3927 is pretty clear
> that link-local addresses are for communication on the local link.  On the
> other hand, using 169.254/16 as the source address is no different from
> using fe80::/64 as the source address, which is what happens when an
> unnumbered IPv6 router needs to send an ICMPv6 packet.
> Quoting Section 2.7:
>    An IPv4 packet whose source and/or destination address is in the
>    169.254/16 prefix MUST NOT be sent to any router for forwarding, and
>    any network device receiving such a packet MUST NOT forward it,
>    regardless of the TTL in the IPv4 header.
> Granted, this requirement does not apply to ICMPv4, but it still makes me
> nervous.  What if a router decides to summarily drop all packets with
> a source address in 169.254/16?

That is a point against using [RFC3927] addresses. But I think the
idea of providing a variety of alternatives for implementers is good.
So maybe if we don't give [RFC3927] addresses as an alternative, a
Babel dummy address should be assigned and available as another
alternative. When such an address is assigned from the
block, you get to explicitly specify whether it can be used as a
source address or not, etc. See

> > Looking carefully at the new Section 3, the end of the third paragraph
> > ("has not been assigned an IPv4 address") and the text near the
> > beginning of the 4th paragraph ("that has been assigned an IPv4
> > address") sound a little contradictory. I suggest they be made more
> > precise.
> Agreed.
> >> Finally, I did not change the intended status (Experimental to Standards
> >> Track), as it is not my role to gauge whether there is sufficient
> >> consensus on this subject.
> > While there haven't been a lot of comments on this, I think that so
> > far they lean towards Proposed Standard.
> I'm fine with it either way, but I'll want one of the chairs to send me
> a clear order that I can refer to.

OK. I'll wait a couple of days and thenell you my judgement...

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

> -- Juliusz