doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc5613.txt b/doc/rfc/rfc5613.txt
new file mode 100644
index 0000000..ed069ea
--- /dev/null
+++ b/doc/rfc/rfc5613.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           A. Zinin
+Request for Comments: 5613                                Alcatel-Lucent
+Obsoletes: 4813                                                   A. Roy
+Category: Standards Track                                      L. Nguyen
+                                                           Cisco Systems
+                                                             B. Friedman
+                                                            Google, Inc.
+                                                                D. Yeung
+                                                           Cisco Systems
+                                                             August 2009
+
+
+                       OSPF Link-Local Signaling
+
+Abstract
+
+   OSPF is a link-state intra-domain routing protocol.  OSPF routers
+   exchange information on a link using packets that follow a well-
+   defined fixed format.  The format is not flexible enough to enable
+   new features that need to exchange arbitrary data.  This document
+   describes a backward-compatible technique to perform link-local
+   signaling, i.e., exchange arbitrary data on a link.  This document
+   replaces the experimental specification published in RFC 4813 to
+   bring it on the Standards Track.
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 1]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+     1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  2
+   2.  Proposed Solution  . . . . . . . . . . . . . . . . . . . . . .  3
+     2.1.  L-Bit in Options Field . . . . . . . . . . . . . . . . . .  4
+     2.2.  LLS Data Block . . . . . . . . . . . . . . . . . . . . . .  4
+     2.3.  LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . .  5
+     2.4.  Extended Options and Flags TLV . . . . . . . . . . . . . .  5
+     2.5.  Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . .  6
+     2.6.  Private TLVs . . . . . . . . . . . . . . . . . . . . . . .  7
+   3.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  7
+   4.  Compatibility Issues . . . . . . . . . . . . . . . . . . . . .  9
+   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     6.2.  Informative References . . . . . . . . . . . . . . . . . . 10
+   Appendix A.  Acknowledgements  . . . . . . . . . . . . . . . . . . 11
+   Appendix B.  Changes from RFC 4813 . . . . . . . . . . . . . . . . 11
+
+1.  Introduction
+
+   This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3
+   [OSPFV3] allowing additional information to be exchanged between
+   routers on the same link.  OSPFv2 and OSPFv3 packet formats are fixed
+   and do not allow for extension.  This document proposes appending an
+   optional data block composed of Type/Length/Value (TLV) triplets to
+   existing OSPFv2 and OSPFv3 packets to carry this additional
+   information.  Throughout this document, OSPF will be used when the
+   specification is applicable to both OSPFv2 and OSPFv3.  Similarly,
+   OSPFv2 or OSPFv3 will be used when the text is protocol specific.
+
+   One potential way of solving this task could be introducing a new
+   packet type.  However, that would mean introducing extra packets on
+   the network that may not be desirable and may cause backward
+   compatibility issues.  This document describes how to exchange data
+   using standard OSPF packet types.
+
+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 [KEY].
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 2]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+2.  Proposed Solution
+
+   To perform link-local signaling (LLS), OSPF routers add a special
+   data block to the end of OSPF packets or right after the
+   authentication data block when cryptographic authentication is used.
+   The length of the LLS block is not included into the length of the
+   OSPF packet, but is included in the IPv4/IPv6 packet length.  Figure
+   1 illustrates how the LLS data block is attached.
+
+   +---------------------+ --              --  +---------------------+
+   | IP Header           | ^               ^   | IPv6 Header         |
+   | Length = HL+X+Y+Z   | | Header Length |   | Length = HL+X+Y     |
+   |                     | v               v   |                     |
+   +---------------------+ --              --  +---------------------+
+   | OSPF Header         | ^               ^   | OSPFv3 Header       |
+   | Length = X          | |               |   | Length = X          |
+   |.....................| | X             | X |.....................|
+   |                     | |               |   |                     |
+   | OSPFv2 Data         | |               |   | OSPFv3 Data         |
+   |                     | v               v   |                     |
+   +---------------------+ --              --  +---------------------+
+   |                     | ^               ^   |                     |
+   | Authentication Data | | Y             | Y |  LLS Data           |
+   |                     | v               v   |                     |
+   +---------------------+ --              --  +---------------------+
+   |                     | ^
+   |  LLS Data           | | Z
+   |                     | v
+   +---------------------+ --
+
+               Figure 1: LLS Data Block in OSPFv2 and OSPFv3
+
+   The LLS block MAY be attached to OSPF Hello and Database Description
+   (DD) packets.  The LLS block MUST NOT be attached to any other OSPF
+   packet types on generation and MUST be ignored on reception.
+
+   The data included in the LLS block attached to a Hello packet MAY be
+   used for dynamic signaling since Hello packets may be sent at any
+   time.  However, delivery of LLS data in Hello packets is not
+   guaranteed.  The data sent with DD packets is guaranteed to be
+   delivered as part of the adjacency forming process.
+
+   This document does not specify how the data transmitted by the LLS
+   mechanism should be interpreted by OSPF routers.  As routers that do
+   not understand LLS may receive these packets, changes made due to LLS
+   block TLV's do not affect the basic routing when interacting with
+   non-LLS routers.
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 3]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+2.1.  L-Bit in Options Field
+
+   A new L-bit (L stands for LLS) is introduced into the OSPF Options
+   field (see Figures 2a and 2b).  Routers set the L-bit in Hello and DD
+   packets to indicate that the packet contains an LLS data block.  In
+   other words, the LLS data block is only examined if the L-bit is set.
+
+             +---+---+---+---+---+---+---+---+
+             | * | O | DC| L |N/P| MC| E | * |
+             +---+---+---+---+---+---+---+-+-+
+
+              Figure 2a: OSPFv2 Options Field
+
+
+   0                   1                       2
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4  5 6 7  8  9  0  1  2  3
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+
+   | | | | | | | | | | | | | | |L|AF|*|*|DC| R| N|MC| E|V6|
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+--+--+--+--+--+
+
+              Figure 2b: OSPFv3 Options Field
+
+   The L-bit MUST NOT be set except in Hello and DD packets that contain
+   an LLS block.
+
+2.2.  LLS Data Block
+
+   The data block used for link-local signaling is formatted as
+   described below (see Figure 3 for illustration).
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Checksum           |       LLS Data Length         |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |                           LLS TLVs                            |
+   .                                                               .
+   .                                                               .
+   .                                                               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                   Figure 3: Format of LLS Data Block
+
+   The Checksum field contains the standard IP checksum for the entire
+   contents of the LLS block.  Before computing the checksum, the
+   checksum field is set to 0.  If the checksum is incorrect, the OSPF
+   packet MUST be processed, but the LLS block MUST be discarded.
+
+
+
+Zinin, et al.               Standards Track                     [Page 4]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+   The 16-bit LLS Data Length field contains the length (in 32-bit
+   words) of the LLS block including the header and payload.
+
+   Note that if the OSPF packet is cryptographically authenticated, the
+   LLS data block MUST also be cryptographically authenticated.  In this
+   case, the regular LLS checksum is not calculated, but is instead set
+   to 0.
+
+   The rest of the block contains a set of Type/Length/Value (TLV)
+   triplets as described in Section 2.3.  All TLVs MUST be 32-bit
+   aligned (with padding if necessary).
+
+2.3.  LLS TLVs
+
+   The contents of an LLS data block are constructed using TLVs.  See
+   Figure 4 for the TLV format.
+
+   The Type field contains the TLV ID, which is unique for each type of
+   TLV.  The Length field contains the length of the Value field (in
+   bytes).  The Value field is variable and contains arbitrary data.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |            Type               |           Length              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                             Value                             .
+   .                                                               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                      Figure 4: Format of LLS TLVs
+
+   Note that TLVs are always padded to a 32-bit boundary, but padding
+   bytes are not included in the TLV Length field (though they are
+   included in the LLS Data Length field in the LLS block header).
+   Unrecognized TLV types are ignored.
+
+2.4.  Extended Options and Flags TLV
+
+   This subsection describes a TLV called the Extended Options and Flags
+   (EOF) TLV.  The format of the EOF-TLV is shown in Figure 5.
+
+   Bits in the Value field do not have any semantics from the point of
+   view of the LLS mechanism.  Bits MAY be allocated to announce OSPF
+   link-local capabilities.  Bits MAY also be allocated to perform
+   boolean link-local signaling.
+
+
+
+Zinin, et al.               Standards Track                     [Page 5]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+   The length of the Value field in the EOF-TLV is 4 bytes.
+
+   The value of the Type field in the EOF-TLV is 1.  The EOF-TLV MUST
+   only appear once in the LLS data block.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |             1                 |            4                  |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                  Extended Options and Flags                   |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                        Figure 5: Format of the EOF-TLV
+
+   Currently, [OOB] and [RESTART] use bits in the Extended Options field
+   of the EOF-TLV.
+
+   The Extended Options and Flags bits are defined in Section 3.
+
+2.5.  Cryptographic Authentication TLV (OSPFv2 ONLY)
+
+   This document defines a special TLV that is used for cryptographic
+   authentication (CA-TLV) of the LLS data block.  This TLV MUST only be
+   included in the LLS block when cryptographic authentication is
+   enabled on the corresponding interface.  The message digest of the
+   LLS block MUST be calculated using the same key and authentication
+   algorithm as used for the OSPFv2 packet.  The cryptographic sequence
+   number is included in the TLV and MUST be the same as the one in the
+   OSPFv2 authentication data for the LLS block to be considered
+   authentic.
+
+   The TLV is constructed as shown in Figure 6.
+
+   0                   1                   2                   3
+   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |              2                |         AuthLen               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                         Sequence Number                       |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   .                                                               .
+   .                           AuthData                            .
+   .                                                               .
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+         Figure 6: Format of Cryptographic Authentication TLV
+
+
+
+Zinin, et al.               Standards Track                     [Page 6]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+   The value of the Type field for the CA-TLV is 2.
+
+   The Length field in the header contains the length of the data
+   portion of the TLV including 4 bytes for Sequence Number and the
+   length of the message digest block for the whole LLS block in bytes.
+
+   The Sequence Number field contains the cryptographic sequence number
+   that is used to prevent simple replay attacks.  For the LLS block to
+   be considered authentic, the Sequence Number in the CA-TLV MUST match
+   the Sequence Number in the OSPFv2 packet header Authentication field
+   (which MUST be present).  In the event of Sequence Number mismatch or
+   Authentication failure, the whole LLS block MUST be ignored.
+
+   The CA-TLV MUST NOT appear more than once in the LLS block.  Also,
+   when present, this TLV MUST be the last TLV in the LLS block.  If it
+   appears more than once, only the first occurrence is processed and
+   any others MUST be ignored.
+
+   The AuthData field contains the message digest calculated for the LLS
+   data block up to the CA-TLV AuthData field (i.e., excludes the CA-TLV
+   AuthData).
+
+   The CA-TLV is not applicable to OSPFv3 and it MUST NOT be added to
+   any OSPFv3 packet.  If found on reception, this TLV MUST be ignored.
+
+2.6.  Private TLVs
+
+   LLS type values in the range of 32768-65536 are reserved for private
+   use.  The first four octets of the Value field MUST be the private
+   enterprise code [ENTNUM].  This allows multiple vendor private
+   extensions to coexist in a network.
+
+3.  IANA Considerations
+
+   This document uses the registry that was originally created in
+   [RFC4813].  IANA updated the following registry to point to this
+   document instead:
+
+   o  "Open Shortest Path First (OSPF) Link-Local Signalling (LLS) -
+      Type/Length/Value Identifiers (TLV)"
+
+   IANA allocated L-bit in the "OSPFv2 Options Registry" and "OSPFv3
+   Options Registry" as per Section 2.1.
+
+   LLS TLV types are maintained by the IANA.  Extensions to OSPF that
+   require a new LLS TLV type MUST be reviewed by a Designated Expert
+   from the routing area.
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 7]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+   The criteria for allocating LLS TLVs are:
+
+   o  LLS should not be used for information that would be better suited
+      to be advertised in a link-local link state advertisement (LSA).
+
+   o  LLS should be confined to signaling between direct neighbors.
+
+   o  Discretion should be used in the volume of information signaled
+      using LLS due to the obvious MTU and performance implications.
+
+   Following the policies outlined in [IANA], LLS type values in the
+   range of 0-32767 are allocated through an IETF Review and LLS type
+   values in the range of 32768-65535 are reserved for private use.
+
+   This document assigns the following LLS TLV types in OSPFv2/OSPFv3.
+
+   TLV Type    Name                                      Reference
+   0           Reserved
+   1           Extended Options and Flags                [RFC5613]
+   2           Cryptographic Authentication+             [RFC5613]
+   3-32767     Reserved for assignment by the IANA
+   32768-65535 Private Use
+
+   + Cryptographic Authentication TLV is only defined for OSPFv2
+
+   IANA renamed the sub-registry from "LLS Type 1 Extended Options" to
+   "LLS Type 1 Extended Options and Flags".
+
+   This document also assigns the following bits in the EOF-TLV outlined
+   in Section 2.5:
+
+   Bit                     Name                        Reference
+   0x00000001              LSDB Resynchronization (LR) [RFC4811]
+   0x00000002              Restart Signal (RS-bit)     [RFC4812]
+
+   Future allocation of Extended Options and Flags bits MUST be reviewed
+   by a Designated Expert from the routing area.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 8]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+4.  Compatibility Issues
+
+   The modifications to OSPF packet formats are compatible with standard
+   OSPF since OSPF routers not supporting LLS will ignore the LLS data
+   block after the OSPF packet or cryptographic message digest.  As of
+   this writing, there are implementations deployed with [RFC4813]-
+   compliant software.  Routers not implementing [RFC4813] ignore the
+   LLS data at the end of the OSPF packet.
+
+   Careful consideration should be given to carrying additional LLS
+   data, as it may affect the OSPF adjacency bring-up time due to
+   additional propagation delay and/or processing time.
+
+5.  Security Considerations
+
+   Security considerations inherited from OSPFv2 are described in
+   [OSPFV2].  This technique provides the same level of security as the
+   basic OSPFv2 protocol by allowing LLS data to be authenticated using
+   the same cryptographic authentication that OSPFv2 uses (see
+   Section 2.5 for more details).
+
+   Security considerations inherited from OSPFv3 are described in
+   [OSPFV3] and [OSPFV3AUTH].  OSPFv3 utilizes IPsec for authentication
+   and encryption.  With IPsec, the AH (Authentication Header), ESP
+   (Encapsulating Security Payload), or both are applied to the entire
+   OSPFv3 payload including the LLS block.
+
+6.  References
+
+6.1.  Normative References
+
+   [IANA]        Narten, T. and H. Alvestrand, "Guidelines for Writing
+                 an IANA Considerations Section in RFCs", BCP 26,
+                 RFC 5226, May 2008.
+
+   [KEY]         Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [OSPFV3AUTH]  Gupta, M. and N. Melam, "Authentication/Confidentiality
+                 for OSPFv3", RFC 4552, June 2006.
+
+
+
+
+
+Zinin, et al.               Standards Track                     [Page 9]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+6.2.  Informative References
+
+   [ENTNUM]      IANA, "PRIVATE ENTERPRISE NUMBERS",
+                 http://www.iana.org.
+
+   [OOB]         Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band
+                 Link State Database (LSDB) Resynchronization",
+                 RFC 4811, March 2007.
+
+   [RESTART]     Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart
+                 Signaling", RFC 4812, March 2007.
+
+   [RFC4813]     Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
+                 Zinin, "OSPF Link-Local Signaling", RFC 4813,
+                 March 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                    [Page 10]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+Appendix A.  Acknowledgements
+
+   The authors would like to acknowledge Russ White, Acee Lindem, and
+   Manral Vishwas for their review of this document.
+
+Appendix B.  Changes from RFC 4813
+
+   This section describes the substantive change from [RFC4813].
+
+   o  Added OSPFv3 support
+
+   o  Private TLVs MUST use private enterprise code
+
+   o  Clarified requirement levels at several places
+
+   o  Changed from Experimental to Standards Track
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                    [Page 11]
+
+RFC 5613               OSPF Link-Local Signaling             August 2009
+
+
+Authors' Addresses
+
+   Alex Zinin
+   Alcatel-Lucent
+   Singapore
+
+   EMail: alex.zinin@alcatel-lucent.com
+
+
+   Abhay Roy
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: akr@cisco.com
+
+
+   Liem Nguyen
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: lhnguyen@cisco.com
+
+
+   Barry Friedman
+   Google, Inc.
+   1600 Amphitheatre Parkway
+   Mountain View, CA  94043
+   USA
+
+   EMail: barryf@google.com
+
+
+   Derek Yeung
+   Cisco Systems
+   170 West Tasman Drive
+   San Jose, CA  95134
+   USA
+
+   EMail: myeung@cisco.com
+
+
+
+
+
+
+
+
+Zinin, et al.               Standards Track                    [Page 12]
+