Subject: need clarification of "deprecated" address

From: [email-masked]
Date: Mon, 19 Aug 2002 11:03:45 +0900

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-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 16:26:24 +0700

Date:        Mon, 19 Aug 2002 11:03:45 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	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

---

From: [email-masked]
Date: Mon, 19 Aug 2002 18:44:08 +0900

>	continue to accept datagrams destined to a deprecated address

	i think the sentence lacks "for existing connection" at the end.

>actually a problem there.

	TCP SYN is definitely an indication of a new connection.

itojun

---

From: Jari Arkko <[email-masked]>
Date: Mon, 19 Aug 2002 12:58:03 +0300

> 	i think the sentence lacks "for existing connection" at the end.

Maybe not. I think the intention was for *our* node to not initiate
new connections using the deprecated address, not prevent other
nodes from doing so.

We could make it stricter of course, by not accepting even others
to initiate new connections. However, I believe this might be bad for
some protocols. Say, you are doing an FTP mget * from node X, which decides
to get a new RFC 3041 address in the middle of things. If I remember
correctly, FTP uses a new TCP session for each new file. Your FTP
session would not proceed if you refused to accept a new TCP session.

> 	TCP SYN is definitely an indication of a new connection.

Yes, but from the other end...

Jari

---

From: [email-masked]
Date: Mon, 19 Aug 2002 18:56:48 +0900

>session would not proceed if you refused to accept a new TCP session.

	these days FTP client/server implementations are picky about endpoint
	address, and we need to use the same address pair for control and
	data connection (to avoid FTP bounce attack).  therefore, FTP client
	side shouldn't use temporary address for the control connection.
	(apparently, server side shouldn't)

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 17:22:10 +0700

Date:        Mon, 19 Aug 2002 18:44:08 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	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

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 17:25:09 +0700

Date:        Mon, 19 Aug 2002 18:56:48 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	these days FTP client/server implementations are picky about endpoint
  | 	address, and we need to use the same address pair for control and
  | 	data connection (to avoid FTP bounce attack).

Yes, fine.   (Personally I still like 3 way FTP but that's not important
here).

  |	therefore, FTP client
  | 	side shouldn't use temporary address for the control connection.

No, temporary address is fine there, unless the overall FTP session will
last longer than a week (the valid lifetime of a temporary address using
the suggested timers)

  | 	(apparently, server side shouldn't)

Yes, that one is kind of obvious - temporary addresses are for a form of
identity hiding, it makes no sense to hide the identity of a server.

But this isn't because of deprecated address rules, just common sense.

kre

---

From: [email-masked]
Date: Mon, 19 Aug 2002 19:30:21 +0900

i guess you are confused.

>earlier than we need to to achieve that.

	i have never said we should terminate existing connections.  i suggested
	we should refuse new incoming connections (TCP SYN).

itojun

---

From: "Jim Fleming" <[email-masked]>
Date: Mon, 19 Aug 2002 05:46:04 -0500

----- Original Message ----- 
From: "Robert Elz" <[email-masked]>
> should use A2 in preference to A1, when that is possible.

This is a rather narrow-minded view, that makes many assumptions, which do not
necessarily hold, especially with 128-bit DNS and addresses. As an example, if the
addresses contain **version** information and/or **time-stamps** the end-to-end
agreement can be that one version of the software will use the addresses that match it
until some time is reached and they roll over to the next version. With the "toy" Internet
(i.e. 32-bit) addresses, there was not a lot of room to store extra information. As an
example, software can look at 2002 addresses and prefer those over 2001 addresses.
Next year, the software may prefer 2003, and deprecate 2001 and 2002.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...
http://www.ican.org/what's_new!!!.htm
http://www.iana.org/assignments/ipv4-address-space
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 17:58:36 +0700

Date:        Mon, 19 Aug 2002 19:30:21 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i have never said we should terminate existing connections.

No, I know you didn't.

  |     i suggested we should refuse new incoming connections (TCP SYN).

Yes, that is what I am arguing against.

The line of reasoning seems to be

	if we accept a connection to a deprecated address, we may
	have to open a connection from a deprecated address later.

	we're not allowed to open a connection from a deprecated address

	hence we should not accept connections to deprecated addresses

That's wrong because the middle point is wrong, you are allowed to
open a connection from a deprecated address.   You're just not supposed
to do that unless there is a reason (existing communications).

Note "communications" != "connection".

But even if it weren't for that point, you'd just be shifting the
finish line in a race condition.

That is,
	if we accept a connection to a non-deprecated address, and that
	address is later deprecated (which any might be) we may have to
	open a connection from that address even later

	we're not allowed to open a connection from a deprecated address

	hence we should not accept connections to non-deprecated addresses

and that's absurd.    That is, even if we weren't allowed to open a new
connection from a deprecated address (which we are, but ignoring that),
that's no reason not to accept incoming connections to deprecated addresses,
or to addresses that might become deprecated before the new connection has
finished.

Just treat a deprecated address identically to any other address, except
don't choose it as the source address if there's some reasonable alternative.

Or, if you like, just follow the rules in the address selection draft,
and aside from that, ignore "deprecated" as it applies to addresses.

kre

ps: I seem to recall that all this was discussed back when deprecated
addresses were invented.

pps: that we're having this discussion does suggest that you're correct
and the docs need clarification.

---

From: [email-masked]
Date: Mon, 19 Aug 2002 20:08:28 +0900

>	hence we should not accept connections to deprecated addresses

	FTP story was just an example.  independent from the FTP story, i am
	- pointing out that the current text does not give any guidance
	  to incoming TCP SYN case, and
	- we should drop incoming TCP SYN to deprecated addresses.

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 18:13:20 +0700

Date:        Mon, 19 Aug 2002 20:08:28 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	- pointing out that the current text does not give any guidance
  | 	  to incoming TCP SYN case, and

I am not disputing that come clarifications might be needed to the text,
just

  | 	- we should drop incoming TCP SYN to deprecated addresses.

isn't the clarification that should be made, it should be the
exact opposite of that.  We should accept TCP SYN to deprecated
addresses, for the reasons that Pekka just gave much more clearly than
I have been able.

kre

---

From: [email-masked]
Date: Mon, 19 Aug 2002 20:18:29 +0900

>addresses, for the reasons that Pekka just gave much more clearly than

	even if you don't advertise your address to public via DNS,
	people will try to connect (people can portscan, ping6 ff02::1,
	whatever).  i don't agree with Pekka's take.

itojun

---

From: Atsushi Onoe <[email-masked]>
Date: Mon, 19 Aug 2002 20:17:45 +0900 (JST)

> 	forbidden to make TCP connection with deprecated IPv6 address as the

Note that we are NOT forbidden, but just required valid reasons to do so
(from the definition of 'SHOULD NOT' of RFC 2119).  In your ftp scenario,
you can (or should) use deprecated address to avoid service disruption.

page 2 in RFC 2462:
|    when possible.  A deprecated address should be used only by
|    applications that have been using it and would have difficulty
|    switching to another address without a service disruption.

Atsushi Onoe

---

From: [email-masked]
Date: Mon, 19 Aug 2002 20:23:46 +0900

>|    switching to another address without a service disruption.

	this may be an implementation issue, but who should decide it?
	in KAME case we have kernel code which forbids the use of deprecated
	address as a source (bind(2)) and FTP daemon cannot override it for
	data connecdtion.

itojun

---

From: Atsushi Onoe <[email-masked]>
Date: Mon, 19 Aug 2002 20:29:08 +0900 (JST)

> 	  to incoming TCP SYN case, and

Isn't the text enough?  It looks to me that incoming TCP SYN 'MUST'
be allowed by default.

|    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.

> 	- we should drop incoming TCP SYN to deprecated addresses.

I don't think so.  Just the same reason of Pekka's comment.

Atsushi Onoe

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 18:29:28 +0700

Date:        Mon, 19 Aug 2002 20:18:29 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	even if you don't advertise your address to public via DNS,
  | 	people will try to connect (people can portscan, ping6 ff02::1,
  | 	whatever).

I'm not sure what this has to do with anything.   You're not suggesting
that not using deprecated addresses is a security issue, are you?

For the ff02::1 case there's no problem anyway - when (if) you reply to
that, you'd use a preferred (non-deprecated) address.   There there's no
existing communications reason not to do so.

I'm having trouble fathoming how portscan is possibly related.

In general, we want connections to work, we're not looking for reasons
to prevent them.   The only reason that we don't send from deprecated
addresses all the time (the only reason "deprecated" exists at all) is
that we're looking for a graceful way to retire an old address.

We can retire it (eventually) from foreign uses, bu aging it out of the
DNS.   That part is easy.   But we have to keep the address valid while
that is happening, so it can be used until it does eventually vanish.

But if we just keep it valid, then there's nothing to prevent our local
node (which does not look up the DNS before deciding what local address
to use) from using the address that we're trying to make go away.  So,
we mark it as special - don't use this one if it makes no difference
which address is used, use that one instead.

But once again, the aim behind all of this is to keep things working as
much as possible during the transition, not to find more ways to prevent
communications.

  | i don't agree with Pekka's take.

I do agree.   And as I recall, it was the reasoning that was also used, and
adopted, years ago.

kre

---

From: [email-masked]
Date: Mon, 19 Aug 2002 20:31:07 +0900

>|    disable such a facility, and the facility MUST be disabled by

	"new communication" isn't clear enough, IMHO.

itojun

---

From: Atsushi Onoe <[email-masked]>
Date: Mon, 19 Aug 2002 20:33:52 +0900 (JST)

> 	address as a source (bind(2)) and FTP daemon cannot override it for

Perhaps the bind(2) with the deprecated address specified explicitly
should be succeeded.

Atsushi Onoe

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 18:34:29 +0700

Date:        Mon, 19 Aug 2002 20:23:46 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	this may be an implementation issue, but who should decide it?

It was already decided long ago.   The doc may need to be made clearer.

  | 	in KAME case we have kernel code which forbids the use of deprecated
  | 	address as a source (bind(2)) and FTP daemon cannot override it for
  | 	data connecdtion.

That's an implementation bug (perhaps caused by doc ambiguities).
Just fix it.

kre

---

From: [email-masked]
Date: Mon, 19 Aug 2002 20:39:04 +0900

>It was already decided long ago.   The doc may need to be made clearer.

	"who" means "userland, or kernel".

itojun

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 18:42:10 +0700

Date:        Mon, 19 Aug 2002 20:31:07 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	"new communication" isn't clear enough, IMHO.

It would be hard to dispute that given the exchange of the past
hour or two.

How would you suggest that it be revised to have the proper effect?
(That is, to explicitly allow deprecated addresses to be used, other
than when it is a toss up which address to use).

Do we currently have a 2462 bis draft?

kre

---

From: Robert Elz <[email-masked]>
Date: Mon, 19 Aug 2002 18:51:00 +0700

Date:        Mon, 19 Aug 2002 20:39:04 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | >  | 	this may be an implementation issue, but who should decide it?
  | 	"who" means "userland, or kernel".

Oh, sorry, I misunderstood (which I guess was obvious).

For the kernel the decision is real simple I think.   If it is picking
a source address, don't use a deprecated one if it can avoid it (if all
addresses are deprecated, or even all of the appropriate scope I think
the address selection draft says, then it has no choice).

Otherwise, the kernel should not even notice that an address is deprecated.

Assuming there's some reasonable way to make the information available to
userland, it should adopt the same policy.   However, userland has done
extremely poorly on address management issues to date, so I am not
all that hopeful.

This doesn't make a big difference really though - preventing userland
from binding to a deprecated address might help very occasionally to
steer the application towards a preferred address (one would hope there
would be a better API for this than a syscall error...)

However, apps that bind to addresses that later become deprecated still
need to be dealt with.  Those apps should be able to discover that the
address they thought was correct, no longer is, and rebind to the new one.

Of course, there aren't many such apps, most just use the address the
DNS says to use for remote addresses (or one passed from the peer) and
whatever address the kernel likes (or the one selected by the remote
partner) for the local address.  Those just keep on keeping on...

kre

---

From: Pekka Savola <[email-masked]>
Date: Mon, 19 Aug 2002 13:57:52 +0300 (EEST)

> 	we should refuse new incoming connections (TCP SYN).

Note: 'communications' not 'connections'; the wording was deliberate, I 
think.

The point (as I saw it) was that if you want to deprecate an address, you
must first kill all references to that address.  If incoming connection
request comes in, probably either:

 1) the initiator has learned the address via some means (e.g. 
long-running application) some time ago before the address became 
deprecated
 2) the deprecated address is still referenced somewhere (e.g. DNS)

Sending RST might be ok for a purpose "ok, I'll reset this request
gracefully [compared to TCP timeout], round-robin or try some other
address", but for some others like "even though you don't know my other
address, I'll send a reset anyway" it may disrupt communications between
the two nodes.

We don't know the reasen the initiator wants to establish the connection,
so we probably should play safe and allow it.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Keith Moore <[email-masked]>
Date: Mon, 19 Aug 2002 12:22:44 -0400

> only address they have is A1, that's the only one they can use.

entirely agree.  and it's also not reasonable to assume that every application
component that has knowledge of an old address is periodically checking DNS 
- the app might not even be getting its addresses from DNS, and there might
not be a reliable DNS name that is bound to the node the app wants to talk to.

deprecated addresses should stop working only when the network stops
forwarding those packets to hosts - there's no need for hosts to break
them prematurely.

Keith

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Aug 2002 00:35:25 +0200

In your previous mail you wrote:

=> IMHO this is an implementation bug: deprecated != invalid.

Regards

[email-masked]

PS: bind(2) should be the only common way to use a deprecated address
as a source address of a new "connection".
--------------------------------------------------------------------
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: [email-masked]
Date: Tue, 20 Aug 2002 08:26:10 +0900

>=> IMHO this is an implementation bug: deprecated != invalid.

	latest KAME tree permits bind(deprecated address), while older tree
	(like *BSD) does not.  i'll need to dig commit logs again to understand
	the reasoning for the change (maybe i made the change and forgot).

itojun

---

From: Francis Dupont <[email-masked]>
Date: Tue, 20 Aug 2002 22:10:27 +0200

=> IMHO the deprecated flag should be used only in source address selection.
BTW for invalidated addresses I don't know if connections should be eagerly
dropped (with some kind of notification to all PCBs) or lazily dropped
(i.e., destroyed only when they show some kind of activity). I implemented
both solutions in the past...

Thanks

---

From: [email-masked]
Date: Wed, 21 Aug 2002 07:11:35 +0900

i now understood all the reasoning for accepting TCP SYN to deprecated
	address, and corrected netbsd.  ok.

>Do we currently have a 2462 bis draft?

	here are my proposed changes.

itojun

RFC2462
page 3:

>   in arbitrary communication is unrestricted. Later, an address becomes
>   "deprecated" in anticipation that its current interface binding will
>   become invalid. While in a deprecated state, the use of an address is
>   discouraged, but not strictly forbidden.  New communication (e.g.,
>   the opening of a new TCP connection) should use a preferred address
>   when possible.  A deprecated address should be used only by
>   applications that have been using it and would have difficulty
>   switching to another address without a service disruption.

	the last sentence does not meet people's understand.  append
	", or there is no other choice than to use deprecated address".

	or, since this is introduction section, we shouldn't go into this
	detail here.

---

From: Peter Lei <[email-masked]>
Date: Tue, 20 Aug 2002 17:47:32 -0500

Consider a multi-homed host using a multi-homed transport protocol (such
as SCTP) having multiple valid addresses but also having a deprecated
address-- from what I understand from this thread,
-- we need to allow binding of the deprecated address on the host
-- we need to accept connections to the deprecated address
I've made these changes in the SCTP stack this is distributed along with
KAME.

However, should any new connections (SCTP associations) FROM this host to
a peer list the deprecated address as part of the association?  Given the
existing text and this discussion, it seems that it should not, as other
preferred address(es) are available.  Of course unless as qualified by the
proposed text below-- that it is the only address available (eg. the host
is single homed/has a single valid address which happens to be a deprecated
address).

Comments?

--peter

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 20 Aug 2002 19:08:43 -0400

> is single homed/has a single valid address which happens to be a deprecated

Does SCTP provide some way to describe a preferred order over the
addresses, or is the address set inherently unordered?  Does it
provide a way to delete an address from an active connection?

If there is an ordering, pushing deprecateds to the bottom of the
barrel (and deleting them when they expire) sounds most robust and in
keeping with the rest of the discussion on this thread.

					- Bill

---

From: Peter Lei <[email-masked]>
Date: Tue, 20 Aug 2002 23:14:23 -0500

> keeping with the rest of the discussion on this thread.

I agree, but the address list is unordered (there is no implied preference
order), hence my thought that they should probably not be included in the
list.

And yes, there is a way to delete an address from an active association,
but that is currently an I-D and not part of RFC 2960; hence, for existing
association(s) that have addresses that become deprecated, then expire,
there is a mechanism to delete them from the association(s).

--peter

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 09:28:24 -0400

As one of the authors of the text being discussed, I can confirm that
the intent for the "SHOULD NOT use deprecated address as source" was
for "active opens" only, not on (say) passive opens.

> 	or, since this is introduction section, we shouldn't go into this

The introduction shouldn't/needn't be the definitive text. But if we
can make it more clear, we should.

How about changing:

    (e.g.,the opening of a new TCP connection)

to

    (e.g., an active open of a new TCP connection)

I'm assuming that "active open" vs. "passive open" terminology is
well-understood (I think it's in RFC 1122).

Thomas

---

From: [email-masked]
Date: Wed, 21 Aug 2002 22:57:26 +0900

>well-understood (I think it's in RFC 1122).

	it certainly make things better.  i would like to see description
	in page 3 much shortened to avoid (possible) inconsistencies.

itojun

---

From: Thomas Narten <[email-masked]>
Date: Wed, 21 Aug 2002 15:35:46 -0400

> 	in page 3 much shortened to avoid (possible) inconsistencies.

I'd prefer not shortening this text, as it is explanatory/introductory
for the novice reader. But, it should not be the definitive text.

Looking further in the document, there is specific text that says:

> 5.5.4.  Address Lifetime Expiry
> 
>    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.

I would prefer clarifying the text here. How about changing the first
paragraph as follows:

    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
    to initiate new communications if an alternate (non-deprecated)
    address of sufficient scope can easily be used instead.  Note that
    the feasibility of initiating new communication using a
    non-deprecated address may be an application-specific decision, as
    only the application may have knowledge about whether the (now)
    deprecated address was (or still is) in use by the application.
    IP and higher layers (e.g., TCP, UDP) MUST continue to accept and
    process datagrams destined to a deprecated address as normal since
    a deprecated address is still a valid address for the
    interface. In the case of TCP, this means TCP SYN segments sent to
    a deprecated address are responded to using the deprecated address
    as a source address in the corresponding SYN-ACK (if the
    connection would otherwise be allowed).  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.
 
Would this address your concerns?

Thomas

---

From: [email-masked]
Date: Thu, 22 Aug 2002 08:26:44 +0900

>for the novice reader. But, it should not be the definitive text.

	hmm.  as long as there's no inconsistency, i'm okay.

>Would this address your concerns?

	looks great!

itojun