>>>>> On Fri, 28 Feb 2003 00:46:37 +0000,
>>>>> Ole Troan <[EMAIL PROTECTED]> 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.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
