Should my dhcpv6 clients also get a /64 address?

jarmo

This shows my ipv6 newbie status...

Ok, so is the /128 address then an issue? But that address matches the pool of addresses I needed to specify in the dhcpv6 server settings for that interface. Therefore, that address makes complete sense to me.

To debug this, I just added another interface (ipv6 only) and specified that for that interface, the router advertisement method is dhcpv6 only. For this new interface I get only one address, and that is a /128. And that connection works too.

So does the /64 address come from SLAAC and the /128 from dhcpv6?

johnpoz

@jarmo you shouldn't be handing out /128 - how would there ever even be any addresses to hand out if your prefix was a /128

Can you show on your client where your seeing a /128 prefix

Gertjan

@jarmo

If this is your WAN IPv6 :

@jarmo said in Should my dhcpv6 clients also get a /64 address?:

c::100a

then the 'c' or ......:xx0c:.... for the LAN can't be possible.
0c will be prefix number 'c' or 12 out of a 256 range (from 00 to ff or 256).
So, '0c' is taken for you WAN - actually one IPv6 use out of the 2^64 ( ^^)
As you said : that unexpected.

edit : humm, I wasn't typing fast ...
Normally, at the WAN interface you would have a IPv6 like this :

'00' means prefix '0'.

On the tracked LAN interface I have :

with prefix 'e2'.

Bob.Dig

This post is deleted!

Bob.Dig

On your WAN you might have /128 but that would be the only exception I can think of.

jarmo

@johnpoz @Bob-Dig and others:

Here is a detailed description of the situation in which I get a /128
dhcpv6 client address.

First, here is the resulting address:

[jarmo ~]$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
2: wlp0s20f3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2xxx:xxxx:xxxx:xxxb::1000/128 scope global dynamic noprefixroute 
       valid_lft 7172sec preferred_lft 4472sec
    inet6 fe80::200a:ff5a:4446:5aba/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

WAN settings:

IPv6 Configuration Type: DHCP6
DHCPv6 Prefix Delegation size: 56 (verified from ISP)
Send IPv6 prefix hint: yes
Block private networks and loopback addresses: yes
Block bogon networks: yes
Firewall rules: no passing rules

Interface WVLAN11 settings:

IPv4 Configuration Type: None
IPv6 Configuration Type: Track Interface
IPv6 Interface: WAN
IPv6 Prefix ID: b
Block private networks and loopback addresses: yes

Router advertisement on WVLAN11:

Router Mode: Managed
Router Priority: Low
Enable DNS: no

DHCPv6 on WVLAN11:

Prefix Delegated Prefix: WAN/11 (2XXX:XXXX:XXXX:XXXb::/64)/64
(not set by me, auto-filled by system)
Address Pool Range: From ::1000 To ::2000
Enable DNS: yes

Firewall rules for WVLAN11:

JKnott

@jarmo said in Should my dhcpv6 clients also get a /64 address?:

My questions are:

Is this kind of behavior expected?
If not, what might I have specified incorrectly?

Is this on the LAN or WAN side? That's entirely normal on the WAN. Also, is there some reason you're using DHCP6 on the LAN? Normally SLAAC does all you need and Android devices don't support DHCP6.

With SLAAC, you get up to 8 global addresses, 1 consistent and up to 7 privacy addresses.

jarmo

@JKnott
The two addresses, one /64 and one /128, are from a DHCP client connected to a VLAN interface via a wireless access point to the netgate router, so I guess in your terminology this would be "from the LAN side".

johnpoz

@jarmo said in Should my dhcpv6 clients also get a /64 address?:

[jarmo ~]$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
inet6 ::1/128 scope host noprefixroute
valid_lft forever preferred_lft forever

That is your loopback - that isn't handed out by dhcp ;)

that is just ::1

Example - here is my lo interface

lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
        options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
        inet 127.0.0.1 netmask 0x0
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x8
        groups: lo
        nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>

Oh you have it on your wlp0s20f3 as well - that makes no sense.. What OS is that on? But should be your actual prefix.. It clearly is a wireless interface since it starts with wl

jarmo

@johnpoz said in Should my dhcpv6 clients also get a /64 address?:

Oh you have it [/128] on your wlp0s20f3 as well - that makes no sense. ... But should be your actual prefix..

Yes indeed, a public /128 address has been handed. To remove clutter,
here it is again:

[jarmo ~]$ ip -6 a | grep "inet6 2"
    inet6 2xxx:xxxx:xxxx:xxxb::1001/128 scope global dynamic noprefixroute

And yes, it matches specified dhcpv6 address range.

@johnpoz said in Should my dhcpv6 clients also get a /64 address?:

It clearly is a wireless interface since it starts with wl

Network device type does not matter. Here is the situation I described
in my opening post. This is a direct wired connection to netgate
device. The relevant settings for this interface are the same as for
the wireless, except for ipv6 prefix id and router advertisement. For
this wired interface, prefix id is 3, and router advertisement mode is
assisted (providing both dhcpv6 and slaac).

[jarmo ~]$ ip -6 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host noprefixroute 
       valid_lft forever preferred_lft forever
4: enp86s0u1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
    inet6 2xxx:xxxx:xxxx:xxx3::1000/128 scope global dynamic noprefixroute 
       valid_lft 7169sec preferred_lft 4469sec
    inet6 2xxx:xxxx:xxxx:xxx3:ee72:cd8d:3d06:e4e6/64 scope global dynamic noprefixroute 
       valid_lft 86397sec preferred_lft 14397sec
    inet6 fe80::d3ff:2ff0:87b6:93b2/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

As you can see, dhcp client gets two public addresses. One is a /128
matching the address pool range specified in dhcpv6 server
settings. The other is a /64, perhaps coming from slaac?

@johnpoz said in Should my dhcpv6 clients also get a /64 address?:

What OS is that on?

OS is Fedora 42, but I do not think it matters. At least my iOS
devices get similarly multiple ipv6 addresses, one matching dhcpv6
pool range, the others similar to the /64 addresses above. But iOS
does not allow me to see the /128 or /64 specifier, I can only see the
addresses themselves.

I guess the next thing I should try is slaac only? But doing that should not be necessary, right?

jarmo

@JKnott said in Should my dhcpv6 clients also get a /64 address?:

Also, is there some reason you're using DHCP6 on the LAN? Normally SLAAC does all you need and Android devices don't support DHCP6.

I do not know why I should be running one or the other.

But as suspected above, slaac might be the solution: I just changed the router advertisement mode of an interface to slaac only, and in that interface, clients get one /64 address from a correct subnetwork.

So... a solution but no explanation?

Thanks!

Gertjan

@jarmo said in Should my dhcpv6 clients also get a /64 address?:

clients get one /64 address

a /64 addresses isn't an addresses, it's more an 'network' (imho).

I asked my NAS to renew its Ipv6 lease :

10:49:34.954022 00:11:32:a7:d5:88 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 129: (hlim 1, next-header UDP (17) payload length: 75) fe80::211:32ff:fea7:d588.546 > ff02::1:2.547: [udp sum ok] dhcp6 solicit (xid=123d36 (client-ID hwaddr type 1 001132a7d588) (option-request DNS-server DNS-search-list) (elapsed-time 0) (Client-FQDN) (IA_NA IAID:849859976 T1:3600 T2:5400))
10:49:34.954799 90:ec:77:29:39:2c > 00:11:32:a7:d5:88, ethertype IPv6 (0x86dd), length 207: (hlim 64, next-header UDP (17) payload length: 153) fe80::1:1.547 > fe80::211:32ff:fea7:d588.546: [udp sum ok] dhcp6 advertise (xid=123d36 (client-ID hwaddr type 1 001132a7d588) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:849859976 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c2 pltime:13500 vltime:21600)) (DNS-server 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c) (DNS-search-list bhf.tld.) (Client-FQDN))
10:49:34.955219 90:ec:77:29:39:2c > 00:11:32:a7:d5:88, ethertype IPv6 (0x86dd), length 207: (hlim 64, next-header UDP (17) payload length: 153) fe80::1:1.547 > fe80::211:32ff:fea7:d588.546: [udp sum ok] dhcp6 advertise (xid=123d36 (client-ID hwaddr type 1 001132a7d588) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:849859976 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c2 pltime:13500 vltime:21600)) (DNS-server 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c) (DNS-search-list bhf.tld.) (Client-FQDN))
10:49:35.965351 00:11:32:a7:d5:88 > 33:33:00:01:00:02, ethertype IPv6 (0x86dd), length 175: (hlim 1, next-header UDP (17) payload length: 121) fe80::211:32ff:fea7:d588.546 > ff02::1:2.547: [udp sum ok] dhcp6 request (xid=ac6158 (client-ID hwaddr type 1 001132a7d588) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (option-request DNS-server DNS-search-list) (elapsed-time 0) (Client-FQDN) (IA_NA IAID:849859976 T1:3600 T2:5400 (IA_ADDR 2a01:dead:beef:a6e2::c2 pltime:7200 vltime:7500)))
10:49:35.968124 90:ec:77:29:39:2c > 00:11:32:a7:d5:88, ethertype IPv6 (0x86dd), length 207: (hlim 64, next-header UDP (17) payload length: 153) fe80::1:1.547 > fe80::211:32ff:fea7:d588.546: [udp sum ok] dhcp6 reply (xid=ac6158 (client-ID hwaddr type 1 001132a7d588) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:849859976 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c2 pltime:13500 vltime:21600)) (DNS-server 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c) (DNS-search-list bhf.tld.) (Client-FQDN))
10:49:35.970710 90:ec:77:29:39:2c > 00:11:32:a7:d5:88, ethertype IPv6 (0x86dd), length 207: (hlim 64, next-header UDP (17) payload length: 153) fe80::1:1.547 > fe80::211:32ff:fea7:d588.546: [udp sum ok] dhcp6 reply (xid=ac6158 (client-ID hwaddr type 1 001132a7d588) (server-ID hwaddr/time type 6 time 753711221 90ec7729392a) (IA_NA IAID:849859976 T1:6750 T2:10800 (IA_ADDR 2a01:dead:beef:a6e2::c2 pltime:13500 vltime:21600)) (DNS-server 2a01:dead:beef:a6e2:92ec:77ff:fe29:392c) (DNS-search-list bhf.tld.) (Client-FQDN))

Windows PC : same thing.
iPhone : same thing.
A ricoh printer : same thing.

No where a /64 to be seen.
It obtained a IPv6 : 2a01:dead:beef:a6e2::c2 for my syno. That could be considered as a /128.
and that's correct as 2a01:dead:beef:a6e2::0 -> 2a01:dead:beef:a6e2::ffff:ffff:ffff:ffff - the entire /64 block) where my 'e2' prefix used on my LAN

My IPv6 DHCP server pool is way shorter, of course :

and I'm using static IPv6 leases for most of my network devices. These leaves are outside of the pool, just above.
Static leases as I don't want them to have these kind of addresses : "2a01:dead:beef:a6e2:92ec:77ff:fe29:392c".

SLAAC : never used it. I'm a DHCP-man, as it worked well for IPv4, so I tend to believe it works fine for my IPv6 stuff also.
Android : never saw or had one ...

All my iPhone, iPad, printers, PCs etc etc that are IPv6 capable, work just fine like this.

A suggestion : maybe you Fedora box is asking for a 'prefix', which would be a /64 ?
(but in that case the pfSense LAN DHCPv6 server would have to be set up to delegate these prefixes downstream.)

johnpoz

Do you have this set?

That should be left empty and it would hand out the /64 that is on your interface.

jarmo

@johnpoz
RA Subnet(s) is empty.

jarmo

Still trying to debug this.

Interesting fact: when those /128 dhcpv6 leases are handed out, pfsense+ status shows that there are no current dhcpv6 leases. Notice that the addresses of those leases match the range specified in dhcpv6 server settings for the interface (::1000 to ::2000).

What could be the reason for this? Addresses from specified pool, but not from this server? So from... ISP server?

Tried to increase priority to "high", no difference.

Gertjan

@jarmo

Services > DHCPv6 Relay isn't active ?

LAN and WAN are VLANs ? Or classic NICs ?

if the pfSense DHCPv6+ server hands out leases, they are listed here :

JKnott

@jarmo said in Should my dhcpv6 clients also get a /64 address?:

clients get one /64 address from a correct subnetwork.

Initially, there should be 2. A consistent address and a privacy address. You get another privacy address each day, up to 7, when the oldest one falls off the list.