draft-ietf-ospf-lls-07.txt   draft-ietf-ospf-lls-08.txt 
Network Working Group A. Zinin Network Working Group A. Zinin
Internet-Draft Alcatel Internet-Draft Alcatel
Obsoletes: 4813 (if approved) A. Roy Obsoletes: 4813 (if approved) A. Roy
Intended status: Standards Track L. Nguyen Intended status: Standards Track L. Nguyen
Expires: September 10, 2009 Cisco Systems Expires: December 10, 2009 Cisco Systems
B. Friedman B. Friedman
Redback Networks Redback Networks
D. Yeung D. Yeung
Cisco Systems Cisco Systems
March 9, 2009 June 8, 2009
OSPF Link-local Signaling OSPF Link-local Signaling
draft-ietf-ospf-lls-07.txt draft-ietf-ospf-lls-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 10, 2009. This Internet-Draft will expire on December 10, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 28 skipping to change at page 2, line 28
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. L-bit in Options Field . . . . . . . . . . . . . . . . . . 5 2.1. L-bit in 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 and Flags TLV . . . . . . . . . . . . . . 6 2.4. Extended Options and Flags TLV . . . . . . . . . . . . . . 6
2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7 2.5. Cryptographic Authentication TLV (OSPFv2 ONLY) . . . . . . 7
2.6. Private TLVs . . . . . . . . . . . . . . . . . . . . . . . 8 2.6. Private TLVs . . . . . . . . . . . . . . . . . . . . . . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 10 4. Compatibility Issues . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 13
6.2. Informative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Changes from RFC 4813 . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3 This document describes an extension to OSPFv2 [OSPFV2] and OSPFv3
[OSPFV3] allowing additional information to be exchanged between [OSPFV3] allowing additional information to be exchanged between
routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed routers on the same link. OSPFv2 and OSPFv3 packet formats are fixed
and do not allow for extension. This document proposes appending an and do not allow for extension. This document proposes appending an
optional data block composed of Type/Length/Value (TLV) triplets to optional data block composed of Type/Length/Value (TLV) triplets to
existing OSPFv2 and OSPFv3 packets to carry this additional existing OSPFv2 and OSPFv3 packets to carry this additional
information. Throughout this document, OSPF will be used when the information. Throughout this document, OSPF will be used when the
skipping to change at page 8, line 33 skipping to change at page 8, line 33
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 block for the whole LLS block in bytes. length of the message digest block for the whole LLS block in bytes.
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
(which MUST be present). In the event of Sequence Number mismatch or (which MUST be present). In the event of Sequence Number mismatch or
Authentication failure, the whole LLS block MUST be ignored. Authentication failure, the whole LLS block MUST be ignored.
The AuthData contains the message digest calculated for the LLS data
block.
The CA-TLV MUST NOT appear more than once in the LLS block. Also, 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 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 appears more than once, only the first occurrence is processed and
any others MUST be ignored. any others MUST be ignored.
The AuthData contains the message digest calculated for the LLS data
block up to CA-TLV (i.e. exludes CA-TLV data).
The CA-TLV is not applicable to OSPFv3 and it MUST NOT be added to 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. any OSPFv3 packet. If found on reception, this TLV MUST be ignored.
2.6. Private TLVs 2.6. Private TLVs
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
use. The first four octets of the Value field MUST be the private use. The first four octets of the Value field MUST be the private
enterprise code [ENTNUM]. This allows multiple vendor private enterprise code [ENTNUM]. This allows multiple vendor private
extensions to coexist in a network. extensions to coexist in a network.
3. IANA Considerations 3. IANA Considerations
This document uses the registry that was originally created in
[RFC4813]. IANA is requested to update 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 is requested to allocate L-bit in "OSPFv2 Options Registry" and IANA is requested to allocate L-bit in "OSPFv2 Options Registry" and
"OSPFv3 Options Registry" as per Section 2.1. "OSPFv3 Options Registry" as per Section 2.1.
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.
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 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 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 Review and LLS type
LLS type values in the range of 32768-65536 are reserved for private values in the range of 32768-65536 are reserved for private use.
use.
This document assigns the following LLS TLV types in OSPFv2/OSPFv3. This document assigns the following LLS TLV types in OSPFv2/OSPFv3.
TLV Type Name Reference TLV Type Name Reference
0 Reserved 0 Reserved
1 Extended Options and Flags [RFCNNNN]* 1 Extended Options and Flags [RFCNNNN]*
2 Cryptographic Authentication+ [RFCNNNN]* 2 Cryptographic Authentication+ [RFCNNNN]*
3-32767 Reserved for assignment by the IANA 3-32767 Reserved for assignment by the IANA
32768-65535 Private Use 32768-65535 Private Use
*[RFCNNNN] refers to the RFC number-to-be for this document. *[RFCNNNN] refers to the RFC number-to-be for this document.
+ Cryptographic Authentication TLV is only defined for OSPFv2 + Cryptographic Authentication TLV is only defined for OSPFv2
IANA is requested to rename the sub-registry "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 This document also assigns the following bits in the EOF-TLV outlined
in Section 2.5: in Section 2.5:
Bit Name Reference Bit Name Reference
0x00000001 LSDB Resynchronization (LR) [OOB] 0x00000001 LSDB Resynchronization (LR) [OOB]
0x00000002 Restart Signal (RS-bit) [RESTART] 0x00000002 Restart Signal (RS-bit) [RESTART]
Other Extended Options and Flags bits will be allocated through an Future allocation of Extended Options and Flags bits MUST be reviewed
IETF consensus action. by an Designated Expert from the routing area.
4. Compatibility Issues 4. Compatibility Issues
The modifications to OSPF packet formats are compatible with standard The modifications to OSPF packet formats are compatible with standard
OSPF since OSPF routers not supporting LLS will ignore the LLS data OSPF since OSPF routers not supporting LLS will ignore the LLS data
block after the OSPF packet or cryptographic message digest. As of block after the OSPF packet or cryptographic message digest. As of
this writing, there are implementations deployed with RFC4813 this writing, there are implementations deployed with [RFC4813]
compliant software. compliant software. Routers not implementing [RFC4813] ignore the
LLS data at the end of OSPF packet.
Careful consideration should be given to carrying additional LLS Careful consideration should be given to carrying additional LLS
data, as it may affect the OSPF adjacency bring-up time due to data, as it may affect the OSPF adjacency bring-up time due to
additional propagation delay and/or processing time." additional propagation delay and/or processing time.
5. Security Considerations 5. Security Considerations
Security Considerations inherited from OSPFv2 are described in Security Considerations inherited from OSPFv2 are described in
[OSPFV2]. This technique provides the same level of security as the [OSPFV2]. This technique provides the same level of security as the
basic OSPFv2 protocol by allowing LLS data to be authenticated using basic OSPFv2 protocol by allowing LLS data to be authenticated using
the same cryptographic authentication that OSPFv2 uses (see the same cryptographic authentication that OSPFv2 uses (see
Section 2.5 for more details). Section 2.5 for more details).
Security considerations inherited from OSPFv3 are described in Security considerations inherited from OSPFv3 are described in
skipping to change at page 13, line 5 skipping to change at page 13, line 35
[ENTNUM] IANA, [ENTNUM] IANA,
"http://www.iana.org/assignments/enterprise-numbers". "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.
[RFC4813] Friedman, B., Nguyen, L., Roy, A., Yeung, D., and A.
Zinin, "OSPF Link-Local Signaling", RFC 4813, March 2007.
Appendix A. Acknowledgements Appendix A. Acknowledgements
The authors would like to acknowledge Russ White, Acee Lindem and The authors would like to acknowledge Russ White, Acee Lindem and
Manral Vishwas for their review of this document. 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
Authors' Addresses Authors' Addresses
Alex Zinin Alex Zinin
Alcatel Alcatel
Sunnyvale Sunnyvale
USA USA
Email: zinin@psg.com Email: zinin@psg.com
Abhay Roy Abhay Roy
 End of changes. 17 change blocks. 
23 lines changed or deleted 59 lines changed or added

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