From carlsonj@phorcys.east.sun.com Fri Oct 27 10:59:32 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9RHxWJi016474 for ; Fri, 27 Oct 2006 10:59:32 -0700 (PDT) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9RHxVf06682; Fri, 27 Oct 2006 11:59:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7T001073B5QK00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Oct 2006 10:59:30 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7T00FOK3B5M5B0@nwk-avmta-1.sfbay.Sun.COM>; Fri, 27 Oct 2006 10:59:29 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9RI2LiV009437; Fri, 27 Oct 2006 14:02:21 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9RI2LDR009434; Fri, 27 Oct 2006 14:02:21 -0400 (EDT) Date: Fri, 27 Oct 2006 14:02:20 -0400 From: James Carlson Subject: 2006/597 DHCPv6 Client To: psarc-ext@sun.com Cc: networking-discuss@opensolaris.org, Anay Panvalkar Message-id: <17730.18860.711565.960646@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 18797 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/.dh6 Project Private Lease cache , 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 Committed DHCPv6 definitions libdhcpagent Consolidation Private libdhcputil Consolidation Private ARPHDR_{FRAME,ATM,HDLC,FC, and IPATM,TUNNEL} Committed 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 and . 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) From Darren.Moffat@Sun.COM Mon Oct 30 05:24:35 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UDOZFh020423 for ; Mon, 30 Oct 2006 05:24:35 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UDOYC18572 for <@sunmail2.sfbay.sun.com:psarc-ext@sun.com>; Mon, 30 Oct 2006 06:24:34 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7Y00L0NAKV7G00@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 05:24:31 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7Y00DM6AKT00B0@nwk-avmta-1.sfbay.Sun.COM> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 05:24:29 -0800 (PST) Received: from d1-emea-10.sun.com (d1-emea-10.sun.com [192.18.2.120] (may be forged)) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9UDOS0b002800 for ; Mon, 30 Oct 2006 13:24:28 +0000 (GMT) Received: from conversion-daemon.d1-emea-10.sun.com by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7Y00201AFUJ300@d1-emea-10.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 13:24:28 +0000 (GMT) Received: from [129.150.120.2] by d1-emea-10.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7Y003XEAKQP600@d1-emea-10.sun.com>; Mon, 30 Oct 2006 13:24:27 +0000 (GMT) Date: Mon, 30 Oct 2006 13:24:19 +0000 From: Darren J Moffat Subject: Re: 2006/597 DHCPv6 Client In-reply-to: <17730.18860.711565.960646@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: psarc-ext@Sun.COM, networking-discuss@opensolaris.org, Anay Panvalkar Message-id: <4545FD03.8040605@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 538 What is the reason for having a separate DHCP eventhook script per protocol ? This surprised me particularly given we have just gone down the path of merging things like hosts(4) and ipnodes(4) it seems very strange to add a new place where there is a distinction between v4 and v6 in a filesystem path name. I believe it would be a compatible change to have dhcpagent(4) pass 3 arguments to /etc/dhcp/eventhook instead of the current 2 (action and interface), where the new third argument indicated v4 or v6. -- Darren J Moffat From carlsonj@phorcys.east.sun.com Mon Oct 30 05:34:07 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UDY6wq020474 for ; Mon, 30 Oct 2006 05:34:07 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UDY3C02735; Mon, 30 Oct 2006 06:34:03 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7Y00M07B0K7H00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Oct 2006 05:33:56 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7Y00D2KB0J00C0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Oct 2006 05:33:55 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9UDanFp015176; Mon, 30 Oct 2006 08:36:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9UDan6L015173; Mon, 30 Oct 2006 08:36:49 -0500 (EST) Date: Mon, 30 Oct 2006 08:36:48 -0500 From: James Carlson Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <4545FD03.8040605@Sun.COM> To: Darren J Moffat Cc: Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org Message-id: <17733.65520.788121.134325@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> Status: RO Content-Length: 1636 Darren J Moffat writes: > What is the reason for having a separate DHCP eventhook script per > protocol ? > > This surprised me particularly given we have just gone down the path of > merging things like hosts(4) and ipnodes(4) it seems very strange to add > a new place where there is a distinction between v4 and v6 in a > filesystem path name. > > I believe it would be a compatible change to have dhcpagent(4) pass 3 > arguments to /etc/dhcp/eventhook instead of the current 2 (action and > interface), where the new third argument indicated v4 or v6. The reason is two-fold. First, the administrative semantics are different. With v4, you'll get per-logical interface notifications, while with v6, you won't. (Or, more precisely: the v6 notification will supply the name of the interface used for control, and won't give you the name of the individual logical interface plumbed or unplumbed by dhcpagent because it's not an administrative unit.) But the second reason is the most important one: it wouldn't be compatible. Existing eventhook scripts aren't aware that this third argument exists, so they don't know that they need to do anything special. If I added a third argument, then it would run the risk of having those existing scripts do unexpected things. I agree that it's unfortunate to fork v4 and v6 here, especially given the history, but I don't quite see a good way around it. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Moffat@Sun.COM Mon Oct 30 06:40:03 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UEe3Hx021532 for ; Mon, 30 Oct 2006 06:40:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UEe2C27903 for <@sunmail1brm.central.sun.com:psarc-ext@sun.com>; Mon, 30 Oct 2006 07:40:02 -0700 (MST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y0010DE2P3000@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Mon, 30 Oct 2006 07:40:01 -0700 (MST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y00GFRE2O24D0@brm-avmta-1.central.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@Sun.COM); Mon, 30 Oct 2006 07:40:01 -0700 (MST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9UEdxbg006060 for ; Mon, 30 Oct 2006 14:39:59 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7Y00C01DXZE200@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@Sun.COM (ORCPT psarc-ext@Sun.COM); Mon, 30 Oct 2006 14:39:59 +0000 (GMT) Received: from [129.150.120.2] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7Y0053VE2MD040@d1-emea-09.sun.com>; Mon, 30 Oct 2006 14:39:59 +0000 (GMT) Date: Mon, 30 Oct 2006 14:39:51 +0000 From: Darren J Moffat Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17733.65520.788121.134325@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Anay Panvalkar , psarc-ext@Sun.COM, networking-discuss@opensolaris.org Message-id: <45460EB7.8030704@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 576 James Carlson wrote: > But the second reason is the most important one: it wouldn't be > compatible. Existing eventhook scripts aren't aware that this third > argument exists, so they don't know that they need to do anything > special. If I added a third argument, then it would run the risk of > having those existing scripts do unexpected things. > > I agree that it's unfortunate to fork v4 and v6 here, especially given > the history, but I don't quite see a good way around it. Okay, grumble grumble, I'm convinced that this is a necessary evil. -- Darren J Moffat From meem@triplex.East.Sun.COM Mon Oct 30 07:14:01 2006 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFE1VX022321 for ; Mon, 30 Oct 2006 07:14:01 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFDvU05089; Mon, 30 Oct 2006 07:13:57 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00D03FN59K00@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:13:53 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y008PDFN4FA80@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:13:53 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id k9UFDqRJ012577; Mon, 30 Oct 2006 10:13:52 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id k9UFDqvN012574; Mon, 30 Oct 2006 10:13:52 -0500 (EST) Date: Mon, 30 Oct 2006 10:13:52 -0500 From: Peter Memishian Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17733.65520.788121.134325@gargle.gargle.HOWL> To: James Carlson Cc: Darren J Moffat , Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org Message-id: <17734.5808.125386.243499@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> Status: RO Content-Length: 899 > The reason is two-fold. > > First, the administrative semantics are different. With v4, you'll > get per-logical interface notifications, while with v6, you won't. > (Or, more precisely: the v6 notification will supply the name of the > interface used for control, and won't give you the name of the > individual logical interface plumbed or unplumbed by dhcpagent because > it's not an administrative unit.) > > But the second reason is the most important one: it wouldn't be > compatible. Existing eventhook scripts aren't aware that this third > argument exists, so they don't know that they need to do anything > special. If I added a third argument, then it would run the risk of > having those existing scripts do unexpected things. Would it be reasonable to make the V4 and V6 action/event names distinct? e.g., have each V6 event name end in a "_V6" or "6"? -- meem From carlsonj@phorcys.east.sun.com Mon Oct 30 07:19:15 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFJE5N022585 for ; Mon, 30 Oct 2006 07:19:14 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k9UFIBHg011766; Mon, 30 Oct 2006 23:19:05 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00D2HFVCKP00@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:18:48 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y008BIFV9FK70@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:18:46 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9UFLd9L015693; Mon, 30 Oct 2006 10:21:39 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9UFLd8n015690; Mon, 30 Oct 2006 10:21:39 -0500 (EST) Date: Mon, 30 Oct 2006 10:21:39 -0500 From: James Carlson Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.5808.125386.243499@triplex.East.Sun.COM> To: Peter Memishian Cc: Darren J Moffat , Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org Message-id: <17734.6275.36075.939193@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> Status: RO Content-Length: 1113 Peter Memishian writes: > > But the second reason is the most important one: it wouldn't be > > compatible. Existing eventhook scripts aren't aware that this third > > argument exists, so they don't know that they need to do anything > > special. If I added a third argument, then it would run the risk of > > having those existing scripts do unexpected things. > > Would it be reasonable to make the V4 and V6 action/event names distinct? > e.g., have each V6 event name end in a "_V6" or "6"? Yes, that'd be possible. That seems roughly equivalent to using a separate script, and you'd have to use separate logic (as the options and such that you'd ordinarily use with dhcpinfo are separate), but it's doable. Is it actually an improvement? It's not clear to me, but if others prefer this over having a separate hook script, I guess I don't have much of a preference myself. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From meem@triplex.East.Sun.COM Mon Oct 30 07:23:47 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFNkYC022665 for ; Mon, 30 Oct 2006 07:23:47 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFNgC11949; Mon, 30 Oct 2006 08:23:42 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00D1BG3FXP00@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:23:39 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y008OYG3DFHA0@nwk-avmta-2.sfbay.sun.com>; Mon, 30 Oct 2006 07:23:37 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id k9UFNbg3012611; Mon, 30 Oct 2006 10:23:37 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id k9UFNbQA012607; Mon, 30 Oct 2006 10:23:37 -0500 (EST) Date: Mon, 30 Oct 2006 10:23:36 -0500 From: Peter Memishian Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.6275.36075.939193@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org, Darren J Moffat Message-id: <17734.6392.991183.712398@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> Status: RO Content-Length: 633 > > Would it be reasonable to make the V4 and V6 action/event names distinct? > > e.g., have each V6 event name end in a "_V6" or "6"? > > Yes, that'd be possible. That seems roughly equivalent to using a > separate script, and you'd have to use separate logic (as the options > and such that you'd ordinarily use with dhcpinfo are separate), but > it's doable. > > Is it actually an improvement? It's not clear to me, but if others > prefer this over having a separate hook script, I guess I don't have > much of a preference myself. How similar are the semantics of the V6 events/actions to the V4 ones? -- meem From Darren.Moffat@Sun.COM Mon Oct 30 07:25:41 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFPfLN022779 for ; Mon, 30 Oct 2006 07:25:41 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFPd825926 for <@sunmail3.sfbay.sun.com:psarc-ext@sun.com>; Mon, 30 Oct 2006 07:25:40 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00E07G6P5500@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 07:25:37 -0800 (PST) Received: from gmp-ea-fw-1.sun.com ([129.156.42.6]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y0089FG6NFK80@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 07:25:36 -0800 (PST) Received: from d1-emea-09.sun.com ([192.18.2.119]) by gmp-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9UFPYuj013230 for ; Mon, 30 Oct 2006 15:25:34 +0000 (GMT) Received: from conversion-daemon.d1-emea-09.sun.com by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7Y00601G4BSH00@d1-emea-09.sun.com> (original mail from Darren.Moffat@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 15:25:34 +0000 (GMT) Received: from [129.150.120.2] by d1-emea-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7Y005N0G6LD040@d1-emea-09.sun.com>; Mon, 30 Oct 2006 15:25:34 +0000 (GMT) Date: Mon, 30 Oct 2006 15:25:26 +0000 From: Darren J Moffat Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.6275.36075.939193@gargle.gargle.HOWL> Sender: Darren.Moffat@Sun.COM To: James Carlson Cc: Peter Memishian , Anay Panvalkar , psarc-ext@Sun.COM, networking-discuss@opensolaris.org Message-id: <45461966.1000506@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1488 James Carlson wrote: > Peter Memishian writes: >> > But the second reason is the most important one: it wouldn't be >> > compatible. Existing eventhook scripts aren't aware that this third >> > argument exists, so they don't know that they need to do anything >> > special. If I added a third argument, then it would run the risk of >> > having those existing scripts do unexpected things. >> >> Would it be reasonable to make the V4 and V6 action/event names distinct? >> e.g., have each V6 event name end in a "_V6" or "6"? > > Yes, that'd be possible. That seems roughly equivalent to using a > separate script, and you'd have to use separate logic (as the options > and such that you'd ordinarily use with dhcpinfo are separate), but > it's doable. > > Is it actually an improvement? It's not clear to me, but if others > prefer this over having a separate hook script, I guess I don't have > much of a preference myself. I think it is a better way of expressing what I was suggesting. So we would have BIND and BIND_V6 that would be good in my opinion. The eventhook scripts I've written in the past would certainly share a lot of content between V4 and V6 but as you point out some of it does need to distinguish in the action and how to get the informaiton - but once it has the info both the V4 and V6 hook scripts I'd right would do exactly the same with it. So for me yes this is better than having two different scripts for v4 and v6. -- Darren J Moffat From Dave.Miner@Sun.COM Mon Oct 30 07:30:26 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFUQbX022926 for ; Mon, 30 Oct 2006 07:30:26 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFUPC21026 for <@sunmail3.sfbay.sun.com:psarc-ext@sun.com>; Mon, 30 Oct 2006 08:30:25 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00E0VGENF300@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 07:30:23 -0800 (PST) Received: from brmea-mail-1.sun.com ([192.18.98.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y008RGGENFHB0@nwk-avmta-2.sfbay.sun.com> for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 07:30:23 -0800 (PST) Received: from fe-amer-05.sun.com ([192.18.108.179]) by brmea-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9UFUNhC008201 for ; Mon, 30 Oct 2006 08:30:23 -0700 (MST) Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7Y00301G1PGW00@mail-amer.sun.com> (original mail from Dave.Miner@Sun.COM) for psarc-ext@sun.com (ORCPT psarc-ext@sun.com); Mon, 30 Oct 2006 08:30:23 -0700 (MST) Received: from [129.148.174.237] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7Y000GTGEL8M04@mail-amer.sun.com>; Mon, 30 Oct 2006 08:30:22 -0700 (MST) Date: Mon, 30 Oct 2006 10:30:21 -0500 From: Dave Miner Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.6275.36075.939193@gargle.gargle.HOWL> Sender: Dave.Miner@Sun.COM To: James Carlson Cc: Peter Memishian , Anay Panvalkar , psarc-ext@Sun.COM, networking-discuss@opensolaris.org, Darren J Moffat Message-id: <45461A8D.5020008@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> User-Agent: Thunderbird 1.5.0.5 (X11/20060925) Status: RO Content-Length: 1112 James Carlson wrote: > Peter Memishian writes: >> > But the second reason is the most important one: it wouldn't be >> > compatible. Existing eventhook scripts aren't aware that this third >> > argument exists, so they don't know that they need to do anything >> > special. If I added a third argument, then it would run the risk of >> > having those existing scripts do unexpected things. >> >> Would it be reasonable to make the V4 and V6 action/event names distinct? >> e.g., have each V6 event name end in a "_V6" or "6"? > > Yes, that'd be possible. That seems roughly equivalent to using a > separate script, and you'd have to use separate logic (as the options > and such that you'd ordinarily use with dhcpinfo are separate), but > it's doable. > > Is it actually an improvement? It's not clear to me, but if others > prefer this over having a separate hook script, I guess I don't have > much of a preference myself. > Structurally it seems somewhat simpler, in that you could more easily share functions between the two without having the trouble of yet a third script to include. Dave From carlsonj@phorcys.east.sun.com Mon Oct 30 07:34:14 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFYENc022961 for ; Mon, 30 Oct 2006 07:34:14 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFY9801065; Mon, 30 Oct 2006 07:34:10 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00305GKXDT00@brm-avmta-1.central.sun.com>; Mon, 30 Oct 2006 08:34:09 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y002TCGKW5960@brm-avmta-1.central.sun.com>; Mon, 30 Oct 2006 08:34:08 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9UFb2XM015858; Mon, 30 Oct 2006 10:37:02 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9UFb2d0015855; Mon, 30 Oct 2006 10:37:02 -0500 (EST) Date: Mon, 30 Oct 2006 10:37:02 -0500 From: James Carlson Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.6392.991183.712398@triplex.East.Sun.COM> To: Peter Memishian Cc: Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org, Darren J Moffat Message-id: <17734.7198.399559.192486@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> <17734.6392.991183.712398@triplex.East.Sun.COM> Status: RO Content-Length: 1179 Peter Memishian writes: > > Yes, that'd be possible. That seems roughly equivalent to using a > > separate script, and you'd have to use separate logic (as the options > > and such that you'd ordinarily use with dhcpinfo are separate), but > > it's doable. > > > > Is it actually an improvement? It's not clear to me, but if others > > prefer this over having a separate hook script, I guess I don't have > > much of a preference myself. > > How similar are the semantics of the V6 events/actions to the V4 ones? The materials/dhcpagent.1m.diff file describes the changes. The main issue is that, unlike v4, v6 manages multiple addresses with a single "session." Thus, when we do an "EXTEND," there may be some addresses added by the server, and some removed. With "EXPIRE," there may still be addresses present. The DROP and RELEASE events refer to the session. (Yes, I should probably make these things clearer in the draft man page.) -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From meem@triplex.East.Sun.COM Mon Oct 30 07:42:03 2006 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFg39T023188 for ; Mon, 30 Oct 2006 07:42:03 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFfw805361; Mon, 30 Oct 2006 07:41:59 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J7Y00307GXYPR00@brm-avmta-1.central.sun.com>; Mon, 30 Oct 2006 08:41:58 -0700 (MST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J7Y002K1GXX5980@brm-avmta-1.central.sun.com>; Mon, 30 Oct 2006 08:41:57 -0700 (MST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id k9UFfvoe012650; Mon, 30 Oct 2006 10:41:57 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id k9UFfvR3012647; Mon, 30 Oct 2006 10:41:57 -0500 (EST) Date: Mon, 30 Oct 2006 10:41:57 -0500 From: Peter Memishian Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.7198.399559.192486@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org, Darren J Moffat Message-id: <17734.7493.351001.972702@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> <17734.6392.991183.712398@triplex.East.Sun.COM> <17734.7198.399559.192486@gargle.gargle.HOWL> Status: RO Content-Length: 525 > The materials/dhcpagent.1m.diff file describes the changes. > > The main issue is that, unlike v4, v6 manages multiple addresses with > a single "session." Thus, when we do an "EXTEND," there may be some > addresses added by the server, and some removed. With "EXPIRE," there > may still be addresses present. > > The DROP and RELEASE events refer to the session. Then I'd be in support of distinct event names regardless -- at which point using a single eventhook script seems a natural fit to me. -- meem From carlsonj@phorcys.east.sun.com Mon Oct 30 07:47:36 2006 Received: from sunmail1brm.Central.Sun.COM (sunmail1brm.Central.Sun.COM [129.147.62.17]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9UFlaW5023541 for ; Mon, 30 Oct 2006 07:47:36 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail1brm.Central.Sun.COM (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k9UFlVC17026; Mon, 30 Oct 2006 08:47:31 -0700 (MST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J7Y00B03H77O600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Oct 2006 07:47:31 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J7Y00B6SH76G800@nwk-avmta-1.sfbay.Sun.COM>; Mon, 30 Oct 2006 07:47:30 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id k9UFoOud015991; Mon, 30 Oct 2006 10:50:24 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id k9UFoOo3015988; Mon, 30 Oct 2006 10:50:24 -0500 (EST) Date: Mon, 30 Oct 2006 10:50:23 -0500 From: James Carlson Subject: Re: [networking-discuss] Re: 2006/597 DHCPv6 Client In-reply-to: <17734.7493.351001.972702@triplex.East.Sun.COM> To: Peter Memishian Cc: Anay Panvalkar , psarc-ext@sun.com, networking-discuss@opensolaris.org, Darren J Moffat Message-id: <17734.7999.908687.212632@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17730.18860.711565.960646@gargle.gargle.HOWL> <4545FD03.8040605@Sun.COM> <17733.65520.788121.134325@gargle.gargle.HOWL> <17734.5808.125386.243499@triplex.East.Sun.COM> <17734.6275.36075.939193@gargle.gargle.HOWL> <17734.6392.991183.712398@triplex.East.Sun.COM> <17734.7198.399559.192486@gargle.gargle.HOWL> <17734.7493.351001.972702@triplex.East.Sun.COM> Status: RO Content-Length: 558 Peter Memishian writes: > > The DROP and RELEASE events refer to the session. > > Then I'd be in support of distinct event names regardless -- at which > point using a single eventhook script seems a natural fit to me. OK. I've changed the case state to 'waiting need spec.' I'll restart the timer once I have updated materials. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Fri Nov 3 12:54:55 2006 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA3KsttX024557 for ; Fri, 3 Nov 2006 12:54:55 -0800 (PST) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id kA3Ksp5B003868; Fri, 3 Nov 2006 12:54:52 -0800 (PST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8600605A3FEF00@brm-avmta-1.central.sun.com>; Fri, 03 Nov 2006 13:54:51 -0700 (MST) Received: from phorcys.east.sun.com ([129.148.174.143]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8600ITPA3EPBC0@brm-avmta-1.central.sun.com>; Fri, 03 Nov 2006 13:54:51 -0700 (MST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kA3Kvn98004537; Fri, 03 Nov 2006 15:57:49 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kA3KvnsN004534; Fri, 03 Nov 2006 15:57:49 -0500 (EST) Date: Fri, 03 Nov 2006 15:57:49 -0500 From: James Carlson Subject: 2006/597 DHCPv6 Client [restart] To: psarc-ext@sun.com Cc: networking-discuss@opensolaris.org, Anay Panvalkar Message-id: <17739.44365.197410.582170@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 18528 I've restarted the timer on this fast-track case; it's now set to 11/10/2006. Based on the comments received, I've merged together the eventhook feature into a single script that receives separate events for DHCPv4 and DHCPv6. The changes in the text below are trivial (simply removing the /etc/dhcp/eventhookv6 script and adding the new *6 events). The only affected man page was dhcpagent(1M), and that's been updated in the materials directory. 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/duid Project Private Stable Unique ID /etc/dhcp/iaid Project Private /etc/dhcp/.dh6 Project Private Lease cache , 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 BOUND6, EXTEND6, EXPIRE6, DROP6, INFORM, INFORM6, LOSS6, RELEASE6 Committed New eventhook events Committed DHCPv6 definitions libdhcpagent Consolidation Private libdhcputil Consolidation Private ARPHDR_{FRAME,ATM,HDLC,FC, and IPATM,TUNNEL} Committed 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/eventhook 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 and . 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) From meem@triplex.East.Sun.COM Sun Nov 5 21:16:59 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA65GwtW015581 for ; Sun, 5 Nov 2006 21:16:59 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA65Go5H019228; Mon, 6 Nov 2006 13:16:55 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8A00A09MO5SQ00@nwk-avmta-2.sfbay.sun.com>; Sun, 05 Nov 2006 21:16:53 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8A00HAFMO3M9C0@nwk-avmta-2.sfbay.sun.com>; Sun, 05 Nov 2006 21:16:52 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kA65Gp3v104124; Mon, 06 Nov 2006 00:16:51 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kA65GpuW104121; Mon, 06 Nov 2006 00:16:51 -0500 (EST) Date: Mon, 06 Nov 2006 00:16:51 -0500 From: Peter Memishian Subject: re: [networking-discuss] 2006/597 DHCPv6 Client [restart] In-reply-to: <17739.44365.197410.582170@gargle.gargle.HOWL> To: James Carlson Cc: PSARC-EXT@sun.com, networking-discuss@opensolaris.org Message-id: <17742.50499.198865.314824@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17739.44365.197410.582170@gargle.gargle.HOWL> Status: RO Content-Length: 332 A nit: could we be consistent with the use of the "6" or "v6" suffix? For instance, I'd prefer /etc/dhcp/inittab6 and DHCP_HOSTCONF_MAGIC6, so that they match /etc/dhcp/.dh6 and so forth. Further, (rather than ) seems more in-keeping with existing headers like . -- meem From carlsonj@phorcys.east.sun.com Mon Nov 6 04:01:13 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA6C1CQu022378 for ; Mon, 6 Nov 2006 04:01:13 -0800 (PST) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA6C10dh020806; Mon, 6 Nov 2006 20:01:09 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0J8B00J0L5DVYQ00@nwk-avmta-2.sfbay.sun.com>; Mon, 06 Nov 2006 04:01:07 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J8B00CI05DS0X60@nwk-avmta-2.sfbay.sun.com>; Mon, 06 Nov 2006 04:01:05 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kA6C44U5008459; Mon, 06 Nov 2006 07:04:04 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kA6C4456008456; Mon, 06 Nov 2006 07:04:04 -0500 (EST) Date: Mon, 06 Nov 2006 07:04:04 -0500 From: James Carlson Subject: re: [networking-discuss] 2006/597 DHCPv6 Client [restart] In-reply-to: <17742.50499.198865.314824@triplex.East.Sun.COM> To: Peter Memishian Cc: PSARC-EXT@sun.com, networking-discuss@opensolaris.org Message-id: <17743.9396.442634.470171@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17739.44365.197410.582170@gargle.gargle.HOWL> <17742.50499.198865.314824@triplex.East.Sun.COM> Status: RO Content-Length: 959 Peter Memishian writes: > > A nit: could we be consistent with the use of the "6" or "v6" suffix? For > instance, I'd prefer /etc/dhcp/inittab6 and DHCP_HOSTCONF_MAGIC6, so that > they match /etc/dhcp/.dh6 and so forth. Further, > (rather than ) seems more in-keeping with existing > headers like . I wish it were possible to be more consistent here. The protocol itself is known as "DHCPv6," so I've tried to keep that term where it doesn't conflict terribly. The IANA-registered names are used for "dhcpv6-client" and "dhcpv6-server," so I won't be changing those. But if you have a strong preference for changing those other three items, I don't think it's a problem. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From meem@triplex.East.Sun.COM Mon Nov 6 05:09:36 2006 Received: from sunmail4.Singapore.Sun.COM (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA6D9Zvn022997 for ; Mon, 6 Nov 2006 05:09:36 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail4.Singapore.Sun.COM (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id kA6D9EJg008129; Mon, 6 Nov 2006 21:09:32 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J8B00L138JUVQ00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Nov 2006 05:09:30 -0800 (PST) Received: from triplex.East.Sun.COM ([129.148.174.104]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J8B004OS8JTG2C0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 06 Nov 2006 05:09:30 -0800 (PST) Received: from triplex.East.Sun.COM (localhost [127.0.0.1]) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8) with ESMTP id kA6D9Tdj106018; Mon, 06 Nov 2006 08:09:29 -0500 (EST) Received: (from meem@localhost) by triplex.East.Sun.COM (8.13.8+Sun/8.13.8/Submit) id kA6D9Ten106015; Mon, 06 Nov 2006 08:09:29 -0500 (EST) Date: Mon, 06 Nov 2006 08:09:29 -0500 From: Peter Memishian Subject: re: [networking-discuss] 2006/597 DHCPv6 Client [restart] In-reply-to: <17743.9396.442634.470171@gargle.gargle.HOWL> To: James Carlson Cc: Peter Memishian , PSARC-EXT@sun.com, networking-discuss@opensolaris.org Message-id: <17743.13321.126357.472297@triplex.East.Sun.COM> MIME-version: 1.0 X-Mailer: VM 7.17 under 21.4 (patch 18) "Social Property" XEmacs Lucid Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17739.44365.197410.582170@gargle.gargle.HOWL> <17742.50499.198865.314824@triplex.East.Sun.COM> <17743.9396.442634.470171@gargle.gargle.HOWL> Status: RO Content-Length: 793 > > A nit: could we be consistent with the use of the "6" or "v6" suffix? For > > instance, I'd prefer /etc/dhcp/inittab6 and DHCP_HOSTCONF_MAGIC6, so that > > they match /etc/dhcp/.dh6 and so forth. Further, > > (rather than ) seems more in-keeping with existing > > headers like . > > I wish it were possible to be more consistent here. > > The protocol itself is known as "DHCPv6," so I've tried to keep that > term where it doesn't conflict terribly. > > The IANA-registered names are used for "dhcpv6-client" and > "dhcpv6-server," so I won't be changing those. But if you have a > strong preference for changing those other three items, I don't think > it's a problem. Yes, that's all I'm asking. -- meem From carlsonj@phorcys.east.sun.com Wed Nov 8 10:05:48 2006 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id kA8I5ma9009923 for ; Wed, 8 Nov 2006 10:05:48 -0800 (PST) Received: from nwk-avmta-1.sfbay.sun.com (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id kA8I5lk1015376; Wed, 8 Nov 2006 10:05:47 -0800 (PST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) id <0J8F00709BLNHI00@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Nov 2006 10:05:47 -0800 (PST) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J8F00M2XBLKZO90@nwk-avmta-1.sfbay.Sun.COM>; Wed, 08 Nov 2006 10:05:45 -0800 (PST) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.8+Sun/8.13.8) with ESMTP id kA8I8kE1019919; Wed, 08 Nov 2006 13:08:46 -0500 (EST) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.8+Sun/8.13.8/Submit) id kA8I8klj019916; Wed, 08 Nov 2006 13:08:46 -0500 (EST) Date: Wed, 08 Nov 2006 13:08:45 -0500 From: James Carlson Subject: Re: 2006/597 DHCPv6 Client [restart] In-reply-to: <17739.44365.197410.582170@gargle.gargle.HOWL> To: psarc-ext@sun.com Cc: networking-discuss@opensolaris.org, Anay Panvalkar Message-id: <17746.7469.957309.518079@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <17739.44365.197410.582170@gargle.gargle.HOWL> Status: RO Content-Length: 307 This fast-track request was approved during ARC business in today's PSARC meeting. -- James Carlson, KISS Network Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677