How Does dynv6 Assign Public Hostnames to Private Hosts?
Updated
dynv6 assigns a public hostname to a private host by combining two things: your current dynamic IPv6 prefix and a stable device identifier (a MAC address or a Host ID). The prefix changes when your ISP rotates it, but the device identifier stays the same, so dynv6 can always rebuild the full address and keep the hostname pointed at it. This works for dynamic IPv4 and IPv6 addresses, and it means you don't need NAT or port forwarding to reach the host.
The core mechanism
An IPv6 network is typically handed to you as a prefix, such as 2001:1234::/64. That prefix can change over time. The lower 64 bits of an address are usually derived from the device itself, so they stay constant.
dynv6 stores the stable part (your MAC address or Host ID) and recombines it with whatever prefix you currently have. The result is a full, routable IPv6 address that the hostname resolves to.
The site gives this exact example:
2001:1234::/64 + 00:80:41:ae:fd:7e = 2001:1234::280:41ff:feae:fd7e
Reading that example:
2001:1234::/64is the current dynamic prefix.00:80:41:ae:fd:7eis the device's MAC address.- The MAC is expanded into an interface identifier using the modified EUI-64 format: the middle bytes
ff:feare inserted, and the universal/local bit is flipped (00becomes02at the byte level, which is why the result shows280:41ff:feae:fd7erather than a literal copy of the MAC).
So the hostname always maps to prefix + device identifier, and only the prefix needs updating when your ISP changes it.
Why this removes NAT and port forwarding
With a public hostname pointing at the host's own IPv6 address, traffic reaches the device directly. There is no address translation step and no inbound port-forwarding rule to maintain, because the host already has a globally reachable address. dynv6's stated purpose is exactly this: "assign public hostnames to your private hosts" so you no longer need to set up NAT and port forwarding.
This is the practical difference from IPv4 setups, where a single public address is shared and you must forward ports to reach internal machines.
How updates get sent
The prefix-to-identifier mapping only stays correct if dynv6 learns your current address. The site lists several update paths:
- REST API
- Update API
- DyDNS API (the classic dynamic DNS update protocol)
- SSH with public key authentication
- DNS updates with TSIG keys
- Webhooks, which can notify external services whenever your IP address changes
Any of these can report the current address, and dynv6 recombines it with the stored device identifier.
What to check before relying on it
- The device identifier must be stable. A MAC address or Host ID that changes will break the mapping.
- Your prefix must actually be delegated to you. The mechanism assumes you receive a routable IPv6 prefix that dynv6 can track.
- It is not built for critical services. dynv6 states it does not offer enterprise-grade DDoS protection or SLAs yet, and advises against using it for critical services.
If your goal is simply to reach a private host at a stable name while your ISP-assigned prefix or IPv4 address changes, this combination of dynamic prefix plus fixed device identifier is what makes it work.