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

[Donald Eastlake <[e-mail]>]

Hi Juliusz,

On Fri, Apr 9, 2021 at 2:49 PM Juliusz Chroboczek <[e-mail]> wrote:
>
> >       Filename        : draft-ietf-babel-v4viav6-01.txt
>
> I've made a full pass over the existing text, fixing typos and rewriting
> stuff.  I've almost completely rewritten the Security Considerations
> section, which I'd be grateful for people to check.

Thanks for getting the draft updated and posted. I like the additional
material in the Security Considerations section.

> Section 3 is new, and contains the word "hamper", a fact that makes me
> immensely proud.  I consider it as a starting point for discussion.  It
> differs from Donald's suggestion in the following ways:

Hamper is certainly a good word for the use you have made of it.

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". There
are a lot of ICMP types and subtypes:
https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml

>   - it merely states that a router MUST be able to send ICMPv4 messages
>     (after explaining why), implementation techniques are worded as mere
>     examples;

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. For example, there is also
traceroute. RFC 1812 (Requirements for IP Version 4 Routers) says
"ICMP Time Exceeded messages are required because the traceroute
diagnostic tool depends on them."

While it is frequently claimed that "ICMPs are dropped by the core
routers of the Internet", I don't think that is generally true. I just
did some traceroutes from my home computer to the Google DNS servers
at at 8.8.8.8 and 8.8.4.4.  Sometimes the packets are sent for a few
hops via routers in the core Internet that simply don't seem to
produce "time expired" (actually hop count exhausted) ICMPs but
occasionally ICMPs are produced and my home computer gets them back
from every router along the path. And I always seem to get ICMPs back
from the far end so those ICMPs are all being forwarded through the
core Internet.

Anyway, I think there should be some sort of reference in passing to
"traceroute and other uses" or the like.

>   - it doesn't include Donald's suggestions to (1) use a randomly drawn
>     address or (2) use the Babel dummy address, as I think they deserve
>     further discussion.

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.

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. So the 3rd paragraph could end with "... originate ICMPv4
packets even when the interface on which they will be transmitted has
not been assigned an IPv4 address." and the text in the 4th paragraph
could be "... if a router has another interface that has been assigned
an IPv4 address ...".

A bit later, I would prefer if "for example an address taken from a
private address range [RFC1918] that is known to not be used in the
local routing domain" were changed to something like "for example
dynamically created address as described in [RFC3927] or an address
taken from a private address range [RFC1918] that is known to not be
used in the local routing domain".

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

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

> -- Juliusz