Deprecating Site Local Addresses
RFC 3879

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                         C. Huitema
Request for Comments: 3879                                     Microsoft
Category: Standards Track                                   B. Carpenter
                                                                     IBM
                                                          September 2004

                    Deprecating Site Local Addresses

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document describes the issues surrounding the use of IPv6 site-
   local unicast addresses in their original form, and formally
   deprecates them.  This deprecation does not prevent their continued
   use until a replacement has been standardized and implemented.

1.  Introduction

   For some time, the IPv6 working group has been debating a set of
   issues surrounding the use of "site local" addresses.  In its meeting
   in March 2003, the group reached a measure of agreement that these
   issues were serious enough to warrant a replacement of site local
   addresses in their original form.  Although the consensus was far
   from unanimous, the working group confirmed in its meeting in July
   2003 the need to document these issues and the consequent decision to
   deprecate IPv6 site-local unicast addresses.

   Site-local addresses are defined in the IPv6 addressing architecture
   [RFC3513], especially in section 2.5.6.

   The remainder of this document describes the adverse effects of
   site-local addresses according to the above definition, and formally
   deprecates them.

Huitema & Carpenter         Standards Track                     [Page 1]
RFC 3879            Deprecating Site Local Addresses      September 2004

   Companion documents will describe the goals of a replacement solution
   and specify a replacement solution.  However, the formal deprecation
   allows existing usage of site-local addresses to continue until the
   replacement is standardized and implemented.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119
   [RFC2119].

2.  Adverse Effects of Site Local Addresses

   Discussions in the IPv6 working group outlined several defects of the
   current site local addressing scope.  These defects fall in two broad
   categories: ambiguity of addresses, and fuzzy definition of sites.

   As currently defined, site local addresses are ambiguous: an address
   such as FEC0::1 can be present in multiple sites, and the address
   itself does not contain any indication of the site to which it
   belongs.  This creates pain for developers of applications, for the
   designers of routers and for the network managers.  This pain is
   compounded by the fuzzy nature of the site concept.  We will develop
   the specific nature of this pain in the following section.

2.1.  Developer Pain, Scope Identifiers

   Early feedback from developers indicates that site local addresses
   are hard to use correctly in an application.  This is particularly
   true for multi-homed hosts, which can be simultaneously connected to
   multiple sites, and for mobile hosts, which can be successively
   connected to multiple sites.

   Applications would learn or remember that the address of some
   correspondent was "FEC0::1234:5678:9ABC", they would try to feed the
   address in a socket address structure and issue a connect, and the
   call will fail because they did not fill up the "site identifier"
   variable, as in "FEC0::1234:5678:9ABC%1".  (The use of the %
   character as a delimiter for zone identifiers is specified in
   [SCOPING].)  The problem is compounded by the fact that the site
   identifier varies with the host instantiation, e.g., sometimes %1 and
   sometimes %2, and thus that the host identifier cannot be remembered
   in memory, or learned from a name server.

   In short, the developer pain is caused by the ambiguity of site local
   addresses.  Since site-local addresses are ambiguous, application
   developers have to manage the "site identifiers" that qualify the

Huitema & Carpenter         Standards Track                     [Page 2]
RFC 3879            Deprecating Site Local Addresses      September 2004

   addresses of the hosts.  This management of identifiers has proven
   hard to understand by developers, and also hard to execute by those
   developers who understand the concept.

2.2.  Developer Pain, Local Addresses

   Simple client/server applications that do share IP addresses at the