1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.IPV6

  • DHCPv6-PD requests, and virtual machines

    From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Michael Richardson on Wed Sep 1 19:10:02 2021
    Michael Richardson <[email protected]> writes:

    https://www.rfc-editor.org/rfc/rfc9096.html was just published.
    While is has specific relevance to those running Debian as their CPE, it also has relevance to people running Debian on a desktop or laptop, and also using virtual machines.

    It is not yet popular to get prefixes via DHCPv6-PD for use with VMs (LXCs, Dockers...), I think that part of this is due to lack of clear infrastructure for doing that.

    In particular, RFC9096 makes it clear that DHCPv6-PD clients ought to store the prefixes they got in stable fashion that survives reboots.
    The question is, where would we do that on Debian?
    It would be nice if we could do this in a fashion that was independant of the various tool options that exist to manage things.

    Yes, standardised persistent lease and DUID storage would be nice.

    But I think we can start much simpler by making sure we follow https://datatracker.ietf.org/doc/html/rfc9096#section-3.1
    everywhere.

    ifupdown has this extremely annoying misfeature that it forces a release
    on shutdown, both for DHCP and DHCPv6. The automatic release on every
    restart forces an unwanted and unnecessary renumbering event.

    Personally, I just gave up on the whole thing and started configuring my interfaces as manual instead. Using stanzas similar to this:

    iface foo0 inet manual
    up /sbin/dhclient -4 -v -i -pf /run/dhclient.$IFACE.pid -lf /var/lib/dhcp/dhclient.$IFACE.leases $IFACE
    up /sbin/dhclient -P -v -pf /run/dhclient6.$IFACE.pid -lf /var/lib/dhcp/dhclient6.$IFACE.leases $IFACE
    down /sbin/dhclient -4 -v -i -x -pf /run/dhclient.$IFACE.pid -lf /var/lib/dhcp/dhclient.$IFACE.leases $IFACE
    doen /sbin/dhclient -P -v -x -pf /run/dhclient6.$IFACE.pid -lf /var/lib/dhcp/dhclient6.$IFACE.leases $IFACE


    If it's not obvious: That is exactly what ifupdown would do with
    "dhcp" except that we run the client with -x (stop) instead of -r
    (release) on interface down.



    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael Richardson@21:1/5 to All on Wed Sep 1 18:40:02 2021
    --=-=-=
    Content-Type: text/plain


    Hi, I don't know if I'm still on this list, or if I got kicked off due to outsourced spam filtering.
    I did find my subscribe message from 2001 :-)

    https://www.rfc-editor.org/rfc/rfc9096.html was just published.
    While is has specific relevance to those running Debian as their CPE, it also has relevance to people running Debian on a desktop or laptop, and also using virtual machines.

    It is not yet popular to get prefixes via DHCPv6-PD for use with VMs (LXCs, Dockers...), I think that part of this is due to lack of clear infrastructure for doing that.

    In particular, RFC9096 makes it clear that DHCPv6-PD clients ought to store
    the prefixes they got in stable fashion that survives reboots.
    The question is, where would we do that on Debian?
    It would be nice if we could do this in a fashion that was independant of the various tool options that exist to manage things.


    --=-=-=
    Content-Type: text/plain
    Content-Disposition: inline
    Content-Description: Signature

    --
    ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [





    --=-=-=--

    -----BEGIN PGP SIGNATURE-----

    iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmEvqDgACgkQgItw+93Q 3WXeIQf+KsoG6J0vxn6ZJR3WN0KGe5CwPkbHKlC4NW7hfMT9Pf6MFHPWn7YogYW0 6910mRx6QG2csE/GA/P4pQI+4bP1HCz3t/wGeTnXAWIjCNpdZo4KjFKZPe3zGQtI qRZkdOuhxoNmepQLAVlpqjVhwtBepAn0ketX5KxHt3hk4Tl3LpaQCaQPdRfPBVNi O6z7sTJryH3zqWQk1TpJJ8WP7WGcMySM3bAAdxHM6wbX0QgH1j0/IED5Ib2v8lNF cy2GJJxj2fYGCw6/nihB0ceGoHNS0PIep/5BT4o+w1jQ+WdvY3O7c4VjvbRBbtFf ZUuS/CABUlb0RoQKO2xa7w+htzchXw==
    =Nd+V
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to Henrique de Moraes Holschuh on Sat Oct 16 21:10:01 2021
    Henrique de Moraes Holschuh <[email protected]> writes:

    On Wed, 01 Sep 2021, Bjørn Mork wrote:
    ifupdown has this extremely annoying misfeature that it forces a release
    on shutdown, both for DHCP and DHCPv6. The automatic release on every

    This is *highly* desired *on IPv4*, wherever address pools are scarce.

    I disagree.

    You'll always need enough addresses for all your clients. If you have a
    stable set of clients, then there is no problem letting a client reboot
    without releasing the address.

    If you have a constant client churn, like for example a public hotspot,
    then you should definitely not depend on clients releasing their address
    on shutdown. You need to set a short enough lease time. Preferably
    still long enough to keep the address over a reboot.

    Releasing the address on shutdown doesn't solve anything. It just
    creates unnecessary problems.

    The correct thing would likely be: do not do it on IPv6, but still do it
    on IPv4.

    Then at least make it configurable.


    Bjørn

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Henrique de Moraes Holschuh@21:1/5 to All on Sat Oct 16 20:20:01 2021
    On Wed, 01 Sep 2021, Bj�rn Mork wrote:
    ifupdown has this extremely annoying misfeature that it forces a release
    on shutdown, both for DHCP and DHCPv6. The automatic release on every

    This is *highly* desired *on IPv4*, wherever address pools are scarce.

    The correct thing would likely be: do not do it on IPv6, but still do it
    on IPv4.

    --
    Henrique Holschuh

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)