Internet DRAFT - draft-liu-v6ops-running-multiple-prefixes
draft-liu-v6ops-running-multiple-prefixes
V6OPS B. Liu
Internet-Draft S. Jiang
Intended status: Informational Y. Bo
Expires: September 26, 2015 Huawei Technologies
March 25, 2015
Multiple IPv6 Prefixes: Background and Considerations
draft-liu-v6ops-running-multiple-prefixes-03
Abstract
This document describes several typical multiple prefixes use cases,
and discusses that running multiple IPv6 prefixes/addresses in one
network/host should be common proactice that administrators need to
adapt.
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 September 26, 2015.
Copyright Notice
Copyright (c) 2015 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.
Liu, et al. Expires September 26, 2015 [Page 1]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Multiple Prefixes Use cases . . . . . . . . . . . . . . . . . 3
2.1. Multiple Prefixes with Different Scopes . . . . . . . . . 3
2.2. Multihoming based on Multiple PA Prefixes . . . . . . . . 3
2.3. Multiple Prefix Co-existing during Network Renumbering . 4
2.4. Service Prefixes . . . . . . . . . . . . . . . . . . . . 4
3. Operational Availability and Considerations . . . . . . . . . 4
3.1. Multiple prefix provisioning . . . . . . . . . . . . . . 4
3.2. Address Selection . . . . . . . . . . . . . . . . . . . . 5
3.3. Exit-router selection . . . . . . . . . . . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
In IPv6 networks, there are deployment scenarios in which multiple
prefixes coexists simultaneously in one network. Several typical use
cases are:
- Multiple Prefixes with Different Scopes (described in Section 2.1)
- IPv6 multihoming based on multiple PA prefixes (described in
Section 2.2)
- Make-before-break renumbeirng (described in Section 2.3)
- An IPv6 network with multiple services, each of which has a
distinct prefix (described in Section 2.4) .
To support the multiple prefixes running mode, there have been some
technologies developed. This document discusses these technologies
of different aspects, which could allow and smoothen the multiple
prefiex operation.
Note that, although MIF (Multiple InterFaces) [RFC6418] architecture
also involves mutliple IPv6 prefixes, it mainly targets different
interfaces which attach to different networks respectively. This
document discusses the multiple IPv6 prefixes running in the same
network.
Liu, et al. Expires September 26, 2015 [Page 2]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
2. Multiple Prefixes Use cases
2.1. Multiple Prefixes with Different Scopes
IPv6 contains link-local addresses, global addresses and unique local
addresses, which by definition are global but normally are site-scope
by practice.
As specified in [RFC4291], all interfaces are required to have at
least one Link-Local unicast address. This is the basic case of
running multiple prefixes. However, this does not require operations
from the network administrators since it is automatically processed.
Besides Link-Local addresses, the Unique Local Addresses (ULAs,
[RFC4193]) might also be used for the interal communication within a
site network. In many deployment, the ULA is used along with PA
(Provider Aggregated) addresses, which connect to the public network.
The benefit of such combination is to provide seperate local
communication from the globally communication so that the local
communication would not be impacted when ISP uplink fail or
prefix(es) be renumbered. It is especially benificial for the home
network and private OAM plane or internal-only nodes in an
enterprise.
2.2. Multihoming based on Multiple PA Prefixes
When a network is multihomed, the multiple upstream network providers
would assign prefixes respectively. If a network does not acquires a
PI (Provider Independent) address spaceu, multihoming will result
coexistent multiple PA prefixes. In such network, a single host have
multiple PA IPv6 addresses that assoicated with different prefixes.
This scenario rarely exists in IPv4 networks, since IPv4 only allows
single address per interface. But it is quite practical in IPv6.
This new feature of IPv6 allows the SMEs (Small/Medium Enterprises)
to multihome without the burden of running PI address space or
running IPv6 NAT. Furthermore, multiple PA spaces do not have the
potential global routing system scalable issue as the PI does
[RFC4894].
However, multihoming with multiple PA prefixes has some operational
issues which mainly include address selection, next-hop selection,
and exit-router selection. For detailed discussion, please refer to
[RFC7157]. [Editor's note: more discussion to be filled.]
Liu, et al. Expires September 26, 2015 [Page 3]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
2.3. Multiple Prefix Co-existing during Network Renumbering
[RFC4192] describes a procedure that can be used to renumber a
network from one prefix to another smoothly through a "make-before-
break" transition. In the transition period, both the old and new
prefixes are available; the usage of multiple prefixes provides the
smooth transition and avoids the session outage issue in most of
renumbering operations.
2.4. Service Prefixes
An IPv6 network may simultaneously provide multiple services, such as
IPTV, Internet access, VPN, etc. Each of these services should have
a distinct prefix. The network may apply different policy based on
the distinguished prefixes. This deployment would simplify the
management and processing on network devices, such as forwarding
routers, access authentication devices, account devices, bourder
filter, etc. The ISPs would provide one subscriber multiple
addresses/prefixes to access different services. This deployment
would paricularly benefit for traffic recognision and management.
3. Operational Availability and Considerations
This section discusses some technologies of different aspects, which
could allow and smooth the multiple prefiex operation.
3.1. Multiple prefix provisioning
o Multiple Prefixes from Different Provisioning Domains
In [I-D.ietf-mif-mpvd-arch], provisioning domain is defined as
consistent set of network configuration information.
Classically, the entire set available on a single interface is
provided by a single source, such as network administrator, and
can therefore be treated as a single provisioning domain.
But in modern IPv6 networks, multihoming or service prefixes
may result in provisioning information from more than one
provisioning domains being presented on a single link. In
these scenarios, current technologies lack support of
distinguishing information from multiple provisioning domains,
thus the host would not be able to associate configuration
information with provisioning domains.
However, there are several techniques under developing in MIF
WG to solve the problems, we could expect them to be
standardized in the near future.
Liu, et al. Expires September 26, 2015 [Page 4]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
o Co-existing DHCPv6/SLAAC
Both SLAAC [RFC4862] and DHCPv6-PD [RFC3633] could assign IPv6
prefixes. DHCPv6-PD is normally run between routers and
routers or routers and DHCPv6 [RFC3315] servers; while SLAAC is
normally run between routers and downstream hosts. The two
protocols could collabarate sufficiently to cover the whole
network's prefix provisioning.
If operate properly, SLAAC and DHCPv6 could also co-exist for
IPv6 addresses provisioning based on different prefixes. They
need to carefully deal with the interaction between the two
protocols. It is mostly regarding to the M flag in Neighbor
Discovery [RFC4861] messages.
3.2. Address Selection
In order to support multiple addresses well, IPv6 introduced address
selection mechanism which utilize a address selection policy table to
calculate a proper source address for a given destination address.
Of cource, destination adresses selection is also defined. [RFC6724]
described the rationale and algorithms in detail, and also defines a
default address selection policy table for operating systems.
Note that, the [RFC6724] is a replacement of the old [RFC3484]
specification to improve some behaviors (e.g. to prefer IPv4 over
ULA for outside connectivity). Currently, so far there haven't been
many operating systems supporting the new standard, but we could
expect that the new standard would be available in all new released
operating systems and becomes the mainstream in the near future.
3.3. Exit-router selection
In multiple PA multihoming networks, if the ISPs enable ingress
filtering at the edge (BCP38, [RFC2827]), then there comes the exit
router selection issues that outgoing packets are routed to the
appropriate border router and ISP link. Normally, a packet sourced
from an address assigned by ISP X should not be sent via ISP Y,
otherwise it would be filtered by ISP Y.
In the past, the administrators have to either communicate with the
ISP for not filtering the prefixes or manually configure routing
policies within the network to make sure the traffics are forwarded
to the right upstream link, based on source prefixes. Now, there are
some source-based routing technologies under development and
standardization. We could expect these solutions available soon.
Liu, et al. Expires September 26, 2015 [Page 5]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
4. Security Considerations
This document does not introduce any new mechanisms or protocols
technologies and as such does not introduce any new security threads.
Nevertheless, relevant important security considerations are worth to
be iterated here:
o [RFC7157] gives the security considerations for multi-prefix based
multihoming.
o Address selection relevant security considerations are described
in [RFC6724].
o ND cache exhausion caused by multiple addresses per host in a big
L2 network is described in Section 3.2. It is possibility that
malicious users intentionally configure massive addresses on host
to make the gateway ND cache exhausted. So administrators always
need to consider mitigation operations for potential ND cache DoS
attack which is documented as [RFC6583].
5. IANA Considerations
This draft does not request any IANA action.
6. Acknowledgements
Valuable inputs of the texts/ideas were from Ole Troan.
Useful comments were received from Brian Carpenter, Victor Kuarsingh,
Lorenzo Colliti, Mikael Abrahamsson, Fred Baker, Lee Howard and
Roberta Maglione.
This document was produced using the xml2rfc tool [RFC2629].
(initiallly prepared using 2-Word-v2.0.template.dot. )
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Liu, et al. Expires September 26, 2015 [Page 6]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic
Host Configuration Protocol (DHCP) version 6", RFC 3633,
December 2003.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
7.2. Informative References
[I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-11 (work in progress), March
2015.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4894] Hoffman, P., "Use of Hash Algorithms in Internet Key
Exchange (IKE) and IPsec", RFC 4894, May 2007.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418,
November 2011.
[RFC6583] Gashinsky, I., Jaeggli, J., and W. Kumari, "Operational
Neighbor Discovery Problems", RFC 6583, March 2012.
Liu, et al. Expires September 26, 2015 [Page 7]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes March 2015
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise
Network Renumbering Scenarios, Considerations, and
Methods", RFC 6879, February 2013.
[RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation", RFC 7157, March 2014.
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
Bo Yang
Huawei Technologies
Q21, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: boyang.bo@huawei.com
Liu, et al. Expires September 26, 2015 [Page 8]
