Differences in OSPFv3 from OSPFv2
Most of the algorithms have been preserved from OSPFv2, however, some changes were needed either to support larger address space or due to changes in protocol semantics between IPv4 and IPv6.
Following are the differences between OSPFv3 and OSPFv2-
1. Protocol processing per-link, not per-subnet:
IPv6 uses the term “link” instead of “subnet” or “network” to define a medium used to communicate between nodes at the link layer. Multiple IP subnets can be assigned to a single link, and two nodes can communicate with each other even if they do not share a common IP subnet.
This change affects Hello packets and Network LSAs processing.
2. Removal of addressing semantics:
- IPv6 addresses are not present in OSPF packets, except in Link-State Update (LSU) packets.
- Router and Network LSAs do not contain network addresses, but only contains topology information.
- OSPF Router ID, Area ID and Link-State IDs remain at 32-bits size- they cannot be assigned IPv6 addresses.
- Neighboring routers are identified by Router IDs only.
3. Addition of Flooding scope:
There are three seperate scopes for flooding LSAs-
Link-local scope-¬†LSA is flooded only on local link and no further. New Link-LSA uses link-local scope.
Area scope-¬†LSA is flooded in a single OSPF area. Router-LSAs, Network-LSA, Inter-area Prefix-LSAs, Inter-area Router-LSAs and Intra-area Prefix-LSAs use Area scope.
AS scope-¬†LSA is flooded throughout the routing domain. AS-external LSAs use AS scope.
4. Explicit support for multiple instances per link:
Providers may run different OSPF domains and would like to keep it seperate even though if they have one or more links in common, can use multiple instances on the same link.
If someone wants a single link in more than one area can use multiple instances on the same link.
Multiple instances on the single link can be achieved using “Instance ID” contained in the OSPF packet header.
5. Use of Link-local addresses:
OSPFv3 requires that every interface has a link-local address from the range FE80/10. A router uses the link-local address as next-hop during packet forwarding for the neighbors attached to its links.
On virtual-links, global or site-local addresses are used for packet forwarding.
Link-local addresses are only sent in Link-LSAs, and not allowed in any other OSPF LSAs.
6. Authentication changes:
In OSPFv3, Authentication for OSPF has been removed. OSPFv3 relies on IPv6 Authentication Header (AH) and Encapsulating Security Payload (ESP) to ensure integrity and authentication/confidentiality of routing exchanges.
Accidental data corruption is handled by checksum.
7. Packet Format changes:
- Version number is now 3.
- No Authentication fields.
- Options field Hello and DBD packets is now 24-bits long
- Two option bits, “R” bit and “v6” bit, are added to Options field for processing Router-LSAs during SPF calculation.
- “Instance ID” is included in Hello packet
8. LSA Format changes:
- Options field is removed from LSA header, increased to 24-bit and moved to Router-LSAs, Network-LSAs, Inter-area Router-LSAs (Type-4 LSA in OSPFv2) and Link-LSAs.
- LSA Type field is expanded to 16 bits with upper 3 bits encoding flooding and handling of unknown LSA Types.
- Addresses in LSAs are now expressed as [prefix, prefix-length]. The default route is expressed as a prefix with length 0.
- Router and Network LSAs have no address information.
- Router LSAs are concatenated before SPF is run.
- New Link-LSA is introduced. They have link-local flooding scope. They have 3 purposes-¬†a)¬†they provide router’s link-local address to all neighbors attached to that link¬†b)¬†inform other routers on the link of IPv6 prefixes to associate with the link¬†c)¬†they allow the router to assert a collection of Option bits to associate with the Network LSAs that will be originated for the link
- Type-3 summary LSA is now Inter-area Prefix-LSA and Type-4 summary LSA is now Inter-area Router-LSA.
- New Intra-area Prefix-LSA is introduced. It carries all IPv6 prefix information that in IPv4 is carried in Router and Network LSAs.
9. Handling Unknown LSA Types:
Unknown LSA Types are either treated as having link-local flooding scope, or stored and flooded as if they were understood.
10. Stub Area support:
Stub area support has been retained in OSPFv3. Only Router-LSAs, Network-LSAs, Inter-area Prefix-LSAs, Intra-area Prefix-LSAs and Link-LSAs are allowed in a Stub area.
Unknown LSAs are labelled as “Store and Flood LSAs” as if type understood under following conditions-
a) the LSA has area or link-local flooding scope
b) the LSA has U-bit set to 0.
11. Identifying neighbors by Router ID:
Neighboring routers on a given link are always identified by a Router ID. This behaviour is valid for neighbors on point-to-point, virtual-links, broadcast, NBMA and point-to-multipoint links.
Router ID 0.0.0.0 is reserved.
1. RFC 2740: OSPF for IPv6¬†http://www.faqs.org/ftp/rfc/pdf/rfc2740.txt.pdf