Much of the core bits are initially ported.

This should be mostly independent of my configs, now.

README.md

@@ -1,3 +1,121 @@
 # rc.router
 
-FreeBSD's Init/RC system could use some extensions for easy configuration of homelab routers.
+The FreeBSD Init/RC system could use some extensions for easy configuration of homelab
+and SOHO routers.
+
+These files provide such a set of extensions.  These extensions, while providing a lot
+of advanced functionality, are not meant for anything other than edge routers.
+"Core router" functionality (which bridges between transit networks) is not provided
+for by this configuration mechanism.
+
+`rc.router` requires FreeBSD-15 or greater.  (It might work for some configurations
+on FreeBSD-14, but I no longer run any routers with it on FreeBSD-14.)
+
+## How to setup (Easy dual-stack example With Git)
+
+Executing this sequence of sample commands will setup a basic Dual-stack router
+for Verizon FIOS.  There are a few pre-canned ISP configuration files which help
+guide what settings are needed for which ISPs.  (Mostly this impacts IPv6 settings
+not IPv4 settings.)
+
+```
+$ cd /etc
+$ mkdir router-conf
+$ cd router-conf
+$ git init .
+$ echo << EOF > rc.conf
+# Configure a basic external v4 ISP
+external_card="em0"
+
+add_canned_isp ${external_card} fios_1 verizon_fios 
+
+
+# Configure a basic internal v4 network
+internal_card="re0"
+add_net ${internal_card} 0 main
+
+EOF
+$ git add rc.conf
+$ git submodule add rc.router https://gitea.nerdland.org/adam/rc.router
+$ git commit -m "FIRST POST!!!"
+$ echo 'rc_router_dir="/etc/router-conf/rc.router"' >> /etc/rc.conf
+$ echo 'rc_router_conf_dif="/etc/router-conf"' >> /etc/rc.conf
+$ echo ". ${rc_router_dir}/rc.entry" >> /etc/rc.conf
+```
+
+## How to setup (Easy v4-only example With Git)
+
+Executing this sequence of sample commands will setup a basic v4 NAT/dhcp router.
+
+```
+$ cd /etc
+$ mkdir router-conf
+$ cd router-conf
+$ git init .
+$ echo << EOF > rc.conf
+# Configure a basic external v4 ISP
+external_card="em0"
+add_v4_isp ${external_card} dhcp
+
+
+
+# Configure a basic internal v4 network
+internal_card="re0"
+v4_net="172.26"
+
+add_v4_net ${internal_card} 0 main
+EOF
+$ git add rc.conf
+$ git submodule add rc.router https://gitea.nerdland.org/adam/rc.router
+$ git commit -m "FIRST POST!!!"
+$ echo 'rc_router_dir="/etc/router-conf/rc.router"' >> /etc/rc.conf
+$ echo 'rc_router_conf_dif="/etc/router-conf"' >> /etc/rc.conf
+$ echo ". ${rc_router_dir}/rc.entry" >> /etc/rc.conf
+```
+
+In this example, `em0` will be the uplink card, and will dhcpv4 configure itself.  `re0` is
+the primary internal interface card, which will be configured to host DHCP for internal
+`172.26.0.0/24` addresses, in the basic default pool of `172.26.0.100` thru `172.26.0.200`.
+The router's internal address in this subnet is `172.26.0.1/24`.  And `8.8.8.8` will be used
+as the default resolver for everyone within this subnet.
+
+## Interoperation with regular FreeBSD `init` and `rc.conf` configuration
+
+These scripts are not meant to replace the FreeBSD init script mechanisms.  Instead these
+scripts seek to augment the system.  The scripts provide ways to set clusters of related
+config variables (and to generate other related configuration files) such that hybrid
+configurations can be made.  The various commands, such as `add_v4_net` result in the
+setting and updating of various `rc.conf` variables as-if the user simply wrote the correct
+configuration settings at that point in the `rc.conf` file.
+
+As such, these mechanisms are meant to co-exist with manual variable setting and manually
+maintained configuration files for things such as DHCP.  This permits an adoption path
+other than "big bang cutover".  The `rc.router` commands are careful to update-by-append
+to certain variables, rather than to assume direct ownership of all variables.  Thus,
+`add_net xy0 402` and `ifconfig_xy0_43_alias0="192.168.10.4/24"` could be safely
+intermingled.  (Right now, the scripts assume ownership over specific related
+variables for interfaces and vlans that they create.)
+
+## IPv6 posture and readiness
+
+`rc.router` is designed as an IPv6-first package.  While IPv4-only networks are still
+possible with this package, the defaults are tuned for and assume IPv6.  Pre-canned
+router configurations should gracefully (albeit with some timeouts) fail back to v4-only
+modes, when IPv6 is not available from those ISPs, due to CPE concerns.
+
+IPv6 configuration with `rc.router` permits DHCPv6 `IA_PD` with Router Advertisements or
+static configuration for the ISP side.  For the internal side, SLAAC is the only
+configuration provided.  DHCPv6 internally for `IA_NA` is not implemented.  `rc.router`
+is not expliticly incompatible with DHCPv6 internal provisioning, but no effort has
+been made to implement or test it.  Given that a large number of consumer devices
+(Android, in particular) refuse to provision via DHCPv6, SLAAC must be used internally
+for any deployment to accommodate the widest swathe of client devices.
+
+`rc.router` installs `tayga` and users are encouraged to use its `map` feature in
+the configuration file to provide IPv4 addresses for IPv6-only hosts, or vice-versa.
+This is intended to permit incremental migration for IPv4-only homelabs to dual-stack
+and IPv6-only deployments.
+
+The DHCPv4 configuration generator is capable of emitting Option 108 for IPv6-mostly
+deployments.
+.