Walled Private Network (WPN) Service Definition

Introduction Existing networking technologies can already construct private IP networks in which a defined set of participants communicate directly with one another while general-purpose Internet access is excluded from that private network. Such deployments may use a VPN, an overlay, a carrier network, a physically isolated LAN, or other mechanisms. What is missing is a single term with a defined set of service semantics. Today, similar deployments are described by combinations of phrases such as "VPN without Internet access", "VPN without a default route", "non-NAT VPN", "closed VPN", "isolated VPN", "private network", or "closed user group". These descriptions overlap, but they are not equivalent and do not, by themselves, identify the complete set of properties specified here. This document defines Walled Private Network (WPN) as a technology-neutral network profile. When a network or service is described as a WPN according to this specification, the term identifies the addressing, member-connectivity, NAT, Internet-egress, isolation, and service-boundary properties defined below. The term is intended to remove the need to restate those properties in a product description, deployment document, or operational agreement each time the same model is used. The mechanisms used to realize a WPN are deliberately outside the definition. A WPN can be built with existing VPN technologies, but a VPN is neither necessary nor sufficient for WPN conformance. A directly attached private LAN can also conform when it satisfies all requirements of this specification. The term WPN is generic technical terminology. It does not identify a particular product, vendor, tunnel protocol, cryptographic system, or deployment topology.

Problem Statement and Terminology Gap The same underlying implementation can be described in several different ways, while the same descriptive phrase can also refer to networks with materially different behavior. This ambiguity is operationally significant because a user cannot infer the complete service boundary from phrases such as "private VPN" or "VPN without Internet".

Why "VPN Without a Default Route" Is Not a Definition A VPN configured without a default route is one common way to implement part of the WPN behavior. It is not, however, a complete definition of WPN. The absence of a default route describes one routing-table property. It does not establish whether member-to-member traffic is translated by NAT, whether member addresses retain end-to-end identity, whether all members use a defined address space, whether the service filters particular applications or transport ports, whether routes to networks behind members are distributed by the service, whether a naming service is required, or whether independently administered private networks are isolated from one another. The absence of a default route also does not necessarily prove the absence of effective Internet access. An implementation could provide broad Internet reachability through more-specific routes, policy routing, an operator-provided gateway, or another mechanism. WPN therefore specifies the resulting service behavior rather than a particular routing-table configuration. Conversely, a WPN does not have to be a VPN. A physically private LAN, a provider network, or another IP infrastructure can satisfy the same WPN requirements without using a tunnel at all.

Service Semantics Rather Than Implementation This specification defines the meaning of the WPN term, not how a WPN is constructed. A conforming implementation is free to select topology, forwarding mechanism, tunneling technology, cryptography, control plane, and management system, subject to the externally visible requirements in this document. Accordingly, "WPN" is intended to be usable as a concise service designation. A statement that a service provides a WPN is a claim that the service satisfies the conformance requirements in Section 5; it is not merely a statement that a VPN product has been configured in a particular way.

Scope and Applicability This document specifies the WPN service boundary at the IP addresses assigned to WPN members. It specifies observable addressing, reachability, translation, isolation, and egress properties at that boundary. This document does not define or require tunnel establishment, key management, membership provisioning protocols, dynamic-routing protocols, service discovery, DNS provisioning, customer-premises routing, or a particular management interface. Those mechanisms may be used by an implementation but are not part of the WPN term itself. A WPN can be provider-operated or self-operated; centrally forwarded or distributed; and implemented as hub-and-spoke, full mesh, switched LAN, routed network, or another topology. Conformance is determined by the network behavior specified here, not by its internal architecture. This specification intentionally separates the WPN service from networks behind a WPN member. A member can itself be a host, router, gateway, or tunnel endpoint, but prefixes reachable behind that member do not automatically become part of the WPN Address Space.

Conventions and Requirements Language The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 (, ) when, and only when, they appear in all capitals, as shown here. A network or network service claiming conformance with this specification as a Walled Private Network MUST satisfy every applicable MUST and MUST NOT requirement in Section 5. The term "WPN", as defined by this specification, denotes such a conforming network or service.

WPN Conformance Requirements

One Logical Private IP Connectivity Domain A WPN MUST present its authorized members as participants in one logical private IP connectivity domain. The WPN MUST have an administratively defined WPN Address Space from which WPN Member Addresses are drawn. This requirement does not imply Layer 2 adjacency, a shared broadcast segment, a particular subnet size, or a tunnel topology. A WPN MAY use Layer 2 forwarding, Layer 3 forwarding, tunnels, multiple transport links, or combinations of those mechanisms.

Explicit Membership and Address Uniqueness Membership in a WPN MUST be explicitly controlled by the WPN administrator or by an authorized membership mechanism. An implementation MUST have a means to determine which systems are authorized WPN Members. The WPN service MUST NOT provide WPN member connectivity to systems that are not authorized members. Each active WPN Member Address MUST be unique within its address family and WPN Address Space. The WPN implementation MUST prevent unauthorized use of WPN forwarding to the extent required to preserve the membership and address-identity properties of the service. This specification does not require a particular authentication or provisioning protocol. Physical access control, static provisioning, cryptographic authentication, or other mechanisms MAY be used when appropriate to the deployment.

Defined WPN Address Space The WPN Address Space MUST be explicitly defined as one or more IP prefixes administered as a single WPN address domain. Every WPN Member Address MUST belong to that address space. A WPN MAY be IPv4-only, IPv6-only, or dual stack. A dual-stack WPN has a WPN Address Space for each supported address family. The prefixes do not need to represent one Layer 2 subnet. A WPN implementation SHOULD permit selection of its WPN Address Space so that administrators can avoid collisions with local networks, other VPNs, or other WPNs used by participating systems.

NAT-Free Member-to-Member Communication For a packet whose source and destination are WPN Member Addresses, the WPN service MUST NOT translate either WPN Member Address using Network Address Translation. The source and destination WPN Member Addresses MUST retain their end-to-end identity across the WPN. NAT performed independently by a member for traffic originating in, or destined for, a Member-side Network is outside the WPN service boundary. Such NAT does not change the requirement that the outer WPN member-to-member communication remains NAT-free.

Protocol-Transparent Member Connectivity For each IP address family supported by communicating members, a WPN MUST provide bidirectional unicast IP connectivity between their WPN Member Addresses. The WPN service MUST NOT impose persistent application-specific, transport-port-specific, or ordinary IP-protocol-specific reachability restrictions between authorized members. A WPN MAY apply controls necessary to preserve membership, prevent source-address spoofing, maintain isolation, protect the infrastructure, or enforce generic resource limits. Such controls MUST NOT be used to define ordinary service behavior in which selected member applications, TCP or UDP ports, or otherwise supported unicast IP protocols are selectively unavailable. This requirement does not imply unlimited bandwidth, zero packet loss, a fixed MTU, multicast support, broadcast support, or the absence of endpoint-local firewall policy. IP multicast and link-layer broadcast semantics are OPTIONAL unless specified by another profile.

No WPN-Provided General-Purpose Internet Egress The WPN service MUST NOT provide effective general-purpose reachability from WPN Member Addresses to arbitrary destinations on the public Internet. Compliance with this requirement is determined by resulting service behavior, not solely by the absence of an Internet default route. A default route, an equivalent broad set of more-specific routes, policy routing, NAT gateway, operator-provided general Internet gateway, proxying function, or another mechanism that is provided as part of the WPN service and gives members general-purpose Internet access violates this requirement. A WPN Member MAY simultaneously use an independent local Internet connection that is not provided by the WPN. A member MAY also operate its own proxy, gateway, or nested tunnel reachable at a WPN Member Address. Such member-operated functionality is outside the WPN service and does not, by itself, make the WPN non-conforming. Control-plane traffic required to reach an underlay tunnel endpoint is also outside the WPN member forwarding domain and does not constitute WPN-provided Internet egress.

Underlay Independence A WPN MAY use the public Internet, a carrier network, a shared private network, a dedicated link, or another infrastructure as its underlay. Use of a public Internet underlay MUST NOT be interpreted as public Internet reachability from within the WPN. When the underlay is not trusted to provide the confidentiality, integrity, and peer isolation required by the deployment, the WPN implementation MUST protect WPN traffic with a suitable authenticated mechanism that provides integrity and confidentiality. This specification does not mandate a particular tunnel or cryptographic protocol.

Member-Side Networks Are Outside the Base WPN A base WPN MUST NOT require discovery, advertisement, distribution, or management of prefixes located behind WPN Members. Such Member-side Networks are not WPN Address Space merely because their router or gateway is a WPN Member. WPN Members MAY use WPN member connectivity as transport for static routing, dynamic routing, nested tunnels, or other mechanisms that they configure between themselves. The WPN service is required to carry the member-to-member outer traffic; it is not required to understand or manage the inner Member-side Network prefixes. If an operator offers managed routing for Member-side Networks, that function MUST be identified as an additional service or profile and MUST NOT alter the meaning of base WPN conformance defined here.

Isolation Between Independent WPNs Independently administered WPNs MUST remain separate forwarding domains. A WPN implementation MUST prevent unintended forwarding or routing-state leakage between independent WPNs and between a WPN and unrelated routing domains. An explicit interconnection between WPNs MAY be constructed as a separate function, but such an interconnection is outside the base WPN service and MUST NOT be assumed from WPN conformance.

Naming Services Are Optional A WPN MUST NOT require DNS or another naming service for base conformance. A WPN MAY carry or provide a naming service, and members MAY operate naming services reachable through their WPN Member Addresses. Provision of a naming service does not change the addressing and reachability requirements of this specification. This document does not define or reserve a WPN-specific DNS suffix.

Addressing Model The WPN Address Space is an administrative property of a particular WPN. It identifies the addresses for which the WPN service provides the member-connectivity semantics defined in Section 5. IPv4 deployments SHOULD normally select addresses appropriate for private use, such as the private-use prefixes defined by . IPv6 deployments SHOULD normally use Unique Local IPv6 Unicast Addresses as defined by when global routing is not required. Other address assignments can be operationally valid when they are deliberately isolated and administered consistently with this specification. Administrators SHOULD avoid collisions with address space already used by participating endpoints. This is particularly important when an endpoint remains simultaneously attached to a local LAN, another VPN, or another WPN. Different isolated WPNs MAY reuse overlapping private address space because their forwarding domains are separate. An endpoint participating in multiple overlapping WPNs needs an explicit mechanism, such as separate interfaces, routing tables, policy contexts, namespaces, or equivalent isolation, to disambiguate those destinations.

Routing and Reachability The WPN service is responsible for reachability among WPN Member Addresses. An implementation MAY use static routes, per-member forwarding state, dynamic routing, switching, tunnel-specific peer state, or another mechanism to realize that reachability. The service boundary is intentionally narrower than a general site-to-site VPN service. Routes to Member-side Networks are not part of base WPN forwarding state unless another service or profile explicitly adds such functionality. A WPN endpoint may therefore have at least two independent routing contexts: one for WPN destinations and another for ordinary local or Internet connectivity. This coexistence is valid as long as Internet traffic is not being provided through the WPN service itself. The "wall" in Walled Private Network is a logical reachability boundary. It does not imply air-gapping or physical isolation. Packets belonging to a WPN can traverse public infrastructure while the public Internet remains outside the WPN member forwarding domain.

Optional Naming and Service Discovery IP addressing is sufficient for WPN conformance. DNS, multicast DNS, service discovery, and other naming systems are optional higher-layer functions. An operator or member MAY provide unicast DNS within a WPN. A member-provided DNS server is simply another reachable WPN Member unless a separate service specification defines additional behavior. Implementations that configure private DNS SHOULD avoid leaking private names to public resolvers when those names are intended only for the WPN context. This specification assigns no special DNS suffix and creates no special resolver behavior.

Transport Underlay and Protection The WPN network model is independent of the transport used between attachment points. A deployment can require no encapsulation at all, or it can use one or more tunnels over a shared underlay. When a public or otherwise untrusted underlay is used, the protection requirement in Section 5.7 applies. Encryption of the underlay transport does not change the WPN addressing model: the inner packet still uses WPN Member Addresses, while the outer packet uses whatever addressing the underlay requires. Transport endpoint addresses are not WPN Member Addresses merely because they carry WPN traffic. A public address used to reach a tunnel endpoint belongs to the underlay and remains conceptually outside the WPN Address Space.

MTU and Nested Encapsulation Encapsulation overhead can reduce the effective MTU available to WPN members. This is a property of the selected transport mechanism rather than a defining limitation of the WPN model. An implementation that encapsulates WPN packets SHOULD expose or configure an effective MTU that can be carried over the expected underlay without relying on persistent fragmentation as ordinary operation. The tunneling considerations in are relevant. Path MTU Discovery for IPv4 and IPv6 is described in and , respectively. Implementations and operators should ensure that the signaling needed by the applicable mechanism is not inadvertently blocked. Members MAY run another VPN, GRE tunnel, IPsec tunnel, or other encapsulation over WPN member connectivity. Such nested encapsulation consumes additional MTU. WPN conformance therefore does not guarantee that an arbitrarily nested tunnel operates without member-side MTU or PMTU adjustment. The protocol-transparent-connectivity requirement means that the WPN does not intentionally block such traffic merely because it is a tunnel protocol; it does not remove the normal packet-size constraints of IP networking.

Relationship to Existing Terms and Architectures

Private Addressing describes private IPv4 addressing and includes hosts that need connectivity inside an enterprise but not network-layer connectivity outside it. WPN is compatible with such addressing but specifies a different concept: a complete set of membership, connectivity, NAT, egress, and service-boundary semantics.

Virtual Private Networks documents provider-provisioned VPN terminology and explicitly addresses the problem of overlapping and inconsistent terminology in that domain. VPN remains a broad technology and service family. A WPN can be implemented using VPN technology, but VPN alone does not imply the WPN requirements. In particular, a VPN can provide Internet egress, can apply member-to-member filtering, can use NAT, can distribute routes to customer sites, or can expose different service boundaries. Conversely, a WPN can exist without any tunneling technology.

Provider-Provisioned VPNs and Closed User Groups describes a framework for Layer 3 provider-provisioned VPNs, and describes, among other policies, a fully meshed closed user group. Such architectures can implement some or all WPN behavior, but they do not make the WPN term redundant. WPN fixes a particular service profile: an explicit WPN Address Space, NAT-free preservation of member addresses, protocol-transparent member connectivity, no WPN-provided general-purpose Internet egress, and an explicit boundary that excludes Member-side Network routing from the base service.

LANs and Intranets LAN describes a local network scope or technology and does not imply the WPN egress, NAT, membership, or filtering properties. A LAN can nevertheless be a WPN when it satisfies this specification. Intranet normally describes an organization-internal network or service environment and likewise does not define the complete WPN service semantics.

Walled Gardens A "walled garden" commonly denotes controlled access to a selected set of services, often while other destinations are blocked. WPN instead requires protocol-transparent connectivity among its members and excludes general-purpose public Internet access from the WPN service. The terms are not synonyms.

Operational Considerations

Address selection: administrators SHOULD choose WPN prefixes that do not conflict with local networks or other simultaneously used private routing domains.
Dual-stack consistency: when both IPv4 and IPv6 are provided, the no-general-purpose-Internet-egress property MUST hold for both address families. Accidentally allowing Internet egress over one family violates WPN conformance for that dual-stack service.
Member lifecycle: implementations SHOULD remove forwarding and authorization state promptly when membership is revoked.
Route leakage: operators SHOULD verify that WPN routes are not exported into unrelated routing domains and that unrelated broad Internet routes are not imported as WPN member reachability.
Source validation: implementations SHOULD bind authorized members to their assigned WPN Member Addresses strongly enough to prevent practical address impersonation.
MTU: operators SHOULD account for underlay and nested-tunnel overhead and SHOULD avoid persistent fragmentation as a normal operating condition.
Capacity: protocol-transparent connectivity does not imply a particular throughput, latency, availability, or service-level objective.
Multiple WPNs: endpoints attached to several WPNs SHOULD maintain unambiguous routing contexts, especially where private address spaces overlap.

Reference Deployment Examples

Central Service Node over a Public Underlay

This is a non-normative example. A central service node, public endpoint, tunnel, and the example prefix are implementation choices, not WPN requirements.

Private LAN as a WPN

No tunnel or VPN protocol is present in this example. If membership is controlled and the other requirements of Section 5 are satisfied, the LAN can conform to the WPN definition.

Member-Side Network Interconnection over a WPN

B | nested tunnel or other member-configured mechanism | inner routing: LAN A <-> LAN B ]]> The WPN carries the member-to-member outer traffic. The members configure the inner routing or tunneling relationship. Base WPN conformance does not require the WPN service to know routes for 192.168.10.0/24 or 192.168.20.0/24.

Security Considerations The VPN isolation considerations in are relevant to WPN deployments that use VPN mechanisms. More generally, WPN isolation is not equivalent to endpoint trust. Because members are intentionally able to communicate at the IP layer, a malicious or compromised member can scan, probe, or attack other members unless those endpoints protect themselves. Membership authorization is security critical. Implementations MUST preserve the explicit-membership and unique-address properties required by Section 5.2. Deployments SHOULD bind authenticated or otherwise authorized member identity to assigned WPN Member Addresses strongly enough for their threat model. Route leakage can defeat the WPN boundary. Accidental import of broad public Internet routes, export of WPN routes into an unrelated domain, or cross-connection between independent WPN forwarding contexts can create reachability forbidden by this specification. When an untrusted underlay is used, Section 5.7 requires suitable authenticated protection providing integrity and confidentiality. Cryptographic algorithm selection and key-management procedures are outside this specification and need to follow the requirements of the chosen security mechanism. A dual-homed member can have both WPN connectivity and an independent Internet path. A compromised or intentionally configured member can relay or copy data between those domains. WPN therefore provides a network-service reachability boundary; it is not a guarantee against exfiltration by an authorized endpoint. Environments requiring stronger separation need additional endpoint, routing, or physical controls. Encrypted tunnels can reveal metadata to an underlay observer, including endpoint addresses, traffic volume, and timing. WPN does not claim to conceal such metadata. Denial-of-service and resource exhaustion remain possible from the underlay or from authorized members. Generic resource controls are compatible with WPN as described in Section 5.5, but application-specific restrictions must not be presented as ordinary WPN member connectivity. Private naming can leak information if resolvers forward private names to public DNS. Naming is optional in WPN, and deployments providing private DNS should apply resolver policy appropriate to their naming scope.

IANA Considerations This document has no IANA actions. In particular, it does not request a special-use DNS name or allocate any address space, protocol number, port number, or other registry value.