RFC Errata
Found 2 records.
Status: Reported (2)
RFC 8678, "Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions", December 2019
Source of RFC: rtgwg (rtg)
Errata ID: 8002
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Alexander Patrakov
Date Reported: 2024-06-25
Section 6.2.3 says:
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.
It should say:
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.
Errata ID: 8124
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Scott Shambarger
Date Reported: 2024-09-28
Section 6.3.2 says:
Let's consider a scenario in which all uplinks are operational, and H41 receives two different RAs from R3: one from LLA_A with a PIO for 2001:db8:0:a020::/64 and the default router preference set to 11 (low), and another one from LLA_B with a PIO for 2001:db8:0:a020::/64, the default router preference set to 01 (high), and a RIO for 2001:db8:0:6666::/64. As a result, H41 uses
It should say:
Let's consider a scenario in which all uplinks are operational, and H41 receives two different RAs from R3: one from LLA_A with a PIO for 2001:db8:0:a020::/64 and the default router preference set to 11 (low), and another one from LLA_B with a PIO for 2001:db8:0:b020::/64, the default router preference set to 01 (high), and a RIO for 2001:db8:0:6666::/64. As a result, H41 uses
Notes:
Minor technical fix to paragraph 2, 1st sentence: PIO of 2001:db8:0:a020::/64 is used for both LLA_A and LLA_B. Based on the remaining contents of the paragraph, the PIO of LLA_B should be 2001:db8:0:b020::/64.