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/