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 <patra...@gmail.com> 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 <j...@juniper.net<mailto:j...@juniper.net>> 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 <patra...@gmail.com<mailto:patra...@gmail.com>> 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 -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
