we need some clarification to RFC246[12] with respect to "deprecated"
address handling.
first of all, definition/description of deprecated address is given in
multiple places in RFC2462, namely
page 3 (introduction)
page 6 (terminology)
page 8 (site renumbering)
page 19 (address lifetime expiry)
they have slightly different description with respect to deprecated
address handling.
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:
> A preferred address becomes deprecated when its preferred lifetime
> expires. A deprecated address SHOULD continue to be used as a source
> address in existing communications, but SHOULD NOT be used in new
> communications if an alternate (non-deprecated) address is available
> and has sufficient scope. IP and higher layers (e.g., TCP, UDP) MUST
> continue to accept datagrams destined to a deprecated address since a
> deprecated address is still a valid address for the interface. An
> implementation MAY prevent any new communication from using a
> deprecated address, but system management MUST have the ability to
> disable such a facility, and the facility MUST be disabled by
> default.
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).
our recommendation is to explicitly state that deprecated address
SHOULD NOT be used for new connection attempt (with no "if an
alternate..." clause).
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).
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.
itojun
--- tcp_input.c
/*
* If deprecated address is forbidden,
* we do not accept SYN to deprecated interface
* address to prevent any new inbound connection from
* getting established.
* When we do not accept SYN, we send a TCP RST,
* with deprecated source address (instead of dropping
* it). We compromise it as it is much better for peer
* to send a RST, and RST will be the final packet
* for the exchange.
*
* If we do not forbid deprecated addresses, we accept
* the SYN packet. RFC2462 does not suggest dropping
* SYN in this case.
* If we decipher RFC2462 5.5.4, it says like this:
* 1. use of deprecated addr with existing
* communication is okay - "SHOULD continue to be
* used"
* 2. use of it with new communication:
* (2a) "SHOULD NOT be used if alternate address
* with sufficient scope is available"
* (2b) nothing mentioned otherwise.
* Here we fall into (2b) case as we have no choice in
* our source address selection - we must obey the peer.
*
* The wording in RFC2462 is confusing, and there are
* multiple description text for deprecated address
* handling - worse, they are not exactly the same.
* I believe 5.5.4 is the best one, so we follow 5.5.4.
*/
if (!ip6_use_deprecated) {
if ((ia6 = ip6_getdstifaddr(m)) &&
(ia6->ia6_flags & IN6_IFF_DEPRECATED)) {
t6p = NULL;
goto dropwithreset;
}
}
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
