====== 4. Addressing and Claim Behavior ======

===== 4.1 Purpose =====

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

===== 4.2 Scope =====

This document describes:

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

===== 4.3 Address Model =====

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.

===== 4.4 Address States =====

The implementation currently uses the following address states:

^ State ^ Meaning ^
| ''UNINITIALIZED'' | local addressing has not yet been initialized |
| ''SELECTING'' | node is choosing a candidate address |
| ''CLAIMING'' | node is actively attempting to claim a candidate address |
| ''CLAIMED'' | node has a valid local address |
| ''CONFLICT'' | the current claim or address is in conflict |

===== 4.5 Initialization Behavior =====

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.

===== 4.6 Candidate Address Selection =====

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.

===== 4.7 Address Claiming =====

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.

===== 4.8 Conflict Detection =====

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

===== 4.9 ADDRESS_CLAIM Handling =====

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.

===== 4.10 ADDRESS_CONFLICT Handling =====

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.

===== 4.11 Successful Claim Finalization =====

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

===== 4.12 Backoff Behavior =====

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

Backoff behavior reduces repeated collisions between competing claimants.

===== 4.13 Network Identifier Relationship =====

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.

===== 4.14 Operational Notes =====

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

===== 4.15 Diagnostic Expectations =====

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