diff options
| -rw-r--r-- | accel-pppd/CMakeLists.txt | 2 | ||||
| -rw-r--r-- | accel-pppd/extra/chap-secrets.c | 6 | ||||
| -rw-r--r-- | accel-pppd/extra/ippool.c | 10 | ||||
| -rw-r--r-- | accel-pppd/ipdb.c | 37 | ||||
| -rw-r--r-- | accel-pppd/ipdb.h | 22 | ||||
| -rw-r--r-- | accel-pppd/ppp/ccp_mppe.c | 1 | ||||
| -rw-r--r-- | accel-pppd/ppp/ipcp_opt_ipaddr.c | 6 | ||||
| -rw-r--r-- | accel-pppd/ppp/ppp.c | 1 | ||||
| -rw-r--r-- | accel-pppd/ppp/ppp.h | 5 | ||||
| -rw-r--r-- | accel-pppd/ppp/ppp_ccp.c | 1 | ||||
| -rw-r--r-- | accel-pppd/radius/radius.c | 25 | ||||
| -rw-r--r-- | accel-pppd/radius/radius_p.h | 3 | ||||
| -rw-r--r-- | rfc/rfc3162.txt | 675 | ||||
| -rw-r--r-- | rfc/rfc5072.txt | 899 |
14 files changed, 1660 insertions, 33 deletions
diff --git a/accel-pppd/CMakeLists.txt b/accel-pppd/CMakeLists.txt index 39d57944..45a070fe 100644 --- a/accel-pppd/CMakeLists.txt +++ b/accel-pppd/CMakeLists.txt @@ -65,6 +65,8 @@ ADD_EXECUTABLE(accel-pppd ppp/ppp_ipcp.c ppp/ipcp_opt_ipaddr.c ppp/ipcp_opt_dns.c + ppp/ipv6cp_opt_intfid.c + ppp/ppp_ipv6cp.c ppp/ppp_ccp.c ppp/ccp_mppe.c diff --git a/accel-pppd/extra/chap-secrets.c b/accel-pppd/extra/chap-secrets.c index 20565b97..61cd2a91 100644 --- a/accel-pppd/extra/chap-secrets.c +++ b/accel-pppd/extra/chap-secrets.c @@ -24,7 +24,7 @@ static struct ipdb_t ipdb; struct cs_pd_t { struct ppp_pd_t pd; - struct ipdb_item_t ip; + struct ipv4db_item_t ip; char *passwd; char *rate; }; @@ -212,7 +212,7 @@ static void ev_ppp_pre_up(struct ppp_t *ppp) } } -static struct ipdb_item_t *get_ip(struct ppp_t *ppp) +static struct ipv4db_item_t *get_ip(struct ppp_t *ppp) { struct cs_pd_t *pd; @@ -244,7 +244,7 @@ static char* get_passwd(struct pwdb_t *pwdb, struct ppp_t *ppp, const char *user } static struct ipdb_t ipdb = { - .get = get_ip, + .get_ipv4 = get_ip, }; static struct pwdb_t pwdb = { diff --git a/accel-pppd/extra/ippool.c b/accel-pppd/extra/ippool.c index 6f07e5f8..d49f0f44 100644 --- a/accel-pppd/extra/ippool.c +++ b/accel-pppd/extra/ippool.c @@ -14,7 +14,7 @@ struct ippool_item_t { struct list_head entry; - struct ipdb_item_t it; + struct ipv4db_item_t it; }; struct ipaddr_t @@ -153,7 +153,7 @@ static void generate_pool(void) } } -static struct ipdb_item_t *get_ip(struct ppp_t *ppp) +static struct ipv4db_item_t *get_ip(struct ppp_t *ppp) { struct ippool_item_t *it; @@ -168,7 +168,7 @@ static struct ipdb_item_t *get_ip(struct ppp_t *ppp) return it ? &it->it : NULL; } -static void put_ip(struct ppp_t *ppp, struct ipdb_item_t *it) +static void put_ip(struct ppp_t *ppp, struct ipv4db_item_t *it) { struct ippool_item_t *pit = container_of(it, typeof(*pit), it); @@ -178,8 +178,8 @@ static void put_ip(struct ppp_t *ppp, struct ipdb_item_t *it) } static struct ipdb_t ipdb = { - .get = get_ip, - .put = put_ip, + .get_ipv4 = get_ip, + .put_ipv4 = put_ip, }; static void ippool_init(void) diff --git a/accel-pppd/ipdb.c b/accel-pppd/ipdb.c index a08d3be2..8054e6bf 100644 --- a/accel-pppd/ipdb.c +++ b/accel-pppd/ipdb.c @@ -5,13 +5,15 @@ static LIST_HEAD(ipdb_handlers); -__export struct ipdb_item_t *ipdb_get(struct ppp_t *ppp) +struct ipv4db_item_t __export *ipdb_get_ipv4(struct ppp_t *ppp) { struct ipdb_t *ipdb; - struct ipdb_item_t *it; + struct ipv4db_item_t *it; list_for_each_entry(ipdb, &ipdb_handlers, entry) { - it = ipdb->get(ppp); + if (!ipdb->get_ipv4) + continue; + it = ipdb->get_ipv4(ppp); if (it) return it; } @@ -19,12 +21,35 @@ __export struct ipdb_item_t *ipdb_get(struct ppp_t *ppp) return NULL; } -void __export ipdb_put(struct ppp_t *ppp, struct ipdb_item_t *it) +void __export ipdb_put_ipv4(struct ppp_t *ppp, struct ipv4db_item_t *it) { - if (it->owner->put) - it->owner->put(ppp, it); + if (it->owner->put_ipv4) + it->owner->put_ipv4(ppp, it); } +struct ipv6db_item_t __export *ipdb_get_ipv6(struct ppp_t *ppp) +{ + struct ipdb_t *ipdb; + struct ipv6db_item_t *it; + + list_for_each_entry(ipdb, &ipdb_handlers, entry) { + if (!ipdb->get_ipv6) + continue; + it = ipdb->get_ipv6(ppp); + if (it) + return it; + } + + return NULL; +} + +void __export ipdb_put_ipv6(struct ppp_t *ppp, struct ipv6db_item_t *it) +{ + if (it->owner->put_ipv4) + it->owner->put_ipv6(ppp, it); +} + + void __export ipdb_register(struct ipdb_t *ipdb) { list_add_tail(&ipdb->entry, &ipdb_handlers); diff --git a/accel-pppd/ipdb.h b/accel-pppd/ipdb.h index ebf38853..35394205 100644 --- a/accel-pppd/ipdb.h +++ b/accel-pppd/ipdb.h @@ -6,22 +6,34 @@ #include "ppp.h" #include "list.h" -struct ipdb_item_t +struct ipv4db_item_t { struct ipdb_t *owner; in_addr_t addr; in_addr_t peer_addr; }; +struct ipv6db_item_t +{ + struct ipdb_t *owner; + struct in6_addr addr; + struct in6_addr peer_addr; +}; + + struct ipdb_t { struct list_head entry; - struct ipdb_item_t *(*get)(struct ppp_t *ppp); - void (*put)(struct ppp_t *ppp, struct ipdb_item_t *); + struct ipv4db_item_t *(*get_ipv4)(struct ppp_t *ppp); + void (*put_ipv4)(struct ppp_t *ppp, struct ipv4db_item_t *); + struct ipv6db_item_t *(*get_ipv6)(struct ppp_t *ppp); + void (*put_ipv6)(struct ppp_t *ppp, struct ipv6db_item_t *); }; -struct ipdb_item_t *ipdb_get(struct ppp_t *ppp); -void ipdb_put(struct ppp_t *ppp, struct ipdb_item_t *); +struct ipv4db_item_t *ipdb_get_ipv4(struct ppp_t *ppp); +void ipdb_put_ipv4(struct ppp_t *ppp, struct ipv4db_item_t *); +struct ipv6db_item_t *ipdb_get_ipv6(struct ppp_t *ppp); +void ipdb_put_ipv6(struct ppp_t *ppp, struct ipv6db_item_t *); void ipdb_register(struct ipdb_t *); diff --git a/accel-pppd/ppp/ccp_mppe.c b/accel-pppd/ppp/ccp_mppe.c index ba86ef47..7d9aab21 100644 --- a/accel-pppd/ppp/ccp_mppe.c +++ b/accel-pppd/ppp/ccp_mppe.c @@ -1,6 +1,7 @@ #include <stdlib.h> #include <string.h> #include <errno.h> +#include <arpa/inet.h> #include <sys/socket.h> #include <sys/ioctl.h> #include "linux_ppp.h" diff --git a/accel-pppd/ppp/ipcp_opt_ipaddr.c b/accel-pppd/ppp/ipcp_opt_ipaddr.c index d584fd7f..217a0806 100644 --- a/accel-pppd/ppp/ipcp_opt_ipaddr.c +++ b/accel-pppd/ppp/ipcp_opt_ipaddr.c @@ -30,7 +30,7 @@ static void ipaddr_print(void (*print)(const char *fmt,...),struct ipcp_option_t struct ipaddr_option_t { struct ipcp_option_t opt; - struct ipdb_item_t *ip; + struct ipv4db_item_t *ip; int started:1; }; @@ -59,7 +59,7 @@ static void ipaddr_free(struct ppp_ipcp_t *ipcp, struct ipcp_option_t *opt) struct ipaddr_option_t *ipaddr_opt=container_of(opt,typeof(*ipaddr_opt),opt); if (ipaddr_opt->ip) - ipdb_put(ipcp->ppp, ipaddr_opt->ip); + ipdb_put_ipv4(ipcp->ppp, ipaddr_opt->ip); _free(ipaddr_opt); } @@ -88,7 +88,7 @@ static int ipaddr_send_conf_req(struct ppp_ipcp_t *ipcp, struct ipcp_option_t *o struct ipcp_opt32_t *opt32=(struct ipcp_opt32_t*)ptr; if (!ipaddr_opt->ip) { - ipaddr_opt->ip = ipdb_get(ipcp->ppp); + ipaddr_opt->ip = ipdb_get_ipv4(ipcp->ppp); if (!ipaddr_opt->ip) { log_ppp_warn("ppp:ipcp: no free IP address\n"); return -1; diff --git a/accel-pppd/ppp/ppp.c b/accel-pppd/ppp/ppp.c index 5c529489..b541ba50 100644 --- a/accel-pppd/ppp/ppp.c +++ b/accel-pppd/ppp/ppp.c @@ -494,6 +494,7 @@ static int get_layer_order(const char *name) if (!strcmp(name,"auth")) return 1; if (!strcmp(name,"ccp")) return 2; if (!strcmp(name,"ipcp")) return 2; + if (!strcmp(name,"ipv6cp")) return 2; return -1; } diff --git a/accel-pppd/ppp/ppp.h b/accel-pppd/ppp/ppp.h index c0ebe834..ae2a7c99 100644 --- a/accel-pppd/ppp/ppp.h +++ b/accel-pppd/ppp/ppp.h @@ -3,7 +3,6 @@ #include <sys/types.h> #include <time.h> -#include <netinet/in.h> #include <pthread.h> #include "triton.h" @@ -99,8 +98,8 @@ struct ppp_t time_t start_time; time_t stop_time; char *username; - in_addr_t ipaddr; - in_addr_t peer_ipaddr; + uint32_t ipaddr; + uint32_t peer_ipaddr; struct ppp_ctrl_t *ctrl; diff --git a/accel-pppd/ppp/ppp_ccp.c b/accel-pppd/ppp/ppp_ccp.c index c277f9f9..79b0c32d 100644 --- a/accel-pppd/ppp/ppp_ccp.c +++ b/accel-pppd/ppp/ppp_ccp.c @@ -1,6 +1,7 @@ #include <stdlib.h> #include <string.h> #include <errno.h> +#include <arpa/inet.h> #include <sys/socket.h> #include <sys/ioctl.h> #include "linux_ppp.h" diff --git a/accel-pppd/radius/radius.c b/accel-pppd/radius/radius.c index 0fc42cd1..5f507cb4 100644 --- a/accel-pppd/radius/radius.c +++ b/accel-pppd/radius/radius.c @@ -90,9 +90,9 @@ int rad_proc_attrs(struct rad_req_t *req) if (!conf_gw_ip_address) log_ppp_warn("radius: gw-ip-address not specified, cann't assign IP address...\n"); else { - req->rpd->ipaddr.owner = &ipdb; - req->rpd->ipaddr.peer_addr = attr->val.ipaddr; - req->rpd->ipaddr.addr = conf_gw_ip_address; + req->rpd->ipv4_addr.owner = &ipdb; + req->rpd->ipv4_addr.peer_addr = attr->val.ipaddr; + req->rpd->ipv4_addr.addr = conf_gw_ip_address; } break; case Acct_Interim_Interval: @@ -163,15 +163,25 @@ static int check(struct pwdb_t *pwdb, struct ppp_t *ppp, const char *username, i return r; } -static struct ipdb_item_t *get_ip(struct ppp_t *ppp) +static struct ipv4db_item_t *get_ipv4(struct ppp_t *ppp) { struct radius_pd_t *rpd = find_pd(ppp); - if (rpd->ipaddr.peer_addr) - return &rpd->ipaddr; + if (rpd->ipv4_addr.peer_addr) + return &rpd->ipv4_addr; return NULL; } +static struct ipv6db_item_t *get_ipv6(struct ppp_t *ppp) +{ + struct radius_pd_t *rpd = find_pd(ppp); + + if (memcmp(&rpd->ipv6_addr.peer_addr, &in6addr_any, sizeof(in6addr_any))) + return &rpd->ipv6_addr; + return NULL; +} + + static void session_timeout(struct triton_timer_t *t) { struct radius_pd_t *rpd = container_of(t, typeof(*rpd), session_timeout); @@ -402,7 +412,8 @@ void __export rad_register_plugin(struct ppp_t *ppp, struct rad_plugin_t *plugin } static struct ipdb_t ipdb = { - .get = get_ip, + .get_ipv4 = get_ipv4, + .get_ipv6 = get_ipv6, }; static struct pwdb_t pwdb = { diff --git a/accel-pppd/radius/radius_p.h b/accel-pppd/radius/radius_p.h index 8c3a10d5..578c7770 100644 --- a/accel-pppd/radius/radius_p.h +++ b/accel-pppd/radius/radius_p.h @@ -33,7 +33,8 @@ struct radius_pd_t struct rad_packet_t *dm_coa_req; struct sockaddr_in dm_coa_addr; - struct ipdb_item_t ipaddr; + struct ipv4db_item_t ipv4_addr; + struct ipv6db_item_t ipv6_addr; int acct_interim_interval; time_t acct_timestamp; diff --git a/rfc/rfc3162.txt b/rfc/rfc3162.txt new file mode 100644 index 00000000..a62642f3 --- /dev/null +++ b/rfc/rfc3162.txt @@ -0,0 +1,675 @@ + + + + + + +Network Working Group B. Aboba +Request for Comments: 3162 Microsoft +Category: Standards Track G. Zorn + Cisco Systems + D. Mitton + Circular Logic UnLtd. + August 2001 + + + RADIUS and IPv6 + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + This document specifies the operation of RADIUS (Remote + Authentication Dial In User Service) when run over IPv6 as well as + the RADIUS attributes used to support IPv6 network access. + +1. Introduction + + This document specifies the operation of RADIUS [4]-[8] over IPv6 + [13] as well as the RADIUS attributes used to support IPv6 network + access. + + Note that a NAS sending a RADIUS Access-Request may not know a-priori + whether the host will be using IPv4, IPv6, or both. For example, + within PPP, IPv6CP [11] occurs after LCP, so that address assignment + will not occur until after RADIUS authentication and authorization + has completed. + + Therefore it is presumed that the IPv6 attributes described in this + document MAY be sent along with IPv4-related attributes within the + same RADIUS message and that the NAS will decide which attributes to + use. The NAS SHOULD only allocate addresses and prefixes that the + client can actually use, however. For example, there is no need for + + + + + +Aboba, et al. Standards Track [Page 1] + +RFC 3162 RADIUS and IPv6 August 2001 + + + the NAS to reserve use of an IPv4 address for a host that only + supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does + not require allocation of an IPv6 prefix. + + The NAS can provide IPv6 access natively, or alternatively, via other + methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14]. The + choice of method for providing IPv6 access has no effect on RADIUS + usage per se, although if it is desired that an IPv6 within IPv4 + tunnel be opened to a particular location, then tunnel attributes + should be utilized, as described in [6], [7]. + +1.1. Requirements language + + In this document, the key words "MAY", "MUST, "MUST NOT", "optional", + "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as + described in [1]. + +2. Attributes + +2.1. NAS-IPv6-Address + + Description + + This Attribute indicates the identifying IPv6 Address of the NAS + which is requesting authentication of the user, and SHOULD be + unique to the NAS within the scope of the RADIUS server. NAS- + IPv6-Address is only used in Access-Request packets. NAS-IPv6- + Address and/or NAS-IP-Address MAY be present in an Access-Request + packet; however, if neither attribute is present then NAS- + Identifier MUST be present. + + A summary of the NAS-IPv6-Address Attribute format is shown below. + The fields are transmitted from left to right. + + 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + + +Aboba, et al. Standards Track [Page 2] + +RFC 3162 RADIUS and IPv6 August 2001 + + + Type + + 95 for NAS-IPv6-Address + + Length + + 18 + + Address + + The Address field is 16 octets. + +3.2. Framed-Interface-Id + + Description + + This Attribute indicates the IPv6 interface identifier to be + configured for the user. It MAY be used in Access-Accept packets. + If the Interface-Identifier IPv6CP option [11] has been + successfully negotiated, this Attribute MUST be included in an + Access-Request packet as a hint by the NAS to the server that it + would prefer that value. It is recommended, but not required, + that the server honor the hint. + + A summary of the Framed-Interface-Id Attribute format is shown below. + The fields are transmitted from left to right. + + 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 | Interface-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Id + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Id | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 96 for Framed-Interface-Id + + Length + + 10 + + Interface-Id + + The Interface-Id field is 8 octets. + + + +Aboba, et al. Standards Track [Page 3] + +RFC 3162 RADIUS and IPv6 August 2001 + + +2.3. Framed-IPv6-Prefix + + Description + + This Attribute indicates an IPv6 prefix (and corresponding route) + to be configured for the user. It MAY be used in Access-Accept + packets, and can appear multiple times. It MAY be used in an + Access-Request packet as a hint by the NAS to the server that it + would prefer these prefix(es), but the server is not required to + honor the hint. Since it is assumed that the NAS will plumb a + route corresponding to the prefix, it is not necessary for the + server to also send a Framed-IPv6-Route attribute for the same + prefix. + + A summary of the Framed-IPv6-Prefix Attribute format is shown below. + The fields are transmitted from left to right. + + 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 | Prefix-Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Prefix + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Prefix | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 97 for Framed-IPv6-Prefix + + Length + + At least 4 and no larger than 20. + + Reserved + + This field, which is reserved and MUST be present, is always set + to zero. + + Prefix-Length + + The length of the prefix, in bits. At least 0 and no larger than + 128. + + + +Aboba, et al. Standards Track [Page 4] + +RFC 3162 RADIUS and IPv6 August 2001 + + + Prefix + + The Prefix field is up to 16 octets in length. Bits outside of + the Prefix-Length, if included, must be zero. + +2.4. Login-IPv6-Host + + Description + + This Attribute indicates the system with which to connect the + user, when the Login-Service Attribute is included. It MAY be + used in Access-Accept packets. It MAY be used in an Access- + Request packet as a hint to the server that the NAS would prefer + to use that host, but the server is not required to honor the + hint. + + A summary of the Login-IPv6-Host Attribute format is shown below. + The fields are transmitted from left to right. + + 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 | Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Address | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 98 for Login-IPv6-Host + + Length + + 18 + + + + + + + + + + + +Aboba, et al. Standards Track [Page 5] + +RFC 3162 RADIUS and IPv6 August 2001 + + + Address + + The Address field is 16 octets in length. The value + 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD + allow the user to select an address or name to be connected to. + The value 0 indicates that the NAS SHOULD select a host to connect + the user to. Other values indicate the address the NAS SHOULD + connect the user to. + +2.5. Framed-IPv6-Route + + Description + + This Attribute provides routing information to be configured for + the user on the NAS. It is used in the Access-Accept packet and + can appear multiple times. + + A summary of the Framed-IPv6-Route Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + | Type | Length | Text ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- + + Type + + 99 for Framed-IPv6-Route + + Length + + >=3 + + Text + + The Text field is one or more octets, and its contents are + implementation dependent. The field is not NUL (hex 00) + terminated. It is intended to be human readable and MUST NOT + affect operation of the protocol. + + For IPv6 routes, it SHOULD contain a destination prefix optionally + followed by a slash and a decimal length specifier stating how + many high order bits of the prefix to use. That is followed by a + space, a gateway address, a space, and one or more metrics + (encoded in decimal) separated by spaces. Prefixes and addresses + are formatted as described in [16]. For example, + "2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1". + + + +Aboba, et al. Standards Track [Page 6] + +RFC 3162 RADIUS and IPv6 August 2001 + + + Whenever the gateway address is the IPv6 unspecified address the + IP address of the user SHOULD be used as the gateway address. The + unspecified address can be expressed in any of the acceptable + formats described in [16]. For example, "2000:0:0:106::/64 :: 1". + +2.6. Framed-IPv6-Pool + + Description + + This Attribute contains the name of an assigned pool that SHOULD + be used to assign an IPv6 prefix for the user. If a NAS does not + support multiple prefix pools, the NAS MUST ignore this Attribute. + + A summary of the Framed-IPv6-Pool Attribute format is shown below. + The fields are transmitted from left to right. + + 0 1 2 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | String... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 100 for Framed-IPv6-Pool + + Length + + >= 3 + + String + + The string field contains the name of an assigned IPv6 prefix pool + configured on the NAS. The field is not NUL (hex 00) terminated. + +3. Table of Attributes + + The following table provides a guide to which attributes may be found + in which kinds of packets, and in what quantity. + + Request Accept Reject Challenge Accounting # Attribute + Request + 0-1 0 0 0 0-1 95 NAS-IPv6-Address + 0-1 0-1 0 0 0-1 96 Framed-Interface-Id + 0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix + 0+ 0+ 0 0 0+ 98 Login-IPv6-Host + 0 0+ 0 0 0+ 99 Framed-IPv6-Route + 0 0-1 0 0 0-1 100 Framed-IPv6-Pool + + + +Aboba, et al. Standards Track [Page 7] + +RFC 3162 RADIUS and IPv6 August 2001 + + +4. References + + [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March, 1997. + + [2] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO + 10646", RFC 2044, October 1996. + + [3] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy + Implementation in Roaming", RFC 2607, June 1999. + + [4] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote + Authentication Dial In User Service (RADIUS)", RFC 2865, June + 2000. + + [5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. + + [6] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting + Modifications for Tunnel Protocol Support", RFC 2867, June + 2000. + + [7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. + and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", + RFC 2868, June 2000. + + [8] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", + RFC 2869, June 2000. + + [9] Kent S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA + Considerations Section in RFCs", BCP 26, RFC 2434, October + 1998. + + [11] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, + December 1998. + + [12] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via + IPv4 Clouds", RFC 3056, February 2001. + + [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [14] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 + Domains without Explicit Tunnels", RFC 2529, March 1999. + + + + + +Aboba, et al. Standards Track [Page 8] + +RFC 3162 RADIUS and IPv6 August 2001 + + + [15] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 + Hosts and Routers", RFC 2893, August 2000. + + [16] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 2373, July 1998. + +5. Security Considerations + + This document describes the use of RADIUS for the purposes of + authentication, authorization and accounting in IPv6-enabled + networks. In such networks, the RADIUS protocol may run either over + IPv4 or over IPv6. Known security vulnerabilities of the RADIUS + protocol are described in [3], [4] and [8]. + + Since IPSEC [9] is mandatory to implement for IPv6, it is expected + that running RADIUS implementations supporting IPv6 will typically + run over IPSEC. Where RADIUS is run over IPSEC and where + certificates are used for authentication, it may be desirable to + avoid management of RADIUS shared secrets, so as to leverage the + improved scalability of public key infrastructure. + + Within RADIUS, a shared secret is used for hiding of attributes such + as User-Password [4] and Tunnel-Password [7]. In addition, the + shared secret is used in computation of the Response Authenticator + [4], as well as the Message-Authenticator attribute [8]. Therefore, + in RADIUS a shared secret is used to provide confidentiality as well + as integrity protection and authentication. As a result, only use of + IPSEC ESP with a non-null transform can provide security services + sufficient to substitute for RADIUS application-layer security. + Therefore, where IPSEC AH or ESP null is used, it will typically + still be necessary to configure a RADIUS shared secret. + + However, where RADIUS is run over IPSEC ESP with a non-null + transform, the secret shared between the NAS and the RADIUS server + MAY NOT be configured. In this case, a shared secret of zero length + MUST be assumed. + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 9] + +RFC 3162 RADIUS and IPv6 August 2001 + + +6. IANA Considerations + + This document requires the assignment of six new RADIUS attribute + numbers for the following attributes: + + NAS-IPv6-Address + Framed-Interface-Id + Framed-IPv6-Prefix + Login-IPv6-Host + Framed-IPv6-Route + Framed-IPv6-Pool + + See section 3 for the registered list of numbers. + +7. Acknowledgments + + The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ + Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent + for contributions to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 10] + +RFC 3162 RADIUS and IPv6 August 2001 + + +8. Authors' Addresses + + Bernard Aboba + Microsoft Corporation + One Microsoft Way + Redmond, WA 98052 + + Phone: +1 425 936 6605 + Fax: +1 425 936 7329 + EMail: bernarda@microsoft.com + + + Glen Zorn + Cisco Systems, Inc. + 500 108th Avenue N.E., Suite 500 + Bellevue, WA 98004 + + Phone: +1 425 471 4861 + EMail: gwz@cisco.com + + + Dave Mitton + Circular Logic UnLtd. + 733 Turnpike Street #154 + North Andover, MA 01845 + + Phone: 978 683-1814 + Email: david@mitton.com + + + + + + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 11] + +RFC 3162 RADIUS and IPv6 August 2001 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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. + + + + + + + + + + + + + + + + + + + +Aboba, et al. Standards Track [Page 12] + diff --git a/rfc/rfc5072.txt b/rfc/rfc5072.txt new file mode 100644 index 00000000..c3846295 --- /dev/null +++ b/rfc/rfc5072.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group S. Varada, Ed. +Request for Comments: 5072 Transwitch +Obsoletes: 2472 D. Haskins +Category: Standards Track E. Allen + September 2007 + + + IP Version 6 over PPP + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + The Point-to-Point Protocol (PPP) provides a standard method of + encapsulating network-layer protocol information over point-to-point + links. PPP also defines an extensible Link Control Protocol, and + proposes a family of Network Control Protocols (NCPs) for + establishing and configuring different network-layer protocols. + + This document defines the method for sending IPv6 packets over PPP + links, the NCP for establishing and configuring the IPv6 over PPP, + and the method for forming IPv6 link-local addresses on PPP links. + + It also specifies the conditions for performing Duplicate Address + Detection on IPv6 global unicast addresses configured for PPP links + either through stateful or stateless address autoconfiguration. + + This document obsoletes RFC 2472. + + + + + + + + + + + + + + + + + +Varada, et al. Standards Track [Page 1] + +RFC 5072 IP Version 6 over PPP September 2007 + + +Table of Contents + + 1. Introduction ....................................................2 + 1.1. Specification of Requirements ..............................3 + 2. Sending IPv6 Datagrams ..........................................3 + 3. A PPP Network Control Protocol for IPv6 .........................3 + 4. IPV6CP Configuration Options ....................................4 + 4.1. Interface Identifier .......................................4 + 5. Stateless Autoconfiguration and Link-Local Addresses ............9 + 6. Security Considerations ........................................11 + 7. IANA Considerations ............................................11 + 8. Acknowledgments ................................................11 + 9. References .....................................................12 + 9.1. Normative References ......................................12 + 9.2. Informative references ....................................12 + Appendix A: Global Scope Addresses................................14 + Appendix B: Changes from RFC-2472.................................14 + +1. Introduction + + PPP has three main components: + + 1) A method for encapsulating datagrams over serial links. + + 2) A Link Control Protocol (LCP) for establishing, configuring, and + testing the data-link connection. + + 3) A family of Network Control Protocols (NCPs) for establishing and + configuring different network-layer protocols. + + In order to establish communications over a point-to-point link, each + end of the PPP link must first send LCP packets to configure and test + the data link. After the link has been established and optional + facilities have been negotiated as needed by the LCP, PPP must send + NCP packets to choose and configure one or more network-layer + protocols. Once each of the chosen network-layer protocols has been + configured, datagrams from each network-layer protocol can be sent + over the link. + + In this document, the NCP for establishing and configuring the IPv6 + over PPP is referred to as the IPv6 Control Protocol (IPV6CP). + + The link will remain configured for communications until explicit LCP + or NCP packets close the link down, or until some external event + occurs (power failure at the other end, carrier drop, etc.). + + This document obsoletes the earlier specification from RFC 2472 [7]. + Changes from RFC 2472 are listed in Appendix B. + + + +Varada, et al. Standards Track [Page 2] + +RFC 5072 IP Version 6 over PPP September 2007 + + +1.1. Specification of Requirements + + In this document, several words are used to signify the requirements + of the specification. + + 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 [6]. + +2. Sending IPv6 Datagrams + + Before any IPv6 packets may be communicated, PPP MUST reach the + network-layer protocol phase, and the IPv6 Control Protocol MUST + reach the Opened state. + + Exactly one IPv6 packet is encapsulated in the Information field of + PPP Data Link Layer frames where the Protocol field indicates Type + hex 0057 (Internet Protocol Version 6). + + The maximum length of an IPv6 packet transmitted over a PPP link is + the same as the maximum length of the Information field of a PPP data + link layer frame. PPP links supporting IPv6 MUST allow the + information field to be at least as large as the minimum link MTU + size required for IPv6 [2]. + +3. A PPP Network Control Protocol for IPv6 + + The IPv6 Control Protocol (IPV6CP) is responsible for configuring, + enabling, and disabling the IPv6 protocol modules on both ends of the + point-to-point link. IPV6CP uses the same packet exchange mechanism + as the LCP. IPV6CP packets may not be exchanged until PPP has + reached the network-layer protocol phase. IPV6CP packets that are + received before this phase is reached should be silently discarded. + + The IPv6 Control Protocol is exactly the same as the LCP [1] with the + following exceptions: + + Data Link Layer Protocol Field + + Exactly one IPV6CP packet is encapsulated in the Information + field of PPP Data Link Layer frames where the Protocol field + indicates type hex 8057 (IPv6 Control Protocol). + + + + + + + + + +Varada, et al. Standards Track [Page 3] + +RFC 5072 IP Version 6 over PPP September 2007 + + + Code field + + Only Codes 1 through 7 (Configure-Request, Configure-Ack, + Configure-Nak, Configure-Reject, Terminate-Request, Terminate- + Ack and Code-Reject) are used. Other Codes should be treated + as unrecognized and should result in Code-Rejects. + + Timeouts + + IPV6CP packets may not be exchanged until PPP has reached the + network-layer protocol phase. An implementation should be + prepared to wait for Authentication and Link Quality + Determination to finish before timing out waiting for a + Configure-Ack or other response. It is suggested that an + implementation give up only after user intervention or a + configurable amount of time. + + Configuration Option Types + + IPV6CP has a distinct set of Configuration Options. + +4. IPV6CP Configuration Options + + IPV6CP Configuration Options allow negotiation of desirable IPv6 + parameters. IPV6CP uses the same Configuration Option format defined + for LCP [1] but with a separate set of Options. If a Configuration + Option is not included in a Configure-Request packet, the default + value for that Configuration Option is assumed. + + Up-to-date values of the IPV6CP Option Type field are specified in + the online database of "Assigned Numbers" maintained at IANA [9]. + The current value assignment is as follows: + + 1 Interface-Identifier + + The only IPV6CP option defined in this document is the interface + identifier. Any other IPV6CP configuration options that can be + defined over time are to be defined in separate documents. + +4.1. Interface Identifier + + Description + + This Configuration Option provides a way to negotiate a unique, 64- + bit interface identifier to be used for the address autoconfiguration + [3] at the local end of the link (see Section 5). A Configure- + Request MUST contain exactly one instance of the interface-identifier + option [1]. The interface identifier MUST be unique within the PPP + + + +Varada, et al. Standards Track [Page 4] + +RFC 5072 IP Version 6 over PPP September 2007 + + + link; i.e., upon completion of the negotiation, different interface- + identifier values are to be selected for the ends of the PPP link. + The interface identifier may also be unique over a broader scope. + + Before this Configuration Option is requested, an implementation + chooses its tentative interface identifier. The non-zero value of + the tentative interface identifier SHOULD be chosen such that the + value is unique to the link and, preferably, consistently + reproducible across initializations of the IPV6CP finite state + machine (administrative Close and reOpen, reboots, etc.). The + rationale for preferring a consistently reproducible unique interface + identifier to a completely random interface identifier is to provide + stability to global scope addresses (see Appendix A) that can be + formed from the interface identifier. + + Assuming that interface identifier bits are numbered from 0 to 63 in + canonical bit order, where the most significant bit is the bit number + 0, the bit number 6 is the "u" bit (universal/local bit in IEEE + EUI-64 [4] terminology), which indicates whether or not the interface + identifier is based on a globally unique IEEE identifier (EUI-48 or + EUI-64 [4])(see case 1 below). It is set to one (1) if a globally + unique IEEE identifier is used to derive the interface identifier, + and it is set to zero (0) otherwise. + + The following are methods for choosing the tentative interface + identifier in the preference order: + + 1) If an IEEE global identifier (EUI-48 or EUI-64) is available + anywhere on the node, it should be used to construct the tentative + interface identifier due to its uniqueness properties. When + extracting an IEEE global identifier from another device on the + node, care should be taken that the extracted identifier is + presented in canonical ordering [14]. + + The only transformation from an EUI-64 identifier is to invert the + "u" bit (universal/local bit in IEEE EUI-64 terminology). + + For example, for a globally unique EUI-64 identifier of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + + + +Varada, et al. Standards Track [Page 5] + +RFC 5072 IP Version 6 over PPP September 2007 + + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" is + the group/individual bit, and "e" are the bits of the extension + identifier, the IPv6 interface identifier would be of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + + |cccccc1gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + The only change is inverting the value of the universal/local bit. + + In the case of a EUI-48 identifier, it is first converted to the + EUI-64 format by inserting two bytes, with hexa-decimal values of + 0xFF and 0xFE, in the middle of the 48-bit MAC (between the + company_id and extension identifier portions of the EUI-48 value). + For example, for a globally unique 48-bit EUI-48 identifier of the + form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4| + |0 5|6 1|2 7| + +----------------+----------------+----------------+ + |cccccc0gcccccccc|cccccccceeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+ + + where "c" are the bits of the assigned company_id, "0" is the + value of the universal/local bit to indicate global scope, "g" is + the group/individual bit, and "e" are the bits of the extension + identifier, the IPv6 interface identifier would be of the form: + + most-significant least-significant + bit bit + |0 1|1 3|3 4|4 6| + |0 5|6 1|2 7|8 3| + +----------------+----------------+----------------+----------------+ + + |cccccc1gcccccccc|cccccccc11111111|11111110eeeeeeee|eeeeeeeeeeeeeeee| + +----------------+----------------+----------------+----------------+ + + 2) If an IEEE global identifier is not available, a different source + of uniqueness should be used. Suggested sources of uniqueness + include link-layer addresses, machine serial numbers, et cetera. + + + +Varada, et al. Standards Track [Page 6] + +RFC 5072 IP Version 6 over PPP September 2007 + + + In this case, the "u" bit of the interface identifier MUST be set + to zero (0). + + 3) If a good source of uniqueness cannot be found, it is recommended + that a random number be generated. In this case, the "u" bit of + the interface identifier MUST be set to zero (0). + + Good sources [1] of uniqueness or randomness are required for the + interface identifier negotiation to succeed. If neither a unique + number nor a random number can be generated, it is recommended that a + zero value be used for the interface identifier transmitted in the + Configure-Request. In this case, the PPP peer may provide a valid + non-zero interface identifier in its response as described below. + Note that if at least one of the PPP peers is able to generate + separate non-zero numbers for itself and its peer, the identifier + negotiation will succeed. + + When a Configure-Request is received with the Interface-Identifier + Configuration Option and the receiving peer implements this option, + the received interface identifier is compared with the interface + identifier of the last Configure-Request sent to the peer. Depending + on the result of the comparison, an implementation MUST respond in + one of the following ways: + + If the two interface identifiers are different but the received + interface identifier is zero, a Configure-Nak is sent with a non-zero + interface-identifier value suggested for use by the remote peer. + Such a suggested interface identifier MUST be different from the + interface identifier of the last Configure-Request sent to the peer. + It is recommended that the value suggested be consistently + reproducible across initializations of the IPV6CP finite state + machine (administrative Close and reOpen, reboots, etc). The "u" + (universal/local) bit of the suggested identifier MUST be set to zero + (0) regardless of its source unless the globally unique EUI-48/EUI-64 + derived identifier is provided for the exclusive use by the remote + peer. + + If the two interface identifiers are different and the received + interface identifier is not zero, the interface identifier MUST be + acknowledged, i.e., a Configure-Ack is sent with the requested + interface identifier, meaning that the responding peer agrees with + the interface identifier requested. + + If the two interface identifiers are equal and are not zero, + Configure-Nak MUST be sent specifying a different non-zero + interface-identifier value suggested for use by the remote peer. It + is recommended that the value suggested be consistently reproducible + across initializations of the IPV6CP finite state machine + + + +Varada, et al. Standards Track [Page 7] + +RFC 5072 IP Version 6 over PPP September 2007 + + + (administrative Close and reOpen, reboots, etc). The "u" + (universal/local) bit of the suggested identifier MUST be set to zero + (0) regardless of its source unless the globally unique EUI-48/EUI-64 + derived identifier is provided for the exclusive use by the remote + peer. + + If the two interface identifiers are equal to zero, the interface + identifier's negotiation MUST be terminated by transmitting the + Configure-Reject with the interface-identifier value set to zero. In + this case, a unique interface identifier cannot be negotiated. + + If a Configure-Request is received with the Interface-Identifier + Configuration Option and the receiving peer does not implement this + option, Configure-Reject is sent. + + A new Configure-Request SHOULD NOT be sent to the peer until normal + processing would cause it to be sent (that is, until a Configure-Nak + is received or the Restart timer runs out [1]). + + A new Configure-Request MUST NOT contain the interface-identifier + option if a valid Interface-Identifier Configure-Reject is received. + + Reception of a Configure-Nak with a suggested interface identifier + different from that of the last Configure-Nak sent to the peer + indicates a unique interface identifier. In this case, a new + Configure-Request MUST be sent with the identifier value suggested in + the last Configure-Nak from the peer. But if the received interface + identifier is equal to the one sent in the last Configure-Nak, a new + interface identifier MUST be chosen. In this case, a new Configure- + Request SHOULD be sent with the new tentative interface identifier. + This sequence (transmit Configure-Request, receive Configure-Request, + transmit Configure-Nak, receive Configure-Nak) might occur a few + times, but it is extremely unlikely to occur repeatedly. More + likely, the interface identifiers chosen at either end will quickly + diverge, terminating the sequence. + + If negotiation of the interface identifier is required, and the peer + did not provide the option in its Configure-Request, the option + SHOULD be appended to a Configure-Nak. The tentative value of the + interface identifier given must be acceptable as the remote interface + identifier; i.e., it should be different from the identifier value + selected for the local end of the PPP link. The next Configure- + Request from the peer may include this option. If the next + Configure-Request does not include this option, the peer MUST NOT + send another Configure-Nak with this option included. It should + assume that the peer's implementation does not support this option. + + + + + +Varada, et al. Standards Track [Page 8] + +RFC 5072 IP Version 6 over PPP September 2007 + + + By default, an implementation SHOULD attempt to negotiate the + interface identifier for its end of the PPP connection. + + A summary of the Interface-Identifier Configuration Option format is + shown below. The fields are transmitted from left to right. + + 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 | Interface-Identifier (MS Bytes) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Identifier (cont) + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Interface-Identifier (LS Bytes) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Type + + 1 + + Length + + 10 + + Interface-Identifier + + The 64-bit interface identifier, which is very likely to be + unique on the link, or zero if a good source of uniqueness + cannot be found. + + Default + + If no valid interface identifier can be successfully + negotiated, no default interface-identifier value should be + assumed. The procedures for recovering from such a case are + unspecified. One approach is to manually configure the + interface identifier of the interface. + +5. Stateless Autoconfiguration and Link-Local Addresses + + The interface identifier of IPv6 unicast addresses [5] of a PPP + interface SHOULD be negotiated in the IPV6CP phase of the PPP + connection setup (see Section 4.1). If no valid interface identifier + has been successfully negotiated, procedures for recovering from such + a case are unspecified. One approach is to manually configure the + interface identifier of the interface. + + + + + +Varada, et al. Standards Track [Page 9] + +RFC 5072 IP Version 6 over PPP September 2007 + + + The negotiated interface identifier is used by the local end of the + PPP link to autoconfigure an IPv6 link-local unicast address for the + PPP interface. However, it SHOULD NOT be assumed that the same + interface identifier is used in configuring global unicast addresses + for the PPP interface using IPv6 stateless address autoconfiguration + [3]. The PPP peer MAY generate one or more interface identifiers, + for instance, using a method described in [8], to autoconfigure one + or more global unicast addresses. + + As long as the interface identifier is negotiated in the IPV6CP phase + of the PPP connection setup, it is redundant to perform duplicate + address detection (DAD) as a part of the IPv6 Stateless Address + Autoconfiguration protocol [3] on the IPv6 link-local address + generated by the PPP peer. It may also be redundant to perform DAD + on any global unicast addresses configured (using an interface + identifier that is either negotiated during IPV6CP or generated, for + instance, as per [8]) for the interface as part of the IPv6 Stateless + Address Autoconfiguration protocol [3] provided that the following + two conditions are met: + + 1) The prefixes advertised through the Router Advertisement + messages by the access router terminating the PPP link are + exclusive to the PPP link. + + 2) The access router terminating the PPP link does not + autoconfigure any IPv6 global unicast addresses from the + prefixes that it advertises. + + Therefore, it is RECOMMENDED that for PPP links with the IPV6CP + interface-identifier option enabled and satisfying the aforementioned + two conditions, the default value of the DupAddrDetectTransmits + autoconfiguration variable [3] is set to zero by the system + management. 3GPP2 networks are an example of a technology that uses + PPP to enable a host to obtain an IPv6 global unicast address and + satisfies the aforementioned two conditions [10]. 3GPP networks are + another example ([11] [13]). + + Link-local addresses + + Link-local addresses of PPP interfaces have the following format: + + | 10 bits | 54 bits | 64 bits | + +----------+------------------------+-----------------------------+ + |1111111010| 0 | Interface-Identifier | + +----------+------------------------+-----------------------------+ + + + + + + +Varada, et al. Standards Track [Page 10] + +RFC 5072 IP Version 6 over PPP September 2007 + + + The most significant 10 bits of the address is the Link-Local prefix + FE80::. 54 zero bits pad out the address between the Link-Local + prefix and the interface-identifier fields. + +6. Security Considerations + + Lack of link security, such as authentication, trigger the security + concerns raised in [3] when the stateless address autoconfiguration + method is employed for the generation of global unicast IPv6 + addresses out of interface identifiers that are either negotiated + through the IPV6CP or generated, for instance, using a method + described in [8]. Thus, the mechanisms that are appropriate for + ensuring PPP link security are addressed below, together with the + reference to a generic threat model. + + The mechanisms that are appropriate for ensuring PPP link Security + are: 1) Access Control Lists that apply filters on traffic received + over the link for enforcing admission policy, 2) an Authentication + protocol that facilitates negotiations between peers [15] to select + an authentication method (e.g., MD5 [16]) for validation of the peer, + and 3) an Encryption protocol that facilitates negotiations between + peers to select encryption algorithms (or crypto-suites) to ensure + data confidentiality [17]. + + There are certain threats associated with peer interactions on a PPP + link even with one or more of the above security measures in place. + For instance, using the MD5 authentication method [16] exposes one to + replay attack, where an attacker could intercept and replay a + station's identity and password hash to get access to a network. The + user of this specification is advised to refer to [15], which + presents a generic threat model, for an understanding of the threats + posed to the security of a link. The reference [15] also gives a + framework to specify requirements for the selection of an + authentication method for a given application. + +7. IANA Considerations + + The IANA has assigned value 1 for the Type field of the IPv6 datagram + interface-identifier option specified in this document. The current + assignment is up-to-date at [9]. + +8. Acknowledgments + + This document borrows from the Magic-Number LCP option and as such is + partially based on previous work done by the PPP working group. + + The editor is grateful for the input provided by members of the IPv6 + community in the spirit of updating RFC 2472. Thanks, in particular, + + + +Varada, et al. Standards Track [Page 11] + +RFC 5072 IP Version 6 over PPP September 2007 + + + go to Pete Barany and Karim El Malki for their technical + contributions. Also, thanks to Alex Conta for a thorough review, + Stephen Kent for helping with security aspects, and Spencer Dawkins + and Pekka Savola for the nits. Finally, the author is grateful to + Jari Arkko for his initiation to bring closure to this specification. + +9. References + +9.1. Normative References + + [1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, + RFC 1661, July 1994. + + [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) + Specification", RFC 2460, December 1998. + + [3] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address + Autoconfiguration", RFC 4862, September 2007. + + [4] IEEE, "Guidelines For 64-bit Global Identifier (EUI-64)", + http://standards.ieee.org/regauth/oui/tutorials/EUI64.html + + [5] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + + [7] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, + December 1998. + + [8] Narten T., Draves, R., and S. Krishnan, "Privacy Extensions for + Stateless Address Autoconfiguration in IPv6", RFC 4941, + September 2007. + +9.2. Informative references + + [9] IANA, "Assigned Numbers," http://www.iana.org/numbers.html + + [10] 3GPP2 X.S0011-002-C v1.0, "cdma2000 Wireless IP Network + Standard: Simple IP and Mobile IP Access Services," September + 2003. + + [11] 3GPP TS 29.061 V6.4.0, "Interworking between the Public Land + Mobile Network (PLMN) Supporting packet based services and + Packet Data Networks (PDN) (Release 6)," April 2005. + + + + + +Varada, et al. Standards Track [Page 12] + +RFC 5072 IP Version 6 over PPP September 2007 + + + [12] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6)", RFC 3315, July 2003. + + [13] 3GPP TS 23.060 v6.8.0, "General Packet Radio Service (GPRS); + Service description; Stage 2 (Release 6)," March 2005. + + [14] Narten, T. and C. Burton, "A Caution On The Canonical Ordering + Of Link-Layer Addresses", RFC 2469, December 1998. + + [15] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. + Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC + 3748, June 2004. + + [16] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April + 1992. + + [17] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC + 1968, June 1996. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Varada, et al. Standards Track [Page 13] + +RFC 5072 IP Version 6 over PPP September 2007 + + +Appendix A: Global Scope Addresses + + A node on the PPP link creates global unicast addresses either + through stateless or stateful address autoconfiguration mechanisms. + In the stateless address autoconfiguration [3], the node relies on + sub-net prefixes advertised by the router via the Router + Advertisement messages to obtain global unicast addresses from an + interface identifier. In the stateful address autoconfiguration, the + host relies on a Stateful Server, like DHCPv6 [12], to obtain global + unicast addresses. + +Appendix B: Changes from RFC 2472 + + The following changes were made from RFC 2472 "IPv6 over PPP": + + - Minor updates to Sections 3 and 4 + + - Updated the text in Section 4.1 to include the reference to + Appendix A and minor text clarifications. + + - Removed Section 4.2 on IPv6-Compression-Protocol based on IESG + recommendation, and created a new standards-track document to + cover negotiation of the IPv6 datagram compression protocol using + IPV6CP. + + - Updated the text in Section 5 to: (a) allow the use of one or more + interface identifiers generated by a peer, in addition to the use + of interface identifier negotiated between peers of the link, in + the creation of global unicast addresses for the local PPP + interface, and (b) identify cases against the DAD of created non- + link-local addresses. + + - Added new and updated references. + + - Added Appendix A + + + + + + + + + + + + + + + + +Varada, et al. Standards Track [Page 14] + +RFC 5072 IP Version 6 over PPP September 2007 + + +Authors' Addresses + + Dimitry Haskin + Ed Allen + + Srihari Varada (Editor) + TranSwitch Corporation + 3 Enterprise Dr. + Shelton, CT 06484. US. + + Phone: +1 203 929 8810 + EMail: varada@ieee.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Varada, et al. Standards Track [Page 15] + +RFC 5072 IP Version 6 over PPP September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Varada, et al. Standards Track [Page 16] + |