Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
My local ISP owns exactly a single /24 IPv4 netblock. They do have a large IPv6 block. They use CGNAT for the IPv4 block out of necessity. They keep saying they intend to offer IPv6 service, but so far have not gotten that off the ground.
But that might be a US-thing. What I can see around my place is the massive use of something that is called DS-Lite. But even with DS-Lite, some ISPs do offer port forwarding for IPv4 via the Port Control Protocol (PCP). Basically, any customer who demands it, is getting a small range of high-ports to open with IPv4. I opted out and am still getting full Dual-Stack for now.
The bigger problem that I am facing is that most network equipment can't cope with the dynamic changing of the IPv6 addresses and prefixes all the time. If your internet connection is having problems, this could be several times a day...
So my conclusion is, use it as much as necessary and as little as possible. -
@JKnott said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
That is entirely the case. My cell phone is an example.
So you are saying that unless you have an IPv6 connection as part of your home Internet connection that your cell phone will not work? That is most certainly not the case. Your phone may be completely IPv6 over the cellular network, but that is immaterial to this entire thread. We never mentioned cell phones even once, and as a user there is zero that you must do in the IPv6 world to make your phone work on the cellular networks. The carriers do all that for you behind the scenes including providing the required IPv4 translation. This thread was about difficulties with IPv6 on a pfSense box for residential Internet connectivity.
I am going to bow out of this discussion gracefully. You are certainly passionate about your cause, but I think you are jousting with windmills here to some degree. Nobody is saying IPv6 is worthless or will never happen. We are simply saying that adoption has been very slow in the wider Internet for a number of reasons, and plenty of ISPs around the planet have either no or a very poor implementation of it currently. For folks affected by one of those issues, lack of IPv6 is not a current show-stopper issue for them.
-
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
U.S. retailer Walmart is one I found, plus amazon.com does not show an IPv6 address via nslookup (at least for me). But www.amazon.com does show an IPv6 address by way of the CDN hosting that domain.
Yep, I get IPv6 on Amazon, but not Wallymart.
I think that is @johnpoz's point. I don't require IPv6 to surf the web. And every user in the world still needs an IPv4 connection to the web in order to access the full web.
If all you're doing is surfing the web here, you don't need it. However, there are some parts of the world where IPv4 is not available at all. If you have it behind CGNAT, have fun trying to access your network, without using some hack. If your ISP doesn't provide IPv6, you can use a tunnel broker, such as he.net, as johnpoz does. When I first got IPv6, it was through a different tunnel broker. Prior to providing native IPv6, my ISP used 6to4 and 6rd tunnels. I've had IPv6 since May 2010.
IPv4 has been inadequate since the day it became necessary to use NAT. NAT, in turn, creates it's own problems, including breaking some protocols. This has resulted in hacks on hacks to get around those problems. For example, VoIP and some games have to use STUN servers to get past NAT. Sticking with IPv4 is crippling the Internet.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Sorry, but what does this have to do with anything we are talking about? You just said in the same paragraph that your phone must have IPv4 access via 464XLAT! Why does it need that? Because there are web sites on the Internet that you cannot access without an IPv4 address available to you -- be that native or some kind of NAT, you must have IPv4.
464XLAT and many other things are hacks made necessary by IPv4 not being adequate to meet the needs of today's world. Major sites, such as Google, Microsoft, etc. support IPv6. As time goes on, more will too, and eventually 464XLAT will not be needed.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
We never mentioned cell phones even once, and as a user there is zero that you must do in the IPv6 world to make your phone work on the cellular networks.
For many people, their phone is their access to the Internet.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
So you are saying that unless you have an IPv6 connection as part of your home Internet connection that your cell phone will not work?
I have never said that. What I have been trying to point out is the world is moving to IPv6 and pretending it isn't is head in the sand thinking.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
You can't just pick a DHCPv6 address scope out of the blue on your side when there is no NAT. What you choose must be recognized and routed correctly by your ISP. An analogy is even if you have a static IPv4 address, you can't just choose any other IPv4 address or subnet you desire on your WAN. You must use the address and subnet provided by your ISP because their end of the connection is routing only exactly what they give you. Similarly, you must use the IPv6 prefix your ISP has assigned on your LAN because there is no NAT. Your ISP expects all of your LAN hosts to be sending and receiving traffic on an IPv6 address from the IPv6 prefix the ISP assigned to your connection. The ISP signals what that prefix is via the "Track Interface" setting.
As has been mentioned in this thread, most ISPs will honor some IPv6 client settings that say "please let me keep this same IPv6 prefix". But not all ISPs will do that, and there are some situations where they need to change the prefix they gave you. In that scenario, if you were using static hard-coded IPv6 subnets on your side, your IPv6 traffic could stop working because the ISP would no longer be routing that prefix for you (since they changed it to a different one on their end). What "track interface" does is help the LAN side of pfSense, and all the hosts there, recognize when (or if) the ISP changes the IPv6 prefix. That triggers all the hosts there to obtain new addresses in the new prefix.
Thanks again for hanging in there - the clouds are parting more. So in reference to your quote above... "IF" I set it to Track Interface and want to setup my DHCPv6 scope on the 2019 AD/DS server - which I have tried before - using the 2001: (that the WAN has on it from my ISP) and the 2601: that is on the LAN side (which comes apparently also from ISP) - neither of them seem to work when going to the TEST IPv6 sites. I get this (see image) - and some severe lag:
If I change everything back to what I was using PRE-AD/DS (where pfSense is doing DNS-Resolver and DHCP/DHCPv6) I will get a score of 19/20 - because apparently my ISP does not give my IPv6 a HOSTNAME.
I even tried the setup like this creating my own fdxx: scope - and still nothing works.
@JKnott said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Your prefix, as assigned by your ISP may be changing. Make sure System / Advanced / Networking / Do not allow PD/Address release is selected. If it is and the prefix still changes, you can use Unique Local Addresses on your LAN, to provide addresses that won't change. You then use those in your DNS.
-
@bearhntr:
I think there may be more than one thing you have incorrect here. You must specify the correct IPv6 prefix AND also specify which of the 16 available /64 blocks you are using. I suspect you are not fully defining the required IPv6 scope in the Windows DHCPv6 server. That scope needs the entire prefix you've been delegated along with a subnet identifier to show which of the sixteen /64 subnets in your /60 prefix is being used on the LAN (and on any other network segments you might have behind your firewall).You stated that your ISP gives you a /60 block with this prefix: 2601:c4:c501:7aa0 {remainder masked}.
Within this /60 block are 16 subnets, each a /64 in size, and the first one of these subnets starts with zero (0) and the last one starts with 0x0f (15). You would need to provide one of those 16 subnets as the "scope" for your Windows AD DHCPv6 server to issue IPv6 addresses from. You would also need to specify the size as /64. Do NOT use your WAN IP address anywhere on your DHCPv6 server in AD. That address is strictly for your WAN, and is not to be used anywhere else. The prefix delegated by your ISP's server is what you need for your internal networks.
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
If you set the scopes properly with the correct /64 subnet masks, then an IPv6 address assigned by your Windows DHCPv6 server will work out to the Internet. But, and this is a big but, the instant your ISP changes your prefix delegation, it will all cease to work again. This is because when the ISP changes your delegated (and thus routed) prefix, the DHCPv6 server scope has to change on your Windows DHCP server to reflect the newly delegated prefix. But there is no automated way for that to happen from the pfSense WAN all the way to the Windows DHCP server on your LAN. That's why with IPv6 prefix delegation (and not a true static IPv6 assignment by your ISP), you are better off letting pfSense do your DHCPv6. That's not the best solution, but when your ISP does prefix delegation it is the easiest route to stable IPv6 connectivity. That's because the DHCPv6 server on pfSense will get automatically updated with the necessary scope when the prefix changes. You can make it work connected differently, but it will require manual intervention on your Windows DHCPv6 server anytime your ISP assigns you a different prefix.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
The last 64 bytes of the IPv6 address that my ISP has give me with the Track Interface - appears to be a SLAAC address - not a DHCP6 address as I would expect - as I see no indication of it being 0-f any place. Instead it has part of the MAC Address in it. This leads me to believe that even though I have set pfSense WAN to be DHCP and DHCPv6 - the Track Interface it doing SLAAC.
RA in pfSense is set to ASSISTED.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
You have elected to mask out some of the prefix your ISP is assigning to you, so I can't give you a complete answer. But you need to put 2601:c4:c501:7aa0 and then whatever section you masked out in your post here as the IPv6 scope on your WIndows DHCPv6 server. There will also be an additional piece of the address that is something between 00 and 0x0f (to denote which of the 16 subnets you are being delegated is used on the LAN).
The last 64 bytes of the IPv6 address that my ISP has give me with the Track Interface - appears to be a SLAAC address - not a DHCP6 address as I would expect - as I see no indication of it being 0-f any place. Instead it has part of the MAC Address in it. This leads me to believe that even though I have set pfSense WAN to be DHCP and DHCPv6 - the Track Interface it doing SLAAC.
RA in pfSense is set to ASSISTED.
This is likely the prefix your ISP is delegating to you: 2601:c4:c501:7aa0::/60
This yields sixteen /64 networks ranging from 2601:c4:c501:7aa0:: to 2601:c4:c501:7aaf::. I put a bold emphasis on the spot where the /64 subnet identifier is located (that 00 - 0xf value I mentioned).
So assuming you were to use subnet "0" for the LAN, your DHCPv6 scope for the LAN would be 2601:c4:c501:7aa0::/64. This would let the DHCPv6 server issue IPv6 addresses in the range 2601:c4:c501:7aa0:0000:0000:0000:0000 to 2601:c4:c501:7aa0:ffff:ffff:ffff:ffff. The next /64 subnet in the prefix you are given would be 2601:c4:c501:7aa1:0000:0000:0000:0000 to 2601:c4:c501:7aa1:ffff:ffff:ffff:ffff. The next one is 2601:c4:c501:7aa2:0000:0000:0000:0000 to 2601:c4:c501:7aa2:ffff:ffff:ffff:ffff, and so on up to 0xf.
You can't directly see the prefix delegated to you, but you can infer it by subnetting out the LAN address because pfSense knows the prefix. Notice on the LAN IPv6 configuration page you have the option, when you enable Track Interface, of entering the prefix subnet (the 00 to 0xf value in your case).
If you want to see the entire DHCPv6 prefix delegation exchange between pfSense and your ISP's server, go to SYSTEM > ADVANCED SETUP and enable the DHCPv6 debug option. Then you can look in the DHCP log under STATUS > SYSTEM LOGS to see the full exchange. There you should find the prefix logged.
A subnet calculator tool such as this one can help you see how the subnetting works: http://www.gestioip.net/cgi-bin/subnet_calculator.cgi.
-
I truly appreciate all the help. I.G.T.F.U. I made all the changes where I think I need to change to use the 2601:c4:c501:7aa0::/64 as a DHCPv6 scope on the server.
Rebooted and A) It killed the STATIC ADDRESS I tried to give to the NIC. I even tried to let the NIC on the AD/DS server grab an address and then set as an exclusion and then the same address as STATIC. Reboot and it goes back to DHCP on the NIC for IPv6. B) Still does not let me pass the tests on the test sites.
I have put pfSense back to the way it was. I will have to figure out some other way to get rid of these DNS errors on the AD/DS server.
-
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
I truly appreciate all the help. I.G.T.F.U. I made all the changes where I think I need to change to use the 2601:c4:c501:7aa0::/64 as a DHCPv6 scope on the server.
Some times it's better to start over from scratch, allowing DHCPv6-PD to do it's thing and using SLAAC on the LAN. I wouldn't bother with a DHCPv6 server, unless you have a specific need for one.
-
@bearhntr:
Windows AD really really wants static addresses for certain things. That is gong to be very difficult in a situation where your IPv6 prefix might change. As I mentioned, there is no way to automate that on the Windows side so that it seamlessly updates the AD DHCP server scopes when your ISP changes your prefix delegation.Using AD with a DHCPv6 server works just fine when you can have a static IPv6 setup such as a tunnel from a broker like Hurricane Electric. I had that setup for several years back when I had a cable company ISP. I had a full DHCPv6 setup on my Windows AD LAN. I had no Android devices, so I was not concerned with compatibility at the time.
I agree with @JKnott here, your life will happier without trying to use a DHCPv6 server. As others have mentioned, there are some devices (looking at you Android) that refuse to use DHCPv6 so those devices would be unable to get IPv6 addresses in your network if you only had DHCPv6 on the LAN.
By the way, your errors above with the "Best Practices Analyzer" indicate that you do not have some things correctly configured in your Active Directory environment -- even IPv4 related things. So, I'm not surprised the DHCPv6 configuration is also not operating properly.
-
@bmeeks said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Windows AD really really wants static addresses for certain things. That is gong to be very difficult in a situation where your IPv6 prefix might change. As I mentioned, there is no way to automate that on the Windows side so that it seamlessly updates the AD DHCP server scopes when your ISP changes your prefix delegation.
If your ISP provides consistent prefixes, your addresses won't change. With SLAAC, devices on your LAN will have one consistent address and up to seven temporary addresses. You point the DNS server to the consistent address. If your AD is used only on the local LAN, then you can configure your network to use Unique Local Addresses, which won't change, no matter what your ISP does.
-
At the top :
@bearhntr said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
ISP is Comcast - and WAN is set to DHCP/DHCP6 (with /60 prefix - confirmed with them for residential this is good) - utilizing Prefix ID '0' My COMCAST WAN IPv6 is 2001:558:6011:a5: {remainder masked} with a 128 prefix The LAN when I use Track - is 2601:c4:c501:7aa0 {remainder masked} with a 64 prefix.
To see and know what happens at the WAN side :
System > Advanced > Networking and check :
and from now on, you can see in the Status > System Logs > DHCP - look for the "dhcp6c" lines, these are from the DHCP client v6 running on your WAN, negotiating an IPv6 WAN and obtained on or more prefixes which can be used for your LAN(s).
I have a line that shows :
2023-10-16 09:03:37.031483+02:00 dhcp6c 6769 IA_PD prefix: 2a01:cb19:beef:a6dc::/64 pltime=600 vltime=1800(My stupid ISP router says it has a /56 for me - for the devices that request prefix, like pfSense. But ... my pfsense only get one /64, 0xdc hex or 220 decimal)
Because dhcp6c obtained only one prefix, I have this choice on my LAN interface :
I can select "0 out of 0" as the counting starts from prefix "0" or 0x00 to 0xff (255). This first prefix isn't 0x00 or 0, but has the number "0xdc" for me.
This prefix is used by the DHCPv6 LAN server so it can hand over IPv6 to devices that request one.
So: first things first : can you see that you (pfSense) obtained a prefix ?
Btw : What I never quit well understood :
My IPv6 LAN : 2a01:cb19:beef:a6dc:92ec:77ff:fe29:392c
Why can't I select / set it to 2a01:cb19:907:a6dc::1
or something like that. Why the random "92ec:77ff:fe29:392c" ?
-
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
Btw : What I never quit well understood :
My IPv6 LAN : 2a01:cb19:beef:a6dc:92ec:77ff:fe29:392c
Why can't I select / set it to 2a01:cb19:907:a6dc::1
or something like that. Why the random "92ec:77ff:fe29:392c" ?It is most probably a SLAAC-address. See this from the online-help of my fritzbox (with vDSL).
The Assign IPv6 address FRITZ!Box randomly option works only if the FRITZ!Box determines the interface ID of your IPv6 address itself via SLAAC (Stateless Address Auto-Configuration). The interface ID is the second component of the IPv6 address. The first component is the IPv6 prefix, which is assigned by the internet provider. The interface ID is derived from the MAC address of the FRITZ!Box in accordance with the EUI-64 method.
-
@Bob-Dig
Ah, yeah, that figures.
But I'm not using a Fritz, but pfSense ;)I wonder : can I static-DHCPv6-MAC-Lease the LAN IP of pfSense itself ??
dit : euh ... what is the DUID of my 4100 igc0 LAN interface ?
-
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
But I'm not using a Fritz, but pfSense ;)
Why LAN-Interface, it is about the WAN. You could look into NPt if you want more than one subnet of IPv6. But to be honest, I haven't understand that fully either.
-
@Bob-Dig said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
@Gertjan said in Why do I have to 'Track Interface' on LAN to WAN for IPv6 to work?:
But I'm not using a Fritz, but pfSense ;)
Why LAN-Interface, it is about the WAN. You could look into NPt if you want more than one subnet of IPv6. But to be honest, I haven't understand that fully either.
Ah, sorry. I haven't read your post close enough, I thought it was about the WAN-interface.
Still it would be SLAAC.
