Internet DRAFT - draft-liu-running-multiple-prefixes
draft-liu-running-multiple-prefixes
Network Working Group B. Liu
Internet Draft S. Jiang
Intended status: Informational Huawei Technologies Co., Ltd
Expires: April 24, 2014 October 21, 2013
Running Multiple IPv6 Prefixes
draft-liu-running-multiple-prefixes-01.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 April 24, 2014.
Copyright Notice
Copyright (c) 2012 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 & Jiang Expires April 24, 2014 [Page 1]
Internet-Draft Running Multiple Prefixes October 2013
Abstract
This document introduces that multiple prefixes in one network/host
might be common in IPv6, and describes several multiple prefixes use
cases that might be beneficial to the network. Then some operational
considerations and current gaps to support multiple prefixes
operations are described.
Table of Contents
1. Introduction ................................................. 3
2. Multiple Prefixes Use cases .................................. 3
2.1. Multihoming ............................................. 3
2.2. ULA+PA .................................................. 4
2.3. Make-before-break renumbering ........................... 4
2.4. Semantic Prefixes ....................................... 4
3. Basic operational considerations ............................. 5
3.1. Multiple prefix provisioning ............................ 5
3.2. Multiple addresses in one interface ..................... 5
3.3. Address selection ....................................... 5
3.4. DNS relevant ............................................ 6
4. Current Gaps ................................................. 6
5. Security Considerations ...................................... 7
6. IANA Considerations .......................................... 7
7. Acknowledgments .............................................. 7
8. References ................................................... 7
8.1. Normative References .................................... 7
8.2. Informative References .................................. 7
Liu & Jiang Expires April 24, 2014 [Page 2]
Internet-Draft Running Multiple Prefixes October 2013
1. Introduction
IP protocols have been widely spread. More and more services are
relying on IP technology. As the evolution of network application,
the IP network architecture/functions are becoming more and more
sophisticated.
One aspect is the requirement of multiple prefixes. There are several
motivations as the following:
- Multiple network provisioning, including multihoming and semantic
prefixes (as described in section 2.4) etc;
- Multiple logic planes, VPN/OAM .etc.
In IPv6, multiple prefixes feature is naturally well-supported.
Standard IPv6 stack supports multiple-address-per-interface as
default; there is a standard address selection algorithms [RFC6724]
defined for multiple prefixes purpose. It is one of the most
important difference and also an advantage comparing IPv4.
This document introduces several multiple prefixes use cases in IPv6
that might be beneficial to the network use. And some operational
considerations are given, as while as some current gaps for
supporting running multiple prefixes.
2. Multiple Prefixes Use cases
2.1. Multihoming
When a network is multihomed, the multiple upstream networks would
assign prefixes respectively. If a network for some reason neither
acquire a PI (Provider Independent) space nor deploys IPv6 NAT, then
the multihoming would resulting in hosts with multiple PA (Provider
Aggregated) IPv6 addresses with different prefixes.
This approach in IPv4 has rarely been used, since the IPv4 doesn't
support multiple addresses/prefixes well. But it is quite practical
in IPv6. This approach allows the SMEs to do multihoming without
burden from running PI address space or running IPv6 NAT. Furthermore,
multiple PA spaces don't have the potential global routing system
scalable issue as the PI does [RFC4894].
However, multihoming with multiple PA spaces has some operational
issues which mainly include address selection, next-hop selection,
Liu & Jiang Expires April 24, 2014 [Page 3]
Internet-Draft Running Multiple Prefixes October 2013
and exit-router selection. Especially for the exit-router selection,
it seems there has not been any practical solution yet.
2.2. ULA+PA
Unique Local Addresses (ULAs) are defined in [RFC4193] as provider-
independent prefixes. Since there is a 40 bits pseudo random field in
the ULA prefix, there is no practical risk of collision (please refer
to section 3.2.3 in [RFC4193] for more detail).
For either home networks or enterprise networks, the main purpose of
using ULA along with GUA is to provide a logically local routing
plane separated from the globally routing plane. The benefit is to
ensure stable and specific local communication regardless of the ISP
uplink failure or change. This benefit is especially meaningful for
the home network or private OAM function in an enterprise.
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 whole
network because of changing ISPs, ISPs restructure their address
allocations, or whatever reasons. In these situations, ULA is an
effective tool for the internal-only nodes.
2.3. Make-before-break 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,
it is a very good use of multiple prefixes that could avoid the
session outage issue in most of the situations when renumbering a
network.
2.4. Semantic Prefixes
[I-D.jiang-semantic-prefix] describes a framework to embed some
parameters into the IPv6 prefix segment. The parameters might contain
user types, service types, applications, security requirements,
traffic identity types, quality requirements and other criteria may
also be relevant parameters which a network operator may wish to use
to treat packets differently and efficiently.
With this approach, for example, the ISPs could provision one
subscriber multiple addresses/prefixes to access different services.
Liu & Jiang Expires April 24, 2014 [Page 4]
Internet-Draft Running Multiple Prefixes October 2013
3. Basic operational considerations
There might be some argument/worry that in practice running multiple
prefixes would makes terrible operational complexity. It is
apprehensible that most of the administrators are not be accustomed
to this model, since it is quite different with that in IPv4.
But considering running multiple prefixes in IPv6 might be very
common, administrators need to adapt this new operational model
regardless of personal prefer.
Following sub-sections summarize several important operational
considerations that try to eliminate the FUD of the administrators.
3.1. Multiple prefix provisioning
- Multiple provisioning domains: considering current DHCP
architecture does not fit multiple provisioning domains well, the
administrators should avoid that multiple provisioning domain all
directly configuring the host through DHCP, since it might cause
confusion for the host.
- Multiple provisioning mechanisms: if administrators applied
DHCP/SLAAC co-exist in one network, and then they need to learn that
there might be some issues, which are reported in [I-D.liu-bonica-
dhcpv6-slaac-problems].
3.2. Multiple addresses in one interface
- Current implementations support this feature very well; normally
this wouldn't be a problem
- But current IPAM/NMS applications might have not ready for this
multiple mappings management
3.3. Address selection
This is probably the most error prone problematic issue in running
multiple prefixes.
[RFC5220] reported various potential problems with address selection
in deployment. Some of them have been handled in the updated standard
address selection mechanism [RFC6724].
Liu & Jiang Expires April 24, 2014 [Page 5]
Internet-Draft Running Multiple Prefixes October 2013
3.4. DNS relevant
Normally, one SP only allows only its users to look at DNS records of
the service. So in multiple network provisioning scenarios, each DNS
query from a host must be forwarded to a suitable DNS server. Hosts
normally are not able to select a DNS server for each DNS query
target.
[RFC6731] is developed for this purpose; it defined DHCPv4/v6 options
to deliver the DNS selection policies for hosts.
4. Current Gaps
o Not all IPAM/NMS tools are able to handle one interface and
multiple addresses mappings.
o ULA+IPv4 selection
There is a special case that needs to be noticed, which is 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 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 address selection
policy [RFC3484]. This will clearly result in a connection failure.
Although the new address selection standard [RFC6724] has added ULA
specific rules to prefer IPv4 over ULA, but the majority of current
existing hosts might still under the old [RFC3484] specification.
o Multiple PA exit-router selection
In multiple PA multihoming networks, if the ISPs enable ingress
filtering at the edge, then the administrators need to deal with the
the exit router selection issues. Currently there is no well-used
solution, so the administrator might need to communicate with the ISP
for not filtering the prefixes.
If a site has multiple PA prefixes, complexities in routing
configuration will appear. In particular, source-based routing rules
might be needed to ensure 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, to
Liu & Jiang Expires April 24, 2014 [Page 6]
Internet-Draft Running Multiple Prefixes October 2013
avoid ingress filtering by Y [RFC2827] [RFC3704]. Additional
considerations may be found in [MULTIHOMING-WITHOUT-NAT].
5. Security Considerations
TBD.
6. IANA Considerations
This draft does not request any IANA actions.
7. Acknowledgments
Useful comments were received from Victor Kuarsingh and Roberta
Maglione.
This document was prepared using 2-Word-v2.0.template.dot.
8. References
8.1. Normative References
[RFC3315] R. Droms, 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.
8.2. Informative References
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing", RFC 4984,
September 2007.
Liu & Jiang Expires April 24, 2014 [Page 7]
Internet-Draft Running Multiple Prefixes October 2013
[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.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved Recursive
DNS Server Selection for Multi-Interfaced Nodes", RFC 6731,
December 2012.
[I-D.ietf-6man-addr-select-opt]
Matsumoto, A.M., Fujisaki T.F., and T. Chown, "Distributing
Address Selection Policy using DHCPv6", Working in Progress,
April 2013.
[I-D.liu-bonica-dhcpv6-slaac-problem]
Liu, B., and R. Bonica, "DHCPv6/SLAAC Address Configuration
Interaction Problem Statement", Working in Progress,
February 2013.
Liu & Jiang Expires April 24, 2014 [Page 8]
Internet-Draft Running Multiple Prefixes October 2013
Authors' Addresses
Bing Liu
Huawei Technologies Co., Ltd
Q14, Huawei Campus
No.156 Beiqing Rd.
Hai-Dian District, Beijing 100095
P.R. China
Email: leo.liubing@huawei.com
Sheng Jiang
Huawei Technologies Co., Ltd
Huawei Q14 Building, No.156 Beiqing Rd.,
Zhong-Guan-Cun Environmental Protection Park, Beijing
P.R. China
EMail: jiangsheng@huawei.com
