[Search] [pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
INTERNET-DRAFT                                          R. Hinden, Nokia
December 5, 2002

               IPv6 Globally 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."

   To view the list Internet-Draft Shadow Directories, see

   This internet draft expires on May 5, 2003.


   This internet draft describes a proposal for IPv6 Globally Unique
   Site-Local Addresses.

1.0 Introduction

   This internet draft describes a proposal for IPv6 Globally Unique
   Site-Local Addresses.

   The IP Version 6 Addressing Architecture [ADDARCH] defines site-local
   addresses as:

draft-hinden-ipv6-global-site-local-00.txt                      [Page 1]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002

      |   10     |
      |  bits    |         54 bits         |         64 bits            |
      |1111111011|        subnet ID        |       interface ID         |

   This document proposes an approach to allocating IPv6 Site-Local
   address so they are globally unique and routable only inside of a

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC 2119].

2.0 Acknowledgments

   The underlying idea of using global tokens based on EUI-48 addresses
   as a way of numbering subnets has been proposed a number of times by
   a variety of people.  The author of this draft does not claim
   exclusive credit.  Credit goes to Christian Huitema, Aidan Williams,
   Andrew White, Michel Py, Charlie Perkins, xxxx, yyyy, and many
   others.  The author would also like to thank xxxx, yyyy, zzzz, <your
   name here>, and zzzz for their comments and suggestions on this

3.0 Proposal

   The key to creating globally unique site-local addresses is to assign
   the subnet ID in a manner that each one is unique on a global scale.
   This document proposes to use global tokens based EUI-48 addresses
   for globally unique site-local subnet assignment.  The format is:

      |   10     |  8    |
      |  bits    | bits  |    46 bits      |         64 bits            |
      |1111111011| area  |   global token  |       interface ID         |


      1111111011        is the binary /10 prefix for IPv6 site-local
                        addresses as defined in [ADDARCH]

      area              Manually configured area.  Default value is

draft-hinden-ipv6-global-site-local-00.txt                      [Page 2]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002

      global token      Based on EUI-48 as defined in section 3.1

      interface ID      As defined in [ADDARCH].

   Each /64 identifies a single subnet.

3.1 Global Token

   EUI-48 addresses commonly used in Local Area Networks devices have
   the property of being reasonably globally unique.  They are a good
   choice for creating a global token for IPv6 site-local subnet

   EUI-48 addresses as defined in [EUI48] have the following format:

      |0              1|1              3|3              4|
      |0              5|6              1|2              7|

   written in Internet standard bit-order , where "u" is the
   universal/local bit, "g" is the individual/group bit, "c" are the
   bits of the company_id, and "m" are the bits of the manufacturer-
   selected extension identifier.  To create the global token used the
   this proposal, the "u" and "g" bits are not needed.  The resulting
   global token is:

      |0              1|1              3|3            4|
      |0              5|6              1|2            5|

   The global token is globally unique and when used to identify IPv6
   site-local subnets results in globally unique site-local subnet

3.2 Assignment

   The globally unique site-local prefixes defined in this document are
   intended to be manually assigned to router interfaces in a site.  The
   global token used in each prefix would be created from an EUI-48
   address found in an interface on the subnet.

   The area is designed to allow sites to manually assign prefix to

draft-hinden-ipv6-global-site-local-00.txt                      [Page 3]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002

   separate areas to facilitate route aggregation at the /18 level in
   the site.

   The prefixes defined in document are also designed to allow automatic
   assignment to subnets in small sites.  It would be expected this
   would be in the default area (e.g., area = 0).  The details of
   automatic subnet assignment are beyond the scope of this document.

3.3 Routing

   Inside of each area the globally unique site-local prefixes are
   designed to be routed in a flat manner (i.e., without any route
   aggregation).  Each /64 prefix in the area would occupy an entry in a
   routers forwarding table.

   The area field allows the assignment of site-local prefixes to area
   to allow large sites to aggregate their intra-site routing around the

   The use of flat routing of /64 prefixes is also designed to reduce
   the possibility of these prefixes being advertised in the global
   internet as each site would have many /64 prefixes and they would all
   have to be advertised independently.

3.4 Renumbering and Site Merging

   The use of site-local addresses in a site results in making
   communication using site-local address independent of renumbering a
   site's provider based global addresses.   This is true for the Site-
   Local addresses defined in [ADDARCH] and the global site-local
   addresses defined in this document.

   The renumbering that occurs when two organizations merge their sites
   is different from the previous case.  If the sites are only using the
   default zone of zero, then the sites can be combined without any need
   to renumber any of the global site-local addresses.

   If the sites had been using manually configured areas to aggregate
   their inter-area site routes, the areas that are duplicate in each
   site will have to be renumbered.  One way around this is to change
   the route advertisements from /18 to /64 in the areas that are
   duplicated.  That will result in there being a unique prefix for each
   subnet.  This will increase the amount of routing overhead, but will
   allow operations to continue with out any disruption to ongoing
   communication.  The areas could be renumbered at a later time when it
   is convenient to do so.

draft-hinden-ipv6-global-site-local-00.txt                      [Page 4]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002

3.5 Site Border Router Filtering

   It is important to keep any packets with site-local source or
   destination addresses from leaking outside of the site and to keep
   any site prefixes from being advertised outside of their site.

   Site border routers MUST install a black hole route for the Site-
   Local prefix FEC0::/10.  This will insure that packets with Site-
   Local destination addresses will not be forwarded outside of the

   Site boarder routers MUST NOT forward any packets with site-local
   source or destination addresses outside of the site.

   If BGP is being used at the site border with an ISP, filters MUST be
   installed in the BGP configuration to keep any site-local prefixes
   from being advertised outside of the site or for site-local prefixes
   to be learned from another site.

3.6 DNS Naming Issues

   Site-Local addresses MUST NOT be installed in the global DNS.  They
   may be installed in a naming system local to the site or kept
   separate from the global DNS using techniques such as "two-faced"

   For future study names with site-local address may be resolved inside
   of the site using dynamic naming systems such as Multicast DNS.

4.0 Advantages

   The proposal has the following advantages:

      - Provides globally unique site-local prefixes per subnet based on
        EUI-48 global tokens.
      - The prefixes are designed to allow for automatic generation
        without manual configuration.
      - Sites using the default area of zero can be merged without any
        renumbering of the site-local addresses.
      - Large sites may create areas to allow aggregation of routes
        inside of the site.
      - The allocation strategy (i.e., /64 per subnet) helps insure that
        the prefixes will not be routed outside of the site because
        there would be too many new routes introduced in the global

draft-hinden-ipv6-global-site-local-00.txt                      [Page 5]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002

5.0 Disadvantages

      - No default aggregation of site-local prefixes inside of the
      - If areas are used and the site is merged with another site, the
        areas that are duplicated will have to be advertised as /64
        prefixes (with the loss of aggregation) and later renumbered.

6.0 Security Considerations


draft-hinden-ipv6-global-site-local-00.txt                      [Page 6]

INTERNET-DRAFT  IPv6 Globally Unique Site-Local Addresses  December 2002


      [ADDARCH] Hinden, R., S. Deering, S., "IP Version 6 Addressing
                Architecture", Internet Draft, <draft-ietf-ipngwg-addr-
                arch-v3-11.txt>, October 2002.

      [IPV6]    Deering, S., R. Hinden, "Internet Protocol, Version 6
                (IPv6) Specification", RFC2460, December 1998.

      [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
                3", RFC2026, BCP00009, October 1996.

      [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels", RFC2119, BCP14, March 1997.


      Robert M. Hinden
      313 Fairchild Drive
      Mountain View, CA 94043

      phone: +1 650 625-2004
      email: hinden@iprg.nokia.com

draft-hinden-ipv6-global-site-local-00.txt                      [Page 7]