Re: [dhcwg] WGLC for draft-ietf-dhc-rfc3315bis-08 - Respond by May 30th, 2017

[神明達哉 <[e-mail]>]

(Sorry, I've noticed a minor but possibly very confusing typo in my
previous message.  I'm replacing the whole text with correcting it
below.  Please ignore the previous one)

At Wed, 14 Jun 2017 20:13:56 +0000,
"Bernie Volz (volz)" <[e-mail]> wrote:

> We are working to get the -09 version out before the July 3rd
> IETF-99 cutoff. And, I think we're waiting on text for you regarding
> one item:

I don't think I promised I would offer text :-) but I admit I should
have provided some followup much earlier.

> > > BV> Unless you provide text, I think we'll leave this alone as
> > > mentioned earlier we feel that this document is not the one that
> > > should describe how these lifetimes are to be used.
>
> > This is not just about wording.  It's about actual protocol
> > behavior, and I don't even know if we have common consensus on it.
> > I also think we can't simply ignore the issue by being silence,
> > since it could result in a bad situation like a site keeps
> > advertising a prefix in RA as a preferred one even when it's
> > already "deprecated" or even "invalidated" in terms of prefix
> > delegation.  I'll see if I can offer something more concrete, but
> > I'd like to raise it as a possible blocking issue.

As I said before (in the quoted text) I actually suspect it's
premature to talk about specific text before discussion.  So let me
talk about what I think is an issue more specifically.

First off, what's this preferred lifetime in the first place?  Section
21.22 simply says:

      preferred-lifetime   The recommended preferred lifetime for the
                           prefix in the option, expressed in units of
                           seconds.  A value of 0xFFFFFFFF represents
                           infinity.

What does this "recommended" mean?  As far as I can see it's not
explained anywhere else in the draft.  But one possible, or likely,
interpretation would be that it's a recommendation for addresses
configured from this prefix.  More specifically, it would be to use it
as the preferred lifetime of a prefix information option (PIO) of RA
for the delegated prefix (or prefixes derived from the delegated
prefix).  Assuming that, consider some more concrete issue:

Assume a PD client gets an /64 IA_PD prefix with preferred lifetime
being 7 days (an arbitrary choice).  If T1/T2 of the IA_PD follows the
recommended value of Section 21.21, the client will try to renew it in
3.5 days.

Meanwhile, this prefix is typically advertised in the downstream link
in the prefix information option (PIO) of RA.  Assuming the above
interpretation of "recommendation", a straightforward implementation
of it is to set the preferred lifetime of the PIO to 7 days.  End
hosts receiving this prefix will configure their addresses, resetting
its preferred lifetime to 7 days every time it receives the PIO (which
is periodically advertised, usually every several minutes).

In 3.5 days the PD client starts renewing the prefix.  But, now suppose
this exchange doesn't succeed (even after the client switches to
REBOUND).  Then what should happen in 7 days?  Should the delegated
prefix now be considered "deprecated"?  And what would that mean?
Should the preferred lifetime value of the corresponding RA PIO be
reset to 0 from this point?

And, what if the PD client can't even RENEW/REBOUND until the valid
lifetime expires?  If, like above, the valid lifetime value is copied
from IA_PD prefix to RA PIO, end hosts will have an address with a
pretty large valid lifetime (in this example scenario, at least 7
days) at the time of expiration due to the periodic RA advertisements.
And, even if the advertised PIO valid lifetime is set to 0 at that
point, end clients will still keep using the address for two hours
(see RFC4862).

I actually don't know whether/how existing implementations deal with
cases like this, but I wouldn't be surprised if there are naive
implementation that simply copies the preferred/valid lifetimes from
PD to RA, potentially having the problems described above.  I suspect
we've not heard problem reports in the actual deployment simply
because the lifetimes are sufficiently long compared to possible
network outage periods, and also perhaps because if this problem
happens because the upstream becomes unreachable, then it doesn't
matter much anyway if the end clients keep using "expired" addresses.
Still, as a protocol design I think it's a kind of defect and we
cannot just rely on the operational conditions.

So, can we agree there's a potential problem as some of the
definitions and the usage are not clear enough, aside from whether
that should be addressed in rfc3315bis?

--
JINMEI, Tatuya