Subject: RE: deprecated address handling for inbound TCP

From: Richard Draves <[email-masked]>
Date: Thu, 9 Nov 2000 00:30:28 -0800

> 	jinmei suggested that it may be better to send TCP RST 
> with deprecated
> 	source, as it will help clients to try the next 
> available address
> 	(on getaddrinfo chain, or something).  i tend to agree.

I disagree. The deprecated address shouldn't be in DNS, so the application
that is trying to connect to your deprecated address probably is *not*
stepping through getaddrinfo results. Instead it is probably some kind of
distributed application, and it got your address a day ago (from getpeername
or getaddrinfo) and saved it in various data structures. Now it is trying to
connect to you again.

Rich
--------------------------------------------------------------------
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: Thu, 09 Nov 2000 17:57:30 +0900

>or getaddrinfo) and saved it in various data structures. Now it is trying to

	yah, but there are faulty DNS servers caches result longer than
	it should.  if we accept the connection, we will use deprecated
	address for longer period of time, and we end up cannot terminate
	contract with ISP-OLD.

itojun

---

From: Bill Manning <[email-masked]>
Date: Thu, 9 Nov 2000 07:04:49 -0800 (PST)

% 
% > 	jinmei suggested that it may be better to send TCP RST 
% > with deprecated
% > 	source, as it will help clients to try the next 
% > available address
% > 	(on getaddrinfo chain, or something).  i tend to agree.
% 
% I disagree. The deprecated address shouldn't be in DNS, so the application
% that is trying to connect to your deprecated address probably is *not*
% stepping through getaddrinfo results. Instead it is probably some kind of
% distributed application, and it got your address a day ago (from getpeername
% or getaddrinfo) and saved it in various data structures. Now it is trying to
% connect to you again.

	Why shouldn't an address be in the DNS? And how can you tell 
	that an address, deprecated for your particular instance, has
	not been re-issued and is valid for some other system?

--bill

---

From: Robert Elz <[email-masked]>
Date: Fri, 10 Nov 2000 14:53:25 +0700

Date:        Thu, 9 Nov 2000 07:04:49 -0800 (PST)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Why shouldn't an address be in the DNS? And how can you tell 
  | 	that an address, deprecated for your particular instance, has
  | 	not been re-issued and is valid for some other system?

Bill, you're attempting to be overly pedantic - you know that isn't
what Rich meant, but in this case, you actually goofed as well...

A deprecated address is still assigned, it can't be re-issued yet,
rather it is in the last stages of its validity to its previous
assignee - but not yet revoked.

So, deprecated addresses shouldn't be in the DNS - the time line should
be to receive notification of an address change, start populating new
addresses through the affected systems, update the DNS for those systems
as their new addresses become available so the new ones are used instead
of the old ones, then once that is done, mark the old addresses as deprecated
for however long is possible to allow existing connections to continue
to work, then finally, remove support for them altogether.   Once that
has happened the addresses can be returned, and then re-issued to someone
else (but by that stage, they're no longer deprecated).

kre

---

From: Bill Manning <[email-masked]>
Date: Fri, 10 Nov 2000 08:38:07 -0800 (PST)

%     From:        Bill Manning <[email-masked]>
% 
%   | 	Why shouldn't an address be in the DNS? And how can you tell 
%   | 	that an address, deprecated for your particular instance, has
%   | 	not been re-issued and is valid for some other system?
% 
% Bill, you're attempting to be overly pedantic - you know that isn't
% what Rich meant, but in this case, you actually goofed as well...
% 
% A deprecated address is still assigned, it can't be re-issued yet,
% rather it is in the last stages of its validity to its previous
% assignee - but not yet revoked.
% 
% So, deprecated addresses shouldn't be in the DNS - the time line should
% be to receive notification of an address change, start populating new
% addresses through the affected systems, update the DNS for those systems
% as their new addresses become available so the new ones are used instead
% of the old ones, then once that is done, mark the old addresses as deprecated
% for however long is possible to allow existing connections to continue
% to work, then finally, remove support for them altogether.   Once that
% has happened the addresses can be returned, and then re-issued to someone
% else (but by that stage, they're no longer deprecated).
% 
% kre

	Ok, I goofed. By what process are addresses marked as "deprecated
	 for however long is possible to allow existing connections
	 to continue to work, then finally, remove support for them 
	 altogether"?  I still don't see why there is the strong requirement
	 to tie an addresses validity to its instantiation in the DNS.
	 
--bill

---

From: "Matt Crawford" <[email-masked]>
Date: Fri, 10 Nov 2000 17:00:16 -0600

> 	not been re-issued and is valid for some other system?

If it's merely deprecated, that would be a grievous error.

---

From: Robert Elz <[email-masked]>
Date: Sat, 11 Nov 2000 13:13:43 +0700

Date:        Fri, 10 Nov 2000 08:38:07 -0800 (PST)
    From:        Bill Manning <[email-masked]>
    Message-ID:  <[email-masked]>

  | 	Ok, I goofed. By what process are addresses marked as "deprecated
  | 	 for however long is possible to allow existing connections
  | 	 to continue to work, then finally, remove support for them 
  | 	 altogether"?

Currently this seems to be human intervention - ie: some person decides
how long the transition period needs to be (and I know we have people on
this list you believe the value should normally be "never less than several
months" and others who would like "24 hours and this address is dead").

There's nothing different here than exists in IPv4 address transitions
really - except better automated methods for getting the changes
distributed around the local net, and a better formalism for allowing
hosts to understand what is the current status of any particular address.

The question that led to this little side discussion was related to the
precise semantics of one of those states.

On that question - would there be any support for adding some kind of
deprecated timer (maybe distributed in RAs) - to allow a switch over
point between when incoming connections to a deprecated address are
still accepted, and when they start being reset ?

kre