Re: usage of rebind for PD (Re: [dhcwg] WG last call on draft-ietf-dhc-dhcpv6-opt-prefix-delegation-02.txt)

[Ole Troan <[e-mail]>]

Jinmei-san,

>>> 2. Section 11.1 now specifies the requesting router to use
>>> Rebind/Reply exchanges to verify an existing binding (instead of
>>> Renew/Reply exchanges).  According to the very recent
>>> clarifications on the base DHCPv6 spec, however, I'm not sure if
>>> Rebind is appropriate here; the server should drop the Rebind
>>> message unless it has an explicit knowledge about the validity or
>>> invalidity of the prefix, which should not be the case (e.g.) when
>>> the upstream link flaps.
>
>> Rebind now behaves just like Confirm. if by link flap you mean change
>> of link to another delegating router, the delegating router can reply
>> to a Rebind even without a binding if it knows through explicit
>> configuration that the prefixes in the IA_PD is not valid for the link.
>
> Are you referring to the following part of
> draft-ietf-dhc-dhcpv6-interop-00.txt?
>
> 1. Response of servers to Renew and Rebind messages, sections 18.2.3 and
>    18.2.4
>
>    Resolution: Leave the sentence in section 18.2.3 unchanged.  Replace
>       the sentence in section 18.2.4 with the following text:
>
>          If the server cannot find a client entry for the IA and the
>          server determines that the addresses in the IA are not
>          appropriate for the link to which the client's interface is
>          attached according to the server's explicit configuration
>          information, the server MAY send a Reply message to the client
>          containing the client's IA, with the lifetimes for the
>          addresses in the IA set to zero.  This Reply constitutes an
>          explicit notification to the client that the addresses in the
>          IA are no longer valid.  In this situation, if the server does
>          not send a Reply message it silently discards the Rebind
>          message.
>
> The problem here is that this is a MAY requirement and that "explicit
> configuration information" is ambiguous.
>
> Since this is a MAY, the delegating router (i.e. server) MAY NOT send
> a Reply message, which will cause a bad effect (that the invalid
> prefix is going to be used).  For the case of address assignment, this
> should be a minor issue, because this situation only happens when none
> of the events to issue a Confirm happen but the upstream router has
> somehow been swapped.

Rebind is only done for 10 seconds (using Confirms timers), then the
client goes back to Solicit state.

I don't think we can mandate that a delegating router will know in all
cases that a prefix is valid for a link or not. I think we should keep
the same text and reasoning as in the base spec.

could any of the DHCPv6 base spec guys answer why this is a MAY, as it
does delay detection of movement.

> For the PD case, however, we don't have Confirm/Reply exchanges.  So
> the requirement level should be stronger enough.

we do. just that we have to use a Rebind/Reply exchange using Confirms
timers since we want a binding confirmation, rather than just movement
detection.

> The same argument should apply to the ambiguous of the wording
> "explicit configuration information".  In my understanding, the author
> intentionally uses an ambiguous term because this is a very minor case
> and there can be a (unidentified) trick to build the explicit
> information, e.g., a background communication between a primary server
> and a secondary one.

I don't think "explicit configuration" is ambiguous as such. how a
server is configured to know which prefixes are appropriate for a link
is implementation dependent.

> Again, for the PD case, this is more likely to happen, so we need to
> be specific enough.

why do you say that? isn't it more likely that a host changes links?
what cases do you have in mind?

> Thus, I would suggest to add the following text (or something like
> this) to the delegating router behavior:
>
>          If the delegating router cannot find a requesting router
>          entry for the IA_PD and the delegating router determines that
>          the prefixes in the IA_PD are not appropriate for the
>          requesting router according to the delegating router's
>          explicit configuration information, the delegating router
>          SHOULD send a Reply message to the requesting router
>          containing the requesting router's IA_PD, with the lifetimes
>          for the prefixes in the IA_PD set to zero.  This Reply
>          constitutes an explicit notification to the requesting router
>          that the prefixes in the IA_PD are no longer valid.  The
>          explicit configuration information of the delegating router
>          contains the fact that the proposed prefixes from the
>          requesting router is not covered by a prefix for the
>          organization of the delegating router.
>
> In summary, I propose to change MAY to SHOULD and to add a concrete
> example of "explicit configuration information."
>
> It would also be helpful to describe how the requesting should react
> to this event.

requesting router should go to Solicit state. I think this will be
made clearer in modified base spec/new PD revision where we'll use
NotOnLink rather than lifetimes = 0.

cheers,
Ole
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg