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

Michael Richardson <[email protected]>
Newsgroups gmane.ietf.dhc
Message-ID <15985.1703694982@localhost>
Bernie Volz <[email protected]> wrote:
    >> On Dec 26, 2023, at 5:59 PM, Michael Richardson <[email protected]> wrote:
    >>
    >> 
    >> Bernie Volz <[email protected]> wrote:
    >>> If you want to report upstream, why not just relay the notification?
    >>
    >> a) because often the local server actually needs to keep it's own database.

    > There’s no reason the notification cannot be consumed both locally and
    > forwarded. Obviously the forwarded request’s reply likely should be
    > dropped if a locally generated reply is being sent - but that’s easy
    > enough for relay to handle by adding something into the Interface ID
    > option?

Well, does the local processing result in an acknowledgement?
What if the forwarded copy gets lost?
If so, then the client stops sending, and the upstream does not get updated.

    >> b) because it might need to filter based upon which addresses are being
    >> reported about.  For instance, filter out ULAs, but keep GUAs.
    >>
    > No reason that device couldn’t filter out ones it doesn’t want to relay.

    >> c) it seems to me like the local server should perhaps be taking
    >> responsability for the delivery.

    > That is perhaps the one benefit for not relaying (see a) but I guess
    > you could change it so relayed Reply is delivered back to client (not
    > local one). This mechanism isn’t expected to be perfect since it may be
    > a while before clients even add the support (and some may never).

In domains where they care, it will get done, I think.
There is also a question of connectivity:  if the enterprise wants to collect
the ULAs that are being used in the branch office, but those ULAs are not
routed, then the replies might not come back if they are unicast.

There is another situation worth dealing with: ULAs are supposed to be routed
(and DHCPv6-PD into the branch office), but there is some "rogue" ULA at the
branch office which the printer has adopted as it's only address.  Knowing
this would be really useful in diagnosing why stuff doesn't work.
(Maybe SNAC is involved)

--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

_______________________________________________
dhcwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dhcwg
signature.asc (application/pgp-signature, 515 B)
-----BEGIN PGP SIGNATURE-----

iQFKBAEBCgA0FiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmWMUoYWHG1jcitpZXRm
QHNhbmRlbG1hbi5jYQAKCRCAi3D73dDdZaDHB/9RUsObRUc7iBrX3hwWUcNA+dOd
sOn+XxrKp4PDRVLAUW/VgLay01ae/9ft7VqnAEZxwZMH5DS4MWE+TJJYyMOM1L4X
W46PxGCFsWvP1ziGsC5dH4EJoJql57xniloDZDFNOAaHz8mqQZ5qi8qmu568Uph7
xLj1KMYr0cP5nENw8iHkTzPXAbp0CyJ3Vm2SZx5fKNrvLFf0usuKEfZHAeJzFARQ
pTvq+4slKy5NGIEia12/x/Y6O5uafSuFbiXBmitXTMO0OEm8iR3+Qzt+EUrtMTUN
w0remTC3rFv7arJF2ickYZ6vzAR/axxAuuJ/OyKVff68M7oGaxl2oclgfAeD
=oD4f
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.