Date: Mon, 19 Aug 2002 18:44:08 +0900
From: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
| i think the sentence lacks "for existing connection" at the end.
You're right, it does lack that. But that is not an accident, it
isn't intended to have that qualification.
| TCP SYN is definitely an indication of a new connection.
Yes, but that isn't relevant.
I think you're being too strict on what deprecated addresses should be
used for, and what they shouldn't.
A deprecated address is still a valid address, and can be used for
anything at all.
However, they're addresses that the intent is to stop using sometime
soon, and if we don't want to break connections when the address becomes
invalid, we should try to avoid using them when possible.
But that doesn't mean that we break/refuse existing communications
earlier than we need to to achieve that.
If I have an address, A1, which is goingto change to A2, what I do is
make A1 deprecated, and A2 preferred, and at (more or less) the same
time I start announcing via the DNS the A2 address instead of the A1
address.
Remote nodes will take something between hours, and days, depending
on DNS TTLs to detect the change from A1 to A2 - in the interim period the
only address they have is A1, that's the only one they can use.
If I refuse incoming connections to my (deprecated) A1 address during
this period, those remote nodes have no way to contact me.
If I didn't deprecate the old address, then I'd have two preferred addresses,
and connections started at my node would be just as likely to use A1 as A2,
and that isn't what I want - since the address is changing, everything
should use A2 in preference to A1, when that is possible.
So, what I do is use A2 (the preferred address) when there's no reason to
care which address is used, but I allow A1 anywhere there's a reason to
prefer it (remote node has selected it, or it is in some way related to
an ongoing conversation - not connection - that us using A1, like the
series of connections used during FTP).
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]
--------------------------------------------------------------------
