Rolf, > On Jul 21, 2024, at 11:41 PM, Rolf Winter <[email protected]> wrote: > > Dear Eric, > > thank you for your comments. I inlined my replies. > > Am 21.07.24 um 16:51 schrieb Eric Vyncke (evyncke): >> Dear authors, >> Without any hat (i.e., feel free to ignore), in preparation for the IETF-120 >> I have read your I-D and here are some comments. As always, reviews note the >> things to be improved and are not criticisms. >> # Generic >> This I-D/idea is really interesting and useful, unsure whether it is really >> stateless if some routers have to transmit several probes. > > It is stateless in the sense that the party performing the actual traceroute > operation does not need to maintain state locally. Everything that it will > need when the ICMP Time Exceeded message comes back, it will find in that > packet. > >> English is also not my native language, but please use a spelling/grammar >> check or have it reviewed ;-) Sorry to write this but the text does not >> always help to convey the good message. > > Will do. > >> # Section 1 >> IPv6 is now RFC 8200 and not RFC 2460 ;-) and does not have a TTL field but >> a hop-limit field. > > That's correct. Since the draft addresses both v4 and v6 I would rather write > somewhere in the introduction that TTL refers to both v4 and v6 instead of > writing "TTL/hop count" whenever we talk about the TTL. I guess the draft > will be more readable this way.
That is not correct and will be confusing. The field in IPv6 is Hop Count, not Time to Live (TTL). This document should describe them accurately. Bob > >> If ` The mechanism defined in this memo does not require router changes` is >> correct, then the intended status should rather be informational as it does >> not change a protocol. > > Informational is not enough. We do define new ICMP machinery incl. asking for > code points. > >> # Section 1.2 >> Please use the correct BCP14 template > > I was hoping xml2rfc was handling this correcly. Will check. > >> # Section 2 >> Mixing “host” and “node” (i.e., a “router” could also initiate such a >> traceroute) > > There is nothing preventing a router from doing so, that is correct. But > there is also nothing preventing a router to perform a regular traceroute. > >> # Section 3.1 >> Not all traceroute “probes” are actually ICMP packets so ` The traceroute >> request MAY be followed by an ICMP extension `does not always apply. > > Section 3.1 is _not_ about the probes, it is about the request, i.e. asking > somebody to send a probe. That is, at least as defined by this document, done > via ICMP. Probes could be UDP, ICMP or TCP. > >> Add “and ignored by the receiver” after ` MUST be set to 0.` > > Alright. > >> ` TTL: The Time-To-Live` what about IPv6 hop limit ? ;-) (it further occurs >> several times) > > See my suggested fix above. > >> ` Supported SHOULD be ICMP, TCP and UDP.` how can a single field have 3 >> values ? ;-) > > It cannot at the same time of course. But those are the ones an > implementation SHOULD support, just like most traceroute implementations > today. > >> # Section 3.2 >> “server” or “router” in ` A traceroute response is sent by a server` ? > > The server, communicating the results of the traceroute operation to the > client. > >> # Sections 4 & 5 >> To be honest, they are not obvious to understand (and to add a 2nd “to be >> honest”, I have reviewed this in my flight from Brussels to Vancouver, so >> not with a sharp mind). > > Will look through them again, but if you find some time to go over them with > a "fresh mind" and have more specific comments on those two section, we are > happy to hear them. > >> # Section 6.1 >> ` It does so by setting the TTL inside the traceroute request message to 0` >> ? Is it in the IP header ? Then it cannot be transmitted. > > It refers to the requested TTL inside the traceroute request message defined > in section 3.1 not inside the actual IP header. > >> # Section 9 >> *I may have misunderstood* the proposed mechanism, but it seems that it >> could open the door for an amplification attack if all intermediate routers >> start their own traceroute. > > Why would they? This is not what the document suggests. There is a small > amount of amplification, which is what basically triggered Section 5.1, the > padding extension. This extension makes sure the client sends as many bytes, > as the server will send. > >> Sincerely hoping that it helps, looking forward to the intarea WG discussion > > Thanks Eric for taking the time to read the document. Will make sure the next > version reflects your comments. > > Best, > > Rolf > > >> -éric >> _______________________________________________ >> Int-area mailing list -- [email protected] >> To unsubscribe send an email to [email protected] > _______________________________________________ > Int-area mailing list -- [email protected] > To unsubscribe send an email to [email protected]
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Int-area mailing list -- [email protected] To unsubscribe send an email to [email protected]
