Walled Private Network (WPN) Service Definition
draft-kafara-walled-private-network-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Martin Kafara | ||
| Last updated | 2026-10-08 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-kafara-walled-private-network-00
Network Working Group M. Kafara
Internet-Draft Wardfold s.r.o.
Intended status: Standards Track 8 October 2026
Expires: 11 April 2027
Walled Private Network (WPN) Service Definition
draft-kafara-walled-private-network-00
Abstract
This document specifies Walled Private Network (WPN) as a technology-
neutral profile for a private IP network or network service. A
conforming WPN has an explicitly defined address space, explicit
membership, end-to-end preservation of member addresses without
Network Address Translation between members, and protocol-transparent
IP connectivity among authorized members. A WPN does not provide
general-purpose Internet egress as part of the WPN service. The
public Internet or another shared network may nevertheless be used as
an underlay. Networks located behind individual members are outside
the base WPN service and may be interconnected by mechanisms
configured independently by those members. The purpose of this
specification is to assign one unambiguous term to this complete set
of service properties. It does not define a new tunneling, routing,
or cryptographic protocol, and use of a VPN or tunnel is not required
for WPN conformance.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 11 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kafara Expires 11 April 2027 [Page 1]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement and Terminology Gap . . . . . . . . . . . . 3
2.1. Why "VPN Without a Default Route" Is Not a Definition . . 4
2.2. Service Semantics Rather Than Implementation . . . . . . 4
3. Scope and Applicability . . . . . . . . . . . . . . . . . . . 4
4. Conventions and Requirements Language . . . . . . . . . . . . 5
5. WPN Conformance Requirements . . . . . . . . . . . . . . . . 5
5.1. One Logical Private IP Connectivity Domain . . . . . . . 5
5.2. Explicit Membership and Address Uniqueness . . . . . . . 6
5.3. Defined WPN Address Space . . . . . . . . . . . . . . . . 6
5.4. NAT-Free Member-to-Member Communication . . . . . . . . . 6
5.5. Protocol-Transparent Member Connectivity . . . . . . . . 7
5.6. No WPN-Provided General-Purpose Internet Egress . . . . . 7
5.7. Underlay Independence . . . . . . . . . . . . . . . . . . 8
5.8. Member-Side Networks Are Outside the Base WPN . . . . . . 8
5.9. Isolation Between Independent WPNs . . . . . . . . . . . 8
5.10. Naming Services Are Optional . . . . . . . . . . . . . . 8
6. Addressing Model . . . . . . . . . . . . . . . . . . . . . . 9
7. Routing and Reachability . . . . . . . . . . . . . . . . . . 9
8. Optional Naming and Service Discovery . . . . . . . . . . . . 10
9. Transport Underlay and Protection . . . . . . . . . . . . . . 10
10. MTU and Nested Encapsulation . . . . . . . . . . . . . . . . 10
11. Relationship to Existing Terms and Architectures . . . . . . 11
11.1. Private Addressing . . . . . . . . . . . . . . . . . . . 11
11.2. Virtual Private Networks . . . . . . . . . . . . . . . . 11
11.3. Provider-Provisioned VPNs and Closed User Groups . . . . 11
11.4. LANs and Intranets . . . . . . . . . . . . . . . . . . . 12
11.5. Walled Gardens . . . . . . . . . . . . . . . . . . . . . 12
12. Operational Considerations . . . . . . . . . . . . . . . . . 12
13. Reference Deployment Examples . . . . . . . . . . . . . . . . 13
13.1. Central Service Node over a Public Underlay . . . . . . 13
13.2. Private LAN as a WPN . . . . . . . . . . . . . . . . . . 13
13.3. Member-Side Network Interconnection over a WPN . . . . . 14
14. Security Considerations . . . . . . . . . . . . . . . . . . . 14
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
16.1. Normative References . . . . . . . . . . . . . . . . . . 16
Kafara Expires 11 April 2027 [Page 2]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
16.2. Informative References . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
1. 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.
2. 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".
Kafara Expires 11 April 2027 [Page 3]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
2.1. 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.
2.2. 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.
3. 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.
Kafara Expires 11 April 2027 [Page 4]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
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.
4. 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 ([RFC2119],
[RFC8174]) 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.
5. WPN Conformance Requirements
5.1. 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.
Kafara Expires 11 April 2027 [Page 5]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
5.2. 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.
5.3. 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.
5.4. 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.
Kafara Expires 11 April 2027 [Page 6]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
5.5. 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.
5.6. 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.
Kafara Expires 11 April 2027 [Page 7]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
5.7. 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.
5.8. 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.
5.9. 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.
5.10. 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.
Kafara Expires 11 April 2027 [Page 8]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
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.
6. 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 [RFC1918].
IPv6 deployments SHOULD normally use Unique Local IPv6 Unicast
Addresses as defined by [RFC4193] 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.
7. 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.
Kafara Expires 11 April 2027 [Page 9]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
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.
8. 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.
9. 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.
10. 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 [RFC4459] are relevant.
Kafara Expires 11 April 2027 [Page 10]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
Path MTU Discovery for IPv4 and IPv6 is described in [RFC1191] and
[RFC8201], 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.
11. Relationship to Existing Terms and Architectures
11.1. Private Addressing
[RFC1918] 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.
11.2. Virtual Private Networks
[RFC4026] 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.
11.3. Provider-Provisioned VPNs and Closed User Groups
[RFC4110] describes a framework for Layer 3 provider-provisioned
VPNs, and [RFC4364] 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.
Kafara Expires 11 April 2027 [Page 11]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
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.
11.4. 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.
11.5. 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.
12. 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.
Kafara Expires 11 April 2027 [Page 12]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
* 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.
13. Reference Deployment Examples
13.1. Central Service Node over a Public Underlay
Public Internet or other underlay
(protected transport)
|
+-----+-----+
| WPN |
| Service |
| Node |
+-----+-----+
|
WPN 10.70.20.0/24
|
+---------------+---------------+
| | |
10.70.20.10 10.70.20.20 10.70.20.30
Member A Member B Member C
\_______________|_______________/
protocol-transparent IP
no member-to-member NAT
no WPN Internet egress
Figure 1
This is a non-normative example. A central service node, public
endpoint, tunnel, and the example prefix are implementation choices,
not WPN requirements.
13.2. Private LAN as a WPN
Kafara Expires 11 April 2027 [Page 13]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
Private LAN 10.80.0.0/24
+-------------+-------------+-------------+
| | | |
10.80.0.10 10.80.0.20 10.80.0.30 10.80.0.40
Member A Member B Member C Member D
no member-to-member NAT
protocol-transparent member connectivity
no WPN-provided Internet egress
Figure 2
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.
13.3. Member-Side Network Interconnection over a WPN
LAN A LAN B
192.168.10.0/24 192.168.20.0/24
| |
Member A Member B
10.70.20.10 10.70.20.20
\ /
+------------ WPN 10.70.20.0/24 ------------+
outer connectivity: A <-> B
|
nested tunnel or other
member-configured mechanism
|
inner routing: LAN A <-> LAN B
Figure 3
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.
14. Security Considerations
The VPN isolation considerations in [RFC4111] 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.
Kafara Expires 11 April 2027 [Page 14]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
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.
15. 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.
16. References
Kafara Expires 11 April 2027 [Page 15]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
16.2. Informative References
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
DOI 10.17487/RFC1191, November 1990,
<https://www.rfc-editor.org/info/rfc1191>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026,
DOI 10.17487/RFC4026, March 2005,
<https://www.rfc-editor.org/info/rfc4026>.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, DOI 10.17487/RFC4110, July 2005,
<https://www.rfc-editor.org/info/rfc4110>.
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
DOI 10.17487/RFC4111, July 2005,
<https://www.rfc-editor.org/info/rfc4111>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
2006, <https://www.rfc-editor.org/info/rfc4459>.
Kafara Expires 11 April 2027 [Page 16]
Internet-Draft Walled Private Network (WPN) Service Def October 2026
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Author's Address
Martin Kafara
Wardfold s.r.o.
Email: kafara@wardfold.com, martin.kafara@innc.cz
URI: https://wardfold.com/
Kafara Expires 11 April 2027 [Page 17]