IPV6 With TP-Link Router

Help Community Help
1

I've searched here as much as I could to see if I could resolve my IPV6 issue but unfortunately can't seem to find the right fix.

I recently updated my router with the TP-Link Archer BE900 (BE24000) and everything seems to work great, but the router is still providing the IPV6 addresses vs the addresses being provided/leased by my Pi-hole.

Quick rundown:

  • Full IPV6 support from my ISP (AT&T Fiber) confirmed with https://test-ipv6.com/
  • AT&T Fiber router/modem is full IP passthrough to router.
  • IPV6 is enabled & DHCP server is disabled on the router
  • IPv6 LAN on router settings is set to SLAAC+Stateless DHCP
  • The routers default DNS is set both IPV4 & IPV6 to the Pi-hole respective addresses
  • DHCP server is enabled on the Pi-hole
  • I have enabled additional IPv6 support (SLAAC + RA) on the Pi-hole

Pi-hole is giving out IPV4 addresses great - no issues, but it isn't providing IPV6 addresses.

Not sure if I need to be using a different IPV6 LAN setting on the router?

It gives me these options:

  • ND Proxy haven't used
  • DHCPv6 TESTED - same result as I'm having now, plus the error: "No address range available for DHCPv6 request via eth0"
  • SLAAC+Stateless DHCP current -but not getting the address range error
  • SLAAC+RDNSS haven't used

When I look at the query log most of the devices are using the IPV6 address under "client" so I know they're getting them, and that they're being sent through the Pi-hole.

But when I look at the DHCP Settings all of the Currently active DHCP leases are IPV4.

I feel so close to the answer, but something is missing for the Pi-hole IPV6 leases. Any help is greatly appreciated!

2

It's a router's job to facilitate IPv6 address assignments.

DHCP is strictly IPv4.
DHCPv6 is about equivalent for IPv6 (different ports, different protocol).

However, most OSs prefer autoassigning IPv6 addresses via NDP/SLAAC, learning required and optional additional network details via NDP/RAs or Stateless DHCPv6. Some OSs do not support DHCPv6 at all, Android being the prime example here.

As for DNS:
If your router supports it, I'd recommend to configure it to offer no IPv6 DNS server address at all. That would allow Pi-hole to reliably associate hostnames to client IPs (as IPv4 addresses don't change regularly as e.g. temporary IPv6 addresses would), and thus make identifying clients easier, so your Pi-hole dashboard would be easier to read.

3 Likes
3

EDIT: @Bucking_Horn beat me to it :wink:

Both SLAAC and Stateless DHCP are not handing out any IP's like you're used to with IPv4 DHCP.
They both work by advertising an IPv6 prefix + mask and leave it up to the clients to construct their own IPv6 address(es).
Prefixes advertised can be for both GUA's or ULA's (the boxes at bottom of below diagram):

You can run below on the Pi-hole host to inspect whats advertised on your network via either IPv4 DHCP or IPv6 RA's:

sudo pihole-FTL dhcp-discover

But still, easiest would be to dissable resolving DNS throught IPv6 entirely for your clients.
So dont advertise any IPv6 DNS server(s) via IPv6 RA's or IPv6 DHCP.
Clients can resolve names to IPv6 addresses through IPv4 DNS and vice versa.
The clients would still connect to the IPv6 addresses resolved through IPv4 DNS.

1 Like
4

Thanks Bucking_Horn & deHakkelaar (I'm not allowed mentions yet :smiling_face_with_tear:) -

TBH I was worried what response I might get, but this really help clarify things I didn't know about IPv6. I didn't realize that clients created the back half of the address and it makes a lot more sense seeing the settings on the router and how Pi-hole is handling everything.

I guess I got caught up in the Pi-hole system settings > DHCP server metrics where it says:

|Allocated / pruned IPv4 leases:|22 / 0|
|Allocated / pruned IPv6 leases:|0 / 0|

When I ran the discover command I got a good response (from what I can tell):

apologies for X redactions

Scanning all your interfaces for DHCP servers and IPv6 routers
Timeout: 6 seconds

* Received 136 bytes from fe80::4747:XXXX:XXXX:XXXX @ eth0
  Hop limit: 64
  Stateful address conf.: No
  Stateful other conf.: Yes
  Mobile home agent: No
  Router preference: Medium
  Neighbor discovery proxy: No
  Router lifetime: 1800 s
  Reachable time: N/A
  Retransmit time: N/A
  - Prefix: 2600:XXXX:XXXX:XXX::/64
    Valid lifetime: 296 sec
    Preferred lifetime: 296 sec
    On-link: Yes
    Autonomous address conf.: Yes
  MTU: 1500 bytes (valid)
  Source link-layer address: XX:XX:XX:XX:XX:XX
  Recursive DNS server 1/4: 2600:1700:XXXX:XXX:XXXX:XXXX:XXXX:XXXX
  Recursive DNS server 2/4: 2600:1700:XXXX:XXX:XXXX:XXXX:XXXX:XXXX
  Recursive DNS server 3/4: fe80::XXXX:XXXX:XXXX:XXXX
  Recursive DNS server 4/4: fe80::XXXX:XXXX:XXXX:XXXX
  DNS server lifetime:296 sec

* Received 56 bytes from fe80::XXXX:XXXX:XXXX:XXXX @ eth0
  Hop limit: 64
  Stateful address conf.: No
  Stateful other conf.: Yes
  Mobile home agent: No
  Router preference: Medium
  Neighbor discovery proxy: No
  Router lifetime: 1800 s
  Reachable time: N/A
  Retransmit time: N/A
  - Prefix: 2600:1700:XXXX:XXX::/64
    Valid lifetime: 300 sec
    Preferred lifetime: 300 sec
    On-link: Yes
    Autonomous address conf.: Yes
  Source link-layer address: XX:XX:XX:XX:XX:XX

* Received 56 bytes from fe80::XXXX:XXXX:XXXX:XXXX @ eth0
  Hop limit: 64
  Stateful address conf.: No
  Stateful other conf.: Yes
  Mobile home agent: No
  Router preference: Medium
  Neighbor discovery proxy: No
  Router lifetime: 1800 s
  Reachable time: N/A
  Retransmit time: N/A
  - Prefix: 2600:1700:XXXX:XXX::/64
    Valid lifetime: 300 sec
    Preferred lifetime: 300 sec
    On-link: Yes
    Autonomous address conf.: Yes
  Source link-layer address: XX:XX:XX:XX:XX:XX

* Received 311 bytes from 19X.XXX.XX.XX @ eth0
  Offered IP address: 19X.XXX.XX.XXX
  Server IP address: 19X.XXX.XX.XX
  Relay-agent IP address: N/A
  BOOTP server: (empty)
  BOOTP file: (empty)
  DHCP options:
   Message type: DHCPOFFER (2)
   server-identifier: 19X.XXX.XX.XX
   lease-time: 43200 ( 12h )
   renewal-time: 21600 ( 6h )
   rebinding-time: 37800 ( 10h 30m )
   netmask: 250.XXX.XXX.X
   broadcast: 19X.XXX.XX.XX
   domain-name: "lan"
   ntp-server: 19X.XXX.XX.XX
   dns-server: 19X.XXX.XX.XX
   dns-server: 19X.XXX.XX.XX
   dns-server: 19X.XXX.XX.XX
   router: 19X.XXX.XX.X
   --- end of options ---

Received 1 DHCP (IPv4) and 3 RA (IPv6) answers on eth0

Suprisingly enough - all the clients are identified, but I also already did some Static DHCP configuration based on MAC addresses of everything.

So, based on what you both provided, and my readout, since everything is working, I should be all set and no additional changes needed?

Again thanks so much for your help and providing details that I really didn't understand about IPv6!

1 Like
5

Are all above IP's those of the Pi-hole host?
You can see all IP's (GUA, ULA & LLA) if run below on the Pi-hole host:

ip -br -6 a

From that diagram I linked previously, the first two are GUA's and the latter two are LLA's.
I would not recommend advertising GUA's to your clients as the prefix for those is under ISP control via prefix delegation and can change over time and most often do.

Recommended is to advertise ULA's if your router is able to advertise a ULA prefix.
Those IP's wont change if no MAC randomisation is applied on the Pi-hole host.

LLA's will also do fine but they are not routable.

6

Yes DNS 1/2 are the same, & DNS 3/4 are the same and they match the Pi-hole. I can't use the LLA's as a designated DNS in the router - it always rejects them as invalid input - The router unfortunately wont take any LLA or ULA's. It's rejecting anything that starts with the fe or fd - will accept anything starting with 2xxx or 3xxx.

However the GUA does differ from the ISP at the subnet ID section (4) - I'm guessing by design the router IPv6 settings change this - I'm assuming this is the "advertise a ULA prefix". AT&T has never changed theirs (up to their subnet) though - well in the last few years it's remained constant.

My ULA is strange (or trying to tell me something) with:

fd11:xxxx/64

No MAC randomizing on the Pi-hole host.

Thanks again for the help!

1 Like
7

Thats a valid ULA:

Doesnt that one work instead of GUA's and/or LLA's?

You can test on a client with nslookup eg:

nslookup pi.hole fd11:xxxx

Sometimes you have to add the local interface eg for %eth0:

$ nslookup pi.hole fe80::xxx%eth0
Server:         fe80::xxx%eth0
Address:        fe80::xxx%2#53

Name:   pi.hole
Address: 10.0.0.4
Name:   pi.hole
Address: fe80::xxx

EDIT: Oh sorry, I dont have IPv6 enabled on my LAN so thats why I address the LLA in my example :wink:
Most all hosts can auto construct an LLA without any RA prefix etc.

8

I noticed "bad:c0de" too late :smiley:

9

Missed above bit.
Thats a bummer.
Have you tried below filling up with zeros?

fd11:5ee:bad:c0de:0000:0000:0000:1

Or maybe:

fd11:5ee:bad:c0de:0:0:0:1

EDIT: I dont know if when you enable Pi-hole's own "IPv6 support (SLAAC + RA)",
if it will advertise Pi-hole's own ULA as a DNS server.
Could give that a try and disable advertising DNS servers via the router entirely?

10

Ha - yeah I think all Raspi's give that ULA tbh - I checked my other one and sure enough its ULA is also "bad:c0de"

I did try to make the ULA its full 128 bit but I am pretty sure it's a TP-Link setting that just says, "anything not 2xxx or 3xxx BAD. :unamused_face:

This is something I am going to try - but that was why I was wondering if any of the other options of the router might do the same thing - allowing the Pi-hole to advertise it's ULA instead (I just now am finally understanding terminology).

I am worried that if I turn it off on the router it might null IPv6 for everything - but it is worth a shot.

Router Options: for reference

ND Proxy 
DHCPv6
SLAAC+Stateless DHCP
SLAAC+RDNSS
11

I just asked AI to explain these things like I'm 5 and :pinched_fingers:

:compass: 1. ND Proxy (Neighbor Discovery Proxy)

:magnifying_glass_tilted_left: What it is:

An ND Proxy is like a middleman device that responds to IPv6 Neighbor Discovery (ND) requests on behalf of another device.

:brain: Real-world analogy:

Think of it like a doorman who answers the door for someone in the back room. The outside world asks, “Who lives here?” and the ND Proxy replies, “That guy does,” even if the guy is hidden behind a wall.

:toolbox: Why it's used:

  • To extend networks across different links (like Wi-Fi + Ethernet)
  • For bridging between two parts of a network that don’t support proper routing
  • To allow IPv6 communication between devices that are technically on separate links

:luggage: 2. DHCPv6 (Dynamic Host Configuration Protocol for IPv6)

:magnifying_glass_tilted_left: What it is:

DHCPv6 is the IPv6 version of DHCP. It’s a centralized way to assign IPv6 addresses and other network info (like DNS, NTP servers) to devices on a network.

:brain: Real-world analogy:

This is like a reception desk handing out hotel room keys and the Wi-Fi password. You show up, ask for an address, and get what you need.

:toolbox: Why it's used:

  • Full control over address assignment
  • Ideal in enterprise environments where tracking devices is important
  • Supports both stateful (gives full address info) and stateless (gives only extra info)

:seedling: 3. SLAAC + Stateless DHCP

:magnifying_glass_tilted_left: What it is:

This is a hybrid method:

  • SLAAC (Stateless Address Autoconfiguration) gives the device its IPv6 address
  • Stateless DHCPv6 provides extra info like DNS servers

:brain: Real-world analogy:

You find your own seat on the bus (SLAAC), but the driver hands you a schedule and map (Stateless DHCP).

:toolbox: Why it’s used:

  • You don’t need a full DHCP server for address assignment
  • Still allows flexibility for providing DNS and other configuration info
  • Common in home and small business networks

:globe_with_meridians: 4. SLAAC + RDNSS (Recursive DNS Server Option)

:magnifying_glass_tilted_left: What it is:

This is another hybrid, but no DHCPv6 is used at all.

  • SLAAC gives the IP address
  • RDNSS (defined in RFC 6106) provides DNS info directly in the Router Advertisement (RA)

:brain: Real-world analogy:

You walk into a library and see a sign telling you where to sit and which websites to visit. No one hands you anything — it’s all just posted clearly.

:toolbox: Why it’s used:

  • Even simpler than using DHCPv6
  • Ideal for minimal networks
  • Not all devices support it (especially older or non-Linux systems)
12

That AI is lagging behind :wink:

Request for Comments: 8106
Obsoletes: 6106

IPv6 Router Advertisement Options for DNS Configuration

13

Full phrase is: "1:5ee:bad:c0de"

I see bad code :wink:
Still no clue what it means.

EDIT: The closest I could find:

As of BIG-IP AS3 3.10.0, if the Firewall_Address_List contains zero addresses, a dummy IPv6 address of ::1:5ee:bad:c0de is added in order to maintain a valid Firewall_Address_List. If an address is added to the list, the dummy address is removed.

1 Like
14

SOLUTION

Just wanted to stop back and report success - I realized that the ISP modem/router was on passthrough (as it should be) but I didn't tell TP-Link that information.

In the IPv6 Menu on the router there is a dropdown on how the internet IPv6 is being handled/provided - it needs to be selected as "Passthrough" if that is what you are doing - then Pi-Hole will have all the IPv6 address ranges it desires and no more issues.

Thanks again for all the help!

1 Like