Networking and address policy

IPv6 first, IPv4 fully supported

The Runink platform is IPv6-first, and many data platforms are still reachable only over IPv4. FACE supports both, so no connector pins an address family.

TCP dials use Happy Eyeballs (RFC 8305). This covers the HTTP-based connectors, the raw-socket protocols (MQTT, LLRP, Modbus, NMEA, Kafka, RTSP), the Snowflake and Databricks transports, and the PostgreSQL and MySQL drivers. When a name resolves to both IPv6 and IPv4 addresses, FACE races them and uses whichever connects first.
gRPC dials (control plane to runner) try addresses in order. They follow RFC 6724 preference, so IPv6 comes first, and fall back to the next address after a connect timeout. They do not race.
Reaching IPv4-only services from an IPv6-only network needs NAT64 or an equivalent egress path. That is a deployment concern, not a connector setting. See /docs/operations/.

Writing addresses

IPv6 literals need brackets when a port is given: [2001:db8::10]:5432, rtsp://[2001:db8::20]:554/stream, tcp://[2001:db8::30]:1883.
A bare IPv6 literal without a port is also accepted where a connector applies a default port. FACE detects “has a port” by parsing, not by looking for a colon, so 2001:db8::10 gets the default port appended and bracketed correctly.
Default ports:
Protocol Default port
PostgreSQL 5432
MySQL 3306
MQTT 1883 (8883 with TLS)
LLRP 5084
Modbus-TCP 502 (802 with TLS)
Kafka 9092
RTSP 554
Databricks 443
Runner https:// endpoint 443
A URL must not contain credentials (user:pass@). Connectors that parse URLs refuse them and ask you to store the credential on the connection instead.

Protocol	Default port
PostgreSQL	5432
MySQL	3306
MQTT	1883 (8883 with TLS)
LLRP	5084
Modbus-TCP	502 (802 with TLS)
Kafka	9092
RTSP	554
Databricks	443
Runner `https://` endpoint	443

Connector address policy

Connectors dial addresses that people type into a form. To stop those addresses from reaching the platform’s own internals, every connector that uses FACE’s hardened network layer checks the address actually being connected to, after DNS resolution, on every dial and on every redirect hop. This covers:

MQTT, RFID, GPS, the sensor gateway and the logistics REST connector
Salesforce, ServiceNow, Guidewire and SAP OData
Kafka and its Schema Registry
CCTV (RTSP, HTTP, ONVIF and snapshots)
the Flipper edge agent and web pages
the Snowflake and Databricks transports

The check happens after resolution, so a hostname that points inward is judged by where it points.

Always refused, with no opt-in

Address	Message
The unspecified address (`0.0.0.0`, `::`)	`refusing to dial the unspecified address`
Any multicast address	`refusing to dial multicast address … — a data source has one server`
The cloud instance-metadata service (`169.254.169.254`, `fd00:ec2::254`)	`refusing to dial …: that is the cloud instance-metadata service, not a data source. This refusal has no opt-in`
An address that cannot be parsed after resolution	`refusing to dial "…": the resolved address could not be parsed, and an address that cannot be checked is not dialled`

Internal addresses: refused or allowed per connector

These classes are internal:

loopback
private (RFC 1918, and IPv6 unique-local fc00::/7)
link-local
carrier-grade NAT (100.64.0.0/10)

Whether an internal address is allowed depends on the connector’s default:

Default	Connectors
Refused	Web pages, Salesforce, ServiceNow, Snowflake, Databricks
Allowed	MQTT, RFID, GPS, sensor gateway, logistics REST, Guidewire, SAP OData, Kafka, CCTV, Flipper edge

Any connection can override its connector’s default in either direction with the property allow_internal_network (also accepted: allow_private_network, allow_internal). Use true or false. A value that is neither falls back to the connector’s default. When an address is refused, the message names the property:

refusing to reach 10.1.2.3: it resolves to a private address, which is inside this deployment's own network rather than on the public internet. If that is genuinely the source you mean, set `allow_internal_network=true` on this connection

An IPv4-mapped IPv6 address (::ffff:a.b.c.d) is judged as the IPv4 address it maps to. The same applies to an address in the NAT64 well-known prefix 64:ff9b::/96: FACE judges the embedded IPv4 address, so NAT64 does not bypass the rules above.

Redirects and proxies

Redirects. HTTP connectors follow at most 5 redirects, and only to the same host. A redirect to another host is refused, so a credential sent to the source you named is never replayed to a different one: refusing to follow a redirect from … to ….
Proxies. Connector HTTP clients use no proxy, so the address that is checked is the address that is connected to.

Timeouts and body caps

Every connector bounds its dial, its handshake and its response body. Over-cap responses are refused rather than read short. See each connector page for its figures. When a body exceeds its cap, the message is:

… returned more than N bytes: refusing to report a partially-read answer as a complete one — narrow the request (a shorter collection window, a smaller page size, a single resource) or point the connection at an endpoint that pages

Runners Troubleshooting