What's new

IPv6 private network address

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

It's been at least 12 hours and going strong. I would have preffered to not use jffs and hope that at some point the ipv6 tab on the router will support an additional ULA.

Looks like for the future, ipv6 prefixes will be dynamic regardless of how they were intended. Things such as power failures, hardware changes, and other disruptions will continue to cause ipv6 prefix reassignments. For me this is roughly every 1 to 2 months. Thanks for the help in no longer needing to update config files after an ipv6 prefix change.

The FreeBSD server grabs both dynamic addresses ipv4/ipv6 from dhcp (via dhcpcd), then appends the fd00::2 by @reboot crontab (at bootup). Assigning fd00::2 earlier had led to some odd behavior such as fd00::2 being dropped, but that would not be related to the asus router.

Here is the working script:

dhcpc-event:
Code:
#!/bin/sh

# two functions to call when needed
_noaddress(){
        /usr/sbin/ip -6 addr add fd00::1/8 dev br0
        logger "ULA IPv6 Address fd00::1/8 not found.. Adding"
}
_addressfound(){
        logger "ULA IPv6 Address fd00::1/8 found.. Skipping"
}

# check to see whether we need to update or just ignore any logging

#DHCP Event Trigger:
case "$1" in
"start")
    continue
    ;;
"bound")
    continue
        ;;
"renew")
    continue
        ;;
"deconfig")
    continue
    ;;
"internal")
    continue
    ;;
*)
    exit 1
    ;;
esac

# run our script

logger "$1 Triggering: DHCPC Event / ULA Status Change"
# this is a bit weird, but if it is true, then we have an address, otherwise we don't
/usr/sbin/ip addr show dev br0 | /bin/grep -q "fd00" && _addressfound || _noaddress
 
It's been at least 12 hours and going strong. I would have preffered to not use jffs and hope that at some point the ipv6 tab on the router will support an additional ULA.

Looks like for the future, ipv6 prefixes will be dynamic regardless of how they were intended. Things such as power failures, hardware changes, and other disruptions will continue to cause ipv6 prefix reassignments. For me this is roughly every 1 to 2 months. Thanks for the help in no longer needing to update config files after an ipv6 prefix change.

The FreeBSD server grabs both dynamic addresses ipv4/ipv6 from dhcp (via dhcpcd), then appends the fd00::2 by @reboot crontab (at bootup). Assigning fd00::2 earlier had led to some odd behavior such as fd00::2 being dropped, but that would not be related to the asus router.

Here is the working script:

dhcpc-event:
Code:
#!/bin/sh

# two functions to call when needed
_noaddress(){
        /usr/sbin/ip -6 addr add fd00::1/8 dev br0
        logger "ULA IPv6 Address fd00::1/8 not found.. Adding"
}
_addressfound(){
        logger "ULA IPv6 Address fd00::1/8 found.. Skipping"
}

# check to see whether we need to update or just ignore any logging

#DHCP Event Trigger:
case "$1" in
"start")
    continue
    ;;
"bound")
    continue
        ;;
"renew")
    continue
        ;;
"deconfig")
    continue
    ;;
"internal")
    continue
    ;;
*)
    exit 1
    ;;
esac

# run our script

logger "$1 Triggering: DHCPC Event / ULA Status Change"
# this is a bit weird, but if it is true, then we have an address, otherwise we don't
/usr/sbin/ip addr show dev br0 | /bin/grep -q "fd00" && _addressfound || _noaddress
From looking at @RMerlin and @dave14305 pull request on the master branch, you may have a more fine tuned method to run this script, strictly as an dhcpv6 event.

Maybe one of the two can clue us in on how this pull request will change the way dhcp event is handled for ipv6

 
It's been at least 12 hours and going strong. I would have preffered to not use jffs and hope that at some point the ipv6 tab on the router will support an additional ULA.

Looks like for the future, ipv6 prefixes will be dynamic regardless of how they were intended. Things such as power failures, hardware changes, and other disruptions will continue to cause ipv6 prefix reassignments. For me this is roughly every 1 to 2 months. Thanks for the help in no longer needing to update config files after an ipv6 prefix change.

The FreeBSD server grabs both dynamic addresses ipv4/ipv6 from dhcp (via dhcpcd), then appends the fd00::2 by @reboot crontab (at bootup). Assigning fd00::2 earlier had led to some odd behavior such as fd00::2 being dropped, but that would not be related to the asus router.

Here is the working script:

dhcpc-event:
Code:
#!/bin/sh

# two functions to call when needed
_noaddress(){
        /usr/sbin/ip -6 addr add fd00::1/8 dev br0
        logger "ULA IPv6 Address fd00::1/8 not found.. Adding"
}
_addressfound(){
        logger "ULA IPv6 Address fd00::1/8 found.. Skipping"
}

# check to see whether we need to update or just ignore any logging

#DHCP Event Trigger:
case "$1" in
"start")
    continue
    ;;
"bound")
    continue
        ;;
"renew")
    continue
        ;;
"deconfig")
    continue
    ;;
"internal")
    continue
    ;;
*)
    exit 1
    ;;
esac

# run our script

logger "$1 Triggering: DHCPC Event / ULA Status Change"
# this is a bit weird, but if it is true, then we have an address, otherwise we don't
/usr/sbin/ip addr show dev br0 | /bin/grep -q "fd00" && _addressfound || _noaddress

Glad you got it working, but why not just give your DHCP server a v4 static IP in addition to its dynamic v6 IP, and let your LAN hosts do lookups using v4? All actual traffic will still be v6 (for endpoints that support it) it's just the DNS resolution that will be v4 (it will still respond with a v6 IP if there is an AAAA record for the host you're looking up).

I'm assuming you have a v4 subnet anyway since not everything out there supports v6, seems less complex to just utilize that.

But whatever works for you.
 
Glad you got it working, but why not just give your DHCP server a v4 static IP in addition to its dynamic v6 IP, and let your LAN hosts do lookups using v4? All actual traffic will still be v6 (for endpoints that support it) it's just the DNS resolution that will be v4 (it will still respond with a v6 IP if there is an AAAA record for the host you're looking up).

I'm assuming you have a v4 subnet anyway since not everything out there supports v6, seems less complex to just utilize that.

But whatever works for you.
Yea, say for example the device is 192.168.1.4, and you want all clients to report to this for dns. If you set 192.168.1.4 as static for that device, you can tell clients to use ::ffff:192.168.1.4 for their ipv6 DNS. Since these are all local addresses, I wouldn't be too worried as about limitations of doing this.
 
And also keep in mind, and someone please correct me if I'm wrong here, if you are running dual stack with ULA addresses the client will prefer ipv4 over IPv6. So when lookups are performed, it will use the A records.
 
And also keep in mind, and someone please correct me if I'm wrong here, if you are running dual stack with ULA addresses the client will prefer ipv4 over IPv6. So when lookups are performed, it will use the A records.
In this instance the ipv6 that has a ula assignment also has a joint slaac assignment so the preference would be null. However it would be the case if only ula assignments were given. Also preference isn't always determined by the type of address, but also by the client doing the request.
 
Yea, say for example the device is 192.168.1.4, and you want all clients to report to this for dns. If you set 192.168.1.4 as static for that device, you can tell clients to use ::ffff:192.168.1.4 for their ipv6 DNS. Since these are all local addresses, I wouldn't be too worried as about limitations of doing this.
Glad you got it working, but why not just give your DHCP server a v4 static IP in addition to its dynamic v6 IP, and let your LAN hosts do lookups using v4? All actual traffic will still be v6 (for endpoints that support it) it's just the DNS resolution that will be v4 (it will still respond with a v6 IP if there is an AAAA record for the host you're looking up).

I'm assuming you have a v4 subnet anyway since not everything out there supports v6, seems less complex to just utilize that.

But whatever works for you.
It's not just the DNS server. That was one example. This FreeBSD box was originally meant to be internet facing. There have been a lot of exploits out last year, and the services I use have not been updated by the maintainers. Thus, the asus router has taken over internet facing duties. It was originally only intended for wifi since I got tired of recompiling drivers/kernels so they would be restricted only to my country and not globally restricted (every restriction, for every country worldwide, applied).

The ffff::192.168.1.2 address doesn't appear to be pingable. I also tried ffff::192.168.1.1 which would be the asus router. The ping goes out, nothing comes back.

I've noticed several threads on random sites going back years looking for a solution to dynamic ipv6 prefixes, and going unanswered. This is a viable solution, but if and when better methods become available, this thread should probably be bumped.
 
It's not just the DNS server. That was one example. This FreeBSD box was originally meant to be internet facing. There have been a lot of exploits out last year, and the services I use have not been updated by the maintainers. Thus, the asus router has taken over internet facing duties. It was originally only intended for wifi since I got tired of recompiling drivers/kernels so they would be restricted only to my country and not globally restricted (every restriction, for every country worldwide, applied).

The ffff::192.168.1.2 address doesn't appear to be pingable. I also tried ffff::192.168.1.1 which would be the asus router. The ping goes out, nothing comes back.

I've noticed several threads on random sites going back years looking for a solution to dynamic ipv6 prefixes, and going unanswered. This is a viable solution, but if and when better methods become available, this thread should probably be bumped.
You would need ::ffff:192.168.1.2, not ffff::,

And you would need to use ping -6
 
You would need ::ffff:192.168.1.2, not ffff::,

And you would need to use ping -6
That would solve so much if it worked. Sent from Linux 5.13.0-40-generic #45~20.04.1-Ubuntu

ping -6 ::ffff:192.168.1.2
PING ::ffff:192.168.1.2:):ffff:192.168.1.2) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
 
That would solve so much if it worked. Sent from Linux 5.13.0-40-generic #45~20.04.1-Ubuntu

ping -6 ::ffff:192.168.1.2
PING ::ffff:192.168.1.2:):ffff:192.168.1.2) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping likely will not work. Try nslookup in interactive mode. Use the server command to point to the ip above. Then test a lookup.
 
ping likely will not work. Try nslookup in interactive mode. Use the server command to point to the ip above. Then test a lookup.
For example:

nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
> google.com
Server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.253.122.139
Name: google.com
Address: 172.253.122.101
Name: google.com
Address: 172.253.122.113
Name: google.com
Address: 172.253.122.138
Name: google.com
Address: 172.253.122.102
Name: google.com
Address: 172.253.122.100
>
 
That would solve so much if it worked. Sent from Linux 5.13.0-40-generic #45~20.04.1-Ubuntu

ping -6 ::ffff:192.168.1.2
PING ::ffff:192.168.1.2:):ffff:192.168.1.2) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
What I usually do is


dig www.google.com @::ffff:192.168.1.2
 
For example:

nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
> google.com
Server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.253.122.139
Name: google.com
Address: 172.253.122.101
Name: google.com
Address: 172.253.122.113
Name: google.com
Address: 172.253.122.138
Name: google.com
Address: 172.253.122.102
Name: google.com
Address: 172.253.122.100
>
That is good see it shows that it can resolve addresses. If anything, I could only see using this to be beneficial if it is done so to be a backup.
 
Last edited:
I have never had a link local ipv6 ip work over a lan with any system
Code:
 ping fe80::1234
for example, returns "ping: sendmsg: Invalid argument" (with -6, and it is able to ping the other ipv6 addresses).
As mentioned above, this varies by application and OS. Windows' ping for example has no problem with this:
Code:
C:\Users\Colin>ping fe80::d898:edc6:fe90:cf5c

Pinging fe80::d898:edc6:fe90:cf5c with 32 bytes of data:
Reply from fe80::d898:edc6:fe90:cf5c: time<1ms
Reply from fe80::d898:edc6:fe90:cf5c: time<1ms
Reply from fe80::d898:edc6:fe90:cf5c: time<1ms
Reply from fe80::d898:edc6:fe90:cf5c: time<1ms

Ping statistics for fe80::d898:edc6:fe90:cf5c:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 0ms, Average = 0ms
Whereas for a typical Linux distro you have to specify the interface, either using -I or a % suffix:
Code:
root@nuc:~# ping -c 4 fe80::a835:b187:2fdc:22b3
PING fe80::a835:b187:2fdc:22b3(fe80::a835:b187:2fdc:22b3) 56 data bytes
ping: sendmsg: Invalid argument
ping: sendmsg: Invalid argument
^C
--- fe80::a835:b187:2fdc:22b3 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1029ms

root@nuc:~# ping -c 4 fe80::a835:b187:2fdc:22b3 -I eno1
ping: Warning: source address might be selected on device other than: eno1
PING fe80::a835:b187:2fdc:22b3(fe80::a835:b187:2fdc:22b3) from :: eno1: 56 data bytes
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=1 ttl=128 time=0.551 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=2 ttl=128 time=0.562 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=3 ttl=128 time=0.465 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=4 ttl=128 time=0.429 ms

--- fe80::a835:b187:2fdc:22b3 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3076ms
rtt min/avg/max/mdev = 0.429/0.501/0.562/0.056 ms

root@nuc:~# ping -c 4 fe80::a835:b187:2fdc:22b3%eno1
PING fe80::a835:b187:2fdc:22b3%eno1(fe80::a835:b187:2fdc:22b3%eno1) 56 data bytes
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=1 ttl=128 time=0.327 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=2 ttl=128 time=0.371 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=3 ttl=128 time=0.374 ms
64 bytes from fe80::a835:b187:2fdc:22b3%eno1: icmp_seq=4 ttl=128 time=0.384 ms

--- fe80::a835:b187:2fdc:22b3%eno1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3053ms
rtt min/avg/max/mdev = 0.327/0.364/0.384/0.021 ms
 
Last edited:
For example:

nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
> google.com
Server: ::ffff:192.168.1.1
Address: ::ffff:192.168.1.1#53
Non-authoritative answer:
Name: google.com
Address: 172.253.122.139
Name: google.com
Address: 172.253.122.101
Name: google.com
Address: 172.253.122.113
Name: google.com
Address: 172.253.122.138
Name: google.com
Address: 172.253.122.102
Name: google.com
Address: 172.253.122.100
>
nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53
> google.com
Server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53

Non-authoritative answer:
Name: google.com
Address: 142.251.41.78
Name: google.com
Address: 2607:f8b0:400b:804::200e
>
 
nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53
> google.com
Server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53

Non-authoritative answer:
Name: google.com
Address: 142.251.41.78
Name: google.com
Address: 2607:f8b0:400b:804::200
>
Also, unless you client doesn't support IPv4, you can just enter 192.168.1.2 in the DNS setting for the client. You don't need to use ::ffff:192.168.1.2. If the client is dual stack, it will still resolve the AAAA records for hosts that have IPv6 address on the DNS server. It doesn't matter if the request was made through IPv4 or IPv6.
 
nslookup
> server ::ffff:192.168.1.2
Default server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53
> google.com
Server: ::ffff:192.168.1.2
Address: ::ffff:192.168.1.2#53

Non-authoritative answer:
Name: google.com
Address: 142.251.41.78
Name: google.com
Address: 2607:f8b0:400b:804::200e
>
So on one of my platforms, I have safe search enforced on the network using unbound. My unbound instance answers queries for a pi-hole that uses it as an upstream. Here is the results from my nslookup to it.


Code:
Looking up www.google.com
nslookup www.google.com ::ffff:192.168.1.14
Server:    ::ffff:192.168.1.14
Address 1: ::ffff:192.168.1.14 RPI1.Family-Network

Name:      www.google.com
Address 1: 2001:4860:4802:32::78 any-in-2001-4860-4802-32--78.1e100.net
Address 2: 216.239.38.120 any-in-2678.1e100.net


Looking up forcesafesearch.google.com:
nslookup forcesafesearch.google.com ::ffff:192.168.1.14
Server:    ::ffff:192.168.1.14
Address 1: ::ffff:192.168.1.14 RPI1.Family-Network

Name:      forcesafesearch.google.com
Address 1: 2001:4860:4802:32::78 any-in-2001-4860-4802-32--78.1e100.net
Address 2: 216.239.38.120 any-in-2678.1e100.net
 
Also, unless you client doesn't support IPv4, you can just enter 192.168.1.2 in the DNS setting for the client. You don't need to use ::ffff:192.168.1.2. If the client is dual stack, it will still resolve the AAAA records for hosts that have IPv6 address on the DNS server. It doesn't matter if the request was made through IPv4 or IPv6.
This wasn't about just DNS. It was a real pain to change all of the config files. I'm not sure the default when something on IPV6 doesn't work should be to go directly to IPV4.
 
This wasn't about just DNS. It was a real pain to change all of the config files. I'm not sure the default when something on IPV6 doesn't work should be to go directly to IPV4.
No, but atleast you would have a fallback for your fallback. What I mean is- I found a couple of times back when I used a ULA script on asuswrt-merlin, that sometimes the ULA address would disappear as if somehow there was an event that took place that was unaccounted for in the DHCP-event script. or may be the ULA address didn't stick when the event did occur. It is hard to explain, but maybe you could use the ::ffff:192.168.1.2 (or 192.168.1.2) as a backup to your backup.
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top