draft-ietf-ospf-lls-04.txt   draft-ietf-ospf-lls-05.txt 
Network Working Group A. Zinin Network Working Group A. Zinin
Internet-Draft Alcatel Internet-Draft Alcatel
Intended status: Standards Track A. Roy Intended status: Standards Track A. Roy
Expires: August 15, 2008 L. Nguyen Expires: October 22, 2008 L. Nguyen
Cisco Systems Cisco Systems
B. Friedman B. Friedman
Redback Networks Redback Networks
D. Young D. Young
February 12, 2008 Cisco Systems
April 20, 2008
OSPF Link-local Signaling OSPF Link-local Signaling
draft-ietf-ospf-lls-04.txt draft-ietf-ospf-lls-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 15, 2008. This Internet-Draft will expire on October 22, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
OSPF is a link-state intra-domain routing protocol. OSPF routers OSPF is a link-state intra-domain routing protocol. OSPF routers
exchange information on a link using packets that follow a well- exchange information on a link using packets that follow a well-
defined fixed format. The format is not flexible enough to enable defined fixed format. The format is not flexible enough to enable
skipping to change at page 2, line 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 4 2. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Options Field . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Options Field . . . . . . . . . . . . . . . . . . . . . . 5
2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 5 2.2. LLS Data Block . . . . . . . . . . . . . . . . . . . . . . 5
2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3. LLS TLVs . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4. Extended Options TLV . . . . . . . . . . . . . . . . . . . 6 2.4. Extended Options TLV . . . . . . . . . . . . . . . . . . . 6
2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7
2.6. Private and Experimental TLVs . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 10 4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 15
skipping to change at page 4, line 45 skipping to change at page 4, line 45
Figure 1: LLS Data Block in OSPFv2 and OSPFv3 Figure 1: LLS Data Block in OSPFv2 and OSPFv3
The LLS data block MAY be attached to OSPF Hello and DD packets. The The LLS data block MAY be attached to OSPF Hello and DD packets. The
data included in LLS block attached to a Hello packet MAY be used for data included in LLS block attached to a Hello packet MAY be used for
dynamic signaling since Hello packets may be sent at any time in dynamic signaling since Hello packets may be sent at any time in
time. However, delivery of LLS data in Hello packets is not time. However, delivery of LLS data in Hello packets is not
guaranteed. The data sent with DD packets is guaranteed to be guaranteed. The data sent with DD packets is guaranteed to be
delivered as part of the adjacency forming process. delivered as part of the adjacency forming process.
This document does not specify how the data transmitted by the LLS This document does not specify how the data transmitted by the LLS
mechanism should be interpreted by OSPF routers. The interface mechanism should be interpreted by OSPF routers. As routers that do
between the OSPF LLS component and its clients is implementation not understand LLS may receive these packets, changes made due to LLS
specific. block TLV's do not affect the basic routing when interacting with
non-LLS routers.
2.1. Options Field 2.1. Options Field
A new L bit (L stands for LLS) is introduced to OSPF Options field A new L bit (L stands for LLS) is introduced to OSPF Options field
(see Figure 2a/2b). Routers set the L bit in Hello and DD packets to (see Figure 2a/2b). Routers set the L bit in Hello and DD packets to
indicate that the packet contains LLS data block. In other words, indicate that the packet contains LLS data block. In other words,
LLS data block is only examined if the L bit is set. LLS data block is only examined if the L bit is set.
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+
| * | O | DC| L |N/P| MC| E | * | | * | O | DC| L |N/P| MC| E | * |
skipping to change at page 6, line 43 skipping to change at page 6, line 43
| | | |
. . . .
. Value . . Value .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of LLS TLVs Figure 4: Format of LLS TLVs
Note that TLVs are always padded to 32-bit boundary, but padding Note that TLVs are always padded to 32-bit boundary, but padding
bytes are not included in TLV Length field (though they are included bytes are not included in TLV Length field (though they are included
in the LLS Data Length field in the LLS block header). in the LLS Data Length field in the LLS block header). Unrecognized
TLV types are ignored.
2.4. Extended Options TLV 2.4. Extended Options TLV
This subsection describes a TLV called the Extended Options (EO) TLV. This subsection describes a TLV called the Extended Options (EO) TLV.
The format of EO-TLV is shown in Figure 5. The format of EO-TLV is shown in Figure 5.
Bits in the Value field do not have any semantics from the point of Bits in the Value field do not have any semantics from the point of
view of the LLS mechanism. This field MAY be used to announce some view of the LLS mechanism. This field MAY be used to announce some
OSPF capabilities that are link-specific. Also, other OSPF OSPF capabilities that are link-specific. Also, other OSPF
extensions MAY allocate bits in the bit vector to perform boolean extensions MAY allocate bits in the bit vector to perform boolean
skipping to change at page 7, line 32 skipping to change at page 7, line 33
Currently, [OOB] and [RESTART] use bits in the Extended Options field Currently, [OOB] and [RESTART] use bits in the Extended Options field
of the EO-TLV. of the EO-TLV.
The Extended Options bits are defined in Section 3. The Extended Options bits are defined in Section 3.
2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY)
This document defines a special TLV that is used for cryptographic This document defines a special TLV that is used for cryptographic
authentication (CA-TLV) of the LLS data block. This TLV MUST be authentication (CA-TLV) of the LLS data block. This TLV MUST be
included in the LLS block when the cryptographic (MD5) authentication included in the LLS block when the cryptographic authentication is
is enabled on the corresponding interface. The message digest of the enabled on the corresponding interface. The message digest of the
LLS block MUST be calculated using the same key and authentication LLS block MUST be calculated using the same key and authentication
algorithm as used for the OSPFv2 packet. The cryptographic sequence 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 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 OSPFv2 authentication data for the LLS block to be considered
authentic. authentic.
The TLV is constructed as shown in Figure 6. The TLV is constructed as shown in Figure 6.
0 1 2 3 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 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
skipping to change at page 8, line 24 skipping to change at page 8, line 24
. AuthData . . AuthData .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of Cryptographic Authentication TLV Figure 6: Format of Cryptographic Authentication TLV
The value of the Type field for the CA-TLV is 2. The value of the Type field for the CA-TLV is 2.
The Length field in the header contains the length of the data The Length field in the header contains the length of the data
portion of the TLV including 4 bytes for Sequence Number and the portion of the TLV including 4 bytes for Sequence Number and the
length of the message digest (MD5) block for the whole LLS block in length of the message digest block for the whole LLS block in bytes.
bytes (this will always be 16 bytes for MD5). Hence, the AuthLen
field will be 20 for MD5 cryptographic authentication.
The Sequence Number field contains the cryptographic sequence number The Sequence Number field contains the cryptographic sequence number
that is used to prevent simple replay attacks. For the LLS block to 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 be considered authentic, the Sequence Number in the CA-TLV MUST match
the Sequence Number in the OSPFv2 packet header Authentication field. the Sequence Number in the OSPFv2 packet header Authentication field.
In the event of Sequence Number mismatch or Authentication failure, In the event of Sequence Number mismatch or Authentication failure,
the whole LLS block MUST be ignored. the whole LLS block MUST be ignored.
The AuthData contains the message digest calculated for the LLS data The AuthData contains the message digest calculated for the LLS data
block. block.
The CA-TLV MUST only appear once in the the LLS block. Also, when The CA-TLV MUST only appear once in the the LLS block. Also, when
present, this TLV SHOULD be the last TLV in the LLS block. present, this TLV SHOULD be the last TLV in the LLS block.
2.6. Private and Experimental TLVs
LLS type values in the range of 32768-65536 are reserved for private
and experimental 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 3. IANA Considerations
LLS TLV types are maintained by the IANA. Extensions to OSPF which LLS TLV types are maintained by the IANA. Extensions to OSPF which
require a new LLS TLV type MUST be reviewed by an designated expert require a new LLS TLV type MUST be reviewed by an designated expert
from the routing area. from the routing area.
Following the policies outlined in [IANA], LLS type values in the Following the policies outlined in [IANA], LLS type values in the
range of 0-32767 are allocated through an IETF Consensus action and range of 0-32767 are allocated through an IETF Consensus action and
LLS type values in the range of 32768-65536 are reserved for private LLS type values in the range of 32768-65536 are reserved for private
and experimental use. and experimental use.
skipping to change at page 12, line 27 skipping to change at page 12, line 27
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", [OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999. RFC 2740, December 1999.
[OSPFV3AUTH] [OSPFV3AUTH]
Gupta, M. and N. Melam, "Authentication/Confidentiality Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
6.2. Informative References 6.2. Informative References
[ENTNUM] IANA,
"http://www.iana.org/assignments/enterprise-numbers".
[OOB] Zinin, A., Roy, A., and L. Nguyen, "OSPF Out-of-band LSDB [OOB] Zinin, A., Roy, A., and L. Nguyen, "OSPF Out-of-band LSDB
resynchronization", RFC 4811, March 2007. resynchronization", RFC 4811, March 2007.
[RESTART] Zinin, A., Roy, A., and L. Nguyen, "OSPF Restart [RESTART] Zinin, A., Roy, A., and L. Nguyen, "OSPF Restart
Signaling", RFC 4812, March 2007. Signaling", RFC 4812, March 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to acknowledge Russ White and Acee Lindem for The authors would like to acknowledge Russ White, Acee Lindem and
their thoughtful review of this document. Manral Vishwas for their review of this document.
Authors' Addresses Authors' Addresses
Alex Zinin Alex Zinin
Alcatel Alcatel
Sunnyvale Sunnyvale
USA USA
Email: zinin@psg.com Email: zinin@psg.com
skipping to change at page 14, line 39 skipping to change at page 14, line 39
Barry Friedman Barry Friedman
Redback Networks Redback Networks
100 Headquarters Drive 100 Headquarters Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: friedman@redback.com Email: friedman@redback.com
Derek Young Derek Young
Cisco Systems
170 West Tasman Drive
San Jose, CA 95134
USA
Email: derekmyeung@yahoo.com Email: myeung@cisco.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 14 change blocks. 
16 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/