IPv6 on LAN, SLAAC - no temporary addresses

[macklij]

First post - please be gentle

Background
My ISP is Community Fibre (London). The IPv4 bit is CGNAT and working, and I believe I only get a /64 IPv6 subnet (neither ideal).

Using my old Draytek router, I am able to use SLAAC without DHCPv6 and my Windows and Mac clients successfully get/generate an IPv6 address and a temporary IPv6 address as well as an fe80 link local. The only issue is that the Draytek can’t route IPv6 packets quick enough - I only get 300Mbs on a 1Gbs connection (it’s fine on IPv4 which is hardware accelerated). Hence I built an OPNsense box.

All is good on OPNsense IPv4, and I can make IPv6 work too, but I only get one public IPv6 address per client – no temporary one. DHCPv6 is running and seems to be required for this to happen – if I disable the service there are no Ipv6 addresses received via SLAAC. Therefore, I suspect the issue is to do with SLAAC, DHCPv6 and prefixes but I can’t work it out.

The Question
I would like to get IPv6 working in the same way as my Draytek, but faster! I.e. Using SLAAC so that Windows and other clients can create two public addresses – one main one and one temporary. Ideally without DHCPv6, but that would be the icing on the cake.

Is this possible?

My setup
I currently have a WAN interface and a single Bridged LAN interface (3 ports working well). With the following settings I get a single working IPv6 address (plus IPv4 of course)

Interfaces>WAN:
Block private networks – checked
Block bogon networks – checked
IPv4 Configuration Type – DHCP
IPv6 Configuration Type – DHCPv6
MAC address – Spoofing the one my ISP likes

DHCPv6 client configuration:
Basic
Request only an IPv6 prefix – checked
Prefix delegation size - 64
Send IPv6 prefix hint – checked

Interfaces>LanBridge
Block private networks – unchecked
Block bogon networks – unchecked
IPv4 Configuration Type – Static IPv4
IPv6 Configuration Type – Track Interface

Track IPv6 Interface:
IPv6 Interface - WAN
IPv6 Prefix ID – 0x0
Manual configuration – unckecked
(I have previously checked this and tried lots of things. Even after disabling it, the router advertisement config isn’t always cleared – is that a bug?. I end up restoring a backup config)

I have played around with this for hours, so any guidance really appreciated (https://forum.opnsense.org/index.php?topic=27288.msg149991#msg149991 and https://forum.opnsense.org/index.php?topic=36986.0 looked useful, but to no avail)

Thanks in advance.

[Maurice]

If you want to use SLAAC without DHCPv6, check "Manual configuration" in the track interface settings. Then disable the DHCPv6 server and set Router Advertisements to "Unmanaged".

Cheers
Maurice

[meyergru]

Apart from a draft that suggest using of variable-length SLAAC (https://datatracker.ietf.org/doc/draft-mishra-6man-variable-slaac/), any current RFC pertaining to IPv6 makes an assumption of a length of 64 bits for the interface identifier. For SLAAC, the managed interface identifier is then the EUI-64 that is derviced from the MAC.

Thus, it should be possible to have a /64 prefix delegation size, but in that case, only one local interface can take that prefix, such that the other local interfaces cannot have IPv6 GUAs.

It seems you configured that already like that. When you look at /var/etc/radvd.conf, it should look something like:

Code: [Select]

# Generated RADVD config for manual assignment on lan
interface br0 {
        AdvSendAdvert on;
        MinRtrAdvInterval 200;
        MaxRtrAdvInterval 600;
        AdvLinkMTU 1500;
        AdvDefaultPreference medium;
        AdvManagedFlag on;
        AdvOtherConfigFlag on;
        prefix 200x:xxx:xxx:xxxx::/64 {
                DeprecatePrefix on;
                AdvOnLink on;
                AdvAutonomous on;
        };
        RDNSS 200x:xxx:xxx:xxxx::/64:f690:eabb:fe00:7489 {
        };
        DNSSL lan {
        };
};

Essentially, it would not look any different even with a /56 prefix delegation length, you could just have more than one interface section. You can check if the content is O.K. and if RADVD is running. Also, the LAN interface should have an IPv6 GUA.

BTW: With "request IPv6 prefix only", your WAN interface should not have a GUA IPv6, either.

P.S.: With your LAN bridge, all of the needed tuneables are set, I guess?

[macklij]

Thanks for the replies both.

Maurice, yes I tried this as per the link above, so I am assuming I have got something else wrong.

Meyergru, I’ll check and report back. I’m still on the nursery slopes with IPv6 so this is a good learning exercise. It will be interesting to see what address the LAN interface has.  From what I have read the WAN interface should be happy with an fe80 address.

More soon

[macklij]

So this morning I have 'turned on 'Allow manual adjustment of DHCPv6 and Router Advertisements' for the LAN( Bridge) interface. I then ensured that Services>DHCPv6>[LANBridge] is not enabled and that Services>Router Advertisements>[LANBridge] Router Advertisements is set to 'Unmanaged'.

What is interesting is that in Services>DHCPv6>[LANBridge] the subnet is 2a02:xxxx:xxxx:8800:: (sounds good?) but the subnet mask says 56 bits (I was expecting this to be 64bits, because Interfaces>WAN>DHCPv6 client configuration has a prefix delegation size of 64 bits)

This is also reflected in /var/etc/radvd.conf which is:

Code: [Select]

# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface bridge0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
prefix 2a02:xxxx:xxxx:8800::/56 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
};
RDNSS 2a02:xxxx:xxxx:8800:5a9c:fcff:fe10:6d75 {
};
DNSSL local {
};
};

I would have expected 'prefix 2a02:xxxx:xxxx:8800::/64' rather than 56.

In this configuration my clients only get a link-local IPv6 address - no public address

Could the /56 be the issue? And if so, any ideas on how to correct?

Thanks again

[meyergru]

Yep, that is a problem, it should be /64.

Could you take a look at Interfaces->WAN, "DHCPv6 client configuration" tab "Advanced" and see what you see under "Prefix Interface Site-Level Aggregation Length"? In your specific case, I think it should be 0 instead of 8, because you cannot strip any more bits for an interface prefix from the 64 bits you have.

[macklij]

Quick update:

I was thinking about the /56 subnet in /var/etc/radvd.conf and, just to play, went to Interfaces>WAN and set the ' Prefix delegation size' to 56 (it was 64 because that is what I believe my ISP issues - and what my old Draytek reports).

With the WAN interface set to 56, the subnet /var/etc/radvd.conf becomes 64 and magically the clients get/generate two IPv6 global addresses and 1 link local, just as I wanted.

So my problem is solved, but I'd love to understand what is going on.  Is it possible my ISP is actually issuing a /56?  And I definitely don't understand why setting a 56 prefix in WAN gives me a /64 in DHCPv6 and radvd.conf.  And vice-versa too - setting a /64 prefix in WAN gives a subnet of 56 in DHCPv6 and radvd.conf.

If someone could enlighten me I'd be really grateful.

Thanks

[macklij]

Yep, that is a problem, it should be /64.

Could you take a look at Interfaces->WAN, "DHCPv6 client configuration" tab "Advanced" and see what you see under "Prefix Interface Site-Level Aggregation Length"? In your specific case, I think it should be 0 instead of 8, because you cannot strip any more bits for an interface prefix from the 64 bits you have.

Thanks. I just switched WAN 'Prefix delegation size' back to 64 bits amd checked 'Advanced'. All the settings, including Prefix Interface Site-Level Aggregation Length, are blank. I've set it to 0 and when I checked its removed all the IP addresses from radvd.conf:

Code: [Select]

# Automatically generated, do not edit
# Generated RADVD config for manual assignment on lan
interface bridge0 {
AdvSendAdvert on;
MinRtrAdvInterval 200;
MaxRtrAdvInterval 600;
AdvLinkMTU 1500;
AdvDefaultPreference medium;
DNSSL local {
};
};


[macklij]

Just to check if I am receiving a /56 subnet from my ISP, rather than a /64, I turned off ' Request only an IPv6 prefix' and 'Send IPv6 prefix hint' on the WAN interface.

My theory was that if the ISP is issuing a /64 things would break - because the WAN interface would get a global rather than link-local address, and there wouldn't be a subnet for the LAN.

Things didn't break. In the dashboard, my WAN interface gets a very different address to the LAN:

WAN: 100.75.x.x (CGNAT)
xxxx:6b68:0:183::7d

LAN:192.168.0.1
xxxx:6b6c:9800:8e00:yyyy:fcff:fe10:6d75

I don't fully understand it yet, but it works, so I am assuming that I get a 56 from my ISP.

Thanks everyone.

PS: Is there any mileage in me writing up a 'how to' for this ISP? And if so where should I put it?

[Maurice]

It seems your ISP actually delegates a /56, yes. Which is unsurprising, this is the most common prefix length for consumers. To double check, you can see the delegated prefix in Interfaces: Overview: WAN.

The prefix length of tracking LAN interfaces should always be /64, SLAAC doesn't work with any other prefix length. It seems this gets set incorrectly if the configured prefix delegation size doesn't match the actual prefix length. I'll have a look later, but it's not unreasonable that an incorrect configuration results in unexpected behaviour (though this could probably be handled more gracefully).

The WAN address is unrelated to the delegated prefix. It often is in a completely different subnet and requesting one has no impact on prefix availability. The setting to only request a prefix is for ISPs who use SLAAC for numbering the WAN interface.

I don't think a new how-to is required. Your ISP seems to use the most common setup there is: A /56 prefix delegation and a /128 WAN address assigned via DHCPv6. It doesn't get more basic than this.

Cheers
Maurice

[macklij]

Thanks Maurice

Yes, it is a basic config - it just didn't feel it at the time!.

In reality, this was all down to me reading in multiple places that my ISP delegates a /64 which turned out to be untrue (most likely they have changed it over time). Being new to OPN I didn't think about Interfaces: Overview. WAN. Yes, it's /56.

 <<The WAN address is unrelated to the delegated prefix.>>
That is useful to know.  I have actually checked the WAN interface 'Request only an IPv6 prefix' again. I figure the WAN interface doesn't need a global address, and is potentially more secure without one. Please correct me if I'm wrong.

Overall, I am really impressed with OPNsense. Having used several Juniper SRX devices at work, I find it lovely to be using a responsive, well thought out web interface (J-Web is a nightmare you quickly ignore in favour of the CLI and configs). I don't have any issue with incorrect configuration resulting in unexpected behaviour - that's true of most platforms!

Thanks again - now the basics are working well, I can move on to VPNs etc.

[Maurice]

A WAN address is required (well, useful) if you want to access services running on OPNsense itself from the Internet. Typical example is VPN.

And of course OPNsense needs a source address for things like DNS queries, downloading updates, NTP and so on. While it can use a LAN interface address for this, I'd recommend having a routable address on the WAN interface whenever possible.

[macklij]

Thanks again Maurice

Good point - especially for a VPN. I would soon realise that when I come to set one up!  I'll do it now, so I don't forget.

[meyergru]

You do not really need a WAN IPv6.

For example, if your ISP only delegates an IPv6 prefix, but no WAN address (mine does this), only your LAN  interface(s) gets an IPv6 GUA. That is no problem, because you can use that for IPv6 traffic originating from and destined to the firewall itself.

[macklij]

Good point.  Thanks

Can the LAN GUA also be used as a source address for OPNsense things like DNS queries, downloading updates, NTP and so on? I didnt see any issues before I turned off 'Request only an IPv6 prefix', but I didn't test updates etc.