Internet DRAFT - draft-francis-ipngwg-unique-site-local
draft-francis-ipngwg-unique-site-local
Internet Draft P. Francis
<draft-francis-ipngwg-unique-site-local-00.txt> TAHOE Networks
Category: Standards Track Feb. 2001
IPv6 Near-Unique Site-Local Addresses
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
For many or most sites, site-local addresses are used for packets
between nodes within the site. The fact that site-local addresses
are not globally unique makes their usage and administration more
difficult than they would be if there were globally unique (or
nearly globally unique). For instance, before two sites can be
merged, one of them has to be renumbered. The meaning of site-local
addresses becomes ambiguous when they are taken out of the immediate
context of the IPv6 layer, for instance when they are conveyed in
email or stored in text files.
All other things being equal, it would be preferable if the prefix
of addresses with site-local scope were as globally unique as
possible. This draft expands the format of the site-local address
to allow them to be near-unique. It does not, however, change the
definition or usage of the site-local address. This draft describes
the format and assignment method of near-unique site-local prefixes.
It also outlines some usage scenarios.
1 Introduction
One of the purposes for using site-local addresses within a site is
to allow internal communications to continue while global addresses
Francis Standards Track - Expires Aug. 2001 Page 1
IPv6 Near-Unique Site Local Addresses Feb 2001
are being renumbered. Site-local addresses as defined today are not
globally unique --- they all share a common prefix (FEC0::/48) [1].
In other words, they are re-used addresses in much the same way that
IPv4 net 10 addresses are re-used (with two key differences: First,
because of the uniqueness of IPv6 interface ID field, individual
addresses are less likely to be exactly identical. Second, IPv6
nodes in non-isolated sites will have global addresses in addition
to the site-locals.)
These differences not-with-standing, the use of site-locals creates
ambiguities that can result in errors and increased administration.
For instance, for two sites to merge, one of them almost certainly
must be renumbered before site-local addresses may be exchanged by
routing protocols. The host identified by a site-local address may
not be known if that address is read out of context --- that is, in
a text file or email message.
All things being equal, it is better if site-local addresses are as
globally unique as possible. This suggestion has been raised and
discussed repeatedly on the IPv6 mailing list (in May 1997, Dec
1998, Nov 1999, Feb 2000), though never with conclusive results. In
the opinion of the author, one of the reasons no conclusion has been
reached is that multiple issues were often mixed together in these
discussions --- whether or not to get rid of (non-unique) site-
locals, whether or not to use two-faced DNS, and what the new role
of site-locals should be. Another reason is that there was never a
complete and concise proposal on which to base the discussion, so it
was never fully clear what was being proposed.
The purpose of this internet-draft is to provide that complete and
concise proposal in order to allow progress to be made on this
issue.
In a nutshell, the proposal is this:
1. Make site-local addresses near-unique by putting allowing the
current 38-bit all-zeros field of the site-local address to contain
any value. This field is called the site-local identifier. The
all-zeros value is used as is by sites that don't require near-
uniqueness.
2. For all remaining (non-zero) values, the site-local identifier
is selected randomly by each site that wants one (if necessary by
literally tossing 38 coins). Thus the site-local is only
statistically unique. In particular, there is no registry for site-
local identifiers.
3. Make no changes to existing host or router implementations.
(Assuming that existing host and router implementations correctly
recognize the site-local prefix as a /10 as defined in section 2.4
of RFC 2373 [1], and not incorrectly as a /48 (as might be assumed
from section 2.5.8 of RFC 2373).
Francis Standards Track - Expires Aug 2001 Page 2
IPv6 Near-Unique Site Local Addresses Feb 2001
1.1 Conventions used in this document
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 RFC 2119 [2].
2 Terminology
This document defines the following new terms:
Near-unique site-local:
A site-local IPv6 address with a non-zero value in the 38-bit
field following the FEC0::/10 prefix.
Default site-local
A site-local IPv6 address with a zero value in the 38-bit field
following the FEC0::/10 prefix.
Site-Local
Either a near-unique site-local or a default site-local.
Site-Local Identifier
The 38-bit field in the site-local address.
Duplicate Site-Local Identifier
A site-local identifier used by more than one site.
Registry
For the purposes of this document, a registry is defined as an
entity that assigns identifiers in such a way as to guarantee
uniqueness. They do this by remembering which numbers have been
assigned, and checking new assignments against previous
assignments to insure no duplicates. This checking may be either
explicit (an actual list is kept), or implicit (by keeping a
counter and assigning consecutive values). By contrast, an
entity that provides a site with true random identifiers as a
service is not considered a registry as defined here.
3 Goals and Non-goals
The goals of this proposal are quite modest. Indeed there is only
one goal: to allow a site to use site-local addresses that are
globally unique with high probability.
More interesting are the non-goals (and the reasons why they are
non-goals).
Francis Standards Track - Expires Aug 2001 Page 3
IPv6 Near-Unique Site Local Addresses Feb 2001
It is not a goal to completely obviate the need for renumbering of
site-local addresses. While it will be possible for two merged
sites to operate indefinitely without renumbering their near-unique
site-locals, some sites may not wish to run DNS or routing in such a
way that allows this. Such sites may prefer to renumber.
It is not a goal to allow a host to always know if a destination
host can or cannot be reached intra-site by comparing their near-
unique site-local addresses. Two near-unique site-locals with the
same /48 prefix may be unreachable, and two near-unique site-locals
with different prefixes may be reachable. Therefore we still rely
on DNS returning addresses that the requesting host can use to reach
the destination.
Put more succinctly, a site-local identifier does not identify a
site.
It is not a goal for all site-local identifiers to be absolutely
100% guaranteed to be globally unique. (Which is fortunate because
it is impossible to make this guarantee even with a registry.)
Rather, non-zero site-local identifiers are globally unique with
high probability (as long as they have been chosen randomly).
It is not a goal that an administration actually "owns", in some
legal sense, the site-local identifier(s) it uses. Because near-
unique site-locals are only used internally, the existence of a
duplicate in another site causes no problem unless the two sites
choose to merge. Once they choose to merge, the damage is done ---
one or the other must renumber. Since the decision to merge implies
that the two administrations are cooperating, there is little value
in allowing one or the other to claim ownership on the site-local
identifier.
4 Details of the Proposal
RFC 2373 defines all addresses with the prefix FEC0::/10 as being a
site-local [1]. It further defines the 38 bits immediately
following this prefix as containing all zeros:
| 10 |
| bits | 38 bits | 16 bits | 64 bits |
+----------+-------------+-----------+----------------------------+
|1111111011| 0 | subnet ID | interface ID |
+----------+-------------+-----------+----------------------------+
This proposal expands the format but not the definition of the site-
local. Specifically, the 38-bit site-local identifier field may
take on any value, not only value 0.
Francis Standards Track - Expires Aug 2001 Page 4
IPv6 Near-Unique Site Local Addresses Feb 2001
It is important to note that only the format and not the definition
of the field is changing. The site-local address is treated the
same by IPv6 nodes and by DNS whether it has zero or non-zero values
in the site-local identifier field.
A site-local with a 0 value site-local identifier is the default
site-local. Because many sites will use the default value, this
will continue to be a heavily re-used prefix.
All other values are valid values. They MUST be assigned randomly.
There SHOULD NOT be any large-scale attempt to insure their
uniqueness other than random assignment. In particular, there MUST
NOT be any notion of ownership attached to the values. Any site has
as much right to use any given value as any other.
A site may of course check with other sites it expects to
interconnect with in the future before selecting a given value.
4.1 Choosing a random value
It is in the best interests of every site to choose a number that is
as random as possible. Any non-randomness in the number only
increases the probability that it is a duplicate.
Given that the random number generation is a one-time event per
site, if a site generates its own number it is strongly advised that
the number SHOULD be generated by tossing a coin 38 times. This
process takes approximately 5 minutes.
If a service provider wishes to provide random site-local
identifiers to its customers, tossing a coin may be inconvenient.
In this case, the good techniques described in RFC 1750 [3] are
appropriate. In any event, the service provider MUST NOT use any
method other than good random number generation, and the service
provider SHOULD NOT attempt to cross-check generated numbers against
previous assignments as such attempts are prone to failure and
reduce the psychological importance of generating good random
numbers.
4.2 Non-compliant host and router implementations
Any existing IPv6 nodes that do not recognize site-local addresses
with non-zero site-local identifier fields as being site-local are
in violation of RFC 2373 [1]. These implementations must be fixed
so that they interpret FEC0::/10, and not just FEC0::/48, as being
site-local.
4.3 IPv6 routers that are not in a site
All routers that are not in a site (i.e. backbone or core routers)
SHOULD treat each interface as being a site boundary. In other
Francis Standards Track - Expires Aug 2001 Page 5
IPv6 Near-Unique Site Local Addresses Feb 2001
words, they SHOULD NOT allow FEC0::/10 addresses to cross those
interfaces.
5 Scenarios and Discussion
5.1 Why random address assignment?
It is impossible to 100% guarantee global uniqueness across all
site-local identifiers, so it is pointless to go through the
tremendous trouble and expense of trying.
The reason is simple. If a site splits, and neither half renumbers,
then there will be duplicate site-local identifiers. Over time,
both halves will assign duplicate SLAs, so it will be impossible to
later merge the halves without renumbering. Since the number of
sites that will have duplicates because of splitting is greater than
the number of sites that will have duplicates because of random
probabilities, attempting to assign unique numbers through a
registry doesn't help.
Another reason for not using a registry is that it is probable that
more duplicates would result using a registry than using random
numbers. This is because there is no innate mechanism of detecting
errors in the assignment process. Since site-local addresses are
kept local, there is no global infrastructure equivalent to the DNS
or IP routing to detect duplicates. Therefore errors in the
assignment process will go undetected.
It is likely that errors in a registry process will produce more
duplicates than random number generation. If a registry assigns
numbers consecutively (the easiest thing to do), then a mistyping of
an identifier during its handling is very likely to result in its
duplicating a "legitimate" identifier. This is because with
consecutive numbers the values are all packed together and almost
any change in a digit will result in another assigned (or soon-to-
be-assigned) value. (In other words, mistyping 12345 as 12344 is
much more likely than mistyping 12345 as 1000002345.) Because
random numbers are spread out, mistyping of a random value is much
less likely to result in a duplicate.
If on the other hand the registry assigns values randomly with
explicit checks for duplicates, a software error could easily
produce duplicates that go undetected for a long time.
A final advantage for not having a registry is that it makes it
harder in the future to justify making near-unique site-locals
globally routable. The facts that any given site-local identifier
may be a duplicate, that there is no way to know if it is a
duplicate, and that no-one can claim legal ownership to it, adds
weight to arguments against trying to advertise it globally.
Francis Standards Track - Expires Aug 2001 Page 6
IPv6 Near-Unique Site Local Addresses Feb 2001
It is for the above reasons that we don't assign a "spare bit" in
the site-local identifier. That is, define the first bit as 0 for
random assignments so that later a registry can be created with
jurisdiction over all values where the first bit is 1.
One downside of random number assignment is that users are going to
think it is weird. Some may choose not to do it, and end up with
less-than-random numbers. Such people are more likely to have
duplicates with each other. People that do properly select random
numbers are no more likely (in fact are less likely) to have
duplicates with the less-than-random numbers.
5.2 What is the probability of duplicates?
The probability of a duplicate assignment somewhere is N^2/2^38,
where N is the number of assigned site-local identifiers. This
means that there will probably be a duplicate somewhere after 500000
assignments, and 3 or 4 duplicates after 1000000 assignments.
What is important though is not the probability of a duplicate
somewhere, but the probability of any given site trying to connect
or merge with a site that has a duplicate. (In other words, what is
interesting is not whether someone will win the lottery, but whether
you will win the lottery.)
If over the lifetime of a site it merges (even partially and
temporarily) with as many as 10000 other sites, the probability that
it will encounter a duplicate is 0.03%. The probability is
correspondingly less if a site merges less.
This probability is so low that it is negligible next to the
probability that a site will split and then later re-merge with the
split half.
5.3 Why don't near-unique site-local prefix comparisons identify
sites?
If prefix comparisons could determine whether two addresses were in
the same site, DNS operation could be made easier. Near-unique site-
locals could be stored in DNS and put in DNS answers without regard
for whether the requester was inside or outside the site.
Unfortunately this is not the case. Duplicate site-local
identifiers in different sites are quite possible (because of
splitting). So are different site-local identifiers in the same
site. If two sites merge but don't renumber their near-unique site-
locals, then a comparison of the two prefixes would indicate that
they are in different sites when they are not.
What this means is that DNS must discriminate its answers based on
where its requests come from just as it must today with default
Francis Standards Track - Expires Aug 2001 Page 7
IPv6 Near-Unique Site Local Addresses Feb 2001
site-locals. Requests from inside a site may be answered with near-
unique site-local addresses. Requests from outside cannot.
[Author's note: Could possibly benefit here from a description
of how this is done, though on the other hand it could be
considered outside the scope of this document.]
It should be noted that implementations following the address
selection rules in draft-ietf-ipngwg-default-addr-select-02.txt [4]
will select site-local addresses before global addresses, regardless
of whether their prefixes match. Therefore DNS can safely return
both global and site-local addresses to an internal requester.
5.4 How to merge sites without renumbering near-unique site-locals
When two sites merge, it is not necessary to renumber the near-
unique site-locals. All that is necessary is that DNS be
reconfigured so that it returns the near-unique site-local addresses
of hosts in both halves for internal DNS requests.
There may be other reasons, however, that renumbering is necessary
when two sites merge. Specifically, if a site wishes to use RFC
2894 site-wide router renumbering [5], then all SLAs in the site
must be unique. Even if two sites have different site-local
identifiers, one site or the other must renumber the duplicate SLAs
(without the benefit of RFC 2894) before adopting a common global
address prefix.
6 Security Considerations
There are no new security considerations that result from this
proposal.
7 Acknowledgements
There are no new ideas in this draft. The basics of this proposal
have been floating around the IPv6 mailing list literally for years.
Because I would inevitably get it wrong, I won't even try to give
individual credit (or blame, as the case may be) for the ideas. You
know who you are. The archives speak for themselves.
I would like to acknowledge Robert Elz for reviewing an early
version of this draft.
8 Copyright
The following copyright notice is copied from RFC 2026 [Bradner,
1996], Section 10.4, and describes the applicable copyright for this
Francis Standards Track - Expires Aug 2001 Page 8
IPv6 Near-Unique Site Local Addresses Feb 2001
document.
Copyright (C) The Internet Society XXX 0, 0000. All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9 Intellectual Property
The following notice is copied from RFC 2026 [Bradner, 1996],
Section 10.4, and describes the position of the IETF concerning
intellectual property claims made against this document.
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use other technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementers or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
Francis Standards Track - Expires Aug 2001 Page 9
IPv6 Near-Unique Site Local Addresses Feb 2001
this standard. Please address the information to the IETF Executive
Director.
10 References
1 S. Deering, R. Hinden, Editors, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
2 S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
3 D. Eastlake 3rd, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", RFC 1750, December 1994.
4 R. Draves, "Default Address Selection for IPv6", draft-ietf-
ipngwg-default-addr-select-02.txt, November 2000.
5 M. Crawford, "Router Renumbering for IPv6", RFC 2894, August 2000.
Author Addresses:
Paul Francis
TAHOE Networks
paul@francis.com
Francis Standards Track - Expires Aug 2001 Page 10
