ipv6: initial dhcpv6 support

17 files changed, 9436 insertions, 44 deletions

diff --git a/accel-pppd/CMakeLists.txt b/accel-pppd/CMakeLists.txt
index 807f039c..cdc2d3ea 100644
--- a/accel-pppd/CMakeLists.txt
+++ b/accel-pppd/CMakeLists.txt
@@ -52,6 +52,7 @@ ADD_SUBDIRECTORY(ctrl)
 ADD_SUBDIRECTORY(auth)
 ADD_SUBDIRECTORY(logs)
 ADD_SUBDIRECTORY(extra)
+ADD_SUBDIRECTORY(ipv6)
 
 ADD_EXECUTABLE(accel-pppd
 	ppp/ppp.c
@@ -69,7 +70,6 @@ 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/accel-ppp.conf b/accel-pppd/accel-ppp.conf
index 3470abab..d7e4814d 100644
--- a/accel-pppd/accel-ppp.conf
+++ b/accel-pppd/accel-ppp.conf
@@ -16,6 +16,8 @@ sigchld
 pppd_compat
 #shaper_tbf
 #chap-secrets
+#ipv6_nd
+#ipv6_dhcp
 
 [core]
 log-error=/var/log/accel-ppp/core.log
@@ -32,7 +34,7 @@ mru=1400
 #single-session=replace
 #mppe=require
 ipv4=require
-ipv6=allow
+ipv6=deny
 ipv6-intf-id=0:0:0:1
 ipv6-peer-intf-id=0:0:0:2
 ipv6-accept-peer-intf-id=1
@@ -149,3 +151,6 @@ tcp=127.0.0.1:2001
 [snmp]
 master=0
 agent-name=accel-ppp
+
+[dhcpv6]
+verbose=1
diff --git a/accel-pppd/extra/ipv6pool.c b/accel-pppd/extra/ipv6pool.c
index 8fe8ce2f..e9fb52d5 100644
--- a/accel-pppd/extra/ipv6pool.c
+++ b/accel-pppd/extra/ipv6pool.c
@@ -40,7 +40,6 @@ static void generate_pool(struct in6_addr *addr, int mask, int prefix_len)
 		it = malloc(sizeof(*it));
 		it->it.owner = &ipdb;
 		INIT_LIST_HEAD(&it->it.addr_list);
-		INIT_LIST_HEAD(&it->it.route_list);
 		a = malloc(sizeof(*a));
 		memset(a, 0, sizeof(*a));
 		*(uint64_t *)a->addr.s6_addr = htobe64(ip);
@@ -104,6 +103,7 @@ static struct ipv6db_item_t *get_ip(struct ppp_t *ppp)
 		it = list_entry(ippool.next, typeof(*it), entry);
 		list_del(&it->entry);
 		it->it.intf_id = 0;
+		it->it.peer_intf_id = 0;
 	} else
 		it = NULL;
 	spin_unlock(&pool_lock);
diff --git a/accel-pppd/ipdb.h b/accel-pppd/ipdb.h
index 69d54792..1fcaf616 100644
--- a/accel-pppd/ipdb.h
+++ b/accel-pppd/ipdb.h
@@ -18,14 +18,15 @@ struct ipv6db_addr_t
 	struct list_head entry;
 	struct in6_addr addr;
 	int prefix_len;
+	int flag_auto:1;
 };
 
 struct ipv6db_item_t
 {
 	struct ipdb_t *owner;
 	uint64_t intf_id;
+	uint64_t peer_intf_id;
 	struct list_head addr_list;
-	struct list_head route_list;
 };
 
 
diff --git a/accel-pppd/ipv6/CMakeLists.txt b/accel-pppd/ipv6/CMakeLists.txt
new file mode 100644
index 00000000..9f8c3d1d
--- /dev/null
+++ b/accel-pppd/ipv6/CMakeLists.txt
@@ -0,0 +1,7 @@
+ADD_LIBRARY(ipv6_dhcp SHARED dhcpv6.c dhcpv6_packet.c)
+ADD_LIBRARY(ipv6_nd SHARED nd.c)
+
+INSTALL(TARGETS ipv6_dhcp ipv6_nd
+	LIBRARY DESTINATION lib/accel-ppp
+)
+
diff --git a/accel-pppd/ipv6/dhcpv6.c b/accel-pppd/ipv6/dhcpv6.c
new file mode 100644
index 00000000..c431fbee
--- /dev/null
+++ b/accel-pppd/ipv6/dhcpv6.c
@@ -0,0 +1,551 @@
+#include <unistd.h>
+#include <stdlib.h>
+#include <stdio.h>
+#include <stdarg.h>
+#include <errno.h>
+#include <string.h>
+#include <fcntl.h>
+#include <time.h>
+#include <pthread.h>
+#include <arpa/inet.h>
+#include <netinet/in.h>
+#include <sys/socket.h>
+
+#include "triton.h"
+#include "mempool.h"
+#include "log.h"
+#include "ppp.h"
+#include "ipdb.h"
+#include "events.h"
+
+#include "memdebug.h"
+
+#include "dhcpv6.h"
+
+#define BUF_SIZE 65536
+#define MAX_DNS_COUNT 3
+
+static int conf_verbose;
+static int conf_pref_lifetime = -1;
+static int conf_valid_lifetime = -1;
+static struct in6_addr conf_dns[MAX_DNS_COUNT];
+static int conf_dns_count;
+static void *conf_dnssl;
+static int conf_dnssl_size;
+
+struct dhcpv6_pd
+{
+	struct ppp_pd_t pd;
+	struct dhcpv6_opt_clientid *clientid;
+	struct dhcpv6_opt_serverid serverid;
+	uint32_t iaid;
+};
+
+static struct triton_md_handler_t dhcpv6_hnd;
+static struct triton_context_t dhcpv6_ctx;
+
+static uint8_t *buf;
+static void *pd_key;
+
+static void ev_ppp_started(struct ppp_t *ppp)
+{
+	struct ipv6_mreq mreq;
+	struct dhcpv6_pd *pd;
+	time_t t, t0;
+	struct tm tm;
+
+	if (!ppp->ipv6)
+		return;
+
+	time(&t);
+	localtime_r(&t, &tm);
+
+	tm.tm_year = 100;
+	tm.tm_mon = 0;
+	tm.tm_mday = 1;
+	tm.tm_hour = 0;
+	tm.tm_min = 0;
+	tm.tm_sec = 0;
+
+	t0 = mktime(&tm);
+
+	pd = _malloc(sizeof(*pd));
+	memset(pd, 0, sizeof(*pd));
+	
+	pd->pd.key = &pd_key;
+
+	pd->serverid.hdr.code = htons(D6_OPTION_SERVERID);
+	pd->serverid.hdr.len = htons(16);
+	pd->serverid.duid.type = htons(DUID_LLT);
+	pd->serverid.duid.u.llt.htype = htons(27);
+	pd->serverid.duid.u.llt.time = htonl(t - t0);
+	*(uint64_t *)pd->serverid.duid.u.llt.addr = ppp->ipv6->intf_id;
+
+	list_add_tail(&pd->pd.entry, &ppp->pd_list);
+
+	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(0x010002);
+
+	if (setsockopt(dhcpv6_hnd.fd, SOL_IPV6, IPV6_ADD_MEMBERSHIP, &mreq, sizeof(mreq))) {
+		log_ppp_error("dhcpv6: failed to join to All_DHCP_Relay_Agents_and_Servers\n");
+		return;
+	}
+}
+
+static struct dhcpv6_pd *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, struct dhcpv6_pd, pd);
+	}
+
+	return NULL;
+}
+
+static void ev_ppp_finished(struct ppp_t *ppp)
+{
+	struct dhcpv6_pd *pd = find_pd(ppp);
+
+	if (!pd)
+		return;
+
+	list_del(&pd->pd.entry);
+
+	if (pd->clientid)
+		_free(pd->clientid);
+
+	_free(pd);
+}
+
+static void dhcpv6_send(struct dhcpv6_packet *reply)
+{
+	struct sockaddr_in6 addr;
+
+	memset(&addr, 0, sizeof(addr));
+	addr.sin6_family = AF_INET6;
+	addr.sin6_port = htons(DHCPV6_CLIENT_PORT);
+	addr.sin6_addr.s6_addr32[0] = htons(0xfe80);
+	*(uint64_t *)(addr.sin6_addr.s6_addr + 8) = reply->ppp->ipv6->peer_intf_id;
+	addr.sin6_scope_id = reply->ppp->ifindex;
+
+	sendto(dhcpv6_hnd.fd, reply->hdr, reply->endptr - (void *)reply->hdr, 0, (struct sockaddr *)&addr, sizeof(addr));
+	printf("sendto: %s %i\n", strerror(errno), errno);
+}
+
+static void build_addr(struct ipv6db_addr_t *a, uint64_t intf_id, struct in6_addr *addr)
+{
+	memcpy(addr, &a->addr, sizeof(*addr));
+
+	if (a->prefix_len <= 64)
+		*(uint64_t *)(addr->s6_addr + 8) = intf_id;
+	else
+		*(uint64_t *)(addr->s6_addr + 8) |= intf_id & ((1 << (128 - a->prefix_len)) - 1);
+}
+
+static void dhcpv6_send_reply(struct dhcpv6_packet *req, struct dhcpv6_pd *pd, int code)
+{
+	struct dhcpv6_packet *reply;
+	struct dhcpv6_option *opt, *opt1, *opt2, *opt3, *opt4;
+	struct dhcpv6_opt_ia_na *ia_na;
+	struct dhcpv6_opt_ia_addr *ia_addr;
+	struct dhcpv6_opt_status *status;
+	struct ipv6db_addr_t *a;
+	struct in6_addr addr, *addr_ptr;
+	int i, j, f = 0, f1;
+	uint16_t *ptr;
+
+	reply = dhcpv6_packet_alloc_reply(req, code);
+	if (!reply)
+		return;
+	
+	list_for_each_entry(opt, &req->opt_list, entry) {
+		if (ntohs(opt->hdr->code) == D6_OPTION_IA_NA) {
+			opt1 = dhcpv6_option_alloc(reply, D6_OPTION_IA_NA, sizeof(struct dhcpv6_opt_ia_na) - sizeof(struct dhcpv6_opt_hdr));
+			memcpy(opt1->hdr + 1, opt->hdr + 1, ntohs(opt1->hdr->len));
+			if (list_empty(&req->ppp->ipv6->addr_list) || f) {
+				opt3 = dhcpv6_nested_option_alloc(reply, opt1, D6_OPTION_STATUS_CODE, sizeof(struct dhcpv6_opt_status) - sizeof(struct dhcpv6_opt_hdr));
+				status = (struct dhcpv6_opt_status *)opt3->hdr;
+				status->code = htons(D6_STATUS_NoAddrsAvail);
+			} else {
+				if (code == D6_REPLY) {
+					ia_na = (struct dhcpv6_opt_ia_na *)opt->hdr;
+					pd->iaid = ia_na->iaid;
+				}
+
+				f = 1;
+
+				list_for_each_entry(a, &req->ppp->ipv6->addr_list, entry) {
+					opt2 = dhcpv6_nested_option_alloc(reply, opt1, D6_OPTION_IAADDR, sizeof(*ia_addr) - sizeof(struct dhcpv6_opt_hdr));
+					ia_addr = (struct dhcpv6_opt_ia_addr *)opt2->hdr;
+
+					build_addr(a, req->ppp->ipv6->peer_intf_id, &ia_addr->addr);
+
+					ia_addr->pref_lifetime = htonl(conf_pref_lifetime);
+					ia_addr->valid_lifetime = htonl(conf_valid_lifetime);	
+				}
+
+				list_for_each_entry(opt2, &opt->opt_list, entry) {
+					if (ntohs(opt2->hdr->code) == D6_OPTION_IAADDR) {
+						ia_addr = (struct dhcpv6_opt_ia_addr *)opt2->hdr;
+						f1 = 0;
+						list_for_each_entry(a, &req->ppp->ipv6->addr_list, entry) {
+							build_addr(a, req->ppp->ipv6->peer_intf_id, &addr);
+							if (memcmp(&addr, &ia_addr->addr, sizeof(addr)))
+								continue;
+							f1 = 1;
+							break;
+						}
+
+						if (!f1) {
+							opt3 = dhcpv6_nested_option_alloc(reply, opt1, D6_OPTION_IAADDR, sizeof(*ia_addr) - sizeof(struct dhcpv6_opt_hdr));
+							memcpy(opt3->hdr->data, opt2->hdr->data, sizeof(*ia_addr) - sizeof(struct dhcpv6_opt_hdr));
+							opt4 = dhcpv6_nested_option_alloc(reply, opt3, D6_OPTION_STATUS_CODE, sizeof(struct dhcpv6_opt_status) - sizeof(struct dhcpv6_opt_hdr));
+							status = (struct dhcpv6_opt_status *)opt4->hdr;
+							status->code = htons(D6_STATUS_NotOnLink);
+						}
+					}
+				}
+			}
+		} else if (ntohs(opt->hdr->code) == D6_OPTION_IA_TA) {
+			opt1 = dhcpv6_option_alloc(reply, D6_OPTION_IA_TA, sizeof(struct dhcpv6_opt_ia_ta) - sizeof(struct dhcpv6_opt_hdr));
+			memcpy(opt1->hdr + 1, opt->hdr + 1, ntohs(opt1->hdr->len));
+			opt3 = dhcpv6_nested_option_alloc(reply, opt1, D6_OPTION_STATUS_CODE, sizeof(struct dhcpv6_opt_status) - sizeof(struct dhcpv6_opt_hdr));
+			status = (struct dhcpv6_opt_status *)opt3->hdr;
+			status->code = htons(D6_STATUS_NoAddrsAvail);
+		}	else if (ntohs(opt->hdr->code) == D6_OPTION_ORO) {
+			for (i = ntohs(opt->hdr->len) / 2, ptr = (uint16_t *)opt->hdr->data; i; i--, ptr++) {
+				if (ntohs(*ptr) == D6_OPTION_DNS_SERVERS) {
+					opt1 = dhcpv6_option_alloc(reply, D6_OPTION_DNS_SERVERS, conf_dns_count * sizeof(addr));
+					for (j = 0, addr_ptr = (struct in6_addr *)opt1->hdr->data; j < conf_dns_count; j++, addr_ptr++)
+						memcpy(addr_ptr, conf_dns + j, sizeof(addr));
+				} else if (ntohs(*ptr) == D6_OPTION_DOMAIN_LIST) {
+					opt1 = dhcpv6_option_alloc(reply, D6_OPTION_DOMAIN_LIST, conf_dnssl_size);
+					memcpy(opt1->hdr->data, conf_dnssl, conf_dnssl_size);
+				}
+			}
+		}
+	}
+				
+	opt3 = dhcpv6_option_alloc(reply, D6_OPTION_STATUS_CODE, sizeof(struct dhcpv6_opt_status) - sizeof(struct dhcpv6_opt_hdr));
+	status = (struct dhcpv6_opt_status *)opt3->hdr;
+	status->code = htons(D6_STATUS_Success);
+
+	if (conf_verbose) {
+		log_ppp_info2("send ");
+		dhcpv6_packet_print(reply, log_ppp_info2);
+	}
+
+	dhcpv6_send(reply);
+
+	dhcpv6_packet_free(reply);
+}
+
+static void dhcpv6_recv_solicit(struct dhcpv6_packet *req)
+{
+	struct dhcpv6_pd *pd = find_pd(req->ppp);
+
+	if (!pd)
+		return;
+	
+	if (!req->clientid) {
+		log_ppp_error("dhcpv6: no Client-ID option\n");
+		return;
+	}
+
+	if (req->serverid) {
+		log_ppp_error("dhcpv6: unexpected Server-ID option\n");
+		return;
+	}
+
+	req->serverid = &pd->serverid;
+
+	if (!pd->clientid) {
+		pd->clientid = _malloc(sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len));
+		memcpy(pd->clientid, req->clientid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len));
+	} else if (pd->clientid->hdr.len != req->clientid->hdr.len || memcmp(pd->clientid, req->clientid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len))) {
+		log_ppp_warn("dhcpv6: Client-ID option was changed\n");
+		return;
+	}
+
+	dhcpv6_send_reply(req, pd, D6_ADVERTISE);
+}
+
+static void dhcpv6_recv_request(struct dhcpv6_packet *req)
+{
+	struct dhcpv6_pd *pd = find_pd(req->ppp);
+
+	if (!pd)
+		return;
+	
+	if (!req->clientid) {
+		log_ppp_error("dhcpv6: no Client-ID option\n");
+		return;
+	}
+
+	if (!req->serverid) {
+		log_ppp_error("dhcpv6: no Server-ID option\n");
+		return;
+	}
+
+	if (!pd->clientid) {
+		pd->clientid = _malloc(sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len));
+		memcpy(pd->clientid, req->clientid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len));
+	} else if (pd->clientid->hdr.len != req->clientid->hdr.len || memcmp(pd->clientid, req->clientid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len))) {
+		log_ppp_warn("dhcpv6: Client-ID option was changed\n");
+		return;
+	}
+	
+	dhcpv6_send_reply(req, pd, D6_REPLY);
+}
+
+static void dhcpv6_recv_renew(struct dhcpv6_packet *pkt)
+{
+
+}
+
+static void dhcpv6_recv_rebind(struct dhcpv6_packet *pkt)
+{
+
+}
+
+static void dhcpv6_recv_release(struct dhcpv6_packet *pkt)
+{
+
+}
+
+static void dhcpv6_recv_decline(struct dhcpv6_packet *pkt)
+{
+
+}
+
+static void dhcpv6_recv_packet(struct dhcpv6_packet *pkt)
+{
+	if (conf_verbose) {
+		log_ppp_info2("recv ");
+		dhcpv6_packet_print(pkt, log_ppp_info2);
+	}
+
+	switch (pkt->hdr->type) {
+		case D6_SOLICIT:
+			dhcpv6_recv_solicit(pkt);
+			break;
+		case D6_REQUEST:
+			dhcpv6_recv_request(pkt);
+			break;
+		case D6_RENEW:
+			dhcpv6_recv_renew(pkt);
+			break;
+		case D6_REBIND:
+			dhcpv6_recv_rebind(pkt);
+			break;
+		case D6_RELEASE:
+			dhcpv6_recv_release(pkt);
+			break;
+		case D6_DECLINE:
+			dhcpv6_recv_decline(pkt);
+			break;
+	}
+
+	dhcpv6_packet_free(pkt);
+}
+
+static int dhcpv6_read(struct triton_md_handler_t *h)
+{
+	int n;
+	struct sockaddr_in6 addr;
+	socklen_t len = sizeof(addr);
+	struct dhcpv6_packet *pkt;
+	struct ppp_t *ppp;
+
+	while (1) {
+		n = recvfrom(h->fd, buf, BUF_SIZE, 0, &addr, &len);
+		if (n == -1) {
+			if (errno == EAGAIN)
+				return 0;
+			log_error("dhcpv6: read: %s\n", strerror(errno));
+		}
+
+		if (!IN6_IS_ADDR_LINKLOCAL(&addr.sin6_addr))
+			continue;
+
+		if (addr.sin6_port != ntohs(DHCPV6_CLIENT_PORT))
+			continue;
+
+		pkt = dhcpv6_packet_parse(buf, n);
+		if (!pkt || !pkt->clientid) {
+			continue;
+		}
+
+		pthread_rwlock_rdlock(&ppp_lock);
+		list_for_each_entry(ppp, &ppp_list, entry) {
+			if (ppp->state != PPP_STATE_ACTIVE)
+				continue;
+
+			if (!ppp->ipv6)
+				continue;
+
+			if (ppp->ifindex != addr.sin6_scope_id)
+				continue;
+
+			if (ppp->ipv6->peer_intf_id != *(uint64_t *)(addr.sin6_addr.s6_addr + 8))
+				continue;
+
+			pkt->ppp = ppp;
+
+			triton_context_call(ppp->ctrl->ctx, (triton_event_func)dhcpv6_recv_packet, pkt);
+			break;
+		}
+		pthread_rwlock_unlock(&ppp_lock);
+	}
+
+	return 0;
+}
+
+static void dhcpv6_close(struct triton_context_t *ctx)
+{
+	triton_md_unregister_handler(&dhcpv6_hnd);
+	close(dhcpv6_hnd.fd);
+	triton_context_unregister(ctx);
+}
+
+static struct triton_md_handler_t dhcpv6_hnd = {
+	.read = dhcpv6_read,
+};
+
+static struct triton_context_t dhcpv6_ctx = {
+	.close = dhcpv6_close,
+};
+
+static void add_dnssl(const char *val)
+{
+	int n = strlen(val);
+	const char *ptr;
+	uint8_t *buf;
+
+	if (val[n - 1] == '.')
+		n++;
+	else
+		n += 2;
+	
+	if (n > 255) {
+		log_error("dnsv6: dnssl '%s' is too long\n", val);
+		return;
+	}
+	
+	if (!conf_dnssl)
+		conf_dnssl = _malloc(n);
+	else
+		conf_dnssl = _realloc(conf_dnssl, conf_dnssl_size + n);
+	
+	buf = conf_dnssl + conf_dnssl_size;
+	
+	while (1) {
+		ptr = strchr(val, '.');
+		if (!ptr)
+			ptr = strchr(val, 0);
+		if (ptr - val > 63) {
+			log_error("dnsv6: dnssl '%s' is invalid\n", val);
+			return;
+		}
+		*buf = ptr - val;
+		memcpy(buf + 1, val, ptr - val);
+		buf += 1 + (ptr - val);
+		val = ptr + 1;
+		if (!*ptr || !*val) {
+				*buf = 0;
+				break;
+		}
+	}
+	
+	conf_dnssl_size += n;
+}
+
+static void load_dns(void)
+{
+	struct conf_sect_t *s = conf_get_section("dnsv6");
+	struct conf_option_t *opt;
+	
+	if (!s)
+		return;
+	
+	conf_dns_count = 0;
+	
+	if (conf_dnssl)
+		_free(conf_dnssl);
+	conf_dnssl = NULL;
+	conf_dnssl_size = 0;
+
+	list_for_each_entry(opt, &s->items, entry) {
+		if (!strcmp(opt->name, "dnssl")) {
+			add_dnssl(opt->val);
+			continue;
+		}
+
+		if (!strcmp(opt->name, "dns") || !opt->val) {
+			if (conf_dns_count == MAX_DNS_COUNT)
+				continue;
+
+			if (inet_pton(AF_INET6, opt->val ? opt->val : opt->name, &conf_dns[conf_dns_count]) == 0) {
+				log_error("dnsv6: faild to parse '%s'\n", opt->name);
+				continue;
+			}
+			conf_dns_count++;
+		}
+	}
+}
+
+static void load_config(void)
+{
+	const char *opt;
+
+	opt = conf_get_opt("dhcpv6", "verbose");
+	if (opt)
+		conf_verbose = atoi(opt);
+	
+	load_dns();
+}
+
+static void init(void)
+{
+	struct sockaddr_in6 addr;
+	int sock;
+
+	load_config();
+
+	sock = socket(AF_INET6, SOCK_DGRAM, 0);
+	if (!sock) {
+		log_error("dhcpv6: socket: %s\n", strerror(errno));
+		return;
+	}
+
+	memset(&addr, 0, sizeof(addr));
+	addr.sin6_family = AF_INET6;
+	addr.sin6_port = htons(DHCPV6_SERV_PORT);
+	
+	if (bind(sock, (struct sockaddr *)&addr, sizeof(addr))) {
+		log_error("dhcpv6: bind: %s\n", strerror(errno));
+		close(sock);
+		return;
+	}
+
+	fcntl(sock, F_SETFL, O_NONBLOCK);
+
+	dhcpv6_hnd.fd = sock;
+
+	buf = malloc(BUF_SIZE);
+
+	triton_context_register(&dhcpv6_ctx, NULL);
+	triton_md_register_handler(&dhcpv6_ctx, &dhcpv6_hnd);
+	triton_md_enable_handler(&dhcpv6_hnd, MD_MODE_READ);
+	triton_context_wakeup(&dhcpv6_ctx);
+
+	triton_event_register_handler(EV_CONFIG_RELOAD, (triton_event_func)load_config);
+	triton_event_register_handler(EV_PPP_STARTED, (triton_event_func)ev_ppp_started);
+	triton_event_register_handler(EV_PPP_FINISHED, (triton_event_func)ev_ppp_finished);
+}
+
+DEFINE_INIT(10, init);
diff --git a/accel-pppd/ipv6/dhcpv6.h b/accel-pppd/ipv6/dhcpv6.h
new file mode 100644
index 00000000..6c5d164c
--- /dev/null
+++ b/accel-pppd/ipv6/dhcpv6.h
@@ -0,0 +1,175 @@
+#ifndef __DHCPV6_H
+#define __DHCPV6_H
+
+#include <stdint.h>
+#include <netinet/in.h>
+
+#include "list.h"
+
+#define __packed __attribute__((packed))
+
+#define DHCPV6_CLIENT_PORT 546
+#define DHCPV6_SERV_PORT 547
+
+#define D6_OPTION_CLIENTID         1
+#define D6_OPTION_SERVERID         2
+#define D6_OPTION_IA_NA            3
+#define D6_OPTION_IA_TA            4
+#define D6_OPTION_IAADDR           5
+#define D6_OPTION_ORO              6
+#define D6_OPTION_PREFERENCE       7
+#define D6_OPTION_ELAPSED_TIME     8
+#define D6_OPTION_RELAY_MSG        9
+#define D6_OPTION_AUTH            11
+#define D6_OPTION_UNICAST         12
+#define D6_OPTION_STATUS_CODE     13
+#define D6_OPTION_RAPID_COMMIT    14
+#define D6_OPTION_USER_CLASS      15
+#define D6_OPTION_VENDOR_CLASS    16
+#define D6_OPTION_VENDOR_SPECIFIC 17
+#define D6_OPTION_INTERFACE_ID    18
+#define D6_OPTION_RECONF_MSG      19
+#define D6_OPTION_RECONF_ACCEPT   20
+#define D6_OPTION_DNS_SERVERS     23
+#define D6_OPTION_DOMAIN_LIST     24
+
+#define D6_SOLICIT                 1
+#define D6_ADVERTISE               2
+#define D6_REQUEST                 3
+#define D6_CONFIRM                 4
+#define D6_RENEW                   5
+#define D6_REBIND                  6
+#define D6_REPLY                   7
+#define D6_RELEASE                 8
+#define D6_DECLINE                 9
+#define D6_RECONFIGURE            10
+#define D6_INFORMATION_REQUEST    11
+#define D6_RELAY_FORM             12
+#define D6_RELAY_REPL             13
+
+#define D6_STATUS_Success          0
+#define D6_STATUS_UnspecFail       1
+#define D6_STATUS_NoAddrsAvail     2
+#define D6_STATUS_NoBinding        3
+#define D6_STATUS_NotOnLink        4
+#define D6_STATUS_UseMulticast     5
+
+#define DUID_LLT 1
+#define DUID_EN  2
+#define DUID_LL  3
+
+struct dhcpv6_opt_hdr
+{
+	uint16_t code;
+	uint16_t len;
+	uint8_t data[0];
+} __packed;
+
+struct dhcpv6_msg_hdr
+{
+	uint32_t type:8;
+	uint32_t trans_id:24;
+	uint8_t data[0];
+} __packed;
+
+struct dhcpv6_duid
+{
+	uint16_t type;
+	union {
+		struct {
+			uint16_t htype;
+			uint32_t time;
+			uint8_t addr[0];
+		} __packed llt;
+		struct {
+			uint32_t enterprise;
+			uint8_t id[0];
+		} en;
+		struct {
+			uint16_t htype;
+			uint8_t addr[0];
+		} ll;
+		uint8_t raw[0];
+	} u;
+} __packed;
+
+struct dhcpv6_opt_clientid
+{
+	struct dhcpv6_opt_hdr hdr;
+	struct dhcpv6_duid duid;
+} __packed;
+
+struct dhcpv6_opt_serverid
+{
+	struct dhcpv6_opt_hdr hdr;
+	struct dhcpv6_duid duid;
+} __packed;
+
+struct dhcpv6_opt_ia_na
+{
+	struct dhcpv6_opt_hdr hdr;
+	uint32_t iaid;
+	uint32_t T1;
+	uint32_t T2;
+} __packed;
+
+struct dhcpv6_opt_ia_ta
+{
+	struct dhcpv6_opt_hdr hdr;
+	uint32_t iaid;
+} __packed;
+
+
+struct dhcpv6_opt_ia_addr
+{
+	struct dhcpv6_opt_hdr hdr;
+	struct in6_addr addr;
+	uint32_t pref_lifetime;
+	uint32_t valid_lifetime;
+} __packed;
+
+struct dhcpv6_opt_oro
+{
+	struct dhcpv6_opt_hdr hdr;
+	uint16_t opt[0];
+} __packed;
+
+struct dhcpv6_opt_status
+{
+	struct dhcpv6_opt_hdr hdr;
+	uint16_t code;
+	char msg[0];
+} __packed;
+
+
+struct dhcpv6_option
+{
+	struct list_head entry;
+
+	struct dhcpv6_opt_hdr *hdr;
+
+	struct dhcpv6_option *parent;
+	struct list_head opt_list;
+};
+
+struct ppp_t;
+struct dhcpv6_packet
+{
+	struct ppp_t *ppp;
+	
+	struct dhcpv6_msg_hdr *hdr;
+	struct dhcpv6_opt_clientid *clientid;
+	struct dhcpv6_opt_serverid *serverid;
+
+	struct list_head opt_list;
+	void *endptr;
+};
+
+struct dhcpv6_packet *dhcpv6_packet_parse(const void *buf, size_t size);
+void dhcpv6_packet_free(struct dhcpv6_packet *pkt);
+void dhcpv6_packet_print(struct dhcpv6_packet *pkt, void (*print)(const char *fmt, ...));
+struct dhcpv6_packet *dhcpv6_packet_alloc_reply(struct dhcpv6_packet *req, int type);
+struct dhcpv6_option *dhcpv6_option_alloc(struct dhcpv6_packet *pkt, int code, int len);
+struct dhcpv6_option *dhcpv6_nested_option_alloc(struct dhcpv6_packet *pkt, struct dhcpv6_option *opt, int code, int len);
+
+#endif
diff --git a/accel-pppd/ipv6/dhcpv6_packet.c b/accel-pppd/ipv6/dhcpv6_packet.c
new file mode 100644
index 00000000..9a709963
--- /dev/null
+++ b/accel-pppd/ipv6/dhcpv6_packet.c
@@ -0,0 +1,438 @@
+#include <stdlib.h>
+#include <string.h>
+#include <arpa/inet.h>
+
+#include "log.h"
+#include "memdebug.h"
+
+#include "dhcpv6.h"
+
+#define BUF_SIZE 4096
+
+struct dict_option {
+	int code;
+	const char *name;
+	int recv;
+	int len;
+	void (*print)(struct dhcpv6_option *, void (*)(const char *fmt, ...));
+};
+
+static void print_clientid(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_ia_na(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_ia_ta(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_ia_addr(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_oro(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_uint8(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_time(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_ipv6addr(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_ipv6addr_array(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_status(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_uint64(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_reconf(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+static void print_dnssl(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...));
+
+static struct dict_option known_options[] = {
+	{ D6_OPTION_CLIENTID, "Client-ID", 1, 0, print_clientid },
+	{ D6_OPTION_SERVERID, "Server-ID", 0, 0, print_clientid },
+	{ D6_OPTION_IA_NA, "IA-NA", 1, sizeof(struct dhcpv6_opt_ia_na), print_ia_na },
+	{ D6_OPTION_IA_TA, "IA-TA", 1, sizeof(struct dhcpv6_opt_ia_ta), print_ia_ta },
+	{ D6_OPTION_IAADDR, "IA-Addr", 1, sizeof(struct dhcpv6_opt_ia_addr), print_ia_addr },
+	{ D6_OPTION_ORO, "Option-Request", 1, 0, print_oro },
+	{ D6_OPTION_PREFERENCE, "Preference", 0, 0, print_uint8 },
+	{ D6_OPTION_ELAPSED_TIME, "Elapsed-Time", 1, 0, print_time },
+	{ D6_OPTION_RELAY_MSG, "Relay-Message", 1, 0 },
+	{ D6_OPTION_AUTH, "Auth", 1, 0 },
+	{ D6_OPTION_PREFERENCE, "Server-Unicast", 0, 0, print_ipv6addr },
+	{ D6_OPTION_STATUS_CODE, "Status", 0, 0, print_status },
+	{ D6_OPTION_RAPID_COMMIT, "Rapid-Commit", 1, 0 },
+	{ D6_OPTION_USER_CLASS, "User-Class", 1, 0 },
+	{ D6_OPTION_VENDOR_CLASS, "Vendor-Class", 1, 0, print_uint64 },
+	{ D6_OPTION_VENDOR_SPECIFIC, "Vendor-Specific", 1, 0, print_uint64 },
+	{ D6_OPTION_INTERFACE_ID, "Interface-ID", 1, 0, print_uint64 },
+	{ D6_OPTION_RECONF_MSG, "Reconfigure", 0, 0, print_reconf },
+	{ D6_OPTION_RECONF_ACCEPT, "Reconfigure-Accept", 1, 0 },
+	{ D6_OPTION_DNS_SERVERS, "DNS", 1, 0, print_ipv6addr_array },
+	{ D6_OPTION_DOMAIN_LIST, "DNSSL", 1, 0, print_dnssl },
+	{ 0 }
+};
+
+static void *parse_option(void *ptr, void *endptr, struct list_head *opt_list)
+{
+	struct dict_option *dopt;
+	struct dhcpv6_opt_hdr *opth = ptr;
+	struct dhcpv6_option *opt;
+
+	if (ptr + sizeof(*opth) + ntohs(opth->len) > endptr) {
+		log_warn("dhcpv6: invalid packet received\n");
+		return NULL;
+	}
+	
+	opt = _malloc(sizeof(*opt));
+	if (!opt) {
+		log_emerg("out of memory\n");
+		return NULL;
+	}
+
+	memset(opt, 0, sizeof(*opt));
+	INIT_LIST_HEAD(&opt->opt_list);
+	opt->hdr = ptr;
+	list_add_tail(&opt->entry, opt_list);
+
+	for (dopt = known_options; dopt->code; dopt++) {
+		if (dopt->code)
+			break;
+	}
+	
+	if (dopt->len) {
+		endptr = ptr + sizeof(*opth) + ntohs(opth->len);
+		ptr += sizeof(*opth) + dopt->len;
+		while (ptr < endptr) {
+			ptr = parse_option(ptr, endptr, &opt->opt_list);
+			if (!ptr)
+				return NULL;
+		}
+	} else
+		ptr = ptr + sizeof(*opth) + ntohs(opth->len);
+	
+	return ptr;
+}
+
+struct dhcpv6_packet *dhcpv6_packet_parse(const void *buf, size_t size)
+{
+	struct dhcpv6_packet *pkt;
+	struct dhcpv6_opt_hdr *opth;
+	void *ptr, *endptr;
+
+	pkt = _malloc(sizeof(*pkt));
+	if (!pkt) {
+		log_emerg("out of memory\n");
+		return NULL;
+	}
+
+	memset(pkt, 0, sizeof(*pkt));
+	INIT_LIST_HEAD(&pkt->opt_list);
+
+	pkt->hdr = _malloc(size);
+	if (!pkt->hdr) {
+		log_emerg("out of memory\n");
+		_free(pkt);
+		return NULL;
+	}
+
+	memcpy(pkt->hdr, buf, size);
+
+	ptr = pkt->hdr->data;
+	endptr =  ((void *)pkt->hdr) + size;
+
+	while (ptr < endptr) {
+		opth = ptr;
+		if (opth->code == htons(D6_OPTION_CLIENTID))
+			pkt->clientid = ptr;
+		else if (opth->code == htons(D6_OPTION_SERVERID))
+			pkt->serverid = ptr;
+		ptr = parse_option(ptr, endptr, &pkt->opt_list);
+		if (!ptr) {
+			dhcpv6_packet_free(pkt);
+			return NULL;
+		}
+	}
+
+	return pkt;
+}
+
+struct dhcpv6_option *dhcpv6_option_alloc(struct dhcpv6_packet *pkt, int code, int len)
+{
+	struct dhcpv6_option *opt;
+	
+	opt = _malloc(sizeof(*opt));
+	if (!opt) {
+		log_emerg("out of memory\n");
+		return NULL;
+	}
+	
+	memset(opt, 0, sizeof(*opt));
+	INIT_LIST_HEAD(&opt->opt_list);
+
+	opt->hdr = pkt->endptr;
+	opt->hdr->code = htons(code);
+	opt->hdr->len = htons(len);
+
+	pkt->endptr += sizeof(struct dhcpv6_opt_hdr) + len;
+
+	list_add_tail(&opt->entry, &pkt->opt_list);
+
+	return opt;
+}
+
+struct dhcpv6_option *dhcpv6_nested_option_alloc(struct dhcpv6_packet *pkt, struct dhcpv6_option *popt, int code, int len)
+{
+	struct dhcpv6_option *opt;
+	
+	opt = _malloc(sizeof(*opt));
+	if (!opt) {
+		log_emerg("out of memory\n");
+		return NULL;
+	}
+	
+	memset(opt, 0, sizeof(*opt));
+	INIT_LIST_HEAD(&opt->opt_list);
+	opt->parent = popt;
+
+	opt->hdr = pkt->endptr;
+	opt->hdr->code = htons(code);
+	opt->hdr->len = htons(len);
+
+	list_add_tail(&opt->entry, &popt->opt_list);
+
+	pkt->endptr += sizeof(struct dhcpv6_opt_hdr) + len;
+
+	while (popt) {
+		popt->hdr->len = htons(ntohs(popt->hdr->len) + sizeof(struct dhcpv6_opt_hdr) + len);
+		popt = popt->parent;
+	}
+
+	return opt;
+}
+
+
+struct dhcpv6_packet *dhcpv6_packet_alloc_reply(struct dhcpv6_packet *req, int type)
+{
+	struct dhcpv6_packet *pkt = _malloc(sizeof(*pkt));
+	struct dhcpv6_option *opt;
+	
+	if (!pkt) {
+		log_emerg("out of memory\n");
+		return NULL;
+	}
+
+	memset(pkt, 0, sizeof(*pkt));
+	INIT_LIST_HEAD(&pkt->opt_list);
+	pkt->ppp = req->ppp;
+
+	pkt->hdr = _malloc(BUF_SIZE);
+	if (!pkt->hdr) {
+		log_emerg("out of memory\n");
+		_free(pkt);
+		return NULL;
+	}
+
+	pkt->hdr->type = type;
+	pkt->hdr->trans_id = req->hdr->trans_id;
+
+	pkt->endptr = pkt->hdr->data;
+
+	opt = dhcpv6_option_alloc(pkt, D6_OPTION_SERVERID, ntohs(req->serverid->hdr.len));
+	memcpy(opt->hdr, req->serverid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->serverid->hdr.len));
+
+	opt = dhcpv6_option_alloc(pkt, D6_OPTION_CLIENTID, ntohs(req->clientid->hdr.len));
+	memcpy(opt->hdr, req->clientid, sizeof(struct dhcpv6_opt_hdr) + ntohs(req->clientid->hdr.len));
+
+	return pkt;
+}
+
+static void free_options(struct list_head *opt_list)
+{
+	struct dhcpv6_option *opt;
+
+	while (!list_empty(opt_list)) {
+		opt = list_entry(opt_list->next, typeof(*opt), entry);
+		list_del(&opt->entry);
+		free_options(&opt->opt_list);
+		_free(opt);
+	}
+}
+
+void dhcpv6_packet_free(struct dhcpv6_packet *pkt)
+{
+	free_options(&pkt->opt_list);
+	_free(pkt->hdr);
+	_free(pkt);
+}
+
+static void print_options(struct list_head *opt_list, int level, void (*print)(const char *fmt, ...))
+{
+	struct dhcpv6_option *opt;
+	struct dict_option *dopt;
+	const char l_open[] = {'<', '{', '('};
+	const char l_close[] = {'>', '}', ')'};
+
+	if (level >= sizeof(l_open))
+		level = sizeof(l_open) - 1;
+
+	list_for_each_entry(opt, opt_list, entry) {
+		for (dopt = known_options; dopt->code; dopt++) {
+			if (htons(dopt->code) == opt->hdr->code)
+				break;
+		}
+		if (dopt->code) {
+			print(" %c%s", l_open[level], dopt->name);
+			if (dopt->print)
+				dopt->print(opt, print);
+
+			print_options(&opt->opt_list, level + 1, print);
+
+			print("%c", l_close[level]);
+		} else
+			print(" %cOption %i%c", l_open[level], ntohs(opt->hdr->code), l_close[level]);
+	}
+}
+
+void dhcpv6_packet_print(struct dhcpv6_packet *pkt, void (*print)(const char *fmt, ...))
+{
+	static const char *type_name[] = {
+		"Solicit",
+		"Advertise",
+		"Request",
+		"Confirt",
+		"Renew",
+		"Rebind",
+		"Reply",
+		"Release",
+		"Decline",
+		"Reconfigure",
+		"Information-Request",
+		"Relay-Form",
+		"Relay-Reply"
+	};
+
+	print("[DHCPv6 ");
+
+	if (pkt->hdr->type == 0 || pkt->hdr->type > 13)
+		print("Unknown");
+	else
+		print("%s", type_name[pkt->hdr->type - 1]);
+	
+	print(" XID=%x", pkt->hdr->trans_id);
+
+	print_options(&pkt->opt_list, 0, print);
+
+	print("]\n");
+}
+
+static void print_clientid(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	int i;
+	struct dhcpv6_opt_clientid *o = (struct dhcpv6_opt_clientid *)opt->hdr;
+
+	print(" %i:", htons(o->duid.type));
+	
+	for (i = 0; i < ntohs(o->hdr.len) - 2; i++)
+		print("%02x", o->duid.u.raw[i]);
+}
+
+static void print_ia_na(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	struct dhcpv6_opt_ia_na *o = (struct dhcpv6_opt_ia_na *)opt->hdr;
+
+	print(" %x T1=%i T2=%i", o->iaid, ntohl(o->T1), ntohl(o->T2));
+}
+
+static void print_ia_ta(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	struct dhcpv6_opt_ia_ta *o = (struct dhcpv6_opt_ia_ta *)opt->hdr;
+
+	print(" %x", o->iaid);
+}
+
+static void print_ia_addr(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	struct dhcpv6_opt_ia_addr *o = (struct dhcpv6_opt_ia_addr *)opt->hdr;
+	char str[50];
+
+	inet_ntop(AF_INET6, &o->addr, str, sizeof(str));
+	print(" %s pref_lifetime=%i valid_lifetime=%i", str, ntohl(o->pref_lifetime), ntohl(o->valid_lifetime));
+}
+
+static void print_oro(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	uint16_t *ptr = (uint16_t *)opt->hdr->data;
+	uint16_t *end_ptr = ptr + ntohs(opt->hdr->len)/2;
+	struct dict_option *dopt;
+	int f = 0;
+
+	for (; ptr < end_ptr; ptr++) {
+		if (f)
+			print(",");
+		else 
+			print(" ");
+
+		for (dopt = known_options; dopt->code; dopt++) {
+			if (ntohs(*ptr) == dopt->code)
+				break;
+		}
+
+		if (dopt->code)
+			print("%s", dopt->name);
+		else
+			print("%i", ntohs(*ptr));
+
+		f = 1;
+	}
+}
+
+static void print_uint8(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	print(" %i", *(uint8_t *)opt->hdr->data);
+}
+
+static void print_time(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	print(" %u", *(uint32_t *)opt->hdr->data);
+}
+
+static void print_ipv6addr(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	char str[50];
+
+	inet_ntop(AF_INET6, opt->hdr->data, str, sizeof(str));
+
+	print(" %s", str);
+}
+
+static void print_ipv6addr_array(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	char str[50];
+	int i;
+	int f = 0;
+	struct in6_addr *addr = (struct in6_addr *)opt->hdr->data;
+
+	for (i = ntohs(opt->hdr->len) / sizeof(*addr); i; i--, addr++) {
+		inet_ntop(AF_INET6, addr, str, sizeof(str));
+		print("%c%s", f ? ',' : ' ', str);
+		f = 1;
+	}
+}
+
+static void print_status(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	struct dhcpv6_opt_status *o = (struct dhcpv6_opt_status *)opt->hdr;
+	static char *status_name[] = {
+		"Success",
+		"UnspecFail",
+		"NoAddrsAvail",
+		"NoBindings",
+		"NotOnLink",
+		"UseMulticast"
+	};
+
+	if (ntohs(o->code) < 0 || ntohs(o->code) > 5)
+		print(" %u", ntohs(o->code));
+	else
+		print(" %s", status_name[ntohs(o->code)]);
+}
+
+static void print_uint64(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+	print(" %llu", *(uint64_t *)opt->hdr->data);
+}
+
+static void print_reconf(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+
+}
+
+static void print_dnssl(struct dhcpv6_option *opt, void (*print)(const char *fmt, ...))
+{
+
+}
+
diff --git a/accel-pppd/ppp/ipv6_nd.c b/accel-pppd/ipv6/nd.c
index 6524c78a..67ba102e 100644
--- a/accel-pppd/ppp/ipv6_nd.c
+++ b/accel-pppd/ipv6/nd.c
@@ -30,6 +30,7 @@ static struct in6_addr conf_dns[MAX_DNS_COUNT];
 static int conf_dns_count;
 static void *conf_dnssl;
 static int conf_dnssl_size;
+static int conf_managed;
 
 #undef ND_OPT_ROUTE_INFORMATION
 #define  ND_OPT_ROUTE_INFORMATION	24
@@ -84,7 +85,7 @@ static void ipv6_nd_send_ra(struct ipv6_nd_handler_t *h, struct sockaddr_in6 *ad
 	void *buf = mempool_alloc(buf_pool), *endptr;
 	struct nd_router_advert *adv = buf;
 	struct nd_opt_prefix_info *pinfo;
-	struct nd_opt_route_info_local *rinfo;
+	//struct nd_opt_route_info_local *rinfo;
 	struct nd_opt_rdnss_info_local *rdnssinfo;
 	struct in6_addr *rdnss_addr;
 	struct nd_opt_dnssl_info_local *dnsslinfo;
@@ -101,23 +102,28 @@ static void ipv6_nd_send_ra(struct ipv6_nd_handler_t *h, struct sockaddr_in6 *ad
 	adv->nd_ra_type = ND_ROUTER_ADVERT;
 	adv->nd_ra_curhoplimit = 64;
 	adv->nd_ra_router_lifetime = htons(conf_router_lifetime);
+	adv->nd_ra_flags_reserved = 
+		conf_managed ? ND_RA_FLAG_MANAGED | ND_RA_FLAG_OTHER : 0;
 	//adv->nd_ra_reachable = 0;
 	//adv->nd_ra_retransmit = 0;
 	
 	pinfo = (struct nd_opt_prefix_info *)(adv + 1);
 	list_for_each_entry(a, &h->ppp->ipv6->addr_list, entry) {
+		if (a->prefix_len == 128)
+			continue;
+			
 		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 = a->prefix_len;
-		pinfo->nd_opt_pi_flags_reserved = ND_OPT_PI_FLAG_ONLINK | ND_OPT_PI_FLAG_AUTO;
+		pinfo->nd_opt_pi_flags_reserved = ND_OPT_PI_FLAG_ONLINK | ((a->flag_auto || !conf_managed) ? ND_OPT_PI_FLAG_AUTO : 0);
 		pinfo->nd_opt_pi_valid_time = 0xffffffff;
 		pinfo->nd_opt_pi_preferred_time = 0xffffffff;
 		memcpy(&pinfo->nd_opt_pi_prefix, &a->addr, 8);
 		pinfo++;
 	}
 	
-	rinfo = (struct nd_opt_route_info_local *)pinfo;
+	/*rinfo = (struct nd_opt_route_info_local *)pinfo;
 	list_for_each_entry(a, &h->ppp->ipv6->route_list, entry) {
 		memset(rinfo, 0, sizeof(*rinfo));
 		rinfo->nd_opt_ri_type = ND_OPT_ROUTE_INFORMATION;
@@ -126,10 +132,10 @@ static void ipv6_nd_send_ra(struct ipv6_nd_handler_t *h, struct sockaddr_in6 *ad
 		rinfo->nd_opt_ri_lifetime = 0xffffffff;
 		memcpy(&rinfo->nd_opt_ri_prefix, &a->addr, 8);
 		rinfo++;
-	}
+	}*/
 
 	if (conf_dns_count) {
-		rdnssinfo = (struct nd_opt_rdnss_info_local *)rinfo;
+		rdnssinfo = (struct nd_opt_rdnss_info_local *)pinfo;
 		memset(rdnssinfo, 0, sizeof(*rdnssinfo));
 		rdnssinfo->nd_opt_rdnssi_type = ND_OPT_RDNSS_INFORMATION;
 		rdnssinfo->nd_opt_rdnssi_len = 1 + 2 * conf_dns_count;
@@ -140,7 +146,7 @@ static void ipv6_nd_send_ra(struct ipv6_nd_handler_t *h, struct sockaddr_in6 *ad
 			rdnss_addr++;
 		}
 	} else
-		rdnss_addr = (struct in6_addr *)rinfo;
+		rdnss_addr = (struct in6_addr *)pinfo;
 	
 	if (conf_dnssl) {
 		dnsslinfo = (struct nd_opt_dnssl_info_local *)rdnss_addr;
@@ -228,7 +234,7 @@ static int ipv6_nd_read(struct triton_md_handler_t *_h)
 	return 0;
 }
 
-int ppp_ipv6_nd_start(struct ppp_t *ppp, uint64_t intf_id)
+static int ipv6_nd_start(struct ppp_t *ppp)
 {
 	int sock;
 	struct icmp6_filter filter;
@@ -247,7 +253,7 @@ int ppp_ipv6_nd_start(struct ppp_t *ppp, uint64_t intf_id)
 	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;
+	*(uint64_t *)(addr.sin6_addr.s6_addr + 8) = ppp->ipv6->intf_id;
 	addr.sin6_scope_id = ppp->ifindex;
 
 	if (bind(sock, (struct sockaddr *)&addr, sizeof(addr))) {
@@ -311,6 +317,8 @@ int ppp_ipv6_nd_start(struct ppp_t *ppp, uint64_t intf_id)
 	triton_md_register_handler(ppp->ctrl->ctx, &h->hnd);
 	triton_md_enable_handler(&h->hnd, MD_MODE_READ);
 
+	triton_timer_add(ppp->ctrl->ctx, &h->timer, 0);
+
 	return 0;
 
 out_err:
@@ -332,12 +340,10 @@ static struct ipv6_nd_handler_t *find_pd(struct ppp_t *ppp)
 
 static void ev_ppp_started(struct ppp_t *ppp)
 {
-	struct ipv6_nd_handler_t *h = find_pd(ppp);
-
-	if (!h)
+	if (!ppp->ipv6)
 		return;
-	
-	triton_timer_add(ppp->ctrl->ctx, &h->timer, 0);
+
+	ipv6_nd_start(ppp);
 }
 
 static void ev_ppp_finishing(struct ppp_t *ppp)
@@ -441,6 +447,8 @@ static void init(void)
 	buf_pool = mempool_create(BUF_SIZE);
 
 	load_config();
+	
+	conf_managed = triton_module_loaded("ipv6_dhcp");
 
 	triton_event_register_handler(EV_CONFIG_RELOAD, (triton_event_func)load_config);
 	triton_event_register_handler(EV_PPP_STARTED, (triton_event_func)ev_ppp_started);
diff --git a/accel-pppd/ppp/ipv6cp_opt_intfid.c b/accel-pppd/ppp/ipv6cp_opt_intfid.c
index 610f0dc3..cc7ce364 100644
--- a/accel-pppd/ppp/ipv6cp_opt_intfid.c
+++ b/accel-pppd/ppp/ipv6cp_opt_intfid.c
@@ -50,8 +50,8 @@ static void ipaddr_print(void (*print)(const char *fmt,...),struct ipv6cp_option
 struct ipaddr_option_t
 {
 	struct ipv6cp_option_t opt;
-	uint64_t intf_id;
 	int started:1;
+	struct ppp_t *ppp;
 };
 
 static struct ipv6cp_option_handler_t ipaddr_opt_hnd =
@@ -72,16 +72,8 @@ static struct ipv6cp_option_t *ipaddr_init(struct ppp_ipv6cp_t *ipv6cp)
 
 	ipaddr_opt->opt.id = CI_INTFID;
 	ipaddr_opt->opt.len = 10;
+	ipaddr_opt->ppp = ipv6cp->ppp;
 
-	switch (conf_intf_id) {
-		case INTF_ID_FIXED:
-			ipaddr_opt->intf_id = conf_intf_id_val;
-			break;
-		case INTF_ID_RANDOM:
-			read(urandom_fd, &ipaddr_opt->intf_id, 8);
-			break;
-	}
-	
 	return &ipaddr_opt->opt;
 }
 
@@ -127,6 +119,23 @@ out:
 	return r;
 }
 
+static uint64_t generate_intf_id(struct ppp_t *ppp)
+{
+	uint64_t id = 0;
+
+	switch (conf_intf_id) {
+		case INTF_ID_FIXED:
+			return conf_intf_id_val;
+			break;
+		//case INTF_ID_RANDOM:
+		default:
+			read(urandom_fd, &id, 8);
+			break;
+	}
+
+	return id;
+}
+	
 static uint64_t generate_peer_intf_id(struct ppp_t *ppp)
 {
 	char str[4];
@@ -166,6 +175,9 @@ static int alloc_ip(struct ppp_t *ppp)
 		log_ppp_warn("ppp: no free IPv6 address\n");
 		return IPV6CP_OPT_CLOSE;
 	}
+
+	if (!ppp->ipv6->intf_id)
+		ppp->ipv6->intf_id = generate_intf_id(ppp);
 	
 	if (conf_check_exists && check_exists(ppp))
 		return IPV6CP_OPT_FAIL;
@@ -187,7 +199,7 @@ static int ipaddr_send_conf_req(struct ppp_ipv6cp_t *ipv6cp, struct ipv6cp_optio
 	
 	opt64->hdr.id = CI_INTFID;
 	opt64->hdr.len = 10;
-	opt64->val = ipaddr_opt->intf_id;
+	opt64->val = ipv6cp->ppp->ipv6->intf_id;
 	return 10;
 }
 
@@ -197,7 +209,7 @@ static int ipaddr_send_conf_nak(struct ppp_ipv6cp_t *ipv6cp, struct ipv6cp_optio
 	struct ipv6cp_opt64_t *opt64 = (struct ipv6cp_opt64_t *)ptr;
 	opt64->hdr.id = CI_INTFID;
 	opt64->hdr.len = 10;
-	opt64->val = ipv6cp->ppp->ipv6->intf_id;
+	opt64->val = ipv6cp->ppp->ipv6->peer_intf_id;
 	return 10;
 }
 
@@ -219,15 +231,15 @@ static int ipaddr_recv_conf_req(struct ppp_ipv6cp_t *ipv6cp, struct ipv6cp_optio
 	}
 
 	if (conf_accept_peer_intf_id && opt64->val)
-		ipv6cp->ppp->ipv6->intf_id = opt64->val;
+		ipv6cp->ppp->ipv6->peer_intf_id = opt64->val;
 
-	if (opt64->val && ipv6cp->ppp->ipv6->intf_id == opt64->val && opt64->val != ipaddr_opt->intf_id) {
+	if (opt64->val && ipv6cp->ppp->ipv6->peer_intf_id == opt64->val && opt64->val != ipv6cp->ppp->ipv6->intf_id) {
 		ipv6cp->delay_ack = ccp_ipcp_started(ipv6cp->ppp);
 		goto ack;
 	}
 		
-	ipv6cp->ppp->ipv6->intf_id = generate_peer_intf_id(ipv6cp->ppp);
-	if (!ipv6cp->ppp->ipv6->intf_id)
+	ipv6cp->ppp->ipv6->peer_intf_id = generate_peer_intf_id(ipv6cp->ppp);
+	if (!ipv6cp->ppp->ipv6->peer_intf_id)
 		return IPV6CP_OPT_TERMACK;
 	
 	return IPV6CP_OPT_NAK;
@@ -251,7 +263,7 @@ ack:
 
 	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;
+	*(uint64_t *)(ifr6.ifr6_addr.s6_addr + 8) = ipv6cp->ppp->ipv6->intf_id;
 	ifr6.ifr6_prefixlen = 64;
 	ifr6.ifr6_ifindex = ipv6cp->ppp->ifindex;
 
@@ -261,7 +273,15 @@ ack:
 	}
 
 	list_for_each_entry(a, &ipv6cp->ppp->ipv6->addr_list, entry) {
-		memcpy(ifr6.ifr6_addr.s6_addr, a->addr.s6_addr, 8);
+		if (a->prefix_len == 128)
+			continue;
+
+		memcpy(ifr6.ifr6_addr.s6_addr, a->addr.s6_addr, 16);
+
+		if (a->prefix_len <= 64)
+			*(uint64_t *)(ifr6.ifr6_addr.s6_addr + 8) = ipv6cp->ppp->ipv6->intf_id;
+		else
+			*(uint64_t *)(ifr6.ifr6_addr.s6_addr + 8) |= ipv6cp->ppp->ipv6->intf_id & ((1 << (128 - a->prefix_len)) - 1);
 
 		if (ioctl(sock6_fd, SIOCSIFADDR, &ifr6)) {
 			log_ppp_error("ppp:ipv6cp: ioctl(SIOCSIFADDR): %s\n", strerror(errno));
@@ -269,9 +289,6 @@ ack:
 		}
 	}
 
-	if (ppp_ipv6_nd_start(ipv6cp->ppp, ipaddr_opt->intf_id))
-		return IPV6CP_OPT_REJ;
-
 	return IPV6CP_OPT_ACK;
 }
 
@@ -284,7 +301,7 @@ static void ipaddr_print(void (*print)(const char *fmt,...), struct ipv6cp_optio
 	if (ptr)
 		*(uint64_t *)(a.s6_addr + 8) = opt64->val;
 	else
-		*(uint64_t *)(a.s6_addr + 8) = ipaddr_opt->intf_id;
+		*(uint64_t *)(a.s6_addr + 8) = ipaddr_opt->ppp->ipv6->intf_id;
 	
 	print("<addr %x:%x:%x:%x>", ntohs(a.s6_addr16[4]), ntohs(a.s6_addr16[5]), ntohs(a.s6_addr16[6]), ntohs(a.s6_addr16[7]));
 }
diff --git a/accel-pppd/ppp/ppp_ipv6cp.c b/accel-pppd/ppp/ppp_ipv6cp.c
index 1a9a334b..816abc42 100644
--- a/accel-pppd/ppp/ppp_ipv6cp.c
+++ b/accel-pppd/ppp/ppp_ipv6cp.c
@@ -30,7 +30,7 @@ struct recv_opt_t
 
 #define START_TIMEOUT 60
 
-static int conf_ipv6 = IPV6_ALLOW;
+static int conf_ipv6 = IPV6_DENY;
 
 static LIST_HEAD(option_handlers);
 static struct ppp_layer_t ipv6cp_layer;
diff --git a/accel-pppd/radius/radius.c b/accel-pppd/radius/radius.c
index 22e4cca9..94f6447d 100644
--- a/accel-pppd/radius/radius.c
+++ b/accel-pppd/radius/radius.c
@@ -122,7 +122,7 @@ int rad_proc_attrs(struct rad_req_t *req)
 				req->rpd->termination_action = attr->val.integer; 
 				break;
 			case Framed_Interface_Id:
-				req->rpd->ipv6_addr.intf_id = attr->val.ifid;
+				req->rpd->ipv6_addr.peer_intf_id = attr->val.ifid;
 				break;
 			case Framed_IPv6_Prefix:
 				a = _malloc(sizeof(*a));
@@ -185,7 +185,10 @@ static struct ipv4db_item_t *get_ipv4(struct ppp_t *ppp)
 static struct ipv6db_item_t *get_ipv6(struct ppp_t *ppp)
 {
 	struct radius_pd_t *rpd = find_pd(ppp);
-	
+
+	rpd->ipv6_addr.owner = &ipdb;
+	rpd->ipv6_addr.intf_id = 0;
+
 	if (!list_empty(&rpd->ipv6_addr.addr_list))
 		return &rpd->ipv6_addr;
 
@@ -218,7 +221,6 @@ static void ppp_starting(struct ppp_t *ppp)
 	pthread_mutex_init(&rpd->lock, NULL);
 	INIT_LIST_HEAD(&rpd->plugin_list);
 	INIT_LIST_HEAD(&rpd->ipv6_addr.addr_list);
-	INIT_LIST_HEAD(&rpd->ipv6_addr.route_list);
 	list_add_tail(&rpd->pd.entry, &ppp->pd_list);
 
 	pthread_rwlock_wrlock(&sessions_lock);
diff --git a/accel-pppd/radius/req.c b/accel-pppd/radius/req.c
index c9b91494..3c4a38b2 100644
--- a/accel-pppd/radius/req.c
+++ b/accel-pppd/radius/req.c
@@ -139,7 +139,7 @@ int rad_req_acct_fill(struct rad_req_t *req)
 			return -1;
 	}
 	if (req->rpd->ppp->ipv6) {
-		if (rad_packet_add_ifid(req->pack, NULL, "Framed-Interface-Id", req->rpd->ppp->ipv6->intf_id))
+		if (rad_packet_add_ifid(req->pack, NULL, "Framed-Interface-Id", req->rpd->ppp->ipv6->peer_intf_id))
 			return -1;
 		list_for_each_entry(a, &req->rpd->ppp->ipv6->addr_list, entry) {
 			if (rad_packet_add_ipv6prefix(req->pack, NULL, "Framed-IPv6-Prefix", &a->addr, a->prefix_len))
diff --git a/rfc/rfc3315.txt b/rfc/rfc3315.txt
new file mode 100644
index 00000000..af601f25
--- /dev/null
+++ b/rfc/rfc3315.txt
@@ -0,0 +1,5659 @@
+
+
+
+
+
+
+Network Working Group                                      R. Droms, Ed.
+Request for Comments: 3315                                         Cisco
+Category: Standards Track                                       J. Bound
+                                                         Hewlett Packard
+                                                                 B. Volz
+                                                                Ericsson
+                                                                T. Lemon
+                                                                 Nominum
+                                                              C. Perkins
+                                                   Nokia Research Center
+                                                               M. Carney
+                                                        Sun Microsystems
+                                                               July 2003
+
+
+         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP
+   servers to pass configuration parameters such as IPv6 network
+   addresses to IPv6 nodes.  It offers the capability of automatic
+   allocation of reusable network addresses and additional configuration
+   flexibility.  This protocol is a stateful counterpart to "IPv6
+   Stateless Address Autoconfiguration" (RFC 2462), and can be used
+   separately or concurrently with the latter to obtain configuration
+   parameters.
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                     [Page 1]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+Table of Contents
+
+   1.  Introduction and Overview . . . . . . . . . . . . . . . . . .   5
+       1.1.   Protocols and Addressing . . . . . . . . . . . . . . .   6
+       1.2.   Client-server Exchanges Involving Two Messages . . . .   6
+       1.3.   Client-server Exchanges Involving Four Messages. . . .   7
+   2.  Requirements. . . . . . . . . . . . . . . . . . . . . . . . .   7
+   3.  Background. . . . . . . . . . . . . . . . . . . . . . . . . .   8
+   4.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   8
+       4.1.   IPv6 Terminology . . . . . . . . . . . . . . . . . . .   9
+       4.2.   DHCP Terminology . . . . . . . . . . . . . . . . . . .  10
+   5.  DHCP Constants. . . . . . . . . . . . . . . . . . . . . . . .  12
+       5.1.   Multicast Addresses. . . . . . . . . . . . . . . . . .  13
+       5.2.   UDP Ports. . . . . . . . . . . . . . . . . . . . . . .  13
+       5.3.   DHCP Message Types . . . . . . . . . . . . . . . . . .  13
+       5.4.   Status Codes . . . . . . . . . . . . . . . . . . . . .  15
+       5.5.   Transmission and Retransmission Parameters . . . . . .  16
+       5.6    Representation of time values and "Infinity" as a time
+              value. . . . . . . . . . . . . . . . . . . . . . . . .  16
+   6.  Client/Server Message Formats . . . . . . . . . . . . . . . .  16
+   7.  Relay Agent/Server Message Formats. . . . . . . . . . . . . .  17
+       7.1.   Relay-forward Message. . . . . . . . . . . . . . . . .  18
+       7.2.   Relay-reply Message. . . . . . . . . . . . . . . . . .  19
+   8.  Representation and Use of Domain Names. . . . . . . . . . . .  19
+   9.  DHCP Unique Identifier (DUID) . . . . . . . . . . . . . . . .  19
+       9.1.   DUID Contents. . . . . . . . . . . . . . . . . . . . .  20
+       9.2.   DUID Based on Link-layer Address Plus Time [DUID-LLT].  20
+       9.3.   DUID Assigned by Vendor Based on Enterprise Number
+              [DUID-EN]. . . . . . . . . . . . . . . . . . . . . . .  22
+       9.4.   DUID Based on Link-layer Address [DUID-LL] . . . . . .  22
+   10. Identity Association. . . . . . . . . . . . . . . . . . . . .  23
+   11. Selecting Addresses for Assignment to an IA . . . . . . . . .  24
+   12. Management of Temporary Addresses . . . . . . . . . . . . . .  25
+   13. Transmission of Messages by a Client. . . . . . . . . . . . .  25
+   14. Reliability of Client Initiated Message Exchanges . . . . . .  26
+   15. Message Validation. . . . . . . . . . . . . . . . . . . . . .  27
+       15.1.  Use of Transaction IDs . . . . . . . . . . . . . . . .  28
+       15.2.  Solicit Message. . . . . . . . . . . . . . . . . . . .  28
+       15.3.  Advertise Message. . . . . . . . . . . . . . . . . . .  28
+       15.4.  Request Message. . . . . . . . . . . . . . . . . . . .  29
+       15.5.  Confirm Message. . . . . . . . . . . . . . . . . . . .  29
+       15.6.  Renew Message. . . . . . . . . . . . . . . . . . . . .  29
+       15.7.  Rebind Message . . . . . . . . . . . . . . . . . . . .  29
+       15.8.  Decline Messages . . . . . . . . . . . . . . . . . . .  30
+       15.9.  Release Message. . . . . . . . . . . . . . . . . . . .  30
+       15.10. Reply Message. . . . . . . . . . . . . . . . . . . . .  30
+       15.11. Reconfigure Message. . . . . . . . . . . . . . . . . .  31
+       15.12. Information-request Message. . . . . . . . . . . . . .  31
+
+
+
+Droms, et al.               Standards Track                     [Page 2]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+       15.13. Relay-forward Message. . . . . . . . . . . . . . . . .  31
+       15.14. Relay-reply Message. . . . . . . . . . . . . . . . . .  31
+   16. Client Source Address and Interface Selection . . . . . . . .  32
+   17. DHCP Server Solicitation. . . . . . . . . . . . . . . . . . .  32
+       17.1.  Client Behavior. . . . . . . . . . . . . . . . . . . .  32
+              17.1.1. Creation of Solicit Messages . . . . . . . . .  32
+              17.1.2. Transmission of Solicit Messages . . . . . . .  33
+              17.1.3. Receipt of Advertise Messages. . . . . . . . .  35
+              17.1.4. Receipt of Reply Message . . . . . . . . . . .  35
+       17.2.  Server Behavior. . . . . . . . . . . . . . . . . . . .  36
+              17.2.1. Receipt of Solicit Messages  . . . . . . . . .  36
+              17.2.2. Creation and Transmission of Advertise Messages 36
+              17.2.3. Creation and Transmission of Reply Messages. .  38
+   18. DHCP Client-Initiated Configuration Exchange. . . . . . . . .  38
+       18.1.  Client Behavior. . . . . . . . . . . . . . . . . . . .  39
+              18.1.1. Creation and Transmission of Request Messages.  39
+              18.1.2. Creation and Transmission of Confirm Messages.  40
+              18.1.3. Creation and Transmission of Renew Messages. .  41
+              18.1.4. Creation and Transmission of Rebind Messages .  43
+              18.1.5. Creation and Transmission of Information-
+                      request Messages  . . .. . . . . . . . . . . .  44
+              18.1.6. Creation and Transmission of Release Messages.  44
+              18.1.7. Creation and Transmission of Decline Messages.  46
+              18.1.8. Receipt of Reply Messages. . . . . . . . . . .  46
+       18.2.  Server Behavior. . . . . . . . . . . . . . . . . . . .  48
+              18.2.1. Receipt of Request Messages. . . . . . . . . .  49
+              18.2.2. Receipt of Confirm Messages. . . . . . . . . .  50
+              18.2.3. Receipt of Renew Messages. . . . . . . . . . .  51
+              18.2.4. Receipt of Rebind Messages . . . . . . . . . .  51
+              18.2.5. Receipt of Information-request Messages. . . .  52
+              18.2.6. Receipt of Release Messages. . . . . . . . . .  53
+              18.2.7. Receipt of Decline Messages. . . . . . . . . .  53
+              18.2.8. Transmission of Reply Messages . . . . . . . .  54
+   19. DHCP Server-Initiated Configuration Exchange. . . . . . . . .  54
+       19.1.  Server Behavior. . . . . . . . . . . . . . . . . . . .  55
+              19.1.1. Creation and Transmission of Reconfigure
+                      Messages . . . . . . . . . . . . . . . . . . .  55
+              19.1.2. Time Out and Retransmission of Reconfigure
+                      Messages . . . . . . . . . . . . . . . . . . .  56
+       19.2.  Receipt of Renew Messages. . . . . . . . . . . . . . .  56
+       19.3.  Receipt of Information-request Messages. . . . . . . .  56
+       19.4.  Client Behavior. . . . . . . . . . . . . . . . . . . .  57
+              19.4.1. Receipt of Reconfigure Messages. . . . . . . .  57
+              19.4.2. Creation and Transmission of Renew Messages. .  58
+              19.4.3. Creation and Transmission of Information-
+                      request Messages . . . . . . . . . . . . . . .  58
+              19.4.4. Time Out and Retransmission of Renew or
+                      Information-request Messages . . . . . . . . .  58
+
+
+
+Droms, et al.               Standards Track                     [Page 3]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+              19.4.5. Receipt of Reply Messages. . . . . . . . . . .  58
+   20. Relay Agent Behavior. . . . . . . . . . . . . . . . . . . . .  58
+       20.1.  Relaying a Client Message or a Relay-forward Message .  59
+              20.1.1. Relaying a Message from a Client . . . . . . .  59
+              20.1.2. Relaying a Message from a Relay Agent. . . . .  59
+       20.2.  Relaying a Relay-reply Message . . . . . . . . . . . .  60
+       20.3.  Construction of Relay-reply Messages . . . . . . . . .  60
+   21. Authentication of DHCP Messages . . . . . . . . . . . . . . .  61
+       21.1.  Security of Messages Sent Between Servers and Relay
+              Agents  . . . . . .  . . . . . . . . . . . . . . . . .  61
+       21.2.  Summary of DHCP Authentication . . . . . . . . . . . .  63
+       21.3.  Replay Detection . . . . . . . . . . . . . . . . . . .  63
+       21.4.  Delayed Authentication Protocol. . . . . . . . . . . .  63
+              21.4.1. Use of the Authentication Option in the Delayed
+                      Authentication Protocol. . . . . . . . . . . .  64
+              21.4.2. Message Validation . . . . . . . . . . . . . .  65
+              21.4.3. Key Utilization  . . . . . . . . . . . . . . .  65
+              21.4.4. Client Considerations for Delayed Authentication
+                      Protocol . . . . . . . . . . . . . . . . . . .  66
+              21.4.5. Server Considerations for Delayed Authentication
+                      Protocol . . . . . . . . . . . . . . . . . . .  67
+       21.5.  Reconfigure Key Authentication Protocol. . . . . . . .  68
+              21.5.1. Use of the Authentication Option in the
+                      Reconfigure Key Authentication Protocol. . . .  69
+              21.5.2. Server considerations for Reconfigure Key
+                      protocol . . . . . . . . . . . . . . . . . . .  69
+              21.5.3. Client considerations for Reconfigure Key
+                      protocol . . . . . . . . . . . . . . . . . . .  70
+   22. DHCP Options. . . . . . . . . . . . . . . . . . . . . . . . .  70
+       22.1.  Format of DHCP Options . . . . . . . . . . . . . . . .  71
+       22.2.  Client Identifier Option . . . . . . . . . . . . . . .  71
+       22.3.  Server Identifier Option . . . . . . . . . . . . . . .  72
+       22.4.  Identity Association for Non-temporary Addresses Option 72
+       22.5.  Identity Association for Temporary Addresses Option. .  75
+       22.6.  IA Address Option. . . . . . . . . . . . . . . . . . .  76
+       22.7.  Option Request Option. . . . . . . . . . . . . . . . .  78
+       22.8.  Preference Option. . . . . . . . . . . . . . . . . . .  79
+       22.9.  Elapsed Time Option. . . . . . . . . . . . . . . . . .  79
+       22.10. Relay Message Option . . . . . . . . . . . . . . . . .  80
+       22.11. Authentication Option. . . . . . . . . . . . . . . . .  81
+       22.12. Server Unicast Option. . . . . . . . . . . . . . . . .  82
+       22.13. Status Code Option . . . . . . . . . . . . . . . . . .  82
+       22.14. Rapid Commit Option. . . . . . . . . . . . . . . . . .  83
+       22.15. User Class Option. . . . . . . . . . . . . . . . . . .  84
+       22.16. Vendor Class Option. . . . . . . . . . . . . . . . . .  85
+       22.17. Vendor-specific Information Option . . . . . . . . . .  86
+       22.18. Interface-Id Option. . . . . . . . . . . . . . . . . .  87
+       22.19. Reconfigure Message Option . . . . . . . . . . . . . .  88
+
+
+
+Droms, et al.               Standards Track                     [Page 4]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+       22.20. Reconfigure Accept Option. . . . . . . . . . . . . . .  89
+   23. Security Considerations . . . . . . . . . . . . . . . . . . .  89
+   24. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  91
+       24.1.  Multicast Addresses. . . . . . . . . . . . . . . . . .  92
+       24.2.  DHCP Message Types . . . . . . . . . . . . . . . . . .  93
+       24.3.  DHCP Options . . . . . . . . . . . . . . . . . . . . .  94
+       24.4.  Status Codes . . . . . . . . . . . . . . . . . . . . .  95
+       24.5.  DUID . . . . . . . . . . . . . . . . . . . . . . . . .  95
+   25. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .  95
+   26. References. . . . . . . . . . . . . . . . . . . . . . . . . .  96
+       26.1.  Normative References . . . . . . . . . . . . . . . . .  96
+       26.2.  Informative References . . . . . . . . . . . . . . . .  97
+   A. Appearance of Options in Message Types . . . . . . . . . . . .  98
+   B. Appearance of Options in the Options Field of DHCP Options . .  99
+   Chair's Address . . . . . . . . . . . . . . . . . . . . . . . . .  99
+   Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . 100
+   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 101
+
+1. Introduction and Overview
+
+   This document describes DHCP for IPv6 (DHCP), a client/server
+   protocol that provides managed configuration of devices.
+
+   DHCP can provide a device with addresses assigned by a DHCP server
+   and other configuration information, which are carried in options.
+   DHCP can be extended through the definition of new options to carry
+   configuration information not specified in this document.
+
+   DHCP is the "stateful address autoconfiguration protocol" and the
+   "stateful autoconfiguration protocol" referred to in "IPv6 Stateless
+   Address Autoconfiguration" [17].
+
+   The operational models and relevant configuration information for
+   DHCPv4 [18][19] and DHCPv6 are sufficiently different that
+   integration between the two services is not included in this
+   document.  If there is sufficient interest and demand, integration
+   can be specified in a document that extends DHCPv6 to carry IPv4
+   addresses and configuration information.
+
+   The remainder of this introduction summarizes DHCP, explaining the
+   message exchange mechanisms and example message flows.  The message
+   flows in sections 1.2 and 1.3 are intended as illustrations of DHCP
+   operation rather than an exhaustive list of all possible
+   client-server interactions.  Sections 17, 18, and 19 explain client
+   and server operation in detail.
+
+
+
+
+
+
+Droms, et al.               Standards Track                     [Page 5]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+1.1. Protocols and Addressing
+
+   Clients and servers exchange DHCP messages using UDP [15].  The
+   client uses a link-local address or addresses determined through
+   other mechanisms for transmitting and receiving DHCP messages.
+
+   DHCP servers receive messages from clients using a reserved,
+   link-scoped multicast address.  A DHCP client transmits most messages
+   to this reserved multicast address, so that the client need not be
+   configured with the address or addresses of DHCP servers.
+
+   To allow a DHCP client to send a message to a DHCP server that is not
+   attached to the same link, a DHCP relay agent on the client's link
+   will relay messages between the client and server.  The operation of
+   the relay agent is transparent to the client and the discussion of
+   message exchanges in the remainder of this section will omit the
+   description of message relaying by relay agents.
+
+   Once the client has determined the address of a server, it may under
+   some circumstances send messages directly to the server using
+   unicast.
+
+1.2. Client-server Exchanges Involving Two Messages
+
+   When a DHCP client does not need to have a DHCP server assign it IP
+   addresses, the client can obtain configuration information such as a
+   list of available DNS servers [20] or NTP servers [21] through a
+   single message and reply exchanged with a DHCP server.  To obtain
+   configuration information the client first sends an
+   Information-Request message to the All_DHCP_Relay_Agents_and_Servers
+   multicast address.  Servers respond with a Reply message containing
+   the configuration information for the client.
+
+   This message exchange assumes that the client requires only
+   configuration information and does not require the assignment of any
+   IPv6 addresses.
+
+   When a server has IPv6 addresses and other configuration information
+   committed to a client, the client and server may be able to complete
+   the exchange using only two messages, instead of four messages as
+   described in the next section.  In this case, the client sends a
+   Solicit message to the All_DHCP_Relay_Agents_and_Servers requesting
+   the assignment of addresses and other configuration information.
+   This message includes an indication that the client is willing to
+   accept an immediate Reply message from the server.  The server that
+   is willing to commit the assignment of addresses to the client
+
+
+
+
+
+Droms, et al.               Standards Track                     [Page 6]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   immediately responds with a Reply message.  The configuration
+   information and the addresses in the Reply message are then
+   immediately available for use by the client.
+
+   Each address assigned to the client has associated preferred and
+   valid lifetimes specified by the server.  To request an extension of
+   the lifetimes assigned to an address, the client sends a Renew
+   message to the server.  The server sends a Reply message to the
+   client with the new lifetimes, allowing the client to continue to use
+   the address without interruption.
+
+1.3. Client-server Exchanges Involving Four Messages
+
+   To request the assignment of one or more IPv6 addresses, a client
+   first locates a DHCP server and then requests the assignment of
+   addresses and other configuration information from the server.  The
+   client sends a Solicit message to the
+   All_DHCP_Relay_Agents_and_Servers address to find available DHCP
+   servers.  Any server that can meet the client's requirements responds
+   with an Advertise message.  The client then chooses one of the
+   servers and sends a Request message to the server asking for
+   confirmed assignment of addresses and other configuration
+   information.  The server responds with a Reply message that contains
+   the confirmed addresses and configuration.
+
+   As described in the previous section, the client sends a Renew
+   message to the server to extend the lifetimes associated with its
+   addresses, allowing the client to continue to use those addresses
+   without interruption.
+
+2. 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 [1].
+
+   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.
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                     [Page 7]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+3. Background
+
+   The IPv6 Specification provides the base architecture and design of
+   IPv6.  Related work in IPv6 that would best serve an implementor to
+   study includes the IPv6 Specification [3], the IPv6 Addressing
+   Architecture [5], IPv6 Stateless Address Autoconfiguration [17], IPv6
+   Neighbor Discovery Processing [13], and Dynamic Updates to DNS [22].
+   These specifications enable DHCP to build upon the IPv6 work to
+   provide both robust stateful autoconfiguration and autoregistration
+   of DNS Host Names.
+
+   The IPv6 Addressing Architecture specification [5] defines the
+   address scope that can be used in an IPv6 implementation, and the
+   various configuration architecture guidelines for network designers
+   of the IPv6 address space.  Two advantages of IPv6 are that support
+   for multicast is required and nodes can create link-local addresses
+   during initialization.  The availability of these features means that
+   a client can use its link-local address and a well-known multicast
+   address to discover and communicate with DHCP servers or relay agents
+   on its link.
+
+   IPv6 Stateless Address Autoconfiguration [17] specifies procedures by
+   which a node may autoconfigure addresses based on router
+   advertisements [13], and the use of a valid lifetime to support
+   renumbering of addresses on the Internet.  In addition, the protocol
+   interaction by which a node begins stateless or stateful
+   autoconfiguration is specified.  DHCP is one vehicle to perform
+   stateful autoconfiguration.  Compatibility with stateless address
+   autoconfiguration is a design requirement of DHCP.
+
+   IPv6 Neighbor Discovery [13] is the node discovery protocol in IPv6
+   which replaces and enhances functions of ARP [14].  To understand
+   IPv6 and stateless address autoconfiguration, it is strongly
+   recommended that implementors understand IPv6 Neighbor Discovery.
+
+   Dynamic Updates to DNS [22] is a specification that supports the
+   dynamic update of DNS records for both IPv4 and IPv6.  DHCP can use
+   the dynamic updates to DNS to integrate addresses and name space to
+   not only support autoconfiguration, but also autoregistration in
+   IPv6.
+
+4. Terminology
+
+   This sections defines terminology specific to IPv6 and DHCP used in
+   this document.
+
+
+
+
+
+
+Droms, et al.               Standards Track                     [Page 8]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+4.1. IPv6 Terminology
+
+   IPv6 terminology relevant to this specification from the IPv6
+   Protocol [3], IPv6 Addressing Architecture [5], and IPv6 Stateless
+   Address Autoconfiguration [17] is included below.
+
+      address                   An IP layer identifier for an interface
+                                or a set of interfaces.
+
+      host                      Any node that is not a router.
+
+      IP                        Internet Protocol Version 6 (IPv6).  The
+                                terms IPv4 and IPv6 are used only in
+                                contexts where it is necessary to avoid
+                                ambiguity.
+
+      interface                 A node's attachment to a link.
+
+      link                      A communication facility or medium over
+                                which nodes can communicate at the link
+                                layer, i.e., the layer immediately
+                                below IP.  Examples are Ethernet (simple
+                                or bridged); Token Ring; PPP links,
+                                X.25, Frame Relay, or ATM networks; and
+                                Internet (or higher) layer "tunnels",
+                                such as tunnels over IPv4 or IPv6
+                                itself.
+
+      link-layer identifier     A link-layer identifier for an
+                                interface.  Examples include IEEE 802
+                                addresses for Ethernet or Token Ring
+                                network interfaces, and E.164 addresses
+                                for ISDN links.
+
+      link-local address        An IPv6 address having a link-only
+                                scope, indicated by having the prefix
+                                (FE80::/10), that can be used to reach
+                                neighboring nodes attached to the same
+                                link.  Every interface has a link-local
+                                address.
+
+      multicast address         An identifier for a set of interfaces
+                                (typically belonging to different
+                                nodes).  A packet sent to a multicast
+                                address is delivered to all interfaces
+                                identified by that address.
+
+      neighbor                  A node attached to the same link.
+
+
+
+Droms, et al.               Standards Track                     [Page 9]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      node                      A device that implements IP.
+
+      packet                    An IP header plus payload.
+
+      prefix                    The initial bits of an address, or a
+                                set of IP addresses that share the same
+                                initial bits.
+
+      prefix length             The number of bits in a prefix.
+
+      router                    A node that forwards IP packets not
+                                explicitly addressed to itself.
+
+      unicast address           An identifier for a single interface.
+                                A packet sent to a unicast address is
+                                delivered to the interface identified by
+                                that address.
+
+4.2. DHCP Terminology
+
+   Terminology specific to DHCP can be found below.
+
+      appropriate to the link   An address is "appropriate to the link"
+                                when the address is consistent with the
+                                DHCP server's knowledge of the network
+                                topology, prefix assignment and address
+                                assignment policies.
+
+      binding                   A binding (or, client binding) is a
+                                group of server data records containing
+                                the information the server has about
+                                the addresses in an IA or configuration
+                                information explicitly assigned to the
+                                client.  Configuration information that
+                                has been returned to a client through a
+                                policy - for example, the information
+                                returned to all clients on the same
+                                link - does not require a binding.  A
+                                binding containing information about
+                                an IA is indexed by the tuple <DUID,
+                                IA-type, IAID> (where IA-type is the
+                                type of address in the IA; for example,
+                                temporary).  A binding containing
+                                configuration information for a client
+                                is indexed by <DUID>.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 10]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      configuration parameter   An element of the configuration
+                                information set on the server and
+                                delivered to the client using DHCP.
+                                Such parameters may be used to carry
+                                information to be used by a node to
+                                configure its network subsystem and
+                                enable communication on a link or
+                                internetwork, for example.
+
+      DHCP                      Dynamic Host Configuration Protocol
+                                for IPv6.  The terms DHCPv4 and DHCPv6
+                                are used only in contexts where it is
+                                necessary to avoid ambiguity.
+
+      DHCP client (or client)   A node that initiates requests on a link
+                                to obtain configuration parameters from
+                                one or more DHCP servers.
+
+      DHCP domain               A set of links managed by DHCP and
+                                operated by a single administrative
+                                entity.
+
+      DHCP realm                A name used to identify the DHCP
+                                administrative domain from which a DHCP
+                                authentication key was selected.
+
+      DHCP relay agent (or relay agent) A node that acts as an
+                                intermediary to deliver DHCP messages
+                                between clients and servers, and is on
+                                the same link as the client.
+
+      DHCP server (or server)   A node that responds to requests from
+                                clients, and may or may not be on the
+                                same link as the client(s).
+
+      DUID                      A DHCP Unique IDentifier for a DHCP
+                                participant; each DHCP client and server
+                                has exactly one DUID.  See section 9 for
+                                details of the ways in which a DUID may
+                                be constructed.
+
+      Identity association (IA) A collection of addresses assigned to
+                                a client.  Each IA has an associated
+                                IAID.  A client may have more than one
+                                IA assigned to it; for example, one for
+                                each of its interfaces.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 11]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+                                Each IA holds one type of address;
+                                for example, an identity association
+                                for temporary addresses (IA_TA) holds
+                                temporary addresses (see "identity
+                                association for temporary addresses").
+                                Throughout this document, "IA" is used
+                                to refer to an identity association
+                                without identifying the type of
+                                addresses in the IA.
+
+      Identity association identifier (IAID) An identifier for an IA,
+                                chosen by the client.  Each IA has an
+                                IAID, which is chosen to be unique among
+                                all IAIDs for IAs belonging to that
+                                client.
+
+      Identity association for non-temporary addresses (IA_NA) An IA
+                                that carries assigned addresses that are
+                                not temporary addresses (see "identity
+                                association for temporary addresses")
+
+      Identity association for temporary addresses (IA_TA) An IA that
+                                carries temporary addresses (see RFC
+                                3041 [12]).
+
+      message                   A unit of data carried as the payload
+                                of a UDP datagram, exchanged among DHCP
+                                servers, relay agents and clients.
+
+      Reconfigure key           A key supplied to a client by a server
+                                used to provide security for Reconfigure
+                                messages.
+
+      relaying                  A DHCP relay agent relays DHCP messages
+                                between DHCP participants.
+
+      transaction ID            An opaque value used to match responses
+                                with replies initiated either by a
+                                client or server.
+
+5. DHCP Constants
+
+   This section describes various program and networking constants used
+   by DHCP.
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 12]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+5.1. Multicast Addresses
+
+   DHCP makes use of the following multicast addresses:
+
+      All_DHCP_Relay_Agents_and_Servers (FF02::1:2) A link-scoped
+                  multicast address used by a client to communicate with
+                  neighboring (i.e., on-link) relay agents and servers.
+                  All servers and relay agents are members of this
+                  multicast group.
+
+      All_DHCP_Servers (FF05::1:3) A site-scoped multicast address used
+                  by a relay agent to communicate with servers, either
+                  because the relay agent wants to send messages to
+                  all servers or because it does not know the unicast
+                  addresses of the servers.  Note that in order for
+                  a relay agent to use this address, it must have an
+                  address of sufficient scope to be reachable by the
+                  servers.  All servers within the site are members of
+                  this multicast group.
+
+5.2. UDP Ports
+
+   Clients listen for DHCP messages on UDP port 546.  Servers and relay
+   agents listen for DHCP messages on UDP port 547.
+
+5.3. DHCP Message Types
+
+   DHCP defines the following message types.  More detail on these
+   message types can be found in sections 6 and 7.  Message types not
+   listed here are reserved for future use.  The numeric encoding for
+   each message type is shown in parentheses.
+
+      SOLICIT (1)        A client sends a Solicit message to locate
+                         servers.
+
+      ADVERTISE (2)      A server sends an Advertise message to indicate
+                         that it is available for DHCP service, in
+                         response to a Solicit message received from a
+                         client.
+
+      REQUEST (3)        A client sends a Request message to request
+                         configuration parameters, including IP
+                         addresses, from a specific server.
+
+      CONFIRM (4)        A client sends a Confirm message to any
+                         available server to determine whether the
+                         addresses it was assigned are still appropriate
+                         to the link to which the client is connected.
+
+
+
+Droms, et al.               Standards Track                    [Page 13]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      RENEW (5)          A client sends a Renew message to the server
+                         that originally provided the client's addresses
+                         and configuration parameters to extend the
+                         lifetimes on the addresses assigned to the
+                         client and to update other configuration
+                         parameters.
+
+      REBIND (6)         A client sends a Rebind message to any
+                         available server to extend the lifetimes on the
+                         addresses assigned to the client and to update
+                         other configuration parameters; this message is
+                         sent after a client receives no response to a
+                         Renew message.
+
+      REPLY (7)          A server sends a Reply message containing
+                         assigned addresses and configuration parameters
+                         in response to a Solicit, Request, Renew,
+                         Rebind message received from a client.  A
+                         server sends a Reply message containing
+                         configuration parameters in response to an
+                         Information-request message.  A server sends a
+                         Reply message in response to a Confirm message
+                         confirming or denying that the addresses
+                         assigned to the client are appropriate to the
+                         link to which the client is connected.  A
+                         server sends a Reply message to acknowledge
+                         receipt of a Release or Decline message.
+
+      RELEASE (8)        A client sends a Release message to the server
+                         that assigned addresses to the client to
+                         indicate that the client will no longer use one
+                         or more of the assigned addresses.
+
+      DECLINE (9)        A client sends a Decline message to a server to
+                         indicate that the client has determined that
+                         one or more addresses assigned by the server
+                         are already in use on the link to which the
+                         client is connected.
+
+      RECONFIGURE (10)   A server sends a Reconfigure message to a
+                         client to inform the client that the server has
+                         new or updated configuration parameters, and
+                         that the client is to initiate a Renew/Reply
+                         or Information-request/Reply transaction with
+                         the server in order to receive the updated
+                         information.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 14]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      INFORMATION-REQUEST (11) A client sends an Information-request
+                         message to a server to request configuration
+                         parameters without the assignment of any IP
+                         addresses to the client.
+
+      RELAY-FORW (12)    A relay agent sends a Relay-forward message
+                         to relay messages to servers, either directly
+                         or through another relay agent.  The received
+                         message, either a client message or a
+                         Relay-forward message from another relay
+                         agent, is encapsulated in an option in the
+                         Relay-forward message.
+
+      RELAY-REPL (13)    A server sends a Relay-reply message to a relay
+                         agent containing a message that the relay
+                         agent delivers to a client.  The Relay-reply
+                         message may be relayed by other relay agents
+                         for delivery to the destination relay agent.
+
+                         The server encapsulates the client message as
+                         an option in the Relay-reply message, which the
+                         relay agent extracts and relays to the client.
+
+5.4. Status Codes
+
+   DHCPv6 uses status codes to communicate the success or failure of
+   operations requested in messages from clients and servers, and to
+   provide additional information about the specific cause of the
+   failure of a message.  The specific status codes are defined in
+   section 24.4.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 15]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+5.5. Transmission and Retransmission Parameters
+
+   This section presents a table of values used to describe the message
+   transmission behavior of clients and servers.
+
+   Parameter     Default  Description
+   -------------------------------------
+   SOL_MAX_DELAY     1 sec   Max delay of first Solicit
+   SOL_TIMEOUT       1 sec   Initial Solicit timeout
+   SOL_MAX_RT      120 secs  Max Solicit timeout value
+   REQ_TIMEOUT       1 sec   Initial Request timeout
+   REQ_MAX_RT       30 secs  Max Request timeout value
+   REQ_MAX_RC       10       Max Request retry attempts
+   CNF_MAX_DELAY     1 sec   Max delay of first Confirm
+   CNF_TIMEOUT       1 sec   Initial Confirm timeout
+   CNF_MAX_RT        4 secs  Max Confirm timeout
+   CNF_MAX_RD       10 secs  Max Confirm duration
+   REN_TIMEOUT      10 secs  Initial Renew timeout
+   REN_MAX_RT      600 secs  Max Renew timeout value
+   REB_TIMEOUT      10 secs  Initial Rebind timeout
+   REB_MAX_RT      600 secs  Max Rebind timeout value
+   INF_MAX_DELAY     1 sec   Max delay of first Information-request
+   INF_TIMEOUT       1 sec   Initial Information-request timeout
+   INF_MAX_RT      120 secs  Max Information-request timeout value
+   REL_TIMEOUT       1 sec   Initial Release timeout
+   REL_MAX_RC        5       MAX Release attempts
+   DEC_TIMEOUT       1 sec   Initial Decline timeout
+   DEC_MAX_RC        5       Max Decline attempts
+   REC_TIMEOUT       2 secs  Initial Reconfigure timeout
+   REC_MAX_RC        8       Max Reconfigure attempts
+   HOP_COUNT_LIMIT  32       Max hop count in a Relay-forward message
+
+5.6  Representation of time values and "Infinity" as a time value
+
+   All time values for lifetimes, T1 and T2 are unsigned integers.  The
+   value 0xffffffff is taken to mean "infinity" when used as a lifetime
+   (as in RFC2461 [17]) or a value for T1 or T2.
+
+6. Client/Server Message Formats
+
+   All DHCP messages sent between clients and servers share an identical
+   fixed format header and a variable format area for options.
+
+   All values in the message header and in options are in network byte
+   order.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 16]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Options are stored serially in the options field, with no padding
+   between the options.  Options are byte-aligned but are not aligned in
+   any other way such as on 2 or 4 byte boundaries.
+
+   The following diagram illustrates the format of DHCP messages sent
+   between clients and servers:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    msg-type   |               transaction-id                  |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      .                            options                            .
+      .                           (variable)                          .
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      msg-type             Identifies the DHCP message type; the
+                           available message types are listed in
+                           section 5.3.
+
+      transaction-id       The transaction ID for this message exchange.
+
+      options              Options carried in this message; options are
+                           described in section 22.
+
+7. Relay Agent/Server Message Formats
+
+   Relay agents exchange messages with servers to relay messages between
+   clients and servers that are not connected to the same link.
+
+   All values in the message header and in options are in network byte
+   order.
+
+   Options are stored serially in the options field, with no padding
+   between the options.  Options are byte-aligned but are not aligned in
+   any other way such as on 2 or 4 byte boundaries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 17]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   There are two relay agent messages, which share the following format:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    msg-type   |   hop-count   |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      |                                                               |
+      |                         link-address                          |
+      |                                                               |
+      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+      |                               |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      |                                                               |
+      |                         peer-address                          |
+      |                                                               |
+      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+      |                               |                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+      .                                                               .
+      .            options (variable number and length)   ....        .
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The following sections describe the use of the Relay Agent message
+   header.
+
+7.1. Relay-forward Message
+
+   The following table defines the use of message fields in a Relay-
+   forward message.
+
+      msg-type       RELAY-FORW
+
+      hop-count      Number of relay agents that have relayed this
+                     message.
+
+      link-address   A global or site-local address that will be used by
+                     the server to identify the link on which the client
+                     is located.
+
+      peer-address   The address of the client or relay agent from which
+                     the message to be relayed was received.
+
+      options        MUST include a "Relay Message option" (see
+                     section 22.10); MAY include other options added by
+                     the relay agent.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 18]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+7.2. Relay-reply Message
+
+   The following table defines the use of message fields in a
+   Relay-reply message.
+
+      msg-type       RELAY-REPL
+
+      hop-count      Copied from the Relay-forward message
+
+      link-address   Copied from the Relay-forward message
+
+      peer-address   Copied from the Relay-forward message
+
+      options        MUST include a "Relay Message option"; see
+                     section 22.10; MAY include other options
+
+8. Representation and Use of Domain Names
+
+   So that domain names may be encoded uniformly, a domain name or a
+   list of domain names is encoded using the technique described in
+   section 3.1 of RFC 1035 [10].  A domain name, or list of domain
+   names, in DHCP MUST NOT be stored in compressed form, as described in
+   section 4.1.4 of RFC 1035.
+
+9. DHCP Unique Identifier (DUID)
+
+   Each DHCP client and server has a DUID.  DHCP servers use DUIDs to
+   identify clients for the selection of configuration parameters and in
+   the association of IAs with clients.  DHCP clients use DUIDs to
+   identify a server in messages where a server needs to be identified.
+   See sections 22.2 and 22.3 for the representation of a DUID in a DHCP
+   message.
+
+   Clients and servers MUST treat DUIDs as opaque values and MUST only
+   compare DUIDs for equality.  Clients and servers MUST NOT in any
+   other way interpret DUIDs.  Clients and servers MUST NOT restrict
+   DUIDs to the types defined in this document, as additional DUID types
+   may be defined in the future.
+
+   The DUID is carried in an option because it may be variable length
+   and because it is not required in all DHCP messages.  The DUID is
+   designed to be unique across all DHCP clients and servers, and stable
+   for any specific client or server - that is, the DUID used by a
+   client or server SHOULD NOT change over time if at all possible; for
+   example, a device's DUID should not change as a result of a change in
+   the device's network hardware.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 19]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The motivation for having more than one type of DUID is that the DUID
+   must be globally unique, and must also be easy to generate.  The sort
+   of globally-unique identifier that is easy to generate for any given
+   device can differ quite widely.  Also, some devices may not contain
+   any persistent storage.  Retaining a generated DUID in such a device
+   is not possible, so the DUID scheme must accommodate such devices.
+
+9.1. DUID Contents
+
+   A DUID consists of a two-octet type code represented in network byte
+   order, followed by a variable number of octets that make up the
+   actual identifier.  A DUID can be no more than 128 octets long (not
+   including the type code).  The following types are currently defined:
+
+      1        Link-layer address plus time
+      2        Vendor-assigned unique ID based on Enterprise Number
+      3        Link-layer address
+
+   Formats for the variable field of the DUID for each of the above
+   types are shown below.
+
+9.2. DUID Based on Link-layer Address Plus Time [DUID-LLT]
+
+   This type of DUID consists of a two octet type field containing the
+   value 1, a two octet hardware type code, four octets containing a
+   time value, followed by link-layer address of any one network
+   interface that is connected to the DHCP device at the time that the
+   DUID is generated.  The time value is the time that the DUID is
+   generated represented in seconds since midnight (UTC), January 1,
+   2000, modulo 2^32.  The hardware type MUST be a valid hardware type
+   assigned by the IANA as described in RFC 826 [14].  Both the time and
+   the hardware type are stored in network byte order.  The link-layer
+   address is stored in canonical form, as described in RFC 2464 [2].
+
+   The following diagram illustrates the format of a DUID-LLT:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               1               |    hardware type (16 bits)    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        time (32 bits)                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    .                                                               .
+    .             link-layer address (variable length)              .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 20]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The choice of network interface can be completely arbitrary, as long
+   as that interface provides a globally unique link-layer address for
+   the link type, and the same DUID-LLT SHOULD be used in configuring
+   all network interfaces connected to the device, regardless of which
+   interface's link-layer address was used to generate the DUID-LLT.
+
+   Clients and servers using this type of DUID MUST store the DUID-LLT
+   in stable storage, and MUST continue to use this DUID-LLT even if the
+   network interface used to generate the DUID-LLT is removed.  Clients
+   and servers that do not have any stable storage MUST NOT use this
+   type of DUID.
+
+   Clients and servers that use this DUID SHOULD attempt to configure
+   the time prior to generating the DUID, if that is possible, and MUST
+   use some sort of time source (for example, a real-time clock) in
+   generating the DUID, even if that time source could not be configured
+   prior to generating the DUID.  The use of a time source makes it
+   unlikely that two identical DUID-LLTs will be generated if the
+   network interface is removed from the client and another client then
+   uses the same network interface to generate a DUID-LLT.  A collision
+   between two DUID-LLTs is very unlikely even if the clocks have not
+   been configured prior to generating the DUID.
+
+   This method of DUID generation is recommended for all general purpose
+   computing devices such as desktop computers and laptop computers, and
+   also for devices such as printers, routers, and so on, that contain
+   some form of writable non-volatile storage.
+
+   Despite our best efforts, it is possible that this algorithm for
+   generating a DUID could result in a client identifier collision.  A
+   DHCP client that generates a DUID-LLT using this mechanism MUST
+   provide an administrative interface that replaces the existing DUID
+   with a newly-generated DUID-LLT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 21]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]
+
+   This form of DUID is assigned by the vendor to the device.  It
+   consists of the vendor's registered Private Enterprise Number as
+   maintained by IANA [6] followed by a unique identifier assigned by
+   the vendor.  The following diagram summarizes the structure of a
+   DUID-EN:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               2               |       enterprise-number       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   enterprise-number (contd)   |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    .                           identifier                          .
+    .                       (variable length)                       .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The source of the identifier is left up to the vendor defining it,
+   but each identifier part of each DUID-EN MUST be unique to the device
+   that is using it, and MUST be assigned to the device at the time it
+   is manufactured and stored in some form of non-volatile storage.  The
+   generated DUID SHOULD be recorded in non-erasable storage.  The
+   enterprise-number is the vendor's registered Private Enterprise
+   Number as maintained by IANA [6].  The enterprise-number is stored as
+   an unsigned 32 bit number.
+
+   An example DUID of this type might look like this:
+
+    +---+---+---+---+---+---+---+---+
+    | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
+    +---+---+---+---+---+---+---+---+
+    |132|221| 3 | 0 | 9 | 18|
+    +---+---+---+---+---+---+
+
+   This example includes the two-octet type of 2, the Enterprise Number
+   (9), followed by eight octets of identifier data
+   (0x0CC084D303000912).
+
+9.4. DUID Based on Link-layer Address [DUID-LL]
+
+   This type of DUID consists of two octets containing the DUID type 3,
+   a two octet network hardware type code, followed by the link-layer
+   address of any one network interface that is permanently connected to
+   the client or server device.  For example, a host that has a network
+   interface implemented in a chip that is unlikely to be removed and
+
+
+
+Droms, et al.               Standards Track                    [Page 22]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   used elsewhere could use a DUID-LL.  The hardware type MUST be a
+   valid hardware type assigned by the IANA, as described in RFC 826
+   [14].  The hardware type is stored in network byte order.  The
+   link-layer address is stored in canonical form, as described in RFC
+   2464 [2].  The following diagram illustrates the format of a DUID-LL:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               3               |    hardware type (16 bits)    |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    .                                                               .
+    .             link-layer address (variable length)              .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   The choice of network interface can be completely arbitrary, as long
+   as that interface provides a unique link-layer address and is
+   permanently attached to the device on which the DUID-LL is being
+   generated.  The same DUID-LL SHOULD be used in configuring all
+   network interfaces connected to the device, regardless of which
+   interface's link-layer address was used to generate the DUID.
+
+   DUID-LL is recommended for devices that have a permanently-connected
+   network interface with a link-layer address, and do not have
+   nonvolatile, writable stable storage.  DUID-LL MUST NOT be used by
+   DHCP clients or servers that cannot tell whether or not a network
+   interface is permanently attached to the device on which the DHCP
+   client is running.
+
+10. Identity Association
+
+   An "identity-association" (IA) is a construct through which a server
+   and a client can identify, group, and manage a set of related IPv6
+   addresses.  Each IA consists of an IAID and associated configuration
+   information.
+
+   A client must associate at least one distinct IA with each of its
+   network interfaces for which it is to request the assignment of IPv6
+   addresses from a DHCP server.  The client uses the IAs assigned to an
+   interface to obtain configuration information from a server for that
+   interface.  Each IA must be associated with exactly one interface.
+
+   The IAID uniquely identifies the IA and must be chosen to be unique
+   among the IAIDs on the client.  The IAID is chosen by the client.
+   For any given use of an IA by the client, the IAID for that IA MUST
+   be consistent across restarts of the DHCP client.  The client may
+   maintain consistency either by storing the IAID in non-volatile
+
+
+
+Droms, et al.               Standards Track                    [Page 23]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   storage or by using an algorithm that will consistently produce the
+   same IAID as long as the configuration of the client has not changed.
+   There may be no way for a client to maintain consistency of the IAIDs
+   if it does not have non-volatile storage and the client's hardware
+   configuration changes.
+
+   The configuration information in an IA consists of one or more IPv6
+   addresses along with the times T1 and T2 for the IA.  See section
+   22.4 for the representation of an IA in a DHCP message.
+
+   Each address in an IA has a preferred lifetime and a valid lifetime,
+   as defined in RFC 2462 [17].  The lifetimes are transmitted from the
+   DHCP server to the client in the IA option.  The lifetimes apply to
+   the use of IPv6 addresses, as described in section 5.5.4 of RFC 2462.
+
+11. Selecting Addresses for Assignment to an IA
+
+   A server selects addresses to be assigned to an IA according to the
+   address assignment policies determined by the server administrator
+   and the specific information the server determines about the client
+   from some combination of the following sources:
+
+   -  The link to which the client is attached.  The server determines
+      the link as follows:
+
+      *  If the server receives the message directly from the client and
+         the source address in the IP datagram in which the message was
+         received is a link-local address, then the client is on the
+         same link to which the interface over which the message was
+         received is attached.
+
+      *  If the server receives the message from a forwarding relay
+         agent, then the client is on the same link as the one to which
+         the interface, identified by the link-address field in the
+         message from the relay agent, is attached.
+
+      *  If the server receives the message directly from the client and
+         the source address in the IP datagram in which the message was
+         received is not a link-local address, then the client is on the
+         link identified by the source address in the IP datagram (note
+         that this situation can occur only if the server has enabled
+         the use of unicast message delivery by the client and the
+         client has sent a message for which unicast delivery is
+         allowed).
+
+   -  The DUID supplied by the client.
+
+   -  Other information in options supplied by the client.
+
+
+
+Droms, et al.               Standards Track                    [Page 24]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   -  Other information in options supplied by the relay agent.
+
+   Any address assigned by a server that is based on an EUI-64
+   identifier MUST include an interface identifier with the "u"
+   (universal/local) and "g" (individual/group) bits of the interface
+   identifier set appropriately, as indicated in section 2.5.1 of RFC
+   2373 [5].
+
+   A server MUST NOT assign an address that is otherwise reserved for
+   some other purpose.  For example, a server MUST NOT assign reserved
+   anycast addresses, as defined in RFC 2526, from any subnet.
+
+12. Management of Temporary Addresses
+
+   A client may request the assignment of temporary addresses (see RFC
+   3041 [12] for the definition of temporary addresses).  DHCPv6
+   handling of address assignment is no different for temporary
+   addresses.  DHCPv6 says nothing about details of temporary addresses
+   like lifetimes, how clients use temporary addresses, rules for
+   generating successive temporary addresses, etc.
+
+   Clients ask for temporary addresses and servers assign them.
+   Temporary addresses are carried in the Identity Association for
+   Temporary Addresses (IA_TA) option (see section 22.5).  Each IA_TA
+   option contains at most one temporary address for each of the
+   prefixes on the link to which the client is attached.
+
+   The IAID number space for the IA_TA option IAID number space is
+   separate from the IA_NA option IAID number space.
+
+   The server MAY update the DNS for a temporary address, as described
+   in section 4 of RFC 3041.
+
+13. Transmission of Messages by a Client
+
+   Unless otherwise specified in this document, or in a document that
+   describes how IPv6 is carried over a specific type of link (for link
+   types that do not support multicast), a client sends DHCP messages to
+   the All_DHCP_Relay_Agents_and_Servers.
+
+   A client uses multicast to reach all servers or an individual server.
+   An individual server is indicated by specifying that server's DUID in
+   a Server Identifier option (see section 22.3) in the client's message
+   (all servers will receive this message but only the indicated server
+   will respond).  All servers are indicated by not supplying this
+   option.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 25]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   A client may send some messages directly to a server using unicast,
+   as described in section 22.12.
+
+14. Reliability of Client Initiated Message Exchanges
+
+   DHCP clients are responsible for reliable delivery of messages in the
+   client-initiated message exchanges described in sections 17 and 18.
+   If a DHCP client fails to receive an expected response from a server,
+   the client must retransmit its message.  This section describes the
+   retransmission strategy to be used by clients in client-initiated
+   message exchanges.
+
+   Note that the procedure described in this section is slightly
+   modified when used with the Solicit message.  The modified procedure
+   is described in section 17.1.2.
+
+   The client begins the message exchange by transmitting a message to
+   the server.  The message exchange terminates when either the client
+   successfully receives the appropriate response or responses from a
+   server or servers, or when the message exchange is considered to have
+   failed according to the retransmission mechanism described below.
+
+   The client retransmission behavior is controlled and described by the
+   following variables:
+
+      RT     Retransmission timeout
+
+      IRT    Initial retransmission time
+
+      MRC    Maximum retransmission count
+
+      MRT    Maximum retransmission time
+
+      MRD    Maximum retransmission duration
+
+      RAND   Randomization factor
+
+   With each message transmission or retransmission, the client sets RT
+   according to the rules given below.  If RT expires before the message
+   exchange terminates, the client recomputes RT and retransmits the
+   message.
+
+   Each of the computations of a new RT include a randomization factor
+   (RAND), which is a random number chosen with a uniform distribution
+   between -0.1 and +0.1.  The randomization factor is included to
+   minimize synchronization of messages transmitted by DHCP clients.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 26]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The algorithm for choosing a random number does not need to be
+   cryptographically sound.  The algorithm SHOULD produce a different
+   sequence of random numbers from each invocation of the DHCP client.
+
+   RT for the first message transmission is based on IRT:
+
+      RT = IRT + RAND*IRT
+
+   RT for each subsequent message transmission is based on the previous
+   value of RT:
+
+      RT = 2*RTprev + RAND*RTprev
+
+   MRT specifies an upper bound on the value of RT (disregarding the
+   randomization added by the use of RAND).  If MRT has a value of 0,
+   there is no upper limit on the value of RT.  Otherwise:
+
+      if (RT > MRT)
+         RT = MRT + RAND*MRT
+
+   MRC specifies an upper bound on the number of times a client may
+   retransmit a message.  Unless MRC is zero, the message exchange fails
+   once the client has transmitted the message MRC times.
+
+   MRD specifies an upper bound on the length of time a client may
+   retransmit a message.  Unless MRD is zero, the message exchange fails
+   once MRD seconds have elapsed since the client first transmitted the
+   message.
+
+   If both MRC and MRD are non-zero, the message exchange fails whenever
+   either of the conditions specified in the previous two paragraphs are
+   met.
+
+   If both MRC and MRD are zero, the client continues to transmit the
+   message until it receives a response.
+
+15. Message Validation
+
+   Clients and servers SHOULD discard any messages that contain options
+   that are not allowed to appear in the received message.  For example,
+   an IA option is not allowed to appear in an Information-request
+   message.  Clients and servers MAY choose to extract information from
+   such a message if the information is of use to the recipient.
+
+   A server MUST discard any Solicit, Confirm, Rebind or
+   Information-request messages it receives with a unicast destination
+   address.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 27]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Message validation based on DHCP authentication is discussed in
+   section 21.4.2.
+
+   If a server receives a message that contains options it should not
+   contain (such as an Information-request message with an IA option),
+   is missing options that it should contain, or is otherwise not valid,
+   it MAY send a Reply (or Advertise as appropriate) with a Server
+   Identifier option, a Client Identifier option if one was included in
+   the message and a Status Code option with status UnSpecFail.
+
+15.1. Use of Transaction IDs
+
+   The "transaction-id" field holds a value used by clients and servers
+   to synchronize server responses to client messages.  A client SHOULD
+   generate a random number that cannot easily be guessed or predicted
+   to use as the transaction ID for each new message it sends.  Note
+   that if a client generates easily predictable transaction
+   identifiers, it may become more vulnerable to certain kinds of
+   attacks from off-path intruders.  A client MUST leave the transaction
+   ID unchanged in retransmissions of a message.
+
+15.2. Solicit Message
+
+   Clients MUST discard any received Solicit messages.
+
+   Servers MUST discard any Solicit messages that do not include a
+   Client Identifier option or that do include a Server Identifier
+   option.
+
+15.3. Advertise Message
+
+   Clients MUST discard any received Advertise messages that meet any of
+   the following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the message does not include a Client Identifier option.
+
+   -  the contents of the Client Identifier option does not match the
+      client's DUID.
+
+   -  the "transaction-id" field value does not match the value the
+      client used in its Solicit message.
+
+   Servers and relay agents MUST discard any received Advertise
+   messages.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 28]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+15.4. Request Message
+
+   Clients MUST discard any received Request messages.
+
+   Servers MUST discard any received Request message that meet any of
+   the following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the contents of the Server Identifier option do not match the
+      server's DUID.
+
+   -  the message does not include a Client Identifier option.
+
+15.5. Confirm Message
+
+   Clients MUST discard any received Confirm messages.
+
+   Servers MUST discard any received Confirm messages that do not
+   include a Client Identifier option or that do include a Server
+   Identifier option.
+
+15.6. Renew Message
+
+   Clients MUST discard any received Renew messages.
+
+   Servers MUST discard any received Renew message that meets any of the
+   following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the contents of the Server Identifier option does not match the
+      server's identifier.
+
+   -  the message does not include a Client Identifier option.
+
+15.7. Rebind Message
+
+   Clients MUST discard any received Rebind messages.
+
+   Servers MUST discard any received Rebind messages that do not include
+   a Client Identifier option or that do include a Server Identifier
+   option.
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 29]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+15.8. Decline Messages
+
+   Clients MUST discard any received Decline messages.
+
+   Servers MUST discard any received Decline message that meets any of
+   the following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the contents of the Server Identifier option does not match the
+      server's identifier.
+
+   -  the message does not include a Client Identifier option.
+
+15.9. Release Message
+
+   Clients MUST discard any received Release messages.
+
+   Servers MUST discard any received Release message that meets any of
+   the following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the contents of the Server Identifier option does not match the
+      server's identifier.
+
+   -  the message does not include a Client Identifier option.
+
+15.10. Reply Message
+
+   Clients MUST discard any received Reply message that meets any of the
+   following conditions:
+
+   -  the message does not include a Server Identifier option.
+
+   -  the "transaction-id" field in the message does not match the value
+      used in the original message.
+
+   If the client included a Client Identifier option in the original
+   message, the Reply message MUST include a Client Identifier option
+   and the contents of the Client Identifier option MUST match the DUID
+   of the client; OR, if the client did not include a Client Identifier
+   option in the original message, the Reply message MUST NOT include a
+   Client Identifier option.
+
+   Servers and relay agents MUST discard any received Reply messages.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 30]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+15.11. Reconfigure Message
+
+   Servers and relay agents MUST discard any received Reconfigure
+   messages.
+
+   Clients MUST discard any Reconfigure messages that meets any of the
+   following conditions:
+
+   -  the message was not unicast to the client.
+
+   -  the message does not include a Server Identifier option.
+
+   -  the message does not include a Client Identifier option that
+      contains the client's DUID.
+
+   -  the message does not contain a Reconfigure Message option and the
+      msg-type must be a valid value.
+
+   -  the message includes any IA options and the msg-type in the
+      Reconfigure Message option is INFORMATION-REQUEST.
+
+   -  the message does not include DHCP authentication:
+
+      *  the message does not contain an authentication option.
+
+      *  the message does not pass the authentication validation
+         performed by the client.
+
+15.12. Information-request Message
+
+   Clients MUST discard any received Information-request messages.
+
+   Servers MUST discard any received Information-request message that
+   meets any of the following conditions:
+
+   -  The message includes a Server Identifier option and the DUID in
+      the option does not match the server's DUID.
+
+   -  The message includes an IA option.
+
+15.13. Relay-forward Message
+
+   Clients MUST discard any received Relay-forward messages.
+
+15.14. Relay-reply Message
+
+   Clients and servers MUST discard any received Relay-reply messages.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 31]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+16. Client Source Address and Interface Selection
+
+   When a client sends a DHCP message to the
+   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
+   through the interface for which configuration information is being
+   requested.  However, the client MAY send the message through another
+   interface attached to the same link, if and only if the client is
+   certain the two interfaces are attached to the same link.  The client
+   MUST use a link-local address assigned to the interface for which it
+   is requesting configuration information as the source address in the
+   header of the IP datagram.
+
+   When a client sends a DHCP message directly to a server using unicast
+   (after receiving the Server Unicast option from that server), the
+   source address in the header of the IP datagram MUST be an address
+   assigned to the interface for which the client is interested in
+   obtaining configuration and which is suitable for use by the server
+   in responding to the client.
+
+17. DHCP Server Solicitation
+
+   This section describes how a client locates servers that will assign
+   addresses to IAs belonging to the client.
+
+   The client is responsible for creating IAs and requesting that a
+   server assign IPv6 addresses to the IA.  The client first creates an
+   IA and assigns it an IAID.  The client then transmits a Solicit
+   message containing an IA option describing the IA.  Servers that can
+   assign addresses to the IA respond to the client with an Advertise
+   message.  The client then initiates a configuration exchange as
+   described in section 18.
+
+   If the client will accept a Reply message with committed address
+   assignments and other resources in response to the Solicit message,
+   the client includes a Rapid Commit option (see section 22.14) in the
+   Solicit message.
+
+17.1. Client Behavior
+
+   A client uses the Solicit message to discover DHCP servers configured
+   to assign addresses or return other configuration parameters on the
+   link to which the client is attached.
+
+17.1.1. Creation of Solicit Messages
+
+   The client sets the "msg-type" field to SOLICIT.  The client
+   generates a transaction ID and inserts this value in the
+   "transaction-id" field.
+
+
+
+Droms, et al.               Standards Track                    [Page 32]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client includes IA options for any IAs to which
+   it wants the server to assign addresses.  The client MAY include
+   addresses in the IAs as a hint to the server about addresses for
+   which the client has a preference.  The client MUST NOT include any
+   other options in the Solicit message, except as specifically allowed
+   in the definition of individual options.
+
+   The client uses IA_NA options to request the assignment of non-
+   temporary addresses and uses IA_TA options to request the assignment
+   of temporary addresses.  Either IA_NA or IA_TA options, or a
+   combination of both, can be included in DHCP messages.
+
+   The client SHOULD include an Option Request option (see section 22.7)
+   to indicate the options the client is interested in receiving.  The
+   client MAY additionally include instances of those options that are
+   identified in the Option Request option, with data values as hints to
+   the server about parameter values the client would like to have
+   returned.
+
+   The client includes a Reconfigure Accept option (see section 22.20)
+   if the client is willing to accept Reconfigure messages from the
+   server.
+
+17.1.2. Transmission of Solicit Messages
+
+   The first Solicit message from the client on the interface MUST be
+   delayed by a random amount of time between 0 and SOL_MAX_DELAY.  In
+   the case of a Solicit message transmitted when DHCP is initiated by
+   IPv6 Neighbor Discovery, the delay gives the amount of time to wait
+   after IPv6 Neighbor Discovery causes the client to invoke the
+   stateful address autoconfiguration protocol (see section 5.5.3 of RFC
+   2462).  This random delay desynchronizes clients which start at the
+   same time (for example, after a power outage).
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   SOL_TIMEOUT
+
+      MRT   SOL_MAX_RT
+
+      MRC   0
+
+      MRD   0
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 33]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   If the client has included a Rapid Commit option in its Solicit
+   message, the client terminates the waiting process as soon as a Reply
+   message with a Rapid Commit option is received.
+
+   If the client is waiting for an Advertise message, the mechanism in
+   section 14 is modified as follows for use in the transmission of
+   Solicit messages.  The message exchange is not terminated by the
+   receipt of an Advertise before the first RT has elapsed.  Rather, the
+   client collects Advertise messages until the first RT has elapsed.
+   Also, the first RT MUST be selected to be strictly greater than IRT
+   by choosing RAND to be strictly greater than 0.
+
+   A client MUST collect Advertise messages for the first RT seconds,
+   unless it receives an Advertise message with a preference value of
+   255.  The preference value is carried in the Preference option
+   (section 22.8).  Any Advertise that does not include a Preference
+   option is considered to have a preference value of 0.  If the client
+   receives an Advertise message that includes a Preference option with
+   a preference value of 255, the client immediately begins a client-
+   initiated message exchange (as described in section 18) by sending a
+   Request message to the server from which the Advertise message was
+   received.  If the client receives an Advertise message that does not
+   include a Preference option with a preference value of 255, the
+   client continues to wait until the first RT elapses.  If the first RT
+   elapses and the client has received an Advertise message, the client
+   SHOULD continue with a client-initiated message exchange by sending a
+   Request message.
+
+   If the client does not receive any Advertise messages before the
+   first RT has elapsed, it begins the retransmission mechanism
+   described in section 14.  The client terminates the retransmission
+   process as soon as it receives any Advertise message, and the client
+   acts on the received Advertise message without waiting for any
+   additional Advertise messages.
+
+   A DHCP client SHOULD choose MRC and MRD to be 0.  If the DHCP client
+   is configured with either MRC or MRD set to a value other than 0, it
+   MUST stop trying to configure the interface if the message exchange
+   fails.  After the DHCP client stops trying to configure the
+   interface, it SHOULD restart the reconfiguration process after some
+   external event, such as user input, system restart, or when the
+   client is attached to a new link.
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 34]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+17.1.3. Receipt of Advertise Messages
+
+   The client MUST ignore any Advertise message that includes a Status
+   Code option containing the value NoAddrsAvail, with the exception
+   that the client MAY display the associated status message to the
+   user.
+
+   Upon receipt of one or more valid Advertise messages, the client
+   selects one or more Advertise messages based upon the following
+   criteria.
+
+   -  Those Advertise messages with the highest server preference value
+      are preferred over all other Advertise messages.
+
+   -  Within a group of Advertise messages with the same server
+      preference value, a client MAY select those servers whose
+      Advertise messages advertise information of interest to the
+      client.  For example, the client may choose a server that returned
+      an advertisement with configuration options of interest to the
+      client.
+
+   -  The client MAY choose a less-preferred server if that server has a
+      better set of advertised parameters, such as the available
+      addresses advertised in IAs.
+
+   Once a client has selected Advertise message(s), the client will
+   typically store information about each server, such as server
+   preference value, addresses advertised, when the advertisement was
+   received, and so on.
+
+   If the client needs to select an alternate server in the case that a
+   chosen server does not respond, the client chooses the next server
+   according to the criteria given above.
+
+17.1.4. Receipt of Reply Message
+
+   If the client includes a Rapid Commit option in the Solicit message,
+   it will expect a Reply message that includes a Rapid Commit option in
+   response.  The client discards any Reply messages it receives that do
+   not include a Rapid Commit option.  If the client receives a valid
+   Reply message that includes a Rapid Commit option, it processes the
+   message as described in section 18.1.8.  If it does not receive such
+   a Reply message and does receive a valid Advertise message, the
+   client processes the Advertise message as described in section
+   17.1.3.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 35]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   If the client subsequently receives a valid Reply message that
+   includes a Rapid Commit option, it either:
+
+      processes the Reply message as described in section 18.1.8, and
+      discards any Reply messages received in response to the Request
+      message, or
+
+      processes any Reply messages received in response to the Request
+      message and discards the Reply message that includes the Rapid
+      Commit option.
+
+17.2. Server Behavior
+
+   A server sends an Advertise message in response to valid Solicit
+   messages it receives to announce the availability of the server to
+   the client.
+
+17.2.1. Receipt of Solicit Messages
+
+   The server determines the information about the client and its
+   location as described in section 11 and checks its administrative
+   policy about responding to the client.  If the server is not
+   permitted to respond to the client, the server discards the Solicit
+   message.  For example, if the administrative policy for the server is
+   that it may only respond to a client that is willing to accept a
+   Reconfigure message, if the client indicates with a Reconfigure
+   Accept option in the Solicit message that it will not accept a
+   Reconfigure message, the servers discard the Solicit message.
+
+   If the client has included a Rapid Commit option in the Solicit
+   message and the server has been configured to respond with committed
+   address assignments and other resources, the server responds to the
+   Solicit with a Reply message as described in section 17.2.3.
+   Otherwise, the server ignores the Rapid Commit option and processes
+   the remainder of the message as if no Rapid Commit option were
+   present.
+
+17.2.2. Creation and Transmission of Advertise Messages
+
+   The server sets the "msg-type" field to ADVERTISE and copies the
+   contents of the transaction-id field from the Solicit message
+   received from the client to the Advertise message.  The server
+   includes its server identifier in a Server Identifier option and
+   copies the Client Identifier from the Solicit message into the
+   Advertise message.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 36]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The server MAY add a Preference option to carry the preference value
+   for the Advertise message.  The server implementation SHOULD allow
+   the setting of a server preference value by the administrator.  The
+   server preference value MUST default to zero unless otherwise
+   configured by the server administrator.
+
+   The server includes a Reconfigure Accept option if the server wants
+   to require that the client accept Reconfigure messages.
+
+   The server includes options the server will return to the client in a
+   subsequent Reply message.  The information in these options may be
+   used by the client in the selection of a server if the client
+   receives more than one Advertise message.  If the client has included
+   an Option Request option in the Solicit message, the server includes
+   options in the Advertise message containing configuration parameters
+   for all of the options identified in the Option Request option that
+   the server has been configured to return to the client.  The server
+   MAY return additional options to the client if it has been configured
+   to do so.  The server must be aware of the recommendations on packet
+   sizes and the use of fragmentation in section 5 of RFC 2460.
+
+   If the Solicit message from the client included one or more IA
+   options, the server MUST include IA options in the Advertise message
+   containing any addresses that would be assigned to IAs contained in
+   the Solicit message from the client.  If the client has included
+   addresses in the IAs in the Solicit message, the server uses those
+   addresses as hints about the addresses the client would like to
+   receive.
+
+   If the server will not assign any addresses to any IAs in a
+   subsequent Request from the client, the server MUST send an Advertise
+   message to the client that includes only a Status Code option with
+   code NoAddrsAvail and a status message for the user, a Server
+   Identifier option with the server's DUID, and a Client Identifier
+   option with the client's DUID.
+
+   If the Solicit message was received directly by the server, the
+   server unicasts the Advertise message directly to the client using
+   the address in the source address field from the IP datagram in which
+   the Solicit message was received.  The Advertise message MUST be
+   unicast on the link from which the Solicit message was received.
+
+   If the Solicit message was received in a Relay-forward message, the
+   server constructs a Relay-reply message with the Advertise message in
+   the payload of a "relay-message" option.  If the Relay-forward
+   messages included an Interface-id option, the server copies that
+   option to the Relay-reply message.  The server unicasts the
+   Relay-reply message directly to the relay agent using the address in
+
+
+
+Droms, et al.               Standards Track                    [Page 37]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   the source address field from the IP datagram in which the Relay-
+   forward message was received.
+
+17.2.3. Creation and Transmission of Reply Messages
+
+   The server MUST commit the assignment of any addresses or other
+   configuration information message before sending a Reply message to a
+   client in response to a Solicit message.
+
+   DISCUSSION:
+
+      When using the Solicit-Reply message exchange, the server commits
+      the assignment of any addresses before sending the Reply message.
+      The client can assume it has been assigned the addresses in the
+      Reply message and does not need to send a Request message for
+      those addresses.
+
+      Typically, servers that are configured to use the Solicit-Reply
+      message exchange will be deployed so that only one server will
+      respond to a Solicit message.  If more than one server responds,
+      the client will only use the addresses from one of the servers,
+      while the addresses from the other servers will be committed to
+      the client but not used by the client.
+
+   The server includes a Rapid Commit option in the Reply message to
+   indicate that the Reply is in response to a Solicit message.
+
+   The server includes a Reconfigure Accept option if the server wants
+   to require that the client accept Reconfigure messages.
+
+   The server produces the Reply message as though it had received a
+   Request message, as described in section 18.2.1.  The server
+   transmits the Reply message as described in section 18.2.8.
+
+18. DHCP Client-Initiated Configuration Exchange
+
+   A client initiates a message exchange with a server or servers to
+   acquire or update configuration information of interest.  The client
+   may initiate the configuration exchange as part of the operating
+   system configuration process, when requested to do so by the
+   application layer, when required by Stateless Address
+   Autoconfiguration or as required to extend the lifetime of an address
+   (Renew and Rebind messages).
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 38]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+18.1. Client Behavior
+
+   A client uses Request, Renew, Rebind, Release and Decline messages
+   during the normal life cycle of addresses.  It uses Confirm to
+   validate addresses when it may have moved to a new link.  It uses
+   Information-Request messages when it needs configuration information
+   but no addresses.
+
+   If the client has a source address of sufficient scope that can be
+   used by the server as a return address, and the client has received a
+   Server Unicast option (section 22.12) from the server, the client
+   SHOULD unicast any Request, Renew, Release and Decline messages to
+   the server.
+
+   DISCUSSION:
+
+      Use of unicast may avoid delays due to the relaying of messages by
+      relay agents, as well as avoid overhead and duplicate responses by
+      servers due to the delivery of client messages to multiple
+      servers.  Requiring the client to relay all DHCP messages through
+      a relay agent enables the inclusion of relay agent options in all
+      messages sent by the client.  The server should enable the use of
+      unicast only when relay agent options will not be used.
+
+18.1.1. Creation and Transmission of Request Messages
+
+   The client uses a Request message to populate IAs with addresses and
+   obtain other configuration information.  The client includes one or
+   more IA options in the Request message.  The server then returns
+   addresses and other information about the IAs to the client in IA
+   options in a Reply message.
+
+   The client generates a transaction ID and inserts this value in the
+   "transaction-id" field.
+
+   The client places the identifier of the destination server in a
+   Server Identifier option.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client adds any other appropriate options,
+   including one or more IA options (if the client is requesting that
+   the server assign it some network addresses).
+
+   The client MUST include an Option Request option (see section 22.7)
+   to indicate the options the client is interested in receiving.  The
+   client MAY include options with data values as hints to the server
+   about parameter values the client would like to have returned.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 39]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The client includes a Reconfigure Accept option (see section 22.20)
+   indicating whether or not the client is willing to accept Reconfigure
+   messages from the server.
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   REQ_TIMEOUT
+
+      MRT   REQ_MAX_RT
+
+      MRC   REQ_MAX_RC
+
+      MRD   0
+
+   If the message exchange fails, the client takes an action based on
+   the client's local policy.  Examples of actions the client might take
+   include:
+
+   -  Select another server from a list of servers known to the client;
+      for example, servers that responded with an Advertise message.
+
+   -  Initiate the server discovery process described in section 17.
+
+   -  Terminate the configuration process and report failure.
+
+18.1.2. Creation and Transmission of Confirm Messages
+
+   Whenever a client may have moved to a new link, the prefixes from the
+   addresses assigned to the interfaces on that link may no longer be
+   appropriate for the link to which the client is attached.  Examples
+   of times when a client may have moved to a new link include:
+
+   o  The client reboots.
+
+   o  The client is physically connected to a wired connection.
+
+   o  The client returns from sleep mode.
+
+   o  The client using a wireless technology changes access points.
+
+   In any situation when a client may have moved to a new link, the
+   client MUST initiate a Confirm/Reply message exchange.  The client
+   includes any IAs assigned to the interface that may have moved to a
+   new link, along with the addresses associated with those IAs, in its
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 40]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Confirm message.  Any responding servers will indicate whether those
+   addresses are appropriate for the link to which the client is
+   attached with the status in the Reply message it returns to the
+   client.
+
+   The client sets the "msg-type" field to CONFIRM.  The client
+   generates a transaction ID and inserts this value in the
+   "transaction-id" field.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client includes IA options for all of the IAs
+   assigned to the interface for which the Confirm message is being
+   sent.  The IA options include all of the addresses the client
+   currently has associated with those IAs.  The client SHOULD set the
+   T1 and T2 fields in any IA_NA options, and the preferred-lifetime and
+   valid-lifetime fields in the IA Address options to 0, as the server
+   will ignore these fields.
+
+   The first Confirm message from the client on the interface MUST be
+   delayed by a random amount of time between 0 and CNF_MAX_DELAY.  The
+   client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   CNF_TIMEOUT
+
+      MRT   CNF_MAX_RT
+
+      MRC   0
+
+      MRD   CNF_MAX_RD
+
+   If the client receives no responses before the message transmission
+   process terminates, as described in section 14, the client SHOULD
+   continue to use any IP addresses, using the last known lifetimes for
+   those addresses, and SHOULD continue to use any other previously
+   obtained configuration parameters.
+
+18.1.3. Creation and Transmission of Renew Messages
+
+   To extend the valid and preferred lifetimes for the addresses
+   associated with an IA, the client sends a Renew message to the server
+   from which the client obtained the addresses in the IA containing an
+   IA option for the IA.  The client includes IA Address options in the
+   IA option for the addresses associated with the IA.  The server
+   determines new lifetimes for the addresses in the IA according to the
+   administrative configuration of the server.  The server may also add
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 41]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   new addresses to the IA.  The server may remove addresses from the IA
+   by setting the preferred and valid lifetimes of those addresses to
+   zero.
+
+   The server controls the time at which the client contacts the server
+   to extend the lifetimes on assigned addresses through the T1 and T2
+   parameters assigned to an IA.
+
+   At time T1 for an IA, the client initiates a Renew/Reply message
+   exchange to extend the lifetimes on any addresses in the IA.  The
+   client includes an IA option with all addresses currently assigned to
+   the IA in its Renew message.
+
+   If T1 or T2 is set to 0 by the server (for an IA_NA) or there are no
+   T1 or T2 times (for an IA_TA), the client may send a Renew or Rebind
+   message, respectively, at the client's discretion.
+
+   The client sets the "msg-type" field to RENEW.  The client generates
+   a transaction ID and inserts this value in the "transaction-id"
+   field.
+
+   The client places the identifier of the destination server in a
+   Server Identifier option.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client adds any appropriate options, including
+   one or more IA options.  The client MUST include the list of
+   addresses the client currently has associated with the IAs in the
+   Renew message.
+
+   The client MUST include an Option Request option (see section 22.7)
+   to indicate the options the client is interested in receiving.  The
+   client MAY include options with data values as hints to the server
+   about parameter values the client would like to have returned.
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   REN_TIMEOUT
+
+      MRT   REN_MAX_RT
+
+      MRC   0
+
+      MRD   Remaining time until T2
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 42]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The message exchange is terminated when time T2 is reached (see
+   section 18.1.4), at which time the client begins a Rebind message
+   exchange.
+
+18.1.4. Creation and Transmission of Rebind Messages
+
+   At time T2 for an IA (which will only be reached if the server to
+   which the Renew message was sent at time T1 has not responded), the
+   client initiates a Rebind/Reply message exchange with any available
+   server.  The client includes an IA option with all addresses
+   currently assigned to the IA in its Rebind message.
+
+   The client sets the "msg-type" field to REBIND.  The client generates
+   a transaction ID and inserts this value in the "transaction-id"
+   field.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client adds any appropriate options, including
+   one or more IA options.  The client MUST include the list of
+   addresses the client currently has associated with the IAs in the
+   Rebind message.
+
+   The client MUST include an Option Request option (see section 22.7)
+   to indicate the options the client is interested in receiving.  The
+   client MAY include options with data values as hints to the server
+   about parameter values the client would like to have returned.
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   REB_TIMEOUT
+
+      MRT   REB_MAX_RT
+
+      MRC   0
+
+      MRD   Remaining time until valid lifetimes of all addresses have
+            expired
+
+   The message exchange is terminated when the valid lifetimes of all
+   the addresses assigned to the IA expire (see section 10), at which
+   time the client has several alternative actions to choose from; for
+   example:
+
+   -  The client may choose to use a Solicit message to locate a new
+      DHCP server and send a Request for the expired IA to the new
+      server.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 43]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   -  The client may have other addresses in other IAs, so the client
+      may choose to discard the expired IA and use the addresses in the
+      other IAs.
+
+18.1.5. Creation and Transmission of Information-request Messages
+
+   The client uses an Information-request message to obtain
+   configuration information without having addresses assigned to it.
+
+   The client sets the "msg-type" field to INFORMATION-REQUEST.  The
+   client generates a transaction ID and inserts this value in the
+   "transaction-id" field.
+
+   The client SHOULD include a Client Identifier option to identify
+   itself to the server.  If the client does not include a Client
+   Identifier option, the server will not be able to return any client-
+   specific options to the client, or the server may choose not to
+   respond to the message at all.  The client MUST include a Client
+   Identifier option if the Information-Request message will be
+   authenticated.
+
+   The client MUST include an Option Request option (see section 22.7)
+   to indicate the options the client is interested in receiving.  The
+   client MAY include options with data values as hints to the server
+   about parameter values the client would like to have returned.
+
+   The first Information-request message from the client on the
+   interface MUST be delayed by a random amount of time between 0 and
+   INF_MAX_DELAY.  The client transmits the message according to section
+   14, using the following parameters:
+
+      IRT   INF_TIMEOUT
+
+      MRT   INF_MAX_RT
+
+      MRC   0
+
+      MRD   0
+
+18.1.6. Creation and Transmission of Release Messages
+
+   To release one or more addresses, a client sends a Release message to
+   the server.
+
+   The client sets the "msg-type" field to RELEASE.  The client
+   generates a transaction ID and places this value in the
+   "transaction-id" field.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 44]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The client places the identifier of the server that allocated the
+   address(es) in a Server Identifier option.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client includes options containing the IAs for
+   the addresses it is releasing in the "options" field.  The addresses
+   to be released MUST be included in the IAs.  Any addresses for the
+   IAs the client wishes to continue to use MUST NOT be added to the
+   IAs.
+
+   The client MUST NOT use any of the addresses it is releasing as the
+   source address in the Release message or in any subsequently
+   transmitted message.
+
+   Because Release messages may be lost, the client should retransmit
+   the Release if no Reply is received.  However, there are scenarios
+   where the client may not wish to wait for the normal retransmission
+   timeout before giving up (e.g., on power down).  Implementations
+   SHOULD retransmit one or more times, but MAY choose to terminate the
+   retransmission procedure early.
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   REL_TIMEOUT
+
+      MRT   0
+
+      MRC   REL_MAX_RC
+
+      MRD   0
+
+   The client MUST stop using all of the addresses being released as
+   soon as the client begins the Release message exchange process.  If
+   addresses are released but the Reply from a DHCP server is lost, the
+   client will retransmit the Release message, and the server may
+   respond with a Reply indicating a status of NoBinding.  Therefore,
+   the client does not treat a Reply message with a status of NoBinding
+   in a Release message exchange as if it indicates an error.
+
+   Note that if the client fails to release the addresses, each address
+   assigned to the IA will be reclaimed by the server when the valid
+   lifetime of that address expires.
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 45]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+18.1.7. Creation and Transmission of Decline Messages
+
+   If a client detects that one or more addresses assigned to it by a
+   server are already in use by another node, the client sends a Decline
+   message to the server to inform it that the address is suspect.
+
+   The client sets the "msg-type" field to DECLINE.  The client
+   generates a transaction ID and places this value in the
+   "transaction-id" field.
+
+   The client places the identifier of the server that allocated the
+   address(es) in a Server Identifier option.
+
+   The client MUST include a Client Identifier option to identify itself
+   to the server.  The client includes options containing the IAs for
+   the addresses it is declining in the "options" field.  The addresses
+   to be declined MUST be included in the IAs.  Any addresses for the
+   IAs the client wishes to continue to use should not be in added to
+   the IAs.
+
+   The client MUST NOT use any of the addresses it is declining as the
+   source address in the Decline message or in any subsequently
+   transmitted message.
+
+   The client transmits the message according to section 14, using the
+   following parameters:
+
+      IRT   DEC_TIMEOUT
+
+      MRT   0
+
+      MRC   DEC_MAX_RC
+
+      MRD   0
+
+   If addresses are declined but the Reply from a DHCP server is lost,
+   the client will retransmit the Decline message, and the server may
+   respond with a Reply indicating a status of NoBinding.  Therefore,
+   the client does not treat a Reply message with a status of NoBinding
+   in a Decline message exchange as if it indicates an error.
+
+18.1.8. Receipt of Reply Messages
+
+   Upon the receipt of a valid Reply message in response to a Solicit
+   (with a Rapid Commit option), Request, Confirm, Renew, Rebind or
+   Information-request message, the client extracts the configuration
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 46]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   information contained in the Reply.  The client MAY choose to report
+   any status code or message from the status code option in the Reply
+   message.
+
+   The client SHOULD perform duplicate address detection [17] on each of
+   the addresses in any IAs it receives in the Reply message before
+   using that address for traffic.  If any of the addresses are found to
+   be in use on the link, the client sends a Decline message to the
+   server as described in section 18.1.7.
+
+   If the Reply was received in response to a Solicit (with a Rapid
+   Commit option), Request, Renew or Rebind message, the client updates
+   the information it has recorded about IAs from the IA options
+   contained in the Reply message:
+
+   -  Record T1 and T2 times.
+
+   -  Add any new addresses in the IA option to the IA as recorded by
+      the client.
+
+   -  Update lifetimes for any addresses in the IA option that the
+      client already has recorded in the IA.
+
+   -  Discard any addresses from the IA, as recorded by the client, that
+      have a valid lifetime of 0 in the IA Address option.
+
+   -  Leave unchanged any information about addresses the client has
+      recorded in the IA but that were not included in the IA from the
+      server.
+
+   Management of the specific configuration information is detailed in
+   the definition of each option in section 22.
+
+   If the client receives a Reply message with a Status Code containing
+   UnspecFail, the server is indicating that it was unable to process
+   the message due to an unspecified failure condition.  If the client
+   retransmits the original message to the same server to retry the
+   desired operation, the client MUST limit the rate at which it
+   retransmits the message and limit the duration of the time during
+   which it retransmits the message.
+
+   When the client receives a Reply message with a Status Code option
+   with the value UseMulticast, the client records the receipt of the
+   message and sends subsequent messages to the server through the
+   interface on which the message was received using multicast.  The
+   client resends the original message using multicast.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 47]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   When the client receives a NotOnLink status from the server in
+   response to a Confirm message, the client performs DHCP server
+   solicitation, as described in section 17, and client-initiated
+   configuration as described in section 18.  If the client receives any
+   Reply messages that do not indicate a NotOnLink status, the client
+   can use the addresses in the IA and ignore any messages that indicate
+   a NotOnLink status.
+
+   When the client receives a NotOnLink status from the server in
+   response to a Request, the client can either re-issue the Request
+   without specifying any addresses or restart the DHCP server discovery
+   process (see section 17).
+
+   The client examines the status code in each IA individually.  If the
+   status code is NoAddrsAvail, the client has received no usable
+   addresses in the IA and may choose to try obtaining addresses for the
+   IA from another server.  The client uses addresses and other
+   information from any IAs that do not contain a Status Code option
+   with the NoAddrsAvail code.  If the client receives no addresses in
+   any of the IAs, it may either try another server (perhaps restarting
+   the DHCP server discovery process) or use the Information-request
+   message to obtain other configuration information only.
+
+   When the client receives a Reply message in response to a Renew or
+   Rebind message, the client examines each IA independently.  For each
+   IA in the original Renew or Rebind message, the client:
+
+   -  sends a Request message if the IA contained a Status Code option
+      with the NoBinding status (and does not send any additional
+      Renew/Rebind messages)
+
+   -  sends a Renew/Rebind if the IA is not in the Reply message
+
+   -  otherwise accepts the information in the IA
+
+   When the client receives a valid Reply message in response to a
+   Release message, the client considers the Release event completed,
+   regardless of the Status Code option(s) returned by the server.
+
+   When the client receives a valid Reply message in response to a
+   Decline message, the client considers the Decline event completed,
+   regardless of the Status Code option(s) returned by the server.
+
+18.2. Server Behavior
+
+   For this discussion, the Server is assumed to have been configured in
+   an implementation specific manner with configuration of interest to
+   clients.
+
+
+
+Droms, et al.               Standards Track                    [Page 48]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   In most instances, the server will send a Reply in response to a
+   client message.  This Reply message MUST always contain the Server
+   Identifier option containing the server's DUID and the Client
+   Identifier option from the client message if one was present.
+
+   In most Reply messages, the server includes options containing
+   configuration information for the client.  The server must be aware
+   of the recommendations on packet sizes and the use of fragmentation
+   in section 5 of RFC 2460.  If the client included an Option Request
+   option in its message, the server includes options in the Reply
+   message containing configuration parameters for all of the options
+   identified in the Option Request option that the server has been
+   configured to return to the client.  The server MAY return additional
+   options to the client if it has been configured to do so.
+
+18.2.1. Receipt of Request Messages
+
+   When the server receives a Request message via unicast from a client
+   to which the server has not sent a unicast option, the server
+   discards the Request message and responds with a Reply message
+   containing a Status Code option with the value UseMulticast, a Server
+   Identifier option containing the server's DUID, the Client Identifier
+   option from the client message, and no other options.
+
+   When the server receives a valid Request message, the server creates
+   the bindings for that client according to the server's policy and
+   configuration information and records the IAs and other information
+   requested by the client.
+
+   The server constructs a Reply message by setting the "msg-type" field
+   to REPLY, and copying the transaction ID from the Request message
+   into the transaction-id field.
+
+   The server MUST include a Server Identifier option containing the
+   server's DUID and the Client Identifier option from the Request
+   message in the Reply message.
+
+   If the server finds that the prefix on one or more IP addresses in
+   any IA in the message from the client is not appropriate for the link
+   to which the client is connected, the server MUST return the IA to
+   the client with a Status Code option with the value NotOnLink.
+
+   If the server cannot assign any addresses to an IA in the message
+   from the client, the server MUST include the IA in the Reply message
+   with no addresses in the IA and a Status Code option in the IA
+   containing status code NoAddrsAvail.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 49]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   For any IAs to which the server can assign addresses, the server
+   includes the IA with addresses and other configuration parameters,
+   and records the IA as a new client binding.
+
+   The server includes a Reconfigure Accept option if the server wants
+   to require that the client accept Reconfigure messages.
+
+   The server includes other options containing configuration
+   information to be returned to the client as described in section
+   18.2.
+
+   If the server finds that the client has included an IA in the Request
+   message for which the server already has a binding that associates
+   the IA with the client, the client has resent a Request message for
+   which it did not receive a Reply message.  The server either resends
+   a previously cached Reply message or sends a new Reply message.
+
+18.2.2. Receipt of Confirm Messages
+
+   When the server receives a Confirm message, the server determines
+   whether the addresses in the Confirm message are appropriate for the
+   link to which the client is attached.  If all of the addresses in the
+   Confirm message pass this test, the server returns a status of
+   Success.  If any of the addresses do not pass this test, the server
+   returns a status of NotOnLink.  If the server is unable to perform
+   this test (for example, the server does not have information about
+   prefixes on the link to which the client is connected), or there were
+   no addresses in any of the IAs sent by the client, the server MUST
+   NOT send a reply to the client.
+
+   The server ignores the T1 and T2 fields in the IA options and the
+   preferred-lifetime and valid-lifetime fields in the IA Address
+   options.
+
+   The server constructs a Reply message by setting the "msg-type" field
+   to REPLY, and copying the transaction ID from the Confirm message
+   into the transaction-id field.
+
+   The server MUST include a Server Identifier option containing the
+   server's DUID and the Client Identifier option from the Confirm
+   message in the Reply message.  The server includes a Status Code
+   option indicating the status of the Confirm message.
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 50]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+18.2.3. Receipt of Renew Messages
+
+   When the server receives a Renew message via unicast from a client to
+   which the server has not sent a unicast option, the server discards
+   the Renew message and responds with a Reply message containing a
+   Status Code option with the value UseMulticast, a Server Identifier
+   option containing the server's DUID, the Client Identifier option
+   from the client message, and no other options.
+
+   When the server receives a Renew message that contains an IA option
+   from a client, it locates the client's binding and verifies that the
+   information in the IA from the client matches the information stored
+   for that client.
+
+   If the server cannot find a client entry for the IA the server
+   returns the IA containing no addresses with a Status Code option set
+   to NoBinding in the Reply message.
+
+   If the server finds that any of the addresses are not appropriate for
+   the link to which the client is attached, the server returns the
+   address to the client with lifetimes of 0.
+
+   If the server finds the addresses in the IA for the client then the
+   server sends back the IA to the client with new lifetimes and T1/T2
+   times.  The server may choose to change the list of addresses and the
+   lifetimes of addresses in IAs that are returned to the client.
+
+   The server constructs a Reply message by setting the "msg-type" field
+   to REPLY, and copying the transaction ID from the Renew message into
+   the transaction-id field.
+
+   The server MUST include a Server Identifier option containing the
+   server's DUID and the Client Identifier option from the Renew message
+   in the Reply message.
+
+   The server includes other options containing configuration
+   information to be returned to the client as described in section
+   18.2.
+
+18.2.4. Receipt of Rebind Messages
+
+   When the server receives a Rebind message that contains an IA option
+   from a client, it locates the client's binding and verifies that the
+   information in the IA from the client matches the information stored
+   for that client.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 51]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   If the server cannot find a client entry for the IA and the server
+   determines that the addresses in the IA are not appropriate for the
+   link to which the client's interface is attached according to the
+   server's explicit configuration information, the server MAY send a
+   Reply message to the client containing the client's IA, with the
+   lifetimes for the addresses in the IA set to zero.  This Reply
+   constitutes an explicit notification to the client that the addresses
+   in the IA are no longer valid.  In this situation, if the server does
+   not send a Reply message it silently discards the Rebind message.
+
+   If the server finds that any of the addresses are no longer
+   appropriate for the link to which the client is attached, the server
+   returns the address to the client with lifetimes of 0.
+
+   If the server finds the addresses in the IA for the client then the
+   server SHOULD send back the IA to the client with new lifetimes and
+   T1/T2 times.
+
+   The server constructs a Reply message by setting the "msg-type" field
+   to REPLY, and copying the transaction ID from the Rebind message into
+   the transaction-id field.
+
+   The server MUST include a Server Identifier option containing the
+   server's DUID and the Client Identifier option from the Rebind
+   message in the Reply message.
+
+   The server includes other options containing configuration
+   information to be returned to the client as described in section
+   18.2.
+
+18.2.5. Receipt of Information-request Messages
+
+   When the server receives an Information-request message, the client
+   is requesting configuration information that does not include the
+   assignment of any addresses.  The server determines all configuration
+   parameters appropriate to the client, based on the server
+   configuration policies known to the server.
+
+   The server constructs a Reply message by setting the "msg-type" field
+   to REPLY, and copying the transaction ID from the Information-request
+   message into the transaction-id field.
+
+   The server MUST include a Server Identifier option containing the
+   server's DUID in the Reply message.  If the client included a Client
+   Identification option in the Information-request message, the server
+   copies that option to the Reply message.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 52]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The server includes options containing configuration information to
+   be returned to the client as described in section 18.2.
+
+   If the Information-request message received from the client did not
+   include a Client Identifier option, the server SHOULD respond with a
+   Reply message containing any configuration parameters that are not
+   determined by the client's identity.  If the server chooses not to
+   respond, the client may continue to retransmit the
+   Information-request message indefinitely.
+
+18.2.6. Receipt of Release Messages
+
+   When the server receives a Release message via unicast from a client
+   to which the server has not sent a unicast option, the server
+   discards the Release message and responds with a Reply message
+   containing a Status Code option with value UseMulticast, a Server
+   Identifier option containing the server's DUID, the Client Identifier
+   option from the client message, and no other options.
+
+   Upon the receipt of a valid Release message, the server examines the
+   IAs and the addresses in the IAs for validity.  If the IAs in the
+   message are in a binding for the client, and the addresses in the IAs
+   have been assigned by the server to those IAs, the server deletes the
+   addresses from the IAs and makes the addresses available for
+   assignment to other clients.  The server ignores addresses not
+   assigned to the IA, although it may choose to log an error.
+
+   After all the addresses have been processed, the server generates a
+   Reply message and includes a Status Code option with value Success, a
+   Server Identifier option with the server's DUID, and a Client
+   Identifier option with the client's DUID.  For each IA in the Release
+   message for which the server has no binding information, the server
+   adds an IA option using the IAID from the Release message, and
+   includes a Status Code option with the value NoBinding in the IA
+   option.  No other options are included in the IA option.
+
+   A server may choose to retain a record of assigned addresses and IAs
+   after the lifetimes on the addresses have expired to allow the server
+   to reassign the previously assigned addresses to a client.
+
+18.2.7. Receipt of Decline Messages
+
+   When the server receives a Decline message via unicast from a client
+   to which the server has not sent a unicast option, the server
+   discards the Decline message and responds with a Reply message
+   containing a Status Code option with the value UseMulticast, a Server
+   Identifier option containing the server's DUID, the Client Identifier
+   option from the client message, and no other options.
+
+
+
+Droms, et al.               Standards Track                    [Page 53]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Upon the receipt of a valid Decline message, the server examines the
+   IAs and the addresses in the IAs for validity.  If the IAs in the
+   message are in a binding for the client, and the addresses in the IAs
+   have been assigned by the server to those IAs, the server deletes the
+   addresses from the IAs.  The server ignores addresses not assigned to
+   the IA (though it may choose to log an error if it finds such an
+   address).
+
+   The client has found any addresses in the Decline messages to be
+   already in use on its link.  Therefore, the server SHOULD mark the
+   addresses declined by the client so that those addresses are not
+   assigned to other clients, and MAY choose to make a notification that
+   addresses were declined.  Local policy on the server determines when
+   the addresses identified in a Decline message may be made available
+   for assignment.
+
+   After all the addresses have been processed, the server generates a
+   Reply message and includes a Status Code option with the value
+   Success, a Server Identifier option with the server's DUID, and a
+   Client Identifier option with the client's DUID.  For each IA in the
+   Decline message for which the server has no binding information, the
+   server adds an IA option using the IAID from the Release message and
+   includes a Status Code option with the value NoBinding in the IA
+   option.  No other options are included in the IA option.
+
+18.2.8. Transmission of Reply Messages
+
+   If the original message was received directly by the server, the
+   server unicasts the Reply message directly to the client using the
+   address in the source address field from the IP datagram in which the
+   original message was received.  The Reply message MUST be unicast
+   through the interface on which the original message was received.
+
+   If the original message was received in a Relay-forward message, the
+   server constructs a Relay-reply message with the Reply message in the
+   payload of a Relay Message option (see section 22.10).  If the
+   Relay-forward messages included an Interface-id option, the server
+   copies that option to the Relay-reply message.  The server unicasts
+   the Relay-reply message directly to the relay agent using the address
+   in the source address field from the IP datagram in which the
+   Relay-forward message was received.
+
+19. DHCP Server-Initiated Configuration Exchange
+
+   A server initiates a configuration exchange to cause DHCP clients to
+   obtain new addresses and other configuration information.  For
+   example, an administrator may use a server-initiated configuration
+   exchange when links in the DHCP domain are to be renumbered.  Other
+
+
+
+Droms, et al.               Standards Track                    [Page 54]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   examples include changes in the location of directory servers,
+   addition of new services such as printing, and availability of new
+   software.
+
+19.1. Server Behavior
+
+   A server sends a Reconfigure message to cause a client to initiate
+   immediately a Renew/Reply or Information-request/Reply message
+   exchange with the server.
+
+19.1.1. Creation and Transmission of Reconfigure Messages
+
+   The server sets the "msg-type" field to RECONFIGURE.  The server sets
+   the transaction-id field to 0.  The server includes a Server
+   Identifier option containing its DUID and a Client Identifier option
+   containing the client's DUID in the Reconfigure message.
+
+   The server MAY include an Option Request option to inform the client
+   of what information has been changed or new information that has been
+   added.  In particular, the server specifies the IA option in the
+   Option Request option if the server wants the client to obtain new
+   address information.  If the server identifies the IA option in the
+   Option Request option, the server MUST include an IA option that
+   contains no other sub-options to identify each IA that is to be
+   reconfigured on the client.
+
+   Because of the risk of denial of service attacks against DHCP
+   clients, the use of a security mechanism is mandated in Reconfigure
+   messages.  The server MUST use DHCP authentication in the Reconfigure
+   message.
+
+   The server MUST include a Reconfigure Message option (defined in
+   section 22.19) to select whether the client responds with a Renew
+   message or an Information-Request message.
+
+   The server MUST NOT include any other options in the Reconfigure
+   except as specifically allowed in the definition of individual
+   options.
+
+   A server sends each Reconfigure message to a single DHCP client,
+   using an IPv6 unicast address of sufficient scope belonging to the
+   DHCP client.  If the server does not have an address to which it can
+   send the Reconfigure message directly to the client, the server uses
+   a Relay-reply message (as described in section 20.3) to send the
+   Reconfigure message to a relay agent that will relay the message to
+   the client.  The server may obtain the address of the client (and the
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 55]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   appropriate relay agent, if required) through the information the
+   server has about clients that have been in contact with the server,
+   or through some external agent.
+
+   To reconfigure more than one client, the server unicasts a separate
+   message to each client.  The server may initiate the reconfiguration
+   of multiple clients concurrently; for example, a server may send a
+   Reconfigure message to additional clients while previous
+   reconfiguration message exchanges are still in progress.
+
+   The Reconfigure message causes the client to initiate a Renew/Reply
+   or Information-request/Reply message exchange with the server.  The
+   server interprets the receipt of a Renew or Information-request
+   message (whichever was specified in the original Reconfigure message)
+   from the client as satisfying the Reconfigure message request.
+
+19.1.2. Time Out and Retransmission of Reconfigure Messages
+
+   If the server does not receive a Renew or Information-request message
+   from the client in REC_TIMEOUT milliseconds, the server retransmits
+   the Reconfigure message, doubles the REC_TIMEOUT value and waits
+   again.  The server continues this process until REC_MAX_RC
+   unsuccessful attempts have been made, at which point the server
+   SHOULD abort the reconfigure process for that client.
+
+   Default and initial values for REC_TIMEOUT and REC_MAX_RC are
+   documented in section 5.5.
+
+19.2. Receipt of Renew Messages
+
+   The server generates and sends a Reply message to the client as
+   described in sections 18.2.3 and 18.2.8, including options for
+   configuration parameters.
+
+   The server MAY include options containing the IAs and new values for
+   other configuration parameters in the Reply message, even if those
+   IAs and parameters were not requested in the Renew message from the
+   client.
+
+19.3. Receipt of Information-request Messages
+
+   The server generates and sends a Reply message to the client as
+   described in sections 18.2.5 and 18.2.8, including options for
+   configuration parameters.
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 56]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The server MAY include options containing new values for other
+   configuration parameters in the Reply message, even if those
+   parameters were not requested in the Information-request message from
+   the client.
+
+19.4. Client Behavior
+
+   A client receives Reconfigure messages sent to the UDP port 546 on
+   interfaces for which it has acquired configuration information
+   through DHCP.  These messages may be sent at any time.  Since the
+   results of a reconfiguration event may affect application layer
+   programs, the client SHOULD log these events, and MAY notify these
+   programs of the change through an implementation-specific interface.
+
+19.4.1. Receipt of Reconfigure Messages
+
+   Upon receipt of a valid Reconfigure message, the client responds with
+   either a Renew message or an Information-request message as indicated
+   by the Reconfigure Message option (as defined in section 22.19).  The
+   client ignores the transaction-id field in the received Reconfigure
+   message.  While the transaction is in progress, the client silently
+   discards any Reconfigure messages it receives.
+
+   DISCUSSION:
+
+      The Reconfigure message acts as a trigger that signals the client
+      to complete a successful message exchange.  Once the client has
+      received a Reconfigure, the client proceeds with the message
+      exchange (retransmitting the Renew or Information-request message
+      if necessary); the client ignores any additional Reconfigure
+      messages until the exchange is complete.  Subsequent Reconfigure
+      messages cause the client to initiate a new exchange.
+
+      How does this mechanism work in the face of duplicated or
+      retransmitted Reconfigure messages?  Duplicate messages will be
+      ignored because the client will begin the exchange after the
+      receipt of the first Reconfigure.  Retransmitted messages will
+      either trigger the exchange (if the first Reconfigure was not
+      received by the client) or will be ignored.  The server can
+      discontinue retransmission of Reconfigure messages to the client
+      once the server receives the Renew or Information-request message
+      from the client.
+
+      It might be possible for a duplicate or retransmitted Reconfigure
+      to be sufficiently delayed (and delivered out of order) to arrive
+      at the client after the exchange (initiated by the original
+      Reconfigure) has been completed.  In this case, the client would
+      initiate a redundant exchange.  The likelihood of delayed and out
+
+
+
+Droms, et al.               Standards Track                    [Page 57]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      of order delivery is small enough to be ignored.  The consequence
+      of the redundant exchange is inefficiency rather than incorrect
+      operation.
+
+19.4.2. Creation and Transmission of Renew Messages
+
+   When responding to a Reconfigure, the client creates and sends the
+   Renew message in exactly the same manner as outlined in section
+   18.1.3, with the exception that the client copies the Option Request
+   option and any IA options from the Reconfigure message into the Renew
+   message.
+
+19.4.3. Creation and Transmission of Information-request Messages
+
+   When responding to a Reconfigure, the client creates and sends the
+   Information-request message in exactly the same manner as outlined in
+   section 18.1.5, with the exception that the client includes a Server
+   Identifier option with the identifier from the Reconfigure message to
+   which the client is responding.
+
+19.4.4. Time Out and Retransmission of Renew or Information-request
+        Messages
+
+   The client uses the same variables and retransmission algorithm as it
+   does with Renew or Information-request messages generated as part of
+   a client-initiated configuration exchange.  See sections 18.1.3 and
+   18.1.5 for details.  If the client does not receive a response from
+   the server by the end of the retransmission process, the client
+   ignores and discards the Reconfigure message.
+
+19.4.5. Receipt of Reply Messages
+
+   Upon the receipt of a valid Reply message, the client processes the
+   options and sets (or resets) configuration parameters appropriately.
+   The client records and updates the lifetimes for any addresses
+   specified in IAs in the Reply message.
+
+20. Relay Agent Behavior
+
+   The relay agent MAY be configured to use a list of destination
+   addresses, which MAY include unicast addresses, the All_DHCP_Servers
+   multicast address, or other addresses selected by the network
+   administrator.  If the relay agent has not been explicitly
+   configured, it MUST use the All_DHCP_Servers multicast address as the
+   default.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 58]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   If the relay agent relays messages to the All_DHCP_Servers multicast
+   address or other multicast addresses, it sets the Hop Limit field to
+   32.
+
+20.1. Relaying a Client Message or a Relay-forward Message
+
+   A relay agent relays both messages from clients and Relay-forward
+   messages from other relay agents.  When a relay agent receives a
+   valid message to be relayed, it constructs a new Relay-forward
+   message.  The relay agent copies the source address from the header
+   of the IP datagram in which the message was received to the
+   peer-address field of the Relay-forward message.  The relay agent
+   copies the received DHCP message (excluding any IP or UDP headers)
+   into a Relay Message option in the new message.  The relay agent adds
+   to the Relay-forward message any other options it is configured to
+   include.
+
+20.1.1. Relaying a Message from a Client
+
+   If the relay agent received the message to be relayed from a client,
+   the relay agent places a global or site-scoped address with a prefix
+   assigned to the link on which the client should be assigned an
+   address in the link-address field.  This address will be used by the
+   server to determine the link from which the client should be assigned
+   an address and other configuration information.  The hop-count in the
+   Relay-forward message is set to 0.
+
+   If the relay agent cannot use the address in the link-address field
+   to identify the interface through which the response to the client
+   will be relayed, the relay agent MUST include an Interface-id option
+   (see section 22.18) in the Relay-forward message.  The server will
+   include the Interface-id option in its Relay-reply message.  The
+   relay agent fills in the link-address field as described in the
+   previous paragraph regardless of whether the relay agent includes an
+   Interface-id option in the Relay-forward message.
+
+20.1.2. Relaying a Message from a Relay Agent
+
+   If the message received by the relay agent is a Relay-forward message
+   and the hop-count in the message is greater than or equal to
+   HOP_COUNT_LIMIT, the relay agent discards the received message.
+
+   The relay agent copies the source address from the IP datagram in
+   which the message was received from the client into the peer-address
+   field in the Relay-forward message and sets the hop-count field to
+   the value of the hop-count field in the received message incremented
+   by 1.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 59]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   If the source address from the IP datagram header of the received
+   message is a global or site-local address (and the device on which
+   the relay agent is running belongs to only one site), the relay agent
+   sets the link-address field to 0; otherwise the relay agent sets the
+   link-address field to a global or site-local address assigned to the
+   interface on which the message was received, or includes an
+   Interface-ID option to identify the interface on which the message
+   was received.
+
+20.2. Relaying a Relay-reply Message
+
+   The relay agent processes any options included in the Relay-reply
+   message in addition to the Relay Message option, and then discards
+   those options.
+
+   The relay agent extracts the message from the Relay Message option
+   and relays it to the address contained in the peer-address field of
+   the Relay-reply message.
+
+   If the Relay-reply message includes an Interface-id option, the relay
+   agent relays the message from the server to the client on the link
+   identified by the Interface-id option.  Otherwise, if the
+   link-address field is not set to zero, the relay agent relays the
+   message on the link identified by the link-address field.
+
+20.3. Construction of Relay-reply Messages
+
+   A server uses a Relay-reply message to return a response to a client
+   if the original message from the client was relayed to the server in
+   a Relay-forward message or to send a Reconfigure message to a client
+   if the server does not have an address it can use to send the message
+   directly to the client.
+
+   A response to the client MUST be relayed through the same relay
+   agents as the original client message.  The server causes this to
+   happen by creating a Relay-reply message that includes a Relay
+   Message option containing the message for the next relay agent in the
+   return path to the client.  The contained Relay-reply message
+   contains another Relay Message option to be sent to the next relay
+   agent, and so on.  The server must record the contents of the
+   peer-address fields in the received message so it can construct the
+   appropriate Relay-reply message carrying the response from the
+   server.
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 60]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   For example, if client C sent a message that was relayed by relay
+   agent A to relay agent B and then to the server, the server would
+   send the following Relay-Reply message to relay agent B:
+
+   msg-type:       RELAY-REPLY
+   hop-count:      1
+   link-address:   0
+   peer-address:   A
+   Relay Message option, containing:
+     msg-type:     RELAY-REPLY
+     hop-count:    0
+     link-address: address from link to which C is attached
+     peer-address: C
+     Relay Message option: <response from server>
+
+   When sending a Reconfigure message to a client through a relay agent,
+   the server creates a Relay-reply message that includes a Relay
+   Message option containing the Reconfigure message for the next relay
+   agent in the return path to the client.  The server sets the
+   peer-address field in the Relay-reply message header to the address
+   of the client, and sets the link-address field as required by the
+   relay agent to relay the Reconfigure message to the client.  The
+   server obtains the addresses of the client and the relay agent
+   through prior interaction with the client or through some external
+   mechanism.
+
+21. Authentication of DHCP Messages
+
+   Some network administrators may wish to provide authentication of the
+   source and contents of DHCP messages.  For example, clients may be
+   subject to denial of service attacks through the use of bogus DHCP
+   servers, or may simply be misconfigured due to unintentionally
+   instantiated DHCP servers.  Network administrators may wish to
+   constrain the allocation of addresses to authorized hosts to avoid
+   denial of service attacks in "hostile" environments where the network
+   medium is not physically secured, such as wireless networks or
+   college residence halls.
+
+   The DHCP authentication mechanism is based on the design of
+   authentication for DHCPv4 [4].
+
+21.1. Security of Messages Sent Between Servers and Relay Agents
+
+   Relay agents and servers that exchange messages securely use the
+   IPsec mechanisms for IPv6 [7].  If a client message is relayed
+   through multiple relay agents, each of the relay agents must have
+   established independent, pairwise trust relationships.  That is, if
+   messages from client C will be relayed by relay agent A to relay
+
+
+
+Droms, et al.               Standards Track                    [Page 61]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   agent B and then to the server, relay agents A and B must be
+   configured to use IPSec for the messages they exchange, and relay
+   agent B and the server must be configured to use IPSec for the
+   messages they exchange.
+
+   Relay agents and servers that support secure relay agent to server or
+   relay agent to relay agent communication use IPsec under the
+   following conditions:
+
+      Selectors        Relay agents are manually configured with the
+                       addresses of the relay agent or server to which
+                       DHCP messages are to be forwarded.  Each relay
+                       agent and server that will be using IPsec for
+                       securing DHCP messages must also be configured
+                       with a list of the relay agents to which messages
+                       will be returned.  The selectors for the relay
+                       agents and servers will be the pairs of addresses
+                       defining relay agents and servers that exchange
+                       DHCP messages on the DHCPv6 UDP ports 546 and
+                       547.
+
+      Mode             Relay agents and servers use transport mode and
+                       ESP. The information in DHCP messages is not
+                       generally considered confidential, so encryption
+                       need not be used (i.e., NULL encryption can be
+                       used).
+
+      Key management   Because the relay agents and servers are used
+                       within an organization, public key schemes are
+                       not necessary.  Because the relay agents and
+                       servers must be manually configured, manually
+                       configured key management may suffice, but does
+                       not provide defense against replayed messages.
+                       Accordingly, IKE with preshared secrets SHOULD be
+                       supported.  IKE with public keys MAY be
+                       supported.
+
+      Security policy  DHCP messages between relay agents and servers
+                       should only be accepted from DHCP peers as
+                       identified in the local configuration.
+
+      Authentication   Shared keys, indexed to the source IP address of
+                       the received DHCP message, are adequate in this
+                       application.
+
+      Availability     Appropriate IPsec implementations are likely to
+                       be available for servers and for relay agents in
+                       more featureful devices used in enterprise and
+
+
+
+Droms, et al.               Standards Track                    [Page 62]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+                       core ISP networks.  IPsec is less likely to be
+                       available for relay agents in low end devices
+                       primarily used in the home or small office
+                       markets.
+
+21.2. Summary of DHCP Authentication
+
+   Authentication of DHCP messages is accomplished through the use of
+   the Authentication option (see section 22.11).  The authentication
+   information carried in the Authentication option can be used to
+   reliably identify the source of a DHCP message and to confirm that
+   the contents of the DHCP message have not been tampered with.
+
+   The Authentication option provides a framework for multiple
+   authentication protocols.  Two such protocols are defined here.
+   Other protocols defined in the future will be specified in separate
+   documents.
+
+   Any DHCP message MUST NOT include more than one Authentication
+   option.
+
+   The protocol field in the Authentication option identifies the
+   specific protocol used to generate the authentication information
+   carried in the option.  The algorithm field identifies a specific
+   algorithm within the authentication protocol; for example, the
+   algorithm field specifies the hash algorithm used to generate the
+   message authentication code (MAC) in the authentication option.  The
+   replay detection method (RDM) field specifies the type of replay
+   detection used in the replay detection field.
+
+21.3. Replay Detection
+
+   The Replay Detection Method (RDM) field determines the type of replay
+   detection used in the Replay Detection field.
+
+   If the RDM field contains 0x00, the replay detection field MUST be
+   set to the value of a monotonically increasing counter.  Using a
+   counter value, such as the current time of day (for example, an NTP-
+   format timestamp [9]), can reduce the danger of replay attacks.  This
+   method MUST be supported by all protocols.
+
+21.4. Delayed Authentication Protocol
+
+   If the protocol field is 2, the message is using the "delayed
+   authentication" mechanism.  In delayed authentication, the client
+   requests authentication in its Solicit message, and the server
+   replies with an Advertise message that includes authentication
+
+
+
+
+Droms, et al.               Standards Track                    [Page 63]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   information.  This authentication information contains a nonce value
+   generated by the source as a message authentication code (MAC) to
+   provide message authentication and entity authentication.
+
+   The use of a particular technique based on the HMAC protocol [8]
+   using the MD5 hash [16] is defined here.
+
+21.4.1. Use of the Authentication Option in the Delayed Authentication
+        Protocol
+
+   In a Solicit message, the client fills in the protocol, algorithm and
+   RDM fields in the Authentication option with the client's
+   preferences.  The client sets the replay detection field to zero and
+   omits the authentication information field.  The client sets the
+   option-len field to 11.
+
+   In all other messages, the protocol and algorithm fields identify the
+   method used to construct the contents of the authentication
+   information field.  The RDM field identifies the method used to
+   construct the contents of the replay detection field.
+
+   The format of the Authentication information is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                          DHCP realm                           |
+    |                      (variable length)                        |
+    .                                                               .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                            key ID                             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                           HMAC-MD5                            |
+    |                          (128 bits)                           |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      DHCP realm  The DHCP realm that identifies the key used to
+                  generate the HMAC-MD5 value.
+
+      key ID      The key identifier that identified the key used to
+                  generate the HMAC-MD5 value.
+
+      HMAC-MD5    The message authentication code generated by applying
+                  MD5 to the DHCP message using the key identified by
+                  the DHCP realm, client DUID, and key ID.
+
+
+
+Droms, et al.               Standards Track                    [Page 64]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The sender computes the MAC using the HMAC generation algorithm [8]
+   and the MD5 hash function [16].  The entire DHCP message (setting the
+   MAC field of the authentication option to zero), including the DHCP
+   message header and the options field, is used as input to the HMAC-
+   MD5 computation function.
+
+   DISCUSSION:
+
+      Algorithm 1 specifies the use of HMAC-MD5.  Use of a different
+      technique, such as HMAC-SHA, will be specified as a separate
+      protocol.
+
+      The DHCP realm used to identify authentication keys is chosen to
+      be unique among administrative domains.  Use of the DHCP realm
+      allows DHCP administrators to avoid conflict in the use of key
+      identifiers, and allows a host using DHCP to use authenticated
+      DHCP while roaming among DHCP administrative domains.
+
+21.4.2. Message Validation
+
+   Any DHCP message that includes more than one authentication option
+   MUST be discarded.
+
+   To validate an incoming message, the receiver first checks that the
+   value in the replay detection field is acceptable according to the
+   replay detection method specified by the RDM field.  Next, the
+   receiver computes the MAC as described in [8].  The entire DHCP
+   message (setting the MAC field of the authentication option to 0) is
+   used as input to the HMAC-MD5 computation function.  If the MAC
+   computed by the receiver does not match the MAC contained in the
+   authentication option, the receiver MUST discard the DHCP message.
+
+21.4.3. Key Utilization
+
+   Each DHCP client has a set of keys.  Each key is identified by <DHCP
+   realm, client DUID, key id>.  Each key also has a lifetime.  The key
+   may not be used past the end of its lifetime.  The client's keys are
+   initially distributed to the client through some out-of-band
+   mechanism.  The lifetime for each key is distributed with the key.
+   Mechanisms for key distribution and lifetime specification are beyond
+   the scope of this document.
+
+   The client and server use one of the client's keys to authenticate
+   DHCP messages during a session (until the next Solicit message sent
+   by the client).
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 65]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+21.4.4. Client Considerations for Delayed Authentication Protocol
+
+   The client announces its intention to use DHCP authentication by
+   including an Authentication option in its Solicit message.  The
+   server selects a key for the client based on the client's DUID.  The
+   client and server use that key to authenticate all DHCP messages
+   exchanged during the session.
+
+21.4.4.1. Sending Solicit Messages
+
+   When the client sends a Solicit message and wishes to use
+   authentication, it includes an Authentication option with the desired
+   protocol, algorithm and RDM as described in section 21.4.  The client
+   does not include any replay detection or authentication information
+   in the Authentication option.
+
+21.4.4.2. Receiving Advertise Messages
+
+   The client validates any Advertise messages containing an
+   Authentication option specifying the delayed authentication protocol
+   using the validation test described in section 21.4.2.
+
+   Client behavior, if no Advertise messages include authentication
+   information or pass the validation test, is controlled by local
+   policy on the client.  According to client policy, the client MAY
+   choose to respond to an Advertise message that has not been
+   authenticated.
+
+   The decision to set local policy to accept unauthenticated messages
+   should be made with care.  Accepting an unauthenticated Advertise
+   message can make the client vulnerable to spoofing and other attacks.
+   If local users are not explicitly informed that the client has
+   accepted an unauthenticated Advertise message, the users may
+   incorrectly assume that the client has received an authenticated
+   address and is not subject to DHCP attacks through unauthenticated
+   messages.
+
+   A client MUST be configurable to discard unauthenticated messages,
+   and SHOULD be configured by default to discard unauthenticated
+   messages if the client has been configured with an authentication key
+   or other authentication information.  A client MAY choose to
+   differentiate between Advertise messages with no authentication
+   information and Advertise messages that do not pass the validation
+   test; for example, a client might accept the former and discard the
+   latter.  If a client does accept an unauthenticated message, the
+   client SHOULD inform any local users and SHOULD log the event.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 66]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+21.4.4.3. Sending Request, Confirm, Renew, Rebind, Decline or Release
+          Messages
+
+   If the client authenticated the Advertise message through which the
+   client selected the server, the client MUST generate authentication
+   information for subsequent Request, Confirm, Renew, Rebind or Release
+   messages sent to the server, as described in section 21.4.  When the
+   client sends a subsequent message, it MUST use the same key used by
+   the server to generate the authentication information.
+
+21.4.4.4. Sending Information-request Messages
+
+   If the server has selected a key for the client in a previous message
+   exchange (see section 21.4.5.1), the client MUST use the same key to
+   generate the authentication information throughout the session.
+
+21.4.4.5. Receiving Reply Messages
+
+   If the client authenticated the Advertise it accepted, the client
+   MUST validate the associated Reply message from the server.  The
+   client MUST discard the Reply if the message fails to pass the
+   validation test and MAY log the validation failure.  If the Reply
+   fails to pass the validation test, the client MUST restart the DHCP
+   configuration process by sending a Solicit message.
+
+   If the client accepted an Advertise message that did not include
+   authentication information or did not pass the validation test, the
+   client MAY accept an unauthenticated Reply message from the server.
+
+21.4.4.6. Receiving Reconfigure Messages
+
+   The client MUST discard the Reconfigure if the message fails to pass
+   the validation test and MAY log the validation failure.
+
+21.4.5. Server Considerations for Delayed Authentication Protocol
+
+   After receiving a Solicit message that contains an Authentication
+   option, the server selects a key for the client, based on the
+   client's DUID and key selection policies with which the server has
+   been configured.  The server identifies the selected key in the
+   Advertise message and uses the key to validate subsequent messages
+   between the client and the server.
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 67]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+21.4.5.1. Receiving Solicit Messages and Sending Advertise Messages
+
+   The server selects a key for the client and includes authentication
+   information in the Advertise message returned to the client as
+   specified in section 21.4.  The server MUST record the identifier of
+   the key selected for the client and use that same key for validating
+   subsequent messages with the client.
+
+21.4.5.2. Receiving Request, Confirm, Renew, Rebind or Release Messages
+          and Sending Reply Messages
+
+   The server uses the key identified in the message and validates the
+   message as specified in section 21.4.2.  If the message fails to pass
+   the validation test or the server does not know the key identified by
+   the 'key ID' field, the server MUST discard the message and MAY
+   choose to log the validation failure.
+
+   If the message passes the validation test, the server responds to the
+   specific message as described in section 18.2.  The server MUST
+   include authentication information generated using the key identified
+   in the received message, as specified in section 21.4.
+
+21.5. Reconfigure Key Authentication Protocol
+
+   The Reconfigure key authentication protocol provides protection
+   against misconfiguration of a client caused by a Reconfigure message
+   sent by a malicious DHCP server.  In this protocol, a DHCP server
+   sends a Reconfigure Key to the client in the initial exchange of DHCP
+   messages.  The client records the Reconfigure Key for use in
+   authenticating subsequent Reconfigure messages from that server.  The
+   server then includes an HMAC computed from the Reconfigure Key in
+   subsequent Reconfigure messages.
+
+   Both the Reconfigure Key sent from the server to the client and the
+   HMAC in subsequent Reconfigure messages are carried as the
+   Authentication information in an Authentication option.  The format
+   of the Authentication information is defined in the following
+   section.
+
+   The Reconfigure Key protocol is used (initiated by the server) only
+   if the client and server are not using any other authentication
+   protocol and the client and server have negotiated to use Reconfigure
+   messages.
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 68]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+21.5.1. Use of the Authentication Option in the Reconfigure Key
+        Authentication Protocol
+
+   The following fields are set in an Authentication option for the
+   Reconfigure Key Authentication Protocol:
+
+      protocol    3
+
+      algorithm   1
+
+      RDM         0
+
+   The format of the Authentication information for the Reconfigure Key
+   Authentication Protocol is:
+
+     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      |                 Value (128 bits)              |
+    +-+-+-+-+-+-+-+-+                                               |
+    .                                                               .
+    .                                                               .
+    .                                               +-+-+-+-+-+-+-+-+
+    |                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      Type    Type of data in Value field carried in this option:
+
+                 1   Reconfigure Key value (used in Reply message).
+
+                 2   HMAC-MD5 digest of the message (used in Reconfigure
+                     message).
+
+      Value   Data as defined by field.
+
+21.5.2. Server considerations for Reconfigure Key protocol
+
+   The server selects a Reconfigure Key for a client during the
+   Request/Reply, Solicit/Reply or Information-request/Reply message
+   exchange.  The server records the Reconfigure Key and transmits that
+   key to the client in an Authentication option in the Reply message.
+
+   The Reconfigure Key is 128 bits long, and MUST be a cryptographically
+   strong random or pseudo-random number that cannot easily be
+   predicted.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 69]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   To provide authentication for a Reconfigure message, the server
+   selects a replay detection value according to the RDM selected by the
+   server, and computes an HMAC-MD5 of the Reconfigure message using the
+   Reconfigure Key for the client.  The server computes the HMAC-MD5
+   over the entire DHCP Reconfigure message, including the
+   Authentication option; the HMAC-MD5 field in the Authentication
+   option is set to zero for the HMAC-MD5 computation.  The server
+   includes the HMAC-MD5 in the authentication information field in an
+   Authentication option included in the Reconfigure message sent to the
+   client.
+
+21.5.3. Client considerations for Reconfigure Key protocol
+
+   The client will receive a Reconfigure Key from the server in the
+   initial Reply message from the server.  The client records the
+   Reconfigure Key for use in authenticating subsequent Reconfigure
+   messages.
+
+   To authenticate a Reconfigure message, the client computes an
+   HMAC-MD5 over the DHCP Reconfigure message, using the Reconfigure Key
+   received from the server.  If this computed HMAC-MD5 matches the
+   value in the Authentication option, the client accepts the
+   Reconfigure message.
+
+22. DHCP Options
+
+   Options are used to carry additional information and parameters in
+   DHCP messages.  Every option shares a common base format, as
+   described in section 22.1.  All values in options are represented in
+   network byte order.
+
+   This document describes the DHCP options defined as part of the base
+   DHCP specification.  Other options may be defined in the future in
+   separate documents.
+
+   Unless otherwise noted, each option may appear only in the options
+   area of a DHCP message and may appear only once.  If an option does
+   appear multiple times, each instance is considered separate and the
+   data areas of the options MUST NOT be concatenated or otherwise
+   combined.
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 70]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+22.1. Format of DHCP Options
+
+   The format of DHCP options is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          option-code          |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          option-data                          |
+      |                      (option-len octets)                      |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   An unsigned integer identifying the specific option
+                    type carried in this option.
+
+      option-len    An unsigned integer giving the length of the
+                    option-data field in this option in octets.
+
+      option-data   The data for the option; the format of this data
+                    depends on the definition of the option.
+
+   DHCPv6 options are scoped by using encapsulation.  Some options apply
+   generally to the client, some are specific to an IA, and some are
+   specific to the addresses within an IA.  These latter two cases are
+   discussed in sections 22.4 and 22.6.
+
+22.2. Client Identifier Option
+
+   The Client Identifier option is used to carry a DUID (see section 9)
+   identifying a client between a client and a server.  The format of
+   the Client Identifier option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        OPTION_CLIENTID        |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                              DUID                             .
+      .                        (variable length)                      .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_CLIENTID (1).
+
+      option-len    Length of DUID in octets.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 71]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      DUID          The DUID for the client.
+
+22.3. Server Identifier Option
+
+   The Server Identifier option is used to carry a DUID (see section 9)
+   identifying a server between a client and a server.  The format of
+   the Server Identifier option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        OPTION_SERVERID        |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                              DUID                             .
+      .                        (variable length)                      .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_SERVERID (2).
+
+      option-len    Length of DUID in octets.
+
+      DUID          The DUID for the server.
+
+22.4. Identity Association for Non-temporary Addresses Option
+
+   The Identity Association for Non-temporary Addresses option (IA_NA
+   option) is used to carry an IA_NA, the parameters associated with the
+   IA_NA, and the non-temporary addresses associated with the IA_NA.
+
+   Addresses appearing in an IA_NA option are not temporary addresses
+   (see section 22.5).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 72]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The format of the IA_NA option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          OPTION_IA_NA         |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        IAID (4 octets)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              T1                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              T2                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      .                         IA_NA-options                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_IA_NA (3).
+
+      option-len           12 + length of IA_NA-options field.
+
+      IAID                 The unique identifier for this IA_NA; the
+                           IAID must be unique among the identifiers for
+                           all of this client's IA_NAs.  The number
+                           space for IA_NA IAIDs is separate from the
+                           number space for IA_TA IAIDs.
+
+      T1                   The time at which the client contacts the
+                           server from which the addresses in the IA_NA
+                           were obtained to extend the lifetimes of the
+                           addresses assigned to the IA_NA; T1 is a
+                           time duration relative to the current time
+                           expressed in units of seconds.
+
+      T2                   The time at which the client contacts any
+                           available server to extend the lifetimes of
+                           the addresses assigned to the IA_NA; T2 is a
+                           time duration relative to the current time
+                           expressed in units of seconds.
+
+      IA_NA-options        Options associated with this IA_NA.
+
+   The IA_NA-options field encapsulates those options that are specific
+   to this IA_NA.  For example, all of the IA Address Options carrying
+   the addresses associated with this IA_NA are in the IA_NA-options
+   field.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 73]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   An IA_NA option may only appear in the options area of a DHCP
+   message.  A DHCP message may contain multiple IA_NA options.
+
+   The status of any operations involving this IA_NA is indicated in a
+   Status Code option in the IA_NA-options field.
+
+   Note that an IA_NA has no explicit "lifetime" or "lease length" of
+   its own.  When the valid lifetimes of all of the addresses in an
+   IA_NA have expired, the IA_NA can be considered as having expired.
+   T1 and T2 are included to give servers explicit control over when a
+   client recontacts the server about a specific IA_NA.
+
+   In a message sent by a client to a server, values in the T1 and T2
+   fields indicate the client's preference for those parameters.  The
+   client sets T1 and T2 to 0 if it has no preference for those values.
+   In a message sent by a server to a client, the client MUST use the
+   values in the T1 and T2 fields for the T1 and T2 parameters, unless
+   those values in those fields are 0.  The values in the T1 and T2
+   fields are the number of seconds until T1 and T2.
+
+   The server selects the T1 and T2 times to allow the client to extend
+   the lifetimes of any addresses in the IA_NA before the lifetimes
+   expire, even if the server is unavailable for some short period of
+   time.  Recommended values for T1 and T2 are .5 and .8 times the
+   shortest preferred lifetime of the addresses in the IA that the
+   server is willing to extend, respectively.  If the "shortest"
+   preferred lifetime is 0xffffffff ("infinity"), the recommended T1 and
+   T2 values are also 0xffffffff.  If the time at which the addresses in
+   an IA_NA are to be renewed is to be left to the discretion of the
+   client, the server sets T1 and T2 to 0.
+
+   If a server receives an IA_NA with T1 greater than T2, and both T1
+   and T2 are greater than 0, the server ignores the invalid values of
+   T1 and T2 and processes the IA_NA as though the client had set T1 and
+   T2 to 0.
+
+   If a client receives an IA_NA with T1 greater than T2, and both T1
+   and T2 are greater than 0, the client discards the IA_NA option and
+   processes the remainder of the message as though the server had not
+   included the invalid IA_NA option.
+
+   Care should be taken in setting T1 or T2 to 0xffffffff ("infinity").
+   A client will never attempt to extend the lifetimes of any addresses
+   in an IA with T1 set to 0xffffffff.  A client will never attempt to
+   use a Rebind message to locate a different server to extend the
+   lifetimes of any addresses in an IA with T2 set to 0xffffffff.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 74]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+22.5. Identity Association for Temporary Addresses Option
+
+   The Identity Association for the Temporary Addresses (IA_TA) option
+   is used to carry an IA_TA, the parameters associated with the IA_TA
+   and the addresses associated with the IA_TA.  All of the addresses in
+   this option are used by the client as temporary addresses, as defined
+   in RFC 3041 [12].  The format of the IA_TA option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |         OPTION_IA_TA          |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        IAID (4 octets)                        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      .                         IA_TA-options                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_IA_TA (4).
+
+      option-len           4 + length of IA_TA-options field.
+
+      IAID                 The unique identifier for this IA_TA; the
+                           IAID must be unique among the identifiers
+                           for all of this client's IA_TAs.  The number
+                           space for IA_TA IAIDs is separate from the
+                           number space for IA_NA IAIDs.
+
+      IA_TA-options        Options associated with this IA_TA.
+
+   The IA_TA-Options field encapsulates those options that are specific
+   to this IA_TA.  For example, all of the IA Address Options carrying
+   the addresses associated with this IA_TA are in the IA_TA-options
+   field.
+
+   Each IA_TA carries one "set" of temporary addresses; that is, at most
+   one address from each prefix assigned to the link to which the client
+   is attached.
+
+   An IA_TA option may only appear in the options area of a DHCP
+   message.  A DHCP message may contain multiple IA_TA options.
+
+   The status of any operations involving this IA_TA is indicated in a
+   Status Code option in the IA_TA-options field.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 75]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Note that an IA has no explicit "lifetime" or "lease length" of its
+   own.  When the valid lifetimes of all of the addresses in an IA_TA
+   have expired, the IA can be considered as having expired.
+
+   An IA_TA option does not include values for T1 and T2.  A client MAY
+   request that the lifetimes on temporary addresses be extended by
+   including the addresses in a IA_TA option sent in a Renew or Rebind
+   message to a server.  For example, a client would request an
+   extension on the lifetime of a temporary address to allow an
+   application to continue to use an established TCP connection.
+
+   The client obtains new temporary addresses by sending an IA_TA option
+   with a new IAID to a server.  Requesting new temporary addresses from
+   the server is the equivalent of generating new temporary addresses as
+   described in RFC 3041.  The server will generate new temporary
+   addresses and return them to the client.  The client should request
+   new temporary addresses before the lifetimes on the previously
+   assigned addresses expire.
+
+   A server MUST return the same set of temporary address for the same
+   IA_TA (as identified by the IAID) as long as those addresses are
+   still valid.  After the lifetimes of the addresses in an IA_TA have
+   expired, the IAID may be reused to identify a new IA_TA with new
+   temporary addresses.
+
+   This option MAY appear in a Confirm message if the lifetimes on the
+   temporary addresses in the associated IA have not expired.
+
+22.6. IA Address Option
+
+   The IA Address option is used to specify IPv6 addresses associated
+   with an IA_NA or an IA_TA.  The IA Address option must be
+   encapsulated in the Options field of an IA_NA or IA_TA option.  The
+   Options field encapsulates those options that are specific to this
+   address.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 76]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The format of the IA Address option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          OPTION_IAADDR        |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      |                         IPv6 address                          |
+      |                                                               |
+      |                                                               |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                      preferred-lifetime                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                        valid-lifetime                         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                        IAaddr-options                         .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_IAADDR (5).
+
+      option-len    24 + length of IAaddr-options field.
+
+      IPv6 address  An IPv6 address.
+
+      preferred-lifetime The preferred lifetime for the IPv6 address in
+                    the option, expressed in units of seconds.
+
+      valid-lifetime The valid lifetime for the IPv6 address in the
+                    option, expressed in units of seconds.
+
+      IAaddr-options Options associated with this address.
+
+   In a message sent by a client to a server, values in the preferred
+   and valid lifetime fields indicate the client's preference for those
+   parameters.  The client may send 0 if it has no preference for the
+   preferred and valid lifetimes.  In a message sent by a server to a
+   client, the client MUST use the values in the preferred and valid
+   lifetime fields for the preferred and valid lifetimes.  The values in
+   the preferred and valid lifetimes are the number of seconds remaining
+   in each lifetime.
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 77]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   A client discards any addresses for which the preferred lifetime is
+   greater than the valid lifetime.  A server ignores the lifetimes set
+   by the client if the preferred lifetime is greater than the valid
+   lifetime and ignores the values for T1 and T2 set by the client if
+   those values are greater than the preferred lifetime.
+
+   Care should be taken in setting the valid lifetime of an address to
+   0xffffffff ("infinity"), which amounts to a permanent assignment of
+   an address to a client.
+
+   An IA Address option may appear only in an IA_NA option or an IA_TA
+   option.  More than one IA Address Option can appear in an IA_NA
+   option or an IA_TA option.
+
+   The status of any operations involving this IA Address is indicated
+   in a Status Code option in the IAaddr-options field.
+
+22.7. Option Request Option
+
+   The Option Request option is used to identify a list of options in a
+   message between a client and a server.  The format of the Option
+   Request option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |           OPTION_ORO          |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |    requested-option-code-1    |    requested-option-code-2    |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_ORO (6).
+
+      option-len    2 * number of requested options.
+
+      requested-option-code-n The option code for an option requested by
+                    the client.
+
+   A client MAY include an Option Request option in a Solicit, Request,
+   Renew, Rebind, Confirm or Information-request message to inform the
+   server about options the client wants the server to send to the
+   client.  A server MAY include an Option Request option in a
+   Reconfigure option to indicate which options the client should
+   request from the server.
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 78]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+22.8. Preference Option
+
+   The Preference option is sent by a server to a client to affect the
+   selection of a server by the client.
+
+   The format of the Preference option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       OPTION_PREFERENCE       |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |  pref-value   |
+      +-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_PREFERENCE (7).
+
+      option-len    1.
+
+      pref-value    The preference value for the server in this message.
+
+   A server MAY include a Preference option in an Advertise message to
+   control the selection of a server by the client.  See section 17.1.3
+   for the use of the Preference option by the client and the
+   interpretation of Preference option data value.
+
+22.9. Elapsed Time Option
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      OPTION_ELAPSED_TIME      |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          elapsed-time         |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_ELAPSED_TIME (8).
+
+      option-len    2.
+
+      elapsed-time  The amount of time since the client began its
+                    current DHCP transaction.  This time is expressed in
+                    hundredths of a second (10^-2 seconds).
+
+   A client MUST include an Elapsed Time option in messages to indicate
+   how long the client has been trying to complete a DHCP message
+   exchange.  The elapsed time is measured from the time at which the
+   client sent the first message in the message exchange, and the
+
+
+
+Droms, et al.               Standards Track                    [Page 79]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   elapsed-time field is set to 0 in the first message in the message
+   exchange.  Servers and Relay Agents use the data value in this option
+   as input to policy controlling how a server responds to a client
+   message.  For example, the elapsed time option allows a secondary
+   DHCP server to respond to a request when a primary server has not
+   answered in a reasonable time.  The elapsed time value is an
+   unsigned, 16 bit integer.  The client uses the value 0xffff to
+   represent any elapsed time values greater than the largest time value
+   that can be represented in the Elapsed Time option.
+
+22.10. Relay Message Option
+
+   The Relay Message option carries a DHCP message in a Relay-forward or
+   Relay-reply message.
+
+   The format of the Relay Message option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |        OPTION_RELAY_MSG       |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                                                               |
+      .                       DHCP-relay-message                      .
+      .                                                               .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_RELAY_MSG (9)
+
+      option-len    Length of DHCP-relay-message
+
+      DHCP-relay-message In a Relay-forward message, the received
+                    message, relayed verbatim to the next relay agent
+                    or server; in a Relay-reply message, the message to
+                    be copied and relayed to the relay agent or client
+                    whose address is in the peer-address field of the
+                    Relay-reply message
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 80]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+22.11. Authentication Option
+
+   The Authentication option carries authentication information to
+   authenticate the identity and contents of DHCP messages.  The use of
+   the Authentication option is described in section 21.  The format of
+   the Authentication option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          OPTION_AUTH          |          option-len           |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |   protocol    |   algorithm   |      RDM      |               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+    |                                                               |
+    |          replay detection (64 bits)           +-+-+-+-+-+-+-+-+
+    |                                               |   auth-info   |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
+    .                   authentication information                  .
+    .                       (variable length)                       .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code                  OPTION_AUTH (11)
+
+      option-len                   11 + length of authentication
+                                   information field
+
+      protocol                     The authentication protocol used in
+                                   this authentication option
+
+      algorithm                    The algorithm used in the
+                                   authentication protocol
+
+      RDM                          The replay detection method used in
+                                   this authentication option
+
+      Replay detection             The replay detection information for
+                                   the RDM
+
+      authentication information   The authentication information,
+                                   as specified by the protocol and
+                                   algorithm used in this authentication
+                                   option
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 81]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+22.12. Server Unicast Option
+
+   The server sends this option to a client to indicate to the client
+   that it is allowed to unicast messages to the server.  The format of
+   the Server Unicast option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          OPTION_UNICAST       |        option-len             |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                                                               |
+    |                       server-address                          |
+    |                                                               |
+    |                                                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code     OPTION_UNICAST (12).
+
+      option-len      16.
+
+      server-address  The IP address to which the client should send
+                      messages delivered using unicast.
+
+   The server specifies the IPv6 address to which the client is to send
+   unicast messages in the server-address field.  When a client receives
+   this option, where permissible and appropriate, the client sends
+   messages directly to the server using the IPv6 address specified in
+   the server-address field of the option.
+
+   When the server sends a Unicast option to the client, some messages
+   from the client will not be relayed by Relay Agents, and will not
+   include Relay Agent options from the Relay Agents.  Therefore, a
+   server should only send a Unicast option to a client when Relay
+   Agents are not sending Relay Agent options.  A DHCP server rejects
+   any messages sent inappropriately using unicast to ensure that
+   messages are relayed by Relay Agents when Relay Agent options are in
+   use.
+
+   Details about when the client may send messages to the server using
+   unicast are in section 18.
+
+22.13. Status Code Option
+
+   This option returns a status indication related to the DHCP message
+   or option in which it appears.  The format of the Status Code option
+   is:
+
+
+
+
+Droms, et al.               Standards Track                    [Page 82]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |       OPTION_STATUS_CODE      |         option-len            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |          status-code          |                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
+    .                                                               .
+    .                        status-message                         .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_STATUS_CODE (13).
+
+      option-len           2 + length of status-message.
+
+      status-code          The numeric code for the status encoded in
+                           this option.  The status codes are defined in
+                           section 24.4.
+
+      status-message       A UTF-8 encoded text string suitable for
+                           display to an end user, which MUST NOT be
+                           null-terminated.
+
+   A Status Code option may appear in the options field of a DHCP
+   message and/or in the options field of another option.  If the Status
+   Code option does not appear in a message in which the option could
+   appear, the status of the message is assumed to be Success.
+
+22.14. Rapid Commit Option
+
+   The Rapid Commit option is used to signal the use of the two message
+   exchange for address assignment.  The format of the Rapid Commit
+   option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |      OPTION_RAPID_COMMIT      |               0               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code     OPTION_RAPID_COMMIT (14).
+
+      option-len      0.
+
+   A client MAY include this option in a Solicit message if the client
+   is prepared to perform the Solicit-Reply message exchange described
+   in section 17.1.1.
+
+
+
+Droms, et al.               Standards Track                    [Page 83]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   A server MUST include this option in a Reply message sent in response
+   to a Solicit message when completing the Solicit-Reply message
+   exchange.
+
+   DISCUSSION:
+
+      Each server that responds with a Reply to a Solicit that includes
+      a Rapid Commit option will commit the assigned addresses in the
+      Reply message to the client, and will not receive any confirmation
+      that the client has received the Reply message.  Therefore, if
+      more than one server responds to a Solicit that includes a Rapid
+      Commit option, some servers will commit addresses that are not
+      actually used by the client.
+
+      The problem of unused addresses can be minimized, for example, by
+      designing the DHCP service so that only one server responds to the
+      Solicit or by using relatively short lifetimes for assigned
+      addresses.
+
+22.15. User Class Option
+
+   The User Class option is used by a client to identify the type or
+   category of user or applications it represents.
+
+   The format of the User Class option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |       OPTION_USER_CLASS       |          option-len           |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                          user-class-data                      .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_USER_CLASS (15).
+
+      option-len           Length of user class data field.
+
+      user-class-data      The user classes carried by the client.
+
+   The information contained in the data area of this option is
+   contained in one or more opaque fields that represent the user class
+   or classes of which the client is a member.  A server selects
+   configuration information for the client based on the classes
+   identified in this option.  For example, the User Class option can be
+   used to configure all clients of people in the accounting department
+
+
+
+
+Droms, et al.               Standards Track                    [Page 84]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   with a different printer than clients of people in the marketing
+   department.  The user class information carried in this option MUST
+   be configurable on the client.
+
+   The data area of the user class option MUST contain one or more
+   instances of user class data.  Each instance of the user class data
+   is formatted as follows:
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+      |        user-class-len         |          opaque-data          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
+   The user-class-len is two octets long and specifies the length of the
+   opaque user class data in network byte order.
+
+   A server interprets the classes identified in this option according
+   to its configuration to select the appropriate configuration
+   information for the client.  A server may use only those user classes
+   that it is configured to interpret in selecting configuration
+   information for a client and ignore any other user classes.  In
+   response to a message containing a User Class option, a server
+   includes a User Class option containing those classes that were
+   successfully interpreted by the server, so that the client can be
+   informed of the classes interpreted by the server.
+
+22.16. Vendor Class Option
+
+   This option is used by a client to identify the vendor that
+   manufactured the hardware on which the client is running.  The
+   information contained in the data area of this option is contained in
+   one or more opaque fields that identify details of the hardware
+   configuration.  The format of the Vendor Class option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      OPTION_VENDOR_CLASS      |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       enterprise-number                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                       vendor-class-data                       .
+      .                             . . .                             .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_VENDOR_CLASS (16).
+
+      option-len           4 + length of vendor class data field.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 85]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      enterprise-number    The vendor's registered Enterprise Number as
+                           registered with IANA [6].
+
+      vendor-class-data    The hardware configuration of the host on
+                           which the client is running.
+
+   The vendor-class-data is composed of a series of separate items, each
+   of which describes some characteristic of the client's hardware
+   configuration.  Examples of vendor-class-data instances might include
+   the version of the operating system the client is running or the
+   amount of memory installed on the client.
+
+   Each instance of the vendor-class-data is formatted as follows:
+
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+      |       vendor-class-len        |          opaque-data          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
+
+   The vendor-class-len is two octets long and specifies the length of
+   the opaque vendor class data in network byte order.
+
+22.17. Vendor-specific Information Option
+
+   This option is used by clients and servers to exchange
+   vendor-specific information.
+
+   The format of the Vendor-specific Information option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      OPTION_VENDOR_OPTS       |           option-len          |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                       enterprise-number                       |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                          option-data                          .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_VENDOR_OPTS (17)
+
+      option-len           4 + length of option-data field
+
+      enterprise-number    The vendor's registered Enterprise Number as
+                           registered with IANA [6].
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 86]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      option-data          An opaque object of option-len octets,
+                           interpreted by vendor-specific code on the
+                           clients and servers
+
+   The definition of the information carried in this option is vendor
+   specific.  The vendor is indicated in the enterprise-number field.
+   Use of vendor-specific information allows enhanced operation,
+   utilizing additional features in a vendor's DHCP implementation.  A
+   DHCP client that does not receive requested vendor-specific
+   information will still configure the host device's IPv6 stack to be
+   functional.
+
+   The encapsulated vendor-specific options field MUST be encoded as a
+   sequence of code/length/value fields of identical format to the DHCP
+   options field.  The option codes are defined by the vendor identified
+   in the enterprise-number field and are not managed by IANA.  Each of
+   the encapsulated options is formatted as follows:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |          opt-code             |             option-len        |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      .                                                               .
+      .                          option-data                          .
+      .                                                               .
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      opt-code             The code for the encapsulated option.
+
+      option-len           An unsigned integer giving the length of the
+                           option-data field in this encapsulated option
+                           in octets.
+
+      option-data          The data area for the encapsulated option.
+
+   Multiple instances of the Vendor-specific Information option may
+   appear in a DHCP message.  Each instance of the option is interpreted
+   according to the option codes defined by the vendor identified by the
+   Enterprise Number in that option.
+
+22.18. Interface-Id Option
+
+   The relay agent MAY send the Interface-id option to identify the
+   interface on which the client message was received.  If a relay agent
+   receives a Relay-reply message with an Interface-id option, the relay
+   agent relays the message to the client through the interface
+   identified by the option.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 87]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   The format of the Interface ID option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |      OPTION_INTERFACE_ID      |         option-len            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    .                                                               .
+    .                         interface-id                          .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code          OPTION_INTERFACE_ID (18).
+
+      option-len           Length of interface-id field.
+
+      interface-id         An opaque value of arbitrary length generated
+                           by the relay agent to identify one of the
+                           relay agent's interfaces.
+
+   The server MUST copy the Interface-Id option from the Relay-Forward
+   message into the Relay-Reply message the server sends to the relay
+   agent in response to the Relay-Forward message.  This option MUST NOT
+   appear in any message except a Relay-Forward or Relay-Reply message.
+
+   Servers MAY use the Interface-ID for parameter assignment policies.
+   The Interface-ID SHOULD be considered an opaque value, with policies
+   based on exact match only; that is, the Interface-ID SHOULD NOT be
+   internally parsed by the server.  The Interface-ID value for an
+   interface SHOULD be stable and remain unchanged, for example, after
+   the relay agent is restarted; if the Interface-ID changes, a server
+   will not be able to use it reliably in parameter assignment policies.
+
+22.19. Reconfigure Message Option
+
+   A server includes a Reconfigure Message option in a Reconfigure
+   message to indicate to the client whether the client responds with a
+   Renew message or an Information-request message.  The format of this
+   option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |      OPTION_RECONF_MSG        |         option-len            |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |    msg-type   |
+    +-+-+-+-+-+-+-+-+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 88]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      option-code          OPTION_RECONF_MSG (19).
+
+      option-len           1.
+
+      msg-type             5 for Renew message, 11 for
+                           Information-request message.
+
+   The Reconfigure Message option can only appear in a Reconfigure
+   message.
+
+22.20. Reconfigure Accept Option
+
+   A client uses the Reconfigure Accept option to announce to the server
+   whether the client is willing to accept Reconfigure messages, and a
+   server uses this option to tell the client whether or not to accept
+   Reconfigure messages.  The default behavior, in the absence of this
+   option, means unwillingness to accept Reconfigure messages, or
+   instruction not to accept Reconfigure messages, for the client and
+   server messages, respectively.  The following figure gives the format
+   of the Reconfigure Accept option:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |     OPTION_RECONF_ACCEPT      |               0               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+      option-code   OPTION_RECONF_ACCEPT (20).
+
+      option-len    0.
+
+23. Security Considerations
+
+   The threat to DHCP is inherently an insider threat (assuming a
+   properly configured network where DHCPv6 ports are blocked on the
+   perimeter gateways of the enterprise).  Regardless of the gateway
+   configuration, however, the potential attacks by insiders and
+   outsiders are the same.
+
+   Use of manually configured preshared keys for IPsec between relay
+   agents and servers does not defend against replayed DHCP messages.
+   Replayed messages can represent a DOS attack through exhaustion of
+   processing resources, but not through mis-configuration or exhaustion
+   of other resources such as assignable addresses.
+
+   One attack specific to a DHCP client is the establishment of a
+   malicious server with the intent of providing incorrect configuration
+   information to the client.  The motivation for doing so may be to
+
+
+
+Droms, et al.               Standards Track                    [Page 89]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   mount a "man in the middle" attack that causes the client to
+   communicate with a malicious server instead of a valid server for
+   some service such as DNS or NTP.  The malicious server may also mount
+   a denial of service attack through misconfiguration of the client
+   that causes all network communication from the client to fail.
+
+   There is another threat to DHCP clients from mistakenly or
+   accidentally configured DHCP servers that answer DHCP client requests
+   with unintentionally incorrect configuration parameters.
+
+   A DHCP client may also be subject to attack through the receipt of a
+   Reconfigure message from a malicious server that causes the client to
+   obtain incorrect configuration information from that server.  Note
+   that although a client sends its response (Renew or
+   Information-request message) through a relay agent and, therefore,
+   that response will only be received by servers to which DHCP messages
+   are relayed, a malicious server could send a Reconfigure message to a
+   client, followed (after an appropriate delay) by a Reply message that
+   would be accepted by the client.  Thus, a malicious server that is
+   not on the network path between the client and the server may still
+   be able to mount a Reconfigure attack on a client.  The use of
+   transaction IDs that are cryptographically sound and cannot easily be
+   predicted will also reduce the probability that such an attack will
+   be successful.
+
+   The threat specific to a DHCP server is an invalid client
+   masquerading as a valid client.  The motivation for this may be for
+   theft of service, or to circumvent auditing for any number of
+   nefarious purposes.
+
+   The threat common to both the client and the server is the resource
+   "denial of service" (DoS) attack.  These attacks typically involve
+   the exhaustion of available addresses, or the exhaustion of CPU or
+   network bandwidth, and are present anytime there is a shared
+   resource.
+
+   In the case where relay agents add additional options to Relay
+   Forward messages, the messages exchanged between relay agents and
+   servers may be used to mount a "man in the middle" or denial of
+   service attack.
+
+   This threat model does not consider the privacy of the contents of
+   DHCP messages to be important.  DHCP is not used to exchange
+   authentication or configuration information that must be kept secret
+   from other networks nodes.
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 90]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   DHCP authentication provides for authentication of the identity of
+   DHCP clients and servers, and for the integrity of messages delivered
+   between DHCP clients and servers.  DHCP authentication does not
+   provide any privacy for the contents of DHCP messages.
+
+   The Delayed Authentication protocol described in section 21.4 uses a
+   secret key that is shared between a client and a server.  The use of
+   a "DHCP realm" in the shared key allows identification of
+   administrative domains so that a client can select the appropriate
+   key or keys when roaming between administrative domains.  However,
+   the Delayed Authentication protocol does not define any mechanism for
+   sharing of keys, so a client may require separate keys for each
+   administrative domain it encounters.  The use of shared keys may not
+   scale well and does not provide for repudiation of compromised keys.
+   This protocol is focused on solving the intradomain problem where the
+   out-of-band exchange of a shared key is feasible.
+
+   Because of the opportunity for attack through the Reconfigure
+   message, a DHCP client MUST discard any Reconfigure message that does
+   not include authentication or that does not pass the validation
+   process for the authentication protocol.
+
+   The Reconfigure Key protocol described in section 21.5 provides
+   protection against the use of a Reconfigure message by a malicious
+   DHCP server to mount a denial of service or man-in-the-middle attack
+   on a client.  This protocol can be compromised by an attacker that
+   can intercept the initial message in which the DHCP server sends the
+   key to the client.
+
+   Communication between a server and a relay agent, and communication
+   between relay agents, can be secured through the use of IPSec, as
+   described in section 21.1.  The use of manual configuration and
+   installation of static keys are acceptable in this instance because
+   relay agents and the server will belong to the same administrative
+   domain and the relay agents will require other specific configuration
+   (for example, configuration of the DHCP server address) as well as
+   the IPSec configuration.
+
+24. IANA Considerations
+
+   This document defines several new name spaces associated with DHCPv6
+   and DHCPv6 options:
+
+      -  Message types
+
+      -  Status codes
+
+      -  DUID
+
+
+
+Droms, et al.               Standards Track                    [Page 91]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+      -  Option codes
+
+   IANA has established a registry of values for each of these name
+   spaces, which are described in the remainder of this section.  These
+   name spaces will be managed by the IANA and all will be managed
+   separately from the name spaces defined for DHCPv4.
+
+   New multicast addresses, message types, status codes, and DUID types
+   are assigned via Standards Action [11].
+
+   New DHCP option codes are tentatively assigned after the
+   specification for the associated option, published as an Internet
+   Draft, has received expert review by a designated expert [11].  The
+   final assignment of DHCP option codes is through Standards Action, as
+   defined in RFC 2434 [11].
+
+   This document also references three name spaces in section 21 that
+   are associated with the Authentication Option (section 22.11).  These
+   name spaces are defined by the authentication mechanism for DHCPv4 in
+   RFC 3118 [4].
+
+   The authentication name spaces currently registered by IANA will
+   apply to both DHCPv6 and DHCPv4.  In the future, specifications that
+   define new Protocol, Algorithm and RDM mechanisms will explicitly
+   define whether the new mechanisms are used with DHCPv4, DHCPv6 or
+   both.
+
+24.1. Multicast Addresses
+
+   Section 5.1 defines the following multicast addresses, which have
+   been assigned by IANA for use by DHCPv6:
+
+      All_DHCP_Relay_Agents_and_Servers address:   FF02::1:2
+
+      All_DHCP_Servers address:                    FF05::1:3
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 92]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+24.2. DHCP Message Types
+
+   IANA has recorded the following message types (defined in section
+   5.3).  IANA will maintain the registry of DHCP message types.
+
+      SOLICIT               1
+
+      ADVERTISE             2
+
+      REQUEST               3
+
+      CONFIRM               4
+
+      RENEW                 5
+
+      REBIND                6
+
+      REPLY                 7
+
+      RELEASE               8
+
+      DECLINE               9
+
+      RECONFIGURE           10
+
+      INFORMATION-REQUEST   11
+
+      RELAY-FORW            12
+
+      RELAY-REPL            13
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 93]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+24.3. DHCP Options
+
+   IANA has recorded the following option-codes (as defined in section
+   22).  IANA will maintain the registry of DHCP option codes.
+
+      OPTION_CLIENTID       1
+
+      OPTION_SERVERID       2
+
+      OPTION_IA_NA          3
+
+      OPTION_IA_TA          4
+
+      OPTION_IAADDR         5
+
+      OPTION_ORO            6
+
+      OPTION_PREFERENCE     7
+
+      OPTION_ELAPSED_TIME   8
+
+      OPTION_RELAY_MSG      9
+
+      OPTION_AUTH           11
+
+      OPTION_UNICAST        12
+
+      OPTION_STATUS_CODE    13
+
+      OPTION_RAPID_COMMIT   14
+
+      OPTION_USER_CLASS     15
+
+      OPTION_VENDOR_CLASS   16
+
+      OPTION_VENDOR_OPTS    17
+
+      OPTION_INTERFACE_ID   18
+
+      OPTION_RECONF_MSG     19
+
+      OPTION_RECONF_ACCEPT  20
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 94]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+24.4. Status Codes
+
+   IANA has recorded the status codes defined in the following table.
+   IANA will manage the definition of additional status codes in the
+   future.
+
+   Name         Code Description
+   ----------   ---- -----------
+   Success         0 Success.
+   UnspecFail      1 Failure, reason unspecified; this
+                     status code is sent by either a client
+                     or a server to indicate a failure
+                     not explicitly specified in this
+                     document.
+   NoAddrsAvail    2 Server has no addresses available to assign to
+                     the IA(s).
+   NoBinding       3 Client record (binding) unavailable.
+   NotOnLink       4 The prefix for the address is not appropriate for
+                     the link to which the client is attached.
+   UseMulticast    5 Sent by a server to a client to force the
+                     client to send messages to the server.
+                     using the All_DHCP_Relay_Agents_and_Servers
+                     address.
+
+24.5. DUID
+
+   IANA has recorded the following DUID types (as defined in section
+   9.1).  IANA will manage the definition of additional DUID types in
+   the future.
+
+      DUID-LLT                       1
+
+      DUID-EN                        2
+
+      DUID-LL                        3
+
+25. Acknowledgments
+
+   Thanks to the DHC Working Group and the members of the IETF for their
+   time and input into the specification.  In particular, thanks also
+   for the consistent input, ideas, and review by (in alphabetical
+   order) Bernard Aboba, Bill Arbaugh, Thirumalesh Bhat, Steve Bellovin,
+   A. K. Vijayabhaskar, Brian Carpenter, Matt Crawford, Francis Dupont,
+   Richard Hussong, Kim Kinnear, Fredrik Lindholm, Tony Lindstrom, Josh
+   Littlefield, Gerald Maguire, Jack McCann, Shin Miyakawa, Thomas
+   Narten, Erik Nordmark, Jarno Rajahalme, Yakov Rekhter, Mark Stapp,
+   Matt Thomas, Sue Thomson, Tatuya Jinmei and Phil Wells.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 95]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   Thanks to Steve Deering and Bob Hinden, who have consistently taken
+   the time to discuss the more complex parts of the IPv6
+   specifications.
+
+   And, thanks to Steve Deering for pointing out at IETF 51 in London
+   that the DHCPv6 specification has the highest revision number of any
+   Internet Draft.
+
+26. References
+
+26.1. Normative References
+
+   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [2]  Crawford, M., "Transmission of IPv6 Packets over Ethernet
+        Networks", RFC 2464, December 1998.
+
+   [3]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [4]  Droms, R., Ed. and W. Arbaugh, Ed., "Authentication for DHCP
+        Messages", RFC 3118, June 2001.
+
+   [5]  Hinden, R. and S. Deering, "IP Version 6 Addressing
+        Architecture", RFC 2373, July 1998.
+
+   [6]  IANA.  Private Enterprise Numbers.
+        http://www.iana.org/assignments/enterprise-numbers.html.
+
+   [7]  Kent, S. and R. Atkinson, "Security Architecture for the
+        Internet Protocol", RFC 2401, November 1998.
+
+   [8]  Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
+        for Message Authentication", RFC 2104, February 1997.
+
+   [9]  Mills, D., "Network Time Protocol (Version 3) Specification,
+        Implementation", RFC 1305, March 1992.
+
+   [10] Mockapetris, P., "Domain names - implementation and
+        specification", RFC 1035, November 1987.
+
+   [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+   [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless
+        Address Autoconfiguration in IPv6", RFC 3041, January 2001.
+
+
+
+
+Droms, et al.               Standards Track                    [Page 96]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+   [13] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
+        IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [14] Plummer, D.C., "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.
+
+   [15] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
+        1980.
+
+   [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April
+        1992.
+
+   [17] Thomson, S. and T. Narten, "IPv6 Stateless Address
+        Autoconfiguration", RFC 2462, December 1998.
+
+26.2. Informative References
+
+   [18] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+        Extensions", RFC 2132, March 1997.
+
+   [19] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+        March 1997.
+
+   [20] R. Droms, Ed.  DNS Configuration options for DHCPv6.  April
+        2002.  Work in Progress.
+
+   [21] A. K. Vijayabhaskar.  Time Configuration Options for DHCPv6.
+        May 2002.  Work in Progress.
+
+   [22] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
+        Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April
+        1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 97]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+A. Appearance of Options in Message Types
+
+   The following table indicates with a "*" the options are allowed in
+   each DHCP message type:
+
+           Client Server IA_NA  Option Pref  Time Relay Auth. Server
+             ID     ID   IA_TA  Request            Msg.       Unica.
+   Solicit   *             *      *           *           *
+   Advert.   *      *      *            *                 *
+   Request   *      *      *      *           *           *
+   Confirm   *             *      *           *           *
+   Renew     *      *      *      *           *           *
+   Rebind    *             *      *           *           *
+   Decline   *      *      *      *           *           *
+   Release   *      *      *      *           *           *
+   Reply     *      *      *            *                 *     *
+   Reconf.   *      *             *                       *
+   Inform.   * (see note)         *           *           *
+   R-forw.                                          *     *
+   R-repl.                                          *     *
+
+   NOTE:
+
+      Only included in Information-Request messages that are sent
+      in response to a Reconfigure (see section 19.4.3).
+
+            Status  Rap. User  Vendor Vendor Inter. Recon. Recon.
+             Code  Comm. Class Class  Spec.    ID    Msg.  Accept
+   Solicit           *     *     *      *                    *
+   Advert.    *            *     *      *                    *
+   Request                 *     *      *                    *
+   Confirm                 *     *      *
+   Renew                   *     *      *                    *
+   Rebind                  *     *      *                    *
+   Decline                 *     *      *
+   Release                 *     *      *
+   Reply      *      *     *     *      *                    *
+   Reconf.                                            *
+   Inform.                 *     *      *                    *
+   R-forw.                 *     *      *      *
+   R-repl.                 *     *      *      *
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 98]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+B. Appearance of Options in the Options Field of DHCP Options
+
+   The following table indicates with a "*" where options can appear in
+   the options field of other options:
+
+                Option  IA_NA/ IAADDR Relay  Relay
+                Field   IA_TA         Forw.  Reply
+   Client ID      *
+   Server ID      *
+   IA_NA/IA_TA    *
+   IAADDR                 *
+   ORO            *
+   Preference     *
+   Elapsed Time   *
+   Relay Message                        *      *
+   Authentic.     *
+   Server Uni.    *
+   Status Code    *       *       *
+   Rapid Comm.    *
+   User Class     *
+   Vendor Class   *
+   Vendor Info.   *
+   Interf. ID                           *      *
+   Reconf. MSG.   *
+   Reconf. Accept *
+
+   Note: "Relay Forw" / "Relay Reply" options appear in the options
+   field of the message but may only appear in these messages.
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+   Ralph Droms
+   Cisco Systems
+   1414 Massachusetts Avenue
+   Boxborough, MA 01719
+
+   Phone: (978) 936-1674
+   EMail: rdroms@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                    [Page 99]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+Authors' Addresses
+
+   Jim Bound
+   Hewlett Packard Corporation
+   ZK3-3/W20
+   110 Spit Brook Road
+   Nashua, NH 03062-2698
+   USA
+
+   Phone:  +1 603 884 0062
+   EMail:  Jim.Bound@hp.com
+
+   Bernie Volz
+   116 Hawkins Pond Road
+   Center Harbor, NH  03226-3103
+   USA
+
+   Phone:  +1-508-259-3734
+   EMail:  volz@metrocast.net
+
+   Ted Lemon
+   Nominum, Inc.
+   950 Charter Street
+   Redwood City, CA 94043
+   USA
+
+   EMail:  Ted.Lemon@nominum.com
+
+   Charles E. Perkins
+   Communications Systems Lab
+   Nokia Research Center
+   313 Fairchild Drive
+   Mountain View, California 94043
+   USA
+
+   Phone:  +1-650 625-2986
+   EMail:  charles.perkins@nokia.com
+
+   Mike Carney
+   Sun Microsystems, Inc
+   17 Network Circle
+   Menlo Park, CA 94025
+   USA
+
+   Phone:  +1-650-786-4171
+   EMail:  michael.carney@sun.com
+
+
+
+
+
+Droms, et al.               Standards Track                   [Page 100]
+
+RFC 3315                     DHCP for IPv6                     July 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms, et al.               Standards Track                   [Page 101]
+
diff --git a/rfc/rfc3633.txt b/rfc/rfc3633.txt
new file mode 100644
index 00000000..b262855e
--- /dev/null
+++ b/rfc/rfc3633.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Network Working Group                                           O. Troan
+Request for Comments: 3633                                      R. Droms
+Category: Standards Track                                  Cisco Systems
+                                                           December 2003
+
+
+                        IPv6 Prefix Options for
+          Dynamic Host Configuration Protocol (DHCP) version 6
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   The Prefix Delegation options provide a mechanism for automated
+   delegation of IPv6 prefixes using the Dynamic Host Configuration
+   Protocol (DHCP).  This mechanism is intended for delegating a long-
+   lived prefix from a delegating router to a requesting router, across
+   an administrative boundary, where the delegating router does not
+   require knowledge about the topology of the links in the network to
+   which the prefixes will be assigned.
+
+Table of Contents
+
+   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
+   2.   DHCPv6 specification dependency  . . . . . . . . . . . . . .   3
+   3.   Terminology  . . . . . . . . . . . . . . . . . . . . . . . .   3
+   4.   Requirements . . . . . . . . . . . . . . . . . . . . . . . .   3
+   5.   Model and Applicability  . . . . . . . . . . . . . . . . . .   3
+        5.1.  Example network architecture . . . . . . . . . . . . .   4
+   6.   Identity Association for Prefix Delegation . . . . . . . . .   5
+   7.   Overview of DHCP with Prefix Delegation  . . . . . . . . . .   6
+   8.   Interface Selection  . . . . . . . . . . . . . . . . . . . .   7
+   9.   Identity Association for Prefix Delegation Option  . . . . .   7
+   10.  IA_PD Prefix option  . . . . . . . . . . . . . . . . . . . .   9
+   11.  Delegating Router Solicitation . . . . . . . . . . . . . . .  11
+        11.1. Requesting router behavior . . . . . . . . . . . . . .  11
+        11.2. Delegating router behavior . . . . . . . . . . . . . .  11
+   12.  Requesting router initiated prefix delegation  . . . . . . .  12
+
+
+
+Troan & Droms               Standards Track                     [Page 1]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+        12.1. Requesting router behavior . . . . . . . . . . . . . .  12
+        12.2. Delegating Router behavior . . . . . . . . . . . . . .  14
+   13.  Prefix Delegation reconfiguration  . . . . . . . . . . . . .  15
+        13.1. Delegating Router behavior . . . . . . . . . . . . . .  15
+        13.2. Requesting Router behavior . . . . . . . . . . . . . .  15
+   14.  Relay agent behavior . . . . . . . . . . . . . . . . . . . .  15
+   15.  Security Considerations  . . . . . . . . . . . . . . . . . .  16
+   16.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  16
+   17.  Intellectual Property Statement. . . . . . . . . . . . . . .  17
+   18.  References . . . . . . . . . . . . . . . . . . . . . . . . .  17
+        18.1. Normative References . . . . . . . . . . . . . . . . .  17
+        18.2. Informative References . . . . . . . . . . . . . . . .  17
+   19.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  18
+   20.  Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  18
+   21.  Full Copyright Statement . . . . . . . . . . . . . . . . . .  19
+
+1.  Introduction
+
+   This document describes new options for Dynamic Host Configuration
+   Protocol (DHCP) that provide a mechanism for the delegation of IPv6
+   prefixes [1].  Through these options, a delegating router can
+   delegate prefixes to authorized requesting routers.
+
+   The prefix delegation mechanism described in this document is
+   intended for simple delegation of prefixes from a delegating router
+   to requesting routers.  It is appropriate for situations in which the
+   delegating router does not have knowledge about the topology of the
+   networks to which the requesting router is attached, and the
+   delegating router does not require other information aside from the
+   identity of the requesting router to choose a prefix for delegation.
+   For example, these options would be used by a service provider to
+   assign a prefix to a Customer Premise Equipment (CPE) device acting
+   as a router between the subscriber's internal network and the service
+   provider's core network.
+
+   Many applications expect stable addresses.  Even though this
+   mechanism makes automatic renumbering easier, it is expected that
+   prefixes have a long lifespan.  During renumbering it is expected
+   that the old and the new prefix co-exist for some time.
+
+   The design of this prefix delegation mechanism meets the requirements
+   for prefix delegation in Requirements for IPv6 prefix delegation [6].
+
+   Note that this use of DHCP is not bound to the assignment of IP
+   addresses or other configuration information to hosts, and that no
+   mechanism is currently available to communicate delegated prefixes to
+   a DHCP server that serves such a function.  This may be an item of
+   future work, should usage warrant.
+
+
+
+Troan & Droms               Standards Track                     [Page 2]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+2.  DHCPv6 specification dependency
+
+   This document describes new DHCPv6 options for IPv6 prefix
+   delegation.  This document should be read in conjunction with the
+   DHCPv6 specification, RFC 3315 [2], for a complete specification of
+   the Prefix Delegation options and mechanism.  Definitions for terms
+   and acronyms not specifically defined in this document are defined in
+   RFC 3315.
+
+3.  Terminology
+
+   This document uses the terminology defined in RFC 2460 [1] and RFC
+   3315.  In addition, this document uses the following terms:
+
+   requesting router:  The router that acts as a DHCP client and is
+                       requesting prefix(es) to be assigned.
+
+   delegating router:  The router that acts as a DHCP server, and is
+                       responding to the prefix request.
+
+   Identity Association for Prefix Delegation (IA_PD): A collection of
+                       prefixes assigned to the requesting router.  Each
+                       IA_PD has an associated IAID.  A requesting
+                       router may have more than one IA_PD assigned to
+                       it; for example, one for each of its interfaces.
+
+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 BCP 14, RFC 2119 [3].
+
+5.  Model and Applicability
+
+   The model of operation for prefix delegation is as follows.  A
+   delegating router is provided IPv6 prefixes to be delegated to
+   requesting routers.  Examples of ways in which the delegating router
+   may be provided these prefixes are given in Section 12.2.  A
+   requesting router requests prefix(es) from the delegating router, as
+   described in Section 12.1.  The delegating router chooses prefix(es)
+   for delegation, and responds with prefix(es) to the requesting
+   router.  The requesting router is then responsible for the delegated
+   prefix(es).  For example, the requesting router might assign a subnet
+   from a delegated prefix to one of its interfaces, and begin sending
+   router advertisements for the prefix on that link.
+
+
+
+
+
+
+Troan & Droms               Standards Track                     [Page 3]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   Each prefix has an associated valid and preferred lifetime, which
+   constitutes an agreement about the length of time over which the
+   requesting router is allowed to use the prefix.  A requesting router
+   can request an extension of the lifetimes on a delegated prefix and
+   is required to terminate the use of a delegated prefix if the valid
+   lifetime of the prefix expires.
+
+   This prefix delegation mechanism would be appropriate for use by an
+   ISP to delegate a prefix to a subscriber, where the delegated prefix
+   would possibly be subnetted and assigned to the links within the
+   subscriber's network.
+
+5.1.  Example network architecture
+
+   Figure 1 illustrates a network architecture in which prefix
+   delegation could be used.
+
+                 ______________________                 \
+                /                      \                 \
+               |    ISP core network    |                 \
+                \__________ ___________/                   |
+                           |                               |
+                   +-------+-------+                       |
+                   |  Aggregation  |                       | ISP
+                   |    device     |                       | network
+                   |  (delegating  |                       |
+                   |    router)    |                       |
+                   +-------+-------+                       |
+                           |                              /
+                           |DSL to subscriber            /
+                           |premises                    /
+                           |
+                    +------+------+                     \
+                    |     CPE     |                      \
+                    | (requesting |                       \
+                    |   router)   |                        |
+                    +----+---+----+                        |
+                         |   |                             | Subscriber
+  ---+-------------+-----+- -+-----+-------------+---      | network
+     |             |               |             |         |
++----+-----+ +-----+----+     +----+-----+ +-----+----+    |
+|Subscriber| |Subscriber|     |Subscriber| |Subscriber|   /
+|    PC    | |    PC    |     |    PC    | |    PC    |  /
++----------+ +----------+     +----------+ +----------+ /
+
+   Figure 1: An example of prefix delegation.
+
+
+
+
+
+Troan & Droms               Standards Track                     [Page 4]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   In this example, the delegating router is configured with a set of
+   prefixes to be used for assignment to customers at the time of each
+   customer's first connection to the ISP service.  The prefix
+   delegation process begins when the requesting router requests
+   configuration information through DHCP.  The DHCP messages from the
+   requesting router are received by the delegating router in the
+   aggregation device.  When the delegating router receives the request,
+   it selects an available prefix or prefixes for delegation to the
+   requesting router.  The delegating router then returns the prefix or
+   prefixes to the requesting router.
+
+   The requesting router subnets the delegated prefix and assigns the
+   longer prefixes to links in the subscriber's network.  In a typical
+   scenario based on the network shown in Figure 1, the requesting
+   router subnets a single delegated /48 prefix into /64 prefixes and
+   assigns one /64 prefix to each of the links in the subscriber
+   network.
+
+   The prefix delegation options can be used in conjunction with other
+   DHCP options carrying other configuration information to the
+   requesting router.  The requesting router may, in turn, then provide
+   DHCP service to hosts attached to the internal network.  For example,
+   the requesting router may obtain the addresses of DNS and NTP servers
+   from the ISP delegating router, and then pass that configuration
+   information on to the subscriber hosts through a DHCP server in the
+   requesting router.
+
+6.  Identity Association for Prefix Delegation
+
+   An IA_PD is a construct through which a delegating router and a
+   requesting router can identify, group and manage a set of related
+   IPv6 prefixes.  Each IA_PD consists of an IAID and associated
+   configuration information.  An IA_PD for prefixes is the equivalent
+   of an IA (described in RFC 3315) for addresses.
+
+   An IA_PD is different from an IA, in that it does not need to be
+   associated with exactly one interface.  One IA_PD can be associated
+   with the requesting router, with a set of interfaces or with exactly
+   one interface.  A requesting router must create at least one distinct
+   IA_PD.  It may associate a distinct IA_PD with each of its downstream
+   network interfaces and use that IA_PD to obtain a prefix for that
+   interface from the delegating router.
+
+   The IAID uniquely identifies the IA_PD and must be chosen to be
+   unique among the IA_PD IAIDs on the requesting router.  The IAID is
+   chosen by the requesting router.  For any given use of an IA_PD by
+   the requesting router, the IAID for that IA_PD MUST be consistent
+   across restarts of the requesting router.  The requesting router may
+
+
+
+Troan & Droms               Standards Track                     [Page 5]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   maintain consistency either by storing the IAID in non-volatile
+   storage or by using an algorithm that will consistently produce the
+   same IAID as long as the configuration of the requesting router has
+   not changed.  If the requesting router uses only one IAID, it can use
+   a well-known value, e.g., zero.
+
+   The configuration information in an IA_PD consists of one or more
+   IPv6 prefixes along with the times T1 and T2 for the IA_PD.  See
+   section 9 for the representation of an IA_PD in a DHCP message.
+
+7.  Overview of DHCP with Prefix Delegation
+
+   Prefix delegation with DHCP is independent of address assignment with
+   DHCP.  A requesting router can use DHCP for just prefix delegation or
+   for prefix delegation along with address assignment and other
+   configuration information.
+
+   A requesting router first creates an IA_PD and assigns it an IAID.
+   The requesting router then transmits a Solicit message containing an
+   IA_PD option describing the IA_PD.  Delegating routers that can
+   delegate prefixes to the IA_PD respond to the requesting router with
+   an Advertise message.
+
+   The requesting router may include prefixes in the IA_PDs as a hint to
+   the delegating router about specific prefixes for which the
+   requesting router has a preference.
+
+   When the requesting router has identified a delegating router, the
+   requesting router uses a Request message to populate the IA_PDs with
+   prefixes.  The requesting router includes one or more IA_PD options
+   in the Request message.  The delegating router returns prefixes and
+   other information about the IA_PDs to the requesting router in IA_PD
+   options in a Reply message.  The requesting router records the
+   lifetimes for the delegated prefix(es) and uses the prefix(es) as
+   described in the previous section.
+
+   Before the valid lifetime on each delegated prefix expires, the
+   requesting router includes the prefix in an IA_PD option sent in a
+   Renew message to the delegating router.  The delegating router
+   responds by returning the prefix with updated lifetimes to the
+   requesting router.
+
+
+
+
+
+
+
+
+
+
+Troan & Droms               Standards Track                     [Page 6]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+8.  Interface Selection
+
+   Delegated prefixes are not associated with a particular interface in
+   the same way as addresses are for address assignment, and the rules
+   described in section 16, "Client Source Address and Interface
+   Selection" of RFC 3315 do not apply.
+
+   When a requesting router sends a DHCP message, it SHOULD be sent on
+   the interface associated with the upstream router (ISP network).  The
+   upstream interface is typically determined by configuration.  This
+   rule applies even in the case where a separate IA_PD is used for each
+   downstream interface.
+
+   When a requesting router sends a DHCP message directly to a
+   delegating router using unicast (after receiving the Server Unicast
+   option from that delegating router), the source address SHOULD be an
+   address from the upstream interface and which is suitable for use by
+   the delegating router in responding to the requesting router.
+
+9.  Identity Association for Prefix Delegation Option
+
+   The IA_PD option is used to carry a prefix delegation identity
+   association, the parameters associated with the IA_PD and the
+   prefixes associated with it.
+
+   The format of the IA_PD option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |         OPTION_IA_PD          |         option-length         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                         IAID (4 octets)                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                              T1                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                              T2                               |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    .                                                               .
+    .                          IA_PD-options                        .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code:      OPTION_IA_PD (25)
+
+   option-length:    12 + length of IA_PD-options field.
+
+
+
+
+
+Troan & Droms               Standards Track                     [Page 7]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   IAID:             The unique identifier for this IA_PD; the IAID must
+                     be unique among the identifiers for all of this
+                     requesting router's IA_PDs.
+
+   T1:               The time at which the requesting router should
+                     contact the delegating router from which the
+                     prefixes in the IA_PD were obtained to extend the
+                     lifetimes of the prefixes delegated to the IA_PD;
+                     T1 is a time duration relative to the current time
+                     expressed in units of seconds.
+
+   T2:               The time at which the requesting router should
+                     contact any available delegating router to extend
+                     the lifetimes of the prefixes assigned to the
+                     IA_PD; T2 is a time duration relative to the
+                     current time expressed in units of seconds.
+
+   IA_PD-options:    Options associated with this IA_PD.
+
+   The IA_PD-options field encapsulates those options that are specific
+   to this IA_PD.  For example, all of the IA_PD Prefix Options carrying
+   the prefixes associated with this IA_PD are in the IA_PD-options
+   field.
+
+   An IA_PD option may only appear in the options area of a DHCP
+   message.  A DHCP message may contain multiple IA_PD options.
+
+   The status of any operations involving this IA_PD is indicated in a
+   Status Code option in the IA_PD-options field.
+
+   Note that an IA_PD has no explicit "lifetime" or "lease length" of
+   its own.  When the valid lifetimes of all of the prefixes in a IA_PD
+   have expired, the IA_PD can be considered as having expired.  T1 and
+   T2 are included to give delegating routers explicit control over when
+   a requesting router should contact the delegating router about a
+   specific IA_PD.
+
+   In a message sent by a requesting router to a delegating router,
+   values in the T1 and T2 fields indicate the requesting router's
+   preference for those parameters.  The requesting router sets T1 and
+   T2 to zero if it has no preference for those values.  In a message
+   sent by a delegating router to a requesting router, the requesting
+   router MUST use the values in the T1 and T2 fields for the T1 and T2
+   parameters.  The values in the T1 and T2 fields are the number of
+   seconds until T1 and T2.
+
+   The delegating router selects the T1 and T2 times to allow the
+   requesting router to extend the lifetimes of any prefixes in the
+
+
+
+Troan & Droms               Standards Track                     [Page 8]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   IA_PD before the lifetimes expire, even if the delegating router is
+   unavailable for some short period of time.  Recommended values for T1
+   and T2 are .5 and .8 times the shortest preferred lifetime of the
+   prefixes in the IA_PD that the delegating router is willing to
+   extend, respectively.  If the time at which the prefixes in an IA_PD
+   are to be renewed is to be left to the discretion of the requesting
+   router, the delegating router sets T1 and T2 to 0.
+
+   If a delegating router receives an IA_PD with T1 greater than T2, and
+   both T1 and T2 are greater than 0, the delegating router ignores the
+   invalid values of T1 and T2 and processes the IA_PD as though the
+   delegating router had set T1 and T2 to 0.
+
+   If a requesting router receives an IA_PD with T1 greater than T2, and
+   both T1 and T2 are greater than 0, the client discards the IA_PD
+   option and processes the remainder of the message as though the
+   delegating router had not included the IA_PD option.
+
+10.  IA_PD Prefix option
+
+   The IA_PD Prefix option is used to specify IPv6 address prefixes
+   associated with an IA_PD.  The IA_PD Prefix option must be
+   encapsulated in the IA_PD-options field of an IA_PD option.
+
+   The format of the IA_PD Prefix option is:
+
+     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
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |        OPTION_IAPREFIX        |         option-length         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                      preferred-lifetime                       |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |                        valid-lifetime                         |
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    | prefix-length |                                               |
+    +-+-+-+-+-+-+-+-+          IPv6 prefix                          |
+    |                           (16 octets)                         |
+    |                                                               |
+    |                                                               |
+    |                                                               |
+    |               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+    |               |                                               .
+    +-+-+-+-+-+-+-+-+                                               .
+    .                       IAprefix-options                        .
+    .                                                               .
+    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+
+
+
+Troan & Droms               Standards Track                     [Page 9]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   option-code:      OPTION_IAPREFIX (26)
+
+   option-length:    25 + length of IAprefix-options field
+
+   preferred-lifetime: The recommended preferred lifetime for the IPv6
+                     prefix in the option, expressed in units of
+                     seconds.  A value of 0xFFFFFFFF represents
+                     infinity.
+
+   valid-lifetime:   The valid lifetime for the IPv6 prefix in the
+                     option, expressed in units of seconds.  A value of
+                     0xFFFFFFFF represents infinity.
+
+   prefix-length:    Length for this prefix in bits
+
+   IPv6-prefix:      An IPv6 prefix
+
+   IAprefix-options: Options associated with this prefix
+
+   In a message sent by a requesting router to a delegating router, the
+   values in the fields can be used to indicate the requesting router's
+   preference for those values.  The requesting router may send a value
+   of zero to indicate no preference.  A requesting router may set the
+   IPv6 prefix field to zero and a given value in the prefix-length
+   field to indicate a preference for the size of the prefix to be
+   delegated.
+
+   In a message sent by a delegating router the preferred and valid
+   lifetimes should be set to the values of AdvPreferredLifetime and
+   AdvValidLifetime as specified in section 6.2.1, "Router Configuration
+   Variables" of RFC 2461 [4], unless administratively configured.
+
+   A requesting router discards any prefixes for which the preferred
+   lifetime is greater than the valid lifetime.  A delegating router
+   ignores the lifetimes set by the requesting router if the preferred
+   lifetime is greater than the valid lifetime and ignores the values
+   for T1 and T2 set by the requesting router if those values are
+   greater than the preferred lifetime.
+
+   The values in the preferred and valid lifetimes are the number of
+   seconds remaining for each lifetime.
+
+   An IA_PD Prefix option may appear only in an IA_PD option.  More than
+   one IA_PD Prefix Option can appear in a single IA_PD option.
+
+   The status of any operations involving this IA_PD Prefix option is
+   indicated in a Status Code option in the IAprefix-options field.
+
+
+
+
+Troan & Droms               Standards Track                    [Page 10]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+11.  Delegating Router Solicitation
+
+   The requesting router locates and selects a delegating router in the
+   same way as described in section 17, "DHCP Server Solicitation" of
+   RFC 3315.  The details of the solicitation process are described in
+   this section.
+
+11.1.  Requesting router behavior
+
+   The requesting router creates and transmits a Solicit message as
+   described in sections 17.1.1, "Creation of Solicit Messages" and
+   17.1.2, "Transmission of Solicit Messages" of RFC 3315.  The
+   requesting router creates an IA_PD and assigns it an IAID.  The
+   requesting router MUST include the IA_PD option in the Solicit
+   message.
+
+   The requesting router processes any received Advertise messages as
+   described in section 17.1.3, "Receipt of Advertise Messages" of RFC
+   3315.  The requesting router MAY choose to consider the presence of
+   advertised prefixes in its decision about which delegating router to
+   respond to.
+
+   The requesting router MUST ignore any Advertise message that includes
+   a Status Code option containing the value NoPrefixAvail, with the
+   exception that the requesting router MAY display the associated
+   status message to the user.
+
+11.2.  Delegating router behavior
+
+   The delegating router sends an Advertise message to the requesting
+   router in the same way as described in section 17.2.2, "Creation and
+   transmission of Advertise messages" of RFC 3315.  If the message
+   contains an IA_PD option and the delegating router is configured to
+   delegate prefix(es) to the requesting router, the delegating router
+   selects the prefix(es) to be delegated to the requesting router.  The
+   mechanism through which the delegating router selects prefix(es) for
+   delegation is not specified in this document.  Examples of ways in
+   which the delegating router might select prefix(es) for a requesting
+   router include: static assignment based on subscription to an ISP;
+   dynamic assignment from a pool of available prefixes; selection based
+   on an external authority such as a RADIUS server using the Framed-
+   IPv6-Prefix option as described in RFC 3162 [5].
+
+   If the requesting router includes an IA_PD Prefix option in the IA_PD
+   option in its Solicit message, the delegating router MAY choose to
+   use the information in that option to select the prefix(es) or prefix
+   size to be delegated to the requesting router.
+
+
+
+
+Troan & Droms               Standards Track                    [Page 11]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   The delegating router sends an Advertise message to the requesting
+   router in the same way as described in section, "Creation and
+   transmission of Advertise messages" of RFC 3315.  The delegating
+   router MUST include an IA_PD option, identifying any prefix(es) that
+   the delegating router will delegate to the requesting router.
+
+   If the delegating router will not assign any prefixes to any IA_PDs
+   in a subsequent Request from the requesting router, the delegating
+   router MUST send an Advertise message to the requesting router that
+   includes the IA_PD with no prefixes in the IA_PD and a Status Code
+   option in the IA_PD containing status code NoPrefixAvail and a status
+   message for the user, a Server Identifier option with the delegating
+   router's DUID and a Client Identifier option with the requesting
+   router's DUID.
+
+12.  Requesting router initiated prefix delegation
+
+   A requesting router uses the same message exchanges as described in
+   section 18, "DHCP Client-Initiated Configuration Exchange" of RFC
+   3315 to obtain or update prefix(es) from a delegating router.  The
+   requesting router and the delegating router use the IA_PD Prefix
+   option to exchange information about prefix(es) in much the same way
+   IA Address options are used for assigned addresses.
+
+12.1.  Requesting router behavior
+
+   The requesting router uses a Request message to populate IA_PDs with
+   prefixes.  The requesting router includes one or more IA_PD options
+   in the Request message.  The delegating router then returns the
+   prefixes for the IA_PDs to the requesting router in IA_PD options in
+   a Reply message.
+
+   The requesting router includes IA_PD options in any Renew, or Rebind
+   messages sent by the requesting router.  The IA_PD option includes
+   all of the prefixes the requesting router currently has associated
+   with that IA_PD.
+
+   In some circumstances the requesting router may need verification
+   that the delegating router still has a valid binding for the
+   requesting router.  Examples of times when a requesting router may
+   ask for such verification include:
+
+   o  The requesting router reboots.
+
+   o  The requesting router's upstream link flaps.
+
+   o  The requesting router is physically disconnected from a wired
+      connection.
+
+
+
+Troan & Droms               Standards Track                    [Page 12]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   If such verification is needed the requesting router MUST initiate a
+   Rebind/Reply message exchange as described in section 18.1.4,
+   "Creation and Transmission of Rebind Messages" of RFC 3315, with the
+   exception that the retransmission parameters should be set as for the
+   Confirm message, described in section 18.1.2, "Creation and
+   Transmission of Confirm Messages" of RFC 3315.  The requesting router
+   includes any IA_PDs, along with prefixes associated with those IA_PDs
+   in its Rebind message.
+
+   Each prefix has valid and preferred lifetimes whose durations are
+   specified in the IA_PD Prefix option for that prefix.  The requesting
+   router uses Renew and Rebind messages to request the extension of the
+   lifetimes of a delegated prefix.
+
+   The requesting router uses a Release message to return a delegated
+   prefix to a delegating router.  The prefixes to be released MUST be
+   included in the IA_PDs.
+
+   The Confirm and Decline message types are not used with Prefix
+   Delegation.
+
+   Upon the receipt of a valid Reply message, for each IA_PD the
+   requesting router assigns a subnet from each of the delegated
+   prefixes to each of the links to which the associated interfaces are
+   attached, with the following exception: the requesting router MUST
+   NOT assign any delegated prefixes or subnets from the delegated
+   prefix(es) to the link through which it received the DHCP message
+   from the delegating router.
+
+   When a requesting router subnets a delegated prefix, it must assign
+   additional bits to the prefix to generate unique, longer prefixes.
+   For example, if the requesting router in Figure 1 were delegated
+   3FFE:FFFF:0::/48, it might generate 3FFE:FFFF:0:1::/64 and
+   3FFE:FFFF:0:2::/64 for assignment to the two links in the subscriber
+   network.  If the requesting router were delegated 3FFE:FFFF:0::/48
+   and 3FFE:FFFF:5::/48, it might assign 3FFE:FFFF:0:1::/64 and
+   3FFE:FFFF:5:1::/64 to one of the links, and 3FFE:FFFF:0:2::/64 and
+   3FFE:FFFF:5:2::/64 for assignment to the other link.
+
+   If the requesting router assigns a delegated prefix to a link to
+   which the router is attached, and begins to send router
+   advertisements for the prefix on the link, the requesting router MUST
+   set the valid lifetime in those advertisements to be no later than
+   the valid lifetime specified in the IA_PD Prefix option.  A
+   requesting router MAY use the preferred lifetime specified in the
+   IA_PD Prefix option.
+
+
+
+
+
+Troan & Droms               Standards Track                    [Page 13]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+   Handling of Status Codes options in received Reply messages is
+   described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315.
+   The NoPrefixAvail Status Code is handled in the same manner as the
+   NoAddrsAvail Status Code.
+
+12.2.  Delegating Router behavior
+
+   When a delegating router receives a Request message from a requesting
+   router that contains an IA_PD option, and the delegating router is
+   authorized to delegate prefix(es) to the requesting router, the
+   delegating router selects the prefix(es) to be delegated to the
+   requesting router.  The mechanism through which the delegating router
+   selects prefix(es) for delegation is not specified in this document.
+   Section 11.2 gives examples of ways in which a delegating router
+   might select the prefix(es) to be delegated to a requesting router.
+
+   A delegating router examines the prefix(es) identified in IA_PD
+   Prefix options (in an IA_PD option) in Renew and Rebind messages and
+   responds according to the current status of the prefix(es).  The
+   delegating router returns IA_PD Prefix options (within an IA_PD
+   option) with updated lifetimes for each valid prefix in the message
+   from the requesting router.  If the delegating router finds that any
+   of the prefixes are not in the requesting router's binding entry, the
+   delegating router returns the prefix to the requesting router with
+   lifetimes of 0.
+
+   The delegating router behaves as follows when it cannot find a
+   binding for the requesting router's IA_PD:
+
+   Renew message:      If the delegating router cannot find a binding
+                       for the requesting router's IA_PD the delegating
+                       router returns the IA_PD containing no prefixes
+                       with a Status Code option set to NoBinding in the
+                       Reply message.
+
+   Rebind message:     If the delegating router cannot find a binding
+                       for the requesting router's IA_PD and the
+                       delegating router determines that the prefixes in
+                       the IA_PD are not appropriate for the link to
+                       which the requesting router's interface is
+                       attached according to the delegating routers
+                       explicit configuration, the delegating router MAY
+                       send a Reply message to the requesting router
+                       containing the IA_PD with the lifetimes of the
+                       prefixes in the IA_PD set to zero.  This Reply
+                       constitutes an explicit notification to the
+                       requesting router that the prefixes in the IA_PD
+                       are no longer valid.  If the delegating router is
+
+
+
+Troan & Droms               Standards Track                    [Page 14]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+                       unable to determine if the prefix is not
+                       appropriate for the link, the Rebind message is
+                       discarded.
+
+   A delegating router may mark any prefix(es) in IA_PD Prefix options
+   in a Release message from a requesting router as "available",
+   dependent on the mechanism used to acquire the prefix, e.g., in the
+   case of a dynamic pool.
+
+   The delegating router MUST include an IA_PD Prefix option or options
+   (in an IA_PD option) in Reply messages sent to a requesting router.
+
+13.  Prefix Delegation reconfiguration
+
+   This section describes prefix delegation in Reconfigure message
+   exchanges.
+
+13.1.  Delegating Router behavior
+
+   The delegating router initiates a configuration message exchange with
+   a requesting router, as described in section 19, "DHCP Server-
+   Initiated Configuration Exchange" of RFC 3315, by sending a
+   Reconfigure message (acting as a DHCP server) to the requesting
+   router, as described in section 19.1, "Server Behavior" of RFC 3315.
+   The delegating router specifies the IA_PD option in the Option
+   Request option to cause the requesting router to include an IA_PD
+   option to obtain new information about delegated prefix(es).
+
+13.2.  Requesting Router behavior
+
+   The requesting router responds to a Reconfigure message, acting as a
+   DHCP client, received from a delegating router as described in
+   section 19.4, "Client Behavior" of RFC 3315.  The requesting router
+   MUST include the IA_PD Prefix option(s) (in an IA_PD option) for
+   prefix(es) that have been delegated to the requesting router by the
+   delegating router from which the Reconfigure message was received.
+
+14.  Relay agent behavior
+
+   A relay agent forwards messages containing Prefix Delegation options
+   in the same way as described in section 20, "Relay Agent Behavior" of
+   RFC 3315.
+
+   If a delegating router communicates with a requesting router through
+   a relay agent, the delegating router may need a protocol or other
+   out-of-band communication to add routing information for delegated
+   prefixes into the provider edge router.
+
+
+
+
+Troan & Droms               Standards Track                    [Page 15]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+15.  Security Considerations
+
+   Security considerations in DHCP are described in section 23,
+   "Security Considerations" of RFC 3315.
+
+   A rogue delegating router can issue bogus prefixes to a requesting
+   router.  This may cause denial of service due to unreachability.
+
+   A malicious requesting router may be able to mount a denial of
+   service attack by repeated requests for delegated prefixes that
+   exhaust the delegating router's available prefixes.
+
+   To guard against attacks through prefix delegation, requesting
+   routers and delegating routers SHOULD use DHCP authentication as
+   described in section 21, "Authentication of DHCP messages" of RFC
+   3315.  For point to point links, where one trusts that there is no
+   man in the middle, or one trusts layer two authentication, DHCP
+   authentication or IPsec may not be necessary.  Because a requesting
+   router and delegating routers must each have at least one assigned
+   IPv6 address, the routers may be able to use IPsec for authentication
+   of DHCPv6 messages.  The details of using IPsec for DHCPv6 are under
+   development.
+
+   Networks configured with delegated prefixes should be configured to
+   preclude intentional or inadvertent inappropriate advertisement of
+   these prefixes.
+
+16.  IANA Considerations
+
+   IANA has assigned option codes to:
+
+   OPTION_IA_PD (25)
+
+   OPTION_IAPREFIX (26)
+
+   from the option-code space as defined in section 24.3, "DHCP Options"
+   of RFC 3315.
+
+   IANA has assigned status code 6 to:
+
+   NoPrefixAvail:      Delegating router has no prefixes available to
+                       assign to the IAPD(s)
+
+   from the status-code space as defined in section 24.4, "Status Codes"
+   of RFC 3315.
+
+
+
+
+
+
+Troan & Droms               Standards Track                    [Page 16]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+17.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+18.  References
+
+18.1.  Normative References
+
+   [1]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
+        Specification", RFC 2460, December 1998.
+
+   [2]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M.
+        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+        RFC 3315, July 2003.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
+        IP Version 6 (IPv6)", RFC 2461, December 1998.
+
+   [5]  Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162,
+        August 2001.
+
+18.2.  Informative References
+
+   [6]  Miyakawa, S. and R. Droms, "Requirements for IPv6 prefix
+        delegation", Work in Progress, August 2003.
+
+
+
+
+
+Troan & Droms               Standards Track                    [Page 17]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+19.  Acknowledgements
+
+   Thanks for the input and review by (in alphabetical order) Steve
+   Deering, Dave Forster, Brian Haberman, Tatuya Jinmei, Shin Miyakawa,
+   Pekka Savola, Bernie Volz, Trevor Warwick and Toshi Yamasaki.
+
+20.  Authors' Addresses
+
+   Ole Troan
+   Cisco Systems
+   250 Longwater Avenue
+   Reading  RG2 6GB
+   United Kingdom
+
+   Phone: +44 20 8824 8666
+   EMail: ot@cisco.com
+
+
+   Ralph Droms
+   Cisco Systems
+   1414 Massachusetts Avenue
+   Boxborough, MA  01719
+   USA
+
+   Phone: +1 978 936 1674
+   EMail: rdroms@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troan & Droms               Standards Track                    [Page 18]
+
+RFC 3633             IPv6 Prefix Options for DHCPv6        December 2003
+
+
+21.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Troan & Droms               Standards Track                    [Page 19]
+
diff --git a/rfc/rfc3646.txt b/rfc/rfc3646.txt
new file mode 100644
index 00000000..42dbd676
--- /dev/null
+++ b/rfc/rfc3646.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                      R. Droms, Ed.
+Request for Comments: 3646                                 Cisco Systems
+Category: Standards Track                                  December 2003
+
+
+              DNS Configuration options for Dynamic Host
+                Configuration Protocol for IPv6 (DHCPv6)
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes Dynamic Host Configuration Protocol for IPv6
+   (DHCPv6) options for passing a list of available DNS recursive name
+   servers and a domain search list to a client.
+
+1.  Introduction
+
+   This document describes two options for passing configuration
+   information related to Domain Name Service (DNS) (RFC 1034 [6] and
+   RFC 1035 [1]) in DHCPv6 (RFC 3315 [2]).
+
+2.  Terminology
+
+   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
+   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be
+   interpreted as described in BCP 14, RFC 2119 [3].
+
+   Throughout this document, unless otherwise specified, the acronym
+   DHCP refers to DHCP for IPv6 (DHCPv6) as specified in RFC 3315.
+
+   This document uses terminology specific to IPv6 and DHCP as defined
+   in section "Terminology" of RFC 3315.
+
+
+
+
+
+
+
+
+Droms                       Standards Track                     [Page 1]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+3.  DNS Recursive Name Server option
+
+   The DNS Recursive Name Server option provides a list of one or more
+   IPv6 addresses of DNS recursive name servers to which a client's DNS
+   resolver MAY send DNS queries [1].  The DNS servers are listed in the
+   order of preference for use by the client resolver.
+
+   The format of the DNS Recursive Name Server option is:
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |      OPTION_DNS_SERVERS       |         option-len            |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |            DNS-recursive-name-server (IPv6 address)           |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                                                               |
+   |            DNS-recursive-name-server (IPv6 address)           |
+   |                                                               |
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |                              ...                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code:               OPTION_DNS_SERVERS (23)
+
+   option-len:                Length of the list of DNS recursive name
+                              servers in octets; must be a multiple of
+                              16
+
+   DNS-recursive-name-server: IPv6 address of DNS recursive name server
+
+4.  Domain Search List option
+
+   The Domain Search List option specifies the domain search list the
+   client is to use when resolving hostnames with DNS.  This option does
+   not apply to other name resolution mechanisms.
+
+
+
+
+
+
+
+
+
+
+
+Droms                       Standards Track                     [Page 2]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+   The format of the Domain Search List option is:
+
+       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
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |      OPTION_DOMAIN_LIST       |         option-len            |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+      |                          searchlist                           |
+      |                              ...                              |
+      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+   option-code:  OPTION_DOMAIN_LIST (24)
+
+   option-len:   Length of the 'searchlist' field in octets
+
+   searchlist:   The specification of the list of domain names in the
+                 Domain Search List
+
+   The list of domain names in the 'searchlist' MUST be encoded as
+   specified in section "Representation and use of domain names" of RFC
+   3315.
+
+5.  Appearance of these options
+
+   The DNS Recursive Name Server option MUST NOT appear in any other
+   than the following messages: Solicit, Advertise, Request, Renew,
+   Rebind, Information-Request, and Reply.
+
+   The Domain Search List option MUST NOT appear in any other than the
+   following messages: Solicit, Advertise, Request, Renew, Rebind,
+   Information-Request, and Reply.
+
+6.  Security Considerations
+
+   The DNS Recursive Name Server option may be used by an intruder DHCP
+   server to cause DHCP clients to send DNS queries to an intruder DNS
+   recursive name server.  The results of these misdirected DNS queries
+   may be used to spoof DNS names.
+
+   To avoid attacks through the DNS Recursive Name Server option, the
+   DHCP client SHOULD require DHCP authentication (see section
+   "Authentication of DHCP messages" in RFC 3315) before installing a
+   list of DNS recursive name servers obtained through authenticated
+   DHCP.
+
+   The Domain Search List option may be used by an intruder DHCP server
+   to cause DHCP clients to search through invalid domains for
+   incompletely specified domain names.  The results of these
+
+
+
+Droms                       Standards Track                     [Page 3]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+   misdirected searches may be used to spoof DNS names.  Note that
+   support for DNSSEC [4] will not avert this attack, because the
+   resource records in the invalid domains may be legitimately signed.
+
+   The degree to which a host is vulnerable to attack via an invalid
+   domain search option is determined in part by DNS resolver behavior.
+   RFC1535 [7] contains a discussion of security weaknesses related to
+   implicit as well as explicit domain searchlists, and provides
+   recommendations relating to resolver searchlist processing.  Section
+   6 of RFC1536 [5] also addresses this vulnerability, and recommends
+   that resolvers:
+
+   1. Use searchlists only when explicitly specified; no implicit
+      searchlists should be used.
+
+   2. Resolve a name that contains any dots by first trying it as an
+      FQDN and if that fails, with the names in the searchlist appended.
+
+   3. Resolve a name containing no dots by appending with the searchlist
+      right away, but once again, no implicit searchlists should be
+      used.
+
+   In order to minimize potential vulnerabilities it is recommended
+   that:
+
+   1. Hosts implementing the domain search option SHOULD also implement
+      the searchlist recommendations of RFC1536, section 6.
+
+   2. Where DNS parameters such as the domain searchlist or DNS servers
+      have been manually configured, these parameters SHOULD NOT be
+      overridden by DHCP.
+
+   3. A host SHOULD require the use of DHCP authentication (see section
+      "Authentication of DHCP messages" in RFC 3315) prior to accepting
+      a domain search option.
+
+7.  IANA Considerations
+
+   IANA has assigned an option code to the DNS Recursive Name Server
+   option (23) and to the Domain Search List option (24) from the DHCP
+   option code space defined in section "IANA Considerations" of RFC
+   3315.
+
+8.  Acknowledgements
+
+   This option was originally part of the DHCPv6 specification, written
+   by Jim Bound, Mike Carney, Charlie Perkins, Ted Lemon, Bernie Volz
+   and Ralph Droms.
+
+
+
+Droms                       Standards Track                     [Page 4]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+   The analysis of the potential attack through the domain search list
+   is taken from the specification of the DHCPv4 Domain Search option,
+   RFC3397 [8].
+
+   Thanks to Rob Austein, Alain Durand, Peter Koch, Tony Lindstrom and
+   Pekka Savola for their contributions to this document.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Mockapetris, P., "Domain names - implementation and
+        specification", STD 13, RFC 1035, November 1987.
+
+   [2]  Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R.
+        Droms (ed.), "Dynamic Host Configuration Protocol for IPv6
+        (DHCPv6)", RFC 3315, May 2003.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [4]  Eastlake, D., "Domain Name System Security Extensions", RFC
+        2535, March 1999.
+
+   [5]  Kumar, A., Postel, J., Neuman, C., Danzig, P. and S. Miller,
+        "Common DNS Implementation Errors and Suggested Fixes", RFC
+        1536, October 1993.
+
+9.2.  Informative References
+
+   [6]  Mockapetris, P., "Domain names - concepts and facilities", STD
+        13, RFC 1034, November 1987.
+
+   [7]  Gavron, E., "A Security Problem and Proposed Correction With
+        Widely Deployed DNS Software", RFC 1535, October 1993.
+
+   [8]  Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol
+        (DHCP) Domain Search Option", RFC 3397, November 2002.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                       Standards Track                     [Page 5]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property 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; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication 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 implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+Author's Address
+
+   Ralph Droms, Editor
+   Cisco Systems
+   1414 Massachusetts Ave.
+   Boxboro, MA  01719
+   USA
+
+   Phone: +1 978 936 1674
+   EMail: rdroms@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                       Standards Track                     [Page 6]
+
+RFC 3646          DNS Configuration Options for DHCPv6     December 2003
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Droms                       Standards Track                     [Page 7]
+
diff --git a/rfc/rfc6106.txt b/rfc/rfc6106.txt
new file mode 100644
index 00000000..4b49a43b
--- /dev/null
+++ b/rfc/rfc6106.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                          J. Jeong
+Request for Comments: 6106                                  Brocade/ETRI
+Obsoletes: 5006                                                  S. Park
+Category: Standards Track                            SAMSUNG Electronics
+ISSN: 2070-1721                                               L. Beloeil
+                                                      France Telecom R&D
+                                                          S. Madanapalli
+                                                       iRam Technologies
+                                                           November 2010
+
+
+        IPv6 Router Advertisement Options for DNS Configuration
+
+Abstract
+
+   This document specifies IPv6 Router Advertisement options to allow
+   IPv6 routers to advertise a list of DNS recursive server addresses
+   and a DNS Search List to IPv6 hosts.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6106.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 1]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Applicability Statements ...................................3
+      1.2. Coexistence of RA Options and DHCP Options for DNS
+           Configuration ..............................................4
+   2. Requirements Language ...........................................4
+   3. Terminology .....................................................4
+   4. Overview ........................................................5
+   5. Neighbor Discovery Extension ....................................5
+      5.1. Recursive DNS Server Option ................................6
+      5.2. DNS Search List Option .....................................7
+      5.3. Procedure of DNS Configuration .............................8
+           5.3.1. Procedure in IPv6 Host ..............................8
+           5.3.2. Warnings for DNS Options Configuration .............10
+   6. Implementation Considerations ..................................10
+      6.1. DNS Repository Management .................................10
+      6.2. Synchronization between DNS Server List and
+           Resolver Repository .......................................11
+      6.3. Synchronization between DNS Search List and
+           Resolver Repository .......................................12
+   7. Security Considerations ........................................13
+      7.1. Security Threats ..........................................13
+      7.2. Recommendations ...........................................14
+   8. IANA Considerations ............................................15
+   9. Acknowledgements ...............................................15
+   10. References ....................................................16
+      10.1. Normative References .....................................16
+      10.2. Informative References ...................................16
+   Appendix A.  Changes from RFC 5006 ................................18
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 2]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+1.  Introduction
+
+   The purpose of this document is to standardize an IPv6 Router
+   Advertisement (RA) option for DNS Recursive Server Addresses used for
+   the DNS name resolution in IPv6 hosts.  This RA option was specified
+   in an earlier Experimental specification [RFC5006].  This document is
+   also to define a new RA option for Domain Name Search Lists for an
+   enhanced DNS configuration.  Thus, this document obsoletes [RFC5006],
+   which only defines the RA option for DNS Recursive Server Addresses.
+
+   Neighbor Discovery (ND) for IP version 6 and IPv6 stateless address
+   autoconfiguration provide ways to configure either fixed or mobile
+   nodes with one or more IPv6 addresses, default routers, and some
+   other parameters [RFC4861][RFC4862].  Most Internet services are
+   identified by using a DNS name.  The two RA options defined in this
+   document provide the DNS information needed for an IPv6 host to reach
+   Internet services.
+
+   It is infeasible to manually configure nomadic hosts each time they
+   connect to a different network.  While a one-time static
+   configuration is possible, it is generally not desirable on general-
+   purpose hosts such as laptops.  For instance, locally defined name
+   spaces would not be available to the host if it were to run its own
+   name server software directly connected to the global DNS.
+
+   The DNS information can also be provided through DHCP
+   [RFC3315][RFC3736][RFC3646].  However, the access to DNS is a
+   fundamental requirement for almost all hosts, so IPv6 stateless
+   autoconfiguration cannot stand on its own as an alternative
+   deployment model in any practical network without any support for DNS
+   configuration.
+
+   These issues are not pressing in dual-stack networks as long as a DNS
+   server is available on the IPv4 side, but they become more critical
+   with the deployment of IPv6-only networks.  As a result, this
+   document defines a mechanism based on IPv6 RA options to allow IPv6
+   hosts to perform the automatic DNS configuration.
+
+1.1.  Applicability Statements
+
+   RA-based DNS configuration is a useful alternative in networks where
+   an IPv6 host's address is autoconfigured through IPv6 stateless
+   address autoconfiguration and where there is either no DHCPv6
+   infrastructure at all or some hosts do not have a DHCPv6 client.  The
+   intention is to enable the full configuration of basic networking
+   information for hosts without requiring DHCPv6.  However, when in
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 3]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   many networks some additional information needs to be distributed,
+   those networks are likely to employ DHCPv6.  In these networks, RA-
+   based DNS configuration may not be needed.
+
+   RA-based DNS configuration allows an IPv6 host to acquire the DNS
+   configuration (i.e., DNS recursive server addresses and DNS Search
+   List) for the link(s) to which the host is connected.  Furthermore,
+   the host learns this DNS configuration from the same RA message that
+   provides configuration information for the link, thereby avoiding
+   also running DHCPv6.
+
+   The advantages and disadvantages of the RA-based approach are
+   discussed in [RFC4339] along with other approaches, such as the DHCP
+   and well-known anycast address approaches.
+
+1.2.  Coexistence of RA Options and DHCP Options for DNS Configuration
+
+   Two protocols exist to configure the DNS information on a host, the
+   Router Advertisement options described in this document and the
+   DHCPv6 options described in [RFC3646].  They can be used together.
+   The rules governing the decision to use stateful configuration
+   mechanisms are specified in [RFC4861].  Hosts conforming to this
+   specification MUST extract DNS information from Router Advertisement
+   messages, unless static DNS configuration has been specified by the
+   user.  If there is DNS information available from multiple Router
+   Advertisements and/or from DHCP, the host MUST maintain an ordered
+   list of this information as specified in Section 5.3.1.
+
+2.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+3.  Terminology
+
+   This document uses the terminology described in [RFC4861] and
+   [RFC4862].  In addition, four new terms are defined below:
+
+   o  Recursive DNS Server (RDNSS): Server that provides a recursive DNS
+      resolution service for translating domain names into IP addresses
+      as defined in [RFC1034] and [RFC1035].
+
+   o  RDNSS Option: IPv6 RA option to deliver the RDNSS information to
+      IPv6 hosts [RFC4861].
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 4]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   o  DNS Search List (DNSSL): The list of DNS suffix domain names used
+      by IPv6 hosts when they perform DNS query searches for short,
+      unqualified domain names.
+
+   o  DNSSL Option: IPv6 RA option to deliver the DNSSL information to
+      IPv6 hosts.
+
+   o  DNS Repository: Two data structures for managing DNS Configuration
+      Information in the IPv6 protocol stack in addition to Neighbor
+      Cache and Destination Cache for Neighbor Discovery [RFC4861].  The
+      first data structure is the DNS Server List for RDNSS addresses
+      and the second is the DNS Search List for DNS search domain names.
+
+   o  Resolver Repository: Configuration repository with RDNSS addresses
+      and a DNS Search List that a DNS resolver on the host uses for DNS
+      name resolution; for example, the Unix resolver file (i.e., /etc/
+      resolv.conf) and Windows registry.
+
+4.  Overview
+
+   This document standardizes the ND option called the RDNSS option
+   defined in [RFC5006] that contains the addresses of recursive DNS
+   servers.  This document also defines a new ND option called the DNSSL
+   option for the Domain Search List.  This is to maintain parity with
+   the DHCPv6 options and to ensure that there is necessary
+   functionality to determine the search domains.
+
+   The existing ND message (i.e., Router Advertisement) is used to carry
+   this information.  An IPv6 host can configure the IPv6 addresses of
+   one or more RDNSSes via RA messages.  Through the RDNSS and DNSSL
+   options, along with the prefix information option based on the ND
+   protocol ([RFC4861] and [RFC4862]), an IPv6 host can perform the
+   network configuration of its IPv6 address and the DNS information
+   simultaneously without needing DHCPv6 for the DNS configuration.  The
+   RA options for RDNSS and DNSSL can be used on any network that
+   supports the use of ND.
+
+   This approach requires the manual configuration or other automatic
+   mechanisms (e.g., DHCPv6 or vendor proprietary configuration
+   mechanisms) to configure the DNS information in routers sending the
+   advertisements.  The automatic configuration of RDNSS addresses and a
+   DNS Search List in routers is out of scope for this document.
+
+5.  Neighbor Discovery Extension
+
+   The IPv6 DNS configuration mechanism in this document needs two new
+   ND options in Neighbor Discovery: (i) the Recursive DNS Server
+   (RDNSS) option and (ii) the DNS Search List (DNSSL) option.
+
+
+
+Jeong, et al.                Standards Track                    [Page 5]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+5.1.  Recursive DNS Server Option
+
+   The RDNSS option contains one or more IPv6 addresses of recursive DNS
+   servers.  All of the addresses share the same Lifetime value.  If it
+   is desirable to have different Lifetime values, multiple RDNSS
+   options can be used.  Figure 1 shows the format of the RDNSS option.
+
+      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            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Lifetime                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :            Addresses of IPv6 Recursive DNS Servers            :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Figure 1: Recursive DNS Server (RDNSS) Option Format
+
+
+   Fields:
+     Type          8-bit identifier of the RDNSS option type as assigned
+                   by the IANA: 25
+
+     Length        8-bit unsigned integer.  The length of the option
+                   (including the Type and Length fields) is in units of
+                   8 octets.  The minimum value is 3 if one IPv6 address
+                   is contained in the option.  Every additional RDNSS
+                   address increases the length by 2.  The Length field
+                   is used by the receiver to determine the number of
+                   IPv6 addresses in the option.
+
+     Lifetime      32-bit unsigned integer.  The maximum time, in
+                   seconds (relative to the time the packet is sent),
+                   over which this RDNSS address MAY be used for name
+                   resolution.  Hosts MAY send a Router Solicitation to
+                   ensure the RDNSS information is fresh before the
+                   interval expires.  In order to provide fixed hosts
+                   with stable DNS service and allow mobile hosts to
+                   prefer local RDNSSes to remote RDNSSes, the value of
+                   Lifetime SHOULD be bounded as
+                   MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval
+                   where MaxRtrAdvInterval is the Maximum RA Interval
+                   defined in [RFC4861].  A value of all one bits
+                   (0xffffffff) represents infinity.  A value of zero
+                   means that the RDNSS address MUST no longer be used.
+
+
+
+Jeong, et al.                Standards Track                    [Page 6]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+     Addresses of IPv6 Recursive DNS Servers
+                   One or more 128-bit IPv6 addresses of the recursive
+                   DNS servers.  The number of addresses is determined
+                   by the Length field.  That is, the number of
+                   addresses is equal to (Length - 1) / 2.
+
+5.2.  DNS Search List Option
+
+   The DNSSL option contains one or more domain names of DNS suffixes.
+   All of the domain names share the same Lifetime value.  If it is
+   desirable to have different Lifetime values, multiple DNSSL options
+   can be used.  Figure 2 shows the format of the DNSSL option.
+
+      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            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                           Lifetime                            |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |                                                               |
+     :                Domain Names of DNS Search List                :
+     |                                                               |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+              Figure 2: DNS Search List (DNSSL) Option Format
+
+  Fields:
+    Type          8-bit identifier of the DNSSL option type as assigned
+                  by the IANA: 31
+
+    Length        8-bit unsigned integer.  The length of the option
+                  (including the Type and Length fields) is in units of
+                  8 octets.  The minimum value is 2 if at least one
+                  domain name is contained in the option.  The Length
+                  field is set to a multiple of 8 octets to accommodate
+                  all the domain names in the field of Domain Names of
+                  DNS Search List.
+
+    Lifetime      32-bit unsigned integer.  The maximum time, in
+                  seconds (relative to the time the packet is sent),
+                  over which this DNSSL domain name MAY be used for
+                  name resolution.  The Lifetime value has the same
+                  semantics as with the RDNSS option.  That is, Lifetime
+                  SHOULD be bounded as follows:
+                  MaxRtrAdvInterval <= Lifetime <= 2*MaxRtrAdvInterval.
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 7]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+                  A value of all one bits (0xffffffff) represents
+                  infinity.  A value of zero means that the DNSSL
+                  domain name MUST no longer be used.
+
+    Domain Names of DNS Search List
+                  One or more domain names of DNS Search List that MUST
+                  be encoded using the technique described in Section
+                  3.1 of [RFC1035].  By this technique, each domain
+                  name is represented as a sequence of labels ending in
+                  a zero octet, defined as domain name representation.
+                  For more than one domain name, the corresponding
+                  domain name representations are concatenated as they
+                  are.  Note that for the simple decoding, the domain
+                  names MUST NOT be encoded in a compressed form, as
+                  described in Section 4.1.4 of [RFC1035].  Because the
+                  size of this field MUST be a multiple of 8 octets,
+                  for the minimum multiple including the domain name
+                  representations, the remaining octets other than the
+                  encoding parts of the domain name representations
+                  MUST be padded with zeros.
+
+   Note:  An RDNSS address or a DNSSL domain name MUST be used only as
+      long as both the RA router Lifetime (advertised by a Router
+      Advertisement message [RFC4861]) and the corresponding option
+      Lifetime have not expired.  The reason is that in the current
+      network to which an IPv6 host is connected, the RDNSS may not be
+      currently reachable, that the DNSSL domain name is not valid any
+      more, or that these options do not provide service to the host's
+      current address (e.g., due to network ingress filtering
+      [RFC2827][RFC5358]).
+
+5.3.  Procedure of DNS Configuration
+
+   The procedure of DNS configuration through the RDNSS and DNSSL
+   options is the same as with any other ND option [RFC4861].
+
+5.3.1.  Procedure in IPv6 Host
+
+   When an IPv6 host receives DNS options (i.e., RDNSS option and DNSSL
+   option) through RA messages, it processes the options as follows:
+
+   o  The validity of DNS options is checked with the Length field; that
+      is, the value of the Length field in the RDNSS option is greater
+      than or equal to the minimum value (3), and the value of the
+      Length field in the DNSSL option is greater than or equal to the
+      minimum value (2).
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 8]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   o  If the DNS options are valid, the host SHOULD copy the values of
+      the options into the DNS Repository and the Resolver Repository in
+      order.  Otherwise, the host MUST discard the options.  Refer to
+      Section 6 for the detailed procedure.
+
+   When the IPv6 host has gathered a sufficient number (e.g., three) of
+   RDNSS addresses (or DNS search domain names), it SHOULD maintain
+   RDNSS addresses (or DNS search domain names) by the sufficient number
+   such that the latest received RDNSS or DNSSL is more preferred to the
+   old ones; that is, when the number of RDNSS addresses (or DNS search
+   domain names) is already the sufficient number, the new one replaces
+   the old one that will expire first in terms of Lifetime.  As an
+   exceptional case, if the received RDNSS addresses (or DNS search
+   domain names) already exist in the IPv6 host, their Lifetime fields
+   update their Expiration-time, that is, when the corresponding DNS
+   information expires in the IPv6 host; note that when the Lifetime
+   field has zero, the corresponding RDNSS (or DNS search domain name)
+   is deleted from the IPv6 host.  Except for this update, the IPv6 host
+   SHOULD ignore other RDNSS addresses (or DNS search domain names)
+   within an RDNSS (or a DNSSL) option and/or additional RDNSS (or
+   DNSSL) options within an RA.  Refer to Section 6 for the detailed
+   procedure.  Note that the sufficient number is a system parameter, so
+   it can be determined by a local policy.  Also, separate parameters
+   can be specified for the sufficient number of RDNSS addresses and
+   that of DNS search domain names, respectively.  In this document,
+   three is RECOMMENDED as a sufficient number considering both the
+   robust DNS query and the reasonably time-bounded recognition of the
+   unreachability of DNS servers.
+
+   In the case where the DNS options of RDNSS and DNSSL can be obtained
+   from multiple sources, such as RA and DHCP, the IPv6 host SHOULD keep
+   some DNS options from all sources.  Unless explicitly specified for
+   the discovery mechanism, the exact number of addresses and domain
+   names to keep is a matter of local policy and implementation choice.
+   However, the ability to store at least three RDNSS addresses (or
+   DNSSL domain names) from at least two different sources is
+   RECOMMENDED.  The DNS options from Router Advertisements and DHCP
+   SHOULD be stored into the DNS Repository and Resolver Repository so
+   that information from DHCP appears there first and therefore takes
+   precedence.  Thus, the DNS information from DHCP takes precedence
+   over that from RA for DNS queries.  On the other hand, for DNS
+   options announced by RA, if some RAs use the Secure Neighbor
+   Discovery (SEND) protocol [RFC3971] for RA security, they MUST be
+   preferred over those that do not use SEND.  Refer to Section 7 for
+   the detailed discussion on SEND for RA DNS options.
+
+
+
+
+
+
+Jeong, et al.                Standards Track                    [Page 9]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+5.3.2.  Warnings for DNS Options Configuration
+
+   There are two warnings for DNS options configuration: (i) warning for
+   multiple sources of DNS options and (ii) warning for multiple network
+   interfaces.  First, in the case of multiple sources for DNS options
+   (e.g., RA and DHCP), an IPv6 host can configure its IP addresses from
+   these sources.  In this case, it is not possible to control how the
+   host uses DNS information and what source addresses it uses to send
+   DNS queries.  As a result, configurations where different information
+   is provided by different sources may lead to problems.  Therefore,
+   the network administrator needs to configure DNS options in multiple
+   sources in order to prevent such problems from happening.
+
+   Second, if different DNS information is provided on different network
+   interfaces, this can lead to inconsistent behavior.  The IETF is
+   working on solving this problem for both DNS and other information
+   obtained by multiple interfaces [MIF-PROBLEM][MIF-PRACTICE].
+
+6.  Implementation Considerations
+
+   Note:  This non-normative section gives some hints for implementing
+      the processing of the RDNSS and DNSSL options in an IPv6 host.
+
+   For the configuration and management of DNS information, the
+   advertised DNS configuration information can be stored and managed in
+   both the DNS Repository and the Resolver Repository.
+
+   In environments where the DNS information is stored in user space and
+   ND runs in the kernel, it is necessary to synchronize the DNS
+   information (i.e., RDNSS addresses and DNS search domain names) in
+   kernel space and the Resolver Repository in user space.  For the
+   synchronization, an implementation where ND works in the kernel
+   should provide a write operation for updating DNS information from
+   the kernel to the Resolver Repository.  One simple approach is to
+   have a daemon (or a program that is called at defined intervals) that
+   keeps monitoring the Lifetimes of RDNSS addresses and DNS search
+   domain names all the time.  Whenever there is an expired entry in the
+   DNS Repository, the daemon can delete the corresponding entry from
+   the Resolver Repository.
+
+6.1.  DNS Repository Management
+
+   For DNS repository management, the kernel or user-space process
+   (depending on where RAs are processed) should maintain two data
+   structures: (i) DNS Server List that keeps the list of RDNSS
+   addresses and (ii) DNS Search List that keeps the list of DNS search
+   domain names.  Each entry in these two lists consists of a pair of an
+   RDNSS address (or DNSSL domain name) and Expiration-time as follows:
+
+
+
+Jeong, et al.                Standards Track                   [Page 10]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   o  RDNSS address for DNS Server List: IPv6 address of the Recursive
+      DNS Server, which is available for recursive DNS resolution
+      service in the network advertising the RDNSS option.
+
+   o  DNSSL domain name for DNS Search List: DNS suffix domain names,
+      which are used to perform DNS query searches for short,
+      unqualified domain names in the network advertising the DNSSL
+      option.
+
+   o  Expiration-time for DNS Server List or DNS Search List: The time
+      when this entry becomes invalid.  Expiration-time is set to the
+      value of the Lifetime field of the RDNSS option or DNSSL option
+      plus the current system time.  Whenever a new RDNSS option with
+      the same address (or DNSSL option with the same domain name) is
+      received on the same interface as a previous RDNSS option (or
+      DNSSL option), this field is updated to have a new Expiration-
+      time.  When Expiration-time becomes less than the current system
+      time, this entry is regarded as expired.
+
+6.2.  Synchronization between DNS Server List and Resolver Repository
+
+   When an IPv6 host receives the information of multiple RDNSS
+   addresses within a network (e.g., campus network and company network)
+   through an RA message with RDNSS option(s), it stores the RDNSS
+   addresses (in order) into both the DNS Server List and the Resolver
+   Repository.  The processing of the RDNSS consists of (i) the
+   processing of RDNSS option(s) included in an RA message and (ii) the
+   handling of expired RDNSSes.  The processing of RDNSS option(s) is as
+   follows:
+
+      Step (a): Receive and parse the RDNSS option(s).  For the RDNSS
+      addresses in each RDNSS option, perform Steps (b) through (d).
+
+      Step (b): For each RDNSS address, check the following: If the
+      RDNSS address already exists in the DNS Server List and the RDNSS
+      option's Lifetime field is set to zero, delete the corresponding
+      RDNSS entry from both the DNS Server List and the Resolver
+      Repository in order to prevent the RDNSS address from being used
+      any more for certain reasons in network management, e.g., the
+      termination of the RDNSS or a renumbering situation.  That is, the
+      RDNSS can resign from its DNS service because the machine running
+      the RDNSS is out of service intentionally or unintentionally.
+      Also, under the renumbering situation, the RDNSS's IPv6 address
+      will be changed, so the previous RDNSS address should not be used
+      any more.  The processing of this RDNSS address is finished here.
+      Otherwise, go to Step (c).
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 11]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+      Step (c): For each RDNSS address, if it already exists in the DNS
+      Server List, then just update the value of the Expiration-time
+      field according to the procedure specified in the third bullet of
+      Section 6.1.  Otherwise, go to Step (d).
+
+      Step (d): For each RDNSS address, if it does not exist in the DNS
+      Server List, register the RDNSS address and Lifetime with the DNS
+      Server List and then insert the RDNSS address in front of the
+      Resolver Repository.  In the case where the data structure for the
+      DNS Server List is full of RDNSS entries (that is, has more
+      RDNSSes than the sufficient number discussed in Section 5.3.1),
+      delete from the DNS Server List the entry with the shortest
+      Expiration-time (i.e., the entry that will expire first).  The
+      corresponding RDNSS address is also deleted from the Resolver
+      Repository.  For the ordering of RDNSS addresses in an RDNSS
+      option, position the first RDNSS address in the RDNSS option as
+      the first one in the Resolver Repository, the second RDNSS address
+      in the option as the second one in the repository, and so on.
+      This ordering allows the RDNSS addresses in the RDNSS option to be
+      preferred according to their order in the RDNSS option for the DNS
+      name resolution.  The processing of these RDNSS addresses is
+      finished here.
+
+   The handling of expired RDNSSes is as follows: Whenever an entry
+   expires in the DNS Server List, the expired entry is deleted from the
+   DNS Server List, and also the RDNSS address corresponding to the
+   entry is deleted from the Resolver Repository.
+
+6.3.  Synchronization between DNS Search List and Resolver Repository
+
+   When an IPv6 host receives the information of multiple DNSSL domain
+   names within a network (e.g., campus network and company network)
+   through an RA message with DNSSL option(s), it stores the DNSSL
+   domain names (in order) into both the DNS Search List and the
+   Resolver Repository.  The processing of the DNSSL consists of (i) the
+   processing of DNSSL option(s) included in an RA message and (ii) the
+   handling of expired DNSSLs.  The processing of DNSSL option(s) is as
+   follows:
+
+      Step (a): Receive and parse the DNSSL option(s).  For the DNSSL
+      domain names in each DNSSL option, perform Steps (b) through (d).
+
+      Step (b): For each DNSSL domain name, check the following: If the
+      DNSSL domain name already exists in the DNS Search List and the
+      DNSSL option's Lifetime field is set to zero, delete the
+      corresponding DNSSL entry from both the DNS Search List and the
+      Resolver Repository in order to prevent the DNSSL domain name from
+      being used any more for certain reasons in network management,
+
+
+
+Jeong, et al.                Standards Track                   [Page 12]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+      e.g., the termination of the RDNSS or a renaming situation.  That
+      is, the RDNSS can resign from its DNS service because the machine
+      running the RDNSS is out of service intentionally or
+      unintentionally.  Also, under the renaming situation, the DNSSL
+      domain names will be changed, so the previous domain names should
+      not be used any more.  The processing of this DNSSL domain name is
+      finished here.  Otherwise, go to Step (c).
+
+      Step (c): For each DNSSL domain name, if it already exists in the
+      DNS Server List, then just update the value of the Expiration-time
+      field according to the procedure specified in the third bullet of
+      Section 6.1.  Otherwise, go to Step (d).
+
+      Step (d): For each DNSSL domain name, if it does not exist in the
+      DNS Search List, register the DNSSL domain name and Lifetime with
+      the DNS Search List and then insert the DNSSL domain name in front
+      of the Resolver Repository.  In the case where the data structure
+      for the DNS Search List is full of DNSSL domain name entries (that
+      is, has more DNSSL domain names than the sufficient number
+      discussed in Section 5.3.1), delete from the DNS Server List the
+      entry with the shortest Expiration-time (i.e., the entry that will
+      expire first).  The corresponding DNSSL domain name is also
+      deleted from the Resolver Repository.  For the ordering of DNSSL
+      domain names in a DNSSL option, position the first DNSSL domain
+      name in the DNSSL option as the first one in the Resolver
+      Repository, the second DNSSL domain name in the option as the
+      second one in the repository, and so on.  This ordering allows the
+      DNSSL domain names in the DNSSL option to be preferred according
+      to their order in the DNSSL option for the DNS domain name used by
+      the DNS query.  The processing of these DNSSL domain name is
+      finished here.
+
+      The handling of expired DNSSLs is as follows: Whenever an entry
+      expires in the DNS Search List, the expired entry is deleted from
+      the DNS Search List, and also the DNSSL domain name corresponding
+      to the entry is deleted from the Resolver Repository.
+
+7.  Security Considerations
+
+   In this section, we analyze security threats related to DNS options
+   and then suggest recommendations to cope with such security threats.
+
+7.1.  Security Threats
+
+   For the RDNSS option, an attacker could send an RA with a fraudulent
+   RDNSS address, misleading IPv6 hosts into contacting an unintended
+   DNS server for DNS name resolution.  Also, for the DNSSL option, an
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 13]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   attacker can let IPv6 hosts resolve a host name without a DNS suffix
+   into an unintended host's IP address with a fraudulent DNS Search
+   List.
+
+   These attacks are similar to Neighbor Discovery attacks that use
+   Redirect or Neighbor Advertisement messages to redirect traffic to
+   individual addresses of malicious parties.  That is, as a rogue
+   router, a malicious node on a LAN can promiscuously receive packets
+   for any router's Media Access Control (MAC) address and send packets
+   with the router's MAC address as the source MAC address in the Layer
+   2 (L2) header.  As a result, L2 switches send packets addressed to
+   the router to the malicious node.  Also, this attack can send
+   redirects that tell the hosts to send their traffic somewhere else.
+   The malicious node can send unsolicited RA or Neighbor Advertisement
+   (NA) replies, answer RS or Neighbor Solicitation (NS) requests, etc.
+   Thus, the attacks related to RDNSS and DNSSL are similar to both
+   Neighbor Discovery attacks and attacks against unauthenticated DHCP,
+   as both can be used for both "wholesale" traffic redirection and more
+   specific attacks.
+
+   However, the security of these RA options for DNS configuration does
+   not affect ND protocol security [RFC4861].  This is because learning
+   DNS information via the RA options cannot be worse than learning bad
+   router information via the RA options.  Therefore, the vulnerability
+   of ND is not worse and is a subset of the attacks that any node
+   attached to a LAN can do independently of ND.
+
+7.2.  Recommendations
+
+   The Secure Neighbor Discovery (SEND) protocol [RFC3971] is used as a
+   security mechanism for ND.  It is RECOMMENDED that ND use SEND to
+   allow all the ND options including the RDNSS and DNSSL options to be
+   automatically included in the signatures.  Through SEND, the
+   transport for the RA options is integrity protected; that is, SEND
+   can prevent the spoofing of these DNS options with signatures.  Also,
+   SEND enables an IPv6 host to verify that the sender of an RA is
+   actually a router authorized to act as a router.  However, since any
+   valid SEND router can still insert RDNSS and DNSSL options, the
+   current SEND cannot verify which one is or is not authorized to send
+   the options.  Thus, this verification of the authorized routers for
+   ND options will be required.  [CSI-SEND-CERT] specifies the usage of
+   extended key for the certificate deployed in SEND.  This document
+   defines the roles of routers (i.e., routers acting as proxy and
+   address owner) and explains the authorization of the roles.  The
+   mechanism in this document can be extended to verify which routers
+   are authorized to insert RDNSS and DNSSL options.
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 14]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   It is common for network devices such as switches to include
+   mechanisms to block unauthorized ports from running a DHCPv6 server
+   to provide protection from rogue DHCP servers.  That means that an
+   attacker on other ports cannot insert bogus DNS servers using DHCPv6.
+   The corresponding technique for network devices is RECOMMENDED to
+   block rogue Router Advertisement messages including the RDNSS and
+   DNSSL options from unauthorized nodes.
+
+   An attacker may provide a bogus DNS Search List option in order to
+   cause the victim to send DNS queries to a specific DNS server when
+   the victim queries non-FQDNs (fully qualified domain names).  For
+   this attack, the DNS resolver in IPv6 hosts can mitigate the
+   vulnerability with the recommendations mentioned in [RFC1535],
+   [RFC1536], and [RFC3646].
+
+8.  IANA Considerations
+
+   The RDNSS option defined in this document uses the IPv6 Neighbor
+   Discovery Option type defined in RFC 5006 [RFC5006], which was
+   assigned by the IANA as follows:
+
+                 Option Name                   Type
+                 Recursive DNS Server Option   25
+
+   The IANA has assigned a new IPv6 Neighbor Discovery Option type for
+   the DNSSL option defined in this document:
+
+                 Option Name                   Type
+                 DNS Search List Option        31
+
+   These options have been registered in the "Internet Control Message
+   Protocol version 6 (ICMPv6) Parameters" registry
+   (http://www.iana.org).
+
+9.  Acknowledgements
+
+   This document has greatly benefited from inputs by Robert Hinden,
+   Pekka Savola, Iljitsch van Beijnum, Brian Haberman, Tim Chown, Erik
+   Nordmark, Dan Wing, Jari Arkko, Ben Campbell, Vincent Roca, and Tony
+   Cheneau.  The authors sincerely appreciate their contributions.
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 15]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119]        Bradner, S., "Key words for use in RFCs to Indicate
+                    Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC4861]        Narten, T., Nordmark, E., Simpson, W., and H.
+                    Soliman, "Neighbor Discovery for IP version 6
+                    (IPv6)", RFC 4861, September 2007.
+
+   [RFC4862]        Thomson, S., Narten, T., and T. Jinmei, "IPv6
+                    Stateless Address Autoconfiguration", RFC 4862,
+                    September 2007.
+
+   [RFC1035]        Mockapetris, P., "Domain names - implementation and
+                    specification", STD 13, RFC 1035, November 1987.
+
+10.2.  Informative References
+
+   [RFC1034]        Mockapetris, P., "Domain names - concepts and
+                    facilities", STD 13, RFC 1034, November 1987.
+
+   [RFC3315]        Droms, R., Bound, J., Volz, B., Lemon, T., Perkins,
+                    C., and M. Carney, "Dynamic Host Configuration
+                    Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3736]        Droms, R., "Stateless Dynamic Host Configuration
+                    Protocol (DHCP) Service for IPv6", RFC 3736,
+                    April 2004.
+
+   [RFC3646]        Droms, R., "DNS Configuration options for Dynamic
+                    Host Configuration Protocol for IPv6 (DHCPv6)",
+                    RFC 3646, December 2003.
+
+   [RFC5006]        Jeong, J., Park, S., Beloeil, L., and S.
+                    Madanapalli, "IPv6 Router Advertisement Option for
+                    DNS Configuration", RFC 5006, September 2007.
+
+   [RFC4339]        Jeong, J., "IPv6 Host Configuration of DNS Server
+                    Information Approaches", RFC 4339, February 2006.
+
+   [RFC3971]        Arkko, J., Kempf, J., Zill, B., and P. Nikander,
+                    "SEcure Neighbor Discovery (SEND)", RFC 3971,
+                    March 2005.
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 16]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+   [RFC5358]        Damas, J. and F. Neves, "Preventing Use of Recursive
+                    Nameservers in Reflector Attacks", BCP 140,
+                    RFC 5358, October 2008.
+
+   [RFC2827]        Ferguson, P. and D. Senie, "Network Ingress
+                    Filtering: Defeating Denial of Service Attacks which
+                    employ IP Source Address Spoofing", BCP 38,
+                    RFC 2827, May 2000.
+
+   [RFC1535]        Gavron, E., "A Security Problem and Proposed
+                    Correction With Widely Deployed DNS Software",
+                    RFC 1535, October 1993.
+
+   [RFC1536]        Kumar, A., Postel, J., Neuman, C., Danzig, P., and
+                    S. Miller, "Common DNS Implementation Errors and
+                    Suggested Fixes", RFC 1536, October 1993.
+
+   [MIF-PROBLEM]    Blanchet, M. and P. Seite, "Multiple Interfaces
+                    Problem Statement", Work in Progress, August 2010.
+
+   [MIF-PRACTICE]   Wasserman, M. and P. Seite, "Current Practices for
+                    Multiple Interface Hosts", Work in Progress,
+                    August 2010.
+
+   [CSI-SEND-CERT]  Gagliano, R., Krishnan, S., and A. Kukec,
+                    "Certificate profile and certificate management for
+                    SEND", Work in Progress, October 2010.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 17]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+Appendix A.  Changes from RFC 5006
+
+   The following changes were made from RFC 5006 "IPv6 Router
+   Advertisement Option for DNS Configuration":
+
+   o  Added the DNS Search List (DNSSL) option to support the
+      advertisement of DNS suffixes used in the DNS search along with
+      RDNSS option in RFC 5006.
+
+   o  Clarified the coexistence of RA options and DHCP options for DNS
+      configuration.
+
+   o  Modified the procedure in IPv6 host:
+
+      *  Clarified the procedure for DNS options in an IPv6 host.
+
+      *  Specified a sufficient number of RDNSS addresses or DNS search
+         domain names as three.
+
+      *  Specified a way to deal with DNS options from multiple sources,
+         such as RA and DHCP.
+
+   o  Modified the implementation considerations for DNSSL option
+      handling.
+
+   o  Modified the security considerations to consider more attack
+      scenarios and the corresponding possible solutions.
+
+   o  Modified the IANA considerations to require another IPv6 Neighbor
+      Discovery Option type for the DNSSL option.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 18]
+
+RFC 6106                   IPv6 RA DNS Options             November 2010
+
+
+Authors' Addresses
+
+   Jaehoon Paul Jeong
+   Brocade Communications Systems/ETRI
+   6000 Nathan Ln N
+   Plymouth, MN  55442
+   USA
+
+   Phone: +1 763 268 7173
+   Fax:   +1 763 268 6800
+   EMail: pjeong@brocade.com
+   URI:   http://www.cs.umn.edu/~jjeong/
+
+
+   Soohong Daniel Park
+   Digital Media & Communications R&D Center
+   SAMSUNG Electronics
+   416 Maetan-3dong, Yeongtong-Gu
+   Suwon, Gyeonggi-Do  443-742
+   Korea
+
+   Phone: +82 31 279 8876
+   EMail: soohong.park@samsung.com
+
+
+   Luc Beloeil
+   France Telecom R&D
+   42, rue des coutures
+   BP 6243
+   14066 CAEN Cedex 4
+   France
+
+   Phone: +33 2 40 44 97 40
+   EMail: luc.beloeil@orange-ftgroup.com
+
+
+   Syam Madanapalli
+   iRam Technologies
+   #H304, Shriram Samruddhi, Thubarahalli
+   Bangalore - 560066
+   India
+
+   EMail: smadanapalli@gmail.com
+
+
+
+
+
+
+
+
+Jeong, et al.                Standards Track                   [Page 19]
+