Comcast dropping prefix delegation?
-
OK this helps. When we perform moves and splits for capacity addresses (for IPv4 and IPv6) and prefixes for IPv6 change unless of course you are a commercial static customer. Commercial static customer IP blocks (IPv4 and IPv6) are static across moves and splits. NOTE - commercial static has NOT yet launched, targeting this summer.
One thing that we did find is that after a mode or a split RENEWs for /60s are responded to with a /64. I think this is what folks are seeing. This is a bug in the DHCP server that I believe has been fixed. I need to check on the rollout of the same.
If the router in use does not deactivate the /60 or parts of the same this will properly result in traffic for the same not being routed. Remember the router was just moved from one CMTS to another. The new /64 should be properly routed. I understand this does not to the crux of the issue a /60 is needed/wanted.
Once you have the /64, the best way to get a /60 back is to change the DUID of your DHCPv6 client. This will result in a new DHCPv6 from your router which will in turn be responded to with a /60 (make sure you request a /60 in the DHCPv6 SOLICIT). This is the best self service approach I can offer, otherwise, the only way for me to help is to manually request the deactivation of the target /64 which in turn prevent the same from being RENEWed. The latter has some scaling issues, i.e. you need me to be involved with each and every request.
Let me know if the above does or does not make sense. And more importantly if what I suggested addresses the issue.
John
-
So what it sounds like might be happening is that since pfSense is requesting renewal of a /60, and Comcast is responding with a /64, pfSense is ignoring the /64 (not necessarily a bad practice if you have set up multiple networks using prefix IDs of a /60). Eventually, the /60 lease expires, but pfSense isn't showing that the /60 isn't valid anymore.
So pfSense might need to take action if the IPv6 prefix renewal doesn't complete as expected and/or the lease received previously expires… though it does sound like the root issue here is on Comcast's side, with the server responding with incorrect prefix size.
-
I have not tested this personally, so I am offering my best guess here. I think what you suggest sounds plausible. pfSense should accept what is offered back as part of the renewal even if it is not the same length as what it currently has, this would at least ensure that IPv6 does not entirely disappear. Note the RENEW message that is sent back in this case contains two IA_PDs, one with zero lifetimes (i.e. expiring the same) and one with non-zero lifetimes, the new prefix which is most likely a /64.
The root of the issue is the change of the prefix size here, however, RFC3315 and RFC3633 indicate that this is legal from a DHCPv6 point of view. Trust me the prefix length change was not intentional.
The mechanism, modulo the prefix length change, is how prefix renumbering is triggered, as such we should look into fixing the same.
Let me know what I can do to help,
John
-
So I'm not seeing a /64 in my logs (just the split(s) of the /60 for my sub-interfaces). Digging a bit, I am seeing two different DHCP6 server DUIDs responding. Not sure if that's relevant, though?
John, I'll share my dhcp6c log with you in a PM so you have a bit more context…
-
I might be in a good position to be a test subject for any changes, at least for the next week… Comcast is getting ready for a CMTS upgrade in my area, so there has been maintenance the past few nights. Last night, it looks like my LAN prefix was lost, as my remote smokeping shows it dropping along with WAN addresses at the start of the work, but it never recovered while the WAN side did.
I'll be happy to recover any logs or anything this afternoon when I get home... just let me know what's needed.
-
@JC:
So I'm not seeing a /64 in my logs (just the split(s) of the /60 for my sub-interfaces). Digging a bit, I am seeing two different DHCP6 server DUIDs responding. Not sure if that's relevant, though?
John, I'll share my dhcp6c log with you in a PM so you have a bit more context…
Seeing two ADVERTISE messages one each from two separate DHCPv6 server is correct. The full four message exchange will only complete with one of the DHCP servers. You should not be seeing REPLIES from two DHCP servers.
John
-
@virgiliomi:
I might be in a good position to be a test subject for any changes, at least for the next week… Comcast is getting ready for a CMTS upgrade in my area, so there has been maintenance the past few nights. Last night, it looks like my LAN prefix was lost, as my remote smokeping shows it dropping along with WAN addresses at the start of the work, but it never recovered while the WAN side did.
I'll be happy to recover any logs or anything this afternoon when I get home... just let me know what's needed.
Just to confirm, you have no delegated prefix now? Or you are fully back online? Either way ping me by messenger or email.
John
-
Thanks all for continuing to work on this -I've been in the field a bunch and not able to keep up here but I did want to chime in/confirm with others.
@JC:
I get a /60 again if I force a renew. There's about a 20-25% chance I get the /60 I was using back.
I know there's no guarantee I'll have the same PD for any length of time. What's getting me though, is the PD's route seems to drop silently (and prematurely) on the Comcast side. So IPv6 traffic on my side grinds to a halt until I manually intervene …
The same here for me except always a new /60.
If the router in use does not deactivate the /60 or parts of the same this will properly result in traffic for the same not being routed.
I've also thought this may be an issue for a while. pfSense doesn't seem to know and/or indicate the prefix is dead and the clients still receive the dead prefix. It would be great if -for whatever reason and whatever ISP- the prefix expires/dies etc. that pfSense would indicate that somehow or there would be some way to handle that. It is easy to see and set what prefix information is being requested, but I haven't found a way to easily view the status, that is, to see when or what has been received etc. My old cheap router would show the prefix received and that was handy -if pfSense had some status information regarding the prefix that would be nice. So far all I've done is look at the internal interface addresses -please let me know if there is an easier way to view the prefix info.
Thanks!
-
Just to confirm, you have no delegated prefix now? Or you are fully back online? Either way ping me by messenger or email.
It appears that everything on my end is fine… the lack of a response from my remote smokeping was due to pfSense dynamic DNS not updating the hostname with the new IPv6 address on the LAN side. I hadn't had a chance to look at my box this morning before going to work, so I wasn't sure what state it was in. It does appear that I did get a new /60 without issue this morning, so maybe the DHCP server in my area (northern VA) is fixed and working as it should.
-
Things for me have stabilized quite a bit. No flops since the 15th. Maybe there was extended upgrade and repair work occurring in my area?
Either way, I think I'll stay on my Tunnelbroker connection for awhile. I'm in the same city as the POP, so the latency is very, very good and the routed /48 is nice :)
-
And back to the silent dropping behavior. Guess I'm sticking with Tunnelbroker for awhile.
-
I was just about to post I dropped ipv6 on all but one subnet and started just requesting a /64. I've gone about a week and it is still working. I can't get /60 to work for more than 24hrs and I don't really have time to fuss with it right now.
Hopefully there will be some solution to this before too long.
