Configuring an IPv6 peer with --min-ttl (mgadm flag) doesn't actually result in the IPv6 hop limit field being updated on the wire, at least not on Illumos.
I believe there are two bugs here: one when setting the hop limit on the current socket (packets we send) and one when setting the minimum acceptable hop limit (packets we receive).
For the packets we receive, I think we are incorrectly calling setsockopt with IPPROTO_IP/IP_MINTTL when it should be IPPROTO_IPV6/IPV6_MINHOPCOUNT.
For the packets we send, we are just calling TcpStream.set_ttl() which eventually calls setsockopt with IPPROTO_IP/IP_TTL -- which is IPv4 specific. It doesn't look like there's a corresponding TcpStream method for the IPv6 hop limit, which means we'll probably need to call setsockopt with IPPROTO_IPV6/IPV6_UNICAST_HOPS
Configuring an IPv6 peer with
--min-ttl(mgadm flag) doesn't actually result in the IPv6 hop limit field being updated on the wire, at least not on Illumos.I believe there are two bugs here: one when setting the hop limit on the current socket (packets we send) and one when setting the minimum acceptable hop limit (packets we receive).
For the packets we receive, I think we are incorrectly calling setsockopt with
IPPROTO_IP/IP_MINTTLwhen it should beIPPROTO_IPV6/IPV6_MINHOPCOUNT.For the packets we send, we are just calling TcpStream.set_ttl() which eventually calls setsockopt with
IPPROTO_IP/IP_TTL-- which is IPv4 specific. It doesn't look like there's a corresponding TcpStream method for the IPv6 hop limit, which means we'll probably need to call setsockopt withIPPROTO_IPV6/IPV6_UNICAST_HOPS