I'm investgating how deprecated address should be treated, and have one
question (I need a tiny clarification).
RFC2462 talks about how to handle deprecated address, in multiple
places. 5.5.4 looks to be the most definitive one.
It basically says, in the first couple of lines:
1. use of deprecated addr with existing communication is okay -
"SHOULD continue to be used"
2. use of deprecated address for new communication:
(2a) "SHOULD NOT be used if no alternate address with sufficient
scope is available"
(2b) nothing mentioned otherwise - implies that it is permitted to
use deprecated address.
we can optionally disallow the use of deprecated address, in
(2b) case.
if we think about some scenarios with the above condition, it will be
like below. for me "new inbound TCP SYN" case (3rd bullet below)
is not very clear, and I may need a clarification. if our intent is
to make the deprecated address (or the /48 prefix associated with it)
to go away, it may be better to always reject the new TCP connection
attempt. however, RFC2462 5.5.4 does not seem to do that.
so I'm a little bit confused.
- I have an existing TCP connection with local address bound to
a deprecated address. can I send a TCP packet to the peer?
yes, based on condition 1.
- User application issued TCP connection request. The kernel need to
establish a new connection. Can I use a deprecated address as the
local address?
if we have alternate address, no, based on (2a).
if we have no alternate address, it falls into (2b).
- if (2b) behavior is allowed, yes (default).
- if (2b) behavior is disallowed, no.
- I got a new TCP connection request from outside, with my deprecated
address as the destination. am I allowed to accept this connetion?
since we have no control over the address on our side, this
falls into (2b).
- if (2b) behavior is allowed, yes.
- if (2b) behavior is disallowed, no. note that we cannot
issue TCP RST in this case (if we issue TCP RST we will
need to use deprecated address as the source)
- UDP issues needs more thinking - how we should handle connected/
non-connected UDP sockets?
- ICMPv6 echo/whatever?
the behavior would affect site renumbering scnearios a little bit.
itojun
--- RFC2462
5.5.4. Address Lifetime Expiry
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.
An address (and its association with an interface) becomes invalid
when its valid lifetime expires. An invalid address MUST NOT be used
as a source address in outgoing communications and MUST NOT be
recognized as a destination on a receiving interface.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
