dnsmasq and ipv6 config

Started by OzziGoblin, November 04, 2025, 05:18:02 AM

Previous topic - Next topic
You can't. A /64 is the only possible network size on a broadcast (Ethernet) interface. Your ISP is supposed (by recommendation of all regional Internet registries like e.g. RIPE for Europe) to assign you a /56 and never anything smaller.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

December 23, 2025, 05:11:03 PM #31 Last Edit: December 23, 2025, 05:13:37 PM by Monviech (Cedrik)
Or you use the ndp proxy from earlier which helps you to provide the same /64 to any amount of downstream vlans. You dont need to think about subnetting when using it since it targets each individual host automatically via host routes.

Just turn off any dhcpv6 and RA service when using it.
Hardware:
DEC740

Ok, from what Patrick said, if I can't subnet a /64 I have two options from here:

1. Pin to ISC that will be soon a plugin and discontinued afterwards

2. Implement NDP and forget about subnets (have to change my mind) and after that migrate to Dnsmask


Thank you Patrick and Monviech for you advice. I think I'll go on with the second option. Will post the results here of course.

Why do you feel the need to internally use /80s based on your public /64? You could choose any unused /48 and subnet it into /64s for your VLANs. Since you use NAT anyway, your internal addresses don't really matter.

The ND proxy solution (without NAT) is preferrable though.

While it's technically possible to use prefixes longer than /64, it's not recommended and issues are to be expected.
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

3. Kick your ISP until they follow recommended practice 🙂

https://www.rfc-editor.org/rfc/rfc3177

3. Address Delegation Recommendations

   The IESG and the IAB recommend the allocations for the boundary
   between the public and the private topology to follow those general
   rules:

      -  /48 in the general case, except for very large subscribers.
      -  /64 when it is known that one and only one subnet is needed by
         design.
      -  /128 when it is absolutely known that one and only one device
         is connecting.

   In particular, we recommend:

      -  Home network subscribers, connecting through on-demand or
         always-on connections should receive a /48.
      -  Small and large enterprises should receive a /48.
      -  Very large subscribers could receive a /47 or slightly shorter
         prefix, or multiple /48's.
[...]

So even a /56 is debatable although in most cases enough (I can theoretically have 256 VLANs with my /56 I get from Deutsche Telekom).
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

Quote from: Patrick M. Hausen on December 23, 2025, 05:36:19 PMKick your ISP until they follow recommended practice

Patrick, here in Argentina ISPs are offering to home user, services like the one I have. If I want a /48 prefix I need to pay a business plan and the costs are much higher. They argue that business plans has less downtime also, but I can see on the streets that the infrastructure is the same that of the home users (cables and equipment) so paying more money only to have a fixed IP or a /48 prefix doesn't worth it, for now. The game changer will be the day that they put me in a CGNAT network. That day I will have to go for a higher plan to keep a public IP.

Quote from: Maurice on December 23, 2025, 05:29:35 PMWhy do you feel the need to internally use /80s based on your public /64?

Some years ago, when I was configuring IPv6 for the first time, I had to chose between using GUAs or ULAs and someone advice me to use GUAs because Windows had some problems with ULAs. As I was using Windows at that time, I went with GUAs. Now I'm mostly using Linux and could try using ULAs.
I understand that when you say that I could chose any unused /48, you are talking about ULAs. Are you?

You could write to LACNIC asking if there is any way to exert some pressure on ISPs who do not follow proper conventions. ISPs in your country get their IP addresses from LACNIC and with almost certainty signed that they will use them adhering to standards.

Yes, for NAT66 you could use some GUA that you know are unused. ULA is not recommended, because happy eyeballs prioritises it after IPv4.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

December 24, 2025, 01:13:04 AM #37 Last Edit: December 24, 2025, 07:05:36 AM by OPNenthu
Quote from: OzziGoblin on November 07, 2025, 01:42:09 AMHowever, there are no IPv6 leases being registed in dnsmasq.  The only way I am able to get the leases registed is if I enter start and end IPv6 addresses, which adds an EXTRA IPv6 address to each device.

Quote from: OzziGoblin on November 08, 2025, 01:11:38 AMRe the DNSMASQ RA configuration I've tried all the options and no IPv6 address is assigned to the client.

I'm starting to think that dnsmasq is incapable of assigning an ipv6 address to the clients.

Where am I going wrong?

Ozzi, I think you might be getting mixed up about the different IPv6 RA modes and expectations with regard to the Leases table.  It's only when you're using DHCPv6 that IPv6 addresses are assigned to clients and the leases are tracked.  If you're using SLAAC (and only SLAAC) then those are stateless addresses generated on the clients themselves and they aren't tracked like leases.

DHCPv6 and SLAAC can be used together but it's unconventional unless you have a need.  I don't know for sure, but I think you might be trying to use DHCPv6 ranges in Dnsmasq just to get the IPv6 addresses to show up in the Leases table?

I know you said you were using RAs before, but I have some clarifying questions:

1) Were you also using ISC DHCPv6 before?  If so, do you have a specific reason or need for that? (e.g. some oddball clients that don't do SLAAC)
2) Are you OK with not having IPv6 entries in the Leases table?


Quote from: Patrick M. Hausen on December 24, 2025, 12:28:32 AMYou could write to LACNIC asking if there is any way to exert some pressure on ISPs who do not follow proper conventions.

I will pass from that for now.

Quote from: Patrick M. Hausen on December 24, 2025, 12:28:32 AMYes, for NAT66 you could use some GUA that you know are unused. ULA is not recommended, because happy eyeballs prioritises it after IPv4.

That's ok. It is possible because NAT66 do the translation into a routable IP. Will do that.

Thank you.

Quote from: muchacha_grande on December 24, 2025, 12:18:01 AMI understand that when you say that I could chose any unused /48, you are talking about ULAs. Are you?
No, I'm talking about GUAs. ULAs are not recommended for the NAT use case.
You can use any unassigned prefix. It's a little ugly, but less ugly than using /80.
OPNsense virtual machine images
OPNsense aarch64 firmware repository

Commercial support & engineering available. PM for details (en / de).

Thank you Maurice. Before migrating to Dnsmask I will change all interface addresses to some presumably unused GUA /64. After testing that will go on with the migration.

Why not give the ndp proxy a try its for this exact usecase and you dont need any other tricks.

No nat, no ulas, no unused guas...
Hardware:
DEC740

Hi Monviech. I'd try ndp proxy, but how could I solve the IPv6 addresses assignment on the different VLANs? I have a single /64 IP on WAN and I need different networks with different /64 prefixes on each VLAN to be able to route between them.

The NDP proxy does that as far as I understand. The hosts think they are all in one single network. You can still firewall on each interface based on IP address.
Deciso DEC750
People who think they know everything are a great annoyance to those of us who do. (Isaac Asimov)

How should I configure IPv6 addresses on each VLAN interface. Should I just put fixed addresses in the same subnet?

Sorry for the dumb question, but I'm rather new on this as you may already see.