Deprecating Site Local Addresses
RFC 3879
| Document | Type | RFC - Proposed Standard (September 2004; No errata) | |
|---|---|---|---|
| Authors | Christian Huitema , Brian Carpenter | ||
| Last updated | 2013-03-02 | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3879 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Margaret Cullen | ||
| Send notices to | (None) | ||
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
Show full document text