A while back, I wrote about what I wish I knew when I got my ASN, which has helped many embark upon the epic quest of hobby networking. I’ve also written plenty about the theory of Internet routing. However, what was conspicuously missing was an introductory practical guide to make use of a new ASN and IP space. I’ve decided to rectify this gap now.

For this exercise, I will breathe new life into my original ASN, which I’ve since replaced globally with the new ARIN ASN 54148 for my main network.1 Now, I will set up AS200351 on a new BGP VM2 on AS54148’s infrastructure as a downstream, i.e. AS54148 will be the service provider that connects AS200351 to the Internet.

Prerequisites

If you want to follow along, you must have your own ASN and IP prefix. If not, please go back to the previous post in the series and figure that part out first.

You must also have a BGP-capable upstream. If you don’t, you can get a cheap VPS for $5/month or less. Here are several providers with which I’ve had good experiences, but of course, your mileage may vary:

There are more providers available on bgp.cheap and bgp.services, which are maintained by community members, but I can’t vouch for anything listed therein personally. Please exercise your own judgement before spending your own hard-earned money.

When selecting upstreams, the most important thing is probably latency, especially if you plan to use a tunnel to use your own IPs at home. Find test IPs (or looking glass IPs) for candidate locations from candidate providers, and compare the ping times from your location, and prefer the ones with the lowest ping.

Also, look for diverse connectivity. A general rule of thumb is to look up the test IPs on bgp.tools and see if there are many diverse paths to tier 1 ISPs (as opposed to reaching all other tier 1s through one tier 1), and also look up the ASN there to see which Internet exchanges they are on. Prefer the ones with multiple distinct tier 1 paths and more Internet exchange connectivity, especially ones local to the server location.

Platform

For the BGP VM, I am running the latest Debian stable release at the time of writing, which is Debian 13, codenamed trixie. If you are following along with some kind of VPS or a dedicated server, I would advise using something similar. Installation of Debian is out of scope for this post and is something you will need to arrange with your server provider, perhaps through the control panel.

We will be using the Linux kernel to do any actual packet forwarding, which is plenty for a hobby network, instead of using something more niche like Vector Packet Processing (VPP).

For the routing daemon, we will be using the BIRD 2.x series, which is the most stable and battle-tested version of BIRD at the point of writing. Specifically, we will use version 2.17.1, which comes with trixie, but 2.0.12 that came with bookworm (Debian 12) would work just as well.

We will also be using my BIRD filter library to do some basic route filtering. We’ll save setting up IRR and RPKI filtering for the next time.

Preparing IP space

Before announcing IP space, you need to make sure that IRR and RPKI on the prefixes are set up correctly so that everyone else on the Internet will accept your route.

For this exercise, I will use the following real IPv6 space:

  • 2602:fa43:f0::/48 (ARIN); and
  • 2a07:54c1:d351::/48 (RIPE).

This will allow me to show how to configure IP space on both ARIN and RIPE.

IRR

Setting up IRR entries for the IP space depends on whether the IP space has been reassigned to you or not. If you rented IP space from an LIR and they chose to not delegate the prefix fully to you, then you would need to inform them about which prefix you intend to announce from which ASN.

If you have received space directly from ARIN, you can follow ARIN’s documentation on IRR-online to create a route6 object, e.g. for 2602:fa43:f0::/48 and AS200351. The end result should look something like:

$ whois -h rr.arin.net 2602:fa43:f0::/48
route6:         2602:fa43:f0::/48
origin:         AS200351
descr:          DQN Test Network
admin-c:        DQNA-ARIN
tech-c:         DQNOC-ARIN
mnt-by:         MNT-GC-1348
created:        2025-10-05T21:08:36Z
last-modified:  2025-10-05T21:08:36Z
source:         ARIN

If you have received space directly from RIPE, or your LIR has granted you mnt-by or mnt-routes access to the prefix, you can just log into the RIPE database and go to this page (RIPE database → Create an object → route6) and enter the IPv6 prefix and ASN (with the AS prefix), then press “submit”. You should get something like:

$ whois -h whois.ripe.net 2a07:54c1:d351::/48AS200351
...
route6:         2a07:54c1:d351::/48
origin:         AS200351
mnt-by:         QUANTUM-MNT
created:        2025-10-06T03:58:36Z
last-modified:  2025-10-06T03:58:36Z
source:         RIPE
...

RPKI

Setting up RPKI Route Origin Authorizations depends strongly on whether you received the space directly from an RIR or from an LIR reselling it to you.

If you have received IP space directly from an RIR, consult the RIR’s documentation for using hosted RPKI, e.g. ARIN’s guide with videos or RIPE’s documentation. Delegated RPKI is also possible, but not something I would recommend for a beginner. If you insist, look at the Krill documentation.

Otherwise, inform the reseller about which prefix you plan to announce from which ASN, and they will take care of it for you.

IPv4

Since IPv4 space doesn’t come cheap, I will just use 192.0.2.0/24 as an example, since I don’t exactly have spare IPv4 prefixes. The process of IRR and RPKI is basically the same for IPv4, except instead of creating a route6 object, you’d create a route object.

Requesting a BGP session

The other thing to do before we can start announcing IPs to the Internet is to inform the desired upstreams and get them to set up a BGP session.

Since I run AS54148, I don’t need to talk with myself, but this is what your upstream might ask before they set up the BGP session, and to save time, it would be good to do this pre-emptively:

  1. Create an as-set, which I’ve described last time, but to summarize: create the equivalent of AS200351:as-all for your ASN. Mine looks something like:

    $ whois -h rr.arin.net AS200351:as-all
as-set:         AS200351:AS-ALL
members:        AS200351
...
source:         ARIN
...

    At this stage, simply include your own ASN as a member. You may include other ASNs once you are upstreaming other ASes, but that’s left as an exercise for the reader.

  2. Edit your aut-num to include something like this, with AS54148 replaced with your upstream’s ASN and AS200351 replaced with your ASN: 
    import:         from AS54148 accept ANY
mp-import:      afi any.unicast from AS54148 accept ANY
export:         to AS54148 announce AS200351:as-all
mp-export:      afi any.unicast to AS54148 announce AS200351:as-all

    This declares to the world that you intend to your upstream of choice to be your upstream and that you aren’t an impostor trying to trick someone into letting you use someone else’s ASN. Repeat this for each upstream ASN.

    Note that on ARIN, you may have to create the aut-num object in the IRR.3 The IRR-online documentation also explains how to do this.

  3. Some upstreams, especially in the Asia–Pacific region, may ask for a letter of authorization (LOA) to announce the IPs. Unless an upstream explicitly requires one, I wouldn’t bother preparing it ahead of time. If you do, you can use a website like loa.tools to generate one or use the following template:

    To whom it may concern,

    This letter serves as authorization for Example ISP (AS64500) to announce the following IP ranges:

    • 192.0.2.0/24
    • 2001:db8::/32

    As a representative of Example LIR, the owner of the aforementioned IP ranges, I hereby declare that I am authorized to represent and sign this letter of authorization. This authorization shall remain in effect until revoked or modified in writing.

    Should you have any questions about this request, please email me at john@example.com or call me at +1 (555) 555-5555.

    Sincerely,

    Signature for John Smith

    John Smith
    CEO of Example LIR

    If your space is leased from another LIR, they would need to be the ones to generate such an LOA, which may prove to be a tedious process on their end. Therefore, don’t ask unless absolutely necessary.

  4. Decide if you want to receive a default route or a full table over BGP. A full table means the complete Internet routing table, containing every single route that’s on the Internet. This is typically only necessary if you have multiple upstreams and would like to use the best upstream for each destination, and uses a lot more resources. When in doubt, ask for a default route instead.

    Note that some upstreams may insist on giving you a full table anyway, in which case you can filter out the unwanted routes with a filter to save on resources.

Once you’ve done the preparations, send the following information to your upstream, often by ticket, but sometimes they may have special automated forms for you to fill out:

  1. Your ASN;
  2. Your as-set (optional if you don’t want to do downstreams, and some providers may not allow downstreaming anyway);
  3. Whether you want default routes or a BGP full table;
  4. A list of prefixes you wish to announce, since some upstreams don’t generate filters from IRR or RPKI for whatever reason;4
  5. A list of downstream ASNs if downstreaming, since some upstreams want an explicit list instead of letting you upstream arbitrary ASNs for fear of route hijacking; and
  6. The IP addresses on your end where you want the session to be established. Typically, this is the IPv4 and IPv6 address allocated to your server, but if your server comes with multiple IP addresses, this requires clarification.

For AS200351, this is what I would tell AS54148, i.e. myself:

  1. ASN: AS200351;
  2. AS-set: AS200351:as-all;
  3. Default routes only;
  4. Prefixes to announce:
    • 192.0.2.0/24,
    • 2602:fa43:f0::/48. and
    • 2a07:54c1:d351::/48;
  5. No downstreams; and
  6. IP addresses on my end: 203.0.113.2 and 2001:db8::2.

If all goes well, your upstream will tell you the IP addresses for the BGP session on their end. Otherwise, answer any additional questions they might have.

For this exercise, pretend this is what AS54148 told AS200351:

The BGP session is set up. IP addresses on our end are 203.0.113.1 and 2001:db8::1.

Installing BIRD

On Debian, installing BIRD 2.x is as simple as:

sudo apt install bird2

For the basic setup, download my filter_bgp.conf as /etc/bird/filter_bgp.conf, making sure to change MY_ASN to your ASN:

sudo wget -O /etc/bird/filter_bgp.conf https://raw.githubusercontent.com/quantum5/bird-filter/refs/heads/master/filter_bgp.conf
sed -i -e '/define MY_ASN/c\define MY_ASN = 200351;' /etc/bird/filter_bgp.conf

(Or just edit filter_bgp.conf with a normal editor like a sane person.)

Then, replace /etc/bird/bird.conf wotj the following BIRD configuration template:

log syslog all;

# This is a 32-bit identifier that should be unique among your peers.
# FIXME: Change this to one of your router's IPv4 addresses if you can.
# If you have none, pick something random from 240.0.0.0/4.
# For this exercise, I am using the IPv4 BGP session address.
router id 203.0.113.2;

protocol kernel {
    scan time 60;
    ipv4 {
        # Note: this just avoids exporting the virtual default route in
        # filter_bgp.conf to the kernel.
        export where source != RTS_STATIC || proto != "default_v4";

        # NOTE: this basic export above doesn't make the routes inserted into
        # the kernel prefer your own IPs. Things will work fine with your
        # server's IP assigned by the provider if you have a single upstream
        # but strange things will happen if you have more than one peer.
        # Instead, to use your own IP as the default source IP for outgoing
        # connections on your system, add an IP from your range to an interface
        # on your system (which is explained later), remove the line above, and
        # use the block below, changing 192.0.2.1 to the IP used.
        #
        # export filter {
        #     if source = RTS_STATIC && proto = "default_v4" then reject;
        #     # FIXME change the IP to one of yours that you want to prefer
        #     if source = RTS_BGP then krt_prefsrc = 192.0.2.1;
        #     accept;
        # };
    };
}

protocol kernel {
    scan time 60;
    ipv6 {
        # Note: same as above.
        export where source != RTS_STATIC || proto != "default_v6";

        # NOTE: similar to above, use the following block to change the default
        # source IP for outgoing connections.
        #
        # export filter {
        #     if source = RTS_STATIC && proto = "default_v6" then reject;
        #     # FIXME change the IP to one of yours that you want to prefer
        #     if source = RTS_BGP then krt_prefsrc = 2602:fa43:f0::1;
        #     accept;
        # };
    };
}

protocol device {
    scan time 60;
}

include "filter_bgp.conf";

protocol static node_v4 {
    ipv4;

    # The "reject" here tells bird to drop all traffic to the prefix by default.
    # If you have more specific routes, they will take precedence and be used.
    # So this really just tells bird (and the kernel) to drop traffic for
    # UNUSED portions of your prefix instead of sending it back out to your
    # upstream and creating a routing loop.
    #
    # FIXME: Replace these with your own IP addresses, or delete if there are none.
    route 192.0.2.0/24 reject;
}

protocol static node_v6 {
    ipv6;

    # See above for what "reject" means.
    # FIXME: Replace these with your own IP addresses.
    route 2602:fa43:f0::/48 reject;
    route 2a07:54c1:d351::/48 reject;
}

# And now for our upstreams:
# FIXME: rename the BGP protocol to contain the name of your upstream.
protocol bgp dqn_v4 {
    # FIXME: change this description.
    description "AS54148 Upstream (IPv4)";

    # FIXME: change the IP addresses and the ASNs here.
    local 203.0.113.2 as 200351;
    neighbor 203.0.113.1 as 54148;

    default bgp_local_pref 50;

    ipv4 {
        import keep filtered;

        # Note that import_transit(upstream_asn, true) means accepting
        # default routes. If you want to reject default routes and take a full
        # table, pass false.
        # FIXME: change the ASNs here to your upstream's.
        import where import_transit(54148, true);
        export where export_cone(54148);
    };
}

# FIXME: rename the BGP protocol to contain the name of your upstream.
protocol bgp dqn_v6 {
    # FIXME: change this description.
    description "AS54148 Upstream (IPv6)";

    # FIXME: change the IP addresses and the ASNs here.
    local 2001:db8::2 as 200351;
    neighbor 2001:db8::1 as 54148;

    default bgp_local_pref 50;

    ipv6 {
        import keep filtered;

        # Meaning of true is defined above.
        # FIXME: change the ASN here to your upstream's.
        import where import_transit(54148, true);
        export where export_cone(54148);
    };
}

Note that if you are already running BIRD for other reasons, you will need to merge the configuration. You should have a single instance of protocol device and two instances of protocol kernel, one for IPv4 and the other for IPv6. You may need to merge the export filters for the latter.

As for bgp_local_pref, a higher value means routes received from that BGP session are more preferred. The exact values are specific to each AS, but I would recommend starting with something like this:

  • 50 for upstreams;
  • 90 for IXPs;
  • 100 for direct peers; and
  • 120 for downstreams.

If you have multiple upstreams, you can use 60 for a more preferred upstream as needed, for example.

If your upstream insists on sending you a full table and you don’t want it, you can change the import filter to net.len = 0 && import_transit([asn], true).

If you want to take a full table and reject any default route, say because you have multiple upstreams, you can import_transit([asn], false). This will insert around a million IPv4 routes and 230k IPv6 routes, so be sure that’s what you want.

Finally, double check that you’ve fixed all the things tagged FIXME in the config.

Once you are done, run sudo birdc configure. If there are any errors, it will tell you, in which case, fix your configuration.

Otherwise, you should see the BGP session come up with sudo birdc show protocols (or just sudo birdc s p):

$ sudo birdc s p
BIRD 2.17.1 ready.
Name       Proto      Table      State  Since         Info
device1    Device     ---        up     03:42:46.786  
default_v4 Static     master4    up     03:48:38.022  
default_v6 Static     master6    up     03:48:38.022  
node_v4    Static     master4    up     03:48:38.022  
node_v6    Static     master6    up     03:48:38.022  
dqn_v4     BGP        ---        up     03:48:38.172  Established   
dqn_v6     BGP        ---        up     03:49:14.381  Established   
kernel1    Kernel     master4    up     03:42:46.786  
kernel2    Kernel     master6    up     03:42:46.786

As you can see, the sessions are established!

You can see the details for each protocol with sudo birdc show protocol all [name] (or sudo birdc s p a [name]), which might look like:

$ sudo birdc s p a  dqn_v6
BIRD 2.17.1 ready.
Name       Proto      Table      State  Since         Info
dqn_v6     BGP        ---        up     03:49:14.381  Established   
  Description:    AS54148 Upstream (IPv6)
  BGP state:          Established
    Neighbor address: 2001:db8::1
    Neighbor AS:      54148
    Local AS:         200351
    Neighbor ID:      203.0.113.1
    Local capabilities
      Multiprotocol
        AF announced: ipv6
      Route refresh
      Graceful restart
      4-octet AS numbers
      Enhanced refresh
      Long-lived graceful restart
    Neighbor capabilities
      Multiprotocol
        AF announced: ipv6
      Route refresh
      Graceful restart
      4-octet AS numbers
      Enhanced refresh
      Long-lived graceful restart
    Session:          external AS4
    Source address:   2001:db8::2
    Hold timer:       200.709/240
    Keepalive timer:  22.049/80
    Send hold timer:  321.314/480
  Channel ipv6
    State:          UP
    Table:          master6
    Preference:     100
    Input filter:   (unnamed)
    Output filter:  (unnamed)
    Routes:         1 imported, 0 filtered, 2 exported, 0 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:              1          0          0          0          1
      Import withdraws:            0          0        ---          0          0
      Export updates:              3          0          1        ---          2
      Export withdraws:            0        ---        ---        ---          0
    BGP Next hop:   2001:db8::2 fe80::1234:5678:9abc:def0

Confirm that the number of routes imported and exported is as expected under Routes:. Here, as expected, we have:

  1. A single imported route: the default route;
  2. Two IPv6 exported prefixes.

You can ignore Route change stats section as the numbers are not very meaningful.

Common BGP session issues

If your BGP session isn’t showing as established, then something has gone wrong. There are several things to try:

  1. Check if you can ping the BGP neighbour address, as seen in birdc s p a. If you can’t ping the IP, it means the IP might be incorrect and you should verify it with your upstream. If it’s correct, something terrible is wrong with the routing on your system. Fixing that is left as an exercise for the reader, since I don’t know how you got into that state.
  2. Check if the BGP neighbour requires multiple hops to reach. You can run traceroute or mtr on the IP address. If you see more than one hop show up, then you will need to add multihop [number of hops] into the protocol bgp block.
  3. If you have a firewall, ensure TCP port 179 connections are allowed, as it is used for BGP.
  4. Check BIRD logs with journalctl -u bird for any errors.

If you can’t figure this out, ask your upstream, or ask for help in the IPv6 Discord.

Seeing your new prefix on the Internet

You can check that your prefix is visible in the global routing table by going to bgp.tools and entering your prefix, then looking at the connectivity tab.

For example, for the ARIN test prefix used here, you can see that the prefix is fully reachable from the Internet.

If you instead see something like this, it means your prefix isn’t visible on the Internet:

bgp.tools showing a route isn't on DFZ

You should probably give it some time, say a day or two. If it’s still not visible, you should:

  1. Validate that you’ve set up IRR and RPKI correctly with IRR explorer. Enter your IP prefix, and it should tell you if anything is wrong;
  2. Attempt to restart the BGP session with your upstream, e.g. sudo birdc restart dqn_v6, and wait another day or two; and
  3. If nothing worked, you probably need to ask your upstream to update their filters.

Start using your own IPs

Now that your IP prefix has been announced to the Internet, it is time to start using it. This is OS-dependent, but I will use Debian as the example with ifupdown2, which supports multiple IP addresses per interface and can reload without taking down the entire interface, making it a lot more suitable than traditional ifupdown for routers. To install ifupdown2, run:

sudo apt install ifupdown2

This will uninstall the old ifupdown. At this point, either reboot the system or manually run sudo ifup on every interface on the system (including lo, the loopback interface), so that ifupdown2 tracks the interface state.

Simple method to use your prefix on one server

With that done, the simplest way to use it on your server is to add the IP to some interface, such as lo, by making this change in /etc/network/interfaces:

...
auto lo
iface lo inet loopback
    # FIXME replace these with some address inside your prefix.
    address 192.0.2.1
    address 2602:fa43:f0::1
    address 2a07:54c1:d351::1
...

The iface lo inet loopback should already be there and you can just add some lines afterwards. Once that’s done, you can run ifreload -c. If all goes well, the IPs added should now be pingable from the Internet.

Using a bridge

Of course, you probably want to use your IPs on more than a single server. For example, if you want to run some virtual machines or systemd-nspawn containers, you will be attaching VMs or containers to a bridge interface. To do this, you will need to create such a bridge interface and add IPs to it that would serve as the default gateway.

First, install the bridge-utils package:

sudo apt install bridge-utils

For example, to create the bridge br0, add the following stanza to /etc/network/interfaces:

auto br0
iface br0 inet static
    # FIXME replace these with some address inside your prefix.
    address 192.0.2.1/24
    address 2602:fa43:f0::1/64

    # If you want to attach physical interfaces to the bridge, list them instead
    # of `none` here.
    bridge-ports none
    bridge-stp off
    bridge-fd 0

    # This prevents `systemd-nspawn` and common VM interfaces from being kicked
    # off the bridge when running `ifreload -c`.
    bridge-ports-condone-regex ^vnet|^vb-|^br0p0$

    # Note that due to Linux bridge limitations, some interface has to be added
    # to the bridge for it to be considered "up". If you are using
    # `bridge-ports none`, you need to add a dummy interface. Otherwise, the IP
    # addresses on the interface would be considered unreachable.
    # This adds that dummy interface, and the `|| true` ensures it doesn't
    # error out when running `ifreload -c`.
    # You obviously don't need this if you don't use `bridge-ports none`.
    up ip link add name "$IFACE"p0 up master "$IFACE" type dummy || true

Remember to delete the lo addresses if you experimented with that approach earlier.

Note that we use a single /64 of IPv6 for this bridge since that’s all that’s needed for a LAN. You have to announce at least a /48 over BGP, which leaves you with 65535 other /64s to assign to different bridges or other purposes.

For IPv4, you can similarly partition your /24 into smaller blocks. For example, if you only need to add 5 to 13 devices on your network, you can use a /28 instead, using the remainder of the space for other purposes.

Also note that any devices added to the bridge will need to have static IPs configured. Using DHCP and SLAAC is out of scope and left as an exercise for the reader. Something like dnsmasq or radvd comes in handy, and they come with documentation.

Now, you can bring this interface up:

sudo ifup br0
sudo ifreload -c

You’ll also need to turn on IP forwarding. Create /etc/sysctl.d/forwarding.conf with the following contents:

net.ipv6.conf.all.forwarding = 1
# Delete the next line if not using IPv4.
net.ipv4.ip_forward = 1

Run sudo systemctl restart systemd-sysctl to make the changes take effect.

Your IP addresses on the bridge, along with anything else added to the bridge, should now be reachable from the Internet.

Tunnelling

You can obviously also tunnel portions of the IP space. For example, you can run OpenVPN in tap mode and add the tap interface to the bridge to virtually hook up any computer to it and thus use your own IPs, or run WireGuard so that you can route subsets of your IP ranges to other locations. The possibilities are endless.

Here’s a quick WireGuard example. Install wireguard-tools on the server and the client:

sudo apt install wireguard-tools

On the server side, generate a key pair:

$ wg genkey
EFr1rNiP5NsYJYp+J1v5v+D4w9VO7HJwDuH/sgyOv1M=
$ echo EFr1rNiP5NsYJYp+J1v5v+D4w9VO7HJwDuH/sgyOv1M= | wg pubkey
mJv/wYe0PZeOek8ZEsXQ3PAkBzK73kJerikNtDukTW4=

On the client side, generate another key pair:

$ wg genkey
UEgGif7OyKe59WA9BNciAFDBmT0Jw+M7Wf1HYQCOzlY=
$ echo UEgGif7OyKe59WA9BNciAFDBmT0Jw+M7Wf1HYQCOzlY= | wg pubkey
a5MlLRW8tY0NOFhHH8GxUUbytWUGvJiLqGYw5eXn9gI=

Then, on the server, create /etc/wireguard/wg_br0.conf (or whatever you would like to call the interface):

[Interface]
# Change the port to something else if you are already using it for something
# else, including another WireGuard instance.
ListenPort = 51820

# FIXME change these address to your own.
# Note WireGuard is an L3 VPN and can't be bridged, so it requires a separate
# network. Hence, we are using a /25 for IPv4 and a separate /64 for IPv6.
Address = 192.0.2.129/25, 2602:fa43:f0:1::1/64

# FIXME generate your own private keys and use it.
PrivateKey = EFr1rNiP5NsYJYp+J1v5v+D4w9VO7HJwDuH/sgyOv1M=

[Peer]
# FIXME use your own client's public keys.
PublicKey = a5MlLRW8tY0NOFhHH8GxUUbytWUGvJiLqGYw5eXn9gI=

# FIXME change this to IPs used by your client.
# This allows the client to use a single IP, which should be from the same IP
# block as that in `Address` above. You can expand this to something larger to
# allow the client to use more IP space. You can also allow entire subnets, such
# 2602:fa43:f0:2::/64, so that the client has an entire LAN to work with,
# e.g. with a bridge. These don't have to be the same range as `Address`.
AllowedIPs = 192.0.2.130/32, 2602:fa43:f0:1::2/128

# You can repeat [Peer] sections as necessary for more peers.
# Note that WireGuard routes based on AllowedIPs, so make sure they don't
# overlap. Also, ensure that you use different private keys for each client and
# put their public keys in their [Peer] sections.

Now we enable WireGuard:

sudo systemctl enable --now wg-quick@wg_br0

Similar to bridges above, enable forwarding with sysctl.

On the client, create the corresponding configuration file, such as /etc/wireguard/wg_myip.conf:

[Interface]
# This is the IP addresses you want to add on the WireGuard interface,
# as well as anything else that should be routed on the same LAN.
# If you are tunnelling entire separate subnets like 2602:fa43:f0:2::/64, that
# should probably go on its own bridge interface and not here.
# FIXME change this to IPs used by your client.
Address = 192.0.2.130/25, 2602:fa43:f0:1::2/64

# FIXME generate your own private keys and use it.
PrivateKey = UEgGif7OyKe59WA9BNciAFDBmT0Jw+M7Wf1HYQCOzlY=

[Peer]
# FIXME use your own server's public keys.
PublicKey = mJv/wYe0PZeOek8ZEsXQ3PAkBzK73kJerikNtDukTW4=

# This adds a default route to the server.
# You can delete 0.0.0.0/0 if you aren't using IPv4.
AllowedIPs = 0.0.0.0/0, ::/0

# FIXME replace with an IP+port on your server that's reachable from the client.
Endpoint = 192.0.2.1:51820

Similarly, we enable WireGuard:

sudo systemctl enable --now wg-quick@wg_myip

If all goes well, your equivalent of 2602:fa43:f0:1::2 should be reachable from the Internet.

Doing anything else is left as an exercise for the reader.

Conclusion

Hopefully, you managed to announce your first prefix to the Internet and hooked up a bunch of other devices to use it. Congratulations! You are now on the Internet as a fully autonomous system with your own IP addresses, instead of using someone else’s IPs.

You can expand upon this to advertise the same prefix in multiple locations for anycasting, or to construct a backbone to support unicast routing to multiple locations on the same prefix.

If you run into trouble, feel free to ask for help in the IPv6 Discord.

Next time, since AS200351 is also a member of F4IX already, I will cover how to connect to an Internet exchange.

Notes

  1. For those who don’t know, I switched to AS54148 because it’s a 16-bit ASN and is therefore compatible with classic BGP communities, and it’s not cursed like AS200351 with inter-RIR transfer messiness, which all started because RIPE wanted to levy extra fees upon existing ASNs… ↩

  2. This is basically equivalent to any BGP-capable VPS providers you might find, except I am running it myself and not charging myself money for it. It’s also not really different software-wise compared to if you had a dedicated server or colocation service. ↩

  3. In ARIN, IRR is optional and separate from the Whois database. Meanwhile, in RIPE, Whois and IRR are the same database, and the aut-num is the object for the ASN and is created when the ASN is issued. ↩

  4. That is not to say that creating the IRR entries is useless when using these upstreams. Oftentimes, their upstreams will be generating their filters from IRR, or they might manually confirm that the IRR entries exist before adding you to their filters manually. ↩