draft-ietf-v6ops-v6nd-problems-01.txt   draft-ietf-v6ops-v6nd-problems-02.txt 
v6ops I. Gashinsky v6ops I. Gashinsky
Internet-Draft Yahoo! Internet-Draft Yahoo!
Intended status: Informational J. Jaeggli Intended status: Informational J. Jaeggli
Expires: June 6, 2012 Zynga Expires: July 11, 2012 Zynga
W. Kumari W. Kumari
Google Google Inc
December 4, 2011 January 8, 2012
Operational Neighbor Discovery Problems Operational Neighbor Discovery Problems
draft-ietf-v6ops-v6nd-problems-01 draft-ietf-v6ops-v6nd-problems-02
Abstract Abstract
In IPv4, subnets are generally small, made just large enough to cover In IPv4, subnets are generally small, made just large enough to cover
the actual number of machines on the subnet. In contrast, the the actual number of machines on the subnet. In contrast, the
default IPv6 subnet size is a /64, a number so large it covers default IPv6 subnet size is a /64, a number so large it covers
trillions of addresses, the overwhelming number of which will be trillions of addresses, the overwhelming number of which will be
unassigned. Consequently, simplistic implementations of Neighbor unassigned. Consequently, simplistic implementations of Neighbor
Discovery can be vulnerable to deliberate or accidental denial of Discovery can be vulnerable to deliberate or accidental denial of
service, whereby they attempt to perform address resolution for large service, whereby they attempt to perform address resolution for large
numbers of unassigned addresses. Such denial of attacks can be numbers of unassigned addresses. Such denial of attacks can be
launched intentionally (by an attacker), or result from legitimate launched intentionally (by an attacker), or result from legitimate
operational tools or accident conditions. As a result of these operational tools or accident conditions. As a result of these
vulnerabilities, new devices may not be able to "join" a network, it vulnerabilities, new devices may not be able to "join" a network, it
may be impossible to establish new IPv6 flows, and existing ipv6 may be impossible to establish new IPv6 flows, and existing IPv6
transported flows may be interrupted. transported flows may be interrupted.
This document describes the potential for DOS in detail and suggests This document describes the potential for DOS in detail and suggests
possible implementation improvements as well as operational possible implementation improvements as well as operational
mitigation techniques that can in some cases be used to protect mitigation techniques that can in some cases be used to protect
against or at least aleviate the impact of such attacks. against or at least alleviate the impact of such attacks.
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 June 6, 2012. This Internet-Draft will expire on July 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . 7 5. Neighbor Discovery Overview . . . . . . . . . . . . . . . . . 7
6. Operational Mitigation Options . . . . . . . . . . . . . . . . 7 6. Operational Mitigation Options . . . . . . . . . . . . . . . . 8
6.1. Filtering of unused address space. . . . . . . . . . . . . 8 6.1. Filtering of unused address space. . . . . . . . . . . . . 8
6.2. Minimal Subnet Sizing. . . . . . . . . . . . . . . . . . . 8 6.2. Minimal Subnet Sizing. . . . . . . . . . . . . . . . . . . 8
6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8 6.3. Routing Mitigation. . . . . . . . . . . . . . . . . . . . 8
6.4. Tuning of the NDP Queue Rate Limit. . . . . . . . . . . . 9 6.4. Tuning of the NDP Queue Rate Limit. . . . . . . . . . . . 9
7. Recommendations for Implementors. . . . . . . . . . . . . . . 9 7. Recommendations for Implementors. . . . . . . . . . . . . . . 9
7.1. Prioritize NDP Activities . . . . . . . . . . . . . . . . 10 7.1. Prioritize NDP Activities . . . . . . . . . . . . . . . . 10
7.2. Queue Tuning. . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Queue Tuning. . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . . 12 11.1. Normative References . . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . . 12 11.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Text goes here. . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document describes implementation issues with IPv6's Neighbor This document describes implementation issues with IPv6's Neighbor
Discovery protocol that can result in vulnerabilities when a network Discovery protocol that can result in vulnerabilities when a network
is scanned, either by an intruder or through the use of scanning is scanned, either by an intruder or through the use of scanning
tools that perform network inventory, security audits, etc. (e.g., tools that perform network inventory, security audits, etc. (e.g.,
"nmap"). "nmap").
This document describes the problem in detail and suggests possible This document describes the problem in detail and suggests possible
skipping to change at page 5, line 14 skipping to change at page 5, line 14
may be impossible to establish new IPv6 flows, and existing ipv6 may be impossible to establish new IPv6 flows, and existing ipv6
transport flows may be interrupted. transport flows may be interrupted.
Network scans attempt to find and probe devices on a network. Network scans attempt to find and probe devices on a network.
Typically, scans are performed on a range of target addresses, or all Typically, scans are performed on a range of target addresses, or all
the addresses on a particular subnet. When such probes are directed the addresses on a particular subnet. When such probes are directed
via a router, and the target addresses are on a directly attached via a router, and the target addresses are on a directly attached
network, the router will attempt to perform address resolution on a network, the router will attempt to perform address resolution on a
large number of destinations (i.e., some fraction of the 2^64 large number of destinations (i.e., some fraction of the 2^64
addresses on the subnet). The router's process of testing for the addresses on the subnet). The router's process of testing for the
(non)existance of neighbors can induce a denial of service condition, (non)existence of neighbors can induce a denial of service condition,
where the number of necessary Neighbor Discovery requests overwhelms where the number of necessary Neighbor Discovery requests overwhelms
the implementation's capacity to process them, exhausts available the implementation's capacity to process them, exhausts available
memory, replaces existing in-use mappings with incomplete entries memory, replaces existing in-use mappings with incomplete entries
that will never be completed, and so on. The resulting network that will never be completed, and so on. The resulting network
disruption, may impact existing traffic, and devices that join the disruption, may impact existing traffic, and devices that join the
network may find that address resolution attempts fail. The DOS as a network may find that address resolution attempts fail. The DOS as a
consequence of network scanning was previously described in [RFC5157] consequence of network scanning was previously described in [RFC5157]
In order to alleviate risk associated with this DOS threat, some In order to alleviate risk associated with this DOS threat, some
router implementations have taken steps to rate-limit the processing router implementations have taken steps to rate-limit the processing
skipping to change at page 6, line 26 skipping to change at page 6, line 26
resolution and maintaining the Neighbor Cache. When forwarding resolution and maintaining the Neighbor Cache. When forwarding
packets, the forwarding plane accesses entries within the Neighbor packets, the forwarding plane accesses entries within the Neighbor
Cache. When the forwarding plane processes a packet for which the Cache. When the forwarding plane processes a packet for which the
corresponding Neighbor Cache Entry is missing or incomplete, it corresponding Neighbor Cache Entry is missing or incomplete, it
notifies NDP to take appropriate action (typically via a shared notifies NDP to take appropriate action (typically via a shared
queue). NDP picks up requests from the shared queue and performs queue). NDP picks up requests from the shared queue and performs
any necessary discovery action. In many implementations the NDP any necessary discovery action. In many implementations the NDP
is also responsible for responding to router solicitation is also responsible for responding to router solicitation
messages, Neighbor Unreachability Detection (NUD), etc. messages, Neighbor Unreachability Detection (NUD), etc.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
4. Background 4. Background
Modern router architectures separate the forwarding of packets Modern router architectures separate the forwarding of packets
(forwarding plane) from the decisions needed to decide where the (forwarding plane) from the decisions needed to decide where the
packets should go (control plane). In order to deal with the high packets should go (control plane). In order to deal with the high
number of packets per second, the forwarding plane is generally number of packets per second, the forwarding plane is generally
implemented in hardware and is highly optimized for the task of implemented in hardware and is highly optimized for the task of
forwarding packets. In contrast, the NDP control plane is mostly forwarding packets. In contrast, the NDP control plane is mostly
implemented in software processes running on a general purpose implemented in software processes running on a general purpose
processor. processor.
When a router needs to forward an IP packet, the forwarding plane When a router needs to forward an IP packet, the forwarding plane
logic performs the longest match lookup to determine where to send logic performs the longest match lookup to determine where to send
the packet and what outgoing interface to use. To deliver the packet the packet and what outgoing interface to use. To deliver the packet
to an adjacent node, the forwarding plance encapsulates the packet in to an adjacent node, the forwarding plane encapsulates the packet in
a link-layer frame (which contains a header with the link-layer a link-layer frame (which contains a header with the link-layer
destination address). The forwarding plane logic checks the Neighbor destination address). The forwarding plane logic checks the Neighbor
Cache to see if it already has a suitable link-layer destination, and Cache to see if it already has a suitable link-layer destination, and
if not, places the request for the required information into a queue, if not, places the request for the required information into a queue,
and signals the control plane (i.e., NDP) that it needs the link- and signals the control plane (i.e., NDP) that it needs the link-
layer address resolved. layer address resolved.
In order to protect NDP specifically and the control plane generally In order to protect NDP specifically and the control plane generally
from being overwhelmed with these requests, appropriate steps must be from being overwhelmed with these requests, appropriate steps must be
taken. For example, the size and fill rate of the queue might be taken. For example, the size and fill rate of the queue might be
skipping to change at page 7, line 41 skipping to change at page 7, line 45
the Neighbor Cache for an existing Neighbor Cache Entry for the the Neighbor Cache for an existing Neighbor Cache Entry for the
neighbor, and if none exists, invokes the address resolution portions neighbor, and if none exists, invokes the address resolution portions
of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the of the IPv6 Neighbor Discovery [RFC4861] protocol to determine the
link-layer address. link-layer address.
[RFC4861] Section 5.2 (Conceptual Sending Algorithm) outlines how [RFC4861] Section 5.2 (Conceptual Sending Algorithm) outlines how
this process works. A very high level summary is that the device this process works. A very high level summary is that the device
creates a new Neighbor Cache Entry for the neighbor, sets the state creates a new Neighbor Cache Entry for the neighbor, sets the state
to INCOMPLETE, queues the packet and initiates the actual address to INCOMPLETE, queues the packet and initiates the actual address
resolution process. The device then sends out one or more Neighbor resolution process. The device then sends out one or more Neighbor
Solicitations, and when it receives a correpsonding Neighbor Solicitations, and when it receives a corresponding Neighbor
Advertisement, completes the Neighbor Cache Entry and sends the Advertisement, completes the Neighbor Cache Entry and sends the
queued packet. queued packet.
6. Operational Mitigation Options 6. Operational Mitigation Options
This section provides some feasible mitigation options that can be This section provides some feasible mitigation options that can be
employed today by network operators in order to protect network employed today by network operators in order to protect network
availability while vendors implement more effective protection availability while vendors implement more effective protection
measures. It can be stipulated that some of these options are measures. It can be stipulated that some of these options are
"kludges", and are operationally difficult to manage. They are "kludges", and are operationally difficult to manage. They are
skipping to change at page 8, line 19 skipping to change at page 8, line 25
6.1. Filtering of unused address space. 6.1. Filtering of unused address space.
The DOS condition is induced by making a router try to resolve The DOS condition is induced by making a router try to resolve
addresses on the subnet at a high rate. By carefully addressing addresses on the subnet at a high rate. By carefully addressing
machines into a small portion of a subnet (such as the lowest machines into a small portion of a subnet (such as the lowest
numbered addresses), it is possible to filter access to addresses not numbered addresses), it is possible to filter access to addresses not
in that portion. This will prevent the attacker from making the in that portion. This will prevent the attacker from making the
router attempt to resolve unused addresses. For example if there are router attempt to resolve unused addresses. For example if there are
only 50 hosts connected to an interface, you may be able to filter only 50 hosts connected to an interface, you may be able to filter
any address above the first 64 addresses of that subnet by any address above the first 64 addresses of that subnet by null-
nullrouting the subnet carrying a more specific /122 route. routing the subnet carrying a more specific /122 route.
As mentioned at the beginning of this section, it is fully understood As mentioned at the beginning of this section, it is fully understood
that this is ugly (and difficult to manage); but failing other that this is ugly (and difficult to manage); but failing other
options, it may be a useful technique especially when responding to options, it may be a useful technique especially when responding to
an attack. an attack.
This solution requires that the hosts be statically or statefully This solution requires that the hosts be statically or statefully
addressed (as is often done in a datacenter) and may not interact addressed (as is often done in a datacenter) and may not interact
well with networks using [RFC4862] well with networks using [RFC4862]
skipping to change at page 9, line 16 skipping to change at page 9, line 21
virtual interface on the host (for example the loopback interface), virtual interface on the host (for example the loopback interface),
enabling IP forwarding on the host and having it run a routing enabling IP forwarding on the host and having it run a routing
daemon. For obvious reasons, host participation in the IGP makes daemon. For obvious reasons, host participation in the IGP makes
many operators uncomfortable, but can be a very powerful technique if many operators uncomfortable, but can be a very powerful technique if
used in a disciplined and controlled manner. used in a disciplined and controlled manner.
6.4. Tuning of the NDP Queue Rate Limit. 6.4. Tuning of the NDP Queue Rate Limit.
Many implementations provide a means to control the rate of Many implementations provide a means to control the rate of
resolution of unknown addresses. By tuning this rate, it may be resolution of unknown addresses. By tuning this rate, it may be
possible to amerlorate the issue, as with most tuning knobs possible to ameliorate the issue, as with most tuning knobs
(especially those that deal with rate limiting), the attack may be (especially those that deal with rate limiting), the attack may be
completed more quickly due to the lower threshold. By excessively completed more quickly due to the lower threshold. By excessively
lowering this rate you may negatively impact how long the device lowering this rate you may negatively impact how long the device
takes to learn new addresses under normal conditions (for example, takes to learn new addresses under normal conditions (for example,
after clearing the neighbor cache or when the router first boots). after clearing the neighbor cache or when the router first boots).
Under attack conditions you may be unable to resolve "legitimate" Under attack conditions you may be unable to resolve "legitimate"
addresses sooner than if you had just left the parameter untouched. addresses sooner than if you had just left the parameter untouched.
It is worth noting that this technique is worth investigating only if It is worth noting that this technique is worth investigating only if
the device has separate queues for resolution of unknown addresses the device has separate queues for resolution of unknown addresses
skipping to change at page 10, line 4 skipping to change at page 10, line 9
memory, etc. are never infinite, yet with IPv6's large subnets it memory, etc. are never infinite, yet with IPv6's large subnets it
is easy to cause NDP to generate large numbers of address is easy to cause NDP to generate large numbers of address
resolution requests for non-existent destinations. resolution requests for non-existent destinations.
Implementations need to limit resources devoted to processing Implementations need to limit resources devoted to processing
Neighbor Discovery requests in a thoughtful manner. Neighbor Discovery requests in a thoughtful manner.
Prioritize - Some NDP requests are more important than others. For Prioritize - Some NDP requests are more important than others. For
example, when resources are limited, responding to Neighbor example, when resources are limited, responding to Neighbor
Solicitations for one's own address is more important than Solicitations for one's own address is more important than
initiating address resolution requests that create new entries. initiating address resolution requests that create new entries.
Likewise, performing Neighbor Unreachability Detection, which by Likewise, performing Neighbor Unreachability Detection, which by
definition is only invoked on destinations that are actively being definition is only invoked on destinations that are actively being
used, is more important than creating new entries for possibly used, is more important than creating new entries for possibly
non-existant neighbors. non-existent neighbors.
7.1. Prioritize NDP Activities 7.1. Prioritize NDP Activities
Not all Neighbor Discovery activities are equally important. Not all Neighbor Discovery activities are equally important.
Specifically, requests to perform large numbers of address Specifically, requests to perform large numbers of address
resolutions on non-existant Neighbor Cache Entries should not come at resolutions on non-existent Neighbor Cache Entries should not come at
the expense of servicing requests related to keeping existing, in-use the expense of servicing requests related to keeping existing, in-use
entries properly up-to-date. Thus, implementations should divide entries properly up-to-date. Thus, implementations should divide
work activities into categories having different priorities. The work activities into categories having different priorities. The
following gives examples of different activities and their importance following gives examples of different activities and their importance
in rough priority order. in rough priority order.
1. It is critical to respond to Neighbor Solicitations for one's own 1. It is critical to respond to Neighbor Solicitations for one's own
address, especially when a router. Whether for address resolution or address, especially when a router. Whether for address resolution or
Neighbor Unreachability Detection, failure to respond to Neighbor Neighbor Unreachability Detection, failure to respond to Neighbor
Solicitations results in immediate problems. Failure to respond to Solicitations results in immediate problems. Failure to respond to
skipping to change at page 10, line 37 skipping to change at page 10, line 41
multicast. Once an entry has been flushed, existing traffic for multicast. Once an entry has been flushed, existing traffic for
destinations using that entry can no longer be forwarded until destinations using that entry can no longer be forwarded until
address resolution completes successfully. In other words, not address resolution completes successfully. In other words, not
responding to NS messages further increases the NDP load, and causes responding to NS messages further increases the NDP load, and causes
on-going communication to fail. on-going communication to fail.
2. It is critical to revalidate one's own existing NCEs in need of 2. It is critical to revalidate one's own existing NCEs in need of
refresh. As part of NUD, ND is required to frequently revalidate refresh. As part of NUD, ND is required to frequently revalidate
existing, in-use entries. Failure to do so can result in the entry existing, in-use entries. Failure to do so can result in the entry
being discarded. For in-use entries, discarding the entry will being discarded. For in-use entries, discarding the entry will
almost certainly result in a subswquent request to perform address almost certainly result in a subsequent request to perform address
resolution on the entry, but this time using multicast. As above, resolution on the entry, but this time using multicast. As above,
once the entry has been flushed, existing traffic for destinations once the entry has been flushed, existing traffic for destinations
using that entry can no longer be forwarded until address resolution using that entry can no longer be forwarded until address resolution
completes succesfully. completes successfully.
3. To maintain the stability of the control plane, Neighbor 3. To maintain the stability of the control plane, Neighbor
Discovery activity related to traffic sourced by the router (as Discovery activity related to traffic sourced by the router (as
opposed to traffic being forwarded by the router) should be given opposed to traffic being forwarded by the router) should be given
high priority. Whenever network problems occur, debugging and making high priority. Whenever network problems occur, debugging and making
other operational changes requires being able to query and access the other operational changes requires being able to query and access the
router. In addition, routing protocols depedent on Neighbor router. In addition, routing protocols dependent on Neighbor
Discovery for connectivty may begin to react (negatively) to Discovery for connectivity may begin to react (negatively) to
perceived connectivity problems, causing addition undesirable ripple perceived connectivity problems, causing addition undesirable ripple
effects. effects.
4. Traffic to unknown addresses should be given lowest priority. 4. Traffic to unknown addresses should be given lowest priority.
Indeed, it may be useful to distinguish between "never seen" Indeed, it may be useful to distinguish between "never seen"
addresses and those that have been seen before, but that do not have addresses and those that have been seen before, but that do not have
a corresponding NCE. Specifically, the conceptual processing a corresponding NCE. Specifically, the conceptual processing
algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting algorithm in IPv6 Neighbor Discovery [RFC4861] calls for deleting
NCEs under certain conditions. Rather than delete them completely, NCEs under certain conditions. Rather than delete them completely,
however, it might be useful to at least keep track of the fact that however, it might be useful to at least keep track of the fact that
skipping to change at page 12, line 9 skipping to change at page 12, line 13
protect themselves from Denial of Service attacks. Implementation protect themselves from Denial of Service attacks. Implementation
advice to router vendors aimed at ameliorating known problems carries advice to router vendors aimed at ameliorating known problems carries
the risk of previously unforeseen consequences. It is not believed the risk of previously unforeseen consequences. It is not believed
that these mitigation techniques or the implementation of finer- that these mitigation techniques or the implementation of finer-
grained queuing of NDP activity create additional security risks or grained queuing of NDP activity create additional security risks or
DOS exposure. DOS exposure.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Ron Bonica, Troy Bonin, John Jason The authors would like to thank Ron Bonica, Troy Bonin, John Jason
Brzozowski, Randy Bush, Vint Cerf,Tassos Chatzithomaoglou, Jason Brzozowski, Randy Bush, Vint Cerf, Tassos Chatzithomaoglou, Jason
Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow and Suran Fesler, Wes George, Erik Kline, Jared Mauch, Chris Morrow and Suran
De Silva. Special thanks to Thomas Narten for detailed review and De Silva. Special thanks to Thomas Narten for detailed review and
(even more so) for providing text! (even more so) for providing text!
Apologies for anyone we may have missed; it was not intentional. Apologies for anyone we may have missed; it was not intentional.
11. References 11. References
11.1. Normative References 11.1. Normative References
skipping to change at page 12, line 36 skipping to change at page 12, line 40
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. Address Autoconfiguration", RFC 4862, September 2007.
[RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti, [RFC6164] Kohno, M., Nitzan, B., Bush, R., Matsuzaki, Y., Colitti,
L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter- L., and T. Narten, "Using 127-Bit IPv6 Prefixes on Inter-
Router Links", RFC 6164, April 2011. Router Links", RFC 6164, April 2011.
11.2. Informative References 11.2. Informative References
[RFC4255] Schlyter, J. and W. Griffin, "Using DNS to Securely
Publish Secure Shell (SSH) Key Fingerprints", RFC 4255,
January 2006.
[RFC5157] Chown, T., "IPv6 Implications for Network Scanning", [RFC5157] Chown, T., "IPv6 Implications for Network Scanning",
RFC 5157, March 2008. RFC 5157, March 2008.
Appendix A. Text goes here.
TBD
Authors' Addresses Authors' Addresses
Igor Igor Gashinsky
Yahoo! Yahoo!
45 W 18th St 45 W 18th St
New York, NY New York, NY
USA USA
Email: igor@yahoo-inc.com Email: igor@yahoo-inc.com
Joel Joel Jaeggli
Zynga Zynga
111 Evelyn 111 Evelyn
Sunnyvale, CA Sunnyvale, CA
USA USA
Email: jjaeggli@zynga.com Email: jjaeggli@zynga.com
Warren Kumari Warren Kumari
Google Google Inc
1600 Amphitheatre Parkway
Mountain View, CA
USA
Email: warren@kumari.net Email: warren@kumari.net
 End of changes. 27 change blocks. 
36 lines changed or deleted 33 lines changed or added

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