draft-ietf-6man-rs-refresh-00.txt   draft-ietf-6man-rs-refresh-01.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: November 20, 2015 S. Krishnan Expires: September 2, 2016 S. Krishnan
Ericsson Ericsson
May 19, 2015 Mar 2016
IPv6 Neighbor Discovery Optional RS/RA Refresh IPv6 Neighbor Discovery Optional RS/RA Refresh
draft-ietf-6man-rs-refresh-00 draft-ietf-6man-rs-refresh-01
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 2, line 4 skipping to change at page 2, line 4
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 November 20, 2015. This Internet-Draft will expire on September 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 3, line 26 skipping to change at page 3, line 26
7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 9 7.1. Sleep and Wakeup . . . . . . . . . . . . . . . . . . . . . 9
7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Movement . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 9 8. Router Behavior . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Router and/or Interface Initialization . . . . . . . . . . 10 8.1. Router and/or Interface Initialization . . . . . . . . . . 10
8.2. Periodic Multicast RA for unmodified hosts . . . . . . . . 10 8.2. Periodic Multicast RA for unmodified hosts . . . . . . . . 10
8.3. Unsolicited RAs to share new information . . . . . . . . . 10 8.3. Unsolicited RAs to share new information . . . . . . . . . 10
9. Router Advertisement Consistency . . . . . . . . . . . . . . . 11 9. Router Advertisement Consistency . . . . . . . . . . . . . . . 11
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
15.1. Normative References . . . . . . . . . . . . . . . . . . . 12 14.2. Informative References . . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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
skipping to change at page 11, line 42 skipping to change at page 11, line 42
This document needs a new Neighbor Discovery option type for the RTO. This document needs a new Neighbor Discovery option type for the RTO.
12. Acknowledgements 12. Acknowledgements
The original idea came up in a discussion with Suresh Krishnan. The original idea came up in a discussion with Suresh Krishnan.
Comments from Samita Chakrabarti, Lorenzo Colitti, and Erik Kline Comments from Samita Chakrabarti, Lorenzo Colitti, and Erik Kline
have helped improve the document. have helped improve the document.
This document has been discussed in the efficient-nd design team. This document has been discussed in the efficient-nd design team.
13. Open Issues 13. Change Log
Should we remove the notion of not sending any periodic RAs and
the associated detection of "legacy" hosts in Section 8.2? Would
periodic RAs every 30 minutes place too much load on the network
even if the hosts on a sleep schedule do not wake up?
Would it be worth-while to try to remove unchanged information
from the refreshed RAs? If so it could be done by including some
epoch number in the RS and RA, and if the RS contains the current
epoch then the RA would not need to include any options except the
epoch number indicating that none of the options are the same as
before. This is difficult with multicast RS refresh...
14. Change Log Changes since the draft-nordmark-6man-rs-refresh-00 version of the
draft:
Changes since draft-nordmark-6man-rs-refresh-01 of the draft: o Removed any suggestion that periodic RAs would not be needed. The
remain required.
o Made Refresh Time zero be reserved and RTOs with this value o Made Refresh Time zero be reserved and RTOs with this value
ignored by the receiver. ignored by the receiver.
o Removed notion that all-ones refresh time means infinite lifetime. o Removed notion that all-ones refresh time means infinite lifetime.
It now means 65535 seconds. It now means 65535 seconds.
o Changed default to be multicast RS refresh, with the option to o Changed default to be multicast RS refresh, with the option to
specify unicast in the RTO. This enables discovering new routers specify unicast in the RTO. This enables discovering new routers
on the link. on the link.
o Clarified the normative behavior for hosts that sleep on a o Clarified the normative behavior for hosts that sleep on a
schedule. schedule.
o Clarified the updated DNA behavior. o Clarified the updated DNA behavior.
o Editorial fixes. o Editorial fixes.
15. References 14. References
15.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-resilient-rs-06 (work in progress), draft-ietf-6man-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, March 1997. Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
RFC2119, March 1997,
<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, December 1998. (IPv6) Specification", RFC 2460, DOI 10.17487/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,
September 2007. DOI 10.17487/RFC4861, September 2007,
<http://www.rfc-editor.org/info/rfc4861>.
15.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-garneij-6man-nd-m2m-issues-00 (work in progress), draft-garneij-6man-nd-m2m-issues-00 (work in progress),
July 2014. July 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-efficient-01 (work in draft-vyncke-6man-mcast-not-efficient-01 (work in
progress), February 2014. progress), February 2014.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Discovery (ND) Trust Models and Threats", RFC 3756, Neighbor Discovery (ND) Trust Models and Threats",
May 2004. RFC 3756, DOI 10.17487/RFC3756, May 2004,
<http://www.rfc-editor.org/info/rfc3756>.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
Neighbor Discovery (SEND)", RFC 3971, March 2005. "SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<http://www.rfc-editor.org/info/rfc3971>.
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for
Detecting Network Attachment in IPv6", RFC 6059, Detecting Network Attachment in IPv6", RFC 6059,
November 2010. DOI 10.17487/RFC6059, November 2010,
<http://www.rfc-editor.org/info/rfc6059>.
[SYNC] Floyd, S. and V. Jacobson, "The Synchronization of [SYNC] Floyd, S. and V. Jacobson, "The Synchronization of
Periodic Routing Messages", IEEE/ACM Transactions on Periodic Routing Messages", IEEE/ACM Transactions on
Networking , April 1994, Networking , April 1994,
<http://ee.lbl.gov/papers/sync_94.pdf>. <http://ee.lbl.gov/papers/sync_94.pdf>.
Authors' Addresses Authors' Addresses
Erik Nordmark Erik Nordmark
Arista Networks Arista Networks
 End of changes. 18 change blocks. 
37 lines changed or deleted 34 lines changed or added

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