Hi John, Thanks for bringing this to the WG's attention.
As a WG member, I support your proposed resolution of the erratum. As RTGWG co-chair, I will continue to track this issue in case there are any objections or intestines in updating the RFC in the future. Thanks, Yingzhen On Thu, Mar 6, 2025 at 10:40 AM John Scudder <jgs= [email protected]> wrote: > Hi Alexander, all, > > I propose to verify this erratum as “hold for document update”. It doesn’t > perfectly fit the guidance for any of the categories, but that seems like > the closest to me. The erratum will still show up for anyone who looks at > the errata for the RFC, which seems like it addresses the most pressing > concern of displaying a “bug report”, and if the working group should ever > take up work on a follow-on document, they can discuss the details of > exactly how to improve it at that time. > > If there are any objections to this approach, please let me know soon. > > —John > > On Feb 21, 2025, at 9:10 PM, Alexander Patrakov <[email protected]> > wrote: > > > > Hello, > > I agree that I have not provided a clear resolution, and a good resolution > would not amount to a small edit. The suggested small edit is the minimal > one to ensure factual correctness, that is, to establish that the approach > based on ICMPv6 Destination Unreachable with Code 5 message does not work > and cannot work at all in any operating system that implements the usual > Berkeley socket API, unless the application itself is prepared to handle > such errors. > > As RFC 8678 is informational, it is important to ensure its factual > correctness, that is, state that the application must be modified to > cooperate in order for the proposed mechanism to work. > > It's a good question whether applications are already expected to handle > such "use a different source IP" errors themselves by retrying the > connection, in exactly the same manner as when there are multiple DNS AAAA > records for the destination and connecting to the first one fails. If they > are, such an assumption should be documented. Documenting such an > assumption would be a satisfactory resolution for me. Another good question > is which API is available in common OSes to signal this condition to > applications, as this affects the feasibility of implementing this part of > the approach. It would be bad if we assume that applications implement this > required behavior without having any means to do so. > > Anyway, please treat the erratum report as a bug report in the RFC, not > directly as a suggested edit. I do not insist on the suggested edit and am > open to discussing better edits. If this means setting it to the Rejected > status (because the suggested edit is of too-low quality), so be it. > > Also, let me state that the approach discussed in RFC 8475 is much easier > and better where it is applicable, i.e., where multihoming is not actually > needed and a simple fail-over is sufficient, but RFC 8678 specifically > deals with the true multi-homed case. Perhaps a link to RFC 8475 can be > added in an updated text once RFC 8678 is updated or replaced. > > On Sat, Feb 22, 2025 at 8:41 AM John Scudder <[email protected]> wrote: > >> Hi RFC 8678 Authors, RTGWG, >> >> Alexander Patrakov filed https://www.rfc-editor.org/errata/eid8002 >> <https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid8002__;!!NEt6yMaO-gk!HQtqNjuOuDuv9X7Z-_bRswxAv06apTJgVRjuVBMt2tSgjz8jk0rFFkPYnV1AUj0a9L1qRKLfXe_7wA$> >> against RFC 8678. I don’t see any reply to the erratum in the archives. >> >> I’m hoping one of you can comment. In looking at the erratum, my first >> inclination is to reject it, although there is also a case for Hold For >> Document Update. See >> https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ >> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/__;!!NEt6yMaO-gk!HQtqNjuOuDuv9X7Z-_bRswxAv06apTJgVRjuVBMt2tSgjz8jk0rFFkPYnV1AUj0a9L1qRKJ05AsIzw$> >> for a discussion about the disposition of errata, it looks to me like point >> 4 applies here: “Technical items that have a clear resolution in line with >> the original intent should be classified as Verified. If the resolution is >> not clear or requires further discussion, the report should be classified >> as Hold for Document Update. In both cases, only items that are clearly >> wrong should be considered.” >> >> It appears to me that this erratum isn’t identifying an outright error in >> the RFC, but making an argument that the approach chosen wasn’t the best >> one. That is beyond the scope of an erratum and fails the “clearly wrong” >> test. But, I’m open to correction, that’s why I’m starting this thread. >> >> Lacking other guidance I’ll plan on rejecting the erratum in a week or so >> (while still thanking Alexander for raising the issue!). >> >> Finally, I’ll point out that even if the erratum is rejected, Alexander >> or someone else could initiate a draft to update or replace RFC 8678. >> >> Thanks in advance, >> >> —John >> >> P.S.: For convenience, I’ve pasted the body of the erratum below. >> >> Type: Technical >> Reported by: Alexander Patrakov <[email protected]> >> >> Section: 6.2.3 >> >> Original Text >> ------------- >> In this example, we could arrange things so that SERb1 drops the >> packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and >> then sends to H31 an ICMPv6 Destination Unreachable message with Code >> 5 (Source address failed ingress/egress policy). When H31 receives >> this packet, it would then be expected to try another source address >> to reach the destination. In this example, H31 would then send a >> packet with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which >> will reach SERa and be forwarded out the uplink to ISP-A. >> >> >> >> Corrected Text >> -------------- >> In this example, we could arrange things so that SERb1 drops the >> packet with S=2001:db8:0:b010::31 and D=2001:db8:0:1234::101, and >> then sends to H31 an ICMPv6 Destination Unreachable message with Code >> 5 (Source address failed ingress/egress policy). When H31 receives >> this packet, an application running on it could then try another >> source address to reach the destination if it was specifically >> programmed to do so. In this example, H31 would then send a packet >> with S=2001:db8:0:a010::31 and D=2001:db8:0:1234::101, which will >> reach SERa and be forwarded out the uplink to ISP-A. >> >> Notes >> ----- >> The approach with ICMPv6 Destination Unreachable message with Code 5 >> (Source address failed ingress/egress policy) is, in fact, unsound, as it >> is possible to force the OS kernel to perform an (uninformed) address >> selection using the standard socket API without sending any packets and >> thus without giving any router a chance to react with ICMPv6 Destination >> Unreachable messages. For example, consider the following Python code: >> >> import socket >> s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM) >> s.connect(("2001:4860:4860::8888", 53)) # no packets are sent, this is a >> datagram socket >> my_addr = s.getsockname() >> >> At this point, one can print my_addr; therefore, it's too late to change >> behind the scenes the decision on the source address that was made in the >> second line if it happens to be incorrect. So, it's crucial that the source >> address selection can happen without any post-factum feedback, which leaves >> router advertisements with the effective routing policy as the only viable >> mechanism for controlling source address selection. >> >> Perhaps this mandatory requirement for an application (not an operating >> system!) to handle ICMPv6 Destination Unreachable messages with Code 5 >> explicitly (that is, in practice, not implemented) could also be added as a >> drawback to section 6.2.4 and mentioned in section 6.3.4 instead of >> referring to the unclear understanding of the host operating system >> behavior. >> > > > -- > Alexander Patrakov > > _______________________________________________ > rtgwg mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
