Subject: [babel] Robert Wilton's Abstain on draft-ietf-babel-v4viav6-07: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Tue, 15 Feb 2022 02:45:51 -0800

Robert Wilton has entered the following ballot position for
draft-ietf-babel-v4viav6-07: Abstain

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-v4viav6/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I'm abstaining because whilst I think that the solution here is clever, I'm
less convinced that it is a good idea, particularly as an IETF standards track
document.  In particular, the use of 192.0.0.8 as a source address could easily
be quite confusing for end-hosts trying to figure out network issues.  It would
be interesting to know whether there are any real or planned deployments of
this draft.

Regards,
Rob

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Feb 2022 16:06:09 +0100

> be quite confusing for end-hosts trying to figure out network issues.

I understand your point.  I initially submitted the extension as an
experimental document to the Babel WG, but the WG was strongly in favour
of pushing it for Standards Track, and they convinced me.  The main
argument is that this technology has the potential to ease IPv6 deployment
in small networks: with standard transition technologies, deploying IPv6
incurs a non-negligible cost; with v4-via-v6, deploying IPv6 gives you
IPv4 essentially for free, thus making it economically viable to deploy
IPv6.  The technology also has a natural sunsetting procedure: the
v4-via-v6 routes disappear as soon as the IPv4 prefixes are retracted.

The use of 192.0.0.8 needs to be standard across all routing protocols.
Please let me quote myself (mail of 14 April 2021):

    By the time the IPv4 module has decided it needs to send an ICMPv4 packet,
    it does not necessarily know whether the issue it's reporting is due to
    Babel or to some routing protocol.  In fact, there might not even be
    a well defined responsible protocol -- if a router running both Babel and
    BGP finds out that it has no route to a given destination, is the ICMPv4
    packet associated with Babel or BGP?

    Thus, any implementable procedure for sending ICMPv4 must be independent
    of any given routing protocol -- so it's not reasonable to have a Babel
    dummy address, distinct from a hypothetical BGP dummy address or an OSPF
    dummy address.  If we define a dummy address, that address must be common
    across all routing protocols.

As you rightly point out, this may complicate fault isolation.  The proper
solution is to define, promote, and implement an ICMP extension that
carries the associated IPv6 address; however, given the lack of enthusiasm
at this point for extensions to IPv4, I doubt this can happen.

> It would be interesting to know whether there are any real or planned
> deployments of this draft.

V4-via-v6 is not yet in the version of Babel in OpenWRT (the Linux
distribution for small routers), since we haven't yet written the code
that checks whether the underlying Linux kernel is compatible with the
extension.  Once we've written (and tested!) all the necessary checks, it
will be possible to enable it by default, at which point all networks that
run Babel on OpenWRT will start deploying it.

-- Juliusz

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 24 Feb 2022 18:25:18 +0100

> document.

The document has been made Experimental, as you suggest.

> deployments of this draft.

We are planning to release a version of babeld with this extension enabled
by default this spring, assuming our testing goes well.  At that point,
all routers that use babeld in the default configuration will deploy this
extension as soon as they get an update.

-- Juliusz

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 24 Feb 2022 17:48:19 +0000

Hi Juliusz,

> -----Original Message-----
> From: Juliusz Chroboczek <[email-masked]>
> Sent: 24 February 2022 17:25
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked]; babel-
> [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Robert Wilton's Abstain on draft-ietf-babel-v4viav6-07: (with
> COMMENT)
> 

Yes.  Thanks for letting me know.  On hearing this in last week's IESG telechat I changed my ballot from Abstain to No Objection.  I probably should have updated the comment at the same time, to avoid any confusion.

> extension as soon as they get an update.

Thanks,
Rob