draft-ietf-6man-maxra-01.txt		draft-ietf-6man-maxra-02.txt
	IPv6 Maintenance S. Krishnan		IPv6 Maintenance S. Krishnan
	Internet-Draft Ericsson		Internet-Draft Ericsson
	Updates: 4861 (if approved) J. Korhonen		Updates: 4861 (if approved) J. Korhonen
	Intended status: Standards Track Broadcom		Intended status: Standards Track Broadcom
	Expires: January 9, 2017 S. Chakrabarti		Expires: September 10, 2017 S. Chakrabarti
	Ericsson		Ericsson
	E. Nordmark		E. Nordmark
	Arista Networks		Arista Networks
	A. Yourtchenko		A. Yourtchenko
	cisco		cisco
	July 8, 2016		March 9, 2017
	Support for adjustable maximum router lifetimes per-link		Support for adjustable maximum router lifetimes per-link
	draft-ietf-6man-maxra-01		draft-ietf-6man-maxra-02
	Abstract		Abstract
	The neighbor discovery protocol specifies the maximum time allowed		The neighbor discovery protocol specifies the maximum time allowed
	between sending unsolicited multicast Router Advertisements from a		between sending unsolicited multicast Router Advertisements from a
	router interface as well as the maximum router lifetime. It also		router interface as well as the maximum router lifetime. It also
	allows the limits to be overridden by link-layer specific documents.		allows the limits to be overridden by link-layer specific documents.
	This document allows for overriding these values on a per-link basis.		This document allows for overriding these values on a per-link basis.
	Status of This Memo		Status of This Memo
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 9, 2017.		This Internet-Draft will expire on September 10, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2017 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 8 ¶
	optimize accordingly to its use case.		optimize accordingly to its use case.
	Also AdvDefaultLifetime MUST be set to a value greater than or equal		Also AdvDefaultLifetime MUST be set to a value greater than or equal
	to the selected MaxRtrAdvInterval. Otherwise, a router lifetime is		to the selected MaxRtrAdvInterval. Otherwise, a router lifetime is
	guaranteed to expire before the new Router Advertisement has a chance		guaranteed to expire before the new Router Advertisement has a chance
	to be sent, thereby creating an outage.		to be sent, thereby creating an outage.
	4. Updates to RFC4861		4. Updates to RFC4861
	This document updates Section 6.2.1. of [RFC4861] to update the		This document updates Section 6.2.1. of [RFC4861] to update the
	following router configuration variables. MaxRtrAdvInterval MUST be		following router configuration variables.
	no greater than 65535. AdvDefaultLifetime MUST be between
	MaxRtrAdvInterval and 65535.		MaxRtrAdvInterval MUST be no greater than 65535. AdvDefaultLifetime
			MUST either be zero (the router is not to be used as a default
			router) or be a value between MaxRtrAdvInterval and 65535.
	5. Host Behavior		5. Host Behavior
	Legacy hosts on a link with updated routers may have issues with a		Legacy hosts on a link with updated routers may have issues with a
	Router Lifetime of more than 9000 seconds. In the few		Router Lifetime of more than 9000 seconds. In the few
	implementations we have tested with general purpose operating		implementations we have tested with general purpose operating
	systems, there does not seem to be any issues with setting this field		systems, there does not seem to be any issues with setting this field
	to more than 9000, but there might be implementations that		to more than 9000, but there might be implementations that
	incorrectly (since RFC4861 requires receivers to handle any value)		incorrectly (since RFC4861 requires receivers to handle any value)
	reject such RAs.		reject such RAs.
	6. Security Considerations		6. Security Considerations
	On a link where router advertisements are few and far between, the		On a link where router advertisements are few and far between, the
	attack window for a rogue router to send an unsolicited RA is greatly		detrimental effects of a rogue router that sends an unsolicited RA
	increased. These attacks can easily be prevented by using SeND		are greatly increased. These rogue RAs can be prevented by using
	[RFC3971]		approaches like RA-Guard [RFC6105] and SeND [RFC3971]
	7. IANA Considerations		7. IANA Considerations
	This document does not require any IANA action.		This document does not require any IANA action.
	8. Acknowledgements		8. Acknowledgements
	The authors would like to thank the members of the 6man efficient ND		The authors would like to thank the members of the 6man efficient ND
	design team for their comments that led to the creation of this		design team for their comments that led to the creation of this
	draft. The authors would also like to thank Lorenzo Colitti, Erik		draft. The authors would also like to thank Lorenzo Colitti, Erik
	Kline, Jeena Rachel John and Brian Carpenter for their comments and		Kline, Jeena Rachel John, Brian Carpenter, Tim Chown and Fernando
	suggestions that improved this document.		Gont for their comments and suggestions that improved this document.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
	"SEcure Neighbor Discovery (SEND)", RFC 3971,
	DOI 10.17487/RFC3971, March 2005,
	<http://www.rfc-editor.org/info/rfc3971>.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	DOI 10.17487/RFC4861, September 2007,		DOI 10.17487/RFC4861, September 2007,
	<http://www.rfc-editor.org/info/rfc4861>.		<http://www.rfc-editor.org/info/rfc4861>.
	9.2. Informative References		9.2. Informative References
			[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
			"SEcure Neighbor Discovery (SEND)", RFC 3971,
			DOI 10.17487/RFC3971, March 2005,
			<http://www.rfc-editor.org/info/rfc3971>.
			[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
			Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
			DOI 10.17487/RFC6105, February 2011,
			<http://www.rfc-editor.org/info/rfc6105>.
	[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,		[RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen,
	T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation		T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
	Partnership Project (3GPP) Evolved Packet System (EPS)",		Partnership Project (3GPP) Evolved Packet System (EPS)",
	RFC 6459, DOI 10.17487/RFC6459, January 2012,		RFC 6459, DOI 10.17487/RFC6459, January 2012,
	<http://www.rfc-editor.org/info/rfc6459>.		<http://www.rfc-editor.org/info/rfc6459>.
	[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.		[RFC7066] Korhonen, J., Ed., Arkko, J., Ed., Savolainen, T., and S.
	Krishnan, "IPv6 for Third Generation Partnership Project		Krishnan, "IPv6 for Third Generation Partnership Project
	(3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,		(3GPP) Cellular Hosts", RFC 7066, DOI 10.17487/RFC7066,
	November 2013, <http://www.rfc-editor.org/info/rfc7066>.		November 2013, <http://www.rfc-editor.org/info/rfc7066>.
End of changes. 10 change blocks.
	18 lines changed or deleted		25 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/