ppp: Neighbor Discovery for IP version 6 (prefix only)

8 files changed, 5777 insertions, 17 deletions

diff --git a/README b/README
index e8aace7..1b708b9 100644
--- a/README
+++ b/README
@@ -144,11 +144,11 @@ snmptable -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::sessionsTabl
 3. Terminate session by session identifier (Acct-Session-ID):
 snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termBySID.0 = 0000000000000001
 4. Terminate session by interface name:
-snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIfName = ppp2
+snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIfName.0 = ppp2
 5. Terminaten session by IP address (Framed-IP-Address):
-snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIP = 192.168.10.10
+snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByIP.0 = 192.168.10.10
 6. Terminate session by username:
-snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByUsername = user1
+snmpset -m +ACCEL-PPP-MIB -v 2c -c local 127.0.0.1 ACCEL-PPP-MIB::termByUsername.0 = user1
 
 
 Warning !!!
diff --git a/accel-pppd/CMakeLists.txt b/accel-pppd/CMakeLists.txt
index 45a070f..807f039 100644
--- a/accel-pppd/CMakeLists.txt
+++ b/accel-pppd/CMakeLists.txt
@@ -69,6 +69,7 @@ ADD_EXECUTABLE(accel-pppd
 	ppp/ppp_ipv6cp.c
 	ppp/ppp_ccp.c	
 	ppp/ccp_mppe.c
+	ppp/ipv6_nd.c
 
 	cli/std_cmd.c
 	cli/show_sessions.c
diff --git a/accel-pppd/extra/ipv6pool.c b/accel-pppd/extra/ipv6pool.c
index 37d2ea8..306d5bd 100644
--- a/accel-pppd/extra/ipv6pool.c
+++ b/accel-pppd/extra/ipv6pool.c
@@ -47,6 +47,7 @@ static void generate_pool(struct in6_addr *addr, int mask, int prefix_len)
 	for (; ip <= endip; ip += step) {
 		it = malloc(sizeof(*it));
 		*(uint64_t *)it->it.addr.s6_addr = htobe64(ip);
+		it->it.prefix_len = prefix_len;
 		list_add_tail(&it->entry, &ippool);
 	}
 }
diff --git a/accel-pppd/ppp/ipv6_nd.c b/accel-pppd/ppp/ipv6_nd.c
new file mode 100644
index 0000000..bec0ea3
--- /dev/null
+++ b/accel-pppd/ppp/ipv6_nd.c
@@ -0,0 +1,308 @@
+#include <stdlib.h>
+#include <stdio.h>
+#include <unistd.h>
+#include <fcntl.h>
+#include <string.h>
+#include <errno.h>
+#include <pthread.h>
+#include <netinet/in.h>
+#include <netinet/icmp6.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+
+#include "log.h"
+#include "ppp.h"
+#include "events.h"
+
+#include "memdebug.h"
+
+static int conf_init_ra = 3;
+static int conf_init_ra_interval = 1;
+static int conf_ra_interval = 60;
+
+struct ipv6_nd_handler_t
+{
+	struct ppp_t *ppp;
+	struct ppp_pd_t pd;
+	struct triton_md_handler_t hnd;
+	struct triton_timer_t timer;
+	int ra_sent;
+};
+
+static void *pd_key;
+
+#define BUF_SIZE 1024
+
+static void ipv6_nd_send_ra(struct ipv6_nd_handler_t *h)
+{
+	void *buf = _malloc(BUF_SIZE);
+	struct nd_router_advert *adv = buf;
+	struct nd_opt_prefix_info *pinfo;
+	//struct nd_opt_route_info *rinfo;
+	//struct nd_opt_rdnss_info_local *rdnssinfo;
+	//struct nd_opt_mtu *mtu;
+	struct sockaddr_in6 addr;
+
+	memset(adv, 0, sizeof(*adv));
+	adv->nd_ra_type = ND_ROUTER_ADVERT;
+	adv->nd_ra_curhoplimit = 64;
+	adv->nd_ra_router_lifetime = htons(1);
+	//adv->nd_ra_reachable = 0;
+	//adv->nd_ra_retransmit = 0;
+	
+	pinfo = (struct nd_opt_prefix_info *)(adv + 1);
+	memset(pinfo, 0, sizeof(*pinfo));
+	pinfo->nd_opt_pi_type = ND_OPT_PREFIX_INFORMATION;
+	pinfo->nd_opt_pi_len = 4;
+	pinfo->nd_opt_pi_prefix_len = h->ppp->ipv6_prefix_len;
+	pinfo->nd_opt_pi_flags_reserved = ND_OPT_PI_FLAG_ONLINK | ND_OPT_PI_FLAG_AUTO;
+	pinfo->nd_opt_pi_valid_time = 0xffffffff;
+	pinfo->nd_opt_pi_preferred_time = 0xffffffff;
+	memcpy(&pinfo->nd_opt_pi_prefix, &h->ppp->ipv6_addr, 8);
+
+	memset(&addr, 0, sizeof(addr));
+	addr.sin6_family = AF_INET6;
+	addr.sin6_addr.s6_addr32[0] = htonl(0xff020000);
+	addr.sin6_addr.s6_addr32[3] = htonl(0x1);
+	addr.sin6_scope_id = h->ppp->ifindex; 
+
+	sendto(h->hnd.fd, buf, (void *)(pinfo + 1) - buf, 0, (struct sockaddr *)&addr, sizeof(addr));
+
+	_free(buf);
+}
+
+static void send_ra_timer(struct triton_timer_t *t)
+{
+	struct ipv6_nd_handler_t *h = container_of(t, typeof(*h), timer);
+
+	if (h->ra_sent++ == conf_init_ra) {
+		h->timer.period = conf_ra_interval * 1000;
+		triton_timer_mod(t, 0);
+	}
+
+	ipv6_nd_send_ra(h);
+}
+
+static int ipv6_nd_read(struct triton_md_handler_t *_h)
+{
+	struct ipv6_nd_handler_t *h = container_of(_h, typeof(*h), hnd);
+	struct msghdr mhdr;
+	int chdr_len;
+	struct iovec iov;
+	struct cmsghdr *chdr, *cmsg;
+	struct in6_pktinfo *pkt_info;
+	struct icmp6_hdr *icmph;
+	void *buf;
+	int n;
+
+	chdr_len = CMSG_SPACE(sizeof(struct in6_pktinfo)) + CMSG_SPACE(sizeof(int));
+	chdr = _malloc(chdr_len);
+	buf = _malloc(BUF_SIZE);
+
+	iov.iov_len = BUF_SIZE;
+	iov.iov_base = buf;
+
+	memset(&mhdr, 0, sizeof(mhdr));
+	mhdr.msg_iov = &iov;
+	mhdr.msg_iovlen = 1;
+	mhdr.msg_control = chdr;
+	mhdr.msg_controllen = chdr_len;
+
+	while (1) {
+		n = recvmsg(h->hnd.fd, &mhdr, 0);
+		if (n == -1) {
+			if (errno == EAGAIN)
+				break;
+			log_ppp_error("ipv6_nd: recvmsg: %s\n", strerror(errno));
+			continue;
+		}
+
+		pkt_info = NULL;
+		for (cmsg = CMSG_FIRSTHDR(&mhdr); cmsg != NULL; cmsg = CMSG_NXTHDR(&mhdr, cmsg)) {
+			if (cmsg->cmsg_level == IPPROTO_IPV6 &&
+				  cmsg->cmsg_type == IPV6_PKTINFO) {
+				if (cmsg->cmsg_len != CMSG_LEN(sizeof(*pkt_info)))
+					log_ppp_warn("ipv6_nd: received invalid IPV6_PKTINFO\n");
+				else
+					pkt_info = (struct in6_pktinfo *)CMSG_DATA(cmsg);
+				break;
+			}
+		}
+
+		if (!pkt_info) {
+			log_ppp_warn("ipv6_nd: no IPV6_PKTINFO\n");
+			continue;
+		}
+
+		if (n < sizeof(*icmph)) {
+			log_ppp_warn("ipv6_nd: received short icmp packet (%i)\n", n);
+			continue;
+		}
+
+		icmph = buf;
+
+		if (icmph->icmp6_type != ND_ROUTER_SOLICIT) {
+			log_ppp_warn("ipv6_nd: received unexcpected icmp packet (%i)\n", icmph->icmp6_type);
+			continue;
+		}
+
+		/*if (!IN6_IS_ADDR_LINKLOCAL(&pkt_info->ipi6_addr)) {
+			log_ppp_warn("ipv6_nd: received icmp packet from non link-local address\n");
+			continue;
+		}*/
+
+		/*if (*(uint64_t *)(pkt_info->ipi6_addr.s6_addr + 8) != *(uint64_t *)(h->ppp->ipv6_addr.s6_addr + 8)) {
+			log_ppp_warn("ipv6_nd: received icmp packet from unknown address\n");
+			continue;
+		}*/
+
+		ipv6_nd_send_ra(h);
+	}
+
+	_free(chdr);
+	_free(buf);
+
+	return 0;
+}
+
+int ppp_ipv6_nd_start(struct ppp_t *ppp, uint64_t intf_id)
+{
+	int sock;
+	struct icmp6_filter filter;
+	struct sockaddr_in6 addr;
+	struct ipv6_mreq mreq;
+	int val;
+	struct ipv6_nd_handler_t *h;
+
+	sock = socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6);
+	
+	if (sock < 0) {
+		log_ppp_error("socket(AF_INET6, SOCK_RAW, IPPROTO_ICMPV6): %s\n", strerror(errno));
+		return -1;
+	}
+
+	memset(&addr, 0, sizeof(addr));
+	addr.sin6_family = AF_INET6;
+	addr.sin6_addr.s6_addr32[0] = htons(0xfe80);
+	*(uint64_t *)(addr.sin6_addr.s6_addr + 8) = intf_id;
+	addr.sin6_scope_id = ppp->ifindex;
+
+	if (bind(sock, (struct sockaddr *)&addr, sizeof(addr))) {
+		log_ppp_error("ipv6_nd: bind: %s %i\n", strerror(errno), errno);
+		goto out_err;
+	}
+
+	val = 1;
+	if (setsockopt(sock, IPPROTO_IPV6, IPV6_RECVPKTINFO, &val, sizeof(val))) {
+		log_ppp_error("ipv6_nd: setsockopt(IPV6_PKTINFO): %s\n", strerror(errno));
+		goto out_err;
+	}
+
+	val = 2;
+	if (setsockopt(sock, IPPROTO_RAW, IPV6_CHECKSUM, &val, sizeof(val))) {
+		log_ppp_error("ipv6_nd: setsockopt(IPV6_CHECKSUM): %s\n", strerror(errno));
+		goto out_err;
+	}
+
+	val = 255;
+	if (setsockopt(sock, IPPROTO_IPV6, IPV6_UNICAST_HOPS, &val, sizeof(val))) {
+		log_ppp_error("ipv6_nd: setsockopt(IPV6_UNICAST_HOPS): %s\n", strerror(errno));
+		goto out_err;
+	}
+	
+	if (setsockopt(sock, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &val, sizeof(val))) {
+		log_ppp_error("ipv6_nd: setsockopt(IPV6_MULTICAST_HOPS): %s\n", strerror(errno));
+		goto out_err;
+	}
+
+	/*val = 1;
+	if (setsockopt(sock, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &val, sizeof(val))) {
+		log_ppp_error("ipv6_nd: setsockopt(IPV6_HOPLIMIT): %s\n", strerror(errno));
+		goto out_err;
+	}*/
+
+	ICMP6_FILTER_SETBLOCKALL(&filter);
+	ICMP6_FILTER_SETPASS(ND_ROUTER_SOLICIT, &filter);
+
+	if (setsockopt(sock, IPPROTO_ICMPV6, ICMP6_FILTER, &filter, sizeof(filter))) {
+		log_ppp_error("ipv6_nd: setsockopt(ICMP6_FILTER): %s\n", strerror(errno));
+		goto out_err;
+	}
+
+	memset(&mreq, 0, sizeof(mreq));
+	mreq.ipv6mr_interface = ppp->ifindex;
+	mreq.ipv6mr_multiaddr.s6_addr32[0] = htonl(0xff020000);
+	mreq.ipv6mr_multiaddr.s6_addr32[3] = htonl(0x2);
+
+	if (setsockopt(sock, SOL_IPV6, IPV6_ADD_MEMBERSHIP, &mreq, sizeof(mreq))) {
+		log_ppp_error("ipv6_nd: failed to join ipv6 allrouters\n");
+		goto out_err;
+	}
+
+	fcntl(sock, F_SETFL, O_NONBLOCK);
+
+	h = _malloc(sizeof(*h));
+	memset(h, 0, sizeof(*h));
+	h->ppp = ppp;
+	h->pd.key = &pd_key;
+	h->hnd.fd = sock;
+	h->hnd.read = ipv6_nd_read;
+	h->timer.expire = send_ra_timer;
+	h->timer.period = conf_init_ra_interval * 1000;
+	list_add_tail(&h->pd.entry, &ppp->pd_list);
+
+	triton_md_register_handler(ppp->ctrl->ctx, &h->hnd);
+	triton_md_enable_handler(&h->hnd, MD_MODE_READ);
+
+	return 0;
+
+out_err:
+	close(sock);
+	return -1;
+}
+
+static struct ipv6_nd_handler_t *find_pd(struct ppp_t *ppp)
+{
+	struct ppp_pd_t *pd;
+
+	list_for_each_entry(pd, &ppp->pd_list, entry) {
+		if (pd->key == &pd_key)
+			return container_of(pd, typeof(struct ipv6_nd_handler_t), pd);
+	}
+
+	return NULL;
+}
+
+static void ev_ppp_started(struct ppp_t *ppp)
+{
+	struct ipv6_nd_handler_t *h = find_pd(ppp);
+
+	if (!h)
+		return;
+	
+	triton_timer_add(ppp->ctrl->ctx, &h->timer, 0);
+}
+
+static void ev_ppp_finishing(struct ppp_t *ppp)
+{
+	struct ipv6_nd_handler_t *h = find_pd(ppp);
+
+	if (!h)
+		return;
+	
+	triton_timer_del(&h->timer);
+	triton_md_unregister_handler(&h->hnd);
+	close(h->hnd.fd);
+
+	list_del(&h->pd.entry);
+	
+	_free(h);
+}
+
+static void init(void)
+{
+	triton_event_register_handler(EV_PPP_STARTED, (triton_event_func)ev_ppp_started);
+	triton_event_register_handler(EV_PPP_FINISHING, (triton_event_func)ev_ppp_finishing);
+}
+
+DEFINE_INIT(0, init);
diff --git a/accel-pppd/ppp/ipv6cp_opt_intfid.c b/accel-pppd/ppp/ipv6cp_opt_intfid.c
index 8e6675c..b55d3ff 100644
--- a/accel-pppd/ppp/ipv6cp_opt_intfid.c
+++ b/accel-pppd/ppp/ipv6cp_opt_intfid.c
@@ -4,13 +4,10 @@
 #include <fcntl.h>
 #include <string.h>
 #include <errno.h>
-#include <endian.h>
 #include <sys/socket.h>
 #include <sys/ioctl.h>
 #include "linux_ppp.h"
 
-#include <netlink/netlink.h>
-
 #include "log.h"
 #include "events.h"
 #include "ppp.h"
@@ -130,6 +127,9 @@ static int ipaddr_send_conf_req(struct ppp_ipv6cp_t *ipv6cp, struct ipv6cp_optio
 	if (conf_check_exists && check_exists(ipv6cp->ppp, &ipaddr_opt->ip->addr))
 		return -1;
 	
+	ipv6cp->ppp->ipv6_addr = ipaddr_opt->ip->addr;
+	ipv6cp->ppp->ipv6_prefix_len = ipaddr_opt->ip->prefix_len;
+	
 	opt64->hdr.id = CI_INTFID;
 	opt64->hdr.len = 10;
 	opt64->val = ipaddr_opt->intf_id;
@@ -150,7 +150,6 @@ static int ipaddr_recv_conf_req(struct ppp_ipv6cp_t *ipv6cp, struct ipv6cp_optio
 {
 	struct ipaddr_option_t *ipaddr_opt = container_of(opt, typeof(*ipaddr_opt), opt);
 	struct ipv6cp_opt64_t *opt64 = (struct ipv6cp_opt64_t* )ptr;
-	struct ifreq ifr;
 	struct in6_ifreq ifr6;
 
 	if (opt64->hdr.len != 10)
@@ -178,25 +177,27 @@ ack:
 	//if (ipv6cp->ppp->stop_time)
 	//	return IPV6CP_OPT_ACK;
 
-	memset(&ifr, 0, sizeof(ifr));
-	strcpy(ifr.ifr_name, ipv6cp->ppp->ifname);
+	memset(&ifr6, 0, sizeof(ifr6));
+	ifr6.ifr6_addr.s6_addr32[0] = htons(0xfe80);
+	*(uint64_t *)(ifr6.ifr6_addr.s6_addr + 8) = ipaddr_opt->intf_id;
+	ifr6.ifr6_prefixlen = 64;
+	ifr6.ifr6_ifindex = ipv6cp->ppp->ifindex;
 
-	if (ioctl(sock_fd, SIOCGIFINDEX, &ifr)) {
-		log_ppp_error("ppp:ipv6cp: ioctl(SIOCGIFINDEX): %s\n", strerror(errno));
+	if (ioctl(sock6_fd, SIOCSIFADDR, &ifr6)) {
+		log_ppp_error("ppp:ipv6cp: ioctl(SIOCSIFADDR): %s\n", strerror(errno));
 		return IPV6CP_OPT_REJ;
 	}
 
-	memset(&ifr6, 0, sizeof(ifr6));
-	ifr6.ifr6_addr.s6_addr16[0] = htons(0xfe80);
-	*(uint64_t *)(ifr6.ifr6_addr.s6_addr + 8) = ipaddr_opt->intf_id;
-	ifr6.ifr6_prefixlen = 64;
-	ifr6.ifr6_ifindex = ifr.ifr_ifindex;
+	memcpy(ifr6.ifr6_addr.s6_addr, ipaddr_opt->ip->addr.s6_addr, 8);
 
 	if (ioctl(sock6_fd, SIOCSIFADDR, &ifr6)) {
 		log_ppp_error("ppp:ipv6cp: ioctl(SIOCSIFADDR): %s\n", strerror(errno));
 		return IPV6CP_OPT_REJ;
 	}
 
+	if (ppp_ipv6_nd_start(ipv6cp->ppp, ipaddr_opt->intf_id))
+		return IPV6CP_OPT_REJ;
+
 	return IPV6CP_OPT_ACK;
 }
 
diff --git a/accel-pppd/ppp/ppp.c b/accel-pppd/ppp/ppp.c
index b541ba5..7406bf7 100644
--- a/accel-pppd/ppp/ppp.c
+++ b/accel-pppd/ppp/ppp.c
@@ -88,6 +88,8 @@ static void generate_sessionid(struct ppp_t *ppp)
 
 int __export establish_ppp(struct ppp_t *ppp)
 {
+	struct ifreq ifr;
+
 	/* Open an instance of /dev/ppp and connect the channel to it */
 	if (ioctl(ppp->fd, PPPIOCGCHAN, &ppp->chan_idx) == -1) {
 		log_ppp_error("ioctl(PPPIOCGCHAN): %s\n", strerror(errno));
@@ -136,8 +138,17 @@ int __export establish_ppp(struct ppp_t *ppp)
 	generate_sessionid(ppp);
 	sprintf(ppp->ifname, "ppp%i", ppp->unit_idx);
 
+	memset(&ifr, 0, sizeof(ifr));
+	strcpy(ifr.ifr_name, ppp->ifname);
+
+	if (ioctl(sock_fd, SIOCGIFINDEX, &ifr)) {
+		log_ppp_error("ppp: ioctl(SIOCGIFINDEX): %s\n", strerror(errno));
+		goto exit_close_unit;
+	}
+	ppp->ifindex = ifr.ifr_ifindex;
+
 	log_ppp_info1("connect: %s <--> %s(%s)\n", ppp->ifname, ppp->ctrl->name, ppp->chan_name);
-	
+
 	init_layers(ppp);
 
 	if (list_empty(&ppp->layers)) {
diff --git a/accel-pppd/ppp/ppp.h b/accel-pppd/ppp/ppp.h
index c810e4a..4708578 100644
--- a/accel-pppd/ppp/ppp.h
+++ b/accel-pppd/ppp/ppp.h
@@ -95,6 +95,7 @@ struct ppp_t
 	int state;
 	char *chan_name;
 	char ifname[PPP_IFNAME_LEN];
+	int ifindex;
 	char sessionid[PPP_SESSIONID_LEN+1];
 	time_t start_time;
 	time_t stop_time;
@@ -183,6 +184,8 @@ struct ppp_layer_data_t *ppp_find_layer_data(struct ppp_t *, struct ppp_layer_t
 extern int ppp_shutdown;
 void ppp_shutdown_soft(void);
 
+int ppp_ipv6_nd_start(struct ppp_t *ppp, uint64_t intf_id);
+
 extern int conf_ppp_verbose;
 extern int conf_single_session;
 
diff --git a/rfc/rfc4861.txt b/rfc/rfc4861.txt
new file mode 100644
index 0000000..816dda6
--- /dev/null
+++ b/rfc/rfc4861.txt
@@ -0,0 +1,5435 @@
+
+
+
+
+
+
+Network Working Group                                          T. Narten
+Request for Comments: 4861                                           IBM
+Obsoletes: 2461                                              E. Nordmark
+Category: Standards Track                               Sun Microsystems
+                                                              W. Simpson
+                                                              Daydreamer
+                                                              H. Soliman
+                                                    Elevate Technologies
+                                                          September 2007
+
+
+               Neighbor Discovery for IP version 6 (IPv6)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This document specifies the Neighbor Discovery protocol for IP
+   Version 6.  IPv6 nodes on the same link use Neighbor Discovery to
+   discover each other's presence, to determine each other's link-layer
+   addresses, to find routers, and to maintain reachability information
+   about the paths to active neighbors.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                     [Page 1]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................4
+   2. Terminology .....................................................4
+      2.1. General ....................................................4
+      2.2. Link Types .................................................8
+      2.3. Addresses ..................................................9
+      2.4. Requirements ..............................................10
+   3. Protocol Overview ..............................................10
+      3.1. Comparison with IPv4 ......................................14
+      3.2. Supported Link Types ......................................16
+      3.3. Securing Neighbor Discovery Messages ......................18
+   4. Message Formats ................................................18
+      4.1. Router Solicitation Message Format ........................18
+      4.2. Router Advertisement Message Format .......................19
+      4.3. Neighbor Solicitation Message Format ......................22
+      4.4. Neighbor Advertisement Message Format .....................23
+      4.5. Redirect Message Format ...................................26
+      4.6. Option Formats ............................................28
+           4.6.1. Source/Target Link-layer Address ...................28
+           4.6.2. Prefix Information .................................29
+           4.6.3. Redirected Header ..................................31
+           4.6.4. MTU ................................................32
+   5. Conceptual Model of a Host .....................................33
+      5.1. Conceptual Data Structures ................................33
+      5.2. Conceptual Sending Algorithm ..............................36
+      5.3. Garbage Collection and Timeout Requirements ...............37
+   6. Router and Prefix Discovery ....................................38
+      6.1. Message Validation ........................................39
+           6.1.1. Validation of Router Solicitation Messages .........39
+           6.1.2. Validation of Router Advertisement Messages ........39
+      6.2. Router Specification ......................................40
+           6.2.1. Router Configuration Variables .....................40
+           6.2.2. Becoming an Advertising Interface ..................45
+           6.2.3. Router Advertisement Message Content ...............45
+           6.2.4. Sending Unsolicited Router Advertisements ..........47
+           6.2.5. Ceasing To Be an Advertising Interface .............47
+           6.2.6. Processing Router Solicitations ....................48
+           6.2.7. Router Advertisement Consistency ...................50
+           6.2.8. Link-local Address Change ..........................50
+      6.3. Host Specification ........................................51
+           6.3.1. Host Configuration Variables .......................51
+           6.3.2. Host Variables .....................................51
+           6.3.3. Interface Initialization ...........................52
+           6.3.4. Processing Received Router Advertisements ..........53
+           6.3.5. Timing out Prefixes and Default Routers ............56
+           6.3.6. Default Router Selection ...........................56
+           6.3.7. Sending Router Solicitations .......................57
+
+
+
+Narten, et al.              Standards Track                     [Page 2]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   7. Address Resolution and Neighbor Unreachability Detection .......59
+      7.1. Message Validation ........................................59
+           7.1.1. Validation of Neighbor Solicitations ...............59
+           7.1.2. Validation of Neighbor Advertisements ..............60
+      7.2. Address Resolution ........................................60
+           7.2.1. Interface Initialization ...........................61
+           7.2.2. Sending Neighbor Solicitations .....................61
+           7.2.3. Receipt of Neighbor Solicitations ..................62
+           7.2.4. Sending Solicited Neighbor Advertisements ..........63
+           7.2.5. Receipt of Neighbor Advertisements .................64
+           7.2.6. Sending Unsolicited Neighbor Advertisements ........66
+           7.2.7. Anycast Neighbor Advertisements ....................67
+           7.2.8. Proxy Neighbor Advertisements ......................68
+      7.3. Neighbor Unreachability Detection .........................68
+           7.3.1. Reachability Confirmation ..........................69
+           7.3.2. Neighbor Cache Entry States ........................70
+           7.3.3. Node Behavior ......................................71
+   8. Redirect Function ..............................................73
+      8.1. Validation of Redirect Messages ...........................74
+      8.2. Router Specification ......................................75
+      8.3. Host Specification ........................................76
+   9. Extensibility - Option Processing ..............................76
+   10. Protocol Constants ............................................78
+   11. Security Considerations .......................................79
+      11.1. Threat Analysis ..........................................79
+      11.2. Securing Neighbor Discovery Messages .....................81
+   12. Renumbering Considerations ....................................81
+   13. IANA Considerations ...........................................83
+   14. References ....................................................84
+      14.1. Normative References .....................................84
+      14.2. Informative References ...................................84
+   Appendix A: Multihomed Hosts ......................................87
+   Appendix B: Future Extensions .....................................88
+   Appendix C: State Machine for the Reachability State ..............89
+   Appendix D: Summary of IsRouter Rules .............................91
+   Appendix E: Implementation Issues .................................92
+   Appendix F: Changes from RFC 2461 .................................94
+   Acknowledgments ...................................................95
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                     [Page 3]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+1.  Introduction
+
+   This specification defines the Neighbor Discovery (ND) protocol for
+   Internet Protocol Version 6 (IPv6).  Nodes (hosts and routers) use
+   Neighbor Discovery to determine the link-layer addresses for
+   neighbors known to reside on attached links and to quickly purge
+   cached values that become invalid.  Hosts also use Neighbor Discovery
+   to find neighboring routers that are willing to forward packets on
+   their behalf.  Finally, nodes use the protocol to actively keep track
+   of which neighbors are reachable and which are not, and to detect
+   changed link-layer addresses.  When a router or the path to a router
+   fails, a host actively searches for functioning alternates.
+
+   Unless specified otherwise (in a document that covers operating IP
+   over a particular link type) this document applies to all link types.
+   However, because ND uses link-layer multicast for some of its
+   services, it is possible that on some link types (e.g., Non-Broadcast
+   Multi-Access (NBMA) links), alternative protocols or mechanisms to
+   implement those services will be specified (in the appropriate
+   document covering the operation of IP over a particular link type).
+   The services described in this document that are not directly
+   dependent on multicast, such as Redirects, Next-hop determination,
+   Neighbor Unreachability Detection, etc., are expected to be provided
+   as specified in this document.  The details of how one uses ND on
+   NBMA links are addressed in [IPv6-NBMA].  In addition, [IPv6-3GPP]
+   and[IPv6-CELL] discuss the use of this protocol over some cellular
+   links, which are examples of NBMA links.
+
+2.  Terminology
+
+2.1.  General
+
+   IP          - Internet Protocol Version 6.  The terms IPv4 and IPv6
+                 are used only in contexts where necessary to avoid
+                 ambiguity.
+
+   ICMP        - Internet Control Message Protocol for the Internet
+                 Protocol Version 6.  The terms ICMPv4 and ICMPv6 are
+                 used only in contexts where necessary to avoid
+                 ambiguity.
+
+   node        - a device that implements IP.
+
+   router      - a node that forwards IP packets not explicitly
+                 addressed to itself.
+
+   host        - any node that is not a router.
+
+
+
+
+Narten, et al.              Standards Track                     [Page 4]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   upper layer - a protocol layer immediately above IP.  Examples are
+                 transport protocols such as TCP and UDP, control
+                 protocols such as ICMP, routing protocols such as OSPF,
+                 and Internet-layer (or lower-layer) protocols being
+                 "tunneled" over (i.e., encapsulated in) IP such as
+                 Internetwork Packet Exchange (IPX), AppleTalk, or IP
+                 itself.
+
+   link        - a communication facility or medium over which nodes can
+                 communicate at the link layer, i.e., the layer
+                 immediately below IP.  Examples are Ethernets (simple
+                 or bridged), PPP links, X.25, Frame Relay, or ATM
+                 networks as well as Internet-layer (or higher-layer)
+                 "tunnels", such as tunnels over IPv4 or IPv6 itself.
+
+   interface   - a node's attachment to a link.
+
+   neighbors   - nodes attached to the same link.
+
+   address     - an IP-layer identifier for an interface or a set of
+                 interfaces.
+
+   anycast address
+               - an identifier for a set of interfaces (typically
+                 belonging to different nodes).  A packet sent to an
+                 anycast address is delivered to one of the interfaces
+                 identified by that address (the "nearest" one,
+                 according to the routing protocol's measure of
+                 distance).  See [ADDR-ARCH].
+
+                 Note that an anycast address is syntactically
+                 indistinguishable from a unicast address.  Thus, nodes
+                 sending packets to anycast addresses don't generally
+                 know that an anycast address is being used.  Throughout
+                 the rest of this document, references to unicast
+                 addresses also apply to anycast addresses in those
+                 cases where the node is unaware that a unicast address
+                 is actually an anycast address.
+
+   prefix      - a bit string that consists of some number of initial
+                 bits of an address.
+
+   link-layer address
+               - a link-layer identifier for an interface.  Examples
+                 include IEEE 802 addresses for Ethernet links.
+
+
+
+
+
+
+Narten, et al.              Standards Track                     [Page 5]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   on-link     - an address that is assigned to an interface on a
+                 specified link.  A node considers an address to be on-
+                 link if:
+
+                    - it is covered by one of the link's prefixes (e.g.,
+                      as indicated by the on-link flag in the Prefix
+                      Information option), or
+
+                    - a neighboring router specifies the address as the
+                      target of a Redirect message, or
+
+                    - a Neighbor Advertisement message is received for
+                      the (target) address, or
+
+                    - any Neighbor Discovery message is received from
+                      the address.
+
+   off-link    - the opposite of "on-link"; an address that is not
+                 assigned to any interfaces on the specified link.
+
+   longest prefix match
+               - the process of determining which prefix (if any) in a
+                 set of prefixes covers a target address.  A target
+                 address is covered by a prefix if all of the bits in
+                 the prefix match the left-most bits of the target
+                 address.  When multiple prefixes cover an address, the
+                 longest prefix is the one that matches.
+
+   reachability
+               - whether or not the one-way "forward" path to a neighbor
+                 is functioning properly.  In particular, whether
+                 packets sent to a neighbor are reaching the IP layer on
+                 the neighboring machine and are being processed
+                 properly by the receiving IP layer.  For neighboring
+                 routers, reachability means that packets sent by a
+                 node's IP layer are delivered to the router's IP layer,
+                 and the router is indeed forwarding packets (i.e., it
+                 is configured as a router, not a host).  For hosts,
+                 reachability means that packets sent by a node's IP
+                 layer are delivered to the neighbor host's IP layer.
+
+   packet      - an IP header plus payload.
+
+   link MTU    - the maximum transmission unit, i.e., maximum packet
+                 size in octets, that can be conveyed in one
+                 transmission unit over a link.
+
+
+
+
+
+Narten, et al.              Standards Track                     [Page 6]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   target      - an address about which address resolution information
+                 is sought, or an address that is the new first hop when
+                 being redirected.
+
+   proxy       - a node that responds to Neighbor Discovery query
+                 messages on behalf of another node.  A router acting on
+                 behalf of a mobile node that has moved off-link could
+                 potentially act as a proxy for the mobile node.
+
+   ICMP destination unreachable indication
+               - an error indication returned to the original sender of
+                 a packet that cannot be delivered for the reasons
+                 outlined in [ICMPv6].  If the error occurs on a node
+                 other than the node originating the packet, an ICMP
+                 error message is generated.  If the error occurs on the
+                 originating node, an implementation is not required to
+                 actually create and send an ICMP error packet to the
+                 source, as long as the upper-layer sender is notified
+                 through an appropriate mechanism (e.g., return value
+                 from a procedure call).  Note, however, that an
+                 implementation may find it convenient in some cases to
+                 return errors to the sender by taking the offending
+                 packet, generating an ICMP error message, and then
+                 delivering it (locally) through the generic error-
+                 handling routines.
+
+   random delay
+               - when sending out messages, it is sometimes necessary to
+                 delay a transmission for a random amount of time in
+                 order to prevent multiple nodes from transmitting at
+                 exactly the same time, or to prevent long-range
+                 periodic transmissions from synchronizing with each
+                 other [SYNC].  When a random component is required, a
+                 node calculates the actual delay in such a way that the
+                 computed delay forms a uniformly distributed random
+                 value that falls between the specified minimum and
+                 maximum delay times.  The implementor must take care to
+                 ensure that the granularity of the calculated random
+                 component and the resolution of the timer used are both
+                 high enough to ensure that the probability of multiple
+                 nodes delaying the same amount of time is small.
+
+   random delay seed
+               - if a pseudo-random number generator is used in
+                 calculating a random delay component, the generator
+                 should be initialized with a unique seed prior to being
+                 used.  Note that it is not sufficient to use the
+                 interface identifier alone as the seed, since interface
+
+
+
+Narten, et al.              Standards Track                     [Page 7]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                 identifiers will not always be unique.  To reduce the
+                 probability that duplicate interface identifiers cause
+                 the same seed to be used, the seed should be calculated
+                 from a variety of input sources (e.g., machine
+                 components) that are likely to be different even on
+                 identical "boxes".  For example, the seed could be
+                 formed by combining the CPU's serial number with an
+                 interface identifier.  Additional information on
+                 randomness and random number generation can be found in
+                 [RAND].
+
+2.2.  Link Types
+
+   Different link layers have different properties.  The ones of concern
+   to Neighbor Discovery are:
+
+   multicast capable
+                  - a link that supports a native mechanism at the link
+                    layer for sending packets to all (i.e., broadcast)
+                    or a subset of all neighbors.
+
+   point-to-point - a link that connects exactly two interfaces.  A
+                    point-to-point link is assumed to have multicast
+                    capability and a link-local address.
+
+   non-broadcast multi-access (NBMA)
+                  - a link to which more than two interfaces can attach,
+                    but that does not support a native form of multicast
+                    or broadcast (e.g., X.25, ATM, frame relay, etc.).
+                    Note that all link types (including NBMA) are
+                    expected to provide multicast service for
+                    applications that need it (e.g., using multicast
+                    servers).  However, it is an issue for further study
+                    whether ND should use such facilities or an
+                    alternate mechanism that provides the equivalent
+                    multicast capability for ND.
+
+   shared media   - a link that allows direct communication among a
+                    number of nodes, but attached nodes are configured
+                    in such a way that they do not have complete prefix
+                    information for all on-link destinations.  That is,
+                    at the IP level, nodes on the same link may not know
+                    that they are neighbors; by default, they
+                    communicate through a router.  Examples are large
+                    (switched) public data networks such as Switched
+                    Multimegabit Data Service (SMDS) and Broadband
+                    Integrated Services Digital Network (B-ISDN).  Also
+                    known as "large clouds".  See [SH-MEDIA].
+
+
+
+Narten, et al.              Standards Track                     [Page 8]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   variable MTU   - a link that does not have a well-defined MTU (e.g.,
+                    IEEE 802.5 token rings).  Many links (e.g.,
+                    Ethernet) have a standard MTU defined by the link-
+                    layer protocol or by the specific document
+                    describing how to run IP over the link layer.
+
+   asymmetric reachability
+                  - a link where non-reflexive and/or non-transitive
+                    reachability is part of normal operation.  (Non-
+                    reflexive reachability means packets from A reach B,
+                    but packets from B don't reach A.  Non-transitive
+                    reachability means packets from A reach B, and
+                    packets from B reach C, but packets from A don't
+                    reach C.)  Many radio links exhibit these
+                    properties.
+
+2.3.  Addresses
+
+   Neighbor Discovery makes use of a number of different addresses
+   defined in [ADDR-ARCH], including:
+
+   all-nodes multicast address
+               - the link-local scope address to reach all nodes,
+                 FF02::1.
+
+   all-routers multicast address
+               - the link-local scope address to reach all routers,
+                 FF02::2.
+
+   solicited-node multicast address
+               - a link-local scope multicast address that is computed
+                 as a function of the solicited target's address.  The
+                 function is described in [ADDR-ARCH].  The function is
+                 chosen so that IP addresses that differ only in the
+                 most significant bits, e.g., due to multiple prefixes
+                 associated with different providers, will map to the
+                 same solicited-node address thereby reducing the number
+                 of multicast addresses a node must join at the link
+                 layer.
+
+   link-local address
+               - a unicast address having link-only scope that can be
+                 used to reach neighbors.  All interfaces on routers
+                 MUST have a link-local address.  Also, [ADDRCONF]
+                 requires that interfaces on hosts have a link-local
+                 address.
+
+
+
+
+
+Narten, et al.              Standards Track                     [Page 9]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   unspecified address
+               - a reserved address value that indicates the lack of an
+                 address (e.g., the address is unknown).  It is never
+                 used as a destination address, but may be used as a
+                 source address if the sender does not (yet) know its
+                 own address (e.g., while verifying an address is unused
+                 during stateless address autoconfiguration [ADDRCONF]).
+                 The unspecified address has a value of 0:0:0:0:0:0:0:0.
+
+   Note that this specification does not strictly comply with the
+   consistency requirements in [ADDR-SEL] for the scopes of source and
+   destination addresses.  It is possible in some cases for hosts to use
+   a source address of a larger scope than the destination address in
+   the IPv6 header.
+
+2.4.  Requirements
+
+   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
+   document, are to be interpreted as described in [KEYWORDS].
+
+   This document also makes use of internal conceptual variables to
+   describe protocol behavior and external variables that an
+   implementation must allow system administrators to change.  The
+   specific variable names, how their values change, and how their
+   settings influence protocol behavior are provided to demonstrate
+   protocol behavior.  An implementation is not required to have them in
+   the exact form described here, so long as its external behavior is
+   consistent with that described in this document.
+
+3.  Protocol Overview
+
+   This protocol solves a set of problems related to the interaction
+   between nodes attached to the same link.  It defines mechanisms for
+   solving each of the following problems:
+
+     Router Discovery: How hosts locate routers that reside on an
+                attached link.
+
+     Prefix Discovery: How hosts discover the set of address prefixes
+                that define which destinations are on-link for an
+                attached link.  (Nodes use prefixes to distinguish
+                destinations that reside on-link from those only
+                reachable through a router.)
+
+     Parameter Discovery: How a node learns link parameters (such as the
+                link MTU) or Internet parameters (such as the hop limit
+                value) to place in outgoing packets.
+
+
+
+Narten, et al.              Standards Track                    [Page 10]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+     Address Autoconfiguration: Introduces the mechanisms needed in
+                order to allow nodes to configure an address for an
+                interface in a stateless manner.  Stateless address
+                autoconfiguration is specified in [ADDRCONF].
+
+     Address resolution: How nodes determine the link-layer address of
+                an on-link destination (e.g., a neighbor) given only the
+                destination's IP address.
+
+     Next-hop determination: The algorithm for mapping an IP destination
+                address into the IP address of the neighbor to which
+                traffic for the destination should be sent.  The next-
+                hop can be a router or the destination itself.
+
+     Neighbor Unreachability Detection: How nodes determine that a
+                neighbor is no longer reachable.  For neighbors used as
+                routers, alternate default routers can be tried.  For
+                both routers and hosts, address resolution can be
+                performed again.
+
+     Duplicate Address Detection: How a node determines whether or not
+                an address it wishes to use is already in use by another
+                node.
+
+     Redirect:  How a router informs a host of a better first-hop node
+                to reach a particular destination.
+
+   Neighbor Discovery defines five different ICMP packet types: A pair
+   of Router Solicitation and Router Advertisement messages, a pair of
+   Neighbor Solicitation and Neighbor Advertisements messages, and a
+   Redirect message.  The messages serve the following purpose:
+
+     Router Solicitation: When an interface becomes enabled, hosts may
+                send out Router Solicitations that request routers to
+                generate Router Advertisements immediately rather than
+                at their next scheduled time.
+
+     Router Advertisement: Routers advertise their presence together
+                with various link and Internet parameters either
+                periodically, or in response to a Router Solicitation
+                message.  Router Advertisements contain prefixes that
+                are used for determining whether another address shares
+                the same link (on-link determination) and/or address
+                configuration, a suggested hop limit value, etc.
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 11]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+     Neighbor Solicitation: Sent by a node to determine the link-layer
+                address of a neighbor, or to verify that a neighbor is
+                still reachable via a cached link-layer address.
+                Neighbor Solicitations are also used for Duplicate
+                Address Detection.
+
+     Neighbor Advertisement: A response to a Neighbor Solicitation
+                message.  A node may also send unsolicited Neighbor
+                Advertisements to announce a link-layer address change.
+
+     Redirect:  Used by routers to inform hosts of a better first hop
+                for a destination.
+
+   On multicast-capable links, each router periodically multicasts a
+   Router Advertisement packet announcing its availability.  A host
+   receives Router Advertisements from all routers, building a list of
+   default routers.  Routers generate Router Advertisements frequently
+   enough that hosts will learn of their presence within a few minutes,
+   but not frequently enough to rely on an absence of advertisements to
+   detect router failure; a separate Neighbor Unreachability Detection
+   algorithm provides failure detection.
+
+   Router Advertisements contain a list of prefixes used for on-link
+   determination and/or autonomous address configuration; flags
+   associated with the prefixes specify the intended uses of a
+   particular prefix.  Hosts use the advertised on-link prefixes to
+   build and maintain a list that is used in deciding when a packet's
+   destination is on-link or beyond a router.  Note that a destination
+   can be on-link even though it is not covered by any advertised on-
+   link prefix.  In such cases, a router can send a Redirect informing
+   the sender that the destination is a neighbor.
+
+   Router Advertisements (and per-prefix flags) allow routers to inform
+   hosts how to perform Address Autoconfiguration.  For example, routers
+   can specify whether hosts should use DHCPv6 and/or autonomous
+   (stateless) address configuration.
+
+   Router Advertisement messages also contain Internet parameters such
+   as the hop limit that hosts should use in outgoing packets and,
+   optionally, link parameters such as the link MTU.  This facilitates
+   centralized administration of critical parameters that can be set on
+   routers and automatically propagated to all attached hosts.
+
+   Nodes accomplish address resolution by multicasting a Neighbor
+   Solicitation that asks the target node to return its link-layer
+   address.  Neighbor Solicitation messages are multicast to the
+   solicited-node multicast address of the target address.  The target
+   returns its link-layer address in a unicast Neighbor Advertisement
+
+
+
+Narten, et al.              Standards Track                    [Page 12]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   message.  A single request-response pair of packets is sufficient for
+   both the initiator and the target to resolve each other's link-layer
+   addresses; the initiator includes its link-layer address in the
+   Neighbor Solicitation.
+
+   Neighbor Solicitation messages can also be used to determine if more
+   than one node has been assigned the same unicast address.  The use of
+   Neighbor Solicitation messages for Duplicate Address Detection is
+   specified in [ADDRCONF].
+
+   Neighbor Unreachability Detection detects the failure of a neighbor
+   or the failure of the forward path to the neighbor.  Doing so
+   requires positive confirmation that packets sent to a neighbor are
+   actually reaching that neighbor and being processed properly by its
+   IP layer.  Neighbor Unreachability Detection uses confirmation from
+   two sources.  When possible, upper-layer protocols provide a positive
+   confirmation that a connection is making "forward progress", that is,
+   previously sent data is known to have been delivered correctly (e.g.,
+   new acknowledgments were received recently).  When positive
+   confirmation is not forthcoming through such "hints", a node sends
+   unicast Neighbor Solicitation messages that solicit Neighbor
+   Advertisements as reachability confirmation from the next hop.  To
+   reduce unnecessary network traffic, probe messages are only sent to
+   neighbors to which the node is actively sending packets.
+
+   In addition to addressing the above general problems, Neighbor
+   Discovery also handles the following situations:
+
+     Link-layer address change - A node that knows its link-layer
+           address has changed can multicast a few (unsolicited)
+           Neighbor Advertisement packets to all nodes to quickly update
+           cached link-layer addresses that have become invalid.  Note
+           that the sending of unsolicited advertisements is a
+           performance enhancement only (e.g., unreliable).  The
+           Neighbor Unreachability Detection algorithm ensures that all
+           nodes will reliably discover the new address, though the
+           delay may be somewhat longer.
+
+     Inbound load balancing - Nodes with replicated interfaces may want
+           to load balance the reception of incoming packets across
+           multiple network interfaces on the same link.  Such nodes
+           have multiple link-layer addresses assigned to the same
+           interface.  For example, a single network driver could
+           represent multiple network interface cards as a single
+           logical interface having multiple link-layer addresses.
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 13]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+           Neighbor Discovery allows a router to perform load balancing
+           for traffic addressed to itself by allowing routers to omit
+           the source link-layer address from Router Advertisement
+           packets, thereby forcing neighbors to use Neighbor
+           Solicitation messages to learn link-layer addresses of
+           routers.  Returned Neighbor Advertisement messages can then
+           contain link-layer addresses that differ depending on, e.g.,
+           who issued the solicitation.  This specification does not
+           define a mechanism that allows hosts to Load-balance incoming
+           packets.  See [LD-SHRE].
+
+     Anycast addresses - Anycast addresses identify one of a set of
+           nodes providing an equivalent service, and multiple nodes on
+           the same link may be configured to recognize the same anycast
+           address.  Neighbor Discovery handles anycasts by having nodes
+           expect to receive multiple Neighbor Advertisements for the
+           same target.  All advertisements for anycast addresses are
+           tagged as being non-Override advertisements.  A non-Override
+           advertisement is one that does not update or replace the
+           information sent by another advertisement.  These
+           advertisements are discussed later in the context of Neighbor
+           advertisement messages.  This invokes specific rules to
+           determine which of potentially multiple advertisements should
+           be used.
+
+     Proxy advertisements - A node willing to accept packets on behalf
+           of a target address that is unable to respond to Neighbor
+           Solicitations can issue non-Override Neighbor Advertisements.
+           Proxy advertisements are used by Mobile IPv6 Home Agents to
+           defend mobile nodes' addresses when they move off-link.
+           However, it is not intended as a general mechanism to handle
+           nodes that, e.g., do not implement this protocol.
+
+3.1.  Comparison with IPv4
+
+   The IPv6 Neighbor Discovery protocol corresponds to a combination of
+   the IPv4 protocols Address Resolution Protocol [ARP], ICMP Router
+   Discovery [RDISC], and ICMP Redirect [ICMPv4].  In IPv4 there is no
+   generally agreed upon protocol or mechanism for Neighbor
+   Unreachability Detection, although the Hosts Requirements document
+   [HR-CL] does specify some possible algorithms for Dead Gateway
+   Detection (a subset of the problems Neighbor Unreachability Detection
+   tackles).
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 14]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   The Neighbor Discovery protocol provides a multitude of improvements
+   over the IPv4 set of protocols:
+
+      Router Discovery is part of the base protocol set; there is no
+      need for hosts to "snoop" the routing protocols.
+
+      Router Advertisements carry link-layer addresses; no additional
+      packet exchange is needed to resolve the router's link-layer
+      address.
+
+      Router Advertisements carry prefixes for a link; there is no need
+      to have a separate mechanism to configure the "netmask".
+
+      Router Advertisements enable Address Autoconfiguration.
+
+      Routers can advertise an MTU for hosts to use on the link,
+      ensuring that all nodes use the same MTU value on links lacking a
+      well-defined MTU.
+
+      Address resolution multicasts are "spread" over 16 million (2^24)
+      multicast addresses, greatly reducing address-resolution-related
+      interrupts on nodes other than the target.  Moreover, non-IPv6
+      machines should not be interrupted at all.
+
+      Redirects contain the link-layer address of the new first hop;
+      separate address resolution is not needed upon receiving a
+      redirect.
+
+      Multiple prefixes can be associated with the same link.  By
+      default, hosts learn all on-link prefixes from Router
+      Advertisements.  However, routers may be configured to omit some
+      or all prefixes from Router Advertisements.  In such cases hosts
+      assume that destinations are off-link and send traffic to routers.
+      A router can then issue redirects as appropriate.
+
+      Unlike IPv4, the recipient of an IPv6 redirect assumes that the
+      new next-hop is on-link.  In IPv4, a host ignores redirects
+      specifying a next-hop that is not on-link according to the link's
+      network mask.  The IPv6 redirect mechanism is analogous to the
+      XRedirect facility specified in [SH-MEDIA].  It is expected to be
+      useful on non-broadcast and shared media links in which it is
+      undesirable or not possible for nodes to know all prefixes for
+      on-link destinations.
+
+      Neighbor Unreachability Detection is part of the base, which
+      significantly improves the robustness of packet delivery in the
+      presence of failing routers, partially failing or partitioned
+      links, or nodes that change their link-layer addresses.  For
+
+
+
+Narten, et al.              Standards Track                    [Page 15]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      instance, mobile nodes can move off-link without losing any
+      connectivity due to stale ARP caches.
+
+      Unlike ARP, Neighbor Discovery detects half-link failures (using
+      Neighbor Unreachability Detection) and avoids sending traffic to
+      neighbors with which two-way connectivity is absent.
+
+      Unlike in IPv4 Router Discovery, the Router Advertisement messages
+      do not contain a preference field.  The preference field is not
+      needed to handle routers of different "stability"; the Neighbor
+      Unreachability Detection will detect dead routers and switch to a
+      working one.
+
+      The use of link-local addresses to uniquely identify routers (for
+      Router Advertisement and Redirect messages) makes it possible for
+      hosts to maintain the router associations in the event of the site
+      renumbering to use new global prefixes.
+
+      By setting the Hop Limit to 255, Neighbor Discovery is immune to
+      off-link senders that accidentally or intentionally send ND
+      messages.  In IPv4, off-link senders can send both ICMP Redirects
+      and Router Advertisement messages.
+
+      Placing address resolution at the ICMP layer makes the protocol
+      more media-independent than ARP and makes it possible to use
+      generic IP-layer authentication and security mechanisms as
+      appropriate.
+
+3.2.  Supported Link Types
+
+   Neighbor Discovery supports links with different properties.  In the
+   presence of certain properties, only a subset of the ND protocol
+   mechanisms are fully specified in this document:
+
+     point-to-point - Neighbor Discovery handles such links just like
+                      multicast links.  (Multicast can be trivially
+                      provided on point-to-point links, and interfaces
+                      can be assigned link-local addresses.)
+
+     multicast      - Neighbor Discovery operates over multicast capable
+                      links as described in this document.
+
+     non-broadcast multiple access (NBMA)
+                    - Redirect, Neighbor Unreachability Detection and
+                      next-hop determination should be implemented as
+                      described in this document.  Address resolution,
+                      and the mechanism for delivering Router
+                      Solicitations and Advertisements on NBMA links are
+
+
+
+Narten, et al.              Standards Track                    [Page 16]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                      not specified in this document.  Note that if
+                      hosts support manual configuration of a list of
+                      default routers, hosts can dynamically acquire the
+                      link-layer addresses for their neighbors from
+                      Redirect messages.
+
+     shared media   - The Redirect message is modeled after the
+                      XRedirect message in [SH-MEDIA] in order to
+                      simplify use of the protocol on shared media
+                      links.
+
+                      This specification does not address shared media
+                      issues that only relate to routers, such as:
+
+                       - How routers exchange reachability information
+                         on a shared media link.
+
+                       - How a router determines the link-layer address
+                         of a host, which it needs to send redirect
+                         messages to the host.
+
+                       - How a router determines that it is the first-
+                         hop router for a received packet.
+
+                      The protocol is extensible (through the definition
+                      of new options) so that other solutions might be
+                      possible in the future.
+
+     variable MTU   - Neighbor Discovery allows routers to specify an
+                      MTU for the link, which all nodes then use.  All
+                      nodes on a link must use the same MTU (or Maximum
+                      Receive Unit) in order for multicast to work
+                      properly.  Otherwise, when multicasting, a sender,
+                      which can not know which nodes will receive the
+                      packet, could not determine a minimum packet size
+                      that all receivers can process (or Maximum Receive
+                      Unit).
+
+     asymmetric reachability
+                    - Neighbor Discovery detects the absence of
+                      symmetric reachability; a node avoids paths to a
+                      neighbor with which it does not have symmetric
+                      connectivity.
+
+                      The Neighbor Unreachability Detection will
+                      typically identify such half-links and the node
+                      will refrain from using them.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 17]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                      The protocol can presumably be extended in the
+                      future to find viable paths in environments that
+                      lack reflexive and transitive connectivity.
+
+3.3.  Securing Neighbor Discovery Messages
+
+   Neighbor Discovery messages are needed for various functions.
+   Several functions are designed to allow hosts to ascertain the
+   ownership of an address or the mapping between link-layer and IP-
+   layer addresses.  Vulnerabilities related to Neighbor Discovery are
+   discussed in Section 11.1.  A general solution for securing Neighbor
+   Discovery is outside the scope of this specification and is discussed
+   in [SEND].  However, Section 11.2 explains how and under which
+   constraints IPsec Authentication Header (AH) or Encapsulating
+   Security Payload (ESP) can be used to secure Neighbor Discovery.
+
+4.  Message Formats
+
+   This section introduces message formats for all messages used in this
+   specification.
+
+4.1.  Router Solicitation Message Format
+
+   Hosts send Router Solicitations in order to prompt routers to
+   generate Router Advertisements quickly.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                            Reserved                           |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...
+     +-+-+-+-+-+-+-+-+-+-+-+-
+
+   IP Fields:
+
+      Source Address
+                     An IP address assigned to the sending interface, or
+                     the unspecified address if no address is assigned
+                     to the sending interface.
+
+      Destination Address
+                     Typically the all-routers multicast address.
+
+      Hop Limit      255
+
+
+
+
+Narten, et al.              Standards Track                    [Page 18]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   ICMP Fields:
+
+      Type           133
+
+      Code           0
+
+      Checksum       The ICMP checksum.  See [ICMPv6].
+
+      Reserved       This field is unused.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+   Valid Options:
+
+      Source link-layer address The link-layer address of the sender, if
+                     known.  MUST NOT be included if the Source Address
+                     is the unspecified address.  Otherwise, it SHOULD
+                     be included on link layers that have addresses.
+
+      Future versions of this protocol may define new option types.
+      Receivers MUST silently ignore any options they do not recognize
+      and continue processing the message.
+
+4.2.  Router Advertisement Message Format
+
+   Routers send out Router Advertisement messages periodically, or in
+   response to Router Solicitations.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     | Cur Hop Limit |M|O|  Reserved |       Router Lifetime         |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                         Reachable Time                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                          Retrans Timer                        |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...
+     +-+-+-+-+-+-+-+-+-+-+-+-
+
+   IP Fields:
+
+      Source Address
+                     MUST be the link-local address assigned to the
+                     interface from which this message is sent.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 19]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Destination Address
+                     Typically the Source Address of an invoking Router
+                     Solicitation or the all-nodes multicast address.
+
+      Hop Limit      255
+
+   ICMP Fields:
+
+      Type           134
+
+      Code           0
+
+      Checksum       The ICMP checksum.  See [ICMPv6].
+
+      Cur Hop Limit  8-bit unsigned integer.  The default value that
+                     should be placed in the Hop Count field of the IP
+                     header for outgoing IP packets.  A value of zero
+                     means unspecified (by this router).
+
+      M              1-bit "Managed address configuration" flag.  When
+                     set, it indicates that addresses are available via
+                     Dynamic Host Configuration Protocol [DHCPv6].
+
+                     If the M flag is set, the O flag is redundant and
+                     can be ignored because DHCPv6 will return all
+                     available configuration information.
+
+      O              1-bit "Other configuration" flag.  When set, it
+                     indicates that other configuration information is
+                     available via DHCPv6.  Examples of such information
+                     are DNS-related information or information on other
+                     servers within the network.
+
+        Note: If neither M nor O flags are set, this indicates that no
+        information is available via DHCPv6.
+
+      Reserved       A 6-bit unused field.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      Router Lifetime
+                     16-bit unsigned integer.  The lifetime associated
+                     with the default router in units of seconds.  The
+                     field can contain values up to 65535 and receivers
+                     should handle any value, while the sending rules in
+                     Section 6 limit the lifetime to 9000 seconds.  A
+                     Lifetime of 0 indicates that the router is not a
+                     default router and SHOULD NOT appear on the default
+
+
+
+Narten, et al.              Standards Track                    [Page 20]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                     router list.  The Router Lifetime applies only to
+                     the router's usefulness as a default router; it
+                     does not apply to information contained in other
+                     message fields or options.  Options that need time
+                     limits for their information include their own
+                     lifetime fields.
+
+      Reachable Time 32-bit unsigned integer.  The time, in
+                     milliseconds, that a node assumes a neighbor is
+                     reachable after having received a reachability
+                     confirmation.  Used by the Neighbor Unreachability
+                     Detection algorithm (see Section 7.3).  A value of
+                     zero means unspecified (by this router).
+
+      Retrans Timer  32-bit unsigned integer.  The time, in
+                     milliseconds, between retransmitted Neighbor
+                     Solicitation messages.  Used by address resolution
+                     and the Neighbor Unreachability Detection algorithm
+                     (see Sections 7.2 and 7.3).  A value of zero means
+                     unspecified (by this router).
+
+   Possible options:
+
+      Source link-layer address
+                     The link-layer address of the interface from which
+                     the Router Advertisement is sent.  Only used on
+                     link layers that have addresses.  A router MAY omit
+                     this option in order to enable inbound load sharing
+                     across multiple link-layer addresses.
+
+      MTU            SHOULD be sent on links that have a variable MTU
+                     (as specified in the document that describes how to
+                     run IP over the particular link type).  MAY be sent
+                     on other links.
+
+      Prefix Information
+                     These options specify the prefixes that are on-link
+                     and/or are used for stateless address
+                     autoconfiguration.  A router SHOULD include all its
+                     on-link prefixes (except the link-local prefix) so
+                     that multihomed hosts have complete prefix
+                     information about on-link destinations for the
+                     links to which they attach.  If complete
+                     information is lacking, a host with multiple
+                     interfaces may not be able to choose the correct
+                     outgoing interface when sending traffic to its
+                     neighbors.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 21]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Future versions of this protocol may define new option types.
+      Receivers MUST silently ignore any options they do not recognize
+      and continue processing the message.
+
+4.3.  Neighbor Solicitation Message Format
+
+   Nodes send Neighbor Solicitations to request the link-layer address
+   of a target node while also providing their own link-layer address to
+   the target.  Neighbor Solicitations are multicast when the node needs
+   to resolve an address and unicast when the node seeks to verify the
+   reachability of a neighbor.
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |     Code      |          Checksum             |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Reserved                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +                       Target Address                          +
+     |                                                               |
+     +                                                               +
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |   Options ...
+     +-+-+-+-+-+-+-+-+-+-+-+-
+
+    IP Fields:
+
+      Source Address
+                     Either an address assigned to the interface from
+                     which this message is sent or (if Duplicate Address
+                     Detection is in progress [ADDRCONF]) the
+                     unspecified address.
+      Destination Address
+                     Either the solicited-node multicast address
+                     corresponding to the target address, or the target
+                     address.
+      Hop Limit      255
+
+   ICMP Fields:
+
+      Type           135
+
+      Code           0
+
+
+
+Narten, et al.              Standards Track                    [Page 22]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Checksum       The ICMP checksum.  See [ICMPv6].
+
+      Reserved       This field is unused.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      Target Address The IP address of the target of the solicitation.
+                     It MUST NOT be a multicast address.
+
+   Possible options:
+
+      Source link-layer address
+                     The link-layer address for the sender.  MUST NOT be
+                     included when the source IP address is the
+                     unspecified address.  Otherwise, on link layers
+                     that have addresses this option MUST be included in
+                     multicast solicitations and SHOULD be included in
+                     unicast solicitations.
+
+      Future versions of this protocol may define new option types.
+      Receivers MUST silently ignore any options they do not recognize
+      and continue processing the message.
+
+4.4.  Neighbor Advertisement Message Format
+
+   A node sends Neighbor Advertisements in response to Neighbor
+   Solicitations and sends unsolicited Neighbor Advertisements in order
+   to (unreliably) propagate new information quickly.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |     Code      |          Checksum             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |R|S|O|                     Reserved                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                       Target Address                          +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Options ...
+      +-+-+-+-+-+-+-+-+-+-+-+-
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 23]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   IP Fields:
+
+      Source Address
+                     An address assigned to the interface from which the
+                     advertisement is sent.
+      Destination Address
+                     For solicited advertisements, the Source Address of
+                     an invoking Neighbor Solicitation or, if the
+                     solicitation's Source Address is the unspecified
+                     address, the all-nodes multicast address.
+
+                     For unsolicited advertisements typically the all-
+                     nodes multicast address.
+
+      Hop Limit      255
+
+   ICMP Fields:
+
+      Type           136
+
+      Code           0
+
+      Checksum       The ICMP checksum.  See [ICMPv6].
+
+      R              Router flag.  When set, the R-bit indicates that
+                     the sender is a router.  The R-bit is used by
+                     Neighbor Unreachability Detection to detect a
+                     router that changes to a host.
+
+      S              Solicited flag.  When set, the S-bit indicates that
+                     the advertisement was sent in response to a
+                     Neighbor Solicitation from the Destination address.
+                     The S-bit is used as a reachability confirmation
+                     for Neighbor Unreachability Detection.  It MUST NOT
+                     be set in multicast advertisements or in
+                     unsolicited unicast advertisements.
+
+      O              Override flag.  When set, the O-bit indicates that
+                     the advertisement should override an existing cache
+                     entry and update the cached link-layer address.
+                     When it is not set the advertisement will not
+                     update a cached link-layer address though it will
+                     update an existing Neighbor Cache entry for which
+                     no link-layer address is known.  It SHOULD NOT be
+                     set in solicited advertisements for anycast
+                     addresses and in solicited proxy advertisements.
+                     It SHOULD be set in other solicited advertisements
+                     and in unsolicited advertisements.
+
+
+
+Narten, et al.              Standards Track                    [Page 24]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Reserved       29-bit unused field.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      Target Address
+                     For solicited advertisements, the Target Address
+                     field in the Neighbor Solicitation message that
+                     prompted this advertisement.  For an unsolicited
+                     advertisement, the address whose link-layer address
+                     has changed.  The Target Address MUST NOT be a
+                     multicast address.
+
+   Possible options:
+
+      Target link-layer address
+                     The link-layer address for the target, i.e., the
+                     sender of the advertisement.  This option MUST be
+                     included on link layers that have addresses when
+                     responding to multicast solicitations.  When
+                     responding to a unicast Neighbor Solicitation this
+                     option SHOULD be included.
+
+                     The option MUST be included for multicast
+                     solicitations in order to avoid infinite Neighbor
+                     Solicitation "recursion" when the peer node does
+                     not have a cache entry to return a Neighbor
+                     Advertisements message.  When responding to unicast
+                     solicitations, the option can be omitted since the
+                     sender of the solicitation has the correct link-
+                     layer address; otherwise, it would not be able to
+                     send the unicast solicitation in the first place.
+                     However, including the link-layer address in this
+                     case adds little overhead and eliminates a
+                     potential race condition where the sender deletes
+                     the cached link-layer address prior to receiving a
+                     response to a previous solicitation.
+
+      Future versions of this protocol may define new option types.
+      Receivers MUST silently ignore any options they do not recognize
+      and continue processing the message.
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 25]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+4.5.  Redirect Message Format
+
+   Routers send Redirect packets to inform a host of a better first-hop
+   node on the path to a destination.  Hosts can be redirected to a
+   better first-hop router but can also be informed by a redirect that
+   the destination is in fact a neighbor.  The latter is accomplished by
+   setting the ICMP Target Address equal to the ICMP Destination
+   Address.
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |     Code      |          Checksum             |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Reserved                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                       Target Address                          +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                     Destination Address                       +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |   Options ...
+      +-+-+-+-+-+-+-+-+-+-+-+-
+
+   IP Fields:
+
+      Source Address
+                     MUST be the link-local address assigned to the
+                     interface from which this message is sent.
+
+     Destination Address
+                     The Source Address of the packet that triggered the
+                     redirect.
+
+      Hop Limit      255
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 26]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   ICMP Fields:
+
+      Type           137
+
+      Code           0
+
+      Checksum       The ICMP checksum.  See [ICMPv6].
+
+      Reserved       This field is unused.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      Target Address
+                     An IP address that is a better first hop to use for
+                     the ICMP Destination Address.  When the target is
+                     the actual endpoint of communication, i.e., the
+                     destination is a neighbor, the Target Address field
+                     MUST contain the same value as the ICMP Destination
+                     Address field.  Otherwise, the target is a better
+                     first-hop router and the Target Address MUST be the
+                     router's link-local address so that hosts can
+                     uniquely identify routers.
+
+      Destination Address
+                     The IP address of the destination that is
+                     redirected to the target.
+
+   Possible options:
+
+      Target link-layer address
+                     The link-layer address for the target.  It SHOULD
+                     be included (if known).  Note that on NBMA links,
+                     hosts may rely on the presence of the Target Link-
+                     Layer Address option in Redirect messages as the
+                     means for determining the link-layer addresses of
+                     neighbors.  In such cases, the option MUST be
+                     included in Redirect messages.
+
+      Redirected Header
+                     As much as possible of the IP packet that triggered
+                     the sending of the Redirect without making the
+                     redirect packet exceed the minimum MTU specified in
+                     [IPv6].
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 27]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+4.6.  Option Formats
+
+   Neighbor Discovery messages include zero or more options, some of
+   which may appear multiple times in the same message.  Options should
+   be padded when necessary to ensure that they end on their natural
+   64-bit boundaries.  All options are of the form:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |     Type      |    Length     |              ...              |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       ~                              ...                              ~
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+      Type           8-bit identifier of the type of option.  The
+                     options defined in this document are:
+
+                           Option Name                             Type
+
+                        Source Link-Layer Address                    1
+                        Target Link-Layer Address                    2
+                        Prefix Information                           3
+                        Redirected Header                            4
+                        MTU                                          5
+
+      Length         8-bit unsigned integer.  The length of the option
+                     (including the type and length fields) in units of
+                     8 octets.  The value 0 is invalid.  Nodes MUST
+                     silently discard an ND packet that contains an
+                     option with length zero.
+
+4.6.1.  Source/Target Link-layer Address
+
+      0                   1                   2                   3
+      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |     Type      |    Length     |    Link-Layer Address ...
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+      Type
+                     1 for Source Link-layer Address
+                     2 for Target Link-layer Address
+
+
+
+
+Narten, et al.              Standards Track                    [Page 28]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Length         The length of the option (including the type and
+                     length fields) in units of 8 octets.  For example,
+                     the length for IEEE 802 addresses is 1
+                     [IPv6-ETHER].
+
+      Link-Layer Address
+                     The variable length link-layer address.
+
+                     The content and format of this field (including
+                     byte and bit ordering) is expected to be specified
+                     in specific documents that describe how IPv6
+                     operates over different link layers.  For instance,
+                     [IPv6-ETHER].
+
+   Description
+                     The Source Link-Layer Address option contains the
+                     link-layer address of the sender of the packet.  It
+                     is used in the Neighbor Solicitation, Router
+                     Solicitation, and Router Advertisement packets.
+
+                     The Target Link-Layer Address option contains the
+                     link-layer address of the target.  It is used in
+                     Neighbor Advertisement and Redirect packets.
+
+                     These options MUST be silently ignored for other
+                     Neighbor Discovery messages.
+
+4.6.2.  Prefix Information
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     | Prefix Length |L|A| Reserved1 |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                         Valid Lifetime                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       Preferred Lifetime                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Reserved2                           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +                            Prefix                             +
+      |                                                               |
+      +                                                               +
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+Narten, et al.              Standards Track                    [Page 29]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Fields:
+
+      Type           3
+
+      Length         4
+
+      Prefix Length  8-bit unsigned integer.  The number of leading bits
+                     in the Prefix that are valid.  The value ranges
+                     from 0 to 128.  The prefix length field provides
+                     necessary information for on-link determination
+                     (when combined with the L flag in the prefix
+                     information option).  It also assists with address
+                     autoconfiguration as specified in [ADDRCONF], for
+                     which there may be more restrictions on the prefix
+                     length.
+
+      L              1-bit on-link flag.  When set, indicates that this
+                     prefix can be used for on-link determination.  When
+                     not set the advertisement makes no statement about
+                     on-link or off-link properties of the prefix.  In
+                     other words, if the L flag is not set a host MUST
+                     NOT conclude that an address derived from the
+                     prefix is off-link.  That is, it MUST NOT update a
+                     previous indication that the address is on-link.
+
+      A              1-bit autonomous address-configuration flag.  When
+                     set indicates that this prefix can be used for
+                     stateless address configuration as specified in
+                     [ADDRCONF].
+
+      Reserved1      6-bit unused field.  It MUST be initialized to zero
+                     by the sender and MUST be ignored by the receiver.
+
+      Valid Lifetime
+                     32-bit unsigned integer.  The length of time in
+                     seconds (relative to the time the packet is sent)
+                     that the prefix is valid for the purpose of on-link
+                     determination.  A value of all one bits
+                     (0xffffffff) represents infinity.  The Valid
+                     Lifetime is also used by [ADDRCONF].
+
+      Preferred Lifetime
+                     32-bit unsigned integer.  The length of time in
+                     seconds (relative to the time the packet is sent)
+                     that addresses generated from the prefix via
+                     stateless address autoconfiguration remain
+                     preferred [ADDRCONF].  A value of all one bits
+                     (0xffffffff) represents infinity.  See [ADDRCONF].
+
+
+
+Narten, et al.              Standards Track                    [Page 30]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                     Note that the value of this field MUST NOT exceed
+                     the Valid Lifetime field to avoid preferring
+                     addresses that are no longer valid.
+
+      Reserved2      This field is unused.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      Prefix         An IP address or a prefix of an IP address.  The
+                     Prefix Length field contains the number of valid
+                     leading bits in the prefix.  The bits in the prefix
+                     after the prefix length are reserved and MUST be
+                     initialized to zero by the sender and ignored by
+                     the receiver.  A router SHOULD NOT send a prefix
+                     option for the link-local prefix and a host SHOULD
+                     ignore such a prefix option.
+
+   Description
+                     The Prefix Information option provide hosts with
+                     on-link prefixes and prefixes for Address
+                     Autoconfiguration.  The Prefix Information option
+                     appears in Router Advertisement packets and MUST be
+                     silently ignored for other messages.
+
+4.6.3.  Redirected Header
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |            Reserved           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                           Reserved                            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      ~                       IP header + data                        ~
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+      Type           4
+
+      Length         The length of the option in units of 8 octets.
+
+      Reserved       These fields are unused.  They MUST be initialized
+                     to zero by the sender and MUST be ignored by the
+                     receiver.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 31]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      IP header + data
+                     The original packet truncated to ensure that the
+                     size of the redirect message does not exceed the
+                     minimum MTU required to support IPv6 as specified
+                     in [IPv6].
+
+   Description
+                     The Redirected Header option is used in Redirect
+                     messages and contains all or part of the packet
+                     that is being redirected.
+
+                     This option MUST be silently ignored for other
+                     Neighbor Discovery messages.
+
+4.6.4.  MTU
+
+       0                   1                   2                   3
+       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |     Type      |    Length     |           Reserved            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              MTU                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   Fields:
+
+      Type           5
+
+      Length         1
+
+      Reserved       This field is unused.  It MUST be initialized to
+                     zero by the sender and MUST be ignored by the
+                     receiver.
+
+      MTU            32-bit unsigned integer.  The recommended MTU for
+                     the link.
+
+   Description
+                     The MTU option is used in Router Advertisement
+                     messages to ensure that all nodes on a link use the
+                     same MTU value in those cases where the link MTU is
+                     not well known.
+
+                     This option MUST be silently ignored for other
+                     Neighbor Discovery messages.
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 32]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                     In configurations in which heterogeneous
+                     technologies are bridged together, the maximum
+                     supported MTU may differ from one segment to
+                     another.  If the bridges do not generate ICMP
+                     Packet Too Big messages, communicating nodes will
+                     be unable to use Path MTU to dynamically determine
+                     the appropriate MTU on a per-neighbor basis.  In
+                     such cases, routers can be configured to use the
+                     MTU option to specify the maximum MTU value that is
+                     supported by all segments.
+
+5.  Conceptual Model of a Host
+
+   This section describes a conceptual model of one possible data
+   structure organization that hosts (and, to some extent, routers) will
+   maintain in interacting with neighboring nodes.  The described
+   organization is provided to facilitate the explanation of how the
+   Neighbor Discovery protocol should behave.  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.
+
+   This model is only concerned with the aspects of host behavior
+   directly related to Neighbor Discovery.  In particular, it does not
+   concern itself with such issues as source address selection or the
+   selecting of an outgoing interface on a multihomed host.
+
+5.1.  Conceptual Data Structures
+
+   Hosts will need to maintain the following pieces of information for
+   each interface:
+
+      Neighbor Cache
+                   - A set of entries about individual neighbors to
+                     which traffic has been sent recently.  Entries are
+                     keyed on the neighbor's on-link unicast IP address
+                     and contain such information as its link-layer
+                     address, a flag indicating whether the neighbor is
+                     a router or a host (called IsRouter in this
+                     document), a pointer to any queued packets waiting
+                     for address resolution to complete, etc.  A
+                     Neighbor Cache entry also contains information used
+                     by the Neighbor Unreachability Detection algorithm,
+                     including the reachability state, the number of
+                     unanswered probes, and the time the next Neighbor
+                     Unreachability Detection event is scheduled to take
+                     place.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 33]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      Destination Cache
+                   - A set of entries about destinations to which
+                     traffic has been sent recently.  The Destination
+                     Cache includes both on-link and off-link
+                     destinations and provides a level of indirection
+                     into the Neighbor Cache; the Destination Cache maps
+                     a destination IP address to the IP address of the
+                     next-hop neighbor.  This cache is updated with
+                     information learned from Redirect messages.
+                     Implementations may find it convenient to store
+                     additional information not directly related to
+                     Neighbor Discovery in Destination Cache entries,
+                     such as the Path MTU (PMTU) and round-trip timers
+                     maintained by transport protocols.
+
+      Prefix List  - A list of the prefixes that define a set of
+                     addresses that are on-link.  Prefix List entries
+                     are created from information received in Router
+                     Advertisements.  Each entry has an associated
+                     invalidation timer value (extracted from the
+                     advertisement) used to expire prefixes when they
+                     become invalid.  A special "infinity" timer value
+                     specifies that a prefix remains valid forever,
+                     unless a new (finite) value is received in a
+                     subsequent advertisement.
+
+                     The link-local prefix is considered to be on the
+                     prefix list with an infinite invalidation timer
+                     regardless of whether routers are advertising a
+                     prefix for it.  Received Router Advertisements
+                     SHOULD NOT modify the invalidation timer for the
+                     link-local prefix.
+
+      Default Router List
+                   - A list of routers to which packets may be sent.
+                     Router list entries point to entries in the
+                     Neighbor Cache; the algorithm for selecting a
+                     default router favors routers known to be reachable
+                     over those whose reachability is suspect.  Each
+                     entry also has an associated invalidation timer
+                     value (extracted from Router Advertisements) used
+                     to delete entries that are no longer advertised.
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 34]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Note that the above conceptual data structures can be implemented
+   using a variety of techniques.  One possible implementation is to use
+   a single longest-match routing table for all of the above data
+   structures.  Regardless of the specific implementation, it is
+   critical that the Neighbor Cache entry for a router is shared by all
+   Destination Cache entries using that router in order to prevent
+   redundant Neighbor Unreachability Detection probes.
+
+   Note also that other protocols (e.g., Mobile IPv6) might add
+   additional conceptual data structures.  An implementation is at
+   liberty to implement such data structures in any way it pleases.  For
+   example, an implementation could merge all conceptual data structures
+   into a single routing table.
+
+   The Neighbor Cache contains information maintained by the Neighbor
+   Unreachability Detection algorithm.  A key piece of information is a
+   neighbor's reachability state, which is one of five possible values.
+   The following definitions are informal; precise definitions can be
+   found in Section 7.3.2.
+
+      INCOMPLETE  Address resolution is in progress and the link-layer
+                  address of the neighbor has not yet been determined.
+
+      REACHABLE   Roughly speaking, the neighbor is known to have been
+                  reachable recently (within tens of seconds ago).
+
+      STALE       The neighbor is no longer known to be reachable but
+                  until traffic is sent to the neighbor, no attempt
+                  should be made to verify its reachability.
+
+      DELAY       The neighbor is no longer known to be reachable, and
+                  traffic has recently been sent to the neighbor.
+                  Rather than probe the neighbor immediately, however,
+                  delay sending probes for a short while in order to
+                  give upper-layer protocols a chance to provide
+                  reachability confirmation.
+
+      PROBE       The neighbor is no longer known to be reachable, and
+                  unicast Neighbor Solicitation probes are being sent to
+                  verify reachability.
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 35]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+5.2.  Conceptual Sending Algorithm
+
+   When sending a packet to a destination, a node uses a combination of
+   the Destination Cache, the Prefix List, and the Default Router List
+   to determine the IP address of the appropriate next hop, an operation
+   known as "next-hop determination".  Once the IP address of the next
+   hop is known, the Neighbor Cache is consulted for link-layer
+   information about that neighbor.
+
+   Next-hop determination for a given unicast destination operates as
+   follows.  The sender performs a longest prefix match against the
+   Prefix List to determine whether the packet's destination is on- or
+   off-link.  If the destination is on-link, the next-hop address is the
+   same as the packet's destination address.  Otherwise, the sender
+   selects a router from the Default Router List (following the rules
+   described in Section 6.3.6).
+
+   For efficiency reasons, next-hop determination is not performed on
+   every packet that is sent.  Instead, the results of next-hop
+   determination computations are saved in the Destination Cache (which
+   also contains updates learned from Redirect messages).  When the
+   sending node has a packet to send, it first examines the Destination
+   Cache.  If no entry exists for the destination, next-hop
+   determination is invoked to create a Destination Cache entry.
+
+   Once the IP address of the next-hop node is known, the sender
+   examines the Neighbor Cache for link-layer information about that
+   neighbor.  If no entry exists, the sender creates one, sets its state
+   to INCOMPLETE, initiates Address Resolution, and then queues the data
+   packet pending completion of address resolution.  For multicast-
+   capable interfaces Address Resolution consists of sending a Neighbor
+   Solicitation message and waiting for a Neighbor Advertisement.  When
+   a Neighbor Advertisement response is received, the link-layer
+   addresses is entered in the Neighbor Cache entry and the queued
+   packet is transmitted.  The address resolution mechanism is described
+   in detail in Section 7.2.
+
+   For multicast packets, the next-hop is always the (multicast)
+   destination address and is considered to be on-link.  The procedure
+   for determining the link-layer address corresponding to a given IP
+   multicast address can be found in a separate document that covers
+   operating IP over a particular link type (e.g., [IPv6-ETHER]).
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 36]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Each time a Neighbor Cache entry is accessed while transmitting a
+   unicast packet, the sender checks Neighbor Unreachability Detection
+   related information according to the Neighbor Unreachability
+   Detection algorithm (Section 7.3).  This unreachability check might
+   result in the sender transmitting a unicast Neighbor Solicitation to
+   verify that the neighbor is still reachable.
+
+   Next-hop determination is done the first time traffic is sent to a
+   destination.  As long as subsequent communication to that destination
+   proceeds successfully, the Destination Cache entry continues to be
+   used.  If at some point communication ceases to proceed, as
+   determined by the Neighbor Unreachability Detection algorithm, next-
+   hop determination may need to be performed again.  For example,
+   traffic through a failed router should be switched to a working
+   router.  Likewise, it may be possible to reroute traffic destined for
+   a mobile node to a "mobility agent".
+
+   Note that when a node redoes next-hop determination there is no need
+   to discard the complete Destination Cache entry.  In fact, it is
+   generally beneficial to retain such cached information as the PMTU
+   and round-trip timer values that may also be kept in the Destination
+   Cache entry.
+
+   Routers and multihomed hosts have multiple interfaces.  The remainder
+   of this document assumes that all sent and received Neighbor
+   Discovery messages refer to the interface of appropriate context.
+   For example, when responding to a Router Solicitation, the
+   corresponding Router Advertisement is sent out the interface on which
+   the solicitation was received.
+
+5.3.  Garbage Collection and Timeout Requirements
+
+   The conceptual data structures described above use different
+   mechanisms for discarding potentially stale or unused information.
+
+   From the perspective of correctness, there is no need to periodically
+   purge Destination and Neighbor Cache entries.  Although stale
+   information can potentially remain in the cache indefinitely, the
+   Neighbor Unreachability Detection algorithm ensures that stale
+   information is purged quickly if it is actually being used.
+
+   To limit the storage needed for the Destination and Neighbor Caches,
+   a node may need to garbage-collect old entries.  However, care must
+   be taken to ensure that sufficient space is always present to hold
+   the working set of active entries.  A small cache may result in an
+   excessive number of Neighbor Discovery messages if entries are
+   discarded and rebuilt in quick succession.  Any Least Recently Used
+   (LRU)-based policy that only reclaims entries that have not been used
+
+
+
+Narten, et al.              Standards Track                    [Page 37]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   in some time (e.g., ten minutes or more) should be adequate for
+   garbage-collecting unused entries.
+
+   A node should retain entries in the Default Router List and the
+   Prefix List until their lifetimes expire.  However, a node may
+   garbage-collect entries prematurely if it is low on memory.  If not
+   all routers are kept on the Default Router list, a node should retain
+   at least two entries in the Default Router List (and preferably more)
+   in order to maintain robust connectivity for off-link destinations.
+
+   When removing an entry from the Prefix List, there is no need to
+   purge any entries from the Destination or Neighbor Caches.  Neighbor
+   Unreachability Detection will efficiently purge any entries in these
+   caches that have become invalid.  When removing an entry from the
+   Default Router List, however, any entries in the Destination Cache
+   that go through that router must perform next-hop determination again
+   to select a new default router.
+
+6.  Router and Prefix Discovery
+
+   This section describes router and host behavior related to the Router
+   Discovery portion of Neighbor Discovery.  Router Discovery is used to
+   locate neighboring routers as well as learn prefixes and
+   configuration parameters related to stateless address
+   autoconfiguration.
+
+   Prefix Discovery is the process through which hosts learn the ranges
+   of IP addresses that reside on-link and can be reached directly
+   without going through a router.  Routers send Router Advertisements
+   that indicate whether the sender is willing to be a default router.
+   Router Advertisements also contain Prefix Information options that
+   list the set of prefixes that identify on-link IP addresses.
+
+   Stateless Address Autoconfiguration must also obtain subnet prefixes
+   as part of configuring addresses.  Although the prefixes used for
+   address autoconfiguration are logically distinct from those used for
+   on-link determination, autoconfiguration information is piggybacked
+   on Router Discovery messages to reduce network traffic.  Indeed, the
+   same prefixes can be advertised for on-link determination and address
+   autoconfiguration by specifying the appropriate flags in the Prefix
+   Information options.  See [ADDRCONF] for details on how
+   autoconfiguration information is processed.
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 38]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+6.1.  Message Validation
+
+6.1.1.  Validation of Router Solicitation Messages
+
+   Hosts MUST silently discard any received Router Solicitation
+   Messages.
+
+   A router MUST silently discard any received Router Solicitation
+   messages that do not satisfy all of the following validity checks:
+
+      - The IP Hop Limit field has a value of 255, i.e., the packet
+        could not possibly have been forwarded by a router.
+
+      - ICMP Checksum is valid.
+
+      - ICMP Code is 0.
+
+      - ICMP length (derived from the IP length) is 8 or more octets.
+
+      - All included options have a length that is greater than zero.
+
+      - If the IP source address is the unspecified address, there is no
+        source link-layer address option in the message.
+
+   The contents of the Reserved field, and of any unrecognized options,
+   MUST be ignored.  Future, backward-compatible changes to the protocol
+   may specify the contents of the Reserved field or add new options;
+   backward-incompatible changes may use different Code values.
+
+   The contents of any defined options that are not specified to be used
+   with Router Solicitation messages MUST be ignored and the packet
+   processed as normal.  The only defined option that may appear is the
+   Source Link-Layer Address option.
+
+   A solicitation that passes the validity checks is called a "valid
+   solicitation".
+
+6.1.2.  Validation of Router Advertisement Messages
+
+   A node MUST silently discard any received Router Advertisement
+   messages that do not satisfy all of the following validity checks:
+
+      - IP Source Address is a link-local address.  Routers must use
+        their link-local address as the source for Router Advertisement
+        and Redirect messages so that hosts can uniquely identify
+        routers.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 39]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      - The IP Hop Limit field has a value of 255, i.e., the packet
+        could not possibly have been forwarded by a router.
+
+      - ICMP Checksum is valid.
+
+      - ICMP Code is 0.
+
+      - ICMP length (derived from the IP length) is 16 or more octets.
+
+      - All included options have a length that is greater than zero.
+
+   The contents of the Reserved field, and of any unrecognized options,
+   MUST be ignored.  Future, backward-compatible changes to the protocol
+   may specify the contents of the Reserved field or add new options;
+   backward-incompatible changes may use different Code values.
+
+   The contents of any defined options that are not specified to be used
+   with Router Advertisement messages MUST be ignored and the packet
+   processed as normal.  The only defined options that may appear are
+   the Source Link-Layer Address, Prefix Information and MTU options.
+
+   An advertisement that passes the validity checks is called a "valid
+   advertisement".
+
+6.2.  Router Specification
+
+6.2.1.  Router Configuration Variables
+
+   A router MUST allow for the following conceptual variables to be
+   configured by system management.  The specific variable names are
+   used for demonstration purposes only, and an implementation is not
+   required to have them, so long as its external behavior is consistent
+   with that described in this document.  Default values are specified
+   to simplify configuration in common cases.
+
+   The default values for some of the variables listed below may be
+   overridden by specific documents that describe how IPv6 operates over
+   different link layers.  This rule simplifies the configuration of
+   Neighbor Discovery over link types with widely differing performance
+   characteristics.
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 40]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   For each interface:
+
+      IsRouter       A flag indicating whether routing is enabled on
+                     this interface.  Enabling routing on the interface
+                     would imply that a router can forward packets to or
+                     from the interface.
+
+                     Default: FALSE
+
+      AdvSendAdvertisements
+                     A flag indicating whether or not the router sends
+                     periodic Router Advertisements and responds to
+                     Router Solicitations.
+
+                     Default: FALSE
+
+                     Note that AdvSendAdvertisements MUST be FALSE by
+                     default so that a node will not accidentally start
+                     acting as a router unless it is explicitly
+                     configured by system management to send Router
+                     Advertisements.
+
+      MaxRtrAdvInterval
+                     The maximum time allowed between sending
+                     unsolicited multicast Router Advertisements from
+                     the interface, in seconds.  MUST be no less than 4
+                     seconds and no greater than 1800 seconds.
+
+                     Default: 600 seconds
+
+      MinRtrAdvInterval
+                     The minimum time allowed between sending
+                     unsolicited multicast Router Advertisements from
+                     the interface, in seconds.  MUST be no less than 3
+                     seconds and no greater than .75 *
+                     MaxRtrAdvInterval.
+
+                     Default: 0.33 * MaxRtrAdvInterval If
+                     MaxRtrAdvInterval >= 9 seconds; otherwise, the
+                     Default is MaxRtrAdvInterval.
+
+      AdvManagedFlag
+                     The TRUE/FALSE value to be placed in the "Managed
+                     address configuration" flag field in the Router
+                     Advertisement.  See [ADDRCONF].
+
+                     Default: FALSE
+
+
+
+
+Narten, et al.              Standards Track                    [Page 41]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      AdvOtherConfigFlag
+                     The TRUE/FALSE value to be placed in the "Other
+                     configuration" flag field in the Router
+                     Advertisement.  See [ADDRCONF].
+
+                     Default: FALSE
+
+      AdvLinkMTU     The value to be placed in MTU options sent by the
+                     router.  A value of zero indicates that no MTU
+                     options are sent.
+
+                     Default: 0
+
+      AdvReachableTime
+                     The value to be placed in the Reachable Time field
+                     in the Router Advertisement messages sent by the
+                     router.  The value zero means unspecified (by this
+                     router).  MUST be no greater than 3,600,000
+                     milliseconds (1 hour).
+
+                     Default: 0
+
+      AdvRetransTimer The value to be placed in the Retrans Timer field
+                     in the Router Advertisement messages sent by the
+                     router.  The value zero means unspecified (by this
+                     router).
+
+                     Default: 0
+
+      AdvCurHopLimit
+                     The default value to be placed in the Cur Hop Limit
+                     field in the Router Advertisement messages sent by
+                     the router.  The value should be set to the current
+                     diameter of the Internet.  The value zero means
+                     unspecified (by this router).
+
+                     Default:  The value specified in the "Assigned
+                     Numbers" [ASSIGNED] that was in effect at the time
+                     of implementation.
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 42]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      AdvDefaultLifetime
+                     The value to be placed in the Router Lifetime field
+                     of Router Advertisements sent from the interface,
+                     in seconds.  MUST be either zero or between
+                     MaxRtrAdvInterval and 9000 seconds.  A value of
+                     zero indicates that the router is not to be used as
+                     a default router.  These limits may be overridden
+                     by specific documents that describe how IPv6
+                     operates over different link layers.  For instance,
+                     in a point-to-point link the peers may have enough
+                     information about the number and status of devices
+                     at the other end so that advertisements are needed
+                     less frequently.
+
+                     Default: 3 * MaxRtrAdvInterval
+
+      AdvPrefixList
+                     A list of prefixes to be placed in Prefix
+                     Information options in Router Advertisement
+                     messages sent from the interface.
+
+                     Default: all prefixes that the router advertises
+                     via routing protocols as being on-link for the
+                     interface from which the advertisement is sent.
+                     The link-local prefix SHOULD NOT be included in the
+                     list of advertised prefixes.
+
+                     Each prefix has an associated:
+
+                        AdvValidLifetime
+                             The value to be placed in the Valid
+                             Lifetime in the Prefix Information option,
+                             in seconds.  The designated value of all
+                             1's (0xffffffff) represents infinity.
+                             Implementations MAY allow AdvValidLifetime
+                             to be specified in two ways:
+
+                               - a time that decrements in real time,
+                                 that is, one that will result in a
+                                 Lifetime of zero at the specified time
+                                 in the future, or
+
+                               - a fixed time that stays the same in
+                                 consecutive advertisements.
+
+                             Default: 2592000 seconds (30 days), fixed
+                             (i.e., stays the same in consecutive
+                             advertisements).
+
+
+
+Narten, et al.              Standards Track                    [Page 43]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+                        AdvOnLinkFlag
+                             The value to be placed in the on-link flag
+                             ("L-bit") field in the Prefix Information
+                             option.
+
+                             Default: TRUE
+
+                   Stateless address configuration [ADDRCONF] defines
+                   additional information associated with each of the
+                   prefixes:
+
+                        AdvPreferredLifetime
+                             The value to be placed in the Preferred
+                             Lifetime in the Prefix Information option,
+                             in seconds.  The designated value of all
+                             1's (0xffffffff) represents infinity.  See
+                             [ADDRCONF] for details on how this value is
+                             used.  Implementations MAY allow
+                             AdvPreferredLifetime to be specified in two
+                             ways:
+
+                               - a time that decrements in real time,
+                                 that is, one that will result in a
+                                 Lifetime of zero at a specified time in
+                                 the future, or
+
+                               - a fixed time that stays the same in
+                                 consecutive advertisements.
+
+                             Default: 604800 seconds (7 days), fixed
+                             (i.e., stays the same in consecutive
+                             advertisements).  This value MUST NOT be
+                             larger than AdvValidLifetime.
+
+                        AdvAutonomousFlag
+                             The value to be placed in the Autonomous
+                             Flag field in the Prefix Information
+                             option.  See [ADDRCONF].
+
+                             Default: TRUE
+
+   The above variables contain information that is placed in outgoing
+   Router Advertisement messages.  Hosts use the received information to
+   initialize a set of analogous variables that control their external
+   behavior (see Section 6.3.2).  Some of these host variables (e.g.,
+   CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes
+   including routers.  In practice, these variables may not actually be
+   present on routers, since their contents can be derived from the
+
+
+
+Narten, et al.              Standards Track                    [Page 44]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   variables described above.  However, external router behavior MUST be
+   the same as host behavior with respect to these variables.  In
+   particular, this includes the occasional randomization of the
+   ReachableTime value as described in Section 6.3.2.
+
+   Protocol constants are defined in Section 10.
+
+6.2.2.  Becoming an Advertising Interface
+
+   The term "advertising interface" refers to any functioning and
+   enabled interface that has at least one unicast IP address assigned
+   to it and whose corresponding AdvSendAdvertisements flag is TRUE.  A
+   router MUST NOT send Router Advertisements out any interface that is
+   not an advertising interface.
+
+   An interface may become an advertising interface at times other than
+   system startup.  For example:
+
+      - changing the AdvSendAdvertisements flag on an enabled interface
+        from FALSE to TRUE, or
+
+      - administratively enabling the interface, if it had been
+        administratively disabled, and its AdvSendAdvertisements flag is
+        TRUE, or
+
+      - enabling IP forwarding capability (i.e., changing the system
+        from being a host to being a router), when the interface's
+        AdvSendAdvertisements flag is TRUE.
+
+   A router MUST join the all-routers multicast address on an
+   advertising interface.  Routers respond to Router Solicitations sent
+   to the all-routers address and verify the consistency of Router
+   Advertisements sent by neighboring routers.
+
+6.2.3.  Router Advertisement Message Content
+
+   A router sends periodic as well as solicited Router Advertisements
+   out its advertising interfaces.  Outgoing Router Advertisements are
+   filled with the following values consistent with the message format
+   given in Section 4.2:
+
+      - In the Router Lifetime field: the interface's configured
+        AdvDefaultLifetime.
+
+      - In the M and O flags: the interface's configured AdvManagedFlag
+        and AdvOtherConfigFlag, respectively.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 45]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      - In the Cur Hop Limit field: the interface's configured
+        CurHopLimit.
+
+      - In the Reachable Time field: the interface's configured
+        AdvReachableTime.
+
+      - In the Retrans Timer field: the interface's configured
+        AdvRetransTimer.
+
+      - In the options:
+
+           o Source Link-Layer Address option: link-layer address of the
+             sending interface.  This option MAY be omitted to
+             facilitate in-bound load balancing over replicated
+             interfaces.
+
+           o MTU option: the interface's configured AdvLinkMTU value if
+             the value is non-zero.  If AdvLinkMTU is zero, the MTU
+             option is not sent.
+
+           o Prefix Information options: one Prefix Information option
+             for each prefix listed in AdvPrefixList with the option
+             fields set from the information in the AdvPrefixList entry
+             as follows:
+
+                - In the "on-link" flag: the entry's AdvOnLinkFlag.
+
+                - In the Valid Lifetime field: the entry's
+                  AdvValidLifetime.
+
+                - In the "Autonomous address configuration" flag: the
+                  entry's AdvAutonomousFlag.
+
+                - In the Preferred Lifetime field: the entry's
+                  AdvPreferredLifetime.
+
+   A router might want to send Router Advertisements without advertising
+   itself as a default router.  For instance, a router might advertise
+   prefixes for stateless address autoconfiguration while not wishing to
+   forward packets.  Such a router sets the Router Lifetime field in
+   outgoing advertisements to zero.
+
+   A router MAY choose not to include some or all options when sending
+   unsolicited Router Advertisements.  For example, if prefix lifetimes
+   are much longer than AdvDefaultLifetime, including them every few
+   advertisements may be sufficient.  However, when responding to a
+   Router Solicitation or while sending the first few initial
+
+
+
+
+Narten, et al.              Standards Track                    [Page 46]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   unsolicited advertisements, a router SHOULD include all options so
+   that all information (e.g., prefixes) is propagated quickly during
+   system initialization.
+
+   If including all options causes the size of an advertisement to
+   exceed the link MTU, multiple advertisements can be sent, each
+   containing a subset of the options.
+
+6.2.4.  Sending Unsolicited Router Advertisements
+
+   A host MUST NOT send Router Advertisement messages at any time.
+
+   Unsolicited Router Advertisements are not strictly periodic: the
+   interval between subsequent transmissions is randomized to reduce the
+   probability of synchronization with the advertisements from other
+   routers on the same link [SYNC].  Each advertising interface has its
+   own timer.  Whenever a multicast advertisement is sent from an
+   interface, the timer is reset to a uniformly distributed random value
+   between the interface's configured MinRtrAdvInterval and
+   MaxRtrAdvInterval; expiration of the timer causes the next
+   advertisement to be sent and a new random value to be chosen.
+
+   For the first few advertisements (up to
+   MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it
+   becomes an advertising interface, if the randomly chosen interval is
+   greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set
+   to MAX_INITIAL_RTR_ADVERT_INTERVAL instead.  Using a smaller interval
+   for the initial advertisements increases the likelihood of a router
+   being discovered quickly when it first becomes available, in the
+   presence of possible packet loss.
+
+   The information contained in Router Advertisements may change through
+   actions of system management.  For instance, the lifetime of
+   advertised prefixes may change, new prefixes could be added, a router
+   could cease to be a router (i.e., switch from being a router to being
+   a host), etc.  In such cases, the router MAY transmit up to
+   MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the
+   same rules as when an interface becomes an advertising interface.
+
+6.2.5.  Ceasing To Be an Advertising Interface
+
+   An interface may cease to be an advertising interface, through
+   actions of system management such as:
+
+      - changing the AdvSendAdvertisements flag of an enabled interface
+        from TRUE to FALSE, or
+
+      - administratively disabling the interface, or
+
+
+
+Narten, et al.              Standards Track                    [Page 47]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      - shutting down the system.
+
+   In such cases, the router SHOULD transmit one or more (but not more
+   than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router
+   Advertisements on the interface with a Router Lifetime field of zero.
+   In the case of a router becoming a host, the system SHOULD also
+   depart from the all-routers IP multicast group on all interfaces on
+   which the router supports IP multicast (whether or not they had been
+   advertising interfaces).  In addition, the host MUST ensure that
+   subsequent Neighbor Advertisement messages sent from the interface
+   have the Router flag set to zero.
+
+   Note that system management may disable a router's IP forwarding
+   capability (i.e., changing the system from being a router to being a
+   host), a step that does not necessarily imply that the router's
+   interfaces stop being advertising interfaces.  In such cases,
+   subsequent Router Advertisements MUST set the Router Lifetime field
+   to zero.
+
+6.2.6.  Processing Router Solicitations
+
+   A host MUST silently discard any received Router Solicitation
+   messages.
+
+   In addition to sending periodic, unsolicited advertisements, a router
+   sends advertisements in response to valid solicitations received on
+   an advertising interface.  A router MAY choose to unicast the
+   response directly to the soliciting host's address (if the
+   solicitation's source address is not the unspecified address), but
+   the usual case is to multicast the response to the all-nodes group.
+   In the latter case, the interface's interval timer is reset to a new
+   random value, as if an unsolicited advertisement had just been sent
+   (see Section 6.2.4).
+
+   In all cases, Router Advertisements sent in response to a Router
+   Solicitation MUST be delayed by a random time between 0 and
+   MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in
+   response to multiple solicitations, the delay is relative to the
+   first solicitation.)  In addition, consecutive Router Advertisements
+   sent to the all-nodes multicast address MUST be rate limited to no
+   more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds.
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 48]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   A router might process Router Solicitations as follows:
+
+    - Upon receipt of a Router Solicitation, compute a random delay
+      within the range 0 through MAX_RA_DELAY_TIME.  If the computed
+      value corresponds to a time later than the time the next multicast
+      Router Advertisement is scheduled to be sent, ignore the random
+      delay and send the advertisement at the already-scheduled time.
+
+    - If the router sent a multicast Router Advertisement (solicited or
+      unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds,
+      schedule the advertisement to be sent at a time corresponding to
+      MIN_DELAY_BETWEEN_RAS plus the random value after the previous
+      advertisement was sent.  This ensures that the multicast Router
+      Advertisements are rate limited.
+
+    - Otherwise, schedule the sending of a Router Advertisement at the
+      time given by the random value.
+
+   Note that a router is permitted to send multicast Router
+   Advertisements more frequently than indicated by the
+   MinRtrAdvInterval configuration variable so long as the more frequent
+   advertisements are responses to Router Solicitations.  In all cases,
+   however, unsolicited multicast advertisements MUST NOT be sent more
+   frequently than indicated by MinRtrAdvInterval.
+
+   Router Solicitations in which the Source Address is the unspecified
+   address MUST NOT update the router's Neighbor Cache; solicitations
+   with a proper source address update the Neighbor Cache as follows.
+   If the router already has a Neighbor Cache entry for the
+   solicitation's sender, the solicitation contains a Source Link-Layer
+   Address option, and the received link-layer address differs from that
+   already in the cache, then the link-layer address SHOULD be updated
+   in the appropriate Neighbor Cache entry, and its reachability state
+   MUST also be set to STALE.  If there is no existing Neighbor Cache
+   entry for the solicitation's sender, the router creates one, installs
+   the link- layer address and sets its reachability state to STALE as
+   specified in Section 7.3.3.  If there is no existing Neighbor Cache
+   entry and no Source Link-Layer Address option was present in the
+   solicitation, the router may respond with either a multicast or a
+   unicast router advertisement.  Whether or not a Source Link-Layer
+   Address option is provided, if a Neighbor Cache entry for the
+   solicitation's sender exists (or is created) the entry's IsRouter
+   flag MUST be set to FALSE.
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 49]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+6.2.7.  Router Advertisement Consistency
+
+   Routers SHOULD inspect valid Router Advertisements sent by other
+   routers and verify that the routers are advertising consistent
+   information on a link.  Detected inconsistencies indicate that one or
+   more routers might be misconfigured and SHOULD be logged to system or
+   network management.  The minimum set of information to check
+   includes:
+
+    - Cur Hop Limit values (except for the unspecified value of zero
+      other inconsistencies SHOULD be logged to system network
+      management).
+
+    - Values of the M or O flags.
+
+    - Reachable Time values (except for the unspecified value of zero).
+
+    - Retrans Timer values (except for the unspecified value of zero).
+
+    - Values in the MTU options.
+
+    - Preferred and Valid Lifetimes for the same prefix.  If
+      AdvPreferredLifetime and/or AdvValidLifetime decrement in real
+      time as specified in Section 6.2.1 then the comparison of the
+      lifetimes cannot compare the content of the fields in the Router
+      Advertisement, but must instead compare the time at which the
+      prefix will become deprecated and invalidated, respectively.  Due
+      to link propagation delays and potentially poorly synchronized
+      clocks between the routers such comparison SHOULD allow some time
+      skew.
+
+   Note that it is not an error for different routers to advertise
+   different sets of prefixes.  Also, some routers might leave some
+   fields as unspecified, i.e., with the value zero, while other routers
+   specify values.  The logging of errors SHOULD be restricted to
+   conflicting information that causes hosts to switch from one value to
+   another with each received advertisement.
+
+   Any other action on reception of Router Advertisement messages by a
+   router is beyond the scope of this document.
+
+6.2.8.  Link-local Address Change
+
+   The link-local address on a router should rarely change, if ever.
+   Nodes receiving Neighbor Discovery messages use the source address to
+   identify the sender.  If multiple packets from the same router
+   contain different source addresses, nodes will assume they come from
+   different routers, leading to undesirable behavior.  For example, a
+
+
+
+Narten, et al.              Standards Track                    [Page 50]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   node will ignore Redirect messages that are believed to have been
+   sent by a router other than the current first-hop router.  Thus, the
+   source address used in Router Advertisements sent by a particular
+   router must be identical to the target address in a Redirect message
+   when redirecting to that router.
+
+   Using the link-local address to uniquely identify routers on the link
+   has the benefit that the address a router is known by should not
+   change when a site renumbers.
+
+   If a router changes the link-local address for one of its interfaces,
+   it SHOULD inform hosts of this change.  The router SHOULD multicast a
+   few Router Advertisements from the old link-local address with the
+   Router Lifetime field set to zero and also multicast a few Router
+   Advertisements from the new link-local address.  The overall effect
+   should be the same as if one interface ceases being an advertising
+   interface, and a different one starts being an advertising interface.
+
+6.3.  Host Specification
+
+6.3.1.  Host Configuration Variables
+
+   None.
+
+6.3.2.  Host Variables
+
+   A host maintains certain Neighbor-Discovery-related variables in
+   addition to the data structures defined in Section 5.1.  The specific
+   variable names are used for demonstration purposes only, and an
+   implementation is not required to have them, so long as its external
+   behavior is consistent with that described in this document.
+
+   These variables have default values that are overridden by
+   information received in Router Advertisement messages.  The default
+   values are used when there is no router on the link or when all
+   received Router Advertisements have left a particular value
+   unspecified.
+
+   The default values in this specification may be overridden by
+   specific documents that describe how IP operates over different link
+   layers.  This rule allows Neighbor Discovery to operate over links
+   with widely varying performance characteristics.
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 51]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   For each interface:
+
+        LinkMTU        The MTU of the link.
+                       Default: The valued defined in the specific
+                       document that describes how IPv6 operates over
+                       the particular link layer (e.g., [IPv6-ETHER]).
+
+        CurHopLimit    The default hop limit to be used when sending IP
+                       packets.
+
+                       Default: The value specified in the "Assigned
+                       Numbers" [ASSIGNED] that was in effect at the
+                       time of implementation.
+
+        BaseReachableTime
+                       A base value used for computing the random
+                       ReachableTime value.
+
+                       Default: REACHABLE_TIME milliseconds.
+
+        ReachableTime  The time a neighbor is considered reachable after
+                       receiving a reachability confirmation.
+
+                       This value should be a uniformly distributed
+                       random value between MIN_RANDOM_FACTOR and
+                       MAX_RANDOM_FACTOR times BaseReachableTime
+                       milliseconds.  A new random value should be
+                       calculated when BaseReachableTime changes (due to
+                       Router Advertisements) or at least every few
+                       hours even if no Router Advertisements are
+                       received.
+
+        RetransTimer   The time between retransmissions of Neighbor
+                       Solicitation messages to a neighbor when
+                       resolving the address or when probing the
+                       reachability of a neighbor.
+
+                       Default: RETRANS_TIMER milliseconds
+
+6.3.3.  Interface Initialization
+
+   The host joins the all-nodes multicast address on all multicast-
+   capable interfaces.
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 52]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+6.3.4.  Processing Received Router Advertisements
+
+   When multiple routers are present, the information advertised
+   collectively by all routers may be a superset of the information
+   contained in a single Router Advertisement.  Moreover, information
+   may also be obtained through other dynamic means like DHCPv6.  Hosts
+   accept the union of all received information; the receipt of a Router
+   Advertisement MUST NOT invalidate all information received in a
+   previous advertisement or from another source.  However, when
+   received information for a specific parameter (e.g., Link MTU) or
+   option (e.g., Lifetime on a specific Prefix) differs from information
+   received earlier, and the parameter/option can only have one value,
+   the most recently received information is considered authoritative.
+
+   A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time,
+   and Retrans Timer) may contain a value denoting that it is
+   unspecified.  In such cases, the parameter should be ignored and the
+   host should continue using whatever value it is already using.  In
+   particular, a host MUST NOT interpret the unspecified value as
+   meaning change back to the default value that was in use before the
+   first Router Advertisement was received.  This rule prevents hosts
+   from continually changing an internal variable when one router
+   advertises a specific value, but other routers advertise the
+   unspecified value.
+
+   On receipt of a valid Router Advertisement, a host extracts the
+   source address of the packet and does the following:
+
+      - If the address is not already present in the host's Default
+        Router List, and the advertisement's Router Lifetime is non-
+        zero, create a new entry in the list, and initialize its
+        invalidation timer value from the advertisement's Router
+        Lifetime field.
+
+      - If the address is already present in the host's Default Router
+        List as a result of a previously received advertisement, reset
+        its invalidation timer to the Router Lifetime value in the newly
+        received advertisement.
+
+      - If the address is already present in the host's Default Router
+        List and the received Router Lifetime value is zero, immediately
+        time-out the entry as specified in Section 6.3.5.
+
+   To limit the storage needed for the Default Router List, a host MAY
+   choose not to store all of the router addresses discovered via
+   advertisements.  However, a host MUST retain at least two router
+   addresses and SHOULD retain more.  Default router selections are made
+   whenever communication to a destination appears to be failing.  Thus,
+
+
+
+Narten, et al.              Standards Track                    [Page 53]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   the more routers on the list, the more likely an alternative working
+   router can be found quickly (e.g., without having to wait for the
+   next advertisement to arrive).
+
+   If the received Cur Hop Limit value is non-zero, the host SHOULD set
+   its CurHopLimit variable to the received value.
+
+   If the received Reachable Time value is non-zero, the host SHOULD set
+   its BaseReachableTime variable to the received value.  If the new
+   value differs from the previous value, the host SHOULD re-compute a
+   new random ReachableTime value.  ReachableTime is computed as a
+   uniformly distributed random value between MIN_RANDOM_FACTOR and
+   MAX_RANDOM_FACTOR times the BaseReachableTime.  Using a random
+   component eliminates the possibility that Neighbor Unreachability
+   Detection messages will synchronize with each other.
+
+   In most cases, the advertised Reachable Time value will be the same
+   in consecutive Router Advertisements, and a host's BaseReachableTime
+   rarely changes.  In such cases, an implementation SHOULD ensure that
+   a new random value gets re-computed at least once every few hours.
+
+   The RetransTimer variable SHOULD be copied from the Retrans Timer
+   field, if the received value is non-zero.
+
+   After extracting information from the fixed part of the Router
+   Advertisement message, the advertisement is scanned for valid
+   options.  If the advertisement contains a Source Link-Layer Address
+   option, the link-layer address SHOULD be recorded in the Neighbor
+   Cache entry for the router (creating an entry if necessary) and the
+   IsRouter flag in the Neighbor Cache entry MUST be set to TRUE.  If no
+   Source Link-Layer Address is included, but a corresponding Neighbor
+   Cache entry exists, its IsRouter flag MUST be set to TRUE.  The
+   IsRouter flag is used by Neighbor Unreachability Detection to
+   determine when a router changes to being a host (i.e., no longer
+   capable of forwarding packets).  If a Neighbor Cache entry is created
+   for the router, its reachability state MUST be set to STALE as
+   specified in Section 7.3.3.  If a cache entry already exists and is
+   updated with a different link-layer address, the reachability state
+   MUST also be set to STALE.
+
+   If the MTU option is present, hosts SHOULD copy the option's value
+   into LinkMTU so long as the value is greater than or equal to the
+   minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value
+   specified in the link-type-specific document (e.g., [IPv6-ETHER]).
+
+   Prefix Information options that have the "on-link" (L) flag set
+   indicate a prefix identifying a range of addresses that should be
+   considered on-link.  Note, however, that a Prefix Information option
+
+
+
+Narten, et al.              Standards Track                    [Page 54]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   with the on-link flag set to zero conveys no information concerning
+   on-link determination and MUST NOT be interpreted to mean that
+   addresses covered by the prefix are off-link.  The only way to cancel
+   a previous on-link indication is to advertise that prefix with the
+   L-bit set and the Lifetime set to zero.  The default behavior (see
+   Section 5.2) when sending a packet to an address for which no
+   information is known about the on-link status of the address is to
+   forward the packet to a default router; the reception of a Prefix
+   Information option with the "on-link" (L) flag set to zero does not
+   change this behavior.  The reasons for an address being treated as
+   on-link is specified in the definition of "on-link" in Section 2.1.
+   Prefixes with the on-link flag set to zero would normally have the
+   autonomous flag set and be used by [ADDRCONF].
+
+   For each Prefix Information option with the on-link flag set, a host
+   does the following:
+
+      - If the prefix is the link-local prefix, silently ignore the
+        Prefix Information option.
+
+      - If the prefix is not already present in the Prefix List, and the
+        Prefix Information option's Valid Lifetime field is non-zero,
+        create a new entry for the prefix and initialize its
+        invalidation timer to the Valid Lifetime value in the Prefix
+        Information option.
+
+      - If the prefix is already present in the host's Prefix List as
+        the result of a previously received advertisement, reset its
+        invalidation timer to the Valid Lifetime value in the Prefix
+        Information option.  If the new Lifetime value is zero, time-out
+        the prefix immediately (see Section 6.3.5).
+
+      - If the Prefix Information option's Valid Lifetime field is zero,
+        and the prefix is not present in the host's Prefix List,
+        silently ignore the option.
+
+   Stateless address autoconfiguration [ADDRCONF] may in some
+   circumstances use a larger Valid Lifetime of a prefix or ignore it
+   completely in order to prevent a particular denial-of-service attack.
+   However, since the effect of the same denial of service targeted at
+   the on-link prefix list is not catastrophic (hosts would send packets
+   to a default router and receive a redirect rather than sending
+   packets directly to a neighbor), the Neighbor Discovery protocol does
+   not impose such a check on the prefix lifetime values.  Similarly,
+   [ADDRCONF] may impose certain restrictions on the prefix length for
+   address configuration purposes.  Therefore, the prefix might be
+   rejected by [ADDRCONF] implementation in the host.  However, the
+
+
+
+
+Narten, et al.              Standards Track                    [Page 55]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   prefix length is still valid for on-link determination when combined
+   with other flags in the prefix option.
+
+      Note: Implementations can choose to process the on-link aspects of
+      the prefixes separately from the stateless address
+      autoconfiguration aspects of the prefixes by, e.g., passing a copy
+      of each valid Router Advertisement message to both an "on-link"
+      and an "addrconf" function.  Each function can then operate
+      independently on the prefixes that have the appropriate flag set.
+
+6.3.5.  Timing out Prefixes and Default Routers
+
+   Whenever the invalidation timer expires for a Prefix List entry, that
+   entry is discarded.  No existing Destination Cache entries need be
+   updated, however.  Should a reachability problem arise with an
+   existing Neighbor Cache entry, Neighbor Unreachability Detection will
+   perform any needed recovery.
+
+   Whenever the Lifetime of an entry in the Default Router List expires,
+   that entry is discarded.  When removing a router from the Default
+   Router list, the node MUST update the Destination Cache in such a way
+   that all entries using the router perform next-hop determination
+   again rather than continue sending traffic to the (deleted) router.
+
+6.3.6.  Default Router Selection
+
+   The algorithm for selecting a router depends in part on whether or
+   not a router is known to be reachable.  The exact details of how a
+   node keeps track of a neighbor's reachability state are covered in
+   Section 7.3.  The algorithm for selecting a default router is invoked
+   during next-hop determination when no Destination Cache entry exists
+   for an off-link destination or when communication through an existing
+   router appears to be failing.  Under normal conditions, a router
+   would be selected the first time traffic is sent to a destination,
+   with subsequent traffic for that destination using the same router as
+   indicated in the Destination Cache modulo any changes to the
+   Destination Cache caused by Redirect messages.
+
+   The policy for selecting routers from the Default Router List is as
+   follows:
+
+     1) Routers that are reachable or probably reachable (i.e., in any
+        state other than INCOMPLETE) SHOULD be preferred over routers
+        whose reachability is unknown or suspect (i.e., in the
+        INCOMPLETE state, or for which no Neighbor Cache entry exists).
+        Further implementation hints on default router selection when
+        multiple equivalent routers are available are discussed in
+        [LD-SHRE].
+
+
+
+Narten, et al.              Standards Track                    [Page 56]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+     2) When no routers on the list are known to be reachable or
+        probably reachable, routers SHOULD be selected in a round-robin
+        fashion, so that subsequent requests for a default router do not
+        return the same router until all other routers have been
+        selected.
+
+        Cycling through the router list in this case ensures that all
+        available routers are actively probed by the Neighbor
+        Unreachability Detection algorithm.  A request for a default
+        router is made in conjunction with the sending of a packet to a
+        router, and the selected router will be probed for reachability
+        as a side effect.
+
+6.3.7.  Sending Router Solicitations
+
+   When an interface becomes enabled, a host may be unwilling to wait
+   for the next unsolicited Router Advertisement to locate default
+   routers or learn prefixes.  To obtain Router Advertisements quickly,
+   a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router
+   Solicitation messages, each separated by at least
+   RTR_SOLICITATION_INTERVAL seconds.  Router Solicitations may be sent
+   after any of the following events:
+
+      - The interface is initialized at system startup time.
+
+      - The interface is reinitialized after a temporary interface
+        failure or after being temporarily disabled by system
+        management.
+
+      - The system changes from being a router to being a host, by
+        having its IP forwarding capability turned off by system
+        management.
+
+      - The host attaches to a link for the first time.
+
+      - The host re-attaches to a link after being detached for some
+        time.
+
+   A host sends Router Solicitations to the all-routers multicast
+   address.  The IP source address is set to either one of the
+   interface's unicast addresses or the unspecified address.  The Source
+   Link-Layer Address option SHOULD be set to the host's link-layer
+   address, if the IP source address is not the unspecified address.
+
+   Before a host sends an initial solicitation, it SHOULD delay the
+   transmission for a random amount of time between 0 and
+   MAX_RTR_SOLICITATION_DELAY.  This serves to alleviate congestion when
+   many hosts start up on a link at the same time, such as might happen
+
+
+
+Narten, et al.              Standards Track                    [Page 57]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   after recovery from a power failure.  If a host has already performed
+   a random delay since the interface became (re)enabled (e.g., as part
+   of Duplicate Address Detection [ADDRCONF]), there is no need to delay
+   again before sending the first Router Solicitation message.
+
+   In some cases, the random delay MAY be omitted if necessary.  For
+   instance, a mobile node, using [MIPv6], moving to a new link would
+   need to discover such movement as soon as possible to minimize the
+   amount of packet losses resulting from the change in its topological
+   movement.  Router Solicitations provide a useful tool for movement
+   detection in Mobile IPv6 as they allow mobile nodes to determine
+   movement to new links.  Hence, if a mobile node received link-layer
+   information indicating that movement might have taken place, it MAY
+   send a Router Solicitation immediately, without random delays.  The
+   strength of such indications should be assessed by the mobile node's
+   implementation depending on the level of certainty of the link-layer
+   hints, and it is outside the scope of this specification.  Note that
+   using this mechanism inappropriately (e.g., based on weak or
+   transient indications) may result in Router Solicitation storms.
+   Furthermore, simultaneous mobility of a large number of mobile nodes
+   that use this mechanism can result in a large number of solicitations
+   sent simultaneously.
+
+   Once the host sends a Router Solicitation, and receives a valid
+   Router Advertisement with a non-zero Router Lifetime, the host MUST
+   desist from sending additional solicitations on that interface, until
+   the next time one of the above events occurs.  Moreover, a host
+   SHOULD send at least one solicitation in the case where an
+   advertisement is received prior to having sent a solicitation.
+   Responses to solicited advertisements may contain more information
+   than unsolicited advertisements.
+
+   If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no
+   Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY
+   seconds after sending the last solicitation, the host concludes that
+   there are no routers on the link for the purpose of [ADDRCONF].
+   However, the host continues to receive and process Router
+   Advertisements messages in the event that routers appear on the link.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 58]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+7.  Address Resolution and Neighbor Unreachability Detection
+
+   This section describes the functions related to Neighbor Solicitation
+   and Neighbor Advertisement messages and includes descriptions of
+   address resolution and the Neighbor Unreachability Detection
+   algorithm.
+
+   Neighbor Solicitation and Advertisement messages are also used for
+   Duplicate Address Detection as specified by [ADDRCONF].  In
+   particular, Duplicate Address Detection sends Neighbor Solicitation
+   messages with an unspecified source address targeting its own
+   "tentative" address.  Such messages trigger nodes already using the
+   address to respond with a multicast Neighbor Advertisement indicating
+   that the address is in use.
+
+7.1.  Message Validation
+
+7.1.1.  Validation of Neighbor Solicitations
+
+   A node MUST silently discard any received Neighbor Solicitation
+   messages that do not satisfy all of the following validity checks:
+
+      - The IP Hop Limit field has a value of 255, i.e., the packet
+        could not possibly have been forwarded by a router.
+
+      - ICMP Checksum is valid.
+
+      - ICMP Code is 0.
+
+      - ICMP length (derived from the IP length) is 24 or more octets.
+
+      - Target Address is not a multicast address.
+
+      - All included options have a length that is greater than zero.
+
+      - If the IP source address is the unspecified address, the IP
+        destination address is a solicited-node multicast address.
+
+      - If the IP source address is the unspecified address, there is no
+        source link-layer address option in the message.
+
+   The contents of the Reserved field, and of any unrecognized options,
+   MUST be ignored.  Future, backward-compatible changes to the protocol
+   may specify the contents of the Reserved field or add new options;
+   backward-incompatible changes may use different Code values.
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 59]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   The contents of any defined options that are not specified to be used
+   with Neighbor Solicitation messages MUST be ignored and the packet
+   processed as normal.  The only defined option that may appear is the
+   Source Link-Layer Address option.
+
+   A Neighbor Solicitation that passes the validity checks is called a
+   "valid solicitation".
+
+7.1.2.  Validation of Neighbor Advertisements
+
+   A node MUST silently discard any received Neighbor Advertisement
+   messages that do not satisfy all of the following validity checks:
+
+      - The IP Hop Limit field has a value of 255, i.e., the packet
+        could not possibly have been forwarded by a router.
+
+      - ICMP Checksum is valid.
+
+      - ICMP Code is 0.
+
+      - ICMP length (derived from the IP length) is 24 or more octets.
+
+      - Target Address is not a multicast address.
+
+      - If the IP Destination Address is a multicast address the
+        Solicited flag is zero.
+
+      - All included options have a length that is greater than zero.
+
+   The contents of the Reserved field, and of any unrecognized options,
+   MUST be ignored.  Future, backward-compatible changes to the protocol
+   may specify the contents of the Reserved field or add new options;
+   backward-incompatible changes may use different Code values.
+
+   The contents of any defined options that are not specified to be used
+   with Neighbor Advertisement messages MUST be ignored and the packet
+   processed as normal.  The only defined option that may appear is the
+   Target Link-Layer Address option.
+
+   A Neighbor Advertisements that passes the validity checks is called a
+   "valid advertisement".
+
+7.2.  Address Resolution
+
+   Address resolution is the process through which a node determines the
+   link-layer address of a neighbor given only its IP address.  Address
+   resolution is performed only on addresses that are determined to be
+   on-link and for which the sender does not know the corresponding
+
+
+
+Narten, et al.              Standards Track                    [Page 60]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   link-layer address (see Section 5.2).  Address resolution is never
+   performed on multicast addresses.
+
+   It is possible that a host may receive a solicitation, a router
+   advertisement, or a Redirect message without a link-layer address
+   option included.  These messages MUST NOT create or update neighbor
+   cache entries, except with respect to the IsRouter flag as specified
+   in Sections 6.3.4 and 7.2.5.  If a Neighbor Cache entry does not
+   exist for the source of such a message, Address Resolution will be
+   required before unicast communications with that address can begin.
+   This is particularly relevant for unicast responses to solicitations
+   where an additional packet exchange is required for advertisement
+   delivery.
+
+7.2.1.  Interface Initialization
+
+   When a multicast-capable interface becomes enabled, the node MUST
+   join the all-nodes multicast address on that interface, as well as
+   the solicited-node multicast address corresponding to each of the IP
+   addresses assigned to the interface.
+
+   The set of addresses assigned to an interface may change over time.
+   New addresses might be added and old addresses might be removed
+   [ADDRCONF].  In such cases the node MUST join and leave the
+   solicited-node multicast address corresponding to the new and old
+   addresses, respectively.  Joining the solicited-node multicast
+   address is done using a Multicast Listener Discovery such as [MLD] or
+   [MLDv2] protocols.  Note that multiple unicast addresses may map into
+   the same solicited-node multicast address; a node MUST NOT leave the
+   solicited-node multicast group until all assigned addresses
+   corresponding to that multicast address have been removed.
+
+7.2.2.  Sending Neighbor Solicitations
+
+   When a node has a unicast packet to send to a neighbor, but does not
+   know the neighbor's link-layer address, it performs address
+   resolution.  For multicast-capable interfaces, this entails creating
+   a Neighbor Cache entry in the INCOMPLETE state and transmitting a
+   Neighbor Solicitation message targeted at the neighbor.  The
+   solicitation is sent to the solicited-node multicast address
+   corresponding to the target address.
+
+   If the source address of the packet prompting the solicitation is the
+   same as one of the addresses assigned to the outgoing interface, that
+   address SHOULD be placed in the IP Source Address of the outgoing
+   solicitation.  Otherwise, any one of the addresses assigned to the
+   interface should be used.  Using the prompting packet's source
+   address when possible ensures that the recipient of the Neighbor
+
+
+
+Narten, et al.              Standards Track                    [Page 61]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Solicitation installs in its Neighbor Cache the IP address that is
+   highly likely to be used in subsequent return traffic belonging to
+   the prompting packet's "connection".
+
+   If the solicitation is being sent to a solicited-node multicast
+   address, the sender MUST include its link-layer address (if it has
+   one) as a Source Link-Layer Address option.  Otherwise, the sender
+   SHOULD include its link-layer address (if it has one) as a Source
+   Link-Layer Address option.  Including the source link-layer address
+   in a multicast solicitation is required to give the target an address
+   to which it can send the Neighbor Advertisement.  On unicast
+   solicitations, an implementation MAY omit the Source Link-Layer
+   Address option.  The assumption here is that if the sender has a
+   peer's link-layer address in its cache, there is a high probability
+   that the peer will also have an entry in its cache for the sender.
+   Consequently, it need not be sent.
+
+   While waiting for address resolution to complete, the sender MUST,
+   for each neighbor, retain a small queue of packets waiting for
+   address resolution to complete.  The queue MUST hold at least one
+   packet, and MAY contain more.  However, the number of queued packets
+   per neighbor SHOULD be limited to some small value.  When a queue
+   overflows, the new arrival SHOULD replace the oldest entry.  Once
+   address resolution completes, the node transmits any queued packets.
+
+   While awaiting a response, the sender SHOULD retransmit Neighbor
+   Solicitation messages approximately every RetransTimer milliseconds,
+   even in the absence of additional traffic to the neighbor.
+   Retransmissions MUST be rate-limited to at most one solicitation per
+   neighbor every RetransTimer milliseconds.
+
+   If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
+   solicitations, address resolution has failed.  The sender MUST return
+   ICMP destination unreachable indications with code 3 (Address
+   Unreachable) for each packet queued awaiting address resolution.
+
+7.2.3.  Receipt of Neighbor Solicitations
+
+   A valid Neighbor Solicitation that does not meet any of the following
+   requirements MUST be silently discarded:
+
+    - The Target Address is a "valid" unicast or anycast address
+      assigned to the receiving interface [ADDRCONF],
+
+    - The Target Address is a unicast or anycast address for which the
+      node is offering proxy service, or
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 62]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+    - The Target Address is a "tentative" address on which Duplicate
+      Address Detection is being performed [ADDRCONF].
+
+   If the Target Address is tentative, the Neighbor Solicitation should
+   be processed as described in [ADDRCONF].  Otherwise, the following
+   description applies.  If the Source Address is not the unspecified
+   address and, on link layers that have addresses, the solicitation
+   includes a Source Link-Layer Address option, then the recipient
+   SHOULD create or update the Neighbor Cache entry for the IP Source
+   Address of the solicitation.  If an entry does not already exist, the
+   node SHOULD create a new one and set its reachability state to STALE
+   as specified in Section 7.3.3.  If an entry already exists, and the
+   cached link-layer address differs from the one in the received Source
+   Link-Layer option, the cached address should be replaced by the
+   received address, and the entry's reachability state MUST be set to
+   STALE.
+
+   If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set
+   to FALSE.  This will be the case even if the Neighbor Solicitation is
+   sent by a router since the Neighbor Solicitation messages do not
+   contain an indication of whether or not the sender is a router.  In
+   the event that the sender is a router, subsequent Neighbor
+   Advertisement or Router Advertisement messages will set the correct
+   IsRouter value.  If a Neighbor Cache entry already exists, its
+   IsRouter flag MUST NOT be modified.
+
+   If the Source Address is the unspecified address, the node MUST NOT
+   create or update the Neighbor Cache entry.
+
+   After any updates to the Neighbor Cache, the node sends a Neighbor
+   Advertisement response as described in the next section.
+
+7.2.4.  Sending Solicited Neighbor Advertisements
+
+   A node sends a Neighbor Advertisement in response to a valid Neighbor
+   Solicitation targeting one of the node's assigned addresses.  The
+   Target Address of the advertisement is copied from the Target Address
+   of the solicitation.  If the solicitation's IP Destination Address is
+   not a multicast address, the Target Link-Layer Address option MAY be
+   omitted; the neighboring node's cached value must already be current
+   in order for the solicitation to have been received.  If the
+   solicitation's IP Destination Address is a multicast address, the
+   Target Link-Layer option MUST be included in the advertisement.
+   Furthermore, if the node is a router, it MUST set the Router flag to
+   one; otherwise, it MUST set the flag to zero.
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 63]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   If the Target Address is either an anycast address or a unicast
+   address for which the node is providing proxy service, or the Target
+   Link-Layer Address option is not included, the Override flag SHOULD
+   be set to zero.  Otherwise, the Override flag SHOULD be set to one.
+   Proper setting of the Override flag ensures that nodes give
+   preference to non-proxy advertisements, even when received after
+   proxy advertisements, and also ensures that the first advertisement
+   for an anycast address "wins".
+
+   If the source of the solicitation is the unspecified address, the
+   node MUST set the Solicited flag to zero and multicast the
+   advertisement to the all-nodes address.  Otherwise, the node MUST set
+   the Solicited flag to one and unicast the advertisement to the Source
+   Address of the solicitation.
+
+   If the Target Address is an anycast address, the sender SHOULD delay
+   sending a response for a random time between 0 and
+   MAX_ANYCAST_DELAY_TIME seconds.
+
+   Because unicast Neighbor Solicitations are not required to include a
+   Source Link-Layer Address, it is possible that a node sending a
+   solicited Neighbor Advertisement does not have a corresponding link-
+   layer address for its neighbor in its Neighbor Cache.  In such
+   situations, a node will first have to use Neighbor Discovery to
+   determine the link-layer address of its neighbor (i.e., send out a
+   multicast Neighbor Solicitation).
+
+7.2.5.  Receipt of Neighbor Advertisements
+
+   When a valid Neighbor Advertisement is received (either solicited or
+   unsolicited), the Neighbor Cache is searched for the target's entry.
+   If no entry exists, the advertisement SHOULD be silently discarded.
+   There is no need to create an entry if none exists, since the
+   recipient has apparently not initiated any communication with the
+   target.
+
+   Once the appropriate Neighbor Cache entry has been located, the
+   specific actions taken depend on the state of the Neighbor Cache
+   entry, the flags in the advertisement, and the actual link-layer
+   address supplied.
+
+   If the target's Neighbor Cache entry is in the INCOMPLETE state when
+   the advertisement is received, one of two things happens.  If the
+   link layer has addresses and no Target Link-Layer Address option is
+   included, the receiving node SHOULD silently discard the received
+   advertisement.  Otherwise, the receiving node performs the following
+   steps:
+
+
+
+
+Narten, et al.              Standards Track                    [Page 64]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   - It records the link-layer address in the Neighbor Cache entry.
+
+   - If the advertisement's Solicited flag is set, the state of the
+     entry is set to REACHABLE; otherwise, it is set to STALE.
+
+   - It sets the IsRouter flag in the cache entry based on the Router
+     flag in the received advertisement.
+
+   - It sends any packets queued for the neighbor awaiting address
+     resolution.
+
+   Note that the Override flag is ignored if the entry is in the
+   INCOMPLETE state.
+
+   If the target's Neighbor Cache entry is in any state other than
+   INCOMPLETE when the advertisement is received, the following actions
+   take place:
+
+   I.  If the Override flag is clear and the supplied link-layer address
+       differs from that in the cache, then one of two actions takes
+       place:
+       a. If the state of the entry is REACHABLE, set it to STALE, but
+          do not update the entry in any other way.
+       b. Otherwise, the received advertisement should be ignored and
+          MUST NOT update the cache.
+
+   II. If the Override flag is set, or the supplied link-layer address
+       is the same as that in the cache, or no Target Link-Layer Address
+       option was supplied, the received advertisement MUST update the
+       Neighbor Cache entry as follows:
+
+       - The link-layer address in the Target Link-Layer Address option
+         MUST be inserted in the cache (if one is supplied and differs
+         from the already recorded address).
+
+       - If the Solicited flag is set, the state of the entry MUST be
+         set to REACHABLE.  If the Solicited flag is zero and the link-
+         layer address was updated with a different address, the state
+         MUST be set to STALE.  Otherwise, the entry's state remains
+         unchanged.
+
+         An advertisement's Solicited flag should only be set if the
+         advertisement is a response to a Neighbor Solicitation.
+         Because Neighbor Unreachability Detection Solicitations are
+         sent to the cached link-layer address, receipt of a solicited
+         advertisement indicates that the forward path is working.
+         Receipt of an unsolicited advertisement, however, may indicate
+         that a neighbor has urgent information to announce (e.g., a
+
+
+
+Narten, et al.              Standards Track                    [Page 65]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+         changed link-layer address).  If the urgent information
+         indicates a change from what a node is currently using, the
+         node should verify the reachability of the (new) path when it
+         sends the next packet.  There is no need to update the state
+         for unsolicited advertisements that do not change the contents
+         of the cache.
+
+       - The IsRouter flag in the cache entry MUST be set based on the
+         Router flag in the received advertisement.  In those cases
+         where the IsRouter flag changes from TRUE to FALSE as a result
+         of this update, the node MUST remove that router from the
+         Default Router List and update the Destination Cache entries
+         for all destinations using that neighbor as a router as
+         specified in Section 7.3.3.  This is needed to detect when a
+         node that is used as a router stops forwarding packets due to
+         being configured as a host.
+
+   The above rules ensure that the cache is updated either when the
+   Neighbor Advertisement takes precedence (i.e., the Override flag is
+   set) or when the Neighbor Advertisement refers to the same link-layer
+   address that is currently recorded in the cache.  If none of the
+   above apply, the advertisement prompts future Neighbor Unreachability
+   Detection (if it is not already in progress) by changing the state in
+   the cache entry.
+
+7.2.6.  Sending Unsolicited Neighbor Advertisements
+
+   In some cases, a node may be able to determine that its link-layer
+   address has changed (e.g., hot-swap of an interface card) and may
+   wish to inform its neighbors of the new link-layer address quickly.
+   In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT
+   unsolicited Neighbor Advertisement messages to the all-nodes
+   multicast address.  These advertisements MUST be separated by at
+   least RetransTimer seconds.
+
+   The Target Address field in the unsolicited advertisement is set to
+   an IP address of the interface, and the Target Link-Layer Address
+   option is filled with the new link-layer address.  The Solicited flag
+   MUST be set to zero, in order to avoid confusing the Neighbor
+   Unreachability Detection algorithm.  If the node is a router, it MUST
+   set the Router flag to one; otherwise, it MUST set it to zero.  The
+   Override flag MAY be set to either zero or one.  In either case,
+   neighboring nodes will immediately change the state of their Neighbor
+   Cache entries for the Target Address to STALE, prompting them to
+   verify the path for reachability.  If the Override flag is set to
+   one, neighboring nodes will install the new link-layer address in
+   their caches.  Otherwise, they will ignore the new link-layer
+   address, choosing instead to probe the cached address.
+
+
+
+Narten, et al.              Standards Track                    [Page 66]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   A node that has multiple IP addresses assigned to an interface MAY
+   multicast a separate Neighbor Advertisement for each address.  In
+   such a case, the node SHOULD introduce a small delay between the
+   sending of each advertisement to reduce the probability of the
+   advertisements being lost due to congestion.
+
+   A proxy MAY multicast Neighbor Advertisements when its link-layer
+   address changes or when it is configured (by system management or
+   other mechanisms) to proxy for an address.  If there are multiple
+   nodes that are providing proxy services for the same set of
+   addresses, the proxies should provide a mechanism that prevents
+   multiple proxies from multicasting advertisements for any one
+   address, in order to reduce the risk of excessive multicast traffic.
+   This is a requirement on other protocols that need to use proxies for
+   Neighbor Advertisements.  An example of a node that performs proxy
+   advertisements is the Home Agent specified in [MIPv6].
+
+   Also, a node belonging to an anycast address MAY multicast
+   unsolicited Neighbor Advertisements for the anycast address when the
+   node's link-layer address changes.
+
+   Note that because unsolicited Neighbor Advertisements do not reliably
+   update caches in all nodes (the advertisements might not be received
+   by all nodes), they should only be viewed as a performance
+   optimization to quickly update the caches in most neighbors.  The
+   Neighbor Unreachability Detection algorithm ensures that all nodes
+   obtain a reachable link-layer address, though the delay may be
+   slightly longer.
+
+7.2.7.  Anycast Neighbor Advertisements
+
+   From the perspective of Neighbor Discovery, anycast addresses are
+   treated just like unicast addresses in most cases.  Because an
+   anycast address is syntactically the same as a unicast address, nodes
+   performing address resolution or Neighbor Unreachability Detection on
+   an anycast address treat it as if it were a unicast address.  No
+   special processing takes place.
+
+   Nodes that have an anycast address assigned to an interface treat
+   them exactly the same as if they were unicast addresses with two
+   exceptions.  First, Neighbor Advertisements sent in response to a
+   Neighbor Solicitation SHOULD be delayed by a random time between 0
+   and MAX_ANYCAST_DELAY_TIME to reduce the probability of network
+   congestion.  Second, the Override flag in Neighbor Advertisements
+   SHOULD be set to 0, so that when multiple advertisements are
+   received, the first received advertisement is used rather than the
+   most recently received advertisement.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 67]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   As with unicast addresses, Neighbor Unreachability Detection ensures
+   that a node quickly detects when the current binding for an anycast
+   address becomes invalid.
+
+7.2.8.  Proxy Neighbor Advertisements
+
+   Under limited circumstances, a router MAY proxy for one or more other
+   nodes, that is, through Neighbor Advertisements indicate that it is
+   willing to accept packets not explicitly addressed to itself.  For
+   example, a router might accept packets on behalf of a mobile node
+   that has moved off-link.  The mechanisms used by proxy are
+   essentially the same as the mechanisms used with anycast addresses.
+
+   A proxy MUST join the solicited-node multicast address(es) that
+   correspond to the IP address(es) assigned to the node for which it is
+   proxying.  This SHOULD be done using a multicast listener discovery
+   protocol such as [MLD] or [MLDv2].
+
+   All solicited proxy Neighbor Advertisement messages MUST have the
+   Override flag set to zero.  This ensures that if the node itself is
+   present on the link, its Neighbor Advertisement (with the Override
+   flag set to one) will take precedence of any advertisement received
+   from a proxy.  A proxy MAY send unsolicited advertisements with the
+   Override flag set to one as specified in Section 7.2.6, but doing so
+   may cause the proxy advertisement to override a valid entry created
+   by the node itself.
+
+   Finally, when sending a proxy advertisement in response to a Neighbor
+   Solicitation, the sender should delay its response by a random time
+   between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due
+   to multiple responses sent by several proxies.  However, in some
+   cases (e.g., Mobile IPv6) where only one proxy is present, such delay
+   is not necessary.
+
+7.3.  Neighbor Unreachability Detection
+
+   Communication to or through a neighbor may fail for numerous reasons
+   at any time, including hardware failure, hot-swap of an interface
+   card, etc.  If the destination has failed, no recovery is possible
+   and communication fails.  On the other hand, if it is the path that
+   has failed, recovery may be possible.  Thus, a node actively tracks
+   the reachability "state" for the neighbors to which it is sending
+   packets.
+
+   Neighbor Unreachability Detection is used for all paths between hosts
+   and neighboring nodes, including host-to-host, host-to-router, and
+   router-to-host communication.  Neighbor Unreachability Detection may
+   also be used between routers, but is not required if an equivalent
+
+
+
+Narten, et al.              Standards Track                    [Page 68]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   mechanism is available, for example, as part of the routing
+   protocols.
+
+   When a path to a neighbor appears to be failing, the specific
+   recovery procedure depends on how the neighbor is being used.  If the
+   neighbor is the ultimate destination, for example, address resolution
+   should be performed again.  If the neighbor is a router, however,
+   attempting to switch to another router would be appropriate.  The
+   specific recovery that takes place is covered under next-hop
+   determination; Neighbor Unreachability Detection signals the need for
+   next-hop determination by deleting a Neighbor Cache entry.
+
+   Neighbor Unreachability Detection is performed only for neighbors to
+   which unicast packets are sent; it is not used when sending to
+   multicast addresses.
+
+7.3.1.  Reachability Confirmation
+
+   A neighbor is considered reachable if the node has recently received
+   a confirmation that packets sent recently to the neighbor were
+   received by its IP layer.  Positive confirmation can be gathered in
+   two ways: hints from upper-layer protocols that indicate a connection
+   is making "forward progress", or receipt of a Neighbor Advertisement
+   message that is a response to a Neighbor Solicitation message.
+
+   A connection makes "forward progress" if the packets received from a
+   remote peer can only be arriving if recent packets sent to that peer
+   are actually reaching it.  In TCP, for example, receipt of a (new)
+   acknowledgment indicates that previously sent data reached the peer.
+   Likewise, the arrival of new (non-duplicate) data indicates that
+   earlier acknowledgments are being delivered to the remote peer.  If
+   packets are reaching the peer, they must also be reaching the
+   sender's next-hop neighbor; thus, "forward progress" is a
+   confirmation that the next-hop neighbor is reachable.  For off-link
+   destinations, forward progress implies that the first-hop router is
+   reachable.  When available, this upper-layer information SHOULD be
+   used.
+
+   In some cases (e.g., UDP-based protocols and routers forwarding
+   packets to hosts), such reachability information may not be readily
+   available from upper-layer protocols.  When no hints are available
+   and a node is sending packets to a neighbor, the node actively probes
+   the neighbor using unicast Neighbor Solicitation messages to verify
+   that the forward path is still working.
+
+   The receipt of a solicited Neighbor Advertisement serves as
+   reachability confirmation, since advertisements with the Solicited
+   flag set to one are sent only in response to a Neighbor Solicitation.
+
+
+
+Narten, et al.              Standards Track                    [Page 69]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Receipt of other Neighbor Discovery messages, such as Router
+   Advertisements and Neighbor Advertisement with the Solicited flag set
+   to zero, MUST NOT be treated as a reachability confirmation.  Receipt
+   of unsolicited messages only confirms the one-way path from the
+   sender to the recipient node.  In contrast, Neighbor Unreachability
+   Detection requires that a node keep track of the reachability of the
+   forward path to a neighbor from its perspective, not the neighbor's
+   perspective.  Note that receipt of a solicited advertisement
+   indicates that a path is working in both directions.  The
+   solicitation must have reached the neighbor, prompting it to generate
+   an advertisement.  Likewise, receipt of an advertisement indicates
+   that the path from the sender to the recipient is working.  However,
+   the latter fact is known only to the recipient; the advertisement's
+   sender has no direct way of knowing that the advertisement it sent
+   actually reached a neighbor.  From the perspective of Neighbor
+   Unreachability Detection, only the reachability of the forward path
+   is of interest.
+
+7.3.2.  Neighbor Cache Entry States
+
+   A Neighbor Cache entry can be in one of five states:
+
+      INCOMPLETE  Address resolution is being performed on the entry.
+                  Specifically, a Neighbor Solicitation has been sent to
+                  the solicited-node multicast address of the target,
+                  but the corresponding Neighbor Advertisement has not
+                  yet been received.
+
+      REACHABLE   Positive confirmation was received within the last
+                  ReachableTime milliseconds that the forward path to
+                  the neighbor was functioning properly.  While
+                  REACHABLE, no special action takes place as packets
+                  are sent.
+
+      STALE       More than ReachableTime milliseconds have elapsed
+                  since the last positive confirmation was received that
+                  the forward path was functioning properly.  While
+                  stale, no action takes place until a packet is sent.
+
+                  The STALE state is entered upon receiving an
+                  unsolicited Neighbor Discovery message that updates
+                  the cached link-layer address.  Receipt of such a
+                  message does not confirm reachability, and entering
+                  the STALE state ensures reachability is verified
+                  quickly if the entry is actually being used.  However,
+                  reachability is not actually verified until the entry
+                  is actually used.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 70]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+      DELAY       More than ReachableTime milliseconds have elapsed
+                  since the last positive confirmation was received that
+                  the forward path was functioning properly, and a
+                  packet was sent within the last DELAY_FIRST_PROBE_TIME
+                  seconds.  If no reachability confirmation is received
+                  within DELAY_FIRST_PROBE_TIME seconds of entering the
+                  DELAY state, send a Neighbor Solicitation and change
+                  the state to PROBE.
+
+                  The DELAY state is an optimization that gives upper-
+                  layer protocols additional time to provide
+                  reachability confirmation in those cases where
+                  ReachableTime milliseconds have passed since the last
+                  confirmation due to lack of recent traffic.  Without
+                  this optimization, the opening of a TCP connection
+                  after a traffic lull would initiate probes even though
+                  the subsequent three-way handshake would provide a
+                  reachability confirmation almost immediately.
+
+      PROBE       A reachability confirmation is actively sought by
+                  retransmitting Neighbor Solicitations every
+                  RetransTimer milliseconds until a reachability
+                  confirmation is received.
+
+7.3.3.  Node Behavior
+
+   Neighbor Unreachability Detection operates in parallel with the
+   sending of packets to a neighbor.  While reasserting a neighbor's
+   reachability, a node continues sending packets to that neighbor using
+   the cached link-layer address.  If no traffic is sent to a neighbor,
+   no probes are sent.
+
+   When a node needs to perform address resolution on a neighboring
+   address, it creates an entry in the INCOMPLETE state and initiates
+   address resolution as specified in Section 7.2.  If address
+   resolution fails, the entry SHOULD be deleted, so that subsequent
+   traffic to that neighbor invokes the next-hop determination procedure
+   again.  Invoking next-hop determination at this point ensures that
+   alternate default routers are tried.
+
+   When a reachability confirmation is received (either through upper-
+   layer advice or a solicited Neighbor Advertisement), an entry's state
+   changes to REACHABLE.  The one exception is that upper-layer advice
+   has no effect on entries in the INCOMPLETE state (e.g., for which no
+   link-layer address is cached).
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 71]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   When ReachableTime milliseconds have passed since receipt of the last
+   reachability confirmation for a neighbor, the Neighbor Cache entry's
+   state changes from REACHABLE to STALE.
+
+      Note: An implementation may actually defer changing the state from
+      REACHABLE to STALE until a packet is sent to the neighbor, i.e.,
+      there need not be an explicit timeout event associated with the
+      expiration of ReachableTime.
+
+   The first time a node sends a packet to a neighbor whose entry is
+   STALE, the sender changes the state to DELAY and sets a timer to
+   expire in DELAY_FIRST_PROBE_TIME seconds.  If the entry is still in
+   the DELAY state when the timer expires, the entry's state changes to
+   PROBE.  If reachability confirmation is received, the entry's state
+   changes to REACHABLE.
+
+   Upon entering the PROBE state, a node sends a unicast Neighbor
+   Solicitation message to the neighbor using the cached link-layer
+   address.  While in the PROBE state, a node retransmits Neighbor
+   Solicitation messages every RetransTimer milliseconds until
+   reachability confirmation is obtained.  Probes are retransmitted even
+   if no additional packets are sent to the neighbor.  If no response is
+   received after waiting RetransTimer milliseconds after sending the
+   MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the
+   entry SHOULD be deleted.  Subsequent traffic to that neighbor will
+   recreate the entry and perform address resolution again.
+
+   Note that all Neighbor Solicitations are rate-limited on a per-
+   neighbor basis.  A node MUST NOT send Neighbor Solicitations to the
+   same neighbor more frequently than once every RetransTimer
+   milliseconds.
+
+   A Neighbor Cache entry enters the STALE state when created as a
+   result of receiving packets other than solicited Neighbor
+   Advertisements (i.e., Router Solicitations, Router Advertisements,
+   Redirects, and Neighbor Solicitations).  These packets contain the
+   link-layer address of either the sender or, in the case of Redirect,
+   the redirection target.  However, receipt of these link-layer
+   addresses does not confirm reachability of the forward-direction path
+   to that node.  Placing a newly created Neighbor Cache entry for which
+   the link-layer address is known in the STALE state provides assurance
+   that path failures are detected quickly.  In addition, should a
+   cached link-layer address be modified due to receiving one of the
+   above messages, the state SHOULD also be set to STALE to provide
+   prompt verification that the path to the new link-layer address is
+   working.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 72]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   To properly detect the case where a router switches from being a
+   router to being a host (e.g., if its IP forwarding capability is
+   turned off by system management), a node MUST compare the Router flag
+   field in all received Neighbor Advertisement messages with the
+   IsRouter flag recorded in the Neighbor Cache entry.  When a node
+   detects that a neighbor has changed from being a router to being a
+   host, the node MUST remove that router from the Default Router List
+   and update the Destination Cache as described in Section 6.3.5.  Note
+   that a router may not be listed in the Default Router List, even
+   though a Destination Cache entry is using it (e.g., a host was
+   redirected to it).  In such cases, all Destination Cache entries that
+   reference the (former) router must perform next-hop determination
+   again before using the entry.
+
+   In some cases, link-specific information may indicate that a path to
+   a neighbor has failed (e.g., the resetting of a virtual circuit).  In
+   such cases, link-specific information may be used to purge Neighbor
+   Cache entries before the Neighbor Unreachability Detection would do
+   so.  However, link-specific information MUST NOT be used to confirm
+   the reachability of a neighbor; such information does not provide
+   end-to-end confirmation between neighboring IP layers.
+
+8.  Redirect Function
+
+   This section describes the functions related to the sending and
+   processing of Redirect messages.
+
+   Redirect messages are sent by routers to redirect a host to a better
+   first-hop router for a specific destination or to inform hosts that a
+   destination is in fact a neighbor (i.e., on-link).  The latter is
+   accomplished by having the ICMP Target Address be equal to the ICMP
+   Destination Address.
+
+   A router MUST be able to determine the link-local address for each of
+   its neighboring routers in order to ensure that the target address in
+   a Redirect message identifies the neighbor router by its link-local
+   address.  For static routing, this requirement implies that the next-
+   hop router's address should be specified using the link-local address
+   of the router.  For dynamic routing, this requirement implies that
+   all IPv6 routing protocols must somehow exchange the link-local
+   addresses of neighboring routers.
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 73]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+8.1.  Validation of Redirect Messages
+
+   A host MUST silently discard any received Redirect message that does
+   not satisfy all of the following validity checks:
+
+      - IP Source Address is a link-local address.  Routers must use
+        their link-local address as the source for Router Advertisement
+        and Redirect messages so that hosts can uniquely identify
+        routers.
+
+      - The IP Hop Limit field has a value of 255, i.e., the packet
+        could not possibly have been forwarded by a router.
+
+      - ICMP Checksum is valid.
+
+      - ICMP Code is 0.
+
+      - ICMP length (derived from the IP length) is 40 or more octets.
+
+      - The IP source address of the Redirect is the same as the current
+        first-hop router for the specified ICMP Destination Address.
+
+      - The ICMP Destination Address field in the redirect message does
+        not contain a multicast address.
+
+      - The ICMP Target Address is either a link-local address (when
+        redirected to a router) or the same as the ICMP Destination
+        Address (when redirected to the on-link destination).
+
+      - All included options have a length that is greater than zero.
+
+   The contents of the Reserved field, and of any unrecognized options,
+   MUST be ignored.  Future, backward-compatible changes to the protocol
+   may specify the contents of the Reserved field or add new options;
+   backward-incompatible changes may use different Code values.
+
+   The contents of any defined options that are not specified to be used
+   with Redirect messages MUST be ignored and the packet processed as
+   normal.  The only defined options that may appear are the Target
+   Link-Layer Address option and the Redirected Header option.
+
+   A host MUST NOT consider a redirect invalid just because the Target
+   Address of the redirect is not covered under one of the link's
+   prefixes.  Part of the semantics of the Redirect message is that the
+   Target Address is on-link.
+
+   A redirect that passes the validity checks is called a "valid
+   redirect".
+
+
+
+Narten, et al.              Standards Track                    [Page 74]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+8.2.  Router Specification
+
+   A router SHOULD send a redirect message, subject to rate limiting,
+   whenever it forwards a packet that is not explicitly addressed to
+   itself (i.e., a packet that is not source routed through the router)
+   in which:
+
+      - the Source Address field of the packet identifies a neighbor,
+        and
+
+      - the router determines (by means outside the scope of this
+        specification) that a better first-hop node resides on the same
+        link as the sending node for the Destination Address of the
+        packet being forwarded, and
+
+      - the Destination Address of the packet is not a multicast
+        address.
+
+   The transmitted redirect packet contains, consistent with the message
+   format given in Section 4.5:
+
+      - In the Target Address field: the address to which subsequent
+        packets for the destination should be sent.  If the target is a
+        router, that router's link-local address MUST be used.  If the
+        target is a host, the target address field MUST be set to the
+        same value as the Destination Address field.
+
+      - In the Destination Address field: the destination address of the
+        invoking IP packet.
+
+      - In the options:
+
+           o Target Link-Layer Address option: link-layer address of the
+             target, if known.
+
+           o Redirected Header: as much of the forwarded packet as can
+             fit without the redirect packet exceeding the minimum MTU
+             required to support IPv6 as specified in [IPv6].
+
+   A router MUST limit the rate at which Redirect messages are sent, in
+   order to limit the bandwidth and processing costs incurred by the
+   Redirect messages when the source does not correctly respond to the
+   Redirects, or the source chooses to ignore unauthenticated Redirect
+   messages.  More details on the rate-limiting of ICMP error messages
+   can be found in [ICMPv6].
+
+   A router MUST NOT update its routing tables upon receipt of a
+   Redirect.
+
+
+
+Narten, et al.              Standards Track                    [Page 75]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+8.3.  Host Specification
+
+   A host receiving a valid redirect SHOULD update its Destination Cache
+   accordingly so that subsequent traffic goes to the specified target.
+   If no Destination Cache entry exists for the destination, an
+   implementation SHOULD create such an entry.
+
+   If the redirect contains a Target Link-Layer Address option, the host
+   either creates or updates the Neighbor Cache entry for the target.
+   In both cases, the cached link-layer address is copied from the
+   Target Link-Layer Address option.  If a Neighbor Cache entry is
+   created for the target, its reachability state MUST be set to STALE
+   as specified in Section 7.3.3.  If a cache entry already existed and
+   it is updated with a different link-layer address, its reachability
+   state MUST also be set to STALE.  If the link-layer address is the
+   same as that already in the cache, the cache entry's state remains
+   unchanged.
+
+   If the Target and Destination Addresses are the same, the host MUST
+   treat the Target as on-link.  If the Target Address is not the same
+   as the Destination Address, the host MUST set IsRouter to TRUE for
+   the target.  If the Target and Destination Addresses are the same,
+   however, one cannot reliably determine whether the Target Address is
+   a router.  Consequently, newly created Neighbor Cache entries should
+   set the IsRouter flag to FALSE, while existing cache entries should
+   leave the flag unchanged.  If the Target is a router, subsequent
+   Neighbor Advertisement or Router Advertisement messages will update
+   IsRouter accordingly.
+
+   Redirect messages apply to all flows that are being sent to a given
+   destination.  That is, upon receipt of a Redirect for a Destination
+   Address, all Destination Cache entries to that address should be
+   updated to use the specified next-hop, regardless of the contents of
+   the Flow Label field that appears in the Redirected Header option.
+
+   A host MUST NOT send Redirect messages.
+
+9.  Extensibility - Option Processing
+
+   Options provide a mechanism for encoding variable length fields,
+   fields that may appear multiple times in the same packet, or
+   information that may not appear in all packets.  Options can also be
+   used to add additional functionality to future versions of ND.
+
+   In order to ensure that future extensions properly coexist with
+   current implementations, all nodes MUST silently ignore any options
+   they do not recognize in received ND packets and continue processing
+   the packet.  All options specified in this document MUST be
+
+
+
+Narten, et al.              Standards Track                    [Page 76]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   recognized.  A node MUST NOT ignore valid options just because the ND
+   message contains unrecognized ones.
+
+   The current set of options is defined in such a way that receivers
+   can process multiple options in the same packet independently of each
+   other.  In order to maintain these properties, future options SHOULD
+   follow the simple rule:
+
+      The option MUST NOT depend on the presence or absence of any other
+      options.  The semantics of an option should depend only on the
+      information in the fixed part of the ND packet and on the
+      information contained in the option itself.
+
+   Adhering to the above rule has the following benefits:
+
+     1) Receivers can process options independently of one another.  For
+        example, an implementation can choose to process the Prefix
+        Information option contained in a Router Advertisement message
+        in a user-space process while the link-layer address option in
+        the same message is processed by routines in the kernel.
+
+     2) Should the number of options cause a packet to exceed a link's
+        MTU, multiple packets can carry subsets of the options without
+        any change in semantics.
+
+     3) Senders MAY send a subset of options in different packets.  For
+        instance, if a prefix's Valid and Preferred Lifetime are high
+        enough, it might not be necessary to include the Prefix
+        Information option in every Router Advertisement.  In addition,
+        different routers might send different sets of options.  Thus, a
+        receiver MUST NOT associate any action with the absence of an
+        option in a particular packet.  This protocol specifies that
+        receivers should only act on the expiration of timers and on the
+        information that is received in the packets.
+
+   Options in Neighbor Discovery packets can appear in any order;
+   receivers MUST be prepared to process them independently of their
+   order.  There can also be multiple instances of the same option in a
+   message (e.g., Prefix Information options).
+
+   If the number of included options in a Router Advertisement causes
+   the advertisement's size to exceed the link MTU, the router can send
+   multiple separate advertisements, each containing a subset of the
+   options.
+
+   The amount of data to include in the Redirected Header option MUST be
+   limited so that the entire redirect packet does not exceed the
+   minimum MTU required to support IPv6 as specified in [IPv6].
+
+
+
+Narten, et al.              Standards Track                    [Page 77]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   All options are a multiple of 8 octets of length, ensuring
+   appropriate alignment without any "pad" options.  The fields in the
+   options (as well as the fields in ND packets) are defined to align on
+   their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit
+   boundary) with the exception of the 128-bit IP addresses/prefixes,
+   which are aligned on a 64-bit boundary.  The link-layer address field
+   contains an uninterpreted octet string; it is aligned on an 8-bit
+   boundary.
+
+   The size of an ND packet including the IP header is limited to the
+   link MTU.  When adding options to an ND packet, a node MUST NOT
+   exceed the link MTU.
+
+   Future versions of this protocol may define new option types.
+   Receivers MUST silently ignore any options they do not recognize and
+   continue processing the message.
+
+10.  Protocol Constants
+
+   Router constants:
+
+            MAX_INITIAL_RTR_ADVERT_INTERVAL  16 seconds
+
+            MAX_INITIAL_RTR_ADVERTISEMENTS    3 transmissions
+
+            MAX_FINAL_RTR_ADVERTISEMENTS      3 transmissions
+
+            MIN_DELAY_BETWEEN_RAS             3 seconds
+
+            MAX_RA_DELAY_TIME                 .5 seconds
+
+   Host constants:
+
+            MAX_RTR_SOLICITATION_DELAY        1 second
+
+            RTR_SOLICITATION_INTERVAL         4 seconds
+
+            MAX_RTR_SOLICITATIONS             3 transmissions
+
+   Node constants:
+
+            MAX_MULTICAST_SOLICIT             3 transmissions
+
+            MAX_UNICAST_SOLICIT               3 transmissions
+
+            MAX_ANYCAST_DELAY_TIME            1 second
+
+            MAX_NEIGHBOR_ADVERTISEMENT        3 transmissions
+
+
+
+Narten, et al.              Standards Track                    [Page 78]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+            REACHABLE_TIME               30,000 milliseconds
+
+            RETRANS_TIMER                 1,000 milliseconds
+
+            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.  This section deals with the main
+   threats related to Neighbor Discovery messages and possible security
+   mechanisms that can mitigate these threats.
+
+11.1.  Threat Analysis
+
+   This section discusses the main threats associated with Neighbor
+   Discovery.  A more detailed analysis can be found in [PSREQ].  The
+   main vulnerabilities of the protocol fall under three categories:
+
+   - Denial-of-Service (DoS) attacks.
+   - Address spoofing attacks.
+   - Router spoofing attacks.
+
+   An example of denial of service attacks is that a node on the link
+   that can send packets with an arbitrary IP source address can both
+   advertise itself as a default router and also send "forged" Router
+   Advertisement messages that immediately time out all other default
+   routers as well as all on-link prefixes.  An intruder can achieve
+   this by sending out multiple Router Advertisements, one for each
+   legitimate router, with the source address set to the address of
+   another router, the Router Lifetime field set to zero, and the
+
+
+
+Narten, et al.              Standards Track                    [Page 79]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   Preferred and Valid lifetimes set to zero for all the prefixes.  Such
+   an attack would cause all packets, for both on-link and off-link
+   destinations, to go to the rogue router.  That router can then
+   selectively examine, modify, or drop all packets sent on the link.
+   The Neighbor Unreachability Detection (NUD) will not detect such a
+   black hole as long as the rogue router politely answers the NUD
+   probes with a Neighbor Advertisement with the R-bit set.
+
+   It is also possible for any host to launch a DoS attack on another
+   host by preventing it from configuring an address using [ADDRCONF].
+   The protocol does not allow hosts to verify whether the sender of a
+   Neighbor Advertisement is the true owner of the IP address included
+   in the message.
+
+   Redirect attacks can also be achieved by any host in order to flood a
+   victim or steal its traffic.  A host can send a Neighbor
+   Advertisement (in response to a solicitation) that contains its IP
+   address and a victim's link-layer address in order to flood the
+   victim with unwanted traffic.  Alternatively, the host can send a
+   Neighbor Advertisement that includes a victim's IP address and its
+   own link-layer address to overwrite an existing entry in the sender's
+   destination cache, thereby forcing the sender to forward all of the
+   victim's traffic to itself.
+
+   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.  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 before
+   being redirected; 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.
+
+   Many link layers are also subject to different denial-of-service
+   attacks such as continuously occupying the link in CSMA/CD (Carrier
+   Sense Multiple Access with Collision Detection) networks (e.g., by
+   sending packets closely back-to-back or asserting the collision
+   signal on the link), or originating packets with somebody else's
+   source MAC address to confuse, e.g., Ethernet switches.  On the other
+   hand, many of the threats discussed in this section are less
+
+
+
+Narten, et al.              Standards Track                    [Page 80]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   effective, or non-existent, on point-to-point links, or cellular
+   links where a host shares a link with only one neighbor, i.e., the
+   default router.
+
+11.2.  Securing Neighbor Discovery Messages
+
+   The protocol reduces the exposure to the above 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.
+
+   Cryptographic security mechanisms for Neighbor Discovery are outside
+   the scope of this document and are defined in [SEND].  Alternatively,
+   IPsec can be used for IP layer authentication [IPv6-SA].  The use of
+   the Internet Key Exchange (IKE) is not suited for creating dynamic
+   security associations that can be used to secure address resolution
+   or neighbor solicitation messages as documented in [ICMPIKE].
+
+   In some cases, it may be acceptable to use statically configured
+   security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure
+   Neighbor Discovery messages.  However, it is important to note that
+   statically configured security associations are not scalable
+   (especially when considering multicast links) and are therefore
+   limited to small networks with known hosts.  In any case, if either
+   [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for
+   the purpose of authentication.  Packets that fail authentication
+   checks MUST be silently discarded.
+
+12.  Renumbering Considerations
+
+   The Neighbor Discovery protocol together with IPv6 Address
+   Autoconfiguration [ADDRCONF] provides mechanisms to aid in
+   renumbering -- new prefixes and addresses can be introduced and old
+   ones can be deprecated and removed.
+
+   The robustness of these mechanisms is based on all the nodes on the
+   link receiving the Router Advertisement messages in a timely manner.
+   However, a host might be turned off or be unreachable for an extended
+   period of time (i.e., a machine is powered down for months after a
+   project terminates).  It is possible to preserve robust renumbering
+   in such cases, but it does place some constraints on how long
+   prefixes must be advertised.
+
+   Consider the following example in which a prefix is initially
+   advertised with a lifetime of 2 months, but on August 1st it is
+   determined that the prefix needs to be deprecated and removed due to
+
+
+
+Narten, et al.              Standards Track                    [Page 81]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   renumbering by September 1st.  This can be done by reducing the
+   advertised lifetime to 1 week starting on August 1st, and as the
+   cutoff gets closer, the lifetimes can be made shorter until by
+   September 1st the prefix is advertised with a lifetime of 0.  The
+   point is that, if one or more nodes were unplugged from the link
+   prior to September 1st, they might still think that the prefix is
+   valid since the last lifetime they received was 2 months.  Thus, if a
+   node was unplugged on July 31st, it thinks the prefix is valid until
+   September 30th.  If that node is plugged back in prior to September
+   30th, it may continue to use the old prefix.  The only way to force a
+   node to stop using a prefix that was previously advertised with a
+   long lifetime is to have that node receive an advertisement for that
+   prefix that changes the lifetime downward.  The solution in this
+   example is simple: continue advertising the prefix with a lifetime of
+   0 from September 1st until October 1st.
+
+   In general, in order to be robust against nodes that might be
+   unplugged from the link, it is important to track the furthest into
+   the future that a particular prefix can be viewed as valid by any
+   node on the link.  The prefix must then be advertised with a 0
+   lifetime until that point in the future.  This "furthest into the
+   future" time is simply the maximum, over all Router Advertisements,
+   of the time the advertisement was sent, plus the prefix's lifetime
+   contained in the advertisement.
+
+   The above has an important implication on using infinite lifetimes.
+   If a prefix is advertised with an infinite lifetime, and that prefix
+   later needs to be renumbered, it is undesirable to continue
+   advertising that prefix with a zero lifetime forever.  Thus, either
+   infinite lifetimes should be avoided or there must be a limit on how
+   long of a time a node can be unplugged from the link before it is
+   plugged back in again.  However, it is unclear how the network
+   administrator can enforce a limit on how long time hosts such as
+   laptops can be unplugged from the link.
+
+   Network administrators should give serious consideration to using
+   relatively short lifetimes (i.e., no more than a few weeks).  While
+   it might appear that using long lifetimes would help ensure
+   robustness, in reality, a host will be unable to communicate in the
+   absence of properly functioning routers.  Such routers will be
+   sending Router Advertisements that contain appropriate (and current)
+   prefixes.  A host connected to a network that has no functioning
+   routers is likely to have more serious problems than just a lack of a
+   valid prefix and address.
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 82]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   The above discussion does not distinguish between the preferred and
+   valid lifetimes.  For all practical purposes, it is probably
+   sufficient to track the valid lifetime since the preferred lifetime
+   will not exceed the valid lifetime.
+
+13.  IANA Considerations
+
+   This document does not require any new ICMPv6 types or codes to be
+   allocated.  However, existing ICMPv6 types have been updated to point
+   to this document instead of RFC 2461.  The procedure for the
+   assignment of ICMPv6 types/codes is described in Section 6 of
+   [ICMPv6].
+
+   This document continues to use the following ICMPv6 message types
+   introduced in RFC 2461 and already assigned by IANA:
+
+      Message name                            ICMPv6 Type
+
+      Router Solicitation                      133
+      Router Advertisement                     134
+      Neighbor Solicitation                    135
+      Neighbor Advertisement                   136
+      Redirect                                 137
+
+   This document continues to use the following Neighbor Discovery
+   option types introduced in RFC 2461 and already assigned by IANA:
+
+      Option Name                             Type
+
+      Source Link-Layer Address                    1
+      Target Link-Layer Address                    2
+      Prefix Information                           3
+      Redirected Header                            4
+      MTU                                          5
+
+   Neighbor Discovery option types are allocated using the following
+   procedure:
+
+   1. The IANA should allocate and permanently register new option types
+   from IETF RFC publication.  This is for all RFC types including
+   standards track, informational, and experimental status that
+   originate from the IETF and have been approved by the IESG for
+   publication.
+
+   2. IETF working groups with working group consensus and area director
+   approval can request reclaimable Neighbor Discovery option type
+   assignments from the IANA.  The IANA will tag the values as
+   "reclaimable in future".
+
+
+
+Narten, et al.              Standards Track                    [Page 83]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   The "reclaimable in the future" tag will be removed when an RFC is
+   published documenting the protocol as defined in 1).  This will make
+   the assignment permanent and update the reference on the IANA Web
+   pages.
+
+   At the point where the option type values are 85% assigned, the IETF
+   will review the assignments tagged "reclaimable in the future" and
+   inform the IANA which ones should be reclaimed and reassigned.
+
+   3. Requests for new option type value assignments from outside the
+   IETF are only made through the publication of an IETF document, per
+   1) above.  Note also that documents published as "RFC Editor
+   contributions" [RFC3667] are not considered to be IETF documents.
+
+14.  References
+
+14.1.  Normative References
+
+   [ADDR-ARCH]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+                Architecture", RFC 4291, February 2006.
+
+   [ICMPv6]     Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+                Control Message Protocol (ICMPv6) for the Internet
+                Protocol Version 6 (IPv6) Specification", RFC 4443,
+                March 2006.
+
+   [IPv6]       Deering, S. and R. Hinden, "Internet Protocol, Version 6
+                (IPv6) Specification", RFC 2460, December 1998.
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+14.2.  Informative References
+
+   [ADDRCONF]   Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+                Address Autoconfiguration", RFC 4862, September 2007.
+
+   [ADDR-SEL]   Draves, R., "Default Address Selection for Internet
+                Protocol version 6 (IPv6)", RFC 3484, February 2003.
+
+   [ARP]        Plummer, D., "Ethernet Address Resolution Protocol: Or
+                Converting Network Protocol Addresses to 48.bit Ethernet
+                Address for Transmission on Ethernet Hardware", STD 37,
+                RFC 826, November 1982.
+
+   [ASSIGNED]   Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is
+                Replaced by an On-line Database", RFC 3232, January
+                2002.
+
+
+
+Narten, et al.              Standards Track                    [Page 84]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   [DHCPv6]     Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+                C., and M. Carney, "Dynamic Host Configuration Protocol
+                for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [HR-CL]      Braden, R., Ed., "Requirements for Internet Hosts -
+                Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [ICMPIKE]    Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress,
+                March 2003.
+
+   [ICMPv4]     Postel, J., "Internet Control Message Protocol", STD 5,
+                RFC 792, September 1981.
+
+   [IPv6-3GPP]  Wasserman, M., Ed., "Recommendations for IPv6 in Third
+                Generation Partnership Project (3GPP) Standards", RFC
+                3314, September 2002.
+
+   [IPv6-CELL]  Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and
+                J. Wiljakka, "Internet Protocol Version 6 (IPv6) for
+                Some Second and Third Generation Cellular Hosts", RFC
+                3316, April 2003.
+
+   [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
+                Ethernet Networks", RFC 2464, December 1998.
+
+   [IPv6-SA]    Kent, S. and K. Seo, "Security Architecture for the
+                Internet Protocol", RFC 4301, December 2005.
+
+   [IPv6-AUTH]  Kent, S., "IP Authentication Header", RFC 4302, December
+                2005.
+
+   [IPv6-ESP]   Kent, S., "IP Encapsulating Security Payload (ESP)", RFC
+                4303, December 2005.
+
+   [IPv6-NBMA]  Armitage, G., Schulter, P., Jork, M., and G. Harter,
+                "IPv6 over Non-Broadcast Multiple Access (NBMA)
+                networks", RFC 2491, January 1999.
+
+   [LD-SHRE]    Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
+                Sharing", RFC 4311, November 2005.
+
+   [MIPv6]      Johnson, D., Perkins, C., and J. Arkko, "Mobility
+                Support in IPv6", RFC 3775, June 2004.
+
+   [MLD]        Deering, S., Fenner, W., and B. Haberman, "Multicast
+                Listener Discovery (MLD) for IPv6", RFC 2710, October
+                1999.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 85]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   [MLDv2]      Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
+                Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June
+                2004.
+
+   [PSREQ]      Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
+                Neighbor Discovery (ND) Trust Models and Threats", RFC
+                3756, May 2004.
+
+   [RAND]       Eastlake, D., 3rd, Schiller, J., and S. Crocker,
+                "Randomness Requirements for Security", BCP 106, RFC
+                4086, June 2005.
+
+   [RDISC]      Deering, S., Ed., "ICMP Router Discovery Messages", RFC
+                1256, September 1991.
+
+   [RFC3667]    Bradner, S., "IETF Rights in Contributions", RFC 3667,
+                February 2004.
+
+   [RTSEL]      Draves, R. and D. Thaler, "Default Router Preferences
+                and More-Specific Routes", RFC 4191, November 2005.
+
+   [SH-MEDIA]   Braden, B., Postel, J., and Y. Rekhter, "Internet
+                Architecture Extensions for Shared Media", RFC 1620, May
+                1994.
+
+   [SEND]       Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+                "SEcure Neighbor Discovery (SEND)", RFC 3971, March
+                2005.
+
+   [SYNC]       S. Floyd, V. Jacobson, "The Synchronization of Periodic
+                Routing Messages", IEEE/ACM Transactions on Networking,
+                April 1994.  ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 86]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+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.  Further work
+   related to this problem can be found in [RTSEL].
+
+   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.  Additional discussion on this topic
+        can be found in RFC 1122 under Section 3.3.4.2.
+
+     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
+
+
+
+Narten, et al.              Standards Track                    [Page 87]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   affected interface(s).  This leads to the following problem: 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 suboptimal 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 88]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+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
+                   retransmissions.       timer
+
+   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=any,     Update content of    unchanged
+                   Override=any, No       IsRouter flag
+                   Link-layer address
+
+    -              NS, RS, Redirect             -                 -
+                   No link-layer address
+
+   !INCOMPLETE     NA, Solicited=1,        -                   REACHABLE
+                   Override=0
+                   Same link-layer
+                   address as cached.
+
+   !INCOMPLETE     NA, Solicited=any,     Update content of    unchanged
+                   Override=any, No       IsRouter flag.
+                   link-layer address
+
+
+
+Narten, et al.              Standards Track                    [Page 89]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   REACHABLE       NA, Solicited=1,        -                     STALE
+                   Override=0
+                   Different link-layer
+                   address than cached.
+
+   STALE, PROBE    NA, Solicited=1,        -                   unchanged
+   Or DELAY        Override=0
+                   Different link-layer
+                   address than cached.
+
+   !INCOMPLETE     NA, Solicited=1,       Record link-layer   REACHABLE
+                   Override=1             address (if
+                                          different).
+
+   !INCOMPLETE     NA, Solicited=0,        -                  unchanged
+                   Override=0
+
+   !INCOMPLETE     NA, Solicited=0,        -                  unchanged
+                   Override=1
+                   Same link-layer
+                   address as cached.
+
+   !INCOMPLETE     NA, Solicited=0,        Record link-layer     STALE
+                   Override=1              address.
+                   Different link-layer
+                   address than cached.
+
+   !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.
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 90]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   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 No link-layer    -                   unchanged
+                   address
+
+   !INCOMPLETE     NS, RS, RA, Redirect    -                   unchanged
+                   Same link-layer
+                   address as cached.
+
+Appendix D: Summary of IsRouter Rules
+
+   This appendix presents a summary of the rules for maintaining the
+   IsRouter flag as specified in this document.
+
+   The background for these rules is that the ND messages contain,
+   either implicitly or explicitly, information that indicates whether
+   or not the sender (or Target Address) is a host or a router.  The
+   following assumptions are used:
+
+    - The sender of a Router Advertisement is implicitly assumed to be a
+      router.
+
+    - Neighbor Solicitation messages do not contain either an implicit
+      or explicit indication about the sender.  Both hosts and routers
+      send such messages.
+
+    - Neighbor Advertisement messages contain an explicit "IsRouter
+      flag", the R-bit.
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 91]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+    - The target of the redirect, when the target differs from the
+      destination address in the packet being redirected, is implicitly
+      assumed to be a router.  This is a natural assumption since that
+      node is expected to be able to forward the packets towards the
+      destination.
+
+    - The target of the redirect, when the target is the same as the
+      destination, does not carry any host vs. router information.  All
+      that is known is that the destination (i.e., target) is on-link
+      but it could be either a host or a router.
+
+   The rules for setting the IsRouter flag are based on the information
+   content above.  If an ND message contains explicit or implicit
+   information, the receipt of the message will cause the IsRouter flag
+   to be updated.  But when there is no host vs. router information in
+   the ND message, the receipt of the message MUST NOT cause a change to
+   the IsRouter state.  When the receipt of such a message causes a
+   Neighbor Cache entry to be created, this document specifies that the
+   IsRouter flag be set to FALSE.  There is greater potential for
+   mischief when a node incorrectly thinks a host is a router, than the
+   other way around.  In these cases, a subsequent Neighbor
+   Advertisement or Router Advertisement message will set the correct
+   IsRouter value.
+
+Appendix E: Implementation Issues
+
+E.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 acknowledgment 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
+      and the ACK of that packet on the passively opening peer.
+
+
+
+
+Narten, et al.              Standards Track                    [Page 92]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+    - Receipt of new data (i.e., data not previously received) indicates
+      that the forward-path was working at the time an acknowledgment
+      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
+   implementations, 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; it 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 (Remote Procedure Call (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 cannot determine
+   whether a received request indicates that a previous response reached
+   the client.
+
+   Note that an implementation cannot use negative upper-layer advice as
+   a replacement for the Neighbor Unreachability Detection algorithm.
+   Negative advice (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 acknowledgment packets to reach the sender.
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 93]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+Appendix F: Changes from RFC 2461
+
+   o Removed references to IPsec AH and ESP for securing messages or as
+     part of validating the received message.
+
+   o Added Section 3.3.
+
+   o Updated Section 11 to include more detailed discussion on threats,
+     IPsec limitations, and use of SEND.
+
+   o Removed the on-link assumption in Section 5.2 based on RFC 4942,
+     "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful".
+
+   o Clarified the definition of the Router Lifetime field in Section
+     4.2.
+
+   o Updated the text in Sections 4.6.2 and 6.2.1 to indicate that the
+     preferred lifetime must not be larger than valid lifetime.
+
+   o Removed the reference to stateful configuration and added reference
+     for DHCPv6 instead.
+
+   o Added the IsRouter flag definition to Section 6.2.1 to allow for
+     mixed host/router behavior.
+
+   o Allowed mobile nodes to be exempt from adding random delays before
+     sending an RS during a handover.
+
+   o Updated the definition of the prefix length in the prefix option.
+
+   o Updated the applicability to NBMA links in the introduction and
+     added references to 3GPP RFCs.
+
+   o Clarified that support for load balancing is limited to routers.
+
+   o Clarified router behavior when receiving a Router Solicitation
+     without Source Link-Layer Address Option (SLLAO).
+
+   o Clarified that inconsistency checks for CurHopLimit are done for
+     non-zero values only.
+
+   o Rearranged Section 7.2.5 for clarity, and described the processing
+     when receiving the NA in INCOMPLETE state.
+
+   o Added clarifications in Section 7.2 on how a node should react upon
+     receiving a message without SLLAO.
+
+   o Added new IANA section.
+
+
+
+Narten, et al.              Standards Track                    [Page 94]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+   o Miscellaneous editorials.
+
+Acknowledgments
+
+   The authors of RFC 2461 would like to acknowledge the contributions
+   of the IPV6 working group and, in particular, (in alphabetical order)
+   Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering,
+   Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert
+   Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins,
+   Matt Thomas, and Susan Thomson.
+
+   The editor of this document (Hesham Soliman) would like to thank the
+   IPV6 working group for the numerous contributions to this revision --
+   in particular (in alphabetical order), Greg Daley, Elwyn Davies,
+   Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola,
+   Fred Templin, and Christian Vogt.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 95]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+Authors' Addresses
+
+   Thomas Narten
+   IBM Corporation
+   P.O. Box 12195
+   Research Triangle Park, NC 27709-2195
+   USA
+
+   Phone: +1 919 254 7798
+   EMail: narten@us.ibm.com
+
+
+   Erik Nordmark
+   Sun Microsystems, Inc.
+   17 Network Circle
+   Menlo Park, CA 94025
+   USA
+
+   Phone: +1 650 786 2921
+   Fax:   +1 650 786 5896
+   EMail: erik.nordmark@sun.com
+
+
+   William Allen Simpson
+   Daydreamer
+   Computer Systems Consulting Services
+   1384 Fontaine
+   Madison Heights, Michigan  48071
+   USA
+
+   EMail: william.allen.simpson@gmail.com
+
+
+   Hesham Soliman
+   Elevate Technologies
+
+   EMail: hesham@elevatemobile.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 96]
+
+RFC 4861               Neighbor Discovery in IPv6         September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
+   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
+   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Narten, et al.              Standards Track                    [Page 97]
+