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