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.