IPv6 over IPv4 Network (6PE)

Module Introduction

Before you start the hands-on part of this module, you should load the appropriate configuration and verify that the testbed is up and running by executing the corresponding robot file:

student@tour:~/trainings_resources/robot$ robot mpls_6pe/mpls_6pe_setup.robot

We use IS-IS as IGP for the examples and exercises in this module. The choice of IGP is not important for understanding and configuration of 6PE. However, if you prefer to run OSPF instead, you can alternatively load the setup using the -v igp:ospf knob:

student@tour:~/trainings_resources/robot$ robot -v igp:ospf mpls_6pe/mpls_6pe_setup.robot

In order to get a better understanding, the lab setup is shown in the picture below.

mpls lab
Figure 1. 6PE Lab Setup

Overview

If a network is based on IPv4 and wants to offer IPv6 internet service to customers, IPv6 Provider Edge (short 6PE) technology can be used. The basic idea is to implement IPv6 on edge router (aka PE routers) which are dual-stack in order to connect to the IPv6 network on the one side and to the MPLS core on the other side.

The core routers only run IPv4 and MPLS signaling protocols to setup LSPs, but are unaware of IPv6. Deploying 6PE only affects the PE routers, which simplifies maintenance and eliminates the need to upgrade the core routers.

Consider two PE routers, R1 and R4, that want to interconnect two isolated IPv6 sites. Because there is MPLS running in the network, we can assume there are LSPs already setup using any label distribution protocol (e.g., LDP), i.e., R1 has an entry for the loopback address of R4 in its ipv4 labeled-unicast routing table and vice versa.

The IPv6 routing information are exchanged between R1 and R4 via BGP. Standard BGP Network Layer Reachability Information (NLRI) only allows IPv4 prefixes and IPv4 next hops, but with multiprotocol extensions of BGP (MP-BGP), NLRI’s for other address families (AFI) and subsequent address families (SAFI) are supported. With 6PE, the AFI is set to 2 (IPv6) and the SAFI to 4 (labeled-unicast).

As next hop for the IPv6 prefix, the IPv4 loopback address of the BGP peer is used which is encoded as an IPv4-mapped IPv6 address in the BGP next hop field. In addition, an MPLS label is added to the IPv6 prefix to signal, that a IPv6 service is offered. In principle, this can be any label value but as R4 needs to perform an IPv6 lookup anyway, most implementations use the reserved label value 2 (IPv6 explicit NULL). The label value is encoded as part of the prefix.

mpls 6pe cp
Figure 2. 6PE BGP Control Plane

When R1 receives a native IPv6 packet, R1 will inspect its IPv6 unicast routing table to find a match for the IPv6 destination address of the packet. As a result, it will find

  • a label which is pushed as an inner label to the packet

  • an IPv4 next hop address which is resolved via the ipv4 labeled-unicast routing table and provides an outer transport label representing the MPLS LSP to R4

After both of these labels are pushed to the IPv6 packet, the packet is forwarded to the next router along the MPLS LSP. The core routers will only forward the packet based on the outer transport label and the net-to-last router will perform penultimate hop popping.

Finally, R4 will receive a single-labeled packet, remove the label and perform a IPv6 routing table lookup.

mpls 6pe dp
Figure 3. 6PE MPLS Data Plane
Even if its always label 2 in most implementations, the label is necessary, because otherwise there would be an unlabeled packet between R3 and R4 due to PHP and then R3-R4 link does not support IPv6.

Configuring 6PE

Exercise 1: Configuring BGP Peering for IPv6

In this lab exercise, IS-IS and LDP are already pre-configured. On R1, verify that LSPs to all routers in the network are established. The loopback addresses are 192.168.0.x for router Rx, x=1,..,6.

Configure an internal BGP sessions to router R4 with address-family ipv6 unicast and ipv6 labeled-unicast enabled. The AS number is 65000.

Click to reveal the answer
cfg> set instance default protocol bgp hostname R1
cfg> set instance default protocol bgp local-as 65000
cfg> set instance default protocol bgp router-id 192.168.0.1
cfg> set instance default protocol bgp address-family ipv6 labeled-unicast
cfg> set instance default protocol bgp address-family ipv6 unicast
cfg> set instance default protocol bgp peer ipv4 192.168.0.4 192.168.0.1 peer-group INTERN
cfg> set instance default protocol bgp peer-group INTERN remote-as 65000
cfg> set instance default protocol bgp peer-group INTERN address-family ipv6 labeled-unicast
cfg> set instance default protocol bgp peer-group INTERN address-family ipv6 unicast
cfg> commit

Once we have successfully configured the BGP peers, there should be a couple of BGP sessions established.

cfg> show bgp peer
Instance: default
  Peer                    Remote AS    State         Up/Down Time           PfxRcvd       PfxSent
  R4                      65000        Established   0d:00h:03m:00s         1             0

From the following output we can see that R1 is receiving one BGP prefix from each peer, but not sending any prefixes itself.

Exercise 2: Configuring BGP Redistribution

Configure redistribution of the loopback interface lo-0/0/0/0 into BGP address-family ipv6 unicast and verify that a prefix is advertised.

Click to reveal the answer
cfg> set instance default protocol bgp address-family ipv6 unicast redistribute direct
cfg> commit
cfg> show bgp peer
Instance: default
  Peer                   Remote AS    State         Up/Down Time           PfxRcvd       PfxSent
  R4                     65000        Established   0d:00h:10m:42s         1             1

Let’s have a more detailed look at the BGP session:

cfg> show bgp peer R4
Peer: R4, Peer IP: 192.168.0.4, Remote AS: 65000, Local: 192.168.0.1, Local AS: 65000, Any AS: False
  Type: ibgp, State: Established, Up/Down Time:
  Discovered on interface: -
  Last transition: Thu May 11 08:42:15 GMT +0000 2023, Flap count: 0
  Peer ID        : 192.168.0.4, Local ID  : 192.168.0.1
  Instance       : default, Peer group: INTERN
  6PE enabled    : False                                         (1)
  Timer values:
    Peer keepalive : 30s, Local keepalive: 30s
    Peer holddown  : 90s, Local holddown : 90s
    Connect retry  : 30s
  Timers:
    Connect retry timer : 0s
    keepalive timer     : expires in 15s 560592us
    Holddown timer      : expires in 1m 13s 421726us
  NLRIs:
    Sent           : ['ipv6-unicast', 'ipv6-labeled-unicast']    (2)
    Received       : ['ipv6-labeled-unicast']                    (3)
    Negotiated     : ['ipv6-labeled-unicast']
  <...>
1 Although we have configured ipv6 unicast and ipv6 labeled-unicast as supported address families in the peer group, the field 6PE Enabled is set to False.
2 Verifies that R1 is correctly configured for ipv6 unicast and labeled-unicast address families.
3 Interesting enough, the peer only sends ipv6 labeled-unicast information.

In order to understand how 6PE works, it is crucial to know that the 6PE router has two roles:

  • It is a normal IPv6 unicast router facing native IPv6 customers, i.e., IPv6 route information need to be in the ipv6 unicast routing table for lookup.

  • It is a BGP router exchanging labeled IPv6 route information across an MPLS domain.

These two sides need to be connected. In RBFS, the keyword is the send-label option, that needs to be configured in the ipv6 unicast address family.

Exercise 3: Enable send-label option

Configure the send-label to be true for the IPv6 unicast address family within the corresponding peer-group.

Click to reveal the answer
cfg> set instance default protocol bgp peer-group INTERN address-family ipv6 unicast send-label true
cfg> commit
cfg> cfg> show bgp peer R4
Peer: R4, Peer IP: 192.168.0.4, Remote AS: 65000, Local: 192.168.0.1, Local AS: 65000, Any AS: False
  Type: ibgp, State: Established, Up/Down Time: , Reason: Cease, Sub-Code: Admin shutdown
  Discovered on interface: -
  Last transition: Thu May 11 08:46:50 GMT +0000 2023, Flap count: 1
  Peer ID        : 192.168.0.4, Local ID  : 192.168.0.1
  Instance       : default, Peer group: INTERN
  6PE enabled    : True                                          (1)
  Timer values:
    Peer keepalive : 30s, Local keepalive: 30s
    Peer holddown  : 90s, Local holddown : 90s
    Connect retry  : 30s
  Timers:
    Connect retry timer : 0s
    keepalive timer     : expires in 7s 508565us
    Holddown timer      : expires in 1m 9s 100192us
  NLRIs:
    Sent           : ['ipv6-labeled-unicast']                    (2)
    Received       : ['ipv6-labeled-unicast']                    (2)
    Negotiated     : ['ipv6-labeled-unicast']
    <...>
1 After enabling send-label, the 6PE status is indicated as enabled.
2 Although both SAFIs, unicast and labeled-unicast, are configured, only labeled-unicast is used ion 6PE sessions.

Now that BGP session is established and routes are exchanged, let’s have a look at the resulting routing tables:

cfg> show route ipv6 labeled-unicast
Instance: default, AFI: ipv6, SAFI: labeled-unicast
Prefix/Label                     Source     Pref    Next Hop                   Interface                      Label
fc00:c0a8::192:168:0:1/128       direct     0       fc00:c0a8::192:168:0:1     lo-0/0/0/0                     -
cfg> show route ipv6 unicast
Instance: default, AFI: ipv6, SAFI: unicast
Prefix/Label                     Source     Pref    Next Hop                   Interface
fc00:c0a8::192:168:0:1/128       direct     0       fc00:c0a8::192:168:0:1     lo-0/0/0/0
fc00:c0a8::192:168:0:4/128       bgp        200     192.168.0.4                hostif-0/0/2/0
                                                    192.168.0.4                hostif-0/0/1/0
The IPv6 labeled-unicast routes received from the 6PE peer are considered as IPv6 unicast routes and installed in IPv6 unicast routing table.

Finally, we can verify that IPv6 packets are successfully sent and received across an IPv4-only core network:

cfg> ping fc00:c0a8::192:168:0:4 source-ip fc00:c0a8::192:168:0:1 count 3
Statistics: 3 sent, 0 received, 100% packet loss

Ups. Although we have received a valid route and installed it into the IPv6 unicast routing table, the ICMP Echo and Reply packet are not forwarded correctly. The reason can easily be seen by looking at the learned prefix in more detail:

cfg> show route ipv6 unicast prefix fc00:c0a8::192:168:0:4/128 detail
Instance: default, AFI: ipv6, SAFI: unicast
fc00:c0a8::192:168:0:4/128
  Source: bgp, Preference: 200
    Next Hop: 192.168.0.4
      Covering prefix: 192.168.0.4/32
      Next Hop type: mpls ingress, Next Hop action: mpls label push
      Resolved in: default-ipv4-unicast            (1)
      Egress interface: hostif-0/0/2/0, NextHop MAC: 7a:00:3f:c0:00:02
      MPLS-Label: 2,bos:1
    Next Hop: 192.168.0.4
      Covering prefix: 192.168.0.4/32
      Next Hop type: mpls ingress, Next Hop action: mpls label push
      Resolved in: default-ipv4-unicast            (1)
      Egress interface: hostif-0/0/1/0, NextHop MAC: 7a:fc:da:c0:00:01
      MPLS-Label: 2,bos:1
1 Once labeled IPv6 prefixes are exchanged between two 6PE routers, the BGP next hop needs to be resolved. By default, RBFS tries to resolve the next hop in the unicast routing table.

In our scenario, the routers in the core network are completely unaware of IPv6 forwarding. Thus, we need to send the packet along an MPLS LSP towards R4. This is achieved by resolving the next hop address using the IPv4 labeled-unicast routing table.

Exercise 4: Configure Next Hop Resolution

Change the next hop resolution to labeled-unicast using the resolve-nexthop command for the IPv6 unicast address family.

Click to reveal the answer
cfg> set instance default protocol bgp address-family ipv6 unicast resolve-nexthop afi ipv4
cfg> set instance default protocol bgp address-family ipv6 unicast resolve-nexthop safi labeled-unicast
cfg> commit
cfg> ping fc00:c0a8::192:168:0:4 source-ip fc00:c0a8::192:168:0:1 count 3
68 bytes from fc00:c0a8::192:168:0:4: icmp_seq=1 ttl=64 time=7.9031 ms
68 bytes from fc00:c0a8::192:168:0:4: icmp_seq=2 ttl=64 time=3.9631 ms
68 bytes from fc00:c0a8::192:168:0:4: icmp_seq=3 ttl=64 time=.9128 ms
Statistics: 3 sent, 3 received, 0% packet loss

Summary

This module outlined the basic concept of interconnecting IPv6 network over an IPv4-based MPLS network (also known as 6PE) and how to configure it on RBFS.

If you have completed the exercise, you can check the results by executing

student@tour:~/trainings_resources/robot$ robot mpls_6pe/mpls_6pe_verify.robot