From sac-owner Fri May 13 14:32:33 2005 Received: from sunmail3.sfbay.sun.com (sunmail3.SFBay.Sun.COM [129.149.247.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j4DLWXs0024116 for ; Fri, 13 May 2005 14:32:33 -0700 (PDT) Received: (from noaccess@localhost) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) id j4DLWQO05688 for one-pager-not-2b-used-directly; Fri, 13 May 2005 14:32:26 -0700 (PDT) Received: from phorcys.East.Sun.COM (phorcys.East.Sun.COM [129.148.174.143]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j4DLWPi05681 for ; Fri, 13 May 2005 14:32:25 -0700 (PDT) Received: from phorcys.East.Sun.COM (localhost [127.0.0.1]) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4) with ESMTP id j4DLWPdA018872 for ; Fri, 13 May 2005 17:32:25 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.East.Sun.COM (8.13.4+Sun/8.13.4/Submit) id j4DLWPGs018869; Fri, 13 May 2005 17:32:25 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17029.7401.378095.24696@gargle.gargle.HOWL> Date: Fri, 13 May 2005 17:32:25 -0400 From: James Carlson To: one-pager@sun.com Subject: [/]IP Duplicate Address Detection Status: RO Content-Length: 8535 Template Version: @(#)onepager.txt 1.29 04/11/15 SMI This information is Copyright 2005 Sun Microsystems, Inc. 1. Introduction 1.1. Project/Component Working Name: IP Duplicate Address Detection 1.2. Name of Document Author/Supplier: James Carlson 1.3. Date of This Document: 05/13/2005 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC 1.4.2. The ARC(s) you expect to review your project: PSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Bev Crair 1.4.4. The name of your business unit: Solaris 1.5. Email Aliases: 1.5.1. Responsible Manager: victor.nelson@sun.com 1.5.2. Responsible Engineer: james.d.carlson@sun.com 1.5.3. Marketing Manager: N/A 1.5.4. Interest List: kftn@sun.com 2. Project Summary 2.1. Project Description: The IP Duplicate Address Detection project puts a common IPv4/IPv6 mechanism into the Solaris kernel that handles detection of duplicate network layer addresses, defense of properly-configured addresses, and configuration of immutable addresses. 2.2. Risks and Assumptions: The prototype effort is based on the current Nevada gate, but the Surya project will integrate ARP and IP at some point in the future. This will require a redesign (and simplification) of part of the prototype before integration. 3. Business Summary 3.1. Problem Area: This small feature addresses four basic areas: a. The current Duplicate Address Detection (DAD) logic is incompletely implemented and has known operational holes. This project repairs those holes and provides a robust solution. b. DAD is needed to implement the automatic address assignment portion of Apple's Rendezvous. c. Accidental duplicate address configuration currently produces hard to understand messages and difficult to diagnose behavior; these issues are addressed. d. As a design side-effect, this feature allows the administrator to configure ARP entries to be "really static," which is considered a security feature by some users. 3.2. Market/Requester: Cabletron Systems BC-Tel Advanced Communications Network Research Belgium Southern Adventist University 3.3. Business Justification: This cleans up a long-standing call generator and makes Solaris more "approachable" by handling errors in a way that is easier to diagnose and safe for the rest of the network. 3.4. Competitive Analysis: WindowsCE currently includes duplicate address detection, though it's not clear from the documentation whether they support it in a robust manner. MacOS X includes robust duplicate address detection, and the protocol itself was in part developed there. OpenBSD includes a "permanent" keyword for /usr/sbin/arp that implements the "really static" feature. We will be catching up with OpenBSD in this area. 3.5. Opportunity Window/Exposure: N/A 3.6. How will you know when you are done?: Resulting implementation is able to detect and report duplicate addresses in multiple scenarios, including interface configuration, network detach/reattach, and subnet partition/ repair. System operates correctly in above scenarios when one or more of the peers are "old" implementations. System interoperates with third-party implementations. Existing ON-PIT regression tests pass. 4. Technical Description: 4.1. Details: The weak duplicate address detection currently resident in dhcpagent (for IPv4) and ifconfig/in.ndpd/libinetcfg (for IPv6) is removed, and an implementation compliant with Stuart Cheshire's "IPv4 Address Conflict Detection" mechanism (work-in-progress) and with RFC 2462 is added to the kernel. /usr/sbin/arp, /usr/bin/pppd, and /usr/lib/inet/mipagent are updated to use robust address defense mechanisms. After the Surya project integrates, the linkage between IP and ARP will need to be redesigned, but this represents a small portion of the project. 4.2. Bug/RFE Number(s): 4728609 IPv4 Duplicate Address Detection (DAD) is broken 4804770 Hardware duplicate IP address error message unclear 4705220 No IPv6 DAD performed during boot 4735678 Our gratuitous ARP implementation should be broadcasting Replies, not Requests 1253974 Please make a "permanent contents" option for arp vs. static 4.3. In Scope: Very minor changes, such as small outstanding bugs and RFEs for ARP, may be swept in as well, depending on the eventual scope of Surya. 4.4. Out of Scope: If Surya does not integrate, this project will not integrate ARP with IP. Instead, it will be replanned to use the prototype signaling mechanism. 4.5. Interfaces: a. New ndd variables for tuning ARP DAD behavior (and disabling DAD entirely for sites that must stick with the existing behavior). Ndd variables are by default Unstable, and it's not expected that users will need to tune these. b. Consolidation Private flags are added between IP and ARP. (The contracted interfaces used by ATM are preserved by this project, but are likely not preserved by Surya.) c. Undocumented behavior of routing sockets changes slightly; new interfaces are reported only after DAD completes. d. Standards-based "ARP probe" packets are transmitted. These have been used in the past by the DHCP implementation, but never on statically addressed systems. e. The system itself can now shut off the IFF_UP bit when conflict resolution determines that we've lost the bid for the address. This is in contrast to the existing design, which, except for IPMP behavior, puts the IFF_UP bit solely in the administrator's hands. Also, IFF_DUPLICATE flag is added to indicate failures. f. New Stable 'ATF_AUTHORITATIVE' flag for ARP entries plus "permanent" command-line flag for /usr/sbin/arp. g. Sysevents for reporting errors and significant conditions. (Details TBD.) 4.6. Doc Impact: Update arp(1M), ifconfig(1M), arp(7P), if_tcp(7P). 4.7. Admin/Config Impact: New "really static" feature in /usr/sbin/arp will allow users to configure hardware addresses that aren't updated by network changes. New behavior when DAD fails (interface automatically shut down) will require that administrators become familiar with the new (and easier) way to deal with such problems. 4.8. HA Impact: None. 4.9. I18N/L10N Impact: None. 4.10. Packaging & Delivery: This project updates files already delivered by existing packages (SUNWmipu, SUNWcsu, SUNWckr, SUNWcslr, SUNWpppdu, SUNWroute, SUNWhea) and does not introduce any new files or packages, nor remove any old files or packages. 4.11. Security Impact: The new "permanent" flag for ARP entries is sometimes considered a security issue by some administrators, but ARP itself (and NDP in IPv6) has no real security. This project does not add or remove security issues. 4.12. Dependencies: This project has a weak dependency on Surya: if Surya delivers first (as expected), then the IP-ARP interface needs to be redesigned. If not, then the prototype can be used. The proposed Rendezvous implementation on Solaris will require robust IPv4 DAD if the automatic addressing portion is included. 5. Reference Documents: See CRs in section 4.2. Also RFC 2462 and, for IPv4, Stuart Cheshire's "Dynamic Configuration of IPv4 Link-Local Addresses" and "IPv4 Address Conflict Detection" drafts. (The latter is now expired, but exists in many repositories and essentially just documents known good practice derived from DHCP implementation efforts.) 6. Resources and Schedule: 6.1. Projected Availability: 1 quarter. 6.2. Cost of Effort: 1 person. 6.3. Cost of Capital Resources: N/A 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: ON 6.4.3. Type of CPT Review and Approval expected: RFE 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: None 6.4.7. Target RTI Date/Release: 08/15/2005 onnv_22 6.4.8. Target Code Design Review Date: 06/10/2005 6.4.9. Update approval addition: No 6.5. ARC review type: Standard 7. Prototype Availability: 7.1. Prototype Availability: 05/31/2005 7.2. Prototype Cost: Approximately 4 staff-weeks to do prototype. 12 to finish.