Home › Docs › What are Typical IPv6 Routing Policies?

What are Typical IPv6 Routing Policies?

IPv6 routing policies are fundamental to maintaining a scalable, secure, and efficient global Internet routing infrastructure. As IPv6 deployment continues to accelerate in 2025—with over half of all routes now covered by RPKI ROAs—understanding and implementing proper routing policies has become essential for network operators, ISPs, and enterprises alike.

Overview of IPv6 BGP Routing Policies

Border Gateway Protocol (BGP) routing policies for IPv6 share many principles with IPv4 but incorporate unique considerations based on IPv6's vast address space and architectural differences. A well-designed IPv6 routing policy framework addresses prefix filtering, route aggregation, security validation, traffic engineering, and multi-homing strategies.

The IPv6 BGP routing table has shown steady growth, with approximately 20,000 new routes added in 2024 alone—a 10% increase in routing entries. This growth underscores the importance of maintaining disciplined routing policies to prevent routing table bloat and ensure optimal performance.

BGP Import and Export Policies

Import Policies (Inbound Filtering)

Import policies control which routes your network accepts from BGP peers. A robust IPv6 import policy should include:

Prefix Length Filtering: Accept only prefixes within acceptable length ranges. The minimum globally routable IPv6 prefix is /48, and best practice dictates rejecting more specific announcements (longer than /48) unless explicitly required for traffic engineering purposes.

Bogon Filtering: Reject reserved, documentation, and invalid IPv6 address space including:

Own Prefix Rejection: Never accept your own prefixes from peers, as this indicates either a configuration error or a potential hijacking attempt.

IANA-Allocated Space Validation: Accept only prefixes derived from IANA-allocated IPv6 address space. This list should be dynamically maintained and regularly updated to reflect new allocations.

Export Policies (Outbound Filtering)

Export policies determine which routes you advertise to BGP neighbors:

Selective Advertisement: Only announce prefixes you are authorized to originate. This typically includes your provider-independent (PI) allocations or provider-assigned (PA) address space.

Private Address Filtering: Never advertise Unique Local Addresses (ULA) fc00::/7 or link-local addresses fe80::/10 to external peers.

Default Route Control: Avoid re-advertising default routes (::::/0) unless you are intentionally providing transit services.

Route Aggregation: Where possible, aggregate more specific prefixes into summary routes to minimize the global routing table size.

Prefix Filtering Best Practices

Minimum Prefix Length: /48

The /48 prefix length represents the cornerstone of IPv6 routing policy. This minimum is recommended for several reasons:

  1. Routing Table Scalability: Accepting more specific prefixes (e.g., /64 or longer) would cause exponential growth in the global routing table
  2. RIR Allocation Policies: Most Regional Internet Registries assign /48 as the minimum allocation to end sites
  3. Statistical Prevalence: Currently, 46% of all IPv6 prefixes in the global routing table are /48s, making this the de facto standard

Configuration Examples

Cisco IOS IPv6 Prefix Filtering:

! Define prefix-list to deny overly specific prefixes
ipv6 prefix-list DENY-LONG-PREFIXES seq 5 deny ::/0 ge 49 le 128

! Define prefix-list to permit acceptable prefixes
ipv6 prefix-list ACCEPT-VALID-PREFIXES seq 10 permit ::/0 ge 1 le 48

! Define bogon filter prefix-list
ipv6 prefix-list BOGONS seq 10 deny 2001:db8::/32
ipv6 prefix-list BOGONS seq 20 deny fc00::/7
ipv6 prefix-list BOGONS seq 30 deny fe80::/10
ipv6 prefix-list BOGONS seq 40 deny ff00::/8
ipv6 prefix-list BOGONS seq 50 permit ::/0 le 48

! Apply to BGP neighbor
router bgp 64500
 address-family ipv6 unicast
  neighbor 2001:db8:0:1::1 remote-as 64501
  neighbor 2001:db8:0:1::1 activate
  neighbor 2001:db8:0:1::1 prefix-list ACCEPT-VALID-PREFIXES in
  neighbor 2001:db8:0:1::1 prefix-list BOGONS in

Juniper JunOS IPv6 Prefix Filtering:

# Define prefix-list for valid prefix lengths
policy-options {
    prefix-list ipv6-valid-prefixes {
        ::/0;
    }
    policy-statement IMPORT-IPV6-POLICY {
        term reject-long-prefixes {
            from {
                route-filter ::/0 prefix-length-range /49-/128;
            }
            then reject;
        }
        term reject-bogons {
            from {
                route-filter 2001:db8::/32 orlonger;
                route-filter fc00::/7 orlonger;
                route-filter fe80::/10 orlonger;
                route-filter ff00::/8 orlonger;
            }
            then reject;
        }
        term accept-valid {
            from {
                route-filter ::/0 prefix-length-range /1-/48;
            }
            then accept;
        }
    }
}

# Apply policy to BGP session
protocols {
    bgp {
        group external-peers {
            family inet6 {
                unicast;
            }
            import IMPORT-IPV6-POLICY;
            neighbor 2001:db8:0:1::1 {
                peer-as 64501;
            }
        }
    }
}

[Route Aggregation Strategies](ipv6-with-bgp)

Route aggregation is critical for IPv6 scalability, yet it presents unique challenges in multi-homed environments.

[Provider-Aggregatable (PA) Addresses](ipv6-address-types)

The IETF strongly encourages the use of provider-aggregatable address space, where ISPs can aggregate customer routes within their own allocated blocks. This approach:

Aggregation Challenges with Multi-homing

Multi-homed organizations reduce aggregation effectiveness because they must advertise their prefixes through multiple providers. When a customer uses a single provider-independent (PI) prefix announced by multiple upstream ISPs, aggregation at the provider level becomes impossible.

Multiple PA Prefix Strategy

An emerging best practice involves assigning multiple provider-aggregatable prefixes to multi-homed sites instead of a single PI prefix. Benefits include:

Multi-homing Considerations

Architectural Approaches

RFC 4177 outlines several architectural approaches to IPv6 multi-homing:

  1. Multiple PA Prefixes: Each upstream provider assigns an aggregatable prefix to the customer
  2. Provider-Independent (PI) Addressing: Customer obtains a PI allocation from an RIR
  3. Geographic/Topological Multi-homing: Different sites use different providers

BGP Policy for Multi-homing

Multi-homed organizations typically implement:

AS Path Prepending: Manipulate inbound traffic by making certain paths appear less attractive:

! Cisco IOS example - prepend AS path for traffic engineering
route-map PREPEND-PATH permit 10
 set as-path prepend 64500 64500 64500

router bgp 64500
 neighbor 2001:db8:1::1 route-map PREPEND-PATH out

Community-Based Traffic Engineering: Use BGP communities to signal desired treatment to upstream providers (covered in detail below).

Local Preference Manipulation: Control outbound traffic by adjusting local preference values for routes learned from different providers.

[Provider-Independent vs Provider-Assigned Addressing](ipv6-address-types)

Provider-Independent (PI) Allocations

Characteristics:

Eligibility Requirements (APNIC/AFRINIC/LACNIC):

Routing Implications:

Provider-Assigned (PA) Allocations

Characteristics:

Best Use Cases:

Allocation Guidelines:

[Community Tagging and Traffic Engineering](ipv6-with-bgp)

BGP communities provide a powerful mechanism for traffic engineering and dynamic policy control without requiring prefix-based policy updates.

Community Attribute Basics

The BGP community attribute (RFC 1997) is a transitive optional attribute used to tag prefixes sharing common properties. Communities enable:

Common Community Applications

Path Manipulation:

Customers can signal desired BGP parameter changes to their service providers by tagging announcements with specific community values. Common applications include:

Geographic/Topology Control:

Configuration Examples

Cisco IOS - Tagging Routes with Communities:

! Define community list
ip community-list standard CUSTOMER-TAG permit 64500:100

! Create route-map to set community
route-map SET-COMMUNITY permit 10
 match ipv6 address prefix-list CUSTOMER-PREFIXES
 set community 64500:100

! Apply to BGP neighbor
router bgp 64500
 address-family ipv6 unicast
  neighbor 2001:db8:1::1 send-community
  neighbor 2001:db8:1::1 route-map SET-COMMUNITY out

Juniper JunOS - Community-Based Local Preference:

policy-options {
    community high-pref members 64500:100;

    policy-statement COMMUNITY-LOCALPREF {
        term match-high-pref {
            from community high-pref;
            then {
                local-preference 200;
                accept;
            }
        }
    }
}

protocols {
    bgp {
        group customers {
            import COMMUNITY-LOCALPREF;
        }
    }
}

Provider-Published Community Values

ISPs typically publish their supported community values on their websites or through peering databases. Network operators should consult provider documentation to understand available traffic engineering options.

[RPKI](announce-ipv6-prefixes-bgp) and Route Security

Resource Public Key Infrastructure (RPKI) has emerged as the cryptographic foundation for BGP route security, with major growth in 2024-2025.

Current Deployment Status (2025)

[Route Origin Authorization (ROA)](announce-ipv6-prefixes-bgp)

A ROA is a cryptographically signed object that authorizes a specific Autonomous System to originate a specific IP prefix. ROAs specify:

  1. Prefix: The IP address block (e.g., 2001:db8::/32)
  2. Maximum Length: The most specific prefix length allowed (e.g., /48)
  3. Origin AS: The AS number authorized to originate the prefix

ROA Validation States

Route Origin Validation (ROV) categorizes BGP announcements as:

Valid: The route matches a ROA with correct AS and prefix length within the specified maximum length.

Invalid: One of the following conditions exists:

Not Found: No ROA exists for the prefix (unknown validity).

RPKI Best Practices (2025)

ROA Creation Guidelines:

ROV Implementation Stages:

  1. Monitor: Enable ROV validation and log results without enforcement
  2. Tag: Mark routes as valid/invalid/unknown using communities
  3. Deprioritize: Lower local preference for invalid routes
  4. Communicate: Notify customers of invalid announcements
  5. Drop: Reject invalid routes entirely

Configuration Examples

Cisco IOS - RPKI Validation:

! Configure RPKI cache server
router bgp 64500
 bgp rpki server tcp 192.0.2.1 port 8282 refresh 600

! Create route-map for validation
route-map RPKI-VALIDATE permit 10
 match rpki valid
 set local-preference 200

route-map RPKI-VALIDATE permit 20
 match rpki not-found
 set local-preference 100

route-map RPKI-VALIDATE permit 30
 match rpki invalid
 set local-preference 50

! Apply to BGP neighbor
router bgp 64500
 address-family ipv6 unicast
  neighbor 2001:db8:1::1 route-map RPKI-VALIDATE in

Juniper JunOS - RPKI Validation:

routing-options {
    validation {
        group rpki-validators {
            session 192.0.2.1 {
                port 8282;
            }
        }
    }
}

policy-options {
    policy-statement RPKI-POLICY {
        term valid-routes {
            from {
                protocol bgp;
                validation-database valid;
            }
            then {
                local-preference 200;
                accept;
            }
        }
        term invalid-routes {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then {
                local-preference 50;
                reject;
            }
        }
    }
}

Policy Examples for Different Scenarios

Scenario 1: Small Enterprise (Single-Homed)

Requirements:

Policy Framework:

! Accept only default route from provider
ipv6 prefix-list FROM-PROVIDER permit ::/0

! Advertise only own prefix
ipv6 prefix-list TO-PROVIDER permit 2001:db8:1000::/48

router bgp 64500
 neighbor 2001:db8:fff::1 remote-as 64501
 address-family ipv6 unicast
  neighbor 2001:db8:fff::1 prefix-list FROM-PROVIDER in
  neighbor 2001:db8:fff::1 prefix-list TO-PROVIDER out
  neighbor 2001:db8:fff::1 default-originate

Scenario 2: Medium Enterprise (Dual-Homed)

Requirements:

Policy Framework:

! Primary provider - normal path
route-map TO-PRIMARY permit 10
 match ipv6 address prefix-list OWN-PREFIX
 set community 64500:100

! Secondary provider - prepend for less preferred path
route-map TO-SECONDARY permit 10
 match ipv6 address prefix-list OWN-PREFIX
 set as-path prepend 64500 64500
 set community 64500:200

router bgp 64500
 neighbor 2001:db8:1::1 remote-as 64501
 neighbor 2001:db8:2::1 remote-as 64502
 address-family ipv6 unicast
  neighbor 2001:db8:1::1 route-map TO-PRIMARY out
  neighbor 2001:db8:2::1 route-map TO-SECONDARY out

Scenario 3: [ISP](isp-ipv6-deployment-status) with Customer Routes

Requirements:

Policy Framework:

! Aggregate customer routes
ipv6 prefix-list CUSTOMERS permit 2001:db8::/32 le 48

! Accept from customers with validation
route-map FROM-CUSTOMERS permit 10
 match ipv6 address prefix-list CUSTOMERS
 match rpki valid
 set local-preference 200

route-map FROM-CUSTOMERS deny 20
 match rpki invalid

! Export aggregate and customer routes
ipv6 prefix-list TO-TRANSIT permit 2001:db8::/32
ipv6 prefix-list TO-TRANSIT permit 2001:db8::/32 le 48

route-map TO-TRANSIT permit 10
 match ipv6 address prefix-list TO-TRANSIT

Testing and Validation

After implementing IPv6 routing policies, comprehensive testing is essential to ensure connectivity and optimal performance.

Connectivity Testing

Test-ipv6.run provides a comprehensive IPv6 connectivity testing platform that validates:

Network operators should regularly test their IPv6 connectivity from various vantage points to ensure routing policies are functioning correctly and not inadvertently blocking legitimate traffic.

Monitoring Best Practices

  1. Route Acceptance Monitoring: Track the number of accepted vs. rejected routes
  2. RPKI Validation Metrics: Monitor valid/invalid/not-found ratios
  3. BGP Session Stability: Track flapping and session resets
  4. Traffic Flow Analysis: Verify traffic engineering policies achieve desired results
  5. Prefix Hijacking Detection: Alert on unexpected origin AS changes

Conclusion

IPv6 routing policies form the foundation of a secure, scalable, and efficient Internet routing infrastructure. As IPv6 adoption accelerates toward majority status in 2025, implementing robust routing policies has become non-negotiable for network operators.

Key takeaways include:

By following these best practices and adapting policies to your specific network requirements, you can ensure optimal IPv6 routing performance while contributing to the overall health and security of the global Internet routing system.

For comprehensive IPv6 connectivity testing and validation, visit test-ipv6.run to check your network's IPv6 readiness with real-time testing of dual-stack operation, protocol preference, and latency measurements.