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

[Donald Eastlake <[e-mail]>]

Hi Juliusz,

We seem to generally be in agreement. See below.

On Sat, Apr 10, 2021 at 7:53 AM Juliusz Chroboczek <[e-mail]> 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 192.0.0.0/24
block, you get to explicitly specify whether it can be used as a
source address or not, etc. See
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml.

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

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


> -- Juliusz