Feature Request: Better diagnostics for SLAAC/DHCPv6 client
-
This post is deleted! -
@jknott said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
As for the WAN side, you should do a packet capture to see what's happening.
Users should not have to do packet capture and analysis with Whiteshark to be able to troubleshoot IPv6 on WAN side.
pfSense should offser easier ways to accomplish it. -
Wireshark or Packet Capture are often used when working on problems. For example, a few years ago, I had a problem with my ISP. Through my testing I determined the problem was not in my network. With Wireshark and capturing DHCPv6 I was able to identify, by host name, the failing system at my ISP.
-
@kostrse said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
pfSense should offser easier ways to accomplish it.
What do you suggest.. Sure the developers will get right on it ;)
-
@johnpoz said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
What do you suggest.. Sure the developers will get right on it ;)
When I open DHCP logs, I would want to see the following events:
- Router Solicitation (RS) message sent by the interface
- Interface expecting Router Advertisement (RA) message
- RA message was received and contents of this message including received Router Advertisement Flags, global IPv6 prefix on the link and the prefix length, as well as DHCPv6 and DNS information (or absence of it).
- ...or fact that RA message wasn't received during a given timeout and the interface stopped expecting it.
- A decision to use SLAAC based on information from RA
- A decision to use DHCPv6 based on information from Ra
- Response from DHCPv6 and contents of the response
- ...of fact that DHCPv6 not responding/misconfiguired and decision to fallback to SLAAC etc.
It would allow me to troubleshoot IPv6 handshake without having to use Whiteshark.
-
@kostrse said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
When I open DHCP logs, I would want to see the following events:
Router Solicitation (RS) message sent by the interface
Interface expecting Router Advertisement (RA) message
RA message was received and contents of this message including received Router Advertisement Flags, global IPv6 prefix on the link and the prefix length, as well as DHCPv6 and DNS information (or absence of it).
...or fact that RA message wasn't received during a given timeout and the interface stopped expecting it.
A decision to use SLAAC based on information from RA
A decision to use DHCPv6 based on information from Ra
Response from DHCPv6 and contents of the response
...of fact that DHCPv6 not responding/misconfiguired and decision to fallback to SLAAC etc.It would allow me to troubleshoot IPv6 handshake without having to use Whiteshark.
The client doesn't normally make a router solicitation, except on startup or connecting to the LAN. The RA happens automatically and frequently. So, if you capture ICMP6, you will normally only see 1 RS. Also, you don't normally use DHCPv6. Whether SLAAC or DHCPv6 is used, is determined by the settings and then the client acts accordingly.
Almost everything you're looking for happens on the client, not pfSense, so there's not much it can do there.
-
@jknott said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
Almost everything you're looking for happens on the client, not pfSense, so there's not much it can do there.
Sorry, probably I'm confused. I'm talking about the WAN interface, so in this case pfSense itself is the client and upstream ISP is the router.
Here is my understanding of the process:
When WAN interface is up, first it self-assigns link-local address to itself. After that, using the self-assigned link-local address, it has to send multicast RS and listen for RA in response (probably some upstream routers ignore RS and just send RA periodically all the time, as you stated in your comment).
Only after RA received, WAN interface can extract values from RA to know the IPv6 prefix, flags and decide whether to use SLAAC or DHCPv6.
I suppose that if RA never received (no routers present or message filtered by firewall etc.) then WAN will never get a routable IPv6 address and will stay with link-local address only. If RA received with significant delay, e.g. 5 minutes later, then routable IPv6 address will be assigned only 5 minutes later etc.
My complain is this workflow is not transparent in pfSense. There's no (adequate) logging which would allow to know whether RA was received and what values did it contain (e.g. did router advertise DHCPv6 or not).
Today where's no consistency in support of IPv6 among ISPs. Some ISPs do not support IPv6 at all, some do support but give only /64 prefixes, some give /48 or /60 only if explicitly requested by client via RS message, some just misconfigured and return rubbish configuration. And the IPv6 negotiation workflow itself has many variables with RS/RA/SLAAC/DHCPv6.
That's why I think that pfSense would greatly benefit if it would provide more transparency into the IPv6 address negotiation process.
My knowledge of IPv6 negotiation is based on this article:
https://www.networkacademy.io/ccna/ipv6/stateless-address-autoconfiguration-slaac -
Fire up Packet Capture on the WAN interface, filtering on ICMP6 and let it run for a while. Take a look at what's happening. If your connection is anything like mine, you won't see any RS or RA. The connection, including default route, is set up in the same manner as with DHCP on IPv4. SLAAC is not used on the WAN, at least not with my ISP. so, when you mentioned things like RS, I automatically thought you were referring to the LAN side.
Rule of thumb, WAN side is DHCPv6 and LAN is SLAAC. On the WAN side, you will only see the full DHCPv6 sequence on boot up or connecting to the WAN. Here's how you can capture the full DHCPv6 sequence.
-
@jknott said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
SLAAC is not used on the WAN
It could be used as a wan I guess in a limited fashion - but I am not aware of it being able to do prefix delegation.. So how would pfsense get prefixes to route on networks behind pfsense.
Pretty sure prefix delegation is a dhcpv6 thing..
So his suggestions 5 and 6 seem pretty pointless.
As to what the dhclient logs - as mentioned that is not a "pfsense" thing - they did not write the client. They use the dhclient that you can run on freebsd.
I can see wanting to not have to do whatever, and just read logs or have a system that just works. But there is a whole bunch of ways ISPs are attempting to deploy IPv6, and to be honest many I have ran into just blow to be honest.. Many of them doing odd stuff, and they can do even more odd stuff when they normally control the router they give you, etc.
Expecting pfsense to work with every single isp on the planet without any info on what that isp might be doing is asking a bit much if you ask me. As long as the isp is doing things per the rfcs - then even if doesn't work currently, sure they would be willing to do what they need to do to get it to work.
But actually using network analyzers is part of troubleshooting most things when it comes to networks. They have it built into pfsense under diagnostics.. It is an invaluable tool when it comes to figuring out what exactly is going on by looking at what is on the wire.. Applications like dhclient don't always take into account all things and account for putting that into easy to read log format.
I use packet capture pretty much any time a problem isn't something dead simple. And need to see exactly what is going on. In previous positions in real life work, looked at them pretty much every day.
While me and @JKnott might bump heads now and again related to ipv6, he thinks its here and ready for prime time now. Me not so much, I think its many years out from actually being the main protocol and there is for sure some growing pains still to be had before it gets there. But I do agree with this and taking a sniff and looking to see exactly what is happening.
And he is more than capable of helping you work out what might be going on if he had a sniff to look at.
I personally don't have much use for it - its a play thing currently in my opinion on a home network, or smb. Shoot even many enterprises don't have it deployed yet and not even on an sort of near term road map. It can be a steep learning curve, and change in how things are done and controlled. Most enterprises won't move to it unless there is a significant cost savings involved in doing so. And that is just not the case.
Until there is actually something that I can not get to via IPv4, its not a requirement.. While parts of the world use it more than the US and not saying its not useful - Phone providers love it, it gives them pretty much limitless IPs to work with for deploying millions and even billions of phones. But they also have to provide translation of that to IPv4 since much of the world is not on ipv6, and major players on the net do not even have their resources even available via IPv6, etc.
If your having issues with your current isp and their deployment of IPv6 - Hurricane Electric can be a viable option for allowing you to play and deploy IPv6 on your network. You can get a /48 and easy assign /64s out of that on your local networks. I have been using them for years and years - my previous isp ipv6 was lazy and shoddy at best if you ask me, and my current isp doesn't even support IPv6. So I use HE for all my playing with IPv6..
If your having issues with getting IPv6 working with your isp - prob going to have to get your hands dirty and look at a sniff or 2 ;)
-
@johnpoz said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
he thinks its here and ready for prime time now. Me not so much,
I have been using it for 12 years. There are a couple of issues and they're not with IPv6. A big problem is those who think IPv4 is good enough, even though it requires hacks on hacks to get around the address shortage. The other issue, as has appeared here occasionally, is some ISPs don't know what they're doing. Mine does well on both cable and cell networks.
The big reason for moving to IPv6 is that sticking with IPv4 is holding things back. There are some parts of the world where IPv4 is not available without using CGNAT. I first learned about IPv4 at a local college in spring 1995. Even then I realized IPv4 wasn't adequate. Shortly after, I read about IPv6 in the April 1995 issue of Byte magazine and have been advocating for it ever since.
-
@jknott said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
There are a couple of issues and they're not with IPv6
One being major players not even on it ;) Can you get to amazon to buy something on ipv6 ;)
Like I said bumping heads ;) I agree IPv6 is the future - that future just isn't today... The fact that you have been using for 12 years, and amazon.com isn't even using it yet makes my point exactly..
The fact that isps don't even know how to correctly deploy it is another.. Just saw a thread over on reddit where the isp is handing out /112 prefix to the client..
Part of the problem of the actual transition to it - is the major players not willing to to spend the money on transition unless specifically required.. With the transition of mobile devices to IPv6 you removed some of the pain of growth on IPv4 - there is a thriving business of selling IPv4 space - the bigger companies find it easier to just purchase more IPv4, than spend the time effort and money on transition to IPv6.
Sorry but with the ability to use IPv6 for things that require lots and lots and lots of IPs like phones means we are going to be in a dual stack setup for years and years to come.. Which removes the need for companies like amazon to transition their services. Why should they spend time and effort and money when the system currently works, etc.
So you find companies spending the required effort to alleviate some of their IP pain.. While not doing a full transition.. You won't see major transition to it until the major players say hey as of XYZ date you will not be able to access us on IPv4. Which they will not do because that would cost them money.
So the world is stuck in transition and its going to be for a really really long time.
You know what could hasten the transition - if the RIR like Arin and Ripe and the others started raising the prices of maintaining IPv4 space.. Companies have to pay to maintain their IPv4 space every year.. It cost like 4k a year to maintain a /16 with Arin every year, make that 40k or 400k and you would start seeing companies transition like crazy.. And just keep bumping the price up.. Until IPv4 is gone.
-
Amazon is part of the problem in that they choose not to use IPv6. On the other hand, Google, Facebook, IBM, Microsoft and many others do. There's even one you might have heard of called "Netgate" that supports IPv6. This is not a problem with IPv6. It's a problem with people who are too lazy to get off their butts and do something.
Yes, there are some ISPs that don't do things properly, but that's hardly a new thing. This is just one example, not just in networks, where someone either accidentally or deliberately doesn't learn how to do something properly. By comparison, my ISP, Rogers, has offered native IPv6 for about 6 years and it works well. Same with their cell network. Prior to offering native IPv6, they it via 6to4 and 6rd tunnels for a few years. They saw the future and decided to go with it. Again, it's not a problem with IPv6.
As for phones, IPv6 is mandatory for LTE and later. My cell network is IPv6 only, with IPv4 provided via 464XLAT.
IPv6 has been supported in the *NIX world for a long time and in Windows since XP SP3. The routers that ISPs use from Cisco and others have also supported IPv6 for years. Further Internet2 requires IPv6 support.
Yes, many peope are stuck on IPv4, not because they can't run IPv6 but because they seem to think hack on hack is the solution to the address shortage, instead of moving to IPv6. One thing I have heard of the RIRs doing is requiring an organization to support IPv6 before giving them IPv4 addresses.
BTW, there are some parts of the world, where IPv4 is no longer an option. I read recently about China moving to IPv6 by 2030.
-
@jknott said in Feature Request: Better diagnostics for SLAAC/DHCPv6 client:
It's a problem with people who are too lazy to get off their butts and do something.
No its not - its cost! Plain and simple.. Its not free or even low cost to move to IPv6 for a company.. Their system already works - their is no advantage for them to move, and significant effort, they don't just get some IPv6 space from their RIR and click a button and they are on IPv6 ;)
By 2030 huh ;) yeah ok - they have like some of the top sites on the internet, all of which still not on IPv6..
4 baidu.com 10 taobao.com 11 tmall.comUntil such time there is incentive for them to move, they won't.. The only way to make it advantageous for them to move is for it to save them money.. Until such time its always going to be on their back burner of things to do.. Currently unless you have need of lots of IPs - there is no advantage of supporting IPv6..
Shoot game makers could drive desire for their users to ask their ISP for IPv6 by just saying hey you can't play unless your on IPv6 or you can't do xyz in the game unless you have IPv6 - this could drive the users to either move to an ISP that supports it or demand from their ISP - do they, no.. Why because it would cost them revenue..
Its not laziness slowing the transition - its greed.. The ceo of many of a company could say hey we need to go to IPv6. But he is going to be hard pressed to get the board to sign off on it unless he can show cost savings or some other advantage to make the company money if they do.. Which isn't easy to do..
-
While there is a cost of moving to IPv6, there is also a cost of not moving. For example if a company like Amazon doesn't support IPv6, it will become more difficult to do business in China. Another major ISP and cell carrier is Bell Canada. They don't provide IPv6 to their ADSL connected customers, but they barely provide it to their cell customers (they fail testipv6.com). This means their networks already support IPv6. A reseller that uses Bell's ADSL service, Teksavvy, manages to provide IPv6 where Bell doesn't. It appears most of the work is already done for Bell to provide IPv6 properly and to all customers. Also, years ago, the U.S. government mandated IPv6 for all public facing servers and not too long ago for all network suppliers. So, more and more, those who do not enable IPv6 look like they have their head in the sand.
