{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T11:31:38Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 22.9, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09562-1de7-7a92-be35-007c2fa11d7d\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: NAT traversal\nSense to describe: (none recorded)\nDomain code: ACT.ACT\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 044: 1001 r", "usd": 0.0, "recall": true }, "codex": { "seconds": 68.0, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09562-1ddd-76e2-a72d-892718bb9d3c\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: NAT traversal\nRegistry id: vr.tr.nat-traversal\nPlane / domain: ACT / ACT.ACT\nRegistry definition: (none recorded)\nNames folded into this entry: (none" } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:45:36+00:00", "fields": [ "agent_conduct", "ethics", "owners", "standards_and_regulation" ] }, "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T10:10:31+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q581558", "registryId": "vr.tr.nat-traversal", "name": "NAT traversal", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "ACT.ACT" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q581558/", "model": { "registry_id": "vr.tr.nat-traversal", "name": "NAT traversal", "purpose": "Enable an AI agent to recognise a NAT traversal attempt, assess whether its communication path works, and select authorised actions to establish or maintain connectivity.", "definition": "NAT traversal is the set of techniques used to establish and maintain communication across network address translators when address translation and associated packet-filtering behavior prevent straightforward end-to-end connectivity.", "scope_statement": "This model owns the process of establishing and maintaining application connectivity across network address translation boundaries, including discovery, coordination, direct-path attempts, explicit mapping and relay fallback.", "in_scope": [ "Endpoint roles, intended traffic direction and observed translation boundaries", "Discovery and exchange of candidate transport addresses", "Direct connectivity checks and explicit port-mapping attempts", "Relay allocation and selection when direct connectivity is unavailable or unsuitable", "Mapping lifetime, path changes, failure diagnosis and traversal authorisation" ], "out_of_scope": [ "General NAT implementation, address translation tables and router administration", "Application session semantics and media encoding", "General firewall policy design and network access control administration", "VPN tunnel construction and overlay routing beyond their relationship to a traversal attempt", "Application identity, end-to-end encryption and content security beyond traversal dependencies" ], "distinguishing_features": [ "An instance must address connectivity affected by address translation; ordinary communication using directly reachable addresses alone is not sufficient.", "Learning an externally observed address is a discovery result, not proof that the intended peer can exchange application traffic through it.", "A direct traversal path exchanges endpoint traffic without a payload relay; a relayed traversal path forwards that traffic through an intermediary.", "NAT translation behaviour and firewall filtering must be recorded separately because a reachable mapping does not establish permission to receive traffic.", "A successful path is specific to endpoints, transport and observation time; success does not establish permanent or universal reachability." ], "characteristics": [ { "name": "Traversal mechanism", "kind": "category", "unit_or_values": "connectivity-check-driven direct traversal | explicit mapping | relay | combination | unknown", "why_it_matters": "Determines the actions, dependencies and evidence needed to establish connectivity." }, { "name": "Endpoint transport context", "kind": "relation", "unit_or_values": "local endpoint, intended peer, transport protocol and address family", "why_it_matters": "Prevents applying observations from one socket, transport or peer to a different communication attempt." }, { "name": "Translation topology", "kind": "category", "unit_or_values": "single translation boundary | multiple boundaries | no boundary observed | unknown; recorded separately for each endpoint", "why_it_matters": "A mapping established at one boundary may leave another boundary unresolved." }, { "name": "Observed mapping and filtering behaviour", "kind": "category", "unit_or_values": "separate observations of address-and-port mapping reuse and inbound acceptance across tested remote endpoints, with untested cases marked unknown", "why_it_matters": "Supports mechanism selection without relying on an overconfident single NAT-type label." }, { "name": "Candidate provenance", "kind": "relation", "unit_or_values": "transport address linked to its discovery method, observing service or peer, interface and timestamp", "why_it_matters": "Distinguishes local, externally observed and relay addresses and makes stale evidence detectable." }, { "name": "Connectivity state", "kind": "state", "unit_or_values": "unattempted | discovering | checking | usable-direct | usable-relayed | degraded | failed | expired", "why_it_matters": "Separates preparatory progress from demonstrated usable connectivity." }, { "name": "Path validation age", "kind": "measurement", "unit_or_values": "seconds since the last successful validation of the selected path", "why_it_matters": "Indicates how current the evidence of reachability is." }, { "name": "Mapping or allocation lifetime", "kind": "measurement", "unit_or_values": "seconds, labelled as granted, experimentally observed, estimated or unknown", "why_it_matters": "Informs refresh timing and prevents treating estimated expiry as guaranteed." }, { "name": "Selected-path performance", "kind": "measurement", "unit_or_values": "round-trip time in milliseconds, packet loss in percent and measured throughput in bits per second, each with an observation window", "why_it_matters": "Allows an agent to judge whether a reachable path meets application requirements." }, { "name": "Traversal authority", "kind": "relation", "unit_or_values": "attempt linked to permitted peers, services, mapping operations and network policy", "why_it_matters": "Technical feasibility alone does not authorise exposure or traffic forwarding." } ], "affordances": [ "Gather candidate addresses and preserve the context and age of each observation.", "Coordinate permitted connectivity checks between participating endpoints.", "Request and later remove an authorised explicit mapping where supported.", "Select a validated direct or relay path against application requirements and policy.", "Refresh, revalidate or replace a path after inactivity or network change.", "Diagnose failed attempts and release mappings, relay allocations and temporary credentials." ], "agent_conduct": { "may": [ "Explain how NAT traversal works in general terms and cite the relevant open standards.", "Configure NAT traversal on networks and applications the agent is authorized to manage.", "Diagnose connection failures caused by address translation for the system's operator." ], "must_not": [ "Use traversal to reach devices or networks it is not authorized to access.", "Open inbound paths through a firewall that bypass an organization's security policy without its approval.", "Expose the private addresses of users in peer-to-peer sessions without their knowledge.", "Use relays to tunnel traffic around monitoring that the network owner requires." ], "requires_human": [ "Enabling automatic port mapping or relays on a shared or corporate network." ] }, "ethics": { "considerations": [ "Traversal can make private devices reachable from the internet, which helps and harms.", "Peer connections can leak a user's network address and approximate location." ], "affected_parties": [ "Network users", "Network administrators", "Owners of exposed devices" ] }, "owners": { "steward": "The operator of the network and of each application that uses traversal.", "master_systems": [] }, "standards_and_regulation": [ "Session Traversal Utilities for NAT (STUN), RFC 8489, Internet Engineering Task Force.", "Traversal Using Relays around NAT (TURN), RFC 8656, Internet Engineering Task Force.", "Interactive Connectivity Establishment (ICE), RFC 8445, Internet Engineering Task Force." ], "what_it_is_for": [ "NAT traversal is used when devices behind address-translating gateways need to communicate with endpoints outside their local networks.", "It supports applications such as voice calls, video meetings, multiplayer sessions and remote device communication.", "Networking software may establish a direct path or use a relay according to gateway behavior and network policy." ], "failure_modes_and_hazards": [ "Incompatible gateway behavior or expired address mappings can prevent connection establishment or interrupt active sessions.", "Traversal arrangements that conflict with access policy can expose services to unintended external communication.", "Relayed traffic can introduce additional latency, operating costs and dependence on third-party infrastructure.", "Connection metadata can reveal network addresses or communication relationships beyond the intended audience." ], "facets_not_applicable": { "recognition": "NAT traversal is a networking technique without a directly perceivable appearance." } }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q581558: NAT traversal", "url": "https://www.wikidata.org/wiki/Q581558", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: NAT traversal", "url": "https://en.wikipedia.org/wiki/NAT_traversal", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "communication-boundaries", "name": "Communication boundaries", "description": "Identify the intended exchange and the translation boundaries affecting it.", "rationale": "Traversal decisions depend on which endpoint must communicate with which peer through which boundaries.", "layers": [ { "id": "endpoint-intent", "name": "Endpoint intent", "description": "Describe the communication that traversal must enable.", "findings": [ { "id": "required-exchange", "name": "Required exchange", "description": "Record endpoint roles, transport, address family and required traffic directions.", "questions": [ { "text": "Which endpoints must exchange traffic, using which transport and address family?", "kind": "definition", "id": "required-exchange-q01" }, { "text": "Must either endpoint receive traffic before sending anything to the intended peer?", "kind": "boundary", "id": "required-exchange-q02" } ] } ] }, { "id": "translation-and-filtering", "name": "Translation and filtering", "description": "Separate observed translation effects from traffic admission constraints.", "findings": [ { "id": "boundary-evidence", "name": "Boundary evidence", "description": "Record evidence of translation layers, filtering and same-network reachability without assuming the complete topology is visible.", "questions": [ { "text": "What observations support the presence of one or more translation boundaries on each endpoint's path?", "kind": "provenance", "id": "boundary-evidence-q01" }, { "text": "Which tests distinguish mapping behaviour, inbound filtering and possible hairpin-path limitations?", "kind": "measurement", "id": "boundary-evidence-q02" }, { "text": "Which suspected boundaries remain unobserved or outside the endpoint operator's control?", "kind": "boundary", "id": "boundary-evidence-q03" } ] } ] } ] }, { "id": "candidate-discovery-and-coordination", "name": "Candidate discovery and coordination", "description": "Maintain possible transport addresses and the coordination needed to test them.", "rationale": "An address is useful for traversal only when its origin, freshness and intended use are understood.", "layers": [ { "id": "address-observations", "name": "Address observations", "description": "Track candidate addresses as contextual observations.", "findings": [ { "id": "candidate-context", "name": "Candidate context", "description": "Associate each candidate with its local interface or socket, discovery method and observation time.", "questions": [ { "text": "Was this candidate obtained from a local interface, a STUN observation, a peer observation, an explicit mapping or a relay allocation?", "kind": "provenance", "id": "candidate-context-q01" }, { "text": "Which local socket and remote observation context produced this address, and when?", "kind": "measurement", "id": "candidate-context-q02" } ] } ] }, { "id": "peer-coordination", "name": "Peer coordination", "description": "Record how endpoints exchange candidates and coordinate traversal checks.", "findings": [ { "id": "candidate-exchange", "name": "Candidate exchange", "description": "Bind exchanged candidates and check parameters to the intended session and peer.", "questions": [ { "text": "Which signalling channel delivers candidates and check parameters to the intended peer?", "kind": "provenance", "id": "candidate-exchange-q01" }, { "text": "How are delayed candidates, simultaneous attempts and obsolete session parameters handled?", "kind": "action", "id": "candidate-exchange-q02" } ] } ] } ] }, { "id": "direct-path-establishment", "name": "Direct path establishment", "description": "Represent attempts to establish endpoint connectivity without a payload relay.", "rationale": "Discovery, coordinated probing and explicit mapping produce different evidence and must not be treated as interchangeable successes.", "layers": [ { "id": "connectivity-checks", "name": "Connectivity checks", "description": "Evaluate candidate pairs through actual traffic exchanges.", "findings": [ { "id": "validated-candidate-pair", "name": "Validated candidate pair", "description": "Track check outcomes for specific endpoint transport addresses and distinguish checks from application readiness.", "questions": [ { "text": "Which candidate pair completed a valid response exchange, under which check procedure?", "kind": "measurement", "id": "validated-candidate-pair-q01" }, { "text": "What further evidence is required before declaring this pair usable for the application's traffic?", "kind": "boundary", "id": "validated-candidate-pair-q02" }, { "text": "When should unsuccessful checks be retried, replaced by another pair or stopped?", "kind": "action", "id": "validated-candidate-pair-q03" } ] } ] }, { "id": "explicit-port-mapping", "name": "Explicit port mapping", "description": "Represent requests to create externally reachable mappings through a supported gateway control mechanism.", "findings": [ { "id": "mapping-grant-and-reachability", "name": "Mapping grant and reachability", "description": "Separate a gateway's mapping grant from verified reachability across the complete path.", "questions": [ { "text": "Which gateway granted which external address, port, transport and lifetime for which internal endpoint?", "kind": "provenance", "id": "mapping-grant-and-reachability-q01" }, { "text": "Does an external connectivity test confirm the mapping is usable beyond all intervening boundaries?", "kind": "measurement", "id": "mapping-grant-and-reachability-q02" }, { "text": "When and by whom must this mapping be refreshed or removed?", "kind": "action", "id": "mapping-grant-and-reachability-q03" } ] } ] } ] }, { "id": "relay-and-path-selection", "name": "Relay and path selection", "description": "Manage intermediary forwarding and choose among usable paths.", "rationale": "Traversal can require relay resources, and reachability alone does not determine the appropriate path.", "layers": [ { "id": "relay-readiness", "name": "Relay readiness", "description": "Track the resources and permissions required for relay forwarding.", "findings": [ { "id": "relay-allocation", "name": "Relay allocation", "description": "Record the relay service, allocation lifetime, supported transport and permission state required by the selected mechanism.", "questions": [ { "text": "Which relay allocation and peer permissions are active, and what evidence confirms forwarding works?", "kind": "measurement", "id": "relay-allocation-q01" }, { "text": "Which authentication, capacity or transport limitation could prevent using or refreshing the allocation?", "kind": "boundary", "id": "relay-allocation-q02" } ] } ] }, { "id": "path-choice", "name": "Path choice", "description": "Compare validated paths against communication requirements and operating policy.", "findings": [ { "id": "selection-and-fallback", "name": "Selection and fallback", "description": "Make the selected path and the conditions for switching explicit.", "questions": [ { "text": "Which validated path satisfies the required latency, throughput, privacy and relay-cost constraints?", "kind": "measurement", "id": "selection-and-fallback-q01" }, { "text": "What observed failure or degradation should trigger fallback, renewed checks or session termination?", "kind": "action", "id": "selection-and-fallback-q02" } ] } ] } ] }, { "id": "continuity-and-controlled-exposure", "name": "Continuity and controlled exposure", "description": "Maintain usable paths while controlling the reachability and resources that traversal creates.", "rationale": "Mappings and allocations can expire or change, and maintaining connectivity can extend network exposure.", "layers": [ { "id": "path-lifecycle", "name": "Path lifecycle", "description": "Track freshness, refresh operations and invalidating network changes.", "findings": [ { "id": "expiry-and-rebinding", "name": "Expiry and rebinding", "description": "Distinguish keeping translation state alive from proving that the peer and application path remain usable.", "questions": [ { "text": "What measured or granted lifetime supports the current keepalive or refresh interval?", "kind": "measurement", "id": "expiry-and-rebinding-q01" }, { "text": "Which interface change, address rebinding or failed exchange requires candidate rediscovery and path revalidation?", "kind": "action", "id": "expiry-and-rebinding-q02" }, { "text": "Does the latest evidence demonstrate mapping persistence, peer responsiveness or successful application traffic?", "kind": "boundary", "id": "expiry-and-rebinding-q03" } ] } ] }, { "id": "permission-and-teardown", "name": "Permission and teardown", "description": "Bound traversal actions by authority, peer consent and resource lifetime.", "findings": [ { "id": "authorised-reachability", "name": "Authorised reachability", "description": "Record permission to create reachability, disclose candidate addresses and continue sending traffic, together with cleanup obligations.", "questions": [ { "text": "What authority permits these probes, mapping requests, candidate disclosures and relay usage?", "kind": "provenance", "id": "authorised-reachability-q01" }, { "text": "How is continued peer consent established where required by the traversal protocol?", "kind": "measurement", "id": "authorised-reachability-q02" }, { "text": "Which mappings, allocations and credentials must be retired when the attempt ends or permission is withdrawn?", "kind": "action", "id": "authorised-reachability-q03" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "This description is recalled knowledge, not a report of sources consulted; verify RFC revision and update status before implementation.", "Traversal success depends on mapping and filtering behavior, transport, topology, and policy; no universal success rate or latency range is defensible.", "The label NAT-T is often used specifically for IPsec NAT traversal and should not automatically be treated as synonymous with the entire topic." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "UDP hole punching", "TCP hole punching", "Explicit port mapping", "Relay-assisted traversal", "Connectivity-check-based selection of direct or relayed paths" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IETF RFC 8445: Interactive Connectivity Establishment (ICE), a NAT traversal framework for UDP.", "IETF RFC 8489: Session Traversal Utilities for NAT (STUN).", "IETF RFC 8656: Traversal Using Relays around NAT (TURN).", "IETF RFC 4787: Network Address Translation Behavioral Requirements for Unicast UDP.", "IETF RFC 6887: Port Control Protocol (PCP)." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Establishing media paths for voice and video calls.", "Connecting WebRTC peers using ICE, with STUN and TURN support.", "Enabling peer-to-peer multiplayer gaming.", "Establishing direct connections between peers in file-sharing and remote-access systems.", "Carrying VPN traffic across NAT devices." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Endpoint-dependent mapping or restrictive filtering can prevent hole punching and require a relay.", "Mapping expiration or a change in the externally mapped address or port can interrupt established communication.", "Multiple translation layers, including carrier-grade NAT, can defeat mappings established only on the local router.", "Relay unavailability, bandwidth limits, or added latency can degrade or prevent communication.", "Explicit mappings can expose services to unsolicited traffic; traversal does not replace authentication, encryption, or access control." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "Network address translation", "difference": "NAT rewrites packet addresses and sometimes ports; NAT traversal establishes communication despite the resulting reachability constraints." }, { "name": "Firewall traversal", "difference": "Firewall traversal addresses traffic-policy restrictions, which can exist without address translation; NAT traversal addresses translation-related connectivity constraints, often alongside filtering." }, { "name": "STUN", "difference": "STUN supplies functions such as discovering mapped addresses and performing connectivity checks; it is a component of traversal solutions rather than a complete solution for every NAT." }, { "name": "TURN", "difference": "TURN provides a relay path through a server; NAT traversal also includes techniques that establish direct paths." }, { "name": "ICE", "difference": "ICE gathers candidates, checks connectivity, and selects a working path; NAT traversal is the broader problem and family of techniques." }, { "name": "Port forwarding", "difference": "Port forwarding establishes a mapping for inbound traffic; it is one possible traversal mechanism rather than a synonym for NAT traversal." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of NAT traversal this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Should the registry boundary include application-specific NAT traversal adaptations such as IPsec NAT traversal, or represent them as specialised models linked to this one?", "Which protocol specifications and versions should define the supported profiles for ICE, STUN, TURN and explicit gateway mapping?", "What minimum observations justify classifying mapping and filtering behaviour without overgeneralising across destinations, transports or time?", "What application-specific evidence and observation window should qualify a path as usable, degraded or failed?", "Which deployment policies determine permitted address disclosure, explicit inbound exposure, relay selection and refresh traffic?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 16, "questions": 31 } }