> That's true in most cases, but as I pointed in my
previous message,
> Release/Reply exchanges are an exception, that is, the
server and the
> client can be successfully synchronized even if some of
the messages
> (Reply in this case) are completely lost. From a quick
reread of
> RFC3315, it also seems to apply to Decline/Reply
exchanges.
In terms of Release/Reply, it sounds like you are referring
here to the
case of the relay/router being left with stale state. But,
if the
relay/router
also configures a client (as in
'draft-templin-autoconf-netlmm-dhcp-04.txt'),
the server can send a Reconfigure to the relay/router's
client asking it
to
perform an Info-Request/Reply exchange that would convey the
correct
RAAN/SRSN options. I'm sure there are other approaches too.
I don't see that Decline/Reply is quite the same, as there
is no
provision
for the client to terminate the retransmission procedure
early. But even
if it were the same, the same approach described above (or
other
approaches) could still be used to ensure reliability.
> In the address allocation case, the relay (= router)
should normally
> know the link prefix anyway so that it can advertise
the prefix in
> Router Advertisements (at least with the L flag ON).
Some links may have no prefixes, and others may have
prefixes with
'A' = 'L' = 0. Clients should still be able to get an
address via DHCP
w/o having to delegate an entire prefix.
> There may be
> exceptional cases, of course, and if those are
realistic and there's
> no alternative for some reason, it may make sense to
apply RAAN to
> address allocation.
OK. DHCP address delegation has the advantage that the DHCP
server ensures uniqueness. This may be necessary for links
on
which RFC2462 DAD is unreliable due to message loss, on
links
with asymmetric reachability, etc.
>My point is (IMO of course) that operations
> relying on RAAN (+ SRSN) are pretty dangerous with many
pitfalls, and
> so we should begin with very specific case(s) where we
really need
> RAAN without any possible alternative.
As I said before, I respect your opinion. But, if there are
other known
pitfalls/dangers IMO we should discuss them here and have
them
out on the table. Are there others we should know about?
Thanks - Fred
fred.l.templin boeing.com
_______________________________________________
dhcwg mailing list
dhcwgietf.org
https://
www1.ietf.org/mailman/listinfo/dhcwg
|