Subject: RE: Status of <draft-hinden-ipv6-global-local-addr-00.txt>

From: "Michel Py" <[email-masked]>
Date: Wed, 11 Jun 2003 08:15:10 -0700

kre,

| Alain Durand wrote:
| Reachability os one thing, but you may have to wait for TCP timeouts.
| RFC1122, section 4.2.3.5 TCP Connection Failures
| Says that the initial SYN has to wait at least 3 minutes...

> kre wrote:
> You're assuming that I am actually using a TCP SYN to
> detect reachability. That isn't the way it is done. We want
> to make things work well, not arbitrarily slow them down.

The problem is that the only way to _really_ test reachability is to
actually try. For example, if you can successfully ping a host it does
not mean that you can telnet to it (or the opposite: ICMP might be
blocked and it might be the best path). Or if you can open an http
connection on port 80 it does not mean that you can open an https one on
port 443 (because someone forgot to open the port) or the opposite
(because the network administrator wants to enforce an https-only web
server).

Note that I am not suggesting that the reachability discovery should be
application specific, but OTOH I don't really see how it can't be.

There might be a slippery slope that says to reduce the SYN delay, but
I'm not buying into it. Look at SMTP for example: if you open a
connection on port 25 to my mail server it is going to check your IP
against a number of spam lists before returning the ACK. This takes
time; if we put 100ms here it is broken.

What Alain refers to is one of the reasons I stated earlier that we will
continue to see split or dual-headed DNS, because if an app uses TCP as
the transport mechanism, we are looking at either a SYN to detect
reachability or at an app failure because the reachability detection
mechanism used ICMP or UDP. In either case, we are looking at
unacceptable delay. Delay leads to frustration. Frustration leads to
split-DNS.

Michel.

--------------------------------------------------------------------
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: Robert Elz <[email-masked]>
Date: Wed, 11 Jun 2003 22:19:25 +0700

Date:        Wed, 11 Jun 2003 08:15:10 -0700
    From:        "Michel Py" <[email-masked]>
    Message-ID:  <[email-masked]>

  | The problem is that the only way to _really_ test reachability is to
  | actually try.

Of course - but what we're looking for here is a hint as to which address
is likely to be best to try first.   We don't need certainty for this,
we just need an indication what is going to work (or is likely to be going
to work).

Having received that indication, we can then try the addresses in a sane
order, instead of either random, or based upon the guesses of people
here as to what is necessarily always going to work best for everyone.

The only real proof of what works is the real connection open, and must
remain that way.  No-one wants to alter that.

kre