This document defines the current address-selection and address-claim behavior of MTRP.

This document describes:

• local node address selection
• dynamic address claiming
• conflict detection and response
• address-state progression

Each MTRP node operates with:

• a local node identifier
• a network identifier
• a device or claimant identity value used during conflict handling

The local node identifier is the address used for MTRP routing and delivery behavior.

The implementation currently uses the following address states:

At startup, the router attempts to ensure:

• a local device identity
• a local network identifier
• a local node address

If a valid local address is already known or recovered, the node MAY proceed directly to the claimed state.

If no valid local address is available, the node enters address-selection behavior.

When selecting an address, the node chooses a candidate node identifier.

A candidate SHOULD NOT be selected if it is already known to be in use according to currently visible local protocol state.

A node in the claiming process transmits an ADDRESS_CLAIM control message for its candidate address.

The claim includes:

• candidate node ID
• claimant identity

The claim process MAY be repeated according to local timing and retry policy.

A conflict exists when two distinct claimants contend for the same candidate node identifier.

Conflict detection may occur when:

• a node receives an ADDRESS_CLAIM for its current candidate
• a node receives an ADDRESS_CONFLICT targeting its claimant identity
• local state indicates an already-claimed conflicting address

When an ADDRESS_CLAIM is received, the router evaluates:

• the candidate node ID
• the claimant identity
• the current local addressing state

If the claim conflicts with local claim or ownership state, the node MAY respond with an ADDRESS_CONFLICT message.

If the claim does not conflict, the node MAY simply observe it and continue normal operation.

When an ADDRESS_CONFLICT is received, the router evaluates whether:

• the disputed candidate matches the local candidate
• the targeted claimant identity matches the local claimant identity

If the conflict is applicable to the local node, the current claim MUST be treated as failed.

A failed claim SHOULD cause the node to abandon the candidate and return to address-selection behavior.

A claim is considered successful when the implementation determines that the candidate address is usable and uncontested.

Upon successful claim finalization:

• the local address becomes active
• the router enters the CLAIMED state
• registered transports SHOULD be updated with the local node ID
• neighbor-facing hello behavior MAY begin
• local route advertisement MAY begin

After a conflict or failed claim, the node MAY delay before attempting another selection.

Backoff behavior reduces repeated collisions between competing claimants.

Address claiming occurs within the scope of the local MTRP network identifier.

A node identifier is therefore meaningful only in the context of its network.

Current address behavior is intentionally lightweight.

The current implementation does not define:

• centralized address allocation
• globally coordinated lease management
• cryptographically authenticated claim ownership
• distributed quorum-based conflict resolution

During testing, expected address-state observations include:

• SELECTING before a candidate is chosen
• CLAIMING while claim traffic is active
• CLAIMED after a stable address is established
• CONFLICT when a competing claim is detected

Repeated conflict transitions usually indicate:

• too-small address space assumptions
• simultaneous startup contention
• stale local state
• address claim timing that needs adjustment