RFC 6860: Hiding Transit-Only Networks in OSPF
In plain English — editorial summary, not part of the RFC
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. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6860
- Published
- January 2013
- Authors
- Y. Yang; A. Retana; A. Roy
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- rtg
- Pages
- 13
- Also known as
- —
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6862Keying and Authentication for Routing Protocols (KARP) Overview, Threats, and RequirementsCurrent
March 2013
- RFC 6863Analysis of OSPF Security According to the Keying and Authentication for Routing Protocols (KARP) Design GuideCurrent
March 2013
- RFC 6870Pseudowire Preferential Forwarding Status BitUpdated
February 2013
- RFC 6850Definitions of Managed Objects for Routing Bridges (RBridges)Current
January 2013
- RFC 6845OSPF Hybrid Broadcast and Point-to-Multipoint Interface TypeCurrent
January 2013
- RFC 6836Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)Current
January 2013
- RFC 6835The Locator/ID Separation Protocol Internet Groper (LIG)Current
January 2013
- RFC 6834Locator/ID Separation Protocol (LISP) Map-VersioningObsoleted
January 2013
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?