In RFC 1247, an OSPF router cannot originate separate AS external link advertisements (or separate summary link advertisements) for two networks that have the same address but different masks. This situation can arise when subnet 0 of a network has been assigned (a practice that is generally discouraged), or when using supernetting as described in [RFC 1519] (a practice that is generally encouraged to reduce the size of routing tables), or even when in transition from one mask to another on a subnet. Using supernetting as an example, you might want to aggregate the four class C networks 192.9.4.0-192.9.7.0, advertising one route for the aggregation and another for the single class C network 192.9.4.0.
The reason behind this limitation is that in RFC 1247, the Link State ID of AS external link advertisements and summary link advertisements is set equal to the described network's IP address. In the above example, RFC 1247 would assign both advertisements the Link State ID of 192.9.4.0, making them in essence the same advertisement. This memo fixes the problem by relaxing the setting of the Link State ID so that any of the "host" bits of the network address can also be set. This allows you to disambiguate advertisements for networks having the same address but different masks. Given an AS external link advertisement (or a summary link advertisement), the described network's address can now be obtained by masking the Link State ID with the network mask carried in the body of the advertisement. Again using the above example, the aggregate can now be advertised using a Link State ID of 192.9.4.0 and the single class C network advertised simultaneously using the Link State ID of 192.9.4.255.
Appendix F gives one possible algorithm for setting one or more "host" bits in the Link State ID in order to disambiguate advertisements. It should be noted that this is a local decision. Each router in an OSPF system is free to use its own algorithm, since only those advertisements originated by the router itself are affected.
It is believed that this change will be more or less compatible with implementations of RFC 1247. Implementations of RFC 1247 will probably either a) install routing table entries that won't be used or b) do the correct processing as outlined in this memo or c) mark the advertisement as unusable when presented with a Link State ID that has one or more of the host bits set. However, in the interest of interoperability, implementations of this memo should only set the host bits in Link State IDs when absolutely necessary.
The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3, 16.4, 16.5, 16.6, A.4.4 and A.4.5.