Monday, May 21, 2018

On "Compromise"

Gun control isn't the answer to the recent spate of school shootings. In fact, there are sources out there that suggest that the most recent one was committed not just with a shotgun, but a sawed off one at that - a class of firearm that has been highly regulated since 1934, such that making one is expensive, and requires government permission and registration. "More gun control" on top of the thousands of federal, state, and local laws is throwing good money after bad, and giving the government power that it not only doesn't need, but shouldn't have.

If you really want more gun control, you're going to need to offer an actual compromise. Not some wishy washy "we didn't take everything we wanted". That's not compromise. Compromise is give and take. For example, we classify bump-fire stocks as machine guns, in return for repealing the Hughes amendment and reopening the machine gun registry. Of course POTUS may very well have rendered that a moot point (we'll see once the legal challenges hit SCOTUS).

More to follow.

Thursday, May 17, 2018

Routing Protocols and IPv6

Note: This was a (relatively short) paper that I did for one of my classes. Given that we occasionally blog about tech stuff, I figured that I'd copy and post the (revised) paper here.
          Due to the differences between IPv4 and IPv6, including the use of Link-Local addresses instead of private IP addresses, the IETF, assisted by various vendors, updated the OSPF and RIP protocols to help ensure a seamless transition to IPv6, when the time comes.  The new versions – OSPFv3 and RIPng – are designed to work with IPv6, taking into account the massively increased address size, the change from private addressing to Link-Local, and even making improvements to the protocols besides those necessary to keep a switch to IPv6 from breaking a network. Despite the differences, there are still substantial similarities between the old and new protocols.
            The introduction of link-local addresses and the deprecation of private IP addresses definitely has an effect upon how things are routed. Different routing protocols handle link-local addresses similarly, using them to discover neighbors and transfer information, but not passing link-local IP addresses around. Under IPv4, private addresses would be used for internal networks and NAT would be used to translate those private IP addresses to public ones, making it so that under IPv4, routing protocols (other than BGP) are dealing mostly with private IP addresses. Under IPv6 however, there are no private IP addresses. Each interface or host gets two addresses – a link-local address that gets used inside a single broadcast domain, never getting beyond the default gateway, and a global unicast address that remains the same on public and private networks. Direct end to end connections, rare under IPv4 due to the prevalence of NAT, will become more common as IPv4 gets phased out.
            RIPng has multiple significant similarities with the older versions of the protocol. For example, the list of limitations in section 1.1 of RFC 1058, the document that describes the original RIP and its implementation is repeated verbatim, at the beginning of both RFC 2453 (Section 3.2), and at the beginning of RFC 2080 (Section 1.2), which cover RIPv2 and RIPng respectively – in fact, RFC 2080 notes that it is merely a modified version of RFC 1058, “reflect RIP-2 and IPv6 enhancements.” (Malkin 1) To summarize, all versions of RIP (v1, v2, and ng) share certain limitations: a maximum of 15 hops (which tends to limit RIP protocols to relatively small networks), “counting to infinity” to resolve uncommon situations, and the use of metrics, rather than real time events and information, to determine the best route.  The specific metrics in use are another similarity between all versions of RIP.  As a distance vector protocol, all three versions of RIP use hop count to figure out which route is best.
The biggest difference between RIPng and that which came before is in addressing considerations. Because IPv6 doesn’t use subnetting and the prefixes which replaced subnets are “unambiguous” (Malkin 8) there is no need to distinguish between different types of routes. The prefix is also used in determining default routes – any route with a prefix length of 0 is a default route (RFC 2080 recommends using a prefix of 0:0:0:0:0:0:0:0 despite it not really making any difference).
            OSPF has several significant differences from v2 to v3. RFC 5340 even takes the time to outline those significant differences, not all of which are due to the differences between IPv6 and IPv4. For example, OSPFv3 supports running multiple instances on the same link – i.e. the same physical port, and runs OSPF per link, unlike OSPFv2 which runs OSPF per subnet (RFC 5340 notes that “network” and “subnet”, as used in the OSPFv2 specification, should be replaced entirely by “link” in OSPFv3). This makes it a lot easier to have different routing domains using the same hardware, something that OSPFv2 only supported in “haphazard fashion using the authentication fields in the OSPF for IPv4 header.” (Coltun 6)
OSPFv3 also removes IP addresses from protocol packets and from some Link State Advertisement (LSA) types (specifically router and network), which, in theory, makes the central part of OSPF “protocol independent”. Which, if we ever colonize the galaxy and figure out FTL communications, will make it a lot easier to upgrade OSPF to work with an IPv6 replacement. It also might be meant to help keep the size of OSPFv3 packets down for the most part - OSPFv3 packets are generally not much larger than OSPF v2 “Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4.” (Coltun 1) Of course, in order to accomplish this, they had to create an entire new set of LSAs just to carry IPv6 addresses, so while individual packets are generally about the same size, there’s a lot more of them than there were previously. Because OSPFv3 packets no longer contain IP addressing, there was a problem of how to identify routers in OSPFv3 packets, a problem which was solved by the use of a 32 bit router ID.
Another change to OSPF LSAs is in the implementation of flooding scopes. OSPFv3 has 3 different
types of flooding scope, each of which is associated with different LSA types. The three scopes cover
broadcast domains (link-local scope), routing areas (area scope), and entire OSPF networks (AS scope).
Interestingly, OSPF security has been abandoned, and OSPFv3 instead uses IPSEC for security.
While handling of stub areas is slightly different, due to the differences in LSAs and packets from
OSPFv2 to OSPFv3, they are still used for the purpose of allowing less capable routers to participate in an OSPF network.
The basic functioning of OSPFv3, despite all the changes from OSPFv2, is basically the same. It still
uses the same packet types (despite changes to some of the packet formats), link types, interface state
machine, neighbor state machine, and discovers and maintains neighbors the same.
            It would not be incorrect to say that, despite the major changes in how IPv6 handles addressing (including the change from private/public to link-local/global), and the changes in size of the addresses and address space, IPv6 routing protocols are very similar to their IPv4 versions (in the case of RIPng, they copied the original RIP RFC almost verbatim, making changes only as necessary to support IPv6), and still operate essentially the same as their predecessors.



          

Works Cited
Hedrick, C. "Routing Information Protocol." IETF, https://tools.ietf.org/html/rfc1058. Accessed 2 May 2018.
Malkin, G. "RIPng for IPv6." IETF, https://tools.ietf.org/html/rfc2080. Accessed 2 May 2018.
Malkin, G. "RIP Version 2." IETF, https://tools.ietf.org/html/rfc2453. Accessed 2 May 2018.
Hinden, R. "IP Version 6 Addressing Architecture." IETF, https://tools.ietf.org/html/rfc4291. Accessed 2 May 2018.
Colton, R., et al. "OSPF for IPv6." IETF, https://tools.ietf.org/html/rfc5340. Accessed 2 May 2018.

Sunday, May 6, 2018

Connecting a VM to a serial port

So you've got an old DOS or Windows 98 program that you'd really like to run. Maybe it's radio programming software for amateur radio,  an old game that you've got fond memories of, an expensive printer that you can't afford to replace, or something else that you've used for years for business or fun that you just don't feel like giving up.
Well, a Windows 98 VM is a fairly effective solution, and certainly one that works better than Microsoft's built in "compatibility mode". My hypervisor of choice is Virtualbox. It's free and platform independent, which many of the competitors are not. There are some good tutorials for setting up Windows 98 VMs for gaming, but they don't really get into what you'd need to do to connect your VM to an outside device, and you really do need to do that if you're planning on doing anything that requires a connection between your VM, and a piece of hardware.

A short tutorial on connecting a serial device to your VM:

  1. From a "powered down" state click on settings
  2. Select "Serial Ports" on the left.
  3. Check the "Enable Serial Port" box.
  4. Under the Port Number drop down, select the port number you want for the COM port inside the VM. Note: DOS programs often will not recognize ports other than COM1 or COM2, so if you plan on utilizing a DOS program, such as Motorola's GP350 RSS, make sure to only use COM1 or COM1.
  5. In the "Path/Address" field, type in the name of the port that you want the VM to utilize. If you've got a permanent physical COM port on your computer, use that. If you do have to use a USB Serial adapter, be aware that the VM will only start when you have the adapter plugged into your computer, unless you disable the adapter, and that unplugging it while utilizing the VM will require rebooting if you wish to continue using the adapter.
  6. Start up the VM and bring up whatever program you wish to use. Make sure that the right serial port is selected.