[sf-lug] SF-LUG & IPv6: Re: IPv6 ... all those addresses! ... Mmmmmm... yummy! (+ free t-shirt!)

[Michael Paoli]

So ... most things SF-LUG, notwithstanding list (Thanks Rick!)
and DNS nameserver related record bits (future),
and possibly some DNS TTL bits (up to 4 hours for older cached
data to expire),
have mostly had SF-LUG's IPv6 moved to address "just" for
SF-LUG stuff:
$ dig +short www.sf-lug.org. AAAA
2001:470:1f05:19e::3
$ dig +short -x 2001:470:1f05:19e::3
sf-lug.org.
$
Well ... those non-list SF-LUG things, are hosted on
virtual machine which is primarily BALUG, so IPv6
connections originated from that virtual machine will
still have a different IPv6 source address (notably that
of BALUG's), but mostly, other than that, SF-LUG has it's
"own" IPv6 address.  The sf-lug.org domain is canonical,
and for web, it's www.sf-lug.org, but the IPv6 changes
likewise apply to the non-canonical domain sf-lug.com.

> From: "Michael Paoli" <Michael.Paoli at cal.berkeley.edu>
> To: SF-LUG <sf-lug at linuxmafia.com>
> Subject: IPv6 ... all those addresses!  ... Mmmmmm... yummy! (+ free  
> t-shirt!)
> Date: Wed, 25 Oct 2017 07:19:59 -0700

> $ (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
>
> 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.