Subject: RE: deprecated address handling for inbound TCP

From: Richard Draves <[email-masked]>
Date: Thu, 9 Nov 2000 21:54:09 -0800

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

The usual reason for putting a node's address in the DNS is so that someone
else can look it up and use the address to contact the node. Deprecated
addresses are not supposed to be used for new communication. So it seems
counterproductive to put deprecated addresses in the DNS.

I don't understand your comment about reissuing an address. A unicast
address should only be assigned to one node (or more strictly, interface).
If an address that was assigned to node X is now assigned to node Y, then of
course a DNS lookup of X's name should not return the address.

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: Fri, 10 Nov 2000 15:44:55 +0900

>counterproductive to put deprecated addresses in the DNS.

	i believe we need some guideline RFC for renumber operation.
	we have been analyzing renumbering scenario (we had a dedicated
	offsite meeting for renumber this week) and our current scenario for
	renumber is like this.  we used router renumber protocol for testing:-)
	jinmei@kame did a heroic job during the test. the diagram was by
	sakane@kame.

itojun

old prefix	...======================================(7)==>(8)
new prefix	      (1)===(2)======================================...>
old AAAA/A6	...---------------------------(5)-->(6)
new AAAA/A6	                  (3)---(4)--------------------------...>

(1) advertise the new prefix
(2) confirm that the new prefix is operating stable enough
(3) advertise new address onto DNS
(4) confirm that the new prefix is advertised stable enough
(5) remove DNS entries for old prefix
(6) confirm that old DNS entries are gone
(7) set preferred lifetime = 0 for old prefix (deprecated)
(8) set valid lifetime = 0 for old prefix (addresses gone)
	we need to confirm that no traffic exists with old prefix, before
	terminating the old prefix.  there's no trivial way.

some of the events could be reordered or overwrapped, but you need to be
careful doing that.  for example, T6 can be after T7, but if you do that,
you will invite connetion to deprecated address so it will be very pretty.

timing invariants:
if we set DNS entry TTL to T, and each event to Tn,
	T4 - T3 >= T
	T6 - T5 >= T

---

From: Robert Elz <[email-masked]>
Date: Fri, 10 Nov 2000 17:24:40 +0700

Date:        Fri, 10 Nov 2000 15:44:55 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	i believe we need some guideline RFC for renumber operation.

Yes, I have been threatening to write a draft on that for some time now,
but haven't managed to find the time to do it...

  | 	we have been analyzing renumbering scenario (we had a dedicated
  | 	offsite meeting for renumber this week) and our current scenario for
  | 	renumber is like this.  we used router renumber protocol for testing:-)
  | 	jinmei@kame did a heroic job during the test. the diagram was by
  | 	sakane@kame.

You have included a bunch of (necessary) intermediate steps I dropped
from my earlier message, but aside from that, your analysis is just about
the same as what I have been thinking...

kre