[sf-lug] IPv6 ... all those addresses! ... Mmmmmm... yummy! (+ free t-shirt!)

[Michael Paoli]

$ (for ipv6 in 2001:470:1f04:19e::2 2001:470:1f05:19e::2  
2001:470:1f05:19e::3; do echo "$ipv6" $(ssh -6 -aqx "$ipv6"  
'hostname') $(dig -x "$ipv6" +short); done)
2001:470:1f04:19e::2 balug-sf-lug-v2.balug.org  
BALUG-1-pt.tunnel.tserv3.fmt2.ipv6.he.net.
2001:470:1f05:19e::2 balug-sf-lug-v2.balug.org balug.org.
2001:470:1f05:19e::3 balug-sf-lug-v2.balug.org sf-lug.org.
$

So, yes, IPv6 ... *lots* of addresses!  :-)  And that's generally a *good*
thing.  We have been and are seeing with IPv4, where too few ends up.  8-O

I recall hearing that in the earlier development from IPv4 towards what
became IPv6 (IPv5 died before making it out the gate), at some earlier
point, they were going to double from
IPv4's 32 bits (2^32=4,294,967,296 addresses), to
64 bits (2^64=18,446,744,073,709,551,616 addresses), but eventually
ended up going with, for IPv6,
128 bits ... that's
2^128=340,282,366,920,938,463,463,374,607,431,768,211,456 addresses!
So ... running out won't be an issue - more IPv6 addresses than there
are grains of sand on Earth.  While it may seem "excessive", not only
does it well ensure we won't be running out of addresses (plenty for
your hundreds of billions of nanobots), it also makes many useful/cool
things possible - e.g. autoconfiguration based upon Ethernet MAC address
(and one can also set privacy option to not "leak" Ethernet MAC
addresses, if that's desired).
Another quite nice thing with IPv6 - one can pretty much say bye-bye to
NAT/SNAT - with all those addresses, for the most part, no need/reason
for NAT/SNAT (and all its complications and headaches).

Anyway, a couple items ...

Virtual Machine, SF-LUG, and BALUG.  Should have gotten around to it
much earlier, but ...
So ... excepting SF-LUG list stuff (Thanks Rick!), DNS slaves (Thanks
Rick & others) and some other trace bits, the SF-LUG and BALUG stuff
essentially all runs on one virtual machine.  Now, it would generally be
good, if/as feasible, to have those reasonably well separated out ...
most notably so they can/could be "peeled apart" easily if or whenever
that might be desired or necessary.  If I had an (over) abundance of
resources (system resources, sysadmin resources, IPs, bandwidth, etc.),
I'd probably have them (much) more fully separated out.  Though there
are also some efficiencies gained by *not* having them totally separated
out (though many of those efficiencies could also be gained, even if
separated out, through various configuration management and similar
tools/infrastructure).  Anyway, to the extent reasonable feasible within
the one VM, SF-LUG and BALUG are *reasonably* separate.  E.g., though
running on a common webserver, their distinct configurations are well
separated out, and for most intents and purposes - most notably to
"outside" (seeing the Webserver from The Internet), they mostly look and
act pretty separate and independent.  E.g. they even have their own
separate SSL/TLS CA certs - even though they share the same IPv4
address.  And, ... IPv6?  :-)  Yeah, that's the part I should've gotten
around to (much) earlier, but anyway ... no shortage of addresses, so
... just added some, so SF-LUG and BALUG can effectively have their own.
And ... why might that matter?  Email is a fairly good example.  MTA
should have "reverse" DNS entry.  If one IP is used, there's one entry
(or set of entries) for the IP ... which is less than optimal.  But with
separate IPs, each can have their own "reverse" DNS entry.  E.g.:
$ dig +short -x 2001:470:1f05:19e::2
balug.org.
$ dig +short -x 2001:470:1f05:19e::3
sf-lug.org.
With both of those IPs - in fact all 3 IPv6 IPs shown in the code
snippet at the top of this post - on the same (virtual) host.
For MTA, the "reverse" DNS should generally match the sending domain, or
a parent domain (but not above registrant level).  Such can also look
more "clean" and proper for, e.g. Web site addresses.

And ... Linux, and adding additional IPv6 IPs to a host?  That's
relatively easy.  One could go quite hog wild 8-O with that ... but I
don't want to be to excessive/messy with the VM, etc.  So ... at present
there are 3 Internet routable IPv6 addresses, 2 of which I very recently
added.  One of them is local host endpoint of IPv6 tunnel (alas, my ISP
doesn't yet offer native IPv6 on the particular plan I'm on ... but they
have at least started deploying native IPv6).  The "reverse" DNS on that
one ... uhm, yeah, I can't set/change that - it's set by the tunnel
provider.  However, from same tunnel provider, also get another routable
/64 block where I get to fully control the "reverse" DNS ... and have
done so.  Hence two more addresses - one for SF-LUG, one for BALUG.

Still lots more to do on that - like more DNS data updates,
setting/changing (or not) which IP address is default source IP address,
due attention to any transitions and possible race conditions, etc.  All
of which should be done carefully to avoid potential problems.  Might
even pick different IP addresses, for various reasons.  In any case,
very nice to have the flexibility and availability ... unlike IPv4 where
it's more like ... ya'll just get one and you're gonna have to learn to
share ... deal with it.

IPv6 training/certification ... and a free t-shirt!
Hurricane Electric provides a very good set of IPv6 training materials:
https://ipv6.he.net/presentations.php
Although most of that material was prepared some years ago, most of it's
still fully relevant.  About the only bit that's changed, is some
of the current, or best current ways, to do some of the configurations
on some more current operating systems or versions thereof, may have
changed a bit.
Hurricane Electric also offers a free IPv6 certification program and a
free t-shirt!
https://ipv6.he.net/certification/
(complete "Sage" level, get a free t-shirt)
Oh, and additional hint/tip regarding the above.  When one gets to the
part to start doing various tests/demonstrations with domain (web
server, email, etc.), one would be best to use a domain where one has
full control of the registrant and DNS data - including IPv6 "glue"
records (and registrar/DNS that supports such), as one may need to
add/update/change that to make "Sage" level, and, a bit oddly, once one
has started using a particular domain along the certification/test
process, they don't have a procedure (at least not any automatic or
self-serve one) in place that will let you later change to use a
different domain.  8-O
Oh, also, on the t-shirts - be patient - they tend to send them out in
batches a couple/few times or so per year and also not particularly
expedient shipping method ... so takes a while ... but they do come!
:-)