Bernie Volz \(volz\) <[email protected]> wrote: > And, something to ponder: - In 5.3, is there any value in potentially > allowing a Relay Agent to supply these options to a server to > potentially return to a client via the RSOO option (RFC6422)? > I raise this question as it seems no documents have mentioned this and there > was a case that recently came up where this was useful for another > option, so just want to remind folks that it exists and to consider > whether it could be used for these options.
We expect that most of the time, these options will be returned for the reverse zone at the time that a IPv6 PD is initially done. (And the rest of the time, it will be because forward zone is *also* configured by the ISP) Do Relay Agents delegated PD? Alas, no. So I can't see a use case for putting those options there. One thing that I just thought of, and I don't remember if we discussed it at all, was whether there was a need to synchonize these returned options with the IA_PD lifetimes. I think not: because if the ISP renumbers the end user (whether a flash number or controlled), then they can also just stop synchronizing the reverse zone, and that effectively kills the reverse zone content. The end user might suffer slightly by having locally served reverse names that are no longer connected: they should obsolete that zone when they realize that their PD hasn't been renewed, until such time, (if it was a flash renumber), they would be right to think that they legitimately control them. (I'm still miffed that Relay Agents have to snoof to learn PD, and nobody seems to think this a problem) -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
