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-----