BNG gateways don't assign IPv6 when state-full requested (IA_NA opt) with dhcpv6

[#1]

I'm using the wide-dhcpv6-client to request my IPv6 addresses.
Up until just now, I've been setting the ia-na option in the dhcp6c.conf to request a stateful address assignment (presuming that I'm then more likely to get the same address back when I reconnect).  This has been working, but I've found that I don't get an IPv6 address at all from some gateways.
These are the newer bng gateways I think.
Over IPv4, this is showing as the first hop:
[tt]lo0.10.central10.pcl-bng01.plus.net (195.166.130.138)  7.034 ms  7.440 ms  7.426 ms[/tt]
Here's a wireshark dissection of a response from one of the failing gateways when the IA_NA option is set:
[tt]No.    Time          Source                Destination          Protocol Length Info
  1384 1267.607778000 fe80::2a0:a544:7e:8684 fe80::1de6:f018:aba4:f2d6 DHCPv6  142    Reply XID: 0x5a3d9b CID: 000100011ad9159200508d9ce822
Frame 1384: 142 bytes on wire (1136 bits), 142 bytes captured (1136 bits) on interface 0
Linux cooked capture
Internet Protocol Version 6, Src: fe80::2a0:a544:7e:8684 (fe80::2a0:a544:7e:8684), Dst: fe80::1de6:f018:aba4:f2d6 (fe80::1de6:f018:aba4:f2d6)
User Datagram Protocol, Src Port: dhcpv6-server (547), Dst Port: dhcpv6-client (546)
DHCPv6
    Message type: Reply (7)
    Transaction ID: 0x5a3d9b
    Client Identifier: 000100011ad9159200508d9ce822
        Option: Client Identifier (1)
        Length: 14
        Value: 000100011ad9159200508d9ce822
        DUID type: link-layer address plus time (1)
        Hardware type: Ethernet (1)
        Time: Apr 10, 2014 09:40:50 BST
        Link-layer address: 00:50:8d:9c:e8:22
    Server Identifier: 0002000005834a4e31323338323130414642000000000000...
        Option: Server Identifier (2)
        Length: 26
        Value: 0002000005834a4e31323338323130414642000000000000...
        DUID type: assigned by vendor based on Enterprise number (2)
        Enterprise ID: Juniper Networks/Funk Software (1411)
        identifier: 4a4e313233383231304146420000000000000000
    Identity Association for Non-temporary Address
        Option: Identity Association for Non-temporary Address (3)
        Length: 18
        Value: 000000010000000000000000000d00020002
        IAID: 00000001
        T1: 0
        T2: 0
        Status code
            Option: Status code (13)
            Length: 2
            Value: 0002
            Status Code: NoAddrAvail (2)
    Rapid Commit
        Option: Rapid Commit (14)
        Length: 0
[/tt]

[#2]

Hi,
Yeah, I think there's a problem on the new BNG gateways with IPv6, I'll have to check with Paul but I remember him mentioning it the other day as he said he was affected by it too.

[#3]

I get assigned a dynamic v6 prefix from the BNGs, rather than a static one.
Having said that, I do find that on the BNGs I get a lot of radvd v6 errors appearing after a short period of connectivity. v6 seems to stop working and I need to disconnect/re-connect for it to restart.

[#4]

Hi
Yes the BNGs aren't working in quite the same way as the older AG boxes at the moment.
If you are on the trial you are likely to have a static IPv6 prefix which you will get when you connect to any AG.  If you stray onto an BNG you will still get (or should) an IPv6 prefix but I wont be the static one you were assigned in the trial account.  This is a RADIUS issue we know about and are working on at the moment.
There are also some differences in the setup of the BNGs and how they give out addresses.  Technically we have not set them up to give out IPv6 prefixes however they are almost doing it by default so there are still adjustments to be made on those if you aren't getting a prefix at all.
Hope that helps.

[#5]

Thanks for the detail Paul, it's very much appreciated.
I noticed yesterday that the IPv6 prefix on my regular account (connected via BNG01) had disappeared.  I reconnected a couple of times and observed that neither BNG01 nor BNG02 issued a prefix.  I've reverted back to the test account and reconnected to an AG to back onto IPv6.
Doug.

[#6]

There have been some config changes on the BNGs so they won't be giving out IPv6 prefixes now unless its enabled in our radius.

[#7]

That's a real disappointment! 
Was enjoying exploring the implications of switching to IP v6!

[#8]

Unless the prefixes have changed, I am getting assigned a different one still.

[#9]

Sorry Townman, unfortunately there was a bug in the software running on the boxes which was causing quite an issue for us so it needed to be disabled.
@AndyH, if you are getting a static via radius then no I don't believe they have changed however as mentioned in other posts the static prefixes aren't getting applied on the BNGs as we are waiting on a change of our radius code.

[#10]

@ paulmh5 - Ah thanks, sorry misread your previous post. Btw, whatever changes you've made to the BNGs, they seem to have had a positive impact on my latency. I've never had such low latency on them (3-4ms now to bbc.co.uk) and I tried a lot of times jumping around on them. I know the route through BT's network is normally the explanation, but I could never get low latency on them.

[#11]

I think these new gateways still have an issue, I have been on one one for the past few days following a PPP outage, and I noticed my usb stick flashing like crazy in my router, and now I know the reason, the log is been hammered (log is stored on the usb stick).
This is coming up every minute. Also my ipv6 has been down, I just hopped but am still on the new gateways so will hop again.

Aug  7 04:54:30 RT-AC66U: start httpd - SSL
Aug  7 04:54:30 rc_service: dhcp6c-state 17515:notify_rc start_radvd
Aug  7 04:54:30 rc_service: dhcp6c-state 17515:notify_rc start_httpd
Aug  7 04:54:30 rc_service: waitting "start_radvd" via dhcp6c-state ...
Aug  7 04:54:30 radvd[17513]: Exiting, sigterm or sigint received.
Aug  7 04:54:30 radvd[17513]: sending stop adverts
Aug  7 04:54:30 radvd[17513]: removing /var/run/radvd.pid
Aug  7 04:54:30 radvd[17520]: version 1.9.8 started

back on the older gateways and ipv6 is up again, but I Am now seeing the log flooded with these (didnt occur before the ppp outage last week )

ug  7 06:21:14 dhcp6c[1561]: client6_send: transmit failed: Network is unreachable
Aug  7 06:22:08 dhcp6c[16388]: client6_send: transmit failed: Network is unreachable
Aug  7 06:23:11 dhcp6c[1561]: client6_send: transmit failed: Network is unreachable
Aug  7 06:24:06 dhcp6c[16388]: client6_send: transmit failed: Network is unreachable
Aug  7 06:25:03 dhcp6c[1561]: client6_send: transmit failed: Network is unreachable
Aug  7 06:26:03 dhcp6c[16388]: client6_send: transmit failed: Network is unreachable
Aug  7 06:27:00 dhcp6c[1561]: client6_send: transmit failed: Network is unreachable

[#12]

Have you flashed to Merlin 376.44?

[#13]

no given that version has "removed" all the previous ipv6 patches.  I dont blindly flash new software everytime its released, I find asus current approach to firmware to be frank irresponsible, its like alpha software, merlin has even made a post saying their development is too fast and he is going to start skipping their updates.
this isnt a firmware issue, as I didnt change anything my end, all that happened was that this started occuring after the ppp outage suggesting plusnet may have done a reconfiguration of some kind.
dick:quote

[#14]

The Asus update is a massive improvement for IPv6 - it fixes a lot of bugs and corrects some major issues for Comcast customers. It updates radvd to 2.x which is a big change from 1.9.x
That wasn't exactly what Merlin said. Asus have a large development/coding team and are continually introducing new features and re-writing code for half a dozen routers. Merlin is one guy and is not able to keep up-to-date with the Asus development changes.

[#15]

We dont know if they fixed all the bugs merlin fixed (that are now removed).  Their development is focused on the .us market and the comcast fixes broken eu isp's connectivity in earlier firmwares.
Asus keeps making massive changes rapidly. and yes he did say the changes are major and is making it hard for him to keep his own code working with it.
But this isnt relevant here as I am not on that new firmware, I am on the same firmware I was using a week ago when these warnings were not in my log.
What changed was a PPP outage.  I was booted of plusnet' recconected, ipv6 stopped working but I was on bng, I then hopped back to one of the older gateways and now have these in my logs (but ipv6 is online).