Open Shortest Path First for IPv6: Difference between revisions
imported>Howard C. Berkowitz No edit summary |
imported>Howard C. Berkowitz No edit summary |
||
Line 6: | Line 6: | ||
It remains true that most OSPF packets consist of a general-purpose header, and, in most packets, a variable number of Link State Advertisements. The most striking difference, however, is that the headers, and most of the LSAs, do not carry addresses, but a more compact identifier — which also gets around the problem of determining the type of address carried in an LSA. Actual addresses, IPv4 and IPv6, are only carried in Link State Updates. | It remains true that most OSPF packets consist of a general-purpose header, and, in most packets, a variable number of Link State Advertisements. The most striking difference, however, is that the headers, and most of the LSAs, do not carry addresses, but a more compact identifier — which also gets around the problem of determining the type of address carried in an LSA. Actual addresses, IPv4 and IPv6, are only carried in Link State Updates. | ||
==Terminology changes== | |||
Due to the need to carry more than one kind of address, some of which will be quite long, terminology often has been generalized. Some data structures also have become less dependent on IPv4 conventions: where OSPFv2 encoded subnet identifications as a 32-bit address and a 32-bit subnet mask, the new version has the prefix, but uses the [[CIDR]] convention of an integer for prefix length rather than a mask. Since discontiguous masks have not been used in years, the /length notation is more readable and more general, but also more compact in storage. | |||
===Generalizing identifiers=== | |||
There are many places, in all OSPF versions, where fields are 32 bits long. '''Simply because a field is 32 bits long,''' and may even be displayed in the format <u>of</u> an IPv4 address, '''does not mean that the field has to be a valid IPv4 address'''. Since OSPF for IPv6 continues to retain 32-bit identifiers in many places, even though all its actual addressing is IPv6, getting into the habit of thinking "identifier" rather than "address" will enormously simplify OSPF for IPv6 deployment. | There are many places, in all OSPF versions, where fields are 32 bits long. '''Simply because a field is 32 bits long,''' and may even be displayed in the format <u>of</u> an IPv4 address, '''does not mean that the field has to be a valid IPv4 address'''. Since OSPF for IPv6 continues to retain 32-bit identifiers in many places, even though all its actual addressing is IPv6, getting into the habit of thinking "identifier" rather than "address" will enormously simplify OSPF for IPv6 deployment. | ||
===Generalizing links=== | |||
Some places in OSPFv2 used addresses when all that was needed by an identifier. That consumed address space, but could also lead to ambiguities. The need for address uniqueness was one reason that a single "link" could belong to only one OSPF instance. | |||
Previous OSPF flooded information in what it called "networks", which were actually IPv4 subnets. OSPF for v6 floods on links, which may contain multiple subnets; note that from the IP standpoint, [[virtual local area networks]] (VLAN) are different links. | Previous OSPF flooded information in what it called "networks", which were actually IPv4 subnets. OSPF for v6 floods on links, which may contain multiple subnets; note that from the IP standpoint, [[virtual local area networks]] (VLAN) are different links. | ||
==OSPF packets== | |||
There remain five OSPF packet types, with a header, and, in four of the five cases, a variable number of [[#Link state advertisements|link state advertisements]] (LSA). This is still true, but the header and LSAs often have been both simplified and generalized. | |||
===Packet header=== | |||
This is much the same as in earlier versions, but simpler, with such things as addresses and authentication removed because IPv6 adequately performs their functions. | |||
0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Version # | Type | Packet length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Area ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Checksum | Instance ID | 0 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Instance ID is new; it relaxes the requirement for unique area and router identifiers and allows multiple instances of OSPF to coexist (i.e., multiple independent OSPF [[routing domain]]s. | |||
===Packet type=== | |||
====Hello packet==== | |||
== | 0 1 2 3 | ||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| 3 | 1 | Packet Length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Area ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Checksum | Instance ID | 0 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Interface ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Rtr Priority | Options | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| HelloInterval | RouterDeadInterval | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Designated Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Backup Designated Router ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Neighbor ID | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| ... | |||
====Database description==== | |||
====Link state request==== | |||
====Link state update==== | |||
====Link state acknowledgement==== | |||
==Link state advertisements== | |||
Revision as of 08:56, 6 September 2008
Template:TOC-right A standard IP routing protocol, Open Shortest Path First, has been issued in a major new version, which can handle both Internet Protocol version 4 and Internet Protocol version 6. Familiarity with basic Open Shortest Path First (OSPF) and link state routing terminology is assumed in this article.
In some respects, readers will find that OSPF packets are simpler, in that this protocol allows IPv6 headers to do a number of things that previous OSPF did itself, occasionally duplicating IPv4 functionality. The packet headers do not contain source and destination addresses. Another simplification of the header is that OSPF-specific authentication has been removed, since the Authentication Header and Encapsulating Security Payload headers of IPv6 provide a quite adequate authentication function.
It remains true that most OSPF packets consist of a general-purpose header, and, in most packets, a variable number of Link State Advertisements. The most striking difference, however, is that the headers, and most of the LSAs, do not carry addresses, but a more compact identifier — which also gets around the problem of determining the type of address carried in an LSA. Actual addresses, IPv4 and IPv6, are only carried in Link State Updates.
Terminology changes
Due to the need to carry more than one kind of address, some of which will be quite long, terminology often has been generalized. Some data structures also have become less dependent on IPv4 conventions: where OSPFv2 encoded subnet identifications as a 32-bit address and a 32-bit subnet mask, the new version has the prefix, but uses the CIDR convention of an integer for prefix length rather than a mask. Since discontiguous masks have not been used in years, the /length notation is more readable and more general, but also more compact in storage.
Generalizing identifiers
There are many places, in all OSPF versions, where fields are 32 bits long. Simply because a field is 32 bits long, and may even be displayed in the format of an IPv4 address, does not mean that the field has to be a valid IPv4 address. Since OSPF for IPv6 continues to retain 32-bit identifiers in many places, even though all its actual addressing is IPv6, getting into the habit of thinking "identifier" rather than "address" will enormously simplify OSPF for IPv6 deployment.
Generalizing links
Some places in OSPFv2 used addresses when all that was needed by an identifier. That consumed address space, but could also lead to ambiguities. The need for address uniqueness was one reason that a single "link" could belong to only one OSPF instance.
Previous OSPF flooded information in what it called "networks", which were actually IPv4 subnets. OSPF for v6 floods on links, which may contain multiple subnets; note that from the IP standpoint, virtual local area networks (VLAN) are different links.
OSPF packets
There remain five OSPF packet types, with a header, and, in four of the five cases, a variable number of link state advertisements (LSA). This is still true, but the header and LSAs often have been both simplified and generalized.
Packet header
This is much the same as in earlier versions, but simpler, with such things as addresses and authentication removed because IPv6 adequately performs their functions.
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version # | Type | Packet length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Instance ID is new; it relaxes the requirement for unique area and router identifiers and allows multiple instances of OSPF to coexist (i.e., multiple independent OSPF routing domains.
Packet type
Hello packet
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 1 | Packet Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Area ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Checksum | Instance ID | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rtr Priority | Options | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HelloInterval | RouterDeadInterval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Designated Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Backup Designated Router ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Neighbor ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ...
Database description
Link state request
Link state update
Link state acknowledgement
Link state advertisements
New LSAs have been created to carry IPv6 addresses and prefixes.