IPv6 and nameservers during IPv6 packet loss



  • This is a strange one, but I'm probably the cause :-)

    I've got Pfsense 2.4.4 on a Comcast Business link. Since Comcast still has no way to support prefix delegation on 99% of modern equipment, I have to use HE for a tunnel broker. It works, but occasionally, it gets packet loss.
    My pfsense box has an IPv6 LAN IP of 2001:XXXX:XXXX:2::1/64. I'm using both DHCP6 and RA Assisted.

    Hosts on the LAN get a DNS address of the pfsense LAN interface. (2001:XXXX:XXXX:2::1/64). When pfsense sees the link has packet loss (note, not "down", just packet loss), I seem to lose name server functions.... at least on Windows clients. (LInux is not affected)

    • Is there something I should have done? I've tried telling the DHCPv6 server on the LAN to send the Link-local address of the pfsense box, but I appear to be ignored. I've also tried to put the link local address in the DNS boxes for the RA service.
    • What's really going on here? What does this happen with packet loss? I still have transit, but no DNS. I'd understand what happens if the link were down, and it does happen that way, but why on packet loss?

    For reference, I'm running one of the Protecteli boxes (i5, 8GB, 120GB SSD) with 4 Intel igb interfaces and pfsense 2.4.4-p3 I believe. As noted above, it's on Comcast Business (static v4 works fine, V6 doens't work since Comcast Buinsess can't support PD on anyting but one old Netgear modem.)


  • LAYER 8 Global Moderator

    What your saying makes no sense, think your following a red herring about windows and linux..

    If your wan is experience packet loss, then yeah dns "could" fail during the resolving process for something that is not cached..But that has zero to do which your lan side.. Or who would be asking.

    Not sure how asking the link local address vs the global on your lan would have anything to do with anything.. Its not your lan side seeing the packet loss, its the wan side.

    So client asks for lan IPv6 address for host.domain.tld... If that is cached by unbound - it would return the address instantly.. If not cached then it would have to resolve it.. Either all the way down from roots, or from the NS it has cached for that domain, etc.

    When it tries to talk to these name servers - if your line is having packet loss, then sure dns could fail.. Or could take extra long.. But it wouldn't matter what sort of client on the lan side is asking for host.domain.tld

    If you ask with windows and fails, then go and ask same question from linux client.. Maybe unbound finally got it resolved with the packet loss..

    Have you tried a different HE pop for your tunnel? Its possible your having issue with the path to that specific pop if your seeing only packet loss on the tunnel connection, and not on the parent IPv4 connection.



  • @jantypas said in IPv6 and nameservers during IPv6 packet loss:

    Since Comcast still has no way to support prefix delegation on 99% of modern equipment

    V6 doens't work since Comcast Buinsess can't support PD on anyting but one old Netgear modem

    That doesn't sound right. What does Comcast say about that? Since it's a business connection, might it be they don't use DHCPv6-PD and expect you configure a routed network? With my ISP, they support multiple modems, but not a Cisco model.

    Have you run Packet Capture on your connection to see what's being provided?



  • Comcast admits they have no support for PD on IPv6. Effectively, you get a /64 no matter what, even if I have my /56 block. The question I wonder about is:

    • I create the tunnel that provides an interface with a routable V6 /48 of 2001:XXXX:YYYY:/48
    • I assigned the LAN interface an address out of that range 2001:XXX:YYYY:2::1
    • pfSense has DNS servers for 8.8.8.8 and 8.8.4.4 along with their V6 versions :8888 and :8844
    • The DHCPv6 server and RA have the DNS entries left blank so the Windows machine gets a DNS server of the pfsense LAN interface (2001:XXXX:YYYY:2::1)

    Everything works until I get packet loss on the tunnel interface. When that happens, sending DNS requets to Pfsense times out.



  • @jantypas said in IPv6 and nameservers during IPv6 packet loss:

    Comcast admits they have no support for PD on IPv6. Effectively, you get a /64 no matter what, even if I have my /56 block.

    Have you seen this?

    Can you put the modem in bridge mode? What happens then? My modem is configured for bridge mode and works fine with pfSense.



  • That would be interesting. Comcast swears that the modem can be in bridged mode, but then it can't do static IPv4. So I have a choice of static IPv4s or V6s. However, Comcast often doesn't know. So, do you have static IPv4s as well?


  • LAYER 8 Global Moderator

    We have a comcast business line here at this office, and it has static IPv4 assigned to a pfsense router behind the gateway which is in bridge mode. Have to run over to the idf room to get what model of isp device.. But port 1 on the device is bridged to pfsense that has the static on it.

    Have never tried to enable ipv6 on it, no need for it.



  • @johnpoz said in IPv6 and nameservers during IPv6 packet loss:

    Have never tried to enable ipv6 on it, no need for it.

    There is a need for it in that we have to move from IPv4 to IPv6 and the sooner the better. While you may not see a need for it, there are many who have only NAT addresses on IPv4, which means they cannot connect to their own network from elsewhere. The longer the delay in moving to IPv6, the longer they're cut off from their own network. Also, the widespread use of NAT results in many thinking that NAT is the only way to do things, as we learned in that recent thread with the "engineer".



  • Don't remind me -- I can accept some of the Comast decisions -- they made sense for the time, but Comcast clearly assigns me a static /56 prefix, but there modems, including the newer ones, can't use it according to them.



  • @jantypas said in IPv6 and nameservers during IPv6 packet loss:

    Don't remind me -- I can accept some of the Comast decisions -- they made sense for the time, but Comcast clearly assigns me a static /56 prefix, but there modems, including the newer ones, can't use it according to them.

    Well, you're paying for the service. It's up to them to make it work.

    I'm really curious as to why they're having such a problem. It's not beyond many other ISPs.


  • LAYER 8 Netgate

    I have had several Comcast business IPv6 tickets. All nightmares due to the Comcast CPE. That is not the first time I have seen "bridge the modem, lose static IPv4."



  • @Derelict said in IPv6 and nameservers during IPv6 packet loss:

    I have had several Comcast business IPv6 tickets. All nightmares due to the Comcast CPE. That is not the first time I have seen "bridge the modem, lose static IPv4."

    As someone who has been a tech for most of my career, it bugs me when someone knows there's a problem, but won't fix it. If the CPE doesn't work, maybe they should go with a different brand. As I mentioned, my ISP will not put IPv6 over a Cisco modem. They provide Hitron, which works well, though the firewall is crap.



  • Quite true perhaps, but Comcast Business is very much a "this is what we have, do it our way or our way or our way" option. And, if this is the only high speed Internet you have, well, you do it their way or no way at all.
    As I said, that's why I have to use an HE tunnel. It works, until I get packet loss, and then, for some reason, DNS on the LAN interface no longer works. Specifically:

    • On a windows client, I see the IPv6 DNS set to the LAN IPv6 address of Pfsense.
    • When I have packet loss, I can no longer do DNS resolution on that address
    • Linux clients are not affected, they seem to handle things just fine

  • LAYER 8 Global Moderator

    @JKnott said in IPv6 and nameservers during IPv6 packet loss:

    There is a need for it in that we have to move from IPv4 to IPv6 and the sooner the better.

    Yeah no sorry, while it is down the road, its not sooner the better.. For starters its seems one of the largest IPv6 isp in the US, has all kinds of issues with actual deployment of it. STILL, years and years into their deployment of it. They started this back in 2011... How is it not rock solid stable and just work, with all kinds of flexibility of this and that method.. Because its not a freaking sprint but a marathon. And companies are not going to spend money on something they don't actually have too.. We are going to be running in this dual stack mode for many years to come.. I will for sure be retired from the biz before it ever close to being mainstream... Sorry.. but that is the reality of it, no matter how much you think or want IPv6 to become mainstream..

    When you get some major player to say, hey you have to have IPv6 to use this resource is when you will see drive towards actual use.. Where ipv6 is king is mobile devices - because there is a freaking billions of cell phones, etc..

    There is Zero resources that are needed to get to from this network that are only IPv6.. So I have and the users here have ZERO use for it at this time.. Zero!! All it does is cause issues and pain and added work and complexity.. While its the future, its not any time soon that should have to do anything with.

    You seem to think that business and non tech people should for some reason have to get this up and running on their networks... While sure if your int a region of the world where the ISPs have a shortage of IPv4 address space, or its too costly for you at this time.. That has zero to do with the current situation in this part of the world..

    Here is what would happen if I enabled IPv6 on this guest network - where all kinds of different devices connect to get to the internet.. Its not working right, its slow, etc. Sorry but not going to deal with that just so can say running ipv6 to cause myself and my users more grief..

    So - as stated, no need for it... Which more than likely is the same boat this guy is in.. So if he as the desire to work through it on his home network.. Sure lets figure it out and get it working.. But there is zero requirement at this point in time..

    So can your client query pfsense IPv6 address for a local fqdn ipv6 address, say pfsense IP? What client is doing the query has zero to do with being able to resolve something upstream - ZERO... not like windows asks the client differently then linux client.. A dns query is a dns query.



  • Almost right -- I agree, certain ISPs seem to be struggling, and, at least some would suggest, they like charging a higher and higher price per static IPv4, but to be fair, IPv6 isn't implemented exactly the same everywhere. Ever try to use IPv6 with android phones or devices? It simply won't work because Google just decided, on its own, it didn't need a DHCP client. Works other places... but not there, and end users have no way to find it, or fix it. The network is just broken and that's it.

    I agree, someday, we'll have actually implement this thing, and I mean all of it, correctly, but ISPs have no incentive and their routers, until they catch fire, are never replaced or updated.

    So, back to the original thread -- why does Pfsnese stop answering DNS queries?


  • LAYER 8 Global Moderator

    I don't think it is, I can shut down my IPv6 HE tunnel and I can still query via IPv6 to unbound and get answers, etc. So what your saying is happening doesn't make any sense at all.. So there is a piece of the puzzle missing..

    Yes resolving stuff upstream from pfsense via a connection that has packet loss on it can and could be sporadic... But that has zero to do with the client talking to unbound be it windows or linux..

    Lets see the query your doing from client on windows and then on linux where one works and the other doesn't... I can turn off my HE tunnel right now and show you resolving still works.. Since unbound could just query for the dns via ipv4 anyway.. Do you have unbound set to only be able to use your HE interface for outbound?



  • @jantypas said in IPv6 and nameservers during IPv6 packet loss:

    Ever try to use IPv6 with android phones or devices? It simply won't work because Google just decided, on its own, it didn't need a DHCP client.

    I am aware of that issue, but it doesn't stop my phone and tablet from working with IPv6 here. However, I do know that it causes some problems for certain businesses that want to use DHCPv6 to assign addresses. I completely fail to understand the reasons given by that guy at Google, as the issues he mention happen with both DHCPv6 and SLAAC. Given that a lot of businesses are going to iPhone for that reason, I think maybe Google should put some pressure on that guy. Perhaps let him know that if he's not capable of making it work, they'll find someone who can. Of course, Android is based on Linux, which has no problem working with DHCPv6.



  • @johnpoz said in IPv6 and nameservers during IPv6 packet loss:

    When you get some major player to say, hey you have to have IPv6 to use this resource is when you will see drive towards actual use.. Where ipv6 is king is mobile devices - because there is a freaking billions of cell phones, etc..
    There is Zero resources that are needed to get to from this network that are only IPv6.. So I have and the users here have ZERO use for it at this time.. Zero!! All it does is cause issues and pain and added work and complexity.. While its the future, its not any time soon that should have to do anything with.

    What about all those who cannot VPN or otherwise connect to their own network, because they can't get a public address from their ISP? There are a lot of those, even in North America. Are they supposed to wait because you don't need IPv6? As for mobile devices, there are more of them in use than there are IPv4 addresses. My carrier uses 464XLAT to provide IPv4 service when needed. Otherwise, it's entirely IPv6.

    As for Comcast, I don't know what their problem is, as so many other ISPs have managed to provide IPv6. Maybe we need to get to the point where failing to properly provide IPv6 support will cost them business.

    BTW, it took a while for IPv4 to get straightened out too. I recall having to use SLIP and 576 MTU with my first ISP. However, I did have a static address back then. 😉



  • I hate to start another thread, but I know.... I still have public ARIN blocks that belong to me, but I can't use them because they're non-contiguous /24s and no ISP will route them. I understand why, but here I have address space I can't use and can't give back or sell.


  • LAYER 8 Netgate

    They should route /24s for you.



  • Sadly no.... first my fault, I should have said announce. My /24s have to be BGP announced from somewhere. And, lots of 24s are bad for the routing tables. I do get that. Also, Big ISPs like Comcast don't actually have to do anything -- they'll tell you that. "You're going to use who else?"


  • LAYER 8 Netgate

    Well, yeah, you'll need BGP. I didn't say they have to, I said they should. I have never had any trouble getting /24s added to ISP BGP filters. Don't expect it on anything short of a dedicated circuit though.


  • LAYER 8 Global Moderator

    Yeah I wouldn't see as an issue if you had actual connection with them... They prob not going to do it if you have the 200 a month "business" connection ;)

    You should also be able to leverage that a colo somewhere, etc.

    While yes selling bigger chunks is easier we just sold off some space - and pretty sure they were would go as low as /24s - how many /24s do you have total? And are you looking to sell all of them off.. I could send you contact I have... We did 3 different deals with them for 3 different chunks of space over the last year.. Went real smooth. Our smallest block was a /19


Log in to reply