Service Provider IPv6 Deployment

These are my study notes regarding IPv6 deployment in SP networks in preparation for the CCDE exam.

Drivers for implementing IPv6

• External drivers
  • SP customers that need access to IPv6 resources
  • SP customers that need to interconnect their IPv6 sites
  • SP customers that need to interface with their own customers over iPv6
• Internal drivers
  • Handle problems that may be hard to fix with IPv4 such as large number of devices (cell phones, IP cameras, sensors etc)
  • Public IPv4 address exhaustion
  • Private IPv4 address exhaustion
• Strategic drivers
  • Long term expansion plans and service offerings
  • Preparing for new services and gaining competitive advantage

Infrastructure

• SP Core Infrastructure
  • Native IPv4 core
  • L2TPv3 for VPNs
  • MPLS core
  • MPLS VPNs

My reflection is that most cores would be MPLS enabled, however there are projects such as Terastream in Deutsche Telekom where the entire core is IPv6 enabled and L2TPv3 is used in place of MPLS.

• IPv6 in Native IPv4 Environments
  • Tunnel v6 in v4
  • Native v6 with dedicated resources
  • Dual stack

The easiest way to get going with v6 was to tunnel it over v4. The next logical step was to enable v6 but on separate interfaces to not disturb the “real” traffic and to be able to experiment with the protocol. The end goal is dual stack, at least in a non MPLS enabled network.

• IPv6 in MPLS environments
  • 6PE
  • 6VPE

6PE is a technology to run IPv6 over an IPv4 enabled MPLS network. 6VPE does the same but with VRFs.

• Native IPv6 over Dedicated Data Link
  • Dedicated data links between core routers
  • Dedicated data links to IPv6 customers
  • Connection to an IPv6 IX
• Dual stack
  • All P + PE routers capable of v4 + v6 transport
  • Either two IGPs or one IGP for both v4 + v6
  • Requires more memory due to two routing tables
  • IPv6 multicast natively supported
  • All IPv6 traffic is routed in global space (no MPLS)
  • Good for content distribution and global services (Internet)

• 6PE
  • IPv6 global connectivity over an IPv4 MPLS core
  • Transition mechanism (debatable)
  • PEs are dual stacked and need 6PE configuration
  • IPv6 reachability exchanged via MPBGP over iBGP sessions
  • IPv6 packets transported from 6PE to 6PE inside MPLS
  • The next-hop is an IPv4 mapped IPv6 address such as ::FFFF:1.1.1.1
  • BGP label assigned for the IPv6 prefix
  • Bottom label used due to P routers not v6 capable and for load sharing
  • neighbor send-label is configured under BGP address-family ipv6

6PE is viewed as a transition mechanism but this is arguable, if you transport IPv4 over MPLS, you may want to do the same with IPv6 as well for consistency. Running 6PE means that there is fate sharing between v4 and v6 though, which could mean that an outage may affect both protocols. This could be avoided by running MPLS for IPv4 but v6 natively.

• Core network (P routers) left untouched
• IPv6 traffic inherits MPLS benefits such as fast-reroute and TE
• Incremental deployment possible (upgrade PE routers first)
• Each site can be v4-only, v4-VPN-only, v4+v6, v4-VPN+v6 and so on
• Scalability concerns due to separate RIB and FIB required per customer
• Mostly suitable for SPs with limited amount of PEs

• 6vPE
  • Equivalent of VPNv4 but for IPv6
  • Add VPNv6 address family under MPBGP
  • Send extended communities for the prefixes under the address family

It is a common misconception for 6PE and 6vPE that traceroutes are not possible, that is however not entirely true. A P router can generate ICMPv6 messages that will follow the LSP to the egress PE and then the ICMPv6 error message is forwarded back to the originator of the traceroute.

• Route reflectors for 6PE and 6vPE
  • Needed to scale BGP full mesh
  • Dedicated RRs or data path RRs
  • Either dedicated RR per AF or have multiple AFs per RR
  • 6PE-RR must support IPv6 + label functionality
  • 6vPE-RR must support IPv6 + label and extended communities functionality

PA vs PI

• PA advantages
  • Aggregation towards upstreams
  • Minimizes Internet routing table size
• PA disadvantages
  • Customer is “locked” with the SP
  • Renumbering can be painful
  • Multi-homing and TE problems

The main driver here is if you are going to multi home or not. Renumbering is always painful but at least less so on IPv6 due to being able to advertise multiple IPv6 prefixes through Router Advertisements (RA).

• PI advantages
  • Customers are not “locked” to the SP
  • Multi homing is straight forward
• PI disadvantages
  • Larger Internet routing table due to lack of efficient aggregation
  • Memory and CPU needs on BGP speakers

Infrastructure Addressing (LLA vs global)

What type of addresses should be deployed on infrastructure links?

• Link Local Address FE80::/10
  • Non routeable address
  • Less attack surface
  • Smaller routing tables
  • Can converge faster due to smaller RIB/FIB
  • Less need for iACL at edge of network
  • Can’t ping links
  • Can’t traceroute links
  • May be more complex to manage with NMS
  • Use global address on loopback for ICMPv6 messages
  • Will not work with RSVP-TE tunnels
• Global only 2000::/3 (current IANA prefix)
  • Globally routeable
  • Larger attack surface unless prefix suppression is used
  • Use uRPF and iACL at edge to protect your links
  • Easier to manage

It would be interesting to hear if you have seen any deployments with LLA only on infrastructure links. In theory it’s a nice idea but it may corner you in some cases, preventing you from implementing other features that you wish to deploy in your network.

Use /126 or /127 on P2P links which is the equivalent of /30 or /31 on IPv4 links. For loopbacks use /128 prefixes. Always assign addresses from a range so that creating ACLs and iACLs becomes less tedious.

Using another prefix than /64 on an interface will break the following features:

• Neighbor Discovery (ND)
• Secure Neighbor Discovery (SEND)
• Privacy extensions
• PIM-SM with embedded RP

This is of course for segments where there are end users.

Prefix Allocation Practices

• Many SPs offer /48, /52, /56, /60 or /64 prefixes
• Enterprise customers receive one /48 or more
• Small business customers receive /52 or /56 prefix
• Broadband customers may receive /56 or /60 via DHCP Prefix Delegation (DHCP-PD)

Debating prefix allocation prefixes is like debating religion, politics or your favourite OS. Whatever you choose, make sure that you can revise your practice as future services and needs arrise.

Carrier Grade NAT(CGN)

• Short term solution to IPv4 exhaustage without changing Residential Gateway (RG) or SP infrastructure
• Subscriber uses NAT44 and SP does CGN with NAT44
• Multiplexes several customers onto the same public IPv4 address
• CGN performance and capabilities should be analysed in the planning phase
• May provide challenges in logging sessions
• Long term solution is to deploy IPv6

I really don’t like CGN, it slows down the deployment of IPv6. It’s a tool like anything else though that may be used selectively if there is no other solution available.

IPv6 over L2TP Softwires

• Dual stack IPv4/IPv6 on RG LAN side
• PPPoE or IPv4oE terminated on v4-only BNG
• L2TPv2 softwire between RG and IPv6-dedicated L2TP Network Server (LNS)
• Stateful architecture on LNS
  • Offers dynamic control and granular accounting of IPv6 traffic
• Limited investment needed and limited impact on existing infrastructure

I have never seen IPv6 deployed over softwires, what about you readers?

6RD

• Uses 6RD CE (Customer Edge) and 6RD BR (Border Relay)
• Automatic prefix delegation on 6RD CE
• Stateless and automatic IPv6 in IPv4 encap and decap functions on 6RD
• Follows IPv4 routing
• 6RD BRs are adressed with IPv4 anycast for load sharing and resiliency
• Limited investment and impact on existing infrastructure

IPv4 via IPv6 Using DS-Lite with NAT44

• Network has migrated to IPv6 but needs to provide IPv4 services
• IPv4 packets are tunneled over IPv6
• Introduces two components: B4 (Basic Bridging Broadband Element) and AFTR (Address Family Transition Router)
  • B4 typically sits in the RG
  • AFTR is located in the core infrastructure
• Does not provide IPv4 and IPv6 hosts to talk to each other
• AFTR device terminates the tunnel and decapsulates IPv4 packet
• AFTR device performs NAT44 on customer private IP to public IP addresses
• Increased MTU, be aware of fragmentation

Connecting IPv6-only with IPv4-only (AFT64)

• Only applicable where IPv6-only hosts need to communicate with IPv4-only hosts
• Stateful or stateless v6 to v4 translation
• Includes NAT64 and DNS64

MAP (Mapping of Address and Port)

• MAP-T Stateless 464 translation
• MAP-E Stateless 464 encapsulation
• Allows sharing of IPv4 address across an IPv6 network
  • Each shared IPv4 endpoint gets a unique TCP/UDP port range via “rules”
  • All or part of the IPv4 address can be derived from the IPv6 prefix
    • This allows for route summarization
  • Need to allocate TCP/UDP port ranges to each CPE
• Stateless border relays in SP network
  • Can be implemented in hardware for superior performance
  • Can use anycast and have asymmetric routing
  • No single point of failure
• Leverages IPv6 in the network
• No CGN inside SP network
• No need for logging or ALGs
• Dependent on CPE router

NAT64

• Stateful or stateless translation
• Stateful
  • 1:N translation
  • “PAT”
  • TCP, UDP, ICMP
  • Shares IPv4 addresses
• Stateless
  • 1:1 translation
  • “NAT”
  • Any protocol
  • No IPv4 address savings

DNS64 is often required in combination with NAT64 to send AAAA response to the IPv6-only hosts in case the server only exists in the v4 world.

464XLAT

• Somewhere around 15% of apps break with native v6 or NAT64
• Skype is one of these apps
• 464XLAT can help with most of these applications
• Handset does stateless 4 to 6 translation
• Network does NAT64
• Deployed by T-Mobile