https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=286322
--- Comment #17 from Paige Thompson <pa...@paige.bio> ---
(In reply to Marek Zarychta from comment #16)
> perhaps it is working correctly
Indeed, the thought crossed my mind. The only problem I have with that is:
1. This works (Linux)
ip link add vrf1 type vrf table 1000
ip link set vrf1 up
ip link add veth0 type veth peer name veth1
ip link set veth1 master vrf1
ip addr add fcff::a/64 dev veth0
ip addr add fcff::b/64 dev veth1
ip link set veth0 up
ip link set veth1 up
2. OpenBSD pair(4) definitely works, I had it setup and running last year and I
still have the configs for it but they're backed up offline somewhere (but if
you really don't believe me I'll gladly retrieve them.)
I'll give one final example and I'll try to be as comprehensive as possible:
root@fbsdshell:/home/admin # sysctl -a | grep source_address_validation
net.inet.ip.source_address_validation: 1
net.inet6.ip6.source_address_validation: 1
root@fbsdshell:/home/admin # ifconfig epair127 create
epair127a
root@fbsdshell:/home/admin # ifconfig epair127a 192.0.0.0/31
root@fbsdshell:/home/admin # ifconfig epair127b 192.0.0.1/31 fib 127
root@fbsdshell:/home/admin # ping 192.0.0.1
PING 192.0.0.1 (192.0.0.1): 56 data bytes
64 bytes from 192.0.0.1: icmp_seq=0 ttl=64 time=0.446 ms
^C
--- 192.0.0.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.446/0.446/0.446/0.000 ms
root@fbsdshell:/home/admin #
IPv4 works fine, now lets add IPv6:
root@fbsdshell:/home/admin # ifconfig epair127a inet6 fcff::a/64
root@fbsdshell:/home/admin # ifconfig epair127b inet6 fcff::b/64 fib 127
root@fbsdshell:/home/admin # ping6 fcff::b
PING(56=40+8+8 bytes) fcff::b --> fcff::b
^C
--- fcff::b ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
root@fbsdshell:/home/admin #
Didn't work, so turn off source validation and try again:
root@fbsdshell:/home/admin # sysctl net.inet6.ip6.source_address_validation=0
net.inet6.ip6.source_address_validation: 1 -> 0
root@fbsdshell:/home/admin # ping6 fcff::b
PING(56=40+8+8 bytes) fcff::b --> fcff::b
16 bytes from fcff::b, icmp_seq=0 hlim=64 time=0.540 ms
^C
--- fcff::b ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.540/0.540/0.540/0.000 ms
root@fbsdshell:/home/admin #
recap:
root@fbsdshell:/home/admin # sysctl -a | grep source_address_validation
net.inet.ip.source_address_validation: 1
net.inet6.ip6.source_address_validation: 0
Okay so maybe the reason IPv4 works is because the addresses are part of the
same /31 segment (I thought of this and it's not but for the sake of the
argument I'll start over and use a /127:
First turn source address validation back on:
root@fbsdshell:/home/admin # sysctl net.inet6.ip6.source_address_validation=1
net.inet6.ip6.source_address_validation: 0 -> 1
root@fbsdshell:/home/admin # ifconfig epair127a destroy
root@fbsdshell:/home/admin # ifconfig epair127 create
epair127a
root@fbsdshell:/home/admin # ifconfig epair127a inet6 fcff::/127
root@fbsdshell:/home/admin # ifconfig epair127b inet6 fcff::1/127 fib 127
Nope:
root@fbsdshell:/home/admin # ping6 fcff::1
PING(56=40+8+8 bytes) fcff::1 --> fcff::1
^C
--- fcff::1 ping statistics ---
2 packets transmitted, 0 packets received, 100.0% packet loss
root@fbsdshell:/home/admin #
Turn this back off:
root@fbsdshell:/home/admin # sysctl net.inet6.ip6.source_address_validation=0
net.inet6.ip6.source_address_validation: 1 -> 0
root@fbsdshell:/home/admin # ping6 fcff::1
PING(56=40+8+8 bytes) fcff::1 --> fcff::1
16 bytes from fcff::1, icmp_seq=0 hlim=64 time=0.497 ms
^C
--- fcff::1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.497/0.497/0.497/0.000 ms
root@fbsdshell:/home/admin #
The TLDR on this; IPv6 neighbors don't need to be part of the same segment but
they do need to be in the same scope (node-local, link-local, site-local,
global) Global and site-local use neighbor discovery and neighbor solicitation
ICMPv6 via link-local (fe80::/10) so essentially each interface must have a
SLAAC address (which they do):
root@fbsdshell:/home/admin # ifconfig epair127a
epair127a: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:5f:cc:2e:f0:0a
inet6 fcff:: prefixlen 127
inet6 fe80::5f:ccff:fe2e:f00a%epair127a prefixlen 64 scopeid 0x3 <---
groups: epair
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
root@fbsdshell:/home/admin # ifconfig epair127b
epair127b: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP>
metric 0 mtu 1500
options=8<VLAN_MTU>
ether 02:5f:cc:2e:f0:0b
inet6 fcff::1 prefixlen 127
inet6 fe80::5f:ccff:fe2e:f00b%epair127b prefixlen 64 scopeid 0x4 <---
groups: epair
fib: 127
media: Ethernet 10Gbase-T (10Gbase-T <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
And looking at the NDP cache it seems to me that it is working:
root@fbsdshell:/home/admin # ndp -a
Neighbor Linklayer Address Netif Expire S Flags
fcff:: 02:5f:cc:2e:f0:0a epair127a permanent R
fe80::5f:ccff:fe2e:f00a%epair127a 02:5f:cc:2e:f0:0a epair127a permanent R
fcff::1 02:5f:cc:2e:f0:0b epair127b permanent R
fe80::5f:ccff:fe2e:f00b%epair127b 02:5f:cc:2e:f0:0b epair127b permanent R
> It's unclear whether we can attribute this failure to
> net.inet6.ip6.source_address_validation knob. Perhaps IPv6 source address
> validation _does_ work correctly, prohibiting this traffic?
I'm gonna have to look at the source unless you know something that I don't
before I can answer that question definitively, but following this example I
wonder if you would not also see the problem with this even if this were
technically working correctly? :)
--
You are receiving this mail because:
You are the assignee for the bug.
