Internet Engineering Task Force                                   B. Liu
Internet-Draft                                                  S. Jiang
Intended status: Informational                       Huawei Technologies
Expires: February 18, September 14, 2017                               March 13, 2017                               August 17, 2016

            Considerations For Using Unique Local Addresses
              draft-ietf-v6ops-ula-usage-considerations-01
              draft-ietf-v6ops-ula-usage-considerations-02

Abstract

   This document provides considerations for using IPv6 Unique Local
   Addresses (ULAs).  Based on an analysis of different ULA usage
   scenarios, this document identifies use cases where ULA addresses are
   helpful as well as potential problems caused by using them, them.

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 http://datatracker.ietf.org/drafts/current/.

   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 February 18, September 14, 2017.

Copyright Notice

   Copyright (c) 2016 2017 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
   (http://trustee.ietf.org/license-info) 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Analysis of ULA Features  . . . . . .  General Considerations For Using ULAs . . . . . . . . . . . .   3
     3.1.  Automatically Generated . . . . .  Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . .   3
     3.2.  Globally Unique . . . . . . . . . . . . . . . . . . . . .   3
     3.3.  Provider Independent Address Space  . . . . . . . . . . .   3
     3.4.  Well Known Prefix . . . . . . . . . . . . . . . . . . . .   4
     3.5.  Stable or Temporary Prefix  .  Using ULAs in a Limited Scope . . . . . . . . . . . . . .   4
   4.  Analysis and Operational Considerations for Scenarios Using
       ULAs  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  ULA-only in Isolated Networks . . . . . . . . . . . . . . . . . . . .   4
     4.2.  ULA+PA in Connected Networks  . . . . . . . . . . . . . . . . . . .   5
       4.2.1.
     4.3.  ULA-Only Deployment . . . . . . . . . . . . . . . . in Connected Networks  .   5
       4.2.2.  ULAs along with PA Addresses . . . . . . . . . . . .   7
     4.3.  IPv4 Co-existence Considerations  .
     4.4.  Some Specific Use Cases . . . . . . . . . . .   9
   5.  General Considerations For Using ULAs . . . . . .   8
       4.4.1.  Special Routing . . . . . .  10
     5.1.  Do Not Treat ULA Equal to RFC1918 . . . . . . . . . . . .  10
     5.2.  Using ULAs in a Limited Scope .   8
       4.4.2.  Used as Identifier  . . . . . . . . . . . . .  10
   6.  ULA Usages Considered Helpful . . . .   8
     4.5.  IPv4 Co-existence Considerations  . . . . . . . . . . . .  11
     6.1.  Used in Isolated Networks   9
   5.  Security Considerations . . . . . . . . . . . . . . . .  11
     6.2.  ULA along with PA . . .   9
   6.  IANA Considerations . . . . . . . . . . . . . . . . .  11
     6.3.  Some Specific Use Cases . . . .  10
   7.  Acknowledgements  . . . . . . . . . . . . .  11
       6.3.1.  Special Routing . . . . . . . . .  10
   8.  References  . . . . . . . . . .  11
       6.3.2.  Used as NAT64 Prefix . . . . . . . . . . . . . . .  10
     8.1.  Normative References  .  11
       6.3.3.  Used as Identifier . . . . . . . . . . . . . . . . .  12
   7.  Security Considerations  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . .  13
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     10.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     10.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   Unique Local Addresses (ULA) is defined in [RFC4193], and it is an
   alternative to site-local address (deprecated in [RFC3879]).  But  ULAs
   have the
   two kind of addresses are not following features:

   -  Automatically Generated

      ULA prefixes can be automatically generated using the same. algorithms
      described in [RFC4193].  This feature allows automatic prefix
      allocation.  Thus one can get a network working immediately
      without applying for prefix(es) from an RIR/LIR (Regional Internet
      Registry/Local Internet Registry).

   -  Globally Unique

      ULAs are defined as a global scope address space.  However, they
      are not intended to be used globally on the public Internet; in
      contrast, they are mostly used locally, for example, in isolated
      networks, internal networks, or VPNs.

   Global scope yet local usage, this special feature has confused
   network operators more or less.  This document aims

      ULAs are intended to introduce the
   usage have an extremely low probability of ULAs
      collision.  The randomization of 40 bits in various scenarios, provide some operational
   considerations, and clarify the advantages a ULA prefix is
      considered sufficient enough to ensure a high degree of uniqueness
      (refer to [RFC4193] Section 3.2.3 for details) and disadvantages simplifies
      merging of networks by avoiding the
   usage in each scenario.  Thus, the administrators could choose need to use renumber overlapping
      IP address space.

   -  Provider Independent Address Space

      ULAs in a certain way that considered benificial can be used for internal communications even without Internet
      connectivity.  They need no registration, so they can support on-
      demand usage and do not carry any RIR/LIR burden of documentation
      or fees.

   -  Well Known Prefix

      The prefixes of ULAs are well known thus they are easily
      identified and filtered.

   This document aims to introduce the usage of ULAs in various
   scenarios, provide some operational considerations, and clarify the
   advantages and disadvantages of the usage in each scenario.  Thus,
   the administrators could choose to use ULAs in a certain way that
   considered benificial for them.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   [RFC2119] when they appear in ALL CAPS.  When these words are not in
   ALL CAPS (such as "should" or "Should"), they have their usual
   English meanings, and are not to be interpreted as [RFC2119] key
   words.

3.  Analysis of ULA Features  General Considerations For Using ULAs

3.1.  Automatically Generated  Do Not Treat ULA prefixes can be automatically generated using the algorithms
   described in [RFC4193].  This feature allows automatic prefix
   allocation.  Thus one can get a network working immediately without
   applying for prefix(es) from an RIR/LIR (Regional Internet Registry/
   Local Internet Registry).

3.2.  Globally Unique

   ULAs are intended Equal to have an extremely low probability of collision.
   The randomization of 40 bits in a RFC1918

   ULA prefix is considered sufficient
   enough to ensure a high degree of uniqueness (refer to [RFC4193]
   Section 3.2.3 for details) and simplifies merging of networks by
   avoiding the need to renumber overlapping IP address space.  Such
   overlapping was a major drawback to the deployment of private [RFC1918] addresses are similar in IPv4.

   Note that, some aspects.  The most obvious one
   is as described in [RFC4864], applications may treat ULAs in
   practice like global-scope addresses, but Section 3.1.3 that ULA provides an internal
   address selection
   algorithms may need independence capability in IPv6 that is similar to distinguish between ULAs and Global-scope
   Unicast Addresses (GUAs) how
   [RFC1918] is commonly used.  ULA allows administrators to ensure bidirectional communications.  As
   a further note, configure
   the default address selection policy table internal network of each platform the same way it is configured
   in
   [RFC6724]) responds IPv4.  Many organizations have security policies and architectures
   based around the local-only routing of [RFC1918] addresses and those
   policies may directly map to ULA [RFC4864].

   But this requirement.

3.3.  Provider Independent Address Space

   ULAs can be used does not mean that ULA is equal to an IPv6 version of
   [RFC1918] deployment.  [RFC1918] usually combines with NAT/NAPT for internal communications even without Internet
   global connectivity.  They need no registration, so they can support on-
   demand usage and do  But it is not carry necessary to combine ULAs with
   any RIR/LIR burden of documentation or
   fees.

3.4.  Well Known Prefix

   The prefixes kind of ULAs are well known thus they are easily identified
   and filtered. NAT.  Operators can use ULA for local communications
   along with global addresses for global communications (see
   Section 4.2).  This is a big advantage brought by default support of
   multiple-addresses-per-interface feature in IPv6.  (People may still
   have a requirement for NAT with ULA, this is discussed in
   Section 4.3.  But people also need to keep in mind that ULA is convenient not
   intentionally designed for management this kind of security policies and
   troubleshooting.  For example, network administrators can segregate
   packets containing data which must stay in use case.)

   Another important difference is the internal network by
   assigning ULAs to internal servers.  Externally-destined data can be
   sent ability to merge two ULA networks
   without renumbering (because of the Internet or telecommunication network by uniqueness), which is a separate
   function, through an appropriate gateway/firewall.

3.5.  Stable or Temporary Prefix big
   advantage over [RFC1918].

3.2.  Using ULAs in a Limited Scope

   A ULA is by definition a prefix can be generated once, at installation time or factory
   reset, and then possibly that is never be changed.  Alternatively, it can be
   regenerated regularly, depending advertised outside a
   given domain, and is used within that domain by agreement of those
   networked by the domain.

   So when using ULAs in a network, the administrators need to clearly
   set the scope of the ULAs and configure ACLs on deployment requirements. relevant border
   routers to block them out of the scope.  And if internal DNS is
   enabled, the administrators might also need to use internal-only DNS
   names for ULAs and might need to split the DNS so that the internal
   DNS server includes records that are not presented in the external
   DNS server.

4.  Analysis and Operational Considerations for Scenarios Using ULAs

4.1.  ULA-only in Isolated Networks

   IP is used ubiquitously.  Some networks like industrial control bus
   (e.g.  [RS-485], [SCADA], or even non-networked digital interfaces
   like [MIL-STD-1397] have begun to use IP.  In these kinds of
   networks, the system may lack the ability to communicate with the
   public networks.

   As another example, there may be some networks in which the equipment
   has the technical capability to connect to the Internet, but is
   prohibited by administration or just temporarily not connected. administration.  These networks may include data center
   networks, separate financial networks, lab networks.
   machine-to-machine  machine-to-
   machine (e.g. vehicle networks), sensor networks, or even normal
   LANs, and can include very large numbers of addresses.

   Serious disadvantages and impact on applications due to the use of
   ambiguous address space have been well documented in [RFC1918].
   However,

   ULA is a straightforward way to assign the IP addresses in the kinds
   of networks just described, with minimal administrative cost or
   burden.  Also, ULAs fit in multiple subnet scenarios, in which each
   subnet has its own ULA prefix.  For example, when assigning vehicles
   with ULAs, it is then possible to separate in-
   vehicle in-vehicle embedded
   networks into different subnets depending on real-
   time real-time situation.

   However, each isolated network has the possibility to be connected in
   the future.  Administrators need to consider the following before
   deciding whether to use ULAs:

   o  If the network eventually connects to another isolated or private
      network, the potential for address collision arises.  However, if
      the ULAs were generated in the standard way, this will not be a
      big problem.

   o  If the network eventually connects to the global Internet, then
      the operator will need to add a new global prefix and ensure that
      the address selection policy is properly set up on all interfaces.

   Operational considerations:

   o  Prefix generation: randomly generated according to the algorithms
      defined in [RFC4193] or manually assigned.  Normally, automatic
      generation of the prefixes is recommended, following [RFC4193].
      If there are some specific reasons that call for manual
      assignment, administrators have to plan the prefixes carefully to
      avoid collision.

   o  Prefix announcement: in some cases, networks might need to
      announce prefixes to each other.  For example, in vehicle networks
      with infrastructure-less settings such as Vehicle-to-Vehicle (V2V)
      communication, prior knowledge of the respective prefixes is
      unlikely.  Hence, a prefix announcement mechanism is needed to
      enable inter-vehicle communications based on IP.  As one
      possibility, such announcements could rely on extensions to the
      Router Advertisement message of the Neighbor Discovery Protocol
      (e.g., [I-D.petrescu-autoconf-ra-based-routing] and
      [I-D.jhlee-mext-mnpp]).

4.2.  ULA+PA in Connected Networks

4.2.1.  ULA-Only Deployment

   In some situations, nodes in one

   Two classes of network are assigned ULAs but not
   Global Unicast Addresses (GUAs), but the nodes also might need to
   communicate use ULA with the outside network.  There could be two approaches: PA (Provider
   Aggregated) addresses:

   o  Using Network Prefix Translation (NPTv6)

         NPTv6[RFC6296] is  Home network.  Home networks are normally assigned with one or
      more globally routed PA prefixes to connect to the uplink of an experimental specification that provides a
         stateless one-to-one mapping between
      ISP.  In addition, they may need internal addresses and
         external addresses.  Translating ULA prefixes into GUA prefixes routed networking even
      when the ISP link is an use case of this specification.

         NPTv6 works differently from traditional stateful NAT/NAPT
         (which down.  Then ULA is discouraged in [RFC5902]).  So it does not create
         several of a proper tool to fit the problems known
      requirement.  [RFC7084] requires the CPE to exsit with other kinds of NATs
         as discussed in [RFC2993] and [RFC3027].  However, NPTv6
         Translation does create difficulties support ULA.  Note:
      ULAs provide more benefit for some kinds of
         applications.  (Please refer to Section 5 of [RFC6296] multiple-segment home networks; for
         detailed analysis.)
      home networks containing only one segment, link-local addresses
      are better alternatives.

   o  Using Application-Layer Proxies

         In this approach, the proxies terminate the network-layer
         connectivity of the hosts and associate separate internal and
         external connections.

         In some environments (e.g., information security sensitive
         enterprises or government departments), central control  Enterprise network.  An enterprise network is
         exercised by allowing the endpoints to connect to the Internet
         only through usually a proxy.  With IPv4, using private address space managed
      network with proxies is an effective and common practice for this
         purpose, one or more PA prefixes or with a PI prefix, all of
      which are globally routed.  The ULA can be used to improve
      internal connectivity and make it is natural more resilient, or to pick ULA as its counterpart in
         IPv6.

   o  Controversies of ULA-only Deployment

         The comunity has strong controversies isolate
      certain functions like OAM for servers.

   Benefits of ULA-only deployment Using ULAs in
         connected networks.

         The this scenario:

   o  Separated local communication plane: for either home networks or
      enterprise networks, the main reason of those who are in favor purpose of using ULAs this
         way is that it could get provider independent along with PA
      addresses or get
         connected is to provide a logically local routing plane separated
      from the isolated stage without applying global routing plane.  The benefit is to any RIRs/
         LIRs. ensure stable
      and specific local communication regardless of the ISP uplink
      failure.  This might be a essential benefit is especially meaningful for the vast number of
         small organizations, home
      network or for saving time and address fee.

         For those who are strongly against this usage, the main reason
         is private OAM function in an enterprise.

   o  Renumbering: in some special cases such as renumbering, enterprise
      administrators may want to avoid breaking the end-to-end transparence.  Because
         people have suffered from the NAT/Proxy middle boxes so much in
         the IPv4 ear, there is no reason need to continue the suffering renumber their
      internal-only, private nodes when
         IPv6 is available.

         So, according they have to renumber the controversy, this document does not
         consider ULA+NPTv6/Proxy as a first choice for normal cases.
         Rather, this document considers ULA+PA (Provider Aggregated) as
         a better approach to connect to PA
      addresses of the global network when ULAs
         are expected to be retained.  The use rest of ULA+PA is discussed in
         detail in Section 4.2.2 below.

   Operational considerations:

   o  Firewall deployment: [RFC6296] points out that an NPTv6 translator
      does not have the same security properties as a traditional NAT44,
      and hence needs be supplemented with a firewall if security at network because they are changing
      ISPs, because the
      boundary is an issue.  The operator ISP has to decide where to locate
      the firewall.

      -  If the firewall is located outside the NPTv6 translator, then
         filtering restructured its address allocations, or
      for some other reason.  In these situations, ULA is based an effective
      tool for addressing internal-only nodes.  Even public nodes can
      benefit from ULA for renumbering, on the translated GUA prefixes, and when the their internal ULA interfaces.
      When renumbering, as [RFC4192] suggests, old prefixes are renumbered, the filtering rules do
         not need continue to
      be changed.  However, when the GUA prefixes of valid until the
         NPTv6 are renumbered, new prefix(es) is(are) stable.  In the filtering rules need process
      of adding new prefix(es) and deprecating old prefix(es), it is not
      easy to be updated
         accordingly.).

      - keep local communication disentangled from global routing
      plane change.  If we use ULAs for local communication, the firewall is located inside
      separated local routing plane can isolate the NPTv6 translator, effects of global
      routing change.

   Drawbacks:

   o  Operational Complexity: there are some arguments that in practice
      the
         filtering is then based on the ULA prefixes, and the rules need
         to be updated correspondingly.  There use of ULA+PA creates additional operational complexity.  This
      is no need to update when not a ULA-specific problem; the NPTv6 GUA prefixes are renumbered.

4.2.2.  ULAs along with PA Addresses

   Two classes multiple-addresses-per-
      interface is an important feature of network might need to use ULA with PA (Provider
   Aggregated) addresses:

   o  Home network.  Home networks are normally assigned with one or
      more globally routed PA IPv6 protocol.  Nevertheless,
      running multiple prefixes to connect to the uplink of an
      ISP.  In addition, they needs more operational consideration
      than running a single one.

   Operational considerations:

   o  Default Routing: connectivity may need internal routed networking even
      when the ISP link is down.  Then ULA is be broken if ULAs are used as
      default route.  When using RIO (Route Information Option) in

      [RFC4191], specific routes can be added without a proper tool default route,
      thus avoiding bad user experience due to fit the
      requirement. timeouts on ICMPv6
      redirects.  This behavior was well documented in [RFC7084] requires the CPE to support ULA.  Note:
      ULAs provide more benefit for multiple-segment home networks; for
      home networks containing only one segment, link-local addresses
      are better alternatives.

   o  Enterprise network.  An enterprise network is usually as rule
      ULA-5 "An IPv6 CE router MUST NOT advertise itself as a managed
      network with one or more PA prefixes or default
      router with a PI prefix, Router Lifetime greater than zero whenever all of
      which
      its configured and delegated prefixes are globally routed.  The ULA can be used to improve
      internal connectivity prefixes." and make it more resilient, or to isolate
      certain functions like OAM for servers.

   Benefits of Using ULAs in this scenario:

   o  Separated local communication plane: for either home networks or
      enterprise networks, the main purpose of using ULAs along with PA
      addresses is to provide a logically local routing plane separated
      from the global routing plane.  The benefit is to ensure stable
      and specific local communication regardless of the ISP uplink
      failure.  This benefit is especially meaningful for the home
      network or for private OAM function in an enterprise.

   o  Renumbering: in some special cases such as renumbering, enterprise
      administrators may want to avoid the need to renumber their
      internal-only, private nodes when they have to renumber the PA
      addresses of the rest of the network because they are changing
      ISPs, because the ISP has restructured its address allocations, or
      for some other reason.  In these situations, ULA is an effective
      tool for addressing internal-only nodes.  Even public nodes can
      benefit from ULA for renumbering, on their internal interfaces.
      When renumbering, as [RFC4192] suggests, old prefixes continue to
      be valid until the new prefix(es) is(are) stable.  In the process
      of adding new prefix(es) and deprecating old prefix(es), it is not
      easy to keep local communication disentangled from global routing
      plane change.  If we use ULAs for local communication, the
      separated local routing plane can isolate the effects of global
      routing change.

   Drawbacks:

   o  Operational Complexity: there are some arguments that in practice
      the use of ULA+PA creates additional operational complexity.  This
      is not a ULA-specific problem; the multiple-addresses-per-
      interface is an important feature of IPv6 protocol.  Nevertheless,
      running multiple prefixes needs more operational consideration
      than running a single one.

   Operational considerations:

   o  Default Routing: connectivity may be broken if ULAs are used as
      default route.  When using RIO (Route Information Option) in
      [RFC4191], specific routes can be added without a default route,
      thus avoiding bad user experience due to timeouts on ICMPv6
      redirects.  This behavior was well documented in [RFC7084] as rule
      ULA-5 "An IPv6 CE router MUST NOT advertise itself as a default
      router with a Router Lifetime greater than zero whenever all of
      its configured and delegated prefixes are ULA prefixes." and along
      with rule L-3 "An IPv6 CE router MUST advertise itself as a router
      for the delegated prefix(es) (and ULA prefix if configured to
      provide ULA addressing) using the "Route Information Option"
      specified in Section 2.3 of [RFC4191].  This advertisement is
      independent of having or not having IPv6 connectivity on the WAN
      interface.".  However, it needs to be noticed that current OSes
      don't all support [RFC4191].

   o  SLAAC/DHCPv6 co-existing: Since SLAAC and DHCPv6 might be enabled
      in one network simultaneously; the administrators need to
      carefully plan how to assign ULA and PA prefixes in accordance
      with the two mechanisms.  The administrators need to know the
      current issue of the SLAAC/DHCPv6 interaction (please refer to
      [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details).

   o  Address selection: As mentioned in [RFC5220], there is a
      possibility that the longest matching rule will not be able to
      choose the correct address between ULAs and global unicast
      addresses for correct intra-site and extra-site communication.
      [RFC6724] claims that a site-specific policy entry can be used to
      cause ULAs within a site to be preferred over global addresses.

   o  DNS relevant: if administrators choose not to do reverse DNS
      delegation inside of their local control of ULA prefixes, a
      significant amount of information about the ULA population may
      leak to the outside world.  Because reverse queries will be made
      and naturally routed to the global reverse tree, so external
      parties will be exposed to the existence of a population of ULA
      addresses.  [ULA-IN-WILD] provides more detailed situations on
      this issue.  Administrators may need a split DNS to separate the
      queries from internal and external for ULA entries and GUA
      entries.

4.3.  IPv4 Co-existence Considerations

   Generally, this document does not consider IPv4 to be in scope.  But
   regarding ULA, there is a special case needs to be recognized, which
   is described in Section 3.2.2 of [RFC5220].  When an enterprise has
   IPv4 Internet connectivity but does not yet have IPv6 Internet
   connectivity, and the enterprise wants to provide site-local IPv6
   connectivity, a ULA is the best choice for site-local IPv6
   connectivity.  Each employee host will have both an IPv4 global or
   private address and a ULA.  Here, when this host tries to connect to
   an outside node that has registered both A and AAAA records in the
   DNS, the host will choose AAAA as the destination address and the ULA
   for the source address according to the IPv6 preference of the
   default policy table defined in the old address selection standard
   [RFC3484].  This will clearly result in a connection failure.  The
   new address selection standard [RFC6724] has corrected this behavior
   by preferring IPv4 than ULAs in the default policy table.  However,
   there are still lots of hosts using the old standard [RFC3484], thus
   this could be an issue in real networks.

   Happy Eyeballs [RFC6555] solves this connection failure problem, but
   unwanted timeouts will obviously lower the user experience.  One
   possible approach to eliminating the timeouts is to deprecate the
   IPv6 default route and simply configure a scoped route on hosts (in
   the context of this document, only configure the ULA prefix routes).
   Another alternative is to configure IPv4 preference on the hosts, and
   not include DNS A records but only AAAA records for the internal
   nodes in the internal DNS server.  Then outside nodes have both A and
   AAAA records and can be connected through IPv4 as default and
   internal nodes can always connect through IPv6.  But since IPv6
   preference is default, changing the default in all nodes is not
   suitable at scale.

5.  General Considerations For Using ULAs

5.1.  Do Not Treat ULA Equal to RFC1918

   ULA and [RFC1918] are similar in some aspects.  The most obvious one
   is as described in Section 3.1.3 that ULA provides an internal
   address independence capability in IPv6 that is similar to how
   [RFC1918] is commonly used.  ULA allows administrators to configure
   the internal network of each platform the same way it is configured
   in IPv4.  Many organizations have security policies and architectures
   based around the local-only routing of [RFC1918] addresses and those
   policies may directly map to ULA [RFC4864].

   But this does not mean that ULA is equal to an IPv6 version of
   [RFC1918] deployment.  [RFC1918] usually combines with NAT/NAPT for
   global connectivity.  But it is not necessary to combine ULAs with
   any kind of NAT.  Operators can use ULA for local communications along
      with global addresses for global communications (see
   Section 4.2.2).  This is a big advantage brought by default support
   of multiple-addresses-per-interface feature in IPv6.  (People may
   still have rule L-3 "An IPv6 CE router MUST advertise itself as a requirement for NAT with ULA, this is discussed in
   Section 4.2.1.  But people also need to keep in mind that ULA is not
   intentionally designed router
      for this kind of use case.)

   Another important difference is the ability delegated prefix(es) (and ULA prefix if configured to merge two
      provide ULA networks
   without renumbering (because of addressing) using the uniqueness), which is a big
   advantage over [RFC1918].

5.2.  Using ULAs "Route Information Option"
      specified in a Limited Scope

   A ULA Section 2.3 of [RFC4191].  This advertisement is by definition a prefix
      independent of having or not having IPv6 connectivity on the WAN
      interface.".  However, it needs to be noticed that is never advertised outside a
   given domain, current OSes
      don't all support [RFC4191].

   o  SLAAC/DHCPv6 co-existing: Since SLAAC and is used within that domain by agreement of those
   networked by DHCPv6 might be enabled
      in one network simultaneously; the domain.

   So when using ULAs administrators need to
      carefully plan how to assign ULA and PA prefixes in a network, accordance
      with the two mechanisms.  The administrators need to clearly
   set know the scope
      current issue of the SLAAC/DHCPv6 interaction (please refer to
      [I-D.ietf-v6ops-dhcpv6-slaac-problem] for details).

   o  Address selection: As mentioned in [RFC5220], there is a
      possibility that the longest matching rule will not be able to
      choose the correct address between ULAs and configure ACLs on relevant border
   routers global unicast
      addresses for correct intra-site and extra-site communication.
      [RFC6724] claims that a site-specific policy entry can be used to block them out of the scope.  And if internal
      cause ULAs within a site to be preferred over global addresses.

   o  DNS is
   enabled, the relevant: if administrators might also need choose not to use internal-only do reverse DNS
   names for ULAs
      delegation inside of their local control of ULA prefixes, a
      significant amount of information about the ULA population may
      leak to the outside world.  Because reverse queries will be made
      and might need naturally routed to split the DNS global reverse tree, so that external
      parties will be exposed to the internal existence of a population of ULA
      addresses.  [ULA-IN-WILD] provides more detailed situations on
      this issue.  Administrators may need a split DNS server includes records that are not presented in to separate the
      queries from internal and external
   DNS server.

6. for ULA Usages Considered Helpful

6.1.  Used entries and GUA
      entries.

4.3.  ULA-Only in Isolated Connected Networks

   As analyzed in Section 4.1, ULA

   In theory, a site numbered with ULAs only can get connected via a
   NPTv6[RFC6296] (which is very suitable for an experimental specification that provides
   a stateless one-to-one mapping between internal addresses and
   external addresses) or application-layer proxy.  This approach could
   get provider independent addresses or get connected from the isolated
   networks.  Especially when there are subnets
   stage without applying to any RIRs/LIRs.  This might make small
   organizations saving time and address fee.

   However, this approach breaks the end-to-end transparence.  People
   have suffered from the NAT/Proxy middle boxes so much in the isolated network,
   ULA IPv4
   ear, there is no reason to continue the suffering when IPv6 is
   available.  This document does not consider ULA+NPTv6/Proxy as a reasonable choice.

6.2.  ULA along with PA

   As described in Section 4.2.2, using good
   choice for normal cases.  Rather, this document considers ULA+PA
   (Provider Aggregated) as a better approach to connect to the global
   network when ULAs along with PA addresses are expected to
   provide a logically separated local plane can benefit OAM functions
   and renumbering.

6.3. be retained.

4.4.  Some Specific Use Cases

   Along with the general scenarios, this section provides some specific
   use cases that could benefit from using ULA.

6.3.1.

4.4.1.  Special Routing

   For various reasons the administrators may want to have private
   routing be controlled and separated from other routing.  For example,
   in the business-to-business case described in
   [I-D.baker-v6ops-b2b-private-routing], two companies might want to
   use direct connectivity that only connects stated machines, such as a
   silicon foundry with client engineers that use it.  A ULA provides a
   simple way to assign prefixes that would assign prefixes that would be used in accordance with
   an agreement between the parties.

4.4.2.  Used as Identifier

   ULAs could be self-generated and easily grabbed from the standard
   IPv6 stack.  And ULAs don't need to be used in accordance with
   an agreement between the parties.

6.3.2.  Used changed as NAT64 Prefix

   The NAT64 PREF64 is just a group of local fake addresses for the
   DNS64 to point traffic GUA prefixes
   do.  So they are very suitable to a NAT64.  Using a ULA prefix be used as identifiers by the PREF64
   easily ensures that only local systems can use the translation
   resources of the NAT64 system up
   layer applications.  And since the ULA is not intended to be globally routable.  The ULA helps clearly identify traffic that
   routed, it is
   locally contained and destined not harmful to the routing system.

   Such kind of benefit has been utilized in real implementations.  For
   example, in [RFC6281], the protocol BTMM (Back To My Mac) needs to
   assign a NAT64.  Using ULA for PREF64 is
   deployed and it is an operational model.

   But there is an issue topology-independent identifier to each client host
   according to the following considerations:

   o  TCP connections between two end hosts wish to survive in network
      changes.

   o  Sometimes one needs a constant identifier to be noted.  The NAT64 standard
   [RFC6146] specifies associated with a
      key so that the PREF64 should align with [RFC6052], in
   which Security Association can survive the IPv4-Embedded IPv6 Address format was specified.  If we
   pick a /48 for NAT64, it happens location
      changes.

   It needs to be a standard 48/ part of ULA
   (7bit noticed again that in theory ULA well-known prefix+ 1 "L" bit + 40bit Global ID).  Then has the
   40bit possibility
   of ULA collision.  However, the probability is desirably small enough and
   can be ignored in most cases when ULAs are used as identifiers.

4.5.  IPv4 Co-existence Considerations

   Generally, this document does not violated by being filled with part of the 32bit consider IPv4 address.  This is important, because the 40bit assures the
   uniqueness of ULA.  If the prefix to be in scope.  But
   regarding ULA, there is shorter than /48, the 40bit
   would a special case needs to be violated, recognized, which
   is described in Section 3.2.2 of [RFC5220].  When an enterprise has
   IPv4 Internet connectivity but does not yet have IPv6 Internet
   connectivity, and this could cause conformance issues.  But it the enterprise wants to provide site-local IPv6
   connectivity, a ULA is considered that the most common use case best choice for site-local IPv6
   connectivity.  Each employee host will be a /96 PREF64, have both an IPv4 global or
   even /64 will be used.  So it seems
   private address and a ULA.  Here, when this issue is not common in
   current practice.

   It is most common host tries to connect to
   an outside node that ULA PREF64 will be deployed on a single
   internal network, where the clients has registered both A and AAAA records in the NAT64 share a common
   internal network.  ULA
   DNS, the host will not be effective choose AAAA as PREF64 when the
   access network must use an Internet transit to receive the
   translation service of a NAT64 since destination address and the ULA will not route across
   for the Internet.

   According source address according to the IPv6 preference of the
   default address selection policy table specified defined in
   [RFC6724], the host would always prefer IPv4 over ULA.  This could be
   a problem in NAT64-CGN scenario as analyzed in Section 8 of
   [RFC7269].  So administrators need to add additional site-specific old address selection rules to the default table to steer traffic flows
   going through NAT64-CGN.  However, updating the default policy tables
   in all hosts involves significant management cost. standard
   [RFC3484].  This may be
   possible will clearly result in an enterprise (using a group policy object, or other
   configuration mechanisms), but it is not suitable at scale for home
   networks.

6.3.3.  Used as Identifier

   ULAs could be self-generated and easily grabbed from the connection failure.  The
   new address selection standard
   IPv6 stack.  And ULAs don't need to be changed as the GUA prefixes
   do.  So they are very suitable to be used as identifiers [RFC6724] has corrected this behavior
   by preferring IPv4 than ULAs in the up
   layer applications.  And since ULA is not intended to be globally
   routed, it is not harmful to the routing system.

   Such kind default policy table.  However,
   there are still lots of benefit has been utilized hosts using the old standard [RFC3484], thus
   this could be an issue in real implementations.  For
   example, in [RFC6281], networks.

   Happy Eyeballs [RFC6555] solves this connection failure problem, but
   unwanted timeouts will obviously lower the protocol BTMM (Back To My Mac) needs to
   assign a topology-independent identifier to each client host
   according user experience.  One
   possible approach to eliminating the following considerations:

   o  TCP connections between two end hosts wish to survive in network
      changes.

   o  Sometimes one needs a constant identifier timeouts is to be associated with deprecate the
   IPv6 default route and simply configure a
      key so that scoped route on hosts (in
   the Security Association can survive context of this document, only configure the location
      changes.

   It needs to be noticed again that in theory ULA has prefix routes).
   Another alternative is to configure IPv4 preference on the possibility
   of collision.  However, hosts, and
   not include DNS A records but only AAAA records for the probability is desirably small enough internal
   nodes in the internal DNS server.  Then outside nodes have both A and
   AAAA records and can be ignored in most cases when ULAs are used connected through IPv4 as identifiers.

7. default and
   internal nodes can always connect through IPv6.  But since IPv6
   preference is default, changing the default in all nodes is not
   suitable at scale.

5.  Security Considerations

   Security considerations regarding ULAs, in general, please refer to
   the ULA specification [RFC4193].  Also refer to [RFC4864], which
   shows how ULAs help with local network protection.

   As mentioned in Section 4.2.2, 4.2, when using NPTv6, the administrators
   need to know where the firewall is located to set proper filtering
   rules.

   Also as mentioned in Section 4.2.2, 4.2, if administrators choose not to do
   reverse DNS delegation inside their local control of ULA prefixes, a
   significant amount of information about the ULA population may leak
   to the outside world.

8.

6.  IANA Considerations

   This memo has no actions for IANA.

9.

7.  Acknowledgements

   Many valuable comments were received in the IETF v6ops WG mail list,
   especially from Cameron Byrne, Fred Baker, Brian Carpenter, Lee
   Howard, Victor Kuarsingh, Alexandru Petrescu, Mikael Abrahamsson, Tim
   Chown, Jen Linkova, Christopher Palmer Jong-Hyouk Lee, Mark Andrews,
   Lorenzo Colitti, Ted Lemon, Joel Jaeggli, David Farmer, Doug Barton,
   Owen Delong, Gert Doering, Bill Jouris, Bill Cerveny, Dave Thaler,
   Nick Hilliard, Jan Zorz, Randy Bush, Anders Brandt, , Sofiane Imadali
   and Wesley George.

   Some test of using ULA in the lab was done by our research partner
   BNRC-BUPT (Broad Network Research Centre in Beijing University of
   Posts and Telecommunications).  Thanks for the work of Prof.
   Xiangyang Gong and student Dengjia Xu.

   Tom Taylor did a language review and revision throught the whole
   document.  The authors appreciate a lot for his help.

   This document was produced using the xml2rfc tool [RFC2629]
   (initially prepared using 2-Word-v2.0.template.dot.).

10.

8.  References

10.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>.

   [RFC4193]  Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
              <http://www.rfc-editor.org/info/rfc4193>.

10.2.

8.2.  Informative References

   [I-D.baker-v6ops-b2b-private-routing]
              Baker, F., "Business to Business Private Routing", draft-
              baker-v6ops-b2b-private-routing-00 (work in progress),
              July 2007.

   [I-D.ietf-v6ops-dhcpv6-slaac-problem]
              Liu, B., Jiang, S., Gong, X., Wang, W., and E. Rey,
              "DHCPv6/SLAAC Interaction Problems on Address and DNS
              Configuration", draft-ietf-v6ops-dhcpv6-slaac-problem-06 draft-ietf-v6ops-dhcpv6-slaac-problem-07
              (work in progress), February August 2016.

   [I-D.jhlee-mext-mnpp]
              Tsukada, M., Ernst, T., and J. Lee, "Mobile Network Prefix
              Provisioning", draft-jhlee-mext-mnpp-00 (work in
              progress), October 2009.

   [I-D.petrescu-autoconf-ra-based-routing]
              Petrescu, A., Janneteau, C., Demailly, N., and S. Imadali,
              "Router Advertisements for Routing between Moving
              Networks", draft-petrescu-autoconf-ra-based-routing-05
              (work in progress), July 2014.

   [MIL-STD-1397]
              "Military Standard, Input/Output Interfaces, Standard
              Digital Data, Navy Systems (MIL-STD-1397B), 3 March 1989".

   [RFC1918]  Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
              and E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
              <http://www.rfc-editor.org/info/rfc1918>.

   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
              DOI 10.17487/RFC2993, November 2000,
              <http://www.rfc-editor.org/info/rfc2993>.

   [RFC3027]  Holdrege, M. and P. Srisuresh, "Protocol Complications
              with the IP Network Address Translator", RFC 3027,
              DOI 10.17487/RFC3027, January 2001,
              <http://www.rfc-editor.org/info/rfc3027>.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484,
              DOI 10.17487/RFC3484, February 2003,
              <http://www.rfc-editor.org/info/rfc3484>.

   [RFC3879]  Huitema, C. and B. Carpenter, "Deprecating Site Local
              Addresses", RFC 3879, DOI 10.17487/RFC3879, September
              2004, <http://www.rfc-editor.org/info/rfc3879>.

   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
              More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
              November 2005, <http://www.rfc-editor.org/info/rfc4191>.

   [RFC4192]  Baker, F., Lear, E., and R. Droms, "Procedures for
              Renumbering an IPv6 Network without a Flag Day", RFC 4192,
              DOI 10.17487/RFC4192, September 2005,
              <http://www.rfc-editor.org/info/rfc4192>.

   [RFC4864]  Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
              E. Klein, "Local Network Protection for IPv6", RFC 4864,
              DOI 10.17487/RFC4864, May 2007,
              <http://www.rfc-editor.org/info/rfc4864>.

   [RFC5220]  Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
              "Problem Statement for Default Address Selection in Multi-
              Prefix Environments: Operational Issues of RFC 3484
              Default Rules", RFC 5220, DOI 10.17487/RFC5220, July 2008,
              <http://www.rfc-editor.org/info/rfc5220>.

   [RFC5902]  Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on
              IPv6 Network Address Translation", RFC 5902,
              DOI 10.17487/RFC5902, July 2010,
              <http://www.rfc-editor.org/info/rfc5902>.

   [RFC6052]  Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
              DOI 10.17487/RFC6052, October 2010,
              <http://www.rfc-editor.org/info/rfc6052>.

   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
              April 2011, <http://www.rfc-editor.org/info/rfc6146>.

   [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
              "Understanding Apple's Back to My Mac (BTMM) Service",
              RFC 6281, DOI 10.17487/RFC6281, June 2011,
              <http://www.rfc-editor.org/info/rfc6281>.

   [RFC6296]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
              Translation", RFC 6296, DOI 10.17487/RFC6296, June 2011,
              <http://www.rfc-editor.org/info/rfc6296>.

   [RFC6555]  Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
              Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
              2012, <http://www.rfc-editor.org/info/rfc6555>.

   [RFC6724]  Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
              "Default Address Selection for Internet Protocol Version 6
              (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
              <http://www.rfc-editor.org/info/rfc6724>.

   [RFC7084]  Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic
              Requirements for IPv6 Customer Edge Routers", RFC 7084,
              DOI 10.17487/RFC7084, November 2013,
              <http://www.rfc-editor.org/info/rfc7084>.

   [RFC7269]  Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64
              Deployment Options and Experience", RFC 7269,
              DOI 10.17487/RFC7269, June 2014,
              <http://www.rfc-editor.org/info/rfc7269>.

   [RS-485]   "Electronic Industries Association (1983). Electrical
              Characteristics of Generators and Receivers for Use in
              Balanced Multipoint Systems. EIA Standard RS-485.".

   [SCADA]    "Boyer, Stuart A. (2010). SCADA Supervisory Control and
              Data Acquisition. USA: ISA - International Society of
              Automation.".

   [ULA-IN-WILD]
              "G. Michaelson, "conference.apnic.net/data/36/apnic-
              36-ula_1377495768.pdf"".

Authors' Addresses

   Bing Liu
   Huawei Technologies
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: leo.liubing@huawei.com

   Sheng Jiang
   Huawei Technologies
   Q14, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: jiangsheng@huawei.com