How we set up IPV6 on StandUp.net

standup | Oct. 31, 2022, 5:58 a.m.

It goes without saying that as long as humans have had nothing to do, they find ways to complicate things.  Thankfully that makes it easy for bored humans to find work to do.  Unfortunately we lack bored humans, so instead we decided to explain to anyone who reads this, how it is this website runs.  Or is starting out running at least.  And why we need IPV6, even more so.  What it is.

IPV6, in other words is not an acronym for anything specifically funny, except if you write out IP phonetically, it means I pee.  Which is kinda funny.  Funniness aside IPV6 is the Internet Protocol version 6.

The first thing was getting an IPV6 address.  Thankfully our hosting provider gave us one configured to our server.  Once we had the IPV6 address, we did have to point our domain's AAAA records to our new IPV6 address, 2604:a880:4:1d0::6fa:5000 in the DNS of our domains registrar.

We then started the set up the use of IPV6 in our Django website.

We run Django ontop of a few layers of abstraction.  Supervisor, Gunicorn, and Nginx.  We will talk about those in a bit; If you are just getting into coding, or want to get into coding.  The first thing we would suggest is learning Python or PHP (this is all in python, but PHP is easier to get a website up and running, python requires a bit more).  There are tons of tutorials, and although it may seem hard, it really isn't.  Just takes a few minutes every day over ten years to get good.

Anyways, back to more advanced shenanigans, we had to configure our gunicorn and nginx configuration in the following way.

First in Nginx to send IPV6 to Django we have to have it forward it via django's IPV6, so nginx location block looks like so

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_set_header X-NginX-Proxy false;
    real_ip_header X-Real-IP;
    proxy_pass http://[::1]:8000;
    proxy_redirect off;
}

And our Supervisor config looks like so

[program:standup]
command = /home/www/standup/venv/bin/gunicorn --workers 3 --bind unix:/home/www/standup/app.sock --bind [::1]:8000 app.wsgi:application
environment=PATH="/home/www/standup/venv/bin:%(ENV_PATH)s"
directory = /home/www/standup
user = user
stdout_logfile = standup.out.log
stderr_logfile = standup.err.log
autostart=true
autorestart=true

As you can see in Nginx we send  to proxy_pass http://[::1]:8000; and in our gunicorn command in supervisor we double bind to both the unix socket and the ipv6 port:

--bind unix:/home/www/standup/app.sock --bind [::1]:8000


This makes it so our application can now not only read the IPV6 address of the user, but also make it accessaible via IPV6 once the DNS records are set up and verified to be working via the dig command

$ dig AAAA standup.net

; <<>> DiG 9.16.1-Ubuntu <<>> AAAA standup.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37371
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;standup.net.			IN	AAAA

;; ANSWER SECTION:
standup.net.		3600	IN	AAAA	2604:a880:4:1d0::6fa:5000

;; Query time: 12 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Oct 31 05:55:58 UTC 2022
;; MSG SIZE  rcvd: 68

We hope you enjoyed this, although it may not have been as standupish as you wished, we had to write it for no other reason than to complain about how our markup editor needs a bit more work to be done.

We also still despite our best efforts, have not been able to find a way to motivate our developer to work faster.  But he did give us this blog post, so there is that.