Learn › RHCSA (EX200) › Basic Networking
nmcli - a hands-on Linux lab on a real virtual machine.
Add an IPv6 address to a connection with the same nmcli you used for IPv4, just the ipv6. keys. Pick the method with ipv6.method (auto for SLAAC, manual for a static address, disabled to turn it off), set a static address and gateway with nmcli con mod NAME ipv6.method manual ipv6.addresses 2001:db8:0:1::10/64 ipv6.gateway, run both stacks on one connection for dual-stack, apply with nmcli con up, and verify on the live link with ip -6 addr. Serves EX200 basic-networking: configure IPv4 and IPv6 addresses and hostname resolution.
A task lands on your desk: the new service must answer on IPv6. You set up the IPv4 side an hour ago, muscle memory by now. But this is IPv6, and the address looks nothing like the dotted numbers you know. It reads 2001:db8:0:1::10, all colons and hex, with a mysterious :: in the middle. You know the connection is called demo. You just do not know how to bolt an IPv6 address onto it.
IPv6 is not a different tool. It is the same nmcli, the same connection, the same three-step rhythm you used for IPv4. Only the property names change: ipv6.method, ipv6.addresses, ipv6.gateway instead of their ipv4.* twins. This lesson takes a connection from no IPv6 at all to a working static IPv6 address living side by side with its IPv4 address on one connection, then verifies it. It is a named EX200 objective, and it is far easier than the strange-looking address makes it seem.
The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2). The IPv6 work was done on a throwaway dummy0 interface, connection name demo, so a live link is never touched. On your machine the connection and interface names will differ, so read demo and dummy0 as stand-ins for whatever a task hands you. What is stable everywhere is the SHAPE: nmcli con mod sets a property, nmcli con up applies it, and ip -6 addr shows the result.
nmcli is the command-line front end to NetworkManager, the service that owns every network connection on a modern RHEL box. Think of NetworkManager as a filing cabinet of connection profiles, one folder per connection, each folder holding the address, the gateway, the DNS servers, and whether to come up at boot. nmcli is how you open a folder and edit what is inside.
You already met the IPv4 side of that folder: ipv4.method, ipv4.addresses, ipv4.gateway. IPv6 lives in the very same folder, under a parallel set of keys that start with ipv6. instead. Nothing about the workflow changes. You edit the same connection profile; you just reach for the ipv6.* keys.
The world ran out of IPv4 addresses years ago. IPv6 is how the internet keeps growing, and a large share of real traffic already rides on it. When a task says a host must be reachable over IPv6, or must run dual-stack (both IPv4 and IPv6 at once), the fix is an ipv6.* block on the connection.
There are three ways a connection can get its IPv6 address, and ipv6.method picks which. auto means the network hands the address out automatically over SLAAC, the IPv6 equivalent of asking the room for an address. manual means you type a fixed static address yourself, the choice for servers that must never move. disabled turns IPv6 off on that connection entirely. The exam almost always wants manual: a known, static address you set by hand.
SLAAC stands for Stateless Address Autoconfiguration. You do not need to memorize the acronym. Just hold the three method values: auto (the network assigns it), manual (you assign it), disabled (no IPv6 here). When a task hands you a specific address to use, that is your signal to choose manual.
Here is the whole move in one command. nmcli con mod modifies an existing connection. You name the connection (demo), then set three ipv6.* properties in a row: ipv6.method manual to switch it to static, ipv6.addresses with the address and its prefix length, and ipv6.gateway with the router.
The address is 2001:db8:0:1::10/64. The /64 is the prefix length, IPv6's version of a netmask: it says the first 64 bits name the network and the rest name this host. The 2001:db8:: range is the documentation range, reserved for examples, which is why it is safe here. Modify the connection:
nmcli con mod demo ipv6.method manual ipv6.addresses 2001:db8:0:1::10/64 ipv6.gateway 2001:db8:0:1::1
prompt: [root@servera ~]# answer: nmcli con mod demo ipv6.method manual ipv6.addresses 2001:db8:0:1::10/64 ipv6.gateway 2001:db8:0:1::1 output: hint: One command, three ipv6 properties: nmcli con mod demo ipv6.method manual ipv6.addresses <addr>/64 ipv6.gateway <router>
No output, and that is success: nmcli con mod is silent when it accepts your changes. In one line you set three things on the demo folder: the method is now manual (static), the address is 2001:db8:0:1::10/64, and the gateway is 2001:db8:0:1::1. Note what did NOT happen: the IPv4 settings on this same connection are untouched. You edited only the ipv6.* keys, so the connection now carries both stacks. One catch, though: a con mod writes the profile to disk but does not apply it to the running link yet. That takes one more step.
nmcli con mod edits the saved profile; it does NOT touch the live connection until you bring it up. The classic exam mistake is to set the address, check ip -6 addr, see nothing, and panic. The address is saved but not applied. After any con mod, run nmcli con up demo to reload the profile onto the interface. Set, then bring up. Every time.
Before applying, read back what you just wrote. nmcli con show demo dumps every property of the demo connection, dozens of lines. To see only the IPv6 lines you filter for them, but here you can read the three that matter directly. Each line is a property name, a colon, and its value.
Confirm the IPv6 block you just set:
nmcli con show demo
prompt: [root@servera ~]# answer: nmcli con show demo output: ipv6.method: manual ipv6.addresses: 2001:db8:0:1::10/64 ipv6.gateway: 2001:db8:0:1::1 hint: The profile dumper is nmcli con show, then the connection name: nmcli con show demo
Three lines confirm the edit took. ipv6.method: manual says the connection is static, not auto. ipv6.addresses: 2001:db8:0:1::10/64 is the exact address and prefix you set. ipv6.gateway: 2001:db8:0:1::1 is the router. This is the profile as saved on disk, the source of truth for what NetworkManager WILL do. It is not proof the address is live on the interface yet, which is a separate check with a separate tool. Read con show to trust the profile; read ip -6 addr to trust the link.
The profile is written; now push it onto the running interface. nmcli con up demo brings the connection up, reloading its saved settings, including the fresh IPv6 block, onto the actual link. This is the step people forget, and it is the difference between a saved address and a working one.
Apply the connection:
nmcli con up demo
prompt: [root@servera ~]# answer: nmcli con up demo output: hint: The activate verb is up: nmcli con up demo
On a real interface nmcli con up prints a one-line confirmation naming the activated connection. The point is what it does: it reloads the demo profile, IPv4 and IPv6 both, onto the live link, so the static IPv6 address you saved is now bound to the interface. Now, and only now, will ip -6 addr show your address. The full rhythm is three beats: con mod to set, con up to apply, then a verify. Never trust a network change until you have applied and verified it.
nmcli con show proved the profile; ip -6 addr proves the running interface. The ip command reports what is actually bound to your network devices right now, and the -6 flag narrows it to IPv6 addresses only. Point it at a device to see just that device's IPv6 addresses.
The most reliable device to inspect is lo, the loopback, which every Linux box carries. Its IPv6 address, ::1, is the IPv6 version of 127.0.0.1. Read the loopback's IPv6 address:
ip -6 addr show lo
prompt: [root@servera ~]# answer: ip -6 addr show lo output: inet6 ::1/128 scope host noprefixroute hint: The live-address reader, IPv6 only: ip -6 addr show <device>
The line inet6 ::1/128 scope host is the loopback's IPv6 address, present on every machine. inet6 marks it as an IPv6 address, ::1 is the loopback itself, and /128 is a full-length prefix meaning this one exact address. On a real configured device you would instead see your 2001:db8:0:1::10/64 here, which is how you confirm the address went live. ip -6 addr is the truth about the link; if the address you set does not appear, you forgot the nmcli con up.
The loopback address ::1/128 is identical on every Linux machine, so your output for lo will match this exactly. Your real connection names, interface names, and the actual IPv6 address a task assigns will all differ. Read the SHAPE: inet6, then the address, then the prefix, then the scope. That shape is the same whether the address is ::1 or the 2001:db8: one you set.
Scaffolding off. No command is printed this time. You have every piece you need.
You just ran nmcli con mod demo ipv6.method manual ipv6.addresses 2001:db8:0:1::10/64 and nmcli con show demo confirms the profile is correct. But ip -6 addr shows the address is not on the interface yet. The profile is saved to disk but has not been pushed onto the running link. Which single command reloads the demo connection's saved settings onto the live interface so the new IPv6 address goes active?
prompt: [root@servera ~]# answer: nmcli con up demo output: hint: It is the activate step of the rhythm, not another mod. The verb is up: nmcli con up demo.
nmcli con up demo reloads the saved demo profile onto the live interface, and the static IPv6 address you set becomes active. con mod had only written the change to disk; con up is what applies it. This is the beat everyone drops under exam pressure: they set the address, look, see nothing, and forget they never applied it. Set with con mod, apply with con up, verify with ip -6 addr. Three beats, every time.
You earned this cheat sheet. Every row is a form you just ran or built:
The one thing to burn in for the exam: IPv6 is the same connection as IPv4, just the ipv6.* keys. Set both stacks on one connection for dual-stack. And always finish with nmcli con up, or the address is saved but not live.
You can chain every ipv6.* property into a single nmcli con mod line, exactly as you did above: method, addresses, and gateway in one command. Because you are only touching the ipv6.* keys, the connection's existing IPv4 settings survive untouched, and the result is a clean dual-stack connection carrying both an IPv4 and an IPv6 address at once. One connection, both worlds.
The practice terminal has walked you through the whole IPv6 loop. nmcli con mod set the method, address, and gateway in one line. nmcli con show read the saved profile back. nmcli con up applied it onto the live interface, and ip -6 addr proved the address went live. Every one of those you typed yourself.
Operation Uplink is where you run these against a real RHEL 10 machine. A full VM boots for you, with real connections and interfaces waiting to be configured. The mission hands you objectives that use exactly what you practiced here. Bring a connection up with a static IPv6 address, run it dual-stack alongside its IPv4 address, and verify the result on the link. One difference from this lesson: the mission shows no commands. You read the objective, recall the ipv6.method, ipv6.addresses, and con up forms, and type them. That recall is what makes it stick on exam day.
Finish the other basic-networking lessons, then take on Operation Uplink and configure IPv6 on a real machine.
Practice IPv6 Addresses with nmcli in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.