datatracker.ietf.org
Sign in
Version 5.12.0.p2, 2015-03-02
Report a bug

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)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4813 (Experimental)
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

[include full document text]