This guide is for homelab admins who understand IPv4s well but find setting up IPv6 hard or annoying because things work differently. In some ways, managing an IPv6 network can be simpler than IPv4, one just needs to learn some new concepts and discard some old ones.
Let’s begin.
First of all, there are some concepts that one must unlearn from ipv4:
Concept 1
The package that linked you here is now pure ESM. It cannot be require()'d from CommonJS.
This means you have the following choices:
import foo from 'foo' instead of const foo = require('foo') to import the package. You also need to put "type": "module" in your package.json and more. Follow the below guide.await import(…) from CommonJS instead of require(…).
| var { html, render } = require('nanohtml') | |
| var { Component, memo, onupdate } = require('nanohtml/component') | |
| // This example illustrates how memo can be used to maintain form state. | |
| // On first render, getInitialValues is called and read values either | |
| // from the fields argument or from local storage. | |
| // Whenever a field changes its value is persisted to local storage. | |
| var Form = Component(function (fields, values = memo(getInitialValues)) { | |
| var update = onupdate(function (fields, values) { |
| Mute these words in your settings here: https://twitter.com/settings/muted_keywords | |
| ActivityTweet | |
| generic_activity_highlights | |
| generic_activity_momentsbreaking | |
| RankedOrganicTweet | |
| suggest_activity | |
| suggest_activity_feed | |
| suggest_activity_highlights | |
| suggest_activity_tweet |
Filing an issue is not about delegating your problem to another developer, it’s about helping maintainers solve issues they haven’t encountered yet.
This tutorial was written using Red Hat Fedora 30 but may be similar on other distros.
You should have an eth0, but if you $ ifconcig -a and don't see it, you should do $ nmcli device status to determine which device is connected to your wifi/ethernet.
$ sudo ip link add macvlan1 link eth0 type macvlan mode bridge
$ sudo ip link add macvlan2 link eth0 type macvlan mode bridge
$ sudo ip netns add net1
I've designed a lot of RPC protocols in my career. One pattern that's worked well basically goes as follows:
// Client calls: print('Hello World\n')
-> [1, "print", "Hello World!\n"]
// Server sends return value (or lack of return vvalue)
<- [-1]
// Client calls: add(1, 2)
-> [2, "add", 1, 2]
This was a huge hassle to figure out, so I wrote up a little guide in hopes that others would find it helpful:
macOS's domain name resolver will only return IPv6 addresses (from AAAA records) when it thinks that you have a valid routable IPv6 address. For physical interfaces like Ethernet or Wi-Fi it's enough to set or be assigned an IPv6 address, but for tunnels (such as those using utun interfaces) there are some extra annoying steps that need to be taken to convince the system that yes, you indeed have an IPv6 address, and yes, you'd like to get IPv6 addresses back for DNS lookups.
I use wg-quick to establish a WireGuard tunnel between my laptop and a Linode virtual server. WireGuard uses a utun user-space tunnel device to make the connection. Here's how that device gets configured: