Solved FreeBSD IPv6 basics

Maximum transmission unit (MTU)

… I took the current example given by Hurricane Electric, put it in the context of this 2021 article:

IPv6 via Hurricane Electric's Free IPv6 Tunnel Broker Service

– in the article, there's an MTU of 1480.

Hurricane Electric's example does not specify an MTU. By following this example for my /etc/rc.conf I get an MTU of 1280, which works, so far. In correspondence with Hurricane Electric I asked about the MTU, no answer yet.

In the meantime: <https://www.google.com/search?q="Hurricane+Electric"+MTU+1480&tbs=li:1#unfucked> at a glance, some very old FreeBSD-related information, and this 2021 article (to deep for me): IPv6 Series: Part 2 – IPv6 at home using 6RD – blog.zuthof.nl
 
I your traffic passes through some tunnel the MTU can be a bit lower due to the overhead of the header of the layer in which it is tunneled. Even PPP uses a , be it short header.
 
My MTU is set to 1500. And I leave it there , because i don't have enough info of the intermediate devices. And there is also something like jumbo-frames. And a difference of 1-link-mtu and full-path-mtu.
 
My MTU is set to 1500.
That's the default MTU for ethernet.

And there is also something like jumbo-frames.
Only on gigabit or higher networks. And you also need switches that support jumbo frames.
Code:
dice@hosaka:~ % ifconfig igb0
igb0: flags=8863<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 9000
        options=4e527bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,WOL_MAGIC,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6,NOMAP>
        ether 00:25:90:f1:58:38
        inet 192.168.10.180 netmask 0xffffff00 broadcast 192.168.10.255
        media: Ethernet autoselect (1000baseT <full-duplex>)
        status: active
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
MTU 9000 means jumbo frames. Basically anything above 1500 is considered a jumbo frame. The garden-variety unmanaged switches you have at home usually don't support jumbo frames.

Ping does not allow to set packetsize.
Of course it does.
Code:
     -s packetsize
             Specify the number of data bytes to be sent.  The default is 56,
             which translates into 64 ICMP data bytes when combined with the 8
             bytes of ICMP header data.

             For IPv4, only the super-user may specify values more than
             default.  This option cannot be used with ping sweeps.

             For IPv6, you may need to specify -b as well to extend socket
             buffer size.
Code:
     -D      Disable fragmentation.

You typically combine this with the "don't fragment" flag and increase the packetsize until it breaks. Then you'll know the largest MTU you can use for the whole chain.

With regards to gif0, my MTU is set to 1280 (that's the default) and this has been working fine for years. So I wouldn't worry too much about it.
 

I have enough to summarise.


FreeBSD IPv6 basics
  1. Unrelated to FreeBSD, your Internet service provider – or other things beyond your control, including network infrastructure – might not support IPv6
  2. be prepared to use a tunnelling service from a different provider
  3. if your FreeBSD computer is behind a router and has a non-public IPv4 address, be prepared to specify the private address when configuring FreeBSD to use the tunnel
  4. IPv6 is not in the index of the FreeBSD Handbook
  5. the System Administration part of the Handbook includes 12.5. Setting Up Network Interface Cards – some basics, but not for IPv6
  6. the next part (IV) of the Handbook includes the basics – PDF page 685, chapter 32 (Advanced Networking), 32.9.2. Configuring IPv6
  7. there are two lines to add to /etc/rc.conf
  8. one of the two lines for IPv6 might cause your IPv4 configuration to cease working.
If sysrc -f /etc/rc.conf rtsold_enable="YES" is problematic, instead:
  • sysrc -f /etc/rc.conf rtsold_enable="NO"
– then whenever you're in a network environment that will work with the router solicitation daemon (rtsold(8)):
  • service rtsold onestart
… and so on.


Router solicitation daemon

… caused FreeBSD to cease working with the IPv4 configuration that's required at my workplace. …

I might be there again some time next week, to retest. In the meantime: the results two days ago seemed clear enough: I couldn't use the Internet until after I stopped the daemon (and took more traditional action to gain a route).
 
There are at least two things that make little sense:
  • ISPs not offering IPv6 are very rare nowadays. To the contrary, many only offer IPv6 now, and give you a tunnel for IPv4 with a private address that is then "NATed" on the provider's end.
    • What's typically needed for using IPv6 from the ISP is IPV6CP for ppp(8) and to get the prefix the ISP delegates you, a DHCPv6 client.
    • A tunnel can of course still make sense, if you want static prefixes, reverse DNS, ...
  • rtsold(8) doesn't hurt in a network where no rtadvd(8) is active. You just won't receive any IPv6 routes. Yes, I tried that a lot with my notebook.
 
Relevant lines from my /etc/rc.conf

Code:
cloned_interfaces="gif0"
create_args_gif0="tunnel 192.168.1.10 address.from.tunnel.provider mtu 1480"
ifconfig_gif0_ipv6="inet6 ⋯:⋯:⋯:⋯::2 ⋯:⋯:⋯:⋯::1 prefixlen 128"
ipv6_defaultrouter="⋯:⋯:⋯:⋯::1"

netif_nic_seq="em0 wlan0"

ifconfig_em0="DHCP"

create_args_wlan0="country GB regdomain etsi"
wlans_iwn0="wlan0"
ifconfig_wlan0="NOAUTO WPA SYNCDHCP"

rtsold_enable="NO"

ipv6_activate_all_interfaces="NO"

Whenever I'll move the computer to an environment that's not compatible with the tunnel:
  • ifconfig gif0 down
The Hurricane Electric tunnel example (specific to me), on which I based the tunnel-related lines of my rc.conf:

Code:
ifconfig gif0 create
ifconfig gif0 tunnel my.router.public.address address.from.tunnel.provider
ifconfig gif0 inet6 ⋯:⋯:⋯:⋯::2 ⋯:⋯:⋯:⋯::1 prefixlen 128
route -n add -inet6 default ⋯:⋯:⋯:⋯::1
ifconfig gif0 up

Advice received:

… MTU 1480 should be in place, as a 6in4 tunnel will always have an MTU of 20 bytes less than the underlying IPv4 connection, down to the IPv6 minimum MTU of 1280. If your server is on normal Ethernet MTU of 1500, 1480 would be the proper value. …
 
Last edited:
It's more stable to enable IPv6 for your whole network (either using the prefix offered by the ISP, or using a HE tunnel). Then, all your device needs is rtsold(8) and there's no reason to disable it.

Opening a tunnel directly on the end device is possible, but sure, if you're in a network with a firewall just blocking/dropping packets on the tunneled connection, things will go wrong as the machine has a "correctly working" IPv6-enabled interface and applications try to use it.
 
Sure, all you need to use IPv6 is an ISP offering it and a consumer router doing the right things, then just enable it on your client if this isn't the default anyways.

No need to know anything. 🤦‍♂️
 
In ipfw i have a rule about frags,
Code:
$cmd 03100 deny all from any to any frag in via $pif
And sysctl.conf
Code:
net.inet.ip.maxfragpackets=0     
net.inet.ip.maxfragsperpacket=0
I suppose i don't need frags because internet works fine.
 

For the WAN IP address of my router:

Sending 32 bytes to ⋯.⋯.⋯.⋯ <- NO REPLY!

We are unable to test this host or IP.
Most likely ICMP traffic to that host or IP is not allowed or the host or IP is invalid.

Without knowing the address of the sender, it was impossible for me to allow the traffic.

For the IPv6 address of the tunnel to my computer:
  • the first test found just one size (not the largest) fragmented, test limit exceeded
  • two or three subsequent tests found no size fragmented, test limit exceeded.
The most recent test found:
  1. sizes 32–1407 bytes not fragmented
  2. 1454 bytes fragmented (maybe the same as in the first test)
  3. sizes 1430–1743 bytes (including 1454 bytes) not fragmented, test limit exceeded.

… This online MTU test is in BETA. …

Fair enough.

With regards to gif0, my MTU is set to 1280 (that's the default) and this has been working fine for years. So I wouldn't worry too much about it.

👍
 
Before I gained a tunnel:

… with Firefox 89 in safe mode, visiting http://beefy3.nyi.freebsd.org/ immediately progresses to https://beefy3.nyi.freebsd.org/ before reporting the inability to connect. …

Thankfully, Firefox seems to exclude non-found addresses from its history ✅ so, no accidental useless visit to any https://beefy3.nyi.freebsd.org/⋯ address.

… Most ISP's support IPv6 …

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption I'm in a 33% adoption country. At a glance, India has more than 50%.

<https://forums.thinkbroadband.com/general/t/4667422-re-ipv6.html> (2020-12-03) apparently three of the top five ISPs did not offer IPv6, I'm with one of those ISPs, I assume that the situation now is the same.
 
Before I gained a tunnel:



Thankfully, Firefox seems to exclude non-found addresses from its history ✅ so, no accidental useless visit to any https://beefy3.nyi.freebsd.org/⋯ address.



https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption I'm in a 33% adoption country. At a glance, India has more than 50%.

<https://forums.thinkbroadband.com/general/t/4667422-re-ipv6.html> (2020-12-03) apparently three of the top five ISPs did not offer IPv6, I'm with one of those ISPs, I assume that the situation now is the same.
As commercial entities, ISP's would try to monetize the fact that they support IPv6. Based on that, they decide whether or or not to offer IPv6 as part of a consumer-grade access subscription. Behind that paywall, everybody supports IPv6 - they have to, no way around it, too many devices on the Internet. Hurricane Electric (and a few others) provide tunnels, but you have to have enough technical expertise (like us) to even use that. Based on that - it's either shop around for an ISP that provides (as opposed to just support) IPv6 as part of a consumer-grade subscription, or connect to a tunnel. Vote with your hard-earned money.
 
I have to disagree with Zirias, (who ironically, fixed *my* ipv6). It seems that even if one's provider has ipv6, on FreeBSD and some versions of Linux, configuration is necessary.
This is at least true for me, using Spectrum in NYC.

I like to boot laptops without networking, because I might not be at home, or for whatever reason, want to use ethernet instead of wireless. On FreeBSD, it seems I can't enable ipv6 if I haven't put the necessary lines in rc.conf. That is, I've always been able to add wireless after booting by creating wlan0, then running wpa_supplicant and dhclient. However, if I do dual-dhclient, though it gets a global address, it can't ping anything.
However, if I set everything up first in rc.conf, it works. For reference, those lines are
Code:
wlans_iwm0="wlan0"
ifconfig_wlan0="WPA SYNDHCP"
ifconfig_wlan0_ipv6="inet6 DHCP accept_rtadv"
rtsold_enable="YES"
dhclient_program="/usr/local/sbin/dual-dhclient"

For my ethernet attached tower, I only have
Code:
ifconfig_re0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
For ipv6. After boot, I will have a link-local address. I have a static ipv4 address, so I have an rc.local line to run
Code:
/usr/local/sbin/dhclient -6 re0
which gets me a dhcp6 address right after boot.

Depending on what version of Linux I use, and what network tool I use, I may have to run dhclient -6 <interface> after boot to get an ipv6 address, on other versions, it works out of the box.

Point is that it does seem to require a bit of effort to get it working, even if the ISP provides it. On the other hand, on my workstation at work, I just have the rtsold line and it's all automatic, but we do better networking there than Spectrum.
 
Back
Top