BT Smart Hub IPv6 Stateless forced DNS options

[paulby]

Can I guide that reply slightly in that it's more about a lack of consisitency in protocol management on the BT Hub devices. As @licquorice  says, IPv4 and IPv6 are different protocols. Because both are delivered, we have to pay attention to both. Your home devices on a BT Hub might use one, the other or both depending on the capabilities of the device.
BT do a very good job on the Hubs.
DNS queries - I would speculate - have "value" and are likely monetised by BT, which is all fair and good, but primarily BT require Hub connections to work with nothing else than a hub placed in the home. Totally fine maximum props to BT on that. 
But to allow customers to choose their own DNS providers in IPv4, but not in IPv6 is quite strange and doesn't make any technical or policy sense.
This thread is about allowing the configuration to remove the ICMPv6 RDNSS advertisement to allow customers to choose their IPv6 DNS resolvers aswell as their own IPv4 resolvers as is already done. It's literally one step away from being the perfect service provider deployment - in my opinion of course 🙂 .
Ideally a new firmware update can be crafted which allows for the ICMPv6 RDNSS advertisement to be turned off.
Again, looking forward to hearing back from the Hub team.
Regards

Paul

[licquorice]

I have re-read your original post and cnot sure I understand where the problem lies.

Currently BT do not have IPv6 DNS servers, they use IPv4 servers to serve both IPv4 and IPv6 addresses.

They also allow any third party IPv6 DNS server to be used

[paulby]

@licquorice  It'll take me some time to author a response to re-iterate the problem later should this not suffice.
In short, you're completely correct, BT don't seem to have their RDNS servers addressed with IPv6. That is by the by, really.
The BT hub uses v6 or v4 as the local (home side) transport and then forwards requests over v4 to the BT DNS servers.
BT also allow by default one to send queries to any UDP/TCP port from a device on the local network to any service you wish. That's great, the KEY here is that you have to configure each device to do so on either v6 or v4 by hand.

Because v6 is an end to end protocol and isn't translated by the Hub as with v4, the addressing on the "home" side of the hub is critical. Sure, you can use ULA - which is a whole separate subject - but the GUA prefix is advertised in stateless mode with the unwelcome addition of the ICMPv6 RDNSS. This protocol option in stateless mode is usually offered by some other service other than the Router announcing its v6 Router Advertisements. This is the nub of the problem.

I've partially gone in to details to assist your understanding but I believe the Hub team will have a very good idea about the issue described and I do hope they are considering the request aside from our dialogue. Perhaps @NeilO  can give any ideas as to thoughts?

Paul

[NeilO]

Hi, @paulby I've emailed our contact in the Hub team again today chasing this up. 

Thanks

Neil

[licquorice]

---

@paulby wrote:

@licquorice  It'll take me some time to author a response to re-iterate the problem later should this not suffice.
In short, you're completely correct, BT don't seem to have their RDNS servers addressed with IPv6. That is by the by, really.
The BT hub uses v6 or v4 as the local (home side) transport and then forwards requests over v4 to the BT DNS servers.

Agreed
BT also allow by default one to send queries to any UDP/TCP port from a device on the local network to any service you wish. That's great, the KEY here is that you have to configure each device to do so on either v6 or v4 by hand.

Exactly, to use anything other than BT DNS, you have to configure it per device.

Because v6 is an end to end protocol and isn't translated by the Hub as with v4, the addressing on the "home" side of the hub is critical. Sure, you can use ULA - which is a whole separate subject - but the GUA prefix is advertised in stateless mode with the unwelcome addition of the ICMPv6 RDNSS. This protocol option in stateless mode is usually offered by some other service other than the Router announcing its v6 Router Advertisements. This is the nub of the problem.

I've partially gone in to details to assist your understanding but I believe the Hub team will have a very good idea about the issue described and I do hope they are considering the request aside from our dialogue. Perhaps @NeilO  can give any ideas as to thoughts?

Paul

---

I'm probably missing something here, but that address is surely just the link local address of the hub, not a DNS server, just the gateway.

[licquorice]

@paulby  Does RFC 8106 shed any light?

[licquorice]

Wireshark

ICMPv6 Option (Recursive DNS Server fe80::be30:d9ff:fe01:32f0)
Type: Recursive DNS Server (25)
Length: 3 (24 bytes)
Reserved
Lifetime: 60
Recursive DNS Servers: fe80::be30:d9ff:fe01:32f0
ICMPv6 Option (MTU : 1492)
ICMPv6 Option (Source link-layer address : bc:30:d9:01:32:f0)

Hub Manager

IPv6 LAN details

Link local address:

fe80::be30:d9ff:fe01:32f0/64

[paulby]

Shed any light? Well, the RFC describes the process that's occuring to some degree if not exactly.
I'm 100% clear on what's occuring. Going back to the title of the thread, RDNSS options are being forced in lieu of running DHCPv6 services on the local segment. But as with turning off DHCPv4 if one is running DHCPv6 services on the segment this enforcement drives over the hopes of a legible configuration with two systems annoucing, one via the BT Hub and one of your own making. That's a very very poor outcome.

The three v6 configuration options (ULA aside) on the BT Hub are stateless (default), stateful and off. The only setting that removes the ICMPv6 RDNSS configuration is "off". This isn't useful as at that point the GUA address space is _completely_ manual and adrift from whatever GUA /56 maybe allocated on the BT Hub from that point on.
The setting I'm suggesting that is missing here is to turn off ICMPv6 RDNSS on Stateless v6 (perhaps even "Turn off RFC8106", but that may be a bit opaque). Maybe even better - Allow configuration of the ICMPv6 RDNSS setting to be a configurable v6 address other than the LLA address of the BT Hub. That! Now that would be really great. 🙂
DNS isn't forced on v4, so it doesn't make senses it's forced on v6 either technically or via policy.

Just to refocus, this is all about DNS. DNS is a key service on the modern Internet. Again, v4 configuration on the BT Hub gives you autonomy, and v6 should allow the same.

Many thanks.
Paul

[licquorice]

---

@paulby wrote:

Just to refocus, this is all about DNS. DNS is a key service on the modern Internet. Again, v4 configuration on the BT Hub gives you autonomy, and v6 should allow the same.

Many thanks.
Paul

---

But it doesn't, you can't configure IPv4 DNS on the hub, only on each device. I must be missing something here, I can't see the difference between IPv4 and IPv6 with regard to autonomy.

[ptrduffy]

If I'm understanding correctly, the OP would like to run his own DHCPv6 server on his local network, and use that to configure DNS for the local hosts.  He can get similar behaviour on IPv4 by simply turning off DHCP on the Hub.  It would appear that the only way to stop the Hub sending the DNS server details in IPv6 is by disabling IPv6 completely.

However, in the original post it would appear that the Hub's IPv6 RA message has the "O" bit set to 1.  This indicates that "Other Information" is available to hosts via DHCPv6, so the hosts should be making a DHCPv6 request.  So, my first question to the OP would be, are the hosts indeed making DHCPv6 requests?

If the hosts are making these requests, then there is the further complication that they will now end up with 2 DNS server addresses - one via the Hub RA message, and one from DHCP.  I'm fairly certain that the relevant RFCs suggest that DHCP-delivered addresses should take precedence - but it's been a number of years since I worked in this area, and we could well be in the realms of something that is implementation dependent.

I think the OP's suggestion of an option to not send the DNS address in the RA message (or, even better, allow the address that is sent to be configurable) is a good idea.