I'm sponsoring this open fast-track request for myself. The timer is set to 11/03/2006.
Yes, there's a substantial amount of material here for a fast-track case, but I intentionally included all of the details I could muster. The subset of crucial items (for those pressed for time) are included in the section labeled "Solution." For those viewing this case externally, the referenced background materials should make their way to the following location as soon as the synchronization script runs. (It should happen overnight.) http://www.opensolaris.org/os/community/arc/caselog/2006/597/ (A reminder: if you would like to comment, please stay on-topic for the project as presented. Other material should go directly to me or to networking-discuss without including 'psarc-ext'.) Background Solaris currently includes an IPv4 DHCP client and server implementation. A key feature of the DHCP client implementation is that it integrates with Solaris-specific internal processes, including IP interface configuration, default route establishment, DNS configuration, and setting the system node name. Key features of the DHCP server are the structure of the database and the administrative interfaces provided for managing addresses. Solaris integration is still important for that separate implementation, but it isn't as significant as it is for the client. IPv6 has a counterpart protocol called DHCPv6, which is described in RFC 3315 (included in the materials directory). This protocol is conceptually similar from a high level, but operates in a slightly different manner from IPv4 DHCP, and has its own set of options. Solaris does not currently support DHCPv6. Problem As CR 6464136 describes, Solaris has an urgent need for a DHCPv6 client-side implementation. Because it must integrate tightly with Solaris proprietary interfaces, and should work with the existing IPv4 DHCP, we require a solution tailored to Solaris. Although a server-side implementation would be helpful as well, the need for that feature is not as well understood at this time, and is not as urgent. A wider, or at least distinct, range of possible solutions are available for that problem, and a future project will examine the options. This isn't that project. Solution This project adds support to the existing 'dhcpagent' daemon for the client side of DHCPv6, as described in RFCs 3315, 2461, and 2462. The project asserts a "patch/micro" release binding and the interfaces have stability as described below: DHCPv6 Protocol Committed RFC 3315 dhcpv6-client Committed 546/udp services(4) dhcpv6-server Committed 547/udp services(4) /etc/default/dhcpagent Committed Syntax extension /etc/dhcp/inittabv6 Committed /etc/dhcp/eventhookv6 Committed /etc/dhcp/duid Project Private Stable Unique ID /etc/dhcp/iaid Project Private /etc/dhcp/<if>.dh6 Project Private Lease cache <number>,<data...> Committed DUID text encoding Unumber24, IPv6, Duid, Domain Committed inittab types DHCP_HOSTCONF_MAGICV6 Project Private value 0x44484302 StatefulAddrConf Committed ndpd.conf option DUID generation Committed System identifier IAID generation Uncommitted Interface identifier dhcpinfo -v option Committed Select version dhcpinfo option names Committed DHCPv6 options snoop dhcp6 keyword Committed Filter expression snoop DHCPv6 output Uncommitted netstat -D output Uncommitted Add -f inet6 behavior ifconfig inet6 extension Committed dhcpagent control DHCPv4 Alias Enhancement Committed RFC 4361 CONFIRMING, DECLINING, RELEASING Committed New DHCP states <netinet/dhcpv6.h> Committed DHCPv6 definitions libdhcpagent Consolidation Private libdhcputil Consolidation Private ARPHDR_{FRAME,ATM,HDLC,FC, <net/if_arp.h> and IPATM,TUNNEL} Committed <netinet/arp.h> source address selectin Committed See 'Details' These changes are further detailed in the man page diffs in the materials directory, as well as the 'Details' section below. The important changes for Solaris users and administrators are: - Use of DHCPv6, unlike DHCPv4, is automatic, as specified in the RFCs. It works in a way that's analogous to the existing IPv6 automatic address configuration. Explicit configuration is required to turn it _off_ rather than _on_. - DHCPv6 negotiates system parameters (such as DNS addresses) on a per-physical-interface basis, rather than on a per-logical- interface basis as with DHCPv4. This means that you don't (and can't) configure an individual "hme0:5" interface to run DHCPv6. - DHCPv6 corrects some fundamental design errors present in DHCPv4. It doesn't pretend to be a routing protocol, and it doesn't play games with the system node name. Users expecting those odd side-effects may be disappointed. Security Like the existing IPv6 stateless address autoconfiguration, stateful (DHCPv6) address autoconfiguration is enabled by default on all IPv6 interfaces, per the relevant standards. IPv6 itself is not currently enabled on any interface by default, but may be in the future. The behavior of DHCPv6 is nearly identical to the behavior of the existing IPv6 stateless address autoconfiguration. For stateless address autoconfiguration, any local router advertising an IPv6 prefix with the 'A' bit set will cause all clients to configure addresses within that prefix. Thus, anyone with the ability to forge such a message can cause systems on the network to configure addresses -- as though by invoking the privileged 'ifconfig addif' command -- to any network desired. The same is true for DHCPv6. Such an attacker can cause the client systems to run DHCPv6 when not desired, and to configure addresses on arbitrary networks. In both cases, the /etc/inet/ndpd.conf file can be used to disable this default behavior if desired (StatelessAddrConf and StatefulAddrConf). DHCPv6 opens up the possibility that such an attacker can also set the address to any value desired. That ability is also at least in theory possible with stateless configuration by forcing conflicts, though substantially more difficult. In any event, the effect of this possible attack seems negligible compared with other attacks that are possible with the same level of network access, such as forging NDP messages. DHCPv6, like DHCPv4, also opens up the ability for an attacker to present unwanted configuration information to an IPv6 system. This project will not be acting on any of the learned information (other than addresses), and it will be the responsibility of other projects that consume dhcpinfo(1) information to evaluate the security implications. Missing Items Besides general server-side and relay operation, the following items are not expected to be present in the project, and the project is assumed to be complete without them. Nothing the project is doing precludes any future project from dealing with these. Rapid Commit - this option allows the DHCPv6 client to skip directly from the SELECTING state (sending Solicit) to the BOUND state. It reduces the exchange from two round-trips to one, at the cost of slightly more complexity. As it is just a performance optimization, it won't be included for this first project. Temporary Addresses - this option allows the DHCPv6 server to supply RFC 3041 "privacy" (temporary) addresses to the client. There are no known implementations of this feature, and it's unclear why users would want to do this as central administration seems at odds with privacy. Prefix Delegation - this allows the server to delegate control of an entire IPv6 prefix, rather than an address, to a client. This is primarily intended for use in simple home routers, where the box has exactly two interfaces: one connected to an ISP, and the other to a home network that needs addresses. This isn't currently a target usage for Solaris. Reconfigure - this message, sent by the server, causes the client to enter into RENEWING state, rather than waiting for the next timer. Network administrators typically don't need this feature, as they just set reasonable DHCP T1/T2 and lease timers, and allow the clients to age away the data during a transition. In addition, the feature also requires significant added complexity (it depends on authentication) and risk. Given that it's merely an optimization of a case that's handled transparently by rational (make-before-break) administrative procedures today, it seems unnecessary. Authentication - this feature allows the client and server to authenticate one another's messages. It relies on an unspecified key distribution mechanism and involves significant complexity. Clients must have at least one key per server, and servers must have at least one key per client, plus some means for bounding the lifetime of keys. Given that an important goal of DHCPv6 is to allow for simple, automatic system configuration, the need for a manually administered key infrastructure seems at odds with the purpose of the protocol. Zones - the new DUID scheme and RFC 4361 support make the use of DHCP for both IPv4 and IPv6 within regular shared-stack Zones fairly trivial. However, this support will not be delivered by this project. Boot and Install - neither OBP nor GRUB supports booting or installing the system via IPv6. This project is not adding support for booting or installing the system using DHCPv6 as the underlying IPv6 support is missing. The project will not prohibit such support from being added in the future. Configuration - the other parameters fetched from the DHCPv6 server will be made available via dhcpinfo(1). No other action will be taken on these. Users may create their own /etc/dhcp/eventhookv6 script to handle the parameters in any manner desired. A future project (likely "Network Automagic" - NWAM) will deal with these parameters in a more comprehensive manner. Primary - selection of a primary interface will follow the same mechanism as IPv4. It is at least theoretically possible that someone may want to have one interface designated as primary for IPv4, with a different one for IPv6, or may wish to designate an interface as primary for IPv6 without running DHCP on any IPv4 interface, but these things will not be supported. It is likely that the future NWAM project will be making significant changes in this area, and removing the need for a "primary" interface. Details The existing Solaris dhcpagent implementation will be extended to cover IPv6 and DHCPv6, as described in RFC 3315. This represents a substantial overhaul of the dhcpagent design. The currently-known internal details of those changes are documented in the 'detailed.txt' file in the materials directory. Among the highlights, dhcpagent currently uses a single data structure to represent a logical interface, a leased address, a set of configuration parameters, the user-interface IPC state, the file descriptors used for DLPI and socket I/O, and the on-the-wire negotiation state. This will be broken up into separate structures that represent these items and allow dhcpagent to deal with the DHCPv6 concept of having multiple addresses per IA and multiple IAs per client/server exchange. The existing Solaris in.ndpd implementation will be enhanced to detect the flags specified in RFC 2462 that determine when to run DHCPv6, and will invoke DHCPv6 automatically when necessary. It will do this using the existing libdhcpagent Consolidation Private library also used by ifconfig(1M). It will also get a new StatefulAddrConf flag for the ndpd.conf file, which will work in exactly the same way as the existing StatelessAddrConf flag, but for stateful (DHCPv6) addresses. The libdhcpagent and libdhcputil Consolidation Private libraries will get new flags and functions (not detailed here) to select IPv6 operation and handle DHCPv6 packets and options. Snoop(1M) will get a DHCPv6 decoder and a new "dhcp6" filter keyword. (DHCPv6 is the formal name of the protocol, but the existing keywords are inet6, ip6, and icmp6, so I will use "dhcp6" for consistency.) The DHCPv6 decoder output will be similar to the existing DHCP output. The ifconfig(1M), dhcpinfo(1), and netstat(1M) utilities will have minor updates to allow for both IPv4 and IPv6 DHCP. Ifconfig will allow the existing "inet6" keyword to be used with the existing "dhcp" family of keywords. Dhcpinfo will get a new "-v" option that can select DHCP version 4 or 6. Netstat will allow the existing "-f inet6" option to work with the existing -D (DHCP) option. (In fact, it already does do this; it'll just start working.) The restriction on using ifconfig(1M) for IPv4 logical interfaces will be lifted. This turns out to be a trivial enhancement due to RFC 4361 and the addition of DUID and IAID support for DHCPv6. This will eventually make DHCP support for regular Zones a simple matter, though that is not part of this project. The /etc/services file will gain the IANA-specified "dhcpv6-client" and "dhcpv6-server" keywords, which select 546/udp and 547/udp, respectively. I won't be adding the IANA-reserved TCP versions for these services, as DHCPv6 doesn't run over TCP and the reservation makes no operational sense. Rule 8 for the IPv6 address selection criteria (see "IPv6 Default Address Selection" PSARC 2002/390) will be amended to include a tie-breaker that prefers DHCP and manually configured addresses above statelessly autoconfigured addresses. This change falls within the existing Rule 8 language allowing implementation- specific knowledge to be used, and will allow predictable system behavior in some corner cases involving multiple addresses in the same prefix. The details of this are being discussed within the IETF ipv6 working group now. Technical alternatives considered for this project included: 1. Porting in some third-party DHCPv6 client. Though attractive from a high level (what could be better than free code?), this one runs into trouble with the details. Unless it were modified to fit in with in.ndpd, ifconfig, and the other existing Solaris utilities, it would stand as a bag on the side of the system and pose a large hazard for future projects, such as NWAM. Unfortunately, in comparison to the generic code that handles the packets, the code that links it into the system is substantial. Thus, the savings is negligible and the cost is high. 2. Implementing as part of in.ndpd This is reasonable, given that in.ndpd already manages both stateless autoconfiguration and temporary addresses. However, to avoid code duplication, it means adapting in.ndpd to _receiving_ the IPC and DHCPv6 messages and using the other mechanisms already developed for dhcpagent. This work is non-trivial, still involves duplication, and doesn't fit with the current design. Other Implementations NEC has a portable client/server/relay implementation, owns the dhcpv6.org domain, and runs ETSI interoperability tests. The WIDE-DHCPv6 (formerly KAME) client/server implementation works on BSD and Linux systems. It does not currently run on Solaris. (It claims to support all "POSIX" systems, but has clear dependencies on a BSD-like kernel through <sys/queue.h> and <err.h>. It's not portable.) Dibbler client/server/relay implementation is available for Linux and Windows. Windows Vista and Longhorn include a DHCPv6 client. Windows CE includes something Microsoft calls "DHCPv6-Lite," and which appears to be option-only (stateless) DHCPv6. AIX V5r3 includes DHCPv6 client/server/relay support. The origin of the code is unclear. HP/UX 11i has a web-download DHCPv6 client/server/relay implementation. Apple does not yet have its own implementation. Reference Documents The materials directory has original, new, and context diffs for the following man pages. dhcp(5) dhcpinfo(1) ndpd.conf(4) dhcp_inittab(4) ifconfig(1m) netstat(1m) dhcpagent(1m) in.ndpd(1m) snoop(1m) Copies of the following RFCs are in the materials directory. (In ARC terms, these are all "Standard" -- they're unchanging and unchangable external references that document standards body action. The attributes "DRAFT" and "PROPOSED" represent different maturity levels based on reports of interoperability and deployment.) 2461 Neighbor Discovery for IP Version 6 (IPv6). T. Narten, E. Nordmark, W. Simpson. December 1998. (Format: TXT=222516 bytes) (Obsoletes RFC1970) (Updated by RFC4311) (Status: DRAFT STANDARD) 2462 IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. December 1998. (Format: TXT=61210 bytes) (Obsoletes RFC1971) (Status: DRAFT STANDARD) 3315 Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed., J. Bound, B. Volz, T. Lemon, C. Perkins, M. Carney. July 2003. (Format: TXT=231402 bytes) (Updated by RFC4361) (Status: PROPOSED STANDARD) 3319 Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers. H. Schulzrinne, B. Volz. July 2003. (Format: TXT=14444 bytes) (Status: PROPOSED STANDARD) 3646 DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). R. Droms, Ed.. December 2003. (Format: TXT=13312 bytes) (Status: PROPOSED STANDARD) 3898 Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6). V. Kalusivalingam. October 2004. (Format: TXT=13955 bytes) (Status: PROPOSED STANDARD) 4075 Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6. V. Kalusivalingam. May 2005. (Format: TXT=9424 bytes) (Status: PROPOSED STANDARD) 4280 Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers. K. Chowdhury, P. Yegani, L. Madour. November 2005. (Format: TXT=23001 bytes) (Status: PROPOSED STANDARD) 4361 Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4). T. Lemon, B. Sommerfeld. February 2006. (Format: TXT=28009 bytes) (Updates RFC2131, RFC2132, RFC3315) (Status: PROPOSED STANDARD) _______________________________________________ networking-discuss mailing list [email protected]
