From sacadmin Mon Sep 12 13:16:18 2005 Received: from sunmail2.sfbay.sun.com (sunmail2.SFBay.Sun.COM [129.149.246.180]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j8CKGIEu021982 for ; Mon, 12 Sep 2005 13:16:18 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j8CKGHP01961; Mon, 12 Sep 2005 13:16:17 -0700 (PDT) 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 <0IMQ00E010B4VP00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 12 Sep 2005 13:16:16 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0IMQ008JG0B387B0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 12 Sep 2005 13:16:15 -0700 (PDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.175.66]) by sfbaymail2sca.sfbay.sun.com (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j8CKGEao012386; Mon, 12 Sep 2005 13:16:15 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9) with ESMTP id j8CKGEEu021977; Mon, 12 Sep 2005 13:16:14 -0700 (PDT) Received: (from ss146556@localhost) by sac.sfbay.sun.com (8.12.9+Sun/8.12.9/Submit) id j8CKGE5D021976; Mon, 12 Sep 2005 13:16:14 -0700 (PDT) Date: Mon, 12 Sep 2005 13:16:14 -0700 (PDT) From: PSARC-coord@sun.com Subject: New PSARC Materials Submitted 2005/314 IP Duplicate Address Detection To: PSARC@sun.com Cc: James.D.Carlson@sun.com, PSARC-coord@sun.com Message-id: <200509122016.j8CKGE5D021976@sac.sfbay.sun.com> MIME-version: 1.0 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.0.3.165339 Status: RO Content-Length: 359 New Materials submitted for PSARC 2005/314 IP Duplicate Address Detection Status: inception scheduled 09/21/2005 Files: /shared/sac/PSARC/2005/314/inception.materials/20questions.txt /shared/sac/PSARC/2005/314/inception.materials/dad-design.pdf /shared/sac/PSARC/2005/314/inception.materials/msft-dad.txt Please let me know if you have questions. - PSARC From sacadmin Wed Sep 21 11:44:41 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 j8LIifEu008333 for ; Wed, 21 Sep 2005 11:44:41 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.56.144]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j8LIi1h29757; Wed, 21 Sep 2005 11:44:14 -0700 (PDT) Received: from sun.com (sr1-umpk-06.SFBay.Sun.COM [129.146.11.166]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5.Beta1) with ESMTP id j8LIi1sb404407; Wed, 21 Sep 2005 11:44:01 -0700 (PDT) Message-ID: <4331A9F1.10405@sun.com> Date: Wed, 21 Sep 2005 11:44:01 -0700 From: Sherri Shieh User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20041214 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sun.com, Craig Payne CC: sbd-core@sun.com, Joep Vesseur Subject: PSARC Meeting Minutes 09/14/2005 Biz: 2005/314, 2005/474; Inception: 2004/368 Content-Type: multipart/mixed; boundary="------------040008090606090805030303" Status: RO Content-Length: 13462 This is a multi-part message in MIME format. --------------040008090606090805030303 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit All, Meeting minutes are now available (sorry so late!) and are attached. Audio files are also available: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050914.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050914.2004.368.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050914.html If you have any corrections/feedback, please direct them to me. Thanks, Sherri -- ========================================================= Sherri Shieh Sun Microsystems, Inc. Program Manager Email: sherri.shieh@sun.com Systems Architecture Phone: 650-786-5245/x85245 =========================================================== --------------040008090606090805030303 Content-Type: text/plain; name="20050914" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="20050914" SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 09/14/2005 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes Robert Berube no Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: no Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) Sherri Shieh: yes ATTENDEES- Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: no Rick Matthews: no (out) Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Kais Belgaied: yes Phil Harman: no Calum Mackay no (out) Michael Speer no Ienup Sung yes Cecilia Hu: no Brian Utterback no Michael Haines no Sebastien Roy no GUESTS: Justin Frank Joep V. Pauly S. Craig Payne Dan Hain Alan H. Alan Coopersmith Frits Vanderlinden Vassili Igouchkine --------------------------------------------------------------------------- AGENDA ------- 09/14/2005 (meeting will start at 1pm PDT; Calum, RickM out) 1:00-1:10 project id 1:10-1:20 ARC Business - Owner/intern for 2005/314 1:20-2:05 Inception: Secure By Default, Phase 1 (2004/368) Submitter: Craig Payne Owner: Gary Winiger Interest: sbd-core@sun.com --------------------------------------------------------------------------- Case Anchors: 1) Case 1: Secure By Default, Phase 1 (2004/368) =========================================================================== ARC BUSINESS -------------- - Fast tracks - 2005/497 ipge/e1000g Ajoy Siddabathuni waiting fast-track 09/08/2005 Joseph Kowalski * Approved last week - needs to update the IAM file 2005/517 EFISTYLE4NONEFI minor version number for Frank Batschulat waiting fast-track 09/14/2005 Sarah Jelinek * Approved 2005/518 tfallocate flag Shawn Debnath waiting fast-track 09/14/2005 Sarah Jelinek * Bill's question is still pending - Bill will ping both people * EXtend timer a week 2005/520 cdrecord and friends into the WOS Frits Vanderlinden waiting fast-track 09/14/05 Frits Vanderlinden * This is unstable and will need updates to have appropriate direction * Approved 2005/521 Optimistic Zones Patching Vassili Igouchkine waiting fast-track 09/14/2005 Gary Winiger * Still some questions from Gary - Gary: My concern that this gets explained well to the man page people...I want this clear so that the customer knows what is going on * Approved pending updated docs 2005/523 I2C Retry Tunable Justin Frank waiting fast-track 09/15/2005 James Carlson * Bill: The big concern I have is that this is not a complete software...from a software fixed stand point, it screams out an FMA issue. * This should really reside in FMA... * I think this needs attention of an executive with some kind of urgency (or possibly PAC?). * AI: Justin will let management know about this issue. I'm trying to provide a relief for the customers out there right now. * Derailed - Owner: Jim Carlson * Opinion information - Project team needs to get the FMA team involved in this - We have an indemic hardware problem...this isn't getting adequate attention by management...this may require very high escalation 2005/525 IIIMF upgrade to revision 12 Fuyuki Hasegawa waiting fast-track 09/16/2005 Ienup Sung * JimC: I don't know if more time is going to fix anything... * Minimum I think there needs to be a written opinon - Should say why this won't work - Intern will write opinion (Ienup Sung) * Derailed - We don't have control over what needs to be fixed..this should be communicated to people who have change on the systems architecture - Owner: Jim Carlson VOTE ---- yes - gary, shudong, glenn, ed, bill, jim no - abstain - NP - 2005/526 SUN mice and Power Management Frits Vanderlinden waiting fast-track 9/15/2005 Frits Vanderlinden * Why do we need to power the manage the mouse? * More discussion will be taken offline - this will be done over email * EXtend the timer 2005/527 new auditreduce(1m) selection options Gary Winiger waiting fast-track 09/21/2005 Gary Winiger * let it run - Other Business - * couple of requests for fast track licensees - 3 successful fast track submissions should be sufficient * add these people to the psarc-fasttrack-licensees - Anish Gupta - Kevin.X.Song - Sherri will put in a ticket for them IP Duplicate Address Detection (2005/314) Submitter: James Carlson Owner: Bill Sommerfeld Zones Upgrade (Ashanti and Zulu) (2005/474) Submitter: James Carlson Owner: Jim Carlson --------------040008090606090805030303-- From sacadmin Wed Sep 28 08:42:30 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 j8SFgUEu015525 for ; Wed, 28 Sep 2005 08:42:30 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.SFBay.Sun.COM [129.146.106.31]) by sunmail3.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id j8SFgTA16835 for ; Wed, 28 Sep 2005 08:42:29 -0700 (PDT) Received: from sun.com (vpn-129-150-28-35.SFBay.Sun.COM [129.150.28.35]) by jurassic.eng.sun.com (8.13.5+Sun/8.13.5.Beta1) with ESMTP id j8SFgStw853280 for ; Wed, 28 Sep 2005 08:42:28 -0700 (PDT) Message-ID: <433AB9DF.30009@sun.com> Date: Wed, 28 Sep 2005 08:42:23 -0700 From: Sherri Shieh User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 X-Accept-Language: en-us, en MIME-Version: 1.0 To: psarc@sun.com Subject: PSARC Meeting Minutes 09/21/2005 Inception: 2005/314; Inception: 2005/474 Content-Type: multipart/mixed; boundary="------------020105040704040205070300" Status: RO Content-Length: 14519 This is a multi-part message in MIME format. --------------020105040704040205070300 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit All, Meeting minutes are now available and are attached. Audio files are now available as well: (1) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050921.arcbiz.mp3 (2) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050921.2005.314.inception.mp3 (3) http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050921.2005.474.inception.mp3 Sum up available at: http://sac.sfbay.sun.com/Archives/Minutes/PSARC/2005/20050921.html If you have any questions/corrections, please direct them to me. Thanks, Sherri ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sherri Shieh Program Manager, System Architecture Sun Microsystems, Inc. Email: Sherri.Shieh@sun.com --------------020105040704040205070300 Content-Type: text/plain; name="20050921.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="20050921.txt" SYSTEM ARCHITECTURE COUNCIL Platform Software ARC --------------------------------- PSARC Regular Meeting time: Wednesdays 10:00-1:00pm in MPK17-3507. 09/21/2005 MEETING MINUTES ============================================================== CORRECTIONS, additions, deletions to sherri.shieh@sun.com. Minutes are archived in sac.Eng:/sac/export/sac/Minutes/PSARC. ATTENDEES - Members: Joseph Kowalski: no (on sabbatical) Glenn Skinner: yes Robert Berube no Andy Rudoff: no (on sabbatical) James Carlson: yes Shudong Zhou: yes Bill Sommerfeld: yes Gary Winiger: yes Tim Marsland: no (on sabbatical) Ed Gould: yes David Robinson no (on sabbatical) Sherri Shieh: yes ATTENDEES- Interns: Don Cragun: yes Peter Dennis: no (on sabbatical) Wyllys Ingersoll: yes Rick Matthews: yes Alec Muffett: no (on sabbatical) James Falkner: no (on sabbatical) Kais Belgaied: yes Phil Harman: no Calum Mackay yes Michael Speer no Ienup Sung no Cecilia Hu: no Brian Utterback no Michael Haines no Sebastien Roy yes Alan Hargreaves yes GUESTS: Dave Miners Alan Coopersmith Terry Whatley Glen Lagowsky Gary Gere Ethan Quach --------------------------------------------------------------------------- AGENDA ------- 09/21/2005 10:00-10:10 project id 10:10-10:20 ARC Business 10:20-11:05 Inception: IP Duplicate Address Detection (2005/314) Submitter: James Carlson Owner: Bill Sommerfeld 11:05-11:50 Inception: Zones Upgrade (Ashanti and Zulu) (2005/474) Submitter: James Carlson Owner: James Carlson --------------------------------------------------------------------------- Case Anchors: 1) Case 1: IP Duplicate Address Detection (2005/314)
1) Case 2: Zones Upgrade (Ashanti and Zulu) (2005/474)
=========================================================================== ARC BUSINESS -------------- - Fast tracks - 2005/469 X86 Energy Star compliance Joseph Townsend waiting fast-track 9/28/05 Terry Whatley * let it run 2005/497 ipge/e1000g Ajoy Siddabathuni waiting fast-track 09/08/2005 Joseph Kowalski * Approved 2 weeks ago - Shudong updated the IAM file 2005/518 tfallocate flag Shawn Debnath waiting fast-track 09/14/2005 Sarah Jelinek * This one looks like it doesn't require a case * closed withdrawn 2005/526 SUN mice and Power Management Frits Vanderlinden waiting fast-track 9/28/2005 Frits Vanderlinden * Timer has been extended 2005/527 new auditreduce(1m) selection options Gary Winiger waiting fast-track 09/21/2005 Gary Winiger * Approved 2005/530 digest(1) md5/md5sum compatibility Alec Muffett waiting fast-track 9/22/2005 Darren Moffat * let it run 2005/532 Python migration from /usr/sfw to /usr a Rich Burridge waiting fast-track 09/22/2005 Richard Burridge * Approved 2005/535 zero-CountryCode keyboard layout support Strony Zhang waiting fast-track 09/23/2005 Shudong Zhou * Shudong asked the project team to re-submit a new spec * waiting need spec 2005/546 FMR Update for IBTF Brendan Doyle waiting fast-track 09/28/2005 Ted Kim * let it run - Other Business - * Welcome Alan Hargreaves as the new PSARC intern! * Vote on PSARC 2005/475: Graphics private misc module for x86 - Opinion was sent out last week yes - glenn, shudong, bill, jim, ed, gary no abstain - NP - - Case has been approved * The ON C-team is tracking the case status...please update opinions. =========================================================================== Inception: IP Duplicate Address Detection (2005/314) Submitter: James Carlson Owner: Bill Sommerfeld SUMMARY ======== * Advice to publsih something to the IT Ops... * Randomness for networking - PAC advice or opinion fodder * Update on first issue * Patch release binding ISSUES ====== wes-1 when there is a transient usurper on the link, shouldn't DAD eventually self-heal when the usurper goes away? this design allows for a new attack: a "drive-by shooting" which to knocks a system off the link permanently (or until administrative intervention occurs). this is the worst kind of denial-of-service attack, since it leaves things broken and leaves little evidence of what happened. * Jim: Other people have stated that they are also having problems with the RFC. I think the right thing to do is probe and bring the interface back up. We definitely don't want to get into an infinite loop. wes-2 nit: table 1 has 9 ndd variables in it but is prefaced with "five ndd parameters are added for /dev/arp" wes-3 * not in issues file yet... * Each file gets to know the mac address of the other party? - Jim: Yes, this is true. - The person who is probed shouldn't really log anything. The other cases where you have somebody who just doesn't implement that, you will get two people using the same address so yes, you will get something where it lets the two people know that this is going on. * I'm not sure if FMA should get involved in this. gw-1 Sort of nits: a) Why wouldn't this qualify for a patch release binding? b) There seem to be lots of timers going off. How do the timers impact kernel and network performance? c) Network random numbers seem to be independent of kernel random number provider from kcfd or /dev/[u]random. Would it be appropriate to just consume randomness from the kernel provider? * I'm concerned about the volume and the complexity of the changes doing it in patch. - The architecture is definitely approved for the patch * What does all these timers do to our performance? - Jim: A lot of the timers end up being the timers going off at any given time. Some of them are just time stamps. There is an important consideration here and that is if you have thousands of interface aliases and they're mostly dormant, you're going to get idle chatter. My feeling on this is that we need to have some way that this does happen. Not doing it at all just seems unacceptable. - A don't do on the interface defense is possible but I don't know how effective it would be. - We could do bursts....but it would need to be small. * Jim: With the third point, there needs to be 2 instances of randomness for this project...pseudo (which shows up a lot in networking) - All you want to fix this is an LCG. eg-1 20q7 Does this project maintain its own ARP table or does it re-use or replace the existing one? * It is using an existing table but I know it's not clear. It's not a matter of duplicates... - So the side effect is fixing this question... seb-1 The IPv6 in.ndpd daemon has a per-interface tunable called DupAddrDetectTransmits, and it currently only applies to the duplicate address detection mechanism implemented inside of that daemon. How will this be integrated into the new scheme? The ndd tunables aren't per interface, but seem to be global parameters. * There is a variable realted to this but it's not connected. - Seb: Do we have a need to implement this? - Jim: I don't think there is a burning need to do this...in principle, it would be very easy to do this. seb-2 The IFF_NOLOCAL flag had another side-effect, in that a network route remained for the local network even if DAD failed. Is that a behavior that would be beneficial to preserve? * Jim: I don't think it does...as far as I can tell, the only reason that this was done is that the kernel accidently uses the source address. On whiteboard: -------------- gs-1 How will RFC get fixed? * Jim: In the man page, I will specify what those deviations are and why. The people who were orignially pushing for the RFC was Microsoft. * Glenn: It sounds like this needs to be fixed up. This would probably end up being opinion fodder. VOTE ===== yes - glenn, shudong, gary, ed, bill, jim no - abstain - NP - Case approved waiting on the updated spec. NEXT STEP ========= * case approved * waiting need spec --------------020105040704040205070300-- From sacadmin Tue Aug 8 09:50:23 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k78GoMvs018780 for ; Tue, 8 Aug 2006 09:50:22 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k78GpxJv019173 for ; Tue, 8 Aug 2006 12:51:59 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k78GpxTY019170; Tue, 8 Aug 2006 12:51:59 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17624.49454.636840.922705@gargle.gargle.HOWL> Date: Tue, 8 Aug 2006 12:51:58 -0400 From: James Carlson To: psarc@sac.sfbay.sun.com Subject: 2005/314 IP Duplicate Address Detection (interface table) X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1188 I believe that a complete interface table was the remaining issue for this project. The final design document is in the final.materials subdirectory in the case directory. Exported Interfaces IPv6 DAD probing Committed RFC 2462 IPv4 DAD probing Committed RFC 3927 Ongoing address defense Committed UnARP (listen-only) Committed RFC 1868 kernel warning messages Uncommitted arp(7P) new ndd parameters Project Private arp(1M) "permanent" flag Committed (*) ATF_AUTHORITY Committed ifconfig up/down Committed IFF_DUPLICATE Committed IFF_UP behavior Committed IFF_NOLOCAL behavior Committed rtsock DAD delay Committed AR_* STREAMS messages Consolidation Private DHCP PRE_BOUND state Project Private Imported Interfaces ire_cache_lookup Consolidation Private ire_refrele Consolidation Private (*) see also "Arp Single Entry Display" (PSARC 2006/017), which modifies the interfaces delivered by this project. -- 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 sacadmin Tue Aug 8 12:28:53 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k78JSqwR025665 for ; Tue, 8 Aug 2006 12:28:52 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k78JSpsp025017; Tue, 8 Aug 2006 15:28:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k78JSp4c022091; Tue, 8 Aug 2006 15:28:51 -0400 (EDT) Subject: Re: 2005/314 IP Duplicate Address Detection (interface table) From: Bill Sommerfeld To: James Carlson Cc: psarc@sac.sfbay.sun.com In-Reply-To: <17624.49454.636840.922705@gargle.gargle.HOWL> References: <17624.49454.636840.922705@gargle.gargle.HOWL> Content-Type: text/plain Date: Tue, 08 Aug 2006 15:28:50 -0400 Message-Id: <1155065330.20963.17.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 515 I've moved this case from "waiting need spec" to "waiting need opinion". My recollection from the review was that the only particularly significant spec change was from wes-1: even after discovering another node using our address, DAD should periodically re-probe so that once the competing node is removed/repaired our use of the address will (eventually) self-heal -- absent administrative intervention, there must not be any "dead end, off the air forever" final states in the DAD state machine. -Bill From sacadmin Tue Aug 8 12:36:16 2006 Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k78JaFdA025956 for ; Tue, 8 Aug 2006 12:36:16 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k78JbpaM019866; Tue, 8 Aug 2006 15:37:51 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.13.7+Sun/8.13.7/Submit) id k78JbpiP019863; Tue, 8 Aug 2006 15:37:51 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17624.59407.579582.181958@gargle.gargle.HOWL> Date: Tue, 8 Aug 2006 15:37:51 -0400 From: James Carlson To: Bill Sommerfeld Cc: psarc@sac.sfbay.sun.com Subject: Re: 2005/314 IP Duplicate Address Detection (interface table) In-Reply-To: Bill Sommerfeld's message of 8 August 2006 15:28:50 References: <17624.49454.636840.922705@gargle.gargle.HOWL> <1155065330.20963.17.camel@thunk> X-Mailer: VM 7.01 under Emacs 21.3.1 Status: RO Content-Length: 1205 Bill Sommerfeld writes: > My recollection from the review was that the only particularly > significant spec change was from wes-1: even after discovering another > node using our address, DAD should periodically re-probe so that once > the competing node is removed/repaired our use of the address will > (eventually) self-heal -- absent administrative intervention, there must > not be any "dead end, off the air forever" final states in the DAD state > machine. And, indeed, there are not. The current spec makes it clear that this doesn't happen, and that there's a recovery timer running when an interface is down as a duplicate. If you explicitly do "ifconfig foo0 down," then that timer stops and the duplicate flag is removed -- when the administrator marks the interface as down, we intentionally give up. (And if he has a hint about when to try bringing it back up, he needn't wait for the recovery timer to finish the job: "ifconfig foo0 up" does what you'd expect.) -- 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 sacadmin Thu Sep 7 08:06:47 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k87F6l6G002424 for ; Thu, 7 Sep 2006 08:06:47 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k87F6jGq011371; Thu, 7 Sep 2006 11:06:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k87F6jIr002211; Thu, 7 Sep 2006 11:06:45 -0400 (EDT) Subject: 2005/314 IP Duplicate Address Detection: opinion for review From: Bill Sommerfeld To: psarc Cc: James Carlson Content-Type: multipart/mixed; boundary="=-ScOWeOVFPOVzCyVc/XAn" Date: Thu, 07 Sep 2006 11:06:44 -0400 Message-Id: <1157641604.1993.13.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Status: RO Content-Length: 7953 --=-ScOWeOVFPOVzCyVc/XAn Content-Type: text/plain Content-Transfer-Encoding: 7bit PSARC Review timer expires 9/14/2006. There is one substantive addition to the opinion which deserves special notice: By actually reading one of the RFC's referenced, I sorted out exactly *why* the specified DAD state machine has the permanent "give up" state I complained about in wes-1: the DAD algorithm specified in 3927 is entwined with the IPv4 version of link-local addresses, and the larger link-local state machine will pick a new address and retry DAD with the new address. That's clearly the right behavior for a randomly selected address, but also clearly wrong when you use the same duplicate-detection algorithm with an administratively-assigned address. IMHO if we're going to pursue documenting this protocol variant in the IETF, the best approach would likely involve a draft documenting how to apply 3927's DAD to administratively-assigned addresses by adding the "try again later" behavior we settled on. - Bill --=-ScOWeOVFPOVzCyVc/XAn Content-Description: Content-Disposition: inline; filename=opinion.txt Content-Type: text/plain; charset=ISO8859-1 Content-Transfer-Encoding: 7bit sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: IP Duplicate Address Detection Submitted by: James D. Carlson File: PSARC/2005/314/opinion.ms Date: August 8th, 2006 Committee: Bill Sommerfeld, James D. Carlson, Ed Gould, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to make several infrastructural improvements to how Solaris's IPv4 ARP and IPv6 Neighbor Discovery implementations detect and handle situations where two nodes on a network claim the same IP address. This work will enable several follow-on projects in the general area of dynamic network autoconfiguration. 2. Decision & Precedence Information This project is approved as specified in reference [1]. The project may be delivered in a Patch/Micro release of Solaris PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |________________________|_________________|______________| |Interface | Classification | Comments | |________________________|_________________|______________| |IPv6 DAD probing | Committed | RFC 2462 | |IPv4 DAD probing | Committed | RFC 3927 [1]| | | | | |Ongoing address defense| Committed | | |behavior | | | | | | | |UnARP (listen-only) | Committed | RFC 1868 | | | | | |kernel warning messages | Uncommitted | arp(7P) | | | | | |new ndd parameters | Project Private| | | | | | |arp(1M) "permanent" flag| Committed | | |arp(1M) output | Uncommited | [4] | |ATF_AUTHORITY | Committed | | | | | | |ifconfig up/down | Committed | | |IFF_DUPLICATE | Committed | [2] | |IFF_UP behavior | Committed | | |IFF_NOLOCAL behavior | Committed | | |rtsock DAD delay | Committed | | |AR_* STREAMS messages | Consolidation | | | | Private | | |DHCP PRE_BOUND state | Project Private| [3] | |________________________|_________________|______________| 1 As revised to add ongoing address defense in the event of a collision; see below. 2 New output-only flag; also visible in ifconfig output 3 New state; visible in ifconfig dhcp status output 4 Flag output changed to match command line keywords PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 3 - The project imports the following interfaces. ______________________________________________________ | Interfaces Imported | |________________|_________________|_________________| |Interface | Classification | Comments | |________________|_________________|_________________| |ire_cache_lookup| Consolidation | kernel function| | | Private | | |ire_refrele | Consolidation | kernel function| | | Private | | |________________|_________________|_________________| 4. Opinion 4.1. Never give up, never surrender! The Duplicate Address Detection algorithm described in RFC 3927 is designed for the allocation of a randomized link- local IPv4 addresses, and thus will back off (and pick a new address) in the event of a collision. This algorithm is inappropriate when applied to authoritatively assigned addresses (i.e., manual assignment or DHCP) as it renders the host subject to a difficult-to-diagnose "drive by" denial-of-service attack. If a duplicate is detected, rather than giving up on a particular address forever, we instead back off for a time and try again later. 4.2. Logging on both parties in the event of a conflict In the event that a conflict is detected between two systems with this project installed, warning messages logged on each system will contain the layer-2 addresses of the other sys- tem, permitting any conflict to be diagnosed starting from either system. 4.3. Need efficient PRNG for protocol use. Most protocols involving periodic broadcast messages will self-synchronize unless timers have substantial random jitter added. The Solaris kernel contains several common random number generator functions; however, they are designed for cryptographic use and are thus computationally expensive per bit generated. A lighter weight function would be useful both for this protocol and several other projects; see the Advisory information below. 5. Minority Opinion(s) None PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 4 - 6. Advisory Information The PAC should fund a project to provide a high-efficiency common random number generator for non-cryptographic use (for instance, for adding random variability to protocol timers to avoid self-synchronization). Once this project integrates and begins to be used on Sun's internal network, the project team should make the operators of the network aware of the new behavior in the event that there is unexpected adverse behavior. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/314. 1. Solaris IP Duplicate Address Detection, version 1.6 File: final.materials/dad-design.pdf 2. RFC 1868 UnARP http://www.ietf.org/rfc/rfc1868.txt 3. RFC 2462 IPv6 Duplicate Address Detection http://www.ietf.org/rfc/rfc2462.txt 4. RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses http://www.ietf.org/rfc/rfc3927.txt PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. --=-ScOWeOVFPOVzCyVc/XAn-- From sac-owner Thu Sep 14 13:50:08 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 k8EKo8fK010864 for ; Thu, 14 Sep 2006 13:50:08 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail2.sfbay.sun.com (8.11.7p1+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id k8EKo8x29100; Thu, 14 Sep 2006 13:50:08 -0700 (PDT) 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 <0J5L00807OJHUZ00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 13:50:05 -0700 (PDT) Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J5L001R0OJGVVD0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 13:50:05 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8EKo3Es022690; Thu, 14 Sep 2006 16:50:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8EKo3gd007788; Thu, 14 Sep 2006 16:50:03 -0400 (EDT) Date: Thu, 14 Sep 2006 16:50:02 -0400 From: Bill Sommerfeld Subject: PSARC 2005/314 IP Duplicate Address Detection: opinion for SAC review To: sac-review Cc: James Carlson Message-id: <1158267002.5600.10.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: multipart/mixed; boundary="Boundary_(ID_v/o4jEcF5fsSGvOCWXnyVg)" X-PMX-Version: 5.2.0.264296 Status: RO Content-Length: 7170 --Boundary_(ID_v/o4jEcF5fsSGvOCWXnyVg) Content-type: text/plain Content-transfer-encoding: 7BIT SAC review timer expires 9/21/2006; no comments were received during the PSARC review period which expired today. - Bill --Boundary_(ID_v/o4jEcF5fsSGvOCWXnyVg) Content-type: text/plain; name=opinion.txt; charset=ISO8859-1 Content-transfer-encoding: 7BIT Content-disposition: inline; filename=opinion.txt sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: IP Duplicate Address Detection Submitted by: James D. Carlson File: PSARC/2005/314/opinion.ms Date: August 8th, 2006 Committee: Bill Sommerfeld, James D. Carlson, Ed Gould, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to make several infrastructural improvements to how Solaris's IPv4 ARP and IPv6 Neighbor Discovery implementations detect and handle situations where two nodes on a network claim the same IP address. This work will enable several follow-on projects in the general area of dynamic network autoconfiguration. 2. Decision & Precedence Information This project is approved as specified in reference [1]. The project may be delivered in a Patch/Micro release of Solaris PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |________________________|_________________|______________| |Interface | Classification | Comments | |________________________|_________________|______________| |IPv6 DAD probing | Committed | RFC 2462 | |IPv4 DAD probing | Committed | RFC 3927 [1]| | | | | |Ongoing address defense| Committed | | |behavior | | | | | | | |UnARP (listen-only) | Committed | RFC 1868 | | | | | |kernel warning messages | Uncommitted | arp(7P) | | | | | |new ndd parameters | Project Private| | | | | | |arp(1M) "permanent" flag| Committed | | |arp(1M) output | Uncommited | [4] | |ATF_AUTHORITY | Committed | | | | | | |ifconfig up/down | Committed | | |IFF_DUPLICATE | Committed | [2] | |IFF_UP behavior | Committed | | |IFF_NOLOCAL behavior | Committed | | |rtsock DAD delay | Committed | | |AR_* STREAMS messages | Consolidation | | | | Private | | |DHCP PRE_BOUND state | Project Private| [3] | |________________________|_________________|______________| 1 As revised to add ongoing address defense in the event of a collision; see below. 2 New output-only flag; also visible in ifconfig output 3 New state; visible in ifconfig dhcp status output 4 Flag output changed to match command line keywords PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 3 - The project imports the following interfaces. ______________________________________________________ | Interfaces Imported | |________________|_________________|_________________| |Interface | Classification | Comments | |________________|_________________|_________________| |ire_cache_lookup| Consolidation | kernel function| | | Private | | |ire_refrele | Consolidation | kernel function| | | Private | | |________________|_________________|_________________| 4. Opinion 4.1. Never give up, never surrender! The Duplicate Address Detection algorithm described in RFC 3927 is designed for the allocation of a randomized link- local IPv4 addresses, and thus will back off (and pick a new address) in the event of a collision. This algorithm is inappropriate when applied to authoritatively assigned addresses (i.e., manual assignment or DHCP) as it renders the host subject to a difficult-to-diagnose "drive by" denial-of-service attack. If a duplicate is detected, rather than giving up on a particular address forever, we instead back off for a time and try again later. 4.2. Logging on both parties in the event of a conflict In the event that a conflict is detected between two systems with this project installed, warning messages logged on each system will contain the layer-2 addresses of the other sys- tem, permitting any conflict to be diagnosed starting from either system. 4.3. Need efficient PRNG for protocol use. Most protocols involving periodic broadcast messages will self-synchronize unless timers have substantial random jitter added. The Solaris kernel contains several common random number generator functions; however, they are designed for cryptographic use and are thus computationally expensive per bit generated. A lighter weight function would be useful both for this protocol and several other projects; see the Advisory information below. 5. Minority Opinion(s) None PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 4 - 6. Advisory Information The PAC should fund a project to provide a high-efficiency common random number generator for non-cryptographic use (for instance, for adding random variability to protocol timers to avoid self-synchronization). Once this project integrates and begins to be used on Sun's internal network, the project team should make the operators of the network aware of the new behavior in the event that there is unexpected adverse behavior. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/314. 1. Solaris IP Duplicate Address Detection, version 1.6 File: final.materials/dad-design.pdf 2. RFC 1868 UnARP http://www.ietf.org/rfc/rfc1868.txt 3. RFC 2462 IPv6 Duplicate Address Detection http://www.ietf.org/rfc/rfc2462.txt 4. RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses http://www.ietf.org/rfc/rfc3927.txt PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. --Boundary_(ID_v/o4jEcF5fsSGvOCWXnyVg)-- From sac-owner Thu Sep 14 14:45:52 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8ELjpku012647 for ; Thu, 14 Sep 2006 14:45:52 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.149.246.28]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k8ELjT8g016383; Thu, 14 Sep 2006 22:45:47 +0100 (BST) 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 <0J5L00D1BR4AVH00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 14:45:46 -0700 (PDT) Received: from nwkea-pix-1.sun.com ([10.4.134.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J5L00AJHR4A9M20@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 14:45:46 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8ELjknp007582; Thu, 14 Sep 2006 14:45:46 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5L00601R14M300@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 14 Sep 2006 14:45:46 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5L0013ZR43X7T4@d1-sfbay-10.sun.com>; Thu, 14 Sep 2006 14:45:45 -0700 (PDT) Date: Thu, 14 Sep 2006 14:45:39 -0700 From: John Plocher Subject: Re: PSARC 2005/314 IP Duplicate Address Detection: opinion for SAC review In-reply-to: <1158267002.5600.10.camel@thunk> Sender: John.Plocher@sun.com To: Bill Sommerfeld Cc: sac-review@sun.com Message-id: <4509CD83.3030203@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <1158267002.5600.10.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 538 +-- Bill Sommerfeld wrote On 09/14/06 13:50,: >6. Advisory Information > >The PAC should fund a project to > > Since the PAC in question professes that they don't "fund" anything, (it is the EVP level MRP process which does so), maybe a better wording could be chosen that doesn't push their hot buttons. I'd suggest "The SOE-PAC should prioritize the establishment of a project to..." After all, the desired goal is that the missing functionality be produced, not that some people get paid to do something... -John From sac-owner Thu Sep 14 15:01:04 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 k8EM13nl013092 for ; Thu, 14 Sep 2006 15:01:04 -0700 (PDT) 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 k8EM0ija020064; Fri, 15 Sep 2006 06:01:02 +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 <0J5L00F3ARTM8V00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 15:00:58 -0700 (PDT) Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J5L00ASYRTI9L30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 15:00:54 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k8EM0rLY012571; Thu, 14 Sep 2006 18:00:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8EM0reB007969; Thu, 14 Sep 2006 18:00:53 -0400 (EDT) Date: Thu, 14 Sep 2006 18:00:52 -0400 From: Bill Sommerfeld Subject: Re: PSARC 2005/314 IP Duplicate Address Detection: opinion for SAC review In-reply-to: <4509CD83.3030203@Sun.COM> To: John Plocher Cc: sac-review@sun.com Message-id: <1158271252.5600.20.camel@thunk> MIME-version: 1.0 X-Mailer: Evolution 2.6.2 Content-type: text/plain Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 References: <1158267002.5600.10.camel@thunk> <4509CD83.3030203@Sun.COM> Status: RO Content-Length: 526 On Thu, 2006-09-14 at 14:45 -0700, John Plocher wrote: > I'd suggest > > "The SOE-PAC should prioritize the establishment of a project to..." I've made a (roughly) equivalent change. folks interested in wordsmithing further should see the new opinion.txt in the case directory. I was unaware that this was a hot button and was just using the boilerplate form I've always been told to use for PAC advice. (If it's a hot button, maybe an addition to the comments in opinion.template.ms is in order...) - Bill From sac-owner Thu Sep 14 15:02:48 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 k8EM2mU9013148 for ; Thu, 14 Sep 2006 15:02:48 -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 k8EM2ls18537; Thu, 14 Sep 2006 16:02:47 -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 <0J5L00F0PRWKNB00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 15:02:44 -0700 (PDT) Received: from sfbaymail2sca.sfbay.sun.com ([129.145.155.42]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2 (built Dec 2 2004)) with ESMTP id <0J5L00ATGRWI9X30@nwk-avmta-1.sfbay.Sun.COM>; Thu, 14 Sep 2006 15:02:42 -0700 (PDT) Received: from dtmail.sfbay.sun.com (pkg.SFBay.Sun.COM [129.146.90.56]) by sfbaymail2sca.sfbay.sun.com (8.13.6+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id k8EM2faE028748; Thu, 14 Sep 2006 15:02:41 -0700 (PDT) Received: from [192.168.0.3] (noho [10.6.92.101]) by dtmail.sfbay.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k8EM2eWT013441; Thu, 14 Sep 2006 15:02:41 -0700 (PDT) Date: Thu, 14 Sep 2006 15:02:37 -0700 From: David Kahn Subject: Re: PSARC 2005/314 IP Duplicate Address Detection: opinion for SAC review To: John Plocher Cc: Bill Sommerfeld , sac-review@sun.com Message-id: <4509D17D.9080700@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.2.0.264296 User-Agent: Thunderbird 1.5.0.5 (Windows/20060719) Status: RO Content-Length: 868 John Plocher wrote: >> The PAC should fund a project to >> > > Since the PAC in question professes that they don't "fund" anything, > (it is the EVP level MRP process which does so), maybe a better > wording could be chosen that doesn't push their hot buttons. > > I'd suggest > > "The SOE-PAC should prioritize the establishment of a project to..." > > After all, the desired goal is that the missing functionality be produced, > not that some people get paid to do something... The "xxx-PAC should fund a project ..." wording is boilerplate opinion text. I guess you're suggesting a change to the boilerplate. But that wording was never intended to "push their hot buttons". I guess we can be a "kinder and gentler" ARC. xxARC would really appreciate it if xxPAC would note that a project is needed to fix yyy as stated in the opinion. -David From sac-owner Thu Sep 14 16:16:00 2006 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k8ENFxoj014823 for ; Thu, 14 Sep 2006 16:15:59 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.149.247.22]) by sunmail5.uk.sun.com (8.13.7+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id k8ENFwPC002883; Fri, 15 Sep 2006 00:15:58 +0100 (BST) 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 <0J5L00B0DVALNM00@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Sep 2006 16:15:57 -0700 (PDT) Received: from nwkea-pix-1.sun.com ([10.4.134.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0J5L007P8VAKJQ60@nwk-avmta-2.sfbay.sun.com>; Thu, 14 Sep 2006 16:15:56 -0700 (PDT) Received: from d1-sfbay-10.sun.com ([192.18.39.120]) by nwkea-pix-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k8ENFuht020593; Thu, 14 Sep 2006 16:15:56 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-10.sun.com by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) id <0J5L00J01V920L00@d1-sfbay-10.sun.com> (original mail from John.Plocher@Sun.COM); Thu, 14 Sep 2006 16:15:56 -0700 (PDT) Received: from [129.146.11.157] by d1-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-4.02 (built Sep 9 2005)) with ESMTPSA id <0J5L001TEVAKX13Z@d1-sfbay-10.sun.com>; Thu, 14 Sep 2006 16:15:56 -0700 (PDT) Date: Thu, 14 Sep 2006 16:15:56 -0700 From: John Plocher Subject: Re: PSARC 2005/314 IP Duplicate Address Detection: opinion for SAC review In-reply-to: <1158271252.5600.20.camel@thunk> Sender: John.Plocher@Sun.COM To: Bill Sommerfeld Cc: sac-review@Sun.COM Message-id: <4509E2AC.8090703@Sun.COM> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.2.0.264296 References: <1158267002.5600.10.camel@thunk> <4509CD83.3030203@Sun.COM> <1158271252.5600.20.camel@thunk> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20050530 Status: RO Content-Length: 373 I updated the opinion templates to reflect this discussion. -John +-- Bill Sommerfeld wrote On 09/14/06 15:00,: >I was unaware that this was a hot button and was just using the >boilerplate form I've always been told to use for PAC advice. > >(If it's a hot button, maybe an addition to the comments in >opinion.template.ms is in order...) > > - Bill > > > > From sac-owner Wed Oct 11 14:43:33 2006 Received: from eastmail4bur.east.Sun.COM (eastmail4bur.East.Sun.COM [129.148.13.1]) by sac.sfbay.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k9BLhWe9020619 for ; Wed, 11 Oct 2006 14:43:32 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL,v2.2) with ESMTP id k9BLhVCv026644; Wed, 11 Oct 2006 17:43:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.7+Sun/8.13.7) with ESMTP id k9BLhVow012862; Wed, 11 Oct 2006 17:43:31 -0400 (EDT) Subject: PSARC 2005/314 IP Duplicate Address Detection: final opinion From: Bill Sommerfeld To: sac-opinion@sac.sfbay.sun.com Cc: solaris-pac-opinion@sun.com Content-Type: text/plain Date: Wed, 11 Oct 2006 17:43:30 -0400 Message-Id: <1160603010.10710.11.camel@thunk> Mime-Version: 1.0 X-Mailer: Evolution 2.6.2 Content-Transfer-Encoding: 7bit Status: RO Content-Length: 6880 sun microsystems Systems Architecture Committee _________________________________________________________________ Subject: IP Duplicate Address Detection Submitted by: James D. Carlson File: PSARC/2005/314/opinion.ms Date: August 8th, 2006 Committee: Bill Sommerfeld, James D. Carlson, Ed Gould, Glenn Skinner, Gary Winiger, Shudong Zhou. Product Approval Committee: Solaris PAC solaris-pac-opinion@sun.com 1. Summary This project proposes to make several infrastructural improvements to how Solaris's IPv4 ARP and IPv6 Neighbor Discovery implementations detect and handle situations where two nodes on a network claim the same IP address. This work will enable several follow-on projects in the general area of dynamic network autoconfiguration. 2. Decision & Precedence Information This project is approved as specified in reference [1]. The project may be delivered in a Patch/Micro release of Solaris PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 2 - 3. Interfaces The project exports the following interfaces. ___________________________________________________________ | Interfaces Exported | |________________________|_________________|______________| |Interface | Classification | Comments | |________________________|_________________|______________| |IPv6 DAD probing | Committed | RFC 2462 | |IPv4 DAD probing | Committed | RFC 3927 [1]| | | | | |Ongoing address defense| Committed | | |behavior | | | | | | | |UnARP (listen-only) | Committed | RFC 1868 | | | | | |kernel warning messages | Uncommitted | arp(7P) | | | | | |new ndd parameters | Project Private| | | | | | |arp(1M) "permanent" flag| Committed | | |arp(1M) output | Uncommited | [4] | |ATF_AUTHORITY | Committed | | | | | | |ifconfig up/down | Committed | | |IFF_DUPLICATE | Committed | [2] | |IFF_UP behavior | Committed | | |IFF_NOLOCAL behavior | Committed | | |rtsock DAD delay | Committed | | |AR_* STREAMS messages | Consolidation | | | | Private | | |DHCP PRE_BOUND state | Project Private| [3] | |________________________|_________________|______________| 1 As revised to add ongoing address defense in the event of a collision; see below. 2 New output-only flag; also visible in ifconfig output 3 New state; visible in ifconfig dhcp status output 4 Flag output changed to match command line keywords PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 3 - The project imports the following interfaces. ______________________________________________________ | Interfaces Imported | |________________|_________________|_________________| |Interface | Classification | Comments | |________________|_________________|_________________| |ire_cache_lookup| Consolidation | kernel function| | | Private | | |ire_refrele | Consolidation | kernel function| | | Private | | |________________|_________________|_________________| 4. Opinion 4.1. Never give up, never surrender! The Duplicate Address Detection algorithm described in RFC 3927 is designed for the allocation of a randomized link- local IPv4 addresses, and thus will back off (and pick a new address) in the event of a collision. This algorithm is inappropriate when applied to authoritatively assigned addresses (i.e., manual assignment or DHCP) as it renders the host subject to a difficult-to-diagnose "drive by" denial-of-service attack. If a duplicate is detected, rather than giving up on a particular address forever, we instead back off for a time and try again later. 4.2. Logging on both parties in the event of a conflict In the event that a conflict is detected between two systems with this project installed, warning messages logged on each system will contain the layer-2 addresses of the other sys- tem, permitting any conflict to be diagnosed starting from either system. 4.3. Need efficient PRNG for protocol use. Most protocols involving periodic broadcast messages will self-synchronize unless timers have substantial random jitter added. The Solaris kernel contains several common random number generator functions; however, they are designed for cryptographic use and are thus computationally expensive per bit generated. A lighter weight function would be useful both for this protocol and several other projects; see the Advisory information below. 5. Minority Opinion(s) None PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc. - 4 - 6. Advisory Information 1. The Solaris PAC should prioritize the establish- ment of a project to provide a high-efficiency common random number generator for non- cryptographic use (for instance, for adding random variability to protocol timers to avoid self- synchronization). 2. Once this project integrates and begins to be used on Sun's internal network, the project team should make the operators of the network aware of the new behavior in the event that there is unexpected adverse behavior. 7. Appendices 7.1. Appendix A: Technical Changes Required None. 7.2. Appendix B: Technical Changes Advised None. 7.3. Appendix C: Reference Material Unless stated otherwise, path names are relative to the case directory PSARC/2005/314. 1. Solaris IP Duplicate Address Detection, version 1.6 File: final.materials/dad-design.pdf 2. RFC 1868 UnARP http://www.ietf.org/rfc/rfc1868.txt 3. RFC 2462 IPv6 Duplicate Address Detection http://www.ietf.org/rfc/rfc2462.txt 4. RFC 3927 Dynamic Configuration of IPv4 Link-Local Addresses http://www.ietf.org/rfc/rfc3927.txt PSARC/2005/314 Copyright 2006 Sun Microsystems, Inc.