negative responses.

To define, in the defs file:

	IPV6_ENABLED=1
	IPV6_SUBNET_PREFIX="2011:1948:0417:0004"

A /64 network is always assumed, don't do anything else. We generate
appropriate foward and reverse entries in the zone files, but
otherwise rely on the on the upstream router to provide the prefix
when asked for it by nodes when they wish to configure an IPV6
interface.

Important caveats:

1. The infrastructure is ipv4 only. We do not dupport dual stack or
   ipv6 only on any infrastructure.

2. We do not support ipv6 only on the control plane; ipv4 or dual stack.

secondary.

(cherry picked from commit 8d852fa8)

in the proper reverse map.

This commit is intended to makes the license status of Emulab and
ProtoGENI source files more clear.  It replaces license symbols like
"EMULAB-COPYRIGHT" and "GENIPUBLIC-COPYRIGHT" with {{{ }}}-delimited
blocks that contain actual license statements.

This change was driven by the fact that today, most people acquire and
track Emulab and ProtoGENI sources via git.

Before the Emulab source code was kept in git, the Flux Research Group
at the University of Utah would roll distributions by making tar
files.  As part of that process, the Flux Group would replace the
license symbols in the source files with actual license statements.

When the Flux Group moved to git, people outside of the group started
to see the source files with the "unexpanded" symbols.  This meant
that people acquired source files without actual license statements in
them.  All the relevant files had Utah *copyright* statements in them,
but without the expanded *license* statements, the licensing status of
the source files was unclear.

This commit is intended to clear up that confusion.

Most Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the Affero GNU General Public License, version 3
(AGPLv3).

Most Utah-copyrighted files related to ProtoGENI are distributed under
the terms of the GENI Public License, which is a BSD-like open-source
license.

Some Utah-copyrighted files in the Emulab source tree are distributed
under the terms of the GNU Lesser General Public License, version 2.1
(LGPL).

The GPO wants this for the protogeni racks. We now build reverse
map files for the 172.16 subnet, although we do it on a /16 boundry
to avoid a zillion zone files.

I am not planning to write an update script for this, since it would
require scripting changes to named.conf, which I am loath to do. So I
will do it by hand in Utah, and new sites (racks) will get it. If a
site wants it:

	boss> cd obj/named

Copy all of the 172 files to /etc/named/reverse
Copy all of the 172 zone entries from named.conf to /etc/named/named.conf

	boss> named_setup

but has not been tested for actual Emulab. A typical elabinelab NS
file would look like:
    
    source tb_compat.tcl
    set ns [new Simulator]
    
    tb-elab-in-elab 1
    tb-elabinelab-singlenet
    tb-elab-in-elab-topology opsvm
    tb-set-elabinelab-attribute CONFIG_WINDOWS 0
    
    namespace eval TBCOMPAT {
        set elabinelab_maxpcs 1
        set elabinelab_hardware("boss") pc3000
    }
    $ns run

Limit recursive resolution to internal hosts -- so, don't let external
view clients resolve recursively.

bigger then a /24 network, as in Utah's network. Mostly the changes
are how we deal with the reverse zone file creation and what gets
stuck into the named.conf file. Prior to this commit, we assumed a
single /24 network, cause thats how it looks in an elabinelab
experiment (which is where its critical to have the named config files
generated automatically).

But with the changes to support a single control network, the named
setup inside elabinelab is bigger then a /24 and the reverse files
have to be created and populated correctly.

initial reverse file. Note that we still do not try to generate
multiple reverse files; that is up to the local site.

make sure MX records wind up with correct entries.

Only place the last bit of the address in the reverse file, not the
entire IP address.  Still, this whole file will probably only work for
a /24 net...

Try my hand at modifying named config creation.  Allows for "fs" to be
different than ops/users.  Also tried to eliminate some redundant output.
We still generate multiple A records for some IPs (e.g., "ops" and "users")
and don't (I think) generate MX records consistently.

request, beef up named setup so that sites like DETER are handled
properly. I have added 4 new defs variables:

    #
    # If your boss/ops nodes are multihomed (and typically, one of the
    # networks is a public routable network, and the other is an internal
    # unroutable network), then define the the external addresses here (and
    # the internal addresses above).
    #
    EXTERNAL_BOSSNODE_IP=$BOSSNODE_IP
    EXTERNAL_USERNODE_IP=$USERNODE_IP

    #
    # As above, if you have internal and external networks, define the
    # external network here, and the internal network above.
    #
    EXTERNAL_TESTBED_NETWORK=$TESTBED_NETWORK
    EXTERNAL_TESTBED_NETMASK=$TESTBED_NETMASK

which if not set default to the internal values. When the external and
internal networks are different, generate two sets of reverse zone
files and two forward files (one internal and one external).

variable in the defs file. Nice for elabinelab to avoid inner named
from having to do too much work.

file with a timestamp in the future (maybe cause timezone not set when
dhclient runs?).

to have to be done in perl; trying to do it with simple substitution
is not really viable.

template files. This is rather simplistic, but should suffice for
generating a working set of files that can then be customized by the
site as needed.

BIG TODO: Deal with multiple reverse maps when the netmask is greater
then /24, and requires a set of reverse maps, not just one.