Summary

  • An IPv4 allocation can stay in place while the IPv6 source carrying its traffic changes. In RFC 8539, the service depends on the recorded association between them, not simply on possession of an IPv4 lease.
  • The client has qualified freedom to choose its tunnel source. A preferred-prefix hint is not an absolute prohibition, but suitable IPv6 reachability and the provider's binding rules still limit that freedom.
  • Source movement, update frequency and privacy are separate choices. A configuration that improves one can impose costs on the others.

The scarce address is not necessarily the part that moves. A customer can retain an IPv4 lease while changing the IPv6 address from which encapsulated traffic enters the provider's network. That possibility changes what an allocation actually describes. It is both a grant of an IPv4 resource and an association with a location in an IPv6 topology.

This is the particular bargain specified by RFC 8539, published in March 2019 as Softwire Provisioning Using DHCPv4 over DHCPv6. The current official record lists it as a Proposed Standard. A check of its errata query on 8 September 2026 returned no matching errata. Neither designation establishes how any particular provider runs the mechanism.

The interesting question is not whether IPv4 or IPv6 has won. It is who gets to choose the moving part of an IPv4 service, how often that choice can change, and how much identifying information the arrangement leaves behind.

Freedom within a provisioned topology

Dynamic softwire provisioning starts after a suitable IPv6 prefix has already been configured. DHCPv6, router advertisements or another mechanism can supply that prerequisite. The IPv4 lease does not conjure an IPv6 path into existence.

Within that environment, the tunnel source need not be tied to one predetermined edge position. A device elsewhere in the end user's routable IPv6 topology can be the endpoint. This is potentially useful placement flexibility: the device providing the IPv4 service and the device at a particular network boundary need not always be the same box. It is not a promise that a customer can carry the service unchanged to an unrelated provider.

The protocol distinguishes information essential to establishing the tunnel from guidance about where its source should sit. The offered configuration must contain a valid border-relay address. Without it, the client discards the message. The preferred IPv6 prefix is different. It is a hint; if it is absent, invalid or does not match an available prefix, the client can, under the specified conditions, choose another valid prefix of suitable scope.

Those two rules allocate different powers. The provider supplies the relay through which the service is reached, while the client's choice of source has some latitude. Reading every server-supplied preference as a command would overstate the provider's control. Reading the client's latitude as permission to use an arbitrary external address would overstate the customer's freedom.

The selected IPv6 source can already exist or be newly constructed. Any required configuration and duplicate-address detection must finish before the client requests its use. Flexibility therefore means a choice among usable endpoints, not a right to nominate a string and expect the network to make it routable.

One lease, a second piece of state

The server records the source IPv6 address beside the IPv4 lease and the client identifier. The binding lasts with the lease. If IPv6 renumbering changes the appropriate source during that period, the client requests an update rather than assuming that the old association has followed it automatically.

Every acknowledgement carries the source address the server has bound. That field is part of the allocation's meaning. The client must compare it with its own active source; the word “acknowledgement” is not a substitute for reading the accepted state.

This is more than administrative tidiness. Lightweight 4over6, one relevant architecture, places address-and-port translation at the customer side and keeps a subscriber-level binding at the provider's lightweight address-family transition router. Its binding joins an IPv6 address, a public IPv4 address and a restricted port set. The provider uses that association to send inbound traffic to the appropriate endpoint and to validate outgoing encapsulated traffic.

That is not the same as storing every translated application session in the provider's central node. Nor does an IPv4 address necessarily confer the use of every port. Where allocation includes a restricted port set, address availability and usable port capacity are separate constraints.

These distinctions limit a simple claim that dynamic allocation makes scarce IPv4 resources “efficient”. The specification explains mechanisms that can support flexibility and sharing. It does not supply a measured saving, reveal a provider's actual port pressure or prove that application sessions survive every possible reconfiguration. An operator's accounting must connect the resource grant to the state needed to use it.

The provider can govern the pace

Freedom to choose a source does not entail freedom to change it continuously. RFC 8539 permits a server-side minimum interval between source updates. If that optional policy is implemented, the specified default is 60 seconds. A request arriving too early can be silently discarded or acknowledged with the old bound address.

This is not a universal 60-second service guarantee. It is not evidence that every implementation enables the limit. It is a provision allowing the server to decline the requested change without treating an existing lease as an entirely new allocation.

The distinction matters when assessing incentives. Frequent binding changes can create work in a provisioning system; limiting their frequency may protect that system. But a customer forced to change source because of renumbering experiences the same limit as a constraint on restoring useful connectivity. Those are plausible operational interests, not evidence that either participant is behaving improperly.

The source must also be unique across active lease bindings. A new allocation and an update to an existing allocation have different conflict-handling rules. The server cannot simply displace another active association to accommodate the requested source. The client's retry and release behaviour must work with this policy environment, not merely with the timing of its own address changes.

The resulting service is a negotiated combination of resource, location and pace. Describing only the IPv4 lease duration omits two of those dimensions.

Movement is not anonymity

A source address that can move is not necessarily one that stops identifying a customer. RFC 8539 warns that an immutable interface identifier can permit tracking across networks and sessions. It discusses a construction based on an IPv4 address and port-set identifier, drawing on MAP-E's address format. In its stated context, this reveals no additional client information to a server that already knows those allocated resources, and the constructed identifier follows changes to the leased IPv4 address.

That is a limited privacy property, not invisibility. The provider still needs the active association to provision the service. “No additional information” relative to an existing allocation record does not mean “no identifying information”, and an endpoint change does not erase a record already retained.

The broader DHCP anonymity profiles explain why changing a link-layer address alone can fail to prevent correlation when other identifiers remain stable. They also identify operational trade-offs. A returning client may no longer receive the same address; a changed identity can leave an earlier lease marked as occupied while a new address is allocated. Some networks rely on registered identifiers to admit clients at all.

None of this is a requirement to randomize every identifier in a fixed broadband service. The useful lesson is narrower: privacy choices and stable provisioning interact. A subscriber may want predictable assignment on one network and less linkability on another. An implementation that silently conflates those preferences makes the trade-off on the subscriber's behalf.

RFC 8539 also has deployment assumptions. It is intended for dedicated layer-two connectivity per client and does not recommend application over a shared medium. Ingress filtering and validation at the border relay belong to the security context. Source selection is a bounded delegation inside that context, not an unrestricted ability to assert where someone else's traffic should go.

The editorial test is the one Lu Heng sets out in Note 36: explain the operating structure rather than advocate a comforting outcome. Here, dynamic provisioning buys qualified placement freedom. It does not abolish the cost of maintaining associations, the power to limit updates or the privacy consequences of identifiers.