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.
No comments:
Post a Comment