Re: [Cerowrt-devel] dhcpv4 to slaac naming rfc ready to submit

[Chuck Anderson <cra@WPI.EDU>]

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" <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