Re: WGLC for draft-ietf-dhc-addr-notification - Respond by December 11, 2023

Michael Richardson <[email protected]> Fri, 29 Dec 2023 12:02:50 -0500

Newsgroups	gmane.ietf.dhc
Message-ID	<22712.1703869370@localhost>

Jen Linkova <[email protected]> wrote:
    >> I wrote some text:
    >> https://github.com/wkumari/draft-wkumari-dhc-addr-notification/pull/68
    >>
    >> and I'm sorry to open this can of worms, but I don't think that enterprises
    >> will be happy without this.

    > I have some concerns.
    > 1. The desired result can be achieved by relaying the messages - and
    > it would using the standard DHCP mechanism. What you are proposing
    > requires developing a new mechanism for proxying (and we'd need to
    > either sacrifice security, or let the proxy use a spoofed source
    > address).

I agree: it seems like overkill.

    > For #2.1  I'd expect the enterprise to collect that data from the
    > router (the same way they would need to do it for DHCPv[46] assigned
    > addresses). That information doesn't need to be collected  in real
    > time, so existing monitoring/telemetry mechanisms would do.

I can live with this.

    >> In particular, our desire to enable more
    >> (permissionless) DHCPv6-PD downstream will get the same pushback that has
    >> lead to this document.

    > I'm not sure what you mean about "permissionless' '. As long as the
    > server delegates the prefix, the administrator knows which device that
    > prefix was delegated to.
    > So accountability is there.

I agree that it's not quite a permissionless as NAT44 is; my point is that I
think/hope that enterprises will come to regard enabling anything to do
DHCPv6-PD will become ubiquitous.  That it's way better than hosts doing
NAT44 from an accountability point of view.  That's the tradeoff where the
admin wins.  Maybe for the host-with-VMs/containers relaying the addr-reg
messages is the right answer.

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

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg

signature.asc (application/pgp-signature, 507 B)