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

Donald Eastlake <> Fri, 09 April 2021 03:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1F5353A298D; Thu, 8 Apr 2021 20:34:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.846
X-Spam-Status: No, score=-1.846 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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 KVGdeqz0n82B; Thu, 8 Apr 2021 20:34:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8B4983A298C; Thu, 8 Apr 2021 20:34:21 -0700 (PDT)
Received: by with SMTP id x3so2993250ilg.5; Thu, 08 Apr 2021 20:34:21 -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=qV2ZsxtGcy1eQ4p97HsiTvBoLJK8DWZ7izhtzuWYJX0=; b=YduztYEaVvTT2sCkj6xS8nzTAlAuzeJQt6ZD409gcU9jO4Q0/ZrJqq8BIEBhaSvZZZ Ua0XYqOnt4upAPTX6iXKkFfFm1h4YTfNAbApzQvWCZkY2eNaqk1WzjuWKA2BfO4IQVl0 K95UvTy4tVkRZE8g992h+6yWQeeger0p0e1OMCE/NDWa0rJ/uorr3qN4W86mBbsP2Lsw qxi0ri6UaKpyJdqmNqvUflgTAi2MHwHV5Vkdb5bCDwukUemub/KQtO1XOOA5/QxZEJ80 dJA7U85GoFRltl1U4Gw1cOo+1//J28KZvR0SxcUFwAcruOqdBVaqEhk73qoxzS6PnfQr /QKg==
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=qV2ZsxtGcy1eQ4p97HsiTvBoLJK8DWZ7izhtzuWYJX0=; b=erRZxrskaNdGbn85gBTeGCAu/y9ntNXl5qwWz/wjD1KrHYN6zaViPfZDqfXfp+R+vY ZAfEMzOj5/UokomMLfalPS9EWVEFlqTl/kCMfGkxtopKoKewUZsXsqcbKLkvh+U79qsa epeO2AlE8aff6gad1S4Rh9ZIX2kijpv/T8avbmaq4xBopXBkgA3aDV+i4GGWYodfJ4mz rqsnyW3CrgE4Hkgw0WdIYiPcQ2IrnO47otpXoQjfBTMI5xXSQyPYoDmFXn4L1JogJUmI hnpauL9bXKwhgXK8URkS5w+WUHnbczZKmWUVzpi6dArrmSTl1EVd35cn2ViplqaEj9wr RE9A==
X-Gm-Message-State: AOAM530WjcU0uuyup63e4N8IrvoOOCW4X+nNHpgbWb5v3DwMMU70A4ki DTrxzNp8ErAiQ++w8ukd4qFGW6Pkna/e6ioF3hy63+sYguU=
X-Google-Smtp-Source: ABdhPJy+8XFzYK6G2mDD8KyXNYLn95Ei/lKBo1Vojx8mw+Gjayv1R4doz4YDdPhf9hj/fduKPnyIS9lGnVFfGBftcFE=
X-Received: by 2002:a92:ad11:: with SMTP id w17mr8875440ilh.199.1617939259515; Thu, 08 Apr 2021 20:34:19 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Thu, 08 Apr 2021 23:34:08 -0400
Message-ID: <>
To: Babel at IETF <>
Cc: babel-chairs <>
Content-Type: multipart/alternative; boundary="000000000000d4e74505bf81d6be"
Archived-At: <>
Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-00.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: Fri, 09 Apr 2021 03:34:24 -0000

Speaking just as a Babel working group member:

I view the source IP address of an ICMP as helping to identify, to the
extent it can without undue effort, the router that generated the ICMP. And
I agree that we should minimally constrain the Babel router consistent with

   1. Obviously, if you are generating an ICMP to send out an interface and
   that interface has an IPv4 address, that's the address you use.
   2. If the interface does not have an IPv4, then the router MAY use the
   IPv4 address of any other interface or an IPv4 address that it has been
   configured to use for this purpose.
   3. If no IPv4 address is available as listed in 1. and 2., then it is
   RECOMMENDED that the Babel router dynamically generated a "Link Local" IPv4
   address [RFC3927] and use that as the ICMP source IP address.
   4. if none of the above are available or convenient, a Babel router MUST
   use the Babel dummy IPv4 address TBD (value suggested).

If people think this is too complex, step 3 could be dropped but it
provides a significant improvement in identifying the ICMP source Babel
router. There are plenty of "MAY"s and a RECOMMENDED in there so someone
who just doesn't feel like implementing all this can skip most parts. I
think we should get a Babel specific dummy address for the last resort step
because it should be easy and it provides a tiny bit more identification
than, for example, using the generic dunn IPv4 address.

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

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

On Thu, Apr 8, 2021 at 11:54 AM David Schinazi <>

> On the topic of the ICMP IPv4 source address, I agree with Juliusz.
> The specific value of that field is not required for interop, so in the
> spirit of Babel specs we shouldn't over-constrain implementations.
> Saying that routers need to be able to send ICMPv4 seems like the
> right choice here. I would suggest adding some implementation
> advice saying that using the same address (e.g. the dummy address
> <>)
> on all routers is simplest but using different addresses can simplify
> debugging.
> On the topic of standards/experimental, I think that this specification
> matches the maturity required of a proposed standard as defined in
> RFC 2026 Section 4.1.1
> <>. When RFC
> 1883 <> was published in
> 1995,
> I don't think that IPv6 had a lot of implementation and deployment
> experience. But I don't feel too strongly here, as the consumers of
> RFCs generally don't look at the track/category when deciding what
> or how to implement.
> David
> On Thu, Apr 8, 2021 at 7:22 AM Toke Høiland-Jørgensen <toke=
>> wrote:
>> Juliusz Chroboczek <> writes:
>> >> There is one other question in my mind. Does this draft really need to
>> >> be Experimental? I would be inclined to target it to Proposed Standard.
>> >
>> > I'm a little uneasy on this subject.  My personal feeling is that we
>> > haven't done our homework on this extension (admittedly my fault), and
>> > that we don't have enough implementation and deployment experience to
>> > propose it as a standard right now.
>> >
>> > I'd be delighted if people could disagree.
>> Isn't that just a matter of time? I.e., we could adopt it as PS, with
>> the expectation that by the time it gets published we will have built
>> that experience? Or does there even need to be a final decision about
>> the status at adoption time?
>> -Toke
>> _______________________________________________
>> babel mailing list