Analysis and recommendation for the ULA usage
draft-liu-v6ops-ula-usage-analysis-00

Network Working Group                                             B. Liu
Internet Draft                                                  S. Jiang
Intended status: Best Current Practice      Huawei Technologies Co., Ltd
Expires: April 2012                                     October 22, 2011

               Analysis and recommendation for the ULA usage
                 draft-liu-v6ops-ula-usage-analysis-00.txt

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 May 10, 2012.

Copyright Notice

   Copyright (c) 2011 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.

Abstract

   This document tries to cover all kinds of ULA use cases. And then
   tries to identify some potentially valuable use cases which can
   benefit from ULA.

                       Expires April 22, 2012                 [Page 1]
Liu & Jiang

Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

Table of Contents

   1. Introduction ................................................. 2
   2. The features of ULA .......................................... 2
      2.1. Globally unique ......................................... 2
      2.2. Independent address space ............................... 3
      2.3. Well known prefix ....................................... 3
   3. ULA usage analysis ........................................... 3
      3.1. ULA as address .......................................... 3
         3.1.1. ULA-only deployment ................................ 3
         3.1.2. ULA co-exist with globally routable addresses ...... 4
      3.2. ULA as identifier ....................................... 5
      3.3. Centrally assigned ULAs ................................. 6
   4. Benefit to renumbering ....................................... 6
   5. Benefit to security/privacy .................................. 6
   6. Security Considerations ...................................... 6
   7. IANA Considerations .......................................... 6
   8. Conclusions .................................................. 7
   9. References ................................................... 7
      9.1. Normative References .................................... 7
      9.2. Informative References .................................. 7
   10. Acknowledgments ............................................. 8

1. Introduction

   Unique Local Addresses (ULAs) are defined in RFC 4193 [RFC4193],
   which defines a local assignment method to be used for local,
   provider-independent prefixes that can be used on isolated networks,
   internal networks and VPNs.

   This document tries to cover all kinds of use cases regardless of
   whether they are valid or not. And then tries to identify some
   potentially valuable use cases.

   Particularly, this document intends to call for any existing practice
   of deploying ULA to be discussed in this document.

2. The features of ULA

2.1. Globally unique

   ULA is intended to be globally unique to avoid collision. Since the
   hosts assigned with ULA may occasionally be merged into one network.

   However, it still has some probability to have collision although the
   probability is very small.

Liu & Jiang            Expires April 22, 2012                 [Page 2]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

   Notice that, as described in [RFC4864], in practice, applications may
   treat ULAs like global-scope addresses, but address selection
   algorithms may need to distinguish between ULAs and ordinary global-
   scope unicast addresses to ensure stability.

2.2. Independent address space

   ULA provides ability in IPv6 that can perform the same function as
   RFC 1918. It allows administrators to configure the internal network
   of each platform the same way. It can be used for internal
   communications without having any permanent or only intermittent
   Internet connectivity. And it needs no registration so that it can
   support on-demand usage.

   ULAs are not intended to be routed in the Internet. So it won't
   bother much for the routing system if ULAs leaks.

2.3. Well known prefix

   The prefixes of ULAs are well known that they are easy to be
   identified and easy to be filtered.

   This feature may bring convenient to management or security policies.
   For example, the administrators can decide what parameters have to be
   assembled or transmitted globally, by a separate function, through an
   appropriate gateway/firewall, to the Internet or to the telecom
   network.

3. ULA usage analysis

   In this section, we try to cover every possible ULA use case. Some of
   them have been discussed in other documents which are briefly
   reviewed as well as other potential valid usage is discussed.

3.1. ULA as address

   This section talks about use cases that hosts in a network are only
   assigned with ULAs.

3.1.1. ULA-only deployment

   - Isolated network

   As we know, IP is used ubiquitously now. Some situations like RS-485,
   or other type of industrial control bus, or even non-networked
   digital interface like MIL-STD-1397 began to use IP protocol.

Liu & Jiang            Expires April 22, 2012                 [Page 3]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

   These systems/platforms may be used in building, car, plane .etc
   which normally are isolated. To configure addresses in these
   systems/environment, we need a straightforward way with minimal
   administrative cost.

   ULA is a good solution for these use cases. The address space is
   provided on-demand, however, for these pure isolated networks, it
   still need automatic ULA address provision.

   - Connected network

   In some situations, hosts/interfaces are assigned with ULA-only, but
   the networks need to communicate with the outside. This use case fits
   the requirement that the system/platform/network needs connectivity
   to the outside but doesn't want the addresses to be globally routed.

   The use case could be achieved through the following two methods.

   o  With NAT, some a kind of NAT which provides a simple one to one
      mapping for a subset of the internal addresses could fit the
      requirement. However, NAT in IPv6 has been always a long-term
      argued topic. This document does not intend to involve the IPv6
      NAT argument, but rather to consider the NAT is a possible
      solution.

   o  Without NAT, using a application-layer proxy can also fit the
      requirement as while as isolates the connectivity at level 3 and
      no NAT is required to be involved. Application Access from outside
      can be strict controlled. Does not matter which address used.

3.1.2. ULA co-exist with globally routable addresses

   - ULA with PA

   There are two classes of network probably to use ULA with PA
   addresses:

   o  Homenet like, which are normally assigned with PA addresses to
      connect to the uplink of some a ISP. And besides, they may use ULA
      to provide routed networking even when the ISP link is down. As
      presented in the IETF Homenet WG, they have the desire for the
      network to provide a stable ULA with limited routing scope
      alongside a global address for Global Internet routing scope.

   o  Enterprise like, this is a managed network with a fixed PA space.
      The ULA could be used for internal connectivity redundancy and
      better internal connectivity.

Liu & Jiang            Expires April 22, 2012                 [Page 4]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

   For enterprise, some people argued that in practice they don't prefer
   ULA+PA, but it is ambiguous that they just don't prefer ULA with PA,
   or just don't prefer running multiple addresses.

   Besides the unwelcome multiple addresses operation, as commented in
   [RFC6296], this use case fails to meet the requirement for address
   independence, because if an ISP renumbering event occurs, all of the
   hosts, routers, DHCP servers, Access Control Lists (ACLs), firewalls,
   and other internal systems that are configured with global addresses
   from the ISP will need to be renumbered before global connectivity is
   fully restored.

   Another issue is 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. [note: needs to identify whether
   it is still suitable for 3484-bis]

   - ULA with PI

   TBD.

3.2. ULA as identifier

   In [RFC6281], the protocol BTMM (Back To My Mac) needs to assign a
   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 associated with a
      key so that the Security Association can survive the location
      changes[RFC6281].

   ULA can fit the requirements, and besides, ULA can be used directly
   because it belongs to the existing IPv6 code and it can be created by
   the ends themselves at boot time. As ULA would not cause any problem
   to the routing system, it can be considered as an ID/Locator split
   solution in this case.

   But there is a problem of ULAs being identifiers, that in theory it
   has the possibility of collision. However, the probability is
   desirable small enough.

Liu & Jiang            Expires April 22, 2012                 [Page 5]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

3.3. Centrally assigned ULAs

   Besides the normal ULA, there has been some discussion about
   centrally assigned ULAs (ULA-C) raised in IETF.

   As analyzed in [I-D. mrw-6man-ulac-analysis], ULA-C has the benefits
   of greater assurance of uniqueness, accountability, and being able to
   populated in global reverse DNS.

   This document does not intend to involve the argument of ULA-C, but
   wants to quote it as a kind of special usage of ULA.

4. Benefit to renumbering

   Enterprise administrators want to avoid the need to renumber their
   internal, private networks when they change ISPs, or when their ISPs
   merge with other ISPs or restructure their address allocations.

   In these situations, ULA is an effective solution.

5. Benefit to security/privacy

   As mentioned in [RFC4864], ULAs have no intrinsic security properties.
   However, they have the useful property that their routing scope is
   limited by default within an administrative boundary.

   One typical benefit of the limited routing scope is about the IP
   leaking issue. In the IPv4 practice, the internal IP addresses seem
   hard to avoid be leaked. For this reason, if ULAs are used, it won't
   be a serious problem since the ULAs are not able to be routed
   globally.

   This will bring much benefit for security or privacy.

6. Security Considerations

   Security considerations regarding ULAs, in general, please refer to
   the ULA specification RFC 4193 [RFC4193], and security considerations
   regarding Centrally Assigned ULAs, in particular, please refer to the
   ULA-C draft [I-D.ietf-ipv6-ula-central].

7. IANA Considerations

   None.

Liu & Jiang            Expires April 22, 2012                 [Page 6]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

8. Conclusions

   TBD.

9. References

9.1. Normative References

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

   [RFC4193] Hinden, R., B. Haberman, "Unique Local IPv6 Unicast
             Addresses", RFC 4193, October 2005.

9.2. Informative References

   [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
             E. Lear, "Address Allocation for Private Internets",BCP 5,
             RFC 1918, February 1996.

   [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
             E. Klein, "Local Network Protection for IPv6", RFC 4864,
             May 2007.

   [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, July 2008.

   [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
             "Understanding Apple's Back to My Mac (BTMM) Service", RFC
             6281, June 2011.

   [RFC6296] Wasserman, M., and F. Baker, "IPv6-to-IPv6 Network Prefix
             Translation", RFC 6296, June 2011.

   [I-D.ietf-ipv6-ula-central]
             Hinden, R., "Centrally Assigned Unique Local IPv6 Unicast
             Addresses", draft-ietf-ipv6-ula-central-02 (work in
             progress), June 2007.

   [I-D. mrw-6man-ulac-analysis]
             Wasserman, M., "An Analysis of Centrally Assigned Unique
             Local Addresses", November 2007

Liu & Jiang            Expires April 22, 2012                 [Page 7]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

10. Acknowledgments

   This document was prepared using 2-Word-v2.0.template.dot.

Liu & Jiang            Expires April 22, 2012                 [Page 8]
Internet-Draft      draft-liu-v6ops-ula-analysis          October 2011

Authors' Addresses

   Bing Liu
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing
   P.R. China

   Email: leo.liubing@huawei.com

   Sheng Jiang
   Huawei Technologies Co., Ltd
   Huawei Building, No.3 Xinxi Rd.,
   Shang-Di Information Industry Base, Hai-Dian District, Beijing
   P.R. China

   Email: jiangsheng@huawei.com

Liu & Jiang            Expires April 22, 2012                 [Page 9]