Hi RFC 8678 Authors, RTGWG, Alexander Patrakov filed https://www.rfc-editor.org/errata/eid8002 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/ 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> 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. _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
