INTERNET DRAFT                                              C. Huitema<draft-ietf-ipv6-deprecate-site-local-03.txt>                MicrosoftMarch 27, 2004                                            B. CarpenterExpires September 27, 2004                                         IBM              Deprecating Site Local AddressesStatus of this memo      This document is an Internet-Draft and is in full conformance with   all provisions of Section 10 of RFC2026.      This document is an Internet-Draft. 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      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.   Carpenter, Huitema.                                          [Page  1]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 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 [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 site 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 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   Carpenter, Huitema.                                          [Page  2]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   Simple client/server applications that do share IP addresses at the   application layer are made more complex by IPv6 site-local   addressing. These applications need to make intelligent decisions   about the addresses that should and shouldn't be passed across site   boundaries. These decisions, in practice, require that the   applications acquire some knowledge of the network topology. Site   local addresses may be used when client and server are in the same   site, but trying to use them when client and server are in different   sites may result in unexpected errors (i.e. connection reset by   peer) or the establishment of connections with the wrong node.  The   robustness and security implications of sending packets to an   unexpected end-point will differ from application to application.      Multi-party applications that pass IP addresses at the application   layer present a particular challenge.  Even if a node can correctly   determine whether a single remote node belongs or not to the local   site, it will have no way of knowing where those addresses may   eventually be sent.  The best course of action for these   applications might be to use only global addresses.  However, this   would prevent the use of these applications on isolated or   intermittently connected networks that only have site-local   addresses available, and might be incompatible with the use of site-   local addresses for access control in some cases.      In summary, the ambiguity of site local addresses leads to   unexpected application behavior when application payloads carry   these addresses outside the local site.   2.3     Manager pain, leaks      The management of IPv6 site local addresses is in many ways similar   to the management of RFC 1918 [RFC1918] addresses in some IPv4   networks. In theory, the private addresses defined in RFC 1918   should only be used locally, and should never appear in the   Internet. In practice, these addresses "leak". The conjunction of   leaks and ambiguity ends up causing management problems.      Names and literal addresses of "private" hosts leak in mail   messages, web pages, or files. Private addresses end up being used   as source or destination of TCP requests or UDP messages, for   example in DNS or trace-route requests, causing the request to fail,   or the response to arrive at unsuspecting hosts.      The experience with RFC1918 addresses also shows some non trivial   leaks, besides pacing these addresses in IP headers. Private   addresses also end up being used as targets of reverse DNS queries   for RFC1918, uselessly overloading the DNS infrastructure. In   general, many applications that use IP addresses directly end up   passing RFC1918 addresses in application payloads, creating   confusion and failures.      The leakage issue is largely unavoidable. While some applicationsCarpenter, Huitema.                                          [Page  3]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   are intrinsically scoped (e.g., Router Advertisement, Neighbor   Discovery), most applications have no concept of scope, and no way   of expressing scope. As a result, "stuff leaks across the borders".   Since the addresses are ambiguous, the network managers cannot   easily find out "who did it". Leaks are thus hard to fix, resulting   in a lot of frustration.   2.4     Router pain, increased complexity      The ambiguity of site local addresses also creates complications for   the routers. In theory, site local addresses are only used within a   contiguous site, and all routers in that site can treat them as if   they were not ambiguous. In practice, special mechanisms are needed   when sites are disjoint, or when routers have to handle several   sites.      In theory, sites should never be disjoint. In practice, if site   local addressing is used throughout a large network, some elements   of the site will not be directly connected for example, due to   network partitioning. This will create a demand to route the site-   local packets across some intermediate network (such as the backbone   area) that cannot be dedicated for a specific site. In practice,   this leads to an extensive use of tunneling techniques, or the use   of multi-sited routers, or both.      Ambiguous addresses have fairly obvious consequences on multi-sited   routers. In classic router architecture, the exit interface is a   direct function of the destination address, as specified by a single   routing table. However, if a router is connected to multiple sites,   the routing of site local packets depends on the interface on which   the packet arrived. Interfaces have to be associated to sites, and   the routing entries for the site local addresses are site-dependent.   Supporting this requires special provisions in routing protocols and   techniques for routing and forwarding table virtualization that are   normally used for VPNs. This contributes to additional complexity of   router implementation and management.      Network management complexity is also increased by the fact that   though sites could be supported using existing routing constructs--   such as domains and areas--the factors driving creation and setting   the boundaries of sites are different from the factors driving those   of areas and domains.      In multi-homed routers, such as for example site border routers, the   forwarding process should be complemented by a filtering process, to   guarantee that packets sourced with a site local address never leave   the site. This filtering process will in turn interact with the   forwarding of packets, for example if implementation defects cause   the drop of packets sent to a global address, even if that global   address happen to belong to the target site.      In summary, the ambiguity of site local addresses makes them hard toCarpenter, Huitema.                                          [Page  4]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   manage in multi-sited routers, while the requirement to support   disjoint sites and existing routing protocol constructs creates a   demand for such routers.   2.5     Site is an ill-defined concept      The current definition of scopes follows an idealized "concentric   scopes" model. Hosts are supposed to be attached to a link, which   belongs to a site, which belongs to the Internet. Packets could be   sent to the same link, the same site, or outside that site. However,   experts have been arguing about the definition of sites for years   and have reached no sort of consensus. That suggests that there is   in fact no consensus to be reached.      Apart from link-local, scope boundaries are ill-defined. What is a   site? Is the whole of a corporate network a site, or are sites   limited to single geographic locations? Many networks today are   split between an internal area and an outside facing "DMZ",   separated by a firewall. Servers in the DMZ are supposedly   accessible by both the internal hosts and external hosts on the   Internet. Does the DMZ belong to the same site as the internal host?      Depending on whom we ask, the definition of the site scope varies.   It may map security boundaries, reachability boundaries, routing   boundaries, QOS boundaries, administrative boundaries, funding   boundaries, some other kinds of boundaries, or a combination of   these. It is very unclear that a single scope could satisfy all   these requirements.      There are some well known and important scope-breaking phenomena,   such as intermittently connected networks, mobile nodes, mobile   networks, inter-domain VPNs, hosted networks, network merges and   splits, etc. Specifically, this means that scope *cannot* be mapped   into concentric circles such as a naive link/local/global model.   Scopes overlap and extend into one another. The scope relationship   between two hosts may even be different for different protocols.      In summary, the current concept of site is naive, and does not map   operational requirements.   3       Development of a better alternative      The previous section reviewed the arguments against site-local   addresses. Obviously, site locals also have some benefits, without   which they would have been removed from the specification long ago.   The perceived benefits of site local are that they are simple,   stable, and private. However, it appears that these benefits can be   also obtained with an alternative architecture, for example   [Hinden/Haberman], in which addresses are not ambiguous and do not   have a simple explicit scope.      Having non-ambiguous address solves a large part of the developers'Carpenter, Huitema.                                          [Page  5]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   pain, as it removes the need to manage site identifiers. The   application can use the addresses as if they were regular global   addresses, and the stack will be able to use standard techniques to   discover which interface should be used. Some level of pain will   remain, as these addresses will not always be reachable; however,   applications can deal with the un-reachability issues by trying   connections at a different time, or with a different address.   Speculatively, a more sophisticated scope mechanism might be   introduced at a later date.      Having non ambiguous addresses will not eliminate the leaks that   cause management pain. However, since the addresses are not   ambiguous, debugging these leaks will be much simpler.      Having non ambiguous addresses will solve a large part of the router   issues: since addresses are not ambiguous, routers will be able to   use standard routing techniques, and will not need different routing   tables for each interface. Some of the pain will remain at border   routers, which will need to filter packets from some ranges of   source addresses; this is however a fairly common function.      Avoiding the explicit declaration of scope will remove the issues   linked to the ambiguity of the site concept. Non-reachability can be   obtained by using "firewalls" where appropriate. The firewall rules   can explicitly accommodate various network configurations, by   accepting of refusing traffic to and from ranges of the new non-   ambiguous addresses.      One question remains, anycast addressing. Anycast addresses are   ambiguous by construction, since they refer by definition to any   host that has been assigned a given anycast address. Link-local or   global anycast addresses can be "baked in the code". Further study   is required on the need for anycast addresses with scope between   link-local and global.   4       Deprecation      This document formally deprecates the IPv6 site-local unicast prefix   defined in [RFC3513], i.e. 1111111011 binary or FEC0::/10. The   special behavior of this prefix MUST no longer be supported in new   implementations. The prefix MUST NOT be reassigned for other use   except by a future IETF standards action. Future versions of the   addressing architecture [RFC3513] will include this information.      However, router implementations SHOULD be configured to prevent   routing of this prefix by default.      The references to site local addresses should be removed as soon as   practical from the revision of the Default Address Selection for   Internet Protocol version 6 [RFC3484], the revision of the Basic   Socket Interface Extensions for IPv6 [RFC3493], and from the   revision of the Internet Protocol Version 6 (IPv6) AddressingCarpenter, Huitema.                                          [Page  6]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   Architecture [RFC3513]. Incidental references to site local   addresses should be removed from other IETF documents if and when   they are updated.  These documents include [RFC2772, RFC2894,   RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316].      Existing implementations and deployments MAY continue to use this   prefix.   5       Security Considerations      The use of ambiguous site-local addresses has the potential to   adversely affect network security through leaks, ambiguity and   potential misrouting, as documented in section 2. Deprecating the   use of ambiguous addresses helps solving many of these problems.      The site-local unicast prefix allows for some blocking action in   firewall rules and address selection rules, which are commonly   viewed as a security feature since they prevent packets crossing   administrative boundaries. Such blocking rules can be configured for   any prefix, including the expected future replacement for the site-   local prefix. If these blocking rules are actually enforced, the   deprecation of the site-local prefix does not endanger security.   6       IANA Considerations      IANA is requested to mark the FEC0::/10 prefix as "deprecated",   pointing to this document. Reassignment of the prefix for any usage   requires justification via an IETF Standards Action [RFC2434].   7       Copyright      The following copyright notice is copied from RFC 2026 [Bradner,   1996], Section 10.4, and describes the applicable copyright for this   document.      Copyright (C) The Internet Society March 26, 2004. 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.   Carpenter, Huitema.                                          [Page  7]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   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.   8       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   this standard.  Please address the information to the IETF Executive   Director.   9       Acknowledgements      The authors would like to thank Fred Templin, Peter Bieringer,   Chirayu Patel, Pekka Savola, and Alain Baudot for their review of   the initial draft. The text of section 2.2 includes 2 paragraphs   taken from a draft by Margaret Wasserman describing the impact of   site local addressing. Alain Durand pointed out the need to revise   existing RFC that make reference to site local addresses.   10      References      Normative References      [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate   Requirement Levels", RFC 2119, March 1997.   Carpenter, Huitema.                                          [Page  8]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   [RFC2434] Narten, T., and H. Alvestrand, "Guidelines for Writing an   IANA Considerations Section in RFCs", RFC 2434, October 1998.      [RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing   Architecture", RFC 3513, April 2003      Informative references      [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.   J. and E. Lear, "Address Allocation for Private Internets", RFC   1918, February 1996      [Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6   Unicast Addresses", work in progress.      [RFC2772] Rockell, R. and R. Fink. "6Bone Backbone Routing   Guidelines." RFC 2772, February 2000.      [RFC2894] M. Crawford. "Router Renumbering for IPv6." RFC 2894,   August 2000.      [RFC3082] Kempf, J. and J. Goldschmidt. "Notification and   Subscription for SLP." RFC 3082, March 2001.      [RFC3111] E. Guttman. "Service Location Protocol Modifications for   IPv6." RFC 3111, May 2001.      [RFC3142] Hagino, J. and K. Yamamoto. "An IPv6-to-IPv4 Transport   Relay Translator." RFC 3142, June 2001.      [RFC3177] IAB, IESG. "IAB/IESG Recommendations on IPv6 Address." RFC   3177, September 2001.      [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J. and J.   Wiljakka. "Internet Protocol Version 6 (IPv6) for Some Second and   Third Generation Cellular Hosts." RFC 3316, April 2003.      [RFC3484] R. Draves. "Default Address Selection for Internet   Protocol version 6 (IPv6)." RFC 3484, February 2003.      [RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J. and W.   Stevens. "Basic Socket Interface Extensions for IPv6." RFC 3493,   February 2003.      [SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and   B. Zill, "IPv6 Scoped Address Architecture", work in progress.      11      Authors' Addresses      Christian Huitema   Microsoft CorporationCarpenter, Huitema.                                          [Page  9]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   One Microsoft Way   Redmond, WA 98052-6399   USA   Email: huitema@microsoft.com      Brian Carpenter   IBM Corporation   Sauemerstrasse 4   8803 Rueschlikon   Switzerland   Email: brc@zurich.ibm.com   12      History of changes   12.1    Changes from draft-00 to draft-01      Changed the text in the introduction to say that the decision was   "confirmed" in July 2003.      Add some explanatory text in section 2.2, address leak, and section   2.3, routing pain.      In section 4, and 5 change the erroneous "link local" to "site   local".      Add a reference to RFC 2119 describing the use of keywords.      In section 5, qualify that the replacement of site local is only as   secure if blocking rules are actually implemented at site   boundaries.   12.2    Changes from draft-01 to draft-02      Inserted a new section "2.2 Developer pain, local addresses" to   capture the pain caused by ambiguous addresses carried in   application payloads.      Added a paragraph in section 4 recommending the removal of   references to site local addresses from several RFC. Added these RFC   to the Reference section.      Removed the reference to the draft "Addressing Requirements for   Local Communications within Sites", in order to avoid references to   drafts that may slow down document publication.   12.3    Changes from draft-02 to draft-03      The changes from draft 02 to draft 03 take into account the IESG   comments.      A reference to the scoped addresses architecture draft has been   added to section 2.1, in order to explain the usage of the % sign toCarpenter, Huitema.                                          [Page 10]INTERNET DRAFT     Deprecating Site Local Addresses     March 27, 2004   document site numbers in site local addresses.      Section 2.4 has been reworded following suggestions by Alex Zinin,   essentially to change the tone from "this creates a problem" to   "this would increase router implementation and management   complexity".      A new paragraph has been added to the security considerations,   reiterating the issues due to ambiguity which were brought up in the   preceding sections.      The IANA considerations have been rewritten for greater precision.      A duplicate reference to RFC 3513 has been removed.Carpenter, Huitema.                                          [Page 11]