dhcpcd-discuss

On 2017-08-25 17:10, Roy Marples wrote:
> Hi
>
> On 25/08/2017 14:37, M. Buecher wrote:
> > Hello developers,
> >
> > I have a feature request to extend the SLAAC option for more
> > flexibility, plus a question in point d).
> > Ideas are based on Raspbian with dhcpcd 6.10.1 from the Debian 9
> > "Stretch" package.
> > Please bear with me as I'm not an IPv6 professional, just an 
> > enthusiast
> > trying to manage his LAN with dhcpcd+dnsmasq on Raspbian.
> >
> > *a) Support multiple SLAAC options at the same time*
> >
> > Allow multiple SLAAC lines for combining different methods.
> > Using multiple lines will still allow that the SLAAC option itself can
> > be easily enhanced.
> >
> > Example:
> > ## Default to stable private addresses
> > slaac stableprivate
> >
> > interface eth0
> >   ## Stable private addresses for services
> >   slaac stableprivate
> >   ## Additional hardware-based addresses as workaround for some 
> > routers
> > that always
> >   ## uses these for port forwarding and cannot be changed until the
> > firmware has been updated somewhen:(
> >   slaac hwaddr
>
> Please open a ticket for this at https://dev.marples.name/

Created T134 at https://dev.marples.name/T134

Also added a comment that SLAAC options for an interface replace all 
globally defined SLAAC options. Just like it is with the current single 
SLAAC option.


> > *b) Support SLAAC options per prefix with preferred lifetime*
> >
> > Allow to specify for which prefix range a SLAAC option is valid for 
> > and
> > specify its preferred lifetime.
> >
> > Example:
> > ## Default to stable private addresses for all GUA
> > slaac stableprivate 2000::/3
> >
> > interface eth0
> >   ## Stable private addresses for services for all prefixes (ULA, 
> > etc.)
> > on this interface
> >   slaac stableprivate ::/0
> >   ## Additional hardware-based addresses only for GUA as workaround 
> > for
> > some routers that always
> >   ## uses these for port forwarding and cannot be changed until the
> > firmware has been updated somewhen:(
> >   ## Preferred as the very last for outgoing connections
> >   slaac hwaddr 2000::/3 PLFT=0
>
> Please open a seperate ticket for this at https://dev.marples.name/

Created T135 at https://dev.marples.name/T135


> > *c) Support "inform6" on stable SLAAC addresses*
> >
> > Add support to inform DHCPv6 server about SLAAC address (found out 
> > about
> > "inform6" in the dev area).
> >
> > Example:
> > ## Default to stable private addresses for all GUA
> > slaac stableprivate 2000::/3
> >
> > interface eth0
> >   ## Stable private addresses for services for all prefixes (ULA, 
> > etc.)
> > on this interface
> >   slaac stableprivate ::/0 inform6
> >   ## Additional hardware-based addresses only for GUA as workaround 
> > for
> > some routers that always
> >   ## uses these for port forwarding and cannot be changed until the
> > firmware has been updated somewhen:(
> >   ## Preferred as the very last for outgoing connections
> >   slaac hwaddr 2000::/3 PLFT=0
>
> I'm not sure what you mean by this.
> DHCP6 has INFORMATION REQUST and doesn't actually notify the DHCPv6
> server what addresses it has.

I assumed that DHCPv6 inform6 sends the selected address to DHCPv6 
servers, just like DHCPv4 inform does.

Found a dhcpcd man page of a more recent version [1], that already notes 
this.
Unfortunately the dhcpcd version number is not included in the man 
pages.

Additionally searching the net and it seems there is no such feature in 
DHCPv6 as with DHCPv4.
So this request is not feasible.

[1] https://www.daemon-systems.org/man/dhcpcd.8.html


> > *d) Support Privacy Extensions "temporary addresses"*
> >
> > Add support for Privacy Extensions "temporary addresses" (RFC 4941
> > <https://tools.ietf.org/html/rfc4941> [1], obsoleted RFC 3041)
> > Preferrable for outgoing connections. In contrast to stable private
> > addresses (RFC 7217 <https://tools.ietf.org/html/rfc7217> [2]) for
> > incoming connections.
> > This should allow to get rid of /etc/interfaces completely, no more
> > "iface eth0 inet6 auto" with "privext 2" needed for privacy extensions
> > and no more hardware-address based addresses.
> > I assume this can be heavily discussed, as sysctl
> > <https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt> 
> > [3]
> > plays another rule in this topic
> > (/proc/sys/net/ipv6/conf/<interface>/use_tempaddr).
> >
> > Or is there another way to *only* have stable private and temporary
> > addresses assigned via SLAAC? No hardware-based addresses anymore.
> >
> > Example:
> > ## Default to additional temporary addresses for GUA
> > slaac temporary 2000::/3
> > ## ULA is handled by dhcp, no SLAAC
> >
> > interface eth0
> >   ## Temporary addresses for GUA
> >   slaac temporary 2000::/3
> >   ## Stable private addresses for services on GUA, preferred as the 
> > very
> > last for outgoing connections (that's what the temporary address is 
> > for)
> >   slaac stableprivate 2000::/3 PLFT=0 inform6
> >   ## ULA is handled by dhcp, no SLAAC
> >
> > [1] https://tools.ietf.org/html/rfc4941
> > [2] https://tools.ietf.org/html/rfc7217
> > [3] https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt
> > [4] Linux: ipv6_create_tempaddr()
>
> Temporary addresses should already work.
> But I've not tested this in a long time, so could be broken.
> I'll look into this tonight.
>
> > Kind regards and thanks for considering any of these ideas
> > Maddes
> >
> > P.S.:
> > Unfortunately the Debian package has only the older version dhcpcd
> > 6.10.1 (without static ip6_address), so I do not know if any of these
> > have already been addressed.
>
> Yeah, debian really needs to update.
> I would do it myself, but I find dealing with their overly complex
> packaging system too time consuming.

One of my next tasks is to become a Debian maintainer for the makejail 
package.
Maybe I will also be able to help you in the future with this.


> > P.P.S.:
> > Didn't know if I should have created a task for this feature request 
> > at
> > https://dev.marples.name/ as I assume this feature request will be 
> > split
> > in different tasks.
>
> Split out yes.
> Discussing here is fine, but I like to ask that the requestor makes the
> tasks at the above link.
>
> Roy