< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/