ipv6: fix: keep a datagram with a link-local source on its link

[adamgeorge309]

An Internet Protocol version 6 (IPv6) router forwarded a unicast datagram whose source address is link-local onto another link, because Ipv6::routePacket() checked only the destination address. It now drops such a datagram and answers with an Internet Control Message Protocol for IPv6 (ICMPv6) Destination Unreachable message, code 2, "beyond scope of source address": Request for Comments (RFC) 4291 Section 2.5.6 forbids the forwarding, and RFC 4007 Section 9 requires the error.

Risk: simulations in which a node sends from its link-local address to an off-link destination, or in which a router's Redirect with a link-local source crosses another router, change. Three fingerprint rows of examples.csv (Mobile IPv6 (MIPv6) Handover, RouteOptimizationTwoCNs, Roaming) are re-recorded, and their statistical baselines in the statistics repository need re-recording after merge. Merge after #1256: without it, tests/module/IPv6_tunnel.test fails (see Verification).

Closes #1357

One commit: ipv6: fix: keep a datagram with a link-local source on its link.

The problem

src/inet/networklayer/ipv6/Ipv6.cc:479-484 on master refuses to forward a datagram with a link-local or loopback destination. Nothing on the forwarding path checks the source address, so a router forwards a datagram with an fe80::/10 source to any interface the routing table picks. Code 2 of Destination Unreachable was not defined: Icmpv6DestUnav had //2 - NOT ASSIGNED in its place.

The change

• Ipv6::routePacket(), after the output interface is chosen and before the Redirect and FORWARD hook steps: a forwarded datagram (!fromHL, with an arrival interface) whose source is link-local and whose output interface differs from its arrival interface is dropped. INET has no zone model, so the arrival interface stands for the link. A datagram sent back out of its arrival interface stays on its link, so it does not leave the zone of its source address; that case, which is the Redirect trigger, is unchanged.
• The drop increments numDropped, emits packetDropped with OTHER_PACKET_DROP, and calls sendIcmpError(..., ICMPv6_DESTINATION_UNREACHABLE, BEYOND_SCOPE_OF_SOURCE). No error is sent for a Redirect (RFC 4443 Section 2.4 (e.2)). Icmpv6::validateDatagramPromptingError() already suppresses errors about ICMPv6 errors, about multicast destinations, and about datagrams that arrived in a link-layer broadcast or multicast frame.
• Icmpv6Type.msg: BEYOND_SCOPE_OF_SOURCE = 2 in Icmpv6DestUnav. The Transmission Control Protocol (TCP) treats it as a soft error: isHardIcmpv6Error() lists only codes 1 and 4.

No C++ interface, Network Description (NED) parameter, message field or feature descriptor changes; the enum gains one value.

Not addressed here: the error is routed like every other locally originated datagram to a link-local destination, by longest-prefix match over the fe80::/10 routes that every non-loopback interface adds. On a router where the arrival interface is not the one that match picks, the error leaves through the wrong interface and does not reach the sender. In the reproduction with the two links swapped, the 3 errors left through eth0 while hostA was on eth1. Pinning the error to the arrival interface would make it a datagram with an output interface but no next-hop determination, which is the separate defect of #1151 (pull request #1152).

Also not addressed: a datagram decapsulated at a tunnel exit keeps the physical interface the tunnel packet arrived on as its arrival interface. An inner datagram with a link-local source that leaves through that same interface is therefore still forwarded; one that leaves through another interface, as in IPv6_tunnel.test, is dropped. Multicast forwarding (routeMulticastPacket()) is unchanged. A datagram that goes out of another interface attached to the same link does not leave the zone either; without a zone model, it is now dropped.

Verification

Release build (make MODE=release in the root and tests/module/lib), each suite run on master bba1db4c81 and with this change.

New module test tests/module/IPv6_forwarding_link_local_source.test: hostA --- router --- hostB, hostA pings hostB's global address from fe80::8aa:ff:fe00:a. It checks that the router never logs a next hop on eth1 for hostB, that it logs the drop 3 times, and that hostA dispatches 3 Icmpv6DestUnreachableMsg with code 2. It fails on master (run before the master baseline), where the router forwards all 3 Echo Requests to hostB and hostB's replies to fe80::8aa:ff:fe00:a are dropped by the router as link-local destinations, and passes with this change.

Command	Master	This change
tests/fingerprint: ./fingerprinttest -s -F tyf	1774 run, 5 failures, 62 errors, 1 expected error	8 failures, the same 62 errors: the 3 rows below, which this commit re-records, and the same 5
tests/module: inet_run_module_tests -m release --no-build -l ERROR	657 run, 368 pass, 289 fail	658 run, 368 pass, 290 fail: the new test passes; IPv6_tunnel fails (below); the other failures are the same tests by name
tests/module: ... -f 'IPv6_tunnel|IPv6_forwarding_link_local_source' with #1256's commit ad02cc70ae applied on top		both pass

Of the 289 module failures on master, 274 are tcp_* tests and 15 are ConvolutionalCoder12, ConvolutionalCoder34, DimensionalMediumAnalogModel_PrintAttenuation_1, EtherHost_lifecycle, ExternalProcess_3, Ieee80211BitDomain, Ieee80211BlockAckVariant_1, Ieee80211SymbolDomain, Ieee8021d-Rstp, Ieee8021d-Stp, IPv6_packet_too_big, LogNormalShadowing_Correlated_4, MIPv6_tcp_handover, PacketGate_1, UDPSocket_1. The 5 fingerprint failures on master are rows of mipv6-refactoring.csv whose recorded ~tNlb fingerprints are stale; the 62 errors are configurations whose optional features are not built.

IPv6_tunnel.test: host A sends into a tunnel interface whose exit is router B. On master the inner datagrams carry the link-local source fe80:: (#1255), and B forwarded them to H. With this change B drops them, all 8, and the test's "received 8 packets" check fails. #1256 gives those datagrams a global source.

Fingerprint rows: in examples.csv, examples/ipv6/mipv6 Handover and RouteOptimizationTwoCNs and examples/ipv6/mipv6roaming Roaming change their tplx, ~tNl and ~tND fingerprints, which this commit records. Their tyf fingerprints (./fingerprinttest -s -f tyf -m mipv6 examples.csv, run on master and with this change) differ from the recorded values on master too, and so does the pmipv6 row's tyf. These, and the 3 changed ~tNlb rows of mipv6-refactoring.csv, are left as they are. What changes in those runs, with this change:

• Handover and Roaming: the correspondent node sends its first 5 Echo Requests from its link-local address, before it has a global address (in Roaming, Duplicate Address Detection (DAD) of fe80::8aa:ff:fe00:c completes at 2.43 s and the global address is assigned, tentative, at 3.31 s and usable at 5.24 s). R_2 in Handover and the backbone router in Roaming drop them.
• All three: the home agent sends a Redirect to the mobile node's home address for reverse-tunnelled datagrams (ipv6: a home agent sends a spurious ICMPv6 Redirect for every reverse-tunneled datagram it forwards #1197), from its link-local address and to the Ethernet broadcast address (ipv6: a unicast datagram with a pinned output interface goes to the Ethernet broadcast address #1151). R_2 (the backbone router in Roaming) receives it and sends it back to the home agent, which used to tunnel it to the mobile node and now drops it: 47 in Handover, 4 in RouteOptimizationTwoCNs, 2 in Roaming. Pull request ipv6: send ICMPv6 Redirects only to neighbours, with a link-local target and at a limited rate #1236 reports 43 such Redirects in Handover on an older master; this base sends 47.

The correspondent node's ping results (pingRxSeq:count, numLost:last) are the same in RouteOptimizationTwoCNs. In Handover, 112 replies arrive instead of 108 (sequence numbers 43, 125, 126 and 127 are added). In Roaming, 111 arrive instead of 112 (84 and 85 at 43.0 s and 43.5 s are lost, 122 at 62.0 s is added). In Roaming, no new drop happens near those times. In Handover, the home agent drops a returned Redirect at every reply in 22.5–39 s and 63.5–69.5 s, including the four added ones. Why only these replies change is not traced.

Gates: check-pull-request.sh --base origin/master (commits, classification, includes, NED parameters, description), check-source-seals.sh --base origin/master and check-architecture.sh src/inet/networklayer pass.

Relationship to other pull requests

• ipv6: take a global source when the outgoing interface is link-local only #1256 (for ipv6: a datagram originated into a tunnel interface carries its link-local source fe80:: off-link #1255): needed for IPv6_tunnel.test, see above. Both change Ipv6.cc in different functions.
• ipv6: send ICMPv6 Redirects only to neighbours, with a link-local target and at a limited rate #1236 (for ipv6: a router sends an ICMPv6 Redirect to a source that is not a neighbour #1233, icmpv6: the Target Address of a Redirect to a router is the route's next hop as configured, not the router's link-local address #1234, icmpv6: Redirect messages are not rate limited #1235): sends Redirects only to neighbours, which removes the home agent's Redirects that this change drops; this change does not depend on it.
• ipv6: address a pinned unicast datagram from the Neighbour Cache #1152 (for ipv6: a unicast datagram with a pinned output interface goes to the Ethernet broadcast address #1151): the pinned-interface defect that blocks sending the error through the arrival interface.
• pmipv6: send Handoff Indicator 4, handoff state unknown #1322, pmipv6: route a mobile node again after a gateway or anchor restart #1324, networklayer: deliver an ICMPv6 error about a first fragment #1326, queueing: report a RED early drop as congestion #1328, icmpv6: restart ReachableTime when a solicited NA sets REACHABLE #1334, icmpv6: end address resolution when an NS sets the entry STALE #1337, icmpv6: send no RA while the link-local address is tentative #1340, icmpv6: send no address-resolution NS from a tentative address #1342 and visualizer: fix: read the dy parameter of PacketDropCanvasVisualizer #1356 also add an entry under "Notable bug fixes" in WHATSNEW; whichever merges later renumbers.