Section 12.2. OSPFv3

12.2. OSPFv3

IPv6 introduces an interesting opportunity that is not at first expected or intended. That is, as long as we are transitioning our networks (from IPv4 to IPv6), we might as well transition several long-standing but acknowledged poor networking practices. Chief among these practices are the way we do multihoming and the way we do security. Although discussion of these changes is beyond the scope of this book, pointing out this opportunity is important because the same thinking has been applied to OSPF. That is, in developing a new version of OSPF to accommodate IPv6, the opportunity exists to apply lessons learned and improve the protocol itself. This has in fact happened, and OSPFv3 is improved over OSPFv2 for reasons that have nothing to do with IPv6.

12.2.1. IPv4 and IPv6 Compatibility in OSPF

OSPFv3 is specified in RFC 2740. The basic mechanisms, databases, data structures, and algorithms remain the same as OSPFv2. However, OSPFv3 is not backward compatible with OSPFv2. In other words, OSPFv3 supports only IPv6. So if you want to route both IPv4 and IPv6 in the same network with OSPF, you must run both OSPFv2 and OSPFv3, as shown in Figure 12.6. In this example, OSPFv2 is configured just as you have seen in previous examples: AIDs and the interfaces running in each of the areas are specified. Notice that the OSPFv3 configuration (JUNOS keyword ospf3) looks exactly the same. The reason identical configurations are possible is because the AIDs used by OSPFv3 remain 32 bits. In fact, AIDs, RIDs, and LSA IDs all remain 32 bits in OSPFv3. The chief advantage of this is that if you want to run an OSPFv3 topology that is identical to an existing OSPFv2 topology, you can use the same identifiers for both. You can, of course, use separate identifiers if you so choose.

[edit] jeff@Juniper3# show protocols ospf {     area 0.0.0.0 {         interface so-1/0/0.0;      }      area 192.168.51.0 {         interface ge-0/0/0.0;      }      area 192.168.3.0 {         interface ge-0/0/1.0;         interface ge-0/0/2.0;      } } ospf3 {     area 0.0.0.0 {         interface so-1/0/0.0;       }       area 192.168.51.0 {         interface ge-0/0/0.0;       }       area 192.168.3.0 {         interface ge-0/0/1.0;         interface ge-0/0/2.0;       } } 

12.2.2. Differences from OSPFv2

The most advantageous improvements to OSPFv3 over version 2 are in the LSAs, described in Section 12.2.3. But a number of other functional and procedural differences exist, some of which are improvements and others of which are just necessitated by the need to support IPv6 addresses. You can find a more complete description of these differences in Section 2 of RFC 2740.

• Removal of addressing semantics You have already seen an example of this change in the example configuration of Figure 12.6 in the preceding section. That is, by keeping the AIDs, RIDs, and LSA IDs 32 bits, these values are not IPv6 addresses. They are not IPv4 addresses either, of course, but they have traditionally been expressed in the same dotted-decimal format and are, in OSPFv2, often derived from them. The advantage here is that if you want to overlay an OSPFv3 domain on an OSPFv2 domain, the same RIDs and AIDs can be used for both. Removal of addressing semantics also means that IPv6 addresses are not found in OSPF packets other than the LSAs of Update packets. There are also changes to the way network addresses are advertised in LSAs, as you will learn in the next section.

• Addition of a link-local flooding scope OSPFv2 has area and domain (AS) flooding scopes, as you already know. Certain LSAs, such as Router and Network LSAs, can be flooded only within an area, whereas other LSAs such as AS-External LSAs can be flooded throughout the OSPF domain. OSPFv3 retains these two scopes, but adds a third scope that encompasses only a single data link. LSAs with this link-local flooding scope can then only be flooded to routers sharing the same link. You will seeagain, in the next sectionhow OSPFv3 applies this scope to a new LSA type to add a bit of efficiency to its flooding operations.

• Removal of OSPF authentication IPv6 has authentication and encryption support built in. So rather than duplicate efforts by adding separate authentication mechanisms to OSPFv3, the protocol just uses the existing capabilities of IPv6.^[8]

  ^[8] At the time of this writing, procedures for authenticating OSPFv3 using the IPv6 AH/ESP extension header are described in an Internet Draft: Mukesh Gupta and Nagavenkata Suresh Melam, "Authentication/Confidentiality for OSPFv3," draft-ietf-ospf-ospfv3-auth-03.txt, August 2003.

• Support for multiple instances per link In some cases, multiple OSPF routers share a common link, but should not run a common process. For instance, suppose there are six routers connected to a single Ethernet link. Routers 1 and 2 link two OSPF subdomains and should form an adjacency to connect their subdomains. Likewise, routers 3 and 4 should form an adjacency to connect their subdomains, and routers 5 and 6 should form an adjacency. However, there should be no other adjacencies. In other words, the six subdomains should comprise three separate OSPF domains, with no communications between them. You can accomplish this with OSPFv2 by manipulating authentication, but OSPFv3 supports it by including an Instance ID field in its packet header.

• Per-link protocol processing OSPFv2 defines interfaces as connected to subnets. Therefore, an OSPFv2 process runs per subnet, as defined by the IPv4 subnet address. IPv6 changes this semantic, so that interfaces are connected to a link rather to a subnet. This removes the address dependency, so that two routers can share OSPFv3 packets over a link with multiple defined subnets, even if the two routers are not on the same subnet. This is in keeping with the IPv6 capability of supporting multiple addresses per interface.

• More flexible handling of unknown LSA types One of the operational difficulties of OSPFv2 is that it throws away unknown LSA types, making network changes and transitions more complex. OSPFv3 treats unknown LSAs more similarly to the way IS-IS treats unknown TLVs, forwarding them rather than discarding them. The result can be, in some cases, simplified network changesparticularly as they apply to stub areas.

• Neighbors are always identified by RID OSPFv2 is inconsistent in its neighbor identification. Neighbors on point-to-point and virtual links are identified by RID, whereas neighbors on broadcast, point-to-multipoint, and MBMA links are identified by their IPv4 interface addresses. OSPFv3 neighbors are always identified by RID, on all link types.

12.2.3. OSPFv3 LSAs

The OSPFv3 LSA header, shown in Figure 12.7, looks almost identical to the OSPFv2 LSA header. The only difference is that the LS Type field is now 16 bits in the space where there was an 8-bit Options field and an 8-bit LS Type field in the version 2 header.

Figure 12.7. The OSPFv3 LSA header.

This longer LS Type field, shown in Figure 12.8, begins with 3 new bits. The U bit tells receiving routers how to handle the encapsulated LSA, if the router does not recognize the LSA type. If the bit is cleared (0), the router treats the LSA as if it had link-local flooding scope. In other words, the LSA is not flooded beyond the receiving router. If the U bit is set (1), the router stores the LSA and floods it as if the LSA type were recognized.

Figure 12.8. Details of the Link State Type field in the OSPFv3 LSA header.

The S2 and S1 bits together indicate the LSA's flooding scope. The possible flooding scopes, and the corresponding values of the S bits, are shown in Table 12.2.

Table 12.2. Flooding Scopes Indicated by the S bits in the LS Type Field

S2	S1	Flooding Scope
0	0	Link-local scope (flooded only on the link the LSA is originated on)
0	1	Area scope (flooded to all routers in the area the LSA was originated in)
1	0	AS scoping (flooded to all routers in the OSPFv3 domain)
1	1	Reserved

The last 13 bits comprise the LSA function code, which as the name implies indicates the function of the encapsulated LSA. In this regard, the LSA function code serves the same purpose as the complete OSPFv2 LS Type code. Table 12.3 lists 10 OSPFv3 LSAs and the LS Type values that correspond to them. You can see from the Hex Type values that all 10 have the U bit set by default to 0. The S bits of all LSAs except two, the AS-external LSA and the Link LSA, are set to area scope. The AS-External LSA has AS flooding scope, and the Link LSA has link-local flooding scope.

Table 12.3. OSPFv3 and OSPFv2 LSA Types

OSPFv3 LSAs		OSPFv2 LSAs
Type	Name	Type	Name
0x2001	Router LSA	1	Router LSA
0x2002	Network LSA	2	Network LSA
0x2003	Inter-Area Prefix LSA	3	Network Summary LSA
0x2004	Inter-Area Router LSA	4	ASBR Summary LSA
0x4005	AS-External LSA	5	AS-External LSA
0x2006	Group Membership LSA	6	Group Membership LSA
0x2007	Type 7 LSA	7	NSSA External LSA
0x0008	Link LSA	[*]
0x2009	Intra-Area Prefix LSA	[*]
0xa00a	Intra-Area-TE LSA	[*]

^[*] No equivalent LSA type

Also shown in Table 12.3 are the OSPFv2 LSAs that correspond to the OSPFv3 LSAs. Some OSPFv3 LSAs have the same names as OSPFv2 LSAs, but differ significantly in the information they carry. Other OSPFv3 LSAs are functionally the same as their OSPFv2 counterparts, but have been renamed. And two entirely new OSPFv3 LSA types contribute greatly to the overall improvement of the protocol. We will look at each LSA in a bit more detail next.

12.2.3.1. Link LSA

The first of the new LSAs is the Link LSA, which is used for communicating information that is significant only to two directly connected neighbors. The link-local scope of the LSA ensures that it and its information are not flooded beyond the link on which they originated. OSPFv2 has no corresponding LSA. If information relevant only to neighbors sharing the same link is to be sent, it must be enclosed in version 2 Router or Network LSAs (practical application normally dictates the latter). Because these LSAs have area flooding scope, the link-local information is inefficiently carried throughout the area of origin, to routers that have no use for the information.

A router originates a separate Link LSA (Figure 12.9) on each of its attached links belonging to an OSPFv3 domain, and a receiving router, because of the link-local flooding scope, never forwards the LSA to any other link. The LSA performs three functions:

• It provides the originating router's link-local address to all other routers attached to the link.

• It provides a list of IPv6 prefixes associated with the link.

• It provides a set of Option bits to associate with Network LSAs originated on the link.

Figure 12.9. The OSPFv3 Link LSA.

Router Priority specifies the router priority assigned to the interface of the originating router.

Options specifies the options bits that the originating router would like to set in the Network LSA that will be originated for the link. This is the same 24-bit Options field carried in OSPFv3 Hello and DD packets, and in a number of OSPFv3 LSAs. The Options field is detailed in Section 12.2.4.

Link-Local Prefix Address specifies the 128-bit link-local prefix of the originating router's interface attached to the link.

Number of Prefixes specifies the number of IPv6 prefixes contained in the LSA, as described by the following Prefix Length, Prefix Options, and Address Prefix fields.

Prefix Length, Prefix Options, and Address Prefix describe one or more IPv6 prefixes associated with the link by the originating router. This set of fields is used not only in the Link LSA, but also the Intra-Area Prefix, Inter-Area Prefix, and AS-External LSAs. The advertised prefix can be any length between 0 and 128. When the prefix is not an even multiple of 32 bits, it is padded out with 0s to fit the 32-bit boundaries of the Address Prefix field. The Prefix Length field specifies the length of the unpadded prefix, in bits. The Prefix Options field, shown in Figure 12.10, specifies optional handling of the prefix during routing calculations.

Figure 12.10. The Prefix Options field.

The Propagate (P) bit is set on NSSA area prefixes that should be re-advertised at the NSSA area border.

The Multicast (MC) bit, when set, specifies that the prefix should be included in multicast routing calculations.

The Local Address (LA) bit, when set, specifies that the prefix is an interface address of the advertising router.

The No Unicast (NU) bit, when set, specifies that the prefix should be excluded from unicast route calculations.

12.2.3.2. Intra-Area Prefix LSA

The second new LSA is the Intra-Area Prefix LSA. Recall from Chapter 8 that one of the factors limiting the size of OSPFv2 areas is the fact that prefixes must be carried in Router and Network LSAs. To recap, some networks such as access service providers can have routers with large numbers of links, which tend to change frequently because of normal customer service activity. The problem is that every time a link is added or deleted, or otherwise fluctuates due to instability or an address change, the link's associated prefix must be advertised or withdrawn. With OSPFv2, this means originating a new Router or Network LSA. But a new Router or Network LSA triggers a new SPF calculation in all the routers in the area, because its primary function is to identify the location of a router or pseudonode in relation to its neighbors on the SPF tree.

OSPFv3 removes the prefix information from its Router and Network LSAs, and carries it in Intra-Area Prefix LSAs. Now, when a link or its prefix changes, the connected router originates an Intra-Area Prefix LSA to flood the information throughout the area. This LSA does not trigger an SPF calculation; the receiving routers simply associate the new prefix information with the originating router. Router and Network LSAs, in OSPFv3, serve only to provide topological information. As a result, this new LSA should make OSPFv3 significantly more scalable for networks with large numbers of frequently changing prefixes. Figure 12.11 shows the format of the Intra-Area Prefix LSA.

Figure 12.11. The OSPFv3 Intra-Area Prefix LSA.

Number of Prefixes specifies the number of prefixes contained in the LSA.

Referenced Link State Type, Referenced Link State ID, and Referenced Advertising Router identify the Router or Network LSA with which the contained prefixes should be associated. If the prefixes are associated with a Router LSA, the referenced link state type is 1, the referenced link state ID is 0, and the referenced advertising router is the RID of the originating router. If the prefixes should be associated with a Network LSA, the referenced link state type is 2, the referenced link state ID is the interface ID^[9] of the link's DR, and the referenced advertising router is the RID of the DR.

^[9] The interface ID used in this and other OSPFv3 LSAs should not be confused with the 64-bit Interface ID portion of an IPv6 address. This field is a 32-bit value distinguishing this interface from other interfaces on the originating router. RFC 2740 suggests using the MIB-II IfIndex for the interface ID value.

Each prefix is then represented by a Prefix Length, Prefix Options, and Address Prefix field, as described previously for the Link LSA. Added to these three fields is Metric field, which is the cost of the prefix.

12.2.3.3. Router LSA

Figure 12.12 shows the OSPFv3 Router LSA compared to the OPSPFv2 Router LSA. You can readily see that the format, although the two LSAs retain the same name, is significantly different. The primary reason for this difference, as you just read, is the elimination of prefix information in the OSPFv3 Router LSA. The OSPFv3 Router LSA now describes just the originating router, its attached links (not prefixes) and directly connected neighbors, and its only purpose is to represent the originating router in the SPF calculations.

Figure 12.12. Comparison of the OSPFv2 and OSPFv3 Router LSAs.

Options, although in a different position within the LSA format and a longer length (24 bits) than the OSPFv2 Options field, performs the same function of identifying optional capabilities. The Options field, carried in several packets and LSAs, is described separately in Section 12.2.4.

Following the Options field is a set of fields that can appear multiple times, to describe each of the attached interfaces.

Type specifies the interface type. Table 12.4 lists the possible interface type values.

Table 12.4. Interface Types in OSPFv3 Router LSA

Type	Description
1	Point-to-point connection to another router
2	Connection to a transit network
3	Reserved
4	Virtual link

Metric specifies the outbound cost of the interface.

Interface ID is a 32-bit value distinguishing the interface from other interfaces on the originating router.

Neighbor Interface is the Interface ID advertised by neighbors on the link in their Hellos or, in the case of type 2 links, the Interface ID of the link's DR.

Neighbor Router ID is the neighbor's RID or, in the case of type 2 links, the DR's RID.

12.2.3.4. Network LSA

The OSPFv3 Network LSA is, as shown in Figure 12.13, similar to the OSPFv2 Network LSA. Functionally, it is identical to the OSPFv2 Network LSA (originated by the DR to represent a pseudonode, 0 cost to attached neighbors is assumed, and so on). The only significant differences are the location of the Options field and the elimination of the Network Mask field (which has no meaning in IPv6).

Figure 12.13. Comparison of the OSPFv2 and OSPFv3 Network LSAs.

12.2.3.5. Inter-Area Prefix LSA

The Inter-Area Prefix LSA performs the same function as the OSPFv2 type 3 Summary LSAABRs originate them into an area to advertise networks that are outside the area but inside the OSPF domainit just sports a different, and more accurately descriptive, name. An ABR originates a separate Inter-Area Prefix LSA for each IPv6 prefix that must be advertised into an area. An ABR can also originate an Inter-Area Prefix LSA to advertise a default route into a stub area.

Figure 12.14 compares the formats of the two LSAs. Once again, the Prefix Length, Prefix Options, and Address Prefix fields completely describe the advertised prefix. The 24-bit Metric field performs the same functionspecifying the cost to the destinationin both LSAs.

Figure 12.14. Comparison of the OSPFv2 Network Summary and the OSPFv3 Inter-Area Prefix LSAs.

12.2.3.6. Inter-Area Router LSA

The Inter-Area Router LSA performs the same duties for OSPFv3 as the type 4 Summary LSA performs for OSPFv2. An ABR originates an Inter-Area Router LSA into an area to advertise an ASBR that resides outside of the area. The ABR originates a separate Inter-Area Router LSA for each ASBR it advertises.

Figure 12.15 compares the Inter-Area Router LSA with the OSPFv2 type 4 Summary LSA. Although the OSPFv2 type 3 and type 4 Summary LSAs have the same formats, you can see by comparing Figures 12.14 and 12.15 that the Inter-Area Network and Inter-Area Router LSAs are different. The fields are self-descriptive: Options specifies optional capabilities of the ASBR, Metric specifies the cost to the ASBR, and Destination Router ID is the ASBR RID.

Figure 12.15. Comparison of the OSPFv2 ASBR Summary and the OSPFv3 Inter-Area Router LSAs.

12.2.3.7. AS-External LSA

Prefixes exterior to the OSPF domain are advertised by both OSPFv2 and OSPFv3 in AS-External LSAs. And with both protocols, an individual AS-External LSA must be generated for every external prefix to be advertised. Therefore, all the same warnings about redistributing large numbers of external prefixes (almost always from BGP) into the domain that apply to OSPFv2 also apply to OSPFv3.

Although the names and functions are the same, Figure 12.16 shows that the formats of the AS-External LSAs vary significantly between OSPFv2 and OSPFv3.

Figure 12.16. Comparison of the OSPFv2 and OSPFv3 AS-External LSAs.

The E flag performs the same function in the OSPFv3 LSA as in the OSPFv2 LSA. If set, the metric is a type 2 external metric. If the bit is cleared, the metric is a type 1 external metric.

The F flag indicates, when set, that a forwarding address is included in the LSA.

The T flag indicates, when set, that an external route tag is included in the LSA.

Metric, of course, specifies the cost of the route. Whether it is type 1 or type 2 depends on the value of the E flag.

Prefix Length, Prefix Options, and Address Prefix completely describe the enclosed prefix, as described earlier in this section.

Forwarding Address, if included, is a fully specified 128-bit IPv6 address representing the next-hop address to the destination prefix. It is included only if the F flag is set.

External Route Tag, if included, performs the same function as the External Route Tag field in the OSPFv2 AS-External LSA. It is included only if the T flag is set.

Referenced Link State ID and Referenced Link State Type, if used, allow additional information about the prefix to be included in another LSA. These two fields describe the Link state ID and the type of the LSA carrying the additional information. The Advertising Router field of the referenced LSA must also match the value of the Advertising Router field in the AS-External LSA. The additional information has, as with the External Route Tag, no relevance to OSPF itself but is used to communicate information across the OSPF domain between border routers. If this function is not used, the Referenced Link State Type field is set to all 0s.

12.2.3.8. Other LSAs

Although they are not illustrated here, you can see from Table 12.3 that OSPFv3 also supports MOSPF with a Group Membership LSA and Not-So-Stubby areas with the Type 7 LSA. The table also lists an Intra-Area-TE LSA, which is a proposed LSA for support of traffic engineering in OSPFv3.^[10] As of this writing, the LSA is not yet supported by the large router vendors. Such support is likely to be in place, however, by the time you are reading this book. Such are the difficulties of book publishing in the face of fast-evolving technology.

^[10] Kunihiro Ishiguro and Toshiaki Takada, "Traffic Engineering Extensions to OSPF Version 3," draft-ietf-ospfospfv3-traffic-01.txt, August 2003.

12.2.4. The Options Field

You have seen in the previous section that a 24-bit Options field, specifying optional capabilities of the originating router, is carried in Router, Network, Inter-Area Router, and Link LSAs. As the next section shows, this field is also carried in the Hello and Database Description packets. Figure 12.17 shows the format of the Options field. As of this writing, only the 6 rightmost bits are defined as options flags, and most of those are the same flags you are familiar with from OSPFv2. OSPFv3 routers ignore unrecognized options flags.

Figure 12.17. The OSPFv3 Options field.

DC specifies support for demand circuits capability.

R indicates whether the originator is an active router. When this bit is cleared, routes transiting the originating node cannot be computed. The R flag therefore adds a capability similar to the IS-IS Overload bit.

N specifies support for NSSA LSAs.

MC specifies support for MOSPF.

E specifies how AS-External LSAs are flooded, for the formation of stub areas.

V6, if clear, specifies that the router or link should be excluded from IPv6 routing calculations.

12.2.5. OSPFv3 Packets

OSPFv3 uses the same five packet types as OSPFv2, and the mechanisms and functions associated with the packets are also essentially the same. Just as OSPFv2 packets are identified by IP protocol number 89, OSPFv3 packets are identified with next header number 89. And OSPFv3 packets use the same multicast procedures as OSPFv2. For IPv6, the AllSPFRouters multicast address is FF02::5, and the AllDRouters multicast address is FF02::6.

Unlike the LSAs, which must vary considerably from version 2 to support both IPv6 prefixes and modified link state processing procedures, the packet formats of OSPFv3 differ little from those of OSPFv2. Most of the differences are in the packet headers and in the Hello packets.

Figure 12.18 compares the OSPFv2 and OSPFv3 packet headers. The values used in the Type field of the OSPFv3 header are identical to the type values used by OSPFv2, because the same five packet types are used. The most noticeable difference between the two headers is the elimination of the authentication fields in OSPFv3. As mentioned earlier in this chapter, OSPFv3 has no authentication procedures of its own but instead relies on the authentication procedures built into the IPv6 packets.

Figure 12.18. Comparison of the OSPFv2 and OSPFv3 packet headers.

The other difference is the Instance ID field in the OSPFv3 header. This field enables the support of multiple OSPFv3 instances on the same link, a capability that OSPFv2 does not have. As discussed earlier in this chapter, multiple instance support means that a set of routers can share a multi-access link while at the same time belonging to separate OSPFv3 domains. Although you can achieve similar results by manipulating OSPFv2 authentication, the resulting implementation is inefficient. As routers in one subset reject Hellos from routers in other subsets, authentication failure messages are being generated at a rate equal to the Hellos generated by all those "outside" routers.

The Instance ID must be unique only to the local link.

Figure 12.19 compares OSPFv2 and OSPFv3 Hello packet formats. The Network Mask field of the OSPFv2 Hello is not included in the OSPFv3 Hello, because IPv6 has no need for it. Beyond that, the same fields (below the header) appear in both packets. The Options field increases in size to 24 bits, and the router dead interval is decreased from 32 bits to 16 bits. The implication of this second field is that the theoretical maximum router dead interval is decreased from 4.3 billion seconds to 65,535 seconds. This change has little or no bearing on operational networks. The maximum configurable router dead interval on the most common OSPF implementations has long been 65,535 anyway, and intelligent OSPF designs do not approach even this maximum.

Figure 12.19. Comparison of the OSPFv2 and OSPFv3 Hello packet formats.

The OSPFv3 Database Description packet, shown in Figure 12.20, differs from its OSPFv2 counterpart only in the repositioning of the Options field to accommodate its greater length. OSPFv3 Link State Request, Link State Update, and Link State Acknowledgement packets are identical in their format, beyond the header, to their OSPFv2 counterparts and are therefore not illustrated in this chapter.

Figure 12.20. Comparison of the OSPFv2 and OSPFv3 Database Description packet formats.

12.2.6. Future Extensions to OSPFv3

I began the discussion of OSPFv3 by stating that the protocol includes several improvements over OSPFv2 that have nothing to do with IPv6. The natural question to ask, then, is: If it is a better protocol, why shouldn't it be extended to support IPv4? At the time this chapter is being written, discussion is ongoing within the IETF's OSPF working group concerning the practicality of such an extension. The key limitation here is that OSPFv3 is designed to run over IPv6. That means that the protocol cannot run in an IPv4-only environment. Having said that, there are no serious roadblocks to using OSPFv3 to carry IPv4 prefixes as long as the underlying network is IPv6-enabled. The Link LSAs can easily accommodate IPv4 prefixes. The focus of the WG discussions is more on how to implement such support. Is it better to have integrated IPv4/IPv6 processing, so that only one SPF tree is calculated within an area and no duplicate adjacencies are needed? Or, is it better to use the Instance ID to define separate OSPF instances for IPv4 and IPv6, trading some processing efficiency for the ease of managing and troubleshooting a separate link state database for IPv4 and IPv6?

An Internet Draft proposes the support in OSPFv3 not just of IPv4, but of multiple address families.^[11] The proposal is to use multiple instances, and to reserve Instance ID ranges for address families: 0 through 19 for IPv6 unicast, 20 through 39 for IPv6 multicast, 40 through 59 for IPv4 unicast, and 60 through 79 for IPv4 multicast (and reserving 80 to 255 for future address families). The draft also proposes a new flag, the AF flag, in the Options field for signaling router support of multiple address families. Whether such an extension to the protocol is ever developed depends largely on whether users demand it. By the time you are reading this book, perhaps that question will be answered.

^[11] Sina Mirtorabi, Abhay Roy, Michael Barnes, Acee Lindem, Quaizar Vohra, and Rahul Aggarwal, "Support of Address Families in OSPFv3," draft-mirtorabi-ospfv3-aff-alt-00.txt, August 2003.

There is also a proposal before the OSPF WG for carrying OSPFv2 Opaque LSAs in OSPFv3. These LSAs (types 9, 10, and 11 in OSPFv2) have proven useful in extending new capabilities to OSPFv2, and so their utility is desirable for OSPFv3. The three Opaque LSAs are made OSPFv3-capable by adding an OSPFv3 LSA header. In the Type field, the LSA function code (see Figure 12.8) is the version 2 type value, the U bit is 1, and the S2/S1 bits are set to reflect the flooding scope of the original version 2 LSAs. As with IPv4 support, whether this extension is adopted is yet to be seen.