Subject: deprecated source addresses

From: Richard Draves <[email-masked]>
Date: Sun, 17 Oct 1999 22:46:56 -0700

One of the issues that we discussed in Tokyo was when a node that is
initiating communication might use a deprecated address as a source address.

RFC 2462 (stateless addr conf) says in section 5.5.4:

   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.

At the meeting, Steve Deering and some others were arguing strenously for a
harder stance - not allowing the use of a deprecated source address in new
communication at all. The argument being that if an administrator deprecates
a prefix, it's because they don't want it to be used anymore, period. If
that breaks something, better to know about it sooner than later.

This argument had almost carried the day when Peter Tattam noted that this
would introduce a new denial-of-service possibility - a bad guy could
deprecate everyone's addresses and prevent new communication. Or more
accurately, prevent new off-link communication, because link-local source
addresses would still be available. This seemed to reopen the issue in
people's minds.

[Btw, I tried this denial-of-service attack in the meeting hall as an
experiment, and nobody noticed. All the implementations there seemed to give
scope considerations more importance in their source address selection, so
they continued to use their deprecated global addresses for global
destinations.]

I think the order implied by the quoted paragraph above is to prefer
1. non-deprecated addresses of sufficient scope
2. deprecated addreses of sufficient scope
3. non-deprecated addresses of insufficient scope
4. deprecated addresses of insufficient scope

This is the almost the order currently specified in
draft-draves-ipngwg-simple-srcaddr-01. The only difference is I believe - if
the destination is global scope, and the two candidate source addresses are
A - deprecated site-local and B - non-deprecated link-local, my draft says
to choose A instead of B.

What do people on the list think about this? In the forthcoming revision of
my draft, should I change this aspect of source address selection?

Thanks,
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: Erik Nordmark <[email-masked]>
Date: Sun, 17 Oct 1999 22:58:44 -0700 (PDT)

> 4. deprecated addresses of insufficient scope

"sufficent" is really an assumption. I think it would be more accurate to
use the terms "same or larger scope than the scope of the destination address".
> to choose A instead of B.

Sounds fine.

> my draft, should I change this aspect of source address selection?

One could also envision that rule 1 and 2 find the an address of the 
same or larger scope but preferring a scope "closer" to the scope
of the destination (i.e. searching through increasing scope values).
Similarly, rule 3 and 4 could search through decreasing scope values.

   Erik