V6OPS B. Liu
Internet-Draft S. Jiang
Intended status: Informational Y. Bo
Expires: April 14, 2015 Huawei Technologies
October 11, 2014
Considerations for Running Multiple IPv6 Prefixes
draft-liu-v6ops-running-multiple-prefixes-02
Abstract
This document describes several typical multiple prefixes use cases.
Then analyzes potential operational issues and provides operational
considerations of running multiple prefixes.
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 April 14, 2015.
Copyright Notice
Copyright (c) 2014 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 April 14, 2015 [Page 1]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
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 Considerations . . . . . . . . . . . . . . . . . 4
3.1. Multiple prefix provisioning . . . . . . . . . . . . . . 4
3.2. Consideration for Managing Address Selection in the
Network . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.3. Exit-router selection . . . . . . . . . . . . . . . . . . 7
3.4. Miscellaneous Considerations . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
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) .
IPv6 standards support multiple addresses on a single interface.
[RFC6724] defines a default address selection policy among multiple
addresses on host. This feature is one of most important
improvements comparing to IPv4. It is also a key supporting factor
to allow a network running multiple prefixes.
In practice, running multiple prefixes in one network introduces
operational complexity and there are a few well-known issues in the
deployment and network operations. While standardization works to
solve these issues are out of scope of this document, network
Liu, et al. Expires April 14, 2015 [Page 2]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
administrators should be aware of these operational issues, and also
need some guidance/considerations to avoid them. This document
provides such operational considerations for site network
administrators. Administrators of ISP networks might also benifit
from this document ,but they are NOT the intended target audience.
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.
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. For details of using ULAs, please refer to
[I-D.ietf-v6ops-ula-usage-recommendations].
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 space or deploys IPv6 NAT,
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.
Liu, et al. Expires April 14, 2015 [Page 3]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
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 [RFC7157]. Especially for the exit-router
selection, currently there is no standardized solution yet. (More
details Section 3.3.)
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 Considerations
This section gives operational considerations for network
administrators for running multiple prefix in their networks.
3.1. Multiple prefix provisioning
o Avoiding Information from Multiple Provisioning Domains on the
Same Link
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.
Liu, et al. Expires April 14, 2015 [Page 4]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
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. Solutions
[I-D.ietf-mif-mpvd-dhcp-support]
[I-D.ietf-mif-mpvd-ndp-support] [I-D.ietf-mif-mpvd-id] have
been proposed to address it.
Since the technology is still under development and would not
be widely supported for a while, the network administrators are
recommended to avoid providing information from multiple
provisioning domains on the same link for current deployment.
o Considerations for Co-existing DHCPv6/SLAAC
If administrators enable both DHCPv6 [RFC3315] and SLAAC
[RFC4862] for address configuration in one network, then 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. The main operational problems of
DHCPv6/SLAAC co-existing might happen are:
- When the hosts are already configured by SLAAC and the
administrators want to add another address (the added
address is probably based on another prefix) by DHCPv6, the
operation might fail on certain hosts. This is because some
operating systems would ignore the M flag transitioning from
0 to 1, since the relevant behavior is ambiguious in the
standard.
Thus, if the administrators need to config different
addresses on the hosts through DHCPv6 and SLAAC
respectively, it needs to be done at the initial stage, that
is to make sure the M flag in the RA messages is set at the
begining so that the hosts could configure SLAAC and DHCPv6
simultaneously.
- According to [RFC6879] a renumbering exercise might cause
hosts to switch from one autoconfiguration mechanism to
another (e.g., DHCPv6 to SLAAC). Currently, certain
opertating systems immediately release the DHCPv6 address
when M flag is off. If the prefix is also changed along
with the mechanism switching, a flash network renumbering
would happen, which against the general "make-before-break"
approach recommended in [RFC4192].
Liu, et al. Expires April 14, 2015 [Page 5]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
To avoid this kind of flash renumbering, it is recommendated
for the administrators to turn on A flag first to make the
hosts all configure SLAAC and then turn the M flag off.
The dedicated problem statement document
[I-D.ietf-v6ops-dhcpv6-slaac-problem] provides more detailed
and comprehensive analysis and considerations. Another
document [I-D.liu-v6ops-dhcpv6-slaac-guidance] provides
operational guidance to avoid such issue.
3.2. Consideration for Managing Address Selection in the Network
In practice, administrators need to concern the following issues.
o Inconsistent Behavior in Old and New Address Selection Standards
reported various potential problems with address selection in
deployment. To address these problems, the updated standard
[RFC6724] was developed.
Old hosts using [RFC3484] might co-exist with hosts using
[RFC6724]. Thus inconsistent behavior would happen. In theory,
all the problems described in [RFC5220] might happen in the
[RFC3484] hosts. This memo specifically documents following
problem which was reported from real expierence.
* ULA+IPv4 address selection
This is a special case described in section 2.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 an obvious
choice. Each employee host will have both an global or private
IPv4 address and a ULA. When the ULAs are for local IPv6
communication, there is no problem; however, when a host tries
to connect to an outside dual-stack node that has registered
both A and AAAA records in the DNS, the host will choose the
IPv6 address in the AAAA record as the destination address and
choose the ULA for the source address according to the IPv6
preference of the default address selection policy defined in
[RFC3484]. This will certainly result in a connection failure.
[RFC6724] has added ULA specific rules to prefer IPv4 over ULA,
but there might be hosts still under the old [RFC3484]
specification.
Liu, et al. Expires April 14, 2015 [Page 6]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
Considering [RFC6724] was just published in late 2012, it is very
possible that it has not been supported by a large portion of
currently under-using operating systems. (The authors did a brief
investigation: Windows 8/8.1 and Windows Server 2012/R2 had
implemented [RFC6724]; Windows 7 and Windows Server 2008 R2 with the
IPv6 readiness update [http://support.microsoft.com/kb/2750841/en-us]
also support [RFC6724]; have not found any clear statements of other
operating systems whether [RFC6724] is supported or not.) Thus,
using ULAs as IPv6 local communication in an network which has not
had global IPv6 connectivity yet might not be a good approach for
current deployment.
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.
Hence, 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.
3.4. Miscellaneous Considerations
In the network side, the administrators also need to notice the
following potential issues.
o Support Multiple-address Management from Network Management Tools
It is possible that multiple addresses on a single interface
mapping is not well supported on all network management tools
(especially the legacy tools). So, the administrators need to
check the capablilities of tools before utilizing them, and make
sure they support multiple-address management.
o ND Cache Shortage in Big L2 Networks
In some scenarios, such as campus networks and enterprise
networks, the "big L2 network" architecture is often used to
reduce the cost and configuration burden. In a big L2 network, a
large amount of hosts (e.g. 10K users) are aggregated to the core
at layer 2.
Liu, et al. Expires April 14, 2015 [Page 7]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
The top-level core switch needs to record the MAC and IP addresses
of all the hosts in the aggregation domain as entries in the ARP/
ND table, so that incoming packets toward the hosts could be
forwarded directly by the line cards in a line speed. When the
ARP/ND table is full, normally the network would not allow new
hosts to access; otherwise, the switch needs to instantly look up
the destination through ARP/ND broadcast/multicast, thus the CPU
needs to be involved in this processing. CPU-involved forwarding
would significantly reduce the performance of the switch, and
packet loss might happen.
According to current state of the art, there are normally 16K or
less entries in a switch (the high-end ones could reach to 64K or
even higher, per line card). Each IPv4 node normally has only one
IPv4 address, so each IPv4 node only ocuppies one IPv4-MAC mapping
entry in the cache. It is obvious that the table space is enough
for IPv4 network most of the time. However, an IPv6 node would
normally have 3 or more IPv6 addresses (e.g. an IPv6-enabled
Window 7 host would have at least one link-local IPv6 address, one
permanent global IPv6 address and one temporary global IPv6
address when it connects to an IPv6 network.), and each IPv6-MAC
mapping entry would requires two to four times the space than
IPv4. As the result, a dual-stack node might cost (3 or
more)*(2-4) +1 times table space than an IPv4 node, thus the table
space shortage is likely to happen in a dual-stack big L2 network.
Thus, an L3 core switch which can sufficiently serve an IPv4 big
L2 network might not be able to serve an IPv6 big L2 network in an
equal scale. So, when designing an IPv6 L2 network, the
administratros need to make sure the core L3 switch has enough ND
cache. Higer end L3 core switch might be needed, which means
higher budget. Or the administrators may have to break the
network into several smaller L2 networks.
4. Security Considerations
This document is a collection of operational considerations for
current technical aspects. It 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.
Liu, et al. Expires April 14, 2015 [Page 8]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
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
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[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.
[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
Liu, et al. Expires April 14, 2015 [Page 9]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
[I-D.ietf-mif-mpvd-arch]
Anipko, D., "Multiple Provisioning Domain Architecture",
draft-ietf-mif-mpvd-arch-07 (work in progress), October
2014.
[I-D.ietf-mif-mpvd-dhcp-support]
Krishnan, S., Korhonen, J., and S. Bhandari, "Support for
multiple provisioning domains in DHCPv6", draft-ietf-mif-
mpvd-dhcp-support-00 (work in progress), August 2014.
[I-D.ietf-mif-mpvd-id]
Krishnan, S., Korhonen, J., Bhandari, S., and S.
Gundavelli, "Identification of provisioning domains",
draft-ietf-mif-mpvd-id-00 (work in progress), August 2014.
[I-D.ietf-mif-mpvd-ndp-support]
Korhonen, J., Krishnan, S., and S. Gundavelli, "Support
for multiple provisioning domains in IPv6 Neighbor
Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-00
(work in progress), August 2014.
[I-D.ietf-v6ops-dhcpv6-slaac-problem]
Liu, B., Bonica, R., Gong, X., and W. Wang, "DHCPv6/SLAAC
Address Configuration Interaction Problem Statement",
draft-ietf-v6ops-dhcpv6-slaac-problem-01 (work in
progress), June 2014.
[I-D.ietf-v6ops-ula-usage-recommendations]
Liu, B. and S. Jiang, "Considerations of Using Unique
Local Addresses", draft-ietf-v6ops-ula-usage-
recommendations-03 (work in progress), July 2014.
[I-D.liu-v6ops-dhcpv6-slaac-guidance]
Liu, B., Bonica, R., and T. Yang, "DHCPv6/SLAAC Address
Configuration Interaction Problem Statement", draft-liu-
v6ops-dhcpv6-slaac-guidance-02 (work in progress), July
2014.
[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.
Liu, et al. Expires April 14, 2015 [Page 10]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
[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.
[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.
[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.
[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
Liu, et al. Expires April 14, 2015 [Page 11]
Internet-Draft draft-liu-v6ops-running-multiple-prefixes October 2014
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 April 14, 2015 [Page 12]