Hello,
Looking to set static IPv6 address(es).
Looking at /etc/network/interfaces - the file suggests I do not to edit it, instead use dietpi-config…
However dietpi-config only has IPv6 on and off..
This post seemed to indicate it was coming DHCPv6 - #8 by MichaIng but maybe it was scrapped?
Is there any future concerns with editing /etc/network/interfaces ? Will my modifications be undone during an update as an example, or worse mess up an update?
Updates should not actually make any changes to the configuration. In case of /etc/network/interfaces, the configuration is only adjusted if you change it yourself via dietpi-config. It might be better to do the IPv6 configuration via drop in and create a configuration file in /etc/network/interfaces.d/.
Thank you.
Out of interest, and get an idea whether such option would be of use for dietpi-config: What is your use case for a static IPv6 address?
Anything that runs as a server should have a static address.. Various DNS servers are made easy to setup with Diet-Pi for a common use-case.
My use-case is that my ISP provides a /124 for IPv6 which is too small for SLACC, but even if they provided a /64 or /56 (or /48), by design, I’d never find the SBC server I’m building. Yes DDNS could work but not needing an external system (and another daemon running) is better in every way. I can just set the AAAA record and be done with it.
Why not using IPv4 within the local network? And a link local address should not change once generated by the operating system
For IPv4 yes. But for IPv6, assigning a static GUA address can break Internet access when your ISP changes the prefix. IPv6 is designed for auto-configuration, and usually does neither require to be set static, nor to use some DHCPv6 client. Everything is automatically configured via SLAAC and RA/ND. Implementing anything else on top of this breaks things, unless you know exactly what you are doing, and why it is necessary in your particular case (which would be a very rare edge case then).
There are 3 kind of IPv6 addresses:
fe80:, and you will find pattern of your MAC address inside it. If for some reason you need to access the device via IPv6 address from LAN instead of via IPv4, try that one. But its routing scope is limited to the very next hop, so even just an additional switch between two peers can prevent access.fc or fd. If you need to access other peers in LAN via IPv6 addresses, and the request must be identifiable as from within LAN by the used IPv6 address (these cannot be globally routed), then ULAs are a way.2001: to 2003: at the moment AFAIK. Those are needed to access the Internet via IPv6, as the other ones are not publicly routable. If you know that the public prefix does not change, it would be possible to assign this statically, but this is pretty uncommon.Usually, for LAN access via IP addresses you’d use IPv4, otherwise local hostnames, so fiddling with IPv6 and messing with its intended automatisms is usually not required, and can break things if you do not know well about it and how your router behaves, about IPv6 prefixes etc.
Sometimes.
My ISP provides me a /124, too small for majority of SLACC implementations.
I have had the same larger prefixes since 2008, in 2021 I received another that is still the same. I haven’t kept track of the smaller ones, /124s and /125s, because they are small, set the hosts and use DNS.
Because we (as networking people) are supposed to be looking forward, IPv6 is 30 years old, do you not feel it is time to start to be using it?
You are assuming I’d be accessing it on the local network?
if your ISP changes the prefix. The server I’m building, I suspect my SD card will die before my IPs need to change.
IPv4 is not obsolete. For local networks, IPv6 has not really much point, overhead, harder to remember IP addresses etc. So within LAN, IPv4 is and will remain the most common protocol. IPv6 was developed to address the limited number of (global) IPv4 addresses, a problem which does not exist within LANs.
Interesting indeed. But shouldn’t your ISP then provide a router/software which supports SLAAC for only the last hex digit? If this is supposed to work at all, Linux surely supports it. However, you can assign a static IPv6 address like that:
cat << '_EOF_' | sudo tee /etc/network/interfaces.d/eth0-ipv6.conf
iface eth0 inet6 static
address 200X:.../124
gateway: fe80:...
_EOF_
The generic fe80::1 might work for the gateway as well. LLAs should be always additionally assigned. This does not collide with /etc/network/interfaces or dietpi-config since it only sets the IPv6 address to static, which is otherwise not defined at all where the interfaces practically falls back to SLACC.
SLACC was originally designed for networks /80 and larger. Eventually it was changed to the /64 for SLACC we have today.
Maybe, or I could just assign the IPs.
Yes. Even on larger sized networks hosts will try and use SLACC addresses for their outgoing data connections when static IPs are set. Daemons can/will listen for incoming traffic on those static IPs but if SLACC is enabled on the network the hosts outgoing traffic will use one of those addresses instead. There is a place to disable that if desired though (as there is with everything).
Force of habit (and my ignorance on how to use the source parameter) I always entered the static IPv6 addresses in /etc/network/interfaces below the IPv4(s).
Full-disclosure on my current project.. I’m adding a SBC and switch inside of another router for out-of-band access. Normally I would use a Raspberry Pi with Raspbian however I can’t get the Raspberry Pi boards to fit so I needed a smaller SBC.. There are an unlimited number to pick from but OS support is always lacking on the ‘knock off’ boards, Diet-Pi is keeping up with updates and not constantly calling-home to Chinese IPs.
I have a static /124 to use for access. With no TLS certificates being issued to FQDNs pointing to the /124, so no public ‘transparency’ logs for bots to scan, that IPv6 block is basically invisible to scanners and bots. My system is secure, but extra layers are always good.
I needed to confirm my changes to files that say ‘you shouldn’t edit this file manually’ at the top wasn’t going to mess up the OS because swapping the memory card is going to need a screwdriver.
The only real problem I have with IPv6 is Cogent peering/routing and apt not falling back to IPv4 if the IPv6 address can’t be reached.
Okay, I wasn’t aware of that. Then the router from ISP should ship with its end of SLAAC disabled and DHCPv6 instead for flexibility. But I agree, then static IPv6 addresses are a better approach for a server system.
Works as well, but breaks when you change network settings in dietpi-config. So a dedicated config file is better.
Calling “home” to our Cloudflare worker if MOTD is enabled in dietpi-banner 
. But Cloudflare has strict own privacy regulations and there are only cumulated access stats available, overall number of requests (since our plan has a limited number of worker requests, after which it passes through to our own server), no individual IPs or such.
But I guess on Chinese vendor Linux distro images, it can be also prevented, adjusting APT, NTP, and DNS servers. As of Great Firewall, Linux/Debian defaults do not always work from there. However, as we converted such images into DietPi in the past, I know how messy those images are, not a priority for those vendors to keep them clean and organized. Hence we consequently generate all our images from scratch since some years, I’ll never provide an image based on any SBC vendor’s Debian images via DietPi website again, and will always recommend to use DietPi or Armbian or official/upstream Debian images (where available) instead.
Until some bots finds it randomly 
. Yeah but what began as workaround for IPv4 address shortage–NATs-- remains an access barrier unless you forward ports. Or otherwise a firewall can do.
As always, unless you know the background/consequences. There is rarely a hard “you must not” like it would automatically break something. But the more tools or automatism touch certain configs, the higher the chance the own customization conflicts. And generally always best to use these drop-in dirs conf.d/*.d that usually exist, to override or extend defaults or otherwise managed configs, which makes it also easier to revert own adjustments, and allows in case DEB packages to upgrade defaults without interactive confirmation: Debian packages leave files in /etc untouched in upgrade if they were manually edited by admins, but will update them if they were never touched, and if the package ships a new version.
Yes, has happened once.. ISP decided to let a third party evaluate customers public facing IPs so they were provided the ranges in use.
After figuring out they were coming from my ISPs network, reported the “abuse” to their NOC, was told pretty quickly what was going on, that it was “harmless”. Requested they not provide any of customer data to an outside organization without explicit permission again.. Shortly after it stopped and hasn’t happened since.
10gbps can send a packet to every IPv4 address in about 4 hours, the same can not be said for scanning IPv6.