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

["Bernie Volz (volz)" <[e-mail]>]

Jinmei:

My reaction is you are wrong – the PIO would, whenever sent, be sent with the preferred and valid lifetime REMAINING on the PD lease. So, sure a PIO sent just after the PD lease started would have (close) to the full values, but the values sent an hour later would be 1 hour less than they were.

Thus, I don’t see a problem as the preferred and valid lifetime of the PIO run down as the time of the lease runs down. At T1 (if 50 % of the preferred lifetime), a PIO sent would have ½ preferred lifetime (preferred lifetime – T1) and a valid lifetime of the original valid lifetime – T1.

This is different than if you explicit configured a manual prefix on a router with preferred/valid lifetimes – those would always be advertised in PIOs with the same values. But, when a lease is involved, the values run down and thus the PIO must contain just the remaining times.

Thus, it all works out nicely?

I will take another look at the IAPREFIX preferred/valid lifetime definitions as perhaps we need to tweak them a bit.

- Bernie

On 6/16/17, 2:28 PM, "[e-mail] on behalf of 神明達哉" <[e-mail] on behalf of [e-mail]> wrote:

    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 1 week (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 6 days.  End
    hosts receiving this prefix will configure their addresses, resetting
    its preferred lifetime to 6 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 6 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 6
    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