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

Juliusz Chroboczek <jch@irif.fr> Sat, 10 April 2021 11:53 UTC

Return-Path: <jch@irif.fr>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12A903A309E for <babel@ietfa.amsl.com>; Sat, 10 Apr 2021 04:53:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9JsJggBke-3 for <babel@ietfa.amsl.com>; Sat, 10 Apr 2021 04:53:28 -0700 (PDT)
Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 D05A13A309D for <babel@ietf.org>; Sat, 10 Apr 2021 04:53:27 -0700 (PDT)
Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id 13ABrMPU027190; Sat, 10 Apr 2021 13:53:22 +0200
Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id 83C45CF2B8; Sat, 10 Apr 2021 13:53:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr
Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id 3QsBxbvj1EZT; Sat, 10 Apr 2021 13:53:20 +0200 (CEST)
Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id D19BECF2B6; Sat, 10 Apr 2021 13:53:18 +0200 (CEST)
Date: Sat, 10 Apr 2021 13:53:18 +0200
Message-ID: <874kge1hld.wl-jch@irif.fr>
From: Juliusz Chroboczek <jch@irif.fr>
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
In-Reply-To: <CAF4+nEGu1Uj12UNz03meFTf7hXsZ1sxvfTHsPNtcRLt+Dncecg@mail.gmail.com>
References: <161799373903.21494.5029385648255827216@ietfa.amsl.com> <87y2drmgxz.wl-jch@irif.fr> <CAF4+nEGu1Uj12UNz03meFTf7hXsZ1sxvfTHsPNtcRLt+Dncecg@mail.gmail.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/27.1 Mule/6.0
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset=US-ASCII
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 10 Apr 2021 13:53:22 +0200 (CEST)
X-Miltered: at korolev with ID 607191B2.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)!
X-j-chkmail-Enveloppe: 607191B2.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/<jch@irif.fr>
X-j-chkmail-Score: MSGID : 607191B2.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000
X-j-chkmail-Status: Ham
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/YXLDwFuHYJe0geUktmHUR3UVk4U>
Subject: Re: [babel] I-D Action: draft-ietf-babel-v4viav6-01.txt
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: Sat, 10 Apr 2021 11:53:30 -0000

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.)

> 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?

> 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.

-- Juliusz