diff options
author | David Gibson <david@gibson.dropbear.id.au> | 2024-11-14 14:33:10 +1100 |
---|---|---|
committer | Stefano Brivio <sbrivio@redhat.com> | 2024-11-14 19:00:40 +0100 |
commit | 6e1e44293ef991d8c946dd59fbbd65c54901b255 (patch) | |
tree | 49ccf906ab273011889e0a6c2b55c1a1c3721099 /tcp_vu.c | |
parent | b39760cc7d89e69c7fb12eccc3df3bd15e2d5665 (diff) | |
download | passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar.gz passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar.bz2 passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar.lz passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar.xz passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.tar.zst passt-6e1e44293ef991d8c946dd59fbbd65c54901b255.zip |
ndp: Send unsolicited Router Advertisements
Currently, our NDP implementation only sends Router Advertisements (RA)
when it receives a Router Solicitation (RS) from the guest. However,
RFC 4861 requires that we periodically send unsolicited RAs.
Linux as a guest also requires this: it will send an RS when a link first
comes up, but the route it gets from this will have a finite lifetime (we
set this to 65535s, the maximum allowed, around 18 hours). When that
expires the guest will not send a new RS, but instead expects the route to
have been renewed (if still valid) by an unsolicited RA.
Implement sending unsolicited RAs on a partially randomised timer, as
required by RFC 4861. The RFC also specifies that solicited RAs should
also be delayed, or even omitted, if the next unsolicited RA is soon
enough. For now we don't do that, always sending an immediate RA in
response to an RS. We can get away with this because in our use cases
we expect to just have passt itself and the guest on the link, rather than
a large broadcast domain.
Link: https://github.com/kubevirt/kubevirt/issues/13191
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'tcp_vu.c')
0 files changed, 0 insertions, 0 deletions