Scenario: A client has work crews that travel all over the country into remote areas. Their command trucks are outfitted with VSAT dishes that provide connectivity into a private VLAN at the satellite provider's data center.
Due to restrictions by the hardware and/or satellite provider, the truck is limited to a single IP address attached to the VSAT endpoint. The current system just uses a consumer-level wireless router to NAT all the crew's traffic onto the uplink, and the telemetry is pushed from inside the truck back to the company's datacenter.
The client wants to be able to make connections from the corporate network to hosts in the field. Unfortunately, most of the devices speak only IPv4, have addresses assigned out of a flat address pool (most of the 192.168. block), and travel from crew to crew, so there's no programmatic way to know which satellite endpoint a particular device is accessible through on any given day.
The devices aren't intelligent enough to advertise their own presence, and it's cost-prohibitive for some intelligent device in the field to enumerate them and then push route advertisements across the uplink (bandwidth is metered and fairly expensive). It is feasible for field technicians to identify the IP address of a particular device and to tell the corporate support personnel the IP and which crew it's with.
The solution that I came up with was to run an IPv6-over-IPv4 tunnel between the truck and a terminator collocated with the satellite provider. A simple Web app had a list of the IPv6 prefixes assigned to each truck, and a troubleshooter could type an IPv4 address in, select the crew from a dropdown, and get redirected to an IPv6 address.
The wireless router, replaced with similar hardware running OpenWrt, ran
TRT to unpack the embedded IPv4 address and run NAT between the IPv6 side and the IPv4-only devices.
There were a number of possible solutions for the VPN terminator, but we eventually decided to use a bare-bones Linux VM using static proto-41 tunnels on the satellite side and OSPFv3 (advertising the trucks' prefixes) on the corporate side.
(As a note, we looked at trying to run some of the IPv6 processing, beyond simple routing, on the main switch in each truck, which was a 3750, but the 3750 has really picky conditions about which tunnel setups it would handle. The docs say it's a hardware limitation, but I was never clear why a punt adjacency and CPU handling wouldn't work.)
I had a few questions during this development that I think would have been suitable for NE, such as:
- "I'm trying to run an IPv6-in-IPv4 tunnel over a link where bandwidth is expensive but changes in the endpoints and their associated prefixes are extremely uncommon. Are there serious disadvantages to using proto-41 tunneling that would be avoided with some heavier encapsulation like GRE?"
- "I have a remote site with 4 VLANs that's delegated an IPv6 /62 prefix. All upstream traffic has to be run over NAT or VPN through a single IP address. Is it better to send the IPv6 link advertisements from the 3750 or the OpenWrt router? Does this answer change depending on how frequently the prefixes are updated?"
- "I have VMs running as tunnel terminators, advertising small (/62) IPv6 prefixes to remote sites into the main corporate network. We have a main router sitting on the edge between the corporate WAN backbone and the datacenter where the terminators are. Is it clearly better to run the OSPFv3 process for the tunnels in its own area or in area 0?"
- "I have incoming IPv6 traffic that consists of both trusted and untrusted data. The addresses are structured in such a way that the last bit of the IPv6 prefix (bit 63) is an 'evil bit' (set indicates guest traffic, clear indicates corporate). Is there a clean way to set up an IPv6 access list to route the traffic differently based on the one bit in the middle of the address?"