Subject: RE: I-D ACTION:draft-ietf-ipngwg-multi-isp-00.txt

From: Richard Draves <[email-masked]>
Date: Wed, 22 Sep 1999 12:22:06 -0700

I like the idea of using router renumbering to temporarily deprecate the
prefix obtained from a broken ISP. This would improve source address
selection. 

Is there a problem with the denial-of-service provisions in RFC 2462
(stateless address autoconf)? When I first implemented that provision I
thought it should apply to both the valid lifetime and preferred lifetime
(which would prevent abruptly setting the preferred lifetime down to zero),
but rereading the text now it seems to apply to only the valid lifetime.

I'm not satisfied with the proposed use of mobility mechanisms. There are
several problems:

- Will H immediately send a binding update to X, or will H wait until it has
some data that it wants to send to X and then include the binding update? If
the latter, then X can't reach H for an unbounded period of time.

- What if this is not a TCP connection, but X is using UDP to send to H?
Then H won't know to send a binding update to X.

- X will keep the binding update that it receives from H in its binding
cache. Note that this is a cache. If the binding update should get dropped
from the cache, then X will not be able to reach H. (In the mobility case,
this is OK because H is still reachabile via the home agent.)

- What if H and X are both multi-homed. They have a connection to each other
via a shared ISP A. H is also connected to ISP B and X is also connected to
ISP C. ISPs B & C are connected to each other. H and X establish a TCP
connection using ISP A (per src/dst address selection, the common prefix is
preferred). Now ISP A goes down. The proposed mechanism will not recover
from this.

Rich
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Thu, 23 Sep 1999 07:42:50 -0400

> but rereading the text now it seems to apply to only the valid lifetime.

It was specifically made to apply only to the valid lifetime as
resetting that to 0 has immediate fatal consequences. In contrast,
tinkering with the preferred lifetime shouldn't break things. I.e., if
the only address you have becomes deprecated, you are still allowed to
use it. 2462 says you SHOULD NOT use a deprecated address for new
communication if a preferred address of sufficient scope exists. Thus,
it still make sense for an implementation to try using a deprecated
address if their are no other better addresses available.

Thomas