[BALUG-Admin] BALUG & IPv6 - separate IPv6 addressed dedicated (mostly & primarily) for BALUG

[Michael Paoli]

BALUG & IPv6,

Did finally, yesterday, get around to updating, so BALUG is now
using IPv6 address that also has "reverse" (PTR) data that indicates
balug.org - most notably useful for SMTP and reducing probability of
rejection as "spam".  That was the principle motivation for the IPv6
address change.
$ dig +short balug.org. AAAA
2001:470:1f05:19e::2
$ dig +short -x 2001:470:1f05:19e::2
balug.org.
$
That IP address is also the default source IPv6 address
for IPv6 traffic to The Internet from the Virtual Machine (VM).

Many/most publicly accessible services are still (also) listening
on IPv6 wildcard address, but may also change that in future.

DNS NS data hasn't been changed yet (future).  But that does
remind me ... DNS IPv6 notify source address - yes, that,
by default, had also changed ... so today I switch that
back at least 'till DNS slaves have been suitably notified,
etc.

SF-LUG - at least that of it on same VM, has its own separate IPv6
address ... however since they're on one single host, for default
outbound IPv6 address, they share the same common IPv6 - which is
primarily for BALUG (it's a BALUG VM also hosting some SF-LUG services,
not vice versa).

> From: "Michael Paoli" <Michael.Paoli@cal.berkeley.edu>
> To: SF-LUG <sf-lug@linuxmafia.com>
> Subject: SF-LUG & IPv6: Re: IPv6 ... all those addresses!  ...  
> Mmmmmm... yummy! (+ free t-shirt!)
> Date: Sat, 16 Dec 2017 12:40:45 -0800

> 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@cal.berkeley.edu>
>> To: SF-LUG <sf-lug@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.