IPv6 with Prefix Delegation

[threepwood]

Hi, quick question: is it possible or planned as a feature to set the prefix length for an IPv6 DHCP-PD connection? My ISP requires me to set the prefix length to 56 in order for IPv6 to work flawlessly.

In Tomato firmware I just set it as:

And it works well. But in AsusWRT - afaik - there's no way to set the prefix length for this type of IPv6 setting. If I just set it at DHCP with PD enabled the connection becomes slow and unstable and IPv6 goes on and off regularly.

Thanks for the help.

 

[RMerlin]

Hi, quick question: is it possible or planned as a feature to set the prefix length for an IPv6 DHCP-PD connection? My ISP requires me to set the prefix length to 56 in order for IPv6 to work flawlessly.

In Tomato firmware I just set it as:

And it works well. But in AsusWRT - afaik - there's no way to set the prefix length for this type of IPv6 setting. If I just set it at DHCP with PD enabled the connection becomes slow and unstable and IPv6 goes on and off regularly.

Thanks for the help.

I'm not sure if it will work, but try setting it over ssh:

nvram set ipv6_prefix_length=56
nvram commit
reboot

Let me know if that works.

 

[threepwood]

Tried that but no dice.

After I ran the first 2 commands, I did an "nvram show | grep ipv6" and ipv6_prefix_length was set to 56. I then rebooted the router and after trialing and checking that IPv6 wasn't available I ran the same command but the ipv6_prefix_length seems to have been reset to 64 automatically.

I didn't change any settings at all, just did as you suggested.

Don't bother yourself with this, I know that IPv6 issues are very hard to diagnose and its not a feature I require at all at the moment.

Thanks for the help anyway.

 

[buddyp]

you can fix this with a startup script

asuswrt uses odhcp6c to pull the WAN IPv6 address and prefix. You can fix this problem using a jffs script to kill the odhcp6c that is running with the default prefix length and restarting it with the length you need.

The script should go something like this:

#!/bin/sh

/usr/bin/logger -t $(basename $0) "started [$@]"

touch /tmp/000-wan-start

date >> /tmp/000-wan-start

killall odhcp6c
odhcp6c -df -P56 -R -p /var/run/odhcp6c.pid -s /tmp/dhcp6c -N try -c <hex client id> -r23 -r24 -r82 -r83 -l7 eth0

/usr/bin/logger -t $(basename $0) "finished [$@]"

Use an editor to paste this code into /jffs/scripts/wan-start. After you save the file

chmod 755 wan-start

to make it executable.

You can find the <hex client id> to use by typing

ps www|grep odhcp6c

 

[threepwood]

Unfortunately that doesn't seem to work too.

Doing a 'ps www|grep odhcp6c' after creating the script and rebooting doesn't even return the client id anymore, seems like odhcp6c isn't being loaded?

On the System Log/IPv6, I now get this (replaced the address with xxx):

IPv6 Connection Type: Native with DHCP-PD
              WAN IPv6 Address: 
              WAN IPv6 Gateway: 
              LAN IPv6 Address: /0
   LAN IPv6 Link-Local Address: xxx::xxx:xxxx:xxxx:xxxx/64
                       DHCP-PD: Enabled
               LAN IPv6 Prefix: /0
                   DNS Address:

I'm also getting the same error message non stop on the log:

"dnsmasq-dhcp[476]: no address range available for DHCPv6 request via br0"


Custom JFFS scripts are enabled, the script was set to executable and placed in /jffs/scripts.

 

[threepwood]

Great news everyone! (or not)

After formatting JFFS and rebooting, as I was about to also disable IPv6, I saw that I now had a valid IPv6 address with a /56 prefix. How is this possible?

I even telnet'ed to see if the JFFS wasn't formatted and the script was still lying around but fact of the matter is that ain't there anymore. Plus the custom scripts setting was auto-disabled after the format.

Could this be explained by a sudden change on the ISP side?

 

[microchip]

Great news everyone! (or not)

After formatting JFFS and rebooting, as I was about to also disable IPv6, I saw that I now had a valid IPv6 address with a /56 prefix. How is this possible?

I even telnet'ed to see if the JFFS wasn't formatted and the script was still lying around but fact of the matter is that ain't there anymore. Plus the custom scripts setting was auto-disabled after the format.

Could this be explained by a sudden change on the ISP side?

Do you happen to have Comcast? If so, Comcast's IPv6 is flaky, from what I've read

 

[threepwood]

Do you happen to have Comcast? If so, Comcast's IPv6 is flaky, from what I've read

No, I have a portuguese ISP (Meo). I'll report in a few days concerning stability of my connection with IPv6 enabled.

Thanks for the help RMerlin and buddyp.

 

[buddyp]

Great news everyone! (or not)

Could this be explained by a sudden change on the ISP side?

Possibly. Are they just rolling out IPv6? If so, it seems reasonable that things might be in flux on their side.

FWIW, I made the claim that asuswrt used odhcp6c because it was running on my router, which has native IPv6 checked in the webui, even though it doesn't have native IPv6. I run a sixxs tunnel at home for IPv6 and in the process of getting it setup I checked that box, because that made some magic happen that makes dnsmasq act as a DHCPv6 server and send out Router Advertisements on my LAN. So, I just looked again and see that I have the PD box unchecked in the webui, so apparently asuswrt only uses odhcp6c if you don't have PD enabled.

I'm familiar with PD because I went through that fight at my beach house where we have comcast (which uses PD), but I run OpenWRT there and I used the WIDE dhcpv6 client, as that was way better documented than odhcp6c - as far as I can tell the only documentation for odhcp6c is the source code.

Anyway, sorry I sent you on a wild goose chase, and I'm glad you got it working.

 

[buddyp]

Do you happen to have Comcast? If so, Comcast's IPv6 is flaky, from what I've read

That's probably based on customers that lived through the roll-out. I imagine that was painful.

I've had comcast IPv6 at the beach since last spring (10 months) and the only time my IPv6 address has changed is when I replaced their cable modem/router with one I bought. When I did that I got new IPv4 and v6 addresses, and not even with the same prefixes. Strange.

There was one IPv4 outage when our prefix was hijacked by some bad guys from russia and our prefix was blackholed by a lot of networks for a short time, but that's been it as far as I can remember.

Don't get wrong - even though I've not had any problems with comcast in recent times, I still think they are evil. We had them at home back in the days before fios and every time it rained, snowed or the wind blew the network went down. Of course, VZ is evil too

 

[MFM000]

I'm not sure if it will work, but try setting it over ssh:

nvram set ipv6_prefix_length=56
nvram commit
reboot

Let me know if that works.

New IPv6 user on AC66U running 380.62. ISP(Cox) says "you can get /56 or /60 if you send a hint with the DHCP request".

Used SSH to set and verify the parameter ipv6_prefix_length=56 in nvram and committed.

However, the parameter value reverted to 64 after a reboot so the above is not persistent.

For me, dnsmasq.conf in /tmp/etc gets overwritten and I'm not a good enough Linux user to see how it gets created.

Is there a .conf file somewhere to be edited (easy now with nano - thanks!) for a persistent reconfig?

 

[IsaacFL]

Did anybody ever figure out how to get a different size prefix?

I still see the behavior noted above. I tried the:

nvram set ipv6_prefix_length=60
nvram commit
reboot

but it always got set back to 64 after reboot.
the gui config page does not let me alter the LAN Prefix Length value.

I know that my ISP will give me a /60 if I ask for it. I set up an opnsense machine temporarily and I can see it can get the /60 from the ISP (TW/Spectrum)

I did not try the script suggested above yet, cause I couldn't see that it worked for the OP.

 

[DigitizedMe]

Did anybody ever figure out how to get a different size prefix?

I still see the behavior noted above. I tried the:

nvram set ipv6_prefix_length=60
nvram commit
reboot

but it always got set back to 64 after reboot.
the gui config page does not let me alter the LAN Prefix Length value.

I know that my ISP will give me a /60 if I ask for it. I set up an opnsense machine temporarily and I can see it can get the /60 from the ISP (TW/Spectrum)

I did not try the script suggested above yet, cause I couldn't see that it worked for the OP.

Hey @IsaacFL , I was able to get this working with some slight modifications. I'm no expert, maybe of trial and error. I'm on Spectrum (legacy TWC).

Before modifying anything, I ran the command "ps www|grep odhcp6c" to see what options the built in odhcp6c command runs at startup. It was a little different than the script above. There is an "-FP 0:00000" command and no "-p" or "-l7" option. Also, I added -k.

My command line in the wan-start script ended up something like this:
odhcp6c -df -P56 -R -s /tmp/dhcp6c -N try -c <hex client id> -FP <0:00000> -r23 -r24 -r82 -r83 -k eth0

I inserted some sleep time between the date insertion and killall commands in the script as well, just experimenting to see what works best. I'm not even sure if the 000-wan-start is necessary since I can comment it out and it runs fine. If I don't understand something, I leave it.

I've tried experimenting with requesting >56 PD. If I try anything more than 56, I won't get a prefix at all.

 

[IsaacFL]

Hey @IsaacFL , I was able to get this working with some slight modifications. I'm no expert, maybe of trial and error. I'm on Spectrum (legacy TWC).

Before modifying anything, I ran the command "ps www|grep odhcp6c" to see what options the built in odhcp6c command runs at startup. It was a little different than the script above. There is an "-FP 0:00000" command and no "-l7" option. Also, I added -k.

My command line in the wanscript ended up something like this:
odhcp6c -df -P56 -R -p /var/run/odhcp6c.pid -s /tmp/dhcp6c -N try -c <hex client id> -FP <0:00000> -r23 -r24 -r82 -r83 -k eth0

I inserted some sleep time between the date insertion and killall commands in the script as well, just experimenting to see what works best. I'm not even sure if the 000-wan-start is necessary since I can comment it out and it runs fine. If I don't understand something, I leave it.

I've tried experimenting with requesting >56 PD. If I try anything more than 56, I won't get a prefix at all.

No, the Asus doesn't support subnetting, which is what is required for a prefix that is not /64.

 

[DigitizedMe]

No, the Asus doesn't support subnetting, which is what is required for a prefix that is not /64.

I suppose I should have checked that before I got the /56 PD from Spectrum....

 

[L&LD]

No, the Asus doesn't support subnetting, which is what is required for a prefix that is not /64.

I suppose I should have checked that before I got the /56 PD from Spectrum....

What it doesn't support is showing a subnet larger than /24 in the network map.

Experimenting may be required to discover what else is hard-coded to /24 too.

It may even end up working, with some limitations.