MTU discovery fails with IPv6 sockets bound to IPv4 mapped address
pick up the IPv4 route for IPv4 mapped IPv6 address to get the correct
MTU and not any unrelated/inappropriate MTU from IPv6 routes. IPv4 mapped
IPv6 addresses are always handled by the IPv4 stack and MTU discovery
is solely handled with the IPv4 routing table.
netinet6: Pick IPv6 fragment ids uniformly at random.
Expected number of packets before collision is ~2^16, about the same
as we get for IPv4 with alternating disjoint random cycles. Keep it
simple unless we determine we really need something much better for
IPv6 than what IPv4 can achieve anyway.
netinet6: Rip out now-unused IPv6 fragment id logic.
(from riastradh)
correct because it works with non-primitive types and provides the ABI
alignment for the type the compiler will use.
- Remove all the *_HDR_ALIGNMENT macros and asserts
- Replace POINTER_ALIGNED_P with ACCESSIBLE_POINTER which is identical to
ALIGNED_POINTER, but returns that the pointer is always aligned if the
CPU supports unaligned accesses.
[ as proposed in tech-kern ]
- use a single macro to align pointers and expose the alignment, instead
of hard-coding 3 in 1/2 the macros.
- fix an issue in the ipv6 lt2p where it was aligning for ipv4 and pulling
for ipv6.
RFC 7048 Section 3 says in the UNREACHABLE state packets continue to be
sent to the link-layer address and then backoff exponentially.
We adjust this slightly and move to the INCOMPLETE state after
`nd_mmaxtries` probes and then start backing off.
This results in simpler code whilst providing a more robust model which
doubles the time to failure over what we did before.
We don't want to be back to the old ARP model where no unreachability
errors are returned because very few applications would look at
unreachability hints provided such as ND_LLINFO_UNREACHABLE or RTM_MISS.
This is much better handled by a user-land tool.
Proposed on tech-net here:
https://mail-index.netbsd.org/tech-net/2020/04/22/msg007766.html
Note that the ioctl SIOCGIFINFO_IN6 no longer sets flags. That now
needs to be done using the pre-existing SIOCSIFINFO_FLAGS ioctl.
Compat is fully provided where it makes sense, but trying to turn on
RA handling will obviously throw an error as it no longer exists.
Note that if you use IPv6 temporary addresses, this now needs to be
turned on in dhcpcd.conf(5) rather than in sysctl.conf(5).
Otherwise if ln_state != ND6_LLINFO_INCOMPLETE and the is no lladdr
and this message was solicited then ln_state is set to ND6_LLINFO_REACHABLE
which could then cause a panic in nd6_resolve().
If ln_state > ND6_LLINFO_INCOMPLETE then it's assumed we have a lladdr.
Potentially this could have been triggered by the introduction of
ND6_LLINFO_PURGE in nd6.c r1.143 but also by the re-introduction of
ND6_LLINFO_INCOMPLETE in nd6.c r1.263.
Depending on the timing, it's technically possible to receive such
a message after the llentry is created with ND6_LLINFO_NOSTATE.
The primary issue was that in revision 1.79 a check was added in the
nd6_defrouter_select() search loop to ignore the entry if RA processing
is enabled on its interface. In practice this results in all entries
being ignored.
This fix reverses the condition, so that an entry is ignored when RA
processing is NOT enabled on its interface. Further, the entry is
only ignored for being selected as the default router. The currently
installed router must be identified regardless of the (current) status
of its interface, so that we can delete the route before installing a
new one.
I also added error logging when adding or deleting a route fails. This
should help the administrator (or kernel developer) in noticing possible
problems.
Finally, if deleting a route fails, the corresponding default route
entry no longer has its "installed" flag cleared, so that deletion will
be retried. At a minimum, this will cause repeated messages about the
failed deletion as opposed to only getting repeated messages about the
installation of a new default route failing.
Fixes PR kern/55091 and also PR bin/54997 as far as the behaviour
observed with ndp(8).
andvar