In reply to a post by ZenUserJP:

In reply to a post by tehdan:

Of course A&A do it the hard way,

<sarcasm> Indeed. 2 days so far unable to get Zen's attempt to work - When I was with A&A it took all of 2 seconds.

The very hard way indeed! </end sarcasm>

The intention is not to make this hard for users. If you are experiencing issues please email the trial email address. We can then look at altering the configuration on your account. Based on investigations to some feedback we have received today, I think it might be possible to have the /48 both routed and available for Prefix Delegation.

I thought I'd previously been unable to achieve this in the lab, but it appears my home connection is actually now running with that form of configuration.

regards,
Brandon.

In reply to a post by hazey_flakes:

In reply to a post by ZenUserJP:

In reply to a post by tehdan:

Of course A&A do it the hard way,

<sarcasm> Indeed. 2 days so far unable to get Zen's attempt to work - When I was with A&A it took all of 2 seconds.

The very hard way indeed! </end sarcasm>

The intention is not to make this hard for users. If you are experiencing issues please email the trial email address. We can then look at altering the configuration on your account. Based on investigations to some feedback we have received today, I think it might be possible to have the /48 both routed and available for Prefix Delegation.

I thought I'd previously been unable to achieve this in the lab, but it appears my home connection is actually now running with that form of configuration.

regards,
Brandon.

I will reply by all means to help you solve the problem sure

Hi Brandon,

For those on Linux, it would seem the dhcp6c daemon is quite naive. If the ppp link drops and reconnects, the daemon does not appear to (by default) re-request the /48 block. A "reload" does not resolve this issue either, so I have had to script a complete "dhcp6c restart" into the ppp script I have custom written, which runs upon detection of a ppp drop/reconnect, that restores the /48 routing in its entirety.

It is subtle issues like this that make me wonder if it is worth just statically routing the /48 and having done with it. But I can work with this either way; others maybe not so well.

Just letting you know.

Edited by deleted (Wed 19-Aug-15 13:24:48)

In reply to a post by mixt:

It is subtle issues like this that make me wonder if it is worth just statically routing the /48 and having done with it. But I can work with this either way; others maybe not so well.

Based on feedback I'm looking at allowing for static routing alongside TR187. However it is likely that CPE will be built to conform with TR187 I want to ensure this works correctly in the first instance. If any of the trialists wish to test the addition of static routing, then I'm happy to attempt it with them.

In theory if the CPE supports it TR187 is the easiest method, the end user almost has no configuration to carry out. On an Asus AC68U , we simply turn on ipv6 native and enable DHCP-PD, all the rest of the configuration is then automatic using the default settings. (well apart from IPv6 firewall which has to be turned on manually).

If we did not use DHCP-PD the user user would have to be aware of their /48 prefix, and know how to subnet this into a /64 for their LAN and configure it into their LAN settings. For technical users this is straight forward. For untechnical home users we assume that they just want to plug and play. NAT in IPv4 actually made this easy for them, a huge number of home users have never considered that they could change their internal subnet away from the default setting.

Edited by deleted (Wed 19-Aug-15 13:54:00)

My connection went over no problems, I just selected auto detect on the router in the ipv6 options.

job done

What router do you have?

What I meant about A&A doing it the hard way is that it requires you to understand networking although yes - they do it in a a straightforward way. The way Zen have gone is obviously designed to let a suitable router be automatically configured. It sounds like your router isn't one of these, so you fall into the 'harder than necessary' category

I agree with you entirely that the best option is a "plug-and-play" setup. I'm not going to request modification of the IPv6 setup you've provisioned me, as I've got it working reliably now, and am quite happy with it.

I hope the trial brings some positive feedback and look forward to this going permanently live over the next year or so (I see no reason why it shouldn't, if the trial proves successful).

Though you do need to decide how reverse DNS delegation is going to work. In my case, it would be easiest if you allowed for delegation of the prefixes to some name servers which I can then configure for this purpose, but I guess for the non-techy users, allowing reverse DNS to be defined via the portal would be acceptable as well (much like you already have for IPv4).

+1 for delegation of name servers for rDNS

+1 for allowing our own name servers to assign rDNS.

Since setup i've had no problems with IPv6. I suspect that OpenWrt supports TR187 out of the box but since i had been using a tunnel i had to reconfigure things myself and can't be 100% sure without doing a reset (which i'll do when 15.05 is officially released).

I'm using RFC 4638 on my connection and haven't experienced any problems with the full 1500 MTU on either IPv4 or IPv6.

I've got multiple subnets and OpenWrt is correctly handing out addresses from multiple /64s of my prefix (wired LAN has a /60 available. The first /64 for clients with the rest available for prefix delegation to any future routers connected).

Most of this stuff was already configured for my HE tunnel and the native IPv6 was a seamless swap. Didn't even need to modify internal DNS since OpenWrt also does ULA and i was using that for internal IPv6 hosts.

a billion 8800nl. i might try and flash the tg582 and use that as it came from aaisp