Glad it was helpful! And thanks a bunch!

Most "network engineers" out there never once in their life have used IPv6. They literally are IPv6 incompetent.

Glad you like it! I've got a few more OPNsense ideas coming

@@apalrdsadventures A fun one is adding a suitable WiFi adapter. Why? If your primary internet connection goes down, you have it failover to your phone operating as a hotspot. You'll likely want to restrict the failover to certain VLANs only (critical stuff), but basically if your primary ISP goes down, home still has internet through your phone.

Glad to help!

KZfaq does that lol glad you still found it!

Wow thanks!

I’ve been using SDN for about a year now in test clusters while it was in beta and it’s pretty great. A few little quirks around vmbr0 during transition to sdn. Also still some bugs in ipv6 handling in vxlan that im aware of, but vxlan and evpn are still in beta anyway. You don’t need it for Ceph though, SDN is purely for VM traffic not Proxmox cluster or ceph traffic.

In general, v6 has a lot of attention to avoiding tracking - DHCPv6 cilents no longer supply their hostname or MAC as a unique ID, SLAAC clients generate multiple addresses with most of them being randomized for privacy, etc. which makes it very difficult to centrally guess what the IP of a client will be. Some DNS+DHCP servers like dnsmasq will calculate what the EUI-64 would have been for DHCPv4 clients and add that as an AAAA record, but this only works for OSes configured for EUI64 (generally just Linux server distros). So what I do now is copy+paste the IP into my public DNS console. If you do automated VM provisioning, you can pull the MAC from the hypervisor and generate the EUI64 address and use that, or query the guest utils in your automations. I've thought about doing NS delegation to something like home.apalrd.net -> my home DNS server, and then doing client-side dynamic DNS from there, but the number of hosts I have it's not a big deal to copy/paste their IP into the public DNS console. There's also the danger of accidentally becoming a public DNS server, so you have to be extremely careful to separate authoritative DNS hosting from forwarding / recursive DNS.

Something else which is an option: multicast DNS aka mDNS, Apple Bonjour and open-source Avahi and Windows 10 supposedly supports mDNS.

> Does that mean clients are now responsible for their own DNS records? They can be, via mDNS, and you may have your DNS server act as an mDNS proxy for a specfied domain name if you want your hosts to be accessible via names that don't end in `.local`. Alternatively, you may use a DNS server that dynamically adds/removes DNS records based on NDP activity. Depending on implementation, this may or may not require you to define the hostname for each MAC address that you want to have a name in the DNS. If your devices spoof their MAC address as a privacy feature, that would be a problem. There are some draft standards to add functionality similar to DHCP(v6)'s ability for hosts to declare their hostname when discovering/leasing an address.

In general, this is a troublesome problem to solve. The easiest way to work around the issue is to use NPTv6, so that your devices and firewall configurations use ULAs, and your edge routers convert between the ULA and GUA prefixes.

OPNsense uses tracking for this. When configured properly, OPNsense will re-address all your subnets when the ISP changes your prefix. OPNsense will also automatically modify firewall rules accordingly.

You can do subnets with direct cabling as well (or a separate switch), VLANs are not required to implement subnets.

If you want to use SLAAC, you *_mustn't_* use a prefix longer than /64. If you have any Android devices on your network, you must support SLAAC. Technically, the IPv6 base standard also stipulates that all network segments mustn't use a prefix longer than /64, and several other standards that build on top of the base IPv6 standard (such as SLAAC) assume this behaviour. Having said that, if all hosts on your network segment support DHCPv6 and you aren't using any IPv6 features that require a host/interface ID section of at least 64 bits, then you can use e.g. a /80 and have DHCPv6 assign the final 48 bits to make a 128-bit address. The root of your problem is that your ISP *_should not_* just be giving you a /64. If they are in fact doing this, complain to them and tell them to refer to RIPE-690, which defines the best current operating practices for ISPs on how to number their IPv6 networks. They should *_at least_* be giving you a /60, *_hopefully_* be giving you a /56, and *_preferably_* be giving you a /48, though many ISPs reserve /48s for paying business customers, albeit usually unjustifably from a technical perspective; they just do it as an excuse to charge more to people who particularly have a need for the extra 8 bits downstream.

I want to add: It's possible that your ISP is actually reserving a shorter prefix / larger allocation than a /64 for you (e.g. a /56), but has supplied you with a router than only uses the first available /64 within that larger allocation. The router they supply to you may not support the use of additional subnets, in which case you will need to use your own router, e.g. as shown in this video with an OpnSense instance.

Perhaps I didn't make myself clear. My UDMSE is configured to get a /60. I then have several VLANs that each have their own /64. What I want to do is build a virtual network that takes one of those /64s and break it down even further to other VLANs houses within that virtual lab network.

@@travisaugustine7264 You still should avoid creating subnets with prefixes longer than /64 wherever possible. Again, if any devices on your network exclusively use SLAAC, they simply won't work on e.g. a /65. Your ISP has given you a /60, so you are able to create 2⁴ = 16 subnets of size /64. If you want more than that, you need to talk to your ISP or find a new one. Again, cite RIPE-690 to them, which says /56 ought to be the bare minimum for residential customers. IPv6 address space is plentiful; ISPs should not be short-changing customers like this.

@@JivanPal my ISP is giving me at least a /60 because I have 4 different VLANS that are each getting their own /64 through prefix delegation. I just want to be able to break one of those delegations into something smaller to experiment with DHCPv6 on that specific VLAN

I have a setup in production somewhere using a single /64 as a LAN and using NDP Proxy (similar to ARP Proxy) for VPN clients to show up on LAN.

@@apalrdsadventures Thank you

VLANs are a link-layer construct, not IP layer, so while they separate traffic on the link layer, we also need separate subnets on the IP layer if we want inter-network routing to work properly

@@apalrdsadventures I think the purpose of the layers is that you don’t have to duplicate separation. If you setup subnets the packets travel separate based on different IP addresses. Why would you still need VLANs. ? They could all travel as one VLAN and still be distinguishable. No?

You don't have to duplicate your firewall/... but a separate VLAN is like a separate physical network. It's a separate layer 2 domain, so clients need to know to go to their layer 3 router to get routed to the correct layer 3 subnet associated with a different layer 2 domain.

2001:db8 is the documentation prefix, for documentation, which is why I used it. You will get a v6 prefix delegation from your ISP over DHCPv6-PD usually, unless you have a business connection and then it might be static.

I'm working on the script for the VPN video, OpenVPN included