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

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

>>>>> On Fri, 28 Feb 2003 00:46:37 +0000, 
>>>>> Ole Troan <[e-mail]> said:

>> 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.

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

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.

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

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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[e-mail]
_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg