diff options
Diffstat (limited to 'doc/rfc/rfc5613.txt')
| -rw-r--r-- | doc/rfc/rfc5613.txt | 675 |
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] + |