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]