OSPF Link-Local Signaling
RFC 4813

Document Type RFC - Experimental (March 2007; No errata)
Obsoleted by RFC 5613
Was draft-nguyen-ospf-lls (individual in rtg area)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 4813 (Experimental)
Telechat date
Responsible AD Bill Fenner
Send notices to lhnguyen@cisco.com, ospf-chairs@ietf.org
Network Working Group                                        B. Friedman
Request for Comments: 4813                                     L. Nguyen
Category: Experimental                                            A. Roy
                                                                D. Yeung
                                                           Cisco Systems
                                                                A. Zinin
                                                                 Alcatel
                                                           February 2007

                       OSPF Link-Local Signaling

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   OSPF is a link-state intra-domain routing protocol used in IP
   networks.  OSPF routers exchange information on a link using packets
   that follow a well-defined format.  The format of OSPF packets is not
   flexible enough to enable applications to exchange arbitrary data,
   which may be necessary in certain situations.  This memo describes a
   vendor-specific, backward-compatible technique to perform link-local
   signaling, i.e., exchange arbitrary data on a link.

Friedman, et al.              Experimental                      [Page 1]
RFC 4813               OSPF Link-Local Signaling           February 2007

Table of Contents

   1. Introduction ....................................................2
   2. Proposed Solution ...............................................2
      2.1. Options Field ..............................................3
      2.2. LLS Data Block .............................................4
      2.3. LLS TLVs ...................................................5
      2.4. Predefined TLV .............................................5
           2.4.1. Extended Options TLV ................................5
           2.4.2. Cryptographic Authentication TLV ....................6
   3. Backward Compatibility ..........................................7
   4. Security Considerations .........................................7
   5. IANA Considerations .............................................7
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8
   Appendix A.  Acknowledgements ......................................9

1.  Introduction

   Formats of OSPF [RFC2328] packets are not very flexible to provide an
   acceptable mechanism for opaque data transfer.  However, this appears
   to be very useful to allow OSPF routers to do so.  An example where
   such a technique could be used is exchanging some capabilities on a
   link (standard OSPF utilizes the Options field in Hello and Exchange
   packets, but there are not so many bits left in it).

   One potential way of solving this task could be introducing a new
   packet type.  However, that would mean introducing extra packets on
   the network, which may not be desirable, so this document describes
   how to exchange data using existing, standard OSPF packet types.

2.  Proposed Solution

   To perform link-local signaling (LLS), OSPF routers add a special
   data block at the end of OSPF packets or right after the
   authentication data block when cryptographic authentication is used.
   Like with OSPF cryptographic authentication, the length of the LLS-
   block is not included into the length of OSPF packet, but is included
   in the IP packet length.  Figure 1 illustrates how the LLS data block
   is attached.

Friedman, et al.              Experimental                      [Page 2]
RFC 4813               OSPF Link-Local Signaling           February 2007

                         +---------------------+ --
                         | IP Header           | ^
                         | Length = HL+X+Y+Z   | | Header Length
                         |                     | v
                         +---------------------+ --
                         | OSPF Header         | ^
                         | Length = X          | |
                         |.....................| | X
                         |                     | |
                         | OSPF Data           | |
                         |                     | v
                         +---------------------+ --
                         |                     | ^
                         | Authentication Data | | Y
Show full document text