diff options
| -rw-r--r-- | accel-pppd/CMakeLists.txt | 2 | ||||
| -rw-r--r-- | accel-pppd/accel-ppp.conf | 7 | ||||
| -rw-r--r-- | accel-pppd/extra/ipv6pool.c | 2 | ||||
| -rw-r--r-- | accel-pppd/ipdb.h | 3 | ||||
| -rw-r--r-- | accel-pppd/ipv6/CMakeLists.txt | 7 | ||||
| -rw-r--r-- | accel-pppd/ipv6/dhcpv6.c | 551 | ||||
| -rw-r--r-- | accel-pppd/ipv6/dhcpv6.h | 175 | ||||
| -rw-r--r-- | accel-pppd/ipv6/dhcpv6_packet.c | 438 | ||||
| -rw-r--r-- | accel-pppd/ipv6/nd.c (renamed from accel-pppd/ppp/ipv6_nd.c) | 34 | ||||
| -rw-r--r-- | accel-pppd/ppp/ipv6cp_opt_intfid.c | 61 | ||||
| -rw-r--r-- | accel-pppd/ppp/ppp_ipv6cp.c | 2 | ||||
| -rw-r--r-- | accel-pppd/radius/radius.c | 8 | ||||
| -rw-r--r-- | accel-pppd/radius/req.c | 2 | ||||
| -rw-r--r-- | rfc/rfc3315.txt | 5659 | ||||
| -rw-r--r-- | rfc/rfc3633.txt | 1067 | ||||
| -rw-r--r-- | rfc/rfc3646.txt | 395 | ||||
| -rw-r--r-- | rfc/rfc6106.txt | 1067 |
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] + |