Network Working Group B. Carpenter
Internet-Draft Univ. of Auckland
Intended status: Standards Track June 8, 2016
Expires: December 10, 2016

What does 'global' mean in IPv6?


The word 'global' is used in two different ways in various IPv6-related RFCs and an IANA registry. This document describes the resulting problem.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

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

This Internet-Draft will expire on December 10, 2016.

Copyright Notice

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

1. Problem description

As defined in the IPv6 Addressing Architecture [I-D.ietf-6man-rfc4291bis], most of the IPv6 address space is reserved for Global Unicast addresses. The high order bits of such addresses are named 'global routing prefix'. However, the word 'global' is not itself defined in the context of unicast addresses.

One subset of Global Unicast address space is defined for Unique Local Addresses [RFC4193]. One can quarrel with something being called 'global' and 'local' at the same time, but RFC 4193 is categorical:

This document defines an IPv6 unicast address format that is globally
unique and is intended for local communications, usually inside of a
site.  These addresses are not expected to be routable on the global
      - Globally unique prefix (with high probability of uniqueness).
      - In practice, applications may treat these addresses like global
        scoped addresses.
By default, the scope of these addresses is global.  That is, they
are not limited by ambiguity like the site-local addresses defined in
[ADDARCH].  Rather, these prefixes are globally unique, and as such,
their applicability is greater than site-local addresses.  Their
limitation is in the routability of the prefixes, which is limited to
a site and any explicit routing agreements with other sites to
propagate them...

In summary: ULAs are defined in these standards track documents as 'global'.

However, the IANA registry for special-purpose IPv6 addresses <>, and the RFC that controls it [RFC6890] use the following definition:

o    Global - A boolean value indicating whether an IP datagram whose
     destination address is drawn from the allocated special-purpose
     address block is forwardable beyond a specified administrative

It is evident, even from the last sentence quoted above from RFC 4193, that ULAs do not meet this definition of 'global'. As a result, they are marked in the registry with Global = False. The registry also assigns them the property Forwardable = True, which is of course valid, but the fact remains that some RFCs say that ULAs are global, but RFC 6890 and the registry say that they are not.

This inconsistency has consequences. Of course, it is always possible for code that manipulates IPv6 addresses to determine with certainty that a given address is, or is not, a ULA. But any code that uses the property 'global' from the IANA registry as a decision criterion might be wrong.

As an example, consider the Python 'ipaddress' module <>, which explicitly cites the IANA registry. It provides the property 'is_global' which tests False for ULAs. A reader of RFC 4193 would expect True. The correct test in Python (apart from an explicit match with fc00::/7) is (is_private and not is_link_local).

2. Possible fixes

  1. Do nothing.
  2. Change the registry entry for ULAs to Global=True (and update text and RFC 6890 accordingly).
  3. That, plus rename the registry column from 'Global' to 'Global scope'.
  4. Change the registry entry for ULAs to Global=Undefined (and update text and RFC 6890 accordingly).
  5. Rename the registry column from 'Global' to 'Globally reachable' (and update text and RFC 6890 accordingly).
  6. That, plus add a registry column for 'Global scope'.
  7. Your suggestion goes here.

3. Security Considerations

Misclassification of a ULA as non-global might cause it to be used for a purpose that should be limited to link-local addresses for security reasons.

4. IANA Considerations

If any changes are made as a result of this discussion, they will require IANA actions.

5. Normative References

[I-D.ietf-6man-rfc4291bis] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", Internet-Draft draft-ietf-6man-rfc4291bis-02, April 2016.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R. and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013.

Author's Address

Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland, 1142 New Zealand EMail: