When the IPv6 VPN traffic is to be transported to the BGP speaker
using IPv4 tunneling (e.g., IPv4 MPLS LSPs, IPsec-protected IPv4
tunnels), the BGP speaker SHALL advertise to its peer a Next Hop
Network Address field containing a VPN-IPv6 address:
whose 8-octet RD is set to zero, and
whose 16-octet IPv6 address is encoded as an IPv4-mapped IPv6
address [V6ADDR] containing the IPv4 address of the advertising
BGP speaker. This IPv4 address must be routable by the other
BGP Speaker.
And in sniffed traffic it seems it is correct:
And this IPv4 address is routable by the opponent router:
[admin@rtr1.CPE] > /ip/route/print where dst-address=10.0.10.12
Flags: D - DYNAMIC; A - ACTIVE; b - BGP, o - OSPF
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
D b 10.0.10.12/32 10.0.10.12 200
DAo 10.0.10.12/32 10.0.1.1%ether2 110
[admin@rtr1.CPE] >
But the mapped address is unreachable. If I create a static route for that mapped address the VPN routes comes up:
[admin@rtr1.CPE] > /ipv6/route/print where bgp-mpls-vpn
[admin@rtr1.CPE] > /ipv6/route/add dst-address=::ffff:10.0.10.12 gateway=fe80::a00:27ff:fe00:4101%ether2
[admin@rtr1.CPE] > /ipv6/route/print where bgp-mpls-vpn
Flags: D - DYNAMIC; A - ACTIVE; y - BGP-MPLS-VPN; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAyH b00b::10:12:11:0/112 ::ffff:10.0.10.12 200
DAyH b00b::10:12:12:0/112 ::ffff:10.0.10.12 200
[admin@rtr1.CPE] >
Correct me if I’m wrong, but that is not supposed to work. Mapped ipv4 address is just a representation of IPv4 address in a specific format to be able to store it in ipv6 database. It cannot be used as real address or to be routed.
In RouterOS routes with such a gateway will always be unreachable because mapped ipv4 is not considered a valid routable gateway. Linux does not allow to add in the FIB ipv6 routes with ipv4 mapped gateways, too.
So previous suggestions still are the only reasonable ones.
And regarding routing filter not working, you cannot set ipv4 gateway to ipv6 route, that is invalid configuration. For ipv6 route you need ipv6 gateway.
Thanks so much to digging these out. If I’m right, if I use VPNv6 over IPv6 I should use LDPv6 for IPv6 nexthops.
I don’t understand yet how should VPNv6 over IPv4 exactly works. I’ll try to investigate this.
So, If I’m right, it should works as mentioned above. BGP neighbors and LDP neighbors is communicating over IPv4, so VPNv4 route’s nexhop is plain IPv4 addresses and VPNv6 (over IPv4) route’s nexthop is mapped IPv4 address. This documents also referring this:
ASR1000#show bgp vpnv6 uni vrf VRF_A 2001:xxxx:800:2900::/56
BGP routing table entry for [65001:40]2001:xxxx:800:2900::/56, version 3240189
Paths: (1 available, best #1, table VRF_A)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from [65001:54]2001:xxxx:800:2900::/56 (global)
::FFFF:10.20.97.230 (metric 81) (via default) from 10.20.97.92 (10.20.97.92)
Origin incomplete, metric 0, localpref 222, valid, internal, best
Extended Community: RT:65001:40
Originator: 10.20.97.230, Cluster list: 10.20.97.92
mpls labels in/out nolabel/379
rx pathid: 0, tx pathid: 0x0
Updated on Jun 6 2024 14:02:57 CEST
ASR1000#show ipv6 cef vrf VRF_A 2001:xxxx:800:2900::/56 detail
2001:xxxx:800:2900::/56, epoch 0, flags [rib defined all labels]
recursive via 10.20.97.230 label 379
nexthop 10.20.111.227 HundredGigE0/0/0 label 24145-(local:5403)
nexthop 10.20.111.229 HundredGigE1/0/0 label 24242-(local:5403)
ASR1000#show mpls forwarding-table vrf VRF_A 2001:xxxx:800:2900::/56
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
None 379 2001:xxxx:800:2900::/56[V] \
0 Hu1/0/0 10.20.111.229
ASR1000#
I don’t know what process translate between mapped IPv4 BGP nexthop and IGP native IPv4 nexthop. If I understand what mrz wrote RouterOS can’t do this due to the Linux nature of RouterOS?
Furthermore if I change the nexthop to global scoped IPv6 address then I need IGP and LDP over IPv6 to nexhops and this is not exists in our setups.
Now I can understand that @oreggin is pointing out that the current 6VPE implementation of ROS does not support section 3.2.1.2 of RFC 4659 “BGP Speaker Requesting IPv4 Transport” https://www.rfc-editor.org/rfc/rfc4659.html#section-3.2.1.1. It’s really a shame because that is perhaps the most interesting functionality of 6VPE.
Regarding what @mrz raises about Cisco, Gopinath_Pigili’s comment refers to a double stack BGP session over IPv4. Section 3.2.1.2 of RFC 4659 is fully supported by Cisco in its various IOS. In fact, this and other manufacturers present 6VPE as the way to provide IPv6 services over an MPLS IPv4 backbone.
I don’t think its a shame. It is not a problem, it is a task
If I’m right, the mapped IPv4 nexthop in BGP table needs to be translated to native IPv4 address when building the MPLS forwarding table when VPNv6 prefixes exchanged over IPv4 BGP session , but I need further invesigation about this just to be sure.
I think the nexthop translation is the smaller task. If RouterOS based on at least Linux v5.2 then we have a chance to implement v6 routes with v4 nexthop. FRR faced this in the past already: https://github.com/FRRouting/frr/issues/4661
Last comment goes to another thread where mention that Linux 5.2 has this function. Maybe…
As mrz said mapped IPv6 address is not valid IPv6 address. It should work if you configure vpnv6 on IPv6 BGP peer and configure LDPv6 and IGP ipv6 address-family.
FTR: It should, but it doesn’t. I tried IS-IS IPv6 over GRE, but nexthops doesn’t work. I switched back to OSPFv2+v3, it works, LDPv4+v6 works, but if I activate VPNv6 on our routers’s BGP connections, it eats up all router’s CPU and VPNv6 prefixes flapping.
Edit: IS-IS IPv6 LL fix is not in 7.15.1 but in 7.16beta1
It depends on is it supported in the current kernel and if not how hard to implement it without other things falls apart. Without this option we need dual stack IGP and LDP to use both VPNv4 and VPNv6.
EDIT: and if I’m right it depends on how hard to implement this in RIB and FIB levels.
Would be awesome if we could get VPNv6 working via IPv4 MPLS LDP transport. That’s what many third party devices like H3C/HPE and Cisco support already.
