Re: [dhcwg] WGLC started -- draft-ietf-homenet-naming-architecture-dhc-options-12

[Michael Richardson <[e-mail]>]

Bernie Volz \(volz\) <volz=[e-mail]> 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 <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide