dhcpcd-discuss

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 

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 

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 

D) SUPPORT PRIVACY EXTENSIONS "TEMPORARY ADDRESSES" 

Add support for Privacy Extensions "temporary addresses" (RFC 4941 [1]
[1], obsoleted RFC 3041)
Preferrable for outgoing connections. In contrast to stable private
addresses (RFC 7217 [2] [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 [3] [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() 

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. 

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. 

  

Links:
------
[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