Re: [dhcwg] Adoption Call for draft-wkumari-dhc-addr-notification-07- Respond by April, 20 2023

[Michael Richardson <[e-mail]>]

TL;DR> let's go ahead with the document.

Jen Linkova <[e-mail]> wrote:
    >> It seems that this will be in conflict with
    >> draft-collink-v6ops-ent64pd, should it be adopted.

    > I'm not sure it's the case, actually.  Let's say my DHCP server knows
    > that clients on the link A should be delegated the prefixes from
    > 2001:db8:a::/48.  Then if it receives ADDR-REG-INFORM from link A for
    > an address in 2001:db8:a::/48, it shall be considered "appropriate for
    > the link".  Or am I missing smth?

So 2001:db8:a::/64 is the "LAN" onlink.
And host 2001:db8:a::1234 has done a DHCP-PD and been delegated 2001:db8:a:0001::/64.
It now sends a registration for 2001:db8:a:0001::babe/128.
Does it send that from 2001:db8:a:0001::babe or from 2001:db8:a::1234?

I prefer that it sends it from ::babe.
I prefer that we don't try to associate the delegated /64 with the address
that asked for it... because... a) the requesting address might change due to
reasons (privacy, etc.)   b) OSPF might move the prefix around a bit.

    >> The Security Considerations relating to the AUTH option
    >> are... insufficient.  I wish we'd removed it from 8415.

    > So would you prefer if we do not mention it, or..?

DHC AUTH was unfortunately undeployable in symmetric form, and the assymetric
form (RSA signatures) was still born.  Twenty years ago, we actually tried to
use it:
  https://web.archive.org/web/20020719073631/http://www.wavesec.org/

I could probably dig out the diagrams.

    >> Does the packet need to originate from the IP address which is being
    >> registered?

    > This is to prevent spoofing: the host would need "own" the address, if
    > the infrastructure supports SAVI.

So, the answer is yes, it must originate from the IP address which is being registered?

    >> Can a host include RFC4704 (Client FQDN) in the same packet to have
    >> the reverse DNS updated?

    > Section 4 already says that: "Clients MAY include other options, such
    > as the Client FQDN Option [RFC4704]."

Ah, I missed that.

    >> There is some subtle (emotional?) connection to RFC8505, which I'll
    >> try to resolve in my mind.

    > I haven' read that one, adding to my reading list. Do you think there
    > are any conflicts between two documents?  Thanks!

There are no conflicts, but there might be something to learn, and I'm
thinking about that.

Lorenzo Colitti <[e-mail]> wrote:
    > What's your concern with that specifically? FWIW, we have heard from
    > large Android deployments that simply take the FQDN option in the
    > DHCPv4 request and put the contents in their internal DNS zones. So
    > basically any host that can get on the link and send a DHCP request
    > will be able to populate an arbitrary name in DNS. This doesn't seem
    > that different.

It's not really different at all.

The zone that the DHCPv4 went into was likely an internal (RFC1918) zone, so
has fewer privacy implications.  A smart operator could put entries it into
an ip6.arpa zone with that has limits on whom may query it.
Some interesting ACLs and (and CNAMEs) one could have externally visible and
invisible names.

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