Visual RFC.
ALL RFCs / RFC 8656
Read the RFC ↗
RFC 8656 / PROTOCOL MECHANISMS

Refresh or delete the allocation

05

Allocations and their supporting state consume relay resources and must be maintained deliberately.

Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

DIAGRAM§ 8 ↗
RFC 8656 · § 8EXAMPLE
3 / 3
Refresh or delete the allocationAllocations and their supporting state consume relay resources and must be maintained deliberately.allocation lifetimeRefresh → granted extensionRefresh lifetime 0 → deleteAllocation, permission, and channel lifetimes are separate
03
A zero-lifetime Refresh explicitly releases the allocation.

A zero-lifetime Refresh explicitly releases the allocation.

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
KEY POINT

Refresh can extend allocation lifetime; a requested lifetime of zero deletes it.

  • Refresh can extend allocation lifetime; a requested lifetime of zero deletes it.
  • Permission and channel lifetimes are separate; refreshing an allocation does not automatically make all peer state permanent.
DETAILS

The drawing is a simplified worked example. Follow the linked RFC and its updates for implementation requirements.

Read the RFC section ↗

Diagrams simplify the RFC. Read the linked sections for complete requirements.

Privacy
All chapters in this RFC
  1. Allocate a relayed transport address
  2. Install a permission for a peer
  3. Relay using Send and Data indications
  4. Bind a channel for repeated traffic
  5. Refresh or delete the allocation
RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗