Before ORC8R can do anything with traffic from the internet, that traffic has to arrive at one of your machines. Arranging that is the one part of public exposure nobody else can do for you: it happens in your hosting provider's control panel, or on your own router, on equipment ORC8R never touches. This page is about that part — the front door — in the four shapes it usually takes.

What you have to supply is one physical fact: a block of public addresses that actually reaches your hosts. Host here means one of your machines; on the plan form you name them by their node ids. Everything after that — picking an address for a pool, deciding which host receives it, forwarding to the pool's nodes, publishing names, getting a certificate — is automatic.

What is automated, and what you wire

Once the block reaches your hosts, this is the division of labour.

ORC8R does	You do
Picks one address per family for each pool and keeps it — the pool holds the same address for as long as it stays exposed	Obtain the block of public addresses
Moves the claim — the one host that currently receives a pool address's incoming traffic — to another host within seconds of a failure	Make the block reach the hosts: either routed to them, or on a network segment they share
Sets up the hosts: forwarding to nodes, the pool address on every node, firewall policy	Leave the traffic alone on the way in — no filter above the hosts that drops it
Publishes the DNS records, and withdraws one while the node behind it is unhealthy	Delegate the base domain once, so that names under example.com are answered by this deployment
Orders and renews the organization's wildcard certificate	Nothing

ORC8R never speaks a routing protocol and never talks to your router. A plan — the block declaration you make under Zone → Public Addresses — is a statement of fact, this block is routed to these hosts, and the platform believes you. Nothing verifies it against your router.

Routed block from a provider

This is the datacenter case, and the one to prefer. Your provider routes a block to your server: commonly a /64 (often a /56) of IPv6 at no cost, and a small IPv4 block for rent. Your host is the last stop for that traffic, and nothing on the path in front of it needs to answer for individual addresses.

What to do:

1. Ask the provider to route the block to the host, rather than putting it on-link — on-link means the addresses sit on a segment the host shares, where something has to answer for each address individually, which is the next pattern. Most provider panels call the routed option "routed subnet", "additional prefix", or "IP block via gateway".
2. Confirm the host has a route for the block, or at least accepts packets addressed to it.
3. Declare the plan with the block and that host in the routed set, dsr on. Direct server return (dsr on the plan form and in log lines) means replies leave straight from the node that served the request, bypassing the host that received it.

Failover is bounded by the block: the claim can move to any host the block is routed to, and no further. If your provider routes a distinct block to each server, declare one plan per block and list each block's own host. A pool then draws from the plan that overlaps its hosts, and failover beyond a single block is not a claim move at all — it falls back to drawing a new address and updating the record.

On-link block on a VLAN — the home-lab and small-office case

Here the block lives on a network segment your hosts share with a router — an IPv6 prefix delegated to a VLAN, or a spare range of a LAN.

There is no routing entry. Instead the claiming host answers NDP (or ARP) for the pool address — the neighbour-discovery question a router asks on the segment, who has this address? — and that is how the router learns where to send it. This is the pattern a UniFi, OPNsense, or MikroTik box gives you.

What to get right:

1. Put the hosts on the VLAN the prefix is assigned to, and declare that prefix as the block.
2. Carve out the range so nothing else hands it out: exclude it from the DHCP pool, and from SLAAC — the IPv6 arrangement where a host builds its own address out of the advertised prefix — if the router would assign inside it.
3. Make sure the router does not claim the addresses itself — turn off any "proxy NDP" or "proxy ARP" feature, which would have it answer for the whole prefix on behalf of everything behind it.
4. If your prefix comes from DHCPv6 prefix delegation — your ISP handing your router a whole block to use, rather than one address — check that it is stable. A prefix that changes when the ISP session resets renumbers every pool address you have drawn from it, and DNS records follow slowly by comparison. Request a static prefix, or use the tunnel pattern below.

The claim moving between hosts is a gratuitous neighbour advertisement; routers pick it up in well under a second, but a router with a long, non-overridable neighbour cache is the thing to look at if a failover seems to hang.

Carving a block over a tunnel — the lab without a routable prefix

If your uplink gives you nothing routable — CGNAT, a single dynamic address, a provider that will not route a prefix — you can rent a small VPS that does get a routed block, and carry a piece of it home over a tunnel (WireGuard is the usual choice). The VPS routes, say, a /80 out of its /64 down the tunnel; the host at your end of the tunnel is then a host the block is routed to, and you declare a plan for exactly that sub-prefix.

Be honest with yourself about two things:

• The tunnel endpoint is a single point of ingress. If it is down, the addresses are unreachable, no matter how many hosts hold nodes.
• Direct server return needs the tunnel on every host that runs a node. Under DSR a node replies out of its own host's uplink, sourced from the pool address, and your ISP will drop a packet sourced from a prefix that is not theirs. On a single-host lab this is a non-issue: the claiming host and the node's host are the same machine, and the reply goes back up the tunnel it came from. On a multi-host lab, carry the tunnel and a route for the block on every host that may run a node. Turning the plan's dsr flag off is not the workaround it looks like — the NAT funnel meant to serve those plans is not implemented on hosts yet, so such an address is currently not served at all.

Also set the tunnel MTU deliberately — the MTU is the largest packet a link will carry, and 1420 is the common WireGuard value. The platform clamps the size TCP negotiates on the forwarded path, so TCP is fine, but large UDP payloads are yours to size.

Many hosts, one block: the BGP tier

The endgame for large deployments is announcing the pool address from several hosts at once with BGP, the protocol routers use to tell each other which addresses they can reach. Incoming traffic would then be spread across every announcing host by ECMP, which is routers sharing traffic evenly over several equally good paths, and failover would happen at routing speed rather than control-plane speed. It is not implemented. What ships today is the single-announcer case of it — one claiming host at a time, reassigned by the control plane in seconds.

Practically, that means ingress for one pool address funnels through one host. Egress does not: it leaves directly from every serving node's own host, which is the direction that carries the bytes. If a single host's ingress capacity is your ceiling, the answers available today are more pools (each draws its own address), or a smaller share of the traffic per node, not a bigger claim.

Choosing between them

• You rent a server from a hosting provider and they will route a block to it → routed block, dsr on. Nothing else to think about.
• You run your own router and can give your machines a VLAN of their own → on-link block, dsr on. Mind the DHCP carve-out and the prefix stability.
• You have neither — a home or office connection with nothing routable behind it → tunnel carve, with the tunnel on every host that runs a node (or keep the lab to a single host, where the question does not arise).
• Somewhere on the path you do not control, packets are dropped when the sender address does not look like it belongs on that link — this is called reverse-path filtering, or strict uRPF → you have no working option today. The dsr flag exists to record exactly the consent such a network cannot give, and a network that filters on the sender address discards DSR replies silently. But the funnel that is meant to serve dsr-off plans is still unimplemented, so the honest answer is to fix the filtering (or exempt the block) rather than to turn the flag off.

Related pages

• Public exposure — declaring the plan and what allocation does.
• Networking overview — how traffic reaches a pool.
• Troubleshooting networking — when the address does not answer.