Subject: deprecated address handling for inbound TCP

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 09 Nov 2000 11:29:52 +0900

I'm investgating how deprecated address should be treated, and have one
	question (I need a tiny clarification).

	RFC2462 talks about how to handle deprecated address, in multiple
	places.  5.5.4 looks to be the most definitive one.
	 It basically says, in the first couple of lines:
	1. use of deprecated addr with existing communication is okay -
	   "SHOULD continue to be used"
	2. use of deprecated address for new communication:
	   (2a) "SHOULD NOT be used if no alternate address with sufficient
		scope is available"
	   (2b) nothing mentioned otherwise - implies that it is permitted to
	        use deprecated address.
	        we can optionally disallow the use of deprecated address, in
		(2b) case.

	if we think about some scenarios with the above condition, it will be
	like below.  for me "new inbound TCP SYN" case (3rd bullet below)
	is not very clear, and I may need a clarification.  if our intent is
	to make the deprecated address (or the /48 prefix associated with it)
	to go away, it may be better to always reject the new TCP connection
	attempt.  however, RFC2462 5.5.4 does not seem to do that.
	so I'm a little bit confused.

	- I have an existing TCP connection with local address bound to
	  a deprecated address.  can I send a TCP packet to the peer?
		yes, based on condition 1.
	- User application issued TCP connection request.  The kernel need to
	  establish a new connection.  Can I use a deprecated address as the
	  local address?
		if we have alternate address, no, based on (2a).
		if we have no alternate address, it falls into (2b).
		- if (2b) behavior is allowed, yes (default).
		- if (2b) behavior is disallowed, no.
	- I got a new TCP connection request from outside, with my deprecated
	  address as the destination.  am I allowed to accept this connetion?
		since we have no control over the address on our side, this
		falls into (2b).
		- if (2b) behavior is allowed, yes.
		- if (2b) behavior is disallowed, no.  note that we cannot
		  issue TCP RST in this case (if we issue TCP RST we will
		  need to use deprecated address as the source)
	- UDP issues needs more thinking - how we should handle connected/
	  non-connected UDP sockets?
	- ICMPv6 echo/whatever?

	the behavior would affect site renumbering scnearios a little bit.

itojun

--- RFC2462
5.5.4.  Address Lifetime Expiry

   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.

   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.
--------------------------------------------------------------------
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: Jun-ichiro itojun Hagino <[email-masked]>
Date: Thu, 09 Nov 2000 17:13:09 +0900

>		  need to use deprecated address as the source)

	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.

itojun

---

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

So do I, if you can somehow be confident that your old RRSET of
addresses has propagated.  (Or if you have preferred addresses that
were already in the older RRSET.)

That's quite a bit for the hosts to know, though.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Nov 2000 09:32:13 -0800 (PST)

> 	(on getaddrinfo chain, or something).  i tend to agree.

I think this is bad since there might be old AAAA/A6 record sets cached
(due to their DNS ttl not having expired yet) that only include the 
old, now deprecated, address.

Imagine a DNS ttl of 1 hour.

T = 0: Configure new prefixes using router renumbering. Initially as
deprecated. T = 5 minutes. Test new address (and old) can be reached i.e.
routing works. T = 6 minutes. Update DNS to have only new addresses.
T = 7 minutes. Use router renumbering to mark new address as preferred and old
	addresses as deprecated.
T >> 1 hour 6 minutes. (Actual number depends on how long lived TCP
connections 
	and other sessions you'd like to handle. But at least the DNS ttl).
	Time to remove the old address using router renumbering i.e. make 
	routing of old addresses no longer work.

I don't think you want an outtage of 59 minutes in this case.

   Erik

---

From: [email-masked]
Date: Tue, 14 Nov 2000 05:27:49 +0900

>I don't think you want an outtage of 59 minutes in this case.

	well, the above scenario looks too aggressive to me.
	the invariants we would like to keep are:
	- advertise address by DNS, only after addresses are ready
	- mark addresses deprecated, only after we remove them DNS and
	  we wait till DNS TTL has passed
	so, the scenario will be as follows: time unit = minutes.

T=0	add a new prefix.
T=5	test new prefix and confirm that it is working okay.
T=10	advertise address on new prefix (and old prefix) via DNS
T=70	confirm that we now have clicks to www.erik.net
T=75	remove addresses on old prefix from DNS
T=135	mark old address deprecated (pltime = 0).
T=140	confirm that there's no new connectivity to old address coming,
	terminate contract with old ISP.
--------------------------------------------------------------------
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: Thu, 16 Nov 2000 07:04:36 -0800 (PST)

> 	- advertise address by DNS, only after addresses are ready

Ready to accept traffic I assume. Or do you mean "ready = preferred"?

> 	  we wait till DNS TTL has passed

That means that the old adresses will be used as source addresses
when they don't exist in the DNS. So any application on a peer which does a
reverse + forward DNS lookup of the source address, will not find anything
in the DNS. While we'd like to see such DNS host name verification replaced
by stronger measures (such as IPsec) I think it would be unfortunate to
completely throw out the ability the rely on DNS for reverse + forward lookups.

   Erik

---

From: [email-masked]
Date: Fri, 17 Nov 2000 06:32:32 +0900

>Ready to accept traffic I assume. Or do you mean "ready = preferred"?

	ready to accept traffic, yes.  i'd enable forward DNS records,
	only after I confirmed the reachability of new address is stable enough
	(run some test from outside, by ping6 or traceroute6).

>completely throw out the ability the rely on DNS for reverse + forward lookups.

	if you want to you may put reverse DNS entries earlier than forward DNS
	entries.  about the use of old address without forward DNS entries,
	i have no answer yet.  let me think.

itojun