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!

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.
I've already added it as the backup dns to the asus router for ipv6.
 
Just seems like a lot of work and discussion and troubleshooting to force IPv6 to behave like IPv4..... just use dual stack, IPv4 where you need static IPs on your LAN and dynamic v6 so that you can access the v6 internet.....
 
Just seems like a lot of work and discussion and troubleshooting to force IPv6 to behave like IPv4..... just use dual stack, IPv4 where you need static IPs on your LAN and dynamic v6 so that you can access the v6 internet.....
Still puts me back to needing to update the config files. Wasn't ipv6 supposed to be static? I can access the ipv6 internet if this works or not (That was never the issue).

I'm not looking for ipv6 to behave like ipv4, I am wishing it wasn't behaving like ipv4. I am not a fan of dynamic ipv4 addresses either.

As for work and troubleshooting. It's solved and working. Lots of posts going back years looking for this solution without answers when I was googling, so I am hoping this will help others.
 
Still puts me back to needing to update the config files. Wasn't ipv6 supposed to be static? I can access the ipv6 internet if this works or not (That was never the issue).

I'm not looking for ipv6 to behave like ipv4, I am wishing it wasn't behaving like ipv4. I am not a fan of dynamic ipv4 addresses either.

As for work and troubleshooting. It's solved and working. Lots of posts going back years looking for this solution without answers when I was googling, so I am hoping this will help others.

Your config files just reference your static IPv4 local address, no need to update them when your IPv6 changes.

I.E your have the Asus hand out 192.168.100.x IPs to all machines. Your DNS and any others that need statics, you put reservations in so they always get the same IP.
It also hands out dynamic IPv6 public IPs that your ISP assigns. May change from time to time. Doesn't matter.

Your machines/config files that need to reference an IP just reference the 192.168.100.x IP or the associated hostname.

If you want to have everything use IPv6 the way it was intended, then you need to look into a dynamic DNS provider, and your configs will need to reference the DDNS hostname, which will get updated by a client app running on the machines that need to be "static" anytime their IPv6 IP changes. Or get a static IP range but that will cost extra.

ULA and the FC00::/7 range was designed for networks that don't communicate to the internet at all, just to have a range that can be used in lab environments etc.

There is no reason IPv6 shouldn't be static, other than ISPs not wanting home users to run servers and wanting to be able to charge you extra for static. That's a fight we'll never win unfortunately.
 
Your config files just reference your static IPv4 local address, no need to update them when your IPv6 changes.

I.E your have the Asus hand out 192.168.100.x IPs to all machines. Your DNS and any others that need statics, you put reservations in so they always get the same IP.
It also hands out dynamic IPv6 public IPs that your ISP assigns. May change from time to time. Doesn't matter.

Your machines/config files that need to reference an IP just reference the 192.168.100.x IP or the associated hostname.

If you want to have everything use IPv6 the way it was intended, then you need to look into a dynamic DNS provider, and your configs will need to reference the DDNS hostname, which will get updated by a client app running on the machines that need to be "static" anytime their IPv6 IP changes. Or get a static IP range but that will cost extra.

ULA and the FC00::/7 range was designed for networks that don't communicate to the internet at all, just to have a range that can be used in lab environments etc.

There is no reason IPv6 shouldn't be static, other than ISPs not wanting home users to run servers and wanting to be able to charge you extra for static. That's a fight we'll never win unfortunately.

Other users have used similar methods to ones suggested to you: (e.g.)


There are alternative methods for running script on linux devices such as RPI, that periodically run to check to see if the IP address has changed, and if so, it does the appropriate modifications on the client then and there. However for scripts like this:


The problem with client side updating is that it would have to be configured manually on the router as well.

I can understand the OP's desire to run a ULA address assignment, it is to ensure the whole addressing assignment doesn't get borked between clients and local dns server. In this instance, using a dynamic dns provider would only be benefitial if the user was talking about a cloud based managed DNS solution.
 
Here is my problem, I run a couple local ipv6 services on my lan, and I have a prefix that is dynamic via dhcp. Every time the prefix changes, I need to update several config files and I don't always notice right away which impacts other things.

As I understand it fd00:: or fc00:: were at some point designated local and not global routable, similar to 192.168.*, though may be stuck in some form of red tape ( https://en.wikipedia.org/wiki/Unique_local_address ). I have previously used them in the past (pre asus router) and would like to continue using them. The problem is that the asus router doesn't route them over the lan.

The Router firmware: 386.5_2
The router: RT-AX58U
Is this what you're looking for?
(go check out the References link from that page for perspective...there are some good articles in their "IPv6 CoE" page(s))
our routers can do NPT6, btw...I think a case has to be made to Asus...seems the most efficient/elegant solution
 
Is this what you're looking for?
(go check out the References link from that page for perspective...there are some good articles in their "IPv6 CoE" page(s))
our routers can do NPT6, btw...I think a case has to be made to Asus...seems the most efficient/elegant solution
Again the problem comes in when running something like a local ipv6 DNS service. Take PiHole on an RPI for example, while the RPI may update its own IPV6 address just fine, other clients may not do such right away. Also, what about PI-Hole in this instance, does it readily gain knowledge of the ipv6 address changes, or is there some sort of hinderance going on that creates a "dead-time" between address updates. While I am sure the router is doing its job of updating the dynamic ipv6 address assignment, client side implementations on the other hand may need alittle assistance updating to reduce, eliminate, or prevent the "dead-time" theory. Thus why the OP would like ULA's to not have to worry about the "dead-time" risk. That way the dynamic IPV6 updates will happen unhindered as they should and the user need to be none-the-wiser of the occurrence.
 
Other users have used similar methods to ones suggested to you: (e.g.)


There are alternative methods for running script on linux devices such as RPI, that periodically run to check to see if the IP address has changed, and if so, it does the appropriate modifications on the client then and there. However for scripts like this:


The problem with client side updating is that it would have to be configured manually on the router as well.

I can understand the OP's desire to run a ULA address assignment, it is to ensure the whole addressing assignment doesn't get borked between clients and local dns server. In this instance, using a dynamic dns provider would only be benefitial if the user was talking about a cloud based managed DNS solution.

Nah, local DNS does a lookup to ISP DNS which resolves the hostname back to the IPv6 address of the local machine (via the DDNS provider). Since IPv6 doesn't employ NAT there is no need for separation of local and internet DNS anymore ("DNS on a stick").
 
Nah, local DNS does a lookup to ISP DNS which resolves the hostname back to the IPv6 address of the local machine (via the DDNS provider). Since IPv6 doesn't employ NAT there is no need for separation of local and internet DNS anymore ("DNS on a stick").
While I appreciate you not deviating from your personal narrative, that is if you are referring to the routers local DNS, if the user is running their own DNS server implementation local side (a.k.a. client side), that is completely different. If you are talking about running dns server cloudside (a.k.a. cloud based solution) then I agree about your DDNS strategy. However when we are talking about client side implementations we are still behind a firewall (and possibly client firewalls too). While the remote changes in IPV6 address assignment will be noticeable via DDNS, the address changes client side are not always such. Your IPV6 implementation must be really firing (and working) on all pistons if it does all this for you. Maybe you should post a full tutorial or guide that goes into full details on your methods.
 
While I appreciate you not deviating from your personal narrative, that is if you are referring to the routers local DNS, if the user is running their own DNS server implementation local side (a.k.a. client side), that is completely different. If you are talking about running dns server cloudside (a.k.a. cloud based solution) then I agree about your DDNS strategy. However when we are talking about client side implementations we are still behind a firewall (and possibly client firewalls too). While the remote changes in IPV6 address assignment will be noticeable via DDNS, the address changes client side are not always such. Your IPV6 implementation must be really firing (and working) on all pistons if it does all this for you. Maybe you should post a full tutorial or guide that goes into full details on your methods.

Nope, referring to this specific scenario where the OP is using their own DNS server.

Client machine does a lookup for foo.ddns.com to the local dns server (not the Asus), local server sends that to internet server, internet server looks it up at ddns.com. Ddns.com has gotten updated by the ddns client running on the foo machine and responds with the current AAAA record for that machine.

Yes, the dns still needs a static IP, and in this case that would have to be an IPv4 IP unless you want to pay for static from your ISP. That's the cost of wanting to be IPv6 these days.

This isn't a personal narrative (weird comment), just explaining how it would work, there are much simpler ways to deal with this. The DDNS solution is more complex than it needs to be but for some reason everyone seems to think using v4 on the LAN is some sort of crime, even though we all have to be dual stack for many years to come regardless, so it is already there.

Long story short, if you want to run your own DNS server, you need a static IP. With IPv6, that isn't as simple as it used to be, but there is no reason you can't use IPv4 for your local DNS traffic.

But hey, to each their own.
 
Nope, referring to this specific scenario where the OP is using their own DNS server.

Client machine does a lookup for foo.ddns.com to the local dns server (not the Asus), local server sends that to internet server, internet server looks it up at ddns.com. Ddns.com has gotten updated by the ddns client running on the foo machine and responds with the current AAAA record for that machine.

Yes, the dns still needs a static IP, and in this case that would have to be an IPv4 IP unless you want to pay for static from your ISP. That's the cost of wanting to be IPv6 these days.

This isn't a personal narrative (weird comment), just explaining how it would work, there are much simpler ways to deal with this. The DDNS solution is more complex than it needs to be but for some reason everyone seems to think using v4 on the LAN is some sort of crime, even though we all have to be dual stack for many years to come regardless, so it is already there.

Long story short, if you want to run your own DNS server, you need a static IP. With IPv6, that isn't as simple as it used to be, but there is no reason you can't use IPv4 for your local DNS traffic.

But hey, to each their own.
Short story long, I got a pretty close to static IPV6 "so far". Last time it changed was when I changed hardware(routers). But I have had to venture to the dark side of configurations a couple of times for port forwarding reasons and firewall restrictions/limitations, but that was on a much different setup. Much different hardware. I don't think I will ever want to give up my current setup Merlin firmware.
 
Is this what you're looking for?
(go check out the References link from that page for perspective...there are some good articles in their "IPv6 CoE" page(s))
our routers can do NPT6, btw...I think a case has to be made to Asus...seems the most efficient/elegant solution
I can see why you brought up NPTv6:

1651720374490.png


It is with this mapping that the ULA is beneficial to.

1651720500582.png
 
I can see why you brought up NPTv6:

View attachment 41109

It is with this mapping that the ULA is beneficial to.

View attachment 41110
yeah, it came up on the WireGuard thread(s) and It's filtering through my pipes. I've had a Native v6 from my ISP for a decade or more, so I could be (possibly well, probably too well) ahead of the curve on this -
WireGuard in the linux kernel will likely be more significant as IPv6 supercedes v4, once it's seen to be more than a VPN, and the unbound script here plays nicely beside/in conference with it. Add NPTv6 and you can darned near make like a proverbial puff of smoke on the interwebz - it's privacy and security for everyone using it, practically natively, once you can see past the way it has been done to the way it CAN be done. And this is why
I'm increasingly of a mind that Asus' firmware might potentially be in need of a significant re-vamp, and it'll spill down to us here in Merlin-land...or (more likely) Merlinites will show Asus the path to take (no idea if it'll break or bulletproof AiMesh, one of the main selling features of the hardware currently). I don't have the chops to take it on myself or I would give it a shot...or someone who does needs to straighten out my suppositions here if they're bent.
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

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