docs(vpc-peering): add features and limitations page

pages/vpc-peering/menu.ts

@@ -32,6 +32,10 @@ export const vpcPeeringMenu = {
           label: 'Understanding VPC Peering',
           slug: 'understanding-vpc-peering',
         },
+        {
+          label: 'Features and limitations',
+          slug: 'features-limitations',
+        },
         {
           label: 'VPC Peering statuses',
           slug: 'statuses',

pages/vpc-peering/reference-content/features-limitations.mdx

@@ -0,0 +1,62 @@
+---
+title: VPC Peering features and limitations
+description: This page presents the different features and limitations of Scaleway VPC Peering.
+tags: vpc-peering features limitations specs quota transitivity dhcp technical datasheet
+dates:
+  creation: 2026-04-10
+  validation: 2026-04-10
+---
+
+<Message type="note">
+VPC Peering is currently in Public Beta, and available only via the [Scaleway API](https://www.scaleway.com/en/developers/api/vpc/).
+</Message>
+
+This page lists the different features and limitations of Scaleway VPC Peering.
+
+## Features
+
+### Cross-project and cross-organization peering
+
+VPC Peering lets you connect any two Scaleway VPCs, whether they belong to the same Project or Organization, or to different ones. There is no requirement for the two VPCs to share any common ownership or management.
+
+### Mutual consent security model
+
+Peering connections are always mutually consented. An owner or manager of each VPC must independently create a [peering connector](/vpc-peering/concepts/#peering-connector) towards the other. If only one side creates a connector, it remains in an `Orphan` state and no connection is established. No requests or notifications are sent between Organizations.
+
+### Fine-grained traffic control via custom routes
+
+Once two VPCs are peered, you control exactly which traffic flows across the peering connection by creating [custom routes](/vpc/how-to/manage-routing/#how-to-create-a-custom-route). Routes support both IPv4 and IPv6, and each side independently manages its own routing configuration.
+
+### Transitive peering
+
+VPC Peering natively supports transitive peering. This means that VPC A can communicate with VPC C via an intermediate VPC B (A ↔ B ↔ C), even without a direct peering connector between A and C. Transitivity requires custom routes to be configured in each VPC of the chain.
+
+### Unlimited traffic
+
+Once a peering connection is established, there are no caps or rate limits on the traffic flowing across it.
+
+## Limitations
+
+### Same-region requirement
+
+Two VPCs can only be peered if they are located in the same Scaleway region. Cross-region peering is not supported.
+
+### No overlapping CIDR blocks
+
+For peering to be established, none of the CIDR blocks attributed to Private Networks in one VPC may overlap with those in the other VPC. If an overlap is detected, both connectors enter a `Conflict` state. Since CIDR blocks cannot be modified after a Private Network is created, conflicting Private Networks must be deleted and recreated with non-overlapping CIDR ranges. See our [troubleshooting guide](/vpc-peering/troubleshooting/resolving-peering-conflicts/) for more details.
+
+### Custom routes are not created automatically
+
+Traffic does not flow between two peered VPCs automatically. You must manually create custom routes on each side to define the IP ranges that should be routed across the peering connection.
+
+### DHCP route propagation delay
+
+When a new custom route is added to a VPC's route table, it is not propagated immediately to attached resources via DHCP. Resources will receive the updated routing information only upon their next DHCP lease renewal, which can take up to 1 hour.
+
+### Routing must be activated on older VPCs
+
+VPCs created before routing was introduced must have [routing activated](/vpc/how-to/manage-routing/#how-to-activate-routing) before a peering connection can be successfully established.
+
+### Target VPC ID required
+
+When creating a peering connector, you must specify the exact VPC ID of the target VPC. No additional information about the target VPC (such as its network topology or resources) is disclosed during the process.