Professional Cloud Network Engineer

Configure Cloud Router, BGP, and Hybrid IPv6 Connectivity

Cloud Router provides dynamic Border Gateway Protocol (BGP) routing between a Virtual Private Cloud (VPC) network and on-premises networks across Dedicated Interconnect or Cloud VPN. To exchange IPv6 routes across hybrid attachments, Cloud Router can establish separate, dedicated IPv4 and IPv6 BGP sessions or use Multi-Protocol BGP (MP-BGP) to exchange both IPv4 and IPv6 address families within a single BGP session. While MP-BGP simplifies management by consolidating routing updates into one session, separate BGP sessions allow administrators to apply distinct routing policies and access controls to each protocol family.

Cloud Router BGP Session Configuration

Cloud Router uses standardized timer settings to maintain session health and ensure fast convergence during network disruptions. Default BGP timers require a keepalive interval of 20 seconds and a hold timer of 60 seconds. When graceful restart is enabled, the stalepath timer is set to 300 seconds, which instructs the on-premises peer to preserve learned routes during temporary Cloud Router maintenance restarts instead of dropping packets. To achieve sub-second fault detection, administrators can enable Bidirectional Forwarding Detection (BFD) on the BGP session with a minimum receive and transmit interval of 1000 milliseconds and a detection multiplier of 5.

Cloud Interconnect and On-Premises Router Setup

Dual-stack connectivity over Dedicated Interconnect requires creating a VLAN attachment configured with a dual-stack (IPv4 and IPv6) stack type. The attachment allocates standard IPv4 link-local peering addresses from 169.254.0.0/16, while IPv6 BGP peering uses globally unique addresses configured with a /125 or /126 mask using candidate IPv6 address flags. Maximum transmission unit (MTU) sizes can be set to 1440, 1460, 1500, or 8896 bytes, provided that every device along the path shares the identical MTU value. Dual-stack VLAN attachments are not supported for Partner Interconnect or High Availability (HA) VPN over Cloud Interconnect deployments.

The on-premises router must support 802.1Q VLAN tagging and Link Aggregation Control Protocol (LACP) for port channels, even when terminating on a single physical circuit. When the VLAN attachment uses Dataplane version 1, the on-premises router must be configured with External BGP (EBGP) multi-hop set to a value of 4; Dataplane version 2 or higher handles peering directly without requiring multi-hop. To prevent routing conflicts, the on-premises network and the VPC network must maintain non-overlapping IP address spaces before routes are dynamically advertised according to the VPC network's dynamic routing mode.

Design Dual-Stack VPC Subnets and GKE Cluster Address Allocation

Dual-stack Google Kubernetes Engine (GKE) networking enables simultaneous IPv4 and IPv6 communication across nodes, Pods, and Services without the processing overhead of translation or encapsulation. GKE dual-stack support requires VPC-native clusters configured with GKE Dataplane V2 on subnets within custom mode VPC networks, as auto-mode VPC networks do not support IPv6 address allocation. Dual-stack clusters introduce operational constraints: they consume additional memory per node compared to IPv4-only clusters, do not support Windows Server node pools, and cannot use Private Google Access over IPv6.

IPv6 Address Allocation Architecture

Google Cloud and GKE use a rigid, hierarchical subnet allocation model to distribute IPv6 address space across cluster components. Each dual-stack VPC subnet is assigned a primary /64 IPv6 range by Google Cloud:

• Nodes receive a primary /96 IPv6 range carved directly out of the subnet's /64 primary range.
• Pods on a given node receive their addresses from a /112 subnet carved out of that specific node's /96 allocation, resulting in a discontiguous overall cluster Pod range.
• Services receive a /112 range allocated from a Google-managed /64 reservation (2600:2d00:0:4::0:0/64), supporting ClusterIP, NodePort, and LoadBalancer Service types.

VPC Subnet Primary Range (/64)
  │
  └── Node Primary Allocation (/96 per node)
        │
        └── Node Pod Allocation (/112 per node)

Google-Managed Service Range (2600:2d00:0:4::0:0/64)
  │
  └── Cluster Services Allocation (/112)

IPv6 Access Types and Shared Ranges

GKE cluster IPv6 reachability is determined at creation time by the ipv6-access-type configuration parameter. Setting the access type to EXTERNAL assigns globally routable public addresses from the Google prefix 2600:1900/28. Setting the access type to INTERNAL assigns private Unique Local Addresses (ULA) from fd20::/20 (within fc00::/7). Clusters using internal IPv6 addresses cannot communicate with the public internet over IPv6 because Cloud NAT does not support IPv6 translation.

To simplify subnet architecture in Shared VPC environments, multiple GKE clusters within the same subnet can share the primary IPv4 node range, secondary IPv4 Pod ranges, and secondary IPv4 Services ranges. Pod ranges can only be shared if explicitly declared using the cluster secondary range flag during creation, and Services ranges must be user-managed rather than Google-managed. Sharing ranges introduces capacity dependencies where rapid scaling in one cluster can exhaust available IP allocations and block node or Pod provisioning in peer clusters.

Implement IPv6 Traffic Management, Load Balancing, and Firewall Security

Google Cloud directs and secures IPv6 traffic by combining proxy or passthrough load balancers with stateful VPC firewall rules. Proxy load balancers terminate client IPv6 connections at the edge and initiate new sessions to backends, whereas passthrough load balancers route intact IPv6 packets directly to cluster nodes. Cloud DNS supports dual-stack routing to these endpoints by resolving IPv6 AAAA records for cluster-internal and external domain names.

IPv6 Load Balancing Architectures

Global external Application Load Balancers and global external proxy Network Load Balancers terminate incoming IPv6 traffic on a global forwarding rule provisioned with a /64 address range. The proxy preserves the original client IP address in the X-Forwarded-For header and uses its configured IP address selection policy to open a new connection to backend zonal network endpoint groups (NEGs) or instance groups over IPv4 or IPv6. Regional external and internal proxy load balancers accept IPv4 client traffic on the frontend and route to dual-stack backends over IPv6 by traversing a regional proxy-only subnet.

Passthrough load balancers preserve end-to-end packet headers from the client directly to the backend instances. Internal and external passthrough Network Load Balancers assign a /96 range to their IPv6 forwarding rules, and GKE automatically configures backend nodes to accept traffic matching the first /128 address within that allocated range.

Client (IPv6)
  │
  ▼
Global External Proxy Load Balancer (/64 Forwarding Rule)
  │ (Terminates connection, inserts X-Forwarded-For)
  │
  ▼ [New IPv4 or IPv6 session via IP address selection policy]
GKE Backend Pods / Zonal NEGs

VPC Firewall Security and Health Check Rules

VPC firewall rules evaluate IPv6 traffic statefully, allowing matching return traffic automatically while enforcing a default deny stance on all incoming connections. Administrators must define ingress allow rules targeting backend virtual machines by network tag to permit traffic from proxy-only subnets, client networks, and automated health checking infrastructure.

Health checks verify backend availability before the load balancer forwards requests. If firewall rules block probe traffic, backends enter an unhealthy state and traffic distribution stops. Google Cloud uses dedicated IPv6 probe ranges that must be allowed through ingress rules:

• Global external Application and Network Load Balancers require ingress allow rules from 2600:2d00:1:b029::/64 and 2600:2d00:1:1::/64.
• Regional external, regional internal, and cross-region internal load balancers require ingress allow rules from 2600:2d00:1:b029::/64.

Key Facts

• Google Kubernetes Engine (GKE) dual-stack networking requires VPC-native clusters configured with GKE Dataplane V2 on custom mode Virtual Private Cloud (VPC) subnets.
• In dual-stack GKE clusters, each node receives a /96 primary IPv6 range from the subnet's /64 allocation, and Pods receive a /112 range carved from that node's /96 allocation.
• Clusters configured with the INTERNAL IPv6 access type use Unique Local Addresses (ULA) from fd20::/20 and cannot access the public internet because Cloud NAT does not support IPv6.
• Global external proxy load balancers terminate client IPv6 traffic on a /64 forwarding rule, preserve the client address in the X-Forwarded-For header, and require ingress firewall rules from health check probe ranges 2600:2d00:1:b029::/64 and 2600:2d00:1:1::/64.
• Dedicated Interconnect supports dual-stack VLAN attachments using Multi-Protocol BGP (MP-BGP) or separate BGP sessions, but dual-stack VLAN attachments are not supported on Partner Interconnect or High Availability (HA) VPN over Interconnect.

Frequently Asked Questions

What happens to on-premises connectivity when Cloud Router restarts for maintenance?

When graceful restart is enabled on Cloud Router, the stalepath timer maintains route entries on the on-premises router for up to 300 seconds. This allows the data path to continue forwarding packets without route withdrawal or packet drops while the Cloud Router BGP process restarts.

How does IPv6 address allocation for Pods differ from IPv4 in dual-stack GKE clusters?

In IPv4, GKE allocates Pod IP addresses from a unified secondary subnet range shared across the cluster. In IPv6, GKE allocates each node a /96 range from the primary subnet /64 range, and Pods receive their /112 addresses directly from their specific host node's /96 allocation, resulting in a discontiguous Pod address layout.

Why can internal IPv6 GKE workloads not reach the public internet?

Workloads with the internal IPv6 access type receive non-routable Unique Local Addresses from fd20::/20. Because Cloud NAT only translates IPv4 traffic and does not support IPv6 address translation, internal IPv6 packets cannot be rewritten to a public IP address to traverse the internet.