Just wanted to post here as I moved to VDSL yesterday, and was delighted to discover that IPv6 is enabled on my connection!

I've been taking a look at it, and thought it might be worth making a couple of points, for Orcon (and in particular a shoutout to Sounddude, who was asking earlier!) as much as anyone else:

 

1. Despite a couple of little problems, it's excellent that Orcon's moving IPv6 support forward - great job!
2. Absolute, definite +1 / double thumbs up on static prefixes for all. In fact, mine hasn't changed since I've been migrated to VDSL, so is this happening already? Apart from the usefulness of being able to allocate a static IP for any device if necessary, it's in the spirit of what was intended for IPv6 deployment in the first place; and obviously devices also allocate themselves random addresses within their subnet, so there won't be any customer perception of increased risk of exposure.
3. At time of writing there appears to be a problem with IPv6 DNS resolution. Orcon's two advertised servers (2400:4800:1::1 and 2400:4800:1:1::1) aren't responding, which will be causing name resolution delays for all IPv6-enabled customers that have machines that prioritise IPv6 (ie recent Windows). Are those two the permanent addresses for IPv6 DNS resolution? Also, dns1.orcon.net.nz and dns2.orcon.net.nz have no AAAA records.

I'm connecting with Orcon's new Genius router for VDSL - the white NetComm NF4V model. Its IPv6 support seems to be confused in general, but in particular there's a showstopping problem that NetComm really must fix urgently:

In the LAN configuration UI for IPv6 (Advanced Setup -> LAN -> IPv6 Autoconfig), there's one tickbox that enables or disables support for both DHCPv6 and RADVD, with no further configuration options available. This will outright break many customers' networks, including mine. For example, in my network I have my own recursive DNS server, and I need to ensure that all clients use it for name resolution - of course this is a common configuration in SOHO environments. There are also a number of other reasons why customers might not want to be forced to use Orcon's DNS servers by default (such as - cough - UnoTelly) and wouldn't want to manually specify DNS servers in the network configuration on their devices. The bottom line is that at the absolute least there needs to be a way to:

 

1. Configure which DNS servers are included in the router's support of option 23 in DHCPv6 and RFC 6106 in RADVD, in the same way that you can change the primary and secondary DNS servers in its support for IPv4 DHCP, including the ability to specify no DNS servers at all;
2. Enable or disable DHCPv6 separately from RADVD;
3. Enable or disable RFC 6106 support in RADVD separate from RADVD in its entirety.

Furthermore, I can't see any legitimate reason why anyone would want to disable RADVD entirely if the router has IPv6 support enabled and a working IPv6 connection. Can anyone think of a reason why this might be a desirable option?

Whatever, this problem means that I'm going to have to disable IPv6 entirely in the router until it's fixed / improved, which is a terrible shame.

Also:

 

1. The Firewall configuration UI (Advanced Setup -> Security -> Firewall) appears to just about work if you're gentle with it (use -1 in the TC field, by the way), but is almost psychotically wrongheaded and desperately needs to be improved. Dealing with it will be a real problem for customers who want to open up particular ports for devices with a static IP.
2. You really ought to be able to specify a static IP address for the router without having to use a ULA address.
3. At one point I saw the router send IPv6 packets that should have been routed internally out onto the Internet (where they were sent back again), but I can't recreate the problem now. Perhaps I was mistaken, or perhaps there's (ironically) a routing bug somewhere - if there is indeed a bug, it would be a major security risk.
4. This isn't related to IPv6, but when WPS is enabled the router appears to allow enrollees to broadcast SSDP messages onto the network. This makes some devices (particularly neighbours' recent Android phones casting about for a WiFi connection!) appear on the network as 'ghost' UPnP devices in Windows, even when they shouldn't have access. The workaround is to disable WPS support in the router. I don't think this presents a particular security risk itself, but could well be indicative of an underlying (and potentially critical) security flaw. Some other routers (presumably using the same code) also exhibit this problem - see here for an illustration.