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?).
> 
> 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" <dave.taht@gmail.com> 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
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel