├── README.md ├── examples ├── Arista_EOS.md ├── Bird2.md ├── Cisco_IOSXR.md ├── FRRouting.md ├── GoBGP.md ├── Juniper_JunOS.md ├── Nokia_SR-Linux.md ├── Nokia_SROS.md ├── README.md └── RtBrick_RBFS.md └── presentations ├── README.md ├── ipv6-only-ixps.odp ├── ipv6-only-ixps.pdf └── w12 BGP Announcing IPv4 with IPv6 next-hop.pdf /README.md: -------------------------------------------------------------------------------- 1 | # rfc8950-ixp 2 | Repository for the rfc8950-ixp working group 3 | 4 | # RFC8950 Working Group Charter - Euro-IX 5 | 6 | ## Scope 7 | 8 | The main purpose of this document is to describe the activities of a new working group on using IPv6 next-hops for IPv4 routes at IXPs. In particular, it will describe the purpose for which the working group is being set up, the activities that will be carried out, how they will be carried out and timing. 9 | 10 | ## Background and goal 11 | 12 | Previously unused IPv4 address space has run out, and as IXPs grow, it’s now increasingly difficult to find a new bigger IPv4 subnet for the shared medium. One proposed solution that was put forward some years ago (RFC5549) was to use only IPv6 on the IXP shared medium and disassociate ARP from mapping route next-hops to MAC addresses on the IXP. The specification has recently been updated as RFC8950. 13 | As vendors have finally started to implement this functionality, it’s time to figure out how to deploy it at IXPs. Most of the deployment happens at IXP members, but the IXP is involved at a few points such as the route servers and to rule on disputes in some corner cases. 14 | 15 | ## Plan and timelines 16 | 17 | The project planning is described below: 18 | 19 | ### Step 1 (2 weeks) - Creation of the working group 20 | 21 | A call for volunteers will be sent to the Euro-IX mailing list. 22 | 23 | ### Step 2 - First meeting of the working group (22 August 23) 24 | 25 | The first meeting will be important to kick off the group's activities and it will have the following goals: 26 | 27 | * presentation of participants 28 | * chair and co-chair selection 29 | * overview of activities 30 | * discussion of working methods and tools (ML, Mattermost, Slack, etc.) 31 | * roles in the project 32 | * frequency of meetings 33 | * timelines. 34 | 35 | The initial agenda of the meeting will be established in advance by the promoters. 36 | 37 | ### Step 3 (3 months) - First activities of the working group 38 | 39 | [describe steps that the working group will be taking] 40 | * Definition of requirements to members 41 | * Evaluation of vendor support (routers, route-servers) [based on documentation] 42 | * Virtual test environment(?) 43 | * IXP Manager integration, identify gaps 44 | 45 | At the end of the first 3 steps of the project, there will be a discussion to initiate the second phase if needed, i.e., the creation or adaptation of one of the identified solutions 46 | 47 | ## Suitable profiles for this working group 48 | 49 | We would like to invite volunteers from Euro-IX (or other interested parties) to join us to do this. 50 | 51 | ## Goals and Targets ## 52 | 53 | Define goals and targets of the working group: 54 | 55 | [Describe skill set requirements for working group] 56 | * IXP Manager setup 57 | * IXP Manager “hacking”/customisation 58 | * Arouteserver configuration/customisation 59 | * BIRD2 route-server configuration (Linux) 60 | * OpenBGPd route-server configuration (OpenBSD, Linux) 61 | * Technical writing 62 | * Setup and operation of virtual environment 63 | * Knowledge about router vendor X – configuration, access to documentation, ideally access to equipment 64 | 65 | ### Step 4 [If needed, will depend on the output of the first phase]. 66 | 67 | [If a step 4 is require, describe the detail here] 68 | * Interop-testing(?) [how can we connect real equipment?] 69 | * Create configuration guides for different router vendors 70 | * Identify implications to filtering 71 | * Can we support brownfield? Migration path? How to support/integrate legacy equipment? 72 | -------------------------------------------------------------------------------- /examples/Arista_EOS.md: -------------------------------------------------------------------------------- 1 | # Arista EOS 2 | 3 | Arista EOS supports [IPv4 addressless forwarding](https://www.arista.com/en/support/toi/eos-4-17-0f/13784-ip-addressless-forwarding-changes-for-bgp-v6-nexthop-for-v4-routes) 4 | as well as [RFC 5549](https://www.arista.com/en/support/toi/eos-4-23-2f/14436-rfc-5549-ipv4-unicast-nlri-with-ipv6-next-hop-support) 5 | BGP signalling. 6 | 7 | ## Minimum Software Version 8 | 9 | Arista EOS comes with two different BGP implementation: ribd and multi-agent. While ribd has support for RFC5549 since EOS 4.17.x, 10 | multi-agent was enhanced to support it from EOS 4.22.1F onwards. Multi-agent model is default nowadays, so it recommended to use it. 11 | 12 | ## Configuration 13 | 14 | ``` 15 | service routing protocols model multi-agent 16 | 17 | ip routing ipv6 interfaces 18 | 19 | interface Ethernet1 20 | no switchport 21 | ipv6 address 2001:7f8:19:6::1:1/64 22 | 23 | interface Loopback0 24 | ip address 10.0.0.1/32 25 | 26 | router bgp 65001 27 | router-id 10.0.0.1 28 | no bgp default ipv4-unicast 29 | neighbor peer peer group 30 | neighbor peer remote-as 65002 31 | neighbor peer next-hop-self 32 | neighbor peer send-community standard large 33 | neighbor 2001:7f8:19:6::2:1 peer group peer 34 | ! 35 | address-family ipv4 36 | neighbor peer activate 37 | neighbor peer next-hop address-family ipv6 originate 38 | ! 39 | address-family ipv6 40 | neighbor peer activate 41 | ``` 42 | 43 | There are four important lines: 44 | 45 | 1. `ip routing ipv6 interfaces` to enable IPv4 forwarding on non-IPv4 interfaces. 46 | 2. At least one (loopback) interface with an IPv4 address within the VRF. This address will be used for answering ICMP unreachables or during traceroutes. 47 | 3. `neighbor peer next-hop-self` should be default for IXP connection, but it's even more important here. 48 | 4. `neighbor peer next-hop address-family ipv6 originate` to enable extended next-hop facility and to also send out IPv4 routes with IPv6 next-hop. 49 | 50 | ## Testing 51 | 52 | ### Are the routes getting accepted? 53 | 54 | Example: 55 | 56 | ``` 57 | # sh ipv6 bgp peers 2001:7f8:19:6::2:1 received-routes 58 | Network Next Hop Metric AIGP LocPref Weight Path 59 | * > 10.1.2.0/24 2001:7f8:19:6::2:1 - - - - 65002 ? 60 | * > 10.1.3.0/24 2001:7f8:19:6::2:1 - - - - 65002 ? 61 | 62 | # sh ip bgp 10.1.2.0/24 detail 63 | BGP routing table information for VRF default 64 | Router identifier 10.0.0.1, local AS number 65001 65 | BGP routing table entry for 10.1.2.0/24 66 | Paths: 1 available 67 | 65002 68 | 2001:7f8:19:6::2:1 from 2001:7f8:19:6::2:1 (10.0.0.2) 69 | Origin INCOMPLETE, metric 0, localpref 100, IGP metric 0, weight 0, tag 0 70 | Received 02:50:52 ago, valid, external, best 71 | Rx SAFI: Unicast 72 | Advertised to 1 peer: 73 | peer-group ibgp: 74 | 10.1.1.1 75 | ``` 76 | 77 | ### Is next-hop address resolution working? 78 | 79 | Yes: 80 | 81 | ``` 82 | # sh ip route 10.1.2.0 83 | 84 | B E 10.1.2.0/24 [20/0] 85 | via 2001:7f8:19:6::2:1, Ethernet1 86 | 87 | # sh ipv6 neighbors 88 | IPv6 Address Age Hardware Addr State Interface 89 | 2001:7f8:19:6::2:1 0:00:21 0c00.31b1.b33b REACH Et1 90 | ``` 91 | 92 | ### What does traceroute look like? 93 | 94 | The router is visible with its loopback interface IPv4 address. 95 | 96 | ### What happens if peer is not configured to use RFC8950 next hops? 97 | 98 | If extended next-hop cannot be negotiated, neither IPv4 routes can be received not advertised. Status can be checked: 99 | 100 | ``` 101 | # sh ipv6 bgp peers 2001:7f8:19:6::2:1 | grep -A1 "Extended Next-Hop" 102 | Extended Next-Hop Capability: 103 | IPv4 Unicast: advertised and received and negotiated 104 | ``` 105 | 106 | In case "IPv4 addressless forwarding" is not enabled, the routes are being accepted and visible in the FIB, but not forwarded, i.e. blackholed. 107 | 108 | ``` 109 | # sh ip | grep "Interface" 110 | IPv6 Interfaces Forwarding : None 111 | 112 | # conf 113 | # ip routing ipv6 interfaces 114 | 115 | # sh ip | grep "Interface" 116 | IPv6 Interfaces Forwarding : True 117 | ``` 118 | 119 | ### What happens if peer sets an IPv4 address on the peering interface? 120 | 121 | When an IPv4 address is configured on the IXP facing interface, this IP address is used in traceroutes. 122 | 123 | Arista only supports /31 or larger IPv4 addresses to be assigned to ethernet interfaces. Alternatively IP unnumbered might be configured referring to an IP address on some other loopback interface. The next-hop remains IPv6 in the FIB. 124 | -------------------------------------------------------------------------------- /examples/Bird2.md: -------------------------------------------------------------------------------- 1 | # Bird2 enhanced next hop configuration 2 | 3 | ## Minimum Software Requirements 4 | 5 | Bird2 has supported IPv6 next hops for IPv4 routes since version 2.0.8. 6 | 7 | ## Configuration 8 | 9 | The key setting is **extended next hop on** in the IPv4 channel of the protocol: 10 | ``` 11 | protocol bgp EXAMPLE { 12 | neighbor 2001:db8:3::2 as 65533; 13 | ipv4 { 14 | import all; 15 | export all; 16 | extended next hop on; 17 | } 18 | } 19 | ``` 20 | IPv6 GUA/LLA next-hop preference can be configured by setting `next hop prefer global` within a channel. 21 | 22 | ## Testing 23 | ### Are the routes getting accepted and installed? 24 | 25 | Yes: 26 | ``` 27 | zsh% birdc show route protocol EXAMPLE 28 | Table master4: 29 | 192.0.2.0/24 unicast [EXAMPLE 2024-12-12] * (100) [AS65533i] 30 | via 2001:db8:3::2 on eth0 31 | zsh% ip route show 192.0.2.0/24 32 | 192.0.2.0/24 via inet6 2001:db8:3::2 dev eth0 proto bird metric 32 33 | ``` 34 | 35 | ### Is the next-hop address resolution working? 36 | yes 37 | 38 | ### What does traceroute look like? 39 | The Linux router will use an IPv4 address to respond to traceroute in the following order: 40 | * if the outgoing interface (for the response) has an IPv4 address, use that 41 | * use any other interface has an IPv4 address, use that 42 | 43 | ### What happens if peer is not configured to use RFC8950 next hops? 44 | 45 | **Not tested yet** 46 | 47 | ### Route filtering? 48 | 49 | You can specify separate filters per channel (e.g. ipv4 or ipv6). 50 | The config example above only has the ipv4 channel defined and 51 | it has the "all" filter defined for both import and export. 52 | -------------------------------------------------------------------------------- /examples/Cisco_IOSXR.md: -------------------------------------------------------------------------------- 1 | # Cisco IOS XR 2 | 3 | ## Minimum Software Version 4 | 5 | Presumably minimum version is IOS-XR 7.3.3 ([3rd-party source](https://www.ausnog.net/sites/default/files/ausnog-2022/presentations/ausnog_2022-day2-07-cooper_lees-who_needs_arp_v4_via_v6.pdf)). 6 | 7 | ## Configuration 8 | 9 | ``` 10 | interface GigabitEthernet 0/1/1 11 | ipv4 forwarding-enable 12 | ipv6 address 2001:db8:1::1/126 13 | 14 | router bgp 64500 15 | bgp router-id 192.0.1.1 16 | address-family ipv4 unicast 17 | neighbor 2001:db8:1::2 18 | remote-as 64496 19 | description Example 20 | enforce-first-as 21 | address-family ipv4 unicast 22 | maximum-prefix 5 95 23 | send-community-ebgp 24 | route-policy session-as64496-v4-in in 25 | route-policy session-as64496-v4-out out 26 | send-extended-community-ebgp 27 | next-hop-self 28 | remove-private-AS 29 | soft-reconfiguration inbound always 30 | ! 31 | address-family ipv6 unicast 32 | maximum-prefix 5 95 33 | send-community-ebgp 34 | route-policy session-as41731-v6-in in 35 | route-policy session-as41731-v6-out out 36 | send-extended-community-ebgp 37 | remove-private-AS 38 | soft-reconfiguration inbound always 39 | ! 40 | ! 41 | ! 42 | ``` 43 | 44 | Important lines are: 45 | 46 | 1. `next-hop-self` - this is not default in this case! 47 | 2. `ipv4 forwarding-enable` - to allow forwarding of IPv4 packets on IPv6-only interfaces. Otherwise they will be silently dropped. 48 | 3. `address-family ipv4 unicast` - otherwise the neighbors will fail to be activated, even if no networks are configured to be exported. 49 | 50 | ## Testing 51 | 52 | ### Are prefixes received? 53 | 54 | Example: 55 | 56 | ``` 57 | # show bgp ipv4 unicast neighbors 2001:db8:1::2 received routes 58 | 59 | Network Next Hop Metric LocPrf Weight Path 60 | * 192.0.2.0/24 2001:db8:1::2 61 | 0 64496 i 62 | 63 | ``` 64 | 65 | ### Is the next-hop address resolution working? 66 | 67 | ``` 68 | #sho ip route 192.0.2.0/24 69 | 70 | Routing entry for 192.0.2.0/24 71 | Known via "bgp 64500", distance 20, metric 0 72 | Tag 60767, type external 73 | Installed Oct 18 07:02:53.061 for 2d05h 74 | Routing Descriptor Blocks 75 | fe80::3817:fcff:fea0:1f17, from 2001:db8:1::2, via GigEthernet 0/1/1, BGP external 76 | Nexthop in Vrf: "default", Table: "default", IPv6 Unicast, Table Id: 0xe0800000 77 | Route metric is 0 78 | No advertising protos. 79 | ``` 80 | 81 | -------------------------------------------------------------------------------- /examples/FRRouting.md: -------------------------------------------------------------------------------- 1 | # FRRouting (FRR) 2 | 3 | The minimum FRRouting version to support `extended-nexthop` (v4 with v6 nexthops) is 7.0.0. 4 | 5 | The [documentation](https://docs.frrouting.org/en/latest/bgp.html#clicmd-neighbor-PEER-capability-extended-nexthop) talks about `extended-nexthop` to allow bgp to negotiate the extended-nexthop capability with it’s peer and allow BGP to install v4 routes with v6 nexthops. 6 | 7 | ## Minimum Software Version 8 | 9 | The minimum FRRouting version to support RFC5549 is 7.0.0. This version introduced the `extended-nexthop` term. 10 | We are running the test with FRRouting 8.2.0. 11 | 12 | Minimum Linux kernel version to support RFC5549 is [Linux 5.2](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d15662682db232da77136cd348f4c9df312ca6f9). 13 | 14 | ## Configuration 15 | 16 | Configuration for route-server: 17 | 18 | ``` 19 | router bgp 133339 20 | no bgp default ipv4-unicast 21 | neighbor 2400:9c80:0:171::2 remote-as 100 22 | neighbor 2400:9c80:0:171::2 description Example-AS100 23 | neighbor 2400:9c80:0:171::2 capability extended-nexthop 24 | ! 25 | address-family ipv4 unicast 26 | neighbor 2400:9c80:0:171::2 activate 27 | neighbor 2400:9c80:0:171::2 next-hop-self 28 | neighbor 2400:9c80:0:171::2 soft-reconfiguration inbound 29 | neighbor 2400:9c80:0:171::2 route-server-client 30 | neighbor 2400:9c80:0:171::2 route-map in-as100 in 31 | neighbor 2400:9c80:0:171::2 route-map out-as100 out 32 | neighbor 2400:9c80:0:171::2 attribute-unchanged next-hop 33 | exit-address-family 34 | ! 35 | address-family ipv6 unicast 36 | neighbor 2400:9c80:0:171::2 activate 37 | neighbor 2400:9c80:0:171::2 next-hop-self 38 | neighbor 2400:9c80:0:171::2 soft-reconfiguration inbound 39 | neighbor 2400:9c80:0:171::2 route-server-client 40 | neighbor 2400:9c80:0:171::2 route-map in-as100 in 41 | neighbor 2400:9c80:0:171::2 route-map out-as100 out 42 | neighbor 2400:9c80:0:171::2 attribute-unchanged next-hop 43 | exit-address-family 44 | exit 45 | ``` 46 | 47 | IPv6 GUA/LLA next-hop preference can be configured by setting `set ipv6 next-hop prefer-global` within `route-map y` of `neighbor x route-map y in`. 48 | 49 | Important lines are: 50 | 51 | 1. `capability extended-nexthop` - this is not default in this case! 52 | 53 | ## Testing 54 | 55 | ### Are the routes getting accepted? 56 | 57 | Yes: 58 | 59 | ``` 60 | # show ip bgp neighbors 2400:9c80:0:171::2 received-routes 61 | BGP table version is 2, local router ID is 1.1.1.1, vrf id 0 62 | Default local pref 100, local AS 133339 63 | Status codes: s suppressed, d damped, h history, * valid, > best, = multipath, 64 | i internal, r RIB-failure, S Stale, R Removed 65 | Nexthop codes: @NNN nexthop's vrf id, < announce-nh-self 66 | Origin codes: i - IGP, e - EGP, ? - incomplete 67 | RPKI validation codes: V valid, I invalid, N Not found 68 | 69 | Network Next Hop Metric LocPrf Weight Path 70 | *> 10.100.100.0/24 2400:9c80:0:171::2 71 | 0 0 100 i 72 | 73 | Total number of prefixes 1 74 | ``` 75 | 76 | ### Is the next-hop address resolution working? 77 | 78 | Yes: 79 | 80 | ``` 81 | # show ip route 10.100.100.0/24 82 | Routing entry for 10.100.100.0/24 83 | Known via "bgp", distance 20, metric 0, best 84 | Last update 00:10:22 ago 85 | * fe80::e8d:e8ff:fe9e:0, via eth0, weight 1 86 | ``` 87 | 88 | ### What does traceroute look like? 89 | 90 | untested (how would a FRR/linux or FRR/BSD router react) 91 | 92 | ### What happens if peer is not configured to use RFC8950 next hops? 93 | 94 | If extended next-hop cannot be negotiated, neither IPv4 routes can be received not advertised. 95 | -------------------------------------------------------------------------------- /examples/GoBGP.md: -------------------------------------------------------------------------------- 1 | # GoBGP 2 | 3 | GoBGP supports extended nexthops natively. GoBGP relies on third party integrations to interact with the FIB, e.g. FRR. So any forwarding plane functionality is out-of-scope for the test. 4 | 5 | ## Minimum Software Version 6 | 7 | GoBGP seems to support the extended nexthop capability for a while. I could not identify any "first version". 8 | 9 | ## Configuration 10 | 11 | No special configuration is necessary. Just the address family ipv4-unicast needs to be enabled for the neibhbor. 12 | 13 | ## Testing 14 | 15 | GoBGP will announce and negotiate extended next-hop capability with the peer. 16 | 17 | ### Are the routes getting accepted? 18 | 19 | Yes: 20 | 21 | ``` 22 | bash-5.0# gobgp global rib 23 | Network Next Hop AS_PATH Age Attrs 24 | *> 10.1.0.0/24 2001:7f8:19:6::1:1 65001 00:16:39 [{Origin: ?} {Communities: 64512:10, 64512:21, 64512:41} {Extcomms: [64512:10], [64512:21], [64512:41]} {LargeCommunity: [ 16374:64512:10, 16374:64512:21, 16374:64512:41]} {Flags: TRANSITIVE|OPTIONAL, Type: BGPAttrType(35), Value: ?�}] 25 | *> 10.1.1.0/24 2001:7f8:19:6::1:1 65001 00:16:39 [{Origin: ?} {Communities: 64512:10, 64512:21, 64512:41} {Extcomms: [64512:10], [64512:21], [64512:41]} {LargeCommunity: [ 16374:64512:10, 16374:64512:21, 16374:64512:41]} {Flags: TRANSITIVE|OPTIONAL, Type: BGPAttrType(35), Value: ?�}] 26 | *> 10.7.0.0/24 2001:7f8:19:6::7:1 65007 00:57:37 [{Origin: i} {Med: 100} {LocalPref: 100} {Communities: 1:1, 2:2}] 27 | ``` 28 | 29 | ### Is the next-hop address resolution working? 30 | 31 | No FIB integration tested. 32 | 33 | ### What does traceroute look like? 34 | 35 | No FIB integration tested. 36 | 37 | ### What happens if peer is not configured to use RFC8950 next hops? 38 | 39 | No FIB integration tested. 40 | -------------------------------------------------------------------------------- /examples/Juniper_JunOS.md: -------------------------------------------------------------------------------- 1 | # Juniper JunOS 2 | 3 | ## Minimum Software Version 4 | 5 | The minimum JunOS version to support RFC5549 is 17.3R1. This version introduced the `extended-nexthop` term. 6 | JunOS before 21.1R1 seems to have [issues with 32 bit next-hop](https://github.com/gacybercenter/kinetic/issues/78) (global + link-local). 7 | 8 | TODO: The [documentation](https://www.juniper.net/documentation/us/en/software/junos/bgp/topics/topic-map/multiprotocol-bgp.html#id-understanding-redistribution-of-ipv4-routes-with-ipv6-next-hop-into-bgp) talks about `dynamic-tunnel`. We do not need this, but it remains to be determined which JunOS version supports untunneled IPv4 with IPv6 next-hop. 9 | 10 | ## Configuration 11 | 12 | ``` 13 | interfaces { 14 | ge-0/0/0 { 15 | unit 0 { 16 | family inet; 17 | family inet6 { 18 | address 2001:7f8:19:6::11:1/64; 19 | } 20 | } 21 | } 22 | lo0 { 23 | unit 0 { 24 | family inet { 25 | address 10.1.11.255/32; 26 | } 27 | } 28 | } 29 | } 30 | policy-options { 31 | policy-statement nh-self { 32 | then { 33 | next-hop self; 34 | } 35 | } 36 | } 37 | routing-options { 38 | router-id 10.0.0.11; 39 | autonomous-system 65011; 40 | } 41 | protocols { 42 | bgp { 43 | group peer-a { 44 | type external; 45 | local-address 2001:7f8:19:6::11:1; 46 | family inet { 47 | unicast { 48 | extended-nexthop; 49 | } 50 | } 51 | family inet6 { 52 | unicast; 53 | } 54 | export nh-self; 55 | peer-as 65001; 56 | local-as 65011; 57 | neighbor 2001:7f8:19:6::1:1; 58 | } 59 | } 60 | } 61 | ``` 62 | 63 | There are four important lines: 64 | 65 | 1. `interfaces X unit Y family inet` needs to be enabled to allow IPv4 forwarding on an interface. 66 | 2. At least one (loopback) interface with an IPv4 address. This address will be used for answering ICMP unreachables or during traceroutes.(*) 67 | 3. `policy-statement nh-self then next-hop self` should be default for IXP connection, but it's even more important here. 68 | 4. `protocols bgp group X family inet unicast extended-nexthop` needs to be enabled to negotiate the capability. 69 | 70 | ## Testing 71 | 72 | ### Are the routes getting accepted? 73 | 74 | Example: 75 | 76 | ``` 77 | > show route receive-protocol bgp 2001:7f8:19:6::1:1 78 | 79 | Prefix Nexthop MED Lclpref AS path 80 | * 10.1.0.0/24 2001:7f8:19:6::1:1 65001 ? 81 | * 10.1.1.0/24 2001:7f8:19:6::1:1 65001 ? 82 | * 10.1.2.0/24 2001:7f8:19:6::1:1 65001 65002 ? 83 | * 10.1.3.0/24 2001:7f8:19:6::1:1 65001 65002 ? 84 | 85 | > show route 10.1.2.0 detail 86 | 87 | 10.1.2.0/24 (1 entry, 1 announced) 88 | *BGP Preference: 170/-101 89 | Next hop type: Router, Next hop index: 660 90 | Address: 0x77c62a4 91 | Next-hop reference count: 12, Next-hop session id: 322 92 | Kernel Table Id: 0 93 | Source: 2001:7f8:19:6::1:1 94 | Next hop: 2001:7f8:19:6::1:1 via ge-0/0/0.0, selected 95 | Session Id: 322 96 | State: 97 | Local AS: 65011 Peer AS: 65001 98 | Age: 19:58 99 | Validation State: unverified 100 | Task: BGP_65001_65011.2001:7f8:19:6::1:1 101 | Announcement bits (3): 0-KRT 2-BGP_RT_Background 3-Resolve tree 1 102 | AS path: 65001 65002 ? 103 | Accepted 104 | Localpref: 100 105 | Router ID: 10.0.0.1 106 | Thread: junos-main 107 | ``` 108 | 109 | ### Is next-hop address resolution working? 110 | 111 | Yes: 112 | 113 | ``` 114 | > show route 10.1.2.0 115 | 10.1.2.0/24 *[BGP/170] 00:27:21, localpref 100 116 | AS path: 65001 65002 ?, validation-state: unverified 117 | > to 2001:7f8:19:6::1:1 via ge-0/0/0.0 118 | 119 | > show ipv6 neighbors 120 | IPv6 Address Linklayer Address State Exp Rtr Secure Interface 121 | 2001:7f8:19:6::1:1 0c:00:3e:ef:d1:a2 reachable 24 yes no ge-0/0/0.0 122 | ``` 123 | 124 | ### What does traceroute look like? 125 | 126 | The router is visible with its loopback interface IPv4 address. 127 | 128 | (*) Addendum: Axu tried this on MX240 and JunOS 23.4R2-S2. The router chose a random interface rather than `lo0.1` (which was a member of the testing VRF) until he set an IPv4 address on the peering interface. 129 | 130 | If an IPv4 address is configured on the interface, this address will be used in traceroutes. 131 | 132 | ### What happens if peer is not configured to use RFC8950 next hops? 133 | 134 | If extended next-hop cannot be negotiated, neither IPv4 routes can be received not advertised. Status can be checked: 135 | 136 | ``` 137 | > show bgp neighbor 2001:7f8:19:6::1:1 | match nexthop 138 | NLRI that we support extended nexthop encoding for: inet-unicast 139 | NLRI that peer supports extended nexthop encoding for: inet-unicast 140 | NLRI(s) enabled for color nexthop resolution: inet-unicast inet6-unicast 141 | ``` 142 | 143 | In case `family inet` is not enabled on the interface connecting the IPv6 next-hop, the routes are being accepted and visible in the FIB, but not forwarded, i.e. blackholed. 144 | -------------------------------------------------------------------------------- /examples/Nokia_SR-Linux.md: -------------------------------------------------------------------------------- 1 | # Nokia SR-Linux 2 | 3 | ## Minimum Software Version 4 | 5 | RFC8950 compliant functionalities have successfully been tested with Nokia SR Linux 22.6.4. 6 | 7 | ## Configuration 8 | 9 | ``` 10 | routing-policy { 11 | prefix-set Clients { 12 | prefix 10.0.0.0/24 mask-length-range exact { 13 | } 14 | } 15 | policy AcceptAny { 16 | default-action { 17 | accept { 18 | } 19 | } 20 | } 21 | policy Announce-Clients { 22 | statement 10 { 23 | match { 24 | prefix-set Clients 25 | } 26 | action { 27 | accept { 28 | } 29 | } 30 | } 31 | } 32 | } 33 | interface ethernet-1/1 { 34 | admin-state enable 35 | subinterface 0 { 36 | description "to IXP" 37 | admin-state enable 38 | ipv6 { 39 | address 2001:db8::1/64 { 40 | } 41 | } 42 | } 43 | } 44 | 45 | network-instance default { 46 | ip-forwarding { 47 | receive-ipv4-check false 48 | } 49 | interface ethernet-1/1.0 { 50 | } 51 | protocols { 52 | bgp { 53 | admin-state enable 54 | autonomous-system 65001 55 | router-id 10.0.0.1 56 | group rs { 57 | export-policy Announce-Clients 58 | import-policy AcceptAny 59 | peer-as 65254 60 | afi-safi ipv4-unicast { 61 | admin-state enable 62 | ipv4-unicast { 63 | advertise-ipv6-next-hops true 64 | receive-ipv6-next-hops true 65 | } 66 | } 67 | } 68 | neighbor 2001:db8::254 { 69 | peer-group rs 70 | } 71 | } 72 | } 73 | } 74 | ``` 75 | 76 | There are three important lines: 77 | 78 | 1. `receive-ipv4-check false` in the context of ip-forwarding config. This allows to accept IPv4 packets even though the interface is operationally down for IPv4. 79 | 2. `receive-ipv6-next-hops true` in the bgp context. This enables accepting IPv4 routes with IPv6 next hops and announces the capability. 80 | 3. `advertise-ipv6-next-hops true` in the bgp context. This enables sending of IPv6 next hops for IPv4 routes. 81 | 82 | ## Testing 83 | 84 | ### Are the routes getting accepted? 85 | 86 | Example: 87 | 88 | ``` 89 | --{ running }--[ ]-- 90 | A:srlinux# show network-instance default route-table ipv4-unicast summary 91 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 92 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 93 | | Prefix | ID | Route Type | Route Owner | Active | Metric | Pref | Next-hop (Type) | Next-hop Interface | 94 | +===================================================+=======+============+======================+======================+==========+=========+===============================+===============================+ 95 | | 192.0.2.0/24 | 3 | local | net_inst_mgr | True | 0 | 0 | 192.0.2.1 (direct) | ethernet-1/2.0 | 96 | | 192.0.2.1/32 | 3 | host | net_inst_mgr | True | 0 | 0 | None (extract) | None | 97 | | 192.0.2.255/32 | 3 | host | net_inst_mgr | True | 0 | 0 | None (broadcast) | | 98 | | 203.0.113.0/24 | 0 | bgp | bgp_mgr | True | 0 | 170 | 2001:db8::222 (indirect) | ethernet-1/1.0 | 99 | +---------------------------------------------------+-------+------------+----------------------+----------------------+----------+---------+-------------------------------+-------------------------------+ 100 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 101 | IPv4 prefixes with active routes : 4 102 | IPv4 prefixes with active ECMP routes: 0 103 | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- 104 | A:srlinux# 105 | ``` 106 | 107 | ### Is next-hop address resolution working? 108 | 109 | Yes: 110 | 111 | ``` 112 | --{ running }--[ ]-- 113 | A:srlinux# show network-instance default protocols bgp routes ipv4 prefix 203.0.113.0/24 114 | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Show report for the BGP routes to network "203.0.113.0/24" network-instance "default" 115 | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Network: 203.0.113.0/24 116 | Received Paths: 1 117 | Path 1: 118 | Route source : neighbor 2001:db8::254 119 | Route Preference: MED is -, LocalPref is 100 120 | BGP next-hop : 2001:db8::222 121 | Path : i [65222] 122 | Communities : None 123 | Path 1 was advertised to: 124 | [ ] 125 | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------{ running }--[ ]-- 126 | A:srlinux# show network-instance default protocols bgp neighbor 2001:db8::254 127 | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------BGP neighbor summary for network-instance "default" 128 | Flags: S static, D dynamic, L discovered by LLDP, B BFD enabled, - disabled, * slow 129 | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+------------------------------------------+----------------------------+----------+---------------+-----------------------+-----------------------+--------------------+------------------------------------------+ 130 | | Net-Inst | Peer | Group | Flags | Peer-AS | State | Uptime | AFI/SAFI | [Rx/Active/Tx] | 131 | +============================+==========================================+============================+==========+===============+=======================+=======================+====================+==========================================+ 132 | | default | 2001:db8::254 | rs | S | 65254 | established | 0d:0h:12m:43s | ipv4-unicast | [1/1/1] | 133 | +----------------------------+------------------------------------------+----------------------------+----------+---------------+-----------------------+-----------------------+--------------------+------------------------------------------+ 134 | -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------Summary: 135 | 1 configured neighbors, 1 configured sessions are established,0 disabled peers 136 | 0 dynamic peers 137 | --{ running }--[ ]-- 138 | A:srlinux# 139 | ``` 140 | 141 | ### What does traceroute look like? 142 | Trace is from client connected to ethernet-1/2: 143 | ``` 144 | [root@client1 /]# traceroute 203.0.113.1 145 | traceroute to 203.0.113.1 (203.0.113.1), 30 hops max, 60 byte packets 146 | 1 192.0.2.1 (192.0.2.1) 1.968 ms * * 147 | 2 203.0.113.1 (203.0.113.1) 0.505 ms 0.632 ms 0.734 ms 148 | [root@client1 /]# 149 | ``` 150 | a bigger setup would be interesting. 151 | 152 | ### What happens if peer is not configured to use RFC8950 next hops? 153 | To be tested. 154 | 155 | ### How do you add route filters for IPv4? 156 | To be tested. 157 | 158 | ### What happens if peer sets an IPv4 address on the peering interface? 159 | To be tested. 160 | -------------------------------------------------------------------------------- /examples/Nokia_SROS.md: -------------------------------------------------------------------------------- 1 | # Nokia SROS 2 | 3 | ## Minimum Software Version 4 | 5 | RFC8950 compliant functionalities have successfully been tested with Nokia SR OS 20.2.R1. 6 | 7 | ## Configuration 8 | 9 | ``` 10 | configure { 11 | policy-options { 12 | prefix-list "Match1" { 13 | prefix 1.1.1.1/32 type exact { 14 | } 15 | } 16 | policy-statement "AcceptAny" { 17 | default-action { 18 | action-type accept 19 | } 20 | } 21 | policy-statement "Announce-Lo" { 22 | entry 10 { 23 | from { 24 | prefix-list ["Match1"] 25 | } 26 | action { 27 | action-type accept 28 | } 29 | } 30 | } 31 | } 32 | port 1/1/c1 { 33 | admin-state enable 34 | description "-" 35 | connector { 36 | breakout c1-100g 37 | } 38 | } 39 | port 1/1/c1/1 { 40 | admin-state enable 41 | description "to IXP" 42 | ethernet { 43 | mode network 44 | } 45 | } 46 | router "Base" { 47 | autonomous-system 65009 48 | interface "T1" { 49 | admin-state enable 50 | loopback 51 | ipv4 { 52 | primary { 53 | address 10.9.0.1 54 | prefix-length 32 55 | } 56 | } 57 | } 58 | interface "system" { 59 | admin-state enable 60 | ipv4 { 61 | primary { 62 | address 10.99.99.1 63 | prefix-length 32 64 | } 65 | } 66 | ipv6 { 67 | address 2001:db8::9 { 68 | prefix-length 128 69 | } 70 | } 71 | } 72 | interface "to IXP" { 73 | admin-state enable 74 | port 1/1/c1/1 75 | ipv6 { 76 | forward-ipv4-packets true 77 | address 2001:7f8:19:6::9:1 { 78 | prefix-length 64 79 | } 80 | } 81 | } 82 | bgp { 83 | admin-state enable 84 | family { 85 | ipv4 true 86 | } 87 | import { 88 | policy ["AcceptAny"] 89 | } 90 | export { 91 | policy ["Announce-Lo"] 92 | } 93 | extended-nh-encoding { 94 | ipv4 true 95 | } 96 | advertise-ipv6-next-hops { 97 | ipv4 true 98 | } 99 | group "4over6" { 100 | } 101 | neighbor "2001:7f8:19:6::1:1" { 102 | admin-state enable 103 | group "4over6" 104 | peer-as 65001 105 | import { 106 | policy ["AcceptAny"] 107 | } 108 | export { 109 | policy ["Announce-Lo"] 110 | } 111 | } 112 | } 113 | } 114 | } 115 | ``` 116 | 117 | There are three important lines: 118 | 119 | 1. `forward-ipv4-packets true` in the context of the interface config. This allows to forward IPv4 packets even though the interface is operationally down for IPv4. 120 | 2. `extended-nh-encoding { ipv4 true }` in the bgp context. This enables accepting IPv4 routes with IPv6 next hops. 121 | 3. `advertise-ipv6-next-hops { ipv4 true }` in the bgp context. This enables sending of IPv6 next hops for IPv4 routes. 122 | 123 | ## Testing 124 | 125 | ### Are the routes getting accepted? 126 | 127 | Example: 128 | 129 | ``` 130 | A:admin@peer-t# show router route-table 131 | 132 | =============================================================================== 133 | Route Table (Router: Base) 134 | =============================================================================== 135 | Dest Prefix[Flags] Type Proto Age Pref 136 | Next Hop[Interface Name] Metric 137 | ------------------------------------------------------------------------------- 138 | 10.1.0.0/24 Remote BGP 00h01m10s 170 139 | 2001:7f8:19:6::1:1 0 140 | 10.1.1.0/24 Remote BGP 00h01m10s 170 141 | 2001:7f8:19:6::1:1 0 142 | 10.9.0.1/32 Local Local 01h12m56s 0 143 | T1 0 144 | 10.99.99.1/32 Local Local 04d23h46m 0 145 | system 0 146 | ------------------------------------------------------------------------------- 147 | No. of Routes: 4 148 | Flags: n = Number of times nexthop is repeated 149 | B = BGP backup route available 150 | L = LFA nexthop available 151 | S = Sticky ECMP requested 152 | =============================================================================== 153 | ``` 154 | 155 | ### Is next-hop address resolution working? 156 | 157 | Yes: 158 | 159 | ``` 160 | A:admin@peer-t# routes 10.1.1.0 161 | =============================================================================== 162 | BGP Router ID:10.99.99.1 AS:65009 Local AS:65009 163 | =============================================================================== 164 | Legend - 165 | Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid 166 | l - leaked, x - stale, > - best, b - backup, p - purge 167 | Origin codes : i - IGP, e - EGP, ? - incomplete 168 | 169 | =============================================================================== 170 | BGP IPv4 Routes 171 | =============================================================================== 172 | Flag Network LocalPref MED 173 | Nexthop (Router) Path-Id IGP Cost 174 | As-Path Label 175 | ------------------------------------------------------------------------------- 176 | u*>? 10.1.1.0/24 None None 177 | 2001:7f8:19:6::1:1 None 0 178 | 65001 - 179 | ------------------------------------------------------------------------------- 180 | Routes : 1 181 | =============================================================================== 182 | 183 | A:admin@peer-t# show router neighbor 184 | 185 | =============================================================================== 186 | Neighbor Table (Router: Base) 187 | =============================================================================== 188 | IPv6 Address Interface 189 | MAC Address State Expiry Type RTR 190 | ------------------------------------------------------------------------------- 191 | 2001:7f8:19:6::1:1 to IXP 192 | 0c:00:4f:a6:28:45 STALE 03h59m59s Dynamic Yes 193 | fe80::e00:4fff:fea6:2845 to IXP 194 | 0c:00:4f:a6:28:45 STALE 02h50m28s Dynamic No 195 | ------------------------------------------------------------------------------- 196 | No. of Neighbor Entries: 2 197 | =============================================================================== 198 | ``` 199 | 200 | ### What does traceroute look like? 201 | To be tested. 202 | 203 | ### What happens if peer is not configured to use RFC8950 next hops? 204 | To be tested. 205 | 206 | ### How do you add route filters for IPv4? 207 | To be tested. 208 | 209 | ### What happens if peer sets an IPv4 address on the peering interface? 210 | To be tested. 211 | -------------------------------------------------------------------------------- /examples/README.md: -------------------------------------------------------------------------------- 1 | # Config Examples 2 | 3 | Put config examples for different platforms and routing daemons in this directory. 4 | 5 | ## Findings So Far 6 | 7 | Links in the **Platform** column go to config examples for that platform. 8 | | Vendor | Platform | Software Version | Notes | 9 | | ------ | -------- | ---------------- | ----- | 10 | | RtBrick | [RBFS](RtBrick_RBFS.md) | All versions | Full support | 11 | | Arista | [EOS](Arista_EOS.md) | 4.22.1F | Some support already in 4.17 | 12 | | Cisco | IOS XE | not supported | IPv6 next hop support for VPN routes since 17.8.1 | 13 | | Cisco | [IOS XR](Cisco_IOSXR.md) | [7.3.3](https://www.ausnog.net/sites/default/files/ausnog-2022/presentations/ausnog_2022-day2-07-cooper_lees-who_needs_arp_v4_via_v6.pdf) | | 14 | | Cisco | NX-OS | ? | to be tested | 15 | | CZNIC | Bird1 | not supported | Bird1 does not and will not support RFC8950 | 16 | | CZNIC | [Bird2](Bird2.md) | 2.0.8 | RIB-only since 2.0.0; Linux kernel version 5.2 required | 17 | | CZNIC | [Bird3](Bird2.md) | 3.0.0 | Bird3 config wrt RFC8950 settings is identical to Bird2 | 18 | | Exa | ExaBGP | 4.1.0 | Cannot program Linux netlinks for RFC5549 | 19 | | Extreme Networks | IronWare, SLX-OS | not supported | verified with vendor | 20 | | Juniper | [Junos](Juniper_JunOS.md) | 17.3R1 | | 21 | | Mikrotik | ROS | [not supported](https://help.mikrotik.com/docs/display/ROS/Routing+Protocol+Overview) | (last checked: 7.18) | 22 | | NetDEF | [FRR](FRRouting.md) | 7.0.0 | Linux kernel version 5.2 required | 23 | | Nokia | [SR-OS](Nokia_SROS.md) | 20.2.R1 | | 24 | | Nokia | [SR Linux](Nokia_SR-Linux.md) | 20.06 | tested on 22.6.4 | 25 | | OSRG | [GoBGP](GoBGP.md) | supported for several years | no FIB integration tested | 26 | | RSSF | OpenBGPd | not supported | on the [roadmap](https://www.rssf.nl/roadmap) | 27 | | Edgecore | OCNOS | not supported in 1.3.8 | Awaiting further comment from OCNOS developers | 28 | | Vyatta | VyOS | 1.2.2 | See FRR above || 29 | 30 | ## Check List for Testing 31 | 32 | ### Configuration 33 | * Find out minimum software requirements 34 | * What's the configuration difference between IPv4 next-hops and RFC8950 next-hops over an IPv6 BGP session? 35 | * Configure EBGP peer that uses RFC8950 style next hops 36 | * Configure source address/interface for ICMP Unreachables, if possible 37 | ### Testing 38 | * Are the routes getting accepted? 39 | * Is next-hop address resolution working? 40 | * What does traceroute look like? 41 | * How do you add route filters for IPv4? 42 | - Is it possible to add a separate route filter for IPv4 and IPv6 routes? 43 | * What happens if peer is not configured to use RFC8950 next hops? 44 | - Errors? Warnings? Alerts? 45 | - Blackholing? 46 | - Turn down session as a fail safe? 47 | - Other misconfiguration cases? 48 | * What happens if peer sets an IPv4 address on the peering interface? 49 | - Will the next-hops still be IPv6? 50 | - Will traceroutes now use this address instead of a loopback? 51 | - Could ISPs set up a /32 address on the interface to have a specific name show up in traceroutes? 52 | -------------------------------------------------------------------------------- /examples/RtBrick_RBFS.md: -------------------------------------------------------------------------------- 1 | # RtBrick RBFS 2 | 3 | ## Minimum Software Version 4 | 5 | All versions of RBFS support RFC5549. 6 | 7 | ## Configuration 8 | 9 | ``` 10 | interface ifp-0/0/0 { 11 | unit 0 { 12 | address { 13 | ipv6 2001:db8:0:1::/127 { 14 | } 15 | } 16 | } 17 | } 18 | interface lo-0/0/0 { 19 | unit 0 { 20 | address { 21 | ipv4 192.0.2.1/32 { 22 | } 23 | ipv6 2001:db8::1/128 { 24 | } 25 | } 26 | } 27 | } 28 | instance default { 29 | protocol { 30 | bgp { 31 | hostname B1; 32 | local-as 65501; 33 | router-id 192.0.2.1; 34 | address-family ipv4 unicast { 35 | redistribute direct { 36 | } 37 | } 38 | address-family ipv6 unicast { 39 | redistribute direct { 40 | } 41 | } 42 | peer { 43 | ipv6 2001:db8:0:1::1 2001:db8:0:1::0 { 44 | peer-group peer-65502; 45 | } 46 | } 47 | peer-group peer-65502 { 48 | remote-as 65502; 49 | address-family ipv4 unicast { 50 | extended-nexthop true; 51 | nexthop-self true; 52 | } 53 | address-family ipv6 unicast { 54 | nexthop-self true; 55 | } 56 | } 57 | } 58 | } 59 | } 60 | 61 | ``` 62 | 63 |
64 | 65 | Configuration in 'set' format 66 | 67 | 68 | ``` 69 | set interface ifp-0/0/0 70 | set interface ifp-0/0/0 unit 0 71 | set interface ifp-0/0/0 unit 0 address 72 | set interface ifp-0/0/0 unit 0 address ipv6 2001:db8:0:1::/127 73 | set interface lo-0/0/0 74 | set interface lo-0/0/0 unit 0 75 | set interface lo-0/0/0 unit 0 address 76 | set interface lo-0/0/0 unit 0 address ipv4 192.0.2.1/32 77 | set interface lo-0/0/0 unit 0 address ipv6 2001:db8::1/128 78 | set instance default 79 | set instance default protocol bgp hostname B1 80 | set instance default protocol bgp local-as 65501 81 | set instance default protocol bgp router-id 192.0.2.1 82 | set instance default protocol bgp address-family ipv4 unicast 83 | set instance default protocol bgp address-family ipv4 unicast redistribute direct 84 | set instance default protocol bgp address-family ipv6 unicast 85 | set instance default protocol bgp address-family ipv6 unicast redistribute direct 86 | set instance default protocol bgp peer ipv6 2001:db8:0:1::1 2001:db8:0:1::0 87 | set instance default protocol bgp peer ipv6 2001:db8:0:1::1 2001:db8:0:1::0 peer-group peer-65502 88 | set instance default protocol bgp peer-group peer-65502 89 | set instance default protocol bgp peer-group peer-65502 remote-as 65502 90 | set instance default protocol bgp peer-group peer-65502 address-family ipv4 unicast 91 | set instance default protocol bgp peer-group peer-65502 address-family ipv4 unicast extended-nexthop true 92 | set instance default protocol bgp peer-group peer-65502 address-family ipv4 unicast nexthop-self true 93 | set instance default protocol bgp peer-group peer-65502 address-family ipv6 unicast 94 | set instance default protocol bgp peer-group peer-65502 address-family ipv6 unicast nexthop-self true 95 | 96 | ``` 97 | 98 |
99 | 100 | 101 | Important lines are: 102 | 103 | 1. At least one (loopback) interface with an IPv4 address. This address will be used for answering ICMP unreachables or during traceroutes.(*) 104 | 2. `nexthop-self true` as this is not the default. 105 | 4. `extended-nexthop true` needs to be enabled to negotiate IPv4 NRLIs with IPv6 nexthop. 106 | 107 | 108 | ## Testing 109 | 110 | ### Are the routes getting accepted? 111 | 112 | Example: 113 | 114 | ``` 115 | B2.rtbrick.net: op> show bgp rib-in ipv4 116 | Flags: & - Imported, ! - Error, N - RPKI Unknown, I - RPKI Invalid, V - RPKI Valid 117 | Instance: default, AFI: ipv4, SAFI: unicast 118 | Hostname: Local, Peer IP: 0.0.0.0 119 | Source IP: 0.0.0.0, Total routes: 1 120 | Flags Prefix Next Hop MED Lpref AS Path 121 | 192.0.2.2/32 - 0 100 - 122 | Hostname: B1, Peer IP: 2001:db8:0:1:: 123 | Source IP: 2001:db8:0:1::1, Total routes: 2 124 | Flags Prefix Next Hop MED Lpref AS Path 125 | 192.0.2.1/32 2001:db8:0:1:: 0 - 65501 126 | 127 | ``` 128 | 129 | ### Is next-hop address resolution working? 130 | 131 | Yes: 132 | 133 | ``` 134 | B2.rtbrick.net: op> show route prefix 192.0.2.1/32 detail 135 | Instance: default, AFI: ipv4, SAFI: unicast 136 | Prefix: 192.0.2.1/32 137 | Source: bgp, Preference: 20 138 | Next Hop: 2001:db8:0:1:: 139 | Covering prefix: 2001:db8:0:1::/128 140 | Next Hop type: direct, Next Hop action: None 141 | Resolved in: default-ipv6-unicast(Primary) 142 | Outgoing Interface: ifp-0/0/0/0, NextHop MAC: 7a:01:61:c0:00:00 143 | 144 | 145 | ``` 146 | 147 | For more information, see the [RBFS documentation](https://documents.rtbrick.com/) -------------------------------------------------------------------------------- /presentations/README.md: -------------------------------------------------------------------------------- 1 | Place presentations given by working group members here... 2 | -------------------------------------------------------------------------------- /presentations/ipv6-only-ixps.odp: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/euro-ix/rfc8950-ixp/ef19225f5edf5ba7dc38b7032284a996fe5417df/presentations/ipv6-only-ixps.odp -------------------------------------------------------------------------------- /presentations/ipv6-only-ixps.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/euro-ix/rfc8950-ixp/ef19225f5edf5ba7dc38b7032284a996fe5417df/presentations/ipv6-only-ixps.pdf -------------------------------------------------------------------------------- /presentations/w12 BGP Announcing IPv4 with IPv6 next-hop.pdf: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/euro-ix/rfc8950-ixp/ef19225f5edf5ba7dc38b7032284a996fe5417df/presentations/w12 BGP Announcing IPv4 with IPv6 next-hop.pdf --------------------------------------------------------------------------------