From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from jabiru.ens-lyon.fr (jabiru.ens-lyon.fr [140.77.51.2]) by huchra.bufferbloat.net (Postfix) with ESMTP id 7BB9F21F214 for ; Mon, 17 Feb 2014 02:11:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by jabiru.ens-lyon.fr (Postfix) with ESMTP id 728A11EB210 for ; Mon, 17 Feb 2014 11:11:56 +0100 (CET) X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at ens-lyon.fr Received: from jabiru.ens-lyon.fr ([127.0.0.1]) by localhost (jabiru.ens-lyon.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBjVeodG3pZ0 for ; Mon, 17 Feb 2014 11:11:54 +0100 (CET) Received: from localhost (dhcp-182-141.ens-lyon.fr [140.77.182.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by jabiru.ens-lyon.fr (Postfix) with ESMTPSA id 677271EB273 for ; Mon, 17 Feb 2014 11:11:54 +0100 (CET) Date: Mon, 17 Feb 2014 11:11:54 +0100 From: Baptiste Jonglez To: cerowrt-devel@lists.bufferbloat.net Message-ID: <20140217101154.GA1958@ens-lyon.fr> References: <20140215152809.GF26063@angus.ind.WPI.EDU> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: <20140215152809.GF26063@angus.ind.WPI.EDU> User-Agent: Mutt/1.5.22 (2013-10-16) 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: Mon, 17 Feb 2014 10:11:59 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Feb 15, 2014 at 10:28:10AM -0500, Chuck Anderson wrote: > 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. Privacy extensions define *additional* addresses, while keeping the SLAAC addresses. RFC4941 does not explicitely state so, but it is hinted at in Section 2.4, third paragraph. At least, the Linux and Android implementations keep using a SLAAC address when using RFC4941-addresses, even if it is not used by default for outgoing connections. > 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. This would defeat the whole point of Privacy Extensions. > 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?). >=20 > 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. >=20 > 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! > >=20 > > http://snapon.lab.bufferbloat.net/~d/draft-taht-kelly-hunt-dhpv4-to-sla= ac-naming-00.html > > On Feb 4, 2014 10:43 AM, "Dave Taht" wrote: > >=20 > > All: > >=20 > > I have been trying to get this off my plate for a while, this summarizes > > the early discussion on the list: > >=20 > > http://snapon.lab.bufferbloat.net/~d/draft-taht-kelly-hunt-dhpv4-to-sla= c-naming-00.html > >=20 > > Ted: > >=20 > > This is my first ever RFC draft attempt, and if you can > > suggest an RFC to model this on hopefully it can flow better? > >=20 > > Other suggestions welcomed. My other (overdue) RFCs are WAY more hairy > > than this one... > >=20 > > evan: I have misplaced the isc-dhcpv4 code. > >=20 > > there needs to be a bind specific section also talking about > > modern usage of nsupdate. > >=20 > > all: arguably this needs ascii art for the state machine > >=20 > > I found a nifty site for generating such and the pandoc2rfc engine > > tolerates it. > >=20 > > http://www.asciiflow.com/#Draw > >=20 > > the git repo for all this is in: > >=20 > > https://github.com/dtaht/bufferbloat-rfcs > >=20 > > -- > > Dave T=E4ht > >=20 > > Fixing bufferbloat with cerowrt: > > http://www.teklibre.com/cerowrt/subscribe.html > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQEcBAEBCAAGBQJTAeBqAAoJENJowA4zCePguj8H/0tHiEd5KWV4SECV+uRQGNH3 1lLuGzpxCZtXNrG/wfnFTnBKlvYeWXDYN+ldgndGBHWkuD0DbWgomuM568MtlHMT Ggq4DfT7/wkZnXufUOYcYcl03exCb//DiE/14UI6OqvfKXNB/s1l99+UJamXlbvs qYlo+p8xEB1925wGpJVCb7mXVyTCTiigukr5JuI/klQQrv6QFisKD5dmZ+kbDy9Z 9GAhpAWr/R0miEWfSWhR7YJGsCh+Myt06Zk16b4nJC3/Kr0vJ05PTd2jsyI7xO+y Aavagg00jBNzoQGg3fgiXgyH/Fsi5BQFtuTVHTSiC8VziZV7UIxghO7ZV0oA2cU= =ejM+ -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--