draft-ietf-6man-rs-refresh-01.txt   draft-ietf-6man-rs-refresh-02.txt 
6man WG E. Nordmark 6man WG E. Nordmark
Internet-Draft Arista Networks Internet-Draft Arista Networks
Updates: 4861,6059 (if approved) A. Yourtchenko Updates: 4861,6059 (if approved) A. Yourtchenko
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: September 2, 2016 S. Krishnan Expires: May 4, 2017 S. Krishnan
Ericsson Ericsson
Mar 2016 October 31, 2016
IPv6 Neighbor Discovery Optional RS/RA Refresh IPv6 Neighbor Discovery Optional RS/RA Refresh
draft-ietf-6man-rs-refresh-01 draft-ietf-6man-rs-refresh-02
Abstract Abstract
IPv6 Neighbor Discovery relies on periodic multicast Router IPv6 Neighbor Discovery relies on periodic multicast Router
Advertisement messages to update timer values and to distribute new Advertisement messages to update timer values and to distribute new
information (such as new prefixes) to hosts. On some links the use information (such as new prefixes) to hosts. On some links the use
of periodic multicast messages to all host becomes expensive, and in of periodic multicast messages to all host becomes expensive, and in
some cases it results in hosts waking up frequently. Many some cases it results in hosts waking up frequently. Many
implementations of RFC 4861 also use multicast for solicited Router implementations of RFC 4861 also use multicast for solicited Router
Advertisement messages, even though that behavior is optional. Advertisement messages, even though that behavior is optional.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
routers where instead of periodic multicast Router Advertisements the routers where instead of periodic multicast Router Advertisements the
hosts are instructed (by the routers) to use Router Solicitations to hosts are instructed (by the routers) to use Router Solicitations to
request refreshed Router Advertisements. This mechanism is enabled request refreshed Router Advertisements. This mechanism is enabled
by configuring the router to include a new option in the Router by configuring the router to include a new option in the Router
Advertisement in order to allow the network administrator to choose Advertisement in order to allow the network administrator to choose
host behavior based on whether periodic multicast are more efficient host behavior based on whether periodic multicast are more efficient
on their link or not. The routers can also tell whether the hosts on their link or not. The routers can also tell whether the hosts
are capable of the new behavior through a new flag in the Router are capable of the new behavior through a new flag in the Router
Solicitations. Solicitations.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). 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 September 2, 2016. This Internet-Draft will expire on May 4, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Goals and Requirements . . . . . . . . . . . . . . . . . . . . 5 2. Goals and Requirements . . . . . . . . . . . . . . . . . . . 4
3. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Definition Of Terms . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. New Neighbor Discovery Flags and Options . . . . . . . . . . . 6 5. New Neighbor Discovery Flags and Options . . . . . . . . . . 5
5.1. Introducing a Router Solicitation Flag . . . . . . . . . . 6 5.1. Introducing a Router Solicitation Flag . . . . . . . . . 5
5.2. Refresh Time option . . . . . . . . . . . . . . . . . . . 7 5.2. Refresh Time option . . . . . . . . . . . . . . . . . . . 6
6. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 7 6. Conceptual Data Structures . . . . . . . . . . . . . . . . . 6
7. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Host Behavior . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 9 7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . 8
7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Router and/or Interface Initialization . . . . . . . . . . 10 8.1. Router and/or Interface Initialization . . . . . . . . . 9
8.2. Periodic Multicast RA for unmodified hosts . . . . . . . . 10 8.2. Periodic Multicast RA for unmodified hosts . . . . . . . 9
8.3. Unsolicited RAs to share new information . . . . . . . . . 10 8.3. Unsolicited RAs to share new information . . . . . . . . 9
9. Router Advertisement Consistency . . . . . . . . . . . . . . . 11 9. Router Advertisement Consistency . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
14.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . 11
14.2. Informative References . . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
IPv6 Neighbor Discovery [RFC4861] was defined at a time when local IPv6 Neighbor Discovery [RFC4861] was defined at a time when local
area networks had different properties than today. A common link was area networks had different properties than today. A common link was
the yellow-coax shared wire Ethernet, where a link-layer multicast the yellow-coax shared wire Ethernet, where a link-layer multicast
and unicast worked the same - send the packet on the wire and the and unicast worked the same - send the packet on the wire and the
interested receivers will pick it up. Thus the network cost interested receivers will pick it up. Thus the network cost
(ignoring any processing cost on the receivers that might not (ignoring any processing cost on the receivers that might not
completely filter out Ethernet multicast addresses that they did not completely filter out Ethernet multicast addresses that they did not
skipping to change at page 12, line 31 skipping to change at page 11, line 28
o Clarified the updated DNA behavior. o Clarified the updated DNA behavior.
o Editorial fixes. o Editorial fixes.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-6man-resilient-rs] [I-D.ietf-6man-resilient-rs]
Krishnan, S., Anipko, D., and D. Thaler, "Packet loss Krishnan, S., Anipko, D., and D. Thaler, "Packet loss
resiliency for Router Solicitations", resiliency for Router Solicitations", draft-ietf-6man-
draft-ietf-6man-resilient-rs-06 (work in progress), resilient-rs-06 (work in progress), April 2015.
April 2015.
[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, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[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>.
14.2. Informative References 14.2. Informative References
[I-D.garneij-6man-nd-m2m-issues] [I-D.garneij-6man-nd-m2m-issues]
Garneij, F., Chakrabarti, S., and S. Krishnan, "Impact of Garneij, F., Chakrabarti, S., and S. Krishnan, "Impact of
IPv6 Neighbor Discovery on Cellular M2M Networks", IPv6 Neighbor Discovery on Cellular M2M Networks", draft-
draft-garneij-6man-nd-m2m-issues-00 (work in progress), garneij-6man-nd-m2m-issues-00 (work in progress), July
July 2014. 2014.
[I-D.vyncke-6man-mcast-not-efficient] [I-D.vyncke-6man-mcast-not-efficient]
Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A. Vyncke, E., Thubert, P., Levy-Abegnoli, E., and A.
Yourtchenko, "Why Network-Layer Multicast is Not Always Yourtchenko, "Why Network-Layer Multicast is Not Always
Efficient At Datalink Layer", Efficient At Datalink Layer", draft-vyncke-6man-mcast-not-
draft-vyncke-6man-mcast-not-efficient-01 (work in efficient-01 (work in progress), February 2014.
progress), February 2014.
[RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", Neighbor Discovery (ND) Trust Models and Threats",
RFC 3756, DOI 10.17487/RFC3756, May 2004, RFC 3756, DOI 10.17487/RFC3756, May 2004,
<http://www.rfc-editor.org/info/rfc3756>. <http://www.rfc-editor.org/info/rfc3756>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971, "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005, DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>. <http://www.rfc-editor.org/info/rfc3971>.
 End of changes. 10 change blocks. 
40 lines changed or deleted 38 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/