Mapping of Address and Port (MAP) - Deployment Considerations
draft-mdt-softwire-map-deployment-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Qiong Sun , Maoke Chen , Gang Chen , Chunfa Sun , Tina Tsou (Ting ZOU) | ||
| Last updated | 2012-03-05 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-mdt-softwire-map-deployment-00
Network Working Group Q. Sun
Internet-Draft China Telecom
Intended status: Informational M. Chen
Expires: September 6, 2012 FreeBit
G. Chen
China Mobile
C. Sun
Softbank BB
T. Tsou
S. Simon
Huawei Technologies
March 5, 2012
Mapping of Address and Port (MAP) - Deployment Considerations
draft-mdt-softwire-map-deployment-00
Abstract
This document describes when and how an operator uses the technique
of Mapping of Address and Port (MAP) for the IPv4 residual deployment
in the IPv6-dominant domain.
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 6, 2012.
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
Sun, et al. Expires September 6, 2012 [Page 1]
Internet-Draft MAP Deployment March 2012
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Fixed networks . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Mobile networks . . . . . . . . . . . . . . . . . . . . . 6
4. Deployment Consideration . . . . . . . . . . . . . . . . . . . 8
4.1. Building the MAP domain . . . . . . . . . . . . . . . . . 8
4.1.1. MAP deployment model planning . . . . . . . . . . . . 8
4.1.2. MAP domain planning . . . . . . . . . . . . . . . . . 8
4.1.3. MAP rule provisioning . . . . . . . . . . . . . . . . 9
4.1.4. MAP DHCPv6 server deployment consideration . . . . . . 10
4.1.5. PSID consideration . . . . . . . . . . . . . . . . . . 11
4.1.6. Addressing and routing . . . . . . . . . . . . . . . . 12
4.1.7. Translation vs. Encapsulation . . . . . . . . . . . . 12
4.2. BR settings . . . . . . . . . . . . . . . . . . . . . . . 13
4.3. CE settings . . . . . . . . . . . . . . . . . . . . . . . 16
4.4. Supporting system . . . . . . . . . . . . . . . . . . . . 17
5. MAP Address Planning, a Step-by-step Guide . . . . . . . . . . 18
6. Migration Methodology . . . . . . . . . . . . . . . . . . . . 21
6.1. Roadmap for MAP-based Solution . . . . . . . . . . . . . . 21
6.1.1. Start from Scratch . . . . . . . . . . . . . . . . . . 21
6.1.2. Coexiting Phases . . . . . . . . . . . . . . . . . . . 21
6.1.3. Exit Strategy . . . . . . . . . . . . . . . . . . . . 22
6.2. Migration Mode . . . . . . . . . . . . . . . . . . . . . . 22
6.2.1. Passive Transition . . . . . . . . . . . . . . . . . . 22
6.2.2. Active Transition . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25
9. Additional Author List . . . . . . . . . . . . . . . . . . . . 26
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative References . . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30
Sun, et al. Expires September 6, 2012 [Page 2]
Internet-Draft MAP Deployment March 2012
1. Introduction
IPv4 address exhaustion has become world-wide reality and the primary
solution in the industry is to deploy IPv6-only networking.
Meanwhile, having access to legacy IPv4 contents and services is a
long-term requirement, will be so until the completion of the IPv6
transition. It demands sharing residual IPv4 address pools for IPv4
communications across the IPv6-only domain(s).
Mapping of Address and Port (MAP)
[I-D.mdt-softwire-mapping-address-and-port] is designed in response
to the requirement of stateless residual deployment. The term
"residual deployment" refers to utilizing not-yet-assigned or
recalled IPv4 addresses for IPv4 communications going across the IPv6
domain backbone. MAP assumes the IPv6-only backbone as the
prerequisite of deployment so that native IPv6 services and
applications are fully supported and encouraged. The statelessness
of MAP ensures only moderate overhead is added to part of the network
devices.
Residual deployment with MAP is new to most operators. This document
is motivated to provide basic understanding on the usage of MAP,
i.e., when and how an operator can do with MAP to meet its own
operational requirements of IPv6 transition and its facility
conditions, in the phase of IPv4 residual deployment. Potential
readers of this document are those who want to know:
1. What are the requirements of MAP deployment ?
2. What technical options needs to be considered when deploying MAP,
and how?
3. How does MAP impact on the address planning for both IPv6 and
IPv4 pools?
4. How does MAP impact on daily network operations and
administrations?
5. How do we migrate to IPv6-only network with the help of MAP?
Terminology of this document, unless it is intentionally specified,
follows the definitions and abbreviations of
[I-D.mdt-softwire-mapping-address-and-port]. (> co-authors: we may
change this if later we find any new terms need to be added.)
Sun, et al. Expires September 6, 2012 [Page 3]
Internet-Draft MAP Deployment March 2012
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Sun, et al. Expires September 6, 2012 [Page 4]
Internet-Draft MAP Deployment March 2012
3. Case Studies
MAP is suitable for deployment either in large-scale carrier (fixed)
networks or in mobile networks. They have similar but different
requirements.
3.1. Fixed networks
There are typically two network models for fixed broadband access
service: one is to use PPPoE/PPPoA authentication method while the
other is to use IPoE. The first one is usually applied to
Residential network and SOHO networks. Subscribers in CPNs can
access broadband network by PPP dial-up authentication. BRAS is the
key network element which takes full responsibility of IP address
assignment, user authentication, traffic aggregation, PPP session
termination, etc. Then IP traffic is forwarded to Core Routers
through Metro Area Network, and finally transited to Internet via
Backbone network. The second network scenario is usually applied to
large enterprise networks. Subscribers in CPNs can access broadband
network by IPoE authentication. IP address is normally assigned by
DHCP server, or static configuration.
In either case, a CPE could obtain a prefix via prefix delegation
procedure, and the hosts behind CPE would get its own IPv6 addresses
within the prefix through SLAAC or DHCPv6 statefully. A MAP CE would
also obtain a set of MAP rules from DHCPv6 server. In MAP solution,
both encapsulation and double translation can be applied.
Figure 1 depicts a generic model of stateless IPv4-over-IPv6
communication for fixed broadband access services.
Sun, et al. Expires September 6, 2012 [Page 5]
Internet-Draft MAP Deployment March 2012
+------------------------------+
| MAP Domain |
+---+---------------+--------------|
+--------+ + | |
| | +---------+ +--+--+ |
| Host |--| CPE | | | |
| | |(MAP CE) |======| BNG | ======+---------+ +-----------+
+--------+ +---------+ +--|--+ | | | IPv4 |
+--------+ +---------------+ |Core |---| Internet |
| | +---|-----+ +--+--+ |Router | | |
| Host |--| CPE |======| | ======+---------+ +-----------+
| | |(MAP CE) | | BNG | |
+--------+ +---------+ +--+--+ |
+ | |
+-------------------+--------------+
Figure 1: Stateless IPv4-over-IPv6 access in fixed networks
3.2. Mobile networks
Regarding the MAP based solution, double translation is more suitable
in mobile environment according to the analysis in stateless
4V6[I-D.dec-stateless-4v6]. Figure 2 depicts a typical model of MAP
deployment in mobile network, where UE plays the rule of MAP CE.
There may be three possible cases: IPv4 only, IPv6 only or IPv6 and
IPv4 connection to IP devices, depicted as H1, H2 and H3,
respectively. The MAP CE may implement a internal NAT44 to provide
IPv4 connectin for multiple IP devices. The IP devices get /64
prefix from MAP CE through RS/RA. Such a /64 prefix is generated
from the prefix assigned by the network through prefix delegation.
In the process, IPv6 prefix delegation is asked to derive the shared
IPv4 address implicitly.
Prefix delegation is introduced in 3GPP network in Release 10. A MAP
CE obtains IPv6 prefix from the mobile network. It then initiates
DHCPv6 for prefix delegation. There are two phases for a MAP CE to
perform prefix delegation function. In the first phase, the MAP CE
attaches to the LTE network. The network provides the UE with IPv6
only connection and the UE obtains a /64 IPv6 prefix. In the second
phase, the MAP CE initiates prefix delegation procedure. The network
assigns a prefix shorter than 64 to the MAP CE. Figure 2 shows a
case where a /56 is assigned to MAP CE during prefix delegation.
Sun, et al. Expires September 6, 2012 [Page 6]
Internet-Draft MAP Deployment March 2012
+-------------+
|Private IPv4 |
| Network | H1
+-------------+
|
|
O-------------------O
| UE (MAP CE) |
| +-------+-------+ | |------------| |------------|
| | NAT44 | 4via6 | | | | | |
| | | /64 | |==| E-UTRAN |----| EPC |
| +-------+-------+ | |------------| |------------|
| | | |
| | /56 | |
O---------+-------+-O
| |
| H3 | H2
+-------------+ +----------+
| /64 IPv6 | | /64 IPv6 |
|&Private IPv4| +----------+
| Network |
+-------------+
Figure 2: MAP deployment in mobile network
Sun, et al. Expires September 6, 2012 [Page 7]
Internet-Draft MAP Deployment March 2012
4. Deployment Consideration
4.1. Building the MAP domain
When deploying stateless MAP in operational network, a provider
should firstly do MAP domain planning based on its own network
condition. According to the definition of
[I-D.mdt-softwire-mapping-address-and-port], a MAP domain is a set of
MAP CEs and BRs connected to the same virtual link. One MAP domain
shares a common BR and has the same set of BMRs, FMRs and DMR, and it
can be further divided into multiple sub-domains when multiple IPv4
subnets are deployed in one MAP domain. All CEs in the MAP domain
are provisioned with the same set of MAP rules by MAP DHCPv6 server
[I-D.mdt-softwire-map-dhcp-option]. There might be multiple BMRs in
one MAP domain, and CE would pick up its own BMR by longest prefix
matching lookup. However, all CEs within the sub-domain will have
the same BMR. in which the BMR of all CEs is the same. In hub and
spoke mode, CE would use DMR as its only FMR for outbound traffic;
while in mesh mode, a longest-matching prefix lookup is done in the
IPv4 routing table and the correct FMR is chosen.
Basically, operator should firstly determine its own deployment mode
for MAP domain: mesh or Hub and spoke, as different considerations
for different deployment models should be applied accordingly.
Afterwards, MAP domain planning, MAP rule provision, addressing and
routing, etc., for a MAP domain should be taken into consideration.
4.1.1. MAP deployment model planning
In order to do MAP domain planning, an operator should firstly make
the decision to choose Mesh or Hub and Spoke model according to
operator's network policy. In Hub and Spoke mode, all traffic within
the same MAP domain has to go through BR which will result in less
optimized traffic; however, it would simplify the CE process since
there is no need to do FMR lookup for each incoming packet. Besides,
it would have enhanced management ability as BR can take full control
of all the traffic. As a result, it is reasonable to deploy Hub and
Spoke mode for network with relatively flat architecture.
In mesh mode, traffic optimization can be achieved by CE to CE direct
path. It is recommended to apply mesh mode in case CE to CE traffic
is high and there are not too many MAP rules, say less than 10 MAP
rules, in the specific domain.
4.1.2. MAP domain planning
Stateless MAP has its own advantage in terms of scalability, high-
reliability, etc. As a result, it is reasonable to apply a larger
Sun, et al. Expires September 6, 2012 [Page 8]
Internet-Draft MAP Deployment March 2012
MAP domain to accommodate more subscribers with less BRs. Moreover,
a larger MAP domain would also be easier for management and
maintenance. However, a larger MAP domain may also result in less
optimized traffic in Hub and spoke case, where all traffic has to go
through a remote BR. Besides, it will also result in increased
number of MAP rules and highly centralized address management, etc.
It is a tradeoff to choose appropriate domain coverage.
Generally speaking, it is not recommended to use a large MAP domain
in Hub and spoke model. While in mesh model, it is suggested to
adopt a relatively larger MAP domain since traffic optimization has
already been guaranteed, and the only concern is to make sure that
the number of MAP rules is not too big.
Furthermore, MAP sub-domains can be divided for differentiated
service provision. Different sub-domains could be distinguished by
different Rule IPv4 prefixes. But all CEs within the same MAP sub-
domain would have the same Rule IPv4 prefix, Rule IPv6 prefix and
PSID parameters.
4.1.3. MAP rule provisioning
In stateless MAP, Mesh or Hub and Spoke communications can be
achieved among CEs in one MAP domain in terms of assigning
appropriate FMR(s) to CEs. We recommend ISP deploy the full Hub and
Spoke mode or full mesh mode describe below, because the DHCPv6
server can simply achieve them.
4.1.3.1. Full Hub and Spoke Communication among CEs
In order to achieve the full communication in the Hub and Spoke mode,
no FMR is assigned to CEs. In this mode, when a CE sends packets to
another CE in the same MAP domain using the DMR as FMR, the packets
must go though BR before arriving at the destination.
4.1.3.2. Full Mesh Communication among CEs
Assigning all BMRs in MAP domain to each CE as FMRs, Mesh
communications can be achieved among all CEs. In this case, when CE
receives an IPv4 packet, it looks up for an appropriate FMR with a
specific Rule IPv4 prefix which has the longest match with the IPv4
destination address. If the FMR is found (destination is one of the
CEs in the MAP domain), the packet will be forwarded to associated CE
directly without going though BR. If the FMR is not found
(destination is out of the MAP domain), the DMR will be selected as
FMR, the CE then forwards the packet to the associated BR.
Sun, et al. Expires September 6, 2012 [Page 9]
Internet-Draft MAP Deployment March 2012
4.1.3.3. Mesh or Hub/Spoke communication among some CEs
Mesh communications among some CEs along with Hub/Spoke
communications among some other CEs can be achieved by which
differentiated FMRs are assigned to CEs. For instance, as Figure 3
shown, Mapping rule 1, Mapping rule 2, Mapping rule 3 is provisioned
to CE1, CE2, CE3 respectively as BMR, and rule 1 and rule2, and rule
1 and rule 2 and rule 3, and rule 2 and rule 3 are assigned to CE1,
CE2, CE3 respectively, then CE1 and CE2, CE2 and CE3 communicate
directly without going though associated BR (Mesh mode), the
communication between CE1 and CE3 must go though BR before reaching
peer each other (Hub/Spoke mode).
+---------------+---------+---------+---------+
| | CE1 | CE2 | CE3 |
+---------------+---------+---------+---------+
| BMR | rule 1 | rule 2 | rule 3 |
+---------------+---------+---------+---------+
| | rule 1 | rule 1 | rule 2 |
| FMRs | rule 2 | rule 2 | rule 3 |
| | | rule 3 | |
+---------------+---------+---------+---------+
Figure 3: Mapping rules assigned to CEs in example
4.1.4. MAP DHCPv6 server deployment consideration
All the CEs within a MAP domain will get the same set of MAP rules by
DHCPv6 server, including BMR, FMRs and DMR. In one MAP domain, BMR
for different CEs might be different, but FMRs and DMR are all the
same. Each Mapping Rule keeps a record of Rule IPv6 prefix, Rule
IPv4 prefix, Rule EA-bits length and Rule Port Parameters. Section 5
would give a step by step example of how to calculate these
parameters.
In stateless MAP, the deployment of DHCPv6 server is independent with
MAP domain planning. So there are three possible ways:
4.1.4.1. MAP domain : DHCPv6 server = 1:1
This is the ideal solution that each MAP domain would have its own
MAP DHCPv6 server. In this case, MAP DHCPv6 server only needs to
configure parameters for the specific MAP domain. It is highly
recommended to adopt this deployment model in stateless MAP.
Sun, et al. Expires September 6, 2012 [Page 10]
Internet-Draft MAP Deployment March 2012
4.1.4.2. MAP domain : DHCPv6 server = 1:N
This might happen when DHCPv6 servers are deployed in a large MAP
domain in a distributed manner. In this case, all these DHCPv6
servers should be configured with the same set of MAP rules for the
MAP domain, including mutiple BMRs, FMRs and DMRs.
4.1.4.3. MAP domain : DHCPv6 server = N:1
This might happen when MAP domain is relatively small and a single
MAP DHCPv6 server is deployed in the network. In this case, multiple
MAP domains should be distinguished based on CE's IPv6 prefix in
different MAP domains.
Besides, the situation of remaining IPv4 address prefixes may have
big impact on MAP rule planning, especially for service operators who
only have rather scattered address space. Since the number of
scattered IPv4 address prefixes would be equal to the number of FMR
rules within a MAP domain, one should choose as large IPv4 address
pool as possible to reduce the number of FMR rules.
4.1.5. PSID consideration
For PSID provisioning, all the CEs, BR and DHCPv6 server within the
same MAP domain should be configured with the same parameter value.
All CEs with the same BMR should have the same PSID length. If a
provider would like to introduce differentiated address sharing
ratios for different CEs, it is better to define multiple MAP sub-
domains with different Rule IPv4 prefixes. In this way, MAP domain
division is only a logical method, rather than a geographical one.
The default PSID offset is chosen as 4 in
[I-D.mdt-softwire-mapping-address-and-port], which will exclude port
range of 0-4096. Operator may adjust the value based on actual
usage, policy, and service mode.
With regard to PSID format, both continuous and non-continuous port
set can be supported in GMA algorithm. Non-continuous port set has
the advantage of better security, UPnP friendly, etc., while
continuous port set is the simplest way to implement. Since PSID
format should be supported not only in CPEs, BRs and DHCPv6 server,
but also in other sustaining systems as well, e.g. traffic logging
system, user management system, a provider should make the decision
based on a comprehensive investigation on its demand and the reality
of existing equipments.
Note that some ISPs may need to offer services in a MAP domain with a
shared address, e.g. there are hosts FTP server under CEs. The
Sun, et al. Expires September 6, 2012 [Page 11]
Internet-Draft MAP Deployment March 2012
service provisioning may require well-know port range (i.e. port
range belong to 0-1023). MAP would provide operators with an option
to generate a port range including those in 0-1023. Afterwards,
operators could decide to assign it to any requesting user.
4.1.6. Addressing and routing
In MAP addressing, it should follow the MAP rule planning in the MAP
domain.
For IPv4 addressing, since the number of scattered IPv4 address
prefixes would be equal to the number of FMR rules within a MAP
domain, one should choose as large IPv4 address pool as possible to
reduce the number of FMR rules.For IPv6 address, the Rule IPv6
prefixes should be equal to the end user IPv6 prefix in MAP domain.
If ISP has a /24 rule IPv4 prefix with sharing ratio of 64 gives
16000 customers, and a /16 rule IPv4 prefix supports 4 million
customer. If up the sharing ratio to 256, 64000 and 16 million
customers can be supports respectively. For the ISP who have number
of scattered IPv4 address prefixes, in order to reduce the FMRs,
according to needs of ports they can divide different class. For
instance, for the enterprise customers class which need many ports to
use, provision them the BMR with low sharing ratio while for the
private customers class which don't need so many ports provision them
the BMR with high sharing ratio.
For MAP routing, there are no IPv4 routes exported to IPv6 networks.
4.1.7. Translation vs. Encapsulation
1. Option header
There may be some options in the IPv4 header, and some of them may
not be able to mapped to IPv6 option headers accurately
[RFC791][RFC2460]. If Translation is used, those options can not be
supported, and packets with those options SHOULD be dropped.
Encapsulation does not have this problem.
2. ICMP
Some IPv4 ICMP codes do not have a corresponding codes in ICMPv6, a
detailed analysis on the double translation behavior suggest that
some ICMPv4 messages, when they are translated to ICMPv6 and back to
ICMPv4 across the IPv6 domain, the accuracy might be sacrificed to
some extent. Encapsulation keeps the full transparency of ICMPv4
messages, while translation can make in-transition access through
either single or double translations with a unified solution.
Sun, et al. Expires September 6, 2012 [Page 12]
Internet-Draft MAP Deployment March 2012
In either the encapsulation or translation mode, if an intermediate
node generates an ICMPv6 error message, it should be converted into
ICMPv4 version and returned to the source with a special source
address set to 192.70.192.254 [I-D.xli-behave-icmp-address], in the
stateless MAP architecture.
3. PMTU and fragmentation
Both translation mode and encapsulation mode have PMTU and
fragmentation problem. [RFC6145] discusses the problem in details
for the translation, while [RFC2473] could be a good reference on the
issue in encapsulation.
4.2. BR settings
1. BR placement
BR placement has important impacts on the operation of a MAP domain.
A first concern should be the avoidance of "triangle routing". That
is, the path from the CE to an IPv4 peer via the BR should be close
to the one that would be taken if the CE had native IPv4
connectivity. This can be accomplished easily by placing the BR
close to the CE, such that the length of the path from the CE to the
BR is minimized.
However, minimizing the CE-BR path would ignore a second concern,
that of minimizing IPv4 operations. An ISP deploying MAP will
probably want to focus on IPv6 operations, while keeping IPv4
operational expenditures to a minimum. This would imply that the
size of the IPv4 network that the ISP has to administer would be kept
to a minimum. Placing the BR near the CE means that the length of
the IPv4 network between the BR and the IPv4 Internet would be
longer.
Moreover, in case where the set of CEs is geographically dispersed,
multiple BRs would be needed, which would further enlarge the IPv4
network that the ISP has to maintain.
Therefore, we offer the following guideline: BRs should be placed as
close to the border with the IPv4 Internet as possible while keeping
triangle routing to a minimum. Regional POPs should probably be
considered as potential candidates.
Note also that MAP being stateless, asymmetric routing is possible,
meaning that separate BRs can be used for traffic entering and
exiting a MAP domain. This option can be considered for its effects
on traffic engineering.
Sun, et al. Expires September 6, 2012 [Page 13]
Internet-Draft MAP Deployment March 2012
Anycast can be used to let the network pick BR closest to a CE for
traffic exiting the MAP domain. This is accomplished by provisioning
a Default Mapping Rule containing an anycast IPv6 address or prefix.
Operationally, this allows incremental deployment of BRs in strategic
locations without modifying the provisioning system's configuration.
CE's close to a newly-deployed BR will automatically start using it.
2. Reliability Considerations
Reliability of MAP is derived in major part from its statelessness.
This means that MAP can benefit from the usual methods of Internet
reliability.
Anycast, already mentioned in section 4.2.1, can be used to ensure
reliability of traffic from CE to BR. Since there can be only one
Default Mapping Rule per MAP domain, traffic from CE to BR will
always use the same destination address (in encapsulation mode) or
prefix (in translation mode). When this address or prefix is
anycast, reliability is greatly increased. If a BR goes down, it
stops advertising the IPv6 anycast address or prefix, and traffic is
automatically re-routed to other BRs. For this mechanism to work
correctly, it is crucial that the anycast route announcement be very
closely tied to BR availability. See [RFC4786] for best current
practices on the operation of anycast services.
Anycast covers global reliability. Reliability within a single link
can be achieved with the help of a redundancy protocol such as VRRP
[RFC5798]. This allows operation of a pair of BRs in active/standby
configuration. No state needs to be shared for the operation of MAP,
so there is no need to keep the standby node in a "warm" state: as
long as it is up and ready to take over the virtual IPv6 address,
quick failover can be achieved. This makes the pair behave as a
single, much more reliable node, with less reliance on quick routing
protocol convergence for reliability.
It is expected that production-quality MAP deployments will make use
of both anycast and a redundancy protocol such as VRRP.
3. MTU/Fragmentation
If the MTU is well-managed such that the IPv6 MTU on the CE WAN side
interface is set so that no fragmentation occurs within the boundary
of the MAP domain, then the 4rd Tunnel MTU can be set to the known
IPv6 MTU minus the size of the encapsulating IPv4 header (40 bytes).
For example, if the IPv6 MTU is known to be 1500 bytes, the 4rd
Tunnel MTU might be set to 1460 bytes. Without more specific
information, the 4rd Tunnel MTU SHOULD default to 1280 bytes.
Sun, et al. Expires September 6, 2012 [Page 14]
Internet-Draft MAP Deployment March 2012
When using encapsulation mode, it is important that fragments of a
MAP packet sent according to the Default Mapping Rule be handled by
the same BR. (This is not required for translation mode.) This can
be a problem when using an anycast BR address and routing
fluctuations cause fragments of a packet to be routed to multiple
BRs.
BRs using an anycast address as source can cause problems. If
traffic sent by a BR with a source anycast address causes an ICMP
error to be returned, that error packet's destination address will be
an anycast address, meaning that a different BR might receive it. In
the case of a Too Big ICMP error, this could cause a path MTU
discovery black hole. Another possible problem could occur if
fragmented packets from different BRs using the same anycast address
as source happen to contain the same fragment ID. This would break
fragment reassembly.
Therefore, when using anycast addresses, it is RECOMMENDED that they
be only used as destination address, and never as source addresses.
BRs SHOULD be configured to accept traffic sent to the anycast
address, but use an unicast address as source.
In MAP domains where IPv4 addresses are not shared, IPv6 destinations
are derived from IPv4 addresses alone. Thus, each IPv4 packet can be
encapsulated and decapsulated independently of each other. 4rd
processing is completely stateless.
On the other hand, in MAP domains where IPv4 addresses are shared,
BRs and CEs may have to encapsulate or translate IPv4 packets whose
IPv6 destinations depend on destination ports. Precautions are
needed, due to the fact that the destination port of a fragmented
datagram is available only in its first fragment. A sufficient
precaution consists in reassembling each datagram received in
multiple packets, and to treat it as though it would have been
received in single packet. This function is such that MAP is in this
case stateful at the IP layer. (This is common with DS-lite and
NAT64/DNS64 which, in addition, are stateful at the transport layer.)
At domain entrance, this ensures that all pieces of all received IPv4
datagrams go to the right IPv6 destinations.
Another peculiarity of shared IPv4 addresses is that, without
precaution, a destination could simultaneously receive from different
sources fragmented datagrams that have the same Datagram ID (the
Identification field of [RFC0791]). This would disturb the
reassembly process. To eliminate this risk, CE MUST rewrite the
datagram ID to a unique value among CEs sharing an IPv4 address upon
sending the packet over a MAP domain. This value SHOULD be generated
locally within the port-range assigned to a given CE. Note that
Sun, et al. Expires September 6, 2012 [Page 15]
Internet-Draft MAP Deployment March 2012
replacing a Datagram ID in an IPv4 header implies an update of its
Header-checksum field, by adding to it the one's complement
difference between the old and the new values.
4.3. CE settings
1. bridging vs. routing mode
In routing mode, the CE runs a standard NAT44 [RFC3022] using the
allocated public address as external IP and ports via DHCPv6 option.
When receiving an IPv4 packet with private source address from its
end hosts, it performs NAT44 function by translating the source
address into public and selecting a port from the allocated port-set.
Then it encapsulates/translates the packet with the concentrator's
IPv6 address as destination IPv6 address, and forwards it to the
concentrator. When receiving an IPv6 packet from the concentrator,
the initiator decapsulates/translates the IPv6 packet to get the IPv4
packet with public destination IPv4 address. Then it performs NAT44
function and translates the destination address into private one.
The CE is responsible for performing ALG functions (e.g., SIP, FTP),
as well as supporting NAT Traversal mechanisms (e.g., UPnP, NAT-PMP,
manual mapping configuration). This is no different from the
standard IPv4 NAT today.
For the bridging mode, end host would run a software performing CE
functionalities. In this case, end host gets public address
directly. It is also suggested that the host run a local NAT to map
randomly generated ports into the restricted, valid port-set.
Another solution is to have the IP stack to only assign ports within
the restricted, valid range to applications. Either way the host
guarantees that every source port number in the outgoing packets
falls into the allocated port-set.
2. CE-initiated application
CE-initiated case is applied for situations where applications run on
CE directly. If the application in CE use the public address
directly, it might conflict with other CEs. So it is highly
suggested that CE should also run a local NAT to map a private
address to public address in CE. In this way, the CE IPv4 address
passed to local applications would be conflict with other CEs.
Moreover, CE should guarantee that every source port number in the
outgoing packets falls into the allocated port-set.
Sun, et al. Expires September 6, 2012 [Page 16]
Internet-Draft MAP Deployment March 2012
4.4. Supporting system
1. Lawful Intercept
Sharing IPv4 addresses among multiple CEs is susceptible to issues
related to lawful intercept. For details, see [RFC6269] section 12.
2. Traffic Logging
It is always possible for a service provider that operates a MAP
domain to determine the IPv6 prefix associated with a MAP IPv4
address (and port number in case of a shared address). This mapping
is static, and it is therefore unnecessary to log every IPv4 address
assignment. However, changes in that static mapping, such as rule
changes in the provisioning system, need to be logged in order to be
able to know the mapping at any point in time.
Sharing IPv4 addresses among multiple CEs is susceptible to issues
related to traffic logging. For details, see [RFC6269] sections 8
and 13.1.
3. Geo-location aware service
Sharing IPv4 addresses among multiple CEs is susceptible to issues
related to geo-location. For details, see [RFC6269] section 7.
4. User Managment (policy control ,etc ... )
MAP IPv4 address assignment, and hence the IPv4 service itself, is
tied to the IPv6 prefix lease; thus, the MAP service is also tied to
this in terms of authorization, accounting, etc. For example, the
MAP address has the same lifetime as its associated IPv6 prefix.
Sun, et al. Expires September 6, 2012 [Page 17]
Internet-Draft MAP Deployment March 2012
5. MAP Address Planning, a Step-by-step Guide
This section is purposed to provide a referential guidance to
operators, illustrating a common fashion of address planning with MAP
in IPv4 residual deployment.
Residual deployment starts from IPv6 address planning.
(A) IPv6 considerations
(A1) Determine the maximum number N of CEs to be supported, and, for
generality, suppose N = 2^n.
For example, we suppose n = 20. It means there will be up to
about one million CEs.
(A2) Choose the length x of IPv6 prefixes to be assigned to ordinary
customers.
Consider we have a /32 IPv6 block, it is not a problem for the
IPv6 deployment with the given number of CEs. Let x = 60,
allowing subnets inside in each CE delegated networks.
(A3) Multiply N by a margin coefficient K, a power of two (K = 2 ^
k), to take into account that:
- Some privileged customers may be assigned IPv6 prefixes of
length x', shorter than x, to have larger addressing spaces
than ordinary customers, both in IPv6 and IPv4;
- Due to the hierarchy of routable prefixes, many theoretically
delegatable prefixes may not be actually delegatable (ref: host
density ratio of [RFC3194]).
In our example, let's take k = 0 for simplicity.
(B) IPv4 considerations
(B1) List all (non overlapping, not yet assigned to any in-running
networks) IPv4 prefixes {Hi} that are available for IPv4
residual deployment.
Suppose that we hold two blocks and not yet assigned to any
fixed network: 192.32.0.0/16 and 63.245.0.0/16.
Sun, et al. Expires September 6, 2012 [Page 18]
Internet-Draft MAP Deployment March 2012
(B2) Take enough of them, among the shortest ones, to get a total
whose size M is a power of two (M = 2 ^ m), and includes a good
proportion of the available IPv4 space.
If we use both blocks, M = 2^16 + 2^16, and therefore m = 17.
Then PSID length could be 3 bits, the corresponding sharing
ratio is also determined so that each CE can have 8192 ports to
use under the shared global IPv4 address; and accordingly the
EA-bit length is (32 - 16) + 3 = 19 bits.
(B3) For each IPv4 prefix, Hi, of length hi, choose an index, say Ri
of length ri = m - (32 - hi).
All these indexes must be non overlapping prefixes (e.g. 0, 10,
110, 111 for one /10, one /11, and two /12). In our example,
we pick 0 for a contiguous block while 1 for another.
Then we have:
H1 = 192.32.0.0./16, h1 = 16, r1 = 1 => R1 = bin(0);
H2 = 63.245.0.0./16, h2 = 16, r2 = 1 => R2 = bin(1);
Sometimes the IPv4 residual pool is not well aggregated and the
contiguous blocks may have different sizes. For example, in (B1), if
we have H1 = 59.112.0.0/13 and H2 = 219.120.0.0/16 as the IPv4
residual pool, then M = 2^19 + 2^16, and in such a case, we must pick
m so that m = ceil(log2(M)), where "ceil(x)" means the minimum
integer not less than x, i.e., m = 20 in this case. Therefore r1 =
20 - (32 - 13) = 1, while r2 = 20 - (32 - 16) = 4. Several
combinations are available for the R1 and R2 and one only needs to
pay attention to avoiding overlapping when picking up the values.
(C) After (A) and (B), derive the rule(s)
(C1) Derive the length c of the MAP domain IPv6 prefix, C, that will
appear at the beginning of all delegated prefixes (c = x - (n +
k)).
(C2) Take any prefix for this C of length c that starts with a RIR-
allocated IPv6 prefix.
(C3) For each IPv4 prefix Hi, make the rule, in which the key is Hi
and the value is the domain IPv6 prefix C followed by the rule
index Ri. Then this i-th rule's Rule IPv6 Prefix will have the
length of (c + ri).
Sun, et al. Expires September 6, 2012 [Page 19]
Internet-Draft MAP Deployment March 2012
Then we can do that:
c = 40 => C = 2001:0db8:ff00::/40
Rule 1: Rule IPv6 Prefix = 2001:0db8:ff00::/41
Rule 2: Rule IPv6 Prefix = 2001:0db8:ff80::/41
If we have different lengths for the Rule IPv4 prefix (as the
extra example discussed at the end of (B)), their Rule IPv6
prefixes should not have the same length, as their rule index
length is different.
As a result, for a certain CE delegating 2001:0db8:ff98:
7650::/60, its parameters are:
Rule IPv6 Prefix = 2001:0db8:ff80::/41 => Rule 2
IPv4 Suffix = bin(001 1000 0111 0110 0)
PSID = bin(101) = 0x5
Rule IPv4 Prefix = 63.245.0.0/16
CE IPv4 Address = 63.245.48.236
If different sharing ratio is demanded, we may partition CEs into
groups and do (A) and (B) for each group, determining the PSID length
for them separately.
Remarks:
1. IPv6 address planning in residual deployment is independent of
the usage of the residual IPv4 addresses.
2. The IPv4 address pool for "residual deployment" contains IPv4
addresses not yet assigned to customers/subscribers and/or those
already recalled from ex-customers. Dynamic assignment is also
considered of the case of "recalled".
3. MAP is mainly designed for residual deployment but also applied
for the case of legacy IPv4 networks keeping communication with
the IPv4 world over the IPv6 domain without renumbering. In such
a case, unlike the residual deployment, the IPv6 addressing is
not independent of IPv4.
4. For the non-residual deployment case, the address format, which
is introduced by [RFC6052] as well as its extensions like
[I-D.xli-behave-divi], is typically applied. The relevance of
MAP- and RFC6052-formats is: once a single rule applies for the
whole IPv4 space, MAP-format becomes equivalent to RFC6052-
format. This frees the domain to distribute any specific rule
information, including the DMR.
Sun, et al. Expires September 6, 2012 [Page 20]
Internet-Draft MAP Deployment March 2012
6. Migration Methodology
6.1. Roadmap for MAP-based Solution
6.1.1. Start from Scratch
IPv6 deployment normally involves a step-wise approach where parts of
the network should properly updated gradually. As IPv6 deployment
progresses it may be simpler for operators to employ a single-version
network, since deploying both IPv4 and IPv6 in parallel would costs
more than IPv6-only network. Therefore switching to an IPv6-only
network in relatively small scale will become more prevalent.
Meanwhile, a significant part of network will still stay in IPv4 for
a long time, especially at early stage of IPv6 transition. There may
not be enough public or private IPv4 addresses to support end-to-end
network communication, without segmenting the network into small
parts with sharing one IPv4 address space. That is a time to
introduce MAP-based solution to bridge these IPv4 islands through
IPv6 backbone network.
6.1.2. Coexiting Phases
A operator may has various deployment strategies. The deployment of
MAP-based solution(i.e., MAP-encapsulation and MAP-translation)
should have a big tolerance to allow different deployment modes to be
occuring. Coexisting deployment would be a basic consideration for
this casualness. In a potential practice, MAP-E and MAP-T would not
only coexist with each other, but also can harmonize with other
deployment cases. Here lists some coexisting cases. (Note: more
coexisting cases are expected to be investigated in future.)
o Case 1: Coexisting between MAP Encapsulation(MAP-E) and MAP
Translation(MAP-T)
o Case 2: Coexisting between MAP translation(Double Translation) and
statelss NAT64 (Single Translation)
o Case3: Coexisting between MAP-based solution and native IPv6
deployement
Regarding the case 1, MAP[I-D.mdt-softwire-mapping-address-and-port]
has provided a good pre-condition, in which a unified address format
and configuration rules have been documented to facilitate the
collocation of MAP-T and MAP-E. Received data packets on CE or BR
could be differentiated and processed accordingly through inspecting
"Next Header" filed in IP header.
Regarding the case 2, separated gateway on the ISP network edge may
Sun, et al. Expires September 6, 2012 [Page 21]
Internet-Draft MAP Deployment March 2012
serve MAP BR and NAT64 respectively. In alternative case, MAP BR or
NAT64 functionality could be configured on the different interfaces
on a standalone gateway. In either case, traffic could be
distributed into proper gateway or interface by addressing diffrent
IPv6 prefix as NAT4prefix and Rule IPv6 prefix.
Regarding the case 3, MAP solutions would not eliminate IPv6 host
accessing MAP CE. Native IPv6 communication should get along with
MAP solution. RFC6204 shoud be applied to CE in this case. Prefix
delegation has two-fold, in which delegated prefix would not only
help to create unique, longer IPv6 prefixes for IPv6 hosts, but also
serve MAP algorithm to implicitly derive shared IPv4 address/port
information. When data packages have been received at CE, it would
distinguish IPv4 packets from native IPv6 packets depending on
preconfigured mapping rules.
6.1.3. Exit Strategy
The benefits of IPv6 + MAP-based solution are that all IPv6 flows
would go directly to the Internet, no need further progressing on
encapsulation or translation. In this way, as more content providers
and service are available over IPv6, the utilization on MAP CE and BR
goes down since fewer destinations require MAP progressing. This way
would advance IPv6, because it provides everyone incentives to use
IPv6, and eventually the result is an pure IPv6 network with no need
for IPv4. As more content providers and hosts equiped with IPv6
capabilities , the MAP utilization goes down until it is eventually
not used at all when all content is IPv6. In this way, MAP has an
"exit strategy". The corresponding solutions will leave the network
in time.
6.2. Migration Mode
IPv4 Residual deployment is an interim phase during IPv6 migration.
It would be beneficial for ISPs, if this phase is as short as
possible since end-to-end IPv6 traversal is the really goals. When
IPv6 is getting more and more mature, MAP solution would be retired
in a natural way or enforced by particular considerations.
6.2.1. Passive Transition
Passive Transition is following IPv4 retirement law. In another
word, MAP would always get along with IPv4 appearance, even all nodes
is dual-stack capable. At a later stage of IPv6 migration, MAP based
solutions can also be served for dual-stack hosts, which is sending
traffic through the IPv4 stack. There is still a value for this
approach because it could steer IPv4 traffic to IPv6 going through a
MAP CE processing. When it comes the time when ISP decide to turn
Sun, et al. Expires September 6, 2012 [Page 22]
Internet-Draft MAP Deployment March 2012
off IPv4, MAP would be faded due to IPv4 disappearance.
6.2.2. Active Transition
Active Transition is targeting to accelerate IPv4 exit and increase
native IPv6 utilization. A desirable way deploying MAP solution is
only providing IPv6 traversal ability to an IPv4-only host. However,
MAP CE can not determine received traffic is sent from an IPv4 node
or a dual-stack node. In the latter case, IPv6 utilization is
prefered in a common case. When a network evolves to a post-IPv6
era, it might be good for ISP to consider implementing enforcements
rules to help IPv6 migration. There is a set of approach would help
the situation.
o ISP could install only IPv6 record (i.e. AAAA) in DNS server,
which would provide users with IPv6 steering effects. When a host
is IPv6-capable and gets IPv6 DNS reply in advance, MAP
functionalities would be restricted by IPv6-only record reply
o ISP could retrieve shared IPv4 address by increasing sharing
ratio. In this case, number of concurrent IPv4 sessions on MAP CE
would be suppressed. It would encourage native IPv6 growth in
some extent.
o ISP could allocate a dedicated IPv6 prefix for MAP deployment.
The allocation could not only facilitate the differentiation
between MAPed traffic and native IPv6 trafffic, but also clearly
observe the tendency of MAP traffic. When the traffic is getting
down for while, ISP could close the MAP functionalities in some
specific area. It would result networks to native IPv6-only
capable.
Sun, et al. Expires September 6, 2012 [Page 23]
Internet-Draft MAP Deployment March 2012
7. IANA Considerations
This specification does not require any IANA actions.
Sun, et al. Expires September 6, 2012 [Page 24]
Internet-Draft MAP Deployment March 2012
8. Security Considerations
There are no new security considerations pertaining to this document.
Sun, et al. Expires September 6, 2012 [Page 25]
Internet-Draft MAP Deployment March 2012
9. Additional Author List
Simon Perreault
Viagenie
246 Aberdeen
Quebec, QC G1R 2E1
Canada
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
Sun, et al. Expires September 6, 2012 [Page 26]
Internet-Draft MAP Deployment March 2012
10. Acknowledgements
Remi Despres contributed the original example of step-by-step
deployment guidance in discussion with the authors. Ole Troan, as
the head of MAP Design Team, joined the discussion directly and
contributed a lot of ideas and comments. We also thank other members
of the MAP Design Team for their comments and suggestions.
Sun, et al. Expires September 6, 2012 [Page 27]
Internet-Draft MAP Deployment March 2012
11. References
11.1. Normative References
[I-D.mdt-softwire-map-dhcp-option]
Mrugalski, T., Boucadair, M., Deng, X., Troan, O., and C.
Bao, "DHCPv6 Options for Mapping of Address and Port",
draft-mdt-softwire-map-dhcp-option-02 (work in progress),
January 2012.
[I-D.mdt-softwire-mapping-address-and-port]
Bao, C., Troan, O., Matsushima, S., Murakami, T., and X.
Li, "Mapping of Address and Port (MAP)",
draft-mdt-softwire-mapping-address-and-port-03 (work in
progress), January 2012.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5342] Eastlake, D., "IANA Considerations and IETF Protocol Usage
for IEEE 802 Parameters", BCP 141, RFC 5342,
September 2008.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
[RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the
IPv4 Address Shortage", RFC 6346, August 2011.
11.2. Informative References
[I-D.dec-stateless-4v6]
Dec, W., Asati, R., and H. Deng, "Stateless 4Via6 Address
Sharing", draft-dec-stateless-4v6-04 (work in progress),
October 2011.
[I-D.murakami-softwire-4rd]
Murakami, T., Troan, O., and S. Matsushima, "IPv4 Residual
Deployment on IPv6 infrastructure - protocol
specification", draft-murakami-softwire-4rd-01 (work in
progress), September 2011.
[I-D.xli-behave-divi]
Shang, W., Li, X., Zhai, Y., and C. Bao, "dIVI: Dual-
Stateless IPv4/IPv6 Translation", draft-xli-behave-divi-04
(work in progress), October 2011.
[I-D.xli-softwire-divi-pd]
Sun, et al. Expires September 6, 2012 [Page 28]
Internet-Draft MAP Deployment March 2012
Sun, Q., Asati, R., Xie, C., Li, X., Dec, W., and C. Bao,
"dIVI-pd: Dual-Stateless IPv4/IPv6 Translation with Prefix
Delegation", draft-xli-softwire-divi-pd-01 (work in
progress), October 2011.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC3194] Durand, A. and C. Huitema, "The H-Density Ratio for
Address Assignment Efficiency An Update on the H ratio",
RFC 3194, November 2001.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
Sun, et al. Expires September 6, 2012 [Page 29]
Internet-Draft MAP Deployment March 2012
Authors' Addresses
Qiong Sun
China Telecom
Room 708 No.118, Xizhimenneidajie
Beijing, 100035
P.R.China
Phone: +86 10 5855 2923
Email: sunqiong@ctbri.com.cn
Maoke Chen
FreeBit Co., Ltd.
13F E-space Tower, Maruyama-cho 3-6
Shibuya-ku, Tokyo 150-0044
Japan
Email: fibrib@gmail.com
Gang Chen
China Mobile
28 Xuanwumenxi Ave; Xuanwu District
Beijing
P.R. China
Email: chengang@chinamobile.com
Chunfa Sun
Softbank BB
Tokyo Shiodome Building. 22F
1-9-1,Higashi-Shimbashi,Minato-Ku
Tokyo 105-7322
JAPAN
Email: chunfa.sun@g.softbank.co.jp
Sun, et al. Expires September 6, 2012 [Page 30]
Internet-Draft MAP Deployment March 2012
Tina Tsou
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Phone: +1-408-330-4424
Email: tina.tsou.zouting@huawei.com
Simon Perreault
Huawei Technologies
Quebec, QC G1R 2E1
Santa Clara, Aberdeen 246
USA
Phone: +1 418 656 9254
Email: simon.perreault@viagenie.ca
Sun, et al. Expires September 6, 2012 [Page 31]