The following errata report has been submitted for RFC8678, "Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8002 -------------------------------------- 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. Instructions: ------------- This erratum is currently posted as "Reported". (If it is spam, it will be removed shortly by the RFC Production Center.) Please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party will log in to change the status and edit the report, if necessary. -------------------------------------- RFC8678 (draft-ietf-rtgwg-enterprise-pa-multihoming-12) -------------------------------------- Title : Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions Publication Date : December 2019 Author(s) : F. Baker, C. Bowers, J. Linkova Category : INFORMATIONAL Source : Routing Area Working Group Stream : IETF Verifying Party : IESG _______________________________________________ rtgwg mailing list -- rtgwg@ietf.org To unsubscribe send an email to rtgwg-le...@ietf.org
