Subject: Re: need clarification of "deprecated" address

From: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 00:39:21 +0200 (CEST)

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

I suspect that is problematic.

An example renumbering scenario:

Address A is assigned to the host. It is in the DNS with ttl=1 week.

Now address B is also assigned to the host. It starts to get advertised in
the DNS with ttl=1 week. 

Shortly after this address A is removed from the DNS RRset for the host
and A is marked as deprecated.

At this point in time new outgoing connections will use B as the source
and such connections can stay up for more than 1 week.
But incoming connections might use a destination address of A
since the TTL on the RRset which contained A has not yet expired.

Then after 1 week the address A can be made invalid on the host.

---

If you want to refuse SYNs to a deprecated destination then you need
a longer renumbering period: first wait for 1 week until the DNS TTL expires
on the original RRset, then mark A deprecated and wait for enough time
to allow existing connections to terminate.

  Erik

--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Tue, 10 Sep 2002 00:32:34 +0200 (CEST)

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

A TCP SYN from the outside isn't the only interesting case.
Another interesting case is when an application (over TCP or UDP) specifies
the local IP address. Since the stack can't know the reason for the application
explicitly requesting the address it can't reject it. For instance, the
application might request it because that IP address is used for in
higher-level communication and there might be a requirement that the multiple
connections in such a grouping use the same pair of IP addresses.

Thus my take is that the "don't use a deprecated address" only comes into
play when the stack is free to select the local IP address i.e. it
was neither specified in bind(), nor due to receiving a TCP SYN.

This seems to be consistent with the definition in 2462:
   communication - any packet exchange among nodes that requires that
        the address of each node used in the exchange remain the same
        for the duration of the packet exchange.  Examples are a TCP
        connection or a UDP request- response.
but the last sentence should really say 
	all packets in a TCP connection
	require the same IP addresses - but this does not imply that each new 	
	TCP connection is  "new communication" since there might be reasons
	that different TCP connections must use the same pair of IP addresses

I think that was the intent when the RFC was written, but the text
might not be crystal clear on this.

  Erik