From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by huchra.bufferbloat.net (Postfix) with ESMTP id 7D5D321F1CA for ; Sat, 15 Feb 2014 07:28:13 -0800 (PST) Received: from MAIL1.WPI.EDU (MAIL1.WPI.EDU [130.215.36.91]) by MAIL1.WPI.EDU (8.14.8/8.14.7) with ESMTP id s1FFSCop007632 for ; Sat, 15 Feb 2014 10:28:12 -0500 X-DKIM: Sendmail DKIM Filter v2.8.3 MAIL1.WPI.EDU s1FFSCop007632 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wpi.edu; s=_dkim; t=1392478092; bh=/e4D1xfqquWta/A1CDjhPxz7ILYtyDx52TPNUPpjX2A=; h=Date:From:To:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Transfer-Encoding:In-Reply-To; b=wBRlQPuLBVW5RvVm4HTWGGciHe3EM0gYQb6aM/ZdL0o4cWDD/ukFthZbUexXMD7Xs CUzW16GQueEprtVMNkbYs6iqFQL9tfLK2bWxQ1llRNfJYvm0CyPdGK731GFxg6f+kc Dz09/dJVt6NSXF3v7Z9j4SgEuMc1fc8BHp6GbVY4= Received: from mx1.wpi.edu (mx1.wpi.edu [130.215.36.141]) by MAIL1.WPI.EDU (8.14.8/8.14.8) with ESMTP id s1FFSCTF007629 for ; Sat, 15 Feb 2014 10:28:12 -0500 Received: from angus.ind.WPI.EDU (ANGUS.IND.WPI.EDU [130.215.130.21]) by mx1.wpi.edu (8.14.4/8.14.4) with ESMTP id s1FFSANP010982 for ; Sat, 15 Feb 2014 10:28:11 -0500 (envelope-from cra@WPI.EDU) Received: from angus.ind.WPI.EDU (localhost [127.0.0.1]) by angus.ind.WPI.EDU (8.14.4/8.14.4) with ESMTP id s1FFSAMb000457 for ; Sat, 15 Feb 2014 10:28:10 -0500 Received: (from cra@localhost) by angus.ind.WPI.EDU (8.14.4/8.14.4/Submit) id s1FFSAVl000456 for cerowrt-devel@lists.bufferbloat.net; Sat, 15 Feb 2014 10:28:10 -0500 X-Authentication-Warning: angus.ind.WPI.EDU: cra set sender to cra@WPI.EDU using -f Date: Sat, 15 Feb 2014 10:28:10 -0500 From: Chuck Anderson To: cerowrt-devel@lists.bufferbloat.net Message-ID: <20140215152809.GF26063@angus.ind.WPI.EDU> Mail-Followup-To: cerowrt-devel@lists.bufferbloat.net References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-12-10) Subject: Re: [Cerowrt-devel] dhcpv4 to slaac naming rfc ready to submit X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Feb 2014 15:28:14 -0000 At best, this is a partial solution. Using a Modified EUI-64 (RFC4291 sec 2.5.1) is not very reliable. Many systems out there, including Windows and recent Linux distributions, do Privacy Addressing by default, so you will never find their SLAAC address by assuming they constructed their address using EUI-64 based on their Link Layer Address. Also, they may not respond to ICMPv6 echo requests due to firewall settings. Rather than relying on EUI-64 to guess the SLAAC address the client is using and following up with an ICMPv6 echo request, why not just query the local neighbor cache table which will have the exact mapping of Link Layer Address to IPv6 address? This should be pretty reliable. It might be necessary to send a Neighbor Discovery request or an Inverse Neighbor Discovery request (RFC 3122) to populate the neighbor cache if the IPv6 node hasn't sent traffic to the router yet. I'm not sure if RFC 3122 is widely implemented for Ethernet hosts though. Alternatively, every SLAAC client must do DAD, so perhaps we can capture the DAD packets to get the client's LL address (or maybe DAD already populates the local ND cache?). See also RFC 6939 which specifies a way for a DHCPv6 Relay Agent to insert the client's Link Layer address in packets relayed to a DHCPv6 server. This relies on looking at the source LL address of the packet. On Fri, Feb 14, 2014 at 04:15:16PM -0500, Dave Taht wrote: > I can't see anything else to add. Eyeballs and reviewers wanted! > > http://snapon.lab.bufferbloat.net/~d/draft-taht-kelly-hunt-dhpv4-to-slaac-naming-00.html > On Feb 4, 2014 10:43 AM, "Dave Taht" wrote: > > All: > > I have been trying to get this off my plate for a while, this summarizes > the early discussion on the list: > > http://snapon.lab.bufferbloat.net/~d/draft-taht-kelly-hunt-dhpv4-to-slac-naming-00.html > > Ted: > > This is my first ever RFC draft attempt, and if you can > suggest an RFC to model this on hopefully it can flow better? > > Other suggestions welcomed. My other (overdue) RFCs are WAY more hairy > than this one... > > evan: I have misplaced the isc-dhcpv4 code. > > there needs to be a bind specific section also talking about > modern usage of nsupdate. > > all: arguably this needs ascii art for the state machine > > I found a nifty site for generating such and the pandoc2rfc engine > tolerates it. > > http://www.asciiflow.com/#Draw > > the git repo for all this is in: > > https://github.com/dtaht/bufferbloat-rfcs > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html