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

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

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 1157 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2018 bytes --]

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

[Simon Kelley]

Looks good, I  just corrected a couple of typos.

Simon.

On 14/02/14 21:15, 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
> <mailto: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
> 

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

[Toke Høiland-Jørgensen]

[-- Attachment #1: Type: text/plain, Size: 455 bytes --]

Dave Taht <dave.taht@gmail.com> writes:

> 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

I found it quite clear. Also, useful; for instance I hadn't noticed this
doesn't work with Windows boxes...

Only thing I found to correct (apart from a couple of typos that I
assume Simon has already fixed) is the broken reference to RFC4443 :)

-Toke

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 489 bytes --]

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

[Chuck Anderson]

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

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

[Baptiste Jonglez]

[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Chuck Anderson]

On Mon, Feb 17, 2014 at 11:11:54AM +0100, Baptiste Jonglez wrote:
> 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.

Well, whatever Windows 7 does, it doesn't provide *ANY* EUI-64 address
at all, so this won't work with the most popular platform out there.