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 -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
