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

From: Donald Eastlake <[email-masked]>
Date: Wed, 7 Apr 2021 23:52:33 -0400

Hi,

Writing as a co-Chair, I think we should determine the WG decision on
how to handle the IP source address for IPv4 ICMP generated by a Babel
router that has no interface with an IPv4 address. Juliusz presented
on this topic to our meeting at the March IETF meeting. See
https://datatracker.ietf.org/meeting/110/materials/slides-110-babel-babel-source-specific-and-v4-via-v6-02
specifically slides 5 through the end.

I think slides 10 and 11 cover the practical choices. Any feedback or
opinions welcome.

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.
(At least in theory an Experimental RFC should say what the experiment
is and how the results will be determined, although there certainly
are Experimental RFCs that fail to do this.)

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

On Tue, Oct 20, 2020 at 3:34 PM Théophile Bastian
<[email-masked]> wrote:
>
> Hello everyone,
>
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Babel routing protocol WG of the IETF.
> >
> >          Title           : IPv4 routes with an IPv6 next-hop in the Babel routing protocol
> >          Authors         : Theophile Bastian
> >                            Juliusz Chroboczek
> >       Filename        : draft-ietf-babel-v4viav6-00.txt
> >       Pages           : 8
> >       Date            : 2020-10-20
>
> With much delay (sorry about this, I got caught in too many things at
> once), I uploaded `draft-ietf-babel-v4viav6-00` as discussed in IETF108,
> which replaces `draft-bastian-babel-v4ov6-NN`.
>
> In this submission, I only updated the submission name, slightly changed
> the title and the date. I will shortly begin to work on an updated
> version, which will
>
> — use "v4-via-v6" instead of "v4-over-v6" (thanks Barbara for the name,
> it is definitely better);
> — address the ICMPv4 issue (if a machine has no IPv4 address at all on
> any interface, it is unable to send ICMPv4 packet).
>
> Cheers,
> --
> Théophile Bastian
>
> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 08 Apr 2021 14:22:43 +0200

> I think slides 10 and 11 cover the practical choices. Any feedback or

To restate the opinion I presented during my talk: the dependency of PMTUd
on ICMP is the fundamental problem here, since it breaks the end-to-end
nature of TCP.  The Babel WG is however not the right forum to redesign
PMTUd.  無.

The draft should merely say that every IPv4 router MUST be able to send
ICMPv4 packets.  How this is realised is an implementation detail -- the
v4 address could be assigned to the outgoing interface, to the router as
a whole, or a fallback address hard-wired in the ICMPv4 module.  The draft
should also state that the router need not be able to receive packets
destined to that address, and that the address need not be locally or
globally unique.  It should discuss debuggability issues, perhaps in an
informative appendix.

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

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 08 Apr 2021 16:21:29 +0200

> 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

---

From: David Schinazi <[email-masked]>
Date: Thu, 8 Apr 2021 08:54:44 -0700

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
<https://datatracker.ietf.org/doc/html/rfc7600#section-4.8>)
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
<https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1>. When RFC 1883
<https://datatracker.ietf.org/doc/html/rfc1883> 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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 8 Apr 2021 23:34:08 -0400

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

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

Thanks,
Donald

Thanks,
Donald

On Thu, Apr 8, 2021 at 11:54 AM David Schinazi <[email-masked]>
wrote:

> <https://datatracker.ietf.org/doc/html/rfc2026#section-4.1.1>. When RFC
> 1883 <https://datatracker.ietf.org/doc/html/rfc1883> was published in
> 1995,

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 09 Apr 2021 13:32:26 +0200

> If people think this is too complex,

I don't think it's complex, I think that it might be difficult to
integrate in an existing implementation of ICMP.

Different ICMP implementations have different behaviours.  A router vendor
who wants to implement this draft will likely want to minimise the amount
of changes that they need to make to their implementation of ICMP; if we
constrain the behaviour too much, the amount of changes will likely
increase, which in turn might hamper deployment of the protocol.

I therefore agree with David that we should aim for the least constrained
description that still ensures that PMTUd isn't broken.

-- Juliusz