Hiding Transit-Only Networks in OSPF
How OSPF routers stop advertising the router-to-router links that only they need, so the prefixes never reach routing tables.
Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January 2013, <https://www.rfc-editor.org/info/rfc6860>.
@misc{rfc6860,
series = {Request for Comments},
number = 6860,
howpublished = {RFC 6860},
publisher = {RFC Editor},
doi = {10.17487/RFC6860},
url = {https://www.rfc-editor.org/info/rfc6860},
author = {Y. Yang and A. Retana and A. Roy},
title = {{Hiding Transit-Only Networks in OSPF}},
pagetotal = 13,
year = 2013,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) Y. Yang
Request for Comments: 6860 A. Retana
Updates: 2328, 5340 A. Roy
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 January 2013
Hiding Transit-Only Networks in OSPF
Abstract
A transit-only network is defined as a network connecting routers
only. In OSPF, transit-only networks are usually configured with
routable IP addresses, which are advertised in Link State
Advertisements (LSAs) but are not needed for data traffic. In
addition, remote attacks can be launched against routers by sending
packets to these transit-only networks. This document presents a
mechanism to hide transit-only networks to speed up network
convergence and reduce vulnerability to remote attacks.
In the context of this document, 'hiding' implies that the prefixes
are not installed in the routing tables on OSPF routers. In some
cases, IP addresses may still be visible when using OSPFv2.
This document updates RFCs 2328 and 5340.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6860.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................3
1.1. Requirements Notation ......................................3
2. Hiding IPv4 Transit-Only Networks in OSPFv2 .....................3
2.1. Point-to-Point Networks ....................................3
2.1.1. Advertising Point-to-Point Networks .................4
2.1.2. Hiding Point-to-Point Networks ......................4
2.2. Broadcast Networks .........................................5
2.2.1. Advertising Broadcast Networks ......................5
2.2.2. Hiding Broadcast Networks ...........................5
2.2.2.1. Sending Network-LSA ........................5
2.2.2.2. Receiving Network-LSA ......................6
2.2.2.2.1. Backward Compatibility ..........6
2.3. Non-Broadcast Networks .....................................7
2.3.1. NBMA ................................................7
2.3.2. Point-to-Multipoint .................................7
2.3.2.1. Advertising Point-to-Multipoint Networks ...7
2.3.2.2. Hiding Point-to-Multipoint Networks ........8
3. Hiding IPv6 Transit-Only Networks in OSPFv3 .....................9
3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3 ..........9
4. Operational Considerations ......................................9
4.1. Forwarding Address ........................................10
4.2. Virtual Links .............................................10
4.3. Unnumbered Interfaces .....................................10
5. Security Considerations ........................................11
6. Acknowledgments ................................................11
7. References .....................................................12
7.1. Normative References ......................................12
7.2. Informative References ....................................12
1. Introduction
A transit-only network is defined as a network connecting routers
only. In OSPF, transit-only networks are usually configured with
routable IP addresses, which are advertised in LSAs but not needed
for data traffic. In addition, remote attacks can be launched
against routers by sending packets to these transit-only networks.
This document presents a mechanism to hide transit-only networks to
speed up network convergence and reduce vulnerability to remote
attacks.
Hiding transit-only networks will not impact reachability to the end
hosts.
In the context of this document, 'hiding' implies that the prefixes
are not installed in the routing tables on OSPF routers. In
[OSPFv2], the IPv4 interface addresses are still visible in the
Router-LSA links and the network-LSA Link-State ID (LSID). In
[OSPFv3], the router-LSAs and network-LSAs do not contain IPv6
addresses and are not visible.
This document updates [OSPFv2] and [OSPFv3] by specifying a mechanism
that can be used to hide transit-only networks.
1.1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORD].
2. Hiding IPv4 Transit-Only Networks in OSPFv2
In [OSPFv2], networks are classified as point-to-point, broadcast, or
non-broadcast. In the following sections, we will review how these
OSPF networks are being advertised and discuss how to hide them.
2.1. Point-to-Point Networks
A point-to-point network joins a single pair of routers. Figure 1
shows a point-to-point network connecting routers RT1 and RT2.
+---+.1 198.51.100.0/30 .2+---+
|RT1|---------------------------|RT2|
+---+ +---+
Figure 1. Physical Point-to-Point Network
2.1.1. Advertising Point-to-Point Networks
For each numbered point-to-point network, a router has two link
descriptions in its router-LSA: one Type 1 link (point-to-point)
describing the neighboring router, and one Type 3 link (stub)
describing the assigned IPv4 subnet.
An example of a router-LSA originated by RT1 would look like the
following:
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.1 ;RT1's Router ID
Advertising Router = 192.0.2.1 ;RT1's Router ID
#links = 2
Link ID = 192.0.2.2 ;RT2's Router ID
Link Data = 198.51.100.1 ;Interface IP address
Type = 1 ;connects to RT2
Metric = 10
Link ID= 198.51.100.0 ;IP network/subnet number
Link Data = 255.255.255.252 ;Subnet's mask
Type = 3 ;Connects to stub network
Metric = 10
The Type 1 link will be used for SPF calculation, while the Type 3
link will be used to install a route to the corresponding subnet in
the Routing Information Base (RIB).
2.1.2. Hiding Point-to-Point Networks
To hide a transit-only point-to-point network, the Type 3 link is
omitted from the router-LSA.
An example of a router-LSA originated by RT1, hiding the point-to-
point network depicted in Figure 1, would look like the following:
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.1 ;RT1's Router ID
Advertising Router = 192.0.2.1 ;RT1's Router ID
#links = 1
Link ID = 192.0.2.2 ;RT2's Router ID
Link Data = 198.51.100.1 ;Interface IP address
Type = 1 ;connects to RT2
Metric = 10
2.2. Broadcast Networks
A broadcast network joins many (more than two) routers and supports
the capability to address a single physical message to all of the
attached routers. Figure 2 shows a broadcast network connecting
routers RT3, RT4, and RT5.
+---+ +---+
|RT3| |RT4|
+---+ +---+
|.3 198.51.100.0/24 .4|
+-----------------------------+
|.5
+---+
|RT5|
+---+
Figure 2. Broadcast Network
2.2.1. Advertising Broadcast Networks
A Designated Router (DR) describes a broadcast network in a
network-LSA. Assuming that RT3 is elected as the DR in Figure 2, an
example of the network-LSA originated by RT3 would look like
LS age = 0 ;newly (re)originated
LS type = 2 ;network-LSA
Link State ID = 198.51.100.3 ;IP address of the DR (RT3)
Advertising Router = 192.0.2.3 ;RT3's Router ID
Network Mask = 255.255.255.0
Attached Router = 192.0.2.3 ;RT3's Router ID
Attached Router = 192.0.2.4 ;RT4's Router ID
Attached Router = 192.0.2.5 ;RT5's Router ID
OSPF obtains the IP network number from the combination of the Link
State ID and the network mask. In addition, the Link State ID is
also being used for the two-way connectivity check.
2.2.2. Hiding Broadcast Networks
2.2.2.1. Sending Network-LSA
A special subnet mask value of 255.255.255.255 MUST be used in the
network-LSA to hide a transit-only broadcast network. While a
broadcast network connects more than routers, using 255.255.255.255
will not hide an access broadcast network accidentally.
As there is no change of the Link State ID, the two-way connectivity
check would proceed normally.
An example of a network-LSA originated by RT3, hiding the broadcast
network depicted in Figure 2, would look like the following:
LS age = 0 ;newly (re-)originated
LS type = 2 ;network-LSA
Link State ID = 198.51.100.3 ;IP address of the DR (RT3)
Advertising Router = 192.0.2.3 ;RT3's Router ID
Network Mask = 255.255.255.255 ;special subnet mask
Attached Router = 192.0.2.3 ;RT3's Router ID
Attached Router = 192.0.2.4 ;RT4's Router ID
Attached Router = 192.0.2.5 ;RT5's Router ID
2.2.2.2. Receiving Network-LSA
It is RECOMMENDED that all routers in an area be upgraded at the same
time to process the modified network-LSA correctly and consistently.
When a router receives a network-LSA, it MUST calculate the routing
table normally [OSPFv2]. However, if the network mask in the
network-LSA is 255.255.255.255, the router MUST NOT install the route
in the RIB.
2.2.2.2.1. Backward Compatibility
When a router that has not yet been upgraded receives a modified
network-LSA, as specified in Section 2.2.2.1, a host route to the
originating DR will be installed. This is not ideal, but it is
better than the current result, which exposes the whole subnet.
In a partial-deployment scenario, upgraded routers and routers that
have not yet been upgraded may coexist. The former do not install
the host route to the DR's interface, while the latter install it.
Such inconsistencies create routing black holes, which should
normally be avoided. In this case, however, as packets destined for
the transit-only networks are dropped somewhere in the network, the
black holes actually help the DRs defend themselves from remote
attacks.
In summary, the modification of the network-LSA, as specified in
Section 2.2.2.1, is backward compatible with the current
specification of [OSPFv2], even in a partial-deployment scenario.
2.3. Non-Broadcast Networks
A non-broadcast network joins many (more than two) routers but does
NOT support the capability to address a single physical message to
all of the attached routers. As mentioned in [OSPFv2], OSPF runs in
one of two modes over non-broadcast networks: Non-Broadcast Multi-
Access (NBMA) or point-to-multipoint.
2.3.1. NBMA
In NBMA mode, OSPF emulates operation over a broadcast network: a
Designated Router is elected for the NBMA network, and the Designated
Router originates an LSA for the network.
To hide an NBMA transit-only network, OSPF adopts the same
modification as that used over the broadcast transit-only network
(see Section 2.2.2).
2.3.2. Point-to-Multipoint
In point-to-multipoint mode, OSPF treats the non-broadcast network as
a collection of point-to-point links.
Figure 3 shows a non-broadcast network connecting routers RT6, RT7,
RT8, and RT9. In this network, all routers can communicate directly,
except for routers RT7 and RT8.
+---+ +---+
|RT6| |RT7|
+---+ +---+
|.6 198.51.100.0/24 .7|
+----------------------------+
|.8 .9|
+---+ +---+
|RT8| |RT9|
+---+ +---+
Figure 3. Non-Broadcast Network
2.3.2.1. Advertising Point-to-Multipoint Networks
For a point-to-multipoint network, a router has multiple link
descriptions in its router-LSA, one Type 1 link (point-to-point) for
EACH directly communicable router, and one Type 3 link (stub)
advertising its interface IPv4 address with a subnet mask of
255.255.255.255.
An example of a router-LSA originated by RT7 would look like the
following:
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.7 ;RT7's Router ID
Advertising Router = 192.0.2.7 ;RT7's Router ID
#links = 3
Link ID = 192.0.2.6 ;RT6's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT6
Metric = 10
Link ID = 192.0.2.9 ;RT9's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT9
Metric = 10
Link ID= 198.51.100.7 ;Interface IP address
Link Data = 255.255.255.255 ;Subnet's mask
Type = 3 ;Connects to stub network
Metric = 0
2.3.2.2. Hiding Point-to-Multipoint Networks
To hide a transit-only point-to-multipoint network, the Type 3 link
is omitted from the router-LSA.
An example of a router-LSA originated by RT7, hiding the point-to-
point network depicted in Figure 3, would look like the following:
LS age = 0 ;newly (re-)originated
LS type = 1 ;router-LSA
Link State ID = 192.0.2.7 ;RT7's Router ID
Advertising Router = 192.0.2.7 ;RT7's Router ID
#links = 2
Link ID = 192.0.2.6 ;RT6's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT6
Metric = 10
Link ID = 192.0.2.9 ;RT9's Router ID
Link Data = 198.51.100.7 ;Interface IP address
Type = 1 ;connects to RT9
Metric = 10
3. Hiding IPv6 Transit-Only Networks in OSPFv3
In [OSPFv3], addressing semantics have been removed from the OSPF
protocol packets and the main LSA types, leaving a network-protocol-
independent core.
More specifically, router-LSAs and network-LSAs no longer contain
network addresses but simply express topology information. Instead,
two new LSA types, link-LSA and intra-area-prefix-LSA, have been
introduced. A link-LSA associates a list of IPv6 addresses to a link
and has local-link flooding scope, and an intra-area-prefix-LSA
either associates a list of IPv6 addresses with a router by
referencing a router-LSA or associates a list of IPv6 addresses with
a broadcast/NBMA network by referencing a network-LSA. In the latter
case, the prefixes in the link-LSAs from adjacent neighbors are
copied into the intra-area-prefix-LSA by the Designated Router.
To hide a transit-only network in [OSPFv3], the IPv6 address prefixes
are omitted from the router-LSA. Consequently, when a Designated
Router builds an intra-area-prefix-LSA referencing a network-LSA,
these IPv6 address prefixes will be omitted.
In addition, when a router builds an intra-area-prefix-LSA that is
referencing a router-LSA, the associated IPv6 address prefixes from
the transit-only network MUST also be omitted from the intra-area-
prefix-LSA.
3.1. Hiding AF-Enabled Transit-Only Networks in OSPFv3
[OSPF-AF] supports multiple Address Families (AFs) by mapping each AF
to a separate Instance ID and OSPFv3 instance.
In the meantime, each prefix advertised in OSPFv3 has a prefix length
field [OSPFv3], which facilitates advertising prefixes of different
lengths in different AFs. The existing LSAs defined in [OSPFv3] are
used for prefix advertising, and there is no need to define new LSAs.
In other words, as link-LSAs and intra-area-prefix-LSAs are still
being used, the same mechanism explained in Section 3 can be used to
hide those AF-enabled transit-only networks as well.
4. Operational Considerations
By eliminating the ability to reach transit-only networks, the
ability to manage these interfaces may be reduced. In order not to
reduce the functionality and capability of the overall network, it is
recommended that extensions such as [UNNUMBERED] also be implemented.
Note that the extension defined in [UNNUMBERED] may provide the user
with the IP address of an interface. If that address was hidden, as
specified in this document, then even though the address is assigned
to the interface, it will not be reachable.
4.1. Forwarding Address
A non-zero forwarding address can be advertised in AS-external-LSAs
and Not-So-Stubby Area LSAs (NSSA-LSAs) [NSSA] to achieve optimal
routing to Autonomous System (AS) external routes. The matching
routing table entry for the forwarding address must exist to
facilitate the SPF calculation.
In other words, when prefix-hiding is configured on the next-hop
interface, the next-hop address MUST NOT be advertised as a
forwarding address.
Consequently, sub-optimal routing to these AS external routes may
exist when prefix-hiding is configured.
4.2. Virtual Links
Virtual links are used to connect physically separate components of
the backbone. The virtual link's viability is determined by the
existence of an intra-area path between two endpoints. The matching
routing table entries of the endpoints must exist to ensure the
virtual link's operation.
In other words, if prefix-hiding is configured on an interface, the
virtual link endpoint MUST NOT use that interface's IP address as the
virtual interface's IP address.
4.3. Unnumbered Interfaces
Note that no host route is generated for, and no IP packets can be
addressed to, interfaces to unnumbered point-to-point networks
[OSPFv2]. In other words, these addresses are already hidden.
However, for manageability purposes, it may be common practice to
manually include the numbered interface (for example, a loopback
interface to which the unnumbered interface points) in routing
updates. If needed, the numbered interface's address can be hidden
by using the mechanisms described in this document or by simply not
advertising it.
Before deciding to hide (or suppress the advertisement of) a numbered
interface, it is very important to consider other uses that interface
may have. Examples of common uses may include virtual link endpoint,
inter-domain routing peering point, etc. In other words, it may not
be possible to hide the address associated to an unnumbered interface
due to other applications in the network.
5. Security Considerations
One motivation for this document is to reduce vulnerability to remote
attacks by hiding transit-only networks. The result should then be
that fewer OSPF core networks will be exposed.
The mechanisms described above result in reachability information
from transit-only networks not being installed in the routers'
forwarding tables. The effect is that even if the address of a
transit-only network is known, the forwarding information is not
present in the routers to reach the destination. Also, in some
cases, the address information is completely omitted from the LSA.
Some information in the LSA (such as the OSPF Router ID) cannot be
omitted. Even though the Router ID may be taken from an IPv4 address
on the router, the configuration can be easily changed. Note again
that having an address doesn't guarantee reachability if the
information is hidden from the forwarding tables.
While the steps described in this document are meant to be applied
only to transit-only networks, they could be used to hide other
networks as well. It is expected that the same care that users put
into the configuration of other routing protocol parameters is used
in the configuration of this extension.
6. Acknowledgments
The idea of using a special subnet mask to hide broadcast networks in
OSPF was originally introduced in the US patent "Apparatus and method
to hide transit only multi-access networks in OSPF" (patent number:
7,929,524), by Yi Yang, Alvaro Retana, James Ng, Abhay Roy, Alfred
Lindem, Sina Mirtorabi, Timothy Gage, and Khalid Raza.
The authors would like to thank Acee Lindem, Shraddha Hegde, Rajesh
Shetty, Marek Karasek, Michael Barnes, Paul Wells, Adrian Farrel, and
Stephen Farrell for their feedback on the document.
7. References
7.1. Normative References
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA)
Option", RFC 3101, January 2003.
[OSPFv2] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
April 1998.
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[OSPF-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M.,
and R. Aggarwal, "Support of Address Families in
OSPFv3", RFC 5838, April 2010.
7.2. Informative References
[UNNUMBERED] Atlas, A., Ed., Bonica, R., Ed., Pignataro, C., Ed.,
Shen, N., and JR. Rivers, "Extending ICMP for Interface
and Next-Hop Identification", RFC 5837, April 2010.
Authors' Addresses
Yi Yang
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
USA
EMail: yiya@cisco.com
Alvaro Retana
Cisco Systems, Inc.
7025 Kit Creek Road
RTP, NC 27709
USA
EMail: aretana@cisco.com
Abhay Roy
Cisco Systems, Inc.
225 West Tasman Drive
San Jose, CA 95134
USA
EMail: akr@cisco.com
AI ELI5
On this page
§1Why Hide Transit-Only Networks
A transit-only network is a network that connects routers only. In OSPF these networks are usually given routable IP addresses. Those addresses are advertised in Link State Advertisements (LSAs), but data traffic does not need them. They also give attackers a target: remote attacks can be launched against routers by sending packets to these networks.
RFC 6860 describes a mechanism to hide them, to speed up network convergence and reduce vulnerability to remote attacks. Hiding does not impact reachability to end hosts.
In this document, 'hiding' means the prefixes are not installed in the routing tables on OSPF routers. In OSPFv2 the IPv4 interface addresses are still visible in the Router-LSA links and in the network-LSA Link-State ID. In OSPFv3 the router-LSAs and network-LSAs do not contain IPv6 addresses, so nothing is visible there. The RFC updates RFC 2328 (OSPFv2) and RFC 5340 (OSPFv3).
Some roads are only used by the routers themselves. Putting them on every map just shows troublemakers where to knock, so this RFC says to leave them off.
§2.1Point-to-Point Networks in OSPFv2
A point-to-point network joins a single pair of routers. For each numbered point-to-point network, a router normally puts two link descriptions in its router-LSA: a Type 1 link (point-to-point) describing the neighbor router, and a Type 3 link (stub) describing the assigned IPv4 subnet. The Type 1 link is used for the SPF calculation, while the Type 3 link is used to install a route to the subnet in the Routing Information Base (RIB).
To hide a transit-only point-to-point network, the router simply omits the Type 3 link from its router-LSA. The neighbor link stays, so the topology still works, but no route to the subnet is installed.
Two friends share a private tunnel. The map still says they are connected, but it no longer lists the tunnel's street address.
§2.2Broadcast and NBMA Networks: the Special Mask
A broadcast network joins more than two routers and can address one physical message to all of them. A Designated Router (DR) describes it in a network-LSA. OSPF gets the network number from the combination of the Link State ID and the network mask, and the Link State ID is also used for the two-way connectivity check.
To hide a transit-only broadcast network, the special subnet mask 255.255.255.255 MUST be used in the network-LSA. Because the Link State ID does not change, the two-way connectivity check proceeds normally. Using that mask also means an access broadcast network (one with hosts on it) is not hidden by accident.
On receipt, a router MUST calculate the routing table normally, but if the network mask is 255.255.255.255 it MUST NOT install the route in the RIB. The RFC recommends that all routers in an area be upgraded at the same time. NBMA networks, where OSPF emulates a broadcast network with a Designated Router, use the same modification.
The group's meeting room is marked on the map with a code that says 'do not drive here'. Everyone still knows who is in the group, but no road leads to the room.
| Network type | How it is hidden |
|---|---|
| Point-to-point (OSPFv2) | Omit the Type 3 stub link from the router-LSA |
| Broadcast (OSPFv2) | Use mask 255.255.255.255 in the network-LSA |
| NBMA (OSPFv2) | Same as broadcast |
| Point-to-multipoint (OSPFv2) | Omit the Type 3 stub link from the router-LSA |
| OSPFv3 | Omit the IPv6 prefixes from the router-LSA and the intra-area-prefix-LSA |
LS age = 0
LS type = 2 ;network-LSA
Link State ID = 198.51.100.3 ;IP address of the DR (RT3)
Advertising Router = 192.0.2.3 ;RT3's Router ID
Network Mask = 255.255.255.255 ;special subnet mask
Attached Router = 192.0.2.3
Attached Router = 192.0.2.4
Attached Router = 192.0.2.5§2.3Point-to-Multipoint Networks and Partial Deployment
In point-to-multipoint mode, OSPF treats a non-broadcast network as a collection of point-to-point links. A router has one Type 1 link for each directly communicable router, plus one Type 3 stub link advertising its own interface address with the mask 255.255.255.255. To hide the network, the Type 3 link is omitted from the router-LSA.
The RFC also considers routers that have not been upgraded. If one receives a modified network-LSA, it installs a host route to the originating DR. That is not ideal, but it is better than the previous result, which exposed the whole subnet. In a partial deployment the upgraded and non-upgraded routers disagree, which creates routing black holes. Here the RFC argues they actually help, because packets for the transit-only networks are dropped somewhere in the network, which helps the DRs defend themselves from remote attacks. It concludes the change is backward compatible with OSPFv2.
If a few people have not got the new map yet, they might still find one door, but not the whole building. That is still better than before.
§3Hiding Networks in OSPFv3
OSPFv3 removed addressing from the main packets and LSA types. Router-LSAs and network-LSAs only express topology. Addresses live in two other LSA types: the link-LSA, which associates IPv6 addresses with a link and has local-link flooding scope, and the intra-area-prefix-LSA, which associates IPv6 addresses with a router (by referencing a router-LSA) or with a broadcast or NBMA network (by referencing a network-LSA).
To hide a transit-only network in OSPFv3, the IPv6 prefixes are omitted from the router-LSA. As a result the Designated Router leaves them out when it builds an intra-area-prefix-LSA that references a network-LSA. A router building an intra-area-prefix-LSA that references a router-LSA MUST also omit the prefixes of the transit-only network.
The same mechanism works for OSPFv3 address families (RFC 5838), because each address family maps to a separate Instance ID and the existing LSAs are still used, so no new LSAs are needed.
In the newer system the street names are on separate notes. To hide a hallway you just do not write its note.
§4Operational Considerations
Hiding networks reduces the ability to manage those interfaces. The RFC recommends also implementing extensions such as RFC 5837, which can give a user the address of an interface. Even if such an address is hidden, it is assigned to the interface but will not be reachable.
- Forwarding address: an AS-external-LSA or NSSA-LSA can carry a non-zero forwarding address, and a matching routing table entry must exist for the SPF calculation. When prefix hiding is configured on the next-hop interface, the next-hop address MUST NOT be advertised as a forwarding address, so routing to some external routes may be sub-optimal.
- Virtual links: a virtual link needs matching routing table entries for its endpoints. If prefix hiding is configured on an interface, the endpoint MUST NOT use that interface's IP address as the virtual interface address.
- Unnumbered interfaces: no host route is generated for them and no IP packets can be addressed to them, so they are already hidden. A numbered interface they point to (for example a loopback) can be hidden by these mechanisms or by not advertising it, but its other uses, such as a virtual link endpoint or an inter-domain peering point, must be considered first.
If a hallway is off the map, even the staff cannot easily walk to it for repairs. So check who else needs it before you hide it.
§5Security Considerations
Reducing vulnerability to remote attacks is one of the reasons for the document. Reachability information for transit-only networks is not installed in routers' forwarding tables, so even if an attacker knows the address of a transit-only network, the routers have no forwarding information to reach it. In some cases the address is omitted from the LSA entirely.
Some information cannot be omitted, such as the OSPF Router ID. It may be taken from an IPv4 address on the router, but the configuration can easily be changed. The steps could also be used to hide networks that are not transit-only, so the RFC expects users to take the same care as with other routing protocol parameters.
A stranger who knows a secret hallway's name still cannot get there if no road leads to it.