IPv6 dhcp6c /48 prefix broken

So at approximately 16:14 today, my ppp session bounced. From this point onwards, the routing of my /48 IPv6 prefix has been non-existent (the /64 prefix is fine; the ppp interface auto-configures itself without issues and pinging the IPv6 world from the router still works using this auto-configured address).

Further investigation shows no acknowledgement from the Zen side for any dhcp6c requests for auto-delegating the /48 to me.

Anyone else seeing the same symptoms? Zen, can you un-break what ever you've decided to break today with regards to IPv6 /48 delegation? Nothing has changed my side.

This may explain why my IPv6 has gone wonky too. I've had a few power cuts and have otherwise been messing around with my network, so I assumed it was due to this.

Looks like it might not have been something I did

Tech support emailed.

I did read somewhere that they have changed the option for how this stuff is configured, that is, it is possible for them to just statically route the /48 directly without the need for the router requesting it (how A&A do things). I'll see if they can configure this for me instead; it will save the antics I currently have to perform (restarting dhcp6c) upon each new established ppp session.

I've got the same problem. Zen's DHCPv6 server is not responding to any requests, so you cannot delegate the /48 prefix. As Zen don't install the route to the /48 until the prefix is delegated, there's no routing to and from the /48.

I spoke to tech support around half an hour ago, who said they had no reports of any outages. They asked me to contact the IPv6 team on [email protected] enclosing any evidence. I will shortly be sending in a packet capture and log extract from my router, showing the problem. I will also point them to this thread.

In reply to a post by David_W:

I will shortly be sending in a packet capture and log extract from my router, showing the problem. I will also point them to this thread.

I've just e-mailed the packet capture, log and problem description to [email protected]. Hopefully this will help in getting the problem sorted out.

Now that IPv6 is a supported service, hopefully Zen will improve their monitoring to detect this sort of problem.

Thanks David. I won't bother emailing the IPv6 team then but I have logged a general support ticket on their system.

As I said in my other post on this thread, I have also taken this opportunity to requested if they can make this a static route so as not to be reliant on dhcp6c for requesting it.

The DHCPv6 server started responding again around 13:15, according to my logs. I've now successfully delegated my /48 prefix, restoring full IPv6 connectivity to my networks.

Yes, looks to be back; session just bounced and its all working again.

Did they say what was wrong?

In reply to a post by mixt:

Anyone else seeing the same symptoms? Zen, can you un-break what ever you've decided to break today with regards to IPv6 /48 delegation? Nothing has changed my side.

Have done at around 13:10 today . I'm not sure why it was missed on our testing, so I'll review that as well.

It was an over zealous ACL which was only meant to be blocking customers from sending RA's to our Gateways. The gateways don't respond to the RAs but it does spam the log files a lot. Will see if we can find out which CPE are doing that. Though they do seem to be making it difficult by sourcing the RAs from fe80::1 with src mac of 00:00:00:00:00:00.

The ACL has now been amended to allow the multicast sourced DHCPv6 messages through, so everything should be back to normal following a PPP session reset.

In reply to a post by mixt:

Yes, looks to be back; session just bounced and its all working again.

Did they say what was wrong?

It would be inappropriate for me to repost the e-mail reply I received at 13:24 verbatim, though it contained the suggestion that the problem was related to a configuration change that was made yesterday. The e-mail said that the issue should now be resolved, and that I should drop my PPP session and reconnect.

In fact, I didn't need to drop the session - my DHCPv6 daemon kept retrying and successfully delegated the prefix at 13:15 without a session drop.