LRI operations report, 2021-W17/2021-W18
This is the report for 26 April 2021–9 May 2021 on the state and activities of the Lorkep Long-Range Interconnect, a virtual network and autonomous system operating on dn42. For the most part, these weeks were focused on the upgrade and internal restructuring of NixOS configurations, with a few externally observable changes.
Bird has been upgraded to 2.0.8, enabling the activation of two new options:
enforce first as and
enforce first as, Bird rejects routes in which the latest AS number in
AS_PATH does not match the AS number of the peer the route was received from. This is an optional check defined in RFC 4271 § 6.3, and may detect misconfiguration of a BGP peer.
advertise hostname implements the Hostname Capability for BGP draft RFC that exposes a human-readable hostname to BGP peers. It is not very useful to Bird users in dn42 as most rely on protocol names, but it may make things easier to users of other routing software.
In the peering front, the LRI is now connected to AS4242423770 through Shingebiss, and the existing connection on Behemoth was updated to peer with a closer node. A new peering with AS4242421288 has also been established via Behemoth.
Expanded availability of SSH host certificates
The SSH host certificate experiment started during the previous fortnight was concluded successfully, with host certificates now implemented in all LRI nodes.
Changes in 464XLAT deployment
Charybdis operates a recursive DNS resolver for Lorkep users, and more recently, for all of dn42. Containerization of this service prompted deployment of a 464XLAT customer-side (SIIT) translator to translate IPv4 packets coming from the container to Charybdis into IPv6 packets, which are then forwarded to Behemoth’s provider-side (NAT64) translator, translated back into NATed IPv4, and sent to the Internet.
A side-effect of this arrangement is that DNS responses received from authoritative servers over IPv4 are localized to Behemoth in Germany, not to Charybdis in Brazil. Enabling the EDNS Client Subnet extension wouldn’t help as the clients are all in private networks.
The first attempt to solve this situation was simply to enable NAT64 translation on Charybdis, however that proved to interfere with the SIIT translation already in place. An old idea then resurfaced, and proved to work flawlessly: node-based translation.
In the existing setup, both Charybdis and the containers running on it receive IPv4 addresses, and when a container sends an IPv4 packet to the Internet, it is received by Charybdis and then translated to IPv6. With node-based translation, this process is performed inside a network namespace; the packets sent to Charybdis are already IPv6.
A minor hurdle is that Jool’s documentation uses one IPv6 source address for native IPv6 packets and another for translated IPv4 packets, so that responses to originally-IPv4 requests can be properly forwarded to Jool. Use of a single IPv6 address can be achieved by using source-based routing to translate only packets coming from the well-known translation prefix
Task list for 2021-W19
- As part of the development of a LRI-specific website, a rename of the network is being debated. If decided for, the results may start showing up this week.
View comments to this post or send your own