Date: Mon, 19 Aug 2002 11:03:45 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| second, the document does not give any guidance when TCP SYN is sent to
| deprecated address. take, for instance, here's the definition from
| page 19:
|
| with TCP SYN sent from outside, it is not an existing communication.
| however, we have no choice on picking other addresses (since TCP
| requires us to swap the src/dst address).
I think this is actually OK. When the SYN arrives, it must be
accepted, as you quoted ...
IP and higher layers (e.g., TCP, UDP) MUST
continue to accept datagrams destined to a deprecated address
After that, TCP processes the incoming connection. That makes existing
communications. Then, when replying, the SYN+ACK can be sent from the
address to which it was sent (deprecated or not). So, I doubt there's
actually a problem there.
| our recommendation is to explicitly state that deprecated address
| SHOULD NOT be used for new connection attempt (with no "if an
| alternate..." clause).
That's a different issue. The alternate clause is to handle the
situation where only deprecated addresses exist, and a node wants
to initiate new communications. Are you really recommending that
a node which has only deprecated addresses is unable to iniatiate
a connection? That is, it is prohibited from sending an SNMP trap
(or anything like it) to inform a management station that all its
addresses are deprecated (as prohibited as SHOULD NOT would make it
anyway).
| in KAME implementation we had a configuration knob to control
| the behavior: if the knob is 1, we accept TCP SYN towards deprecated
| addresss. if 0, we send TCP RST with deprecated address as a source
| (since it gives a better feedback to sender than to simply drop TCP
| SYN attempt).
I'm not sure the knob is needed, just "1" is the setting I'd expect,
always. If your DNS update hasn't filtered around the world yet, you
have to expect incoming packets to deprecated addresses.
| recently it was found that knob = 1 is not a good idea as we have
| protocols that use multiple TCP sessions - for instance, suppose you
| are ftp server and TCP control connection attempt is sent to deprecated
| address. with knob = 1 we accept it. then when we are to make active
| TCP data connetion with EPRT (IPv6 PORT), we can't make it as we are
| forbidden to make TCP connection with deprecated IPv6 address as the
| source.
I think that's another example of existing communications. The rule
doesn't say "existing connection". Whenever what you're doing requires
use of the deprecated address, you use it. That is, if an application
bind()'s to a deprecated address, the stack should simply use that. You
assume the application knows what it is doing, and don't attempt to second
guess.
The rule against using deprecated addresses, as I understand it, is just
that when there's no reason to choose one over the other, or no other reason,
always use the preferred address. If there's a reason to use the
deprecated address (like things will break if we don't) then use it.
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
