DELAY_FIRST_PROBE_TIME 5 seconds
MIN_RANDOM_FACTOR .5
MAX_RANDOM_FACTOR 1.5
Additional protocol constants are defined with the message formats in
Section 4.
All protocol constants are subject to change in future revisions of
the protocol.
The constants in this specification may be overridden by specific
documents that describe how IPv6 operates over different link layers.
This rule allows Neighbor Discovery to operate over links with widely
varying performance characteristics.
11. SECURITY CONSIDERATIONS
Neighbor Discovery is subject to attacks that cause IP packets to
flow to unexpected places. Such attacks can be used to cause denial
of service but also allow nodes to intercept and optionally modify
packets destined for other nodes.
The protocol reduces the exposure to such threats in the absence of
authentication by ignoring ND packets received from off-link senders.
The Hop Limit field of all received packets is verified to contain
255, the maximum legal value. Because routers decrement the Hop
Limit on all packets they forward, received packets containing a Hop
Limit of 255 must have originated from a neighbor.
The trust model for redirects is the same as in IPv4. A redirect is
accepted only if received from the same router that is currently
being used for that destination. It is natural to trust the routers
on the link. If a host has been redirected to another node (i.e.,
the destination is on-link) there is no way to prevent the target
from issuing another redirect to some other destination. However,
this exposure is no worse than it was; the target host, once
subverted, could always act as a hidden router to forward traffic
elsewhere.
The protocol contains no mechanism to determine which neighbors are
authorized to send a particular type of message e.g. Router
Advertisements; any neighbor, presumably even in the presence of
authentication, can send Router Advertisement messages thereby being
able to cause denial of service. Furthermore, any neighbor can send
proxy Neighbor Advertisements as well as unsolicited Neighbor
Advertisements as a potential denial of service attack.
Neighbor Discovery protocol packet exchanges can be authenticated
using the IP Authentication Header [IPv6-AUTH]. A node SHOULD
include an Authentication Header when sending Neighbor Discovery
packets if a security association for use with the IP Authentication
Header exists for the destination address. The security associations
may have been created through manual configuration or through the
operation of some key management protocol.
Received Authentication Headers in Neighbor Discovery packets MUST be
verified for correctness and packets with incorrect authentication
MUST be ignored.
It SHOULD be possible for the system administrator to configure a
node to ignore any Neighbor Discovery messages that are not
authenticated using either the Authentication Header or Encapsulating
Security Payload. The configuration technique for this MUST be
documented. Such a switch SHOULD default to allowing unauthenticated
messages.
Confidentiality issues are addressed by the IP Security Architecture
and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
ESP].
REFERENCES
[ADDRCONF] Thomson, S., and T. Narten, "IPv6 Address
Autoconfiguration", RFC1971, August 1996.
[ADDR-ARCH] Deering, S., and R. Hinden, Editors, "IP Version 6
Addressing Architecture", RFC1884, January 1996.
[ANYCST] Partridge, C., Mendez, T., and W. Milliken, "Host
Anycasting Service", RFC1546, November 1993.
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", STD
37, RFC826, November 1982.
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC1122, October 1989.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[ICMPv6] Conta, A., and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6)", RFC1885, January 1996.
[IPv6] Deering, S., and R. Hinden, Editors, "Internet Protocol,
Version 6 (IPv6) Specification", RFC1883, January, 1996.
[IPv6-ETHER] Crawford, M., "A Method for the Transmission of IPv6
Packets over Ethernet Networks", RFC1972, August 1996.
[IPv6-SA] Atkinson, R., "Security Architecture for the Internet
Protocol", RFC1825, August 1995.
[IPv6-AUTH] Atkinson, R., "IP Authentication Header", RFC1826,
August 1995.
[IPv6-ESP] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC1827, August 1995.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC1256,
September 1991.
[SH-MEDIA] Braden, R., Postel, J., and Y. Rekhter, "Internet
Architecture Extensions for Shared Media", RFC1620, May
1994.
[ASSIGNED] Reynolds, J., and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC1700, October 1994.
[SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing
Messages", IEEE/ACM Transactions on Networking, April 1994.
ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
AUTHORS' ADDRESSES
Erik Nordmark Thomas Narten
Sun Microsystems, Inc. IBM Corporation
2550 Garcia Ave P.O. Box 12195
Mt. View, CA 94041 Research Triangle Park, NC 27709-2195
USA USA
Phone: +1 415 786 5166 Phone: +1 919 254 7798
Fax: +1 415 786 5896 Fax: +1 919 254 4027
EMail: nordmark@sun.com EMail: narten@vnet.ibm.com
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
USA
EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com
APPENDIX A: MULTIHOMED HOSTS
There are a number of complicating issues that arise when Neighbor
Discovery is used by hosts that have multiple interfaces. This
section does not attempt to define the proper operation of multihomed
hosts with regard to Neighbor Discovery. Rather, it identifies
issues that require further study. Implementors are encouraged to
experiment with various approaches to making Neighbor Discovery work
on multihomed hosts and to report their experiences.
If a multihomed host receives Router Advertisements on all of its
interfaces, it will (probably) have learned on-link prefixes for the
addresses residing on each link. When a packet must be sent through
a router, however, selecting the "wrong" router can result in a
suboptimal or non-functioning path. There are number of issues to
consider:
1) In order for a router to send a redirect, it must determine that
the packet it is forwarding originates from a neighbor. The
standard test for this case is to compare the source address of the
packet to the list of on-link prefixes associated with the
interface on which the packet was received. If the originating
host is multihomed, however, the source address it uses may belong
to an interface other than the interface from which it was sent.
In such cases, a router will not send redirects, and suboptimal
routing is likely. In order to be redirected, the sending host
must always send packets out the interface corresponding to the
outgoing packet's source address. Note that this issue never
arises with non-multihomed hosts; they only have one interface.
2) If the selected first-hop router does not have a route at all for
the destination, it will be unable to deliver the packet. However,
the destination may be reachable through a router on one of the
other interfaces. Neighbor Discovery does not address this
scenario; it does not arise in the non-multihomed case.
3) Even if the first-hop router does have a route for a destination,
there may be a better route via another interface. No mechanism
exists for the multihomed host to detect this situation.
If a multihomed host fails to receive Router Advertisements on one or
more of its interfaces, it will not know (in the absence of
configured information) which destinations are on-link on the
affected interface(s). This leads to a number of problems:
1) If no Router Advertisement is received on any interfaces, a
multihomed host will have no way of knowing which interface to send
packets out on, even for on-link destinations. Under similar
conditions in the non-multihomed host case, a node treats all
destinations as residing on-link, and communication proceeds. In
the multihomed case, however, additional information is needed to
select the proper outgoing interface. Alternatively, a node could
attempt to perform address resolution on all interfaces, a step
involving significant complexity that is not present in the non-
multihomed host case.
2) If Router Advertisements are received on some, but not all
interfaces, a multihomed host could choose to only send packets out
on the interfaces on which it has received Router Advertisements.
A key assumption made here, however, is that routers on those other
interfaces will be able to route packets to the ultimate
destination, even when those destinations reside on the subnet to
which the sender connects, but has no on-link prefix information.
Should the assumption be false, communication would fail. Even if
the assumption holds, packets will traverse a sub-optimal path.
APPENDIX B: FUTURE EXTENSIONS
Possible extensions for future study are:
o Using dynamic timers to be able to adapt to links with widely varying
delay. Measuring round trip times, however, requires acknowledgments
and sequence numbers in order to match received Neighbor
Advertisements with the actual Neighbor Solicitation that triggered
the advertisement. Implementors wishing to experiment with such a
facility could do so in a backwards-compatible way by defining a new
option carrying the necessary information. Nodes not understanding
the option would simply ignore it.
o Adding capabilities to facilitate the operation over links that
currently require hosts to register with an address resolution
server. This could for instance enable routers to ask hosts to send
them periodic unsolicited advertisements. Once again this can be
added using a new option sent in the Router Advertisements.
o Adding additional procedures for links where asymmetric and non-
transitive reachability is part of normal operations. Such
procedures might allow hosts and routers to find usable paths on,
e.g., radio links.
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE
This appendix contains a summary of the rules specified in Sections
7.2 and 7.3. This document does not mandate that implementations
adhere to this model as long as their external behavior is consistent
with that described in this document.
When performing address resolution and Neighbor Unreachability
Detection the following state transitions apply using the conceptual
model:
State Event Action New state
- Packet to send. Create entry. INCOMPLETE
Send multicast NS.
Start retransmit timer
INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE
less than N Start retransmit timer
retransmissions.
INCOMPLETE Retransmit timeout, Discard entry -
N or more Send ICMP error
retransmissions.
INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=any address. Send queued
packets.
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued
packets.
!INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0
!INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=1 address.
!INCOMPLETE NA, Solicited=0, - STALE
Override=0
!INCOMPLETE NA, Solicited=0, Record link-layer STALE
Override=1 address.
!INCOMPLETE upper-layer reachability - REACHABLE
confirmation
REACHABLE timeout, more than - STALE
N seconds since
reachability confirm.
STALE Sending packet Start delay timer DELAY
DELAY Delay timeout Send unicast NS probe PROBE
Start retransmit timer
PROBE Retransmit timeout, Retransmit NS PROBE
less than N
retransmissions.
PROBE Retransmit timeout, Discard entry -
N or more
retransmissions.
The state transitions for receiving unsolicited information other
than Neighbor Advertisement messages apply to either the source of
the packet (for Neighbor Solicitation, Router Solicitation, and
Router Advertisement messages) or the target address (for Redirect
messages) as follows:
State Event Action New state
- NS, RS, RA, Redirect Create entry. STALE
INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE
address. Send queued
packets.
!INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE
Different link-layer address
address than cached.
!INCOMPLETE NS, RS, RA, Redirect - unchanged
Same link-layer
address as cached.
APPENDIX D: IMPLEMENTATION ISSUES
Appendix D.1: Reachability confirmations
Neighbor Unreachability Detection requires explicit confirmation that
a forward-path is functioning properly. To avoid the need for
Neighbor Solicitation probe messages, upper layer protocols should
provide such an indication when the cost of doing so is small.
Reliable connection-oriented protocols such as TCP are generally
aware when the forward-path is working. When TCP sends (or receives)
data, for instance, it updates its window sequence numbers, sets and
cancels retransmit timers, etc. Specific scenarios that usually
indicate a properly functioning forward-path include:
- Receipt of an acknowledgement that covers a sequence number (e.g.,
data) not previously acknowledged indicates that the forward path was
working at the time the data was sent.
- Completion of the initial three-way handshake is a special case of the
previous rule; although no data is sent during the handshake, the SYN
flags are counted as data from the sequence number perspective. This
applies to both the SYN+ACK for the active open the ACK of that
packet on the passively opening peer.
- Receipt of new data (i.e., data not previously received) indicates
that the forward-path was working at the time an acknowledgement was
sent that advanced the peer's send window that allowed the new data
to be sent.
To minimize the cost of communicating reachability information
between the TCP and IP layers, an implementation may wish to rate-
limit the reachability confirmations its sends IP. One possibility
is to process reachability only every few packets. For example, one
might update reachability information once per round trip time, if an
implementation only has one round trip timer per connection. For
those implementations that cache Destination Cache entries within
control blocks, it may be possible to update the Neighbor Cache entry
directly (i.e., without an expensive lookup) once the TCP packet has
been demultiplexed to its corresponding control block. For other
implementation it may be possible to piggyback the reachability
confirmation on the next packet submitted to IP assuming that the
implementation guards against the piggybacked confirmation becoming
stale when no packets are sent to IP for an extended period of time.
TCP must also guard against thinking "stale" information indicates
current reachability. For example, new data received 30 minutes
after a window has opened up does not constitute a confirmation that
the path is currently working. In merely indicates that 30 minutes
ago the window update reached the peer i.e. the path was working at
that point in time. An implementation must also take into account
TCP zero-window probes that are sent even if the path is broken and
the window update did not reach the peer.
For UDP based applications (RPC, DNS) it is relatively simple to make
the client send reachability confirmations when the response packet
is received. It is more difficult and in some cases impossible for
the server to generate such confirmations since there is no flow
control, i.e., the server can not determine whether a received
request indicates that a previous response reached the client.
Note that an implementation can not use negative upper-layer advise
as a replacement for the Neighbor Unreachability Detection algorithm.
Negative advise (e.g. from TCP when there are excessive
retransmissions) could serve as a hint that the forward path from the
sender of the data might not be working. But it would fail to detect
when the path from the receiver of the data is not functioning
causing, none of the acknowledgement packets to reach the
dgement